Decentralized creation of attestation

Abstract

Embodiments described herein are generally directed to decentralized creation of attestation. According to one embodiment, a blockchain and a smart contract are maintained by a creator service, the smart contract including a social decentralized identifier (DID) contract, and a plurality of creator contracts owned and controlled by respective creators. A first social DID for a creator of a digital article is created on a blockchain via a social DID contract. Based at least in part on the first social DID, a decentralized creation attestation (e.g., a non-homogenous token (NFT)) for the digital article is created on the blockchain via a creator contract of the plurality of creator contracts deployed by or on behalf of the creator.

Description

Technical Field

[0001] The embodiments described herein relate generally to the field of identity authentication and proving ownership of digital artifacts, and more specifically, to solutions that enable creators of digital artifacts and purchasers / users of digital artifacts to assert their identities using decentralized identities that are not tied to any particular non-fungible token (NFT) market. Background Art

[0002] A non-fungible token (NFT) is a unique cryptographic token recorded on a blockchain. Once minted, NFTs are immutable, making them useful for symbolizing ownership (much like ownership of a car), proving authenticity, and / or otherwise representing digital or physical assets based on the issuer and associated metadata. NFTs can be monetized (e.g., sold, traded, leased, etc.). For example, ownership of an NFT is recorded on a blockchain and can be transferred from the owner (initially usually the creator) to the purchaser. An NFT marketplace is an online marketplace (or digital platform) that facilitates the purchase, sale, and / or trading of NFTs. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The embodiments described herein are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references refer to similar elements.

[0004] Figure 1 is a block diagram illustrating an operating environment for creating a certification facilitator service in accordance with some embodiments.

[0005] Figure 2 is a flow diagram illustrating operations for facilitating decentralized creation of proofs in accordance with some embodiments.

[0006] Figure 3 is a flow diagram illustrating operations for creating a proof of creation in accordance with some embodiments.

[0007] Figure 4 is a flow diagram illustrating operations for creating a social decentralized identifier (DID) according to some embodiments.

[0008] Figure 5 is a flow diagram illustrating operations for monetizing NFTs minted by a Creation Proof Facilitator service in accordance with some embodiments.

[0009] Figure 6 is a flow diagram illustrating operations for purchasing NFTs minted by a Creation Proof Facilitator service in accordance with some embodiments.

[0010] Figure 7 is an example of a computer system that some embodiments may utilize. DETAILED DESCRIPTION

[0011] The embodiments described herein are generally directed to decentralized proof of creation. Existing centralized NFT markets generally operate like app stores (e.g., Apple App Store, Samsung Galaxy, Google Play, etc.), making it impossible for creators of digital artifacts (e.g., digital paintings, three-dimensional (3D) models, etc.) to assert their ownership and maintain control over the monetization of their creations and / or their derivatives. In addition, the identity review procedures employed by such markets are exclusive to that market, essentially locking creators into that market.

[0012] While several decentralized NFT markets have emerged with the intent to break or “decentralize” traditional “centralized” online markets, various limitations remain. For example, while decentralized NFT markets such as Opensea and the like have been created with a decentralized spirit, surprisingly, they leave little, if any, control to the creator. While these decentralized NFT markets may mint NFTs on the blockchain for each digital artifact to uniquely identify it, they retain control over the blockchain smart contracts that mint the NFTs, thereby maintaining full control over the monetization terms—just like centralized NFT markets. At the same time, there are several public instances where such decentralized NFT markets have unilaterally changed the monetization terms of creators or censored some creators. In addition, in order for creators to list their creations for sale in a given decentralized NFT market, creators need to upload their original creations to a third-party market server, which essentially forces the creator to lose control of their creations.

[0013] There are also problems from the buyer / user's perspective. For example, the buyer / user does not have direct access to the proof of creation from the creator of a given digital artifact. Instead, the buyer / user must trust the creator identity vetting process of the decentralized NFT market in question. At the same time, these proofs of creation are tied to a specific decentralized NFT market - again leading to market lock-in. Further, there is no visibility for the buyer / user into various sources, such as generative artificial intelligence (AI), or whether the sources used by the creator have been authorized by their corresponding underlying creators.

[0014] The various embodiments described herein seek to address or at least mitigate one or more of the limitations of the existing decentralized NFT market by introducing decentralized proof of creation. As further described below, according to one embodiment, a proof of creation facilitator service maintains a blockchain and a smart contract, which includes a social decentralized identifier (DID) contract, and multiple creator contracts owned and controlled by the corresponding creator (e.g., one for each creator / digital artifact pair, or one for each creator). A first social DID is created on the blockchain for the creator of a digital artifact via a social DID contract. Then, based at least in part on the first social DID, a decentralized proof of creation for a digital artifact (e.g., an NFT) is created and persisted to the blockchain via a creator contract in multiple creator contracts deployed by or on behalf of the creator.

[0015] Although various examples are described herein with reference to the use of Ethereum Request for Comment 721 (ERC-721) NFTs and / or ERC-1155 smart contracts and the Ethereum blockchain, it should be appreciated that the methods described herein are generally applicable to NFTs issued by other token standards (e.g., Binance Smart Chain Evolution Proposal 20 (BEP-721)), smart contracts that facilitate the management of NFTs issued by other token standards (e.g., BEP-1155), and other blockchains (e.g., the former BNB Smart Chain (BCS), Binance Smart Chain, as well as Polygon, Klayton, Solana, Arbitrum, Optimism, Avalanche, Zora, Foundation Blockchain, etc.).

[0016] In the following description, numerous specific details are set forth in order to provide a thorough understanding of example embodiments. However, it will be apparent to one skilled in the art that the embodiments described herein may be practiced without some of these specific details. the term

[0017] The terms "connected" or "coupled" and related terms are used in an operational sense and are not necessarily limited to direct connections or couplings. Thus, for example, two devices may be coupled directly, or via one or more intermediate media or devices. As another example, devices may be coupled in such a way that information may be transferred between them while not sharing any physical connection with each other. Based on the disclosure provided herein, one of ordinary skill in the art will appreciate the various ways in which there are connections or couplings according to the foregoing definitions.

[0018] If the specification states a component or feature "may," "might," "could," or "can" be included or have a property, that particular component or feature is not required to be included or have that property.

[0019] As used in the description herein and throughout the claims that follow, the meanings of "a", "an", and "the" include plural references unless the context clearly dictates otherwise. Additionally, as used in the description herein, the meaning of "in" includes "in" and "on", unless the context clearly dictates otherwise.

[0020] As used herein, "digital artifacts" generally refer to anything that exists only in digital form and has different usage rights or different usage licenses. Non-limiting examples of digital artifacts include graphic artwork (e.g., digital drawings or paintings), 3D models, digital music, software code, digital photography, digital video, digital movies, poetry, books, digital game items, virtual worlds, digital trading cards, and other online collectibles or other valuable data and code stored in digital form.

[0021] As used herein, "non-fungible tokens" or "NFTs" generally refer to cryptographic assets (digital representations of value that can be transferred, stored, or traded electronically) on a blockchain that have unique identification codes and metadata that distinguish them from one another. NFTs are unique cryptographic tokens that can represent digital artifacts that have been tokenized by a blockchain. NFTs can be traded and exchanged for currency, cryptocurrency, or other NFTs, depending on the market and the value that the owner places on them. The difference between cryptocurrencies (which are also cryptographic tokens) is that two cryptocurrencies from the same blockchain are interchangeable - they are fungible. In contrast, while two NFTs from the same blockchain may look the same, they are not interchangeable. ERC-721 and ERC-1155 are the most popular NFT standards on the Ethereum network.

[0022] As used herein, “non-fungible token marketplace” or “NFT marketplace” generally refers to an online marketplace through which NFTs can be purchased, sold, rented, and / or traded.

[0023] As used herein, "blockchain" generally refers to a digital database or ledger that maintains a secure, immutable, and decentralized record of transactions in the form of blocks linked together via cryptography and distributed among nodes of a peer-to-peer network. Non-limiting examples of blockchains include Ethereum, Polygon, Klaytn, Solana, Arbitrum, Optimism, Avalanche, BNB, Zora, and Base blockchains.

[0024] As used herein, "blockchain smart contracts" or simply "smart contracts" generally refer to code written into a blockchain that executes the terms of an agreement or contract from outside the chain. Smart contracts are programmed to execute automatically when certain conditions are met and can be used for a variety of purposes, including but not limited to buying, selling, leasing, or trading NFTs and minting NFTs. Smart contracts can automate actions that would otherwise be completed by the parties to an agreement or contract, thereby removing the need for the parties to trust each other and reducing or eliminating the need for third-party intermediaries.

[0025] As used herein, "creator" generally refers to a person who produces a digital artifact.

[0026] As used herein, “decentralized identifier” or “DID” generally refers to an identifier that enables a verifiable decentralized digital identity. A DID can refer to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.). The decentralized aspect of a DID refers to the elimination of the requirement for centralized institutions or single points of failure in identifier management, which includes registration of globally unique identifiers, public verification keys, services, and other information. Compared to typical federated identifiers, DIDs are designed so that they can be decoupled from centralized registries, identity providers, certificate authorities, and online marketplaces (e.g., NFT marketplaces). DIDs give subjects the power to directly control their DIDs without relying on external institutions. DIDs are typically associated with a public key (e.g., the public part of an asymmetric key pair that may be contained within the DID) and a private key (e.g., the private part of an asymmetric key pair protected by the subject). Non-limiting examples of DIDs are represented by Decentralized Identifier (DID) v1.0 Manu Spooni; Amy Guy; Marcus Sabadello; Drummond Reed. W3C. 19 July 2022. W3C Recommendation. Uniform Resource Locator (URL): https: / / www.w3.org / TR / did-core) Description, the entire contents of which are incorporated herein by reference for all purposes.

[0027] As used herein, a "social decentralized identifier" or "social DID" generally refers to a DID that can be verified by a subject's social media account (or linked to a subject's social media account). For example, a social DID can be mapped to a verifiable social identity statement made by a person through a social media handle (or social media identity) associated with their social media account (e.g., Facebook account, Twitter account, Instagram account, etc.), which establishes the person (associated with a specific social media identity) as the creator or owner of a specific digital artifact. In the various examples described herein, it is expected that each creator has a social media account followed by their fans. As further described below, a creator can create a verifiable social identity statement by issuing a social media post containing their DID public key. Then, when the creator's DID is created, a link to the social media post (e.g., a uniform resource locator (URL)) can be mapped to a DID in a smart contract (e.g., a social DID contract). In this way, a social DID is effectively guaranteed by a third-party social media account through which a social identity statement is made.

[0028] As used herein, "proof of creation" of a digital artifact generally refers to proof that the digital artifact was created by a known entity. A non-limiting example of proof of creation of a digital artifact is an NFT caused by the creator of the digital artifact through a proof of creation facilitator service, the NFT including metadata related to the digital artifact and identifying the creator as the creator (e.g., by reference to the creator's social DID).

[0029] As used herein, "decentralized proof of creation" generally refers to a proof of creation that is not tied to any particular NFT marketplace. For example, in various embodiments described herein, a decentralized proof of creation for a given digital artifact may be created by a third-party service (e.g., a proof of creation facilitator service) that is separate and independent of any particular NFT marketplace and uses a social DID.

[0030] As used herein, a "peer-to-peer file sharing network" or "P2P file sharing network" generally refers to a network through which participating computer systems can share files or digital artifacts. A non-limiting example of a P2P file sharing network is the InterPlanetary File System (IPFS).

[0031] As used herein, "cloud" or "cloud environment" refers broadly and generally to a platform through which cloud computing can be delivered via a public network (e.g., the Internet) and / or a private network. The National Institute of Standards and Technology (NIST) defines cloud computing as "a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be quickly provided and released with minimal management effort or service provider interaction" (P. Mell, T. Grance, NIST Cloud Computing Definition, National Institute of Standards and Technology, 2011). The cloud infrastructure can be deployed according to various deployment models, including private clouds, community clouds, public clouds, and hybrid clouds. In the private cloud deployment model, the cloud infrastructure is provided for exclusive use by a single organization including multiple consumers (e.g., business departments), and can be owned, managed, and operated by an organization, a third party, or a combination thereof, and can exist internally or externally. In a community cloud deployment model, cloud infrastructure is provided for exclusive use by a specific community of consumers from organizations with shared concerns (e.g., missions, security requirements, policies, and compliance considerations), may be owned, managed, and operated by one or more of the organizations in the community, a third party, or a combination thereof, and may exist on-premises or off-premises. In a public cloud deployment model, cloud infrastructure is provided for open use by the general public, may be owned, managed, and operated by a cloud service provider (e.g., a commercial, academic, or government organization, or a combination thereof), and exists on the premises of the cloud service provider. A cloud service provider may provide cloud-based platform, infrastructure, application, or storage services as a service according to a variety of service models, including Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and / or Infrastructure-as-a-Service (IaaS). In a hybrid cloud deployment model, the cloud infrastructure is a composite of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technologies that enable portability and mobility of data and applications (e.g., cloud bursting for load balancing between clouds).

[0032] As used herein, a "network link," or simply a "link," generally refers to the address of a resource, such as on a network or within a P2P file sharing network, depending on the context of use. Non-limiting examples of links include a uniform resource identifier (URI), a uniform resource locator (URL), and a content identifier (CID) (or content address), such as an IPFS hash.

[0033] As used herein, the terms "module", "component", "engine", "service", etc. are intended to refer to a computer-related entity: software executing a general-purpose processor, hardware, firmware, or a combination thereof. For example, a module or component can be, but is not limited to, a process, an executable file, an execution thread, a program, and / or a computer running on a computing resource. Example operating environment

[0034] Figure 1 1 is a block diagram illustrating an operating environment 100 for a creation proof facilitator service according to some embodiments. According to one embodiment, in order to ensure that there is no middleman exerting control over the creator's creation, the proposed creation proof facilitator service (e.g., creation proof facilitator service 120) includes multiple blockchain smart contracts. The creation proof facilitator service 120 can represent a service hosted by a public cloud (not shown) (e.g., Amazon Web Services, Microsoft Azure, Google Cloud Platform, etc.) and accessible to end customers via a SaaS delivery model.

[0035] The proof of creation facilitator service 120 can be represented by a blockchain 130, a plurality of smart contracts stored thereon, and a web user interface (not shown), through which end users of the service (e.g., creators and potential purchasers or buyers) interact with the smart contracts. In one embodiment, the web user interface is published to the P2P file sharing network 110 and can be accessed at a content identifier representing a unique immutable address of content based on the web user interface. Such an immutable address assures the end user that the web user interface has not been modified or tampered with, and is therefore the original website used by a given creator (e.g., creator 101) to cast a given NFT (e.g., NFT 135), which can represent proof of creation of a given digital artifact (e.g., digital artifact 161) and ownership of a given digital artifact.

[0036] As further described below, in one embodiment, the creation proof facilitator service 120 can utilize the social media platform 160 (e.g., Facebook, Twitter, Instagram, etc.) to act as the underlying identity confirmation mechanism for the social DIDs generated for end users (e.g., creators of digital artifacts and purchasers / users of digital artifacts) via the creation proof facilitator service 120.

[0037] The blockchain 130 may be used to store a social DID contract 150 deployed by or on behalf of the owner of the proof of creation facilitator service 120. The blockchain 120 may also be used to store a creator contract (e.g., creator contract 140) deployed by or on behalf of each creator (e.g., creator 101) that has been assigned a social DID by the social DID contract 150 for each digital artifact (e.g., digital artifact 151) created by the creator. For example, a given creator contract (e.g., creator contract 140) may be deployed from a wallet (e.g., Ethereum wallet) of a given creator (e.g., creator 101) that is compatible with the blockchain 130 and is therefore controlled by a private key owned by the given creator. In one embodiment, the blockchain 130 may represent the Ethereum blockchain; however, it should be understood that any blockchain that supports smart contracts may be used.

[0038] The social DID contract 150 can represent a smart contract deployed by the creation proof facilitator service 120. In the context of the various embodiments described herein, all end users of the creation proof facilitator service 120 (e.g., creators of digital artifacts and purchasers / users of digital artifacts) are expected to have an identity in the form of a social DID. This identity is used to establish who created or owns a particular digital artifact, for example, by initially associating the creator's social DID with the creator field and owner field of the metadata of the NFT minted for the particular digital artifact, and changing the owner field to reference the social DID of any subsequent purchaser. According to one embodiment, an end user can create a social DID by calling the social DID contract 150 with information from a social media platform 160, which can be used to link the end user's social identity or social media handle on the social media platform 160 with the social DID. Reference is made below to Figure 4 Non-limiting examples of creation of social DIDs are further described.

[0039] The creator contract 140 may represent a smart contract running on the blockchain 120 that is responsible for minting one or more NFTs (e.g., NFT 135) on behalf of the creator 101 for a given digital artifact (e.g., digital artifact 161) created by the creator 101, and controlling access to the given digital artifact via one or more NFTs (e.g., representing ownership (or ownership interest) of the given digital artifact). For example, the creator contract 140 may enforce various policies specified by the creator 101 as part of determining the permissibility of a particular transaction (e.g., purchase or lease) of the digital artifact 161, or otherwise executing and completing a particular transaction (e.g., purchase or lease). Non-limiting examples of such policies include terms of sale, lease terms, derivative use terms, and who is allowed to purchase / use a given digital artifact (e.g., geographic restrictions).

[0040] In the context of this example, assuming that creator 101 has created digital artifact 161 and wishes to monetize (e.g., sell, rent, or trade) digital artifact 161, creator 101 may store digital artifact 162 in a private online data safe (e.g., data safe 160a). Additionally, as described above, creator 101 is expected to have a social DID, which may be created by social DID contract 160 and may be associated with a verifiable social identity claim (e.g., social identity claim 171) through social DID contract 160, for example, as described below with reference to Figure 4 Further described. In addition, creator 101 can deploy a creator contract 140 on blockchain 130, which can be used to mint NFT 135, which represents a decentralized proof of creation of digital artifact 161, for example, by referencing creator 101's social DID to identify creator 101 as both the creator and owner of digital artifact 161. Figure 2 and Figure 3 Further details are described regarding facilitating decentralized creation of proofs, including, for example, creating metadata 121 related to a digital artifact 161 , publishing the metadata 121 to a P2P file sharing network 110 , and minting an NFT 135 .

[0041] After successfully creating NFT 135, creator 101 may publish the address of NFT 135 on an NFT marketplace (not shown) via a corresponding NFT decentralized application (dApp) 111 hosted in P2P file sharing network 110, and notify his / her fans and potential purchasers of the availability of NFT 135 for purchase, rental, or trading, for example, via social media (e.g., as part of a post on social media platform 170 and / or one or more other social media platforms), email, text message, or other electronic means. Figure 5 Describe further details regarding monetization of digital artifacts.

[0042] Assuming that buyer 102 wishes to purchase digital artifact 161 (via acquisition of NFT 135), buyer 102 is also expected to have a social DID, which can be created by social DID contract 160 and can be associated with a verifiable social identity claim through social DID contract 160, for example, as described below with reference to Figure 4 The purchaser 102 may then utilize the creator contract 140 and the user interface (UI) of the NFT dApp 112 to verify and / or purchase the NFT 135, including depositing funds, securely transferring the digital artifact 161 from the data safe 160a to the purchaser's 102 private online data safe (e.g., data safe 160b), and updating the ownership of the digital artifact 161, as described below with reference to Figure 6 Non-limiting examples of data safes 160a-b include a data storage and message relay mechanism entity or identity hub, for example, as defined in the Decentralized Identity Foundation (DIF) Identity Hub specification currently available at https: / / identity.foundation / decentralized-web-node / spec / 0.0.1-predraft / .

[0043] Although in the context of this example, for simplicity, a given creator contract (e.g., creator contract 140) is described as having a one-to-one relationship with a given digital artifact (e.g., digital artifact 151) created by a given creator (e.g., creator 101), it should be appreciated that in alternative embodiments, a one-to-many relationship may exist between creator contracts and digital artifacts. Similarly, although only a single creator 101 and a single purchaser 102 are shown, it should be appreciated that the end users of the creation proof facilitator service 120 may include multiple creators and purchasers.

[0044] The various software components described herein (e.g., the creation proof facilitator service 120, the blockchain 130, the creator contract 140, the social DID contract 150, and the data safes 160a-b, and the social media platform 170), and the processes described below) may be implemented in the form of executable instructions stored on one or more machine-readable media and / or in the form of other types of electronic circuitry, the executable instructions being executed by one or more processing resources (e.g., microcontrollers, microprocessors, CPU cores, CPUs, GPUs, xPUs, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), etc.). For example, the processes may be executed by various forms of one or more virtual or physical computer systems (such as, for example, those described below with reference to Figure 7 The computer system described herein is executed. Example decentralized proof of creation

[0045] Figure 2 is a flow chart illustrating operations for facilitating decentralized creation of proofs according to some embodiments. Figure 2 The described process may be performed using a creation certification facilitator service (eg, creation certification facilitator service 120).

[0046] At box 210, a blockchain (e.g., blockchain 130) and a plurality of smart contracts are maintained by a creation proof facilitator service. Smart contracts may include a creator contract (e.g., creator contract 150) and a social DID contract (e.g., social DID contract 160). In one embodiment, the social DID contract is owned by the operator of the creation proof facilitator service and deployed on the blockchain by the operator of the creation proof facilitator service, while the creator contract is owned by the creator (e.g., creator 101) of a given digital product (e.g., digital product 161) and deployed on the blockchain by the creator (e.g., creator 101) of the given digital product (e.g., digital product 161), thereby excluding changes to the monetization terms or conditions related to the given digital product by a third party or entity (e.g., the operator of the creation proof facilitator service, the NFT market on which the given digital product is listed for sale, etc.). As described above, in one embodiment, the creator contract can be deployed from the creator's Ethereum wallet so that the creator contract is controlled by a private key owned by the creator. In one embodiment, a creator can deploy a creator contract on the blockchain for each digital artifact he / she wishes to monetize. Alternatively, there may be a one-to-many relationship between creator contracts and digital artifacts.

[0047] At block 220, a first social DID is created for the creator on the blockchain via the social DID contract. According to one embodiment, the creator may invoke the social DID contract by its unique identity (e.g., its script hash) and providing appropriate input parameters (e.g., a public key of an asymmetric key pair associated with the first social DID). In one embodiment, the first social DID may represent a DID associated with a verifiable social identity claim (e.g., social identity claim 161). For example, as described below with reference to Figure 4 As further described, during creation of the first social DID, the social DID contract may persist an immutable record of a mapping between the first social DID and the verifiable social identity claim to the blockchain.

[0048] At box 230, a proof of creation is created for the digital artifact. According to one embodiment, the creator calls a creator contract associated with the digital artifact to create a decentralized proof of creation for the digital artifact, which is, for example, in the form of a newly minted NFT (e.g., NFT 135) that is stored on a blockchain and represents ownership of the digital artifact. The NFT may include metadata related to the digital artifact, the metadata including, in addition to other information for the fields, information identifying a known entity (in this case, creator 101) as the creator of the digital artifact. For example, the metadata may include a creator field that references a first social DID. Using a social DID that is not tied to any NFT marketplace as part of the decentralized proof of creation also makes the decentralized proof of creation independent of any NFT marketplace and makes the decentralized proof of creation accessible to and verifiable by any end user of the proof of creation facilitator service. Reference is made below to Figure 3 A non-limiting example of creation of a proof of creation by a creator contract is further described. Example Creation Proof of Creation

[0049] Figure 3 is a flow chart illustrating operations for creating a proof of creation according to some embodiments. Figure 3 The process described is shown in Figure 2, and may be performed using a creation proof facilitator service (e.g., creation proof facilitator service 120). In the context of this example, assume that a creator (e.g., creator 101) of a digital artifact (e.g., digital artifact 161) has stored an original version of the digital artifact in a first data safe (e.g., data safe 160a) and has created metadata describing the digital artifact (e.g., metadata 121). The metadata describing the digital artifact may include, among other information and / or fields, a name of the digital artifact, a description of the digital artifact, a link to a reduced or low-resolution copy of the digital artifact, a zero-knowledge proof that the reduced or low-resolution image is an image of the original digital artifact owned by the creator, an identity of the creator of the digital artifact (e.g., a social DID), and / or an identity of an owner of the digital artifact, and may be stored in a metadata file.

[0050] At block 310, metadata describing the digital artifact is published to a P2P file sharing network (e.g., P2P file sharing network 110) for permanent storage. In one embodiment, in addition to publishing the metadata to the P2P file sharing network, the creator may also publish a reduced or low-resolution image of the digital artifact to the P2P file sharing network. A non-limiting example of a P2P file sharing network is IPFS.

[0051] At box 320, a creator contract (e.g., creator contract 150) deployed by the creator on the blockchain of the creation proof facilitator service (e.g., blockchain 130) can be called by the creator to mint an NFT (e.g., NFT 135) to represent the creation and ownership of the digital artifact. In one embodiment, the input parameters of the minting function of the creator contract may include a link to metadata stored on the P2P file sharing network and a link to a first data safe storing the digital artifact (e.g., a link to the digital artifact contained in the first data safe, which may contain multiple digital artifacts, whether the multiple digital artifacts are created or purchased). After successfully creating the NFT (including two links), the NFT is stored on the blockchain, and the creator contract can return the address of the NFT on the blockchain to the creator. Example Social DID Creation

[0052] Figure 4 is a flow diagram illustrating operations for creating a social decentralized identifier (DID) according to some embodiments. Figure 4The described process can be performed by leveraging the creation of a proof facilitator service (e.g., creation proof facilitator service 120). End users of the facilitator service proof (e.g., creator 101 and purchaser 102) are expected to have a social DID before they can participate in minting NFTs and / or transactions related to NFTs.

[0053] At block 410, an end user (e.g., creator 101 or purchaser 102) of the creation proof facilitator service (e.g., creation proof facilitator service 120) can make a social media statement or social identity statement (e.g., social identity statement 171) in the following form, for example: a social media post containing the public key of the asymmetric key pair that will be associated with their social DID, or a social media post signed with the private key of the asymmetric key pair that will be associated with their social DID.

[0054] At block 420, the social DID contract (e.g., social DID contract 160) creates a social DID containing the public key for the end user. For example, the creator can call the minting function of the social DID contract with input parameters (including the public key and a link to the social identity statement), and based on this, the social DID contract can generate a new social DID for the creator, store the new social DID on the blockchain, and return the address of the new social DID to the creator. A non-limiting example of the format of the social DID is DID::<Proof of Creation Facilitator Service Operator>:SocialDIDContractAddress::DIDNumber.

[0055] At block 430, during the minting function, the social DID contract can also create a mapping between the social identity statement and the social DID by persisting a record containing the link to the social identity statement to the blockchain, thereby allowing other end users to verify the end user who owns the private key associated with the social DID as the same end user as the one who made the social identity statement on the social media platform (e.g., social media platform 170). Example NFT Monetization

[0056] Figure 5 is a flowchart illustrating operations for monetization of an NFT (e.g., NFT 135) minted by a creation proof facilitator service (e.g., creation proof facilitator service 120). Refer to Figure 5The described process may be performed, at least in part, by a creator (e.g., creator 101) utilizing operating environment 100. In the context of this example, it is assumed that the creator has created a digital artifact (e.g., digital artifact 161), stored the original content of the digital artifact in a private data safe (e.g., data safe 160a), created a social DID (e.g., based on Figure 4 ), a decentralized proof of creation is created for digital artifacts in the form of NFT135 (e.g., based on Figure 3 ), and now hopes to monetize NFTs.

[0057] At box 510, the creator publishes the address of the NFT as part of an NFT decentralized application (dApp) hosted by a P2P file sharing network (e.g., P2P file sharing network 110) and through which the corresponding NFT marketplace can be accessed.

[0058] At box 520, the creator may then advertise the availability of the NFT for purchase, rental, or trading by, for example, sharing a link to the NFT dApp with fans and potential purchasers via social media (e.g., as part of a post on a social media platform (e.g., social media platform 170) and / or one or more other social media platforms), email, text message, or other electronic means. Example NFT Purchase

[0059] Figure 6 is a flow diagram illustrating operations for purchasing an NFT (e.g., NFT 135) minted by a proof of creation facilitator service (e.g., proof of creation facilitator service 120) in accordance with some embodiments. Figure 6 The described process may be performed at least in part by a purchaser (e.g., purchaser 102) utilizing operating environment 100. Assuming that purchaser 102 wishes to purchase a digital artifact (purchasing digital artifact 161 via acquisition of NFT 135), purchaser 102 is also expected to have a social DID, which may be created by social DID contract 160 and may be associated with a verifiable social identity claim through social DID contract 160, for example, as described above with reference to Figure 4 The buyer 102 can then utilize the creator contract 150 and the user interface (UI) (e.g., NFT dApp UI 112) of the NFT dApp (e.g., NFT dApp 111) of the corresponding NFT marketplace to which the creator of the digital artifact (e.g., creator 101) has listed the NFT to verify and / or purchase the NFT, for example via a purchase button presented by the NFT dApp.

[0060] At box 610, the buyer can view the NFT details and verify the source and / or ownership of the digital product. For example, the buyer can view the owner field to confirm the current owner, and can view the creator field to confirm the source of the digital product. The buyer can also verify the digital product originating from the creator based on the public key of the asymmetric key pair, for example, by verifying the social identity statement (e.g., social identity statement 171) made by the creator on a social media platform (e.g., social media platform 170). In addition or alternatively, the buyer can issue an identity challenge to the claimed creator, and the creator can respond to it with an identity statement signed by the private key of the asymmetric key pair associated with the creator's social DID. The buyer can then verify the identity statement using the public key of the asymmetric key pair associated with the creator's social DID. The buyer can also obtain other NFT details from the creator's private data safe (e.g., data safe 160a) by signing the request with the private key of the asymmetric key pair associated with the buyer's social DID, such as discounts, prices, etc. provided by the creator for frequent buyers, and other configured policies.

[0061] At box 620, assuming the purchaser wants to proceed with the purchase of the NFT, the purchaser deposits funds into the creator's smart contract (e.g., creator contract 150) and retrieves a link to the creator's data safe where the digital artifact is stored.

[0062] At box 630, the purchaser initiates a transfer of the digital artifact from the creator's data safe to the purchaser's data safe (e.g., data safe 160b). For example, the purchaser can call the transfer function of the creator's smart contract, providing a link to the purchaser's data safe as an input parameter. In response to the purchaser's request, the purchaser's data safe can establish a trusted connection with the creator's data safe, the creator's data safe can check with the creator's smart contract to verify whether there is a deposit entry for the NFT from the purchaser's social DID, and once verified, the creator's data safe transfers the digital asset to the purchaser's data safe (and in the case of IPFS, the purchaser should lock the NFT metadata).

[0063] At box 640, after the digital artifact has been successfully transferred to the purchaser's data safe, the purchaser releases the funds from the escrow, for example by signing the transaction with their crypto wallet (e.g., Metamask, etc.), and the creator's smart contract then updates the ownership of the NFT to reflect the purchaser as the new owner by updating the owner field of the NFT's metadata to reference the purchaser's social DID and updating the link to the original version of the digital artifact to a link to the purchaser's data safe where the original digital artifact is now stored.

[0064] According to one embodiment, the creator's smart contract can also emit events that the creator can listen to and pull funds into his / her wallet. In addition, as will be appreciated by those skilled in the art, any transaction related to the digital artifact becomes part of the transfer history of the NFT and can be accessed by any future purchaser who wishes to view the transfer history.

[0065] Although in the context of this example, reference Figure 2-Figure 6 The flowchart of the present invention includes a plurality of enumerated blocks, but it should be understood that the example can include additional blocks before, after and / or between the enumerated blocks. Similarly, in some examples, one or more of the enumerated blocks can be omitted and / or executed in a different order. Example Computer System

[0066] Figure 7 700 may be an example of a computer system 700 that may be utilized by some embodiments. Computer system 700 may represent some, all, or a subset of the components of one or more computer systems on which a creation proof facilitator service (e.g., creation proof facilitator service 120) is run and / or a client computer system is utilized by an end user of the creation proof facilitator service (e.g., creator 101 or purchaser 102). It is worth noting that the components of computer system 700 described herein are intended only to illustrate various possibilities. Example computer system 700 should in no way limit the scope of the present disclosure. In the context of this example, computer system 700 includes a bus 702 or other communication mechanism for communicating information, and processing resources (e.g., one or more hardware processors 704) coupled to bus 702 for processing information. The processing resources may be, for example, one or more general purpose microprocessors or system on a chip (SoC) integrated circuits.

[0067] The computer system 700 also includes a main memory 706 (such as a random-access memory (RAM) or other dynamic storage device) coupled to the bus 702 for storing information and instructions to be executed by the processor 704. The main memory 706 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by the processor 704. Such instructions, when stored in a non-transitory storage medium accessible to the processor 704, present the computer system 700 as a special-purpose machine customized to perform the operations specified in the instructions.

[0068] The computer system 700 further includes a read only memory (ROM) 708 or other static storage device coupled to the bus 702 for storing static information and instructions for the processor 704. A storage device 710 (e.g., a magnetic disk, an optical disk, or a flash drive (made of flash memory chips)) is provided and coupled to the bus 702 for storing information and instructions.

[0069] The computer system 700 may be coupled to a display 712, such as a cathode ray tube (CRT), a liquid crystal display (LCD), an organic light-emitting diode display (OLED), a digital light processing display (DLP), etc., via the bus 702 for displaying information to a computer user. An input device 714 including alphanumeric and other keys is coupled to the bus 702 for communicating information and command selections to the processor 704. Another type of user input device is a cursor control 716, such as a mouse, a trackball, a touch screen, a touch pad, or cursor direction keys, for communicating direction information and command selections to the processor 704 and controlling cursor movement on the display 712. The input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), which allows the device to specify a position in a plane.

[0070] The removable storage medium 740 may be any type of external storage medium, including but not limited to a hard disk drive, a floppy disk drive, Zip drives, Compact Disc–Read Only Memory (CD-ROM), Compact Disc–Re-Writable (CD-RW), Digital Video Disk–Read Only Memory (DVD-ROM), universal serial bus (USB) flash drives, etc.

[0071] The computer system 700 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, or program logic that, in combination with the computer system, makes the computer system 700 a special purpose machine or programs the computer system 700 to be a special purpose machine. According to one embodiment, the techniques herein are performed by the computer system 700 in response to the processor 704 executing one or more sequences of one or more instructions contained in the main memory 706. Such instructions may be read into the main memory 706 from another storage medium, such as the storage device 710. Execution of the sequences of instructions contained in the main memory 706 causes the processor 704 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0072] The term "storage medium" as used herein refers to any non-transitory medium that stores data or instructions that cause a machine to operate in a specific manner. Such storage media may include non-volatile media or volatile media. Non-volatile media include, for example, optical disks, magnetic disks, or flash drives, such as storage device 710. Volatile media include dynamic memory, such as main memory 706. Common forms of storage media include, for example, floppy disks, hard disks, solid-state drives, magnetic tapes or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a pattern of holes, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or boxes.

[0073] Storage media are distinct from, but may be used in conjunction with, transmission media. Transmission media participate in the transfer of information between storage media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires that make up bus 702. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0074] Various forms of media may be involved in carrying one or more sequences of one or more instructions to the processor 704 for execution. For example, the instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to the computer system 700 may receive the data on the telephone line and use an infrared transmitter to convert the data into an infrared signal. An infrared detector may receive the data carried in the infrared signal, and appropriate circuitry may place the data on the bus 702. The bus 702 carries the data to the main memory 706, from which the processor 704 retrieves and executes the instructions. The instructions received by the main memory 706 may optionally be stored on the storage device 710 before or after execution by the processor 704.

[0075] The computer system 700 also includes an interface circuit system 718 coupled to the bus 702. The interface circuit system 718 can be implemented by hardware according to any type of interface standard, such as an Ethernet interface, a USB interface, Interface 718 may be a processor, processor, or processor that is coupled to a processor and / or processors in a manner that is communicatively coupled to one or more discrete accelerators (eg, one or more XPUs).

[0076] Interface 718 can also provide two-way data communication coupled to network link 720, and network link 720 is connected to local network 722.For example, interface 718 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem or a modem for providing a data communication connection to a telephone line of a corresponding type.As another example, interface 718 can be a LAN card for providing a data communication connection to a compatible local area network (LAN).Wireless links can also be implemented.In any such implementation, interface 718 can send and receive electrical, electromagnetic or optical signals carrying digital data streams representing various types of information.

[0077] The network link 720 generally provides data communication to other data devices through one or more networks. For example, the network link 720 can provide a connection to a host computer 724 or to a data equipment operated by an Internet Service Provider (ISP) 726 through a local network 722. The ISP 726 in turn provides data communication services through a global packet data communication network now commonly referred to as the "Internet" 728. Both the local network 722 and the Internet 728 use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link 720 and through the communication interface 718 are example forms of transmission media, and the communication interface 718 carries digital data to and from the computer system 700.

[0078] Computer system 700 may send messages and receive data, including program code, through the network(s), network link 720, and communication interface 718. In the Internet example, server 730 may transmit the requested code for an application program through Internet 728, ISP 726, local network 722, and communication interface 718. The received code may be executed by processor 704 as it is received, or stored in storage device 710 or other non-volatile storage for later execution.

[0079] Although many of the methods may be described herein in their basic form, it should be noted that processes may be added to or deleted from any of the methods, and information may be added to or subtracted from any of the described messages without departing from the basic scope of the current embodiments. It will be apparent to those skilled in the art that many further modifications and adaptations may be made. The specific embodiments are not provided to limit the concepts but to illustrate the concepts. The scope of the embodiments is not determined by the specific examples provided above, but only by the claims below.

[0080] It should be appreciated that in the above description of exemplary embodiments, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various novel aspects. However, this method of disclosure should not be interpreted as reflecting an intention that the claimed embodiments require more features than those expressly recited in each claim. On the contrary, as reflected in the appended claims, novel aspects reside in fewer features than all of the features of a single previously disclosed embodiment. Thus, the claims are hereby expressly incorporated into this specification, with each claim acting by itself as a separate embodiment.

[0081] The following clauses and / or examples refer to further embodiments or examples. Details in the examples may be used anywhere in one or more embodiments. Various features of different embodiments or examples may be combined in various ways with some features included and other features excluded to accommodate various different applications. Examples may include subject matter such as: a method; an apparatus for performing the actions of the method; at least one machine-readable medium including instructions that, when executed by a machine, cause the machine to perform the actions of the method, or the actions of an apparatus or system for operating a creation proof facilitator service according to the embodiments and examples described herein.

[0082] Some embodiments relate to Example 1, which includes a method comprising: maintaining a blockchain and a smart contract, the smart contract comprising a social decentralized identifier (DID) contract and multiple creator contracts; creating a first social DID for a creator of a digital artifact on the blockchain via the social DID contract; and creating a decentralized proof of creation for the digital artifact on the blockchain based at least in part on the first social DID via a creator contract deployed by or on behalf of the creator in the multiple creator contracts.

[0083] Example 2 includes the subject matter of Example 1, wherein creating a decentralized proof of creation for the digital artifact comprises: publishing metadata describing the digital artifact to a peer-to-peer (P2P) file sharing network, wherein the metadata includes at least the first social DID.

[0084] Example 3 includes the subject matter of Example 2, wherein creating a decentralized proof of creation for a digital artifact further includes: minting, by a creator contract, an NFT corresponding to the digital artifact based on a link to metadata and a link to a first data safe storing the digital artifact, without requiring the digital artifact to be uploaded to a non-fungible token (NFT) market associated with a P2P file sharing network.

[0085] Example 4 includes the subject matter of any of Examples 1-3, wherein the first social DID is identified by a private key-public key pair including a private key maintained by a creator and including a public key.

[0086] Example 5 includes the subject matter of Example 4, wherein creating the first social DID comprises: forming, by the social DID contract, an association between the first social DID and a connection to a social identity proof made by a creator in the form of a social media post by the creator, the social media post containing a public key or signed by a private key.

[0087] Example 6 includes the subject matter of any of Examples 1-5, further comprising: creating, via the social DID contract, on the blockchain a second social DID for the potential purchaser of the digital artifact.

[0088] Example 7 includes the subject matter of Example 6, further comprising: facilitating monetization of digital artifacts by publishing the address of the NFT to an NFT marketplace for viewing by potential purchasers.

[0089] Example 8 includes the subject matter of Example 7, further comprising: receiving, by the creator contract, funds deposited by the potential purchaser; and providing, by the creator contract, a link to the first data safe to the potential purchaser.

[0090] Example 9 includes the subject matter of Example 8, further comprising: before transferring the digital artifact from the first data safe to the second data safe of the potential purchaser, verifying, by the creator contract, the existence of a deposit entry for the NFT associated with the second social DID on the blockchain.

[0091] Example 10 includes the subject matter of Example 9, wherein current ownership of the digital artifact is identified within the metadata with reference to an owner social DID, the owner social DID initially set to the first social DID.

[0092] Example 11 includes the subject matter of Example 10, further comprising: updating the current owner social DID to the second social DID after funds are released from the escrow asset by the potential purchaser.

[0093] Example 12 includes the subject matter of Example 6, wherein interaction by creators and potential purchasers with the NFT marketplace, social DID contracts, and creator contracts is conducted via a web user interface published to a P2P file sharing network.

[0094] Example 13 includes the subject matter of any of Examples 1-12, further including: restrictions enforced by the creator contract on the types of transactions in which the digital artifact may be involved based on conditions defined by the creator and associated with the NFT.

[0095] Example 14 includes the subject matter of any of Examples 1-13, wherein the origin of the digital artifact is identified within the metadata with reference to an originator DID, the originator DID being set as the first DID, and a transfer history is maintained throughout the digital artifact.

[0096] Example 15 includes the subject matter of any of Examples 1-14, wherein the P2P sharing network is based on the InterPlanetary File System (IPFS) protocol.

[0097] Some embodiments relate to Example 16, which includes a non-transitory machine-readable medium storing instructions that, when executed by one or more processing resources of one or more computer systems, cause the one or more computer systems to: maintain a blockchain and a smart contract, the smart contract comprising a social decentralized identifier (DID) contract and multiple creator contracts; create a first social DID for a creator of a digital artifact on the blockchain via the social DID contract; and create a decentralized proof of creation for the digital artifact on the blockchain based at least in part on the first social DID via a creator contract in the multiple creator contracts deployed by the creator or on behalf of the creator.

[0098] Example 17 includes the subject matter of Example 16, wherein the creation of a decentralized proof of creation for the digital artifact comprises: publishing metadata describing the digital artifact to a peer-to-peer (P2P) file sharing network, wherein the metadata includes at least the first social DID.

[0099] Example 18 includes the subject matter of any of Examples 16 or 17, wherein the first social DID is identified by a private key-public key pair including a private key maintained by a creator and including a public key.

[0100] Example 19 includes the subject matter of Example 18, wherein creation of the first social DID comprises: forming, by the social DID contract, an association between the first social DID and a connection to a social identity claim made by a creator in the form of a social media post by the creator, the social media post containing a public key or signed by a private key.

[0101] Example 20 includes the subject matter of any of Examples 17-19, wherein the instructions further cause one or more computer systems to: enforce restrictions by the creator contract on the types of transactions in which the digital artifact may be involved based on conditions defined by the creator and associated with the NFT.

[0102] Some embodiments relate to Example 21, which includes an apparatus or system that implements or performs a method as in any of Examples 1-16.

[0103] Example 22 includes at least one machine-readable medium including a plurality of instructions that, when executed on a computing device, implement or perform the method described in any of the preceding examples or implement the apparatus described in any of the preceding examples.

[0104] Example 23 includes an apparatus comprising means for performing a method as described in any of Examples 1-16.

[0105] The accompanying drawings and the foregoing description give examples of embodiments. It will be appreciated by those skilled in the art that one or more of the elements described may be well combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, the order of the processes described herein may be changed, and the order of the processes described herein is not limited to the manner described herein. Moreover, the actions of any flowchart do not have to be implemented in the order shown; nor do they necessarily need to perform all of these actions. In addition, those actions that are independent of other actions may also be performed in parallel with other actions. The scope of each embodiment is by no means limited by these specific examples. Numerous variants (whether or not explicitly given in the specification) are possible, such as differences in the use of structure, scale, and material. The scope of the embodiment is at least as broad as the scope given by the appended claims.

Claims

1. A method, comprising: Maintaining blockchain and smart contracts, including a social decentralized identifier (DID) contract and multiple creator contracts; creating, via the social DID contract, a first social DID for a creator of a digital artifact on the blockchain; as well as Creating a decentralized proof of creation for the digital artifact on the blockchain via a creator contract of the plurality of creator contracts deployed by or on behalf of the creator based at least in part on the first social DID.

2. The method according to claim 1, wherein: Creating a decentralized proof of creation for the digital artifact includes publishing metadata describing the digital artifact to a peer-to-peer (P2P) file sharing network, wherein the metadata includes at least the first social DID.

3. The method according to claim 2, wherein: Creating a decentralized proof of creation for the digital artifact further includes: without requiring the digital artifact to be uploaded to a non-fungible token (NFT) market associated with the P2P file sharing network, the creator contract minting an NFT corresponding to the digital artifact based on a link to the metadata and a link to a first data safe storing the digital artifact.

4. The method according to claim 1, wherein: The first social DID is identified by a private key-public key pair, the private key-public key pair including a private key maintained by the creator and including a public key.

5. The method according to claim 4, wherein: Creating a first social DID includes: forming, by the social DID contract, an association between the first social DID and a link to a social identity claim made by the creator in the form of a social media post by the creator, the social media post containing the public key or signed by the private key.

6. The method according to claim 1, further comprising: A second social DID is created on the blockchain via the social DID contract for a potential purchaser of the digital artifact.

7. The method according to claim 6, further comprising: The monetization of the digital artifact is facilitated by publishing the address of the NFT to the NFT marketplace for viewing by the potential purchasers.

8. The method according to claim 7, further comprising: Receiving, by the creator contract, funds deposited by the potential purchaser; as well as A link to the first data safe is provided to the potential purchaser by the creator contract.

9. The method according to claim 8, further comprising: Prior to transferring the digital artifact from the first data safe to the potential purchaser's second data safe, the creator contract verifies the existence of a deposit entry for the NFT associated with the second social DID on the blockchain.

10. The method according to claim 9, wherein: The current ownership of the digital artifact is identified within the metadata with reference to an owner social DID, the owner social DID being initially set to the first social DID.

11. The method according to claim 10, further comprising: After the funds are released from the escrow asset by the potential purchaser, the social DID of the current owner is updated to the second social DID.

12. The method according to claim 6, wherein: Interactions by the creator and the potential purchaser with the NFT marketplace, the social DID contract, and the creator contract are conducted via a web user interface published to the P2P file sharing network.

13. The method according to any one of claims 1 to 12, further comprising: Restrictions are enforced by the creator contract on the types of transactions in which the digital artifact may be involved based on conditions defined by the creator and associated with the NFT.

14. The method according to any one of claims 1 to 12, wherein: The origin of the digital artifact is identified within the metadata with reference to an originator DID, the originator DID is set to the first DID, and a transfer history throughout the digital artifact is maintained.

15. The method according to any one of claims 1 to 12, wherein: The P2P sharing network is based on the InterPlanetary File System IPFS protocol.

16. A computer program product comprising instructions which, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 15.

17. A computer system for enabling creators of digital artifacts and purchasers / users of digital artifacts to assert their identities using a decentralized identity that is not tied to any particular non-fungible token (NFT) marketplace, the computer system comprising: one or more processors; as well as A memory, the memory being coupled to the one or more processors, the memory being used to store instructions, which, when executed by the one or more processors, cause the one or more processors to perform the method according to any one of claims 1-15.

Images