information management

Abstract

Embodiments of the present disclosure disclose devices, methods, and apparatuses for information management. In an embodiment, a first apparatus transmits a first request to a second apparatus, the first request being for authorization to open first user data to a third apparatus, the third apparatus comprising an application programming interface (API) invoker. The first request indicates the first user data and one or more attributes related to the first user data. The first apparatus then receives a first response message from the second apparatus, the first response message indicating that i) user data among the first user data is allowed to be opened, or ii) the first user data is not allowed to be opened.

Description

Technical Field

[0001] Various example embodiments relate to the field of communications, and more specifically, to devices, methods, apparatuses, and computer-readable storage media for information management (e.g., management of sensitive user information). Background Technology

[0002] A communication network can be viewed as a facility that enables communication between two or more communication devices, or as a facility that provides communication devices with access to a data network. Mobile or wireless communication networks are an example of communication networks.

[0003] Such communication networks operate according to standards such as those issued by 3GPP (3rd Generation Partnership Project) or ETSI (European Telecommunications Standards Institute). Examples of such standards include the so-called 5G (fifth generation) standard or other standards issued by 3GPP. Summary of the Invention

[0004] Generally, the exemplary embodiments of this disclosure provide solutions for information management (e.g., management of sensitive user information).

[0005] In a first aspect, a first device is provided, comprising a Common Application Programming Interface Framework Core Functionality (CCF). The first device includes at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured, together with the at least one processor, to enable the first device to: transmit a first request to a second device, wherein the first request is for authorization to expose first user data to a third device, the third device including an application programming interface (API) caller. The first request indicates the first user data and one or more attributes associated with the first user data. The first device is also enabled to receive a first response message from the second device, the first response message indicating: i) user data among the first user data that is permitted to be exposed, or ii) the first user data that is not permitted to be exposed.

[0006] In a second aspect, a second device is provided. The second device includes at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured, together with the at least one processor, to enable the second device to: receive a first request from a first device, the first device including Common Application Programming Interface Framework Core Functionality (CCF), the first request being for authorization to expose first user data to a third device, the third device including an Application Programming Interface (API) caller. The first request indicates the first user data and one or more attributes associated with the first user data. The second device also enables the second device to transmit a first response message to the first device, the first response message indicating: i) user data in the first user data that is permitted to be exposed, or ii) the first user data that is not permitted to be exposed.

[0007] In a third aspect, a third device is provided. The third device includes at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured, together with the at least one processor, to enable the third device to: transmit a second request for an access token to a first device, the first device including Common Application Programming Interface Framework Core Functionality (CCF). The second request indicates required first user data and one or more additional attributes associated with the first user data. The third device is also enabled to receive an access token from the first device.

[0008] In a fourth aspect, a fourth device is provided. The fourth device includes at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured, together with the at least one processor, to enable the fourth device to transmit a third request to a first device for publishing one or more APIs, the first device including Common Application Programming Interface Framework Core Functionality (CCF). The third request indicates second user data associated with one or more APIs and a second or more attributes associated with the second user data.

[0009] In a fifth aspect, a fifth device is provided. The fifth device includes at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured, together with the at least one processor, to enable the fifth device to: receive an eighth request from a third device for an API-related service, the third device including an application programming interface (API) caller. The fifth device is also configured to: determine, based on the eighth request, sensitive information to be disclosed; transmit a sixth request to a first device for disclosing authorized sensitive information, the first device including a Common Application Programming Interface Framework Core Function (CCF); and receive a response message from the first device, the response message indicating: i) user data in first user data that is permitted to be disclosed, or ii) the first user data that is not permitted to be disclosed.

[0010] In a sixth aspect, a method implemented at a first device is provided. The method includes: transmitting a first request to a second device, the first request for authorization to expose first user data to a third device, the third device including an application programming interface (API) caller, wherein the first request indicates the first user data and one or more attributes associated with the first user data; and receiving a first response message from the second device, the first response message indicating: i) user data within the first user data that is permitted to be exposed, or ii) the first user data that is not permitted to be exposed.

[0011] In a seventh aspect, a method implemented at a second device is provided. The method includes: receiving a first request from a first device, the first device including Common Application Programming Interface Framework Core Functionality (CCF), the first request for authorization to expose first user data to a third device, the third device including an Application Programming Interface (API) caller, wherein the first request indicates the first user data and one or more attributes associated with the first user data; and transmitting a first response message to the first device, the first response message indicating: i) user data within the first user data that is permitted to be exposed, or ii) the first user data that is not permitted to be exposed.

[0012] In an eighth aspect, a method implemented at a third device is provided. The method includes: transmitting a second request for an access token to a first device, the first device including Common Application Programming Interface Framework Core Functionality (CCF), wherein the second request indicates required first user data and one or more additional attributes associated with the first user data; and receiving the access token from the first device.

[0013] In a ninth aspect, a method implemented at a fourth device is provided. The method includes transmitting a third request to a first device for publishing one or more APIs, the first device including the Common Application Programming Interface Framework Core Functionality (CCF). The third request indicates second user data associated with the one or more APIs and a second or more attributes related to the second user data.

[0014] In a tenth aspect, a method implemented at a fifth device is provided. The method includes: receiving an eighth request from a third device for an API-related service, the third device including an application programming interface (API) caller; determining sensitive information to be disclosed based on the eighth request; transmitting a sixth request to a first device for disclosing authorized sensitive information, the first device including Common Application Programming Interface Framework Core Functionality (CCF); and receiving a response message from the first device, the response message indicating: i) user data in the first user data that is permitted to be disclosed, or ii) the first user data that is not permitted to be disclosed.

[0015] In the eleventh aspect, a first apparatus including the core functionality of a public application programming interface framework (CCF) is provided, and the first apparatus includes: a component for transmitting a first request to a second apparatus, the first request being for authorizing the disclosure of first user data to a third apparatus, the third apparatus including an application programming interface (API) caller, wherein the first request indicates the first user data and one or more attributes associated with the first user data; and a component for receiving a first response message from the second apparatus, the first response message indicating: i) user data in the first user data that is permitted to be disclosed, or ii) the first user data that is not permitted to be disclosed.

[0016] In a twelfth aspect, a second apparatus is provided, comprising: components for receiving a first request from a first apparatus, the first apparatus including Common Application Programming Interface Framework Core Functionality (CCF), the first request being for authorizing the disclosure of first user data to a third apparatus, the third apparatus including an Application Programming Interface (API) caller, wherein the first request indicates the first user data and one or more attributes associated with the first user data; and components for transmitting a first response message to the first apparatus, the first response message indicating: i) user data in the first user data that is permitted to be disclosed, or ii) the first user data that is not permitted to be disclosed.

[0017] In a thirteenth aspect, a third device is provided that includes an application programming interface (API) caller, and the third device includes: components for transmitting a second request for an access token to a first device, the first device including Common Application Programming Interface Framework Core Functionality (CCF), wherein the second request indicates required first user data and one or more additional attributes associated with the first user data; and components for receiving an access token from the first device.

[0018] In a fourteenth aspect, a fourth means is provided that includes at least one of an Application Programming Interface (API) Open Function (AEF) or an API Release Function (APF), and the fourth means includes: a component for transmitting a third request to a first means for releasing one or more APIs, the first means including a Common Application Programming Interface Framework Core Function (CCF), wherein the third request indicates second user data associated with one or more APIs and a second or more attributes associated with the second user data.

[0019] In a fifteenth aspect, a fifth apparatus including API Open Functionality (AEF) is provided, and the fifth apparatus includes: components for receiving an eighth request from a third apparatus for an API-related service, the third apparatus including an application programming interface (API) caller; components for determining sensitive information to be opened based on the eighth request; components for transmitting a sixth request to a first apparatus for opening authorized sensitive information, the first apparatus including Common Application Programming Interface Framework Core Functionality (CCF); and components for receiving a response message from the first apparatus, the response message indicating: i) user data in the first user data that is allowed to be opened, or ii) the first user data that is not allowed to be opened.

[0020] In a sixteenth aspect, a computer program is provided that includes instructions, which, when executed by a device, cause the device to at least: transmit a first request to a second device, the first request being for authorization to disclose first user data to a third device, the third device including an application programming interface (API) caller. The first request indicates the first user data and one or more attributes associated with the first user data. The device is also caused to receive a first response message from the second device, the first response message indicating: i) user data within the first user data that is permitted to be disclosed, or ii) the first user data that is not permitted to be disclosed.

[0021] In a seventeenth aspect, a computer program is provided that includes instructions, which, when executed by a device, cause the device to at least: receive a first request from a first device, the first device including Common Application Programming Interface Framework Core Functionality (CCF), the first request being for authorization to expose first user data to a third device, the third device including an Application Programming Interface (API) caller. The first request indicates the first user data and one or more attributes associated with the first user data. The device also causes the device to transmit a first response message to the first device, the first response message indicating: i) user data within the first user data that is permitted to be exposed, or ii) the first user data that is not permitted to be exposed.

[0022] In an eighteenth aspect, a computer program is provided that includes instructions, which, when executed by a device, cause the device to at least: transmit a second request for an access token to a first device, the first device including Common Application Programming Interface Framework Core Functionality (CCF). The second request indicates required first user data and one or more additional attributes associated with the first user data. The device also receives an access token from the first device.

[0023] In a nineteenth aspect, a computer program including instructions is provided that, when executed by a device, causes the device to at least: transmit to a first device a third request for publishing one or more APIs, the first device including Common Application Programming Interface Framework Core Functionality (CCF). The third request indicates second user data associated with the one or more APIs and a second or more attributes associated with the second user data.

[0024] In a twentieth aspect, a computer program is provided that includes instructions, which, when executed by a device, cause the device to at least: receive an eighth request from a third device for an API-related service, the third device including an application programming interface (API) caller. The device is also provided to: determine, based on the eighth request, sensitive information to be disclosed; transmit a sixth request to a first device for disclosing authorized sensitive information, the first device including Common Application Programming Interface Framework Core Functions (CCF); and receive a response message from the first device indicating: i) user data in the first user data that is permitted to be disclosed, or ii) the first user data that is not permitted to be disclosed.

[0025] In a twenty-first aspect, a first apparatus device including the core functionality (CCF) of a Public Application Programming Interface Framework is provided. The first apparatus includes: a transmission circuit configured to: transmit a first request to a second apparatus, the first request being for authorization to expose first user data to a third apparatus, the third apparatus including an application programming interface (API) caller, wherein the first request indicates the first user data and one or more attributes associated with the first user data; and a receiving circuit configured to receive a first response message from the second apparatus, the first response message indicating: i) user data in the first user data that is permitted to be exposed, or ii) the first user data that is not permitted to be exposed.

[0026] In a twenty-second aspect, a second apparatus is provided. The second apparatus includes: a receiving circuit configured to receive a first request from a first apparatus, the first apparatus including a Common Application Programming Interface Framework Core Function (CCF), the first request being for authorization to expose first user data to a third apparatus, the third apparatus including an Application Programming Interface (API) caller, wherein the first request indicates the first user data and one or more attributes associated with the first user data; and a transmitting circuit configured to transmit a first response message to the first apparatus, the first response message indicating: i) user data in the first user data that is permitted to be exposed, or ii) the first user data that is not permitted to be exposed.

[0027] In a twenty-third aspect, a third device is provided that includes an application programming interface (API) caller. The third device includes: a transmission circuit configured to transmit a second request for an access token to a first device, the first device including a Common Application Programming Interface Framework Core Function (CCF), wherein the second request indicates required first user data and one or more additional attributes associated with the first user data; and a receiving circuit configured to receive the access token from the first device.

[0028] In a twenty-fourth aspect, a fourth device is provided, including at least one of an Application Programming Interface (API) Open Function (AEF) or an API Publishing Function (APF). The fourth device includes: a transmission circuit configured to transmit to a first device a third request for publishing one or more APIs, the first device including a Common Application Programming Interface Framework Core Function (CCF), wherein the third request indicates second user data associated with one or more APIs and a second or more attributes associated with the second user data.

[0029] In a twenty-fifth aspect, a fifth device is provided that includes an API Open Function (AEF). The fifth device includes: a first receiving circuit configured to receive an eighth request from a third device for an API-related service, the third device including an application programming interface (API) caller; a determining circuit configured to determine sensitive information to be opened based on the eighth request; a transmitting circuit configured to transmit a sixth request to the first device for opening the authorized sensitive information; and a second receiving circuit configured to receive a response message from the first device, the response message indicating: i) first user data that is allowed to be opened, or ii) the first user data is not allowed to be opened.

[0030] In a twenty-sixth aspect, a non-transitory computer-readable medium is provided, including program instructions for causing the apparatus to perform at least the method according to any one of the sixth to tenth aspects above.

[0031] It should be understood that the summary portion is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0032] Some exemplary embodiments will now be described with reference to the accompanying drawings, in which: Figure 1 An example communication network in which embodiments of the present disclosure may be implemented is shown; Figure 2 An example signaling process for information management according to an example embodiment of this disclosure is shown; Figure 3 A specific example of user sensitive information management in a virtual world via a Public Application Programming Interface Function (CAPIF) is shown according to an exemplary embodiment of this disclosure; Figure 4 Another example signaling process for information management according to an example embodiment of this disclosure is shown; Figure 5Another specific example of user-sensitive information management in a virtual world via a Public Application Programming Interface Function (CAPIF) according to an example embodiment of the present disclosure is shown, wherein the CAPIF provider and the application programming interface (API) provider are in different domains; Figure 6 A flowchart is shown showing a method implemented at a first device according to some embodiments of the present disclosure; Figure 7 A flowchart is shown illustrating a method implemented at a second device according to some embodiments of the present disclosure; Figure 8 A flowchart is shown illustrating a method implemented at a third device according to some embodiments of the present disclosure; Figure 9 A flowchart is shown illustrating a method implemented at a fourth device according to some embodiments of the present disclosure; Figure 10 A flowchart is shown illustrating a method implemented at a fifth device according to some embodiments of the present disclosure; Figure 11 A simplified block diagram of an apparatus suitable for implementing embodiments of the present disclosure is shown; and Figure 12 A block diagram of an example computer-readable medium according to some embodiments of the present disclosure is shown.

[0033] Throughout the accompanying drawings, the same or similar reference numerals denote the same or similar elements. Detailed Implementation

[0034] The principles of this disclosure will now be described with reference to some exemplary embodiments. It should be understood that these embodiments are described for illustrative purposes only and to help those skilled in the art to understand and implement this disclosure, without implying any limitation on the scope of this disclosure. The disclosure described herein can be implemented in various ways other than those described below.

[0035] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0036] References to "an embodiment," "embodiment," "example embodiment," etc., in this disclosure indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment includes that particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Moreover, when a particular feature, structure, or characteristic is described in connection with an embodiment, whether explicitly described or not, those skilled in the art will recognize that such features, structures, or characteristics apply in conjunction with other embodiments.

[0037] It should be understood that although the terms “first” and “second” may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of the exemplary embodiments, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0038] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments. As used herein, the singular forms “a,” “an,” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise. It will also be understood that the terms “comprising,” “including,” “having,” “possessing,” “containing,” and / or “covering” as used herein specify the presence of stated features, elements, and / or components, etc., but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof. As used herein, “at least one of the following: ” and “at least one of ” and similar expressions, wherein the list of two or more elements is connected by “and” or “or”, means at least any one of these elements, or at least any two or more of these elements, or at least all of the elements.

[0039] As used in this application, the term "circuit system" may refer to one or more or all of the following: (a) Hardware circuit implementation only (e.g., implemented with purely analog and / or digital circuits), and (b) A combination of hardware circuitry and software, such as (if applicable): (i) A combination of (multiple) analog and / or digital hardware circuits and software / firmware, and (ii) Any part of a hardware processor(s) having software (including (multiple) digital signal processors, software, and (multiple) memories, which work together to enable a device (such as a mobile phone or server) to perform various functions), and (c) The operation requires software (e.g., firmware) for the operation of (multiple) hardware circuits and / or (multiple) processors, such as (multiple) microprocessors or parts thereof, but the software may be absent when the operation does not require the software.

[0040] This definition of "circuit" applies to all uses of the term in this application, including in any claim. As another example, as used herein, the term "circuit" also encompasses only hardware circuitry or a processor (or multiple processors), or portions of hardware circuitry or a processor and their accompanying software and / or firmware implementations. For instance, where applicable to specific claim elements, the term "circuit" also encompasses baseband integrated circuits or processor integrated circuits for mobile devices or servers, cellular network devices, or other computing or networking devices.

[0041] As used herein, the term "communication network" refers to a network that conforms to any suitable communication standard, such as 5G New Radio (NR), Long Term Evolution (LTE), LTE-A Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed ​​Packet Access (HSPA), Narrowband Internet of Things (NB-IoT), etc. Furthermore, communication between terminal devices and network devices in a communication network can be performed according to any suitable generated communication protocol, including but not limited to first-generation (1G), second-generation (2G), 2.5G, 2.75G, third-generation (3G), fourth-generation (4G), 4.5G, future fifth-generation (5G) communication protocols, future sixth-generation (6G) communication protocols, and / or any other currently known or future-developed protocols. Embodiments of this disclosure can be applied to various communication systems. Given the rapid development of communications, there will inevitably be future types of communication technologies and systems that can implement this disclosure. The scope of this disclosure should not be limited to the aforementioned systems only.

[0042] As used herein, the term "network device" refers to a node in a communication network through which terminal devices access the network and receive services. Depending on the terminology and technology applied, a network device can refer to a base station (BS) or access point (AP), such as a Node B (NodeB or NB), an evolved Node B (eNodeB or eNB), an NR NB (also known as a gNB, a base station for 5G systems), a Remote Radio Unit (RRU), a Radio Head (RH), a Remote Radio Head (RRH), a relay, or a low-power node (such as a femtosecond, picosecond, etc.).

[0043] The term "terminal device" refers to any terminal device capable of wireless communication. As an example and not a limitation, a terminal device may also be referred to as a communication device, user equipment (UE), subscriber station (SS), portable subscriber station, mobile station (MS), or access terminal (AT). Terminal devices may include, but are not limited to, mobile phones, cellular phones, smartphones, Voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable terminal devices, personal digital assistants (PDAs), portable computers, desktop computers, image acquisition terminal devices (such as digital cameras), gaming terminal devices, music storage and playback devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, laptop embedded devices (LEE), laptop mounted devices (LME), USB dongles, smart devices, wireless customer premises equipment (CPE), Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. In the following description, the terms "terminal equipment", "communication equipment", "terminal", "user equipment" and "UE" are used interchangeably.

[0044] In some example embodiments of this disclosure, the term "Application Programming Interface (API)" refers to an interface between software components. It defines how different software components interact with each other. It acts as a bridge for communication between software components, much like a door between different rooms, allowing information and operations to pass between different software components.

[0045] In some example embodiments of this disclosure, the term "Common API Framework (CAPIF)" refers to a unified framework for all APIs within the 3GPP system. CAPIF provides a set of pre-built tools and functionalities to enable rapid API construction and deployment. Typically, CAPIF may include the following components and functionalities: API caller, CAPIF Core Function (CCF), API Open Function, and API Publishing Function. The API caller, typically provided by a third party, is responsible for mutual authorization, API discovery, and API invocation. The CCF is responsible for authorizing API callers, granting them authorization before they use the API services, publishing and storing API information, and handling API caller registration and deregistration. The AEF provides the service API and acts as the service communication entry point for API callers. The APF enables API providers to publish service API information via the CCF, thereby facilitating API discovery by API callers.

[0046] With technological advancements, Application Programming Interfaces (APIs) have become multifaceted and crucial. APIs act as bridges, enabling seamless communication and data exchange between different software applications, systems, and platforms. For example, an e-commerce application (app) can use APIs to connect with various related systems. This allows users to check account balances, transfer funds, and view transaction history across multiple sellers through a single interface. Without APIs, integrating these different services would be a complex and time-consuming task.

[0047] To utilize an API, an API caller, located on an end device or the network side, can request services from the API. Typically, the API caller can provide the necessary credentials or tokens to prove its identity and gain access to the API's resources. As an illustrative example, the API caller acts as a client or consumer, while the API is analogous to a service provider. The API caller sends requests to the API, which processes these requests and sends back a response.

[0048] However, the widespread use of APIs also brings risks. For example, a large number of detected attacks target APIs and related entities, making them top targets for cyberattacks. Attacks such as unauthorized access, API abuse, and data theft are becoming increasingly common. Therefore, security has become a critical priority in API development, especially regarding the exposure of sensitive user information during API use.

[0049] As an example only, if an API (such as a avatar) provided by an API Open Functionality (AEF, e.g., a SEAL server) involves sensitive user information related to the personal details of the avatar owner (RO), such as age, mobile number, location, health, clothing choices, links to social media, etc., the RO of the avatar (e.g., the avatar owner) may not be aware that such personal or sensitive data is being shared with the API caller (on the end device or network) when they access the avatar. This lack of awareness raises privacy issues for the resource owner.

[0050] Specifically, CAPIF's CCF only receives the API name from the access token request and is unaware of any sensitive information that the resource owner has disclosed to the API (and / or the API caller). In this scenario, the CCF cannot obtain any authorization from the resource owner regarding sensitive information. Therefore, this lack of transparency can lead to potential privacy risks for the resource owner, resulting in regulatory non-compliance issues for the operator and potentially severely impacting their business and finances. For the sake of discussion, some specific details regarding the disclosure of sensitive information and API utilization mechanisms are discussed further below.

[0051] In light of these analyses and considerations, several aspects of information management are proposed in some embodiments of this disclosure. In some example embodiments of this disclosure, the RO function (ROF) or terminal device supports a more granular level (or finer-grained) authorization for the opening of user data (e.g., sensitive information). For example, the user can know the potential events for opening user data, the user data to be opened, the attributes of the user data (e.g., purpose of use, sensitivity level), the risks associated with opening, etc. The user can then decide whether to open at least a portion of the user data accordingly.

[0052] In one aspect, the first device transmits a first request to the second device, the first request authorizing the opening of first user data to a third device. In some example embodiments of this disclosure, the first device may include a CCF of CAPIF, and the second device may include, or be associated with, the resource owner (RO) of the first user data. The first request indicates the first user data and one or more attributes associated with the first user data. The second device responds to the first request by transmitting a first response message to the first device, and the first response indicates: i) user data within the first user data that is permitted to be opened, or ii) the first user data that is not permitted to be opened. In some example embodiments of this disclosure, the first request may be triggered by an access token request transmitted from an API caller, or an open authorization request transmitted from an APE in a different domain.

[0053] In this way, resource owners can know in advance whether sensitive information needs to be disclosed to API callers or the API itself. Then, resource owners can decide whether to allow this disclosure on demand. Therefore, the disclosure of sensitive information can be managed accordingly.

[0054] The principles and embodiments of this disclosure will now be described in detail with reference to the accompanying drawings. First, refer to... Figure 1 This document illustrates an example communication system 100 (or communication network) in which embodiments of the present disclosure may be implemented. System 100 (e.g., communication network) includes: a first device 110, which may include a CCF; a second device 120, which may be a terminal device or UE including RO and ROF; a third device, which may include an API caller; and a fourth device, which may include an AEF and an APF in the same domain A as the CAPIF provider. In some embodiments of the present disclosure, the third device or API caller may be configured on the network device side or on the user equipment (e.g., a terminal device or UE).

[0055] System 100 also includes a fifth device comprising another AEF located in a different domain B than the CAPIF in domain A. The AEF in the fifth device can also be considered an API provider. In some embodiments of this disclosure, a domain can refer to a legal entity. That is, functional entities in different domains can belong to different legal entities.

[0056] Communication in communication system 100 may be implemented according to any suitable communication protocol, including but not limited to cellular communication protocols such as first-generation (1G), second-generation (2G), third-generation (3G), fourth-generation (4G), and fifth-generation (5G), wireless local area network communication protocols (such as IEEE 802.11), and / or any other currently known or to be developed in the future. Furthermore, communication may utilize any suitable wireless communication technology, including but not limited to: code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), frequency division duplex (FDD), time division duplex (TDD), multiple-input multiple-output (MIMO), orthogonal frequency division multiple access (OFDM), discrete Fourier transform extended OFDM (DFT-s-OFDM), and / or any other currently known or to be developed in the future.

[0057] As mentioned above, during an API call, CAPIF's CCF only receives the API name from the access token request and is unaware of any sensitive information that the resource owner has disclosed to the API (and / or the API caller). In this case, the CCF cannot obtain any authorization from the resource owner regarding sensitive information. The following lists some signaling formats related to API calls for illustrative purposes only. Table 1 shows at least a portion of the information elements in a service API posting request from APF to CCF.

[0058] Table 1

[0059] Table 2 shows at least a portion of the information elements in the API caller request from the API caller to the CCF.

[0060] Table 2

[0061] Table 3 shows at least a portion of the information elements in the loaded API caller response from the CCF to the API caller.

[0062] Table 3

[0063] Table 4 shows at least a portion of the information elements in the access token request message parameters from the API caller to the CCF.

[0064] Table 4

[0065] Based on the above, it can be seen that during the API caller's loading process, no indication was made regarding the API's publication, access token requests, the user data to be used, or the attributes of that user data. Therefore, the CCF cannot know which sensitive information the resource owner has opened to the API (and / or the API caller). Consequently, the CCF cannot request the resource owner to permit the opening of data, because the CCF does not know which data will be used.

[0066] In addition, some other related details need to be considered. Resource Owner-Aware Northbound API Access (RNAA) is designed for end-user authorization to access any information of the resource owner of the desired server. However, it has some issues that need to be addressed. One issue is that it does not distinguish between privacy-sensitive data, which requires explicit user permission to comply with regulations. This lack of distinction could lead to potential privacy violations.

[0067] Another aspect to consider is data retention. Clear guidance is needed regarding how long data will be retained. Regulatory policies and data storage costs are likely two major factors guiding this decision. If there are compliance requirements for certain data, the compliance policy typically defines a minimum retention period. However, the cost of storing data for extended periods also needs to be considered. For example, if the cost of maintaining servers to store data is too high and exceeds the value of the data, it may be necessary to shorten the retention period.

[0068] Then, there's the question of how to revoke consent or permission for certain data. Making it easy for users to revoke permission is crucial. Some platforms have made the process relatively simple, allowing users to go to a specific tab, select their account, and click "Disconnect" to revoke permission. However, it's essential to ensure this process is seamless and effective in all scenarios. Distinguishing which data is mandatory for providing the service and which is optional for advertising, optimization, etc., is also important. This clarity helps users understand what data they need to provide and for other purposes. It gives users more control over their data.

[0069] If user data is collected or shared, users also need to know the results. For example, if their mobility can be tracked or their health status can be made public. Transparency in this regard is key to building trust with users. It may also need to be known which entity will use the data for what purpose. For example, user data might be used by a third-party API caller to represent users as virtual avatars with personal attributes in a game. This information needs to be clearly communicated to the user. During the API discovery phase, it's necessary to consider how user permission will be considered to avoid denial during the access token request phase. This will streamline the process and make it more efficient for both users and service providers. Last but not least, when the CAPIF provider and the API provider are different legal entities, appropriate mechanisms are needed to handle user permission. This ensures that user rights are protected and that the responsibilities of all parties involved regarding user data are clearly defined.

[0070] At least in order to address the aforementioned problems and risks, we now refer to Figure 2 This illustrates an example signaling process for information management according to an example embodiment of the present disclosure. For discussion purposes, reference will be made to... Figure 1 Describe the signaling process 200. It should be understood that, although it has already... Figure 1 The signaling process 200 is described in the communication environment 100, but the signaling process 200 can also be applied to other communication scenarios.

[0071] In signaling procedure 200, fourth device 140 transmits (201) a request 203 to first device for publishing one or more APIs. This request indicates user data associated with one or more APIs and one or more attributes associated with the user data. For discussion purposes only, in some example embodiments of this disclosure, the request for publishing one or more APIs may also be referred to as a “third request” or a “publishing request,” the user data associated with the API may also be referred to as “second user data,” and the one or more attributes associated with the second user data may also be referred to as “second one or more attributes.” In some embodiments, the APF in fourth device 140 may transmit the third request.

[0072] In some embodiments, the indicated second user data may include user data that the API may potentially expose to third-party applications. The second or more attributes may be attributes(s) of the second user data, such as whether the data is sensitive personal data subject to privacy regulations. In some example embodiments of this disclosure, attributes of user data (whether the second user data or other user data discussed below) may include the sensitivity level of the user data (e.g., high or low sensitivity regarding privacy), shareability with the API consumer (e.g., yes or no), and / or the purpose of use of the user data (e.g., location purposes, health monitoring purposes, etc.). Additionally or alternatively, attributes of the user data may include the level of necessity for using the first user data (e.g., optional or mandatory), the consumer of the user data, and / or the processing entity of the user data (e.g., processor). Additionally or alternatively, this attribute may include the potential risks of exposing the first user data (e.g., financial risks, location exposure risks) and / or the lifetime of the user data (e.g., how long the consumer or processing entity will retain the user data).

[0073] Specifically, in some embodiments, the "Shareability" attribute can indicate whether user data can be shared with API consumers. For example, when AEF publishes a "Shareability" attribute of "No" for user data, AEF will never share that user data with any API consumer. Regarding the "Sensitivity" attribute, when user data is marked with "Yes" for sensitivity, this means that the user data is considered sensitive / private to the user according to AEF's regulatory requirements. The "Purpose" attribute can indicate to the CCF what purpose the user data will be used for. For example, an API caller can indicate to the CCF the purpose for which the user data is required. Furthermore, the purpose could be gaming, advertising, etc. The "Necessity" attribute can indicate whether the user data is "mandatory," "optional," "recommended," etc. When the necessity attribute is set by the API caller, this means that the API caller requires the user data mandatorily, optionally, or recommendedly. The "Lifetime" attribute can indicate how long the user data will remain in AEF or with the API caller.

[0074] In some embodiments, a third request may include one or more user data names of the second user data and at least one attribute corresponding to each user data name. In this way, the second user data can be categorized into different dimensions, and each dimension can be defined as an attribute. Furthermore, the second user data can be bound based on attributes when it is to be displayed to a user or sent to the ROF for authorization / licensing in the future. Therefore, in some embodiments, the second user data can be bound based on sensitivity (e.g., personal data affected by privacy regulations or public data / resources to support services). Additionally or alternatively, the second user data can be bound based on use / purpose (e.g., linked to features, applications, etc.). Additionally or alternatively, the second user data can be bound based on the necessity of the data (e.g., forcing services, for advertising, for optimization, etc.). Additionally or alternatively, the second user data can be bound based on potential attacks, such as public personal tracking, health status, financial status, etc. Additionally or alternatively, the second user data can be bound based on the data's "processor / consumer" (e.g., AEF (as a controller and processor), API caller as another processor, etc.).

[0075] For the purpose of clarification only, an example of a third request is shown below: API Post Request = {API Name, Non-public Protocol, NDA, Available (with CAPIF provider's "Signed Contract") = Yes / No, User Data:} [{User Data 1 (User Data Name: e.g., Virtual Avatar), Attribute (Attribute 1: Shareability (Can be shared with API consumers or not) = Yes / No, Attribute 2: Sensitivity (Private or Non-Private = Yes / No))}, {User data 2 (User data name: Photo), Attributes (Attribute 1: Shareability = Yes / No, Attribute 2: Sensitivity = Yes / No), ...)}, API status, etc.}.

[0076] Additionally or alternatively, in some embodiments, the third request may indicate one or more APIs based on attributes of the second or more attributes. As an example, the attribute may be a purpose attribute. In some embodiments, the third request may indicate one or more APIs by a first purpose of use among one or more purposes of use and a first set of APIs among one or more APIs corresponding to the first purpose of use. The third request may also indicate a second purpose of use among one or more purposes of use and a second set of APIs among one or more APIs corresponding to the second purpose of use. It should be understood that the first set of APIs and the second set of APIs may be the same or different, as the data used may be used for the same or different purposes. Examples of APIs associated with a purpose of use are shown below, only for clarity of discussion: Acquiring a virtual avatar for advertising purposes, acquiring a virtual avatar for gaming purposes, and acquiring a virtual avatar for general purposes. (Get Avatar-advertisement Purpose, Get Avatar-Gaming Purpose, and the Get Avatar-General Purpose) The API "virtual avatar" refers to the same API associated with different uses.

[0077] Each API (GetAvatar-advertisementPurpose, GetAvatar-GamingPurpose, and GetAvatar-GeneralPurpose) provides access to different user resources or avatar data, or access to the same avatar resource at different granular levels. Furthermore, these APIs can expose different levels of user data, including sensitive information for specific purposes.

[0078] In this way, the APF can publish different service APIs for different purposes, which can expose different user data or provide access to the same user data at different granularities or with anonymization. That is, in some embodiments, a single service API can be linked to multiple purposes. Alternatively, in some embodiments, separate API(s) can be defined for each purpose, and user data can be associated with each purpose-based API(s). Furthermore, at least one additional attribute associated with one or more APIs can be indicated. Given the above, from the perspective of the API service provider, a third request can indicate user data and its attributes associated with the published API(s).

[0079] Still referencing Figure 2 The first device 110 accordingly receives (205) a third request 203. In some embodiments, the third device 130 may transmit a load request to the first device 110 for loading. For discussion purposes only, the load request may also be referred to as a "fourth load request". In some embodiments, the fourth request may indicate a second or more APIs required. Furthermore, in some embodiments, the fourth request may also indicate user data for an API in the second or more APIs, for example, user data for each API in the second or more APIs. Furthermore, in some embodiments, the fourth request may also indicate at least one attribute associated with the user data for the API.

[0080] In a specific example, when an API caller running on the UE or network (e.g., a third device located in the second device 120 or on the network side) is loaded, the API caller may optionally notify the first device 110 (e.g., CCF) of the user data to be utilized for the API, including the name and attributes of the data, such as the purpose of using the data, the necessity of the data for the application, etc.

[0081] Furthermore, in some embodiments, the fourth request may also include information about a non-public agreement (NDA) related to the user data. For example, a third device 130, including the API caller, may include an NDA or a link to an NDA in the fourth request. Examples of an NDA may include the use of sensitive user data, and that the sensitive data will not be disclosed to any other third parties listed in the NDA. Another example of an NDA may include data that is used only locally.

[0082] The first device 110 may accordingly receive a fourth request. The first device 110 may then determine, based on a local policy, whether to allow the API caller to access one or more (or each) of the required second APIs for the required user data. For example, if a third request indicates that an API is associated with highly sensitive user data and the API caller also needs the same data for the API, the CCF in the first device 110 may decide that the API caller is not allowed to access the API.

[0083] Then, the first device 110 can transmit a response message (which may also be referred to as a "second response message") to the third device 130 in response to the fourth request. The second response message may include a list of allowed APIs, user data associated with the list of allowed APIs (which may also be referred to as third user data in some embodiments), and attributes associated with the third user data. Therefore, the CCF in the first device 110 can return the list of allowed APIs along with the required user data in its load response to the API caller (on the UE or network). Furthermore, the first device 110 may store the list of allowed APIs along with the required user data in a configuration file used for the API call. Alternatively, in some embodiments, if the first device 110 (or its CCF) cannot determine the allowed user data, the first device 110 will not provide any API to the third device 130. In this case, it can be handled dynamically later.

[0084] Furthermore, in some embodiments, if the fourth request includes information about a non-public protocol (NDA), the first device 110 may store the NDA information in a configuration file for the API caller. For clarity only, an example of a fourth request is shown below: Load request = {API name, NDA available (with CAPIF provider's "signed contract") = Yes / No, User data:} [{User Data 1 (e.g., virtual avatar), attributes (Attribute 1: Purpose = game, advertising, healthcare, etc., Attribute 2: Necessity = mandatory, optional, recommended, etc.) {User data 2 (e.g., photos), attributes (Attribute 1: Purpose = game, advertising, healthcare, etc., Attribute 2: Necessity = mandatory, optional, recommended, etc.)} Additionally, in some embodiments, the third device 130 may transmit a request for API discovery to the first device 110. For the purposes of discussion, in some embodiments, the request for API discovery may also be referred to as a “fifth request” or an “API discovery request.” An API caller may use an API discovery request to obtain detailed usage instructions, parameter requirements for a specific API, etc. Compared to a third request for loading, an API discovery request aims to obtain more detailed information about the API. In some embodiments, the fifth request may include the requested API and fourth user data associated with the requested API. Upon receiving the fifth request for API discovery, the device 110 including the CCF may determine the fifth user data associated with the requested API that is permitted to be accessed by the API caller, based on the second user data and a second or more attributes indicated in the third request. For example, the fifth user data may be part of the requested fourth user data or may be the fourth user data itself.

[0085] In a specific example, when an API caller in a third device 130 running on a UE or network transmits an API discovery request on a service API with the required user data, the CCF in the first device 110 can check whether the API caller is authorized to obtain the user data based on a list of attributes of the user data available at the CCF (received from a fourth device, UE, or network) and return the information to the API caller accordingly.

[0086] Still referencing Figure 2 Following the API discovery process, in order to invoke the API, the first device 110 transmits (207) a request for access token 209. The request for access token may indicate the required user data and one or more attributes associated with the user data. For clarity, in some embodiments, the request for access token may also be referred to as a "second request" or an "access token request," the required user data indicated in the second request may also be referred to as "first user data," and one or more attributes associated with the second user data may also be referred to as "one or more additional attributes."

[0087] Therefore, the first device 110 receives (211) the second request 209 from the third device 130 accordingly. In some embodiments, the second request may indicate the required first user data by one or more user data names including the second user data. Furthermore, the second request may indicate one or more additional attributes by indicating at least one attribute corresponding to a user data name in one or more user data names. Additionally, the second request may indicate the identifier (ID) of the required service API and resource owner (RO).

[0088] In the example, the UE or an API caller on the network sends an access token request that includes the service API, RO ID, and required user data including the data name, data attributes (such as the purpose of using the data), and the necessity of the data to support the purpose.

[0089] For the purpose of clarification only, an example of the second request is shown below: Access Token Request = {API Name, Resource Owner ID, AEF Details, ...} User data: [{User Data 1 (e.g., virtual avatar), attributes (attribute 1: purpose = game, attribute 2: necessity = mandatory)}, {User Data 2 (e.g., photos), Attributes (Attribute 1: Purpose = Game, Attribute 2: Necessity = Mandatory, Attribute 3: Lifespan = Half a Year}] Upon receiving a second request or access token request, the first device 110 (or its CCF) may determine whether the API caller (or the third device 130) is authorized to access the service API for the requested first user data based on locally stored valid user authorization, NDA information in the API caller's configuration file, and other policies. For example, the first device 110 may determine whether the API caller (or the third device 130) is authorized based on the permitted user data indicated in the load response and / or discovery response.

[0090] In some embodiments, if the API caller is authorized to access the service API for the requested first user data, the first device 110 may directly send an access token (which may be referred to as "another access token" in some embodiments) to the third device 130. Otherwise, if the API caller is not authorized to access the service API for the requested first user data (e.g., the first user data includes sensitive information such as location, health, or other information not authorized to the API caller), the first device 110 transmits (215) a request 217 to the second device 120 for authorization (or permission) to open the first user data to the third device 130. The first request indicates the first user data and one or more attributes associated with the first user data. Similar to the second request, the first user data may be indicated by one or more user data names that include the second user data. Furthermore, the first request may indicate one or more attributes by indicating at least one attribute corresponding to a user data name in one or more user data names. In addition, the first request may also indicate the required service API and NDA information associated with the API caller. In some embodiments, the one or more attributes indicated in the first request may be different from the other one or more attributes indicated in the second request. For example, the first request may also include attributes such as "potential risks of the first user data being exposed", "sensitivity level of the first user data", and "lifespan of the first user data". Alternatively, one or more attributes indicated in the first request may be the same as one or more other attributes.

[0091] For the purpose of clarification only, an example of the first request is shown below: Authorization or license request = NDA from API caller, NDA from AEF, API caller details, API name. User data: [User Data 1 (e.g., virtual avatar), attributes (Attribute 1: Purpose = Game, Attribute 2: Necessity = Mandatory, Attribute 3: Sensitivity = Yes), {User Data 2 (e.g., photos), Attributes (Attribute 1: Purpose = Game, Attribute 2: Necessity = Mandatory, Attribute 3: Sensitivity = Yes, Attribute 4: Lifespan = Half a Year}] The second device 120 accordingly receives (219) the first request 217. Then, the second device 120 (or its RO) can determine whether to permit the access. For example, the RO can determine that the first user data can be fully accessed, a portion of the first user data can be accessed, or the first user data cannot be accessed. Subsequently, the second device 120 transmits (223) a first response message 223 to the first device 110 in response to the first request. Based on the determination by the second device 120, the first response message indicates which user data within the first user data is permitted to be accessed. For example, the first response message can indicate that a portion of the first user data is permitted to be accessed or that the entire first user data is permitted to be accessed. Alternatively, the first response message can indicate that access to the first user data is not permitted. An example of a first response message is shown below: Authorization response (allowed user data and attributes).

[0092] In a specific example, if the CCF cannot authorize the use of its locally available information, it sends a user authorization or permission request (i.e., first request 217) to the RO resource owner via the ROF-Resource Owner function. This request includes the service API, API caller details, along with the data name and attributes, such as data sensitivity, purpose of data use, necessity to fulfill the purpose, data sensitivity, and data lifetime. This then triggers the RO to determine whether the required user data can be made available to the API caller. In some embodiments, if the RO grants permission for the data, the ROF in the second device 120 can respond using a list of permitted user data (names).

[0093] Then, the first device 110 transmits (227) an access token 229 to the third device 130. The access token 229 may include one or more user-allowed data names from the second device 120. Furthermore, in some embodiments, the access token 229 may also indicate attributes corresponding to one or more user-allowed data names.

[0094] In this way, the authorization token is issued by the CCF to the API caller, and the token contains the permitted data accepted by the RO. Furthermore, the third device 130 can store the consent / permission details locally.

[0095] Using the access token, the third device 130 can transmit a request for the API service to the fourth device 140 (or the AEF therein). In some embodiments, this request may also be referred to as a seventh request. The seventh request may include the obtained access token. The fourth device 140 can then determine the information to be provided to the third device 130 based on the access token in the request for the API service.

[0096] In a specific example, the API caller can send a service request (i.e., the seventh request) to the AEF along with an access token containing the service API, the resource owner ID, and user data accepted by the resource owner. The AEF then checks the allowed user data in the access token and provides the user data to the API caller in the service response accordingly.

[0097] In some embodiments, if a specific user data request is not mentioned in the access token request, user data, especially sensitive information, will not be provided, or user data will be provided in accordance with the AEF policy. Furthermore, in some embodiments, the RO in the second device 120 can also revoke user authorization / permission for specific user data to a specific API caller by sending a revocation request to the CCF, and the CCF can also forward the request to the AEF.

[0098] Given the above, with a more granular or level-based licensing scheme for the data to be made available, the resource owner can know that sensitive information will be disclosed to API callers or the API in advance. The resource owner can then decide whether to allow this disclosure on demand. Therefore, the disclosure of sensitive information can be managed accordingly.

[0099] For clarity, please refer to Figure 3 Further discussion of specific signaling procedure examples for procedure 200. Figure 3 A specific example of user sensitive information management in a virtual world via a Public Application Programming Interface Function (CAPIF) is shown according to an example embodiment of this disclosure.

[0100] exist Figure 3 In the example, RO and ROF can be in the second device 120, the API caller can be in the third device 130, the CCF can be in the first device 110, and the AEF and APF can be in the fourth device 140. Therefore, the aforementioned entities can be identified accordingly by their respective reference numerals.

[0101] At step 1, APF 140 publishes an API publication request to CCF, which includes the service API name and different user data and its attributes associated with the service API. As mentioned above, the user data can be indicated based on attributes of multiple properties (e.g., purpose of use).

[0102] At steps 2 and 3, CCF 110 stores details and provides an API posting response. At step 4, the API caller 130 on the UE / network sends a load request with a list of APIs to CCF 110, optionally mentioning user data and its attributes that the API caller 130 is interested in. At step 5, CCF 110 checks local policies to verify the user data and stores it in the API caller configuration file.

[0103] At step 6, CCF 110 provides a load response with an API list along with the accepted user data and attributes. At steps 7 and 8, when an API caller on the UE / network sends an API discovery request with the service API name and its user data, CCF 110 checks whether the user data (e.g., photo, age) can be made available to the API caller based on the attributes received in step 1 and provides a response.

[0104] At step 9, CCF 110 provides the user data that can be offered to the API caller in the API discovery response. At steps 10 and 11, the API caller 130 on the UE / network sends an access token request (i.e., a request for an access token) containing the resource owner ID, the service API name, the required user data, and their attributes (purpose=game, necessity=mandatory, lifetime=six months). CCF 110 checks whether the API caller 130 is authorized to access the service API for the requested data based on locally stored valid user authorization, the NDA in the API caller's profile, and other policies.

[0105] At step 12, if resource owner permission is required, CCF 110 sends a permission request to the RO (UE), which includes API caller information, NDA details of the API caller and AEF, user data, and their attributes. At steps 13 and 14, the RO checks the user data that needs to be opened to API caller 130 and provides a permission response. At step 15, CCF 110 provides the API caller with an access token containing the user data and attributes accepted by the RO. Then, at steps 16, 17, and 18, the UE or API caller 130 on the network sends a service request to the AEF containing the service API name and access token received from the CCF, and the AEF checks the user data and attributes and provides a service response accordingly.

[0106] In the above embodiments, the CAPIF (Public API Framework) provider and the API provider can belong to the same legal entity, so that CCF can directly manage data access requests from API callers.

[0107] However, in some cases, the CAPIF provider and the API provider may not be the same legal entity, and the more granular authorization or access control policies used to access APIs provided by the AEF or API provider cannot be shared with the CAPIF Core Functionality (CCF). Currently, the API name is included in the access token request, and the CCF authorizes based on the service API name. However, during the actual API call utilizing AEF, the service request includes parameters for user data required by the application supporting the API caller. Therefore, the CCF cannot perform user data authorization simultaneously when granting an access token to the API caller, because the CCF is unaware of the authorization policy.

[0108] In some example embodiments of this disclosure, when a UE or an API caller on the network makes a service request related to a resource owner (RO) using API parameters, the AEF may decide to seek authorization / permission from the RO before proceeding, whereby the API parameters involve sending data from the RO that includes sensitive information.

[0109] On the other hand, the fifth device receives an eighth request from the third device for services related to the API. The fifth device may include an AEF.

[0110] In this manner, AEF sends a request to CCF to initiate an authorization or permission request for the Resource Owner (RO). This request may include user data and its attributes, API name, API caller details, etc. The fifth device determines the user data to be opened based on the eighth request. Then, the fifth device transmits a sixth request to the first device for opening the authorized user data. Subsequently, the fifth device receives a response message from the first device indicating: i) the user data is allowed to be opened, or ii) the first user data is not allowed to be opened.

[0111] In this way, sensitive information management can be achieved even if the CAPIF provider and the API provider are not the same legal entity.

[0112] Figure 4 Another example signaling process 400 for information management according to an example embodiment of this disclosure is shown. For discussion purposes, reference will be made to... Figure 1 Describe the signaling process 400. It should be understood that, although it has already... Figure 1 The signaling process 200 is described in the communication environment 100, but the signaling process 400 can also be applied to other communication scenarios. In some embodiments, the fifth device 150 may include an AEF.

[0113] In signaling process 400, the third device 130 transmits 401 a request 403 for a service related to the API. The fifth device 150 accordingly receives (401) an eighth request 403. In some embodiments, the request for the service may also be referred to as the "eighth request." The eighth request may include the name of the requested API and API-related parameters. Therefore, the fourth device 140 determines 407 the user data to be disclosed based on the eighth request. For example, the fourth device 140 may examine the sensitive user information to be disclosed based on the API-related parameters and decide to grant user permission. In some embodiments, the user data may include user identifiers, location information, mobility information, health information, or any combination thereof.

[0114] Then, based on determination 407, the fourth device 140 transmits (409) a request 411 to the first device 110 for access to authorized user data. In some embodiments, request 411 may also be referred to as a “sixth request” for the purposes of discussion. In some embodiments, the sixth request may indicate user data and one or more attributes similar to the first request to the third request. The first device 110 receives (413) the sixth request 411 accordingly. The first device 110 then transmits (415) a request 417 to the second device 120 for authorization (or permission) to access data to the third device 130. In some embodiments, request 417 may be the same as or similar to the first request 217 discussed above. Therefore, in some embodiments, this request 417 may also be referred to as request 417 or the first request 417.

[0115] Then, similar to the reference Figure 2 In the operation discussed, upon receiving (419) the first request 417, the second device 120 can determine whether the user data contains data that is allowed to be opened or data that is not allowed to be opened. Then, the second device 120 transmits (421) a response message 423 to the first device 110 in response to the first request 417. The response message 423 indicates: i) the user data contains user data that is allowed to be opened, or ii) the first user data is not allowed to be opened. In some embodiments, the response message 423 may be the same as or similar to the first response message 223. Therefore, in some embodiments, the response message 423 may also be referred to as the first response message 423.

[0116] In a specific example, when the CCF sends an authorization or license request (i.e., request 417) to the Resource Owner (RO), the RO can decide whether to allow user data to be provided to the API caller. If the RO accepts, the RO will specify which user data can be shared with the API caller and which data needs to be flagged or suppressed to protect its privacy, and send an authorization / license response accordingly. The first device 110 accordingly receives (425) a first response message 423. Based on the first response message 423, the first device 110 can transmit a service response to the third device 130. For example, the AEF can send a service response to the API caller based on the authorization or license response (i.e., first response message 423) received from the RO (i.e., the second device 120).

[0117] For clarity, please refer to Figure 5 Further discussion of specific signaling procedure examples for procedure 400. Figure 5 The illustration shows another specific example of user sensitive information management in a virtual world via a Public Application Programming Interface Function (CAPIF) according to an example embodiment of the present disclosure, wherein the CAPIF provider and the application programming interface (API) provider are in different domains.

[0118] exist Figure 5 In the example, RO and ROF can be in the second device 120, the API caller can be in the third device 130, the CCF can be in the first device 110, and the AEF can be in the fifth device 150. Therefore, the aforementioned entities can be identified accordingly by their respective reference numerals.

[0119] Assume CCF 110, API caller 130, and RO 120 are in domain A, and AEF 150 is in domain B. Therefore, more granular authorization or access control policies for accessing APIs provided by AEF may not be available at the CCF in domain A. User data associated with the service API and its attributes is only available at the AEF.

[0120] At step 2, API caller 130 sends an access token request to CCF containing the service API name, RO ID, AEF details, etc. At steps 3, 4, 5, and 6, CCF 110 verifies the token request, obtains permission from the resource owner for service API access, and provides the access token to API caller 130. At step 7, API caller 130 makes a service request using API parameters, which may involve sending RO data including sensitive information to AEF along with the access token received from CCF. At steps 8 and 9, AEF 150 examines the attributes associated with the user data and sends a message to CCF requesting permission for the RO using the attributes associated with the user data. At steps 10 and 11, CCF 110 sends a request to the RO containing API caller details, service API, user data, and their attributes, obtains a permission response, and forwards it to AEF. At steps 12 and 13, based on the permission response received from CCF, AEF 150 provides a service response to API caller 130.

[0121] Figure 6 A flowchart of a method 600 implemented at a first device according to some embodiments of the present disclosure is shown. The first device for performing method 600 may be an example of the first device 110 described above.

[0122] At 610, the first device 110 transmits a first request to the second device, wherein the first request is for authorization to open the first user data to the third device, and the first request indicates the first user data and one or more attributes associated with the first user data. At 620, the first device 110 receives a first response message from the second device, the first response message indicating: i) user data in the first user data that is allowed to be opened, or ii) the first user data that is not allowed to be opened.

[0123] In some embodiments, one or more attributes include at least one of the following: the sensitivity level of the first user data; the shareability with the API consumer; the purpose of using the first user data; the necessity level of using the first user data; the consumer of the first user data; the processing entity of the first user data; the potential risks of opening the first user data; or the lifetime of the first user data.

[0124] In some embodiments, the first request includes: one or more user data names of the first user data; and at least one attribute corresponding to a user data name in one or more user data names.

[0125] In some embodiments, the first device may transmit a first request by: receiving a second request for an access token from a third device, wherein the second request indicates required first user data and one or more additional attributes associated with the first user data, wherein the one or more additional attributes are the same as or different from the one or more attributes; and transmitting the first request to the second device to authorize the third device to access the first user data.

[0126] In some embodiments, the first device may also transmit an access token to a third device, including an API caller, based on a first response message.

[0127] In some embodiments, the first response message includes one or more allowed user data names of the permitted user data; and the access token indicates one or more allowed user data names.

[0128] In some embodiments, the access token also indicates an attribute corresponding to one or more user-allowed data names.

[0129] In some embodiments, one or more attributes are first one or more attributes, and wherein the first device may further: receive from a fourth device a third request for publishing one or more APIs, wherein the third request indicates second user data associated with one or more APIs and second one or more attributes associated with the second user data.

[0130] In some embodiments, the third request indicates one or more APIs based on attributes in the second or more attributes.

[0131] In some embodiments, the attribute includes one or more uses, and the third request indicates one or more APIs by: a first use of one or more uses and a first group of APIs corresponding to the first use of one or more APIs; a second use of one or more uses and a second group of APIs corresponding to the second use of one or more APIs, wherein the first group of APIs and the second group of APIs are the same or different; and at least one additional attribute associated with one or more APIs.

[0132] In some embodiments, one or more APIs are first one or more APIs, and the first device may further: receive a fourth request from a third device for loading, wherein the fourth request indicates a second one or more APIs and user data for the APIs in the second one or more APIs.

[0133] In some embodiments, the fourth request also indicates at least one attribute related to the user data of the API.

[0134] In some embodiments, the fourth request includes information about a non-public agreement (NDA) related to user data, and the first device may further: store the NDA information in a configuration file of the API caller.

[0135] In some embodiments, the first device may further: determine, based on the fourth request and the third request, APIs that are allowed to be accessed by the API caller from a second or more APIs; and transmit a second response message to the fourth request to the third device, wherein the second response message indicates a list of allowed APIs, third user data associated with the list of allowed APIs, and attributes associated with the third user data.

[0136] In some embodiments, the first device may further: receive a fifth request for API discovery from a third device, wherein the fifth request indicates a requested API and fourth user data associated with the requested API; determine fifth user data associated with the requested API that is permitted to be exposed to the API caller based on second user data and one or more second attributes indicated in the third request; and transmit a third response message to the third device in response to the fifth request, wherein the third response message indicates fifth user data that is permitted to be provided to the API caller.

[0137] In some embodiments, the second device includes at least one of a resource owner (RO) or a RO function (ROF).

[0138] In some embodiments, the first user data includes at least one of the following: user identifier; location information; mobility information; or health information.

[0139] In some embodiments, the first device may transmit a first request by receiving a sixth request from the fifth device for authorizing the first user data, wherein the sixth request indicates the first user data and one or more attributes.

[0140] In some embodiments, the first device may also transmit a first response message to the fifth device.

[0141] In some embodiments, at least one of the following is included: a first device includes a Common Application Programming Interface Framework Core Functionality (CCF); a second device includes at least one of a Resource Owner (RO) or RO Functionality (ROF); a third device includes an Application Programming Interface (API) caller; a fourth device includes at least one of an API Publishing Functionality (APF) or API Open Functionality (AEF); or a fifth device includes another AEF.

[0142] In some embodiments, an apparatus (e.g., a first apparatus) capable of performing any of the methods in method 600 may include: a component for transmitting a first request to a second apparatus, wherein the first request is for authorizing the opening of first user data to a third apparatus, the first request indicating the first user data and one or more attributes associated with the first user data; and a component for receiving a first response message from the second apparatus, the first response message indicating: i) user data that is allowed to be opened in the first user data, or ii) the first user data is not allowed to be opened.

[0143] In some embodiments, one or more attributes include at least one of the following: the sensitivity level of the first user data; the shareability with the API consumer; the purpose of using the first user data; the necessity level of using the first user data; the consumer of the first user data; the processing entity of the first user data; the potential risks of opening the first user data; or the lifetime of the first user data.

[0144] In some embodiments, the first request includes: one or more user data names of the first user data; and at least one attribute corresponding to a user data name in one or more user data names.

[0145] In some embodiments, the apparatus may further include components for: receiving a second request for an access token from a third device, wherein the second request indicates required first user data and one or more additional attributes associated with the first user data, wherein the one or more additional attributes are the same as or different from the one or more attributes; and transmitting a first request to a second device to authorize the third device to access the first user data.

[0146] In some embodiments, the apparatus may further include components for transmitting an access token to a third device, including an API caller, based on a first response message.

[0147] In some embodiments, the first response message includes one or more allowed user data names; and the access token indicates one or more allowed user data names.

[0148] In some embodiments, the access token also indicates an attribute corresponding to one or more user-allowed data names.

[0149] In some embodiments, one or more attributes are first or more attributes, and the apparatus may further include: a component for receiving from a fourth apparatus a third request for publishing one or more APIs, wherein the third request indicates second user data associated with one or more APIs and second or more attributes associated with the second user data.

[0150] In some embodiments, the third request indicates one or more APIs based on attributes in the second or more attributes.

[0151] In some embodiments, the attribute includes one or more uses, and the third request indicates one or more APIs by: a first use of one or more uses and a first group of APIs corresponding to the first use of one or more APIs; a second use of one or more uses and a second group of APIs corresponding to the second use of one or more APIs, wherein the first group of APIs and the second group of APIs are the same or different; and at least one additional attribute associated with one or more APIs.

[0152] In some embodiments, one or more APIs are first one or more APIs, and the first device may further: receive a fourth request for loading from a third device, wherein the fourth request indicates a second one or more APIs and user data for the APIs in the second one or more APIs.

[0153] In some embodiments, the fourth request also indicates at least one attribute related to the user data of the API.

[0154] In some embodiments, the fourth request includes information about a non-public agreement (NDA) related to user data, and the apparatus may further include a component for storing the NDA information in a configuration file of the API caller.

[0155] In some embodiments, the apparatus may further include components for: determining, based on a fourth request and a third request, APIs that are permitted to be accessed by an API caller from a second or more APIs; and transmitting a second response message to a third apparatus in response to the fourth request, wherein the second response message indicates a list of permitted APIs, third user data associated with the list of permitted APIs, and attributes associated with the third user data.

[0156] In some embodiments, the apparatus may further include: means for receiving a fifth request for API discovery from a third means, wherein the fifth request indicates a requested API and fourth user data associated with the requested API; means for determining, based on second user data and one or more attributes indicated in the third request, the fifth user data associated with the requested API that is permitted to be made available to the API caller; and means for transmitting a third response message for the fifth request to the third means, wherein the third response message indicates the fifth user data that is permitted to be made available to the API caller.

[0157] In some embodiments, the second device includes at least one of a resource owner (RO) or a RO function (ROF).

[0158] In some embodiments, the first user data includes at least one of the following: user identifier; location information; mobility information; or health information.

[0159] In some embodiments, the component for transmitting the first request may include: a component for receiving from the fifth device a sixth request for authorizing first user data, wherein the sixth request indicates the first user data and one or more attributes.

[0160] In some embodiments, the apparatus may further include a component for transmitting a first response message to a fifth apparatus.

[0161] In some embodiments, at least one of the following is included: a first device includes a Common Application Programming Interface Framework Core Functionality (CCF); a second device includes at least one of a Resource Owner (RO) or RO Functionality (ROF); a third device includes an Application Programming Interface (API) caller; a fourth device includes at least one of an API Publishing Functionality (APF) or API Open Functionality (AEF); or a fifth device includes another AEF.

[0162] In some embodiments, the apparatus further includes components for performing additional steps in some embodiments of method 600. In some embodiments, the components include at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured to cause performance of the apparatus together with the at least one processor.

[0163] Figure 7 A flowchart of a method 700 implemented at a second device according to some embodiments of the present disclosure is shown. The second device for performing method 700 may be an example of the second device 120 described above.

[0164] At 710, the second device 120 receives a first request from the first device, the first device including the Common Application Programming Interface Framework Core Functionality (CCF), the first request authorizing the disclosure of first user data to a third device, the third device including an Application Programming Interface (API) caller. The first request indicates the first user data and one or more attributes associated with the first user data. At 720, the second device 120 transmits a first response message to the first device, the first response message indicating: i) user data within the first user data that is permitted to be disclosed, or ii) the first user data that is not permitted to be disclosed.

[0165] In some embodiments, one or more attributes include at least one of the following: the sensitivity level of the first user data; the shareability with the API consumer; the purpose of using the first user data; the necessity level of using the first user data; the consumer of the first user data; the processing entity of the first user data; the potential risks of opening the first user data; or the lifetime of the first user data.

[0166] In some embodiments, the first request includes: one or more user data names of the first user data; and at least one attribute corresponding to a user data name in one or more user data names.

[0167] In some embodiments, the second device may transmit a first response message by: determining, based on one or more attributes, allowed user data in the first user data; and including the names of one or more allowed user data of the allowed user data in the first response message to be transmitted.

[0168] In some embodiments, at least one of the following is true: the first device includes the Common Application Programming Interface Framework Core Functionality (CCF); or the second device includes at least one of Resource Owner (RO) or RO Functionality (ROF).

[0169] In some embodiments, an apparatus capable of performing any of the methods in method 700 (e.g., a second apparatus) may include: a component for receiving a first request from a first apparatus at the second apparatus, the first apparatus including a Common Application Programming Interface Framework Core Function (CCF), the first request being for authorizing the opening of first user data to a third apparatus, the third apparatus including an Application Programming Interface (API) caller, wherein the first request indicates the first user data and one or more attributes associated with the first user data; and a component for transmitting a first response message to the first apparatus, the first response message indicating: i) user data that is permitted to be opened in the first user data, or ii) the first user data that is not permitted to be opened.

[0170] In some embodiments, one or more attributes include at least one of the following: the sensitivity level of the first user data; the shareability with the API consumer; the purpose of using the first user data; the necessity level of using the first user data; the consumer of the first user data; the processing entity of the first user data; the potential risks of opening the first user data; or the lifetime of the first user data.

[0171] In some embodiments, the first request includes: one or more user data names of the first user data; and at least one attribute corresponding to a user data name in one or more user data names.

[0172] In some embodiments, the second device may transmit a first response message by: determining, based on one or more attributes, allowed user data in the first user data; and including the names of one or more allowed user data of the allowed user data in the first response message to be transmitted.

[0173] In some embodiments, at least one of the following is true: the first device includes the Common Application Programming Interface Framework Core Functionality (CCF); or the second device includes at least one of Resource Owner (RO) or RO Functionality (ROF).

[0174] In some embodiments, the apparatus further includes components for performing additional steps in some embodiments of method 700. In some embodiments, the components include at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured to cause performance of the apparatus together with the at least one processor.

[0175] Figure 8 A flowchart of a method 800 implemented at a third device according to some embodiments of the present disclosure is shown. The third device performing method 800 may be an example of the third device 130 described above.

[0176] At 810, the third device 130 transmits a second request for an access token to the first device, wherein the second request indicates the required first user data and one or more additional attributes associated with the first user data. At 820, the third device 130 receives the access token from the first device.

[0177] In some embodiments, one or more additional attributes include at least one of the following: the sensitivity level of the first user data; the shareability with the API consumer; the purpose of using the first user data; the necessity level of using the first user data; the consumer of the first user data; the processing entity of the first user data; the potential risks of opening the first user data; or the lifetime of the first user data.

[0178] In some embodiments, the access token indicates one or more names of allowed user data. In some embodiments, the access token also indicates an attribute corresponding to one or more names of allowed user data.

[0179] In some embodiments, the third device may also transmit a fourth request for loading to the first device, wherein the fourth request indicates a second or more APIs and user data for the APIs in the second or more APIs.

[0180] In some embodiments, the fourth request also indicates at least one attribute related to user data for the API. In some embodiments, the fourth request includes information about a non-public agreement (NDA) related to the user data.

[0181] In some embodiments, the third device may further: receive from the first device a second response message in response to the fourth request, wherein the second response message indicates a list of allowed APIs, third user data associated with the list of allowed APIs, and attributes associated with the third user data.

[0182] In some embodiments, the third device may further: transmit a fifth request for API discovery to the first device, wherein the fifth request indicates a requested API and fourth user data associated with the requested API; and receive a third response message from the first device in response to the fifth request, wherein the third response message indicates fifth user data associated with the requested API that is permitted to be exposed to the API caller.

[0183] In some embodiments, the third device may further: transmit a seventh request to the fourth device for an API-related service, wherein the seventh request includes an access token obtained from the first device.

[0184] In some embodiments, at least one of the following is included: a first device includes the Common Application Programming Interface Framework Core Functionality (CCF); a third device includes an Application Programming Interface (API) caller; or a fourth device includes at least one of the API Publishing Functionality (APF) or the API Exposure Functionality (AEF).

[0185] In some embodiments, an apparatus capable of performing any of the methods in method 800 (e.g., a third apparatus) may include: a component for transmitting a second request for an access token to a first apparatus, wherein the second request indicates required first user data and one or more additional attributes associated with the first user data; and a component for receiving an access token from the first apparatus.

[0186] In some embodiments, one or more additional attributes include at least one of the following: the sensitivity level of the first user data; the shareability with the API consumer; the purpose of using the first user data; the necessity level of using the first user data; the consumer of the first user data; the processing entity of the first user data; the potential risks of opening the first user data; or the lifetime of the first user data.

[0187] In some embodiments, the access token indicates one or more names of allowed user data. In some embodiments, the access token also indicates an attribute corresponding to one or more names of allowed user data.

[0188] In some embodiments, the third means may further include: a component for transmitting a fourth request for loading to the first means, wherein the fourth request indicates a second or more APIs and user data for the APIs in the second or more APIs.

[0189] In some embodiments, the fourth request also indicates at least one attribute related to user data for the API. In some embodiments, the fourth request includes information about a non-public agreement (NDA) related to the user data.

[0190] In some embodiments, the third apparatus may further include: a component for receiving a second response message from the first apparatus in response to the fourth request, wherein the second response message indicates a list of allowed APIs, third user data associated with the list of allowed APIs, and attributes associated with the third user data.

[0191] In some embodiments, the third apparatus may further include: a component for transmitting a fifth request for API discovery to the first apparatus, wherein the fifth request indicates a requested API and fourth user data associated with the requested API; and a component for receiving a third response message from the first apparatus in response to the fifth request, wherein the third response message indicates fifth user data associated with the requested API that is permitted to be made available to the API caller.

[0192] In some embodiments, the third device may further include a component for transmitting a seventh request for an API-related service to a fourth device, wherein the seventh request includes an access token obtained from the first device.

[0193] In some embodiments, at least one of the following is included: a first device includes the Common Application Programming Interface Framework Core Functionality (CCF); a third device includes an Application Programming Interface (API) caller; or a fourth device includes at least one of the API Publishing Functionality (APF) or the API Exposure Functionality (AEF).

[0194] In some embodiments, the apparatus further includes components for performing additional steps in some embodiments of method 800. In some embodiments, the components include at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured to cause performance of the apparatus together with the at least one processor.

[0195] Figure 9 A flowchart of a method 900 implemented at a fourth device according to some embodiments of the present disclosure is shown. The device for performing method 900 may be an example of the fourth device 140 described above.

[0196] At 910, the fourth device 140 transmits a third request to the first device for publishing one or more APIs. The third request indicates second user data associated with the one or more APIs and one or more second attributes associated with the second user data.

[0197] In some embodiments, the third request indicates one or more APIs based on attributes in the second or more attributes.

[0198] In some embodiments, the attribute includes one or more uses, and the third request indicates a second or more APIs by: a first use of the one or more uses and a first group of APIs corresponding to the first use of the one or more APIs; a second use of the one or more uses and a second group of APIs corresponding to the second use of the one or more APIs, wherein the first group of APIs and the second group of APIs are the same or different; and at least one additional attribute associated with the one or more APIs.

[0199] In some embodiments, the fourth device may also receive a seventh request from the third device for an API-related service, wherein the seventh request includes an access token indicating one or more allowed user data names and attributes corresponding to the one or more allowed user data names.

[0200] In some embodiments, the fourth device may also determine the information to be provided to the third device based on the access token.

[0201] In some embodiments, at least one of the following is included: a first device includes the Common Application Programming Interface Framework Core Functionality (CCF); a third device includes an Application Programming Interface (API) caller; or a fourth device includes at least one of the API Publishing Functionality (APF) or the API Exposure Functionality (AEF).

[0202] In some embodiments, an apparatus capable of performing any of the methods of method 900 (e.g., a fourth apparatus) may include a component for transmitting a third request to a first apparatus for publishing one or more APIs, wherein the third request indicates second user data associated with one or more APIs and a second or more attributes associated with the second user data.

[0203] In some embodiments, the third request indicates one or more APIs based on attributes in the second or more attributes.

[0204] In some embodiments, the attribute includes one or more uses, and the third request indicates a second or more APIs by: a first use of the one or more uses and a first group of APIs corresponding to the first use of the one or more APIs; a second use of the one or more uses and a second group of APIs corresponding to the second use of the one or more APIs, wherein the first group of APIs and the second group of APIs are the same or different; and at least one additional attribute associated with the one or more APIs.

[0205] In some embodiments, the fourth device may further include a component for receiving a seventh request from the third device for an API-related service, wherein the seventh request includes an access token indicating one or more allowed user data names and attributes corresponding to the one or more allowed user data names.

[0206] In some embodiments, the fourth device may further include a component for determining information to be provided to the third device based on an access token.

[0207] In some embodiments, at least one of the following is included: a first device includes the Common Application Programming Interface Framework Core Functionality (CCF); a third device includes an Application Programming Interface (API) caller; or a fourth device includes at least one of the API Publishing Functionality (APF) or the API Exposure Functionality (AEF).

[0208] In some embodiments, the apparatus further includes components for performing additional steps in some embodiments of method 900. In some embodiments, the components include at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured to cause performance of the apparatus together with the at least one processor.

[0209] Figure 10 A flowchart of a method 1000 implemented at an apparatus according to some embodiments of the present disclosure is shown. The apparatus for performing method 1000 may be an example of the fifth apparatus 150 described above.

[0210] At 1010, the fifth device 150 receives an eighth request from the third device for services related to the API. At 1020, the fifth device 150 determines the user data to be opened based on the eighth request. At 1030, the fifth device 150 transmits a sixth request to the first device for opening authorized user data. At 1040, the fifth device 150 receives a response message from the first device, indicating that: i) the first user data contains user data that is allowed to be opened, or ii) the first user data is not allowed to be opened.

[0211] In some embodiments, user data includes at least one of the following: user identifier; location information; mobility information; or health information.

[0212] In some embodiments, at least one of the following is included: a first device includes the Common Application Programming Interface Framework Core Functionality (CCF); a third device includes an Application Programming Interface (API) caller; or a fifth device includes another AEF.

[0213] In some embodiments, an apparatus capable of performing any of the methods of method 1000 (e.g., a fifth apparatus) may include: components for receiving an eighth request for an API-related service from a third apparatus at the fifth apparatus; components for determining user data to be opened based on the eighth request; components for transmitting a sixth request for opening authorized user data to a first apparatus; and components for receiving a response message from the first apparatus, the response message indicating: i) user data that is allowed to be opened in the first user data, or ii) the first user data is not allowed to be opened.

[0214] In some embodiments, user data includes at least one of the following: user identifier; location information; mobility information; or health information.

[0215] In some embodiments, at least one of the following is included: a first device includes the Common Application Programming Interface Framework Core Functionality (CCF); a third device includes an Application Programming Interface (API) caller; or a fifth device includes another AEF.

[0216] In some embodiments, the apparatus further includes components for performing additional steps in some embodiments of method 1000. In some embodiments, the components include at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured to affect the performance of the apparatus together with the at least one processor.

[0217] Figure 11 This is a simplified block diagram of a device 1100 suitable for implementing embodiments of the present disclosure. The device 1100 can be provided to implement a communication device, such as a first terminal device, a second terminal device, or a network device. As shown, the device 1100 includes one or more processors 1110, one or more memories 1120 coupled to the processors 1110, and one or more communication modules 1140 coupled to the processors 1110.

[0218] Communication module 1140 is used for bidirectional communication. Communication module 1140 has at least one antenna to facilitate communication. The communication interface can represent any interface necessary for communication with other network elements.

[0219] As a non-limiting example, processor 1110 can be any type suitable for a local technology network and can include one or more of the following: general-purpose computer, special-purpose computer, microprocessor, digital signal processor (DSP), and processor based on a multi-core processor architecture. Device 1100 can have multiple processors, such as application-specific integrated circuit chips that are time-dependent on a clock synchronized with the main processor.

[0220] Memory 1120 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 1324, electrically programmable read-only memory (EPROM), flash memory, hard disk, miniature optical disc (CD), digital video disc (DVD), and other magnetic and / or optical storage. Examples of volatile memories include, but are not limited to, random access memory (RAM) 1322 and other volatile memories that will not be maintained during power outages.

[0221] Computer program 1130 includes computer-executable instructions that are executed by the associated processor 1110. Program 1130 may be stored in ROM 1124. Processor 1110 may perform any suitable actions and processes by loading program 1130 into RAM 1122.

[0222] The embodiments of this disclosure can be implemented by program 1130, thereby enabling device 1300 to execute as described in the reference. Figures 2 to 10 Any process discussed in this disclosure. Embodiments of this disclosure may also be implemented in hardware or a combination of software and hardware.

[0223] In some embodiments, program 1120 may be tangibly contained in a computer-readable medium, which may be included in device 1100 (such as in memory 1120) or in other storage devices accessible by device 1100. Device 1100 may load program 1130 from the computer-readable medium into RAM 1122 for execution. The computer-readable medium may include any type of tangible non-volatile storage medium, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc. The computer-readable medium has program 1130 stored thereon.

[0224] Generally, the various embodiments of this disclosure can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects can be implemented in hardware, while others can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of this disclosure are shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that the blocks, apparatuses, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof, as examples without limitation.

[0225] This disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions (such as those included in a program module) that are executed in a device on a target physical or virtual processor to perform the functions described above. Figure 6-10 Methods 600, 700, 800, 900, or 1000 are described. Typically, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of a program module can be combined or split among program modules as needed. The machine-executable instructions for a program module can execute on a local device or a distributed device. In a distributed device, a program module can reside on both local and remote storage media.

[0226] Program code used to perform the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that, when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a stand-alone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0227] In the context of this disclosure, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, etc.

[0228] Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable media can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof. More specific examples of computer-readable storage media will include electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. The term “non-transient” as used herein is a limitation on the medium itself (i.e., tangible, not signaling), not on the persistence of data storage (e.g., RAM versus ROM).

[0229] Furthermore, although operations are described in a specific order, this should not be construed as requiring such operations to be performed in the specific order shown or sequentially, or requiring the execution of all shown operations to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be considered as limiting the scope of this disclosure, but rather as a description of features that may be specific to particular embodiments. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0230] Although this disclosure has been described in language specific to structural features and / or methodological actions, it should be understood that the disclosure as defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as exemplary forms for implementing the claims.

[0231] Furthermore, the various implementations of this disclosure can be described with reference to the following terms, and their features can be combined in any reasonable manner.

[0232] Clause 1. A first means for communication, comprising: at least one processor; and at least one memory, the at least one memory storing instructions that, when executed by the at least one processor, cause the first means to at least: transmit a first request to a second means, wherein the first request is for authorization to open first user data to a third means, the first request indicating the first user data and one or more attributes associated with the first user data; and receive a first response message from the second means, the first response message indicating: i) user data in the first user data that is permitted to be opened, or ii) the first user data that is not permitted to be opened.

[0233] Clause 2. The first device pursuant to Clause 1, wherein one or more attributes include at least one of the following: the sensitivity level of the first user data; the shareability with the API consumer; the purpose of using the first user data; the level of necessity for using the first user data; the consumer of the first user data; the processing entity of the first user data; the potential risks of the first user data being made public; or the lifetime of the first user data.

[0234] Clause 3. The first device according to Clause 1 or 2, wherein the first request includes: one or more user data names of the first user data; and at least one attribute corresponding to the user data name in the one or more user data names.

[0235] Clause 4. A first device pursuant to any one of Clauses 1 to 3, wherein the first device is configured to transmit a first request by: receiving a second request for an access token from a third device, wherein the second request indicates required first user data and one or more additional attributes associated with the first user data, wherein the one or more additional attributes are the same as or different from the one or more attributes; and transmitting the first request to a second device to authorize the third device to access the first user data.

[0236] Clause 5. The first device pursuant to Clause 4, wherein the first device is further configured to: transmit an access token to a third device, including the API caller, based on the first response message.

[0237] Clause 6. The first device according to Clause 5, wherein: the first response message includes one or more allowed user data names; and the access token indicates one or more allowed user data names.

[0238] Clause 7. The first device according to Clause 6, wherein the access token further indicates an attribute corresponding to one or more user-allowed data names.

[0239] Clause 8. A first device pursuant to any one of Clauses 1 to 7, wherein one or more attributes are first or more attributes, and wherein the first device is further configured to: receive from a fourth device a third request for publishing one or more APIs, wherein the third request indicates second user data associated with one or more APIs and second or more attributes associated with the second user data.

[0240] Clause 9. The first device pursuant to Clause 8, wherein the third request indicates one or more APIs based on an attribute in one or more second attributes.

[0241] Clause 10. The first apparatus pursuant to Clause 9, wherein the attribute includes one or more uses, and the third request indicates one or more APIs by: a first use among the one or more uses and a first set of APIs corresponding to the first use among the one or more APIs; a second use among the one or more uses and a second set of APIs corresponding to the second use among the one or more APIs, wherein the first set of APIs and the second set of APIs are the same or different; and at least one additional attribute associated with the one or more APIs.

[0242] Clause 11. A first device pursuant to any one of Clauses 8 to 10, wherein one or more APIs are first one or more APIs, and wherein the first device is further configured to: receive a fourth request from a third device for loading, wherein the fourth request indicates a second or more APIs and user data for the APIs in the second or more APIs.

[0243] Clause 12. The first device according to Clause 11, wherein the fourth request further indicates at least one attribute related to user data of the API.

[0244] Clause 13. The first means pursuant to Clause 11 or 12, wherein the fourth request includes information about a non-public protocol NDA relating to user data, and the first means is further configured to: store the NDA information in a configuration file of the API caller.

[0245] Clause 14. A first means pursuant to any one of Clauses 11 to 13, wherein the first means is further configured to: determine, based on a fourth request and a third request, APIs permitted to be accessed by the API caller from a second or more APIs; and transmit to a third means a second response message in response to the fourth request, wherein the second response message indicates a list of permitted APIs, third user data associated with the list of permitted APIs, and attributes associated with the third user data.

[0246] Clause 15. A first device according to any one of Clauses 1 to 14, wherein the first device is further configured to: receive a fifth request for API discovery from a third device, wherein the fifth request indicates a requested API and fourth user data associated with the requested API; determine, based on second user data and one or more second attributes indicated in the third request, fifth user data associated with the requested API that is permitted to be exposed to the API caller; and transmit a third response message to the third device in response to the fifth request, wherein the third response message indicates fifth user data that is permitted to be provided to the API caller.

[0247] Clause 16. The first device according to any one of Clauses 1 to 15, wherein the second device includes at least one of Resource Owner (RO) or RO Function (ROF).

[0248] Clause 17. A first device pursuant to any one of Clauses 1 to 16, wherein the first user data includes at least one of the following: user identifier; location information; mobility information; or health information.

[0249] Clause 18. A first device according to any one of Clauses 1 to 3, wherein the first device is configured to transmit a first request by receiving a sixth request from a fifth device for authorizing first user data, wherein the sixth request indicates the first user data and one or more attributes.

[0250] Clause 19. The first device according to Clause 18, wherein the first device is further configured to: transmit a first response message to the fifth device.

[0251] Clause 20. A first device under any one of Clauses 1 to 19, wherein at least one of the following is included: the first device includes the Common Application Programming Interface Framework Core Function (CCF); the second device includes at least one of Resource Owner (RO) or RO Functionality (ROF); the third device includes the Application Programming Interface (API) Caller; the fourth device includes at least one of API Publishing Functionality (APF) or API Open Functionality (AEF); or the fifth device includes another AEF.

[0252] Clause 21. A second means for communication, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the second means to at least: receive a first request from a first means, the first means including Common Application Programming Interface Framework Core Functionality (CCF), the first request being for authorization to open first user data to a third means, the third means including an Application Programming Interface (API) caller, wherein the first request indicates the first user data and one or more attributes associated with the first user data; and transmit a first response message to the first means, the first response message indicating: i) user data in the first user data that is permitted to be opened, or ii) the first user data that is not permitted to be opened.

[0253] Clause 22. The second device pursuant to Clause 21, wherein one or more attributes include at least one of the following: the sensitivity level of the first user data; the shareability with the API consumer; the purpose of using the first user data; the level of necessity for using the first user data; the consumer of the first user data; the processing entity of the first user data; the potential risks of opening the first user data; or the lifetime of the first user data.

[0254] Clause 23. The second device pursuant to Clause 21 or 22, wherein the first request comprises: one or more user data names of the first user data; and at least one attribute corresponding to a user data name in one or more user data names.

[0255] Clause 24. A second means according to any one of Clauses 21 to 23, wherein the second means is configured to transmit a first response message by: determining, based on one or more attributes, permitted user data in the first user data; and including, the permitted name of one or more permitted user data in the first response message to be transmitted.

[0256] Clause 25. A second device pursuant to any one of Clauses 21 to 24, wherein at least one of the following is true: the first device includes the Common Application Programming Interface Framework Core Function (CCF); or the second device includes at least one of Resource Owner (RO) or RO Function (ROF).

[0257] Clause 26. A third means for communication, comprising: at least one processor; and at least one memory, the at least one memory storing instructions that, when executed by the at least one processor, cause the third means to at least: transmit a second request for an access token to a first means, wherein the second request indicates required first user data and one or more additional attributes associated with the first user data; and receive an access token from the first means.

[0258] Clause 27. The third device pursuant to Clause 26, wherein one or more additional attributes include at least one of the following: the sensitivity level of the first user data; the shareability with the API consumer; the purpose of using the first user data; the level of necessity for using the first user data; the consumer of the first user data; the processing entity of the first user data; the potential risks of opening the first user data; or the lifetime of the first user data.

[0259] Clause 28. A third device pursuant to Clause 26 or 27, wherein the access token indicates one or more names of allowed user data.

[0260] Clause 29. A third device pursuant to Clause 28, wherein the access token further indicates an attribute corresponding to one or more user-allowed data names.

[0261] Clause 30. A third device pursuant to any one of Clauses 26 to 29, wherein the third device is further configured to: transmit to the first device a fourth request for loading, wherein the fourth request indicates a second or more APIs and user data for the APIs in the second or more APIs.

[0262] Clause 31. The third device pursuant to Clause 30, wherein the fourth request further indicates at least one attribute relating to user data for the API.

[0263] Clause 32. A third device pursuant to Clause 30 or 31, wherein the fourth request includes information related to a non-public agreement NDA relating to user data.

[0264] Clause 33. A third device pursuant to any one of Clauses 30 or 32, wherein the third device is further configured to: receive from the first device a second response message in response to a fourth request, wherein the second response message indicates a list of allowed APIs, third user data associated with the list of allowed APIs, and attributes associated with the third user data.

[0265] Clause 34. A third device according to any one of Clauses 26 to 33, wherein the third device is further configured to: transmit to the first device a fifth request for API discovery, wherein the fifth request indicates a requested API and fourth user data associated with the requested API; and receive from the first device a third response message for the fifth request, wherein the third response message indicates fifth user data associated with the requested API that is permitted to be exposed to the API caller.

[0266] Clause 35. A third device pursuant to any one of Clauses 26 to 34, wherein the third device is further configured to: transmit a seventh request to a fourth device for a service related to the API, wherein the seventh request includes an access token obtained from the first device.

[0267] Clause 36. A third device under any one of Clauses 26 to 35, wherein at least one of the following is included: the first device includes the Common Application Programming Interface Framework Core Function (CCF); the third device includes the Application Programming Interface (API) caller; or the fourth device includes at least one of the API Publishing Function (APF) or the API Open Function (AEF).

[0268] Clause 37. A fourth means for communication, comprising: at least one processor; and at least one memory, the at least one memory storing instructions that, when executed by the at least one processor, cause the fourth means to at least: transmit to a first means a third request for publishing one or more APIs, wherein the third request indicates second user data associated with the one or more APIs and a second or more attributes associated with the second user data.

[0269] Clause 38. The fourth device pursuant to Clause 37, wherein the third request indicates one or more APIs based on an attribute in the second or one or more attributes.

[0270] Clause 39. The fourth device pursuant to Clause 38, wherein the attribute includes one or more uses, and the third request indicates the second or more APIs by: a first use among the one or more uses and a first set of APIs corresponding to the first use among the one or more APIs; a second use among the one or more uses and a second set of APIs corresponding to the second use among the one or more APIs, wherein the first set of APIs and the second set of APIs are the same or different; and at least one additional attribute associated with the one or more APIs.

[0271] Clause 40. A fourth device pursuant to any one of Clauses 37 to 39, wherein the fourth device is further configured to: receive a seventh request from a third device for a service related to the API, wherein the seventh request includes an access token indicating one or more allowed user data names and attributes corresponding to the one or more allowed user data names.

[0272] Clause 41. The fourth device pursuant to Clause 40, wherein the fourth device is further configured to: determine the information to be provided to the third device based on the access token.

[0273] Clause 42. The fourth device under any one of Clauses 37 to 41, wherein at least one of the following is included: the first device includes the Common Application Programming Interface Framework Core Function (CCF); the third device includes the Application Programming Interface (API) caller; or the fourth device includes at least one of the API Publishing Function (APF) or the API Open Function (AEF).

[0274] Clause 43. A fifth means for communication, comprising: at least one processor; and at least one memory, the at least one memory storing instructions that, when executed by the at least one processor, cause the fifth means to at least: receive an eighth request from a third means for an API-related service; determine, based on the eighth request, user data to be opened; transmit to a first means a sixth request for opening authorized user data; and receive a response message from the first means, the response message indicating: i) user data in the first user data that is allowed to be opened, or ii) the first user data that is not allowed to be opened.

[0275] Clause 44. The fifth device pursuant to Clause 39, wherein the user data includes at least one of the following: user identifier; location information; mobility information; or health information.

[0276] Clause 45. A fifth device pursuant to Clause 43 or 44, wherein at least one of the following is true: a first device includes the Common Application Programming Interface Framework (CCF); a third device includes an Application Programming Interface (API) caller; or a fifth device includes another Application Programming Interface (AEF).

[0277] Clause 46. A method for communication, comprising: transmitting a first request from a first device to a second device, wherein the first request is for authorization to open first user data to a third device, the first request indicating the first user data and one or more attributes associated with the first user data; and receiving a first response message from the second device, the first response message indicating: i) user data in the first user data that is permitted to be opened, or ii) the first user data that is not permitted to be opened.

[0278] Clause 47. A method for communication, comprising: receiving a first request from a first device at a second device, wherein the first device includes Common Application Programming Interface Framework Core Functionality (CCF), the first request being for authorization to expose first user data to a third device, the third device including an Application Programming Interface (API) caller, the first request indicating the first user data and one or more attributes associated with the first user data; and transmitting a first response message to the first device, the first response message indicating: i) user data in the first user data that is permitted to be exposed, or ii) the first user data that is not permitted to be exposed.

[0279] Clause 48. A method for communication, comprising: transmitting a second request for an access token from a third device to a first device, wherein the second request indicates required first user data and one or more additional attributes associated with the first user data; and receiving the access token from the first device.

[0280] Clause 49. A method for communication, comprising: transmitting a third request for publishing one or more APIs from a fourth device to a first device, wherein the third request indicates second user data associated with the one or more APIs and a second or more attributes associated with the second user data.

[0281] Clause 50. A method for communication, comprising: receiving, at a fifth device, an eighth request from a third device for a service related to an API; determining, based on the eighth request, user data to be opened; transmitting, to a first device, a sixth request for opening authorized user data; and receiving, from the first device, a response message indicating: i) user data in the first user data that is permitted to be opened, or ii) the first user data that is not permitted to be opened.

[0282] Clause 51. An apparatus for communication, comprising: a component for transmitting a first request to a second device, wherein the first request is for authorizing the opening of first user data to a third device, the first request indicating the first user data and one or more attributes associated with the first user data; and a component for receiving a first response message from the second device, the first response message indicating: i) user data that is permitted to be opened in the first user data, or ii) the first user data is not permitted to be opened.

[0283] Clause 52. An apparatus for communication, comprising: components for receiving a first request from a first device at a second device, wherein the first device includes Common Application Programming Interface Framework Core Functionality (CCF), the first request is for authorizing the disclosure of first user data to a third device, the third device includes an Application Programming Interface (API) caller, the first request indicating the first user data and one or more attributes associated with the first user data; and components for transmitting a first response message to the first device, the first response message indicating: i) user data in the first user data that is permitted to be disclosed, or ii) the first user data that is not permitted to be disclosed.

[0284] Clause 53. An apparatus for communication, comprising: components for transmitting a second request for an access token to a first device, wherein the second request indicates required first user data and one or more additional attributes associated with the first user data; and components for receiving the access token from the first device.

[0285] Clause 54. An apparatus for communication, comprising: a component for transmitting to a first apparatus a third request for publishing one or more APIs, wherein the third request indicates second user data associated with one or more APIs and a second or more attributes associated with the second user data.

[0286] Clause 55. An apparatus for communication, comprising: means for receiving, at a fifth means, an eighth request from a third means for a service related to an API; means for determining, based on the eighth request, user data to be opened; means for transmitting, to a first means, a sixth request for opening authorized user data; and means for receiving, from the first means, a response message indicating: i) user data in the first user data that is permitted to be opened, or ii) the first user data that is not permitted to be opened.

[0287] Clause 56. A computer-readable medium comprising program instructions stored thereon for performing at least any one of Clauses 46 to 50.

Claims

1. A first device for communication, comprising: At least one processor; as well as At least one memory, the at least one memory storing instructions, the instructions, when executed by the at least one processor, cause the first device to at least: A first request is transmitted to a second device, wherein the first request is for authorization to open first user data to a third device, and the first request indicates the first user data and one or more attributes associated with the first user data; as well as The second device receives a first response message, the first response message indicating: i) user data that is allowed to be opened in the first user data, or ii) the first user data is not allowed to be opened.

2. The first apparatus according to claim 1, wherein the one or more properties include at least one of the following: The sensitivity level of the first user data; Shareability with API consumers; The purpose of using the first user data; The necessity level of using the first user data; The consumer of the first user data; The entity that processes the first user data; The potential risks of opening the first user data; or The lifespan of the first user data.

3. The first apparatus of claim 1, wherein the first request comprises: One or more user data names of the first user data; as well as At least one attribute corresponding to the user data name in one or more user data names.

4. The first apparatus of claim 1, wherein the first apparatus is configured to transmit the first request by: Receive a second request for the access token from the third device, wherein the second request indicates the required first user data and one or more additional attributes associated with the first user data, wherein the one or more additional attributes are the same as or different from the one or more attributes; and The first request is transmitted to the second device to authorize the third device to access the first user data.

5. The first device according to claim 4, wherein the first device is further configured to: Based on the first response message, an access token is transmitted to the third device, including the API caller.

6. The first apparatus according to claim 5, wherein: The first response message includes one or more allowed user data names of the allowed user data; and The access token indicates one or more user-allowed data names.

7. The first apparatus of claim 6, wherein the access token further indicates an attribute corresponding to the one or more allowed user data names.

8. The first device according to any one of claims 1 to 7, wherein the one or more properties are first or more properties, and wherein the first device is further configured to: Receive a third request from the fourth device for publishing one or more APIs. The third request indicates second user data associated with the one or more APIs and a second or more attributes associated with the second user data.

9. The first apparatus of claim 8, wherein the third request indicates the one or more APIs based on an attribute in the second or more attributes.

10. The first apparatus of claim 9, wherein the attribute includes one or more uses, and the third request indicates the one or more APIs by means of: The first purpose of use in the one or more purposes of use and the first group of APIs in the one or more APIs that correspond to the first purpose of use; The second purpose of use in the one or more purposes of use and the second group of APIs in the one or more APIs that correspond to the second purpose of use, wherein the first group of APIs and the second group of APIs are the same or different; as well as At least one additional property associated with the one or more APIs.

Images