Managing permissions for access to user data in a distributed ledger trust network

Abstract

Mechanisms for managing permissions to access user data in a distributed ledger trust network ("DLTN") are described. A given user can share access to user data in a fine-grained manner. Access to user data can depend on the category of the user data and / or the role of another user (e.g., whether the other user is identified as connected). Access to user data can be limited in duration. Permission to access user data can be set proactively or reactively. A protocol allows potential reviewers to request access to a given user's user data, where the given user selectively approves or denies access by the reviewer. In this way, a given user can control access to user data in the DLTN, thereby selectively granting (or revoking) access to some of the user data or all of the user data by selected other users or by all other users.

Description

[0001] Related application information

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 760,789, filed on November 13, 2018, the disclosure of which is incorporated herein by reference. Technical Field

[0003] Enhancements to the Distributed Ledger Trust Network (“DLTN”). Some of these enhancements relate to mechanisms for managing access to user data in the DLTN. Background Art

[0004] Blockchain technology has been used in contexts such as banking, cryptocurrency exchanges, and smart contracts. In general, blockchain technology provides a distributed ledger that records transactions in a verifiable, permanent manner. The blockchain can be distributed across a network of computer systems called nodes. The nodes follow a protocol for communicating between nodes, adding new blocks to the blockchain, and approving ("validating") new blocks.

[0005] Typically, a blockchain is a list of dynamically growing records in a chain, called blocks. A given block is logically linked to a previous block in the blockchain. For example, by applying a cryptographic hash function to the data of a previous block, a hash value is calculated, and the hash value is stored in a given block. A given block also includes other fields, such as a timestamp and payload data (sometimes referred to as transaction data). The payload data typically represents one or more transactions, but more generally can be any kind of data. Typically, once a given block is added to the blockchain, the data in the given block cannot be modified later because any subsequent blocks depend on the data in the given block. (To retroactively change the data in a given block, subsequent blocks in the blockchain must also be changed, which requires a consensus level that is impossible or impractical within the blockchain network.) The integrity of the blockchain can be verified by recalculating the hash values ​​for the corresponding blocks in the blockchain and comparing these recalculated hash values ​​with the previously calculated hash values ​​that logically link these blocks.

[0006] In some cases, multiple blocks may be generated simultaneously and added to the same previous block in the blockchain. This temporarily creates a fork in the blockchain. The nodes of the blockchain network follow a protocol to rank ("score") the different branches of the fork so that one of the branches (with the highest score) is followed by all nodes. In this way, the size of non-preferred branches of the blockchain is limited. Nodes supporting the blockchain share versions of the blockchain, and the version with the highest score is retained. Various incentives are implemented to reduce the likelihood that a version of the blockchain will be superseded the longer it is used.

[0007] By storing the blockchain across the nodes of the blockchain network, the risk of data loss associated with storing data in a single centralized location is mitigated. Depending on the implementation, each node in the blockchain network can store a full or partial copy of the blockchain.

[0008] In a public blockchain (also known as a permissionless blockchain), the blocks of the blockchain are accessible to participants in the blockchain network without permission. Any participant in the blockchain network can access blocks in the blockchain, verify blocks of the blockchain, add new blocks to the blockchain, and validate new blocks of the blockchain. Access control is not used in public blockchains. In contrast, in a private blockchain (also known as a permissioned blockchain), a central authority controls access to the blockchain network. That is, the central authority controls which participants can: access blocks in the blockchain, verify blocks of the blockchain, add new blocks to the blockchain, and validate new blocks of the blockchain.

[0009] In previous approaches to implementing private blockchains, a given user can add data about the given user to the blockchain. For example, the user data can be biographical information about the given user or data about transactions to which the given user is a party. However, the given user has very limited options regarding controlling other users' access to the given user's user data in the blockchain, which can result in the given user's user data being exposed in a manner inconsistent with the given user's expectations. Summary of the invention

[0010] In summary, the specific embodiments propose various innovations for managing permissions to access user data in a distributed ledger trust network ("DLTN"). Using such innovations, a given user can share access to a given user's user data (e.g., biographical data, contact data, identification documents, transaction data, etc.) in a fine-grained manner. For example, access to user data can depend on the category of the user data. Or, as another example, access to user data can depend on the role of another user (e.g., whether the other user is identified as a connection of the given user). Further, access to user data can be limited in duration so that permission to access user data expires after a certain period of time. A given user can proactively set permission to access user data, or a given user can reactively set permission to access user data. For example, a protocol is described that allows a potential reviewer to request access to a given user's user data, where the given user selectively approves or denies the reviewer's access through any of a variety of channels. In this way, in some example implementations, a given user can control access to the given user's user data in the DLTN, thereby selectively granting (or revoking) access to some or all of the user data by selected other users or all other users.

[0011] The innovations described herein include, but are not limited to, those covered by the claims. The innovations may be implemented as part of a method, as part of a computer system configured to perform the method, or as part of a non-transient computer-readable medium storing computer executable instructions, which are used to cause one or more processors in a computer system to perform the method. Various innovations may be used in combination or individually. The present disclosure is provided to introduce some concepts in a simplified form, which are further described below in the detailed description. The present disclosure is not intended to identify the key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. The foregoing and other purposes, features and advantages of the present invention will become more apparent through the following detailed description, which continues to refer to the accompanying drawings and illustrates many examples. The examples may also be used for other and different applications, and some details may be modified in various aspects without departing from the spirit and scope of the disclosed innovation. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The following drawings illustrate some features of the disclosed innovation.

[0013] Figure 1 is a diagram illustrating an example computer system in which some of the described examples may be implemented.

[0014] Figure 2 is a diagram illustrating an example blockchain.

[0015] Figure 3 is a diagram illustrating an example architecture for managing a private blockchain in a DLTN.

[0016] Figure 4 It is illustrated in Figure 3 Diagram of an example architecture for authentication services and encryption / decryption services used in the architecture of .

[0017] Figure 5a and Figure 5b is a flow chart illustrating various aspects of a generalized technique for updating permission settings for user data for a given user in a DLTN.

[0018] Figure 6 is a protocol diagram illustrating an example method for updating permission settings for user data for a given user in a DLTN.

[0019] Figures 7a to 7e is a flow chart illustrating various aspects of a generalized technique for requesting and approving access to user data for a given user in a DLTN.

[0020] Figure 8a and Figure 8b is a protocol diagram illustrating an example method of requesting and approving access to user data for a given user in a DLTN.

[0021] Figure 9a and Figure 9b is a flow chart illustrating various aspects of a generalized technique for revoking access to user data for a given user in a DLTN.

[0022] Fig.10 is a protocol diagram illustrating an example method for revoking access to user data for a given user in a DLTN.

[0023] Figures 11a to 11j is a diagram of example screen shots illustrating different features of managing permission settings for user data for a given user in a DLTN. DETAILED DESCRIPTION

[0024] DETAILED DESCRIPTION Various innovations are proposed for a distributed ledger trust network ("DLTN"). Some of the innovations described herein relate to mechanisms for managing permissions to access user data in a DLTN.

[0025] In the examples described herein, the same reference numerals in different figures indicate the same components, modules or operations. More generally, various alternatives to the examples described herein are possible. For example, by changing the order of the described method actions, by splitting, repeating or omitting certain method actions, etc., some methods in the methods described herein can be changed. Various aspects of the disclosed technology can be used in combination or individually. Some of the innovations described herein solve one or more of the problems mentioned in the background. Generally, a given technology / tool ​​cannot solve all such problems. It is to be understood that other examples can be utilized, and without departing from the scope of the present disclosure, structural, logical, software, hardware and electrical changes can be made. Therefore, the following description should not be considered restrictive. Specifically, the scope of the present invention is defined by the appended claims.

[0026] I. Example Computer System

[0027] Figure 1 A generalized example of a suitable computer system (100) is illustrated in which many of the described innovations may be implemented. The innovations described herein relate to enhancements to a DLTN. Other than for use in a DLTN, the computer system (100) is not intended to suggest any limitation to the scope of use or functionality, as the innovations may be implemented in a variety of computer systems, including specialized computer systems suitable for operation in a DLTN.

[0028] Reference Figure 1 , the computer system (100) includes one or more processing cores (110...11x) of a central processing unit ("CPU") and local on-chip memory (118). The processing core(s) (110...11x) execute computer executable instructions. The number of processing core(s) (110...11x) depends on the implementation and may be, for example, 4 or 8. The local memory (118) may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two, which is accessible by the corresponding processing core(s) (110...11x).

[0029] The local memory (118) may store software (180) in the form of computer executable instructions that implement innovative tools for DLTN for operations performed by the corresponding processing core(s) (110...11x). Figure 1 In the present invention, the local memory (118) is an on-chip memory such as one or more caches, to which access operations, transfer operations, etc. by (multiple) processing cores (110...11x) are fast.

[0030] The computer system (100) may include a processing core (not shown) of a graphics processing unit (“GPU”) and local memory (not shown). Alternatively, the computer system (100) includes one or more processing cores (not shown) of a system on a chip (“SoC”), an application specific integrated circuit (“ASIC”), or other integrated circuit, and associated memory (not shown). The processing core(s) may execute computer executable instructions for one or more innovations for the DLTN.

[0031] More generally, the term "processor" may refer to any device that can process computer-executable instructions, and may include microprocessors, microcontrollers, programmable logic devices, digital signal processors, and / or other computing devices. The processor may be a CPU or other general purpose unit, however, it is also known to provide a dedicated processor using, for example, an ASIC or a field programmable gate array ("FPGA").

[0032] The term "control logic" may refer to a controller or more generally one or more processors operable to process computer-executable instructions, determine results, and generate outputs. Depending on the implementation, the control logic may be implemented by software executable on a CPU, by software controlling dedicated hardware (e.g., a GPU or other graphics hardware), or by dedicated hardware (e.g., in an ASIC).

[0033] The computer system (100) includes a shared memory (120), which may be a volatile memory (e.g., RAM), a non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two, accessible by the processing core(s). The memory (120) stores software (180) in the form of computer executable instructions that implement one or more innovative tools for the DLTN for the operations performed. Figure 1 In the embodiment, the shared memory (120) is an off-chip memory, and the access operation and transfer operation of the processing core to the shared memory (120) are relatively slow.

[0034] The computer system (100) includes one or more network adapters (140). As used herein, the term network adapter refers to any network interface card ("NIC"), network interface, network interface controller, or network interface device. (Multiple) network adapters (140) support communication with another computing entity (e.g., server, other computer system) over a network. The network may be a wide area network, a local area network, a storage area network, or other network. (Multiple) network adapters (140) may support wired connections and / or wireless connections for use with wide area networks, local area networks, storage area networks, or other networks. (Multiple) network adapters (140) communicate data (such as computer executable instructions, audio or video input or output, or other data) over (multiple) network connections using modulated data signals. A modulated data signal is a signal that sets or changes one or more of its characteristics in such a way that the information in the signal is encoded. By way of example and not limitation, a network connection may use electrical, optical, RF, or other carriers.

[0035] The computer system (100) also includes one or more (plurality) input devices (150).

[0036] The input device(s) may be a touch input device (such as a keyboard, mouse, pen, or trackball), a scanning device, or another device that provides input to the computer system (100). The computer system (100) may also include video input, audio input, motion sensor / tracker input, and / or game controller input.

[0037] The computer system (100) includes one or more output devices (160). The output device(s) (160) may be a printer, a CD recorder, a video output, an audio output, or another device that provides output from the computer system (100).

[0038] The storage device (170) may be removable or non-removable and includes magnetic media (such as disks, tapes, or cassettes), optical media, and / or any other media that can be used to store information and can be accessed within the computer system (100). The storage device (170) stores instructions for software (180) that implements one or more innovations for DLTN.

[0039] An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computer system (100). Typically, operating system software (not shown) provides an operating environment for other software executed in the computer system (100) and coordinates the activities of the components of the computer system (100).

[0040] Figure 1The computer system (100) is a physical computer system. A virtual machine may include Figure 1 Components are organized as shown.

[0041] The term "application" or "program" may refer to software, such as any user mode instructions for providing functionality. The software of an application (or program) may also include instructions for an operating system and / or device driver. The software may be stored in an associated memory. The software may be, for example, firmware. Although it is contemplated that a properly programmed general-purpose computer or computing device may be used to execute such software, it is also contemplated that hard-wired circuitry or custom hardware (e.g., ASIC) may be used in place of, or in combination with, software instructions. Therefore, the examples are not limited to any particular combination of hardware and software.

[0042] The term "computer-readable medium" refers to any medium that participates in providing data (e.g., instructions) that can be read by a processor and accessed within a computing environment. Computer-readable media can take many forms, including but not limited to non-volatile media and volatile media. Non-volatile media include, for example, optical or magnetic disks and other persistent memories. Volatile media include dynamic random access memory ("DRAM"). Common forms of computer-readable media include, for example, solid-state drives, flash drives, hard disks, any other magnetic media, CD-ROMs, digital versatile disks ("DVDs"), any other optical media, RAM, programmable read-only memory ("PROM"), erasable programmable read-only memory ("EPROM"), USB memory sticks, any other memory chip or cartridge, or any other medium from which a computer can read. The term "computer-readable memory" specifically excludes transient propagation signals, carrier waves, and waveforms or other intangible or transient media, although they can be read by a computer. The term "carrier wave" may refer to an electromagnetic wave that is modulated in amplitude or frequency to convey a signal.

[0043] Innovation can be described in the general context that computer executable instructions are executed in a computer system on a target real or virtual processor. Computer executable instructions may include instructions executable on a processing core of a general-purpose processor to provide functionality described herein, instructions executable to control a GPU or dedicated hardware to provide functionality described herein, instructions executable on a processing core of a GPU to provide functionality described herein, and / or instructions executable on a processing core of a dedicated processor to provide functionality described herein. In some implementations, computer executable instructions may be organized in program modules. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules may be combined or split between program modules as desired. Computer executable instructions for program modules may be executed in a local or distributed computer system.

[0044] Many examples are described in the present disclosure and are presented for illustrative purposes only. The examples described are not restrictive in any sense and are not intended to be restrictive. As is apparent from the present disclosure, the innovation currently disclosed can be widely applied to many contexts. Those of ordinary skill in the art will recognize that the disclosed innovation can be put into practice with various modifications and changes (such as structural, logical, software and electrical modifications). Although the specific features of the disclosed innovations can be described with reference to one or more specific examples, it should be understood that, unless otherwise expressly specified, such features are not limited to the usage in one or more specific examples to which they are described with reference. The present disclosure is neither a literal description of all examples nor a list of features of the present invention that must exist in all examples.

[0045] When an ordinal number (such as "first", "second", "third", etc.) is used as an adjective before a term, (unless otherwise expressly specified) the ordinal number is used only to indicate a specific feature, such as to distinguish the specific feature from another feature described by the same or similar terms. The mere use of the ordinal numbers "first", "second", "third", etc. does not indicate any physical order or position, any temporal order, or any ranking of importance, quality, etc. In addition, the mere use of an ordinal number does not define a numerical limitation on the feature identified by the ordinal number.

[0046] When introducing an element, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements.

[0047] When a single device, component, module or structure is described, multiple devices, components, modules or structures (whether they collaborate or not) can be used instead of a single device, component, module or structure. The functionality described as being owned by a single device can be owned by multiple devices instead, whether they collaborate or not. Similarly, where multiple devices, components, modules or structures are described in this article, whether they collaborate or not, a single device, component, module or structure can be used instead of multiple devices, components, modules or structures. The functionality described as being owned by multiple devices can be owned by a single device instead. Typically, a computer system or device can be local or distributed, and can include any combination of dedicated hardware and / or hardware with software that implements the functionality described herein.

[0048] Further, the techniques and tools described herein are not limited to the specific examples described herein. Rather, the corresponding techniques and tools can be utilized independently and separately from other techniques and tools described herein.

[0049] Devices, components, modules or structures that communicate with each other do not need to communicate with each other continuously unless otherwise explicitly specified. Instead, such devices, components, modules or structures only need to transmit to each other when necessary or desired, and can actually suppress exchanging data most of the time. For example, a device that communicates with another device via the Internet may not transmit data to the other device for weeks at a time. In addition, devices, components, modules or structures that communicate with each other can communicate directly or indirectly through one or more intermediaries.

[0050] As used herein, the term "send" means any way of conveying information from one device, component, module or structure to another device, component, module or structure. The term "receive" means any way of obtaining information from another device, component, module or structure at a device, component, module or structure. Device, component, module or structure can be part of the same computer system or different computer systems. Information can be passed by value (for example, as a parameter of a message or function call), or passed by reference (for example, in a buffer). Depending on the context, information can be directly transmitted or communicated through one or more intermediate devices, components, modules or structures. As used herein, the term "connected" means an operable communication link between a device, component, module or structure, which can be part of the same computer system or different computer systems. An operable communication link can be a wired or wireless network connection, which can be direct or through one or more intermediaries (for example, of a network).

[0051] The description of an example with multiple features does not imply that all or even any of such features are required. Instead, various optional features are described to illustrate multiple possible examples of the innovation described herein. Unless otherwise explicitly specified, no feature is necessary or required.

[0052] In addition, although process steps and phases can be described in a sequential order, such a process can be configured to work in a different order. The description of a specific sequence or order does not necessarily indicate that the step / phase is required to be performed in this order. The step or phase can be performed in any practical order. In addition, although described or implied as non-simultaneous occurrence, some steps or phases can be performed simultaneously. Describing a process as including multiple steps or phases does not imply that all or any steps or phases in the step or phase are necessary or required. Various other examples can omit some or all steps or phases in the described steps or phases. Unless otherwise clearly specified, no step or phase is necessary or required. Similarly, although a product can be described as including multiple aspects, qualities or characteristics, this does not mean that all of them are necessary or required. Various other examples can omit some or all aspects, qualities or characteristics in these aspects, qualities or characteristics.

[0053] An enumerated listing of items does not imply that any or all of those items are mutually exclusive, unless expressly specified otherwise. Likewise, an enumerated listing of items does not imply that any or all of those items are comprehensive for any category, unless expressly specified otherwise.

[0054] For purposes of illustration, the detailed description uses terms such as "determine" and "select" to describe computer operations in a computer system. These terms represent operations performed by one or more processors or other components in a computer system and should not be confused with actions performed by humans. The actual computer operations corresponding to these terms vary depending on the implementation.

[0055] II. Example Blockchain

[0056] Figure 2 An example blockchain (200) is shown, which is simplified for illustration. The blockchain (200) can be replicated between different nodes of the blockchain network. Each of the nodes can store a full or partial copy of the blockchain (200). The blockchain (200) includes a plurality of blocks, starting with a root block and growing dynamically as blocks are added to the blockchain. Each of the blocks includes a header and payload data.

[0057] The header of a block includes a plurality of fields. With the exception of the root block, the header includes a hash value that is a hash value calculated by applying a cryptographic hash function to the data of a previous block in the blockchain (200). In this manner, a given block is logically linked to a previous block in the blockchain. For example, the hash value of block 1 is calculated by applying a cryptographic hash function to the data of the root block, the hash value of block 2 is calculated by applying a cryptographic hash function to the data of block 1, and so on. The integrity of the blockchain (200) can be verified by recalculating hash values ​​for corresponding blocks in the blockchain (200) and comparing these recalculated hash values ​​to the previously calculated hash values ​​(in the header) that logically link these blocks. In this manner, payload data in the blockchain (200) can be verified.

[0058] The header of the chunk also includes a timestamp and a user identifier ("ID") of the user associated with the chunk (e.g., the owner of the payload data). Other fields of the header depend on the implementation and are not shown for simplicity. For example, these fields may include a key ID that identifies the encryption key used to encrypt the payload data in the chunk and a category ID that identifies the category of the payload data in the chunk. In general, the fields of the header depend on the rules defined for the DLTN.

[0059] The blockchain (200) is used as a primary storage device for various types of data. The blockchain (200) can be shared - there is no central database that always stores data, and there is no central administrator who owns and controls the data. Payload data (sometimes called transaction data) is arbitrary data. In some blocks of the blockchain (200), the payload data is user data for a user (e.g., for one or more transactions, contact data, biographical data, identification documents), where the user data can include static data and / or dynamic data. In some other blocks of the blockchain (200), the payload data is a permission setting, which can be set as explained in Sections III and IV. More generally, payload data can be any kind of data.

[0060] exist Figure 2 In the example of , the payload data in a given block is "owned" by the user specified by the user ID in the given block. The permission settings for a user are used to control access to the user data of the user, and the permission settings can be stored in a file such as Figure 2The payload data in the blockchain (200) may be encrypted by a user-specific (for the respective owner of the payload data) and context-specific (e.g., depending on access privileges) encryption key. Thus, the blockchain (200) may include different encrypted versions of the same payload data, which may be accessible to different groups of users.

[0061] Because cryptographic hash functions are applied successively to compute hash values ​​that logically link blocks in the blockchain (200), a block depends on data (including hash values) of earlier blocks in the blockchain (200). Typically, once a block is added to the blockchain (200), the data in the block cannot be modified later. In order to retroactively change the data in a block, subsequent blocks in the blockchain must also be changed, which requires a level of consensus within the blockchain network that is impossible or impractical to achieve.

[0062] In some cases, multiple blocks may be generated simultaneously and added to the same previous block in the blockchain (200). Figure 2 In , block 2 and block 3 are generated simultaneously and added from block 1 of blockchain (200). This temporarily creates a fork in blockchain (200). A protocol is followed to rank ("score") the different branches of the fork so that all nodes follow the one branch (with the highest score). Figure 2 In the example, block 2 has a higher score than block 3, so subsequent blocks are added from block 2. Nodes in the blockchain network share versions of the blockchain (200), and the version with the highest score is retained. Various incentives are implemented to reduce the likelihood that a version of the blockchain (200) will be replaced as it is used longer.

[0063] In many of the examples described herein, the blockchain is a private permissioned blockchain. However, in some examples, the blockchain may instead be a public blockchain.

[0064] To keep it simple, Figure 2 A blockchain (200) is shown in which all blocks are logically linked in a single chain (e.g., using hash values ​​for the respective blocks). Alternatively, a set of separate chains of blocks may be used instead of a single blockchain, such as logically linking blocks of user data in one chain and logically linking blocks of permission settings in another chain. As used herein, the term "blockchain" or "the blockchain" includes blocks that are logically linked into one or more chains managed by a blockchain platform.

[0065] III. Example Architecture

[0066] picture Figure 3An example architecture (300) for managing a private blockchain in a DLTN is shown. In the example architecture (300), various entities are configured to communicate over a network (320) such as the Internet.

[0067] The one or more client systems (310) each include a DLTN client (312) for the DLTN. The user of the DLTN client (312) may be an individual, a small business, a large business, a bank, a non-profit organization, a government agency, or another entity. The client system (310) may be a personal computer, a laptop computer, a smartphone, or other type of computing device.

[0068] exist Figure 3 In the embodiment of the present invention, each of the one or more integrated partner systems (315) further includes a DLTN client (316) for the DLTN. Users of the integrated partner systems (315) potentially have enhanced privileges, permissions, or rights in the DLTN compared to users of the client system (310). However, for the purposes of the innovation described herein, the DLTN client (316) for the integrated partner system (315) is essentially the same as the DLTN client (312) for the client system (310). The integrated partner system (315) can be a personal computer, a laptop computer, a smart phone, or other type of computing device.

[0069] The DLTN client (312, 316) is configured to interoperate with a DLTN server (370) for DLTN via a secure connection (e.g., an SSL encrypted connection). Typically, the DLTN client (312, 316) provides a client-side user interface ("UI") to the DLTN. The DLTN client (312, 316) can make other client-side decisions and manage client-side communications. The DLTN client (312, 316) can be implemented as an independent executable file (e.g., a separate application). Alternatively, the DLTN client (312, 316) can be implemented using client-side script logic or other control logic in a Web browser environment that is executed on the client side. Alternatively, the DLTN client (312, 316) can be implemented as a set of functions of a Web browser to control client-oriented script logic executed by a DLTN server, wherein the script logic is executed at the DLTN server, but is a client-side controlled user input for navigation (e.g., click, data entry). Thus, the DLTN client (312, 316) may be implemented using conventional web browser functionality that provides a "front end" to the DLTN server's web application. In some example implementations, the DLTN client (312, 316) is implemented using conventional web browser functionality that uses JavaScript Object Notation ("JSON") to control client-facing scripts to interoperate with the DLTN. In conjunction with the DLTN server (370) actions, the DLTN client (312, 316) is configured to allow a user to perform various actions. For example, through the DLTN client (312, 316), a user can: log in to the DLTN; manage the network of connections to other users of the DLTN; engage in transactions with other users in the DLTN; add, edit, or remove user data; edit permission settings for a user's user data; request access to another user's user data; grant or revoke access to the user's user data in response to a request from another user; create a custom form to share with other users; provide data for a form shared by another user; or review, approve, reject, or take some other action on a submitted form. Specifically, the functionality of the DLTN client (312, 316) in various scenarios is described in Section IV.

[0070] One or more external service providers (390) are configured to provide services to the DLTN server (370). The external service providers (390) are configured to interoperate with the DLTN server (370) through a secure connection (eg, an SSL encrypted connection).

[0071] For example, the external service providers (390) may include one or more providers of communication services that are configured to provide programmatic access to the DLTN server (370) for functionality to make and receive phone calls, send and receive text messages via SMS or another set of protocols, or perform other communication functions. In some examples, the external service providers (390) include Twilio, Clickatell, and Nexmo. Specifically, when a request to grant access to a user's user data is denied or approved, the provider of communication services may allow the DLTN server (370) to communicate with the user via an alternative communication channel (e.g., phone calls and voice navigation menus; SMS messages).

[0072] As another example, the external service providers (390) may include one or more providers of email services that are configured to provide programmatic access to the DLTN server (370) for functionality to send and receive emails. In some example implementations, the external service providers (390) include SendGrid. Specifically, when sending a request for granting access to a user's user data, the providers of email services may allow the DLTN server (370) to communicate with the user via an alternative communication channel (e.g., email).

[0073] exist Figure 3 In the example, cloud computing services (330, 350) are hosted to provide functional services for DLTN. For example, cloud computing services (330, 350) are provided by Microsoft Azure, Google Cloud or Amazon Web Services. Figure 3 Two different providers (330, 350) for cloud computing services are shown, alternatively, a single provider or more providers can be used to host services that provide functionality for the DLTN. Alternatively, privately owned computing resources or a mix of privately owned computing resources and cloud computing services can be used to provide server-side functionality for the DLTN.

[0074] The cloud computing service (330, 350) can be configured to organize services into separate partitions, groups, etc. In this way, the cloud computing service (330, 350) can support scaling and / or replication of services. The load balancer (354) can be configured to distribute traffic and workloads across partitions.

[0075] The firewall (332, 352) can be configured to monitor and control incoming network traffic and outgoing network traffic. The firewall (332, 352) can be configured to apply various security rules to establish a barrier between the network (320) and the resources of the cloud computing service (330, 350). The cloud computing service (330, 350) can be configured to include one or more public subnets and one or more isolated (private) subnets. Typically, the public subnets are accessible to the Internet. The isolated network is not accessible through the Internet, but is instead accessible through an access control list ("ACL") or other mechanism managed by the cloud computing service (330, 350).

[0076] In some example implementations, services hosted in cloud computing services (330, 350) are deployed in "containers" or executed in virtual machines. Containers or virtual machines virtualize access to resources provided by cloud computing services (330, 350). In some example implementations, services are deployed in Docker containers, which can be distributed across different locations.

[0077] DLTN includes various dedicated nodes, which are configured to perform different services according to the rules of DLTN. For redundancy, nodes can be distributed across one or more clouds provided by cloud computing services (330, 350). For example, DLTN uses Ethereum technology, which provides a distributed computing platform and operating system based on blockchain, which may support smart contract functionality. Alternatively, DLTN uses another technology (such as Eris:db, HydraChain, Hyperledger Fabric, Iroha, Sawtooth Lake, IBM blockchain platform, Multichain, Openchain, Cardano, Quorum, Stellar, Symbiont Assembly, BigChainDB, ChainCore, Corda, Credits, Domus Tower blockchain, Elements blockchain platform). As used herein, the terms "distributed ledger trust network" and "blockchain network" are interchangeable, and the term blockchain generally indicates any record (block) account book that is logically linked.

[0078] The nodes (334, 356, 360) of the DLTN provide various services. Typically, the DLTN nodes can be configured to store (synchronize) data of the blockchain. Alternatively, the DLTN nodes can be configured to verify transactions before new blocks are added to the blockchain. (In some example implementations, blocks can be added to the blockchain without using cryptocurrency for payment. Like this, the speed and security of transactions are not affected by the potential volatility of the cryptocurrency used in the DLTN. Alternatively, the DLTN nodes can coordinate activities in the DLTN. Typically, in order to add a block to the blockchain, the DLTN node approves (verifies) the block and adds the block.

[0079] exist Figure 3 In the embodiment of the present invention, a DLTN node (356) hosted in a public subnetwork of a cloud computing service (350) provides a node discovery service. The node discovery service is used to locate nodes in the DLTN. In some example implementations, the DLTN node (356) is an Ethereum bootstrap node that provides a lightweight service for locating nodes according to a node discovery protocol. As another example, a DLTN node (360) hosted in an isolated subnetwork of a cloud computing service (350) provides an RPC service. In some example implementations, the node (360) provides an RPC service. As another example, a DLTN node (334) hosted in a public subnetwork of a cloud computing service (330) provides a node discovery service and / or an RPC service. The DLTN nodes (334, 356) in the public subnetwork communicate via encrypted data transmission through the network (320). The DLTN node (360) in the isolated subnetwork communicates with the node (356) in the public subnetwork via a connection protected by a network ACL and encryption.

[0080] In some example implementations, the DLTN nodes (334, 356, 360) are Ethereum nodes implemented using Geth. Alternatively, the nodes use another implementation of Ethereum or use another DLTN technology. In some example implementations, the DLTN nodes (334, 356, 360) are deployed in a Docker container. Alternatively, the DLTN nodes (334, 356, 360) are deployed using another virtualization technology.

[0081] The architecture (300) includes one or more DLTN servers (370). The DLTN server (370) is configured to interoperate with one or more DLTN clients (312, 316) of the DLTN via a secure connection (e.g., an SSL encrypted connection). The DLTN server (370) is also configured to interoperate with one or more external service providers (390) via a secure connection (e.g., an SSL encrypted connection). The DLTN server (370) can be implemented as a standalone executable file, a Web application (also referred to as a Web-based application), or in some other way. In some example implementations, the DLTN server (370) includes a method executable to implement an application programming interface ("API"), provide Web application functionality, make other server-side decisions, and manage control logic for server-side communications. In these example implementations, the API is designed according to the principles of representation layer state transfer ("REST") The API is designed to have a predictable resource-oriented uniform resource locator ("URL") and use HTTP response codes to indicate API errors. The API uses built-in HTTP features (such as HTTP verbs) that are generally understood by off-the-shelf HTTP clients. The API uses JSON for input and output. The web application component of the DLTN server (370) can be separated from the API component of the DLTN server (370). For example, with respect to the front-end component for interoperating with the DLTN client (312, 316), the DLTN server (370) can be implemented using a library (such as React, JavaScript library) that provides functionality for building a UI and a library (such as Redux, JavaScript library) that provides functionality for managing application state. With respect to the back-end component, the DLTN server (370) can be implemented using a runtime environment (such as NodeJS) for server-side scripts and command-line tools and a web application framework (such as Express) that provides functionality for building web applications and APIs. Alternatively, the DLTN server (370) can be implemented in some other way. In some example implementations, the DLTN server (370) is deployed in a Docker container in a cloud computing environment. Alternatively, the DLTN server (370) is deployed using another virtualization technology.

[0082] In some aspects, one or more DLTN servers (370) in the architecture (300) act as a centralized authority by mediating access to the blockchain network and other platform functions (e.g., for authentication or encryption / decryption). For example, the DLTN server (370) uses a permission mechanism to control write access to the blockchain and restrict read access to the blockchain. However, in other aspects, the DLTN server (370) does not act as a central authority. There may be multiple DLTN servers (370). Moreover, transactions between users of the DLTN do not require approval or mediation of the DLTN server (370) other than mediating access to the blockchain network or other platform functions.

[0083] The DLTN server (370) is configured to allow a user to perform various actions through the DLTN client (312, 316), as described above. Specifically, the functionality of the DLTN client (370) in various scenarios is described in Section IV.

[0084] The DLTN clients (312, 316) and DLTN servers (370) may be internationalized / localized into different languages.

[0085] The architecture (300) also includes a storage device (372) configured to store photos, attachments, and other data accessible to the DLTN server (370). Such data can be used in various operations of the DLTN. The DLTN server (370) is configured to connect to the storage device (372) via a connection protected by using a network ACL and encryption.

[0086] The authentication service (380) provides authentication services to the DLTN server (370). The encryption service (382) provides encryption / decryption services to the DLTN server (370). The DLTN server (370) connects to the authentication service (380) and the encryption service (382) via a connection protected by a network ACL and encryption. In some example implementations, the authentication service (380) and the encryption service (382) are implemented using Vault. Alternatively, the authentication service (380) and the encryption service (382) can be implemented in some other way. In some example implementations, the authentication service (380) and the encryption service (382) are deployed in a Docker container in a cloud computing environment. Alternatively, the authentication service (380) and the encryption service (382) are deployed using another virtualization technology.

[0087] The authentication service (380) and the encryption service (382) are configured to manage and apply access rules (384) (such as ACL data, policy data) and encryption keys (386) in a storage device that is accessible to the authentication service (380) and the encryption service (382) through a secure connection. The access rules (384) (e.g., ACL data, policy data) and encryption keys (386) are stored in an encrypted form in a protected (isolated) subnetwork without Internet access. In a DLTN, data is typically encrypted at rest and in transit. Typically, data in a blockchain is encrypted using user-specific and context-specific encryption keys. In transit, data can be encrypted using mechanisms provided by the connection. In some example implementations, the key storage device is implemented using Consul. Alternatively, the key storage device can be implemented in some other way.

[0088] Operation and characteristics of authentication service (380) and encryption service (382) Figure 4 The architecture (400) is further explained.

[0089] The authentication service (380) performs various operations to initialize structures and data for authentication. For example, after a threshold number of master key shares (412) are acquired, the authentication service (380) can use a set of master key shares (412) to create a master key (422). The authentication service (380) can use the master key (422) to determine an encryption key (428), which can be used to decrypt access rules (384) and user encryption keys (386). The authentication service (380) can retrieve encrypted versions of the access rules (384) and user encryption keys (386) from a persistent storage device (438) and perform a decryption operation using the encryption key (428). The decrypted access rules (384) and user encryption keys (386) are buffered in a cache (430) in a memory accessible to the authentication service (380).

[0090] When a user registers, the authentication service (380) can randomly generate a set of encryption keys for the user. The authentication service (380) can use key derivation and rotation to separate encryption contexts. If necessary, the authentication service (380) can generate additional encryption keys for users (e.g., for different subsets of users whose user data is shared, or for other different contexts). Depending on the implementation, the encryption keys for users can be organized in different ways. For example, the encryption keys for users can include a first set of one or more encryption keys for encrypting / decrypting data that is not shared (i.e., private), a second set of one or more encryption keys for encrypting / decrypting the connection shared with the user in the DLTN, and a third set of one or more encryption keys for encrypting / decrypting the data shared with everyone in the DLTN (i.e., public). In this configuration, according to the access rules (ACL, policy data, etc.) and consistent with the permission settings, the (multiple) first encryption key is not shared with other users, the (multiple) second encryption key is shared with the connection of the user in the DLTN, and the (multiple) third encryption key is shared with all users in the DLTN. (An encryption key "shared" with another user can be accessed and used by the encryption service (382) on behalf of the other user, but is not actually assigned to the other user.) Or, as another example, the encryption keys for a user may include one or more encryption keys for each different subset of users in the DLTN (e.g., a first encryption key (s) not shared with the user, a second encryption key (s) shared with a first subset of users, a third encryption key (s) shared with a second subset of users, ..., an nth encryption key (s) shared with all users). Alternatively, the encryption keys for the users may be organized in some other manner.

[0091] Typically, access to sensitive data is limited to rely on authentication, authorization, and accountability provided using the authentication service (380) and encryption service (382). Before a user receives access to encryption keys, encryption / decryption requests are checked and logged according to security policies. In operation, the authentication service (380) uses ACLs and policies to specify access by users to encryption keys owned by users and shared encryption keys. In some example implementations, the authentication service (380) operates in a "whitelist" mode. Actions are not allowed unless explicitly granted via policies. The authentication service (380) receives user credentials (424) for the user from the DLTN server (370) and authenticates the user according to access rules (e.g., ACL data, policy data). If the user is authenticated and access is granted, the authentication service (380) returns a user authentication token (426) for the user. The user authentication token (426) is associated with a list of access policies and corresponding encryption keys that can be used according to the access policies, which are also provided to the encryption service (382).

[0092] For encryption / decryption, the DLTN server (370) passes the user data (442) and the user authentication token (426) to the encryption service (382). The encryption service (382) returns the user data (444). For decryption operations, the user data (442) passed to the encryption service (382) is encrypted, and the user data (444) returned by the encryption service has been decrypted using the appropriate encryption key. For encryption operations, the user data (442) passed to the encryption service (382) is decrypted, and the user data (444) returned by the encryption service has been encrypted using the appropriate encryption key. As described in Section IV, the "user data" encrypted / decrypted by the encryption service (382) can be biographical data, contact data, transactional data, or other user data. In some example implementations, the encryption service (382) uses symmetric key encryption—the same encryption key is used for encryption and decryption of data. Alternatively, the encryption service may use asymmetric key encryption (e.g., according to a public / private key protocol). IV. Example Management of Permission Settings for User Data in a Blockchain

[0093] This section describes various aspects of managing permission settings for user data in a blockchain in a DLTN. In some example implementations, the innovation enables a user to own, access, monetize, and set permissions for his / her user data. The innovations described in this section can be used to support various features, including but not limited to:

[0094] ●The ability for a given user to control which categories of user data are shared;

[0095] ● The ability for a given user to control which other users can access the given user's user data, or to allow access to all users of the DLTN;

[0096] ● The ability for a given user to revoke previously granted access permissions or otherwise modify permission settings;

[0097] ● The ability for a given user to set time limits on access to the given user’s user data;

[0098] ● The ability for a given user to “go dark” (be forgotten) in the DLTN;

[0099] The ability for a given user to request access to another user's user data;

[0100] ● the ability of a given user to respond to requests from other users for access to the given user's user data; and

[0101] - The ability for a given user to allow or revoke requested permissions via a simple SMS message response.

[0102] A. Introduction

[0103] The user data of the user is stored in the blockchain. The user can be an individual, a small business, a large enterprise, a bank, a non-profit organization, or other entity. The user data may include the user's biographical data (e.g., name, education record, employment record, credit history, health record, nationality, dependents), the user's contact data (e.g., physical address, phone number, email address), the user's identification document (e.g., credentials), the user's connection in the DLTN, data about one or more transactions involving the user as a party (e.g., commercial exchange, remote purchase, fund wallet, regular purchase, cash expenditure), data about the user's assets (e.g., property records), and / or other types of data. The user data may include a geolocation tag. Typically, only one user owns the user data of the user, but for transaction data, each user participating in the transaction can have an equal and protected copy of the transaction data of the transaction.

[0104] Typically, user data in a blockchain can be indexed at the user level, organization level, or asset level. However, typically, user data is associated with the user ID of the user who wrote the user data to the blockchain (who owns the user data). For example, Figure 2As shown, a block in a blockchain includes a user ID of a user and user data supplied by the user. The association of user data with the corresponding user in the blockchain facilitates control by the user of permission to access the user data. The user data of a user is encrypted using one or more encryption keys controlled by the user, which effectively allows the user to own the user data. The encryption key can be user-specific (for the owner of the user data) and context-specific (e.g., per user group, per data category). A user can selectively share encryption keys with other users to allow other users to access the user data. Therefore, controlling access to encryption keys through permission settings can allow the user to control access to user data. In some example implementations, a block may also include a key ID and a category ID, the key ID identifying the encryption key used to encrypt the user data in the block, and the category ID identifying the category of the user data in the block.

[0105] The permissions for a user's user data may be category-restricted. That is, a user may set different permissions for different categories of a user's user data. A user who owns the user data may grant permission to access all data in the user data or only a subset of the user data. Access to different subsets of user data may be granted to different groups of other users. In some example implementations, a user who owns the user data may be presented with a checkbox per data category, which may be selected or deselected by the user to grant or revoke access to the user data of that category. For example, there are checkboxes for emails, phone numbers, addresses, transactions, education records, employment records, and assets. Alternatively, the permission settings per category may be presented to the user in some other manner.

[0106] In some example implementations, the permissions set by the user may be limited in duration. For example, the user may specify an expiration time and date. Alternatively, the user may specify a duration for which access to the user data is granted. Alternatively, the permissions set by the user have an unlimited duration—the permissions remain active until changed by the user.

[0107] Depending on the implementation, permissions for user data of a given user may be set on a per-user basis for other users of the DLTN, for any subset of users of the DLTN, for a subset of other users with a defined relationship (e.g., the user's connections) to the given user, for all users of the DLTN, or for the public. In this way, different permissions may be set for different subsets of DLTN users. Different permission management approaches (by category, by duration, by user / user set) may be used in combination. For example, in some example implementations, per-category permissions for access to user data of a given user may be set for the public, and per-category permissions may be set for connections of the given user.

[0108] When user data is shared with the public over the Internet, a DLTN server (370) may create a Web page that presents the shared user data. The user data is decrypted and the material for the Web page is cached in a memory accessible to the Web server. The DLTN server (370) may provide the URL of the Web page to the user's DLTN client (312, 316), which may share the URL. When the URL is dereferenced, the shared user data is presented as a Web page in a Web browser. If the user changes the shared user data, the Web page may be recreated and assigned the same URL or a different URL. If the user revokes access to previously shared user data, the Web page and associated material may be removed from the cache.

[0109] The user can configure the permission settings when the user joins DLTN or when the user first adds user data to the blockchain. The user can also configure the permission settings at a later time, such as driven by an event that causes the user to want to share access to user data or revoke access to user data.

[0110] As explained above, permission settings may be proactively set by a given user. Permission settings may also be reactively set by a given user in response to requests from other users to access the given user's user data.

[0111] In a DLTN, a user can request user data of another user in the DLTN. The requesting user can be a connection of the user who owns the user data. Alternatively, the requesting user can be some other user in the DLTN. The requesting user can request access to all the user data of the owner or a subset of the user data of the owner. For example, the requesting user can select one or more check boxes for different categories of requested user data.

[0112] The user who owns the user data can respond to the request through various channels. For example, if the user is logged into the DLTN client of the DLTN, the user can access a page that lists the requests to be reviewed. In addition to each request, one or more graphical elements can also indicate whether the request is approved or rejected. Alternatively, if the user is logged into the DLTN client of the DLTN, a pop-up box can be presented in the UI of the DLTN client, prompting the user to approve or reject the request.

[0113] Alternatively, the request may be reviewed through another channel. The request may be reviewed in a different channel than the channel in which the request was issued to enable multi-channel licensing of user data in the blockchain. For example, the request may be presented to the user in an SMS message. The SMS message may prompt the user to approve the request by sending a reply message via SMS, or by accessing a web page with a graphical control that can be actuated to approve the request. Or, as another example, an email may be sent to the user who owns the user data to prompt the user to approve the request (via a return email) or to log into a DLTN client to review the request.

[0114] The request may be approved or rejected as a whole. Alternatively, in some example implementations, the request may be partially approved or rejected (e.g., on a category-by-category basis). If the request (or a portion of the request) is approved, a set of smart contract algorithms may package the correct set of permissions for access. That is, permissions may be set by applying conditional logic based on the request and approval, and the updated permission settings may be stored.

[0115] The permission settings for the user data of a user may be stored and deployed in various ways. For example, the permission settings may be stored in a block of the blockchain associated with the user. That is, the permission settings are stored in the blockchain in association with the identity of the user. The permission settings may be encrypted using an encryption key shared by the user with other users of the DLTN. When another user attempts to access the user data, the permission settings may be retrieved from the blockchain (by the DLTN server on behalf of the other user), decrypted using the shared encryption key, and evaluated in conjunction with access rules, ACLs, policy rules, etc. to determine whether access is granted. If access is granted, the appropriate (multiple) shared encryption keys may be identified and communicated to the encryption service for decrypting the requested user data. If access is not granted, the request for access to the user data is denied, but a request for granting access may be sent to the owner of the user data for review. If the permission settings change, the updated permission settings may be stored in a new block of the blockchain, replacing the previous block. Thus, the currently active permissions are stored in the user's last permission settings block in the blockchain. The updated permission settings may be encrypted using the same encryption key or a different encryption key.

[0116] Alternatively, when managing access to user data in the blockchain, the permission settings may be incorporated into the ACL data, policy data, or access rules applied by the authentication service. When the user updates the permission settings, the authentication service updates the ACL data, policy data, or access rules to reflect the changes. The authentication service generates new encryption keys for the user as needed. The ACL data, policy data, or access rules are encrypted using the authentication service's common key rather than the user-specific encryption key. When another user attempts to access the user data of a given user, the permission settings may be evaluated as part of the access rules, ACLs, policy rules, etc. to determine whether access is granted. If access is granted, the appropriate (multiple) shared encryption keys may be identified and communicated to the encryption service for decrypting the requested user data. If access is not granted, the request to access the user data is denied, but a request to grant access may be sent to the owner of the user data for review.

[0117] B. Examples of operations involving permission settings for user data

[0118] Figure 5a , Figure 5b , Figure 7a , Figure 7b , Figure 9a and Figure 9b Different operations involving permission settings for user data are illustrated. Some of these operations are performed by a DLTN client, while other operations are performed by a DLTN server. Typically, a DLTN client is configured to perform various operations to interoperate with a DLTN server to access the DLTN, and the DLTN server is configured to perform various operations to provide access to the DLTN. In some example implementations, the DLTN uses Ethereum technology. Alternatively, the DLTN uses another DLTN technology.

[0119] In these examples, the user data of the user is (or will be) stored in the blockchain of the DLTN in association with the identity of the user. In some example implementations, the blockchain is a private blockchain with a DLTN server managing access to the private blockchain. Alternatively, the blockchain is a public blockchain. The blockchain includes one or more blocks. For example, a given block in a block of the blockchain includes a hash value based on one or more previous blocks in the blockchain, a key identifier, a type value, a user ID of a given user, and user data of a given user. The user data is encrypted using, for example, one of a set of encryption keys that are user-specific and context-specific. Alternatively, a given block of the blockchain includes other and / or additional fields.

[0120] In some examples, access to the user data of the user is requested. The requested user data may be all available user data in the available user data of the user. Alternatively, the requested user data may be a subset of the available user data of the user, wherein the subset includes one or more categories of user data of the user. The user data may include the user's biographical data (e.g., name, education record, employment record, credit history, health record, nationality, dependents), the user's contact data (e.g., physical address, telephone number, email address), the user's identification document (e.g., credential), the user's connection in the DLTN, data on one or more transactions involving the user as a party (e.g., commercial exchange, remote purchase, fund wallet, regular purchase, cash expenditure), data on the user's assets (e.g., property records), and / or other types of data.

[0121] The permission settings may be organized in various ways with respect to the set of users affected by the permission settings. For example, the permission settings may include a group permission setting that controls private access to user data of a user per group of one or more connected users through the DLTN. As another example, the permission settings may include individual permission settings that control private access to user data of a user per connected user through the DLTN. As another example, the permission settings may include a public permission setting that controls public access to user data of a user through the Internet.

[0122] With respect to the user data affected by the permission settings, the permission settings may be organized in various ways. For example, the permission settings may include category-specific permission settings that control the granting of access to corresponding categories of user data of a user. As another example, the permission settings may include global permission settings that control the granting of access to all user data in the user data of a user.

[0123] The permission settings may be time-limited. For example, the permission settings include one or more timed permission settings that control the granting of access to the user data of the user before an expiration time. Alternatively, the permission settings may have an unlimited duration that remains valid until changed.

[0124] In some example implementations, the DLTN client is referenced Figure 3 The DLTN client (312, 316) described herein and the DLTN server are referenced Figure 3The DLTN server (370) described herein. The DLTN server may include a web application and implement an API accessible to the DLTN client. The DLTN client may be implemented as a set of functions of a web browser to control client-oriented script logic executed by the DLTN server. The DLTN server executes in a public subnet of a cloud computing service. The DLTN server is configured to call authentication services and encryption services executed in an isolated subnet of a cloud computing service. For operations involving a blockchain of the DLTN, the DLTN server is configured to call one or more nodes of the DLTN, which are executed in an isolated subnet of a cloud computing service. Alternatively, for example, as described above with reference to Figure 3 As described, the DLTN client and / or the DLTN server are implemented in some other manner.

[0125] C. Example of Setting or Changing Permissions to Access User Data

[0126] Figure 5a A generalized technique for updating permission settings for user data for a given user in a DLTN is shown from the perspective of the given user's DLTN client (501). Figure 5b A generalized technique for updating permission settings for user data for a given user in a DLTN is shown from the perspective of a DLTN server (502).

[0127] Reference Figure 5a The DLTN client sends (510) a request for permission settings for the user data of the user to the DLTN server. Figure 5b The DLTN server receives (515) a request for permission settings for user data of the user from the DLTN client. The request may be sent / received in encrypted form over a secure connection.

[0128] The DLTN server retrieves (520) the permission settings. The permission settings may be stored in persistent storage and retrieved in various ways, as described below.

[0129] The DLTN server sends (525) the permission settings to the DLTN client. Figure 5a , the DLTN client receives (530) the permission settings from the DLTN server. The permission settings may be sent / received in encrypted form over a secure connection.

[0130] The DLTN client presents (535) the permission settings through the UI of the DLTN client. For example, the DLTN client displays a graphical control through the user interface of the DLTN client, the graphical control being operable to authorize access to the corresponding category of user data of the user.

[0131] The DLTN client receives (540) user input from the user via the UI of the DLTN client, the user input indicating one or more updates to the permission settings. For example, the update(s) to the permission settings include granting access to at least some of the user data of the user. Or, as another example, the update(s) to the permission settings include revoking access to at least some of the user data of the user.

[0132] The DLTN client sends (545) one or more updates to the permission settings to the DLTN server. Figure 5b , the DLTN server receives (550) one or more updates to the permission settings from the DLTN client. The update(s) to the permission settings may be sent / received in encrypted form over a secure connection.

[0133] Based on the one or more updates to the permission settings, the DLTN server updates (555) the permission settings. Depending on how the permission settings are stored in the persistent storage, they may be updated in various ways, as described below.

[0134] When a category of user data for a user is publicly accessible, the DLTN server may perform additional operations to make the user data available. For example, the DLTN server may create a Web page that includes any publicly accessible categories of user data for the user. The DLTN server may then send a link to the Web page to the DLTN client.

[0135] The DLTN server may perform additional operations based on the update(s) to the permission settings. Because the update may revoke access to previously accessible user data, or grant access to previously inaccessible user data, the DLTN server may change how the user data is encrypted. For example, the DLTN server may decrypt at least some of the user data of the user using a first encryption key from a set of encryption keys for the user. The DLTN server may then re-encrypt at least some of the user data of the user using a second encryption key (different from the first encryption key) from the set of encryption keys. The DLTN server may store the re-encrypted user data of the user in a new block in the blockchain.

[0136] When a user registers, permission settings can be Figure 5a and 5b In this case, the request for permission settings may be part of a request to register the user, and the update(s) to the permission settings are changes to the default initial values ​​of the permission settings. Alternatively, when the user later changes the permission settings, the permission settings may be updated as shown in FIG. Figure 5a and5b In this case, the request for the permission settings may be part of a request to review the permission settings, and the update(s) to the permission settings are changes to previously set values ​​of the permission settings.

[0137] The permission settings may be stored in an encrypted form in the blockchain of the DLTN in association with the identity of the user. In this case, the DLTN server may retrieve the permission settings by searching the blockchain for the permission settings. Alternatively, the DLTN server may retrieve the permission settings by requesting the permission settings from the DLTN's service. When the DLTN server updates the permission settings, the new version of the permission settings (or at least the updated permission settings) is stored in a new block in the blockchain.

[0138] Alternatively, the permission settings may be stored in encrypted form in a storage device accessible to the authentication service. In this case, the permission settings may be encrypted and decrypted using a master key of the authentication service. The permission settings are enforceable by the authentication service in conjunction with one or more access rules. When the DLTN server updates the permission settings, the DLTN server may change the permission settings in the storage device accessible to the authentication service.

[0139] Figure 6 An example method (600) for updating permission settings for user data of a given user in a DLTN is shown. The method includes referring to Figure 5a and 5b Some of the operations described in this document are as well as operations for user login, decryption, and encryption. Figure 6 In the illustrated example method (600), communications between the DLTN client and the DLTN server may use encrypted messages over a secure connection (e.g., an SSL connection) for the session. Permission settings and user data may be stored in encrypted form using separate encryption keys that are specific to a given user (owner of the user data) and managed by the encryption service.

[0140] To begin, in the login phase (610), the user, who is the owner of the user data, initiates (611) the login process through the UI of the DLTN client. The DLTN client provides (612) the user's credentials to the DLTN server. The DLTN server authenticates (613, 614) the user using an authentication service, which, when successful, provides the DLTN server with a user authentication token. The DLTN server sends (615) a message to the DLTN client indicating that the authentication has been successful.

[0141] In the next stage (620), permission settings for the user's user data are requested and presented. Through the UI of the DLTN client, the user requests (621) permission settings. The DLTN client sends (622) a request to the DLTN server, which retrieves (623, 624) the permission settings from the blockchain or other storage device. The permission settings may be retrieved in encrypted form, in which case the DLTN server calls (625) a cryptographic service to decrypt the permission settings. To decrypt the permission settings, the cryptographic service uses one or more appropriate user-specific encryption keys for the user (owner of the user data). The cryptographic service returns (626) the permission settings in decrypted form to the DLTN server, which sends (627) the decrypted permission settings to the DLTN client (via the secure connection for the session). The DLTN client presents (628) the permission settings through the UI of the DLTN client.

[0142] In the next stage (630), the permission settings are selectively updated. The user provides (631) user input through the UI of the DLTN client, which indicates one or more updates to the permission settings. The DLTN client sends (632) (multiple) updates to the DLTN server, and the DLTN server updates the permission settings. If the updated permission settings are stored in encrypted form, the DLTN server calls (633) an encryption service to encrypt the new permission settings, and the encryption service returns (634) the updated permission settings in encrypted form. To encrypt the permission settings, the encryption service uses one or more appropriate user-specific encryption keys for the user (owner of the user data). The DLTN server stores (635) the updated permission settings in a blockchain or other storage device.

[0143] D. Example of requesting and approving permission to access user data

[0144] Figure 7a A generalized technique (701) for requesting access to user data of a given user in a DLTN is shown from the perspective of a DLTN client of another user, who is a potential reviewer of the user data. Figure 7b A corresponding generalized technique is shown from the perspective of a DLTN server (702).

[0145] Reference Figure 7a , the DLTN client sends (710) a request from the reviewer for accessing the user data of the user to the DLTN server. Figure 7b , the DLTN server receives (715) a request from the DLTN client for accessing the user data of the user. The request may be sent / received in encrypted form over a secure connection.

[0146] The DLTN server retrieves (720) permission settings for the user. Permission settings may be stored in a persistent storage device and retrieved in various ways. For example, the permission settings may be stored in an encrypted form in the blockchain of the DLTN in association with the identity of the user. In this case, the DLTN server may retrieve the permission settings by searching the blockchain for the permission settings. Alternatively, the DLTN server may retrieve the permission settings by requesting the permission settings from the service of the DLTN. Alternatively, the permission settings may be stored in an encrypted form in a storage device accessible to the authentication service. In this case, the permission settings may be encrypted and decrypted using the master key of the authentication service. The permission settings are enforceable by the authentication service in conjunction with one or more access rules.

[0147] The DLTN server determines (725) based on the permission settings that access to the user data of the user is not granted to the reviewer. The DLTN server sends (730) to the DLTN client an indication that access to the user data of the user is not granted to the reviewer. The indication may be sent in encrypted form over a secure connection.

[0148] Reference Figure 7a , the DLTN client receives (735) an indication from the DLTN server that access to the user data of the user is not granted to the reviewer according to the permission settings for the user data of the user. In response, the DLTN client may display one or more graphical elements through the UI of the DLTN client, the one or more graphical elements indicating that access to the user data of the user is not granted. Subsequently, the DLTN client may receive user input from the reviewer through the UI of the DLTN client, the user input indicating a request for approval to access the user data of the user. The DLTN client initiates (740) a request to the user for approval to access the user data of the user. For example, the DLTN client sends an indication to the DLTN server or server messaging application that the reviewer seeks approval by the user to access the user data of the user.

[0149] Reference Figure 7b , the DLTN server receives (745) from the DLTN client an indication that the reviewer seeks approval by the user to access the user's user data. The DLTN server then sends (750) to the user's DLTN client or the user's client messaging application a request for approval by the user for the reviewer to access the user's user data. At least when sent to the user's DLTN client, the request may be sent in encrypted form over a secure connection.

[0150] Figure 7cA generalized technique for approving access to user data for a given user is shown from the perspective of the given user's DLTN client (703). Figure 7d A corresponding generalized technique is shown from the perspective of a DLTN server (704).

[0151] Reference Figure 7c , the DLTN client presents (755) through the UI of the DLTN client a request for approval by the user for the reviewer to access the user data of the user. For example, the DLTN client displays a graphical control through the user interface of the DLTN client that is operable to indicate approval or rejection of the request. The request may be received by the DLTN client from the DLTN server in encrypted form over a secure connection.

[0152] The DLTN client receives (760) input via the UI of the DLTN client indicating approval or rejection of the request.

[0153] The DLTN client sends (765) an indication of approval or rejection of the request to the DLTN server. Figure 7d The DLTN server receives (770) an indication of approval or rejection of the request from the DLTN client. The indication of approval or rejection may be sent / received in encrypted form over a secure connection.

[0154] Based on the indication, the DLTN server selectively updates the permission settings. Specifically, the DLTN server checks (775) whether the request from the reviewer is approved. If so, the DLTN server updates (780) the permission settings to provide the reviewer with the requested access to the user data of the user. Depending on how the permission settings are stored in the persistent storage device, they can be updated in various ways. For example, if the permission settings are stored in an encrypted form in the blockchain of the DLTN in association with the identity of the user, when the DLTN server updates the permission settings, the new version of the permission settings (or at least the updated permission settings) is stored in a new block in the blockchain. Alternatively, if the permission settings are stored in an encrypted form in a storage device accessible to the authentication service, when the DLTN server updates the permission settings, the DLTN server can change the permission settings in the storage device accessible to the authentication service.

[0155] The DLTN server may perform additional operations based on the indication of approving or rejecting the request. Since the approval grants access to previously inaccessible user data, the DLTN server may change how the user data is encrypted. For example, the DLTN server may decrypt at least some of the user data of the user using a first encryption key from a set of encryption keys for the user. The DLTN server may then re-encrypt at least some of the user data of the user using a second encryption key (different from the first encryption key) from the set of encryption keys. The DLTN server may store the re-encrypted user data of the user in a new block in the blockchain.

[0156] Figure 7c 1 shows operations performed by a DLTN client interoperating with a DLTN server, and Figure 7e A generalized technique (705) for approving access to user data for a given user using an alternate channel is shown. The operations of the technique (705) may be performed by a client messaging application, such as an SMS messaging application. For example, if the given user is not logged into the DLTN or does not have access to a DLTN client, the technique (705) may be performed.

[0157] To begin, the client messaging application presents (756) a request for an approved reviewer to access the user data of the user through the UI of the client messaging application. For example, the client messaging application displays a text message through the UI of the client messaging application that includes text describing the request. The text message may also include a link to a web page and / or a messaging number.

[0158] The client messaging application receives (761) user input from a user through the UI of the client messaging application, the user input indicating approval of the request. The client messaging application sends (766) an indication of approval of the request to a web server or server messaging application. For example, if the request (e.g., a text message) includes a link to a web page, the client system can launch a web browser and navigate to the web page indicated in the link, thereby notifying the web server of approval of the request. Or, as another example, if the request (e.g., a text message) includes a messaging number, the client messaging application can send a text message to the messaging number, thereby notifying the server messaging application of approval of the request.

[0159] Figure 8a and Figure 8b An example method (800) is shown for requesting and approving access to user data for a given user in a DLTN. The method includes referring to Figures 7a to 7dSome of the operations described in this document are as well as operations for user login, decryption, and encryption. Figure 8a and 8b In the illustrated example method (800), communications between the DLTN client and the DLTN server may use encrypted messages over a secure connection (e.g., an SSL connection) for the session. Permission settings and user data may be stored in encrypted form using separate encryption keys that are specific to a given user (owner of the user data) and managed by the encryption service.

[0160] Reference Figure 8a , during the reviewer's login phase (810), the reviewer initiates (811) the login process through the UI of the DLTN client. The DLTN client provides (812) the reviewer's credentials to the DLTN server. The DLTN server authenticates (813, 814) the reviewer using an authentication service, which, when successful, provides a user authentication token to the DLTN server. The DLTN server sends (815) a message to the DLTN client indicating that the authentication was successful.

[0161] In the next stage (820), the reviewer requests access to another user's user data. Through the UI of the DLTN client, the user requests (821) access to the user's user data. The DLTN client sends (822) a request to the DLTN server, which retrieves (823, 824) permission settings for the user (who owns the user data) from the blockchain or other storage device. The permission settings may be retrieved in encrypted form, in which case the DLTN server calls (825) the encryption service to decrypt the permission settings. To decrypt the permission settings, the encryption service uses one or more appropriate user-specific encryption keys for the user (the owner of the user data). The encryption service returns (826) the permission settings in decrypted form to the DLTN server, which uses the permission settings to determine whether the reviewer has access to the user's user data. (Alternatively, if the permission settings are stored directly in a storage device accessible to the authentication service, the authentication service can determine whether the reviewer has access to the user's user data.) Figure 8a and Figure 8b In the example shown, the DLTN server determines that the reviewer does not have access to the user data of the user. The DLTN server sends (827) an indication that access is not granted to the DLTN client, and the DLTN client presents (828) the indication that access is not granted on the UI of the DLTN client.

[0162] In the next stage (830), the reviewer provides (831) input through the UI of the DLTN client indicating that the reviewer seeks approval by the user for the reviewer to access the user data. The DLTN sends (832) to the DLTN server an indication that the reviewer seeks approval by the user to access the user data.

[0163] Reference Figure 8b , during the login phase (840) of the user who owns the user data, the user initiates (841) the login process through the UI of the DLTN client. The DLTN client provides (842) the user's credentials to the DLTN server. The DLTN server authenticates (843, 844) the user using an authentication service, which, when successful, provides the DLTN server with a user authentication token. The DLTN server sends (845) a message to the DLTN client indicating that the authentication has been successful.

[0164] In the next stage (850), the DLTN server sends (851) to the DLTN client a request for approval by the user for the reviewer to access the user's user data. The DLTN client presents (852) the request in the UI of the DLTN client. Through the UI of the DLTN client, the user provides (853) user input indicating whether the request is approved. The DLTN client sends (854) to the DLTN server an indication of whether the request has been approved or denied.

[0165] In the next stage (860), the permission settings are selectively updated based on an indication of whether the request has been approved or rejected. If the DLTN server no longer has permission settings for the user, the DLTN server retrieves (861, 862) the permission settings for the user (who owns the user data) from the blockchain or other storage device. The permission settings may be retrieved in an encrypted form, in which case the DLTN server calls (863) an encryption service to decrypt the permission settings. To decrypt the permission settings, the encryption service uses one or more appropriate user-specific encryption keys for the user (owner of the user data). The encryption service returns (864) the permission settings to the DLTN server in a decrypted form. The DLTN server updates the permission settings. If the permission settings are stored in an encrypted form, the DLTN server calls (865) an encryption service to encrypt the updated permission settings, and the encryption service returns (866) the updated permission settings in an encrypted form. To encrypt the permission settings, the encryption service uses one or more appropriate user-specific encryption keys for the user (owner of the user data). The DLTN server stores (867) the updated permission settings in the blockchain or other storage device. An indication of approval may be sent to the reviewer's DLTN client and presented to the reviewer. Subsequently, when the reviewer attempts to access the user's user data again (e.g. Figure 8a The access is granted as in operations 821 to 826.

[0166] E. Example of revoking permission to access user data.

[0167] Figure 9a A generalized technique for revoking access to user data for a given user in a DLTN is shown from the perspective of the given user's DLTN client (901). Figure 9b A corresponding generalized technique is shown from the perspective of a DLTN server (902).

[0168] Reference Figure 9b , the DLTN server sends (910) to the DLTN client a previously approved request from the reviewer for granting access to the user data of the user. The previously approved request may be sent / received in encrypted form over a secure connection.

[0169] Reference Figure 9a The DLTN client presents (915) a previously approved request for granting access to the user data of the user through the UI of the DLTN client. For example, the DLTN client displays a graphical control through the UI of the DLTN client, which is operable to indicate the revocation of the previously approved request.

[0170] The DLTN client receives (920) input via the UI of the DLTN client indicating a withdrawal of the previously approved request.

[0171] The DLTN client sends (925) to the DLTN server an instruction to revoke the previously approved request. Figure 9b The DLTN server receives (930) from the DLTN client an indication of revoking the previously approved request. The indication of revocation may be sent / received in encrypted form over a secure connection.

[0172] Based on the indication to revoke the previously approved request, the DLTN server updates (935) the permission settings. Depending on how the permission settings are stored in the persistent storage, they can be updated in various ways. For example, if the permission settings are stored in an encrypted form in association with the identity of the user in the blockchain of the DLTN, then when the DLTN server updates the permission settings, the new version of the permission settings (or at least the updated permission settings) is stored in a new block in the blockchain. Alternatively, if the permission settings are stored in an encrypted form in a storage device accessible to the authentication service, then when the DLTN server updates the permission settings, the DLTN server can change the permission settings in the storage device accessible to the authentication service.

[0173] Based on the indication of revoking the previously approved request, the DLTN server may perform additional operations. Since the revocation removes access to the previously accessible user data, the DLTN server may change how the user data is encrypted. For example, the DLTN server may decrypt at least some of the user data of the user using a first encryption key from a set of encryption keys for the user. The DLTN server may then re-encrypt at least some of the user data of the user using a second encryption key (different from the first encryption key) from the set of encryption keys. The DLTN server may store the re-encrypted user data of the user in a new block in the blockchain.

[0174] Fig.10 An example method (1000) is shown for revoking access to user data of a given user in a DLTN. The method comprises referring to Figure 9a and Figure 9b Some of the operations described in this document are as well as operations for user login, decryption, and encryption. Fig.10In the illustrated example method (1000), communications between the DLTN client and the DLTN server may use encrypted messages over a secure connection (e.g., an SSL connection) for the session. Permission settings and information about previous requests may be stored in encrypted form using separate encryption keys that are specific to a given user (owner of the user data) and managed by the encryption service.

[0175] To begin, in the login phase (1010), the user initiates (1011) the login process through the UI of the DLTN client. The DLTN client provides (1012) the user's credentials to the DLTN server. The DLTN server authenticates (1013, 1014) the user using an authentication service, which, when successful, provides the DLTN server with a user authentication token. The DLTN server sends (1015) a message to the DLTN client indicating that the authentication has been successful.

[0176] In the next stage (1020), previously approved requests for access to the user data are requested and presented. Through the UI of the DLTN client, the user requests (1021) a list of previously approved requests for the user's user data. The DLTN client sends (1022) a request to the DLTN server, which retrieves (1023, 1024) permission settings and previously approved requests from the blockchain or other storage device. The permission settings and previously approved requests may be retrieved in encrypted form, in which case the DLTN server calls (1025) a cryptographic service to decrypt the permission settings and previously approved requests. To decrypt the permission settings and previously approved requests, the cryptographic service uses one or more appropriate user-specific encryption keys for the user (owner of the user data). The cryptographic service returns (1026) the permission settings and previously approved requests in decrypted form to the DLTN server, which sends (1027) the decrypted previously approved requests to the DLTN client. The DLTN client presents (1028) the previously approved request through the UI of the DLTN client.

[0177] In the next stage (1030), the user provides (1031) user input through the UI of the DLTN client indicating the revocation of one of the previously approved requests. The DLTN client sends (1032) an indication of the revocation to the DLTN server, which updates the permission settings and the list of previously approved requests (to remove the revoked request). (Alternatively, the DLTN server may retrieve and decrypt the permission settings at this time, rather than retrieving them earlier). If the updated permission settings and the remaining previously approved requests are stored in encrypted form, the DLTN server calls (1033) an encryption service to encrypt the updated permission settings and the remaining previously approved requests, and the encryption service returns (1034) the updated permission settings and the remaining previously approved requests in encrypted form. To encrypt the permission settings and the remaining previously approved requests, the encryption service uses one or more appropriate user-specific encryption keys for the user (owner of the user data). The DLTN server stores (1035) the updated permission settings and remaining previously approved requests in a blockchain or other storage device.An indication of revocation may be sent to the user's DLTN client and / or the DLTN client of the user whose permission is revoked.

[0178] F. Sample Screenshots

[0179] Figures 11a to 11j is a diagram of example screenshots illustrating different features of managing permission settings for user data for a given user in a DLTN in some example implementations. Figures 11a to 11c and Figure 11e to Figure 11i , the screenshot shows a page drawn in a web browser (of a DLTN client) with graphical elements provided by a web application (of a DLTN server).

[0180] Fig.11aThe screenshot (1100) in shows the home page (1101) of the UI of the DLTN client after the user (Farmer 2) has logged in. The top row (1102) of the home page (1101) includes graphical controls (drop-down menus) that can be actuated to reach menus or pages that show the identity associated with the user, available applications, forms (defined by the user, or to be completed or reviewed by the user, or previously submitted by the user), or the user's assets. The top row (1102) also includes a graphical indicator that indicates the language of the home page and the logged-in user. Below the top row (1102), the home page (1101) includes a section for the user's profile, settings, and security. The profile section includes graphical controls that can be actuated to review and edit the user's user data (such as general information, employment history, education), or upload a document of the user's user data (such as an identification document). The security section includes graphical controls that can be actuated to review and mark permission settings for a user's user data ("Public Profile Settings"), or to review a request to share a user's user data ("Profile Sharing Request").

[0181] Fig.11b The screenshot (1110) in shows a page (1111) of the UI of the DLTN client after the user (Farmer 2) has actuated the graphical control to review and edit the permission settings. The top row (1102) and Fig.11a The same as shown. The right column (1113) provides graphical controls and information related to permission settings and sharing of user data. At the top of the right column (1113) is provided a link to a web page ("Link to your sharing profile") and a graphical control that can be used to share the link. The web page includes publicly available items of the user's user data. Below it, the right column (1113) includes check boxes that can be selected to share categories of the user's user data with the public or only with the user's connections in the DLTN. In one tab ("Internet"), check boxes can be selected to share categories of the user's user data with the public. In another tab ("Connections"), check boxes can be selected to share categories of the user's user data only with the user's connections in the DLTN. In Fig.11b, page (111) shows four categories (email, language proficiency, employment history, and transactions) that are selected to be shared with the public, and page (1111) shows the user data in these categories. Some of the user data (e.g., language proficiency, employment history) can be edited by actuating the graphical controls for that category of user data in that section. Other information (e.g., transactions) cannot be edited. The user can select or deselect check boxes to change which categories of user data are shared publicly and which categories of user data are shared with the user's connections. After making changes, the user can save the changes to the permission settings by actuating the Save button, which causes updates to the permission settings to be sent to the DLTN server.

[0182] Fig.11c The screenshot (1120) in shows another page (1121) of the UI of the DLTN client after the user (Farmer 2) has actuated the graphical control to review and edit the permission settings. Fig.11b Compared to the page (1111) shown, different categories of user data are selected for sharing. Fig.11c , the page (1121) shows two categories (identity and transaction) selected to be shared with the public and the user data in these categories. Some user data (e.g., identity) can be edited by actuating the graphical control for that category of user data in that section. Other information (e.g., transaction) cannot be edited.

[0183] Fig.11d The screenshot (1130) shown shows a web page (1131) that includes publicly available user data for a user (Farmer 2). The web page is rendered in a conventional web browser (not acting as a DLTN client), which includes, for example, an address bar (1132). Fig.11d The publicly shared user data includes email addresses, phone numbers, physical addresses, and identities.

[0184] Fig.11e The screenshot (1140) in FIG. 1 shows that after the user (Farmer 2) has actuated the graphical control to review the profile sharing request (eg Fig.11a The profile sharing request control on the home page (1101) or Fig.11b or the profile sharing request link in the right column (1113) of 11c) is displayed. The top row (1141) is the same as Figures 11a to 11c, and the like. Below the top row (1102), the page (1141) includes sections of two different profile sharing requests available for user review. One request is from user Coffee Company, and the other request is from user Ashish Gadnis. Each request lists the category of user data to be shared requested by the request, or lists an overview ("sections"). As indicated in the lower left corner, the first request (from user Coffee Company) has been previously approved. In the section for the first request, a graphical control can be actuated to open or revoke the first request. The second request (from user Ashish Gadnis) has not yet been approved. In the section for the second request, a graphical control can be actuated to approve or dismiss the second request.

[0185] Fig.11f The screenshot (1150) in shows the page (1151) of the UI of the DLTN client after the user (Farmer Two) has actuated the graphical control to review the first request (from the user coffee company). The top row (1102) and Figures 11a to 11c and Fig.11e Below the top row (1102), the page (1151) includes a section for a first profile sharing request (from the user's coffee company). The section lists the categories of user data to be shared requested by the first request. A graphical control can be actuated to revoke the first request.

[0186] Figures 11g to 11i The screenshots (1160, 1170, 1180) in generate a series of pages (1161, 1171, 1181) of the UI of the DLTN client after another user (the coffee company) has logged in. The top row (1162) of the corresponding page includes a graphical control (a drop-down menu) that can be actuated to reach a menu or page that shows the identity associated with the user, available applications, forms (defined by the user, or to be completed or reviewed by the user, or previously submitted by the user), the user's assets, requests from the user, and administrative settings. The top row (1162) also includes a graphical indicator that indicates the page (1161, 1171, 1181) language and the logged in user. Figure 11g and 11h The pages (1161, 1171) shown show the user's connection (Farmer Juan) and the shared user data (email address) of the connection. Fig.11h The illustrated page (1171) shows a graphical control that can be actuated to send a profile sharing request to the connection (Farmer Juan) to share user data ("Request More Information"). Fig.11iThe screen shot (1180) in shows the page (1181) after the user (Coffee Company) has actuated the graphical control to send a profile sharing request to the connection (Farmer Juan). The page (1181) lists the categories of user data to be included in the profile sharing request. After the categories are selected by the user (Coffee Company), the profile sharing request is sent to the connection (Farmer Juan), which can request to review the request in the DLTN client and then approve or reject it (as shown in FIG. Fig.11e explained).

[0187] at last, Fig.11j The screenshot (1190) in shows a screen (1191) of the UI of the client messaging application after one user (coffee company) has sent a profile sharing request to another user (farmer Juan) in an alternative channel. The screen (1191) shows a text message that includes a summary of the profile sharing request, the categories of user data that the sender (coffee company) wants the user (farmer Juan) to share, and two options for the user to approve the request. The first option is a link that the user can actuate to approve the request. The second option is a phone number that the user can send a short response ("yes") to approve the request.

[0188] The innovations described herein include, but are not limited to, the following:

[0189]

[0190]

[0191]

[0192]

[0193]

[0194]

[0195]

[0196]

[0197]

[0198]

[0199]

[0200] The foregoing description discloses only examples. Modifications falling within the scope of the invention will be apparent to those of ordinary skill in the art. In view of the many possible examples to which the principles of the disclosed invention can be applied, it should be appreciated that the illustrated examples are only preferred examples of the invention and should not be considered to limit the scope of the invention. On the contrary, the scope of the invention is defined by the appended claims. Therefore, we claim all that falls within the scope and spirit of these claims as our invention.

Claims

1. A computer readable medium having computer executable instructions stored therein, the computer executable instructions being used to cause a computer system implementing a distributed ledger trust network (DLTN) server to perform operations when programmed by the computer system to provide access to the DLTN, the operations comprising: receiving a request for permission settings from a DLTN client, the permission settings being for user data of a user; retrieving said permission settings; sending the permission setting to the DLTN client; receiving one or more updates to the permission settings from the DLTN client; as well as Based on the one or more updates to the permission settings, the permission settings are updated, the user data of the user is stored in the blockchain of the DLTN in association with the identity of the user, the user data has been encrypted using a set of user-specific and context-specific encryption keys, wherein the user data of the user stored in the blockchain includes biographical data of the user, contact data of the user, identification documents of the user, geographic location data of the user, and asset data of the user, and wherein the set of encryption keys is a set of encryption keys from a plurality of sets of encryption keys specific to the user, each set of encryption keys in the plurality of sets of encryption keys is associated with a different context, the different contexts being different data categories or different subsets of other users, and wherein the permission settings control access to the plurality of sets of encryption keys respectively depending on a plurality of the different contexts.

2. The computer-readable medium of claim 1, wherein the operations further comprise: creating a web page including any publicly accessible category of the user data of the user; as well as A link to the Web page is sent to the DLTN client.

3. The computer-readable medium of claim 1 , wherein the permission settings are stored in encrypted form in a storage device accessible to an authentication service, the permission settings are encrypted and decrypted using a master key of the authentication service, and wherein the permission settings are enforceable by the authentication service in conjunction with one or more access rules.

4. The computer-readable medium of claim 1, wherein the permission settings are stored in the blockchain of the DLTN in an encrypted form in association with the identity of the user, and wherein: The retrieving the permission setting comprises searching the blockchain for the permission setting, or requesting the permission setting for a service from the DLTN; and The updating of the permission settings includes storing a new version of one or more of the permission settings in a new block in the blockchain.

5. The computer-readable medium of claim 1, wherein the operations further comprise, based on one of the one or more updates to the permission settings: decrypting at least some of the user data of the user using a first encryption key from the set of encryption keys; re-encrypting the at least some of the user data for the user using a second encryption key from the set of encryption keys, the second encryption key being different from the first encryption key; as well as The re-encrypted user data of the user is stored in a new block in the blockchain.

6. The computer-readable medium of claim 1, wherein the request for permission settings is part of a request to register the user, and wherein the one or more updates to the permission settings are changes to default initial values ​​of the permission settings.

7. The computer-readable medium of claim 1, wherein the request for a permission setting is part of a request to review the permission setting, and wherein the one or more updates to the permission setting are changes to previously set values ​​of the permission setting.

8. The computer-readable medium of claim 1 , wherein the one or more updates to the permission settings comprise: granting access to at least some of the user data of the user; and / or Access to at least some of the user data of the user is revoked.

9. The computer-readable medium of claim 1, wherein the blockchain is a private blockchain, and wherein the DLTN server manages access to the private blockchain.

10. The computer-readable medium of claim 1, wherein: The DLTN server includes a Web application and implements an application programming interface API accessible to the DLTN client; and The DLTN client is implemented as a separate executable application, as client-side script logic executed in a Web browser environment, or as a set of functions of a Web browser to control the client-oriented script logic executed by the DLTN server.

11. The computer-readable medium of claim 1 , wherein the user data of the user stored in the blockchain further comprises transaction data involving transactions to which the user is a party, wherein the user is an individual, a small business, a large business, a bank, a non-profit organization, or other entity, and wherein none of the user's data is stored in a central database.

12. A method in a computer system implementing a distributed ledger trust network (DLTN) server, the distributed ledger trust network server being configured to provide access to the DLTN, the method comprising: receiving a request from a DLTN client for access to user data of a user, the user data of the user being stored in a blockchain of the DLTN in association with the identity of the user, the user data having been encrypted using a set of user-specific and context-specific encryption keys, wherein the user data of the user stored in the blockchain comprises biographical data of the user, contact data of the user, an identification document of the user, geo-location data of the user, and asset data of the user, and wherein the set of encryption keys is a set of encryption keys from among a plurality of sets of encryption keys specific to the user, each set of encryption keys from among the plurality of sets of encryption keys being associated with a different context, the different contexts being different data categories or different subsets of other users; retrieving permission settings for the user data for the user, and wherein the permission settings respectively control access to the plurality of sets of encryption keys depending on a plurality of the different contexts; determining, based on the permission settings, that access to the user data of the user is not granted to a reviewer; as well as An indication is sent to the DLTN client that access to the user data of the user is not granted to the reviewer.

13. The method according to claim 12, further comprising: receiving an indication from the DLTN client that the reviewer seeks approval by the user to access the user data of the user; as well as A request is sent to the user's DLTN client or the user's client messaging application for approval by the user for the reviewer to access the user's user data.

14. A method according to claim 12, wherein the permission settings are stored in an encrypted form in a storage device accessible to an authentication service, the permission settings are encrypted and decrypted using a master key of the authentication service, and wherein the permission settings are enforceable by the authentication service in combination with one or more access rules.

15. The method of claim 12, wherein the permission settings are stored in the blockchain of the DLTN in an encrypted form in association with the identity of the user, and wherein: The retrieving the permission setting includes searching the blockchain for the permission setting, or requesting the permission setting for a service from the DLTN.

16. The method according to claim 12, further comprising: sending a request to another DLTN client for approving the reviewer to access the user data of the user; receiving an indication from the other DLTN client approving or rejecting the request for approval; and The permission setting is selectively updated in the blockchain of the DLTN.

17. The method of claim 16, wherein the request for approval is sent in encrypted form over a secure connection, and wherein the indication of approval or rejection is received in encrypted form over the secure connection.

18. The method of claim 16, further comprising based on the indication of approving or rejecting the request: decrypting at least some of the user data of the user using a first encryption key from the set of encryption keys; re-encrypting the at least some of the user data for the user using a second encryption key from the set of encryption keys, the second encryption key being different from the first encryption key; as well as The re-encrypted user data of the user is stored in a new block in the blockchain.

19. The method of claim 12, wherein the user data of the user stored in the blockchain further includes transaction data involving transactions to which the user is a party, wherein the user is an individual, a small business, a large business, a bank, a non-profit organization, or other entity, and wherein none of the user's data is stored in a central database.

20. A computer system comprising a memory and one or more processing units, wherein the computer system implements a distributed ledger trust network (DLTN) server, the distributed ledger trust network server being configured to perform operations comprising: sending to the DLTN client a previously approved request from the reviewer for granting access to user data of a user, the user data of the user being stored in a blockchain of the DLTN in association with the identity of the user, the user data having been encrypted using a user-specific and context-specific set of encryption keys, wherein the user data of the user stored in the blockchain comprises biographical data of the user, contact data of the user, an identification document of the user, geo-location data of the user, and asset data of the user, and wherein the set of encryption keys is a set of encryption keys from among a plurality of sets of encryption keys specific to the user, each set of encryption keys from among the plurality of sets of encryption keys being associated with a different context, the different contexts being different data categories or different subsets of other users; receiving an indication from the DLTN client to revoke the previously approved request; as well as A permission setting for the user data of the user is updated, and wherein the permission setting controls access to the plurality of sets of encryption keys respectively depending on a plurality of the different contexts.

21. The computer system of claim 20, wherein the previously approved request is sent in encrypted form over a secure connection, and wherein the indication to revoke the previously approved request is received in encrypted form over the secure connection.

22. The computer system of claim 20, wherein the permission settings are stored in encrypted form in a storage device accessible by an authentication service.

23. The computer system of claim 20, wherein the permission settings are stored in the blockchain of the DLTN in an encrypted form in association with the identity of the user, and wherein: The updating of the permission settings includes storing a new version of one or more of the permission settings in a new block in the blockchain.

24. The computer system of claim 20, the operations further comprising, based on the indication to revoke the previously approved request: decrypting at least some of the user data of the user using a first encryption key from the set of encryption keys; re-encrypting the at least some of the user data for the user using a second encryption key from the set of encryption keys, the second encryption key being different from the first encryption key; as well as The re-encrypted user data of the user is stored in a new block in the blockchain.

25. The computer system of claim 20, wherein the user data of the user stored in the blockchain further comprises transaction data involving transactions to which the user is a party, wherein the user is an individual, a small business, a large business, a bank, a non-profit organization, or other entity, and wherein none of the user's data is stored in a central database.

Images