WO2022220062A1 - アートワーク管理方法、コンピュータ、及びプログラム - Google Patents

アートワーク管理方法、コンピュータ、及びプログラム Download PDF

Info

Publication number
WO2022220062A1
WO2022220062A1 PCT/JP2022/014311 JP2022014311W WO2022220062A1 WO 2022220062 A1 WO2022220062 A1 WO 2022220062A1 JP 2022014311 W JP2022014311 W JP 2022014311W WO 2022220062 A1 WO2022220062 A1 WO 2022220062A1
Authority
WO
WIPO (PCT)
Prior art keywords
artwork
document
computer
artist
identifies
Prior art date
Application number
PCT/JP2022/014311
Other languages
English (en)
French (fr)
Inventor
アフィナフ カナル
ユテ カンプマン
ジョス ダニエル ギファード－バーレイ
ミハル イェリネック
Original Assignee
株式会社ワコム
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社ワコム filed Critical 株式会社ワコム
Priority to JP2022546706A priority Critical patent/JP7180038B1/ja
Priority to CN202280022914.0A priority patent/CN117043774A/zh
Priority to EP22787987.1A priority patent/EP4296876A4/en
Publication of WO2022220062A1 publication Critical patent/WO2022220062A1/ja
Priority to JP2022183495A priority patent/JP2023143661A/ja
Priority to US18/461,381 priority patent/US20230418984A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/01—Social networking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/26—Government or public services
    • G06Q50/265—Personal security, identity or safety
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Definitions

  • the present invention relates to artwork management methods, computers, and programs.
  • SSI Self-Sovereign Identity
  • ID a decentralized identity
  • IPFS InterPlanetary File System
  • Non-Patent Document 1 describes standards for DIDs and DID documents.
  • VC Verifiable Credentials
  • VC is information containing an electronic signature obtained by encrypting the hash value of information to be certified using the issuer's private key. The person who receives the VC together with the information to be certified derives the hash value of the received information, decrypts the electronic signature with the issuer's public key, and compares the derived hash value with the decrypted electronic signature. , to verify the authenticity of the information received.
  • Non-Patent Document 2 describes the VC standard.
  • one of the objects of the present invention is to provide an artwork management method, a computer, and a program that can appropriately manage artwork by SSI.
  • An artwork management method is a computer-executed artwork management method, wherein the computer receives a request for use of a first artwork, and the computer receives the first artwork. and a second DID that is a DID that identifies a first user requesting use of the first artwork. It is a method of managing the generated artwork.
  • a computer receives a request for use of a first artwork, a first DID that identifies the first artwork, and a first DID that requests use of the first artwork.
  • a computer that generates a first DID document that is a DID document that includes a second DID that is a DID that identifies one user.
  • the program according to the present invention causes a computer to receive a request for use of a first artwork, and to provide a first DID that is a DID that identifies the first artwork and use of the first artwork.
  • artwork can be appropriately managed by SSI.
  • FIG. 1 is a diagram showing the configuration of an artwork management system 1 according to this embodiment
  • FIG. 3 is a diagram showing an example of the hardware configuration of an artist terminal 3 and a web server 4
  • FIG. FIG. 4 is a diagram showing the configuration of biometric signature data
  • 3 is a diagram showing an example of a screen of a web application 3a displayed on the display of an artist terminal 3 in which artwork 1 is to be registered.
  • FIG. 3 is a diagram showing an example of a screen of a web application 3a displayed on the display of an artist terminal 3 in which artwork 1 is to be registered.
  • FIG. 3 is a diagram showing an example of a screen of a web application 3a displayed on the display of an artist terminal 3 in which artwork 1 is to be registered.
  • FIG. 3 is a diagram showing an example of a screen of a web application 3a displayed on the display of an artist terminal 3 in which artwork 1 is to be registered.
  • FIG. 3 is a diagram showing an example of a screen of a web application 3a displayed on the display of an artist terminal 3 in which artwork 1 is to be registered.
  • FIG. 3 is a diagram showing an example of a screen of a web application 3a displayed on the display of an artist terminal 3 in which artwork 1 is to be registered.
  • FIG. 10 is a sequence diagram showing processing related to registration of a new user;
  • FIG. 10 is a sequence diagram showing a process for registering artwork 1;
  • FIG. 10 is a sequence diagram showing a process for registering artwork 1;
  • (a) is a diagram showing a configuration example of a DID document of artwork 1
  • (b) is a diagram showing the contents of a VC for artwork 1.
  • FIG. 10 is a flow diagram showing a flow of processing executed by a computer that receives artwork data of artwork 1 and VC via SNS or a sales site;
  • 3 is a diagram showing an example of a screen of a web application 3a displayed on the display of an artist terminal 3 for applying for use of artwork 1.
  • FIG. 3 is a diagram showing an example of a screen of a web application 3a displayed on the display of an artist terminal 3 for applying for use of artwork 1.
  • FIG. 3 is a diagram showing an example of a screen of a web application 3a displayed on the display of an artist terminal 3 that has received an application for using artwork 1.
  • FIG. 3 is a diagram showing an example of a screen of a web application 3a displayed on the display of an artist terminal 3 that has received an application for using artwork 1.
  • FIG. 10 is a flow diagram showing a flow of processing executed by a computer that receives artwork data of artwork 1 and VC via SNS or a sales site;
  • 3 is a diagram showing an example of a screen of
  • FIG. 3 is a diagram showing an example of a screen of a web application 3a displayed on the display of an artist terminal 3 for applying for use of artwork 1.
  • FIG. 4 is a diagram showing an example of a request list screen displayed by a web application 3a of an artist 2 who is an applicant as a result of processing performed by a web server 4.
  • FIG. 10 is a sequence diagram showing processing related to application for use of artwork 1;
  • FIG. 10 is a sequence diagram showing processing related to application for use of artwork 1;
  • (a) is a diagram showing a configuration example of a DID document of a project, and
  • (b) is a diagram showing the contents of a VC for the project.
  • FIG. 4 is a flow diagram showing the flow of processing performed by a computer that receives a project's DID document and VC via an SNS or sales site;
  • 3 is a diagram showing an example of a screen of a web application 3a displayed on the display of an artist terminal 3 for registering an artwork 2.
  • FIG. 3 is a diagram showing an example of a screen of a web application 3a displayed on the display of an artist terminal 3 for registering an artwork 2.
  • FIG. 3 is a diagram showing an example of a screen of a web application 3a displayed on the display of an artist terminal 3 for registering an artwork 2.
  • FIG. 10 is a sequence diagram showing a process for registering artwork 2;
  • FIG. 10 is a sequence diagram showing a process for registering artwork 2;
  • FIG. 10 is a sequence diagram showing a process for registering artwork 2;
  • FIG. 10 is a sequence diagram showing a process for registering artwork 2;
  • FIG. 10 is a sequence diagram showing a process for registering artwork 2;
  • FIG. 10 is a sequence diagram showing a process for registering artwork 2;
  • FIG. 10 is a sequence diagram showing a process for registering artwork 2;
  • (a) is a diagram showing a configuration example of a DID document for artwork 2
  • (b) is a diagram showing the contents of a VC for artwork 2
  • (c) is an updated project Fig. 3 shows a DID document;
  • FIG. 1 is a diagram showing the configuration of an artwork management system 1 according to this embodiment.
  • the artwork management system 1 has a configuration in which a plurality of artist terminals 3, a web server 4, a distributed file system 5, and a blockchain network 6 are interconnected via a network 2. have.
  • FIG. 2 is a diagram showing an example of the hardware configuration of the artist terminal 3 and the web server 4.
  • the artist terminal 3 and the web server 4 can each be configured by a computer 100 having the illustrated configuration.
  • the web server 4 may be configured by combining a plurality of computers 100 .
  • the computer 100 includes a CPU (Central Processing Unit) 101, a storage device 102, an input device 103, an output device 104, and a communication device 105.
  • CPU Central Processing Unit
  • the CPU 101 is a device that controls each part of the computer 100 and reads and executes various programs stored in the storage device 102 .
  • Each process described later with reference to FIGS. 3 to 31 is implemented by CPU 101 of artist terminal 3 or web server 4 executing a program stored in storage device 102 .
  • the programs executed by the CPU 101 of the artist terminal 3 include the web application 3a shown in FIG.
  • the storage device 102 includes a main storage device such as a DRAM (Dynamic Random Access Memory) and an auxiliary storage device such as a hard disk. serves to store data used by programs in a main storage device.
  • a main storage device such as a DRAM (Dynamic Random Access Memory)
  • an auxiliary storage device such as a hard disk. serves to store data used by programs in a main storage device.
  • the input device 103 is a device that receives a user's input operation and supplies it to the CPU 101, and includes, for example, a keyboard, a mouse, and a touch detection device.
  • the touch detection device is a device including a touch sensor and a touch controller, and is used to detect pen input or touch input.
  • a pen P shown in FIG. 1 is an electronic pen used to perform pen input to the touch detection device of the artist terminal 3 .
  • Pen input by the pen P is realized by, for example, an active electrostatic method or an electromagnetic induction method.
  • the output device 104 is a device that outputs the processing results of the CPU 101 to the user, and includes, for example, a display and a speaker.
  • a communication device 105 is a device for communicating with an external device, and transmits and receives data according to instructions from the CPU 101 .
  • Each artist terminal 3 and web server 4 use this communication device 105 to communicate with other devices, systems, networks, etc. including the illustrated distributed file system 5 and blockchain network 6 .
  • Each of the plurality of artist terminals 3 performs the production of artwork, registration of the produced artwork with the web server 4, application for use of artwork produced by other artists, and input of biometric signature data to be described later.
  • Each of the artwork and biometric signature data is digital data, and includes digital ink data (described later) generated by the artist performing pen input using the pen P to the input device 103 of the artist terminal 3. be done.
  • FIG. 3 is a diagram showing the configuration of biometric signature data.
  • Biometric signature data is data generated according to, for example, WILL (Wacom Ink Layer Language) or FSS (Forensic Signature Stream), and as shown in the figure, dynamic signature data, hash value of signed document, context information , and the additional information, the dynamic signature data, the hash value of the signed document, the hash value of the context information, the hash value of this hash value and the hash value of the additional information, and possible errors in the transmission and reception of this hash value. It contains a checksum for
  • Dynamic signature data is digital ink data that includes a series of coordinate data that make up a line drawing. Each coordinate data is data indicating the position of the pen P detected by the touch detection device described above.
  • the touch sensor includes a plurality of X electrodes each extending in the Y direction and arranged at equal intervals in the X direction, and a plurality of electrodes each extending in the X direction and arranged at equal intervals in the Y direction. and a plurality of Y electrodes.
  • the touch controller receives the burst signals transmitted by the pen P at each of the plurality of X electrodes and the plurality of Y electrodes, thereby obtaining coordinates indicating the position of the pen P. Get data.
  • the touch controller sequentially sends a signal to each of the plurality of X electrodes, receives this signal at each of the plurality of Y electrodes, and detects the amplitude change of the received signal. By doing so, coordinate data indicating the position of the pen P is acquired.
  • the touch controller is configured to collect coordinate data at a frequency of, for example, 100 or 200 times per second.
  • the hash value of the signed document is the hash value of the electronic data of the document (exhibition application form, contract, etc.) signed by the artist to generate the biometric signature data.
  • a hash value is a value obtained by inputting target electronic data into a predetermined one-way hash function. This point is the same for other hash values to be described later.
  • the context information includes the name data of the artist who signed the signature, the date and time of the signature, the purpose of the signature, the information of the touch detection device used for the signature (manufacturer name, model name, etc.), the information of the application used for the signature (application name , version information, etc.), operating system information (operating system name, version information, etc.) of the artist terminal 3, address information (IP address, MAC address, etc.) of the artist terminal 3, and the like. Additional information is dynamic signature data, hash values of signed documents, context information, and information that can be arbitrarily designated by the administrator of the artwork management system 1 .
  • the web server 4 is a server that executes various processes for implementing artwork management.
  • the various processes include a process of registering the artwork and its related data in the distributed file system 5 or the blockchain network 6, and a process of accepting an application for use of the artwork. Details of each process will be described later. Note that when the web server 4 is configured by connecting a plurality of computers 100 , various processes described later can be distributed to the plurality of computers 100 and executed.
  • the distributed file system 5 is a network of multiple computers connected by peer-to-peer and configured to store arbitrary electronic data.
  • a specific distributed file system 5 may be the interplanetary file system described above, or may be another type of distributed file system.
  • electronic data stored within distributed file system 5 is identified by its hash value. That is, in the distributed file system 5, the hash value of the stored electronic data functions as the address information of the electronic data.
  • a distributed file system 5 is used to store encrypted artwork and various DID documents. As will be described later, when artwork is managed by SSI, a DID is assigned to each artwork stored in the distributed file system 5, and owner information indicating the owner of the artwork is included in the DID document. , address information indicating the place where the actual artwork is placed, and license information (whether secondary creation is permitted, whether commercial use is permitted, etc.).
  • the blockchain network 6 is a network of multiple computers connected by peer-to-peer and configured to record smart contract transactions on the blockchain.
  • the blockchain network 6 is the Ethereum network. Recording of transactions on the blockchain is performed by several computers (hereinafter referred to as “miners”) connected to the blockchain network 6 .
  • each block that makes up the blockchain includes a block header and data (transaction data) that indicates the specific contents of the transaction.
  • the block header includes a Merkle root, which is data obtained by compressing the size of transaction data, a hash value of the previous block, and a nonce value, which is an arbitrary character string.
  • the hash value of that block in order to connect a new block to the blockchain, the hash value of that block must satisfy a predetermined condition (for example, a value starting with "000").
  • a miner who intends to record a block in the blockchain brute forcely finds a nonce value (mining) so that the hash value of the block header of that block satisfies the above-mentioned predetermined conditions.
  • the miner that succeeds in discovering the nonce value earliest will link that block to the blockchain, completing the recording of the transaction on the blockchain.
  • an artwork created without relying on other artwork hereinafter referred to as “artwork 1”, and the artist who created artwork 1 is referred to as “artist 1”) 14 to 23, and finally to FIGS. 24 to 31.
  • artwork 2 an artwork created without relying on other artwork
  • artist 2 the artist who created artwork 1
  • FIGS. 24 to 31 the processing related to the registration of artwork created based on artwork 1 (hereinafter referred to as “artwork 2" and the artist who created artwork 2 is referred to as “artist 2" or “Hanako Hanako”) explain.
  • FIG. 4 to 8 are examples of screens of the web application 3a displayed on the display of the artist terminal 3 where the artwork 1 is to be registered.
  • the login screen shown in FIG. 4 is displayed by the web application 3a.
  • the login screen includes an email address entry field 10, a password entry field 11, and a login button 12.
  • FIG. Here, when the artist 1 enters the e-mail address and password pre-registered in the web application 3a into the e-mail address entry field 10 and the password entry field 11, respectively, and presses the login button 12, the web application 3a displays the screen shown in FIG. is displayed.
  • the screen of the web application 3a displayed after login has a configuration in which a side menu is arranged on the left side.
  • a side menu is arranged on the left side.
  • a photo 13 and name 14 of the logged-in user a link 15 to the registered content screen, a link 16 to the request list screen, a link 17 to the transaction screen, a link 18 to the profile screen, and , a link 19 to the My Project screen is arranged.
  • the Registered Contents screen is for managing artworks uploaded by logged-in users
  • the Request List screen is for artwork usage applications (applications made by logged-in users and , and usage applications made to logged-in users)
  • the transaction screen is a screen for managing the transaction ID obtained as a result of recording in the blockchain network 6.
  • the profile screen is a screen for managing the information of the logged-in user (name, photo, email address, password, etc., hereinafter referred to as "user information"), and the My Project screen is generated by the logged-in user. This is a screen for managing the created project (described later).
  • FIG. 5 shows the registered content screen when there is no registered content.
  • a registration button 20 is displayed on the registered content screen in this case.
  • FIG. 6 is a content registration screen displayed by the web application 3a that has detected that the registration button 20 in FIG. 5 has been pressed.
  • the content registration screen includes a content name input field 21 , a file selection interface 22 , an artwork metadata input interface 23 , and a registration button 24 .
  • the content name input field 21 is a text box for inputting the name of the artwork 1 arbitrarily named by the artist 1.
  • "rider" is entered as the name of artwork 1.
  • the selection interface 22 is an interface for selecting an artwork file that the artist 1 intends to register.
  • the files selected here are image files such as jpg files and png files, and the artwork 1 is composed of one or more files selected here.
  • the selection interface 22 is configured so that a folder containing a plurality of files can also be selected.
  • FIG. 6 shows a state in which two images A1 and A2 are selected.
  • Image A2 is, for example, a picture including a person
  • image A1 is, for example, a partially enlarged image of image A2.
  • the metadata input interface 23 is an interface for inputting metadata, which is information for describing the artwork 1. As a specific content of the metadata input here, as illustrated in FIG. , whether the artist 1 is the owner of the artwork 1), and various information about the license of the artwork 1. In the example of FIG. 6, the various types of information regarding this license include information indicating whether or not to set a collaborator license, information indicating whether or not to set a commercial license, and input based on the user's own thinking. Contains one or more pieces of information (unique IP settings).
  • the web application 3a When the user presses the registration button 24, the web application 3a displays the signature window 25 shown in FIG.
  • the signature window 25 has an interface for the artist 1 to input a handwritten signature using the pen P, and a confirmation button 26 .
  • the web application 3a When the artist 1 who has entered the signature presses the confirmation button 26, the web application 3a generates the biometric signature data shown in FIG. 3 based on the entered signature, and then issues a registration request shown in FIG. Send to web server 4 .
  • the web server 4 responds to this registration request by processing to register the artwork 1 in the distributed file system 5, generates the DID and DID document of the artwork 1, and sends the DID document to the distributed file system 5. While registering, the process of recording the DID in the blockchain network 6, the process of generating a VC for proving the authenticity of the artwork 1, and the process of embedding a watermark in each file that constitutes the artwork 1 are performed.
  • FIG. 8 is a registration completion screen displayed by the web application 3a after a series of processing by the web server 4 is completed.
  • the registration completion screen includes display columns 27 to 31 for displaying predetermined information and operation buttons 32 to 36 for executing predetermined operations.
  • the display field 27 displays the DID of the artwork 1 recorded in the blockchain network 6 by the web server 4.
  • a list of thumbnails of files that constitute the artwork 1 is displayed. By clicking on this thumbnail, Artist 1 can download the corresponding file.
  • the file downloaded here is preferably a file with a watermark, which will be described later, but a file without a watermark may be downloaded.
  • a display field 29 displays a content ID assigned when the web server 4 registers the artwork 1 in the distributed file system 5 .
  • the content ID is a hash value of artwork data including each file and metadata that constitute the artwork 1 .
  • the display column 30 displays the address of the artwork 1 in the distributed file system 5 . In a typical example, this address is the URL (Uniform Resource Locator) of the distributed file system 5 with a content ID. All or part of the medadata of the artwork 1 is displayed in the display column 31 .
  • the operation button 32 is a push button for updating the artwork 1.
  • the web application 3a that has detected that the operation button 32 has been pressed displays a screen for adding, changing, and deleting files that make up the artwork 1.
  • the operation button 33 is a push button for changing ownership of the artwork 1 .
  • the web application 3a that has detected that the operation button 33 has been pressed displays a screen for designating a new owner of the artwork 1.
  • the operation button 34 is a push button for changing metadata of the artwork 1 .
  • the web application 3 a that has detected that the operation button 34 has been pressed displays a screen for changing the metadata of the artwork 1 .
  • the web application 3a transmits a registration request to the web server 4 again.
  • the artwork 1 registered in the distributed file system 5 is changed, a new DID is recorded in the blockchain network 6, a new VC is issued, and new water is added to each file that constitutes the artwork 1.
  • the mark will be embedded.
  • the operation button 35 is a push button for uploading the artwork 1 to SNS (Social Networking Service). Further, the operation button 36 is a push button for uploading the artwork 1 to the sales site.
  • the web application 3a that has detected that the operation button 35 or the operation button 36 has been pressed displays a screen for selecting the SNS or sales site to which the artwork 1 is to be uploaded. When the user selects a certain SNS or sales site on this screen, the web application 3a sends each file (watermark is embedded) and metadata. This makes it possible to securely disclose the information of the artwork 1 on the SNS or sales site.
  • FIG. 9 is a sequence diagram showing processing for registering a new user.
  • the web application 3a and the web server 4 first execute login processing using the login screen shown in FIG. 4 (step S1). It should be noted that if the e-mail address and password have not been registered in the web application 3a, a process of registering various types of user information including the combination of the e-mail address and password is also executed in step S1.
  • the web server 4 determines whether or not the user's key pair (combination of public key and private key for public key cryptography; hereinafter the same) has been generated. If so, a new key pair is generated and stored (step S2).
  • the web application 3a receives and stores the generated key pair from the web server 4 (step S3).
  • the web server 4 generates and stores the DID of the user and the DID document containing all or part of the user information described above (step S4). Then, the generated DID document is registered in the distributed file system 5 (step S5), and a smart contract for recording the generated DID in the blockchain is issued to the blockchain network 6 (step S6). When the recording on the blockchain is completed, the blockchain network 6 issues a transaction ID. The web server 4 receives and stores this transaction ID (user's transaction ID) from the blockchain network 6 (step S7). The web server 4 also transmits the generated user's DID and DID document to the web application 3a (step S8). The web application 3a stores the received DID and DID document, uses the user's DID when generating a registration request for the artwork 1 described later, and uses the user's DID to generate the above-described profile screen. Use documentation.
  • FIG. 10 and 11 are sequence diagrams showing the process of registering artwork 1.
  • FIG. 10 the content registration screen shown in FIG. 6 is displayed by the web application 3a (step S10).
  • the web application 3a displays the signature window 25 shown in FIG. 7, and transmits a registration request for the artwork 1 to the web server 4 (step S11).
  • This registration request contains the DID of the artist 1 stored by the web application 3a in step S7 of FIG.
  • Metadata of the work 1 (information including the name input in the content name input field 21 shown in FIG. 6 and each information input in the metadata input interface 23 shown in FIG. 6), and the metadata shown in FIG.
  • Biometric signature data generated based on the signature entered with a pen in the signature window 25 and the electronic signature of artist 1 are included.
  • FIG. 10 and subsequent figures exemplify "FSS" as biometric signature data, it is of course possible to use biometric signature data other than FSS.
  • the web application 3a is configured to generate the electronic signature of the artist 1 by encrypting the hash value of the data (excluding the electronic signature) constituting the registration request with the user's private key.
  • web server 4 Upon receiving the registration request for artwork 1, web server 4 first confirms the validity of the electronic signature and biometric signature data (steps S12 and S13).
  • the validity of the electronic signature is confirmed by decrypting the electronic signature included in the registration request with the user's public key, deriving the hash value of the data (excluding the electronic signature) that constitutes the registration request, and This can be done by comparison.
  • one or more pieces of dynamic signature data corresponding to the user DID included in the registration request are retrieved from a database that stores one or more pieces of dynamic signature data in association with the user DID. This may be done by retrieving and comparing with the dynamic signature data contained in the biometric signature data. If the validity of the biometric signature data is confirmed as a result of this comparison, the web server 4 replaces the dynamic signature data included in the registration request with the new dynamic signature data of the user in the database. preferably added to.
  • the web server 4 generates and stores a key pair for artwork 1 (step S14).
  • the private key included in the key pair generated here will be referred to as the "artwork private key”
  • the public key will be referred to as the "artwork public key”.
  • the web server 4 then encrypts the artwork data (data consisting of each file and metadata that make up the artwork 1) with the generated artwork secret key and registers it in the distributed file system 5 (step S15). to the web application 3a (step S17).
  • the web server 4 generates and stores the DID of the artwork 1 and the DID document containing all or part of the metadata of the artwork 1 (step S18). Then, the generated DID document is registered in the distributed file system 5 (step S19), and a smart contract for recording the generated DID in the blockchain is issued to the blockchain network 6 (step S20). When the recording on the blockchain is completed, the blockchain network 6 issues a transaction ID. The web server 4 receives and stores this transaction ID (transaction ID of artwork 1) from the blockchain network 6 (step S21). The web server 4 also transmits the generated DID of the artwork 1 and the DID document to the web application 3a (step S22).
  • FIG. 12(a) is a diagram showing a configuration example of the DID document of the artwork 1 generated by the web server 4 in step S18.
  • the DID document of Artwork 1 can include information on owner, contributor, secondary creation, IP share, usage mode, signature, storage location, and public key.
  • the owner is the user who holds ownership of artwork 1 (artist 1 in this case), and the contributor is the artist who contributed to the creation of artwork 1 (artist 1 in this case).
  • the user's DID included in the registration request is set for both the owner and the contributor, but it may be possible for the user to individually specify them on the content registration screen shown in FIG.
  • Information in the metadata included in the registration request is set for the secondary creation, IP share, and usage mode.
  • the signature is set with a hash value of the biometric signature data included in the registration request (information indicating dynamic signature data included in the biometric signature data).
  • the storage location is set to the address obtained when the web server 4 registers the artwork data in the distributed file system 5 in step S15.
  • the public key is set to the artwork public key generated by the web server 4 in step S14.
  • web server 4 generates a watermark based on the biometric signature data included in the registration request (or the dynamic signature data included therein) to compose artwork 1. embedded in each file to be used (step S23). Specifically, the biometric signature data or dynamic signature data itself may be used as the watermark, or the hash value of the biometric signature data or dynamic signature data may be used as the watermark. Then, the web server 4 stores each watermarked file in which the watermark is embedded in association with the DID of the artwork 1 (step S24), and transmits it to the web application 3a (step S25). Each file stored in step S24 is used when the file is displayed on the registration completion screen shown in FIG. 8, the artwork details screen shown in FIG. 14, which will be described later, and the like.
  • the web server 4 replaces each file in the artwork data with a file with a watermark (step S26), and sends the hash value of the data consisting of the DID document of the artwork data and the artwork 1 to the web server 4. (hereinafter referred to as "publisher's private key") to generate an electronic signature (step S27). Then, a VC including the generated electronic signature and the transaction ID of the artwork 1 received from the blockchain network 6 is issued (step S28) and transmitted to the web application 3a (step S29).
  • FIG. 12(b) is a diagram showing the contents of the VC for artwork 1.
  • the VC includes the issue date, issuer, issuer's electronic signature, and transaction ID.
  • the issue date is set with the date when the web server 4 issued the VC.
  • Information (name, address, etc.) specifying the web server 4 that issued the VC is set in the issuer.
  • the issuer's electronic signature is set to the electronic signature generated in step S27.
  • the transaction ID is set to the transaction ID of the artwork 1 received from the blockchain network 6 .
  • the web application 3a Upon receiving the VC from the web server 4, the web application 3a generates and displays the registration completion screen shown in FIG. 8 (step S30). This completes a series of registration processes.
  • FIG. 13 is a flow chart showing the flow of processing executed by a computer that receives artwork data of artwork 1 and VC via SNS or a sales site.
  • This computer may be the artist terminal 3 shown in FIG. 1, or may be another computer.
  • a specific use of the VC of artwork 1 will be described below with reference to FIG.
  • the computer acquires the VC of Artwork 1 together with the artwork data (one or more watermarked files and metadata that constitute Artwork 1) published on the SNS or sales site (step S40). Subsequently, the computer acquires the DID of artwork 1 from the blockchain network 6 based on the transaction ID contained in the VC (step S41), and further, based on the acquired DID of artwork 1, from the distributed file system 5 A DID document of artwork 1 is obtained (step S42).
  • the computer derives the hash value of the artwork data acquired in step S40 and the data consisting of the DID document of artwork 1 acquired in step S42 (step S43). Also, based on the issuer information contained in the VC, the computer acquires the public key of the issuer who issued the VC (hereinafter referred to as the "issuer public key") (step S44), The electronic signature in the VC is decrypted using the public key of the person (step S45). Then, the hash value obtained by decryption is compared with the hash value derived in step S43 (step S46). As a result, if these hash values match, the authenticity of the published artwork data is confirmed. By performing verification by VC in this way, it becomes possible to confirm the authenticity of the published artwork data.
  • the computer that verifies the VC acquires the DID document of the artwork 1 from the distributed file system 5, but the DID document is also published together with the artwork data of the artwork 1 on the SNS or sales site. You can do it.
  • the hash value derivation in step S43 may use the published DID document, so there is no need to arrange the transaction ID of artwork 1 in the VC.
  • FIG. 16 and 17 are examples of screens of the web application 3a displayed on the display of the artist terminal 3 that has received the application for using the artwork 1.
  • FIG. 16 and 17 are examples of screens of the web application 3a displayed on the display of the artist terminal 3 that has received the application for using the artwork 1.
  • the screen shown in FIG. 14 is an artwork detail screen displayed when artist 2 selects artwork 1 on the artwork list display screen.
  • the artwork details screen includes display columns 40 to 45 for information about artwork 1, a request content input interface 46, and a request button 47.
  • the display field 40 contains the owner information (photograph, name, etc.) of the artwork 1, the display field 41 contains the content name of the artwork 1, the display field 42 contains the DID of the artwork 1, and the display field 43 contains the DID of the artwork 1. DIDs of one or more users who are the owners of the artwork 1 are displayed, and information (photograph, name, etc.) of one or more users who are the contributors of the artwork 1 are displayed in the display field 44 . To display this information, the web server 4 obtains the DID document of artwork 1 from the DID of artwork 1, and also extracts the respective DID documents from the owner and contributor DIDs described therein. By acquiring, the data to be displayed in the display columns 40 to 44 are configured to be acquired. Also, in the display column 45, thumbnails of the watermarked files stored in step S24 of FIG. 11 are displayed.
  • the request content input interface 46 is an interface for inputting the content of a request to the owner of artwork 1.
  • the specific content of the request input here may include non-commercial license content, commercial license content, profit sharing rate proposal, and arbitrary sentences.
  • Fig. 14 shows a state in which artist 2 has not yet logged into web application 3a.
  • the web application 3a displays the login screen shown in FIG. 4 and causes the artist 2 to perform login processing.
  • the web application 3a displays a request transmission screen shown in FIG.
  • the request transmission screen is a screen displayed when the artist 2 is logged into the web application 3a, and therefore has a side menu on the left side, similar to FIG.
  • the contents of the information displayed on the side menu are as described with reference to FIG.
  • the contact button 49 is a push button for contacting the owner of artwork 1 separately from the usage application.
  • the web application 3a detects that the contact button 49 has been pressed and displays an e-mail input screen. Send an email to the email address of
  • communication means other than e-mail such as SNS. In that case, as part of the user information of the owner of the artwork 1, information about the SNS of the owner of the artwork 1 needs to be stored in advance.
  • the send request button 48 is a push button for actually sending a request for use of artwork 1 to the owner of artwork 1.
  • the web application 3a that has detected that the request transmission button 48 has been pressed displays a signature window 50 shown in FIG.
  • This signature window 50 is an interface similar to the signature window 25 shown in FIG. be.
  • the web application 3a When the artist 2 who has entered the signature presses the confirmation button 51, the web application 3a generates the biometric signature data shown in FIG. 3 based on the entered signature, and then submits the usage application shown in FIG. Send to web server 4 .
  • the web server 4 processes to notify the owner of the usage application, acquires the content of agreement according to the approval result of the owner, and processes the DID and DID document of the project related to the usage application, which will be described later in detail. and register the DID document in the distributed file system 5, record the DID in the blockchain network 6, and generate a VC for proving the authenticity of the project.
  • FIG. 17 shows the request list screen displayed by the web application 3a of the artist terminal 3 (the artist terminal 3 of the artist 1 who is the owner of the artwork 1) that has received the notification of the usage application (pressing the link 16 in the side menu).
  • This is the screen displayed by In this example, one request for "rider” is displayed on the screen as a usage application received from another computer.
  • the request ID is information for uniquely identifying a usage application, and is assigned by the web server 4 each time a usage application is transmitted.
  • information other than these, such as information constituting the metadata of the artwork 1, may be displayed.
  • the request ID is a hyperlink to the usage application details screen shown in FIG.
  • the web application 3a displays the usage application details screen shown in FIG.
  • the usage application details screen includes display columns 52 to 58, a permission button 59, a rejection button 60, and a contact button 61.
  • the content name of artwork 1 is displayed in display field 52
  • the DID of artwork 1 is displayed in display field 53
  • the DID of the user who is the owner of artwork 1 is displayed in display field 54
  • the artwork is displayed in display field 55.
  • the display column 56 contains all or part of the metadata of the artwork
  • the display column 57 contains the applicant's information (photo, name, etc.)
  • the display column 58 displays the content of the request (information input to the request content input interface 46 shown in FIG. 15).
  • the contact button 61 is a push button for contacting the applicant.
  • the web application 3a detects that the contact button 61 has been pressed, it displays an e-mail input screen in the same way as when the contact button 49 shown in FIG. 15 is pressed, and presses the send button displayed on the screen.
  • An e-mail is sent to the e-mail address of the owner of the artwork 1 in response to the user's pressing.
  • other means of communication may be used in place of e-mail.
  • the permission button 59 is a push button for accepting usage applications.
  • the reject button 60 is a push button for rejecting the usage application.
  • the web application 3a that has detected that any button has been pressed transmits information (permission or denial) according to the pressed button to the web server 4. FIG. Processing performed by the web server 4 according to this information will be described later.
  • FIG. 19 is a diagram showing an example of a request list screen displayed by the web application 3a of the artist 2 who is the applicant as a result of the processing performed by the web server 4.
  • the status displayed is "permitted" as a result of the usage application being permitted by the owner.
  • a download button 62 for downloading each file constituting the artwork 1 is displayed near the request ID. The operation of the web application 3a when the user presses the download button 62 will be described later.
  • FIGS. 20 and 21 are sequence diagrams showing the processing related to application for use of artwork 1.
  • FIG. "Web application 1" shown in these figures indicates the web application 3a running on the artist terminal 3 of artist 1 who is the owner of artwork 1, and "web application 2" is the artist of artist 2 who is the applicant.
  • a web application 3a running on the terminal 3 is shown.
  • the web application 3a displays the request transmission screen shown in FIG. 15 (step S50).
  • the web application 3a displays the signature window 50 shown in FIG. S51).
  • the DID of artist 2 who is the applicant the DID of artwork 1, the DID of artist 1 who is the owner of artwork 1, and the DID of artist 1, which is the owner of artwork 1, are input to the request content input interface 46 shown in FIG. information, biometric signature data generated based on the signature entered in the signature window 50 shown in FIG. 16, and artist 2's electronic signature.
  • the web application 3a generates the electronic signature of the artist 2 by encrypting the hash value of the data (excluding the electronic signature) constituting the usage application with the user's private key.
  • the web server 4 that has received the application for use of artwork 1 first confirms the validity of the electronic signature and biometric signature data (steps S52 and S53). The details of each are the same as those described with reference to steps S12 and S13 in FIG.
  • the web server 4 transmits a usage application to the web application 3a of the artist 1 who owns the artwork 1 (step S54).
  • the web application 3a that has thus received the usage application displays the received usage application in the request list screen as shown in FIG. is displayed (step S55).
  • the artist 1 presses the permission button 59 the information indicating "permit” is sent to the web server 4, and when the artist 1 presses the reject button 60, the information indicating "rejection” is sent to the web server 4. (step S56).
  • the web server 4 determines whether the information (owner's reply) received from the web application 3a of the owner of the artwork 1 is permission or denial (step S57). Information indicating refusal is transmitted to the web application 3a of a certain artist 2. In this case, on the request list screen shown in FIG. 19, "rejected" is displayed in the status column of the corresponding usage application. On the other hand, in the case of permission, the web server 4 transmits the content agreed upon between the applicant and the owner (in principle, the information entered in the request content input interface 46 shown in FIG. 15; however, the applicant and the owner may be changed later by ) is acquired (step S58).
  • the web server 4 newly sets a project related to the usage application, generates and stores the DID and DID document of the set project (step S59). Then, the generated DID document is registered in the distributed file system 5 (step S60), and a smart contract for recording the generated DID in the blockchain is issued to the blockchain network 6 (step S61). When the recording on the blockchain is completed, the blockchain network 6 issues a transaction ID. The web server 4 receives and stores this transaction ID (project transaction ID) from the blockchain network 6 (step S62). The web server 4 also transmits the generated DID of the project and the DID document to the applicant's web application 3a (step S63).
  • FIG. 22(a) is a diagram showing a configuration example of a project DID document generated by the web server 4 in step S59.
  • a project DID document may include owner, signature, target work, and terms of use information.
  • the owner is set with the DID of the applicant (artist 2 in this case) included in the usage application.
  • a hash value of biometric signature data included in the usage application is set in the signature.
  • the DID of the artwork 1 for which the use application is made is set for the target work.
  • Information indicating the content of the agreement acquired in step S58 is set in the terms of use.
  • the web server 4 generates an electronic signature by encrypting the hash value of the project's DID document using the issuer's private key (step S64). Then, a VC (verifiable certificate) containing the generated electronic signature and the transaction ID of the project received from the blockchain network 6 is issued (step S65) and transmitted to the applicant's web application 3a (step S66 ).
  • VC verifiable certificate
  • FIG. 22(b) is a diagram showing the contents of the VC for the project.
  • This VC also includes the issue date, issuer, issuer's electronic signature, and transaction ID, like the VC of artwork 1 shown in FIG. 12(b).
  • the setting contents of the issue date, issuer, and issuer's electronic signature are the same as those of the artwork 1 VC.
  • the transaction ID is set to the transaction ID of the project received from the blockchain network 6 .
  • a project's VC may not include a transaction ID.
  • the web application 3a that has received the project VC displays the request list screen shown in FIG. 19 (step S67). In this case, "permitted” is displayed in the status column of the corresponding usage application.
  • the web application 3a that has detected that the download button 62 has been pressed on the request list screen shown in FIG. View the download page for each file you want. As a result, artist 2 who is the applicant can use each piece of information.
  • FIG. 23 is a flow diagram showing the flow of processing executed by a computer that receives a project's DID document and VC via SNS or sales site.
  • This computer may be the artist terminal 3 shown in FIG. 1, or may be another computer.
  • a specific use of the project VC will be described below with reference to FIG.
  • the computer acquires the VC of the project along with the DID document of the project published on the SNS or sales site (step S70). The computer then derives the hash value of the obtained DID document (step S71). The computer also obtains the issuer public key based on the issuer information contained in the VC (step S72), and decrypts the electronic signature in the VC using the obtained issuer public key (step S73). Then, the hash value obtained by decryption is compared with the hash value derived in step S74 (step S74). As a result, if these hash values match, the authenticity of the published DID document (and the agreement contained therein) has been confirmed. By performing verification by the VC in this way, it is possible to confirm the authenticity of the content agreed upon between the owner of the artwork 1 and the applicant who applied for use.
  • 24 to 26 are examples of screens of the web application 3a displayed on the display of the artist terminal 3 where the artwork 2 is to be registered.
  • the web application 3a displays the above-described my project screen.
  • web application 3a displays a content registration screen shown in FIG.
  • the content registration screen shown in FIG. 24 includes a content name input field 70, an original work display field 71, a file selection interface 72, an artwork metadata input interface 73, and a registration button 74.
  • the content name input field 70 is a text box for inputting the name of the artwork 2 arbitrarily named by the user.
  • “rider” which is the same as the artwork 1, is entered in the content name input field 70, but a name different from the name of the artwork 1 may be entered.
  • the original work display field 71 displays information (content name, content ID, thumbnail, etc.) indicating the target work of the project (hereinafter referred to as "original work").
  • the selection interface 72 is an interface for selecting the artwork file that the user intends to register.
  • the file selected here is, for example, an image file such as a jpg file or a png file, or a folder containing a plurality of files, similar to the selection interface 22 shown in FIG. FIG. 24 shows a state in which one folder F1 and one image B1 are selected.
  • Image B1 is, for example, a 3D model of a person included in image A2.
  • Folder F1 may contain, for example, one or more image files that constitute textures (3D textures) used for displaying image B1.
  • Each file in folder F1 constitutes artwork 2 together with image B1.
  • the metadata input interface 73 is an interface for inputting metadata that is information for describing the artwork 2. As will be described later, since Artwork 2 is shared with the owner of Artwork 1, some metadata cannot be edited here. On the other hand, it is possible to input other metadata, and FIG. 24 shows the content of the contribution by artist 2 and the IP setting as an example of such metadata.
  • the web application 3a When the user presses the registration button 74, the web application 3a displays the signature window 75 shown in FIG.
  • the signature window 75 is an interface similar to the signature window 25 shown in FIG. 7 and the signature window 50 shown in FIG. 76.
  • the web application 3a When the user who has entered the signature presses the confirmation button 76, the web application 3a generates the biometric signature data shown in FIG. 3 based on the entered signature, and then transmits the registration request shown in FIG. Send to server 4.
  • the web server 4 responds to this registration request by processing to register the artwork 2 in the distributed file system 5, generates the DID and DID document of the artwork 2, and sends the DID document to the distributed file system 5. While registering, the process of recording the DID in the blockchain network 6, the process of generating a VC for proving the authenticity of the artwork 2, and the process of embedding a watermark in each file that constitutes the artwork 2 are performed.
  • FIG. 26 is a registration completion screen displayed by the web application 3a after the series of processes performed by the web server 4 is completed.
  • the registration completion screen includes display fields 77 to 83 for displaying predetermined information and operation buttons 84 to 87 for executing predetermined operations.
  • the display field 77 displays the DID of the artwork 2 recorded in the blockchain network 6 by the web server 4.
  • a list of thumbnails of files constituting the artwork 2 is displayed. By clicking on this thumbnail, the user can download the corresponding file, but the file downloaded here will be a file with a watermark, which will be described later.
  • a display column 79 displays information (content name, content ID, thumbnail, etc.) indicating the original work.
  • information photograph, name, etc.) of one or more artists (artist 1 and artist 2 in this case) involved in the production of artwork 2 is displayed.
  • the content ID given when the web server 4 registers the artwork 2 in the distributed file system 5 is displayed.
  • the content ID is a hash value of artwork data including each file and metadata that constitute the artwork 2 .
  • the display column 82 displays the address of the artwork 2 in the distributed file system 5 . All or part of the medadata of the artwork 2 is displayed in the display field 83 .
  • the operation button 84 is a push button for updating the artwork 2.
  • the web application 3a displays a screen for adding, changing, and deleting files that make up the artwork 2.
  • the operation button 85 is a push button for changing the metadata of the artwork 2 .
  • the web application 3 a that has detected that the operation button 85 has been pressed displays a screen for changing the metadata of the artwork 2 .
  • the web application 3a transmits a registration request to the web server 4 again.
  • the artwork 2 registered in the distributed file system 5 is changed, a new DID is recorded in the blockchain network 6, a new VC is issued, and new water is added to each file that constitutes the artwork 2.
  • the mark will be embedded.
  • the operation button 86 is a push button for uploading the artwork 2 to the SNS. Further, the operation button 87 is a push button for uploading the artwork 2 to the sales site. Details of these are the same as those of the operation buttons 35 and 36 described with reference to FIG.
  • FIG. 27 is an artwork detail screen displayed when the user selects artwork 2 on the artwork list display screen (not shown).
  • the artwork details screen includes display columns 88 to 94 for information on artwork 2, a request content input interface 95, and a request button 96.
  • FIG. Details of the request content input interface 95 and the request button 96 are the same as those of the request content input interface 46 and the request button 47 described with reference to FIG.
  • Information indicating the original work is displayed in the display column 89 .
  • the content name of artwork 2 is displayed in a display field 90
  • the DID of artwork 2 is displayed in a display field 91
  • the owner of artwork 2 (the owner set in the DID document of artwork 2) is displayed in a display field 92.
  • the DIDs of one or more users are shown in the display field 93 as one or more contributors of artwork 2 (contributors set in the DID document of artwork 2).
  • Information (photograph, name, etc.) of each user is displayed.
  • the method by which the web server 4 acquires these pieces of information is as described with reference to FIG.
  • FIG. 28 to 30 are sequence diagrams showing the process of registering artwork 2.
  • FIG. 28 the specific contents of the processes of steps S80 to S87 are the same as the processes of steps S10 to S17 shown in FIG. 10, except that artwork 1 is replaced with artwork 2.
  • the metadata of the artwork 2 included in the registration request is generated by the web application 3a based on the metadata input interface 73 shown in FIG. 24 and the agreed contents set in the DID document of the corresponding project. data.
  • the content ID and address of the artwork 2 are sent to the web application 3a (step S87).
  • step S87 the web server 4 generates and stores the DID of the artwork 2 and the DID document including all or part of the metadata of the artwork 2 (step S88), and then steps S89 to S92. process.
  • the specific contents of the processing of steps S89 to S92 are the same as the processing of steps S19 to S22 shown in FIG. 10, except that artwork 1 is replaced with artwork 2.
  • the DID of the artwork 2 and the DID document are sent to the web application 3a (step S92).
  • FIG. 31(a) is a diagram showing a configuration example of the DID document of artwork 2 generated by the web server 4 in step S88.
  • the components of the DID document of artwork 2 are the same as those of the DID document of artwork 1 shown in FIG.
  • both the DID of Artist 1, who owns Artwork 1, and the DID of Artist 2, who created Artwork 2 are set for the Owner along with their respective shares.
  • the DID of artist 1 and the DID of artist 2 are set as the contributors together with their contribution contents.
  • steps S93 to S99 the web server 4 performs steps S93 to S99.
  • the specific contents of the processing of steps S93 to S99 are the same as the processing of steps S23 to S29 shown in FIG. 11, except that artwork 1 is replaced with artwork 2.
  • each file with a watermark and the VC of artwork 2 are sent to web application 3a (steps S95 and S99).
  • FIG. 31(b) is a diagram showing the contents of the VC for artwork 2.
  • the VC for artwork 2 has the same configuration as the VC for artwork 1.
  • the issuer's electronic signature is set by encrypting the hash value of the data consisting of the artwork data of artwork 2 and the DID document with the issuer's private key, and the transaction ID is set to the artwork 2 A transaction ID is set.
  • the web server 4 adds the DID of the artwork 2 to the DID document of the corresponding project (step S100), as shown in FIG. Along with updating the DID document of the project, the DID document of the project stored in the distributed file system 5 is also updated (step S101). The web server 4 also transmits the updated DID document to the web application 3a (step S102).
  • FIG. 31(c) is a diagram showing the DID document of the project updated in step S101.
  • the updated DID document has a derivative work column added therein, in which the DID of artwork 2 is set. This allows derivative work generated according to a project to be managed within the project's DID document.
  • the web server 4 then performs steps S103 to S105.
  • the specific contents of the processing of steps S103 to S105 are the same as the processing of steps S64 to S66 shown in FIG.
  • a new VC of the project is sent to the web application 3a (step S105).
  • the web application 3a that has received the VC from the web server 4 generates and displays the registration completion screen shown in FIG. 26 (step S106), thereby completing a series of registration processing.
  • the web server 5 in response to receiving the usage application for the artwork 1, transmits the DID of the artwork 1 and the usage of the artwork 1. Since the DID document of the project including the DID of the user who submitted the application is generated, the information regarding the artwork can be properly managed by the SSI.
  • the artwork management system 1 by looking at the DID document of the project, it is possible to know the relationship between the artwork 1 which is the original work and the artwork 2 which is the work derived therefrom. can.
  • the project DID document generated by the artwork management system 1 according to the present embodiment it is possible to manage the process of evolution from a picture of a person to a 3D model.
  • the authenticity of the DID document of the project can be ensured by performing verification based on the electronic signature in the VC distributed together with the DID document of the project. Therefore, it is possible to appropriately manage information on evolution from artwork 1, which is an original work, to artwork 2 by the SSI.
  • the SSI can also manage various information related to projects such as
  • DID and DID documents were generated for the artwork as a whole in response to a registration request. may be generated. Also, the generated DID and DID document may be recorded in the blockchain network 6 and registered in the distributed file system 5 in the same manner as the DID and DID document for the artwork as a whole.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Strategic Management (AREA)
  • Human Resources & Organizations (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Tourism & Hospitality (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Software Systems (AREA)
  • Bioethics (AREA)
  • Primary Health Care (AREA)
  • Computing Systems (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Power Engineering (AREA)
  • Development Economics (AREA)
  • Educational Administration (AREA)
  • Data Mining & Analysis (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】アートワークに関する情報をＳＳＩによって適切に管理できるようにする。 【解決手段】コンピュータによって実行されるアートワークの管理方法の発明である。前記コンピュータは、第１のアートワークの利用のリクエストを受信し、前記第１のアートワークを識別するＤＩＤである第１のＤＩＤを含むとともに、前記第１のアートワークの利用をリクエストする第１のユーザを識別するＤＩＤである第２のＤＩＤを含むＤＩＤドキュメントである第１のＤＩＤドキュメントを生成するよう構成される。

Description

アートワーク管理方法、コンピュータ、及びプログラム
　本発明は、アートワーク管理方法、コンピュータ、及びプログラムに関する。
　近年、自己主権型アイデンティティ（Self-Sovereign Identity。以下「ＳＳＩ」という）が注目されている。ＳＳＩは、管理主体が介在することなく自分自身が自らのアイデンティティ（Identity。以下「ＩＤ」という）を保有、コントロールできるようにすることにより、中央集権的なＩＤ管理による諸問題を解決する仕組みである。ＳＳＩにおいては、ブロックチェーンによって管理される分散型のＩＤである分散型アイデンティティ（Decentralized Identity。以下「ＤＩＤ」という）によって情報が識別される。ＤＩＤにより識別される情報はＤＩＤドキュメントと呼ばれ、惑星間ファイルシステム（InterPlanetary File System。以下「ＩＰＦＳ」という）などの分散ファイルシステムに格納される。非特許文献１には、ＤＩＤ及びＤＩＤドキュメントの規格が記載されている。
　また、ＳＳＩでは、検証可能証明書（Verifiable Credentials。以下「ＶＣ」という）と呼ばれる証明書が利用される。ＶＣは、証明対象である情報のハッシュ値を発行者の秘密鍵によって暗号化してなる電子署名を含む情報である。証明対象である情報とともにＶＣを受け取った者は、受け取った情報のハッシュ値を導出するとともに、発行者の公開鍵によって電子署名を復号し、導出したハッシュ値と復号した電子署名を比較することによって、受け取った情報の真正性を確認する。非特許文献２には、ＶＣの規格が記載されている。
　しかしながら、従来、スタイラスなどによって描かれたデジタル画像（以下「アートワーク」という）の取り扱いにおいて、アートワークをＳＳＩによって適切に管理することは困難であった。
　したがって、本発明の目的の一つは、アートワークをＳＳＩによって適切に管理できるアートワーク管理方法、コンピュータ、及びプログラムを提供することにある。
　本発明によるアートワーク管理方法は、コンピュータによって実行されるアートワークの管理方法であって、前記コンピュータは、第１のアートワークの利用のリクエストを受信し、前記コンピュータは、前記第１のアートワークを識別するＤＩＤである第１のＤＩＤ、及び、前記第１のアートワークの利用をリクエストする第１のユーザを識別するＤＩＤである第２のＤＩＤを含むＤＩＤドキュメントである第１のＤＩＤドキュメントを生成する、アートワークの管理方法である。
　本発明によるコンピュータは、第１のアートワークの利用のリクエストを受信し、前記第１のアートワークを識別するＤＩＤである第１のＤＩＤ、及び、前記第１のアートワークの利用をリクエストする第１のユーザを識別するＤＩＤである第２のＤＩＤを含むＤＩＤドキュメントである第１のＤＩＤドキュメントを生成する、コンピュータである。
　本発明によるプログラムは、コンピュータに、第１のアートワークの利用のリクエストを受信し、前記第１のアートワークを識別するＤＩＤである第１のＤＩＤ、及び、前記第１のアートワークの利用をリクエストする第１のユーザを識別するＤＩＤである第２のＤＩＤを含むＤＩＤドキュメントである第１のＤＩＤドキュメントを生成する、処理を実行させるためのプログラムである。
　本発明によれば、アートワークをＳＳＩによって適切に管理することが可能になる。
本実施の形態によるアートワーク管理システム１の構成を示す図である。 アーティスト端末３及びウェブサーバ４のハードウェア構成の一例を示す図である。 バイオメトリック署名データの構成を示す図である。 アートワーク１の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク１の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク１の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク１の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク１の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 新規ユーザの登録にかかる処理を示すシーケンス図である。 アートワーク１の登録にかかる処理を示すシーケンス図である。 アートワーク１の登録にかかる処理を示すシーケンス図である。 （ａ）は、アートワーク１のＤＩＤドキュメントの構成例を示す図であり、（ｂ）は、アートワーク１のためのＶＣの内容を示す図である。 ＳＮＳ又は販売サイトを経由してアートワーク１のアートワークデータ及びＶＣを受け取ったコンピュータによって実行される処理のフローを示すフロー図である。 アートワーク１の利用申請を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク１の利用申請を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク１の利用申請を受信したアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク１の利用申請を受信したアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク１の利用申請を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 ウェブサーバ４が行った処理の結果として申請者であるアーティスト２のウェブアプリ３ａにより表示されるリクエスト一覧画面の一例を示す図である。 アートワーク１の利用申請にかかる処理を示すシーケンス図である。 アートワーク１の利用申請にかかる処理を示すシーケンス図である。 （ａ）は、プロジェクトのＤＩＤドキュメントの構成例を示す図であり、（ｂ）は、プロジェクトのためのＶＣの内容を示す図である。 ＳＮＳ又は販売サイトを経由してプロジェクトのＤＩＤドキュメント及びＶＣを受け取ったコンピュータによって実行される処理のフローを示すフロー図である。 アートワーク２の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク２の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク２の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク一覧表示画面においてユーザがアートワーク２を選択することによって表示されるアートワーク詳細画面である。 アートワーク２の登録にかかる処理を示すシーケンス図である。 アートワーク２の登録にかかる処理を示すシーケンス図である。 アートワーク２の登録にかかる処理を示すシーケンス図である。 （ａ）は、アートワーク２のＤＩＤドキュメントの構成例を示す図であり、（ｂ）は、アートワーク２のためのＶＣの内容を示す図であり、（ｃ）は、更新されたプロジェクトのＤＩＤドキュメントを示す図である。
　以下、添付図面を参照しながら、本発明の実施の形態について詳細に説明する。
　図１は、本実施の形態によるアートワーク管理システム１の構成を示す図である。同図に示すように、アートワーク管理システム１は、複数のアーティスト端末３と、ウェブサーバ４と、分散ファイルシステム５と、ブロックチェーンネットワーク６とがネットワーク２を介して相互に接続された構成を有している。
　図２は、アーティスト端末３及びウェブサーバ４のハードウェア構成の一例を示す図である。アーティスト端末３及びウェブサーバ４はそれぞれ、図示した構成を有するコンピュータ１００によって構成され得る。なお、ウェブサーバ４は、複数のコンピュータ１００の結合によって構成されていてもよい。
　図２に示すように、コンピュータ１００は、ＣＰＵ（Central Processing Unit）１０１、記憶装置１０２、入力装置１０３、出力装置１０４、及び通信装置１０５を有して構成される。
　ＣＰＵ１０１は、コンピュータ１００の各部を制御するとともに、記憶装置１０２に記憶される各種のプログラムを読み出して実行する装置である。後掲する図３～図３１を参照して説明する各処理は、アーティスト端末３又はウェブサーバ４のＣＰＵ１０１が記憶装置１０２に記憶されるプログラムを実行することによって実現される。アーティスト端末３のＣＰＵ１０１によって実行されるプログラムには、図１に示したウェブアプリ３ａが含まれる。
　記憶装置１０２は、ＤＲＡＭ（Dynamic Random Access Memory）などの主記憶装置と、ハードディスクなどの補助記憶装置とを含み、コンピュータ１００のオペレーティングシステムや各種のアプリケーションを実行するための各種のプログラム、及び、これらのプログラムによって利用されるデータを記憶する役割を果たす。
　入力装置１０３は、ユーザの入力操作を受け付けてＣＰＵ１０１に供給する装置であり、例えばキーボード、マウス、タッチ検出装置を含んで構成される。このうちタッチ検出装置はタッチセンサ及びタッチコントローラを含む装置であり、ペン入力又はタッチ入力を検出するために使用される。図１に示したペンＰは、アーティスト端末３のタッチ検出装置に対してペン入力を行うために用いられる電子ペンである。ペンＰによるペン入力は、例えばアクティブ静電方式又は電磁誘導方式により実現される。
　出力装置１０４は、ＣＰＵ１０１の処理結果をユーザに対して出力する装置であり、例えばディスプレイ、スピーカーを含んで構成される。通信装置１０５は、外部の装置と通信するための装置であり、ＣＰＵ１０１の指示にしたがってデータの送受信を行う。各アーティスト端末３及びウェブサーバ４はそれぞれ、この通信装置１０５を用いて、図示した分散ファイルシステム５及びブロックチェーンネットワーク６を含む他の装置、システム、ネットワークなどとの間で通信を行う。
　図１に戻る。複数のアーティスト端末３はそれぞれ、アートワークの制作、制作したアートワークのウェブサーバ４への登録、他のアーティストが制作したアートワークの利用申請、及び、後述するバイオメトリック署名データの入力などを行うために使用されるコンピュータである。アーティスト端末３の具体的なハードウェアとしては、パーソナルコンピュータ、タブレット端末、スマートフォンなど任意のコンピュータを用いる得る。アートワーク及びバイオメトリック署名データはそれぞれデジタルデータであり、アーティスト端末３の入力装置１０３に対し、アーティストがペンＰを用いてペン入力を行うことによって生成されたデジタルインクデータ（後述）を含んで構成される。
　図３は、バイオメトリック署名データの構成を示す図である。バイオメトリック署名データは、例えばＷＩＬＬ（Wacom Ink Layer Language）又はＦＳＳ（Forensic Signature Stream）に従って生成されるデータであり、同図に示すように、動的署名データ、署名した書類のハッシュ値、コンテキスト情報、及び追加情報と、動的署名データ、署名した書類のハッシュ値、及びコンテキスト情報のハッシュ値、このハッシュ値及び追加情報のハッシュ値、並びに、このハッシュ値の送受信の際に生じ得る誤りを検出するためのチェックサムを含んで構成される。
　動的署名データは、線画を構成する一連の座標データを含むデジタルインクデータである。各座標データは、上述したタッチ検出装置により検出されるペンＰの位置を示すデータである。この検出について詳しく説明すると、タッチセンサは、それぞれＹ方向に延在し、Ｘ方向に等間隔で配置された複数のＸ電極と、それぞれＸ方向に延在し、Ｙ方向に等間隔で配置された複数のＹ電極とを含んで構成される。ペンＰが信号を送信可能に構成される場合、タッチコントローラは、これら複数のＸ電極及び複数のＹ電極のそれぞれでペンＰが送信したバースト信号を受信することにより、ペンＰの位置を示す座標データを取得する。一方、ペンＰが信号を送信できない場合、タッチコントローラは、複数のＸ電極のそれぞれに順次信号を送信し、複数のＹ電極のそれぞれでこの信号を受信し、受信される信号の振幅変化を検出することにより、ペンＰの位置を示す座標データを取得する。タッチコントローラは、例えば１秒当たり１００回又は２００回の頻度で、座標データを収集するように構成される。
　署名した書類のハッシュ値は、バイオメトリック署名データを生成するためにアーティストが署名した書類（出品申込書、契約書など）の電子データのハッシュ値である。なお、ハッシュ値は、対象の電子データを所定の一方向ハッシュ関数に入力することによって得られる値である。この点は、後述する他のハッシュ値についても同様である。
　コンテキスト情報は、署名したアーティストの氏名データ、署名日時、署名の目的、署名のために使用したタッチ検出装置の情報（メーカー名、モデル名など）、署名のために使用したアプリケーションの情報（アプリケーション名、バージョン情報など）、アーティスト端末３のオペレーティングシステムの情報（オペレーティングシステム名、バージョン情報など）、アーティスト端末３のアドレス情報（ＩＰアドレス、ＭＡＣアドレスなど）などを含む情報である。追加情報は、動的署名データ、署名した書類のハッシュ値、コンテキスト情報の他に、アートワーク管理システム１の管理者が任意で指定できる情報である。
　図１に戻る。ウェブサーバ４は、アートワークの管理を実現するための各種の処理を実行するサーバである。各種の処理には、アートワーク及びその関連データを分散ファイルシステム５又はブロックチェーンネットワーク６に登録する処理と、アートワークの利用申請を受け付ける処理とが含まれる。各処理の詳細については、後述する。なお、ウェブサーバ４が複数のコンピュータ１００の結合によって構成される場合、後述する各種の処理は複数のコンピュータ１００に分散して実行され得る。
　分散ファイルシステム５は、ピアツーピアによって接続された複数のコンピュータのネットワークであり、任意の電子データを格納するように構成される。具体的な分散ファイルシステム５は、上述した惑星間ファイルシステムであってもよいし、他の種類の分散ファイルシステムであってもよい。一例では、分散ファイルシステム５内に格納された電子データはそのハッシュ値によって識別される。すなわち、分散ファイルシステム５においては、格納された電子データのハッシュ値がその電子データのアドレス情報として機能する。本実施の形態では、暗号化されたアートワーク及び各種のＤＩＤドキュメントを格納するために分散ファイルシステム５が使用される。後述でも説明するが、ＳＳＩによってアートワークを管理する場合、分散ファイルシステム５に格納した個々のアートワークに対してＤＩＤを付与し、そのＤＩＤドキュメントの中に、アートワークの所有者を示すオーナー情報、アートワークの実体の置き場所を示すアドレス情報、ライセンス情報（二次創作の可否、商業利用の可否など）を配置する。
　ブロックチェーンネットワーク６は、ピアツーピアによって接続された複数のコンピュータのネットワークであり、スマート・コントラクトのトランザクションをブロックチェーンに記録するように構成される。具体的な例を挙げると、ブロックチェーンネットワーク６はイーサリアムネットワークである。トランザクションのブロックチェーンへの記録は、ブロックチェーンネットワーク６に接続されたいくつかのコンピュータ（以下、「マイナー」と称する）によって実行される。
　具体的に説明すると、ブロックチェーンを構成する各ブロックは、ブロックヘッダと、トランザクションの具体的な内容を示すデータ（取引データ）とを含んで構成される。このうちブロックヘッダには、取引データのサイズを圧縮してなるデータであるマークルルートと、１つ前のブロックのハッシュ値と、任意の文字列であるナンス値とが含まれる。ブロックチェーンネットワーク６においては、新たなブロックをブロックチェーンに接続するには、そのブロックのハッシュ値が所定の条件（例えば、「０００」で始まる値である、という条件）を満たしていなければならないというルールが定められている。そこで、ブロックチェーンにあるブロックを記録しようとするマイナーは、そのブロックのブロックヘッダのハッシュ値が上記所定の条件を満たすこととなるよう、総当たり的にナンス値を見つける作業（マイニング）を行う。この作業の結果として、最も早くナンス値の発見に成功したマイナーがそのブロックをブロックチェーンに連結することによって、トランザクションのブロックチェーンへの記録が完了する。
　以下、ウェブサーバ４が実行する各種の処理について、具体的に説明する。以下では、まず図４～図１３を参照しながら、他のアートワークに依拠せずに制作されたアートワーク（以下「アートワーク１」と称し、アートワーク１を制作したアーティストを「アーティスト１」又は「特許太郎」と称する）の登録にかかる処理を説明し、次いで図１４～図２３を参照しながらアートワーク１の利用申請にかかる処理を説明し、最後に図２４～図３１を参照しながら、アートワーク１に依拠して制作されたアートワーク（以下「アートワーク２」と称し、アートワーク２を制作したアーティストを「アーティスト２」又は「発明花子」と称する）の登録にかかる処理を説明する。
　初めに、アートワーク１の登録にかかる処理を説明する。図４～図８は、アートワーク１の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例である。このアーティスト端末３のユーザであるアーティスト１がウェブアプリ３ａを立ち上げると、ウェブアプリ３ａにより、図４に示すログイン画面が表示される。同図に示すように、ログイン画面には、メールアドレス入力欄１０、パスワード入力欄１１、及び、ログインボタン１２が含まれる。ここで、アーティスト１がウェブアプリ３ａに予め登録してあるメールアドレス及びパスワードをそれぞれメールアドレス入力欄１０及びパスワード入力欄１１に入力してログインボタン１２を押下すると、ウェブアプリ３ａにより図５の画面が表示される。
　図５に示すように、ログイン後に表示されるウェブアプリ３ａの画面は、左側にサイドメニューが配置された構成を有している。サイドメニュー内には、ログインしているユーザの写真１３及び氏名１４、登録済コンテンツ画面へのリンク１５、リクエスト一覧画面へのリンク１６、トランザクション画面へのリンク１７、プロフィール画面へのリンク１８、及び、マイプロジェクト画面へのリンク１９が配置される。これらの画面のうち登録済コンテンツ画面は、ログインしているユーザがアップロードしたアートワークを管理する画面であり、リクエスト一覧画面は、アートワークの利用申請（ログインしているユーザが行った利用申請と、ログインしているユーザに対して行われた利用申請とを含む）を管理する画面であり、トランザクション画面は、ブロックチェーンネットワーク６への記録の結果として得られたトランザクションＩＤを管理する画面であり、プロフィール画面は、ログインしているユーザの情報（氏名、写真、メールアドレス、パスワードなど。以下「ユーザ情報」と称する）を管理する画面であり、マイプロジェクト画面は、ログインしているユーザによって生成されたプロジェクト（後述）を管理する画面である。
　図５には、登録済みコンテンツが１つも存在しない場合の登録済コンテンツ画面を示している。同図に示すように、この場合の登録済コンテンツ画面には、登録ボタン２０が表示される。アートワーク１の制作を完了し、ウェブサーバ４に登録しようとするアーティスト１は、この登録ボタン２０を押下する。
　図６は、図５の登録ボタン２０の押下を検出したウェブアプリ３ａによって表示されるコンテンツ登録画面である。同図に示すように、コンテンツ登録画面には、コンテンツ名入力欄２１と、ファイルの選択インターフェイス２２と、アートワークのメタデータの入力インターフェイス２３と、登録ボタン２４とが含まれる。
　コンテンツ名入力欄２１は、アーティスト１が任意に名付けたアートワーク１の名称を入力するテキストボックスである。図６では、アートワーク１の名称として「ライダー」が入力されている。選択インターフェイス２２は、アーティスト１がこれから登録しようとするアートワークのファイルを選択するためのインターフェイスである。ここで選択するファイルは、例えばｊｐｇファイル、ｐｎｇファイルなどの画像ファイルであり、アートワーク１は、ここで選択された１以上のファイルによって構成される。後述する図２４に例示するように、選択インターフェイス２２は複数のファイルを含むフォルダも選択可能に構成される。図６には、２つの画像Ａ１，Ａ２が選択された状態を示している。画像Ａ２は例えば人物を含む絵であり、画像Ａ１は例えば画像Ａ２の一部拡大画像である。
　メタデータ入力インターフェイス２３は、アートワーク１を説明するための情報であるメタデータを入力するためのインターフェイスである。ここで入力されるメタデータの具体的な内容としては、図６に例示するように、アートワーク１がアーティスト１の知的財産（Intellectual Property。以下「ＩＰ」という）であるか否か（すなわち、アーティスト１がアートワーク１のオーナーであるか否か）を示す情報や、アートワーク１のライセンスに関する各種の情報が含まれ得る。図６の例では、このライセンスに関する各種の情報に、共同編集者ライセンスを設定するか否かを示す情報、商業ライセンスを設定するか否かを示す情報、及び、ユーザが独自に考えて入力する１以上の情報（独自のＩＰ設定）が含まれる。
　ユーザが登録ボタン２４を押下すると、ウェブアプリ３ａは、図７に示す署名ウィンドウ２５を表示する。署名ウィンドウ２５は、アーティスト１がペンＰを用いて手書きの署名を入力するためのインターフェイスと、確認ボタン２６とを有して構成される。署名を入力したアーティスト１が確認ボタン２６を押下すると、ウェブアプリ３ａは、入力された署名に基づいて図３に示したバイオメトリック署名データを生成したうえで、後述する図１０に示す登録要求をウェブサーバ４に送信する。詳しくは後述するが、ウェブサーバ４はこの登録要求に応じて、アートワーク１を分散ファイルシステム５に登録する処理、アートワーク１のＤＩＤ及びＤＩＤドキュメントを生成し、ＤＩＤドキュメントを分散ファイルシステム５に登録する一方、ＤＩＤをブロックチェーンネットワーク６に記録する処理、アートワーク１の真正性を証明するためのＶＣを生成する処理、アートワーク１を構成する各ファイルにウォーターマークを埋め込む処理を行う。
　図８は、ウェブサーバ４による一連の処理が完了した後、ウェブアプリ３ａによって表示される登録完了画面である。同図に示すように、登録完了画面には、所定の情報を表示するための表示欄２７～３１と、所定の操作を実行するための操作ボタン３２～３６とが含まれる。
　表示欄２７には、ウェブサーバ４によってブロックチェーンネットワーク６に記録されたアートワーク１のＤＩＤが表示される。表示欄２８には、アートワーク１を構成するファイルのサムネイルが一覧で表示される。このサムネイルをクリックすれば、アーティスト１は、対応するファイルをダウンロードすることができる。なお、ここでダウンロードされるファイルは後述するウォーターマーク付きのファイルであることが好ましいが、ウォーターマークが付加されていないファイルがダウンロードされることとしてもよい。表示欄２９には、ウェブサーバ４がアートワーク１を分散ファイルシステム５に登録する際に付与されるコンテンツＩＤが表示される。コンテンツＩＤは、具体的には、アートワーク１を構成する各ファイル及びメタデータからなるアートワークデータのハッシュ値である。表示欄３０には、分散ファイルシステム５におけるアートワーク１のアドレスが表示される。典型的な例では、このアドレスは、分散ファイルシステム５のＵＲＬ（Uniform Resource Locator）にコンテンツＩＤを付したものとなる。表示欄３１には、アートワーク１のメダテータの全部又は一部が表示される。
　操作ボタン３２は、アートワーク１を更新するための押しボタンである。操作ボタン３２が押下されたことを検出したウェブアプリ３ａは、アートワーク１を構成するファイルの追加、変更、削除を実行するための画面を表示する。操作ボタン３３は、アートワーク１の所有権を変更するための押しボタンである。操作ボタン３３が押下されたことを検出したウェブアプリ３ａは、アートワーク１の新たな所有者を指定するための画面を表示する。操作ボタン３４は、アートワーク１のメタデータを変更するための押しボタンである。操作ボタン３４が押下されたことを検出したウェブアプリ３ａは、アートワーク１のメタデータを変更するための画面を表示する。操作ボタン３２～３４の押下に応じて表示される画面において、対応する情報が実際に変更等された場合、ウェブアプリ３ａは、ウェブサーバ４に対して改めて登録要求を送信する。これにより、分散ファイルシステム５に登録されているアートワーク１が変更され、ブロックチェーンネットワーク６に新たなＤＩＤが記録され、新たなＶＣが発行され、アートワーク１を構成する各ファイルに新たなウォーターマークが埋め込まれることになる。
　操作ボタン３５は、アートワーク１をＳＮＳ（Social Networking Service）にアップロードするための押しボタンである。また、操作ボタン３６は、アートワーク１を販売サイトにアップロードするための押しボタンである。操作ボタン３５又は操作ボタン３６が押下されたことを検出したウェブアプリ３ａは、アートワーク１のアップロード先となるＳＮＳ又は販売サイトの選択画面を表示する。この画面においてユーザがあるＳＮＳ又は販売サイトを選択すると、ウェブアプリ３ａは、そのＳＮＳ又は販売サイトに対して、ウェブサーバ４によって発行されたＶＣとともに、アートワーク１を構成する各ファイル（ウォーターマークが埋め込まれたもの）及びメタデータからなるアートワークデータを送信する。これにより、ＳＮＳ又は販売サイト上で、アートワーク１の情報をセキュアに公開することが可能になる。
　次に、ウェブアプリ３ａ及びウェブサーバ４が行う処理について、詳しく説明する。初めに、図９は、新規ユーザの登録にかかる処理を示すシーケンス図である。同図に示すように、ウェブアプリ３ａ及びウェブサーバ４はまず、図４に示したログイン画面を用いてログイン処理を実行する（ステップＳ１）。なお、ウェブアプリ３ａにメールアドレス及びパスワードが未登録である場合には、このステップＳ１において、メールアドレス及びパスワードの組み合わせを含む各種のユーザ情報を登録する処理も実行される。
　ウェブサーバ４は、ログイン処理が終了すると、ユーザのキーペア（公開鍵暗号方式にかかる公開鍵と秘密鍵の組み合わせ。以下、同様。）が生成済みであるか否かを判定し、作成済みでなければ新たにキーペアを生成して記憶する（ステップＳ２）。ウェブアプリ３ａは、生成されたキーペアをウェブサーバ４から受信して記憶する（ステップＳ３）。
　また、ウェブサーバ４は、ユーザのＤＩＤと、上述したユーザ情報の全部又は一部を含むＤＩＤドキュメントとを生成して記憶する（ステップＳ４）。そして、生成したＤＩＤドキュメントを分散ファイルシステム５に登録する（ステップＳ５）とともに、生成したＤＩＤをブロックチェーンに記録するためのスマート・コントラクトをブロックチェーンネットワーク６に対して発行する（ステップＳ６）。ブロックチェーンへの記録が完了すると、ブロックチェーンネットワーク６によりトランザクションＩＤが発行される。ウェブサーバ４は、このトランザクションＩＤ（ユーザのトランザクションＩＤ）をブロックチェーンネットワーク６から受信し、記憶する（ステップＳ７）。また、ウェブサーバ４は、生成したユーザのＤＩＤ及びＤＩＤドキュメントをウェブアプリ３ａにも送信する（ステップＳ８）。ウェブアプリ３ａは、受信したＤＩＤ及びＤＩＤドキュメントを記憶しておき、後述するアートワーク１の登録要求を生成する際にユーザのＤＩＤを使用するとともに、上述したプロフィール画面を生成するためにユーザのＤＩＤドキュメントを使用する。
　図１０及び図１１は、アートワーク１の登録にかかる処理を示すシーケンス図である。初めにウェブアプリ３ａによって、図６に示したコンテンツ登録画面が表示される（ステップＳ１０）。ユーザが図６に示した登録ボタン２４を押下すると、ウェブアプリ３ａは、図７に示した署名ウィンドウ２５の表示を行い、そして、ウェブサーバ４に対してアートワーク１の登録要求を送信する（ステップＳ１１）。この登録要求には、図９のステップＳ７でウェブアプリ３ａが記憶したアーティスト１のＤＩＤと、アートワーク１を構成する各ファイル（図６に示した選択インターフェイス２２において選択されたもの）と、アートワーク１のメタデータ（図６に示したコンテンツ名入力欄２１に入力された名称、及び、図６に示したメタデータ入力インターフェイス２３において入力された各情報を含む情報）と、図７に示す署名ウィンドウ２５においてペン入力された署名に基づいて生成されたバイオメトリック署名データと、アーティスト１の電子署名とが含まれる。なお、図１０及び以降の各図では、バイオメトリック署名データとして「ＦＳＳ」を例示しているが、ＦＳＳ以外のバイオメトリック署名データを用いてもよいのは勿論である。また、ウェブアプリ３ａは、登録要求を構成するデータ（電子署名を除く）のハッシュ値をユーザの秘密鍵によって暗号化することにより、アーティスト１の電子署名を生成するよう構成される。
　アートワーク１の登録要求を受信したウェブサーバ４はまず、電子署名とバイオメトリック署名データの正当性を確認する（ステップＳ１２，Ｓ１３）。ここで、電子署名の正当性の確認は、登録要求に含まれる電子署名をユーザの公開鍵によって復号するとともに、登録要求を構成するデータ（電子署名を除く）のハッシュ値を導出し、これらを比較することによって行えばよい。また、バイオメトリック署名データの正当性の確認は、ユーザＤＩＤに対応付けて１以上の動的署名データを蓄積するデータベースから、登録要求に含まれるユーザＤＩＤに対応する１以上の動的署名データを取り出し、バイオメトリック署名データに含まれる動的署名データと比較することによって行えばよい。なお、この比較の結果としてバイオメトリック署名データの正当性が確認された場合、ウェブサーバ４は、登録要求に含まれていた動的署名データを、当該ユーザの新たな動的署名データとして上記データベースに追加することが好ましい。
　次にウェブサーバ４は、アートワーク１のキーペアを生成して記憶する（ステップＳ１４）。以下では、ここで生成したキーペアに含まれる秘密鍵を「アートワーク秘密鍵」と称し、公開鍵を「アートワーク公開鍵」と称する。そしてウェブサーバ４は、生成したアートワーク秘密鍵によりアートワークデータ（アートワーク１を構成する各ファイル及びメタデータからなるデータ）を暗号化して分散ファイルシステム５に登録し（ステップＳ１５）、その結果として得られる上記コンテンツＩＤ及びアドレスをウェブアプリ３ａに送信する（ステップＳ１７）。
　続いてウェブサーバ４は、アートワーク１のＤＩＤと、アートワーク１のメタデータの全部又は一部を含むＤＩＤドキュメントとを生成して記憶する（ステップＳ１８）。そして、生成したＤＩＤドキュメントを分散ファイルシステム５に登録する（ステップＳ１９）とともに、生成したＤＩＤをブロックチェーンに記録するためのスマート・コントラクトをブロックチェーンネットワーク６に対して発行する（ステップＳ２０）。ブロックチェーンへの記録が完了すると、ブロックチェーンネットワーク６によりトランザクションＩＤが発行される。ウェブサーバ４は、このトランザクションＩＤ（アートワーク１のトランザクションＩＤ）をブロックチェーンネットワーク６から受信し、記憶する（ステップＳ２１）。また、ウェブサーバ４は、生成したアートワーク１のＤＩＤ及びＤＩＤドキュメントをウェブアプリ３ａにも送信する（ステップＳ２２）。
　図１２（ａ）は、ステップＳ１８においてウェブサーバ４が生成するアートワーク１のＤＩＤドキュメントの構成例を示す図である。同図に示すように、アートワーク１のＤＩＤドキュメントは、オーナー、寄与者、二次創作、ＩＰシェア、利用態様、署名、格納場所、及び、公開鍵の各情報を含み得る。オーナーは、アートワーク１の所有権を保持しているユーザ（この場合はアーティスト１）であり、寄与者は、アートワーク１の制作に寄与したアーティスト（この場合はアーティスト１）である。オーナー及び寄与者のいずれにも、原則として、登録要求に含まれるユーザのＤＩＤが設定されるが、図６に示したコンテンツ登録画面において、ユーザによって個別に指定可能としても構わない。二次創作、ＩＰシェア、利用態様には、登録要求に含まれるメタデータの中の情報が設定される。なお、他の種類のメタデータをアートワーク１のＤＩＤドキュメント内に設定することとしてもよいのは勿論である。署名には、登録要求に含まれるバイオメトリック署名データのハッシュ値（バイオメトリック署名データに含まれる動的署名データを示す情報）が設定される。格納場所には、ウェブサーバ４がステップＳ１５においてアートワークデータを分散ファイルシステム５に登録した際に得られたアドレスが設定される。公開鍵には、ウェブサーバ４がステップＳ１４において生成したアートワーク公開鍵が設定される。
　次に図１１を参照すると、ウェブサーバ４は、登録要求に含まれていたバイオメトリック署名データ（又はその中に含まれる動的署名データ）に基づいてウォーターマークを生成し、アートワーク１を構成する各ファイルに埋め込む（ステップＳ２３）。具体的には、バイオメトリック署名データ又は動的署名データそのものをウォーターマークとしてもよいし、バイオメトリック署名データ又は動的署名データのハッシュ値をウォーターマークとしてもよい。そしてウェブサーバ４は、ウォーターマークの埋め込まれたウォーターマーク付きの各ファイルをアートワーク１のＤＩＤに対応付けて記憶するとともに（ステップＳ２４）、ウェブアプリ３ａに対して送信する（ステップＳ２５）。ステップＳ２４で記憶した各ファイルは、図８に示した登録完了画面、後述する図１４に示すアートワーク詳細画面などにおいてファイルを表示する際に使用される。
　続いてウェブサーバ４は、アートワークデータ内の各ファイルをウォーターマーク付きのファイルに入れ替えたうえで（ステップＳ２６）、アートワークデータ及びアートワーク１のＤＩＤドキュメントからなるデータのハッシュ値をウェブサーバ４の秘密鍵（以下「発行者秘密鍵」と称する）を用いて暗号化することにより、電子署名を生成する（ステップＳ２７）。そして、生成した電子署名と、ブロックチェーンネットワーク６から受信したアートワーク１のトランザクションＩＤとを含むＶＣを発行し（ステップＳ２８）、ウェブアプリ３ａに送信する（ステップＳ２９）。
　図１２（ｂ）は、アートワーク１のためのＶＣの内容を示す図である。同図に示すように、ＶＣには、発行日、発行者、発行者の電子署名、及びトランザクションＩＤが含まれる。発行日には、ウェブサーバ４がＶＣを発行した日付が設定される。発行者には、ＶＣを発行したウェブサーバ４を特定する情報（名称、アドレスなど）が設定される。発行者の電子署名には、ステップＳ２７で生成された電子署名が設定される。トランザクションＩＤには、ブロックチェーンネットワーク６から受信したアートワーク１のトランザクションＩＤが設定される。
　図１１に戻る。ウェブサーバ４からＶＣを受信したウェブアプリ３ａは、図８に示した登録完了画面を生成して表示する（ステップＳ３０）。これにより、一連の登録処理が完了する。
　図１３は、ＳＮＳ又は販売サイトを経由してアートワーク１のアートワークデータ及びＶＣを受け取ったコンピュータによって実行される処理のフローを示すフロー図である。なお、このコンピュータは、図１に示したアーティスト端末３であってもよいし、他のコンピュータであってもよい。以下、この図１３を参照して、アートワーク１のＶＣの具体的な用途を説明する。
　コンピュータは、ＳＮＳ又は販売サイト上で公開されたアートワークデータ（アートワーク１を構成する１以上のウォーターマーク付きファイル及びメタデータ）とともに、アートワーク１のＶＣを取得する（ステップＳ４０）。続いてコンピュータは、ＶＣ内に含まれるトランザクションＩＤに基づき、ブロックチェーンネットワーク６からアートワーク１のＤＩＤを取得し（ステップＳ４１）、さらに、取得したアートワーク１のＤＩＤに基づき、分散ファイルシステム５からアートワーク１のＤＩＤドキュメントを取得する（ステップＳ４２）。
　続いてコンピュータは、ステップＳ４０で取得したアートワークデータ、及び、ステップＳ４２で取得したアートワーク１のＤＩＤドキュメントからなるデータのハッシュ値を導出する（ステップＳ４３）。また、コンピュータは、ＶＣ内に含まれる発行者の情報に基づいて、当該ＶＣを発行した発行者の公開鍵（以下「発行者公開鍵」と称する）を取得し（ステップＳ４４）、取得した発行者公開鍵によりＶＣ内の電子署名を復号する（ステップＳ４５）。そして、復号によって得られたハッシュ値と、ステップＳ４３で導出したハッシュ値とを比較する（ステップＳ４６）。その結果、これらのハッシュ値が一致していれば、公開されたアートワークデータの真正性が確認されたことになる。このように、ＶＣによる検証を行うことで、公開されたアートワークデータの真正性を確認することが可能になる。
　なお、ここではＶＣの検証を行うコンピュータが分散ファイルシステム５からアートワーク１のＤＩＤドキュメントを取得する例を説明したが、ＳＮＳ又は販売サイトにおいて、アートワーク１のアートワークデータとともにＤＩＤドキュメントも公開することとしてもよい。この場合、ステップＳ４３のハッシュ値の導出では、公開されたＤＩＤドキュメントを用いればよいので、ＶＣ内にアートワーク１のトランザクションＩＤを配置しなくてもよい。
　次に、アーティスト２によるアートワーク１の利用申請にかかる処理を説明する。図１４、図１５、図１８は、アートワーク１の利用申請を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例である。また、図１６及び図１７は、アートワーク１の利用申請を受信したアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例である。
　図１４に示した画面は、アートワーク一覧表示画面においてアーティスト２がアートワーク１を選択することによって表示されるアートワーク詳細画面である。同図に示すように、このアートワーク詳細画面には、アートワーク１に関する情報の表示欄４０～４５と、リクエスト内容入力インターフェイス４６と、リクエストボタン４７とが含まれる。
　表示欄４０にはアートワーク１のオーナーの情報（写真、氏名など）が、表示欄４１にはアートワーク１のコンテンツ名が、表示欄４２にはアートワーク１のＤＩＤが、表示欄４３にはアートワーク１のオーナーである１以上のユーザのＤＩＤが、表示欄４４にはアートワーク１の寄与者である１以上のユーザの情報（写真、氏名など）がそれぞれ表示される。これらの情報を表示するため、ウェブサーバ４は、アートワーク１のＤＩＤからアートワーク１のＤＩＤドキュメントを取得し、さらに、その中に記述されているオーナー及び寄与者のＤＩＤからそれぞれのＤＩＤドキュメントを取得することにより、表示欄４０～４４に表示するデータを取得するよう構成される。また、表示欄４５には、図１１のステップＳ２４で記憶しておいたウォーターマーク付きファイルのサムネイルが表示される。
　リクエスト内容入力インターフェイス４６は、アートワーク１のオーナーに対するリクエストの内容を入力するためのインターフェイスである。ここで入力されるリクエストの具体的な内容としては、図１４に示すように、非商業ライセンスの内容、商業ライセンスの内容、利益の分配率の提案、任意の文章が含まれ得る。
　図１４には、アーティスト２がまだウェブアプリ３ａにログインしていない状態を示している。この状態でユーザがリクエストボタン４７を押下すると、ウェブアプリ３ａは、図４に示したログイン画面を表示し、アーティスト２にログイン処理を行わせる。その結果としてログインが成功すると、ウェブアプリ３ａは、図１５に示すリクエスト送信画面を表示する。
　リクエスト送信画面は、アーティスト２がウェブアプリ３ａにログインしているときに表示される画面であり、したがって図５と同様に、左側にサイドメニューを有している。サイドメニューに表示される情報の内容は、図５を参照して説明したとおりである。サイドメニューの右側には、図１４で説明した表示欄４０～４５及びリクエスト内容入力インターフェイス４６が改めて表示されるとともに、リクエスト送信ボタン４８及び連絡ボタン４９が新たに表示される。
　連絡ボタン４９は、利用申請とは別にアートワーク１のオーナーに連絡するための押しボタンである。連絡ボタン４９が押下されたことを検出したウェブアプリ３ａは、電子メールの入力画面を表示し、該画面に表示されている送信ボタンをアーティスト２が押下したことに応じて、アートワーク１のオーナーのメールアドレスに対して電子メールを送信する。なお、ここでは電子メールを用いる例を説明しているが、ＳＮＳなどの電子メール以外の通信手段を用いることとしてもよいのは勿論である。その場合、アートワーク１のオーナーのユーザ情報の一部として、アートワーク１のオーナーのＳＮＳに関する情報を予め記憶しておく必要がある。
　リクエスト送信ボタン４８は、アートワーク１の利用申請をアートワーク１のオーナーに対して実際に送信するための押しボタンである。リクエスト送信ボタン４８が押下されたことを検出したウェブアプリ３ａは、図１６に示す署名ウィンドウ５０を表示する。この署名ウィンドウ５０は、図７に示した署名ウィンドウ２５と同様のインターフェイスであり、アーティスト２がペンＰを用いて手書きの署名を入力するためのインターフェイスと、確認ボタン５１とを有して構成される。署名を入力したアーティスト２が確認ボタン５１を押下すると、ウェブアプリ３ａは、入力された署名に基づいて図３に示したバイオメトリック署名データを生成したうえで、後述する図２０に示す利用申請をウェブサーバ４に送信する。詳しくは後述するが、ウェブサーバ４はこの利用申請に応じて、オーナーに利用申請を通知する処理、オーナーの承認結果に応じて合意内容を取得する処理、利用申請にかかるプロジェクトのＤＩＤ及びＤＩＤドキュメントを生成し、ＤＩＤドキュメントを分散ファイルシステム５に登録する一方、ＤＩＤをブロックチェーンネットワーク６に記録する処理、プロジェクトの真正性を証明するためのＶＣを生成する処理を行う。
　図１７は、利用申請の通知を受けたアーティスト端末３（アートワーク１のオーナーであるアーティスト１のアーティスト端末３）のウェブアプリ３ａによって表示されるリクエスト一覧画面（サイドメニュー内のリンク１６を押下することによって表示される画面）である。この例では、他のコンピュータから受信した利用申請として、「ライダー」に対するリクエストが１件、画面内に表示されている。
　ここで、リクエスト一覧画面内に表示される利用申請の具体的な内容としては、例えば図１７に示すように、利用申請が送信された日付、利用申請の状態（申請中、許可、拒否など）、申請対象のアートワーク１を特定するデータ（コンテンツ名、アートワーク１を構成するファイルのサムネイルなど）、申請者、リクエストＩＤが用いられる。このうちリクエストＩＤは利用申請を一意に識別するための情報であり、利用申請の送信ごとにウェブサーバ４によって付与される。これら以外の情報、例えばアートワーク１のメタデータを構成する情報などを表示することとしてもよいのは、勿論である。
　リクエストＩＤは、図１８に示す利用申請詳細画面へのハイパーリンクとなっている。ユーザがこのハイパーリンクをクリックすると、ウェブアプリ３ａは、図１８に示す利用申請詳細画面を表示する。図１８に示すように、利用申請詳細画面には、表示欄５２～５８、許可ボタン５９、拒否ボタン６０、連絡ボタン６１が含まれる。
　表示欄５２にはアートワーク１のコンテンツ名が、表示欄５３にはアートワーク１のＤＩＤが、表示欄５４にはアートワーク１のオーナーであるユーザのＤＩＤが、表示欄５５には、アートワーク１を構成する１以上のウォーターマーク付きファイルのサムネイルが、表示欄５６にはアートワーク１のメタデータの全部又は一部が、表示欄５７には申請者の情報（写真、氏名など）が、表示欄５８にはリクエストの内容（図１５に示したリクエスト内容入力インターフェイス４６に入力されていた情報）がそれぞれ表示される。
　連絡ボタン６１は、申請者に連絡するための押しボタンである。連絡ボタン６１が押下されたことを検出したウェブアプリ３ａは、図１５に示した連絡ボタン４９の押下時と同様に、電子メールの入力画面を表示し、該画面に表示されている送信ボタンをユーザが押下したことに応じて、アートワーク１のオーナーのメールアドレスに対して電子メールを送信する。電子メールに代えて他の通信手段を用いてもよいのは、連絡ボタン４９に関して説明したとおりである。
　許可ボタン５９は、利用申請を受け入れるための押しボタンである。一方、拒否ボタン６０は、利用申請を拒絶するための押しボタンである。いずれかのボタンが押下されたことを検出したウェブアプリ３ａは、押下されたボタンに応じた情報（許可又は拒否）をウェブサーバ４に送信する。この情報に応じてウェブサーバ４が行う処理については後述する。
　図１９は、ウェブサーバ４が行った処理の結果として申請者であるアーティスト２のウェブアプリ３ａにより表示されるリクエスト一覧画面の一例を示す図である。この例では、利用申請がオーナーによって許可された結果として、表示される状態が「許可」となっている。この場合、図１９に示すように、例えばリクエストＩＤの近傍に、アートワーク１を構成する各ファイルをダウンロードするためのダウンロードボタン６２が表示される。ダウンロードボタン６２をユーザが押下した場合のウェブアプリ３ａの動作については、後述する。
　図２０及び図２１は、アートワーク１の利用申請にかかる処理を示すシーケンス図である。これらの図に示す「ウェブアプリ１」はアートワーク１のオーナーであるアーティスト１のアーティスト端末３上で動作しているウェブアプリ３ａを示し、「ウェブアプリ２」は申請者であるアーティスト２のアーティスト端末３上で動作しているウェブアプリ３ａを示す。
　初めにウェブアプリ３ａによって、図１５に示したリクエスト送信画面が表示される（ステップＳ５０）。ユーザが図１５に示したリクエスト送信ボタン４８を押下すると、ウェブアプリ３ａは、図１６に示した署名ウィンドウ５０の表示を経て、ウェブサーバ４に対してアートワーク１の利用申請を送信する（ステップＳ５１）。この登録要求には、申請者であるアーティスト２のＤＩＤと、アートワーク１のＤＩＤと、アートワーク１のオーナーであるアーティスト１のＤＩＤと、図１５に示したリクエスト内容入力インターフェイス４６に入力された情報と、図１６に示す署名ウィンドウ５０において入力された署名に基づいて生成されたバイオメトリック署名データと、アーティスト２の電子署名とが含まれる。ウェブアプリ３ａは、利用申請を構成するデータ（電子署名を除く）のハッシュ値をユーザの秘密鍵によって暗号化することにより、アーティスト２の電子署名を生成する。
　アートワーク１の利用申請を受信したウェブサーバ４はまず、電子署名とバイオメトリック署名データの正当性を確認する（ステップＳ５２，Ｓ５３）。それぞれの詳細については、図１０のステップＳ１２，Ｓ１３を参照して説明したものと同様である。
　次にウェブサーバ４は、アートワーク１のオーナーであるアーティスト１のウェブアプリ３ａに対し、利用申請を送信する（ステップＳ５４）。こうして利用申請を受信したウェブアプリ３ａは、図１７に示したように、受信した利用申請をリクエスト一覧画面内に表示し、その中のリクエストＩＤをアーティスト１がクリックしたことに応じて、図１８に示した利用申請詳細画面を表示する（ステップＳ５５）。そして、アーティスト１が許可ボタン５９を押下した場合には「許可」を示す情報を、アーティスト１が拒否ボタン６０を押下した場合には「拒否」を示す情報を、それぞれウェブサーバ４に対して送信する（ステップＳ５６）。
　ウェブサーバ４は、アートワーク１のオーナーのウェブアプリ３ａから受信された情報（オーナーの回答）が許可及び拒否のいずれであったかを判定し（ステップＳ５７）、拒否であった場合には申請者であるアーティスト２のウェブアプリ３ａに拒否を示す情報を送信する。この場合、図１９に示したリクエスト一覧画面において、対応する利用申請の状態欄に「拒否」が表示されることになる。一方、許可であった場合、ウェブサーバ４は、申請者とオーナーの間で合意された内容（原則として、図１５に示したリクエスト内容入力インターフェイス４６に入力された情報。ただし、申請者とオーナーによってその後に変更されることとしてもよい。）を取得する（ステップＳ５８）。
　続いてウェブサーバ４は、利用申請にかかるプロジェクトを新たに設定し、設定したプロジェクトのＤＩＤ及びＤＩＤドキュメントを生成して記憶する（ステップＳ５９）。そして、生成したＤＩＤドキュメントを分散ファイルシステム５に登録する（ステップＳ６０）とともに、生成したＤＩＤをブロックチェーンに記録するためのスマート・コントラクトをブロックチェーンネットワーク６に対して発行する（ステップＳ６１）。ブロックチェーンへの記録が完了すると、ブロックチェーンネットワーク６によりトランザクションＩＤが発行される。ウェブサーバ４は、このトランザクションＩＤ（プロジェクトのトランザクションＩＤ）をブロックチェーンネットワーク６から受信して記憶する（ステップＳ６２）。また、ウェブサーバ４は、生成したプロジェクトのＤＩＤ及びＤＩＤドキュメントを申請者のウェブアプリ３ａにも送信する（ステップＳ６３）。
　図２２（ａ）は、ステップＳ５９においてウェブサーバ４が生成するプロジェクトのＤＩＤドキュメントの構成例を示す図である。同図に示すように、プロジェクトのＤＩＤドキュメントは、オーナー、署名、対象のワーク、利用条件の各情報を含み得る。オーナーには、利用申請に含まれる申請者（この場合はアーティスト２）のＤＩＤが設定される。署名には、利用申請に含まれるバイオメトリック署名データのハッシュ値が設定される。対象のワークには、利用申請の対象となったアートワーク１のＤＩＤが設定される。利用条件には、ステップＳ５８で取得した合意内容を示す情報が設定される。
　次に図２１を参照すると、ウェブサーバ４は、プロジェクトのＤＩＤドキュメントのハッシュ値を発行者秘密鍵を用いて暗号化することにより、電子署名を生成する（ステップＳ６４）。そして、生成した電子署名と、ブロックチェーンネットワーク６から受信したプロジェクトのトランザクションＩＤとを含むＶＣ（検証可能な証明書）を発行し（ステップＳ６５）、申請者のウェブアプリ３ａに送信する（ステップＳ６６）。
　図２２（ｂ）は、プロジェクトのためのＶＣの内容を示す図である。このＶＣにも、図１２（ｂ）に示したアートワーク１のＶＣと同様に、発行日、発行者、発行者の電子署名、及びトランザクションＩＤが含まれる。発行日、発行者、発行者の電子署名の設定内容については、アートワーク１のＶＣと同様である。トランザクションＩＤには、ブロックチェーンネットワーク６から受信したプロジェクトのトランザクションＩＤが設定される。ただし、プロジェクトのＶＣはトランザクションＩＤを含まなくてもよい。
　図２１に戻る。プロジェクトのＶＣを受信したウェブアプリ３ａは、図１９に示したリクエスト一覧画面を表示する（ステップＳ６７）。この場合においては、対応する利用申請の状態欄に「許可」が表示されることになる。図１９に示したリクエスト一覧画面においてダウンロードボタン６２の押下を検出したウェブアプリ３ａは、ステップＳ６３で受信したプロジェクトのＤＩＤ及びＤＩＤドキュメント、ステップＳ６３で受信したプロジェクトのＶＣ、及び、アートワーク１を構成する各ファイルのダウンロードページを表示する。これにより申請者であるアーティスト２は、各情報を利用できるようになる。
　図２３は、ＳＮＳ又は販売サイトを経由してプロジェクトのＤＩＤドキュメント及びＶＣを受け取ったコンピュータによって実行される処理のフローを示すフロー図である。なお、このコンピュータは、図１に示したアーティスト端末３であってもよいし、他のコンピュータであってもよい。以下、この図２３を参照して、プロジェクトのＶＣの具体的な用途を説明する。
　コンピュータは、ＳＮＳ又は販売サイト上で公開されたプロジェクトのＤＩＤドキュメントとともに、当該プロジェクトのＶＣを取得する（ステップＳ７０）。続いてコンピュータは、取得したＤＩＤドキュメントのハッシュ値を導出する（ステップＳ７１）。また、コンピュータは、ＶＣ内に含まれる発行者の情報に基づいて発行者公開鍵を取得し（ステップＳ７２）、取得した発行者公開鍵によりＶＣ内の電子署名を復号する（ステップＳ７３）。そして、復号によって得られたハッシュ値と、ステップＳ７４で導出したハッシュ値とを比較する（ステップＳ７４）。その結果、これらのハッシュ値が一致していれば、公開されたＤＩＤドキュメント（及びその中に含まれる合意内容）の真正性が確認されたことになる。このように、ＶＣによる検証を行うことで、アートワーク１のオーナーと利用申請を行った申請者との間で合意された内容の真正性を確認することが可能になる。
　最後に、アートワーク１に依拠して制作されたアートワーク２の登録にかかる処理を説明する。図２４～図２６は、アートワーク２の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例である。このアーティスト端末３のユーザであるアーティスト２がサイドメニュー内にあるリンク１９を押下すると、ウェブアプリ３ａは、上述したマイプロジェクト画面を表示する。このマイプロジェクト画面においてアーティスト２がアートワーク１にかかるプロジェクトを選択した場合、ウェブアプリ３ａは、図２４に示すコンテンツ登録画面を表示する。
　図２４に示すコンテンツ登録画面には、コンテンツ名入力欄７０と、オリジナルワーク表示欄７１と、ファイルの選択インターフェイス７２と、アートワークのメタデータの入力インターフェイス７３と、登録ボタン７４とが含まれる。
　コンテンツ名入力欄７０は、ユーザが任意に名付けたアートワーク２の名称を入力するテキストボックスである。図６においては、このコンテンツ名入力欄７０にアートワーク１と同じ「ライダー」が入力されているが、アートワーク１の名称と異なる名称を入力してもよい。オリジナルワーク表示欄７１には、プロジェクトの対象ワーク（以下「オリジナルワーク」と称する）を示す情報（コンテンツ名、コンテンツＩＤ、サムネイルなど）が表示される。
　選択インターフェイス７２は、ユーザがこれから登録しようとするアートワークのファイルを選択するためのインターフェイスである。ここで選択するファイルは、図６に示した選択インターフェイス２２と同様に、例えばｊｐｇファイル、ｐｎｇファイルなどの画像ファイル、又は、複数のファイルを含むフォルダである。図２４には、１つのフォルダＦ１と、１つの画像Ｂ１とが選択された状態を示している。画像Ｂ１は、例えば画像Ａ２内に含まれる人物の３Ｄモデルである。フォルダＦ１には、例えば、画像Ｂ１の表示のために使用されるテクスチャ（３Ｄテクスチャ）を構成する１以上の画像ファイルが含まれ得る。フォルダＦ１内の各ファイルは、画像Ｂ１とともにアートワーク２を構成する。
　メタデータ入力インターフェイス７３は、アートワーク２を説明するための情報であるメタデータを入力するためのインターフェイスである。後述するように、アートワーク２はアートワーク１のオーナーとの共有にかかることから、一部のメタデータについては、ここでは編集できなくなっている。一方、他のメタデータについては入力可能とされており、図２４には、そのようなメタデータの例として、アーティスト２による寄与の内容とＩＰ設定とが示されている。
　ユーザが登録ボタン７４を押下すると、ウェブアプリ３ａは、図２５に示す署名ウィンドウ７５を表示する。この署名ウィンドウ７５は、図７に示した署名ウィンドウ２５や図１６に示した署名ウィンドウ５０と同様のインターフェイスであり、ユーザがペンＰを用いて手書きの署名を入力するためのインターフェイスと、確認ボタン７６とを有して構成される。署名を入力したユーザが確認ボタン７６を押下すると、ウェブアプリ３ａは、入力された署名に基づいて図３に示したバイオメトリック署名データを生成したうえで、後述する図２８に示す登録要求をウェブサーバ４に送信する。詳しくは後述するが、ウェブサーバ４はこの登録要求に応じて、アートワーク２を分散ファイルシステム５に登録する処理、アートワーク２のＤＩＤ及びＤＩＤドキュメントを生成し、ＤＩＤドキュメントを分散ファイルシステム５に登録する一方、ＤＩＤをブロックチェーンネットワーク６に記録する処理、アートワーク２の真正性を証明するためのＶＣを生成する処理、アートワーク２を構成する各ファイルにウォーターマークを埋め込む処理を行う。
　図２６は、ウェブサーバ４が行う一連の処理が完了した後、ウェブアプリ３ａによって表示される登録完了画面である。同図に示すように、登録完了画面には、所定の情報を表示するための表示欄７７～８３と、所定の操作を実行するための操作ボタン８４～８７とが含まれる。
　表示欄７７には、ウェブサーバ４によってブロックチェーンネットワーク６に記録されたアートワーク２のＤＩＤが表示される。表示欄７８には、アートワーク２を構成するファイルのサムネイルが一覧で表示される。このサムネイルをクリックすれば、ユーザは対応するファイルをダウンロードすることができるが、ここでダウンロードされるファイルは、後述するウォーターマーク付きのファイルとなる。表示欄７９には、オリジナルワークを示す情報（コンテンツ名、コンテンツＩＤ、サムネイルなど）が表示される。表示欄８０には、アートワーク２の制作に関わった１以上のアーティスト（この場合はアーティスト１及びアーティスト２）の情報（写真、氏名など）が表示される。
　表示欄８１には、ウェブサーバ４がアートワーク２を分散ファイルシステム５に登録する際に付与されるコンテンツＩＤが表示される。コンテンツＩＤは、具体的には、アートワーク２を構成する各ファイル及びメタデータからなるアートワークデータのハッシュ値である。表示欄８２には、分散ファイルシステム５におけるアートワーク２のアドレスが表示される。表示欄８３には、アートワーク２のメダテータの全部又は一部が表示される。
　操作ボタン８４は、アートワーク２を更新するための押しボタンである。操作ボタン８４が押下されたことを検出したウェブアプリ３ａは、アートワーク２を構成するファイルの追加、変更、削除を実行するための画面を表示する。また、操作ボタン８５は、アートワーク２のメタデータを変更するための押しボタンである。操作ボタン８５が押下されたことを検出したウェブアプリ３ａは、アートワーク２のメタデータを変更するための画面を表示する。操作ボタン８４，８５の押下に応じて表示される画面において、対応する情報が実際に変更等された場合、ウェブアプリ３ａは、ウェブサーバ４に対して改めて登録要求を送信する。これにより、分散ファイルシステム５に登録されているアートワーク２が変更され、ブロックチェーンネットワーク６に新たなＤＩＤが記録され、新たなＶＣが発行され、アートワーク２を構成する各ファイルに新たなウォーターマークが埋め込まれることになる。
　操作ボタン８６は、アートワーク２をＳＮＳにアップロードするための押しボタンである。また、操作ボタン８７は、アートワーク２を販売サイトにアップロードするための押しボタンである。これらの詳細は、図８を参照して説明した操作ボタン３５，３６と同様である。
　図２７は、図示しないアートワーク一覧表示画面においてユーザがアートワーク２を選択することによって表示されるアートワーク詳細画面である。同図に示すように、このアートワーク詳細画面には、アートワーク２に関する情報の表示欄８８～９４と、リクエスト内容入力インターフェイス９５と、リクエストボタン９６とが含まれる。このうちリクエスト内容入力インターフェイス９５及びリクエストボタン９６の詳細は、図１４を参照して説明したリクエスト内容入力インターフェイス４６及びリクエストボタン４７と同様である。
　表示欄８８にはアートワーク２を制作したアーティスト２の情報（写真、氏名など）が表示される。図１４に示したアートワーク詳細画面と異なり、ここにＩＰオーナーを表示していないのは、アーティスト２が単独でアートワーク２のオーナーを構成しているわけではないことによる。
　表示欄８９には、オリジナルワークを示す情報（コンテンツ名、コンテンツＩＤ、サムネイルなど）が表示される。表示欄９０にはアートワーク２のコンテンツ名が、表示欄９１にはアートワーク２のＤＩＤが、表示欄９２にはアートワーク２のオーナー（アートワーク２のＤＩＤドキュメントに設定されているオーナー）である１以上のユーザ（この場合はアーティスト１及びアーティスト２）のＤＩＤが、表示欄９３にはアートワーク２の寄与者（アートワーク２のＤＩＤドキュメントに設定されている寄与者）である１以上のユーザ（この場合はアーティスト１及びアーティスト２）の情報（写真、氏名など）がそれぞれ表示される。ウェブサーバ４がこれらの情報を取得する方法は、図１４を参照して説明したとおりである。表示欄９４には、後述する図２９のステップＳ９４で記憶しておいたウォーターマーク付きファイルのサムネイルが表示される。
　図２８～図３０は、アートワーク２の登録にかかる処理を示すシーケンス図である。図２８に示す処理のうちステップＳ８０～Ｓ８７にかかる処理の具体的な内容は、アートワーク１がアートワーク２に替わる他は、図１０に示したステップＳ１０～Ｓ１７にかかる処理と同様である。ただし、登録要求に含まれるアートワーク２のメタデータは、ウェブアプリ３ａが図２４に示したメタデータ入力インターフェイス７３と、対応するプロジェクトのＤＩＤドキュメント内に設定されている合意内容とに基づいて生成したデータとなる。処理の結果として、アートワーク２のコンテンツＩＤ及びアドレスがウェブアプリ３ａに送信される（ステップＳ８７）。
　ステップＳ８７を終了したウェブサーバ４は、アートワーク２のＤＩＤと、アートワーク２のメタデータの全部又は一部を含むＤＩＤドキュメントとを生成して記憶したうえで（ステップＳ８８）、ステップＳ８９～Ｓ９２の処理を行う。ステップＳ８９～Ｓ９２にかかる処理の具体的な内容も、アートワーク１がアートワーク２に替わる他は、図１０に示したステップＳ１９～Ｓ２２にかかる処理と同様である。処理の結果として、アートワーク２のＤＩＤ及びＤＩＤドキュメントがウェブアプリ３ａに送信される（ステップＳ９２）。
　図３１（ａ）は、ステップＳ８８においてウェブサーバ４が生成するアートワーク２のＤＩＤドキュメントの構成例を示す図である。アートワーク２のＤＩＤドキュメントの構成要素は、図１２（ａ）に示したアートワーク１のＤＩＤドキュメントと同様であるが、その内容が一部異なっている。特に、オーナーには、アートワーク１のオーナーであるアーティスト１のＤＩＤと、アートワーク２を制作したアーティスト２のＤＩＤとの両方がそれぞれの持ち分とともに設定される。また、寄与者には、アーティスト１のＤＩＤとアーティスト２のＤＩＤとがそれぞれの寄与内容とともに設定される。
　次に図２９を参照すると、ウェブサーバ４はステップＳ９３～Ｓ９９の処理を行う。ステップＳ９３～Ｓ９９にかかる処理の具体的な内容も、アートワーク１がアートワーク２に替わる他は、図１１に示したステップＳ２３～Ｓ２９にかかる処理と同様である。処理の結果として、ウォーターマーク付きの各ファイルと、アートワーク２のＶＣとがウェブアプリ３ａに送信される（ステップＳ９５，Ｓ９９）。
　図３１（ｂ）は、アートワーク２のためのＶＣの内容を示す図である。図１２（ｂ）に示したＶＣと比較すると理解されるように、アートワーク２のためのＶＣは、アートワーク１のためのＶＣと同様の構成を有している。ただし、発行者の電子署名には、アートワーク２のアートワークデータ及びＤＩＤドキュメントからなるデータのハッシュ値を発行者の秘密鍵で暗号化したものが設定され、トランザクションＩＤには、アートワーク２のトランザクションＩＤが設定される。
　次に図３０を参照すると、ウェブサーバ４は、図３０に示すように、対応するプロジェクトのＤＩＤドキュメントにアートワーク２のＤＩＤを追記し（ステップＳ１００）、追記したＤＩＤドキュメントにより、記憶しているプロジェクトのＤＩＤドキュメントを更新するとともに、分散ファイルシステム５に記憶されているプロジェクトのＤＩＤドキュメントも更新する（ステップＳ１０１）。ウェブサーバ４はまた、更新後のＤＩＤドキュメントをウェブアプリ３ａに対して送信する（ステップＳ１０２）。
　図３１（ｃ）は、ステップＳ１０１において更新されたプロジェクトのＤＩＤドキュメントを示す図である。同図と図２２（ａ）を比較すると理解されるように、更新後のＤＩＤドキュメントには派生ワークの欄が追加され、そこにアートワーク２のＤＩＤが設定されている。これにより、プロジェクトに従って生成された派生ワークをプロジェクトのＤＩＤドキュメント内で管理することが可能になる。
　図３０に戻る。ウェブサーバ４は次に、ステップＳ１０３～Ｓ１０５の処理を行う。ステップＳ１０３～Ｓ１０５にかかる処理の具体的な内容は、図２１に示したステップＳ６４～Ｓ６６にかかる処理と同様である。処理の結果として、プロジェクトの新たなＶＣがウェブアプリ３ａに対して送信される（ステップＳ１０５）。ウェブサーバ４からＶＣを受信したウェブアプリ３ａは図２６に示した登録完了画面を生成して表示し（ステップＳ１０６）、これにより一連の登録処理が完了する。
　以上説明したように、本実施の形態によるアートワーク管理システム１によれば、アートワーク１の利用申請を受信したことに応じて、ウェブサーバ５がアートワーク１のＤＩＤと、アートワーク１の利用申請を送信したユーザのＤＩＤとを含むプロジェクトのＤＩＤドキュメントを生成するので、アートワークに関する情報をＳＳＩによって適切に管理することが可能になる。
　また、本実施の形態によるアートワーク管理システム１によれば、プロジェクトのＤＩＤドキュメントを見ることでオリジナルワークであるアートワーク１と、そこから派生したワークであるアートワーク２との関係を知ることができる。一例を挙げて説明すると、人物を含む絵があり、その絵の中の人物の３Ｄモデルを作成する場合、人物の絵という２次元のアートワークが３次元のアートワークに派生したということになるが、本実施の形態によるアートワーク管理システム１によって生成されるプロジェクトのＤＩＤドキュメントによれば、人物の絵から３Ｄモデルへの進化の過程を管理することが可能となる。しかも、プロジェクトのＤＩＤドキュメントとともに配布されるＶＣ内の電子署名に基づく検証を行うことによって、プロジェクトのＤＩＤドキュメントの真正性を確保することができる。したがって、オリジナルワークであるアートワーク１からアートワーク２への進化に関する情報をＳＳＩによって適切に管理することが可能になる。
　また、プロジェクトのＤＩＤドキュメントの中に、アートワーク１のオーナーとアートワーク２を制作したアーティストとの間で合意された内容を配置しているので、プロジェクトのＤＩＤドキュメントにより、アートワーク１のライセンス条件などのプロジェクトに関わる各種情報もＳＳＩによって管理することが可能になる。
　また、アートワーク２のＤＩＤドキュメントの中に、アーティスト１のＤＩＤ及びアーティスト２のＤＩＤを配置するとともに、それぞれの持ち分や寄与の内容を示す情報を配置しているので、これらの情報もＳＳＩによって管理することが可能になる。
　以上、本発明の好ましい実施の形態について説明したが、本発明はこうした実施の形態に何等限定されるものではなく、本発明が、その要旨を逸脱しない範囲において、種々なる態様で実施され得ることは勿論である。
　例えば、上記実施の形態では、登録要求に応じ、全体としてのアートワークに対してＤＩＤ及びＤＩＤドキュメントを生成する例を説明したが、アートワークを構成する個々のファイルに対してもＤＩＤ及びＤＩＤドキュメントを生成することとしてもよい。また、生成したＤＩＤ及びＤＩＤドキュメントについて、全体としてのアートワークに対してのＤＩＤ及びＤＩＤドキュメントと同様に、ブロックチェーンネットワーク６への記録と分散ファイルシステム５への登録を行うこととしてもよい。
　また、上記実施の形態では、アートワークデータの真正性を証明するためのＶＣを発行する例を説明したが、個々のファイルやバイオメトリック署名データの真正性を証明するためのＶＣも発行することとしてもよい。
１　　　　　アートワーク管理システム
３　　　　　アーティスト端末
３ａ　　　　ウェブアプリ
４　　　　　ウェブサーバ
５　　　　　分散ファイルシステム
６　　　　　ブロックチェーンネットワーク
１０　　　　メールアドレス入力欄
１１　　　　パスワード入力欄
１２　　　　ログインボタン
１３　　　　写真
１４　　　　氏名
１５～１９　リンク
２０，２４，７４　登録ボタン
２１，７０　コンテンツ名入力欄
２２，７２　ファイル選択インターフェイス
２３，７３　メタデータ入力インターフェイス
２５，５０，７５　署名ウィンドウ
２６，５１，７６　確認ボタン
２７～３１，４０～４５，５２～５８，７７～８３，８８～９４　表示欄
３２～３６，８４～８７　操作ボタン
４６，９５　リクエスト内容入力インターフェイス
４７，９６　リクエストボタン
４８　　　　リクエスト送信ボタン
４９，６１　連絡ボタン
５９　　　　許可ボタン
６０　　　　拒否ボタン
６２　　　　ダウンロードボタン
７１　　　　オリジナルワーク表示欄
１００　　　コンピュータ
１０２　　　記憶装置
１０３　　　入力装置
１０４　　　出力装置
１０５　　　通信装置
Ａ１，Ａ２，Ｂ１　画像
Ｆ１　　　　フォルダ

Claims (25)

  1. 　コンピュータによって実行されるアートワークの管理方法であって、
    　前記コンピュータは、第１のアートワークの利用のリクエストを受信し、
    　前記コンピュータは、前記第１のアートワークを識別するＤＩＤである第１のＤＩＤを含むとともに、前記第１のアートワークの利用をリクエストするユーザを識別するＤＩＤである第２のＤＩＤを含むＤＩＤドキュメントである第１のＤＩＤドキュメントを生成する、
    　アートワークの管理方法。
  2. 　前記コンピュータは、前記第１のＤＩＤドキュメントに基づいて第１の電子署名を生成し、
    　前記コンピュータは、前記第１の電子署名を含む第１の証明書を発行する、
    　請求項１に記載のアートワークの管理方法。
  3. 　前記コンピュータは、前記第１のＤＩＤドキュメントを生成するとともに、前記第１のＤＩＤに関連づけられる第３のＤＩＤを生成し、
    　前記コンピュータは、前記第３のＤＩＤのブロックチェーンへの記録に伴い生成されるトランザクションＩＤを受信し、
    　前記第１の証明書は、前記第１の電子署名及び前記トランザクションＩＤを含む、
    　請求項２に記載のアートワークの管理方法。
  4. 　前記第１のＤＩＤドキュメントは、前記第１のアートワークのオーナーと、前記ユーザとの間で合意された内容を含む、
    　請求項１に記載のアートワーク管理方法。
  5. 　前記コンピュータは、前記第１のアートワークに依拠して制作された第２のアートワークの登録要求を受信し、
    　前記コンピュータは、前記第２のアートワークを識別するＤＩＤである第４のＤＩＤを生成するとともに、前記第２のアートワークのアーティストを識別するＤＩＤである第５のＤＩＤを含むＤＩＤドキュメントである第２のＤＩＤドキュメントを生成する、
    　請求項１に記載のアートワークの管理方法。
  6. 　前記第２のＤＩＤドキュメントは、前記第１のアートワークのアーティストを識別するＤＩＤである第６のＤＩＤを含む、
    　請求項５に記載のアートワーク管理方法。
  7. 　前記第２のＤＩＤドキュメントは、前記第１のアートワークを制作したアーティスト、及び、前記第２のアートワークを制作したアーティストそれぞれの持ち分を示す情報を含む、
    　請求項６に記載のアートワーク管理方法。
  8. 　前記第２のＤＩＤドキュメントは、前記第１のアートワークを制作したアーティスト、及び、前記第２のアートワークを制作したアーティストそれぞれの寄与の内容を示す情報を含む、
    　請求項６又は７に記載のアートワーク管理方法。
  9. 　前記コンピュータは、前記第２のアートワークを構成するアートワークデータ及び前記第２のＤＩＤドキュメントからなるデータに基づいて第２の電子署名を生成し、
    　前記コンピュータは、前記第２の電子署名を含む第２の証明書を発行する、
    　請求項６乃至８のいずれか一項に記載のアートワーク管理方法。
  10. 　前記第２の証明書は、前記第２のアートワークＤＩＤをブロックチェーンに登録する場合に発行されるトランザクションＩＤを含む、
    　請求項９に記載のアートワーク管理方法。
  11. 　前記登録要求は、ペン入力を行うことによって生成されたデジタルインクデータである動的署名データを含み、
    　前記第１のＤＩＤドキュメントは、前記動的署名データを示す情報を含む、
    　請求項５乃至１０のいずれか一項に記載のアートワーク管理方法。
  12. 　前記コンピュータは、前記動的署名データに基づいてウォーターマークを生成し、前記第２のアートワークを構成する１以上のファイルのそれぞれに埋め込む、
    　請求項１１に記載のアートワーク管理方法。
  13. 　前記第１のアートワーク及び前記第２のアートワークはそれぞれ、ペン入力を行うことによって生成されたデジタルインクデータを含む、
    　請求項５乃至１２のいずれか一項に記載のアートワーク管理方法。
  14. 　第１のアートワークの利用のリクエストを受信し、
    　前記第１のアートワークを識別するＤＩＤである第１のＤＩＤを含むとともに、前記第１のアートワークの利用をリクエストするユーザを識別するＤＩＤである第２のＤＩＤを含むＤＩＤドキュメントである第１のＤＩＤドキュメントを生成する、
    　コンピュータ。
  15. 　前記第１のＤＩＤドキュメントに基づいて第１の電子署名を生成し、
    　前記コンピュータは、前記第１の電子署名を含む第１の証明書を発行する、
    　請求項１４に記載のコンピュータ。
  16. 　前記第１のＤＩＤドキュメントを生成するとともに、前記第１のＤＩＤに関連づけられる第３のＤＩＤを生成し、
    　前記第３のＤＩＤのブロックチェーンへの記録に伴い生成されるトランザクションＩＤを受信し、
    　前記第１の証明書は、前記第１の電子署名及び前記トランザクションＩＤを含む、
    　請求項１５に記載のコンピュータ。
  17. 　前記第１のＤＩＤドキュメントは、前記第１のアートワークのオーナーと、前記ユーザとの間で合意された内容を含む、
    　請求項１４に記載のコンピュータ。
  18. 　前記第１のアートワークに依拠して制作された第２のアートワークの登録要求を受信し、
    　前記第２のアートワークを識別するＤＩＤである第４のＤＩＤを生成するとともに、前記第２のアートワークのアーティストを識別するＤＩＤである第５のＤＩＤを含むＤＩＤドキュメントである第２のＤＩＤドキュメントを生成する、
    　請求項１４に記載のコンピュータ。
  19. 　前記第２のＤＩＤドキュメントは、前記第１のアートワークのアーティストを識別するＤＩＤである第６のＤＩＤを含む、
    　請求項１８に記載のコンピュータ。
  20. 　コンピュータに、
    　　第１のアートワークの利用のリクエストを受信し、
    　　前記第１のアートワークを識別するＤＩＤである第１のＤＩＤを含むとともに、前記第１のアートワークの利用をリクエストするユーザを識別するＤＩＤである第２のＤＩＤを含むＤＩＤドキュメントである第１のＤＩＤドキュメントを生成する、
    　処理を実行させるためのプログラム。
  21. 　前記コンピュータに、
    　　前記第１のＤＩＤドキュメントに基づいて第１の電子署名を生成し、
    　　前記コンピュータは、前記第１の電子署名を含む第１の証明書を発行する、
    　処理を実行させるための請求項２０に記載のプログラム。
  22. 　前記コンピュータに、
    　　前記第１のＤＩＤドキュメントを生成するとともに、前記第１のＤＩＤに関連づけられる第３のＤＩＤを生成し、
    　　前記第３のＤＩＤのブロックチェーンへの記録に伴い生成されるトランザクションＩＤを受信する処理を実行させ、
    　前記第１の証明書は、前記第１の電子署名及び前記トランザクションＩＤを含む、
    　請求項２１に記載のプログラム。
  23. 　前記第１のＤＩＤドキュメントは、前記第１のアートワークのオーナーと、前記ユーザとの間で合意された内容を含む、
    　請求項２０に記載のプログラム。
  24. 　前記コンピュータに、
    　　前記第１のアートワークに依拠して制作された第２のアートワークの登録要求を受信し、
    　　前記第２のアートワークを識別するＤＩＤである第４のＤＩＤを生成するとともに、前記第２のアートワークのアーティストを識別するＤＩＤである第５のＤＩＤを含むＤＩＤドキュメントである第２のＤＩＤドキュメントを生成する、
    　処理を実行させるための請求項２０に記載のプログラム。
  25. 　前記第２のＤＩＤドキュメントは、前記第１のアートワークのアーティストを識別するＤＩＤである第６のＤＩＤを含む、
    　請求項２４に記載のプログラム。
PCT/JP2022/014311 2021-04-06 2022-03-25 アートワーク管理方法、コンピュータ、及びプログラム WO2022220062A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2022546706A JP7180038B1 (ja) 2021-04-06 2022-03-25 アートワーク管理方法、コンピュータ、及びプログラム
CN202280022914.0A CN117043774A (zh) 2021-04-06 2022-03-25 艺术品管理方法、计算机及程序
EP22787987.1A EP4296876A4 (en) 2021-04-06 2022-03-25 METHOD FOR MANAGING ILLUSTRATIONS, COMPUTER AND PROGRAM
JP2022183495A JP2023143661A (ja) 2021-04-06 2022-11-16 アートワークの管理方法、コンピュータ、及びプログラム
US18/461,381 US20230418984A1 (en) 2021-04-06 2023-09-05 Artwork managing method, computer, and program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021064893 2021-04-06
JP2021-064893 2021-04-06

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/461,381 Continuation US20230418984A1 (en) 2021-04-06 2023-09-05 Artwork managing method, computer, and program

Publications (1)

Publication Number Publication Date
WO2022220062A1 true WO2022220062A1 (ja) 2022-10-20

Family

ID=83640610

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/014311 WO2022220062A1 (ja) 2021-04-06 2022-03-25 アートワーク管理方法、コンピュータ、及びプログラム

Country Status (5)

Country Link
US (1) US20230418984A1 (ja)
EP (1) EP4296876A4 (ja)
JP (2) JP7180038B1 (ja)
CN (1) CN117043774A (ja)
WO (1) WO2022220062A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024090530A1 (en) * 2022-10-26 2024-05-02 Nec Corporation Decentralized identity management apparatus, decentralized identity management system, decentralized identity management method, and decentralized identity management storage medium

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210075774A1 (en) * 2019-09-05 2021-03-11 Microsoft Technology Licensing, Llc Control of the delegated use of did-related data
WO2021090838A1 (ja) * 2019-11-08 2021-05-14 株式会社ワコム アートワークの取引方法及び取引装置、並びに、プログラム
US20210312073A1 (en) * 2020-09-04 2021-10-07 Alipay (Hangzhou) Information Technology Co., Ltd. Data processing methods, apparatuses, and devices

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA3001899C (en) * 2015-10-16 2023-07-18 Syngrafii Inc. System and method for providing authentic signatures on demand
CN107679045B (zh) * 2016-08-01 2021-08-31 华为技术有限公司 版权授权管理方法及系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210075774A1 (en) * 2019-09-05 2021-03-11 Microsoft Technology Licensing, Llc Control of the delegated use of did-related data
WO2021090838A1 (ja) * 2019-11-08 2021-05-14 株式会社ワコム アートワークの取引方法及び取引装置、並びに、プログラム
US20210312073A1 (en) * 2020-09-04 2021-10-07 Alipay (Hangzhou) Information Technology Co., Ltd. Data processing methods, apparatuses, and devices

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Decentralized Identifiers (DIDs) v1.0", WORLD WIDE WEB CONSORTIUM, 26 March 2021 (2021-03-26), Retrieved from the Internet <URL:"https://www.w3.org/TR/did-core/>
"Verifiable Credentials Data Model 1.0", WORLD WIDE WEB CONSORTIUM, 26 March 2021 (2021-03-26), Retrieved from the Internet <URL:https://www.w3.org/TR/vc-data-model/>
See also references of EP4296876A4

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024090530A1 (en) * 2022-10-26 2024-05-02 Nec Corporation Decentralized identity management apparatus, decentralized identity management system, decentralized identity management method, and decentralized identity management storage medium

Also Published As

Publication number Publication date
JP2023143661A (ja) 2023-10-06
JP7180038B1 (ja) 2022-11-29
EP4296876A4 (en) 2024-04-24
CN117043774A (zh) 2023-11-10
JPWO2022220062A1 (ja) 2022-10-20
US20230418984A1 (en) 2023-12-28
EP4296876A1 (en) 2023-12-27

Similar Documents

Publication Publication Date Title
JP6961818B2 (ja) データ共有方法、クライアント、サーバ、コンピューティングデバイス、及び記憶媒体
US11049205B2 (en) System and method for electronically providing legal instrument
TWI714843B (zh) 用於具有分散式共識之分散式系統中之契約資料之存取控制方法及其契約產生器及驗證伺服器
KR102144302B1 (ko) 저작권 관리 방법 및 시스템
JP7007985B2 (ja) 鍵を有するリソースロケーター
US20190182042A1 (en) Methods and systems for recovering data using dynamic passwords
CN109690549B (zh) 跨不同方来跟踪对象
US20230108366A1 (en) Systems for encryption using blockchain distributed ledgers
US11928105B2 (en) System for tracking data associated with a digital token
US20160162897A1 (en) System and method for user authentication using crypto-currency transactions as access tokens
CN113056741A (zh) 基于分布式账本的简档验证
US20160239683A1 (en) System and method for securely storing files
JP6049908B2 (ja) ファイル保管システム
JP6819748B2 (ja) 情報処理装置、情報処理システム及びプログラム
CN111915298A (zh) 区块链中生成和验证可链接环签名的方法及装置
CN115730277A (zh) 使用非同质化代币nft的补充数字内容访问控制
WO2013149296A1 (en) Digital rights management for three dimensional object production
JP2022548583A (ja) ブロックチェーンのトランザクションを介するデータの共有
US20230418984A1 (en) Artwork managing method, computer, and program
CN117082026A (zh) 一种数字资产的管理方法及相关装置
US20150286843A1 (en) Method and system for modular digital watermarking of electronic files
JP7171504B2 (ja) 個人情報管理サーバ、個人情報管理方法及び個人情報管理システム
CN112954403B (zh) 视频加密方法、装置、设备及存储介质
WO2023080075A1 (ja) Ｎｆｔ発行方法、コンピュータ、及びプログラム
WO2024009544A1 (ja) 書類の署名者の証明に関する方法、コンピュータ、及びプログラム

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2022546706

Country of ref document: JP

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22787987

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202280022914.0

Country of ref document: CN

Ref document number: 2022787987

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2022787987

Country of ref document: EP

Effective date: 20230920

NENP Non-entry into the national phase

Ref country code: DE