JPWO2020080537A1 - 取扱管理装置 - Google Patents

Abstract

取引される対象に関する各種情報を効率的に管理可能なシステムを提供すること。
物品証明情報発行部５１は、流通の対象の価値を向上させる要素に関する作品基本情報と、前記対象の流通にかかる制約条件に関する制約条件情報とを含む、前記対象の証明に関する情報を対象証明情報として、当該対象に対して発行する。流通業者情報発行部５２は、前記対象の流通にかかる提供条件に関する提供条件情報を含む流通業者の証明に関する流通業者証明情報を、当該流通業者に対して発行する。流通許可部５３は、前記対象の流通に際して、前記対象証明情報と前記流通業者証明情報とを対比して、前記制約条件情報により示される前記制約条件が前記提供条件情報における前記提供条件と合致すると判定した場合に、前記流通を許可する。

Description

本発明は、取扱管理装置に関する。

従来より、絵画、建築、彫刻、工芸品等の美術作品は、愛好家により親しまれており、それに伴い、個展等が開催され、また、美術作品の売買も盛んである。
しかし、美術作品の価値については、判断が難しい。そこで、多くの人から美術家（作者・アーティスト）の評価を受けることを可能にし、その評価に応じた対価を美術家に還元するための技術が存在する（例えば、特許文献１参照）。

特開２００９−０４８６１９号公報

しかしながら、作品取引における贋作の混入は未だ深刻な問題である。即ち、特許文献１の技術を含む従来技術では、流通する美術作品が本物であるか（出所）や、これまでどのような人々の手に渡ってきたか（来歴）に関する正確な記録は美術（アート）業界に対する信頼の基礎であるにもかかわらず、十分に行われているとは言えなかった。

本発明は、このような状況に顧みてなされたものであり、取引される対象に関する各種情報を効率的に管理可能なシステムを提供することを目的とする。

上記目的を達成するため、本発明の一態様の取扱管理装置は、
流通の対象の価値を向上させる要素に関する要素情報と、前記対象の流通にかかる制約条件に関する制約条件情報とを含む、前記対象の証明に関する情報を対象証明情報として、当該対象に対して発行する対象証明情報発行手段と、
前記対象の流通の取扱いにかかる提供条件に関する提供条件情報を含む取扱者の証明に関する取扱者証明情報を、当該取扱者に対して発行する取扱者情報発行手段と、
前記対象の流通に際して、前記対象証明情報と前記取扱者証明情報とを対比して、前記制約条件情報により示される前記制約条件が前記提供条件情報により示される前記提供条件と合致すると判定した場合に、前記流通を許可する流通許可手段と、
を備える。

本発明によれば、取引される対象に関する各種情報を効率的に管理可能なシステムを提供することができる。

本発明の取扱管理装置の一実施形態にかかるサーバが適用されたＢＣＮが利用される環境の概要を示す図である。 ＢＣＮで利用されるＢＣＮ証明書の一例を示す図である。 ＢＣＮ証明書を構成する作品来歴情報の一例を示す図である。 ＢＣＮ証明書を構成する作品ルールセット情報の一例を示す図である。 ＢＣＮ証明書とハンドラー登録書の一例を示す図である。 還元金の送付スキームの一例を示す図である。 還元金の送付スキームのうち、図６とは異なる例を示す図である。 一次販売と二次販売のスキームの一例を示す図である。 ブロックチェーンアドレスのＫＹＣのスキームの一例を示す図である。 ＢＣＮスマートコントラクトの概要を示す図である。 ＢＣＮスマートコントラクトのアーキテクチャの一例を示す図である。 Ｔｗｏ−ｗａｙ ｐｅｇを利用したインターオペラビリティを実現する仕組みの一例を示す図である。 トークンの循環問題を示す図である。 分割所有プロジェクトとの連携の一例を示す図である。 ＢＣＮ証明書の移動に際する契約関係の移動の一例を示す図である。 一次販売と二次販売のスキームの一例を含みＢＣＮサービスの全体像を示す図である。図８とは異なる例を示す図である。 ＢＣＮ証明書保管ウォレット作成ＩＤに関する図である。 他社サービスでＢＣＮ証明書保管ウォレット呼び出しに関する図である。 多様なサービスのためのインフラに関する図である。 ＢＣＮ証明書で想定しているビジネスに関する図である。 ＢＣＮ上の所有権・閲覧権情報と連動しつつデジタルアートを表示するシステムのシステム構成図を示す図である。 システム構成図を示す図であって、図２１とは異なる図である。 スマートフォンアプリ、ＮＦＣカードに関する図である。 ブロックチェーン上のコンテンツ所有権と連動したデバイス上での表示制御に関する図である。 作品規約改訂のスキームに関する図である。 作品規約改訂のスキームに関する図であって、図２５とは異なる図である。 本発明の取扱管理装置の一実施形態にかかるサーバのハードウェア構成の一例を示すブロック図である。 図２７のサーバの機能的構成の一例を示す機能ブロック図である。 ＢＣＮサービスが拡張され得るユースケースの一覧である。 ＢＣＮサービスが拡張され得るユースケースの一覧であって、図２９Ａとは異なる図である。

以下、本発明の実施形態について、図面を用いて説明する。

以下、本実施形態の説明において、取引される対象は、美術作品であるものとして説明する。
美術作品の価値の判断は、以下のような問題点等を有すると言える。換言すれば、これらの問題点を解決するべく各種情報の正確性等を担保した上で各種情報を管理することが好適である。本実施形態に係るサーバは、このような各種情報を管理することができる。

作品取引における贋作の混入の原因には、現在の取引が、偽造や改ざんが容易かつ統一的な規格や管理手法も確立されていない紙の証明書に依存している点が挙げられる。この場合の証明書は、十分に証明書たり得ない。その結果として、作品の出所と来歴は、取引の都度、専門家により時間をかけて鑑定されることによって担保される必要がある。

また、管理すべき作品の金額と量とが大きくなる程に、それらの出所と来歴は複雑化する。このような場合、伝統的な手法で情報の正確さを担保することは一層困難になる。

さらに、テクノロジーの発展が及ぼす影響も見過ごすことは出来ない。テクノロジーの発展により、複製技術が向上し、複製可能な形式で流通する美術作品の広がりという大きな潮流がある。即ち、その管理にも相応の技術が求められている。
以上の背景から、作品の出所と来歴の担保は、美術（アート）業界の信頼性維持・向上のために取り組むべき喫緊の課題である。

つまり、上述の特許文献１を含む従来の技術のみでは、昨今のオンライン市場を含めた美術（アート）市場が拡大を続ける中で、贋作の混入が深刻な問題に対応できず、美術作品の信頼性担保や価値証明を困難にするだけでなく、二次流通市場における作品の著作権管理などもほぼ不可能である。この原因は、流通する美術作品の出所と来歴という、信頼性の根幹を管理するシステムの整備が不十分だからである。

美術作品の出所と来歴の担保は、現時点の制度に基づいた美術（アート）業界の信用に貢献するだけではありません。例えば、美術作品が二次流通市場での販売を繰り返す度に売上額の一部を制作者に還元する追及権（Ｒｅｓａｌｅ−Ｒｉｇｈｔｓ）の制度は、現在その是非について様々な観点から議論されていますが、主要な反対意見の1つとして作品の出所と来歴を含む取引記録のモニタリングに多大なコストがかかる点が指摘されている。

また、ある美術作品の所有権を小口に分割してそれらを個別に取引する分割所有（Ｆｒａｃｔｉｏｎａｌ Ｏｗｎｅｒｓｈｉｐ）の提案に関しても、対象となる美術作品及び分割された所有権の出所と来歴をどのように担保するかは取り組むべき課題である。

さらに、管理コストの都合上、これまで二次流通以降での適切な遵守が困難であった著作権や取引ルールも、出所と来歴の記録に付帯した管理によって実用性が大きく高まってきている。

つまり、このように、出所と来歴の担保は、現時点の制度にはまだ存在しない新たな流通管理手法を確立するための土台になり得る。

加えて、美術（アート業界）は、流通する美術作品の価値が美術の文脈に沿って評価されるよう、単純に中間取引を減らせば効率化出来る訳では決してない独特の構造に依拠している。そのため、この構造を踏まえて各関係者のインセンティブを考慮した設計を行わなければ、共通のインフラストラクチャーとしての普及は、これまで困難とされてきた。

もう1つは、乱立するプラットフォーム間で規格が十分に統一されていない点がある。特定のプラットフォーム内でのみ作品管理が出来る状態では利便性の低下は避けられず、さらに言えば、独自規格が乱立した結果オンライン・アート・マーケットそのものが飽和状態となる可能性も危惧される 。

このような現状において、オンライン化を通じた利益を広く行き渡らせるためには、美術（アート）業界における各プレイヤーのインセンティブや将来登場する新たな技術に合わせて出所・来歴に付帯するルール設定や登録情報のフォーマットを適切に変更出来ること、つまりアップグレード性（アップグレーダビリティ）、そして同様の試みを行う他のプラットフォーム間で記録の受け渡しが出来ること、つまり相互運用性（インターオペラビリティ）は欠かせない条件である。

図１は、本発明の取扱管理装置の一実施形態にかかるサーバが適用されたＢＣＮに関する環境の概要を示す図である。
本発明の取扱管理装置の一実施形態にかかるサーバには、ブロックチェーンに係る技術が利用されている。以下、このブロックチェーンに係る技術が利用されたネットワークを、ブロックチェーンネットワーク（以下、「ＢＣＮ」と適宜呼ぶ）と呼ぶ。ＢＣＮ内で発生した取引は、その取引の記録（ブロック）を互いに共有し、検証し合いながら正しい記録をチェーン上のブロックとして記録することができる。
本実施形態に係るＢＣＮにおいて、芸術（アート）販売に関わるサービス、美術作品の物理的保管・価値保全・教育等に関わるサービス、美術（アート）関連金融サービス、その他美術（アート）関連サービスを独自のネットワーク内で発生した取引の記録（ブロック）を互いに共有し、検証し合いながら正しい記録をチェーン上のブロックとして記録するための仕組みである。図１では、取引の記録は、（１）から（２）へ、（２）から（３）へチェーン上のブロックとして記録されるイメージを示している。

図２は、ＢＣＮで利用されるＢＣＮ証明書（作品証明書）の一例を示す図である。
ＢＣＮに登録される各美術作品には、美術作品ごとに一つのＢＣＮ証明書（作品証明書）が発行される。ＢＣＮ証明書（作品証明書）は、大きく分けて、「作品データ」と「関連アカウント情報」の内容が含まれる。以下、それぞれについて詳述する。

「作品データ」は、（Ａ）作品基本情報、（Ｂ）作品来歴情報、（Ｃ）作品ルールセット情報、必要に応じて（Ｄ）デジタルアート情報で構成される。一方、「関連アカウント情報」は、（Ｅ−１）ハンドラーのＩＤと（Ｅ−２）プラットフォームのＩＤ、（Ｆ）発行者のＩＤ、（Ｇ）作者のＩＤ及び（Ｈ）現所有者のＩＤで構成される。

ここで、（Ａ）作品基本情報には、各美術作品に関する基本的な情報が記録される。従来の紙の証明書にも記載されていた「作品タイトル」、「作者」「制作年（月日）」や「技法」といった内容を含む他、美術作品が二次流通市場に出品された後に、真贋鑑定のために参照することができるような、作品登録時点での美術作品そのものに関するデータ（例えば、２Ｄや３Ｄ画像、スペクトルデータ、その他真贋判定に有効なデータがある。）へのリンクも記録が可能である。これらの作品基本情報は、原則として美術作品の流通以降も変更の必要がない情報であるが、例外的には、作者による追加の言語対応や詳細情報の追記が考えられる。

次に、（Ｂ）作品来歴情報には、各美術作品に関する来歴情報が記録される。
図３は、ＢＣＮ証明書を構成する作品来歴情報の一例を示す図である。来歴情報は、何らかの取引が行われた時点で記録される情報で、売買履歴として、その取引が行われた日時（タイムスタンプ）、ハンドラー名やその取引種別（例えば、プライマリー取引、セカンダリー取引、オフライン取引などのカテゴリ）、場所（ロケーション）、所有者ＩＤ鑑定書などといった図３に示す情報が書き込まれる。

また、売買履歴に限らず、展示履歴や保管履歴の他、作品の受賞歴や修復の記録なども含まれる。既に二次流通市場で取引されている美術作品など、それ以前の紙の証明書や来歴情報などが存在する場合には、それらの情報を電子ファイル化した上で、そのリンクを非公開情報として記録するとことが可能である。

さらに、図２に係る（Ｃ）作品ルールセット情報には、作品の二次流通に関連して作者（またはその代理人）が設定する取り決めや、作品所有者に認める著作権のライセンスに関する情報を記述することが可能である。

図４は、ＢＣＮ証明書を構成する作品ルールセット情報の一例を示す図である。作品ルールセットで設定できる流通・著作権管理に関連する項目が例示されている。
具体的には、二次流通に伴う還元金の要否、作品所有者に認める著作権上の利用許諾、二次流通のための販売流通管理などが挙げられる。

加えて、従来からの美術作品（リアルアート）の場合は、ＢＣＮ証明書によって、美術作品の正当な所有権が証明されるが、例えば、静止画やアニメーション，ＳＦＸを駆使した映像的な作品，空間や装置を使った展示・体験型作品(インスタレーション)，そしてインターネット上のアートやＣＤ−ＲＯＭのようにデスクトップ上で見ることができるマルチメディア作品ともいわれるデジタルアートの取引の場合、すなわち図２に係る（Ｄ）デジタルアート情報として、ＢＣＮ上の所有権と美術作品データ自体へのアクセスを、よりオンライン上で直接的に紐付けて管理することが可能である。例えば、分散型ストレージの仕組みであるＩＰＦＳ（Ｉｎｔｅｒｐｌａｎｅｔａｒｙ Ｆｉｌｅ Ｓｙｓｔｅｍ）と本実施形態に係るＢＣＮとの連携運用も可能である。この場合、オリジナル画像データのリンクも可能となる（図示せぬ）。

一方、図２に示す（Ｅ−１）ハンドラーのＩＤと（Ｅ−２）プラットフォームのＩＤ、（Ｆ）発行者のＩＤ、（Ｇ）作者のＩＤ及び（Ｈ）現所有者のＩＤで構成される「関連アカウント情報」には、当該ＢＣＮ証明書と関連するＢＣＮ参加者の例えばイーサリアムアドレスが記述される。
イーサリアムアドレスとは、ブロックチェーン上でコントラクトごとに発行されるアドレスで、ＢＣＮ上では、ハンドラーごとにユニークなアドレスが発行される構造になっている。

なお、本実施形態に係るＢＣＮ参加者とは、ＢＣＮに参加する各種ユーザをいい、以下の５種類で構成される。

（Ｅ−１）ハンドラーとは、プラットフォームが提供するＢＣＮシステムにおける美術（アート）関連の様々な機能を提供する参加者である。ＢＣＮ上での作品証明書の移転や来歴の追加などの役割を担う。後述するＢＣＮ上のハンドラー登録書は、各ハンドラーに対して１セット発行される。

具体的には、ハンドラーは、図１に示す通り、美術（アート）の販売に関わる事業者、美術（アート）作品の物理的保管・価値保全・教育などの来歴に関わる事業者、美術（アート）金融に関わる事業者、その他美術（アート）関連に関わる事業者に大別できる。
美術（アート）の販売に関わる事業者は、アートＥコマース、オークションハウス、ギャラリー、アートディーラーの事業者である。
また、美術（アート）作品の物理的保管・価値保全・教育などの来歴に関わる事業者は、修復・鑑定サービス、保管・輸送サービス、教育機関、美術館の事業者である。
さらに、美術（アート）金融に関わる事業者は、美術品保険を手掛ける損害保険会社、美術品信託会社、美術（アート）担保ローンを提供する金融機関、投資関連会社である。

また、（Ｅ−２）プラットフォームとは、ＢＣＮシステムに直接接続し、美術作品を扱う上記ハンドラーをその提供するＢＣＮシステム上展開（作成）することができる参加者である。

また、（Ｆ）発行者とは、ＢＣＮ証明書（作品証明書）の発行者であるユーザである。発行者としてなりえるユーザの例として、作者（アーティスト）、作者から委託を受けた代理人、各種ハンドラー、所有者（オーナー）がある。

さらに、（Ｇ）作者（アーティスト）とは、作品の作者として、自身の作品を本実施形態に係るＢＣＮに登録する参加者である。自身が創作した作品の著作者であり、ＢＣＮシステム上での著作権ライセンスなどに関するルール設定を行うことが可能である。また、作品流通に伴う還元金が発生する場合には、その受け取り権利者にもなる。作者は本人の場合もあれば、作者から委託を受けた代理人（マネジメントギャラリーなど）の場合もある。

加えて、（Ｈ）所有者（オーナー）とは、法人・個人を問わず、美術（アート）作品を売買・譲渡により所有する参加者である。本実施形態に係るＢＣＮ上での各作品の所有者である。作者が美術作品を所有している場合、所有者（オーナー）と作者（アーティスト）は一致する。

上記ＢＣＮ参加者のイーサリアムアドレスは、（Ｅ−１）ハンドラー及び（Ｅ−２）プラットフォームのコントラクトアドレス、または証明書の受け渡しに利用される外部所有アカウント（ＥＯＡ）のアドレスである。
外部所有アカウント（ＥＯＡ）アドレスには、証明書の発行者、美術作品の作者（またはその代理人）、所有者（過去から現在にかけて）の外部所有アカウント（ＥＯＡ）のアドレスが含まれる。

これらのＢＣＮ参加者のイーサリアムアドレスには、誰が記述した情報なのか、還元金や利用料などが発生する場合、誰が受け取れるのか、誰が美術作品に係るルールを改定（または承認）できるのかを管理する役割がある。

ここまで、ＢＣＮ証明書の内容について詳述したが、ＢＣＮ証明書の発行には２つの発行方法があり、理想的には作者自身（困難である場合には、作者から直接委託を受けた代理人）がＢＣＮシステム上で発行する。本実施形態に係るＢＣＮでは、この発行方法を「プライマリー発行」という。
プライマリー発行されたＢＣＮ証明書は、著作権ライセンスや還元金受け取りのルールを設定可能であり、作者のイーサリアムアドレスを紐付けることが可能である。これにより、他の参加者は、その美術作品の信頼性が高いかどうかを判断が可能である。

もう一つの方法は、現存する二次流通している美術作品のＢＣＮへの登録がある。二次流通している美術作品は、現所有者である所有者（オーナー）や流通関係者によって既に所有されている。このような二次流通作品は、所有者（オーナー）や流通関係者によってＢＣＮ証明書を発行される。本実施形態に係るＢＣＮでは、この発行方法を「セカンダリー発行」という。
なお、セカンダリー発行では、作者（アーティスト）本人の認証を伴わないため、図２に示した（Ｃ）作品ルールセットの設定を行うことができず、作者（アーティスト）のイーサリアムドレスとの紐付けも行うことはできない。
ただし、セカンダリー発行されたＢＣＮ証明書も、後日作者（アーティスト）本人からの認証を受けることによって、プライマリー発行されたＢＣＮ証明書と同様のＢＣＮ証明書に変換することが可能である。この際、作者（アーティスト）は自身の美術作品にルールセットの設定を行うことが可能だが、その場合、その時点での所有者（オーナー）の承認が必要になる。

ＢＣＮ証明書のセカンダリー発行は、今日の美術（アート）業界において、オークションハウスが二次販売の目的で販売証明書を発行したり、美術館が保管の目的で収蔵品登録証明書を発行したりするような実情を反映している。また、文化遺産としての美術作品のデジタルアーカイブ（デジタル情報として記録し，劣化なく永久保存するとともに，ネットワークなどを用いて提供すること）の必要性がより認識されている中で、美術館などの公共的な作品所有者がまとめて美術作品の情報を登録することで、公共財としての性格を持つ美術（アート）の保全に繋がっていく。

さらに、ＢＣＮ証明書のセカンダリー発行は、すでにコレクションを多数有する所有者（オーナー）に対しても、美術作品の情報の管理に新たなインフラを提供することになる。

図５は、ＢＣＮ証明書とハンドラー登録書の一例を示す図である。ハンドラー登録書は、ＢＣＮ証明書と対になる存在とされ、本実施形態に係るＢＣＮに接続する各ハンドラーは、「ハンドラー登録書」をＢＣＮシステム上で設定・発行する。このハンドラー登録書は、ＢＣＮ上における各ハンドラーの登記情報のような役割として、ハンドラーの名称・運営者・所在地・国籍などのハンドラーに関する基礎情報をユーザに示す役割を担うと同時に、ハンドラーの様々な運営ポリシーを表明・運用するための役割も担う。

作者（アーティスト）が、自身の美術作品の扱われ方を（Ｃ）作品ルールセット情報で設定できるのと同様に、各ハンドラーは、ハンドラー登録書上の（ｃ）ハンドラールールセットによって取り扱う美術作品に求める諸条件や、自発的な還元金の設定についてのポリシーを定めることが可能である。

当該（ｃ）ハンドラールールセット情報と（Ｃ）作品ルールセット情報の内容が、ハンドラー登録書とＢＣＮ登録書にそれぞれ記載されている内容と一致しているかを照合する仕組みによって、作者（アーティスト）と流通事業者双方の意向を尊重したマッチングが可能になる。

具体的には、ハンドラー登録書は、（ａ）ハンドラー基本情報、（ｂ）ハンドラー来歴情報、（ｃ）ハンドラールールセット情報で構成される。

（ａ）ハンドラー基本情報は、ＢＣＮ上における各ハンドラーの登記情報が記載され、ハンドラーの名称、所在地や運営者などの基礎情報が含まれる。
（ｂ）ハンドラー来歴情報は、ハンドラーのルールセットの変更履歴などのハンドラーに関わる来歴情報が含まれる。
（ｃ）ハンドラールールセット情報は、ハンドラーが設定する。運営・美術作品の取り扱いに関するポリシー（ルールセット）を示す情報が含まれる。例えば、ハンドラー自らが定める利用規約とは別に、ＢＣＮ上の美術作品の受け入れ・取り扱いのポリシーをブロックチェーン上に表明することが可能である。換言すれば、取り扱いに伴う還元金付与の有無（有りの場合は、その取引金額に対する割合を表明する。）、受け入れる美術作品の証明書に求める条件なども含まれる。

ＢＣＮ証明書の内容（Ａ）作品基本情報、（Ｂ）作品来歴情報及び（Ｃ）作品ルールセット情報と照合することで、美術作品の取り扱いをスマートコントラクトにより制御することが可能になる。ここで、スマートコントラクトとは、契約の自動実行機能のことを指し、例えば、イーサリアム・ブロックチェーンにはスマートコントラクトを実装することで、契約内容に応じた実行制御を自動的に行うことが可能になる機能がある。

次に、図５に示すＢＣＮ証明書の機能について詳細する。
ＢＣＮ証明書には、（Ｂ）作品来歴情報、（Ｃ）作品ルールセット情報、必要に応じて（Ｄ）デジタルアート情報が含まれる。これらの情報により、来歴管理、ルールセットによる流通・著作権管理、ＢＣＮ証明書間の相互参照機能、還元金受け取り機能がある。

来歴管理は、主に（Ｂ）作品来歴情報により可能になる。来歴管理は、美術作品の贋作の流通を防ぐという点で極めて重要である。また、美術作品の価値は真贋や作者（アーティスト）に限らず、その美術作品が辿ってきた歴史的な経路によっても形作られるということが知られている。（Ｂ）作品来歴情報は、売買履歴に限らず展示・保管・修復といった、美術作品の価値に関するあらゆる来歴を包含する。

このような美術作品に関する来歴は、ＢＣＮ上に記述される。それにより、今まで様々な場所に分散していた美術作品に関する来歴がＢＣＮ上に集約的に記述され、美術作品の信頼性担保と美術作品の価値の醸成に寄与することが可能である。

また、現在では美術作品が広範囲に二次流通しているため、美術作品の所在地を作者（アーティスト）自身でさえ把握することが困難である。さらに、作者（アーティスト）の回顧展の開催やカタログレゾネ（美術作品を製作年やサイズなどの情報と共に一元的にまとめた目録）の網羅的な編纂に際し、来歴情報の欠落が障害になっていた。ここで、作品来歴情報がＢＣＮ上に記述され、共有されることによって、人類の共通資産としての美術作品の保全が実物面でも、情報面でも行いやすくなる。

加えて、来歴情報の記述は、基本的に、売買・展示・保管、その他修復・管理などのイベントが発生するハンドラーの単位で行われる。個人の実名や住所など、取引を行う個人の情報の単位では記述されない。これにより、来歴を記録したハンドラーの情報を書き込めるので、今までに培われた（アート）業界内のブランドや信頼をＢＣＮ上で反映することが可能になる。

関連アカウント情報により、ＢＣＮでは、美術作品の所有権の管理に加えて、ルールセットによる流通・著作権管理は、主に（Ｃ）作品ルールセット情報により可能になる。美術作品に関する著作権や二次流通ルールの管理が可能になる。

美術作品の著作権の部分的な利用許可に当たっては、これまで作者（アーティスト）または著作権管理団体と所有者（オーナー）間で個別に契約書を作成・締結する必要があった。ただし、実際には、一連のプロセスには運営上高いハードルがあり、作者（アーティスト）の著作権を保護した上での美術作品の十分な活用にとってボトルネックになっていた。また、美術作品の二次流通に関しても売買に関わる約束事項などを都度契約として締結することは実際の運営上困難である。

ＢＣＮでは、最初に設定されたルールが美術作品の所有権と共に引き継がれる仕組みとなっているため、作者（アーティスト）が各所有者（オーナー）と再度個別に契約を締結する必要がない。

当該仕組みは、作者（アーティスト）だけでなく、所有者（オーナー）や流通関係者に対してもメリットがある。作者（アーティスト）が所有者（オーナー）に対する許諾の範囲を事前に設定しておくことが可能である。そのため、美術作品の所有者（オーナー）や流通関係者は、都度作者（アーティスト）に利用許諾の連絡をする必要がなくなり、美術作品の取り扱いにかかる事務コストを削減することが可能である。

本実施例で今回使用するイーサリアム・ブロックチェーンには、スマートコントラクトと呼ばれる契約の自動実行の機能が実装されている。これにより、ＢＣＮ上で実行可否の自動判別が可能な内容については、契約内容に応じて自動的に実行制御を行うことが可能である。スマートコントラクトによって制御可能な内容の例としては、美術作品の特定のハンドラーへの登録可否の判断、ＢＣＮ証明書の移転に関する制御、ＢＣＮ上で還元金の契約比率に基づく分配、二次創作物やエディション作品（限定部数が付された作品）としての関連証明書の紐付けなどが挙げられる。

一方で、著作権ライセンス関連の契約内容については、実際の実行制御がオンライン上だけでなく、実世界にも関連してくるものが少なからず存在する。
例えば、ある美術作品に関する展示・改変・商品化などのライセンス契約がそれに該当する。それらの契約内容については、実際に契約内容を順守しているかどうかをＢＣＮ上のみで判別することができない。しかしながら、ＢＣＮ上にライセンス許諾範囲・契約内容が明示され、その内容を確認したうえで双方（作者・所有者）が合意した事実が日時を含めて記録されれば、後日確認の必要性が生じた際の根拠とすることが可能である。

美術作品の所有権の移転に伴って、新たな所有者と作者（アーティスト）の間に新たな契約が締結される仕組み、及び作者（アーティスト）またはその代理人と現所有者間によって美術作品のルール改定が行われる仕組みを以下に示す。

まず、美術作品の作者（アーティスト）またはその代理人は、その美術作品の所有者（オーナー）に著作権上の利用ライセンスをどの程度付与するかという情報を、「作品ルール」として、ＢＣＮ証明書上に設定する。

次に、作者（アーテイスト）が設定した「作品ルール」は、ＢＣＮ上に記述され、美術作品の流通時に美術作品の所有権が移転し、ＢＣＮ証明書の権利者が移転するのに伴って、著作権ライセンスの権利者も同時に移転する。この際、法的には、美術作品の作者（アーティスト）と新たな所有者の間に新たなライセンス契約関係が１対１で締結された形になる。特にデジタルアートなどの分野において、美術作品の所有権と独立した特定の著作権ライセンスを取引できる仕組みを実装することも可能になる。

さらに、美術作品の所有権が既に作者（アーティスト）から他の所有者に移転している場合、作品ルールをアップデートするためには、作者（アーティスト）・現所有者の双方の合意が必要になる。すなわち一方から行われた提案に対して、他方が承認を行うプロセスが考えられる。

ＢＣＮ証明書間の相互参照機能（図示せぬ）は、以下の通りとなる。ＢＣＮ証明書には、他の関連性があるＢＣＮ証明書との関連性を相互に参照する形で記述することが可能である。例えば、ある美術作品のエディション作品に対する各証明書や、ある美術作品に基づく公式二次創作物の証明書などが挙げられる。

ＢＣＮ上でＢＣＮ証明書間の関連性を記述することには、以下のようなメリットが主に３つある。

１つは、複数存在するエディション作品の証明書の著作権は、全て同等に扱われるべきであり、相互に矛盾が生じない形で一括に著作権の許諾の設定・管理を行うことが可能である。

２つは、オリジナルの美術作品の著作者から認められた二次創作物の認証、およびオリジナルの美術作品を含めた収益分配の実行が可能である。

エディション作品のエディションの発行上限数は、作者（アーティスト）にとっての美術作品の希少性担保の上で非常に重要な約束事である。３つは、ＢＣＮ上のスマートコントラクトによって、一定数以上のエディション証明書の紐付け発行が行えないように自動制御することが可能である。

還元金受け取り機能は、主に（Ｃ）作品ルールセット情報により可能になる。二次流通からも作者（アーティスト）に収益を還元する仕組みとして、ＢＣＮには、還元金の仕組みが実装されている。作者（アーティスト）は、ＢＣＮ証明書を発行した美術作品が取引される度に、作品ルールセット及びハンドラールールセットに応じて還元金を受け取ることが可能である。

欧州を始めとしていくつかの国・地域では、既に法律により追及権（Ａｒｔｉｓｔ Ｒｅｓａｌｅ Ｒｉｇｈｔｓ）が導入されているが、ＢＣＮの還元金の仕組みでは、追及権の導入国のみに限定せず、作者（アーティスト）と美術作品を扱う各ハンドラー間の合意に基づく契約の形で、還元金機能を実現することが可能である。

図６は、還元金の送付スキームの一例を示す図である。まずは、ＡＰＩ経由で決済サービスを利用して還元金を送付できる仕組みが図示されている。特にオフチェーン（ブロックチェーン外）の場合に該当する。
還元金の支払いは、オフチェーン（ブロックチェーン外）とオンチェーン（ブロックチェーン上）での送金機能を設定することが可能である。オフチェーンの送金は、決済事業者の機能を導入することで実現可能である。

図７は、還元金の送付スキームのうち、図６とは異なる例を示す図である。特にオンチェーン（ブロックチェーン上）の場合に該当する。オンチェーンの送金では、法定通貨から例えばイーサ（イーサリアム上でやり取りされる仮想通貨を指し、ここでは、ＥＴＨと表記する。）、またはステーブルコイン（法定通貨との組み合わせなどにより価格の安定した仮想通貨）などその他価格の安定したコインへ交換することにより実現することが可能である。

上記スキームの構築により、作者（アーティスト）には、事前に、ＢＣＮ証明書内の（Ｃ）作品ルールセットにおいて、その美術作品の流通を取り扱うハンドラーに対して、「還元金をもとめるか」、「（求める場合は、）美術作品の売買金額（※消費税などの各種税金や送料などの関連費用を除く）の何％以上を求めるか」などの設定をすることが可能である。

当該（Ｃ）作品ルールセットにおける還元金に関する設定は、各ハンドラーの設定するハンドラー登録書内の（ｃ）ハンドラールールセットで設定されている図示せぬ「還元金率」と照合される。作者が求める割合以上の還元金を受け取る設定を行っているハンドラーが、美術作品の取り扱いが可能になる。すなわち、ハンドラーが設定している還元金率の要件に当て嵌まる作品のみが、そのハンドラーでの扱いが許可されるという仕組みになる。

還元金制度については、導入によって流通の妨げになるのではないかという市場（マーケット）の懸念が存在する。しかしながら、本実施形態に係るＢＣＮの思想としては、追及権がすでに導入されている国・地域においては、その実行をサポートし、追及権が存在しない国・地域においては、作者（アーティスト）・各サービスが自由に自身のポリシーを設定してマッチングできる仕組みを提供することで、上記懸念は解消する。

作者（アーティスト）は、自身が作者（アーティスト）として受け取る各作品の還元金の受益権の一部を、自身のマネジメントを行う代理人（例えば、ギャラリーなど）や展示施設・教育機関、または自身の制作活動への支援者など他のステークホルダーに対して、自らの設定により分配することが可能である。

これにより、作者（アーティスト）が目下の活動資金が潤沢にない状態でも、制作活動・展示などを行うことを容易にし、複数のステークホルダーが連携してリスクとメリットを共有する仕組みが可能である。

図８は、一次販売と二次販売のスキームの一例を示す図である。具体的には、本実施形態に係るＢＣＮ上での一次・二次販売サービスを利用した場合の販売フローである。

作者（アーティスト）、ハンドラー、所有者（オーナー）が存在する構造の下で、美術作品の売買などが行われる。なお、売買以外に、贈与・保管・修復といったユースケースもあるが、ここでは説明を簡略化するために売買の例を挙げる。

作者（アーティスト）が美術作品をオンライン上の売買サービスに出品する場合のステップ（図示せぬ）は、以下の通りである。なお、ここでのハンドラーは売買サービスを行う。

ステップ１として、作者（アーティスト）が（ｃ）ハンドラールールセット情報に同意したうえで、売買サービスに美術作品を出品するとともに、（Ｃ）作品ルールセット情報を設定する。

ステップ２として、購入者は、美術作品の作品ルールセットに同意し、美術作品を購入する。

ステップ３として、購入者は、売買サービスに、美術作品の代金を支払う。

ステップ４として、ＢＣＮ上の作者アカウントからこの売買サービスのアカウントに、ＢＣＮ証明書が一時的に委託される。

ステップ５として、作者（アーティスト）若しくは売買サービスは、購入者に美術作品を発送する。

ステップ６として、購入者が美術作品を受け取ったことを確認して、売買サービスのアカウントから購入者のアカウントにＢＣＮ証明書が移転され、この売買サービス（一次販売ハンドラー）での売買記録がＢＣＮ証明書の来歴に追加される。

ステップ７として、売買サービスは、作者（アーティスト）に対して販売代金を支払う。

次に、二次流通している美術作品をユーザ間で販売するケースも、基本的な流れは同じになる。美術作品の所有者（オーナー）が売買サービスに美術作品を出品する際、（Ｃ）作品ルールセット情報と、（ｃ）ハンドラールールセット情報が合致する場合に出品が可能である。

さらに、支払いの際、手数料と還元金を除いた代金は、販売者に支払われる。還元金は、美術作品の作者（アーティスト）に支払われる。そして、手数料は売買サービスに支払われる。

上記販売フローの他、個人間（ハンドラーを介さない）の取引もある。個人のウォレット間でＢＣＮ証明書を送付する方法に加えて、ＮＦＣ（近距離無線通信規格）カードの利用も可能である。この方法では、ＢＣＮ証明書にアクセスするために必要な秘密鍵情報の一部を記載したＮＦＣカードを美術作品と共に継承することにより、ＢＣＮ証明書の移転が可能である。

次に、本実施形態に係るＢＣＮは、単一の管理者により管理・認証される組織でなく、透明性と耐改ざん性の特徴を併せ持つブロックチェーン技術それ自体と、合意形成を主軸とするその運営によって美術作品の信頼性を担保する必要がある。ここでは、美術作品の信頼性を担保する方法として、ＢＣＮ証明書やハンドラー登録書の発行主体が、悪意のあるユーザ・事業者でないかという認証と、ＢＣＮ証明書自体が実物と連携しているかという認証が必要である。

図９は、ブロックチェーンアドレスのＫＹＣのスキームの一例を示す図である。
前述の通り、ＢＣＮ証明書及び来歴の信頼性は、その証明書の発行元・来歴の登録者が誰であるのか、という情報により判断可能な仕組みになっている。これには、各種のＢＣＮ参加者のイーサリアムアドレスと、実在の個人若しくは法人がどのように紐付けているのかが重要である。ＢＣＮ証明書の発行元、来歴の登録者が誰であるかという情報に対して、信頼性を付与する可能性があるのは、作者（アーティスト）、作者の委託を受けた代理人、ハンドラーである。

そのため、ＢＣＮ参加者は、ＢＣＮシステムの信頼性のために、実在の個人・法人とイーサリアム上の人格との紐付け（例えば、イーサリアムアドレスのＫＹＣ認証）がされる必要がある。

作者（アーティスト）のＫＹＣ（本人確認）認証は、基本的に各ハンドラーを介して行われるが、ＢＣＮを運営する主体によって直接の認証を受けることも可能である。また、１つのＥＯＡアドレスが複数のハンドラーから認証を受けることも可能である。

一方、個人ユーザの個人情報は、インターネット上に公開されることはないが、ＥＵ（欧州連合）を中心に美術（アート）作品の取引におけるＡＭＬ（アンチマネーロンダイング）の必要性がより検討されている。このような中、ブロックチェーン技術をＡＭＬに適用する可能である。つまりＢＣＮとブロックチェーンアドレスのＫＹＣ（本人確認）サービスが連携することで、ＡＭＬへの応用も可能である。

美術作品の証明書のエコシステムに関わる信頼性の問題には、ＢＣＮ証明書そのものの信頼性の他に、ＢＣＮ証明書に記載されている情報と実際の美術作品との一致をどのように担保するのか、という問題が存在する。これは例えば、ＢＣＮ証明書自体は本物であっても、偽の美術作品が二次流通の過程でＢＣＮ証明書と一緒に悪意を持って販売され、本物の作品自体は以前の持主の手元に留まっているような、実物作品と偽物がすり替えられるケースにおいて問題になる。

このようなリスクを完全に排除することは困難だが、ＢＣＮでは、２つの方法でこの問題に対処可能である。1つ目の対処方法は、美術作品の撮影データをブロックチェーン上に保存する方法がある。２つ目の対処方法は、ＢＣＮの運営主体によってガバナンスを行う方法がある。

１つ目の対処方法では、美術作品そのものの持つ形や色・素材といった情報をいかに正確にデジタルデータ化し保存するかといった課題について、ＢＣＮでは、ＢＣＮ証明書のプライマリー発行時、またはその後、作者（アーティスト）に関する各種撮影データをＢＣＮ証明書の情報の一部として保存することが可能である。ＢＣＮ証明書のブロックチェーン上での発行日時は明確に情報保存されるため、登録された作品の撮影データも、いつの時点の撮影情報であるかは明確となる。その情報を、後日実物と再照合する事によって、すり替えの有無を分析する。

さらに、撮影データの形式は、本実施形態に係るＢＣＮが限定するのではなく、作品の形式に最適なデータ形式で保存が可能である。

２つ目の対処方法では、悪意あるユーザによってＢＣＮ証明書の所有者（オーナー）と実物作品の所有者の乖離が生じてしまう可能性は否定できない。この場合、ＢＣＮの運営主体が、独自のガバナンスによって情報の修正およびそのユーザの追放を行う役割を担うことが可能である。

本実施形態に係るＢＣＮ（ブロックチェーンネットワーク）は、例えば、イーサリアムと呼ばれるパブリックチェーン（パブリック・ブロックチェーン）を採用する。また、イーサリアムには、スマートコントラクトを用いて分散型アプリケーションをブロックチェーン上に構築できる仕組みがある。

図１０は、ＢＣＮスマートコントラクトの概要を示す図である。スマートコントラクトを機能別に分類、スマートコントラクトについて説明する。

本実施例では、他のプロジェクトとの互換性を重視する観点から、ＯｐｅｎＺｅｐｐｅｌｉｎ ＳＤＫというツールキットを活用する。

コントラクトは、大きく分けて、ＢＣＮ証明書（ＢＣＮトークン）に関わる部分と、ハンドラー登録書（マーケット）に関わる部分と後述するメタトランザクションの窓口となる部分（リレー部分）に分かれる。

ＢＣＮトークン側では、例えば、ＥＲＣ７２１に準拠した証明書トークンの発行、または移転を実行する機能がある。一方、マーケット側では、プラットフォームコントラクトによってハンドラー一つ一つがコントラクトして展開され、識別可能な一意のコントラクトアドレスと紐付いた形でハンドラールールの設定が可能となる。そして、それを繋ぐリレー部分は、ユーザのトランザクションを代理で行うメタトランザクションを行うエンドポイントであり、ＢＣＮトークン、マーケットのコントラクト双方に対して関数の実行を行う。ＢＣＮ証明書の所有権移転時などは、ＢＣＮ証明書（ＢＣＮトークン）からハンドラー（マーケット）へのデータ参照を通じて、ハンドラールールセットを反映したオンチェーン上の取引が可能になる。

ＢＣＮ証明書は、ＥＲＣ７２１と呼ばれるイーサリアムにおける代表的なトークン規格の一つを使用する。ＮＦＴ（ノン・ファンジブル・トークンの略）として本実施形態に係るＢＣＮブロックチェーン上に発行される。

さらにコードレベルでは、イーサリアムコミュニティでデファクトスタンダードとなっているＯｐｅｎＺｅｐｐｅｌｉｎのＥＲＣ７２１ライブラリを継承し、定義された関数名に準拠しながらも独自の制御を追加することで、作者（アーティスト）、所有者（オーナー）、ギャラリー、オークションハウスに代表される複数人のステークホルダーの利害を反映したトークン運営が可能となる。

加えて、従来のＷｅｂアプリケーションでは専用のアプリやインターフェイスを通してのみしか、自身の保有する情報にアクセスすることができなかった。しかし、この設計により、ＥＲＣ７２１に対応した個人が所有する一般的なウォレットなどのアプリケーションを通じて、ＢＣＮ証明書の移動、保有一覧の確認などが実行可能になる。

エンドポイントとなるプロキシ（Ｐｒｏｘｙ）コントラクトは、恒久的に使用される想定の下で、そのアドレスが固定され、データ保存のストレージの役割を果たす。一方で、ｄｅｌｅｇａｔｅ＿ｃａｌｌによって関数の実行を外部コントラクトに対してフォワードするという必要最低限の機能しか有していない。プロキシ（Ｐｒｏｘｙ）コントラクトからアクセスされるコントラクト一式は、所有権といったステート情報のみでなくハンドラーの運用・ルールに関わるロジック情報も保持する。このデータストレージとロジックが分離された構造により、耐改ざん性をもつブロックチェーンの特性を保持しながら、ロジック部分のコントラクトをイーサリアム上に再度展開することが可能になっている。
なお、この操作は、参加者の合意を得たうえでガバナンスのコントラクトからのみ行える。Ｐｒｏｘｙコントラクトがもつストレージに対して恒久的、且つ継続してアクセスが可能となるためには、既存のデータに対するアクセスを維持しながら、機能追加や万が一発覚した場合のシステムの不具合への対応が容易になっている。

一方、イーサリアム上へのデータの保存は、様々な制約を伴う。１つのトランザクション内で使用可能なスタックやメモリの量には限度があり、インプットに含まれるデータ量が多くなればＧＡＳ（イーサリアム上の１つの計算ステップの単位）代の高騰につながる。この問題を解決するために、美術作品のメタ情報などのプログラム上の演算などに用いないデータに関しては、イーサリアムネットワーク外のオフチェーン上に記録し、イーサリアム上には原本となるデータが閲覧可能なＵＲＬやそのハッシュ値が保存される使用になる。ハッシュ値はデータ情報を基に生成されるため、イーサリアムへの書き込み以後に改ざんを検証する役割を担う。

イーサリアム・ブロックチェーン上で情報の登録・更新を行うためには、マイナー（イーサリアム上に多数存在する取引の承認者）への手数料としてＧＡＳ代（イーサリアム利用料）を支払う必要がある。このＧＡＳ代は、情報と登録・更新する際に、トランザクションに署名を行ったイーサリアムアドレスから支払われるが、イーサリアム・ブロックチェーン利用の大きな障害となっているのが現状である。

それを解決するために、ＢＣＮはメタトランザクションというＧＡＳ代をプラットフォーム側がユーザに代行して支払うことを可能にする技術を採用する。この技術により、イーサを持つアカウント（プラットフォーム）に、ユーザはスマートコントラクトの執行を委任することが可能になる。すなわち、プラットフォームがユーザに代行してＧＡＳ代を支払うことが可能になる。

また、ユーザに加え、プラットフォームが支払うＧＡＳ代を少なくする工夫も必要となる。これを解決するために、美術作品や来歴などの情報を用途に応じて異なる場所に保存する工夫を行う。美術作品の来歴情報には大きく分けて、スマートコントラクト自動執行の計算式に「必要なもの」と「必要でないもの（記録のみの情報）」が存在する。ＧＡＳ代削減のため、前者はストレージに格納し、後者はイベントログやオフチェーン上に保存する。

次に、美術（アート）業界では、来歴情報の透明性の確保が必要である。ただし、必ずしも全ての情報を公開することが最適というわけではない。美術作品によっては、公開したい情報と公開したくない情報の要件が異なってくる場合がある。所有者（オーナー）がいまどのような美術作品を所有しているのか、いくら支払ったのかといったプライバシーにかかわる情報をブロックチェーン上一般公開するのは望ましくない。

ただし、本来的にはブロックチェーンは構造的に、データの透明性を確保しながら分散的にデータの管理を行うため、全てのノードが同じデータを保存し閲覧可能なように設計されている。従って、一般的なブロックチェーンネットワークに存在するデータは必然的に誰でも閲覧が可能でなっている。そこで、データのプライバシーを重視するブロックチェーンのネットワーク（例えば、エニグマ・プロトコル）を利用することにより、ブライバシー対策を行うことも可能である。

現状のイーサリアムのプロトコルでは、本実施形態に係るＢＣＮの来歴情報は、公開部分と非公開部分の２つの部分から構成されている。この来歴情報はイーサリアムのイベントログ発行を通じて、誰でも閲覧可能な状態で永久に保存される。

一方で、公開したくない来歴情報へのアプローチに関しては、代表的な３つのユースケースが存在する。一つ目は、ユーザがオフチェーンでデータを暗号化した後、ブロックチェーンに記録する方法である。これにより、暗号化する際に使用した鍵がない限り、来歴のプライベート情報を読み取ることができない。

二つ目は、オフチェーンとの融合で、１つは、美術作品の実データなどに関して、その情報の保存先ストレージのリンクのみをブロックチェーン上に記述する方法がある。保存先ストレージサービスのリンクのみをブロックチェーン上に記述する方法がある。保存先ストレージサービスのアクセス権限に関しては、個々のユーザがオフチェーン上で独自に設定を加えることが可能である。

もう１つは、他者から照会不可能なＩＤで記録する方法がある。例えば、サードパーティによって提供される決済プラットフォームを利用して決済した場合、生成された決済ＩＤをブロックチェーン上に記録することで、第三者からの詳細の閲覧を拒否しつつ、決済の存在を証明することが可能である。

次に、アクセス権限管理について説明する。コントラクトのストレージとイベントログの情報は、上述したように基本的に誰でも閲覧可能である。一方で、データの生成・更新、削除といった処理に関しては、その権限が特定の個人・法人に属している必要がある。ＢＣＮでは、作者（アーティスト）、や作品所有者といった人物別単位の権限付与と、所有権移転といった機能別単位権限付与の二軸から生成・更新、削除のアクセス権限管理を実現が可能である。

さらに、作品所有者以外の代理人が出品管理を行う場面を想定し、複数人へのアクセス権限付与や、作者（アーティスト）と作品所有者の両者の承認がないと処理が執行されないようなマルチシグ機能も実装する。

ＧＡＳ代をプラットフォームが代理で支払うことを可能にするメタトランザクション機能について前述した。しかし、このようなメタトランザクションを採用する際に注意すべき項目が複数存在する。スマートコントラクト上で発生し得る脆弱性をとりまとめたＳＷＣ（Ｓｍａｒｔ Ｃｏｎｔｒａｃｔ Ｗｅａｋｎｅｓｓ Ｃｌａｓｓｉｆｉｃａｔｉｏｎａｎｄ Ｔｅｓｔ Ｃａｓｅｓ）のリストからメタトランザクションに関連するセキュリティリスク項目を抜き出し、問題とそれに対してＢＣＮ上で対策を行っている。

例えば、悪意のあるユーザが、引数となる署名を一部改変し、未使用の有効な署名を生成して使用する危険性が想定される。これを回避するためには、ＢＣＮでは署名を生成するハッシュ関数の引数に電子署名を含まない設計を採用する（ＳＷＣ１１７）。また、これに関連してオンチェーン上でデータマッピングをし、同じ署名が利用されることを防ぐような設計を採用する（ＳＷＣ１２１）。また、オフチェーンから電子署名を受け取る際、楕円曲線暗号に準拠した復元方法を用いて、署名者のアドレスを確実に復元する方法を採用する（ＳＷＣ１２２）。

ＢＣＮにアクセスするためには、自身のＥＯＡアドレスに紐付いた秘密鍵が必要である。しかし、この鍵の管理は極めて重要である。方法としては、鍵管理をユーザ自身が行うか、ＢＣＮがユーザの鍵を預かり管理を行うか、第三者鍵管理業者（カストディ業者）に委託するのかの方法がある。鍵管理を専門に行うカストディ業者のカストディサービスを利用することが、鍵の紛失リスクを最小限に抑えることに繋がる。一方で、ＢＣＮが期待するユーザビリティを犠牲にする可能性がある。これは、カストディ業者の技術的進歩とサービスアップデートに依存するため、現時点ではイーサを保有していない鍵においてＢＣＮがその鍵管理を行う可能性及び、ユーザ自身がウォレット上で鍵管理を行う。

図１１は、ＢＣＮスマートコントラクトのアーキテクチャの一例を示す図である。
リレーとは、代理トランザクションを行うメタトランザクションを実行する際のエンドポイントである。まず引数として渡された署名と、元となるハッシュデータから、署名者のイーサリアムアドレス（ＥＯＡアドレス）を復元し、これを引数として付与し直す。
その後、トークン、またはマーケットコントラクトへとつながる各プロキシコントラクトへとアクセスを行います。呼び出し先のコントラクト内では、ｍｓｇ．ｓｅｎｄｅｒがリレーコントラクトであることを確認した後、引数として渡されたＥＯＡアドレスが個々の関数に設定された権限として適切であるかを検証する。

プロキシとは、メタトランザクション実行後のリレーコントラクトと秘密鍵を管理しているウォレット、または読み取りのみのアクセスからのエンドポイントとなります。ｄｅｌｅｇａｔｅ＿ｃａｌｌを実行して、外部のコントラクトへデータをフォワードすると同時に、プロキシコントラクト内部のストレージ領域を参照しながら外部のコントラクト関数を実行することで、データを保存するストレージの役目も果たす。更新されることのないコントラクトとして、固定アドレス、恒久的なストレージを提供しアップグレード可能な設計の要である。

トークンとは、ＯｐｅｎＺｅｐｐｅｌｉｎのＥＲＣ７２１コントラクトを継承することで標準的なＥＲＣ７２１の規格に基づいたトークンの発行や移転の機能を備えた関数にアクセスが可能となる。また、それぞれの関数をオーバーライドすることで、独自の制限や機能を追加しています。トークンに直接関わらない美術作品に関する情報に関しては、Ｋｅｙ−ｖａｌｕｅデータの構造として保存される。また、ＯｐｅｎＺｅｐｐｅｌｉｎ−ＳＤＫによって実質的にプロキシ上のデータストレージに保存が行われることで、アップグレード可能なコントラクトとなっていることも特徴の一つである。

ロジックとは、ＥＲＣ７２１トークンの情報以外に関わる作品メタ情報、来歴情報の保存といった機能に使われる関数が用意されている。トークンから継承され、ストレージコントラクトを継承しており、その上でプロキシコントラクトからｄｅｌｅｇａｔｅ＿ｃａｌｌを用いることで、プロキシ上のストレージに対して事前に定義したデータ型でデータを保存する。トークンと同様にアップグレード可能な仕様となっており、仕様の変更要望などに対応することが可能である。

ストレージとは、事前に多次元のデータ型を定義することで、複数コントラクトから共通のデータ型を利用可能とする。これにより、ＢＣＮ証明書に要素情報と、制約条件情報を含むこと可能になる。

ライブラリとは、データの保存や、演算処理などを実行するコードが用意されている。ロジックコントラクトと分離させることによって、トークンコントラクトのコード総量、ひいてはＧＡＳ総量の削減につながり、より多くの機能を一つのコントラクト内で実装することが可能になる。

アドミンプロキシとは、インプリメントとしてパッケージ化されているコントラクト郡を更新・変更する権限をもつコントラクトアドレスが管理されている。ガバナンスコントラクトのアドレスが登録することも可能である。

マーケットとは、１つのハンドラーに対して、1対1で対応するマーケットコントラクトを展開する。同時に、展開したコントラクトアドレスとマーケットに属する情報(ハンドラーの管理者ＥＯＡアドレスやハンドラー名などがその一例)をマッピングしてストレージに保存しておく役目も担う。コントラクトアドレスを用いて要素をマッピングする理由は２つある。1つ目は証明書の移転時、マーケットに記録された情報を参照した取引の制限や来歴への書き込みを実現するためである。もう1つは、ＯｐｅｎＺｅｐｐｅｌｉｎのＥＲＣ７２１を継承したｔｒａｎｓｆｅｒＦｏｒｍ関数で用いられるアドレスデータの引数ｔｏ(トークンの移転先アドレス)と互換性を持たせるためである。また、ＯｐｅｎＺｅｐｐｅｌｉｎ−ＳＤＫを使用することで、トークンコントラクトの項目で述べた内容と同様に、同じストレージを使用しながら、マーケットコントラクトの内容だけを変更可能である。

マーケットコントラクトとは、マーケットコントラクトから展開されるコントラクトである。上述した通り、目的は、マーケットコントラクト内でマーケットの諸情報とコントラクトアドレスをマッピングすることなので、必要最低限の機能のみ用意されている。

プラットフォームファクトリーとは、ガバナンスによる認証を得ることで、プラットフォームに対して1対1で対応するプラットフォームコントラクトの展開を行うことができる。生成されたコントラクトアドレスとプラットフォームオーナーのＥＯＡは認証済みとしてマッピングされ保存、閲覧が可能となる。これにより、マーケットコントラクトの作成権限を認証済みのプラットフォームのみに限定する。または生成されたマーケットコントラクトが認証済みであるかどうかを検証するなど、悪意あるユーザの参加を防ぐ機能の実装が可能である。

プラットフォームコントラクトとは、プラットフォームファクトリーを経由して生成されるコントラクトである。プラットフォームとそのオーナーを識別する役割を担う。

ガバナンスコントラクトとは、トークンを発行するコントラクトである。本実施形態に係るＢＣＮの運営主体のプロトコルに則り、トークン保有者に対してコントラクトの更新に関する議決権、悪意あるトランザクションへの否決権などが与えられている。

図１２は、Ｔｗｏ−ｗａｙ ｐｅｇ（双方向でのやり取りができること）を利用したインターオペラビリティを実現する仕組みの一例を示す図である。ＢＣＮでは他アートブロックチェーンプロジェクトとのインターオペラビリティを実現するため、ＸＲＰ Ｌｅｄｇｅｒにおけるゲートウェイのような、価値がネットワークに出入りする方法を提供するモデルを参考にし、設計をされている。

この方法は、トークン（ここではＢＣＮ証明書）がブロックチェーン間を横断する際に、移動前のプロジェクト内で証明書を固定（ロック）しておく方法である。この際、移動先のプロジェクト内で新たに証明書を発行する。例えば、ＢＣＮから他のブロックチェーン上に作られたプロジェクトに証明書を移動する場合、ＢＣＮ上でその証明書をロックし、移動先のプロジェクトで新たに証明書を発行するという流れである。そして、証明書を元のＢＣＮ内に戻す際には、そのロックを解除し、再び流通させる。このような方式を一般に「Ｔｗｏ−ｗａｙ ｐｅｇ」と呼ばれる。

この方法を可能にするのは、２つのブロックチェーン間のトークンの移動を管理するゲートウェイ企業である。ＢＣＮと他の異なるブロックチェーンプロジェクトは、このゲートウェイ企業がトークンのロックと解除を行うことによって、接続することが可能になる。

図１３は、トークンの循環問題を示す図である。ＢＣＮを中心にゲートウェイ企業により他のネットワークと接続することは、異なるブロックチェーンを超えたシームレスな証明書の移動を可能になる。一方で、ＢＣＮを介さないトークンの移動によってトークンが複数のネットワークで循環する問題が生じてしまう。あるネットワークで発行された証明書がゲートウェイ企業を通じて、ＢＣＮ、さらに別のネットワークへと順に移動した場合が想定される。循環とは、この際、移転前のネットワークと移転後のネットワーク同士が、ゲートウェイ企業によって接続され、証明書が発行元のネットワークに回帰してしまう現象である。

それを防止するために、そのトークンがどこのプラットフォームから来たトークンなのかという情報をトークンに記述する。そして、トークンがＢＣＮを経由して他のネットワークに移動する際に、発行元のネットワークでロックされたトークンの削除依頼を行う必要がある。

図１４は、分割所有プロジェクトとの連携の一例を示す図である。ここではＢＣＮ来歴を利用するプロジェクトとの連携例として、作品の分割所有を実現するプロジェクトと連携を行う例を紹介する。

作品の購入・投資の機会をより多くの人に提供するべく、作品の所有権を分割販売し、取引することを可能にするプラットフォームが現れている。

ＢＣＮ上の来歴情報を参照する形で分割所有権トークンが発行されることにより、ユーザはＢＣＮの来歴情報を確認した上で安心して分割トークンを購入可能になる。また、ＢＣＮのユーザには幅広い選択肢と、より高い流動性を提供すること可能になる。

図１５は、ＢＣＮ証明書の移動に際する契約関係の移動の一例を示す図である。ＢＣＮにおけるＢＣＮ証明書は、作者（アーティスト）と所有者（オーナー）の個人間の契約合意内容をＢＣＮ証明書と共に次の契約へと引き継ぐ仕組みになっている。新たな所有者（オーナー）が当該作品を購入などした際、作者（アーティスト）によって事前に設定された作品ルールセットに同意することで、契約関係が移行します。その結果、作者（アーティスト）と元の所有者の契約が終了し、作者（アーティスト）と新所有者の間で契約が成立する。

所有権の移転とセットで著作権の利用権が移転するケースと、所有権を伴わない利用許諾単体での契約の両方が想定される。

図１６は、一次販売と二次販売のスキームの一例を含みＢＣＮサービスの全体像を示す図である。のうち、を示す図である。図８とは異なる例を示す図である。具体的には、本実施形態に係るＢＣＮ上での一次・二次販売サービスを利用した場合の販売フローである。

ステップ１として、作者（アーティスト）が美術作品の登録を行い、売買サービス（ハンドラー）に美術作品を出品するとともに、（Ｃ）作品ルールセット情報を設定する。そのうえで、ＢＣＮ上で、ＢＣＮ証明書を発行してもらう。以上が、作者（アーティスト）がＢＣＮに繋がったサービス（ハンドラーＡ)を通じて作品をＢＣＮに登録するフローである。

ステップ２として、購入者であるオーナー１が美術作品のルールセットに同意し、美術作品を購入する。購入者（オーナー１)は売買サービス（ハンドラー）に作品代金を支払う。ＢＣＮ上の作者（アーティスト）アカウントからこの売買サービス（ハンドラー）のアカウントにＢＣＮ証明書が一時的に委託される。作者（アーティスト）若しくは売買サービスが購入者に作品を発送する。購入者（オーナー１)が美術作品を受け取ったことを確認して、売買サービス（ハンドラー）のアカウントから購入者のアカウントにＢＣＮ証明書が移転され、この売買サービス（ハンドラー）での売買記録がＢＣＮ証明書の来歴に追加される (売買金額の登録は必須ではないが、参考情報として閲覧者を制限して登録することが可能である）。売買サービスは作者に販売代金を支払う。以上が、購入者（オーナー）が作品ルールセットに合意して美術作品を購入するフローである。すなわち、一次販売のフローである。

ステップ３として、オーナー１が販売者として美術作品を売買サービスに出品する。その際に、美術作品の作品ルールセットと売買サービス（ハンドラー）のルールセット（ハンドラールールセット）を照合する。問題がなければ美術出品を受け入れる。購入者であるオーナー２が美術作品の作品ルールセットに同意し、美術作品を購入する。購入者（オーナー２) は売買サービスに作品代金を支払う。ＢＣＮ上の作者アカウントからこの売買サービスのアカウントにＢＣＮ証明書が一時的に委託される。販売者（オーナー２)若しくは売買サービスは購入者に作品を発送する。購入者（オーナー２) が美術作品を受け取ったことを確認して、売買サービス（ハンドラー）のアカウントから購入者のアカウントにＢＣＮ証明書が移転され、この売買サービス（ハンドラー）での売買記録がＢＣＮ証明書の来歴に追加される(売買金額の登録は必須ではないが、参考情報として閲覧者を制限して登録することが可能である）。売買サービス（ハンドラー）は、販売者（オーナー１）に販売代金を支払う。以上が、美術作品が別のオーナーに二次販売されるフローである。

ステップ４として、美術作品の所有者（オーナー）が、ＢＣＮと接続した美術（アート）関連サービス（所有者移転を伴わない）に美術作品を登録（保管・保険・鑑定・展示等)する。美術作品の作品ルールセットとサービスのルールセット（ハンドラールールセット）を照合する。問題がなければ作品登録を受け入れる。提供されたサービス内容に応じて、ハンドラー（サービス提供事業者）がＢＣＮ証明書に来歴を追加する。

保管来歴には、保管実施者・保管期間・保管場所に加えて、保管条件等の詳細情報を添付情報として登録可能である (添付情報は、閲覧者を制限したプライベート公開も可能である。)。
保険来歴には、保険提供者・保険対象期間に加えて、保険条件等を添付情報として登録可能 である(添付情報は閲覧者を制限したプライベート公開も可能である。)。
保管来歴には、鑑定実施者・鑑定実施日の記載に加えて、鑑定内容を添付内容も登録可能である(添付情報は閲覧者を制限したプライベート公開も可能である。)。
展示来歴には、展示場所・展示期間に加えて、その他展示に関連した詳細情報を添付情報として登録可能である (添付情報は閲覧者を制限したプライベート公開も可能である。)。

図１７は、ＢＣＮ証明書保管ウォレット作成ＩＤに関する図である。ウォレットＩＤとは、ＢＣＮ上のユーザＩＤ（イーサリアムを利用する場合はイーサリアムアドレス）と同義である。
まず、ユーザは、既存のユーザでなければ、新規ユーザ登録を開始する必要がある。新規ユーザにより所定の情報が登録されると、サーバ内でユーザ情報が格納される。
次に、ＢＣＮ上のブロックチェーン技術により新規ユーザのウォレットＩＤが新規に作成される。次に、このウォレットＩＤは、サーバ内でウォレットＩＤが格納される。

図１８は、他社サービスでＢＣＮ証明書保管ウォレット呼び出しに関する図である。ＢＣＮでない他社サービスでウォレットＩＤを有するユーザの場合、まず、ＢＣＮ上のユーザ管理画面において他社が発行したウォレットＩＤを入力する。入力されたウォレットＩＤが入力されると、サーバ内でウォレットＩＤが登録される。
次に、登録されたウォレットＩＤをＢＣＮ上の確認がなされる。その際、ウォレットＩＤに紐付いた作品情報がサーバに対して送信される。
このウォレットＩＤに紐付いた作品情報をサーバは取得し、作品の管理・販売などに活用することが可能である。

図１９は、多様なサービスのためのインフラに関する図である。本図における「ＢＣＮと連携したサービス」とは、ＢＣＮと連動して機能するサービスの一例を表す。ユーザは、ウォレットＩＤを入力すると、ＢＣＮと連携するあらゆる美術作品関連サービスからでもＢＣＮ証明書を活用することが可能である。連携可能な美術作品関連サービスには、オークションハウス、クリエーターＳＮＳ，額縁デジタルアートサブスクリプション、鑑定サービス、保険サービス、コレクションアーカイブサービス、質屋サービス、ＥＣサービス、証明書発行サービスなどが挙げられる。また、ＢＣＮの運営主体と異なる運営主体によって運営されるサービスも含む。
この場合、ユーザは、ＢＣＮ証明書を活用することによりＢＣＮが主催しない他のオークションサービスも利用することが可能になる。

なお、ユーザは、ＢＣＮのＡＳＰ（アプリケーションサービスプロバイダ）システムを経由してセキュアにブロックチェーン接続が可能である。この場合、ＢＣＮのＡＳＰシステムに盛り込まれている機能には、主に証明書管理及び証明書発行がある。

証明書管理には、証明書の初期設定（サービス名などの登録）、証明書の値段設定、販売管理及び管理画面が用意されている。
証明書発行には、証明書発行用ユーザインターフェース、証明書ＩＤの発行、証明書ＩＤのインポート・エクスポート、証明書に紐付いた作品の情報管理及び証明書の来歴表示インターフェースが用意されている。

その他の機能として、共通の規約や同意文に関する機能や、日本語・英語対応など言語に関する機能が用意されている。

図２０は、ＢＣＮ証明書で想定しているビジネスに関する図である。例の１として、エディション限定作品の販売管理がある。具体的には、ある作品がエディション作品であることを証明するために、エディションナンバーをＢＣＮ証明書に記入することが可能である。作品ルールセット情報に、エディションナンバーが記入されることにより、作品のエディション管理が行われた情報で作品の二次流通が可能となる。
写真作品、映像作品などは容易に複製が出来るため、エディション管理は作品管理には必須の要素である。ＢＣＮ証明書ではエディション数を限定した複製作品の管理も行うことが可能である。

例の２として、デジタル作品の販売管理がある。具体的には、デジタル作品の所有者を証明するために、所有者情報をＢＣＮ証明書に記入することが可能である。作品ルールセット情報に、デジタル作品の所有者が記入されることにより、作品の所有者が明確になり、作品の所有者の許諾若しくは新たな所有者への移転に基づく、二次流通が可能になる。
従来、デジタル作品は複製が簡単に行えることから、そのポテンシャルは評価されているものの、財として流通しにくい側面があった。そこで、ＢＣＮ証明書を使用することによりそのような複製が容易な作品にもユニークなＩＤを振り、販売管理を行うことが可能である。

例の３として、作品のレンタル管理がある。具体的には、作品の所有権を移転せずに、作品の貸し借り（レンタル）の記録をＢＣＮ証明書に記入することが可能である。作品ルールセット情報に、作品の貸し借りの記録などのレンタル管理だけでなく、美術館などでの展示履歴も記入することが可能となる。
ＢＣＮ証明書を使えば、美術品（作品）のレンタルビジネスの管理を行うことが可能である。作品の通常貸出のみならずデジタル作品のレンタルや、美術館同士の作品貸し借りの管理をすることも可能になる。場合によっては作品価値向上の来歴管理にも繋げることが可能である。

図２１は、ＢＣＮ上の所有権・閲覧権情報と連動しつつデジタルアートを表示するシステムのシステム構成図を示す図である。作者（アーティスト）は、芸術作品（実物）をスキャン若しくは撮像し、デジタルデータをサーバのデータベースに格納する。また、作者（デジタルアーティスト）は、デジタル作品をそのまま投稿し、サーバのデータベースに格納する。また、作者以外の代理人またはその他のハンドラー（版権を管理する事業者等）が同様に作品情報を格納することも可能である。

上述の作者（アーティスト及びデジタルアーティスト）は、デジタルデータの他に、所有権情報、画像情報、著作権情報、メタデータなども格納することが可能である。その際、作者は、ＡＰＩ経由で、ＢＣＮ証明書情報の取得及びＢＣＮ証明書の発行が可能である。ＢＣＮ証明書情報は、世界中のＢＣＮに参加するサービスで共有できるため、他社サービスとも連携が可能である。また、分散型ストレージの仕組みであるＩＰＦＳ（ファイルストレージ）とＢＣＮとの連携運用も可能である。この場合、オリジナル画像データのリンクも可能となる（図示せぬ）。

また、ＢＣＮサービスの一環として提供する額縁デバイス連動用ＳＤＫを活用することにより、サーバは、他社表示デバイスとも連携が可能となる。これに対し、ユーザやコレクターは、表示権や配信のためのサブスクリプションなどを購入することが可能となる。その際、ユーザ等は秘密鍵管理用アプリ若しくは秘密鍵連動ＮＦＣカードを用いて自らが所有するデジタルアート作品の管理を行うことができる。

上記購入により、ＢＣＮサービスの提供者は、プラットフォーム収入を得ることが可能となる。また、作者は、著作権収入や所有権販売時の収入の他、二次販売時の還元金収入、二次創作が販売された時の分配金などを受け取ることが可能となる。

図２２は、システム構成図を示す図であって、図２１とは異なる図である。次に各システムを説明する。
Ａ−（１）は、創作物の権利関係を管理し、１次〜ｎ次創作者、または一次〜ｎ次販売者、さらには、一次〜ｎ次販売代理人に収益を分配するための、収益分配機能である。

Ａ−（２）は、ＢＣＮで、作品証明書のみならず容量の大きいデジタルアートの作品データ自体を管理するための、分散型ストレージ（ＩＰＦＳ等）をいう。

Ａ−（３）は、休眠しているアート作品を２Ｄ・３Ｄスキャニングし、デジタルデータ化・ブロックチェーン登録するためのアプリケーションである。

Ａ−（４）は、ＢＣＮに接続したデジタルコンテンツの流通のためのＷｅｂプラットフォームである。デジタル作品の登録、ブロックチェーン証明書の発行、デバイスへのコンテンツ配信及び証明書付きのデジタル作品購入が可能なＷｅｂプラットフォームである。

Ａ−（５）は、ユーザがＢＣＮでの自身のアカウントのプライベートキー（秘密鍵）を管理するためのスマートフォンウォレットである。Ａ−（３）のＷｅｂプラットフォームと連携する作品登録や購入機能、著作権規約変更承認機能を有する。

Ａ−（６）は、デジタル作品のブロックチェーン証明書を物理的にもやり取り可能にするためのＢＣＮと連携する作品証明書アクセスキーを保存したＮＦＣカードである。展示会での販売等対面形式での販売シーンにも対応を可能にするためである。

Ａ−（７）は、ＢＣＮ上の所有権・著作権許諾と連動してデジタル額縁デバイスで作品を鑑賞するためのＳＤＫである。

図２３は、スマートフォンアプリ、ＮＦＣカードに関する図である。スマートフォンアプリ（Ｗｅｂアプリ）の機能を列記する。
ユーザのブロックチェーンアカウントの管理（プライベートキーの管理を含む。）が可能である。
ユーザの表示デバイスとアカウントの紐付けが可能である。
デジタルコンテンツのサブスクリプション契約の管理（申し込み及び停止を含む。）が可能である。
限定版デジタルコンテンツの購入及び管理が可能である。
ユーザの持つデジタルコンテンツをＷｅｂ上で二次販売のために出品する際に、ユーザのアカウントが作品を保有することを証明するために認証する機能を有する。
限定版デジタルコンテンツの二次出品と同時に、アカウントに付随した表示デバイスから表示データを消去する機能を有する。
作品に付随する規約の確認・同意・変更提案が可能である。
作者とのメッセージのやり取り機能を有する。

ＮＦＣカードについて説明する。ＮＦＣカードは、ＮＦＣが埋め込まれたＩＣカードである。ブロックチェーン上の作品証明書に紐付いた秘密鍵が格納されている。スマートフォンアプリ内のＮＦＣリーダーに対応し、スマートフォンに近づけて情報を読み込む際には事前に設定されたパスコードを入力する仕様である。物理的な保証の要求に対応したり、やむを得ないオフラインでの取引時に使用する。
なお、デザインは、サービスに変更可能である。

図２４は、ブロックチェーン上のコンテンツ所有権と連動したデバイス上での表示制御に関する図である。
ユーザは、スマートフォン若しくはＷｅｂアプリ上で、アカウント管理を行うことが可能である。スマートフォン等は、ＢＣＮサービスのサーバとデジタル額縁デバイスとそれぞれ連携している。

ＢＣＮサービスと連携したスマートフォン等には、保有コンテンツの情報が表示される
ため確認が可能になる。その際、表示デバイスを選択することによりデジタル額縁がスマートフォン等に表示される。

選択されたデジタル額縁がスマートフォン等に表示された状態の場合、コンテンツ所有権の移転が可能である。具体的には、スマートフォン等の表示画面にある売却ボタンを押すと、デジタル額縁の表示データが消去される。スマートフォン等には、デジタル額縁の表示データの消去完了の通知が送付される。当該通知受領後、ＢＣＮ上では、新たな保有者への権利移転処理がなされる。

図２５は、作品規約改訂のスキームに関する図である。ＢＣＮ証明書を有するユーザ若しくはコレクターが現所有者の場合、スマートフォン等の表示画面を通じて、規約の改定内容を提案可能である。上記ユーザ等が規約改定の提案を行うと、作品二次売買プラットフォーム、ＢＣＮ及び作品一次売買プラットフォームを経て、作者に対して規約改定若しくは変更の通知（提案）がなされる。作者は、当該通知（提案）に同意しない場合、不同意に通知若しくは放置することが可能である。

一方、作者は、当該通知（提案）を同意する場合、ユーザ等に対して同意の通知をすることが可能である。この場合、保存された変更内容は、作品一次売買プラットフォーム、ＢＣＮ及び作品二次売買プラットフォームを経て、ユーザ等に対して規約改定若しくは変更完了の通知がなされる。当該通知完了後は、ユーザ等及び作者は、変更後の規約によって両者は制約を受ける。

図２６は、作品規約改訂のスキームに関する図であって、図２５とは異なる図である。作者は、スマートフォン等の表示画面を通じて、規約の改定内容を提案可能である。当該作者が規約改定の提案を行うと、作品一次売買プラットフォーム、ＢＣＮ及び作品二次売買プラットフォームを経て、ユーザ等に対して規約改定若しくは変更の通知（提案）がなされる。ユーザ等は、当該通知（提案）に同意しない場合、不同意に通知若しくは放置することが可能である。

一方、ユーザ等は、当該通知（提案）を同意する場合、作者に対して同意の通知をすることが可能である。この場合、保存された変更内容は、作品二次売買プラットフォーム、ＢＣＮ及び作品一次売買プラットフォームを経て、作者に対して規約改定若しくは変更完了の通知がなされる。当該通知完了後は、作者及びユーザ等は、変更後の規約によって両者は制約を受ける。

図２７は、本発明の取扱管理装置の一実施形態にかかるサーバのハードウェア構成の一例を示すブロック図である。

サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３と、バス１４と、入出力インターフェース１５と、入力部１６と、出力部１７と、記憶部１８と、通信部１９と、ドライブ２０とを備えている。

ＣＰＵ１１は、ＲＯＭ１２に記録されているプログラム、又は、記憶部１８からＲＡＭ１３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

ＣＰＵ１１、ＲＯＭ１２及びＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インターフェース１５も接続されている。入出力インターフェース１５には、入力部１６、出力部１７、記憶部１８、通信部１９及びドライブ２０が接続されている。

入力部１６は、例えばキーボード等により構成され、各種情報を出力する。
出力部１７は、液晶等のディスプレイやスピーカ等により構成され、各種情報を画像や音声として出力する。
記憶部１８は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部１９は、インターネットを含む通信ネットワークＮを介して他の装置との間で通信を行う。

ドライブ２０には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア３０が適宜装着される。ドライブ２０によってリムーバブルメディア３０から読み出されたプログラムは、必要に応じて記憶部１８にインストールされる。
また、リムーバブルメディア３０は、記憶部１８に記憶されている各種データも、記憶部１８と同様に記憶することができる。

このような図２７のサーバ１の各種ハードウェアと各種ソフトウェアとの協働により、上述の各種処理の実行が可能になる。

図２８は、図２７のサーバの機能的構成の一例を示す機能ブロック図である。

図２８に示すように、サーバ１のＣＰＵ１１においては、物品証明情報発行部５１と、流通業者情報発行部５２と、流通許可部５３と、第１関連付部５４と、第２関連付部５５と、第３関連付け部５６と、取引履歴取得部５７と、ガバナンストークン管理部５８と、仕様変更部５９とが機能する。

物品証明情報発行部５１は、流通の対象（例えば作品）の価値を向上させる要素に関する要素情報と、前記対象の流通にかかる制約条件に関する制約条件情報とを含む、前記対象の証明に関する情報を対象証明情報として、当該対象に対して発行する。
流通業者情報発行部５２は、前記対象の流通にかかる提供条件に関する提供条件情報を含む流通業者の証明に関する流通業者証明情報を、当該流通業者に対して発行する。
流通許可部５３は、前記対象の流通に際して、前記対象証明情報と前記流通業者証明情報とを対比して、前記制約条件情報により示される前記制約条件が前記提供条件情報における前記提供条件と合致すると判定した場合に、前記流通を許可する。

ここで、前記制約条件及び提供条件は、前記対象の現物の二次流通の際の条件を含むようにすることができる。

また、前記制約条件及び提供条件は、還元金に係る条件を含むようにすることができる。

さらにまた、前記制約条件及び提供条件は、前記対象の二次的著作物に関する条件を含むようにすることができる。

第１関連付部５４は、前記対象が二次的著作物を含む場合、当該二次的著作物と原著作物との関連付けを行う。

第２関連付部５５は、前記対象が複数のエディションを有する場合、当該複数のエディションの夫々の関連付けを行う。

ここで、前記制約条件及び提供条件は、著作権の移転が所有権の移転を伴うという条件を含むことができる。
一方、前記制約条件及び提供条件は、著作権の移転が所有権の移転を伴うことを要しないという条件を含むこともできる。

第３関連付部５６は、サーバ１が適用されるシステムで管理される取引市場から、当該取引市場とは異なる別取引市場へ前記対象が移転される場合に、当該別取引市場を識別する識別情報を当該対象と関連付けを行う。
取引履歴取得部５７は、前記対象が前記別取引市場から前記取引市場に移転される場合に、当該対象に関する取引きの履歴に関する情報を取引履歴情報として取得する。

さらに、取引履歴取得部５７は、サーバ１が適用されるシステムで管理される取引市場から、当該取引市場とは異なる第１別取引市場へ前記対象が移転され、さらに、当該第１別取引市場から、当該取引市場及び前記第１別取引市場とは異なる第２別取引市場へ前記対象が移転され、その後、当該第２別取引市場から前記取引市場に移転される場合に、当該対象に関する取引きの履歴に関する情報を前記取引履歴情報として取得する。

ガバナンストークン管理部５８は、サーバ１が適用されるシステムで管理される取引市場とは異なる取引市場を別取引市場として、当該別取引市場による当該取引市場へのアクセスに関する情報を含むガバナンストークンを管理する。

仕様変更部５９は、サーバ１が適用されるシステムで管理される取引市場における前記対象証明情報と前記流通業者証明情報のうち少なくとも一方の仕様変更に関する意思決定を行う。
例えば、仕様変更部５９は、閾値を調整可能なＶＥＴＯ投票の結果に基づいて、前記仕様変更に関する前記意思決定を行うことができる。

以上、本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。

例えば、流通の対象は、美術品等上述の例に特に限定されず、任意の１以上の者にとって価値を有すると判断されるものであればよい。
例えば、図２９Ａや図２９Ｂに「ユースケース」として夫々示すものを、流通の対象として採用することができる。
なお、図２９Ａや図２９Ｂにおける「備考」には、同一行の「ユースケース」で特定される流通の対象についての、具体例、内容説明等各種各様な説明が記載されている。

また、上述に示すシステム構成や、図２７に示す管理サーバ１のハードウェア構成は、本発明の目的を達成するための例示に過ぎず、特に限定されない。

また、図２８に示す機能ブロック図は、例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能がシステムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは、特に図２８の例に限定されない。

また、機能ブロックの存在場所も、図２８に限定されず、任意でよい。
また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。

各機能ブロックの処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。

このようなプログラムを含む記録媒体は、各ユーザにプログラムを提供するために装置本体とは別に配布される、リムーバブルメディアにより構成されるだけではなく、装置本体に予め組み込まれた状態で各ユーザに提供される記録媒体等で構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に添って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。

また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものである。

１・・・サーバ、１１・・・ＣＰＵ、１２・・・ＲＯＭ、１３・・・ＲＡＭ、１４・・・バス、１５・・・入出力インターフェース、１６・・・入力部、１７・・・出力部、１８・・・記憶部、１９・・・通信部、２０・・・ドライブ、５１・・・物品証明情報発行部、５２・・・流通業者情報発行部、５３・・・流通許可部、５４・・・第１関連付部、５５・・・第２関連付部、５６・・・第３関連付部、５７・・・取引履歴取得部、５８・・・ガバナンストークン管理部、５９・・・仕様変更部

Claims (13)

1. 流通の対象の価値を向上させる要素に関する要素情報と、前記対象の流通にかかる制約条件に関する制約条件情報とを含む、前記対象の証明に関する情報を対象証明情報として、当該対象に対して発行する対象証明情報発行手段と、
   前記対象の流通の取扱いにかかる提供条件に関する提供条件情報を含む取扱者の証明に関する取扱者証明情報を、当該取扱者に対して発行する取扱者情報発行手段と、
   前記対象の流通に際して、前記対象証明情報と前記取扱者証明情報とを対比して、前記制約条件情報により示される前記制約条件が前記提供条件情報により示される前記提供条件と合致すると判定した場合に、前記流通を許可する流通許可手段と、
   を備える取扱管理装置。
2. 前記制約条件及び提供条件は、前記対象の現物の二次流通の際の条件を含む、
   請求項１に記載の取扱管理装置。
3. 前記制約条件及び提供条件は、還元金に係る条件を含む、
   請求項１に記載の取扱管理装置。
4. 前記制約条件及び提供条件は、前記対象の二次的著作物に関する条件を含む、
   請求項１に記載の取扱管理装置。
5. 前記対象が二次的著作物を含む場合、当該二次的著作物と原著作物との関連付けを行う第１関連付手段、
   をさらに備える請求項１又は４に記載の取扱管理装置。
6. 前記対象が複数のエディションを有する場合、当該複数のエディションの夫々の関連付けを行う第２関連付手段、
   をさらに備える請求項１に記載の取扱管理装置。
7. 前記制約条件及び提供条件は、著作権の移転が所有権の移転を伴うという条件を含む、
   請求項１に記載の取扱管理装置。
8. 前記制約条件及び提供条件は、著作権の移転が所有権の移転を伴うことを要しないという条件を含む、
   請求項１に記載の取扱管理装置。
9. 前記取扱管理装置が適用されるシステムで管理される取引市場から、当該取引市場とは異なる別取引市場へ前記対象が移転される場合に、当該別取引市場を識別する識別情報を当該対象と関連付けを行う第３関連付け手段と、
   前記対象が前記別取引市場から前記取引市場に移転される場合に、当該対象に関する取引きの履歴に関する情報を取引履歴情報として取得する取引履歴取得手段と、
   をさらに備える請求項１に記載の取扱管理装置。
10. 前記取引履歴取得手段は、
    前記取扱管理装置が適用されるシステムで管理される前記取引市場から、当該取引市場とは異なる第１別取引市場へ前記対象が移転され、
    さらに、当該第１別取引市場から、当該取引市場及び前記第１別取引市場とは異なる第２別取引市場へ前記対象が移転され、
    その後、当該第２別取引市場から前記取引市場に移転される場合に、当該対象に関する取引きの履歴に関する情報を前記取引履歴情報として取得する、
    請求項９に記載の取扱管理装置。
11. 前記取扱管理装置が適用されるシステムで管理される取引市場とは異なる取引市場を別取引市場として、当該別取引市場による当該取引市場へのアクセスに関する情報を含むガバナンストークンを管理するガバナンストークン管理手段、
    をさらに備える請求項１に記載の取扱管理装置。
12. 前記取扱管理装置が適用されるシステムで管理される取引市場における前記対象証明情報と前記取扱者証明情報のうち少なくとも一方の仕様変更に関する意思決定を行う仕様変更手段、
    をさらに備える請求項１に記載の取扱管理装置。
13. 前記仕様変更手段は、閾値を調整可能なＶＥＴＯ投票の結果に基づいて、前記仕様変更に関する前記意思決定を行う、
    請求項１２に記載の取扱管理装置。

Images