Private and public media data in a decentralized system

Abstract

Media data is inserted into existing media data in a manner that ensures that the inserted data is not accessible to all users. A computing system and method are implemented in a decentralized network that implements a distributed ledger that supports one or more decentralized identities (DIDs) for one or more users of the computing system. Access to a first portion of media data is authorized to various users. The access is based in part on a DID associated with each user. A second portion of media data is received, the second portion being inserted into the first portion of media data. The second portion of media data is accessible only to some users that have access to the first portion of media data. Access to the second portion of media data is also based in part on the DID of each user in a subset of users.

Description

Background Art

[0001] Most of the documents or records that prove identity currently used are issued by centralized organizations, such as governments, schools, employers, or other service centers or regulatory agencies. These organizations usually maintain the identity of each member in a centralized identity management system. A centralized identity management system is a centralized information system that is used to organize and manage published identities, their authentication, authorization, roles, and privileges. Centralized identity management systems have been considered secure because they usually use professionally maintained hardware and software. Typically, the identity issuing organization sets the terms and requirements for registering people with the organization. Finally, when one party needs to verify the identity of another party, the verifying party usually needs to obtain information to verify and / or authenticate the identity of the other party through a centralized identity management system.

[0002] A decentralized identifier (DID) is a new type of identifier that is independent of any centralized registry, identity provider, or certificate authority. Distributed ledger technology (such as blockchain) provides the opportunity to use fully decentralized identifiers. Distributed ledger technology uses a global distributed ledger to record transactions between two or more parties in a verifiable manner. Once a transaction is recorded, the data in that part of the ledger cannot be retroactively changed unless all subsequent parts of the ledger are changed, which provides a fairly secure platform. In a broader sense, a DID can further include a DID method that specifies how a client registers, replaces, rotates, and / or recovers a key. A DID method can also set an expiration date for a key.

[0003] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in the environments described above. Rather, this background is provided merely to illustrate one exemplary technology area in which some embodiments described herein may be practiced. Summary of the invention

[0004] The Summary is provided to introduce some concepts in a simplified form, which are further described in the Detailed Description below. The Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0005] Embodiments disclosed herein relate to a computing system and method for inserting media data into existing media data in a manner that ensures that the inserted data is not accessible to all users. The computing system and method are implemented in a decentralized network that implements a distributed ledger that is configured to support one or more decentralized identities (DIDs) for one or more users of the computing system. Access to a first portion of the media data is granted to various users. The access is based in part on a DID associated with each of the users. A second portion of the media data is received, and the second portion is inserted into the first portion of the media data. The second portion of the media data is accessible only to some of the users that have access to the first portion of the media data. Access to the second portion of the media data is also based in part on the DID of each user in a subset of users.

[0006] Additional features and advantages will be set forth in the following description and, in part, will become apparent from the description or may be learned by practice of the teachings herein. The features and advantages of the present invention may be realized and obtained by the means and combinations particularly pointed out in the appended claims. The features of the present invention will become more fully apparent from the following description and the appended claims or may be learned by practice of the present invention as described below. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to describe the manner in which the advantages and features recited above and other advantages and features can be obtained, a more particular description of the subject matter briefly described above will be rendered by reference to specific embodiments illustrated in the accompanying drawings. Understanding that these drawings depict only typical embodiments and are therefore not to be considered limiting of the scope of the invention, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0008] Figure 1 illustrates an example computing system in which the principles described herein may be employed;

[0009] Figure 2 illustrates an example environment for creating a decentralized identity (DID);

[0010] Figure 3 illustrates example environments for various DID lifecycle management operations and services;

[0011] Figure 4 An embodiment for inserting media data into existing media data is illustrated;

[0012] Figure 5A and Figure 5B Pictured Figure 4 Examples of embodiments of; and

[0013] Figure 6A-6D Pictured Figure 4 Alternative examples of embodiments of;

[0014] Figure 7 A flow chart illustrating an example method for inserting media data into existing media data in a manner that: ensures that the inserted data is not accessible to all users; and

[0015] Figure 8 A flow chart illustrating an alternative example method for inserting media data into existing media data in a manner that ensures that the inserted data is not accessible to all users. DETAILED DESCRIPTION

[0016] Embodiments disclosed herein relate to a computing system and method for inserting media data into existing media data in a manner that ensures that the inserted data is not accessible to all users. The computing system and method are implemented in a decentralized network that implements a distributed ledger that is configured to support one or more decentralized identities (DIDs) for one or more users of the computing system. Access to a first portion of the media data is granted to various users. The access is based in part on a DID associated with each of the users. A second portion of the media data is received, and the second portion is inserted into the first portion of the media data. The second portion of the media data is accessible only to some of the users that have access to the first portion of the media data. Access to the second portion of the media data is also based in part on the DID of each user in a subset of users.

[0017] The embodiments disclosed herein provide a technical advancement over conventional systems that do not utilize a distributed network using decentralized identifiers. Additionally, the embodiments disclosed herein allow a user to insert media data into existing media data in a manner that the media data is accessible only to certain other users. Additionally, the inserted media data may be kept in-line with the existing media data. This enhances usability for the user because he or she may quickly select the desired media data, may more easily view the inserted data, and may also conserve computing system bandwidth.

[0018] Because the principles described herein can be implemented in the context of a computing system, some introductory discussion of computing systems will be with respect to Figure 1 This description will then go back to the principles of the DID platform relative to the rest of the diagram.

[0019] Computing systems are now increasingly taking a variety of forms. For example, a computing system may be a handheld device, an appliance, a laptop computer, a desktop computer, a mainframe, a distributed computing system, a data center, or even a device that is not traditionally considered a computing system, such as a wearable device (e.g., glasses). In this specification and claims, the term "computing system" is broadly defined to include any device or system (or combination thereof) that includes at least one physical and tangible processor, and a physical and tangible memory that can have computer executable instructions that can be executed by the processor thereon. The memory may take any form and may depend on the nature and form of the computing system. The computing system may be distributed over a network environment and may include multiple constituent computing systems.

[0020] like Figure 1 As shown, in its most basic configuration, computing system 100 typically includes at least one hardware processor 102 and memory 104. Processor 102 may include a general-purpose processor, and may also include a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other special-purpose circuit. Memory 104 may be physical system memory, which may be volatile, non-volatile, or some combination of the two. The term "memory" may also be used herein to refer to non-volatile mass storage, such as a physical storage medium. If the computing system is distributed, then processing, memory, and / or storage capabilities may also be distributed.

[0021] The computing system 100 also has a plurality of structures thereon, which are generally referred to as "executable components." For example, the memory 104 of the computing system 100 is illustrated as including an executable component 106. The term "executable component" is a name for a structure well known to those of ordinary skill in the computing arts, which structure is understood to be a structure that may be software, hardware, or a combination thereof. For example, when implemented in software, one of ordinary skill will understand that the structure of an executable component may include software objects, routines, methods, etc., which may be executed on the computing system, regardless of whether such executable component is present in the computing system's stack or whether the executable component is present on a computer-readable storage medium.

[0022] In this case, one of ordinary skill will recognize that the structure of the executable component exists on a computer-readable medium so that the computing system performs the function when interpreted by one or more processors of the computing system (e.g., by a processor thread). Such a structure can be directly computer-readable by the processor (as in the case where the executable component is binary). Alternatively, the structure can be constructed to be interpretable and / or compiled (whether in a single stage or in multiple stages) to generate such a binary that is directly interpretable by the processor. When the term "executable component" is used, this understanding of the example structure of the executable component is well within the understanding of one of ordinary skill in the computing arts.

[0023] The term "executable component" is also well understood by those of ordinary skill to include structures such as hard-coded logic gates or hard-wired logic gates that are implemented exclusively or almost exclusively in hardware, such as in a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other special circuit. Therefore, the term "executable component" is a term for structures well known to those of ordinary skill in the computing arts, whether implemented in software, hardware, or a combination. In this description, the terms "component", "agent", "manager", "service", "engine", "module", "virtual machine", etc. may also be used. As used in this description and in this context, these terms (whether or not with modifying clauses) are also intended to be synonymous with the term "executable component" and therefore have structures well known to those of ordinary skill in the computing arts.

[0024] In the following description, embodiments are described with reference to actions performed by one or more computing systems. If such actions are implemented in software, then in response to having executed the computer executable instructions constituting the executable component, one or more processors (of the associated computing system that performs the action) instruct the operation of the computing system. For example, such computer executable instructions may be embodied in one or more computer readable media forming a computer program product. Examples of such operations involve manipulation of data. If such actions are implemented exclusively or almost exclusively in hardware, such as in an FPGA or ASIC, the computer executable instructions may be hard-coded or hard-wired logic gates. Computer executable instructions (and manipulated data) may be stored in a memory 104 of the computing system 100. The computing system 100 may also include a communication channel 108 that allows the computing system 100 to communicate with other computing systems, such as through a network 110.

[0025] Although not all computing systems require a user interface, in some embodiments, the computing system 100 includes a user interface system 112 for interfacing with a user. The user interface system 112 may include an output mechanism 112A and an input mechanism 112B. The principles described herein are not limited to the precise output mechanism 112A or input mechanism 112B, as this will depend on the nature of the device. However, the output mechanism 112A may include, for example, a speaker, a display, a tactile output, a hologram, etc. Examples of the input mechanism 112B may include, for example, a microphone, a touch screen, a hologram, a camera, a keyboard, a mouse for other pointer input, any type of sensor, etc.

[0026] The embodiments described herein may include or utilize a dedicated or general-purpose computing system including computer hardware, such as, for example, one or more processors and system memory, as discussed in more detail below. The embodiments described herein also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general-purpose or special-purpose computing system. The computer-readable medium that stores computer-executable instructions is a physical storage medium. The computer-readable medium that carries computer-executable instructions is a transmission medium. Therefore, by way of example and not limitation, embodiments of the present invention may include at least two distinct types of computer-readable media: a storage medium and a transmission medium.

[0027] Computer-readable storage media includes RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other physical and tangible storage media that can be used to store desired program code means in the form of computer-executable instructions or data structures and that can be accessed by a general-purpose or special-purpose computing system.

[0028] "Network" is defined as one or more data links that enable the transmission of electronic data between computing systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computing system via a network or other communication connection (hardwired, wireless, or a combination of hardwired or wireless), the computing system correctly treats the connection as a transmission medium. The transmission medium may include a network and / or a data link that can be used to carry the desired program code components in the form of computer executable instructions or data structures and can be accessed by a general or special computing system. The combination of the above should also be included within the scope of computer-readable media.

[0029] Further, upon reaching various computing system components, program code components in the form of computer executable instructions or data structures may be automatically transferred from a transmission medium to a storage medium (or vice versa). For example, a computer executable instruction or data structure received over a network or data link may be buffered in RAM of a network interface module (e.g., a "NIC") and then ultimately transferred to computing system RAM and / or a less volatile storage medium at the computing system. Thus, it should be understood that storage media may be included in computing system components that also (or even primarily) utilize transmission media.

[0030] For example, computer executable instructions include instructions and data that, when executed at a processor, cause a general purpose computing system, a special purpose computing system, or a special purpose processing device to perform a certain function or a set of functions. Alternatively or in addition, computer executable instructions may configure a computing system to perform a certain function or a set of functions. For example, computer executable instructions may be binary files, or even instructions that undergo some conversion (such as compilation) before being directly executed by a processor, such as intermediate format instructions (such as assembly language), or even source code.

[0031] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0032] Those skilled in the art will appreciate that the present invention can be practiced in a network computing environment with many types of computing system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, pagers, routers, switches, data centers, wearable devices (such as glasses), etc. The present invention can also be practiced in a distributed system environment, in which local and remote computing systems that are linked (by a hardwired data link, a wireless data link, or a combination of a hardwired and wireless data link) through a network all perform tasks. In a distributed system environment, program modules can be located in both local and remote memory storage devices.

[0033] Those skilled in the art will also appreciate that the present invention can be practiced in a cloud computing environment. A cloud computing environment can be distributed, although this is not required. When distributed, a cloud computing environment can be distributed internationally within an organization and / or have components owned across multiple organizations. In this specification and the following claims, "cloud computing" is defined as a model for implementing on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage devices, applications, and services). The definition of "cloud computing" is not limited to any of the other numerous advantages that can be obtained from such a model when the model is properly deployed.

[0034] The remaining figures may discuss various computing systems, which may correspond to the computing system 100 described previously. As will be explained, the computing systems of the remaining figures include various components or functional blocks that can implement the various embodiments disclosed herein. The various components or functional blocks can be implemented on a local computing system, or can be implemented on a distributed computing system that includes an element residing in the cloud or implements various aspects of cloud computing. The various components or functional blocks can be implemented as software, hardware, or a combination of software and hardware. The computing systems of the remaining figures may include more or fewer components than those shown in the figures, and some components may be combined as needed. Although it is not necessary to explain, the various components of the computing system may access and / or utilize processors and memories, such as processor 102 and memory 104, as needed to perform their various functions.

[0035] Now about Figure 2 Give some introductory discussion of decentralized identities (DIDs) and the environments in which they are created and reside. Figure 2 As shown, DID owner 201 may own or control DID 205, which represents the identity of DID owner 201. DID owner 201 may register a DID using a creation and registration service, which will be explained in more detail below.

[0036] DID owner 201 may be any entity that may benefit from a DID. For example, DID owner 201 may be a human or an organization of humans. Such an organization may include a company, department, government, agency, or any other organization or group of organizations. Each individual person may have a DID, and the organization(s) to which each person belongs may also have a DID.

[0037] DID owner 201 may alternatively be a machine, system or device, or a collection of (multiple) machines, (multiple) devices and / or (multiple) systems. In other embodiments, DID owner 201 may be a sub-part of a machine, system or device. For example, a device may be a printed circuit board, where the sub-parts of the circuit board are the individual components of the circuit board. In such an embodiment, a machine or device may have a DID, and each sub-part may also have a DID. DID owner may also be a software component, such as described above with respect to Figure 1 An example of a complex executable component 106 may be an artificial intelligence. The artificial intelligence may also have a DID.

[0038] Thus, DID owner 201 may be any reasonable entity, human or non-human, that is capable of creating a DID 205 or at least has a DID 205 created for and associated with it. Although DID owner 201 is shown as having a single DID 205, this need not be the case, as there may be any number of DIDs associated with DID owner 201 as desired.

[0039] As mentioned, DID owner 201 can create and register DID 205. DID 205 can be any identifier associated with DID owner 201. Preferably, the identifier is unique to the DID owner 201, at least within the scope of the intended use of the DID. As an example, the identifier can be a locally unique identifier, and it may be more desirable to provide a globally unique identifier for identity systems that are expected to operate globally. In some implementations, DID 205 can be a uniform resource identifier (URI) (such as a uniform resource locator (URL)) or other pointer that connects DID owner 201 to an organization to participate in a trusted interaction with DID owner 201.

[0040] DID 205 is "decentralized" because it does not require a centralized, third-party management system to generate, manage, or use. Therefore, DID 205 remains under the control of DID owner 201. This is different from traditional centralized IDs, which place trust on centralized management agencies, and it remains under the control of enterprise directory services, certificate authorities, domain name registries, or other centralized management agencies (collectively referred to herein as "centralized management agencies"). Therefore, DID 205 can be any identifier that is under the control of DID owner 201 and independent of any centralized management agency.

[0041] In some implementations, the structure of DID 205 may be as simple as a username or some other human-understandable term. However, in other implementations, DID 205 may preferably be a random string of numbers and letters for increased security. In one embodiment, DID 205 may be a string of 128 letters and numbers. Therefore, the embodiments described herein do not rely on any specific implementation of DID 205. In a very simple example, DID 205 is shown as "123ABC".

[0042] Also like Figure 2 As shown, DID owner 201 has control over a private key 206 and a public key 207 pair associated with DID 205. Since DID 205 is independent of any centralized authority, private key 206 should always be in full control of DID owner 201. That is, the private and public keys should be generated in a decentralized manner that ensures that they remain under the control of DID owner 201.

[0043] As will be described in more detail below, the private key 206 and public key 207 pair may be generated on a device controlled by the DID owner 201. Therefore, the private key 206 and public key 207 pair should not be generated on a server controlled by any centralized authority, as this may result in the private key 206 and public key 207 pair not always being completely under the control of the DID owner 201. Figure 2 While this description has described private and public key pairs, it should also be noted that other types of reasonable cryptographic information and / or mechanisms may also be used as desired.

[0044] Figure 2 Also illustrated is a DID document 210 associated with the DID 205. As will be explained in more detail below, the DID document 210 may be generated when the DID 205 is created. The DID document 210, in its simplest form, describes how the DID 205 is used. Thus, the DID document 210 includes a reference to the DID 205, which is the DID described by the DID document 210. In some embodiments, the DID document 210 may be implemented according to a method specified by a distributed ledger 220, which will be used to store representations of the DID 205, as will be explained in more detail below. Thus, the DID document 210 may have different methods depending on the particular distributed ledger.

[0045] DID document 210 also includes a public key 207 or some other equivalent cryptographic information created by DID owner 201. Public key 207 can be used by third-party entities that are given access by DID owner 201 to information and data owned by DID owner 201. Public key 207 can also be used by verifying that DID owner 201 actually owns or controls DID 205.

[0046] The DID document 210 may also include authentication information 211. The authentication information 211 may specify one or more mechanisms by which the DID owner 201 is able to prove that the DID owner 201 owns the DID 205. In other words, the mechanisms of the authentication information 211 may show proof of the binding between the DID 205 (and therefore it is the DID owner 201) and the DID document 210. In one embodiment, the authentication information 211 may specify that the public key 207 is used for a signing operation to prove ownership of the DID 205. Alternatively or additionally, the authentication information 211 may specify that the public key 207 is used for a biometric operation to prove ownership of the DID 205. Thus, the authentication information 211 may include any number of mechanisms by which the DID owner 201 is able to prove that the DID owner 201 owns the DID 205.

[0047] The DID document 210 may also include authorization information 212. The authorization information 212 may allow the DID owner 201 to authorize a third-party entity to modify the DID document 210 or a portion of the document without giving the third party the right to prove ownership of the DID 205. For example, the authorization information 212 may allow a third party to update any specified set of one or more fields in the DID document 210 using any specified update mechanism. Alternatively, the authorization information may allow the third party to limit the use of the DID 205 by the DID owner 201 for a specified period of time. This may be useful when the DID owner 201 is a minor child and the third party is the parent or guardian of the child. The authorization information 212 may allow the parent or guardian to limit the use of the DID 201 until the child is no longer a minor.

[0048] The authorization information 212 may also specify one or more mechanisms that the third party will need to follow to prove that they are authorized to modify the DID document 210. In some embodiments, these mechanisms may be similar to those discussed above with respect to the authentication information 211.

[0049] The DID document 210 may also include one or more service endpoints 213. A service endpoint may include a network address on which a service operates on behalf of the DID owner 201. Examples of specific services include discovery services, social networks, document storage services (such as identity servers or centers), and verifiable claims repository services. Thus, the service endpoints 213 act as pointers to services that operate on behalf of the DID owner 201. These pointers can be used by the DID owner 201 or a third-party entity to access services that operate on behalf of the DID owner 201. Specific examples of service endpoints 213 will be explained in more detail below.

[0050] The DID document 210 may also include identification information 214. The identification information 214 may include personally identifiable information of the DID owner 201, such as name, address, occupation, family members, age, hobbies, interests, etc. Therefore, the identification information 214 listed in the DID document 210 may represent different personas of the DID owner 201 for different purposes. For example, the persona may be pseudo-anonymous, for example, the DID owner 201 may include a pseudonym in the DID document when identifying him or her as an author posting an article on a blog; the persona may be completely anonymous, for example, the DID owner 201 may only want to disclose his or her job title or other background data (e.g., school teacher, FBI agent, adult over 21 years old, etc.), rather than his or her name in the DID document; and the persona may be specific to the identity of the DID owner 201 as an individual, for example, the DID owner 201 may include information identifying him or her as a volunteer of a specific charity organization, an employee of a specific company, a winner of a specific award, etc.

[0051] The DID document 210 may also include credential information 215, which may also be referred to herein as an attestation. The credential information 215 may be any information associated with the background of the DID owner 201. For example, the credential information 215 may be (but is not limited to) qualifications, achievements, government IDs, government entitlements (such as a passport or driver's license), payment providers or bank accounts, college degrees or other educational backgrounds, work status and history, or any other information about the background of the DID owner 201.

[0052] DID document 210 may also include various other information 216. In some embodiments, other information 216 may include metadata specifying when DID document 210 was created and / or when it was last modified. In other embodiments, other information 216 may include cryptographic evidence of the integrity of DID document 210. In further embodiments, other information 216 may include additional information specified by the particular method of implementing the DID document, or specified by DID owner 201.

[0053] Figure 2 A distributed ledger or blockchain 220 is also illustrated. The distributed ledger 220 can be any decentralized, distributed network that includes various computing systems that communicate with each other. For example, the distributed ledger 220 can include a first distributed computing system 230, a second distributed computing system 240, a third distributed computing system 250, and any number of additional distributed computing systems illustrated by ellipse 260. The distributed ledger or blockchain 220 can operate according to any known standard or method for distributed ledgers. Examples of conventional distributed ledgers that can correspond to the distributed ledger or blockchain 220 include, but are not limited to, Bitcoin [BTC], Ethereum, and Litecoin.

[0054] In the context of DID 205, a distributed ledger or blockchain 220 is used to store a representation of DID 205 pointing to DID document 210. In some embodiments, DID document 210 may be stored on the actual distributed ledger. Alternatively, in other embodiments, DID document 210 may be stored in a data storage device (not shown) associated with distributed ledger or blockchain 220.

[0055] As mentioned, a representation of the DID 205 is stored on each distributed computing system of the distributed ledger or blockchain 220. For example, in Figure 2 In FIG. 2 , this is shown as DID hash 231, DID hash 241, and DID hash 251, which are ideally identical copies of the same DID. DID hash 231, DID hash 241, and DID hash 251 can then point to the location of DID document 210. Distributed ledger or blockchain 220 can also store many other representations of other DIDs, as illustrated by references 232, 233, 234, 242, 243, 244, 252, 253, and 254.

[0056] In one embodiment, when DID user 201 creates DID 205 and associated DID document 210, DID hash 231, DID hash 241, and DID hash 251 are written to distributed ledger or blockchain 220. Distributed ledger or blockchain 220 thus records that DID 205 is now out. Because distributed ledger or blockchain 220 is decentralized, DID 205 is not controlled by any entity other than DID owner 201. In addition to a pointer to DID document 210, DID hash 231, DID hash 241, and DID hash 251 may also include a record or timestamp specifying when DID 205 was created. Later, when DID document 210 is modified, this may also be recorded in DID hash 231, DID hash 241, and DID hash 251. DID hash 231 , DID hash 241 , and DID hash 251 may also include a copy of public key 207 , such that DID 205 is cryptographically bound to DID document 210 .

[0057] Figure 3 An embodiment of an environment 300 is illustrated in which a DID such as DID 205 can be utilized. In particular, environment 300 will be used to describe the use of DID 205 in connection with one or more decentralized storage devices or identity centers. It should be noted that Figure 3 Can include relevant Figure 2 Reference is made to the elements first discussed in the description and therefore to facilitate the explanation, the same reference numerals are used.

[0058] like Figure 3 As shown in FIG, environment 300 includes various storage devices or identity centers 310 associated with DID owner 201. For example, storage devices or identity centers 311 may include a first identity center 311, a second identity center 312, a third identity center 313, and a fourth identity center 314. Ellipses 315 indicate that there may be any number of additional storage devices or identity centers as needed. It should be noted that identity center 310 is considered a decentralized storage device because (as will be explained in more detail below) the identity center is addressable using DID 205 and its corresponding DID document 210. In addition, although the identity center can be hosted by a third party, all access to the identity center is based on permissions determined by DID owner 201.

[0059] In one embodiment, the first identity center 311 can be implemented at the first cloud storage provider, the second identity center 312 can be implemented at the second cloud storage provider, the third identity center 313 can be implemented as part of a home computing system, and the fourth identity center 314 can be implemented as part of a mobile device. Therefore, various identity centers 310 can be implemented across different service providers, such as two different cloud storage providers. Further, the various identity centers 310 can be implemented as a combination of storage devices provided by a third party (such as two cloud storage providers) and memory devices owned by the DID owner 201 (such as a home computing system and a mobile device). Of course, the various identity centers 310 can be implemented as other storage devices and services as needed.

[0060] In one embodiment, identity center 310 may be multiple instances of the same identity center. It is represented by line 310A. Therefore, various identity centers 310 may include at least some of the same data and services. Therefore, if any changes are made to one of the identity centers 310, the changes may be reflected in the remaining identity centers. For example, the first identity center and the second identity center are implemented in a cloud storage device and may therefore be able to save a large amount of data. Therefore, a complete data set may be stored in these identity centers. However, identity centers 312 and 313 may have a smaller memory space. Therefore, in these identity centers, descriptors of the data stored in the first and second identity centers may be included. Alternatively, records of changes made to the data in other identity centers may be included. Therefore, changes in one of the identity centers 310 are either completely copied to the other identity centers, or at least records or descriptors of the data are recorded in the other identity centers.

[0061] Because identity centers can be multiple instances of the same identity center, only a complete description of the first identity center 311 will be provided, as the description may also apply to identity centers 312-315. As shown, identity center 311 may include a data storage device 320. Data storage device 320 may be used to store any type of data associated with DID owner 201. In one embodiment, the data may be a collection 322 of a specific type of data corresponding to a specific protocol. For example, collection 322 may be medical record data corresponding to a specific protocol of medical data. Collection 322 may be any other type of data.

[0062] In one embodiment, the stored data may have different authentication and privacy settings 321 associated with the stored data. For example, a first subset of data may have a setting 321 that allows the data to be exposed publicly, but the setting 321 does not include any authentication of the DID owner 201. This type of data may be relatively unimportant data, such as a color scheme, etc. A second subset of data may have a setting 321 that allows the data to be exposed publicly and includes authentication of the DID owner 201. A third subset of data may have a setting 321 that encrypts the data subset using a private key 206 and a public key 207 pair (or some other key pair) associated with the DID owner 201. This type of data will require the party to have access to the public key 207 or some other associated public key in order to decrypt the data. This process may also include authentication of the DID owner 201. A fourth subset of data may have a setting 321 that restricts the data to a subset of third parties. This may require that the public key associated with the subset of third parties be used to decrypt the data. For example, DID owner 201 may cause setting 321 to specify that only public keys associated with friends of DID owner 201 may decrypt the data.

[0063] In some embodiments, identity center 311 may have a permissions module 330 that allows DID owner 201 to set specific authorizations or permissions for third parties, such as third parties 301 and 302, to access identity center. For example, DID owner 201 may provide access rights to allow his or her spouse to access all data 320. Alternatively, DID owner 201 may allow his or her doctor to access any medical records. It should be understood that DID owner 201 may grant any number of third parties access to a subset of data 320. This will be explained in more detail below.

[0064] In some embodiments, the identity center 311 may include a certification repository 340 that includes various certifications 341, 342, and any number of additional certifications, as illustrated by the ellipsis 343 associated with the DID owner 201. The certification may also be referred to as a credential or a verified credential, such as the credential 215 in the DID document 210. That is, the certification or verified credential may provide information about the DID owner 201 and / or about various entities with which the DID owner 201 interacts. As previously mentioned, the certification may be (but is not limited to) a qualification, an achievement, a government ID, a government entitlement (such as a passport or driver's license), a payment provider or bank account, a college degree or other educational history, employment status and history, or any other information about the background of the DID owner 201. Thus, the certification may be used to verify the identity of the DID owner 201.

[0065] The identity center 311 may also have a messaging module 345. In operation, the messaging module allows the identity center to receive messages, such as requests from third parties (such as third parties 301 and 302) to access the data and services of the identity center. In addition, the messaging module 345 allows the identity center 311 to respond to messages from third parties and also communicate with the DID resolver 350. The DID resolver 350 may be a service, application, or module that is configured to search the distributed ledger or blockchain 220 for a DID document associated with a DID in operation. Thus, in an embodiment, the DID resolver 350 may use the DID 205 to search the distributed ledger or blockchain 220, which may result in the DID resolver 350 finding the DID document 210. The ellipsis 316 indicates that the identity center 311 may have additional services as needed.

[0066] In an example embodiment, DID owner 201 may provide DID 205 to third-party entity 301 so that the third party can access data or services stored on identity center 311. Once third party 301 has access to DID 205, he or she may access DID resolver 350 to access DID document 210. As previously discussed, DID document 210 may include endpoint 213, which is an address or pointer to identity center 311. Third party 301 may then use the address or pointer to access identity center 311.

[0067] Third party 301 may send a message to messaging module 345 requesting permission to access data in identity center 311. Messaging module 345 may then send a message to DID owner 201 asking whether third party 301 should be given access to the data. Since DID owner 201 desires to provide access to the data, DID owner 201 may allow permission to third party 301, and the permission may be recorded in permissions 330.

[0068] The messaging module 345 can then communicate a message to the third party 301, informing the third party that he or she can access the data. The identity center 311 and the third party 301 can then communicate directly so that the third party can access the data. It should be noted that in many cases it will be the identity center associated with the third party 301 that actually communicates with the identity center 311. However, it may be the device of the third party 301 that communicates.

[0069] Advantageously, the process described above allows the identity center 311 to communicate and share data with third parties 301 without requiring the third parties to access the identity center 311 in a conventional manner. Instead, the communication is provided in a decentralized manner using the DID 205 and the DID document 210. This advantageously allows the DID owner to have full control over the process.

[0070] like Figure 3 As shown in FIG. 2 , third party 302 can also use DID 205 and DID document 210 to request permission to access identity center 311. Therefore, the embodiments disclosed herein allow any number of third parties to access identity center 310.

[0071] Figure 4 An embodiment of an environment 400 is illustrated in which a DID such as DID 205 can be utilized. Specifically, environment 400 will be used to describe the use of DID 205 with respect to a media data service that allows context review and insertion / deletion of various media, as will be explained in more detail below. It should be noted that Figure 4 Can include relevant Figure 2-Figure 3 1 and 2, and therefore, for ease of explanation, the same reference numerals are used.

[0072] As shown, environment 400 includes media data service 410. In one embodiment, media data service 410 may be implemented by a third party such as DID management service 440 and / or provider of identity center 310. In some embodiments, media data service 410 may be hosted on a server computer that is separate from any device owned by DID owner 201.

[0073] A specific use embodiment of the media data service 410 will now be explained, followed by a specific example of the media data service 410. In one embodiment, the media data service 410 may be initiated by the DID owner 201 associated with the identity center 311 as described above. In addition, as described above, the DID owner 201 may have control over the public and private key pairs 206 and 207. Of course, in some alternative embodiments, the media data service may be initiated by a third party other than the DID owner 201.

[0074] In an embodiment, the media data service 410 may allow the DID owner 201 to provide various types of media data to other users for various purposes as will be explained below. The various types of media data that may be implemented on the media data service 410 include, but are not limited to: chat media data, any type of written media data (such as a book, paper, internet page, or blog), audio media data, and video media data. Therefore, the embodiments disclosed herein are not limited by the actual media data implemented on the media data service 410.

[0075] In an embodiment, DID owner 201 may desire to provide media data to user 401, user 402, and user 403 using media data service 410. Figure 4 As shown, user 401 may own or have control over DID 401A, and user 402 may own or have control over DID 402A. It should be noted that DID 401A and DID 402A are generated and stored on the distributed ledger or blockchain 220 in the manner described above for DID 205. Therefore, users 401 and 402 will also have DID documents associated with their respective DIDs, and may also have one or more identity centers that include proofs that can be used to verify the identities of users 401 and 402. Therefore, the DID documents and identity centers associated with users 401 and 402 can be similar to the DID documents 210 and identity centers 310 described above, and therefore do not require further detailed explanation. It should also be noted that user 403 initially does not have a DID associated with him or her.

[0076] As illustrated, media data service 410 may include public media data portion 420. DID owner 201 may utilize public media data portion 420 to provide media data 425 accessible to all users. Thus, user 401, user 402, and user 403, as well as any number of additional users illustrated by ellipsis 404, may access public media data 425. However, in some embodiments, access to public media data 425 may require the user to own or have control over the DID.

[0077] Additionally, media data service 410 may include private media data portion 430. DID owner 201 may utilize private media data portion 430 to provide private media data, which may be private because it has been encrypted by DID owner 201 using the previously described public and private key pair 206 and 207. The private media data may only be accessible to users who own or control the DID, and therefore have a way to access DID owner 201's public key 207 so that they can access the private media data.

[0078] For example, the identity center 311 as described above may have a permissions module 330 that allows the DID owner 201 to set specific authorizations or permissions for users 401-403. In the current embodiment, these permissions may allow the DID owner 201 to set a first permission 411 for a first portion of private media data 431, a second permission 412 for a second portion of private media data 432, and a third permission 413 for a third portion of private media data 433. It should be noted that the DID owner 201 may set any number of additional permissions for any additional portion (not shown) of the private media data 430 included in the media data service 410, as indicated by the ellipsis 414. These permissions may be based on the DIDs owned or controlled by the various users utilizing the media data service 410, thereby ensuring that access to the private media data is controlled in a decentralized manner using the distributed ledger or blockchain 220.

[0079] In an embodiment, user 401 can access media data service 410. As previously described, he or she can access public media data 425 because all users can access the data. However, user 401 may also desire to access private media data portion 430 so that he or she can access some private media data. In this case, media data service 410 can access DID resolver 350 using DID 401A to find the DID document associated with DID 401A. This can then lead to an identity center associated with user 401, where media data service 410 may be able to access one or more certificates to verify the identity of user 401. If media data service 410 cannot verify the identity of user 401, private media data cannot be provided to user 401.

[0080] If the identity is verified, media data service 410 may access permissions 411-414 stored in identity center 311 to determine whether user 401 should be allowed to access private media data. In the current embodiment, permission 411 may give user 401 permission to access private media data 431, permission 412 may give user 401 permission to access private media data 432, and permission 413 may give user 401 permission to access private media data 433. Of course, in some embodiments, the step of using proof to verify the identity of user 401 may be skipped, and media data service 410 may rely solely on permissions.

[0081] Because user 401 owns or controls DID 401A, user 401 is part of a decentralized system anchored by distributed ledger or blockchain 220. Therefore, user 401 can access DID resolver 350 using DID 205 to search distributed ledger or blockchain 220, which may cause DID resolver 350 to find DID document 210. DID document 210 can then be used to access public key 207 from DID document or identity center 311 in the manner previously described.

[0082] User 401 may then be able to use public key 207 (or some other key associated with DID owner 201) to decrypt private media data 430. That is, media data service 410 may access private data 431 from identity center 311 (or some other source) and then make it available to user 401 who may be able to decrypt and access private media data 431. In some embodiments, private media data 431 may be decrypted at a presentation level, such as when it is presented in UI 410A associated with media data service 410.

[0083] As mentioned previously, user 401 may also be given permission to access private media data 432 and 433. Therefore, media data service 410 may provide private media data 432 and 433 to user 401. User 401 may be able to decrypt private media data 432 and 433 at the presentation level in the manner described previously.

[0084] Likewise, user 402 may access media data service 410. As previously described, he or she may access public media data 425, since all users may access the data. However, user 402 may also desire access to private media data portion 430 so that he or she may access some private media data. In this case, media data service 410 may then access DID resolver 350 using DID 402A to find the DID document associated with DID 402A. This may then lead to an identity center associated with user 402, where media data service 410 may be able to access one or more certificates to verify the identity of user 402. Of course, in some embodiments, the step of using certificates to verify the identity of user 402 may be skipped, and media data service 410 may rely solely on permissions.

[0085] Once the identity is verified, media data service 410 may access permissions 411-414 stored in identity center 311 to determine whether user 402 should be allowed to access private media data. In the current embodiment, permission 412 may give user 402 permission to access private media data 432, and permission 413 may give user 402 permission to access private media data 433. Of course, in some embodiments, the step of using authentication to verify the identity of user 402 may be skipped, and media data service 410 may rely solely on permissions.

[0086] Because user 402 owns or controls DID 401A, user 402 is also part of the decentralized system anchored by distributed ledger or blockchain 220. Therefore, user 402 can access DID resolver 350 using DID 205 to search distributed ledger or blockchain 220, which can cause DID resolver 350 to find DID document 210. DID document 210 can then be used to access public key 207 from DID document or identity center 311 in the manner previously described.

[0087] User 402 may then be able to use public key 207 (or some other key associated with DID owner 201) to decrypt private media data 430. That is, media data service 410 may access private data 432 from identity center 311 (or some other source) and then make it available to user 402 who may be able to decrypt and access data 432. In a similar manner, user 402 may also be given access to private media data 433, which he or she may be able to decrypt in the manner previously described.

[0088] In an embodiment, user 403 may also access media data service 410 to obtain access to some private media data. However, in this case, media data service 410 may determine that user 403 does not yet own a DID or have control over a DID. Therefore, media data service 410 may prompt user 403 to access DID service 440, which is a service typically owned by a third party that can generate a DID for a user. DID service 440 may generate DID 403A in accordance with the method described above, which DID 403A is supported by distributed ledger or blockchain 220. Therefore, embodiments disclosed herein contemplate that users without DIDs can obtain DIDs to fully utilize media data service 410.

[0089] The media data service 410 may then access the access rights 411-414 and determine that the user 403 should be allowed to access the private media data 433. The user 403 may then access the DID resolver 350 in the manner previously described to search the distributed ledger or blockchain 220 to access the public key 207. The private media data 433 may then be decrypted using the public key 207 described previously. It should be appreciated that the user 403 is unlikely to have accumulated any proofs because the DID 403A is new, and therefore this step may be skipped because the media data service 410 may be able to determine the identity of the user 403 because the user has just created the DID 403A.

[0090] In some embodiments, media data service 410 may include media data insertion component 450. Media data insertion component 450 may allow DID owner 201 and one or more of users 401-403 to insert media data that is not accessible or viewable to other users into media data service 410. In some embodiments, media data insertion component 450 may allow two or more of users 401-403 to insert media data that is not accessible or viewable to DID owner 201 and other users into media data service 410.

[0091] For example, Figure 4 As shown in , media data insertion component 450 can allow DID owner 201 to insert media data 451 that is only accessible or viewable by user 401. Similarly, user 401 can insert media 452 that is only accessible or viewable by DID owner 201. However, as Figure 4 As shown, users 402 and 403, although able to access private media data 433, cannot access or view media data 451 and 452 that have been inserted into private media data 433 by DID owner 201 and user 401 via media data insertion component 450. Therefore, DID owner 201 and user 401 constitute a subset of users that can access private media data 433. For example, if media data 451 and 452 are chat data, only DID owner 201 and user 401 will be able to view the specific chat data inserted by DID owner 201 and user 401. An example of media data insertion component 450 will be described in more detail below.

[0092] Figure 5A The use of the media data service 410 is illustrated. Therefore, for ease of explanation, no Figure 4 All details will be in Figure 5AAs shown, the media data service 410 and its corresponding UI 410A are used to show media data, which can be a book, article, blog post, or any other type of written document 510 that the DID owner 201 (or some other user) desires to be edited by various users. However, in order to ensure that no editing user can access the entire document, which may cause the document 510 to be copied or leaked, the DID owner 201 can only allow different users to access certain parts of the document.

[0093] For example, public media data portion 520 of a document including title 521 may be accessible or viewable by all editing users. Thus, public media data portion 520 may correspond to public media data 420 described above. As shown in the figure, users 401, 402, and 403 may access portion 520 without requiring any DID-based permissions.

[0094] like Figure 5A As further illustrated in FIG. 5 , document 510 may include private media data portions 530, 540, and 550. These portions of document 510 may be various paragraphs or chapters to be edited. Thus, these portions may correspond to private media data 430 discussed above.

[0095] like Figure 5A , user 401 has been given access to and therefore review the private media data portion 530 of document 510. Figure 4 As described, the identity of user 401 can be verified, and user 401 can access public key 207 of DID owner 201 and can then use the public key to decrypt private media data portion 530. User 401 can then review private media data portion 530 and edit the data as needed.

[0096] Also like Figure 5A As shown in , both user 401 and user 403 have permission to access document 510 and therefore review private media data portion 540 of document 510. Figure 4 As described, users 401 and 403 may access public key 207 of DID owner 201 and may then use the public key to decrypt private media data portion 540. Users 401 and 403 may then review private media data portion 540 and may edit the data as desired.

[0097] In an embodiment, user 403 may make some edits 541 to private media data 540 that are intended to be viewable only by DID owner 201. Edits 541 may be corrections or additions to already written content, the nature of which is that it is not expected that user 401 will see the content of the edits. Therefore, user 403 may access media data insertion component 450 to insert edits 541 into private media data 540. User 403 may then encrypt edits 541 using his or her private key and public key pair associated with DID 403A. DID owner 201 may access distributed ledger or blockchain 220 to obtain the public key associated with DID 403A to decrypt edits 541 as needed. In this way, only DID owner 201 is aware of edits 541 and is able to decrypt them when needed.

[0098] like Figure 5A As further shown in FIG. 5 , all users 401, 402, and 403 have been granted permission to access and therefore review the private media data portion 550 of the document 510. These users can access the distributed ledger or blockchain 220 to obtain the required public key to decrypt the private media data portion 550 in the manner previously described. In addition, their identities can be verified using the distributed ledger or blockchain 220 in the manner previously described. Users 401, 402, and 403 can then review the private media data portion 540 and can edit the data as needed. Although not shown, any user can utilize the media data insertion component 450 to insert edits that are only viewed by the few users who have access to the private media data portion 550.

[0099] Figure 5B An alternative use embodiment of the media data service 410 is illustrated. Figure 5B , the media data in this embodiment may be streaming media data 560, such as audio data, video data, or some other type of media data that can be streamed by a user. The streaming media data 560 may be shown on the UI 410A of the media data service 410.

[0100] like Figure 5B As shown in , streaming media data 560 may include various portions 561-566 that may correspond to different time periods in the data stream. For example, portions 564, 565, and 566 may correspond to time periods of streaming data that are not accessible to any user except DID owner 201 (or some other user that owns streaming data 560).

[0101] As shown, portion 561 may correspond to a time period of stream data 560 to which user 401 has been granted access. User 401 may access distributed ledger or blockchain 220 to gain access to that portion of the stream in the manner previously described. User 401 may then review and edit that portion as desired.

[0102] Likewise, portion 562 may correspond to a time period of stream data 560 to which user 402 has been granted access, and portion 563 may correspond to a time period of stream data 560 to which user 403 has been granted access. Users 402 and 403 may access the distributed ledger or blockchain 220 to obtain access to these portions of the data stream, respectively, in the manner described above. Users 402 and 403 may then review and edit the respective portions as desired.

[0103] Figure 6A-6D An alternative use embodiment of the media data service 410 is illustrated. Figure 6A-6D In the embodiment of , the media data is chat data. These figures illustrate the use of UI 410A to implement chat in a decentralized manner. Figure 5A and Figure 5B For the convenience of explanation, the previously described Figure 4 The elements in .

[0104] like Fig. 6A As shown in , UI 410A may include an identifier portion 610, which identifies the media as chat media data. The UI may also include an element 615, which shows the user who is actively using a block chat. For example, element 615 shows that DID owner 201 and users 401-403 are communicating using block chat 610. In some embodiments, the icons of different users of the block chat may be different colors, shapes, or other unique identifiers, so that each user is easily identified in the block chat. Element 615 may be an example of public media data 420, or it may be part of private media data 430. Therefore, not all embodiments disclosed herein require a public media data portion.

[0105] Fig. 6AAlso shown is a private media data portion 620, which may correspond to private media data portion 430. Private media data portion 620 includes a first chat box 621 that has been generated by DID owner 201. As shown, chat box 621 states "Well, we'll use a hammer to tighten the screw." Private media data portion 620 also includes a second chat box 622 that has been generated by user 401. Chat box 622 states "Good idea. That will save money because there's no need to buy a screwdriver." It should be noted that DID owner 201 and user 401 are able to use the same method discussed above with respect to the first chat box 621. Figure 4 The corresponding chat box is generated in a decentralized manner. That is, the media data service 410 uses the distributed ledger or blockchain 220 and the DIDs 205 and 401A of the DID owner 201 and the user 401 to grant permissions including the chat box.

[0106] Fig. 6A Further shown is a user input element 630 that allows the user 402 to insert data into the box chat in a private manner. Thus, the user input element 630 may correspond to the media data insertion component 450 and will be explained in more detail below.

[0107] Figure 6B The operation of user input element 630 is shown. For example, suppose user 402 disagrees that it is a good idea to tighten the screw with a hammer. However, user 402 may not want to publicly express this view and let DID owner 201 and / or user 401 see it, so as not to embarrass or anger DID owner 201 and / or user 401. Therefore, user 402 can provide user input 641 to user input element 630. In the illustrated embodiment, this may cause element 640 to appear in UI 410A, which lists all other users that user 402 may wish to communicate privately with outside user 402. In an embodiment, user 402 can provide user input 642 for selecting user 403, as shown in dotted line 643. The dotted line represents that the selected user can be represented by different colors, sizes or other unique identifiers.

[0108] Figure 6C The operation of the user input element 630 is further illustrated. As shown, the user 402 can enter "Bad idea. This won't work" because he or she may not trust the hammer to effectively tighten the screw. As explained previously, the figure also shows at 635 that the distributed ledger or blockchain 220 will be accessed so that the user 403 can receive a private message from the user 402.

[0109] Fig.6DA private chat box 645 from user 402 is shown to have been inserted into the boxed chat. The dotted line around private chat box 645 illustrates that only users 402 and 403 can see the inserted private chat box 645. Advantageously, the inserted private chat box 645 has been placed in the UI 410A in a row with the previous chat boxes 621 and 622. Therefore, users 402 and 403 do not need to open any other UI to view this message. This can increase the readability of the inserted private chat box 645 and therefore increase the comfort of the users. It should be noted that user 402 can view the inserted private chat box 645 in the same manner as described above. Figure 4 The media data service 410 can utilize the distributed ledger or blockchain 220 and DID 402A to grant permissions including private

[0110] Furthermore, even when additional chat messages are added, the private chat box 645 can remain in one column. For example, Fig.6D The chat message 623 showing the narrative “Let’s do this” generated by the DID owner 201 has been added after the private chat box 645. However, the private chat boxes 645 are kept in one column according to their chronological order, which can also increase the readability of the inserted private chat boxes 645.

[0111] The following discussion now relates to a number of methods and method actions that can be performed. Although method actions may be discussed in a certain order or illustrated in a flowchart as occurring in a particular order, no particular order is required unless otherwise specified or required because one action depends on another action being completed before the action is performed.

[0112] Figure 7 A flow chart of an example method 700 for inserting media data into existing media data in a manner that ensures that the inserted data is not accessible to all users is illustrated. Figure 2-6D One or more of the following may be used to describe the

[0113] Method 700 includes receiving a first portion of media data (710). For example, as previously discussed, first media data such as private media data 430 (431, 432, 433), 530, 540, 550, 561-563, media data portion 620, and media data in chat boxes 621 and 622 can be received by media data service 410. The first portion of media data can be chat data, a document such as a book, an article, a blog post, an Internet page, or streaming audio or video data.

[0114] Method 700 includes granting access to a first portion of media data to a plurality of users (720). The access is based at least in part on a DID associated with each of the plurality of users. For example, as previously described, DID owner 201 and users 401-403 may be granted access to a first portion of media data. Figure 2-Figure 4 As described, the media data service utilizes one or more of DIDs 205, 401A, 402A, and 403A to access the distributed ledger or blockchain 220 to verify the identity of the user as needed. The user can also use one or more DIDs to obtain a public key that allows the user to decrypt the first portion of the media data.

[0115] The method 700 includes receiving a second portion of media data inserted into the first portion of media data (730). The second portion of the media data is accessible only to a subset of a plurality of users that have access to the first portion of the media data. Access to the second portion of the media data is also based at least in part on a DID of each user in the subset of users.

[0116] For example, as described above, the second portion of media data, such as media data 451, 452, media data corresponding to edit 541, and media data in private chat box 645, can be inserted by media data insertion component 450. As described above, the data is accessible by less than all DID owners 201 and users 401-403. Media data service 410 and media data insertion component 450 use one or more of DIDs 205, 401A, 402A, and 403A to allow media data insertion component 450 to insert the second media data in the manner described above.

[0117] Figure 8 A flow chart of an example method 800 for inserting media data into existing media data in a manner that ensures that the inserted data is not accessible to all users is illustrated. Figure 2-6D Described in one or more of the discussions.

[0118] The method 800 includes displaying a first portion of media data generated by a first user in a first user interface portion (810). For example, the DID owner 210 may generate a chat box 621 in the user interface portion as described above.

[0119] The method 800 includes displaying a second portion of the media data generated by the second user in the first user interface portion (820).For example, the user 401 as described above can generate a chat box 622 in the user interface portion.

[0120] Method 800 includes exposing a first interface portion to first and second users and a third user (830). The first, second, and third users are identified based on respective decentralized identities (DIDs), the respective DIDs being supported by a distributed ledger of a distributed network. For example, DID owner 201 and users 401-403 are exposed to the user interface portion. Each user's DID can be utilized to identify various users in the manner described above.

[0121] Method 800 includes receiving input from a second user or a third user in the second user interface portion, the third user generating a third portion of media data for insertion into the first user interface portion (840). For example, as previously described, user 402 can use user input element 630 to generate private box chat 645, which user input element 630 can correspond to media data insertion component 450.

[0122] Method 800 includes inserting a third portion of media data into the first user interface portion (850). The third portion of media data is viewable to the second and third users, but not to the first user. For example, as described above, private chat box 645 is inserted into the user interface portion. However, only user 402 and user 403 can view private chat box 645. DID owner 201 and user 401 cannot view the private chat box. As shown, the private chat box can be placed in a column so that users 402 and 403 do not need to use another UI to view the private chat box.

[0123] For the processes and methods disclosed herein, the operations performed in the processes and methods may be implemented in different orders. In addition, the summarized operations are provided only as examples, and some operations may be optional, combined into fewer steps and operations, supplemented into further operations or expanded into additional operations without departing from the essence of the embodiments of the present disclosure.

[0124] Without departing from the spirit or features of the present invention, the present invention may be implemented in other specific forms. The described embodiments should be considered in all respects only as illustrative and not restrictive. Therefore, the scope of the present invention is indicated by the appended claims rather than the preceding description. All changes falling within the equivalent meaning and scope of the claims should be included within their scope.

Claims

1. A computing system that inserts media data into existing media data to ensure that the inserted media data is not accessible to all users, the computing system comprising: one or more hardware processors; as well as one or more computer-readable media having computer-executable instructions thereon that, when executed by the one or more hardware processors, are structured to configure the computing system to: receiving a first portion of media data; granting access to the first portion of media data to a plurality of users, the access being based at least in part on a decentralized identifier (DID) associated with each of the plurality of users; as well as receiving a second portion of media data, the second portion of media data being inserted into the first portion of media data, the second portion of media data being accessible only to a subset of the plurality of users that have access to the first portion of media data, wherein access to the second portion of media data is also based at least in part on the DID of each user in the subset of users, The computing system is implemented in a decentralized network implementing a distributed ledger, wherein the distributed ledger is configured to support one or more decentralized identifiers DID for the plurality of users. 2 . The computing system of claim 1 , wherein the access to the first portion of media data is further based on a set of permissions associated with the DID of an owner of the first portion of media data.

3. The computing system of claim 1, wherein the second portion of media data is placed in a column with the first portion of media data in a user interface (UI), and the first portion and the second portion of media data are presented in the user interface (UI).

4. The computing system of claim 1 , wherein the DID associated with each of the plurality of users allows each of the plurality of users to access a public key via the decentralized network, the public key being used to decrypt the first portion of the media data at a presentation level.

5. The computing system of claim 1 , wherein the one or more hardware processors execute the computer executable instructions to further cause the computing system to: receive a third portion of the media data, the third portion of the media data being accessible to one or more additional users who do not have access to the DID.

6. The computing system of claim 1, wherein the first portion of media data and the second portion of media data comprise chat media data.

7. The computing system of claim 1, wherein the first portion of media data and the second portion of media data comprise one of: a written document, a book, an article, a blog post, or an internet page.

8. The computing system of claim 1, wherein the first portion of media data and the second portion of media data include one or more of: streaming audio data, or streaming video data.

9. A method of inserting media data into existing media data to ensure that the inserted media data is not accessible to all users, the method comprising: receiving a first portion of media data; granting access to the first portion of media data to a plurality of users, the access being based at least in part on a decentralized identifier (DID) associated with each of the plurality of users; as well as receiving a second portion of media data, the second portion of media data being inserted into the first portion of media data, the second portion of media data being accessible only to a subset of the plurality of users that have access to the first portion of media data, wherein access to the second portion of media data is also based at least in part on the DID of each user in the subset of users, The method is performed in a computing system implemented in a decentralized network implementing a distributed ledger, wherein the distributed ledger is configured to support one or more decentralized identifiers DID for the plurality of users.

10. The method of claim 9, wherein the access to the first portion of media data is further based on a set of rights associated with the DID of an owner of the first portion of media data.

11. The method according to claim 9, wherein the second part of the media data is placed in a column with the first part of the media data in a user interface (UI), and the first part and the second part of the media data are presented in the user interface (UI).

12. The method of claim 9, wherein the DID associated with each of the plurality of users allows each of the plurality of users to access a public key via the decentralized network, the public key being used to decrypt the first portion of media data at a presentation level.

13. The method according to claim 9, further comprising: A third portion of the media data is received, the third portion of the media data being accessible to one or more additional users that do not have access to the DID.

14. The method of claim 9, wherein the first portion of media data and the second portion of media data comprise chat media data.

15. The method of claim 9, wherein the first portion of media data and the second portion of media data comprise one of: a written document, a book, an article, a blog post, or an internet page.

16. The method of claim 9, wherein the first portion of media data and the second portion of media data comprise one or more of: streaming audio data, or streaming video data.

Images