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

Abstract

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

Description

本発明は、アートワーク管理方法、コンピュータ、及びプログラムに関する。

近年、自己主権型アイデンティティ（Self-Sovereign Identity。以下「ＳＳＩ」という）が注目されている。ＳＳＩは、管理主体が介在することなく自分自身が自らのアイデンティティ（Identity。以下「ＩＤ」という）を保有、コントロールできるようにすることにより、中央集権的なＩＤ管理による諸問題を解決する仕組みである。ＳＳＩにおいては、ブロックチェーンによって管理される分散型のＩＤである分散型アイデンティティ（Decentralized Identity。以下「ＤＩＤ」という）によって情報が識別される。ＤＩＤにより識別される情報はＤＩＤドキュメントと呼ばれ、惑星間ファイルシステム（InterPlanetary File System。以下「ＩＰＦＳ」という）などの分散ファイルシステムに格納される。非特許文献１には、ＤＩＤ及びＤＩＤドキュメントの規格が記載されている。

また、ＳＳＩでは、検証可能証明書（Verifiable Credentials。以下「ＶＣ」という）と呼ばれる証明書が利用される。ＶＣは、証明対象である情報のハッシュ値を発行者の秘密鍵によって暗号化してなる電子署名を含む情報である。証明対象である情報とともにＶＣを受け取った者は、受け取った情報のハッシュ値を導出するとともに、発行者の公開鍵によって電子署名を復号し、導出したハッシュ値と復号した電子署名を比較することによって、受け取った情報の真正性を確認する。非特許文献２には、ＶＣの規格が記載されている。

ワールド・ワイド・ウェブ・コンソーシアム，"Decentralized Identifiers (DIDs) v1.0"，［online］，［令和３年３月２６日検索］，インターネット，＜URL："https://www.w3.org/TR/did-core/"＞ ワールド・ワイド・ウェブ・コンソーシアム，"Verifiable Credentials Data Model 1.0"，［online］，［令和３年３月２６日検索］，インターネット，＜URL："https://www.w3.org/TR/vc-data-model/"＞

しかしながら、従来、スタイラスなどによって描かれたデジタル画像（以下「アートワーク」という）の取り扱いにおいて、アートワークをＳＳＩによって適切に管理することは困難であった。

したがって、本発明の目的の一つは、アートワークをＳＳＩによって適切に管理できるアートワーク管理方法、コンピュータ、及びプログラムを提供することにある。

本発明によるアートワーク管理方法は、コンピュータによって実行されるアートワークの管理方法であって、前記コンピュータは、第１のアートワークの利用のリクエストを受信し、前記コンピュータは、前記第１のアートワークを識別するＤＩＤである第１のＤＩＤ、及び、前記第１のアートワークの利用をリクエストする第１のユーザを識別するＤＩＤである第２のＤＩＤを含むＤＩＤドキュメントである第１のＤＩＤドキュメントを生成する、アートワークの管理方法である。

本発明によるコンピュータは、第１のアートワークの利用のリクエストを受信し、前記第１のアートワークを識別するＤＩＤである第１のＤＩＤ、及び、前記第１のアートワークの利用をリクエストする第１のユーザを識別するＤＩＤである第２のＤＩＤを含むＤＩＤドキュメントである第１のＤＩＤドキュメントを生成する、コンピュータである。

本発明によるプログラムは、コンピュータに、第１のアートワークの利用のリクエストを受信し、前記第１のアートワークを識別するＤＩＤである第１のＤＩＤ、及び、前記第１のアートワークの利用をリクエストする第１のユーザを識別するＤＩＤである第２のＤＩＤを含むＤＩＤドキュメントである第１のＤＩＤドキュメントを生成する、処理を実行させるためのプログラムである。

本発明によれば、アートワークをＳＳＩによって適切に管理することが可能になる。

本実施の形態によるアートワーク管理システム１の構成を示す図である。 アーティスト端末３及びウェブサーバ４のハードウェア構成の一例を示す図である。 バイオメトリック署名データの構成を示す図である。 アートワーク１の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク１の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク１の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク１の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク１の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 新規ユーザの登録にかかる処理を示すシーケンス図である。 アートワーク１の登録にかかる処理を示すシーケンス図である。 アートワーク１の登録にかかる処理を示すシーケンス図である。 （ａ）は、アートワーク１のＤＩＤドキュメントの構成例を示す図であり、（ｂ）は、アートワーク１のためのＶＣの内容を示す図である。 ＳＮＳ又は販売サイトを経由してアートワーク１のアートワークデータ及びＶＣを受け取ったコンピュータによって実行される処理のフローを示すフロー図である。 アートワーク１の利用申請を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク１の利用申請を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク１の利用申請を受信したアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク１の利用申請を受信したアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク１の利用申請を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 ウェブサーバ４が行った処理の結果として申請者であるアーティスト２のウェブアプリ３ａにより表示されるリクエスト一覧画面の一例を示す図である。 アートワーク１の利用申請にかかる処理を示すシーケンス図である。 アートワーク１の利用申請にかかる処理を示すシーケンス図である。 （ａ）は、プロジェクトのＤＩＤドキュメントの構成例を示す図であり、（ｂ）は、プロジェクトのためのＶＣの内容を示す図である。 ＳＮＳ又は販売サイトを経由してプロジェクトのＤＩＤドキュメント及びＶＣを受け取ったコンピュータによって実行される処理のフローを示すフロー図である。 アートワーク２の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク２の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク２の登録を行おうとするアーティスト端末３のディスプレイに表示されるウェブアプリ３ａの画面の例を示す図である。 アートワーク一覧表示画面においてユーザがアートワーク２を選択することによって表示されるアートワーク詳細画面である。 アートワーク２の登録にかかる処理を示すシーケンス図である。 アートワーク２の登録にかかる処理を示すシーケンス図である。 アートワーク２の登録にかかる処理を示すシーケンス図である。 （ａ）は、アートワーク２のＤＩＤドキュメントの構成例を示す図であり、（ｂ）は、アートワーク２のためのＶＣの内容を示す図であり、（ｃ）は、更新されたプロジェクトのＤＩＤドキュメントを示す図である。

以下、添付図面を参照しながら、本発明の実施の形態について詳細に説明する。

図１は、本実施の形態によるアートワーク管理システム１の構成を示す図である。同図に示すように、アートワーク管理システム１は、複数のアーティスト端末３と、ウェブサーバ４と、分散ファイルシステム５と、ブロックチェーンネットワーク６とがネットワーク２を介して相互に接続された構成を有している。

図２は、アーティスト端末３及びウェブサーバ４のハードウェア構成の一例を示す図である。アーティスト端末３及びウェブサーバ４はそれぞれ、図示した構成を有するコンピュータ１００によって構成され得る。なお、ウェブサーバ４は、複数のコンピュータ１００の結合によって構成されていてもよい。

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

Images