IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社ワコムの特許一覧

特開2023-143661アートワークの管理方法、コンピュータ、及びプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023143661
(43)【公開日】2023-10-06
(54)【発明の名称】アートワークの管理方法、コンピュータ、及びプログラム
(51)【国際特許分類】
   G06F 21/64 20130101AFI20230928BHJP
   H04L 9/32 20060101ALI20230928BHJP
   G06F 21/10 20130101ALI20230928BHJP
【FI】
G06F21/64
H04L9/32 200B
G06F21/10
【審査請求】未請求
【請求項の数】23
【出願形態】OL
(21)【出願番号】P 2022183495
(22)【出願日】2022-11-16
(62)【分割の表示】P 2022546706の分割
【原出願日】2022-03-25
(71)【出願人】
【識別番号】000139403
【氏名又は名称】株式会社ワコム
(74)【代理人】
【識別番号】100130982
【弁理士】
【氏名又は名称】黒瀬 泰之
(72)【発明者】
【氏名】アフィナフ カナル
(72)【発明者】
【氏名】ユテ カンプマン
(72)【発明者】
【氏名】ジョス ダニエル ギファード-バーレイ
(72)【発明者】
【氏名】ミハル イェリネック
(57)【要約】
【課題】オリジナルワークであるアートワーク1からアートワーク2への進化に関する情報をSSIによって適切に管理できるようにする。
【解決手段】1以上のコンピュータによって実行されるアートワークの管理方法であって、第1のコンピュータが、第1のアーティストによって制作された第1のアートワークに依拠して第2のアーティストによって制作された第2のアートワークの登録のリクエストを受信し、前記第1のコンピュータが、前記第1のアーティストを識別するDID(Decentralized Identity)である第1のDIDおよび前記第2のアーティストを識別するDIDである第2のDIDを含むDIDドキュメントであり前記第2のアートワークを説明する第1のDIDドキュメントを生成する、アートワークの管理方法である。
【選択図】図28
【特許請求の範囲】
【請求項1】
1以上のコンピュータによって実行されるアートワークの管理方法であって、
第1のコンピュータが、第1のアーティストによって制作された第1のアートワークに依拠して第2のアーティストによって制作された第2のアートワークの登録のリクエストを受信し、
前記第1のコンピュータが、前記第1のアーティストを識別するDID(Decentralized Identity)である第1のDIDおよび前記第2のアーティストを識別するDIDである第2のDIDを含むDIDドキュメントであり前記第2のアートワークを説明する第1のDIDドキュメントを生成する、
アートワークの管理方法。
【請求項2】
前記第1のコンピュータは、前記第2のアートワークのオーナーを示す識別子として前記第1のDIDおよび前記第2のDIDが設定される前記第1のDIDドキュメントを生成する、
請求項1に記載のアートワークの管理方法。
【請求項3】
前記第1のコンピュータは、前記第2のアートワークの寄与者を示す識別子として、前記第1のDIDおよび前記第2のDIDが設定される前記第1のDIDドキュメントを生成する、
請求項1に記載のアートワークの管理方法。
【請求項4】
前記第1のコンピュータは、前記第2のアートワークの知的財産に関する取扱いについて設定された前記第1のDIDドキュメントを生成する、
請求項1に記載のアートワークの管理方法。
【請求項5】
前記第1のコンピュータは、前記第2のアートワークに依拠したアートワークの創作の可否について設定された前記第1のDIDドキュメントを生成する、
請求項1に記載のアートワークの管理方法。
【請求項6】
前記第1のコンピュータが、前記第2のアートワークに基づいて生成される電子署名を含む証明書を生成する、
請求項1に記載のアートワークの管理方法。
【請求項7】
前記第1のコンピュータが、前記第1のDIDドキュメントを含むデータを用いて算出される第1のハッシュ値を用いて前記電子署名を生成する、
請求項6に記載のアートワークの管理方法。
【請求項8】
前記第1のコンピュータは、前記第2のアートワークを識別するDIDである第3のDIDのブロックチェーンネットワークへの記録に応じて前記ブロックチェーンネットワークが発行するトランザクションIDをさらに含む前記証明書を生成する、
請求項7に記載のアートワークの管理方法。
【請求項9】
前記第1のコンピュータとは異なる第2のコンピュータが、前記証明書に含まれる前記トランザクションIDに基づいて前記ブロックチェーンネットワークから取得される前記第3のDIDによって特定される前記第1のDIDドキュメントを含むデータを用いて第2のハッシュ値を算出し、前記証明書に含まれる前記電子署名を用いて生成される前記第1のハッシュ値および前記第2のハッシュ値を用いて前記第2のアートワークの真正性を判断する、
請求項8に記載のアートワークの管理方法。
【請求項10】
前記第1のコンピュータが、前記第1のアートワークに依拠して前記第2のアートワークを創作するプロジェクトを識別するDIDドキュメントであり、前記第1のアートワークを識別するDIDである第4のDIDおよび前記第2のアートワークを識別するDIDである第3のDIDを含む第2のDIDドキュメントを生成する、
請求項1に記載のアートワークの管理方法。
【請求項11】
前記第1のコンピュータが、前記第2のアートワークの登録のリクエストを受信した後、ウォーターマークが埋め込まれた第2のアートワークを生成する、
請求項1に記載のアートワークの管理方法。
【請求項12】
第1のアーティストによって制作された第1のアートワークに依拠して第2のアーティストによって制作された第2のアートワークの登録のリクエストを受信し、
前記リクエストの受信に応じて、前記第1のアーティストを識別するDID(Decentralized Identity)である第1のDIDおよび前記第2のアーティストを識別するDIDである第2のDIDを含むDIDドキュメントであり前記第2のアートワークを説明する第1のDIDドキュメントを生成する、
コンピュータ。
【請求項13】
前記第1のDIDドキュメントは、前記第2のアートワークのオーナーを示す識別子として、前記第1のDIDおよび前記第2のDIDを含む、
請求項12に記載のコンピュータ。
【請求項14】
前記第1のDIDドキュメントは、前記第2のアートワークの寄与者を示す識別子として、前記第1のDIDおよび前記第2のDIDを含む、
請求項12に記載のコンピュータ。
【請求項15】
前記第2のアートワークに基づいて生成される電子署名を含む証明書を生成する、
請求項12に記載のコンピュータ。
【請求項16】
前記第1のDIDドキュメントを含むデータを用いて算出される第1のハッシュ値を用いて前記電子署名を生成する、
請求項15に記載のコンピュータ。
【請求項17】
前記証明書は、前記第2のアートワークを識別するDIDである第3のDIDのブロックチェーンネットワークへの記録に応じて前記ブロックチェーンネットワークが発行するトランザクションIDをさらに含む、
請求項16に記載のコンピュータ。
【請求項18】
第1のアーティストによって制作された第1のアートワークに依拠して第2のアーティストによって制作された第2のアートワークの登録のリクエストを受信ステップ、及び、
前記リクエストの受信に応じて、前記第1のアーティストを識別するDID(Decentralized Identity)である第1のDIDおよび前記第2のアーティストを識別するDIDである第2のDIDを含むDIDドキュメントであり前記第2のアートワークを説明する第1のDIDドキュメントを生成するステップ、
をコンピュータに実行させるためのプログラム。
【請求項19】
前記第1のDIDドキュメントは、前記第2のアートワークのオーナーを示す識別子として、前記第1のDIDおよび前記第2のDIDを含む、
請求項18に記載のプログラム。
【請求項20】
前記第1のDIDドキュメントは、前記第2のアートワークの寄与者を示す識別子として、前記第1のDIDおよび前記第2のDIDを含む、
請求項18に記載のプログラム。
【請求項21】
前記第2のアートワークに基づいて生成される電子署名を含む証明書を生成するステップ、
を前記コンピュータにさらに実行させるための請求項18に記載のプログラム。
【請求項22】
前記第1のDIDドキュメントを含むデータを用いて算出される第1のハッシュ値を用いて前記電子署名を生成するステップ、
を前記コンピュータにさらに実行させるための請求項21に記載のプログラム。
【請求項23】
前記証明書は、前記第2のアートワークを識別するDIDである第3のDIDのブロックチェーンネットワークへの記録に応じて前記ブロックチェーンネットワークが発行するトランザクションIDをさらに含む、
請求項22に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、アートワーク管理方法、コンピュータ、及びプログラムに関する。
【背景技術】
【0002】
近年、自己主権型アイデンティティ(Self-Sovereign Identity。以下「SSI」という)が注目されている。SSIは、管理主体が介在することなく自分自身が自らのアイデンティティ(Identity。以下「ID」という)を保有、コントロールできるようにすることにより、中央集権的なID管理による諸問題を解決する仕組みである。SSIにおいては、ブロックチェーンによって管理される分散型のIDである分散型アイデンティティ(Decentralized Identity。以下「DID」という)によって情報が識別される。DIDにより識別される情報はDIDドキュメントと呼ばれ、惑星間ファイルシステム(InterPlanetary File System。以下「IPFS」という)などの分散ファイルシステムに格納される。非特許文献1には、DID及びDIDドキュメントの規格が記載されている。
【0003】
また、SSIでは、検証可能証明書(Verifiable Credentials。以下「VC」という)と呼ばれる証明書が利用される。VCは、証明対象である情報のハッシュ値を発行者の秘密鍵によって暗号化してなる電子署名を含む情報である。証明対象である情報とともにVCを受け取った者は、受け取った情報のハッシュ値を導出するとともに、発行者の公開鍵によって電子署名を復号し、導出したハッシュ値と復号した電子署名を比較することによって、受け取った情報の真正性を確認する。非特許文献2には、VCの規格が記載されている。
【先行技術文献】
【特許文献】
【0004】
【非特許文献1】ワールド・ワイド・ウェブ・コンソーシアム,"Decentralized Identifiers (DIDs) v1.0",[online],[令和3年3月26日検索],インターネット,<URL:"https://www.w3.org/TR/did-core/">
【非特許文献2】ワールド・ワイド・ウェブ・コンソーシアム,"Verifiable Credentials Data Model 1.0",[online],[令和3年3月26日検索],インターネット,<URL:"https://www.w3.org/TR/vc-data-model/">
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、従来、スタイラスなどによって描かれたデジタル画像(以下「アートワーク」という)の取り扱いにおいて、アートワークをSSIによって適切に管理することは困難であった。
【0006】
したがって、本発明の目的の一つは、アートワークをSSIによって適切に管理できるアートワーク管理方法、コンピュータ、及びプログラムを提供することにある。
【課題を解決するための手段】
【0007】
本発明によるアートワーク管理方法は、コンピュータによって実行されるアートワークの管理方法であって、前記コンピュータは、第1のアートワークの利用のリクエストを受信し、前記コンピュータは、前記第1のアートワークを識別するDIDである第1のDID、及び、前記第1のアートワークの利用をリクエストする第1のユーザを識別するDIDである第2のDIDを含むDIDドキュメントである第1のDIDドキュメントを生成する、アートワークの管理方法である。
【0008】
本発明によるコンピュータは、第1のアートワークの利用のリクエストを受信し、前記第1のアートワークを識別するDIDである第1のDID、及び、前記第1のアートワークの利用をリクエストする第1のユーザを識別するDIDである第2のDIDを含むDIDドキュメントである第1のDIDドキュメントを生成する、コンピュータである。
【0009】
本発明によるプログラムは、コンピュータに、第1のアートワークの利用のリクエストを受信し、前記第1のアートワークを識別するDIDである第1のDID、及び、前記第1のアートワークの利用をリクエストする第1のユーザを識別するDIDである第2のDIDを含むDIDドキュメントである第1のDIDドキュメントを生成する、処理を実行させるためのプログラムである。
【発明の効果】
【0010】
本発明によれば、アートワークをSSIによって適切に管理することが可能になる。
【図面の簡単な説明】
【0011】
図1】本実施の形態によるアートワーク管理システム1の構成を示す図である。
図2】アーティスト端末3及びウェブサーバ4のハードウェア構成の一例を示す図である。
図3】バイオメトリック署名データの構成を示す図である。
図4】アートワーク1の登録を行おうとするアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例を示す図である。
図5】アートワーク1の登録を行おうとするアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例を示す図である。
図6】アートワーク1の登録を行おうとするアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例を示す図である。
図7】アートワーク1の登録を行おうとするアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例を示す図である。
図8】アートワーク1の登録を行おうとするアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例を示す図である。
図9】新規ユーザの登録にかかる処理を示すシーケンス図である。
図10】アートワーク1の登録にかかる処理を示すシーケンス図である。
図11】アートワーク1の登録にかかる処理を示すシーケンス図である。
図12】(a)は、アートワーク1のDIDドキュメントの構成例を示す図であり、(b)は、アートワーク1のためのVCの内容を示す図である。
図13】SNS又は販売サイトを経由してアートワーク1のアートワークデータ及びVCを受け取ったコンピュータによって実行される処理のフローを示すフロー図である。
図14】アートワーク1の利用申請を行おうとするアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例を示す図である。
図15】アートワーク1の利用申請を行おうとするアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例を示す図である。
図16】アートワーク1の利用申請を受信したアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例を示す図である。
図17】アートワーク1の利用申請を受信したアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例を示す図である。
図18】アートワーク1の利用申請を行おうとするアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例を示す図である。
図19】ウェブサーバ4が行った処理の結果として申請者であるアーティスト2のウェブアプリ3aにより表示されるリクエスト一覧画面の一例を示す図である。
図20】アートワーク1の利用申請にかかる処理を示すシーケンス図である。
図21】アートワーク1の利用申請にかかる処理を示すシーケンス図である。
図22】(a)は、プロジェクトのDIDドキュメントの構成例を示す図であり、(b)は、プロジェクトのためのVCの内容を示す図である。
図23】SNS又は販売サイトを経由してプロジェクトのDIDドキュメント及びVCを受け取ったコンピュータによって実行される処理のフローを示すフロー図である。
図24】アートワーク2の登録を行おうとするアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例を示す図である。
図25】アートワーク2の登録を行おうとするアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例を示す図である。
図26】アートワーク2の登録を行おうとするアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例を示す図である。
図27】アートワーク一覧表示画面においてユーザがアートワーク2を選択することによって表示されるアートワーク詳細画面である。
図28】アートワーク2の登録にかかる処理を示すシーケンス図である。
図29】アートワーク2の登録にかかる処理を示すシーケンス図である。
図30】アートワーク2の登録にかかる処理を示すシーケンス図である。
図31】(a)は、アートワーク2のDIDドキュメントの構成例を示す図であり、(b)は、アートワーク2のためのVCの内容を示す図であり、(c)は、更新されたプロジェクトのDIDドキュメントを示す図である。
【発明を実施するための形態】
【0012】
以下、添付図面を参照しながら、本発明の実施の形態について詳細に説明する。
【0013】
図1は、本実施の形態によるアートワーク管理システム1の構成を示す図である。同図に示すように、アートワーク管理システム1は、複数のアーティスト端末3と、ウェブサーバ4と、分散ファイルシステム5と、ブロックチェーンネットワーク6とがネットワーク2を介して相互に接続された構成を有している。
【0014】
図2は、アーティスト端末3及びウェブサーバ4のハードウェア構成の一例を示す図である。アーティスト端末3及びウェブサーバ4はそれぞれ、図示した構成を有するコンピュータ100によって構成され得る。なお、ウェブサーバ4は、複数のコンピュータ100の結合によって構成されていてもよい。
【0015】
図2に示すように、コンピュータ100は、CPU(Central Processing Unit)101、記憶装置102、入力装置103、出力装置104、及び通信装置105を有して構成される。
【0016】
CPU101は、コンピュータ100の各部を制御するとともに、記憶装置102に記憶される各種のプログラムを読み出して実行する装置である。後掲する図3図31を参照して説明する各処理は、アーティスト端末3又はウェブサーバ4のCPU101が記憶装置102に記憶されるプログラムを実行することによって実現される。アーティスト端末3のCPU101によって実行されるプログラムには、図1に示したウェブアプリ3aが含まれる。
【0017】
記憶装置102は、DRAM(Dynamic Random Access Memory)などの主記憶装置と、ハードディスクなどの補助記憶装置とを含み、コンピュータ100のオペレーティングシステムや各種のアプリケーションを実行するための各種のプログラム、及び、これらのプログラムによって利用されるデータを記憶する役割を果たす。
【0018】
入力装置103は、ユーザの入力操作を受け付けてCPU101に供給する装置であり、例えばキーボード、マウス、タッチ検出装置を含んで構成される。このうちタッチ検出装置はタッチセンサ及びタッチコントローラを含む装置であり、ペン入力又はタッチ入力を検出するために使用される。図1に示したペンPは、アーティスト端末3のタッチ検出装置に対してペン入力を行うために用いられる電子ペンである。ペンPによるペン入力は、例えばアクティブ静電方式又は電磁誘導方式により実現される。
【0019】
出力装置104は、CPU101の処理結果をユーザに対して出力する装置であり、例えばディスプレイ、スピーカーを含んで構成される。通信装置105は、外部の装置と通信するための装置であり、CPU101の指示にしたがってデータの送受信を行う。各アーティスト端末3及びウェブサーバ4はそれぞれ、この通信装置105を用いて、図示した分散ファイルシステム5及びブロックチェーンネットワーク6を含む他の装置、システム、ネットワークなどとの間で通信を行う。
【0020】
図1に戻る。複数のアーティスト端末3はそれぞれ、アートワークの制作、制作したアートワークのウェブサーバ4への登録、他のアーティストが制作したアートワークの利用申請、及び、後述するバイオメトリック署名データの入力などを行うために使用されるコンピュータである。アーティスト端末3の具体的なハードウェアとしては、パーソナルコンピュータ、タブレット端末、スマートフォンなど任意のコンピュータを用いる得る。アートワーク及びバイオメトリック署名データはそれぞれデジタルデータであり、アーティスト端末3の入力装置103に対し、アーティストがペンPを用いてペン入力を行うことによって生成されたデジタルインクデータ(後述)を含んで構成される。
【0021】
図3は、バイオメトリック署名データの構成を示す図である。バイオメトリック署名データは、例えばWILL(Wacom Ink Layer Language)又はFSS(Forensic Signature Stream)に従って生成されるデータであり、同図に示すように、動的署名データ、署名した書類のハッシュ値、コンテキスト情報、及び追加情報と、動的署名データ、署名した書類のハッシュ値、及びコンテキスト情報のハッシュ値、このハッシュ値及び追加情報のハッシュ値、並びに、このハッシュ値の送受信の際に生じ得る誤りを検出するためのチェックサムを含んで構成される。
【0022】
動的署名データは、線画を構成する一連の座標データを含むデジタルインクデータである。各座標データは、上述したタッチ検出装置により検出されるペンPの位置を示すデータである。この検出について詳しく説明すると、タッチセンサは、それぞれY方向に延在し、X方向に等間隔で配置された複数のX電極と、それぞれX方向に延在し、Y方向に等間隔で配置された複数のY電極とを含んで構成される。ペンPが信号を送信可能に構成される場合、タッチコントローラは、これら複数のX電極及び複数のY電極のそれぞれでペンPが送信したバースト信号を受信することにより、ペンPの位置を示す座標データを取得する。一方、ペンPが信号を送信できない場合、タッチコントローラは、複数のX電極のそれぞれに順次信号を送信し、複数のY電極のそれぞれでこの信号を受信し、受信される信号の振幅変化を検出することにより、ペンPの位置を示す座標データを取得する。タッチコントローラは、例えば1秒当たり100回又は200回の頻度で、座標データを収集するように構成される。
【0023】
署名した書類のハッシュ値は、バイオメトリック署名データを生成するためにアーティストが署名した書類(出品申込書、契約書など)の電子データのハッシュ値である。なお、ハッシュ値は、対象の電子データを所定の一方向ハッシュ関数に入力することによって得られる値である。この点は、後述する他のハッシュ値についても同様である。
【0024】
コンテキスト情報は、署名したアーティストの氏名データ、署名日時、署名の目的、署名のために使用したタッチ検出装置の情報(メーカー名、モデル名など)、署名のために使用したアプリケーションの情報(アプリケーション名、バージョン情報など)、アーティスト端末3のオペレーティングシステムの情報(オペレーティングシステム名、バージョン情報など)、アーティスト端末3のアドレス情報(IPアドレス、MACアドレスなど)などを含む情報である。追加情報は、動的署名データ、署名した書類のハッシュ値、コンテキスト情報の他に、アートワーク管理システム1の管理者が任意で指定できる情報である。
【0025】
図1に戻る。ウェブサーバ4は、アートワークの管理を実現するための各種の処理を実行するサーバである。各種の処理には、アートワーク及びその関連データを分散ファイルシステム5又はブロックチェーンネットワーク6に登録する処理と、アートワークの利用申請を受け付ける処理とが含まれる。各処理の詳細については、後述する。なお、ウェブサーバ4が複数のコンピュータ100の結合によって構成される場合、後述する各種の処理は複数のコンピュータ100に分散して実行され得る。
【0026】
分散ファイルシステム5は、ピアツーピアによって接続された複数のコンピュータのネットワークであり、任意の電子データを格納するように構成される。具体的な分散ファイルシステム5は、上述した惑星間ファイルシステムであってもよいし、他の種類の分散ファイルシステムであってもよい。一例では、分散ファイルシステム5内に格納された電子データはそのハッシュ値によって識別される。すなわち、分散ファイルシステム5においては、格納された電子データのハッシュ値がその電子データのアドレス情報として機能する。本実施の形態では、暗号化されたアートワーク及び各種のDIDドキュメントを格納するために分散ファイルシステム5が使用される。後述でも説明するが、SSIによってアートワークを管理する場合、分散ファイルシステム5に格納した個々のアートワークに対してDIDを付与し、そのDIDドキュメントの中に、アートワークの所有者を示すオーナー情報、アートワークの実体の置き場所を示すアドレス情報、ライセンス情報(二次創作の可否、商業利用の可否など)を配置する。
【0027】
ブロックチェーンネットワーク6は、ピアツーピアによって接続された複数のコンピュータのネットワークであり、スマート・コントラクトのトランザクションをブロックチェーンに記録するように構成される。具体的な例を挙げると、ブロックチェーンネットワーク6はイーサリアムネットワークである。トランザクションのブロックチェーンへの記録は、ブロックチェーンネットワーク6に接続されたいくつかのコンピュータ(以下、「マイナー」と称する)によって実行される。
【0028】
具体的に説明すると、ブロックチェーンを構成する各ブロックは、ブロックヘッダと、トランザクションの具体的な内容を示すデータ(取引データ)とを含んで構成される。このうちブロックヘッダには、取引データのサイズを圧縮してなるデータであるマークルルートと、1つ前のブロックのハッシュ値と、任意の文字列であるナンス値とが含まれる。ブロックチェーンネットワーク6においては、新たなブロックをブロックチェーンに接続するには、そのブロックのハッシュ値が所定の条件(例えば、「000」で始まる値である、という条件)を満たしていなければならないというルールが定められている。そこで、ブロックチェーンにあるブロックを記録しようとするマイナーは、そのブロックのブロックヘッダのハッシュ値が上記所定の条件を満たすこととなるよう、総当たり的にナンス値を見つける作業(マイニング)を行う。この作業の結果として、最も早くナンス値の発見に成功したマイナーがそのブロックをブロックチェーンに連結することによって、トランザクションのブロックチェーンへの記録が完了する。
【0029】
以下、ウェブサーバ4が実行する各種の処理について、具体的に説明する。以下では、まず図4図13を参照しながら、他のアートワークに依拠せずに制作されたアートワーク(以下「アートワーク1」と称し、アートワーク1を制作したアーティストを「アーティスト1」又は「特許太郎」と称する)の登録にかかる処理を説明し、次いで図14図23を参照しながらアートワーク1の利用申請にかかる処理を説明し、最後に図24図31を参照しながら、アートワーク1に依拠して制作されたアートワーク(以下「アートワーク2」と称し、アートワーク2を制作したアーティストを「アーティスト2」又は「発明花子」と称する)の登録にかかる処理を説明する。
【0030】
初めに、アートワーク1の登録にかかる処理を説明する。図4図8は、アートワーク1の登録を行おうとするアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例である。このアーティスト端末3のユーザであるアーティスト1がウェブアプリ3aを立ち上げると、ウェブアプリ3aにより、図4に示すログイン画面が表示される。同図に示すように、ログイン画面には、メールアドレス入力欄10、パスワード入力欄11、及び、ログインボタン12が含まれる。ここで、アーティスト1がウェブアプリ3aに予め登録してあるメールアドレス及びパスワードをそれぞれメールアドレス入力欄10及びパスワード入力欄11に入力してログインボタン12を押下すると、ウェブアプリ3aにより図5の画面が表示される。
【0031】
図5に示すように、ログイン後に表示されるウェブアプリ3aの画面は、左側にサイドメニューが配置された構成を有している。サイドメニュー内には、ログインしているユーザの写真13及び氏名14、登録済コンテンツ画面へのリンク15、リクエスト一覧画面へのリンク16、トランザクション画面へのリンク17、プロフィール画面へのリンク18、及び、マイプロジェクト画面へのリンク19が配置される。これらの画面のうち登録済コンテンツ画面は、ログインしているユーザがアップロードしたアートワークを管理する画面であり、リクエスト一覧画面は、アートワークの利用申請(ログインしているユーザが行った利用申請と、ログインしているユーザに対して行われた利用申請とを含む)を管理する画面であり、トランザクション画面は、ブロックチェーンネットワーク6への記録の結果として得られたトランザクションIDを管理する画面であり、プロフィール画面は、ログインしているユーザの情報(氏名、写真、メールアドレス、パスワードなど。以下「ユーザ情報」と称する)を管理する画面であり、マイプロジェクト画面は、ログインしているユーザによって生成されたプロジェクト(後述)を管理する画面である。
【0032】
図5には、登録済みコンテンツが1つも存在しない場合の登録済コンテンツ画面を示している。同図に示すように、この場合の登録済コンテンツ画面には、登録ボタン20が表示される。アートワーク1の制作を完了し、ウェブサーバ4に登録しようとするアーティスト1は、この登録ボタン20を押下する。
【0033】
図6は、図5の登録ボタン20の押下を検出したウェブアプリ3aによって表示されるコンテンツ登録画面である。同図に示すように、コンテンツ登録画面には、コンテンツ名入力欄21と、ファイルの選択インターフェイス22と、アートワークのメタデータの入力インターフェイス23と、登録ボタン24とが含まれる。
【0034】
コンテンツ名入力欄21は、アーティスト1が任意に名付けたアートワーク1の名称を入力するテキストボックスである。図6では、アートワーク1の名称として「ライダー」が入力されている。選択インターフェイス22は、アーティスト1がこれから登録しようとするアートワークのファイルを選択するためのインターフェイスである。ここで選択するファイルは、例えばjpgファイル、pngファイルなどの画像ファイルであり、アートワーク1は、ここで選択された1以上のファイルによって構成される。後述する図24に例示するように、選択インターフェイス22は複数のファイルを含むフォルダも選択可能に構成される。図6には、2つの画像A1,A2が選択された状態を示している。画像A2は例えば人物を含む絵であり、画像A1は例えば画像A2の一部拡大画像である。
【0035】
メタデータ入力インターフェイス23は、アートワーク1を説明するための情報であるメタデータを入力するためのインターフェイスである。ここで入力されるメタデータの具体的な内容としては、図6に例示するように、アートワーク1がアーティスト1の知的財産(Intellectual Property。以下「IP」という)であるか否か(すなわち、アーティスト1がアートワーク1のオーナーであるか否か)を示す情報や、アートワーク1のライセンスに関する各種の情報が含まれ得る。図6の例では、このライセンスに関する各種の情報に、共同編集者ライセンスを設定するか否かを示す情報、商業ライセンスを設定するか否かを示す情報、及び、ユーザが独自に考えて入力する1以上の情報(独自のIP設定)が含まれる。
【0036】
ユーザが登録ボタン24を押下すると、ウェブアプリ3aは、図7に示す署名ウィンドウ25を表示する。署名ウィンドウ25は、アーティスト1がペンPを用いて手書きの署名を入力するためのインターフェイスと、確認ボタン26とを有して構成される。署名を入力したアーティスト1が確認ボタン26を押下すると、ウェブアプリ3aは、入力された署名に基づいて図3に示したバイオメトリック署名データを生成したうえで、後述する図10に示す登録要求をウェブサーバ4に送信する。詳しくは後述するが、ウェブサーバ4はこの登録要求に応じて、アートワーク1を分散ファイルシステム5に登録する処理、アートワーク1のDID及びDIDドキュメントを生成し、DIDドキュメントを分散ファイルシステム5に登録する一方、DIDをブロックチェーンネットワーク6に記録する処理、アートワーク1の真正性を証明するためのVCを生成する処理、アートワーク1を構成する各ファイルにウォーターマークを埋め込む処理を行う。
【0037】
図8は、ウェブサーバ4による一連の処理が完了した後、ウェブアプリ3aによって表示される登録完了画面である。同図に示すように、登録完了画面には、所定の情報を表示するための表示欄27~31と、所定の操作を実行するための操作ボタン32~36とが含まれる。
【0038】
表示欄27には、ウェブサーバ4によってブロックチェーンネットワーク6に記録されたアートワーク1のDIDが表示される。表示欄28には、アートワーク1を構成するファイルのサムネイルが一覧で表示される。このサムネイルをクリックすれば、アーティスト1は、対応するファイルをダウンロードすることができる。なお、ここでダウンロードされるファイルは後述するウォーターマーク付きのファイルであることが好ましいが、ウォーターマークが付加されていないファイルがダウンロードされることとしてもよい。表示欄29には、ウェブサーバ4がアートワーク1を分散ファイルシステム5に登録する際に付与されるコンテンツIDが表示される。コンテンツIDは、具体的には、アートワーク1を構成する各ファイル及びメタデータからなるアートワークデータのハッシュ値である。表示欄30には、分散ファイルシステム5におけるアートワーク1のアドレスが表示される。典型的な例では、このアドレスは、分散ファイルシステム5のURL(Uniform Resource Locator)にコンテンツIDを付したものとなる。表示欄31には、アートワーク1のメダテータの全部又は一部が表示される。
【0039】
操作ボタン32は、アートワーク1を更新するための押しボタンである。操作ボタン32が押下されたことを検出したウェブアプリ3aは、アートワーク1を構成するファイルの追加、変更、削除を実行するための画面を表示する。操作ボタン33は、アートワーク1の所有権を変更するための押しボタンである。操作ボタン33が押下されたことを検出したウェブアプリ3aは、アートワーク1の新たな所有者を指定するための画面を表示する。操作ボタン34は、アートワーク1のメタデータを変更するための押しボタンである。操作ボタン34が押下されたことを検出したウェブアプリ3aは、アートワーク1のメタデータを変更するための画面を表示する。操作ボタン32~34の押下に応じて表示される画面において、対応する情報が実際に変更等された場合、ウェブアプリ3aは、ウェブサーバ4に対して改めて登録要求を送信する。これにより、分散ファイルシステム5に登録されているアートワーク1が変更され、ブロックチェーンネットワーク6に新たなDIDが記録され、新たなVCが発行され、アートワーク1を構成する各ファイルに新たなウォーターマークが埋め込まれることになる。
【0040】
操作ボタン35は、アートワーク1をSNS(Social Networking Service)にアップロードするための押しボタンである。また、操作ボタン36は、アートワーク1を販売サイトにアップロードするための押しボタンである。操作ボタン35又は操作ボタン36が押下されたことを検出したウェブアプリ3aは、アートワーク1のアップロード先となるSNS又は販売サイトの選択画面を表示する。この画面においてユーザがあるSNS又は販売サイトを選択すると、ウェブアプリ3aは、そのSNS又は販売サイトに対して、ウェブサーバ4によって発行されたVCとともに、アートワーク1を構成する各ファイル(ウォーターマークが埋め込まれたもの)及びメタデータからなるアートワークデータを送信する。これにより、SNS又は販売サイト上で、アートワーク1の情報をセキュアに公開することが可能になる。
【0041】
次に、ウェブアプリ3a及びウェブサーバ4が行う処理について、詳しく説明する。初めに、図9は、新規ユーザの登録にかかる処理を示すシーケンス図である。同図に示すように、ウェブアプリ3a及びウェブサーバ4はまず、図4に示したログイン画面を用いてログイン処理を実行する(ステップS1)。なお、ウェブアプリ3aにメールアドレス及びパスワードが未登録である場合には、このステップS1において、メールアドレス及びパスワードの組み合わせを含む各種のユーザ情報を登録する処理も実行される。
【0042】
ウェブサーバ4は、ログイン処理が終了すると、ユーザのキーペア(公開鍵暗号方式にかかる公開鍵と秘密鍵の組み合わせ。以下、同様。)が生成済みであるか否かを判定し、作成済みでなければ新たにキーペアを生成して記憶する(ステップS2)。ウェブアプリ3aは、生成されたキーペアをウェブサーバ4から受信して記憶する(ステップS3)。
【0043】
また、ウェブサーバ4は、ユーザのDIDと、上述したユーザ情報の全部又は一部を含むDIDドキュメントとを生成して記憶する(ステップS4)。そして、生成したDIDドキュメントを分散ファイルシステム5に登録する(ステップS5)とともに、生成したDIDをブロックチェーンに記録するためのスマート・コントラクトをブロックチェーンネットワーク6に対して発行する(ステップS6)。ブロックチェーンへの記録が完了すると、ブロックチェーンネットワーク6によりトランザクションIDが発行される。ウェブサーバ4は、このトランザクションID(ユーザのトランザクションID)をブロックチェーンネットワーク6から受信し、記憶する(ステップS7)。また、ウェブサーバ4は、生成したユーザのDID及びDIDドキュメントをウェブアプリ3aにも送信する(ステップS8)。ウェブアプリ3aは、受信したDID及びDIDドキュメントを記憶しておき、後述するアートワーク1の登録要求を生成する際にユーザのDIDを使用するとともに、上述したプロフィール画面を生成するためにユーザのDIDドキュメントを使用する。
【0044】
図10及び図11は、アートワーク1の登録にかかる処理を示すシーケンス図である。初めにウェブアプリ3aによって、図6に示したコンテンツ登録画面が表示される(ステップS10)。ユーザが図6に示した登録ボタン24を押下すると、ウェブアプリ3aは、図7に示した署名ウィンドウ25の表示を行い、そして、ウェブサーバ4に対してアートワーク1の登録要求を送信する(ステップS11)。この登録要求には、図9のステップS7でウェブアプリ3aが記憶したアーティスト1のDIDと、アートワーク1を構成する各ファイル(図6に示した選択インターフェイス22において選択されたもの)と、アートワーク1のメタデータ(図6に示したコンテンツ名入力欄21に入力された名称、及び、図6に示したメタデータ入力インターフェイス23において入力された各情報を含む情報)と、図7に示す署名ウィンドウ25においてペン入力された署名に基づいて生成されたバイオメトリック署名データと、アーティスト1の電子署名とが含まれる。なお、図10及び以降の各図では、バイオメトリック署名データとして「FSS」を例示しているが、FSS以外のバイオメトリック署名データを用いてもよいのは勿論である。また、ウェブアプリ3aは、登録要求を構成するデータ(電子署名を除く)のハッシュ値をユーザの秘密鍵によって暗号化することにより、アーティスト1の電子署名を生成するよう構成される。
【0045】
アートワーク1の登録要求を受信したウェブサーバ4はまず、電子署名とバイオメトリック署名データの正当性を確認する(ステップS12,S13)。ここで、電子署名の正当性の確認は、登録要求に含まれる電子署名をユーザの公開鍵によって復号するとともに、登録要求を構成するデータ(電子署名を除く)のハッシュ値を導出し、これらを比較することによって行えばよい。また、バイオメトリック署名データの正当性の確認は、ユーザDIDに対応付けて1以上の動的署名データを蓄積するデータベースから、登録要求に含まれるユーザDIDに対応する1以上の動的署名データを取り出し、バイオメトリック署名データに含まれる動的署名データと比較することによって行えばよい。なお、この比較の結果としてバイオメトリック署名データの正当性が確認された場合、ウェブサーバ4は、登録要求に含まれていた動的署名データを、当該ユーザの新たな動的署名データとして上記データベースに追加することが好ましい。
【0046】
次にウェブサーバ4は、アートワーク1のキーペアを生成して記憶する(ステップS14)。以下では、ここで生成したキーペアに含まれる秘密鍵を「アートワーク秘密鍵」と称し、公開鍵を「アートワーク公開鍵」と称する。そしてウェブサーバ4は、生成したアートワーク秘密鍵によりアートワークデータ(アートワーク1を構成する各ファイル及びメタデータからなるデータ)を暗号化して分散ファイルシステム5に登録し(ステップS15)、その結果として得られる上記コンテンツID及びアドレスをウェブアプリ3aに送信する(ステップS17)。
【0047】
続いてウェブサーバ4は、アートワーク1のDIDと、アートワーク1のメタデータの全部又は一部を含むDIDドキュメントとを生成して記憶する(ステップS18)。そして、生成したDIDドキュメントを分散ファイルシステム5に登録する(ステップS19)とともに、生成したDIDをブロックチェーンに記録するためのスマート・コントラクトをブロックチェーンネットワーク6に対して発行する(ステップS20)。ブロックチェーンへの記録が完了すると、ブロックチェーンネットワーク6によりトランザクションIDが発行される。ウェブサーバ4は、このトランザクションID(アートワーク1のトランザクションID)をブロックチェーンネットワーク6から受信し、記憶する(ステップS21)。また、ウェブサーバ4は、生成したアートワーク1のDID及びDIDドキュメントをウェブアプリ3aにも送信する(ステップS22)。
【0048】
図12(a)は、ステップS18においてウェブサーバ4が生成するアートワーク1のDIDドキュメントの構成例を示す図である。同図に示すように、アートワーク1のDIDドキュメントは、オーナー、寄与者、二次創作、IPシェア、利用態様、署名、格納場所、及び、公開鍵の各情報を含み得る。オーナーは、アートワーク1の所有権を保持しているユーザ(この場合はアーティスト1)であり、寄与者は、アートワーク1の制作に寄与したアーティスト(この場合はアーティスト1)である。オーナー及び寄与者のいずれにも、原則として、登録要求に含まれるユーザのDIDが設定されるが、図6に示したコンテンツ登録画面において、ユーザによって個別に指定可能としても構わない。二次創作、IPシェア、利用態様には、登録要求に含まれるメタデータの中の情報が設定される。なお、他の種類のメタデータをアートワーク1のDIDドキュメント内に設定することとしてもよいのは勿論である。署名には、登録要求に含まれるバイオメトリック署名データのハッシュ値(バイオメトリック署名データに含まれる動的署名データを示す情報)が設定される。格納場所には、ウェブサーバ4がステップS15においてアートワークデータを分散ファイルシステム5に登録した際に得られたアドレスが設定される。公開鍵には、ウェブサーバ4がステップS14において生成したアートワーク公開鍵が設定される。
【0049】
次に図11を参照すると、ウェブサーバ4は、登録要求に含まれていたバイオメトリック署名データ(又はその中に含まれる動的署名データ)に基づいてウォーターマークを生成し、アートワーク1を構成する各ファイルに埋め込む(ステップS23)。具体的には、バイオメトリック署名データ又は動的署名データそのものをウォーターマークとしてもよいし、バイオメトリック署名データ又は動的署名データのハッシュ値をウォーターマークとしてもよい。そしてウェブサーバ4は、ウォーターマークの埋め込まれたウォーターマーク付きの各ファイルをアートワーク1のDIDに対応付けて記憶するとともに(ステップS24)、ウェブアプリ3aに対して送信する(ステップS25)。ステップS24で記憶した各ファイルは、図8に示した登録完了画面、後述する図14に示すアートワーク詳細画面などにおいてファイルを表示する際に使用される。
【0050】
続いてウェブサーバ4は、アートワークデータ内の各ファイルをウォーターマーク付きのファイルに入れ替えたうえで(ステップS26)、アートワークデータ及びアートワーク1のDIDドキュメントからなるデータのハッシュ値をウェブサーバ4の秘密鍵(以下「発行者秘密鍵」と称する)を用いて暗号化することにより、電子署名を生成する(ステップS27)。そして、生成した電子署名と、ブロックチェーンネットワーク6から受信したアートワーク1のトランザクションIDとを含むVCを発行し(ステップS28)、ウェブアプリ3aに送信する(ステップS29)。
【0051】
図12(b)は、アートワーク1のためのVCの内容を示す図である。同図に示すように、VCには、発行日、発行者、発行者の電子署名、及びトランザクションIDが含まれる。発行日には、ウェブサーバ4がVCを発行した日付が設定される。発行者には、VCを発行したウェブサーバ4を特定する情報(名称、アドレスなど)が設定される。発行者の電子署名には、ステップS27で生成された電子署名が設定される。トランザクションIDには、ブロックチェーンネットワーク6から受信したアートワーク1のトランザクションIDが設定される。
【0052】
図11に戻る。ウェブサーバ4からVCを受信したウェブアプリ3aは、図8に示した登録完了画面を生成して表示する(ステップS30)。これにより、一連の登録処理が完了する。
【0053】
図13は、SNS又は販売サイトを経由してアートワーク1のアートワークデータ及びVCを受け取ったコンピュータによって実行される処理のフローを示すフロー図である。なお、このコンピュータは、図1に示したアーティスト端末3であってもよいし、他のコンピュータであってもよい。以下、この図13を参照して、アートワーク1のVCの具体的な用途を説明する。
【0054】
コンピュータは、SNS又は販売サイト上で公開されたアートワークデータ(アートワーク1を構成する1以上のウォーターマーク付きファイル及びメタデータ)とともに、アートワーク1のVCを取得する(ステップS40)。続いてコンピュータは、VC内に含まれるトランザクションIDに基づき、ブロックチェーンネットワーク6からアートワーク1のDIDを取得し(ステップS41)、さらに、取得したアートワーク1のDIDに基づき、分散ファイルシステム5からアートワーク1のDIDドキュメントを取得する(ステップS42)。
【0055】
続いてコンピュータは、ステップS40で取得したアートワークデータ、及び、ステップS42で取得したアートワーク1のDIDドキュメントからなるデータのハッシュ値を導出する(ステップS43)。また、コンピュータは、VC内に含まれる発行者の情報に基づいて、当該VCを発行した発行者の公開鍵(以下「発行者公開鍵」と称する)を取得し(ステップS44)、取得した発行者公開鍵によりVC内の電子署名を復号する(ステップS45)。そして、復号によって得られたハッシュ値と、ステップS43で導出したハッシュ値とを比較する(ステップS46)。その結果、これらのハッシュ値が一致していれば、公開されたアートワークデータの真正性が確認されたことになる。このように、VCによる検証を行うことで、公開されたアートワークデータの真正性を確認することが可能になる。
【0056】
なお、ここではVCの検証を行うコンピュータが分散ファイルシステム5からアートワーク1のDIDドキュメントを取得する例を説明したが、SNS又は販売サイトにおいて、アートワーク1のアートワークデータとともにDIDドキュメントも公開することとしてもよい。この場合、ステップS43のハッシュ値の導出では、公開されたDIDドキュメントを用いればよいので、VC内にアートワーク1のトランザクションIDを配置しなくてもよい。
【0057】
次に、アーティスト2によるアートワーク1の利用申請にかかる処理を説明する。図14図15図18は、アートワーク1の利用申請を行おうとするアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例である。また、図16及び図17は、アートワーク1の利用申請を受信したアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例である。
【0058】
図14に示した画面は、アートワーク一覧表示画面においてアーティスト2がアートワーク1を選択することによって表示されるアートワーク詳細画面である。同図に示すように、このアートワーク詳細画面には、アートワーク1に関する情報の表示欄40~45と、リクエスト内容入力インターフェイス46と、リクエストボタン47とが含まれる。
【0059】
表示欄40にはアートワーク1のオーナーの情報(写真、氏名など)が、表示欄41にはアートワーク1のコンテンツ名が、表示欄42にはアートワーク1のDIDが、表示欄43にはアートワーク1のオーナーである1以上のユーザのDIDが、表示欄44にはアートワーク1の寄与者である1以上のユーザの情報(写真、氏名など)がそれぞれ表示される。これらの情報を表示するため、ウェブサーバ4は、アートワーク1のDIDからアートワーク1のDIDドキュメントを取得し、さらに、その中に記述されているオーナー及び寄与者のDIDからそれぞれのDIDドキュメントを取得することにより、表示欄40~44に表示するデータを取得するよう構成される。また、表示欄45には、図11のステップS24で記憶しておいたウォーターマーク付きファイルのサムネイルが表示される。
【0060】
リクエスト内容入力インターフェイス46は、アートワーク1のオーナーに対するリクエストの内容を入力するためのインターフェイスである。ここで入力されるリクエストの具体的な内容としては、図14に示すように、非商業ライセンスの内容、商業ライセンスの内容、利益の分配率の提案、任意の文章が含まれ得る。
【0061】
図14には、アーティスト2がまだウェブアプリ3aにログインしていない状態を示している。この状態でユーザがリクエストボタン47を押下すると、ウェブアプリ3aは、図4に示したログイン画面を表示し、アーティスト2にログイン処理を行わせる。その結果としてログインが成功すると、ウェブアプリ3aは、図15に示すリクエスト送信画面を表示する。
【0062】
リクエスト送信画面は、アーティスト2がウェブアプリ3aにログインしているときに表示される画面であり、したがって図5と同様に、左側にサイドメニューを有している。サイドメニューに表示される情報の内容は、図5を参照して説明したとおりである。サイドメニューの右側には、図14で説明した表示欄40~45及びリクエスト内容入力インターフェイス46が改めて表示されるとともに、リクエスト送信ボタン48及び連絡ボタン49が新たに表示される。
【0063】
連絡ボタン49は、利用申請とは別にアートワーク1のオーナーに連絡するための押しボタンである。連絡ボタン49が押下されたことを検出したウェブアプリ3aは、電子メールの入力画面を表示し、該画面に表示されている送信ボタンをアーティスト2が押下したことに応じて、アートワーク1のオーナーのメールアドレスに対して電子メールを送信する。なお、ここでは電子メールを用いる例を説明しているが、SNSなどの電子メール以外の通信手段を用いることとしてもよいのは勿論である。その場合、アートワーク1のオーナーのユーザ情報の一部として、アートワーク1のオーナーのSNSに関する情報を予め記憶しておく必要がある。
【0064】
リクエスト送信ボタン48は、アートワーク1の利用申請をアートワーク1のオーナーに対して実際に送信するための押しボタンである。リクエスト送信ボタン48が押下されたことを検出したウェブアプリ3aは、図16に示す署名ウィンドウ50を表示する。この署名ウィンドウ50は、図7に示した署名ウィンドウ25と同様のインターフェイスであり、アーティスト2がペンPを用いて手書きの署名を入力するためのインターフェイスと、確認ボタン51とを有して構成される。署名を入力したアーティスト2が確認ボタン51を押下すると、ウェブアプリ3aは、入力された署名に基づいて図3に示したバイオメトリック署名データを生成したうえで、後述する図20に示す利用申請をウェブサーバ4に送信する。詳しくは後述するが、ウェブサーバ4はこの利用申請に応じて、オーナーに利用申請を通知する処理、オーナーの承認結果に応じて合意内容を取得する処理、利用申請にかかるプロジェクトのDID及びDIDドキュメントを生成し、DIDドキュメントを分散ファイルシステム5に登録する一方、DIDをブロックチェーンネットワーク6に記録する処理、プロジェクトの真正性を証明するためのVCを生成する処理を行う。
【0065】
図17は、利用申請の通知を受けたアーティスト端末3(アートワーク1のオーナーであるアーティスト1のアーティスト端末3)のウェブアプリ3aによって表示されるリクエスト一覧画面(サイドメニュー内のリンク16を押下することによって表示される画面)である。この例では、他のコンピュータから受信した利用申請として、「ライダー」に対するリクエストが1件、画面内に表示されている。
【0066】
ここで、リクエスト一覧画面内に表示される利用申請の具体的な内容としては、例えば図17に示すように、利用申請が送信された日付、利用申請の状態(申請中、許可、拒否など)、申請対象のアートワーク1を特定するデータ(コンテンツ名、アートワーク1を構成するファイルのサムネイルなど)、申請者、リクエストIDが用いられる。このうちリクエストIDは利用申請を一意に識別するための情報であり、利用申請の送信ごとにウェブサーバ4によって付与される。これら以外の情報、例えばアートワーク1のメタデータを構成する情報などを表示することとしてもよいのは、勿論である。
【0067】
リクエストIDは、図18に示す利用申請詳細画面へのハイパーリンクとなっている。ユーザがこのハイパーリンクをクリックすると、ウェブアプリ3aは、図18に示す利用申請詳細画面を表示する。図18に示すように、利用申請詳細画面には、表示欄52~58、許可ボタン59、拒否ボタン60、連絡ボタン61が含まれる。
【0068】
表示欄52にはアートワーク1のコンテンツ名が、表示欄53にはアートワーク1のDIDが、表示欄54にはアートワーク1のオーナーであるユーザのDIDが、表示欄55には、アートワーク1を構成する1以上のウォーターマーク付きファイルのサムネイルが、表示欄56にはアートワーク1のメタデータの全部又は一部が、表示欄57には申請者の情報(写真、氏名など)が、表示欄58にはリクエストの内容(図15に示したリクエスト内容入力インターフェイス46に入力されていた情報)がそれぞれ表示される。
【0069】
連絡ボタン61は、申請者に連絡するための押しボタンである。連絡ボタン61が押下されたことを検出したウェブアプリ3aは、図15に示した連絡ボタン49の押下時と同様に、電子メールの入力画面を表示し、該画面に表示されている送信ボタンをユーザが押下したことに応じて、アートワーク1のオーナーのメールアドレスに対して電子メールを送信する。電子メールに代えて他の通信手段を用いてもよいのは、連絡ボタン49に関して説明したとおりである。
【0070】
許可ボタン59は、利用申請を受け入れるための押しボタンである。一方、拒否ボタン60は、利用申請を拒絶するための押しボタンである。いずれかのボタンが押下されたことを検出したウェブアプリ3aは、押下されたボタンに応じた情報(許可又は拒否)をウェブサーバ4に送信する。この情報に応じてウェブサーバ4が行う処理については後述する。
【0071】
図19は、ウェブサーバ4が行った処理の結果として申請者であるアーティスト2のウェブアプリ3aにより表示されるリクエスト一覧画面の一例を示す図である。この例では、利用申請がオーナーによって許可された結果として、表示される状態が「許可」となっている。この場合、図19に示すように、例えばリクエストIDの近傍に、アートワーク1を構成する各ファイルをダウンロードするためのダウンロードボタン62が表示される。ダウンロードボタン62をユーザが押下した場合のウェブアプリ3aの動作については、後述する。
【0072】
図20及び図21は、アートワーク1の利用申請にかかる処理を示すシーケンス図である。これらの図に示す「ウェブアプリ1」はアートワーク1のオーナーであるアーティスト1のアーティスト端末3上で動作しているウェブアプリ3aを示し、「ウェブアプリ2」は申請者であるアーティスト2のアーティスト端末3上で動作しているウェブアプリ3aを示す。
【0073】
初めにウェブアプリ3aによって、図15に示したリクエスト送信画面が表示される(ステップS50)。ユーザが図15に示したリクエスト送信ボタン48を押下すると、ウェブアプリ3aは、図16に示した署名ウィンドウ50の表示を経て、ウェブサーバ4に対してアートワーク1の利用申請を送信する(ステップS51)。この登録要求には、申請者であるアーティスト2のDIDと、アートワーク1のDIDと、アートワーク1のオーナーであるアーティスト1のDIDと、図15に示したリクエスト内容入力インターフェイス46に入力された情報と、図16に示す署名ウィンドウ50において入力された署名に基づいて生成されたバイオメトリック署名データと、アーティスト2の電子署名とが含まれる。ウェブアプリ3aは、利用申請を構成するデータ(電子署名を除く)のハッシュ値をユーザの秘密鍵によって暗号化することにより、アーティスト2の電子署名を生成する。
【0074】
アートワーク1の利用申請を受信したウェブサーバ4はまず、電子署名とバイオメトリック署名データの正当性を確認する(ステップS52,S53)。それぞれの詳細については、図10のステップS12,S13を参照して説明したものと同様である。
【0075】
次にウェブサーバ4は、アートワーク1のオーナーであるアーティスト1のウェブアプリ3aに対し、利用申請を送信する(ステップS54)。こうして利用申請を受信したウェブアプリ3aは、図17に示したように、受信した利用申請をリクエスト一覧画面内に表示し、その中のリクエストIDをアーティスト1がクリックしたことに応じて、図18に示した利用申請詳細画面を表示する(ステップS55)。そして、アーティスト1が許可ボタン59を押下した場合には「許可」を示す情報を、アーティスト1が拒否ボタン60を押下した場合には「拒否」を示す情報を、それぞれウェブサーバ4に対して送信する(ステップS56)。
【0076】
ウェブサーバ4は、アートワーク1のオーナーのウェブアプリ3aから受信された情報(オーナーの回答)が許可及び拒否のいずれであったかを判定し(ステップS57)、拒否であった場合には申請者であるアーティスト2のウェブアプリ3aに拒否を示す情報を送信する。この場合、図19に示したリクエスト一覧画面において、対応する利用申請の状態欄に「拒否」が表示されることになる。一方、許可であった場合、ウェブサーバ4は、申請者とオーナーの間で合意された内容(原則として、図15に示したリクエスト内容入力インターフェイス46に入力された情報。ただし、申請者とオーナーによってその後に変更されることとしてもよい。)を取得する(ステップS58)。
【0077】
続いてウェブサーバ4は、利用申請にかかるプロジェクトを新たに設定し、設定したプロジェクトのDID及びDIDドキュメントを生成して記憶する(ステップS59)。そして、生成したDIDドキュメントを分散ファイルシステム5に登録する(ステップS60)とともに、生成したDIDをブロックチェーンに記録するためのスマート・コントラクトをブロックチェーンネットワーク6に対して発行する(ステップS61)。ブロックチェーンへの記録が完了すると、ブロックチェーンネットワーク6によりトランザクションIDが発行される。ウェブサーバ4は、このトランザクションID(プロジェクトのトランザクションID)をブロックチェーンネットワーク6から受信して記憶する(ステップS62)。また、ウェブサーバ4は、生成したプロジェクトのDID及びDIDドキュメントを申請者のウェブアプリ3aにも送信する(ステップS63)。
【0078】
図22(a)は、ステップS59においてウェブサーバ4が生成するプロジェクトのDIDドキュメントの構成例を示す図である。同図に示すように、プロジェクトのDIDドキュメントは、オーナー、署名、対象のワーク、利用条件の各情報を含み得る。オーナーには、利用申請に含まれる申請者(この場合はアーティスト2)のDIDが設定される。署名には、利用申請に含まれるバイオメトリック署名データのハッシュ値が設定される。対象のワークには、利用申請の対象となったアートワーク1のDIDが設定される。利用条件には、ステップS58で取得した合意内容を示す情報が設定される。
【0079】
次に図21を参照すると、ウェブサーバ4は、プロジェクトのDIDドキュメントのハッシュ値を発行者秘密鍵を用いて暗号化することにより、電子署名を生成する(ステップS64)。そして、生成した電子署名と、ブロックチェーンネットワーク6から受信したプロジェクトのトランザクションIDとを含むVC(検証可能な証明書)を発行し(ステップS65)、申請者のウェブアプリ3aに送信する(ステップS66)。
【0080】
図22(b)は、プロジェクトのためのVCの内容を示す図である。このVCにも、図12(b)に示したアートワーク1のVCと同様に、発行日、発行者、発行者の電子署名、及びトランザクションIDが含まれる。発行日、発行者、発行者の電子署名の設定内容については、アートワーク1のVCと同様である。トランザクションIDには、ブロックチェーンネットワーク6から受信したプロジェクトのトランザクションIDが設定される。ただし、プロジェクトのVCはトランザクションIDを含まなくてもよい。
【0081】
図21に戻る。プロジェクトのVCを受信したウェブアプリ3aは、図19に示したリクエスト一覧画面を表示する(ステップS67)。この場合においては、対応する利用申請の状態欄に「許可」が表示されることになる。図19に示したリクエスト一覧画面においてダウンロードボタン62の押下を検出したウェブアプリ3aは、ステップS63で受信したプロジェクトのDID及びDIDドキュメント、ステップS63で受信したプロジェクトのVC、及び、アートワーク1を構成する各ファイルのダウンロードページを表示する。これにより申請者であるアーティスト2は、各情報を利用できるようになる。
【0082】
図23は、SNS又は販売サイトを経由してプロジェクトのDIDドキュメント及びVCを受け取ったコンピュータによって実行される処理のフローを示すフロー図である。なお、このコンピュータは、図1に示したアーティスト端末3であってもよいし、他のコンピュータであってもよい。以下、この図23を参照して、プロジェクトのVCの具体的な用途を説明する。
【0083】
コンピュータは、SNS又は販売サイト上で公開されたプロジェクトのDIDドキュメントとともに、当該プロジェクトのVCを取得する(ステップS70)。続いてコンピュータは、取得したDIDドキュメントのハッシュ値を導出する(ステップS71)。また、コンピュータは、VC内に含まれる発行者の情報に基づいて発行者公開鍵を取得し(ステップS72)、取得した発行者公開鍵によりVC内の電子署名を復号する(ステップS73)。そして、復号によって得られたハッシュ値と、ステップS74で導出したハッシュ値とを比較する(ステップS74)。その結果、これらのハッシュ値が一致していれば、公開されたDIDドキュメント(及びその中に含まれる合意内容)の真正性が確認されたことになる。このように、VCによる検証を行うことで、アートワーク1のオーナーと利用申請を行った申請者との間で合意された内容の真正性を確認することが可能になる。
【0084】
最後に、アートワーク1に依拠して制作されたアートワーク2の登録にかかる処理を説明する。図24図26は、アートワーク2の登録を行おうとするアーティスト端末3のディスプレイに表示されるウェブアプリ3aの画面の例である。このアーティスト端末3のユーザであるアーティスト2がサイドメニュー内にあるリンク19を押下すると、ウェブアプリ3aは、上述したマイプロジェクト画面を表示する。このマイプロジェクト画面においてアーティスト2がアートワーク1にかかるプロジェクトを選択した場合、ウェブアプリ3aは、図24に示すコンテンツ登録画面を表示する。
【0085】
図24に示すコンテンツ登録画面には、コンテンツ名入力欄70と、オリジナルワーク表示欄71と、ファイルの選択インターフェイス72と、アートワークのメタデータの入力インターフェイス73と、登録ボタン74とが含まれる。
【0086】
コンテンツ名入力欄70は、ユーザが任意に名付けたアートワーク2の名称を入力するテキストボックスである。図6においては、このコンテンツ名入力欄70にアートワーク1と同じ「ライダー」が入力されているが、アートワーク1の名称と異なる名称を入力してもよい。オリジナルワーク表示欄71には、プロジェクトの対象ワーク(以下「オリジナルワーク」と称する)を示す情報(コンテンツ名、コンテンツID、サムネイルなど)が表示される。
【0087】
選択インターフェイス72は、ユーザがこれから登録しようとするアートワークのファイルを選択するためのインターフェイスである。ここで選択するファイルは、図6に示した選択インターフェイス22と同様に、例えばjpgファイル、pngファイルなどの画像ファイル、又は、複数のファイルを含むフォルダである。図24には、1つのフォルダF1と、1つの画像B1とが選択された状態を示している。画像B1は、例えば画像A2内に含まれる人物の3Dモデルである。フォルダF1には、例えば、画像B1の表示のために使用されるテクスチャ(3Dテクスチャ)を構成する1以上の画像ファイルが含まれ得る。フォルダF1内の各ファイルは、画像B1とともにアートワーク2を構成する。
【0088】
メタデータ入力インターフェイス73は、アートワーク2を説明するための情報であるメタデータを入力するためのインターフェイスである。後述するように、アートワーク2はアートワーク1のオーナーとの共有にかかることから、一部のメタデータについては、ここでは編集できなくなっている。一方、他のメタデータについては入力可能とされており、図24には、そのようなメタデータの例として、アーティスト2による寄与の内容とIP設定とが示されている。
【0089】
ユーザが登録ボタン74を押下すると、ウェブアプリ3aは、図25に示す署名ウィンドウ75を表示する。この署名ウィンドウ75は、図7に示した署名ウィンドウ25や図16に示した署名ウィンドウ50と同様のインターフェイスであり、ユーザがペンPを用いて手書きの署名を入力するためのインターフェイスと、確認ボタン76とを有して構成される。署名を入力したユーザが確認ボタン76を押下すると、ウェブアプリ3aは、入力された署名に基づいて図3に示したバイオメトリック署名データを生成したうえで、後述する図28に示す登録要求をウェブサーバ4に送信する。詳しくは後述するが、ウェブサーバ4はこの登録要求に応じて、アートワーク2を分散ファイルシステム5に登録する処理、アートワーク2のDID及びDIDドキュメントを生成し、DIDドキュメントを分散ファイルシステム5に登録する一方、DIDをブロックチェーンネットワーク6に記録する処理、アートワーク2の真正性を証明するためのVCを生成する処理、アートワーク2を構成する各ファイルにウォーターマークを埋め込む処理を行う。
【0090】
図26は、ウェブサーバ4が行う一連の処理が完了した後、ウェブアプリ3aによって表示される登録完了画面である。同図に示すように、登録完了画面には、所定の情報を表示するための表示欄77~83と、所定の操作を実行するための操作ボタン84~87とが含まれる。
【0091】
表示欄77には、ウェブサーバ4によってブロックチェーンネットワーク6に記録されたアートワーク2のDIDが表示される。表示欄78には、アートワーク2を構成するファイルのサムネイルが一覧で表示される。このサムネイルをクリックすれば、ユーザは対応するファイルをダウンロードすることができるが、ここでダウンロードされるファイルは、後述するウォーターマーク付きのファイルとなる。表示欄79には、オリジナルワークを示す情報(コンテンツ名、コンテンツID、サムネイルなど)が表示される。表示欄80には、アートワーク2の制作に関わった1以上のアーティスト(この場合はアーティスト1及びアーティスト2)の情報(写真、氏名など)が表示される。
【0092】
表示欄81には、ウェブサーバ4がアートワーク2を分散ファイルシステム5に登録する際に付与されるコンテンツIDが表示される。コンテンツIDは、具体的には、アートワーク2を構成する各ファイル及びメタデータからなるアートワークデータのハッシュ値である。表示欄82には、分散ファイルシステム5におけるアートワーク2のアドレスが表示される。表示欄83には、アートワーク2のメダテータの全部又は一部が表示される。
【0093】
操作ボタン84は、アートワーク2を更新するための押しボタンである。操作ボタン84が押下されたことを検出したウェブアプリ3aは、アートワーク2を構成するファイルの追加、変更、削除を実行するための画面を表示する。また、操作ボタン85は、アートワーク2のメタデータを変更するための押しボタンである。操作ボタン85が押下されたことを検出したウェブアプリ3aは、アートワーク2のメタデータを変更するための画面を表示する。操作ボタン84,85の押下に応じて表示される画面において、対応する情報が実際に変更等された場合、ウェブアプリ3aは、ウェブサーバ4に対して改めて登録要求を送信する。これにより、分散ファイルシステム5に登録されているアートワーク2が変更され、ブロックチェーンネットワーク6に新たなDIDが記録され、新たなVCが発行され、アートワーク2を構成する各ファイルに新たなウォーターマークが埋め込まれることになる。
【0094】
操作ボタン86は、アートワーク2をSNSにアップロードするための押しボタンである。また、操作ボタン87は、アートワーク2を販売サイトにアップロードするための押しボタンである。これらの詳細は、図8を参照して説明した操作ボタン35,36と同様である。
【0095】
図27は、図示しないアートワーク一覧表示画面においてユーザがアートワーク2を選択することによって表示されるアートワーク詳細画面である。同図に示すように、このアートワーク詳細画面には、アートワーク2に関する情報の表示欄88~94と、リクエスト内容入力インターフェイス95と、リクエストボタン96とが含まれる。このうちリクエスト内容入力インターフェイス95及びリクエストボタン96の詳細は、図14を参照して説明したリクエスト内容入力インターフェイス46及びリクエストボタン47と同様である。
【0096】
表示欄88にはアートワーク2を制作したアーティスト2の情報(写真、氏名など)が表示される。図14に示したアートワーク詳細画面と異なり、ここにIPオーナーを表示していないのは、アーティスト2が単独でアートワーク2のオーナーを構成しているわけではないことによる。
【0097】
表示欄89には、オリジナルワークを示す情報(コンテンツ名、コンテンツID、サムネイルなど)が表示される。表示欄90にはアートワーク2のコンテンツ名が、表示欄91にはアートワーク2のDIDが、表示欄92にはアートワーク2のオーナー(アートワーク2のDIDドキュメントに設定されているオーナー)である1以上のユーザ(この場合はアーティスト1及びアーティスト2)のDIDが、表示欄93にはアートワーク2の寄与者(アートワーク2のDIDドキュメントに設定されている寄与者)である1以上のユーザ(この場合はアーティスト1及びアーティスト2)の情報(写真、氏名など)がそれぞれ表示される。ウェブサーバ4がこれらの情報を取得する方法は、図14を参照して説明したとおりである。表示欄94には、後述する図29のステップS94で記憶しておいたウォーターマーク付きファイルのサムネイルが表示される。
【0098】
図28図30は、アートワーク2の登録にかかる処理を示すシーケンス図である。図28に示す処理のうちステップS80~S87にかかる処理の具体的な内容は、アートワーク1がアートワーク2に替わる他は、図10に示したステップS10~S17にかかる処理と同様である。ただし、登録要求に含まれるアートワーク2のメタデータは、ウェブアプリ3aが図24に示したメタデータ入力インターフェイス73と、対応するプロジェクトのDIDドキュメント内に設定されている合意内容とに基づいて生成したデータとなる。処理の結果として、アートワーク2のコンテンツID及びアドレスがウェブアプリ3aに送信される(ステップS87)。
【0099】
ステップS87を終了したウェブサーバ4は、アートワーク2のDIDと、アートワーク2のメタデータの全部又は一部を含むDIDドキュメントとを生成して記憶したうえで(ステップS88)、ステップS89~S92の処理を行う。ステップS89~S92にかかる処理の具体的な内容も、アートワーク1がアートワーク2に替わる他は、図10に示したステップS19~S22にかかる処理と同様である。処理の結果として、アートワーク2のDID及びDIDドキュメントがウェブアプリ3aに送信される(ステップS92)。
【0100】
図31(a)は、ステップS88においてウェブサーバ4が生成するアートワーク2のDIDドキュメントの構成例を示す図である。アートワーク2のDIDドキュメントの構成要素は、図12(a)に示したアートワーク1のDIDドキュメントと同様であるが、その内容が一部異なっている。特に、オーナーには、アートワーク1のオーナーであるアーティスト1のDIDと、アートワーク2を制作したアーティスト2のDIDとの両方がそれぞれの持ち分とともに設定される。また、寄与者には、アーティスト1のDIDとアーティスト2のDIDとがそれぞれの寄与内容とともに設定される。
【0101】
次に図29を参照すると、ウェブサーバ4はステップS93~S99の処理を行う。ステップS93~S99にかかる処理の具体的な内容も、アートワーク1がアートワーク2に替わる他は、図11に示したステップS23~S29にかかる処理と同様である。処理の結果として、ウォーターマーク付きの各ファイルと、アートワーク2のVCとがウェブアプリ3aに送信される(ステップS95,S99)。
【0102】
図31(b)は、アートワーク2のためのVCの内容を示す図である。図12(b)に示したVCと比較すると理解されるように、アートワーク2のためのVCは、アートワーク1のためのVCと同様の構成を有している。ただし、発行者の電子署名には、アートワーク2のアートワークデータ及びDIDドキュメントからなるデータのハッシュ値を発行者の秘密鍵で暗号化したものが設定され、トランザクションIDには、アートワーク2のトランザクションIDが設定される。
【0103】
次に図30を参照すると、ウェブサーバ4は、図30に示すように、対応するプロジェクトのDIDドキュメントにアートワーク2のDIDを追記し(ステップS100)、追記したDIDドキュメントにより、記憶しているプロジェクトのDIDドキュメントを更新するとともに、分散ファイルシステム5に記憶されているプロジェクトのDIDドキュメントも更新する(ステップS101)。ウェブサーバ4はまた、更新後のDIDドキュメントをウェブアプリ3aに対して送信する(ステップS102)。
【0104】
図31(c)は、ステップS101において更新されたプロジェクトのDIDドキュメントを示す図である。同図と図22(a)を比較すると理解されるように、更新後のDIDドキュメントには派生ワークの欄が追加され、そこにアートワーク2のDIDが設定されている。これにより、プロジェクトに従って生成された派生ワークをプロジェクトのDIDドキュメント内で管理することが可能になる。
【0105】
図30に戻る。ウェブサーバ4は次に、ステップS103~S105の処理を行う。ステップS103~S105にかかる処理の具体的な内容は、図21に示したステップS64~S66にかかる処理と同様である。処理の結果として、プロジェクトの新たなVCがウェブアプリ3aに対して送信される(ステップS105)。ウェブサーバ4からVCを受信したウェブアプリ3aは図26に示した登録完了画面を生成して表示し(ステップS106)、これにより一連の登録処理が完了する。
【0106】
以上説明したように、本実施の形態によるアートワーク管理システム1によれば、アートワーク1の利用申請を受信したことに応じて、ウェブサーバ5がアートワーク1のDIDと、アートワーク1の利用申請を送信したユーザのDIDとを含むプロジェクトのDIDドキュメントを生成するので、アートワークに関する情報をSSIによって適切に管理することが可能になる。
【0107】
また、本実施の形態によるアートワーク管理システム1によれば、プロジェクトのDIDドキュメントを見ることでオリジナルワークであるアートワーク1と、そこから派生したワークであるアートワーク2との関係を知ることができる。一例を挙げて説明すると、人物を含む絵があり、その絵の中の人物の3Dモデルを作成する場合、人物の絵という2次元のアートワークが3次元のアートワークに派生したということになるが、本実施の形態によるアートワーク管理システム1によって生成されるプロジェクトのDIDドキュメントによれば、人物の絵から3Dモデルへの進化の過程を管理することが可能となる。しかも、プロジェクトのDIDドキュメントとともに配布されるVC内の電子署名に基づく検証を行うことによって、プロジェクトのDIDドキュメントの真正性を確保することができる。したがって、オリジナルワークであるアートワーク1からアートワーク2への進化に関する情報をSSIによって適切に管理することが可能になる。
【0108】
また、プロジェクトのDIDドキュメントの中に、アートワーク1のオーナーとアートワーク2を制作したアーティストとの間で合意された内容を配置しているので、プロジェクトのDIDドキュメントにより、アートワーク1のライセンス条件などのプロジェクトに関わる各種情報もSSIによって管理することが可能になる。
【0109】
また、アートワーク2のDIDドキュメントの中に、アーティスト1のDID及びアーティスト2のDIDを配置するとともに、それぞれの持ち分や寄与の内容を示す情報を配置しているので、これらの情報もSSIによって管理することが可能になる。
【0110】
以上、本発明の好ましい実施の形態について説明したが、本発明はこうした実施の形態に何等限定されるものではなく、本発明が、その要旨を逸脱しない範囲において、種々なる態様で実施され得ることは勿論である。
【0111】
例えば、上記実施の形態では、登録要求に応じ、全体としてのアートワークに対してDID及びDIDドキュメントを生成する例を説明したが、アートワークを構成する個々のファイルに対してもDID及びDIDドキュメントを生成することとしてもよい。また、生成したDID及びDIDドキュメントについて、全体としてのアートワークに対してのDID及びDIDドキュメントと同様に、ブロックチェーンネットワーク6への記録と分散ファイルシステム5への登録を行うこととしてもよい。
【0112】
また、上記実施の形態では、アートワークデータの真正性を証明するためのVCを発行する例を説明したが、個々のファイルやバイオメトリック署名データの真正性を証明するためのVCも発行することとしてもよい。
【符号の説明】
【0113】
1 アートワーク管理システム
3 アーティスト端末
3a ウェブアプリ
4 ウェブサーバ
5 分散ファイルシステム
6 ブロックチェーンネットワーク
10 メールアドレス入力欄
11 パスワード入力欄
12 ログインボタン
13 写真
14 氏名
15~19 リンク
20,24,74 登録ボタン
21,70 コンテンツ名入力欄
22,72 ファイル選択インターフェイス
23,73 メタデータ入力インターフェイス
25,50,75 署名ウィンドウ
26,51,76 確認ボタン
27~31,40~45,52~58,77~83,88~94 表示欄
32~36,84~87 操作ボタン
46,95 リクエスト内容入力インターフェイス
47,96 リクエストボタン
48 リクエスト送信ボタン
49,61 連絡ボタン
59 許可ボタン
60 拒否ボタン
62 ダウンロードボタン
71 オリジナルワーク表示欄
100 コンピュータ
102 記憶装置
103 入力装置
104 出力装置
105 通信装置
A1,A2,B1 画像
F1 フォルダ
図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
図26
図27
図28
図29
図30
図31