Personal data ecosystem

Abstract

Embodiments of the present disclosure relate to a personal data ecosystem. Embodiments of the present disclosure utilize distributed ledger technology to apply user-centric control to data shared with third-party service providers. User access provider (UAP) devices manage user-configured permissions and metadata, which control access to user data by third-party service providers. Permissions can enable service providers to access, write and share user data with other service providers with appropriate permissions. Users can provide data to various service providers when they interact with services supported by the platform, and when data is received, it can be verified and then stored on a distributed ledger. Data can be synchronized regularly across different service provider nodes responsible for maintaining distributed ledgers to ensure consistency of data about each user. In addition, users can revoke permissions, such as if the user stops using the service, and data associated with the revoked permissions can be cleared or deleted from the distributed ledger.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is a continuation-in-part of U.S. patent application No. 16 / 837,746, filed on April 1, 2020, entitled “PERSONAL DATA MANAGEMENT SYSTEM,” which claims priority to U.S. Provisional Patent Application No. 62 / 829,363, filed on April 4, 2019, entitled “SYSTEM AND METHOD FOR MANAGING PERSONAL DATA,” the disclosures of which are incorporated herein by reference in their entirety. Technical Field

[0003] The present application relates to distributed ledger technology (DLT) and more particularly to technology for utilizing DLT to control and manage data distributed to different systems. Background Art

[0004] Technological advances have had a tremendous impact on the world. A well-known example of such advancement is the Internet. In its early days, access to the Internet was primarily used for academic and research purposes, but has now been integrated into nearly every aspect of daily life. For example, the Internet has become the primary medium through which people work, communicate, and provide and / or access services. Internet-based service companies (e.g., social media platforms, media streaming services, e-commerce providers, etc.) typically require users to pay service providers (e.g., The personal information provided to such service providers may include the user's name, address, bank card or account information (e.g., credit card information, debit card information, bank account information, etc.), interests (e.g., hobbies, places the user likes to visit, contacts, etc.), and many other types of information. Some services may even monitor the user's activity so that recommendations and information responsive to the user's needs can be provided, such as Amazon's support A device that uses voice identification technology to provide information to a user.

[0005] Although such capabilities have enhanced and improved people's lives, there are some drawbacks. For example, when a user provides personal information to a company via the Internet, it may become difficult for the person to manage or control how the company uses the following information: information provided by the user or information about the user that the service provider has empirically collected (e.g., based on analysis of the user's activities and interaction with the (multiple) services provided by the service provider). In addition, the services used by the user may change over time, making the services that the user once used no longer relevant to the user (e.g., preferring another service or for some other reason). When this happens, the user may or may not close their account, but this does not necessarily mean that the information provided by the user to the service provider can no longer be used by the service provider. Another problem is to maintain the latest information provided to each service provider. For example, if the user moves, the address information that the service provider has obtained may become incorrect unless the user updates their personal information to reflect their new address. However, it may be difficult for the user to update the information individually every time there is a change, and in some cases, the service provider has outdated information that may prevent access to (multiple) services or otherwise affect the user's ability to use (multiple) services.

[0006] Existing service provider systems also do not provide tools or mechanisms that enable users to control their content and limit how the information is used and maintained by the service provider. To illustrate, many social media service providers provide public / private settings that allow users to control how their information is viewed and accessed by third parties and other social media users, but these settings impose few (if any) restrictions on how the social media provider can use the information. Typically, social media and other service providers analyze text, image, and video content created by their users to derive information about their users' interests, shopping habits, travel and location-based information, or other characteristics, and such information is used to advertise to users and is sold to third parties for similar purposes. Another problem with existing social media and other service providers is the removal of content, such as if a user decides to leave the social media platform or stop using the service. Currently, when a user leaves a service provider, they can close their account but the information that the user has provided to the service provider can be retained (e.g., if the user ever decides to return to the service provider because the service provider considers the information to be an asset of the service provider rather than the user, or for other reasons). Thus, service providers may continue to share user information with third parties even when some of those users have stopped using the service provider(s)' services (e.g., because the users have little or no control over how the service providers use their personal data). Summary of the invention

[0007] Embodiments of the present disclosure address these challenges and disclose a platform that provides tools and mechanisms to give users control over their data and how the data is distributed, shared, and accessed by various service providers. A user access provider (UAP) device is provided to manage multiple sets of permissions and metadata that can be used to control how user data is accessed, shared, and utilized by service providers. A user can register with a UAP device and receive a platform identity (PID). As part of the registration process, a user can receive a private key and the corresponding public key can be stored by the UAP device. Once registered with the UAP, a user can access services provided by one or more service providers. As part of the access to the service, a user can sign the data provided to the service using a private key, and the service provider can use the corresponding public key to verify that the user is the actual source of the data, via interaction with the UAP device, or the public key can be provided by the UAP device to the service provider for data authentication purposes, as described in more detail below.

[0008] When the data is received and verified by the service provider, the service provider node can create a transaction or record on the distributed ledger. The data recorded to the distributed ledger can be maintained on a per-user, per-data type basis, so that each user's data is maintained separately from other users. In addition, user data can be isolated on an ecosystem basis, so that data exchanged with a service provider within a service provider ecosystem and data exchanged with a service provider in another service provider ecosystem are maintained separately (for example, medical data can be stored in a portion of the distributed ledger assigned to a medical service provider, and social media data can be stored in a portion of the distributed ledger assigned to a social media service provider). The service provider node can be configured to synchronize the data recorded to the distributed ledger according to the configured permissions to ensure that the user's data is consistent across all service providers and ecosystems. In addition, the user device can maintain a digital wallet, and the user data can be backed up to (multiple) wallets regularly to provide (multiple) users with visibility of their online or digital footprints. In addition, the user can revoke permissions from one or more service providers to prevent those service providers from further using or accessing all or part of the user's data. When the permission is revoked, the service provider node may delete or clear the user's data from the local instance of the distributed ledger, thereby ensuring that the service provider no longer has access to the user's data (or a portion thereof).The concepts described above are described and illustrated in more detail below.

[0009] The foregoing has been fairly broadly summarized the features and technical advantages of the present invention so that the detailed description of the present invention can be better understood. Additional features and advantages of the present invention will be described below, which form the subject matter of the claims of the present invention. It should be appreciated by those skilled in the art that the disclosed concepts and specific embodiments can be easily used as the basis for modifying or designing other structures for performing the same purpose of the present invention. It should also be appreciated by those skilled in the art that such equivalent structures do not deviate from the spirit and scope of the present invention as set forth in the appended claims. The novel features and additional objects and advantages that are considered to be the characteristics of the present invention (both with respect to its organization and method of operation) will be better understood from the following description when considered in conjunction with the accompanying drawings. However, it should be clearly understood that each of the accompanying drawings is provided for illustration and description purposes and is not intended to be a limitation to the limitations of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] For a more complete understanding of the disclosed methods and apparatus, reference should be made to the implementations illustrated in more detail in the accompanying drawings, in which:

[0011] Figure 1 is a block diagram of a platform for providing user-based control of data access in a multi-party environment according to an embodiment of the present disclosure;

[0012] Figure 2 is a block diagram illustrating aspects of a data ecosystem according to an embodiment of the present disclosure;

[0013] Figure 3 is a block diagram illustrating an exemplary process for recording and managing access to data according to aspects of the present disclosure;

[0014] Figure 4 is a block diagram illustrating a process for synchronizing data maintained on a distributed ledger according to aspects of the present disclosure;

[0015] Figure 5 is a block diagram illustrating aspects of clearing information from a distributed ledger according to aspects of the present disclosure;

[0016] Figure 6 is a block diagram illustrating aspects of a distributed ledger according to aspects of the present disclosure;

[0017] Figure 7 is a block diagram illustrating aspects of a process for registering a user with a service provider according to aspects of the present disclosure;

[0018] Figure 8 is a flow chart of an exemplary method for permissions-based management of user data via a distributed ledger; and

[0019] Fig. 9 is a flow chart of another exemplary method for permissions-based management of user data via a distributed ledger.

[0020] It should be understood that the drawings are not necessarily to scale and that the disclosed embodiments are sometimes illustrated diagrammatically and in partial views. In some instances, details that are not necessary for understanding the disclosed methods and apparatus or that render other details difficult to perceive may have been omitted. Of course, it should be understood that the present disclosure is not limited to the particular embodiments described herein. DETAILED DESCRIPTION

[0021] Embodiments of the present disclosure enable users to gain control of their data by providing a platform for managing service providers' access to user data using permissions. Service provider permissions can be managed by a UAP device (or multiple UAP devices) and allow service providers to receive / share / access user data or prevent service providers from receiving / sharing / accessing user data. For service providers with appropriate permissions, users can provide data during access to one or more services, and the data can be recorded in a distributed ledger by a service provider node. Each service provider node can correspond to different service provider devices (or services) and can only store information (e.g., user data, permission data, metadata, etc.) for which the corresponding service provider has appropriate permissions. For illustration, a service provider with only access permissions can store user data on a distributed ledger, but the data may not be shared. In contrast, a service provider with both access and sharing permissions can store data and share the data with other service providers (at least with access permissions). The user may also revoke the granted permissions, such as if the user stops using a particular service, and the revoking permissions may result in at least a portion of the data of the user corresponding to the service provider with the revoked permissions being deleted or cleared from the distributed ledger maintained by the service provider. As will be apparent from the more detailed description and examples below, embodiments of the present disclosure provide new functionality and features that improve the way users interact with service provider systems to manage their online footprints, and provide new capabilities that enable users to view and remove their data from service provider systems, a capability that is not readily available in today's systems. In addition, aspects of the present disclosure may improve data security by preventing abuse and misplacement of user data by entities. For example, the permissions-based aspects of the present disclosure may exclude sharing of user data with entities that have not been granted access by the user, thereby placing the user at the center of controlling the distribution of data among service providers. Such capabilities represent a change from existing systems in which service providers control how user data is utilized and shared with users who are provided with little or no control over such functionality.

[0022] refer to Figure 1 , a block diagram of a platform for providing user-based control of data access in a multi-party environment according to an embodiment of the present disclosure is shown as platform 100. Figure 1 As shown in FIG. 1 , the platform 100 includes one or more user devices 110, one or more user access provider nodes 120, a plurality of service provider (SP) devices, and a plurality of SP nodes 180. Note that although Figure 1 The plurality of SP devices are illustrated as including N SP devices, including SP device 140 , . . . , SP device 150 , but it should be understood that a platform according to the present disclosure may include more or fewer service providers (eg, N≧1).

[0023] like Figure 1 As illustrated in FIG. 1 , the user device(s) 110, the one or more user access provider nodes 120, the multiple SP devices, and the multiple SP nodes 180 may be communicatively coupled to one or more networks 170 via one or more wired or wireless communication links. The one or more networks 170 may include a local area network (LAN), a wide area network (WAN), a wireless LAN (WLAN), a wireless WAN, a metropolitan area network (MAN), a cellular data network, a cellular voice network, the Internet, etc. The communication links provided via the one or more networks may include: wired or wireless communication links established according to one or more communication protocols or standards (e.g., Ethernet protocol, transmission control protocol / Internet protocol (TCP / IP), Institute of Electrical and Electronics Engineers (IEEE) 802.11 protocol, and IEEE 802.16 protocol, 3rd generation (3G) communication standards, 4th generation (4G) / long term evolution (LTE) communication standards, 5th generation (5G) communication standards, etc.).

[0024] (Multiple) user devices 110 include one or more processors 112, memory 114, and one or more communication interfaces 118. Each of the one or more processors 112 can be a central processing unit (CPU) or other computing circuit (e.g., a microcontroller, one or more application-specific integrated circuits (ASICs), etc.), and can have one or more processing cores. The memory 114 can include a read-only memory (ROM) device, a random access memory (RAM) device, one or more hard disk drives (HDDs), flash memory devices, solid-state drives (SSDs), other devices configured to store data in a persistent or non-persistent state, or a combination of different memory devices. The memory 114 can store instructions 116 that, when executed by the one or more processors 112, cause the one or more processors 112 to perform a reference Figure 1-Figure 9Operations described in conjunction with user device 110. In addition to storing instructions 116, memory 114 may also store a digital wallet 117. Digital wallet 117 may be configured to store information associated with a user corresponding to user device 110, such as digital identity information, digital snapshots of personal data that the user has provided to various service providers, and other information, as described in more detail below.

[0025] The one or more communication interfaces 118 may be configured to communicatively couple the user device 110 to the one or more networks 170 via a wired or wireless communication link in accordance with one or more communication protocols or standards (e.g., one or more communication standards described above with reference to the one or more networks 170). Figure 1 , but the (multiple) user devices 110 may include input / output (I / O) devices, which may include one or more display devices, a keyboard, a stylus, one or more touch screens, a mouse, a track pad, a camera, one or more speakers, a tactile feedback device, or other types of devices configured to present information to a user or provide information to external systems and devices (such as multiple SP devices).

[0026] The user device(s) 110 may include various interfaces and applications that enable a user to interact with external systems and devices (e.g., multiple SP devices), such as to provide input to a website displayed in a web browser or an application (e.g., a mobile application, a desktop application, etc.) running on the user device 110, and view data displayed at a website displayed in a web browser or an application (e.g., a mobile application, a desktop application, etc.) running on the user device 110. For example, the SP device may be associated with a social media service provider, a financial service provider, a medical care service provider, a retailer (e.g., a loyalty program application, an e-commerce service, etc.), a communication service provider (e.g., an email service provider, a voice communication service provider, a messaging service, etc.), etc. The website or application may enable a user to provide information to various service providers, such as to create and manage an account of the user, upload images to a social media profile, perform financial transactions, initiate communications with various contacts of the user, obtain medical services, or other types of operations and functionality. Exemplary aspects of managing such data according to the present disclosure are described in more detail below.

[0027] The (multiple) UAP devices 120 may include one or more processors 122, a memory 124, and one or more communication interfaces 130. Each of the one or more processors 122 may be a CPU or other computing circuit (e.g., a microcontroller, one or more ASICs, etc.), and may have one or more processing cores. The memory 114 may include a ROM device, a RAM device, one or more HDDs, a flash memory device, a solid-state drive SSD, other devices configured to store data in a persistent or non-persistent state, or a combination of different memory devices. The memory 124 may store instructions 126 that, when executed by the one or more processors 122, cause the one or more processors 122 to perform a reference Figure 1-Figure 9 Operations described in conjunction with (multiple) UAP devices 120. In addition to storing instructions 126, memory 124 may also store permission data 128. Permission data 128 may include multiple sets of permissions for different users of platform 100, and may be used to control access to user data by multiple service providers. For illustration, permission data associated with user device 110 may specify permissions to provide or deny access to data associated with a user corresponding to user device 110. When permissions provide access to data, the access may be provided as read-only access (e.g., a service provider may view data provided by a user to which the service provider has been granted permissions), write access, sharing control (e.g., permissions that specify whether a service provider shares user data with other entities), publishing control (e.g., publishing control may allow data to be published or otherwise made publicly available, which is different from sharing control that allows data to be (privately) shared from one service provider to another service provider), or other types of access. Additional exemplary aspects of using permission data to control sharing of data with and between service providers and denying or revoking access to data are described in more detail below.

[0028] The one or more communication interfaces 130 may be configured to communicatively couple the UAP device(s) 120 to the one or more networks 170 via a wired or wireless communication link in accordance with one or more communication protocols or standards (e.g., one or more communication standards described above with reference to the one or more networks 170). Although not shown in FIG. Figure 1 However, the (multiple) UAP device 120 may include I / O devices, which may include one or more display devices, a keyboard, a stylus, one or more touch screens, a mouse, a track pad, a camera, one or more speakers, a tactile feedback device, or other types of devices configured to present information supporting the operation of the (multiple) UAP device 120 to an administrator or other user or to receive such information from an administrator or other user.

[0029] SP device 140 may include one or more processors 142, memory 144, and one or more communication interfaces 148. Each of the one or more processors 142 may be a CPU or other computing circuit (e.g., a microcontroller, one or more ASICs, etc.), and may have one or more processing cores. Memory 144 may include a ROM device, a RAM device, one or more HDDs, flash memory devices, SSDs, other devices configured to store data in a persistent or non-persistent state, or a combination of different memory devices. Memory 144 may store instructions 146 that, when executed by one or more processors 142, cause one or more processors 142 to perform a reference Figure 1-Figure 9 Operations described in conjunction with the service provider device.

[0030] The one or more communication interfaces 148 may be configured to communicatively couple the SP device 140 to the one or more networks 170 via a wired or wireless communication link in accordance with one or more communication protocols or standards (e.g., one or more communication standards described above with reference to the one or more networks 170). Figure 1 , but the SP device 140 may include I / O devices, which may include one or more display devices, a keyboard, a stylus, one or more touch screens, a mouse, a track pad, a camera, one or more speakers, a tactile feedback device, or other types of devices configured to present information supporting the operation of the SP device 140 to an administrator or other user or to receive such information from an administrator or other user.

[0031] SP device 150 may include one or more processors 152, memory 154, and one or more communication interfaces 158. Each of the one or more processors 152 may be a CPU or other computing circuit (e.g., a microcontroller, one or more ASICs, etc.), and may have one or more processing cores. Memory 154 may include a ROM device, a RAM device, one or more HDDs, flash memory devices, SSDs, other devices configured to store data in a persistent or non-persistent state, or a combination of different memory devices. Memory 154 may store instructions 156 that, when executed by one or more processors 152, cause one or more processors 152 to perform a reference Figure 1-Figure 9 Operations described in conjunction with the service provider device.

[0032] The one or more communication interfaces 158 may be configured to communicatively couple the SP device 150 to the one or more networks 170 via a wired or wireless communication link in accordance with one or more communication protocols or standards (e.g., one or more communication standards described above with reference to the one or more networks 170). Figure 1, but the SP device 150 may include I / O devices, which may include one or more display devices, a keyboard, a stylus, one or more touch screens, a mouse, a track pad, a camera, one or more speakers, a tactile feedback device, or other types of devices configured to present information supporting the operation of the SP device 150 to an administrator or other user or to receive such information from an administrator or other user.

[0033] In aspects of the present disclosure, users may utilize their user devices to register with the UAP device 120. For example, the UAP device 120 may provide an application (e.g., a mobile application, a desktop application, a browser-based application, etc.) that may be accessed by the user device 110. The application may be configured to facilitate a registration process through which a user may obtain a PID.

[0034] During the registration process, the user device 110 may transmit a registration request 102 to the UAP device 120 via the application. Depending on the specific configuration of the UAP device 120, the registration request 102 may include the user's name, a device identifier (e.g., a media access control (MAC)) address, a serial number, or other identifier that may be used to identify the user device 110), a username, a secret or password, an email address, a phone number, or other information. It is noted that the specific types of information described above as being included in the registration request 102 have been provided for purposes of illustration and not by way of limitation, and that the registration request may be configured to include additional and / or different types of information depending on the specific use case to which the system 100 is applied and the type of service provider involved. For example, if a government organization or entity is involved, then the information used to register the user may include the user's social security number or other types of government-assigned identifiers that may uniquely identify the user to the government organization or entity. Accordingly, for use cases involving social media service providers, utilizing a social security number would be an inappropriate piece of information required to identify the user during registration. It will be appreciated, therefore, that the registration request of an embodiment may utilize different types of information configured to uniquely identify a user, and that the particular pieces of information included in the registration request may vary depending on the service provider(s) involved, the types of services provided by the service provider(s), or for other reasons.

[0035] After receiving the registration request 102, the UAP device 120 can verify the content of the registration request 102 and upon successful verification, can transmit a platform identity (PID) message 104. In one aspect, the verification of the content of the registration request 102 can include the transmission of the verification to the user device 110, such as an email message, a text message, an automated voice reply message, or other communication configured to be received by the user. The verification transmitted to the user device 110 can include: a code (e.g., a sequence of letters, numbers, or alphanumeric characters) that the user can enter into an application associated with the UAP device 120 (e.g., using an I / O device of the user device 110) to verify the content of the registration request 102. It is noted that other techniques can be used to verify the identity of the user based on the registration request (such as based on an image of the user's driver's license or other types of identification technology), and the examples described herein are provided for purposes of illustration and not by way of limitation. After successful verification of the registration request 102, the UAP device 120 can transmit the PID message 104 to the user device 110 to indicate that the user has successfully registered with the UAP 120. After receiving the PID message 104, the application can generate a set of keys, which may include a public key and a private key. The private key can be stored locally on the user device 110, such as in the wallet 117. The public key can be transmitted to the UAP 120 and stored at the memory 124. For example, the public key can be stored as metadata within the authority database 128.

[0036] The platform 100 can utilize PIDs to facilitate various functions involving interactions between registered users (e.g., users who have completed the above-mentioned registration process with the UAP device 120) and multiple service provider devices. The PID can be unique on a distributed ledger configured to support the operation of the platform 100. For example, each of the multiple service provider devices can be associated with one of the SP nodes 180, and the distributed ledger can be maintained on the SP node. In one aspect, the SP node 180 can be established when the service provider registers with the platform 100. In various aspects, the functionality of the SP node 180 can be provided via a software process running on the corresponding service provider device. In additional or alternative aspects, the SP node can be a cloud-based process running on behalf of different service providers, or can be a physical server or other type of computing device operating on a service provider network or accessible to the service provider network.

[0037] The registration of service providers and the establishment of SP nodes can be used by the platform 100 to ensure compliance with various aspects of the present disclosure. For example, when a user provides data to multiple service provider devices, the data can be recorded on a distributed ledger maintained by the SP node. The SP node can use the application programming interface (API) of the UAP device 120 to verify or confirm the data provided by the user (e.g., to verify the identity of the user providing the data). When a user is provided to a service provider and stored at the SP node 180 corresponding to the service provider, the data can be synchronized with other SP nodes corresponding to other service providers. The permissions configured by each of the users can control how the service providers access and use the data, as well as the manner in which the data is synchronized between the service providers (e.g., in response to new data being provided by the user, modifying existing data, etc.). In addition, permissions granted to one or more service providers can be revoked by the user. When permissions are revoked, the user's data can be removed from the distributed ledger maintained by the SP node 180. Further details on the above functionality and other operations that can be performed by the platform 100 are provided below.

[0038] Brief reference Figure 2 , a block diagram illustrating aspects of a data ecosystem according to an embodiment of the present disclosure is shown. Figure 2 As shown in FIG, the platform 100 can be configured to organize service providers into different ecosystems. Figure 2 20 is illustrated as including a financial service provider ecosystem 210, a medical service provider ecosystem 220, a professional service provider ecosystem 230, and a social media service provider ecosystem 240. Each service provider ecosystem may include one or more service providers. For example, the financial service provider ecosystem 210 may include one or more financial service providers 212 (e.g., banks, credit card service providers, money transfer service providers, mortgage service providers, etc.), the medical service provider ecosystem 220 may include one or more medical service providers (e.g., clinics, hospitals, pharmacies, diagnostic services, etc.), and the professional service provider ecosystem 230 may include one or more professional service providers 232 (e.g., employees or third parties (such as e-commerce companies) that provide services to them). , etc.), and the social media service provider ecosystem 240 may include one or more social media service providers 242 (e.g., wait).

[0039] Please note, Figure 2The exemplary service provider ecosystems illustrated in the figure are shown for the purpose of illustration and not by way of limitation, and other service provider ecosystems may be utilized by platforms configured according to embodiments of the present disclosure. For example, service provider ecosystems may include government service ecosystems (e.g., public services or government service providers), public utility and energy service provider ecosystems, communication service provider ecosystems (e.g., cellular communication service providers, email service providers, etc.), media service provider ecosystems (e.g., entities providing streaming video services, movie studios, etc.), education service provider ecosystems (e.g., elementary schools, middle schools, high schools, universities, etc.), travel service provider ecosystems (e.g., airline service providers, railway service providers, subway service providers, taxi or ride-sharing service providers, etc.), physical service provider ecosystems (e.g., storage service providers, auction service providers, shipping service providers, etc.) or other service provider ecosystems. Although many different types of ecosystems may be supported by the infrastructure and operations of the system 100, different ecosystems may be subject to the same or different rules governing how entities within those ecosystems operate and interact with users and their data. For example, ecosystems involving government entities may require more sensitive data (e.g., Social Security number, driver's license number, etc.) upon registration and may require non-anonymous user accounts, while consumer ecosystems (e.g., social media or commerce ecosystems) may allow anonymous user accounts and may require less sensitive information to be provided by the user.

[0040] Each of the different service provider ecosystems may interact with a user (e.g., an operator of a user device 110) in different ways and based on different types of information. For example, a user may provide location information, contact information, image content, video content, and other types of information to service providers within the social media service provider ecosystem 240, and may provide medical history information, disease or symptom information, medication information (e.g., information about medications that the user(s) are currently taking or have previously taken), or other types of information that are not typically provided to social media service providers to the medical ecosystem 220. Additionally, the use of information provided by users by service providers within different service provider ecosystems may vary depending on the type of service associated with each ecosystem. For example, information provided by a user to a service provider in a medical service provider ecosystem may be used to diagnose and treat a disease, injury, or other medical problem that the user is experiencing, while information provided by a user to a service provider in a social media service provider ecosystem may be used to derive information about the user and the user's behavior and then use the derived information to generate revenue (e.g., through targeted advertising or other forms of monetization of user information).

[0041] Return to reference Figure 1 , the platform 100 can be configured to utilize different types of data. For example, the data types utilized by the platform 100 may include metadata, user information, permissions, and personal information. The metadata data type may include a user PID and information associated with the user's PID, such as a public key generated during registration with the UAP for each user. The public key may be stored by the UAP device 120, such as at the memory 124, and may be used to authenticate the information provided to the service provider. For illustration, a signature generated based on the user's private key may be included in the information provided to multiple service providers, and the service provider receiving the information may verify that the information actually comes from the user by requesting verification of the signature using the UAP device 120. The UAP device 120 may receive a request to verify the signature, and may verify that the information actually comes from the user using a public key associated with the PID of the user who is asserted to provide the information to the service provider. Additional details about verification of data based on public keys and signatures are described in more detail below.

[0042] The permission data type corresponds to information that grants various rights to authorize a service provider with respect to user data. The permission data may be maintained and stored at the UAP device 120 (e.g., as permission data 128). It is noted that a user may use permissions to grant access to data on the basis of a data type, on the basis of an ecosystem, on the basis of a service provider, etc. In addition to granting access to data by a service provider, permission data may also be used to revoke access to data. For example, a user may grant access to data to a specific service provider for a certain period of time, and then stop using the service provided by the specific service provider. When the user stops using the service, the user may revoke the permission of a specific service provider to access the user's data, thereby preventing further use of the data by the specific service provider. In an embodiment, the SP node 180 may be configured to delete user data from an SP node associated with a service provider having permission to revoke or deny access to user data. The personal information data type may correspond to data provided by a user to a service provider. Information of the personal information data type may be stored by a service provider on a distributed ledger, such as at the SP node 180. Note that information associated with the personal information data type may include personally identifiable information (PII) (e.g., information that can be used to identify a specific user or that may be subject to General Data Protection Regulation (GDPR) requirements).

[0043] The user information data type may correspond to data provided by a user to a service provider during interactions between the user and a plurality of service providers. Depending on the permissions configured by the user for a particular service provider, the service provider may store the information in a corresponding SP node, utilize the information in a one-time use scenario (e.g., to perform a financial transaction; to authenticate a user accessing a service, such as using or The SP nodes 180 may create a data structure (e.g., a hierarchical data structure) for storing information provided by each user. For example, the data structure may be a tree, and a different tree data structure may be created for each user to store the information provided by the user. Note that although a tree data structure is described above, the tree data structure is provided for purposes of illustration and not by way of limitation, and embodiments may utilize other data structures in accordance with the concepts disclosed herein. Creating a separate data structure for each user ensures that each user's data is maintained separately from other data provided by the user, which may enable the data to be more easily managed on a per-user basis. For example, when a user (e.g., using the rights data 128) revokes access to the user's data or a portion of the data, the SP node of the service provider associated with the revoked access rights may clear or delete the data structure.

[0044] The above process of providing, authenticating and storing user information at the SP node is illustrated in Figure 3 middle, Figure 3 is a block diagram illustrating an exemplary process for recording and managing access to data according to aspects of the present disclosure. Figure 3 middle, Figure 1 A user device 110, a UAP device 120 and a service provider device 140 are shown. In addition, Figure 3 Service provider devices 310, 320, 330 and service provider nodes 312, 322, 332, 342 are illustrated. Service provider device 140 may correspond to service provider node 342, service provider device 310 may correspond to service provider node 312, service provider device 320 may correspond to service provider node 322, and service provider device 330 may correspond to service provider node 332. In some embodiments, service provider devices 140, 310, 320, 330 may be assigned or allocated to the same service provider ecosystem, such as a social media service provider, a medical service provider ecosystem, a financial service provider ecosystem, etc. In other embodiments, some of the service provider devices 140, 310, 320, 330 may be assigned or allocated to different service provider ecosystems, such as a financial service provider ecosystem and a medical service provider ecosystem. It should be noted that in conjunction with Figure 3 References to specific ecosystems are provided for purposes of illustration and not by way of limitation, and Figure 3 The description may be utilized with a service provider device associated with other service provider ecosystems or combinations of service provider ecosystems.

[0045] like Figure 3 , the user device 110 may generate data 302 and transmit the data to the service provider device 140 via one or more networks 180. As described above, the data 302 may include a PID associated with the operator of the user device 110 and a signature generated using a private key of the PID. After receiving the user information 302, the service provider device 140 may transmit an authentication request 304 to the UAP device 120 via the one or more networks 180. The authentication request 304 may include the signature and PID included in the data 302, and may request the UAP device 120 to authenticate the identity of the user based on the signature and the PID. It is noted that the PID may not include the actual name or other identifying information of the user, and may simply be a digital identifier that enables the UAP device 120 to determine a public key that can be used to authenticate the signature (e.g., as described above, when the user's PID is created, it may be associated with a public / private key pair, and the UAP device 120 may store the public key, while the user device 110 may store the private key).

[0046] The authentication request 304 may be received by the UAP device 120, and the public key associated with the PID may be retrieved (e.g., from the memory 124). The UAP device 120 may apply the public key to the signature to verify that the signature corresponds to the PID, such as to verify that the application of the public key to the signature produces a correct value or other data indicating that the signature has been generated using the private key corresponding to the PID. Based on the application of the public key to the signature, the UAP device 120 may generate an authentication response 306, which may be transmitted to the service provider device 140 via one or more networks 180. The authentication response 306 may indicate whether the data 302 is actually provided by the user. For example, in the case where the application of the public key to the signature produces a first value, the data 302 may be verified to be from the user, and in the case where the application of the public key to the signature produces a second value, the data 302 may be determined to be from a different user (e.g., the data 302 cannot be trusted).

[0047] The service provider device 140 may receive the authentication response 306 via the one or more networks 180 and selectively store the user information 302 at the service provider node 342 based on whether the authentication response 306 indicates that the data 302 is verified to be from the user or not. For example, in the event that the authentication response 306 indicates that the author of the data 302 is the user corresponding to the PID, the data 302 may be stored at the service provider node 342, and in the event that the authentication response 306 indicates that the author of the data 302 is not the user corresponding to the PID, the data 302 may not be stored at the service provider node 342. When the authentication response 306 indicates that the author of the data 302 is not the user corresponding to the PID, an error message may be transmitted to the user device 110 to indicate that there is a problem associated with the data 302, or some other indication of a problem that occurred when the data 302 was provided to the service provider device 140. Note that although Figure 3 The service provider device 140 is illustrated as transmitting the authorization request 304 to the UAP device 120 to perform verification of the user's identity and verifying the source of the data using the authentication response message 306, but in some aspects, the service provider may autonomously perform the verification operation based on information received from the UAP device 120 (e.g., the user's public key), as described below with reference to Figure 7 Described in more detail.

[0048] Return to reference Figure 1 , information (e.g., Figure 3 The data 302) can be periodically synchronized across the service provider nodes to ensure that the distributed ledger maintained by the service provider nodes contains consistent information. The synchronization of data across the distributed ledger can be controlled via a set of policies. The set of policies for controlling the synchronization and sharing of user data across the distributed ledger can be configured based on permissions specified by the user, which are used to control the type of access each service provider has. Depending on the specific configuration of the platform 100, the access type may include read-only access, denied or no access, shared access, published access, open access, write access, or other types of access.

[0049] Open access or an open ecosystem may be used for use cases where greater flexibility may be desired. For example, an open access or ecosystem may enable users to autonomously register with a service provider (i.e., without providing their real name or other personally identifiable information), or allow a single user to have multiple accounts with a service provider. An open access or ecosystem may be used for use cases where service providers and their services are not covered by government regulations, and / or where there is minimal or no risk that the ability to have an anonymous identity would enable a user to use the service in a malicious manner (such as to commit fraud).

[0050] The read-only access type may allow the service provider to read the user's data from the distributed ledger without performing other operations on the data, such as storing the data, using the data to profile the user, selling the data to a third party, etc. The denied access type may prevent the service provider from reading, receiving (e.g., during a synchronization operation), or accessing data stored on the distributed ledger maintained by the service provider node 180. A service provider with write access may update or change user data recorded on the distributed ledger.

[0051] The shared access type may enable a service provider to provide or share user data with other service providers with appropriate permission levels. For example, the shared access type may allow a first service provider to share user information with other service providers with read-only access, shared access, or open access, but not with service providers with denied access permissions. Sharing permissions may be specified on a per-service provider basis, on an ecosystem basis, on a data type basis, or based on other factors.

[0052] When sharing permissions are specified on a per-service provider basis, user data may be shared only with service providers approved or specified by the user. For example, the UAP device 120 may be configured to provide a graphical user interface that includes an interactive element that enables a user to authorize a first service provider to share information with one or more additional service providers but may not share user data with other service providers. When so configured, the first service provider may share user information with one or more additional service providers but may not share user information with any other service providers. It should be noted that such a capability may enable a user to authorize a first service provider to share information with a second service provider but prevent the second service provider from sharing information with the first service provider. For example, a user may authorize a service provider that provides online retail services to share information with a second service provider that provides financial transaction processing services, such as a bank or financial institution where the user maintains one or more financial accounts, but may prevent the second service provider from sharing user information (e.g., bank or financial account information) with the first service provider (e.g., an online retailer). Note that in this example, the second service provider may be authorized to provide some information to the first service provider, such as authorization to charge a certain amount to the user's financial card or account, but may not share the user's personal information related to the user's financial account, such as balance, account number, etc., which may be stored at the service provider node corresponding to the second service provider.

[0053] Configuring sharing permissions on an ecosystem basis can enable users to quickly authorize or deny sharing of information between different service provider ecosystems. For example, a user may be able to configure sharing permissions that allow sharing of user information between service providers assigned or allocated to a medical service provider ecosystem using a single permission, thereby enabling service providers providing medical services to users to share information. Such capabilities can enable users to quickly configure permissions for many different service providers within an ecosystem. In addition to configuring permissions for sharing information within a single ecosystem, permissions can also specify sharing capabilities for sharing information between different ecosystems. For example, a graphical user interface provided by the UAP device 120 for configuring permissions may include interactive elements (e.g., check boxes, radio buttons, drop-down menus, etc.), which enable users to configure permissions for sharing information between different service provider ecosystems, such as specifying that service providers within a medical service provider ecosystem and within a retail service provider ecosystem can share information with service providers within a financial service provider ecosystem. In addition, configuring permissions on an ecosystem basis can be used to deny sharing of user information within an ecosystem or between multiple ecosystems. For example, permissions may enable a user to specify that service providers within a social media service provider ecosystem may not share information with other service provider ecosystems and / or other service providers within a social media service provider ecosystem.

[0054] Configuring permissions on the basis of data types can enable sharing permissions to be specified for different types of data. For example, a user can configure permissions for the following: personal information (e.g., address, legal name, phone number, email address, etc.), financial information (e.g., bank account, financial card information, etc.), social media content (e.g., image content, video content, text content, contact or friend information, etc.), or other types of information. For example, a user can configure permissions to allow a service provider to share financial information, such as to enable a retail service provider to share financial information provided by a user with other service providers (e.g., a financial service provider that provides services that use financial information to process payments) (e.g., to facilitate payments for purchases or other transactions). In various aspects, sharing permissions for data types can be more specific than just one category or type of data. For example, configuring sharing permissions for financial information can enable (multiple) users to configure permissions for sharing one or more specific financial cards without enabling sharing of other types of financial information, such as financial account information. This can provide users with the ability to enforce sharing permissions with a finer degree of specificity rather than simply sharing categorical data types.

[0055] It should be noted that the various user-configured sharing permissions described above have been provided for illustrative purposes rather than by way of limitation, and the platform 100 may enable additional sharing permissions to be configured. For example, the platform 100 may enable a combination of the above-mentioned sharing permissions to be used, such as to configure sharing permissions for a specific ecosystem or between specific ecosystems or other combinations of the above-mentioned sharing permissions and technologies on a per-data type basis. In addition, users can configure sharing and access permissions at the data instance level. For example, in a pharmacy use case, a user can configure permissions that indicate which pharmacies can access each individual prescription. In contrast to the user, the ability to configure permissions at the data instance level provides the user with the ability to share information with service providers on a need-to-know basis, so that the service providers can only access the portion of the user's information that each service provider needs to provide their services (for example, a pharmacy that dispenses a prescription for allergy medicine may not need access to the user's entire medical history).

[0056] In addition to the sharing permissions configured by the user, the platform 100 can be configured to impose some platform-level sharing permissions. For example, regulations such as the General Data Protection Regulation (GDPR) and various national regulations can limit the distribution of personally identifiable information (PII). The platform 100 can be configured to limit the flow of PII data according to such requirements. It should be noted that although such restrictions can limit the ability of the platform 100 to synchronize data to each service provider node of the distributed ledger, other mechanisms can be provided by the platform 100 to ensure that the data is processed in a consistent manner. For example, in the case where PII data cannot be transmitted to a specific service provider node due to restrictions on the distribution of PII data, a token or other type of information can be transmitted to a specific service provider node to indicate that the updated information for a specific user has been received by other service provider nodes of the platform 100. Different tokens can be used to identify specific multiple pieces of information, such as to indicate updated address information, updated financial account information, etc. When a specific service provider device receives a communication or interaction with a user, the service provider node can prompt the user to provide updated information based on (multiple) tokens, thereby ensuring that the user's information is currently across distributed ledgers.

[0057] In one aspect, the token(s) may be associated with a hash value or other information derived from the updated information, which may allow a particular service provider node to verify that the information provided by the user corresponds to the updated information that resulted in the transmission of the token. For example, in the case where a token associated with an updated address is provided, a hash of the current address information may also be provided. Note that because the hash function will not include PII data, it may not be transmitted in accordance with GDPR regulations, even if the actual address information will not be transmitted. When a particular service provider device receives the updated address information (e.g., after prompting the user to provide such information), a hash function may be performed on the updated address information to verify the hash received using the token, and if a match occurs, the updated address information may be recorded to the particular service provider node, and the distributed ledger may be synchronized without violating any GDPR regulations. In the event that the hash value does not match, the user may be prompted to confirm the address information, and if confirmed, additional token data may be transmitted to other service provider nodes and devices to indicate that another updated address has been received, and the process described above may be performed by other service provider devices and nodes to obtain updated information. The above techniques can facilitate the sharing and synchronization of information (e.g., tokens, hash values, etc.) in compliance with GDPR regulations without requiring actual sharing of PII data. Regardless of the specific manner in which user data is synchronized by the platform 100, it is understood that the synchronization of user data between the SP node and the portion of the distributed ledger maintained by the SP node can be restricted based on permissions configured by the user. For example, each service provider that receives information via sharing must have been previously granted permission to the shared data (e.g., to ensure that the shared data is provided in compliance with GDPR privacy by design provisions). In addition, when the user revokes permissions from the service provider, the service provider will no longer gain access to data about the user, and information previously obtained by the service provider from the user can be deleted from the service provider ledger, as described elsewhere herein, thereby ensuring compliance with the right to be forgotten provisions of the GDPR. As shown above, the platform 100 provides a mechanism that provides a structured and manageable way to ensure compliance with various GDPR provisions, including providing a mechanism for data sharing that complies with data portability provisions.

[0058] As briefly described above, when user data is provided from a user device (e.g., user device 110) to a service provider operating within a different service provider ecosystem, policies governed by permissions configured by the user may be used to share and synchronize data across a distributed ledger maintained by SP node 180. An exemplary process for synchronizing user information across a distributed ledger maintained by a service provider node of platform 100 according to aspects of the present disclosure is described in detail below. Figure 4 It is shown in Figure 4is a block diagram illustrating a process for synchronizing data maintained on a distributed ledger according to aspects of the present disclosure. Figure 4 middle, Figure 3 The service provider nodes 312, 322, 332, 342 and the service provider nodes 410, 420 are shown.

[0059] like Figure 4 As shown in FIG. 4 , user data 402 may be received at a service provider node 342 corresponding to Figure 1 and Figure 3 In one aspect, the user data 402 may be received at the service provider node 342 after the author of the user data 402 is authenticated, as described above with reference to Figure 3 As described. After receiving the user data 402, the service provider node 342 may access the user data stored on the distributed ledger corresponding to the author of the user data 402 to determine whether the user data 402 provides a change or update to the existing user data. For illustration, it is assumed that the user data 402 has address information. After receiving the user data 402, the service provider node 342 may compare the address information included in the user data 402 with the address data 442A stored on the distributed ledger at the memory of the service provider node 342 (or the memory 144 of the service provider device 140). The address data 442A may have been received at a previous time (t=0), and the user data 402 may be received at a subsequent time (t=1). After comparing the address data 442A with the address information included in the user data 402, the service provider node 342 may determine that the address information included in the user data 402 includes updated or new address information, and may store the updated or new address information as address data 442B.

[0060] A state may be associated with data stored on a distributed ledger. For example, address data 442A may include state data indicating that address data 442 is current address data at time (t=0), but the state data associated with address data 442 may be updated to indicate that address data 442A is historical data (e.g., not current, invalid, no longer in use, etc.) at time (t=1), and the state data associated with address data 442B may be assigned a current or valid information state. State data may be used to indicate the freshness or validity state of information recorded to a distributed ledger, and a service provider device may be configured to utilize information associated with a current or valid state rather than a historical state. Of course, if the address data included in user data 402 is already the same as address data 442A, then no update to the address data stored on the distributed ledger may be performed. Additionally or alternatively, data stored on the distributed ledger may be timestamped, and the timestamp associated with the state data corresponding to address data 442A may be updated to indicate the time when user data 402 was received, which may indicate that address data 442A is still valid or current as of that timestamp.

[0061] Recording timestamps in conjunction with data recorded to a distributed ledger can help coordinate synchronization of data across distributed ledgers. For example, in a high-traffic scenario where most information is shared with a service provider device and a corresponding service provider node, it is possible that updates to the information recorded to the distributed ledger may occur frequently, however, synchronization may not be performed in real time, and therefore it is possible that one service provider node records first information to the distributed ledger as "current" information, and another service provider node records second information (e.g., different from the first information) to the distributed ledger as "current" information, thereby creating a scenario in which two different pieces of information are recorded to the distributed ledger in a "current" or "valid" state. Such a scenario may occur in a situation where synchronization operations are performed periodically (rather than in real time), such as once a day, a week, an hour, or some other time period. Service provider nodes may use timestamps to synchronize distributed ledger data so that a consensus can be reached as to whether the "current" information should be the first information or the second information. To illustrate, where the first information has a most recent timestamp, the distributed ledger may be synchronized based on the first information, and where the second information has a most recent timestamp, the distributed ledger may be synchronized based on the second information.

[0062] In some aspects, the synchronization operation may synchronize both the current (or new) information and any intermediate information that may be relatively new (e.g., containing new information but not necessarily the latest information). For illustration, assume that in the above example, both the first information and the second information are new to one of the service provider nodes, but the second information is the latest or most recently received information. The service provider node may synchronize its distributed ledger data based on both the first information and the second information (e.g., so that the information recorded to the distributed ledger information of the service provider node is complete), but the first information may be marked with a historical state and the second information may be marked with a current state. Synchronizing information known to be historical may ensure that all nodes have a complete record of the user information and maintain consensus among the service provider nodes that store the information on the distributed ledger.

[0063] like Figure 4 As shown in FIG. 4 , when the service provider node 342 records the address information 422B to the distributed ledger, the service provider node 342 may transmit the synchronization data 404 to other nodes of the platform (e.g., Figure 1 For example, the service provider node 342 may transmit the synchronization data 404 to the service provider nodes 312, 322, 332, and may not transmit the synchronization data 404 to the service provider nodes 410, 420. The transmission of the synchronization data 404 to the selected service provider node may be based on the sharing permissions configured by the user and / or based on the sharing permissions configured by the platform 100, such as the sharing permissions described above for transmitting tokens (and possibly hash values, etc.) to comply with regulatory requirements (such as GDPR-related regulations). For example, Figure 4 As shown in FIG. 1 , at time (t=0), the service provider nodes 312, 322, 332 may store address information 412A, 422A, 432A having current tags or states, respectively. The address information 412A, 422A, 432A corresponding to time (t=0) may be the same as the address information 442A (e.g., indicating the same address information as the address information 442A).

[0064] At time (t=2), which may correspond to the time when the service provider node 312, 322, 332 receives the synchronization data 404, the service provider node 312, 322, 332 may record the updated address information and update the state data associated with the address data 412A, 422A, 432A to indicate the historical state. For example, the service provider node 312 may record the updated address information as address information 412B with current or active state data and assign the historical state to the address information 412A; the service provider node 322 may record the updated address information as address information 422B with current or active state data and assign the historical state to the address information 422A; and the service provider node 332 may record the updated address information as address information 432B with current or active state data and assign the historical state to the address information 432A.

[0065] The transmission of synchronization data 404 to service provider nodes 312, 322, 332, 342 can be based on sharing permissions configured on a per-ecosystem basis. For example, each of the service provider nodes 312, 322, 332, 342 can be part of the same service provider ecosystem, and the user's sharing permissions can be configured to allow sharing of user data between service provider nodes within the same ecosystem. It should be noted that such sharing permissions can only be applied to service providers with whom the user actually has a relationship. For example, service provider node 410 can be associated with a service provider that provides services that the user does not use, and synchronization data 404 may not be transmitted to service provider node 410, even if service provider node 410 can be associated with the same service provider ecosystem as service provider nodes 312, 322, 332, 342. As another example, synchronization data can be transmitted to service provider nodes 312, 322, 332, 342 based on sharing permissions configured on a per-service provider basis. For example, a user may configure sharing permissions that enable user data 402 to be shared between service provider node 342 and service provider nodes 312, 322, 332 instead of service provider nodes 410, 420. It should be noted that synchronization data 404 may be transmitted according to other sharing permissions and techniques (e.g., token / hash value techniques, etc.), and the exemplary scenarios described above have been provided for purposes of illustration and not by way of limitation. Therefore, it should be understood that the techniques described herein for controlling the sharing of data within a platform configured according to the present disclosure may be used to manage and control the sharing and synchronization of data across nodes that maintain a distributed ledger supporting (multiple) platforms.

[0066] Return to reference Figure 1As shown above, the platform 100 provides various mechanisms that enable users to gain control over how information is shared and synchronized between service providers that provide services used by the user. In addition to providing mechanisms for controlling how data is shared and synchronized, the platform 100 can also enable users to exert control over the storage of information on a distributed ledger. For example, the platform 100 can provide a graphical user interface that enables a user to selectively clear data from a distributed ledger maintained by multiple service provider nodes 180. The ability to clear information can enable a user to remove user data from a service provider node that is associated with a service provider that provides services that the user no longer desires to use. Clearing information from one or more service providers (or service provider nodes) can be accomplished by revoking permissions from (multiple) service providers.

[0067] For example and reference Figure 5 , a block diagram illustrating aspects of clearing information from a distributed ledger according to aspects of the present disclosure is shown. Figure 5 middle, Figure 1 The user equipment 110 and the UAP device 120 and the service provider node 332 are shown. Figure 5 As illustrated in , the user device 110 may provide permission data 502 to the UAP device 120. The permission data 502 may include an indication that permission to access user data by a service provider corresponding to the service provider node 332 has been revoked. Upon receiving the permission data 502, the UAP device 120 may update the permissions stored at a memory of the UAP device 120 (e.g., permissions 128 stored at the memory 124). For example, permission data 522A for a user at time (t=0) may authorize the service provider node 332 to access the user's data. Thus, at time (t=0), the service provider node 332 may store user data 532A, which may include information previously provided by the user to the service provider node 332 and / or as a result of a data synchronization operation (e.g., as described above with reference to Figure 4 described).

[0068] At time (t=1), the UAP device 120 may receive permission data 502 indicating that access rights have been granted to a service provider (eg, Figure 3522B). In one aspect, the permission data stored at the UAP device 120 may be associated with the shared data. For example, at time (t=0), the permission data 522A may have a current or active state, but after receiving the permission data 502, the permission data 522A may be assigned a historical state, and the permission data 522B may be assigned a current or active state (e.g., at time (t=1)).

[0069] After updating the permission data for the user based on the permission data 502, the UAP device 120 may transmit a revocation notification 504 to the service provider node 332 (or Figure 3 330). The revocation notification 504 may indicate that the service provider's permission to access the user's data has been revoked, and the service provider is no longer authorized to access the user's data. Upon receiving the revocation notification 504, the service provider node 332 may clear or delete the user's data. For example, before the permission data 502 is received by the UAP device 120 (e.g., at time (t=0)), the service provider node 332 may store user data 532A with a current or active status. When the revocation notification 504 is received, the service provider node 332 may delete the user data 532A, as indicated by arrow 506. Therefore, at time (t=1), the service provider node 332 may not store any user data corresponding to the user associated with the user device 110. Note that the clearing or deletion of user data may include the removal of any records of user transactions that the user may have interacted with the service provider. It is noted that although the examples described above provide for complete deletion or purging of user data when permissions are revoked, in some aspects, purging of data may not result in complete purging of all user data. For example, in some use cases, regulatory requirements or other factors may require that some data be retained (e.g., for financial or health care use cases). In such instances, the platform 100 may be configured to facilitate some data retention capabilities, such as to retain portions of a user's data required to comply with appropriate regulatory requirements, and any retained data may be prohibited from being shared, or may be shared only with service providers (such as government-type service providers) that have higher-level permissions to access the retained data.

[0070] Please note that although reference Figure 5The illustrated and described examples involve deleting all user data from the service provider node 332, but embodiments of the present disclosure are not so limited. For example, a user may revoke access to all of the user's data, which may result in clearing or deleting all user data, as described above, or may revoke access to certain types or pieces of information (such as financial account information, address information, email or phone number information, video content, image content, or other information that the user may have provided to the service provider and may be recorded to the distributed ledger by the service provider node 332). When access rights for specific types or pieces of information are indicated (e.g., instead of all access rights), the service provider node(s) may only delete or clear the specific types or pieces of user data for which the rights have been revoked, rather than all user data.

[0071] The ability to delete or clear information from a distributed ledger using permission highlights is an important difference between utilizing distributed ledgers and blockchain technology. For example, public blockchains are often touted as creating a trustworthy system due to the immutability of records recorded to the blockchain. However, if data is removed from the blockchain, this will reduce the credibility of the system because deleting blocks from the blockchain will create the appearance that the data has been tampered with, and can prevent the authentication of data retained on the blockchain. As an example, data recorded to the blockchain typically includes information, such as a hash value or other encrypted information derived from a previous block, and this information can be used to verify the authenticity of the block, such as by verifying that the hash value of the encrypted information stored in the block can be reproduced using the information recorded to the previous block. However, the deletion of information from the previous block can prevent such verification techniques from being used, thereby creating a sense of distrust within the system.

[0072] In contrast, the distributed ledger used by the platform according to embodiments of the present disclosure may be able to maintain consensus on user data despite the deletion of user data from some service provider nodes. For example, the synchronization techniques described above may ensure that all service provider nodes receive updated user data or at least notification that user data has changed (e.g., if GDPR regulations prevent the transmission of user data), thereby allowing all service provider nodes to track the current state of user data within the distributed ledger. In addition, because the data is maintained in a historical state (unless deleted or cleared based on revoked permissions), changes to user data can be tracked and identified, thereby allowing service provider nodes to achieve consensus on what the current user data actually is.

[0073] In one aspect, the platform 100 of an embodiment may utilize private blockchain technology to facilitate private ecosystems between service providers. In such instances, new service providers may be added only with the consensus of the ecosystem, thereby ensuring that all service providers in a given ecosystem agree to comply with the ecosystem requirements (e.g., all service providers agree to comply with the platform's permission-based access scheme and clear data after permission is revoked). However, for some ecosystems, it may be open to any service provider.

[0074] In one aspect, smart contracts can be used by the platform of the present disclosure to provide verification and enforcement mechanisms or other functionality. For example, smart contracts can be used to enforce compliance with data access rights, revocation and deletion of data, or other use case-specific functionality. Smart contracts can be provided on an ecosystem basis, so that each ecosystem is associated with a smart contract to which all ecosystem members are parties. The use of ecosystem-specific smart contracts can enable permissions and data clearing to be enforced in different ways to account for differences associated with different ecosystems. For example, some ecosystems may be subject to regulatory requirements that require data to be retained for a specific period of time. In such instances, data may be retained by those service providers for the required period of time before being cleared, but service providers in other ecosystems that do not have data retention requirements may be required by smart contracts to clear data immediately after the revocation of permissions.

[0075] In addition to the above-described features for configuring and controlling access to user data via permissions, the platform 100 may provide other functionality. Figure 1 , the user device 110 may maintain a wallet 117 in the memory 114. The wallet 117 may be configured to store one or more snapshots of user data that the user has provided to various service providers supported by the platform 100. For example, when user data is provided to multiple service providers, the user data may be periodically stored as snapshots at the user's wallet 117. The information stored in the wallet 117 may enable the user to: determine what information the user has provided to the various service providers, and obtain a comprehensive view of the user's footprint on the distributed ledger maintained by the service provider nodes of the platform 100.

[0076] For illustration, the user device 110 may include an application provided by an entity operating the UAP device 120, and the application may be configured to present a graphical user interface to the user, which allows the user to view the service providers that provide services used by the user (e.g., information has been provided to). The application may be a mobile application, a browser-based application (e.g., an application accessible via a web browser over the Internet), or other types of applications running on a smartphone, a tablet computing device, a desktop or laptop computing device, a personal digital assistant, or other types of electronic devices suitable for performing operations of the user device 110. The graphical user interface may enable the user to view information that has been recorded to the distributed ledger, and may arrange or present the information maintained in the wallet 117 in various ways. For example, the graphical user interface may enable the user to view a list of all service providers that the user has used, view information maintained on the distributed ledger by each service provider, view and modify the permissions that each service provider has within the platform 100, or other types of features. The information maintained on the distributed ledger may be arranged or presented in various ways, such as to show current personal information maintained on the distributed ledger (e.g., the user's address, email, phone number, and other personal information), which should be consistent across all service providers. Additionally, the user may be able to browse a list of transactions the user has engaged in with various service providers, which may include purchases or financial transactions, medical records, content viewed on a streaming platform, content uploaded to a social media service provider, or other types of information.

[0077] Providing each user with the ability to view a snapshot of the data they have shared with the service provider represents a significant departure from today's technology. For example, for today's Internet users, it may be difficult to remember every service provider that a user has interacted with in their lifetime, not to mention the content and data they have shared with all of them. This makes it nearly impossible for users to manage their digital footprint and keep track of the information they have provided to service providers over time. In contrast, the wallet described above enables snapshots of user data on a distributed ledger maintained by a service provider node to be backed up to a local user device (e.g., user device 110), where the information can be viewed by the user, thereby enabling the user to view a current list of service providers and services that the user has used, as well as data that the user has provided to the service provider. In addition, the data stored in the wallet enables the user to actively manage permissions and verify that data to which the user has revoked access has been cleared by the service provider, such as by viewing the information maintained in the wallet on a per-service provider basis after clearing to ensure that the user information is no longer stored on the service provider node.

[0078] In addition, the snapshots stored in the wallet 117 can be used to periodically audit the user's information on the distributed ledger, for example, the wallet 117 can store current and historical user data that has been provided to the service provider over time. Periodically, the user device 110 can transmit an audit request to a service provider device (or service provider node) requesting a snapshot or copy of all or a portion of the user's data, and the user device 110 can (e.g., in response to the audit request) compare the information received from the service provider device / node with a previously obtained snapshot of the user's data (e.g., a snapshot obtained via a periodic backup of the user's data) to verify that the contents of the distributed ledger are correct. Such a feature provides the user with the ability to view, verify, and audit the user's online footprint and verify that the user's data has not been altered or is incorrect.

[0079] Brief reference Figure 6 , a block diagram illustrating aspects of a distributed ledger according to aspects of the present disclosure is shown. Figure 6 , a distributed ledger 600 is shown and includes multiple transaction sequences. Note that the transaction sequences on the distributed ledger are not financial transactions, but rather are transaction sequences involving interactions between users and service providers (e.g., a user uploads media content to a social media service provider), or between service providers on behalf of or for the benefit of a user (e.g., a doctor performs tests on a user's patient and then a laboratory analyzes the tests and provides the results back to the doctor), which interactions result in data being recorded to the distributed ledger 600.

[0080] like Figure 6 As shown in , the data recorded to the distributed ledger 600 can be reflected as a separate transaction or transaction sequence for each user / data type. Figure 6In the ledger 600 illustrated in FIG. 6 , a sequence of transactions 610, 620, 630, 640 are shown. The transaction sequence 610 includes data transactions corresponding to a first user (identified to the platform 100 using “PID1”), and transactions 612, 614, 616 of the transaction sequence 610 include data transactions that record the medical data of the first user to the distributed ledger 600. Transaction 612 may be a data transaction that records information associated with a medical test performed on the first user, transaction 614 may be a data transaction that records information associated with a laboratory analysis of the medical test (e.g., a swab of the first user’s mouth, a blood test, etc.), and transaction 616 may be a data transaction that records a diagnosis of the first user’s condition by a doctor, which may or may not be related to the medical test and the laboratory analysis. The transactions included in the transaction sequence 610 may be performed by a single entity or by multiple entities. For example, transactions 612, 616 may be performed by the first user's attending physician, and laboratory analysis transaction 614 may be performed by a third-party medical service provider, or the transactions may all be performed by a single medical service provider (e.g., a hospital with an on-site laboratory, etc.). Transaction sequence 610 includes the medical data of the first user recorded to the distributed ledger 600 using the techniques described above (e.g., signature verification, permission-based access, etc.). It is noted that, depending on the permissions of the various medical service providers supported by the platform 100, the medical data recorded to the transaction sequence 610 may be readable or unreadable to a specific service provider supported by the platform 100 (e.g., some service providers may have permissions that allow read / view access to the first user's medical data, while other service providers may not). In addition, it is noted that some service providers may be able to see some but not all of the transactions. For example, a laboratory service provider associated with transaction 614 may be provided with access to data recorded in transaction 612, such as to share assay information (or samples) with a laboratory, but may not be able to read or access transaction 616. In one aspect, when a transaction occurs (e.g., a transaction that updates data, a transaction that creates new data, etc.), signatures from the service provider and the user can be recorded as part of the transaction. The sequence of transactions can be stored and distributed among the service providers along with the current state of the data.

[0081] Similar to transaction sequence 610, transaction sequence 620 includes data transactions corresponding to a first user (identified to platform 100 using "PID2"), and transactions 622, 624, 626 of transaction sequence 620 include data transactions that record medical data of the first user to distributed ledger 600. Transaction 622 may be a data transaction that records information associated with an x-ray taken on a second user, transaction 624 may be a data transaction that records information associated with treatment of the second user (e.g., information associated with placing a cast or other type of fixation device on a broken bone that was x-rayed, etc.), and transaction 626 may be a data transaction that records insurance information (insurance provider information of the second user) on ledger 600. The transactions included in transaction sequence 620 may be performed by a single entity or by multiple entities. For example, transactions 622, 624 may be performed by an emergency room that examines and treats the second user, and transaction 626 may be data recorded to distributed ledger 600 by the second user (e.g., after obtaining health insurance, after a change in health insurance, etc.). The transaction sequence 620 includes the medical data of the second user recorded to the distributed ledger 600 using the techniques described above (e.g., signature verification, permission-based access, etc.). It is noted that, depending on the permissions of the various medical service providers supported by the platform 100, the medical data recorded to the transaction sequence 620 may be readable or unreadable to a particular service provider supported by the platform 100 (e.g., some service providers may have permissions that allow read / view access to the first user's medical data, while other service providers may not). In addition, it is noted that some service providers may be able to see some but not all of the transactions.

[0082] Transaction sequence 630 includes data transactions corresponding to a first user (identified to platform 100 using “PID1”), and transactions 632, 634 of transaction sequence 630 include data transactions that record social media data of the first user to distributed ledger 600. For example, transaction 632 may be a data transaction that records media content uploaded by the first user to a social media service on distributed ledger 600, and transaction 634 may include text information posted by the first user to the social media service.

[0083] Transaction sequence 640 includes data corresponding to a first user (identified to platform 100 using "PID1") and transaction 642. The data recorded to distributed ledger 600 in conjunction with transaction sequence 640 may include data related to a data transaction between the first user and a retail service provider supported by the platform. For example, transaction 632 may be a data transaction that records information associated with an order placed by the first user with respect to a retail service provider, such as an order placed with respect to an online shopping service.

[0084] Note that although Figure 6 Distributed ledger 600 is illustrated as including four transaction sequences (e.g., transaction sequences 610, 620, 630, 640) corresponding to two different users (e.g., a first user associated with “PID1” and a second user associated with “PID2”), and including three different types of data (e.g., medical data, social media data, and retail data), but it should be understood that Figure 6 The exemplary transaction sequences illustrated in have been provided for purposes of illustration and not by way of limitation, and a distributed ledger according to an embodiment may include transaction sequences associated with other types of data (e.g., financial data, etc.). Additionally, although transaction sequences 610, 620, 630, 640 are illustrated as including three or fewer data transactions, a transaction sequence maintained on a distributed ledger according to the present disclosure may include more than three data transactions, depending on the particular level of data transactions that a user interacts with a service provider provided by the platform.

[0085] like Figure 6 As illustrated in and described above, data is recorded to the distributed ledger 600 as separate transactions for each user and each data type (e.g., the first user's medical data is recorded on the transaction sequence 610, while the first user's social media data and retail data are recorded on the transaction sequences 630, 640, and the second user's medical data (or other type of data) is recorded in a transaction sequence separate from the transaction sequence associated with the first user). By maintaining the transaction sequence on a per-user / per-data type basis, information can be cleared from the distributed ledger 600 without creating the appearance of tampering. For example, assume that the first user revokes a particular service provider's access to all or part of the user's social media data. When this occurs, the transaction sequence 630 (or portion) on the distributed ledger maintained by the service provider node of the particular service provider may be deleted (e.g., if the user revokes access to only images, the images will be deleted, if the user revokes access to all data, the entire transaction sequence maintained by the particular service provider node will be deleted). It is noted that if some of the data recorded to the social media transaction sequence 630 is associated with a different service provider (e.g., other than a particular service provider), the distributed ledger maintained on the service provider node of the different service provider may maintain its instance of the social media transaction sequence. Thus, for the particular service provider, the social media data of the first user is completely deleted, while other service providers maintaining the social media data transaction sequence for the first user may not see any changes.

[0086] Also, please note that Figure 6 The transaction sequence illustrated in the figure may not be completely consistent with the Figure 1614. The medical data recorded to the transaction sequence 610 may be visible to all service providers supported by the platform 100. For example, the medical data recorded to the transaction sequence 610 may be associated with two different medical service providers (e.g., a doctor and a laboratory) that provide medical services to the first user. The laboratory may be able to access the medical tests and laboratory analysis data 614 associated with the transaction 612, but may not be able to access the transaction data 616 including information related to the diagnosis made by the doctor based on the laboratory analysis data 614. In contrast, the doctor may be able to access all data recorded to the transaction sequence 610, including the laboratory analysis recorded in the transaction 614. Therefore, the transaction sequence 610 may be recorded in its entirety on the service provider node associated with the doctor, while only a portion of the transaction sequence 610 (e.g., transactions 612, 614) may be recorded at that portion of the distributed ledger maintained by the service provider node associated with the laboratory. Thus, depending on the access permissions that each service provider has been granted, each service provider node may record the same or different portions of the user's data on the distributed ledger (e.g., service providers with the same permissions for a particular type of user data may have the same data recorded by their service provider nodes, and service providers with different permissions for a particular type of user data may have different portions of the data recorded by their service provider nodes).

[0087] As briefly described above, the distributed ledger data may be periodically backed up to a user wallet, which allows the user to obtain a complete picture of the data maintained by the service provider node on the distributed ledger. For example, a first user may be able to access the first user's wallet (e.g., Figure 1 wallet 117) and views transaction sequence 610, transaction sequence 630, and transaction sequence 640 without viewing transaction sequence 620 associated with the second user.

[0088] It is noted that transaction sequences can be structured as records in a database. For example, each data transaction sequence on the distributed ledger 600 can correspond to a specific user, and a single user can have multiple transaction sequences on the distributed ledger, such as different transaction sequences for different types of data and / or service provider ecosystems. Therefore, instead of including a single data structure or table that records all user data for a user, the distributed ledger 600 can contain many individual transaction sequence records for each user, where each individual transaction sequence record corresponds to a data transaction sequence for a specific user and data type or ecosystem. In this way, when the data of a specific user is cleared, the transaction sequence record for the specific user of the data is simply deleted without affecting other transaction sequence records associated with data transaction sequences for other users, and without causing any changes to other instances of transaction sequence records of the distributed ledger storing the data for the user.

[0089] refer to Figure 7 , a block diagram illustrating aspects of a process for registering a user with a service provider according to aspects of the present disclosure is shown. Figure 7 middle, Figure 1 and Figure 3 The user equipment 110 and the UAP device 120 and Figure 3 The service providers 310, 320, 330 and the service provider nodes 312, 322, 332 are shown. In addition, Figure 7 A service provider device 710 and a service provider node 712 corresponding to the service provider device 710 are illustrated. Figure 7 In the example of FIG. 7 , a user associated with user device 110 is registering with service provider device 710 as a new service provider for the user (eg, the operator of user device 110 ).

[0090] The registration process may be initiated when the user device 110 transmits a registration request 702 to the service provider device 710. In various aspects, the registration request may be transmitted via an application that communicatively couples the user device 110 to the service provider device 710. For example, the application may be a mobile application that the user has installed on the user device 110, and may provide a graphical user interface that enables the user to register one or more services provided by the service provider device 710. Additionally or alternatively, the application may be a web-based application accessible via a web browser of the user device 110, such as a website associated with a service provider corresponding to the service provider device 710. The application may request information from the user, such as the user's name, address, telephone number, email address, or other information, and the user may fill the information into the graphical user interface of the application (e.g., via a form or other input technology). When the registration request 702 is transmitted, it may include a signature of the user (e.g., a signature generated using a private key corresponding to a public key registered by the UAP device 120).

[0091] The registration request 702 may be received by the service provider device 710 via the network(s) 180, and upon receiving the registration request, the service provider device 710 may determine that the user is a new user and transmit an access request 704 to the UAP device 120. The access request 704 may be a request to receive permissions and other metadata from the UAP device 120, where the permissions and metadata may be used to control access of the service provider device to the user's data. In one aspect, the initial set of permissions granted to the service provider device 710 may be based on data type permissions, and then, once registered, the user may customize permissions for the service provider device 710. Alternatively or additionally, the UAP device 120 may transmit a notification or message to the user device 110 to configure service provider permissions for the service provider device 710. In such an implementation, the user may then access a permissions graphical user interface provided by the UAP device 120 to configure permissions.

[0092] Regardless of whether the permissions and metadata are configured using default, per-data type permissions, or custom permissions, the UAP device 120 may transmit the permissions and metadata to the service provider device 710 as a permissions and metadata message 706 (in Figure 7 706). The permissions and metadata message 706 may be received by the service provider device 710 via one or more networks 180, and the granted permissions may be used to configure a portion of a distributed ledger maintained by the service provider node 712 to store the user's data based on permissions (e.g., when the user begins exchanging data with the service provider device 710). In one aspect, the permissions and metadata message 706 may include a public key corresponding to a private key of the user (e.g., a private key that the user used to generate a user signature when providing data to the service provider). The service provider device 710 may use the public key in subsequent interactions with the user to verify the data provided by the user, such as to verify the identity of the user as the source of the data provided to the service provider device 710. In particular, rather than sending an authentication request (e.g., Figure 3 The authentication request 304 is transmitted to the UAP device 120 and an authentication response (e.g., Figure 3 Authentication response 306), as referenced Figure 3As described, instead, the service provider device can use the corresponding public key (which can be stored by the service provider node as part of the distributed ledger) to verify the signature included in the data transmitted from the (multiple) user device. In such an implementation, the public key can also be used by the service provider device and the service provider node to verify the data during the synchronization operation, such as to verify that the data synchronized from one service provider node to other service provider nodes is authenticated using the public key and the signature associated with the data is synchronized. Using the above techniques, service providers can ensure that the transactions broadcast to them as part of the data synchronization are legitimate and that the user has approved the transaction by verifying the signature.

[0093] The permissions granted to the new service provider (e.g., the service provider associated with the service provider device 710) may be synchronized to portions of the distributed ledger maintained by one or more other service providers that also maintain distributed ledger data for the user. For example, assume that the user utilizes services provided by the service provider corresponding to the service provider device 310, 320, and the service provider node 312, 322 maintains at least some of the user's data on the distributed ledger. The permissions granted to the service provider device 710 may be synchronized with the distributed ledger instance maintained by the service provider device 310, 320 and the service provider node 312, 322. In various aspects, the synchronization of permissions for the new service provider may be limited on a per-ecosystem basis, such that only distributed ledger data maintained by other service providers within the same service provider ecosystem as the new service provider is updated with the permissions of the new service provider. In additional or alternative aspects, permissions may be synchronized between portions of the distributed ledger across multiple ecosystems or all ecosystems (e.g., to facilitate more robust data synchronization or system awareness).

[0094] In some aspects, the UAP device 120 may select a service provider to serve as a custodian service provider. The custodian service provider 708 may at least partially facilitate the synchronization of user data and permissions across or within an ecosystem. For example, the UAP device 120 may select one of the service providers 710, 310, 320 as a custodian service provider responsible for backing up the user's data across the ecosystem. The custodian service provider may not have write permissions (e.g., the custodian service provider may not be able to write new user data to the distributed ledger autonomously). Due to their role in helping the synchronization of user data on the distributed ledger, the custodian service provider may also be involved in facilitating the backup of user data recorded on the distributed ledger to the user's wallet. It should be noted that in some aspects, a service provider that is not a custodian may be selected to help synchronize distributed ledger data within or across an ecosystem. In other aspects, the custodian service provider may be given priority in helping to synchronize data across and within an ecosystem. For example, where multiple service providers within an ecosystem maintain user data on a distributed ledger and one of the service providers is a custodial service provider, the custodial service provider may assume or be assigned the role of managing or coordinating the synchronization of the distributed ledger data for one or more ecosystems.

[0095] As Figure 7In the illustrative example of the concept illustrated in FIG, it is assumed that the user of the user device 110 is a woman who is 26 weeks pregnant. The user may have visited her regular doctor many times, but one night she experienced complications and needed to visit the emergency room in the middle of the night. When her regular doctor was able to access various medical history data and other medical information related to the user's pregnancy, this was the first time the user had been to the emergency room. Traditionally, the user would be asked to complete a lot of paperwork and wait in the waiting room until the time to see the doctor, and once she met the doctor, she would be asked a lot of questions about her medical history and pregnancy (for example, the information that her regular doctor already had). This process is very time-consuming and may produce unnecessary and unreasonable delays in providing services to the user, and may cause inaccurate information to be given to the emergency room doctor (for example, if the patient forgets to mention something about the existing condition). Compared to the traditional processing of this exemplary scenario, after arriving at the emergency room, the user can register with the emergency room, as described above. Once registration is complete and the user's metadata and permissions are transferred to the emergency room system, the user's medical history information (including information about the user's past tests and evaluations during her pregnancy) can be shared with the emergency room system (e.g., via synchronization with other medical service providers). In addition to sharing medical history information, the metadata and permissions can also result in synchronization of the user's health insurance information, thereby eliminating the need to provide this information via filling out lengthy forms upon arrival at the emergency room (or perhaps just confirming that it is still correct).

[0096] The synchronization of data after approval of the emergency room to the network of the user's approved or authorized entity can enable the user to be seen by the doctor more quickly, minimize the time required for the doctor to diagnose the user (e.g., by eliminating the need to ask the user many questions to obtain the user's medical history), and minimize the cost of the health care services received by the user from the emergency room (e.g., by avoiding unnecessary tests due to having a complete picture of the user's medical history). To illustrate, a doctor in the emergency room may be able to quickly review the synchronized medical history data to learn the pregnancy history, and then only ask questions about the current symptoms the user is experiencing. This can enable the doctor to diagnose the user's symptoms more quickly and implement a plan to treat the user's condition. For example, the doctor may determine that the user needs a minor medical procedure. It is noted that although the doctor may have arrived at the same diagnosis using traditional techniques, the synchronization and sharing of data can enable the services provided by the doctor and the emergency room to be provided more quickly and efficiently, thereby reducing cost and time. In addition, in some emergency situations, the ability to synchronize and share data can play an even more critical role in providing services to the user, such as if the user suffers from a life-threatening condition, which may be diagnosed and treated more quickly due to the synchronization of medical data instead of using traditional techniques.

[0097] As shown above, the platform of the embodiments provides various advantages over current technologies and systems that allow users to exchange data with service providers. For example, current users inconsistently copy and manage their personal data and other data across service providers, resulting in inconsistent data being provided to different service providers (e.g., different service providers may have different addresses or other information for a user), and / or different service providers having inconsistent views of the user's information (e.g., different medical service providers may have limited visibility of the user's information). In contrast, the platform 100 synchronizes user data across various service providers and service provider ecosystems based on user configurable permissions to ensure that the user data is consistent across all service providers, at least to the extent that different service providers have appropriate permissions for a given set of user data. In addition, the platform 100 provides a wallet (e.g., that allows users to view their online footprint or data footprint (e.g., data that a user has provided to different service providers) Figure 1 wallet 117). In addition, the platform of an embodiment enables a user to clear data from a service provider, such as when the user stops using the service. It is noted that distributed ledger technology (e.g., Figure 6 The use of a distributed ledger 600) also provides technical improvements in the way data is managed, stored, and synchronized. For example, traditional blockchain technology is not suitable for providing all of the features provided by the platform of the present disclosure because deleting or clearing data from the blockchain will create the appearance of tampering and may prohibit verification of the data (for example, because some blockchain verification technologies require information from previous blocks, which may not be available if those blocks are deleted). In addition, as referenced Figure 6 The described maintenance of transaction sequences on a distributed ledger on a per-user / per-data type basis allows data to be shared and synchronized differently for different service providers and service provider ecosystems, thereby providing the ability to tune and control how user data is shared between different service providers.

[0098] refer to Figure 8 , a flowchart of an exemplary method for permission-based management of user data via a distributed ledger is shown as method 800. In various aspects, method 800 can facilitate a data management platform (such as Figure 1 In various aspects, the steps of the method may be stored as instructions that, when executed by one or more processors, cause the one or more processors to perform operations corresponding to the steps of the method 800.

[0099] like Figure 8As shown in , method 800 may include: at step 810, configuring a set of permissions for a first user by a user access provider (UAP) device, and at step 820, storing a public key at a memory by the UAP device. The set of permissions may be configured to grant or deny permissions to multiple service providers (such as Figure 1-Figure 5 and Figure 7 As described above, the set of permissions may be configured after the user registers with the UAP device or at a later time, such as when the first user begins using services provided by multiple service providers supported by the platform. As part of the configuration process, the first user may be assigned a decentralized identity (PID), as described above with reference to Figure 1 Additionally, the registration process may include creating a private key / public key pair, wherein the private key is maintained or stored at a memory of a user device corresponding to the first user, and the public key is stored at a memory of the UAP device (as in step 820 of method 800).

[0100] At step 830, method 800 includes: transmitting, by the UAP device, the public key to one or more service provider nodes associated with a service provider providing services to the first user. As described above, when a user provides data to a service provided by a service provider, the user may use a private key to sign the data, and the service provider may verify the user based on the public key, such as to verify that the first user is the source of the data by verifying a signature included in the data provided to the service using a public key corresponding to the first user. At step 840, method 800 includes: storing, by a first service provider node associated with the first service provider, the first data to a distributed ledger. The first data may be provided to a service provided by the first service provider via a user device of the first user, and may be verified by verifying a signature provided with the first data using a public key corresponding to the first user.

[0101] At step 850, method 800 includes: synchronizing, by the service provider node, the first data to one or more second service provider nodes based on a set of permissions corresponding to the first user. The one or more second service provider nodes may correspond to other service providers that provide services to the first user, and the set of permissions may specify different types of access for different second service provider nodes in the one or more second service provider nodes, as described above. In various aspects, the user data recorded to the distributed ledger by the service provider node may be associated with a state, as described above with reference to Figure 3For example, current data may be assigned a first state, while data that has changed or been updated may be assigned a historical state. In addition, data may be stored on a distributed ledger as a sequence of data transactions on a per-user and per-data type basis, as described above with reference to Figure 6 In various aspects, method 800 may also include features for clearing data from a portion of a distributed ledger maintained by one or more service provider nodes, as described above with reference to Figure 5 described herein; and synchronization of user data to a wallet (e.g., to enable a user to view a snapshot of their online data), and other features described herein.

[0102] As shown above, the platform of the embodiment operating in accordance with method 800 provides various advantages over current technologies and systems that allow users to exchange data with service providers. For example, method 800 enables synchronization of user data across various service providers and service provider ecosystems based on user configurable permissions to ensure that user data is consistent across all service providers, at least to the extent that different service providers have appropriate permissions for a given set of user data. Additionally, method 800 enables synchronization of user data from a distributed ledger to a user wallet (e.g., Figure 1 The method 800 may also enable the user to clear data from the service provider, such as when the user stops using the service. It is noted that the distributed ledger technology (e.g., Figure 6 The use of a distributed ledger 600) also provides technical advantages with respect to the way data is managed, stored, and synchronized. For example, conventional blockchain technology is not suitable for providing all of the features provided by method 800 because deleting or clearing data from the blockchain will create the appearance of tampering and may inhibit verification of the data (e.g., because some blockchain verification technologies require information from previous blocks, which may not be available when those blocks are deleted). Note also that, as referenced in Figure 6 The described maintenance of user data in a transaction sequence on a per-user / per-data type basis allows data to be shared and synchronized differently for different service providers and service provider ecosystems, thereby providing the ability to tune and control how user data is shared between different service providers and service provider ecosystems.

[0103] refer to Fig. 9 , a flowchart of another exemplary method for permission-based management of user data via a distributed ledger is shown as method 900. In various aspects, method 900 can be performed by a service provider system (such as Figure 1-Figure 5 and Figure 7The steps of method 900 may be stored as instructions that, when executed by one or more processors, cause one or more processors to perform the steps of method 900.

[0104] like Fig. 9 As shown in , method 900 includes receiving a registration request at a service provider device at step 910. The registration request may include information associated with a user registering for a service provided by a service provider corresponding to the service provider device, as described above with reference to Figure 7 At step 920, method 900 includes transmitting an access request to a user access provider (UAP) device based on the registration request, and at step 930, receiving a set of permissions from the UAP device in response to the access request. The access request may be Figure 7 Request for access 704, and the set of permissions may include information about Figure 7 The information described by the permissions and metadata message 706. As described above, this set of permissions and metadata can authorize the service provider to store, access and share the data provided by the user, depending on how the permissions are configured.

[0105] At step 940, method 900 includes receiving first data from a user via the service. As described above, the first data may include user data and a signature generated using a private key of the user. At step 950, method 900 includes verifying the user as the source of the first data based on the signature. As described above, the signature may be verified by transmitting the data to the UAP device (e.g., as described in reference to FIG. 1 ). Figure 3 ), or can be verified using a public key provided with the authority data (e.g., in step 930). At step 960, the method includes storing the first data to a portion of a distributed ledger maintained by a first service provider node. The first service provider node can be a service provider node corresponding to a service provider that received the first data, and the portion of the distributed ledger can correspond to a sequence of data transactions specific to the user, as described in reference to Figure 6 At step 970, the method may include synchronizing the first data to one or more other service provider nodes based on the set of permissions. In various aspects, the first data may be synchronized to one or more other service provider nodes, such as reference Figure 4 It is noted that method 900 may include other operations described herein, such as clearing data (such as reference Figure 5 described herein), synchronization of data to user wallets, and other features described herein.

[0106] As shown above, the platform of the embodiment operating in accordance with method 800 provides various advantages over current technologies and systems that allow users to exchange data with service providers. For example, method 900 enables synchronization of user data across various service providers and service provider ecosystems based on user configurable permissions to ensure that user data is consistent across all service providers, at least to the extent that different service providers have appropriate permissions for a given set of user data. Additionally, method 900 enables synchronization of user data from a distributed ledger to a user wallet (e.g., Figure 1 The method 900 may also enable the user to clear data from the service provider, such as when the user stops using the service. It is noted that the distributed ledger technology (e.g., Figure 6 The use of a distributed ledger 600) also provides technical advantages with respect to the way data is managed, stored, and synchronized. For example, conventional blockchain technology is not suitable for providing all of the features provided by method 900 because deleting or clearing data from the blockchain will create the appearance of tampering and may inhibit verification of the data (e.g., because some blockchain verification technologies require information from previous blocks, which may not be available when those blocks are deleted). Note also that, as referenced in Figure 6 The described maintenance of user data in a transaction sequence on a per-user / per-data type basis allows data to be shared and synchronized differently for different service providers and service provider ecosystems, thereby providing the ability to tune and control how user data is shared between different service providers and service provider ecosystems.

[0107] As shown above, embodiments of the present disclosure provide new technologies and processes for managing how user data is accessed, shared, and controlled in a multi-party environment. The permission-based control provided by the embodiments improves data security by preventing unauthorized entities from accessing user data (e.g., only service providers with access rights authorized by the user can access user data), and enables users to clear data from service provider systems (e.g., by revoking access rights). In addition, embodiments enable users to gain control over their data in a variety of new ways, such as managing permissions on a per-ecosystem basis (e.g., ecosystem-level permissions), on a per-data type instance, on a per-service provider basis, on a per-data instance basis, etc. Such capabilities provide users with robust controls for: sharing data between different service providers while ensuring that user data is maintained in a consistent state across all service providers with appropriate permissions. In addition, embodiments provide wallets that enable users to view snapshots of data that service providers have, which can allow users to make more informed decisions about which service providers can access their data and what data is included in their online footprint. The features and functionality described above may provide a framework that provides a standardized approach for systems under the control of different service providers or entities to be operated autonomously, while ensuring compliance with various requirements (e.g., GDPR) while allowing users to remain at the center of control over how their data is accessed and used by third-party entities.

[0108] Those skilled in the art will appreciate that information and signals may be represented using a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced in the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0109] The functional blocks and modules described herein (eg, Figure 1-Figure 9 The functional blocks and modules in the present invention may include processors, electronic devices, hardware devices, electronic components, logical circuits, memories, software codes, firmware codes, etc., or any combination thereof. Figure 1-Figure 9 The features discussed may be implemented via dedicated processor circuits, via executable instructions, and / or a combination thereof.

[0110] As used herein, various terms are only for the purpose of describing a particular implementation and are not intended to be a limitation on the implementation. For example, as used herein, ordinal numbers (e.g., "first," "second," "third," etc.) used to modify elements (such as structures, components, operations, etc.) do not themselves indicate any priority or order of the element relative to another element, but instead only distinguish the element from another element with the same name (but for the purpose of using ordinal numbers). The term "coupled" is defined as connected, but not necessarily directly, and not necessarily mechanically; the two items "coupled" can be integral to each other. The terms "one" and "an" are defined as one or more, unless otherwise expressly required by the present disclosure. The term "substantially" is defined as generally but not necessarily completely specified content, and includes specified content; for example, substantially 90 degrees includes 90 degrees, and substantially parallel includes parallel, as understood by those of ordinary skill in the art. In any disclosed embodiment, the term "substantially" may be substituted for the specified content with "within [percentage] of...", where percentages include 0.1 percent, 1 percent, 5 percent, and 10 percent; and the term "approximately" may be substituted for "within 10 percent of the specified content." The phrase "and / or" means and or. For illustration, A, B, and / or C includes: A alone, B alone, C alone, a combination of A and B, a combination of A and C, a combination of B and C, or a combination of A, B, and C. In other words, "and / or" is used as an inclusive or. In addition, the phrase "A, B, C, or a combination thereof" or "A, B, C, or any combination thereof" includes: A alone, B alone, C alone, a combination of A and B, a combination of A and C, a combination of B and C, or a combination of A, B, and C.

[0111] The terms "comprise" and any form thereof (such as "comprises" and "comprising"), "have" and any form thereof (such as "has" and "having"), and the term "include" and any form thereof (such as "includes" and "including") are open linking verbs. As a result, a device that "comprises," "has," or "includes" one or more elements possesses those one or more elements, but is not limited to possessing only those elements. Similarly, a method that "comprises," "has," or "includes" one or more steps possesses those one or more steps, but is not limited to possessing only those one or more steps.

[0112] Any implementation of any of the devices, systems and methods may consist of or consist essentially of the following rather than include / comprise / have the following: any of the described steps, elements and / or features. Therefore, in any claim, the term "consisting of" or "consisting essentially of" may replace any open-ended linking verb recited above in order to change the scope of a given claim from the situation where the open-ended linking verb is used. In addition, it will be understood that the term "wherein" can be used interchangeably with "wherein".

[0113] In addition, a device or system configured in a particular manner is configured in at least that manner, but it may also be configured in other ways other than those specifically described. Even if not described or illustrated, aspects of one example may also be applied to other examples, unless explicitly prohibited by the nature of this disclosure or the particular example.

[0114] Those skilled in the art will also recognize that the various illustrative logical blocks, modules, circuits, and algorithm steps (e.g., Figure 1-Figure 9 The logic blocks in the embodiment of the present invention can be implemented as electronic hardware, computer software or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits and steps have been described above in general terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. The technician can implement the described functionality in a manner that varies for each specific application, but such implementation decisions should not be understood as causing a departure from the scope of the present disclosure. The technician will also easily recognize that the order or combination of the components, methods, or interactions described herein are merely examples, and the components, methods, or interactions of various aspects of the present disclosure can be combined or performed in a manner other than the manner described and described herein.

[0115] The various illustrative logical blocks, modules, and circuits described in conjunction with the disclosure herein may be implemented or performed using a general purpose processor, a digital signal processor (DSP), an ASIC, a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in an alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0116] The steps of the method or algorithm described in conjunction with the disclosure herein can be directly embodied in hardware, in a software module operated by a processor, or in a combination of the two. The software module can reside in any other form of a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM, or a storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. In an alternative, the storage medium can be integrated into the processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In an alternative, the processor and the storage medium can reside as discrete components in a user terminal.

[0117] In one or more exemplary designs, the functions described can be implemented in hardware, software, firmware or any combination thereof. If implemented in software, the functions can be stored on a computer-readable medium or transmitted by a computer-readable medium as one or more instructions or codes. Computer-readable media include both computer storage media and communication media, and the communication media include any medium that promotes the transmission of a computer program from one place to another. Computer-readable storage media can be any available medium that can be accessed by a general or special-purpose computer. By way of example and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, or can be used to carry or store any other medium of a desired program code unit in the form of an instruction or data structure and can be accessed by a general or special-purpose computer or a general or special-purpose processor. In addition, the connection can be appropriately named as a computer-readable medium. For example, if the software is transmitted from a website, a server or other remote source using a coaxial cable, an optical fiber cable, a twisted pair, or a digital subscriber line (DSL), the coaxial cable, the optical fiber cable, the twisted pair, or the DSL are included in the definition of the medium. Disks and optical disks as used herein include compact disks (CDs), laser disks, optical disks, digital versatile disks (DVDs), hard disks, solid-state disks, and blue-ray disks, wherein disks typically reproduce data magnetically, while optical disks reproduce data optically using lasers. The combination of the above should also be included within the scope of computer-readable media.

[0118] The above description and examples provide a complete description of the structure and use of illustrative implementations. Although certain embodiments have been described above with some degree of particularity or with reference to one or more individual examples, those skilled in the art will be able to make many changes to the disclosed implementations without departing from the scope of the present invention. Therefore, the various illustrative implementations of the present method and system are not intended to be limited to the specific forms disclosed. Instead, they include all modifications and alternatives that fall within the scope of the claims, and other examples other than the examples shown may include some or all of the features of the depicted examples. For example, elements may be omitted or combined into a single structure, and / or connections may be replaced. In addition, where appropriate, any aspect of the examples described above may be combined with any aspect of the other examples described to form other examples with comparable or different properties and / or functions and to solve the same or different problems. Similarly, it will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several implementations.

[0119] The claims are not intended to include, and should not be interpreted as including, means-plus-function or step-plus-function limitations unless such limitations are expressly recited in a given claim using the phrase(s) “means for” or “step for” respectively.

[0120] Although the various aspects of the present disclosure and its advantages have been described in detail, it should be understood that various changes, substitutions and modifications can be made herein without departing from the spirit of the present disclosure as defined in the appended claims. In addition, the scope of the present application is not intended to be limited to the specific implementation of the process, machine, manufacture, material composition, parts, methods and steps described in this specification. As those of ordinary skill in the art will easily recognize from the present disclosure, the process, machine, manufacture, material composition, parts, methods or steps (existing or later developed) that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein can be used according to the present disclosure. Therefore, the appended claims are intended to be included in the scope of such process, machine, manufacture, material composition, parts, methods or steps.

Claims

1. A platform for controlling access to and distribution of user data, the platform comprising: a first service provider node corresponding to a first service provider among the plurality of service providers, The first service provider node is configured to store a first portion of a distributed ledger; a second service provider node corresponding to a second service provider among the plurality of service providers, The second service provider node is configured to store a second portion of the distributed ledger; as well as A user access provider UAP device configured to store permissions and metadata; The rights and metadata include control information for synchronization and sharing of user data among the plurality of service providers; wherein the first portion of the distributed ledger includes permissions and metadata granting the first service provider access to user data associated with a first group of users who use services provided by the first service provider, and wherein the first service provider node is configured to: verifying, based on a public key corresponding to a first user, a signature included in data provided by the first user to the first service provider; After successfully verifying the signature using the public key, recording the data provided by the first user into the first portion of the distributed ledger; as well as synchronizing the data provided by the first user to the second portion of the distributed ledger based on the permissions and metadata of the first portion of the distributed ledger, wherein the UAP device is configured to provide a graphical user interface to the first user, and wherein the graphical user interface provides functionality for customizing the permissions of the first user, The customization of the permissions includes at least one of the following: authorizing one or more service providers to access the data of the first user recorded in the distributed ledger, writing data to the distributed ledger on behalf of the first user, and sharing the data of the first user recorded in the distributed ledger, wherein the permission is revocable, and wherein the UAP device is configured to: receiving input from a user device associated with the first user via the graphical user interface, The input includes revoking access rights of the second service provider to at least a portion of the data of the first user; as well as transmitting a revocation message to the second service provider via a network communication link, The second service provider node is configured to clear at least the portion of the data of the first user from the second portion of the distributed ledger in response to the revocation message.

2. The platform of claim 1 , wherein each of the plurality of service providers is assigned to one of a plurality of service provider ecosystems, and the permissions and metadata authorize sharing of user data between service providers within the one service provider ecosystem.

3. The platform according to claim 1, further comprising a first wallet corresponding to the first user, wherein the first wallet is configured to store a snapshot of the data of the first user stored on the distributed ledger, and The snapshot of the data of the first user includes all of the data of the first user stored on the distributed ledger, regardless of whether different portions of the data of the first user can be shared between a particular pair of service provider nodes.

4. The platform of claim 1 , wherein at least one of the plurality of service providers is designated as a custodial service provider, Wherein the custodial service provider is configured to facilitate synchronization of data among a group of service providers among the plurality of service providers based on the permissions and the metadata.

5. The platform of claim 1 , wherein data is stored on the distributed ledger on a per-user and per-data type basis such that the data of the first user is maintained on the distributed ledger in one or more data transaction sequences that are separate from data transaction sequences associated with user data of other users.

6. A method for permission-based management of user data via a distributed ledger, the method comprising: A set of permissions for the first user is configured by a user access provider UAP device, The set of permissions is configured to grant or deny access to the first user's data by a plurality of service providers; The UAP device stores the public key in a memory, The public key corresponds to a private key associated with the first user; transmitting, by the UAP device, the permission data to a group of service providers among the plurality of service providers, the permission data comprising permissions associated with sharing data of the first user among the set of service providers; receiving, by the UAP device, an authentication request from a first service provider in the group of service providers, the authentication request corresponds to a request to authenticate the first user as a source of data provided to the first service provider device; determining, by the UAP device based on the public key, whether the first user is the source of the data, wherein the first user uses a private key corresponding to the public key to sign data provided to the plurality of service providers; The UAP device transmits an authorization response to the first service provider device, wherein the authorization response authorizes storage of the data in a portion of the distributed ledger maintained by the first service provider based on the first user being determined to be the source of the data, and wherein the data is synchronized to other portions of the distributed ledger maintained by other service providers in the set of service providers based on the permission data; The UAP device receives a permission revocation message from the first user, The permission revocation message revokes the first service provider's access to at least a portion of the first data recorded on the distributed ledger by the first service provider node; The UAP device transmits a revocation notification to the first service provider node, The revocation notification is configured to inform the first service provider that access by the first service provider to at least the portion of the first data has been revoked by the first user, and Wherein the revocation notification is configured to purge at least the portion of the first data from the portion of the distributed ledger maintained by the first service provider.

7. The method of claim 6, wherein at least the portion of the first data is not cleared from the plurality of portions of the distributed ledger maintained by the other service providers.

8. The method of claim 6, wherein data is stored on the distributed ledger on a per-user and per-data type basis, such that data provided by different users is maintained on the distributed ledger in different data transaction sequences.

9. The method of claim 6, wherein clearing at least the portion of the first data comprises: A sequence of data transactions including at least the portion of the first data is cleared from the portion of the distributed ledger maintained by the first service provider node.

10. The method of claim 6, wherein each of the plurality of service providers is assigned to one service provider ecosystem among a plurality of service provider ecosystems, and the permission data authorizes sharing of user data between service providers within the one service provider ecosystem.

11. The method according to claim 6, further comprising: receiving, by the UAP device, an access request message from a third service provider among the plurality of service providers, wherein the access request message is received in response to the first user registering for a service provided by the third service provider; The UAP device transmits the additional permission data to the third service provider, The additional permission data authorizes the third service provider to store, access and share data provided by the first user according to at least one additional service provider among the plurality of service providers.

12. A non-transitory computer-readable storage medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations for permission-based management of user data via a distributed ledger, the operations comprising: receiving a registration request at a service provider device, the registration request including information associated with user registration for a service provided by a service provider corresponding to the service provider device; transmitting an access request to a user access provider UAP device based on the registration request; In response to the access request, receiving a set of permissions from the UAP device, The set of permissions authorizes one or more actions that the service provider can perform with respect to the data provided by the user; receiving first data from the user via the service, The first data includes user data and a signature; authenticating the user as a source of the first data based on the signature; storing the first data in a portion of the distributed ledger maintained by the first service provider node based on the verification, The first service provider node corresponds to the service provider, and The portion of the distributed ledger corresponds to a sequence of data transactions specific to the user; and synchronizing the first data to one or more other service provider nodes based on the set of permissions; receiving second data from the user via the service, The second data comprises changes to the first data stored on the distributed ledger; verifying the second data; as well as In response to verifying the second data, storing the second data in the sequence of data transactions specific to the user; updating the state associated with the first data as a historical state, The history status indicates that at least a portion of the first data is stale; and assigning a state to the second data, wherein the state assigned to the second data is a current state and indicates that the second data is not stale; receiving a revocation notification from the UAP device, The revocation notification is configured to indicate that permission for the first service provider to access at least a portion of the first data has been revoked by the user, and At least the portion of the first data is cleared from the portion of the distributed ledger maintained by the first service provider node.

13. The non-transitory computer-readable storage medium of claim 12, wherein the purging does not remove at least the portion of the first data from the one or more other service provider nodes.

14. The non-transitory computer-readable storage medium of claim 12, wherein the set of permissions includes a public key associated with the user, and the signature is verified based on the public key.

Images