JP7243154B2 - 提供装置及び処理システム - Google Patents

Description

本発明は、提供装置及び処理システム等に関する。

従来、プリンター等の電子機器に関するサービスを提供するシステムが知られている。例えば、電子機器の消耗品を自動配送するためのシステムが知られている。特許文献１には、デバイスの消耗品が交換条件を満たすと、情報処理端末からサーバーに消耗品を発注して、消耗品の発送を要求するシステムが開示されている。

特開２０１７－２１５６９１号公報

電子機器に関するサービスを提供するシステム構成は種々考えられる。例えば、電子機器からのデータを収集、集計するシステム、集計結果に基づいて具体的なサービスを行うシステム、課金額を請求するシステム、決済を行うシステム等、複数のシステムを連携させる手法が考えられる。

しかし従来、電子機器に関するサービスを提供するシステムにおいて、ブロックチェーン技術を用いる手法は開示されていなかった。

本開示の一態様は、ブロックチェーンを用いたネットワークとの通信を行う通信部と、前記通信部を制御する処理部と、を含み、前記処理部は、管理対象である電子機器についてのサービス提供処理を行うためのサービス提供処理プログラムを、前記ブロックチェーンに登録するためのトランザクションを生成し、生成した前記トランザクションを、前記通信部を介して前記ネットワークに発行し、前記サービス提供処理プログラムは、前記ブロックチェーンに記憶されたサービス提供者情報により表されるサービス提供者に、サービスを依頼する処理を行う提供装置に関係する。

提供装置の構成例。 処理システムの構成例。 ブロックチェーンの説明図。 ブロックチェーンへの書き込み処理を説明するフローチャート。 サービス提供者の登録処理を説明するフローチャート。 サービス提供者の登録処理を説明する他のフローチャート。 本実施形態のブロックチェーンの例。 消耗品配送サービスにおける定期実行処理を説明するフローチャート。 消耗品配送サービスにおける定期実行処理を説明するフローチャート。 消耗品の残量収集及び残量計算処理を説明するフローチャート。 警告状態確認処理を説明するフローチャート。 配送手配処理を説明するフローチャート。 課金、請求、決済処理を説明するフローチャート。 本実施形態のブロックチェーンの他の例。 修理請負サービスにおける定期実行処理を説明するフローチャート。 修理請負サービスにおける定期実行処理を説明するフローチャート。 状態確認処理を説明するフローチャート。 修理手配処理を説明するフローチャート。 課金、請求、決済処理を説明するフローチャート。

以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された内容を不当に限定するものではない。また本実施形態で説明される構成の全てが必須構成要件であるとは限らない。

１．概要
図１は本実施形態の提供装置１００の構成例である。提供装置１００は、ブロックチェーンを用いたネットワークとの通信を行う通信部１２０と、通信部１２０を制御する処理部１１０を含む。そして処理部１１０は、管理対象である電子機器についてのサービス提供処理を行うためのサービス提供処理プログラムを、ブロックチェーンに登録するためのトランザクションを生成し、生成したトランザクションを、通信部１２０を介してネットワークに発行する。詳細については図２を用いて後述するが、電子機器３００は直接又は処理装置２００を介して、ブロックチェーンを用いたネットワークに接続される。また、サービス提供処理の詳細についても後述する。以下、ブロックチェーンを用いたネットワークを、ブロックチェーンネットワークＮＷと表記する。なお「ブロックチェーンに登録」とは、具体的にはブロックチェーンのブロックにデータが書き込まれることである。

ブロックチェーンネットワークＮＷにおいては、複数のブロックがチェーン状につながったブロックチェーンと呼ばれるデータ構造が用いられる。トランザクションとは、データをブロックチェーンに登録する処理を行う際に発行される命令である。ブロックチェーンネットワークＮＷの各ノードは、同じ内容のブロックチェーンを保持している。そのため、提供装置１００が発行した処理プログラムを含むトランザクションがブロックチェーンに書き込まれた場合、当該処理プログラムはブロックチェーンネットワークＮＷに参加する全てのノードから参照可能となる。ここでの処理プログラムとは、狭義には発注処理プログラム等のサービス提供処理プログラムであるが、後述するようにサービス提供処理に関連する種々のプログラムを含んでもよい。これにより、サービス提供処理を実現するための各処理プログラムの提供が容易になる。

本実施形態における電子機器３００は、例えばプリンターである。或いは電子機器３００は、スキャナー、ファクシミリ装置又はコピー機であってもよい。電子機器３００は、複数の機能を有する複合機（ＭＦＰ：Multifunction Peripheral）であってもよく、印刷機能を有する複合機もプリンターの一例である。電子機器３００は、プロジェクター、頭部装着型表示装置、ウェアラブル機器、脈拍計や活動量計等の生体情報測定機器、ロボット、カメラ等の映像機器、スマートフォン等の携帯情報端末、又は物理量計測機器等であってもよい。

なお、本実施形態の処理部１１０は、下記のハードウェアにより構成される。ハードウェアは、デジタル信号を処理する回路及びアナログ信号を処理する回路の少なくとも一方を含むことができる。例えば、ハードウェアは、回路基板に実装された１又は複数の回路装置や、１又は複数の回路素子で構成することができる。１又は複数の回路装置は例えばＩＣ等である。１又は複数の回路素子は例えば抵抗、キャパシター等である。

また処理部１１０は、下記のプロセッサーにより実現されてもよい。本実施形態の提供装置１００は、情報を記憶するメモリーと、メモリーに記憶された情報に基づいて動作するプロセッサーと、を含む。情報は、例えばプログラムと各種のデータ等である。プロセッサーは、ハードウェアを含む。プロセッサーは、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）等、各種のプロセッサーを用いることが可能である。メモリーは、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）などの半導体メモリーであってもよいし、レジスターであってもよいし、ハードディスク装置等の磁気記憶装置であってもよいし、光学ディスク装置等の光学式記憶装置であってもよい。例えば、メモリーはコンピューターにより読み取り可能な命令を格納しており、当該命令がプロセッサーにより実行されることで、提供装置１００の各部の機能が処理として実現されることになる。ここでの命令は、プログラムを構成する命令セットの命令でもよいし、プロセッサーのハードウェア回路に対して動作を指示する命令であってもよい。

図２は、本実施形態の提供装置１００と、処理装置２００を含む処理システム１０の構成例である。処理装置２００は、電子機器３００に対応して設けられる装置である。提供装置１００は、スマートコントラクトによってブロックチェーンに処理プログラムを書き込む処理を行う装置であり、図２においては、提供装置１００が２つである例を示している。例えば提供装置１００の一方は後述するプラットフォーム管理者が使用する装置であり、他方はサービス提供者が使用する装置である。ただし、提供装置１００の数はこれに限定されない。また図２は、処理装置２００が２つであり、各処理装置２００に２つの電子機器３００が接続される例を示しているが、処理装置２００の数及び電子機器３００の数はこれに限定されない。処理装置２００は、具体的には後述するサービス利用者が使用する装置である。また、図２では処理装置２００と電子機器３００が異なる機器である例を示したが、電子機器３００が処理装置２００を含んでもよい。即ち、電子機器３００が直接ブロックチェーンネットワークＮＷに参加することは妨げられない。

提供装置１００及び処理装置２００は、ブロックチェーンのクライアントアプリケーションがインストールされる。クライアントアプリケーションは、ブロックチェーンネットワークＮＷに参加するためのソフトウェアである。クライアントアプリケーションは、例えばトランザクションの生成、発行、コンセンサスアルゴリズムの処理、仮想通貨の管理等、ブロックチェーンネットワークＮＷで行われる各種処理を実行するためのソフトウェアである。

また処理装置２００には、電子機器３００を管理するための管理アプリケーションがインストールされる。なお、クライアントアプリケーションと管理アプリケーションは、連携可能な異なるアプリケーションであってもよいし、ブロックチェーンのクライアント機能及び電子機器３００の管理機能の両方を含む１つのアプリケーションとして実現されてもよい。

管理アプリケーションは、電子機器３００に対する処理コマンドの実行処理を行うことによって電子機器３００の制御を行う。電子機器３００の制御を行う処理コマンドは、初期化コマンド、再起動コマンド、設定変更コマンド等、種々のコマンドが考えられる。また、電子機器３００の情報を取得する処理プログラムはブロックチェーンに書き込まれ、クライアントアプリケーションにより実行されることが想定される。電子機器３００の情報を取得する処理プログラムとは、例えば後述する残量収集プログラム、警告状態確認プログラム等である。ただし、管理アプリケーションが処理プログラムに相当するプログラムを保持していてもよい。この場合、管理アプリケーションが当該プログラムを定期的に実行することによって、電子機器３００の情報取得が行われる。

なお本実施形態の手法は、図１に示した提供装置１００に限定されず、図２に示した処理システム１０に適用されてもよい。図２に示したように、本実施形態に係る処理システム１０は、提供装置１００と、電子機器３００に対応して設けられる処理装置２００と、を含む。処理装置２００は、例えば後述する残量収集プログラム、警告状態確認プログラム等、電子機器３００の使用状況データや状態データの取得を行う処理プログラムを実行する。

２．ブロックチェーンとスマートコントラクト
次にブロックチェーン技術について説明する。なお以下で説明する内容はブロックチェーン技術を構成する要素の一部であり、異なる技術要素が追加されてもよい。また、以下で説明する技術要素の一部が省略されてもよい。また、各技術要素を発展させた方式も本実施形態におけるブロックチェーン技術に含まれる。

ブロックチェーンは、オープンなネットワークにおいて、参加者による分散型の合意形成を行う手法である。ブロックチェーンネットワークＮＷは、Ｐ２Ｐネットワークである。そのため、クライアント／サーバー型のシステムとは異なり、特定の機器がデータを一元管理することはない。ブロックチェーンネットワークＮＷでは、ブロックが連結されたブロックチェーンと呼ばれるデータ構造によりデータが管理され、各ノードが共通のブロックチェーンを保持している。

図３は、ブロックチェーンの構造を説明する図である。１つのブロックは、複数のトランザクションのデータと、親ブロックのハッシュ値のデータを含む。親ブロックのハッシュ値とは、具体的には、１つ前のブロックのブロックヘッダーのハッシュ値である。当該ハッシュ値により、ブロック間のつながりが実現される。トランザクションとは、ブロックチェーンへのデータの登録時にノードによって発行される命令である。例えば、仮想通貨を用いた取引を行う場合、送金元のユーザーアドレス、送金先のユーザーアドレス、送金額等の情報を含むトランザクションが生成される。

生成されたトランザクションは、送信者の署名を付してブロードキャストされ、ブロックチェーンネットワークＮＷ上の各ノードに伝搬する。なお、トランザクションの送信は、Ｐ２Ｐネットワークで用いられる種々のデータ伝搬アルゴリズムにより実現可能である。例えば、単純に隣接ノードにトランザクションを送信し、当該隣接ノードから他のノードへの伝搬を繰り返す手法でもよい。或いは、スーパーノードと呼ばれる生存している蓋然性の高い特定のノードを規定し、当該スーパーノードに対してトランザクションが送信されてもよい。スーパーノードを送信先とすることによって、トランザクションがブロックチェーンネットワークＮＷの各ノードに伝搬する蓋然性を高めることが可能になる。

ブロックチェーンへのブロックの追加は、マイナーと呼ばれるノードにより実行される。マイナーは、トランザクションが所定量蓄積されると、当該トランザクションを含むブロックの生成を試みる。ブロックは、コンセンサスアルゴリズムに従って合意形成が行われたと判定されたことを条件に、ブロックチェーンに追加される。

コンセンサスアルゴリズムとしてＰｏＷ（Proof of Work）が用いられる場合、ブロックヘッダーのハッシュ値が、特定の条件を満たす必要がある。特定の条件とは、例えばハッシュ値が所定閾値よりも小さくなるという条件である。ブロックヘッダーは、Ｎｏｎｃｅと呼ばれるフィールドを含み、当該Ｎｏｎｃｅはマイナーにより設定される。換言すれば、マイナーはブロックヘッダーのハッシュ値が特定の条件を満たすようなＮｏｎｃｅを探索する処理を実行する。ハッシュ値を求めるためのハッシュ関数は、入力値から出力値を予測することが困難であるため、マイナーはＮｏｎｃｅを変更しながら総当たりで条件を満たすＮｏｎｃｅを探す必要がある。即ち、ＰｏＷとは、仕事量を根拠として合意を形成する手法である。

マイナーにより新たなブロックが生成されると、当該ブロックは各ノードでの検証を経て、ブロックチェーンネットワークＮＷ内で伝搬する。各ノードでの検証は、ハッシュ値を求め、当該ハッシュ値が特定の条件を満たすかを判定する処理であり、短時間で実行可能である。

なおコンセンサスアルゴリズムはＰｏＷに限定されない。例えば、仮想通貨の保有量に応じて発言権が付与されるＰｏＳ（Proof of Stake）、或いは参加者の重要度に応じて発言権が付与されるＰｏＩ（Proof of Importance）等のコンセンサスアルゴリズムが用いられてもよい。また、固有の署名が付与されている場合は無条件に合意したとみなしてもよい。また、限られたユーザー、端末しかアクセスできないプライベートネットワークを用いる場合、署名に関する判定も除外して、無条件に合意形成したとみなしてもよい。本実施形態におけるコンセンサスアルゴリズムに基づく合意形成とは、無条件に合意形成したとみなす場合を含む。

図４は、ブロックチェーンにデータを書き込む処理を説明するフローチャートである。この処理が開始されると、まずブロックチェーンへのデータ書き込みを希望するノードは、当該データを含むトランザクションを生成し、当該トランザクションをブロックチェーンネットワークＮＷにブロードキャストする（Ｓ１０１）。各ノードへの通知は、ブロードキャストに限るものではなく、Ｐ２Ｐネットワークで用いられる他の手段を用いてもよい点は上述した通りである。

次にデータを受信した各ノードは、データをブロックチェーンに書き込んで良いか判断するため、コンセンサスアルゴリズムに基づく合意形成を行う（Ｓ１０２）。コンセンサスアルゴリズムは、上述した通りＰｏＷ，ＰｏＳ，ＰｏＩ等、種々のアルゴリズムを採用可能である。コンセンサスアルゴリズムで合意が得られるまでの間（Ｓ１０３でＮｏ）、Ｓ１０２の処理が繰り返される。

コンセンサスアルゴリズムで合意が得られた場合（Ｓ１０３でＹｅｓ）、合意を得たノードは、各ノードに合意形成をブロードキャストし（Ｓ１０４）、各ノードは自分が保持するブロックチェーンにデータを書き込む（Ｓ１０５）。以上の処理により、Ｓ１０１でブロードキャストされたデータがブロックチェーンに追加され、各ノードにより利用可能になる。

またブロックチェーンネットワークＮＷにおいては、ノードで実行されるプログラムを、ブロックチェーンに追加することが可能である。このプログラムは、ステート及び関数を含み、ノード内の実行環境により実行される。ステートは変数の集合と言い換えてもよく、関数はサブルーチン、メソッド等と言い換えてもよい。ノード内の実行環境とは、例えば仮想マシンである。このような、ブロックチェーンにプログラムを追加してノードにおいてプログラムを実行する仕組みは、スマートコントラクトと呼ばれる。

スマートコントラクトによるブロックチェーンへのプログラムの書き込みについても、図４を用いて上述した流れに従って実行される。即ち、スマートコントラクトの書き込みを希望するノードは、書き込み対象であるプログラムを含むトランザクションの生成、ブロードキャストを行う。当該トランザクションがコンセンサスアルゴリズムにより合意された場合に、スマートコントラクトによりプログラムがブロックチェーンに書き込まれる。

本実施形態に係る提供装置１００の処理部１１０は、サービス提供処理プログラムを、スマートコントラクトを用いてブロックチェーンに登録するためのトランザクションを生成する。このように、サービス提供処理プログラムを、スマートコントラクトを用いてブロックチェーンに書き込むことによって、当該サービス提供処理プログラムをブロックチェーンネットワークＮＷの任意のノードで実行することが可能になる。

特に、ブロックチェーン技術においては、所与のスマートコントラクトのプログラムから他のスマートコントラクトのプログラムを呼び出すことが可能である。即ち、ブロックチェーンに書き込まれたサービス提供処理プログラム等をスマートコントラクトによって実行することによって、処理プログラム間の連携を容易に実現することが可能になる。具体的な連携については後述する。

３．プラットフォーム管理者、サービス提供者、サービス利用者
本実施形態の手法においては、ブロックチェーンネットワークＮＷを利用したサービス提供プラットフォームを用いて、種々のサービスが提供される。サービス提供プラットフォームの参加者としては、プラットフォーム管理者、サービス提供者、サービス利用者が想定される。

プラットフォーム管理者とは、サービス提供プラットフォームの提供及び管理を行う事業者である。サービス提供者とは、サービス提供プラットフォームを利用してサービスを提供する事業者である。サービス利用者とは、サービス提供プラットフォームにおいて提供されているサービスを利用するユーザーであり、個人であってもよいし、企業等の団体であってもよい。なおここでのサービスは電子機器３００に関するサービスであるため、サービス利用者とは、電子機器３００を使用するユーザーである。

プラットフォーム管理者は、サービス提供者情報と、当該サービス提供者が提供するサービス内容情報を対応づけて記憶することによって、サービス提供者の管理を行う。サービス提供者情報とは、例えばサービス提供者の名称、所在地、責任者、登録年月日等の情報である。サービス提供者情報には、後述するデジタルＩＤが含まれてもよい。サービス内容情報は、例えば後述する消耗品配送、修理請負等、サービスの内容を特定可能な情報である。以下、サービス提供者情報と、サービス内容情報を合わせてサービス登録必須情報と表記する。

プラットフォーム管理者は、サービス提供者と契約を締結し、契約内容に基づいて、サービス登録必須情報の登録処理を行う。なお、プラットフォーム管理者は、サービス提供者を兼ねてもよい。この場合、プラットフォーム管理者が提供するサービスについては、登録処理を省略してもよい。或いは、契約が締結されたものと見なして、サービス登録必須情報の登録処理が実行されてもよい。例えば、プラットフォーム管理者は、サービス利用者に電子機器３００を貸与し、当該電子機器３００の使用状況に応じた課金処理を行うサービスを提供してもよい。ここでの電子機器３００の使用状況とは、例えばインクやトナーの使用量、印刷枚数、スキャン枚数、機器の使用時間等である。

図５は、具体的な登録処理を説明するフローチャートである。プラットフォーム管理者が使用する管理システムは、まずサービス登録必須情報を取得する（Ｓ２０１）。なお、サービスの提供には、種々の処理プログラムを適切なタイミングにおいて実行する必要がある。よってＳ２０１において、管理システムは、使用する処理プログラムを特定するためのスマートコントラクト情報、及び当該処理プログラムの実行タイミング情報を取得してもよい。

次に管理システムは、サービス登録必須情報に第三者機関が発行したデジタルＩＤが含まれているか否かを判定する（Ｓ２０２）。デジタルＩＤとはコンピューター上で管理される識別情報である。第三者機関とは、プラットフォーム管理者及びサービス提供者のいずれとも異なる機関であり、デジタルＩＤの発行及び認証を行う機関である。第三者機関が発行したデジタルＩＤは、ブロックチェーンを利用したデジタルＩＤであってもよいし、ブロックチェーンを利用しないデジタルＩＤであってもよい。また、ここでのデジタルＩＤは、証明書発行機関により発行された証明書であってもよい。

サービス登録必須情報にデジタルＩＤが含まれる場合（Ｓ２０２でＹｅｓ）、管理システムは第三者機関にＩＤの問い合わせを行い（Ｓ２０３）、当該デジタルＩＤが正当なＩＤであるか否かを判定する（Ｓ２０４）。デジタルＩＤが正当なＩＤである場合（Ｓ２０４でＹｅｓ）、管理システムは、Ｓ２０１において取得したサービス登録必須情報を含む情報をブロックチェーンに書き込む処理を行う（Ｓ２０５）。Ｓ２０５における処理は、具体的には、プラットフォーム管理者の提供装置１００に含まれるクライアントアプリケーションが、後述する契約管理コントラクトを呼び出すことによって実行される。契約管理コントラクトには、サービス登録必須情報をブロックチェーンに書き込むための処理が記述されている。契約管理コントラクトは、ブロックチェーンに書き込まれる種々の情報のうち、自身が書き込み処理を行った情報を参照することによって、適切にサービス提供者との契約を管理することが可能になる。一方、デジタルＩＤが正当なＩＤでない場合（Ｓ２０４でＮｏ）、管理システムは登録を却下する（Ｓ２０６）。具体的には、管理システムはサービス登録必須情報等の書き込みを行わずに処理を終了する。

また、サービス登録必須情報にデジタルＩＤが含まれない場合（Ｓ２０２でＮｏ）、管理システムは処理対象となっているサービス提供者にユニークなＩＤを発行する（Ｓ２０７）。そして管理システムは、Ｓ２０１において取得したサービス登録必須情報を含む情報をブロックチェーンに書き込む処理を行う（Ｓ２０５）。

図５に示した処理を行うことによって、第三者機関によるデジタルＩＤが正当でないサービス提供者を排除すること、ブロックチェーンを用いてサービス提供者との契約を管理すること、登録が完了したサービス提供者とデジタルＩＤとを対応づけることが可能になる。なおデジタルＩＤは、サービス利用時に、利用対象であるサービスが正規サービスとして登録済みであるか否かを確認するために用いられてもよい。当該確認は、例えば契約管理コントラクトによって実行される。詳細については後述する。また、正規サービスかを確認しない実施形態の場合、デジタルＩＤに関する処理を省略してもよい。例えば、図５において、Ｓ２０２～Ｓ２０４、Ｓ２０６、Ｓ２０７の処理が省略される。

なおＳ２０５の処理において、契約管理コントラクトを呼び出すことによって、サービス登録必須情報のブロックチェーンへの書き込みを実行することを考慮すれば、ここでの管理システムは、プラットフォーム管理者が使用する提供装置１００によって実現されることが望ましい。ただし、管理システムは、提供装置１００とは異なる装置によって実現されてもよいし、提供装置１００と他の装置が連携することによって実現されてもよい。

図５に示した処理は、例えばサービス提供プラットフォーム外において契約が締結される場合に適している。その場合、プラットフォーム管理者は、契約を締結するまでの段階、或いは契約の締結後であって図５に示す登録処理を開始するまでの段階において、サービス提供者の信頼性について判定する機会がある。登録処理を実行するか否かをプラットフォーム管理者側でコントロールできるため、第三者機関が発行するデジタルＩＤを有さない場合にサービス提供者の登録を行っても問題になりにくい。具体的には、Ｓ２０２でＮｏと判定された場合であっても、Ｓ２０５の処理を実行可能である。

ただし、スマートコントラクトを用いて、サービス提供者の登録を自動化することも妨げられない。例えば契約管理コントラクトは、サービス登録必須情報の取得、及び登録処理を実行する関数を含み、当該関数をＡＰＩ（Application Programming Interface）として提供する。サービス提供者は、当該ＡＰＩを用いてサービス登録必須情報を入力することによって、自身の登録を試行する。

図６は、この場合の登録処理を説明するフローチャートであり、契約管理コントラクトによって実行される処理を説明するフローチャートである。この処理が開始されると、契約管理コントラクトを実行した提供装置１００は、サービス提供者からの登録要求を受け付ける（Ｓ３０１）。具体的には、サービス登録必須情報、スマートコントラクト情報、実行タイミング情報等の入力を受け付ける。

この場合、サービス提供者側から登録要求が実行されるため、登録処理前にプラットフォーム管理者側でサービス提供者を選別できない。換言すれば、信頼できないサービス提供者がサービス提供プラットフォームに入り込むおそれがある。よってここでは、サービス登録必須情報が第三者機関によるデジタルＩＤを含むことを、登録における必須条件とする。即ち契約管理コントラクトは、Ｓ３０１において第三者機関によって発行されたデジタルＩＤが入力されることを、Ｓ３０２以降の処理に移行する条件とする。

そして提供装置１００は、第三者機関にＩＤの問い合わせを行い（Ｓ３０２）、当該デジタルＩＤが正当なＩＤであるか否かを判定する（Ｓ３０３）。デジタルＩＤが正当なＩＤである場合（Ｓ３０３でＹｅｓ）、提供装置１００は、サービス登録必須情報を含む情報をブロックチェーンに書き込む処理を行う（Ｓ３０４）。デジタルＩＤが正当なＩＤでない場合（Ｓ３０３でＮｏ）、提供装置１００は登録を却下する（Ｓ３０５）。

図６に示した処理を行うことによって、プラットフォーム管理者とサービス提供者の間の契約締結、及びサービス提供者の登録処理を自動化できる。そのため、プラットフォーム管理者とサービス提供者双方の負担軽減が可能である。その際、第三者機関が発行するデジタルＩＤを用いることによって、不適切なサービス提供者が登録されることを抑制可能である。

このように、プラットフォーム管理者が使用する提供装置１００の処理部１１０は、電子機器３００に関するサービスを提供するサービス提供者を管理するための管理プログラムを、ブロックチェーンに登録するための第１トランザクションを生成し、生成した第１トランザクションを、通信部１２０を介してネットワークに発行する。また管理プログラムは、サービス提供者を識別するサービス提供者情報と、サービス提供者によるサービスを提供するためのサービス提供処理プログラムとを対応付けた情報を、ブロックチェーンに登録するための第２トランザクションを生成し、生成した第２トランザクションを、通信部１２０を介してネットワークに発行する。

このようにすれば、プラットフォーム管理者がブロックチェーンネットワークＮＷを用いて管理プログラムを提供すること、及び当該管理プログラムが必要な情報をブロックチェーンに書き込むことが可能になる。即ち、ブロックチェーンを用いたサービス提供プラットフォームに、種々のサービス提供者を参加させることが可能になる。また、サービス提供者をブロックチェーン上で適切に管理することも可能になる。

ここで、サービス提供者情報は、サービス提供者を特定可能な情報であればよく、上述した情報の全てを含む必要はない。また、サービス提供者情報は、デジタルＩＤであってもよい。デジタルＩＤは、第三者機関が発行するＩＤであってもよいし、管理システムが発行するＩＤであってもよい。また、管理プログラムとは、例えば上述した契約管理コントラクトである。ただし、詳細については後述するが、契約管理コントラクトはサービス提供者とサービス利用者との間の契約を管理するプログラムである。当該契約管理コントラクトがサービス提供者の管理を行ってもよいし、サービス提供者を管理する管理プログラムが、契約管理コントラクトとは別のプログラムとして実現されてもよい。なお、管理プログラムは、ブロックチェーンへの書き込み処理（Ｓ２０５又はＳ３０４）を行えばよく、デジタルＩＤの問い合わせ等を行ってもよいし、行わなくてもよい。

以上で説明した処理によって、サービス提供プラットフォームにおけるサービス提供者の登録処理が実行される。サービス利用者は、サービス提供プラットフォームを用いて登録済みのサービスを検索する。具体的には、プラットフォーム管理者は、サービス登録必須情報を用いて、サービス利用者が必要なサービスを見つけるための手段を提供する。

例えばプラットフォーム管理者は、サービスを見つけるための手段として検索システムを提供する。サービス利用者は、検索システムにおいて、サービス提供者の名称、サービス内容、サービス提供地域等、自身が利用したいサービスに関連する任意の情報を入力する。ここで入力される情報は、例えばテキスト情報である。検索システムは、入力された情報に関連するサービスを提示する。

或いは、プラットフォーム管理者は、サービスを見つけるための手段としてフィルタリングシステムを提供する。サービス利用者は、フィルタリングシステムにおいて、フィルタリング条件を入力する。フィルタリングシステムは、登録済みのサービスに対して入力された条件に従ったフィルタリング処理を行い、処理結果をサービス利用者に提供する。フィルタリング条件は、サービスのジャンル、サービス毎の評判情報、評価順、サービス毎の受注回数等、種々の条件を設定可能である。また、ブロックチェーンへの貢献度が高いサービス提供者は信頼できると推定することも可能である。よってフィルタリングシステムは、ブロックチェーンにおけるマイニング量に基づくフィルタリングを行ってもよい。

或いは、プラットフォーム管理者は、サービスを見つけるための手段としてディレクトリーサービスを提供してもよい。より具体的には、プラットフォーム管理者は、登録済みのサービスを選択するためのポータルを提供してもよい。ディレクトリーサービスは、登録済みのサービスをツリー構造等の特定のデータ構造によって管理する。サービス利用者は、ポータルを起点とすることによって、目的のサービスに到達可能である。ディレクトリーサービスについては広く知られているため、詳細な説明は省略する。

サービス利用者は、上記種々の手段を用いて利用を希望するサービスを選択する。そして、サービス利用者は当該サービスを利用するために必要な情報を入力することによって、サービス提供者との間で当該サービスに関する契約を締結する。契約内容はブロックチェーンに書き込まれる。当該契約内容は、契約管理コントラクトによって管理される。具体的な契約内容は、サービスに応じて異なるため、詳細については後述する。なお、以下では消耗品配送サービス及び修理請負サービスについて詳細に説明するが、サービス提供者の登録、及びサービス利用者によるサービスの探索については、上記の流れに従って完了しているものとして説明を行う。

４．サービスの具体例
本実施形態にかかる提供装置１００の処理部１１０は、管理対象である電子機器３００についてのサービス提供処理を行うためのサービス提供処理プログラムを、ブロックチェーンに登録するためのトランザクションを生成し、生成したトランザクションを、通信部１２０を介してブロックチェーンネットワークＮＷに発行する。サービス提供処理プログラムは、ブロックチェーンに記憶されたサービス提供者情報により表されるサービス提供者に、サービスを依頼する処理を行う。このようにすれば、適切なサービス提供者に対してサービスを依頼することが可能になる。サービス提供者情報は、例えば上述したように、契約管理コントラクトによってブロックチェーンに書き込む処理が行われる。

以下、サービスの具体例として、消耗品配送サービスと修理請負サービスについて説明する。消耗品配送サービスにおけるサービス提供処理プログラムとは、消耗品の残量収集プログラム、残量計算プログラム、警告状態確認プログラム、発注プログラムに対応する。修理請負サービスにおけるサービス提供処理プログラムとは、状態確認プログラム、修理手配プログラムに対応する。

またサービス提供処理プログラムは、サービス提供により発生する費用を含むサービス提供データを、ブロックチェーンに書き込む処理を行う。また提供装置１００の処理部１１０は、ブロックチェーンに書き込まれたサービス提供データに基づいて、課金額を決定する課金処理プログラムをブロックチェーンに登録するためのトランザクションを生成する。このようにすれば、サービス提供に伴う課金処理が可能になる。消耗品配送サービスにおいて発生する費用とは、消耗品自体の費用、及び送料等である。修理請負サービスにおいて発生する費用とは、出張料、技術料、部品代等である。

４．１ 消耗品配送サービス
消耗品配送サービスについて説明する。まず、消耗品配送サービスで用いられるスマートコントラクトの具体例を説明し、その後、フローチャートを用いて処理の流れを説明する。

４．１．１ スマートコントラクト
＜契約管理コントラクト＞
提供装置１００の処理部１１０は、サービス提供処理の内容を決定するための契約内容情報、及び、サービス提供者情報を管理する契約管理プログラムを、ブロックチェーンに登録するためのトランザクションを生成する。スマートコントラクトを用いてブロックチェーンに書き込まれる契約管理プログラムを、契約管理コントラクトと表記する。

このようにすれば、ブロックチェーン上で動作するプログラムである契約管理コントラクトを用いて、サービス提供者及び当該サービス提供者によって提供されるサービスの内容を管理することが可能になる。換言すれば、契約管理コントラクトは、プラットフォーム管理者とサービス提供者の間の契約、及び、サービス提供者とサービス利用者の間の契約を管理する。

プラットフォーム管理者とサービス提供者の間の契約は、上述したようにサービス登録必須情報の登録処理に基づいて管理される。例えば、契約管理コントラクトは、サービス登録必須情報のブロックチェーンへの書き込み機能を有し、自身が書き込みを行ったサービス登録必須情報に基づくサービスを登録済みの正規サービスと判定する。換言すれば、契約管理コントラクトを介さずにサービス登録必須情報がブロックチェーンに書き込まれたとしても、当該サービス登録必須情報に対応するサービスは正規サービスと判定されない。このようにすれば、不適切なサービス提供者によるサービス提供を抑制できる。

また契約管理コントラクトは、消耗品の発注処理の内容を決定するための契約アカウント情報を管理する。契約アカウント情報は、サービス利用者を特定する情報と、契約内容を表す情報を含む。このようにすれば、サービス提供者とサービス利用者との間の契約内容に基づく発注処理を、ブロックチェーンを用いて共有されるプログラムに基づいて実行することが可能になる。

契約アカウント情報は、契約ＩＤ、契約者情報、契約内容情報、サービス提供対象となる電子機器３００を特定する情報等を含む。

契約ＩＤとは、当該契約を一意に特定する情報である。契約者情報とは、契約者であるサービス利用者の名称やＩＤの情報である。なお、所与の契約者が複数のサービス利用契約を結ぶことは妨げられない。電子機器３００を特定する情報とは、消耗品配送の対象となる電子機器３００を特定する情報であり、電子機器３００のシリアル番号やＭＡＣアドレス等の種々の情報を利用可能である。

消耗品配送サービスにおける契約内容情報とは、契約タイプ、締め日、配送先、配送方法、請求方法等を含む情報である。また、消耗品の発注先が契約によって決定される場合、契約内容情報は発注先を表す情報を含んでもよい。

契約タイプは、例えば印刷媒体の自動配送、インクの自動配送、トナーの自動配送等、どのような配送サービスを行うかを表す情報である。なお契約タイプは、Ａ４用紙、ロール紙、布等の印刷媒体のサイズ、種類を特定する情報を含んでもよい。締め日は、自動的に配送された消耗品についての課金処理を実行するタイミングを表す情報である。配送先は、消耗品の配送先を表す住所等の情報である。配送方法は、配送業者や配送時間等を特定する情報である。請求方法は、消耗品の代金をサービス利用者に請求する際の、請求書の宛先、請求書の送付方法を特定する情報である。

なお消耗品の値段は固定であってもよいし、サービス利用者ごとに可変であってもよい。消耗品の値段が可変である場合、契約内容情報は単価、割引情報を含む。単価とは、単位数量当たりの課金額の情報であり、例えば所与の用紙サイズ１枚あたり何円という情報、或いはインク１ミリリットルあたり何円という情報である。割引情報とは、例えば１回の発注量が所定枚数以上、或いは所定インク量以上の場合に課金額を何％減額するという割引率の情報である。

また、契約管理コントラクトは、契約アカウント情報とサービス登録必須情報に加えて、サービス提供時に必要な処理プログラムを特定するスマートコントラクト情報を対応づけて管理する。消耗品配送サービスにおいては、後述する残量収集コントラクト、警告状態確認コントラクト、発注コントラクトを実行することによって消耗品の配送手配が行われる。契約管理コントラクトは、これらのうち、少なくとも自身が呼び出す必要がある残量収集コントラクト、警告状態確認コントラクトを表す情報を、スマートコントラクト情報として管理する。また、消耗品配送サービスにおいては、後述する課金コントラクト、請求コントラクトを実行することによって配送した消耗品に関する課金、請求処理が行われる。契約管理コントラクトは、これらのうち、少なくとも自身が呼び出す必要がある課金コントラクトを表す情報を、スマートコントラクト情報として管理する。

また、契約管理コントラクトは、上記スマートコントラクト情報によって表される処理プログラムを実行するタイミングを表す実行タイミング情報を管理する。消耗品配送サービスにおいては、契約管理コントラクトは、残量収集コントラクト、警告状態確認コントラクトの実行タイミングを表す情報を管理する。なお、処理プログラムによっては実行タイミングが契約によって決定されるものもある。例えば課金コントラクトの実行タイミングはサービス利用者に応じて異なり、契約内容情報の「締め日」によって特定される。

以上で説明したように、契約管理コントラクトは、契約アカウント情報、サービス登録必須情報、スマートコントラクト情報、実行タイミング情報を対応づけて管理する。契約アカウント情報とサービス登録必須情報と対応づけて管理することによって、サービス提供者とサービス利用者の間の契約を適切に管理可能である。また、スマートコントラクト情報と実行タイミング情報も対応づけられるため、サービスを実現するためには、どの処理プログラムをどのタイミングにおいて実行すればよいかを特定することも可能である。

契約管理コントラクトは、定期的に実行され、あらかじめ指定した条件に応じて、スマートコントラクトによりブロックチェーンに書き込まれた他のプログラムを実行する。契約管理コントラクト自体が定期実行機能を持ってもよい。或いは、契約管理コントラクトは、定期的に外部から起動され、必要なタスクがある場合にブロックチェーンに書き込まれた他のプログラムを起動してもよい。

契約管理コントラクトは、残量計算コントラクト、警告状態確認コントラクトを定期的に起動することによって、消耗品の発注処理を行う。また契約管理コントラクトは、課金コントラクトを締め日に対応するタイミングにおいて起動することによって、消耗品の発注に伴う課金処理を行う。

＜残量収集コントラクト＞
提供装置１００の処理部１１０は、電子機器３００の消耗品の使用状況データを収集する残量収集プログラムを、ブロックチェーンに登録するためのトランザクションを生成する。残量収集プログラムは、契約管理プログラムによって所与のスケジュールに従って起動されるプログラムである。スマートコントラクトを用いてブロックチェーンに書き込まれる残量収集プログラムを、残量収集コントラクトと表記する。このようにすれば、消耗品の使用状況データの収集を、ブロックチェーンを用いて共有されるプログラムに基づいて実行することが可能になる。

ここでの使用状況データとは、消耗品の残量特定に用いられるデータであり、例えばインク残量やトナー残量である。また、使用状況データは、印刷媒体の消費量を含む。印刷媒体の消費量は、印刷枚数であってもよいし、ロール紙における印刷長であってもよい。印刷媒体の消費量に基づいて、当該印刷媒体の残量の演算が可能である。

使用状況データの取得は、例えば、ＳＮＭＰ（Simple Network Management Protocol）に則って実行される。この場合、残量収集コントラクトを実行する処理装置２００が通信のマネージャー、各電子機器３００が通信のエージェントとなる。処理装置２００は、収集プログラムを実行することによりＳＮＭＰに則った通信を行い、電子機器３００からＭＩＢ（Management Information Base）情報を受信する。

また残量収集コントラクトは、取得した使用状況データをブロックチェーンに登録する処理を行う。具体的には、使用状況データを含むトランザクションを生成し、当該トランザクションをブロックチェーンに登録するための発行処理を行う。コンセンサスアルゴリズムに基づいて合意形成されると、当該トランザクションを含むブロックがブロックチェーンに追加され、使用状況データが各ノードから参照可能になる。

契約管理コントラクトは、契約ＩＤ及び収集対象となる電子機器３００を特定する情報を指定して残量収集コントラクトを起動する。残量収集コントラクトは、指定された電子機器３００の使用状況データを取得する。上述したように、契約管理コントラクトは、他のコントラクトの実行タイミングを規定する実行タイミング情報を管理する。契約管理コントラクトが実行タイミング情報に従って残量収集コントラクトを起動することによって、サービス提供者の決定した適切なタイミングで使用状況データの収集が可能になる。具体的な起動タイミングは種々の変形実施が可能であるが、収集コントラクトは、３０分に１回、１時間に１回等のある程度高い頻度で起動される。このようにすれば、消耗品切れを出来る限り遅延なく検出することが可能になる。

また使用状況データの収集タイミングは、サービス提供者とサービス利用者の間の契約によって決定されてもよい。その場合、契約内容情報は残量収集ルールを含む。契約管理コントラクトが残量収集ルールに従って残量収集コントラクトを起動することによって、契約内容に即した適切なタイミングにおいて使用状況データの収集が可能になる。

＜残量計算コントラクト＞
提供装置１００の処理部１１０は、消耗品の使用状況データに基づいて残量計算を行う残量計算プログラムを、ブロックチェーンに登録するためのトランザクションを生成する。残量計算プログラムは、残量収集プログラムによって起動されるプログラムである。なお、消耗品切れを出来る限り遅延なく検出することを考慮すれば、残量計算プログラムは、残量収集の終了時に、毎回起動されることが望ましい。スマートコントラクトを用いてブロックチェーンに書き込まれる残量計算プログラムを、残量計算コントラクトと表記する。このようにすれば、残量収集コントラクトによって収集された使用状況データに基づく計算処理を、ブロックチェーンを用いて共有されるプログラムに基づいて実行することが可能になる。

残量計算コントラクトは、残量収集コントラクトから、契約ＩＤ、電子機器３００を特定する情報を受け取り、ブロックチェーンに保存されている使用状況データに基づいて、各契約の消耗品の残量を計算する。残量計算コントラクトは、各電子機器３００から収集したインク残量の値をインク残量とする。トナー残量についても同様である。また残量計算コントラクトは、用紙サイズごとに、前回残量から今回収集した印刷量の増加分を減じることによって印刷媒体の残量を算出する。

残量計算コントラクトは、求められたインク残量、トナー残量、印刷媒体残量等に基づいて、残量不足となっているか否かを判定する。なお、残量計算コントラクトは、契約において消耗品配送サービスの対象となっている消耗品を対象として処理を行い、他の種類の消耗品については処理を省略可能である。例えば残量計算コントラクトは、インク、トナー、印刷媒体について、それぞれ残量不足と判定する閾値を事前に設定しておき、求められた残量が当該閾値を下回った場合に、残量不足であると判定する。

残量計算コントラクトは、残量不足であると判定された場合、契約ＩＤ、残量不足と判定された消耗品種別をパラメーターとして、発注コントラクトを起動する。

なお、上述したように電子機器３００から収集可能であるのは、印刷媒体の消費量である。印刷媒体の残量を正しく計算するためには、初期値を正しく記録していること、配送分は加算すること、本サービス提供プラットフォーム以外では印刷媒体を購入しないこと、等が必要となる。或いは、本サービス提供プラットフォーム以外で印刷媒体を購入した場合、購入量をユーザーが入力可能にしてもよい。入力は、例えば電子機器３００又は処理装置２００において行われ、入力された情報は契約ＩＤ、電子機器３００を特定する情報、消耗品種別等と対応づけてブロックチェーンに書き込まれる。

＜警告状態確認コントラクト＞
提供装置１００の処理部１１０は、消耗品の不足に基づく警告状態となっているか否かを確認する警告状態確認プログラムを、ブロックチェーンに登録するためのトランザクションを生成する。警告状態確認プログラムは、契約管理プログラムによって所与のスケジュールに従って起動される。スマートコントラクトを用いてブロックチェーンに書き込まれる警告状態確認プログラムを、警告状態確認コントラクトと表記する。このようにすれば、消耗品の不足に基づく警告状態の確認処理を、ブロックチェーンを用いて共有されるプログラムに基づいて実行することが可能になる。

警告状態確認コントラクトは、電子機器３００の状態データを取得する。状態データは、少なくとも消耗品不足に起因するエラー状態であるか否かを識別可能な情報である。また、ここでの状態データが、他の状態を識別可能な情報であってもよい。他の状態とは、正常動作状態、アイドル状態、消耗品不足以外のエラー状態を含み、消耗品不足以外のエラー状態とは、例えば紙詰まりや部品故障等が発生した状態である。状態データの取得は、例えば、使用状況データの収集と同様に、ＳＮＭＰに則って実行される。

警告状態確認コントラクトは、電子機器３００が消耗品不足の警告状態であると判定された場合、契約ＩＤ、不足消耗品種別をパラメーターとして、発注コントラクトを起動する。

なお、ここでの消耗品不足に起因する警告状態は、プリンターのインク切れが相当する。印刷用紙等の印刷媒体切れに関しても検出可能だが、在庫を含めた用紙切れではない可能性もあるため、消耗品を配送すべきか判断できない。また、印刷媒体の不足については残量計算コントラクトにおいて検出可能である。よって警告状態確認コントラクトは、用紙切れ警告は対象外とする。

契約管理コントラクトは、契約ＩＤ及び収集対象となる電子機器３００を特定する情報を指定して警告状態確認コントラクトを起動する。警告状態確認コントラクトは、指定された電子機器３００の状態データを取得する。契約管理コントラクトが実行タイミング情報に従って残量収集コントラクトを起動することによって、サービス提供者の決定した適切なタイミングで使用状況データの収集が可能になる。具体的な起動タイミングは種々の変形実施が可能であるが、警告状態確認コントラクトは、収集コントラクトと同様に、３０分に１回、１時間に１回等のある程度高い頻度で起動される。このようにすれば、消耗品切れを出来る限り遅延なく検出することが可能になる。或いは契約管理コントラクトは、対象の全ての電子機器３００の警告状態確認が完了後、あらかじめ指定された警告状態確認インターバル経過したら、次の警告状態確認を行うようにしてもよい。ここでの警告状態確認インターバルは、例えば１分間である。

また状態データの収集タイミングについても、サービス提供者とサービス利用者の間の契約によって決定されてもよい。その場合、契約内容情報は警告状態確認ルールを含む。契約管理コントラクトが警告状態確認ルールに従って警告状態確認コントラクトを起動することによって、契約内容に即した適切なタイミングで警告状態の確認が可能になる。

＜発注コントラクト＞
提供装置１００の処理部１１０は、管理対象である電子機器３００の消耗品の発注処理を行うための発注処理プログラムを、ブロックチェーンに登録するためのトランザクションを生成する。発注処理プログラムは、残量計算プログラムによって起動される。または発注処理プログラムは、警告状態確認プログラムによって起動される。スマートコントラクトを用いてブロックチェーンに書き込まれる発注処理プログラムを、発注コントラクトと表記する。このようにすれば、消耗品の発注処理を、ブロックチェーンを用いて共有されるプログラムに基づいて実行することが可能になる。

残量計算コントラクト又は警告状態確認コントラクトは、契約ＩＤ、不足消耗品種別をパラメーターとして、発注コントラクトを起動する。発注コントラクトは、契約ＩＤに基づいて、契約管理コントラクトから配送先、配送方法等を取得する。契約管理コントラクトは、不足消耗品種別に対応する消耗品を、配送方法に従った方法によって配送先へ配送する処理を行う。実際の配送処理についてはブロックチェーン外で行われることであるため詳細な説明は省略する。また発注コントラクトは、発注分の費用を含む発注データをブロックチェーンに保存する。

なお、発注コントラクトは、発注先情報により表される発注先に、消耗品を発注する処理を行う。例えば、サービス提供者が消耗品の販売業者である場合、発注先情報により表される発注先はサービス提供者となる。例えば発注先情報は発注コントラクトによって管理される。より具体的には、発注コントラクトは、サービス提供者を発注先とする発注処理を実行する処理プログラムとして実現される。

ただし、サービス提供者が、当該サービス提供者以外の消耗品販売業者に消耗品の発注を行うことは妨げられない。例えば、いずれの発注先に発注を行うかが、サービス提供者とサービス利用者の間の契約において決定されてもよい。この場合、発注先情報は、契約管理プログラムによって管理される。

以上のように、発注先は種々の変形実施が考えられる。例えば、発注先情報は、電子機器３００の販売元（すなわち、電子機器３００を販売した業者）を表す情報であってもよい。この場合、サービス利用者からすれば、電子機器３００の販売元と、消耗品の発注先（すなわち、消耗品の発注を受けて、消耗品配送サービスを提供する業者）が同じになるため、電子機器３００に関する問い合わせ等の負担が軽減される。

＜課金コントラクト＞
上述したように、発注処理プログラムは、発注により発生する費用を含む発注データを、ブロックチェーンに書き込む処理を行う。提供装置１００の処理部１１０は、ブロックチェーンに書き込まれた発注データに基づいて、課金額を決定する課金処理プログラムをブロックチェーンに登録するためのトランザクションを生成する。課金処理プログラムは、契約管理プログラムによって起動されるプログラムである。スマートコントラクトを用いてブロックチェーンに書き込まれる課金処理プログラムを、課金コントラクトと表記する。このようにすれば、消耗品の発注に伴う課金処理を、ブロックチェーンを用いて共有されるプログラムに基づいて実行することが可能になる。

上述したように、契約管理コントラクトは締め日の情報を保持する。締め日とは課金処理の基準となる日を表す情報であり、例えば毎月末日等の情報である。ただし締め日の設定は１ヶ月に１回に限定されず、２ヶ月に１回等の異なる周期であってもよい。契約管理コントラクトが課金コントラクトを起動することによって、適切なタイミングで課金処理を実行することが可能になる。

課金コントラクトは、契約アカウントごとに、課金額を決定する。契約管理コントラクトは、契約ＩＤ、締め日をパラメーターとして、課金コントラクトを起動する。課金コントラクトは、契約ＩＤごとに、ブロックチェーンに保存された発注データのうち、前回の締め日以降、今回の締め日までの発注金額を取得、累計することによって課金額を決定する。

＜請求コントラクト＞
提供装置１００の処理部１１０は、課金処理プログラムによって決定された課金額を、対応する契約アカウントに対して請求する請求プログラムをブロックチェーンに登録するためのトランザクションを生成する。請求プログラムは、課金処理プログラムによって起動されるプログラムである。スマートコントラクトを用いてブロックチェーンに書き込まれる請求プログラムを、請求コントラクトと表記する。このようにすれば、課金コントラクトによって決定された課金額の請求を、ブロックチェーンを用いて共有されるプログラムに基づいて実行することが可能になる。

課金コントラクトは、契約ＩＤ及び課金額をパラメーターとして、請求コントラクトを起動する。請求コントラクトは、取得した契約ＩＤに基づいて契約管理コントラクトに問い合わせを行い、当該契約ＩＤに対応する請求方法を取得する。請求方法とは、請求の宛先、請求の送付方法であり、送付方法とは郵便や電子メール等である。請求コントラクトは、取得した請求方法に従って、請求書を送付する。このようにすれば、サービス利用者に対応する適切な契約アカウントに対して、請求を行うことが可能になる。なお、仮想通貨を使用して決済を行う場合、請求書の送付とは、ブロックチェーン上での支払い要求である。

＜決済コントラクト＞
また処理装置２００は、請求プログラムによる請求に対する決済を行う決済プログラムをブロックチェーンに登録するためのトランザクションを生成する。決済プログラムは、ブロックチェーンにおける仮想通貨を用いて決済を行うプログラムである。また決済プログラムは、請求プログラムによって起動されるプログラムである。スマートコントラクトを用いてブロックチェーンに書き込まれる決済プログラムを、決済コントラクトと表記する。このようにすれば、請求コントラクトによる請求に対する決済を、ブロックチェーンを用いて共有されるプログラムに基づいて実行することが可能になる。

決済コントラクトは、仮想通貨による支払いを行うコントラクトのため、サービス利用者ごとに、当該サービス利用者がブロックチェーンに登録する必要がある。よって処理装置２００において、決済コントラクトの生成、及びブロックチェーンに登録するための処理が行われる。なお、ブロックチェーン技術においては、プログラムを生成するプログラムを、スマートコントラクトによりブロックチェーンに書き込むことも許容される。例えば提供装置１００は、決済コントラクト生成用のプログラムをスマートコントラクトにより提供し、処理装置２００は当該プログラムを実行することによって、自身の決済用の決済コントラクトを生成してもよい。決済コントラクトは、例えば仮想通貨の送金元として、サービス利用者のアドレスを保持するプログラムである。

請求コントラクトは、請求書をパラメーターとして決済コントラクトを起動する。請求書とは、送金先のアドレスと、送金額を指定する情報である。決済コントラクトは、保持しているサービス利用者のアドレスから、請求書に指定された仮想通貨のアドレス宛に、請求された額の仮想通貨を支払う処理を行う。

４．１．２ ブロックチェーンの具体例
以上のように、本実施形態の提供装置１００は、スマートコントラクトを用いて各処理プログラムをブロックチェーンに書き込む処理を行う。具体的には、提供装置１００の処理部１１０は、各処理プログラムをブロックチェーンのブロックに登録するためのトランザクションを生成する処理を行う。生成されたトランザクションはブロックチェーンネットワークＮＷにブロードキャストされる。

契約管理コントラクトは、サービス利用者及びサービス提供者を管理するための処理プログラムである。そのため、契約管理コントラクトは、プラットフォーム管理者の提供装置１００においてブロックチェーンに書き込む処理が行われる。残量収集、残量計算、警告状態確認、課金、請求の各処理プログラムについては、プラットフォーム管理者の提供装置１００から書き込まれてもよいし、サービス提供者の提供装置１００から書き込まれてもよい。例えば、残量収集、残量計算、警告状態確認の各処理プログラムは、提供されるサービス内容を決定するプログラムである。サービス提供者が自社独自のサービスを提供する場合、これらの処理プログラムはサービス提供者の提供装置１００から書き込まれる。或いは、汎用サービスとしてプラットフォーム管理者の提供装置１００から書き込まれてもよい。課金、請求の各処理プログラムは、サービス提供者が独自のルールで課金を行いたいと考えればサービス提供者の提供装置１００から書き込まれる。或いは、課金や請求に関する処理は種々のサービスにおいて流用可能であるため、プラットフォーム管理者の提供装置１００がブロックチェーンに書き込み、多くのサービスにおいて汎用的に利用されてもよい。その他、契約管理コントラクトを除く各処理プログラムがいずれの提供装置１００から書き込まれるかについては、種々の変形実施が可能である。

また、処理装置２００は、決済プログラムをスマートコントラクトを用いてブロックチェーンに書き込む処理を行う。処理装置２００は、決済コントラクトをブロックチェーンのブロックに登録するためのトランザクションを生成する処理を行う。

トランザクションの生成以降の流れは、図４を用いて上述した通りである。具体的にはコンセンサスアルゴリズムを用いた処理が行われ、合意形成が行われた場合に、トランザクションが取り込まれたブロックがブロックチェーンに追加される。

図７は、本実施形態のブロックチェーンの例である。ブロックＡには契約管理コントラクトを含むトランザクションが書き込まれている。ブロックＢには残量収集コントラクトを含むトランザクションが書き込まれている。ブロックＣには残量計算コントラクトを含むトランザクションが書き込まれている。ブロックＤには警告状態確認コントラクトを含むトランザクションが書き込まれている。ブロックＥには発注コントラクトを含むトランザクションが書き込まれている。ブロックＦには課金コントラクトを含むトランザクションが書き込まれている。ブロックＧには請求コントラクトを含むトランザクションが書き込まれている。ブロックＨには決済コントラクトを含むトランザクションが書き込まれている。

ブロックＡ～Ｈがブロックチェーンに追加されることによって、ブロックチェーンネットワークＮＷの各ノードは、消耗品配送サービスに関する各処理を実行可能になる。なお、図７はブロックチェーンの構造を表す一例であり、各プログラムがスマートコントラクトによりブロックチェーンに書き込まれる順序は問わない。また１ブロックに複数のコントラクトが書き込まれてもよい。

ブロックチェーンは、図７に示したスマートコントラクトにより書き込まれるプログラムだけでなく、ブロックチェーンネットワークＮＷで通信される任意のデータを含むことが可能である。ブロックチェーンに書き込まれるデータは、例えばプログラムの実行結果を表すデータであってもよいし、仮想通貨の取引を表す情報であってもよいし、他のデータであってもよい。実行結果を表すデータとは、残量収集コントラクトの実行結果である使用状況データであってもよいし、発注コントラクトの実行結果である発注データであってもよいし、図７には不図示のプログラムの実行結果であってもよい。また仮想通貨の取引を表す情報とは、決済コントラクトの実行結果であってもよいし、本実施形態に係る決済処理とは異なる仮想通貨の取引結果を表す情報であってもよい。

４．１．３ 処理の詳細
次に本実施形態の処理について詳細に説明する。なお、上述した各プログラムは、図４に示した処理を経て、スマートコントラクトによりブロックチェーンに書き込まれているものとして、説明を行う。

サービス提供者とサービス利用者との間で、消耗品配送サービスに関する契約が締結されると、まず契約アカウント情報のブロックチェーンへの登録処理が行われる。契約では、契約管理コントラクトが管理する契約タイプ、単価、割引情報、配送先、配送方法、締め日、請求方法の情報が決定される。各情報については上述した通りである。なお、契約にスマートコントラクトを用いる場合、契約アカウント情報の登録処理の完了をもって、契約が締結されたとみなしてもよい。

図８は、契約管理コントラクトの実行処理を説明するフローチャートである。なお、以下では、プラットフォーム管理者の提供装置１００が契約管理コントラクトを実行することによって、図８の各ステップを実行するものとして説明する。ただし、プラットフォーム管理者の提供装置１００は、契約管理コントラクトのブロックチェーンへの登録、及び契約アカウント情報の書き込み等を行うことは想定されるが、図８に示す処理の実行は必須ではない。図８を用いて後述する各ステップは、プラットフォーム管理者の提供装置１００で実行されてもよいし、サービス提供者の提供装置１００で実行されてもよいし、処理装置２００等の他のノードで実行されてもよい。広義には、ブロックチェーンネットワークＮＷのいずれかのノードが、当該ノード内の実行環境でスマートコントラクトを用いて提供されたプログラムを実行することによって、各ステップが実現される。図９以降のフローチャートについても同様であり、特定の装置が処理プログラムを実行することによって、フローチャートの各ステップの処理を実行するものとして説明を行うが、ブロックチェーンネットワークＮＷの他のノードにおいて当該処理が実行されてもよい。

まず提供装置１００は、実行タイミング情報に基づいて、残量収集コントラクト及び警告状態確認コントラクトの起動インターバルを登録する。また提供装置１００は、契約内容情報の締め日に基づいて、課金コントラクトの起動時刻を登録する（Ｓ４０１）。起動インターバルとは、例えば３０分、１時間等の時間である。締め日とは、例えば「毎月２１日０９：００」、「月初０８：００」といった情報である。

次に提供装置１００は、前回の残量収集コントラクト及び警告状態確認コントラクトの起動から現在時刻までの時間と、Ｓ４０１で取得した起動インターバルを比較することによって、起動インターバルを経過しているか否かを判定する（Ｓ４０２）。起動インターバルを経過していると判定した場合（Ｓ４０２でＹｅｓ）、提供装置１００は、残量計算コントラクト及び警告状態確認コントラクトを起動する（Ｓ４０３）。Ｓ４０２においてＮｏの場合、Ｓ４０３の処理は行われない。

次に提供装置１００は、現在時刻とＳ４０１で取得した起動時刻を比較することによって、起動時刻を経過しているか否かを判定する（Ｓ４０４）。起動時刻を経過していると判定した場合（Ｓ４０４でＹｅｓ）、提供装置１００は、課金コントラクトを起動する（Ｓ４０５）。Ｓ４０４においてＮｏの場合、課金コントラクトは起動されない。Ｓ４０５の処理後、又はＳ４０４においてＮｏの場合、Ｓ４０２に戻り処理が繰り返される。

図８の処理を行うことによって、所定の起動インターバルに従った残量収集コントラクト及び警告状態確認コントラクト起動、及び、締め日における課金コントラクトの起動が可能になる。なお、契約管理コントラクトは、定期実行機能を有してもよい。即ち、契約管理コントラクトは、自身の機能を用いて図８に示した処理を定期的に実行してもよい。

或いは、契約管理コントラクトが定期実行機能を持たず、外部プログラムが定期的に契約管理コントラクトを起動してもよい。この場合、外部プログラムは、使用状況データの収集ルールや締め日情報を知らない。そのため外部プログラムは、毎分、５分毎、３０分毎、毎時等の任意の間隔で、定期的に契約管理コントラクトを起動する。契約管理コントラクトは、起動の都度、図８に示した処理を行う。例えば、締め日として「毎月２１日０９：００（Ａ社）、月初０８：００（Ｂ社）」という情報が取得された場合であって、ある月の２１日０９：０３に外部プログラムから契約管理コントラクトが起動されたとする。この場合、契約管理コントラクトは、「毎月２１日０９：００（Ａ社）」という締め日に従って課金コントラクトを起動する。

なお、図８に示した処理においては、警告状態確認コントラクトの所与の起動から次の起動までの間隔である起動インターバルが制御される。ただし、警告状態確認コントラクトの起動制御はこれに限定されない。例えば、警告状態確認コントラクトは、所与の起動に伴う確認処理が終了してから、次の起動までの間隔が制御されてもよい。

図９は、契約管理コントラクトによる警告状態確認コントラクトの定期起動処理を説明する他のフローチャートである。この処理が開始されると、まず契約管理コントラクトを実行する提供装置１００は、実行タイミング情報に基づいて、警告状態確認インターバルを登録する（Ｓ５０１）。警告状態確認インターバルは、例えば１分程度の相対的に短い時間である。

次に、提供装置１００は、警告状態確認コントラクトを起動する（Ｓ５０２）。そして提供装置１００は、確認対象である全ての電子機器３００について、警告状態の確認が完了したか否かを判定する（Ｓ５０３）。確認が完了していない場合、Ｓ５０２に戻り、確認対象である他の電子機器３００を対象として処理を繰り返す。確認が完了した場合、提供装置１００は、そこから警告状態確認インターバルによって指定される時間だけ待機し（Ｓ５０４）、その後、Ｓ５０２に戻り警告状態確認コントラクトを再度起動する。図９に示した処理を行う場合、相対的に短い警告状態確認インターバルの期間を除いて、警告状態確認コントラクトが動作を繰り返すことになるため、電子機器３００における警告状態の発生を速やかに検出することが可能になる。

図１０は、残量収集コントラクト及び残量計算コントラクトによる処理を説明するフローチャートである。残量収集コントラクトを実行する処理装置２００は、図８のＳ４０３において起動されると、まず契約管理コントラクトから収集対象である電子機器３００を特定する情報を取得する（Ｓ６０１）。Ｓ６０１の処理では、例えば収集対象となる電子機器３００の数が取得される。処理装置２００は、対象の電子機器３００から、印刷枚数、インク残量等の消耗品の使用状況データを収集する（Ｓ６０２）。処理装置２００は、収集したデータに、電子機器３００を特定する情報と収集時刻を付与して、ブロックチェーンに書き込む処理を行う。次に処理装置２００は、対象となる全ての電子機器３００からの使用状況データの収集が完了したか否かを判定する（Ｓ６０３）。未収集の電子機器３００が残っている場合（Ｓ６０３でＮｏ）、Ｓ６０２に戻って収集を継続する。全ての電子機器３００からの収集が完了した場合（Ｓ６０３でＹｅｓ）、処理装置２００は残量計算コントラクトを起動する（Ｓ６０４）。

Ｓ６０５以降の処理は、残量計算コントラクトによって行われる。残量計算コントラクトを実行する提供装置１００は、残量収集コントラクトから取得した契約ＩＤに基づいて、契約タイプを特定する。そして残量計算の対象がインク残量であるか否かを判定する（Ｓ６０５）。対象がインク残量である場合（Ｓ６０５でＹｅｓ）、提供装置１００は、対象である電子機器３００のインク残量データを含む使用状況データをブロックチェーンから取得し、当該インク残量がインク残量限界値以下であるか否かを判定する（Ｓ６０６）。Ｓ６０６でＹｅｓの場合、残量不足であると判定されるため、提供装置１００は、インクを不足消耗品種別として指定して、発注コントラクトを起動する（Ｓ６０７）。Ｓ６０６でＮｏの場合、発注コントラクトは起動されずに処理を終了する。

一方、残量計算の対象が印刷媒体である場合（Ｓ６０６でＮｏ）、提供装置１００は、用紙サイズごとに以下の処理をループする。具体的には、提供装置１００は、対象である電子機器３００の印刷枚数を含む使用状況データをブロックチェーンから取得した後、前回の残量から印刷枚数を減算することによって、用紙残量を求める（Ｓ６０８）。なお、ここでの印刷枚数は、前回の残量計算からの増加分を表す。なお、残量の初期値は適切に設定されているものとする。また、印刷用紙を購入した場合、購入分が残量に加算される。

そして提供装置１００トは、求めた用紙残量が用紙残量限界値以下であるか否かを判定する（Ｓ６０９）。Ｓ６０９でＹｅｓの場合、残量不足であると判定されるため、提供装置１００は、対象の用紙サイズについて、残量不足フラグを設定する（Ｓ６１０）。Ｓ６０９でＮｏの場合、又は、Ｓ６１０の処理後、提供装置１００は、全ての用紙サイズについて処理が完了したか否かを判定する（Ｓ６１１）。Ｓ６１１でＮｏの場合、Ｓ６０８に戻り処理を継続する。

Ｓ６１１でＹｅｓの場合、提供装置１００は、いずれかの用紙サイズについて、残量不足フラグが設定されているか否かを判定する（Ｓ６１２）。残量不足フラグが設定されていた場合（Ｓ６１２でＹｅｓ）、提供装置１００は、対応するサイズの印刷用紙を不足消耗品種別として指定して、発注コントラクトを起動する（Ｓ６０７）。Ｓ６１２でＮｏの場合、発注コントラクトは起動されずに処理を終了する。

図１１は、警告状態確認コントラクトによる処理を説明するフローチャートである。警告状態確認コントラクトを実行する処理装置２００は、図８のＳ４０３又は図９のＳ５０２において起動されると、契約管理コントラクトから収集対象である電子機器３００を特定する情報を取得する（Ｓ７０１）。Ｓ７０１の処理では、例えば収集対象となる電子機器３００の数が取得される。処理装置２００は、対象の電子機器３００から、警告状態か否かを表すデータを含む状態データを収集する（Ｓ７０２）。処理装置２００は、収集した状態データに基づいて、電子機器３００がインク切れに対応する警告状態であるか否かを判定する（Ｓ７０３）。Ｓ７０３でＹｅｓの場合、対象の電子機器３００に消耗品切れフラグを設定する（Ｓ７０４）。

Ｓ７０３でＮｏの場合、又は、Ｓ７０４の処理後、処理装置２００は、全ての電子機器３００について処理が完了したか否かを判定する（Ｓ７０５）。Ｓ７０５でＮｏの場合、Ｓ７０２に戻り処理を継続する。

Ｓ７０５でＹｅｓの場合、処理装置２００は、いずれかの電子機器３００について、消耗品切れフラグが設定されているか否かを判定する（Ｓ７０６）。消耗品切れフラグが設定されていた場合（Ｓ７０６でＹｅｓ）、処理装置２００は、インクを不足消耗品種別として指定して、発注コントラクトを起動する（Ｓ７０７）。Ｓ７０６でＮｏの場合、発注コントラクトは起動されずに処理を終了する。

図１２は、発注コントラクトによる処理を説明するフローチャートである。まず発注コントラクトを実行する提供装置１００は、起動時に、残量計算コントラクト又は警告状態確認コントラクトから契約ＩＤ及び不足消耗品種別を取得する（Ｓ８０１）、次に提供装置１００は、取得した契約ＩＤに基づいて、契約管理コントラクトに問い合わせを行うことによって、配送先及び配送方法を取得する（Ｓ８０２）。提供装置１００は、不足消耗品種別によって特定される消耗品を、指定された配送方法によって、指定された配送先に配送するための手配処理を行う（Ｓ８０３）。その後、提供装置１００は、消耗品の代金、及び送料を含む発注データを、ブロックチェーンに書き込む処理を行う（Ｓ８０４）。

図１３は、課金コントラクト、請求コントラクト、決済コントラクトの処理を説明するフローチャートである。課金コントラクトを実行する提供装置１００は、図８のＳ４０５において、契約ＩＤ及び締め日をパラメーターとして契約管理コントラクトによって起動される。提供装置１００は、ブロックチェーンに保存されている発注データのうち、前回の締め日以降、今回の締め日までの発注金額を取得、累計することによって、課金額を決定する（Ｓ９０１）。課金額が決定されると、提供装置１００は、契約ＩＤ、課金額をパラメーターとして請求コントラクトを起動する（Ｓ９０２）。

請求コントラクトを実行する提供装置１００は、パラメーターとして取得した契約ＩＤに基づいて契約管理コントラクトに問い合わせを行い、請求方法として宛先や送付方法の情報を取得する（Ｓ９０３）。提供装置１００は、取得した方法で請求書を送付する（Ｓ９０４）。なお、仮想通貨を使用して決済を行う場合、Ｓ９０４における請求書とは、ブロックチェーン上での支払い要求になる。支払い要求を行うために、請求コントラクトは、自分の仮想通貨の受信アドレスと請求額をパラメーターとして、請求対象である契約者の決済コントラクトを起動する（Ｓ９０５）。

決済コントラクトを実行する提供装置１００は、自身が保持する契約者のアドレスを、仮想通貨の送信アドレスとする。そして提供装置１００は、当該送信アドレスから、パラメーターとして取得した受信アドレスへ、請求額分を送金するという取引データをブロックチェーンに書き込む処理を行う（Ｓ９０６）。実際の仮想通貨の取引はコンセンサスアルゴリズムに基づく合意形成が承認された後、成立する。

なお、決済処理において、契約者のアカウントが請求額に満たない仮想通貨しか保有していなかった場合、提供装置１００は、不足分を未決済取引としてブロックチェーンに書き込む処理を行ってもよい。その場合、決済コントラクトは、次回以降の決済時に、ブロックチェーン内の未決済取引から順に処理することによって、未払いの請求に関する決済を実行する。

これ以降についても、図８～図１３に示した各処理を実行することによって、消耗品配送サービスを自動で実行する処理システム１０を実現できる。ブロックチェーン上で処理を自動化することによって、一つのシステムのみで消耗品配送サービスを実現することが可能である。なお、郵送やメールによって行われた請求に対する決済を、仮想通貨を用いずに行う場合のように、消耗品配送サービスに関する一部の処理がブロックチェーンを介さずに実行されてもよい。

本実施形態によれば、ブロックチェーン技術を利用して、電子機器３００に関するサービス提供処理を自動化できる。狭義には、サービスとは消耗品配送サービスであって、残量収集、残量計算、警告状態確認、発注、サービスによって発生する費用の課金、課金額の請求、の各処理を自動化できる。また、同じブロックチェーン上の仮想通貨を使用することで、請求に基づく決済についても自動化が可能である。ブロックチェーン技術では、ブロックチェーンにデータを書き込む際にコンセンサスアルゴリズムによる合意形成が行われる。これにより、発行したトランザクションが書き込まれることなく放置されること、及び同じトランザクションが二重に書き込まれることが抑制できる。即ち、人手によるチェックを行わずとも、消耗品の重複配送及び配送忘れ、或いは重複課金や課金忘れを抑制することが可能である。

４．２ 修理請負サービス
次に電子機器３００に関するサービスの他の例として、修理請負サービスについて説明する。まず、修理請負サービスで用いられるスマートコントラクトの具体例を説明し、その後、フローチャートを用いて処理の流れを説明する。

４．２．１ スマートコントラクト
＜契約管理コントラクト＞
契約管理コントラクトについては消耗品配送サービスと同様である。契約管理コントラクトは、契約アカウント情報とサービス提供者情報を管理することによって、プラットフォーム管理者とサービス提供者の間の契約、及び、サービス提供者とサービス利用者の間の契約を管理する。

ただし修理請負サービスを実現するためには、契約アカウント情報に含まれる契約内容情報は、修理請負サービスに関する契約の内容を表す情報である必要があり、契約内容情報の具体的な内容は消耗品配送サービスと異なる。修理請負サービスにおける契約内容情報とは、保証期間、修理形態、年間サポート契約、請求方法等を含む情報である。

保証期間は、電子機器３００の保証期間を表す情報であり、例えば保証期間の開始日と、保証期間の長さを特定する情報である。修理形態は、訪問修理を行うか引取修理を行うかを特定する情報である。年間サポート契約は、上記保証期間とは別に、修理費用を低減する契約を結んでいるか否かを表す情報である。年間サポート契約は、例えば修理費用を低減する対象となる故障、サポート期間、費用の低減額等の情報を含む。なお、以下では説明を簡略化するため、年間サポート契約の契約範囲内であれば、修理費用を無料とする例について説明する。請求方法は、修理代金をサービス利用者に請求する際の、請求書の宛先、請求書の送付方法を特定する情報である。

また、契約管理コントラクトが、スマートコントラクト情報、実行タイミング情報を対応づけて管理する点は消耗品配送サービスと同様である。修理請負サービスにおいては、後述する状態確認コントラクト、修理手配コントラクトを実行することによって電子機器３００の修理手配が行われる。契約管理コントラクトは、これらのうち、少なくとも自身が呼び出す必要がある状態確認コントラクトを表す情報をスマートコントラクト情報として管理する。また契約管理コントラクトは、状態確認コントラクトの実行タイミングを表す情報を管理する。

＜状態確認コントラクト＞
サービス提供処理プログラムは、電子機器３００のエラー状態の確認処理、及び、電子機器３００の部品交換の有無の判定処理の少なくとも一方の処理を行う状態確認プログラムを含む。提供装置１００の処理部１１０は、状態確認プログラムを、ブロックチェーンに登録するためのトランザクションを生成する。状態確認プログラムは、契約管理プログラムによって所与のスケジュールに従って起動される。スマートコントラクトを用いてブロックチェーンに書き込まれる状態確認プログラムを、状態確認コントラクトと表記する。このようにすれば、修理が必要な状態であるか否かの確認処理を、ブロックチェーンを用いて共有されるプログラムに基づいて実行することが可能になる。

状態確認コントラクトは、電子機器３００の状態データを取得する。状態データは、サービスコールが必要なエラー状態であるかを識別可能な情報である。また状態確認コントラクトは、電子機器３００の使用状況データを取得し、当該使用状況データに含まれる部品の使用量情報又は使用時間情報に基づいて、交換時期か否かを判定する。状態データ、使用状況データの取得は、消耗品配送サービスの例と同様に、ＳＮＭＰに則って実行される。なお状態データの種類によっては、状態確認コントラクトは、定期交換が必要な部品が交換時期になっているか否かを状態データに基づいて判定することも妨げられない。また、ここでの状態確認コントラクトは、エラー状態の確認処理及び部品交換の有無の判定処理の両方を行うものには限定されず、いずれか一方に基づいて修理が必要な状態であるか否かを判定してもよい。

例えば電子機器３００がプロジェクターである場合、使用状況データは、当該プロジェクターの光源の発光時間である。状態確認コントラクトは、発光時間の累計と耐用時間に基づいて交換が必要か否かを判定する。或いは使用状況データは、電子機器３００の可動部の移動量、例えばモーターの回転量等であってもよい。また使用状況データは、例えば電子機器３００の電源がオンになっている時間を表す情報であってもよいし、電子機器３００の特定の機能を使用している時間を表す情報であってもよい。特定の機能とは、例えばプリンターの印刷機能、スキャナーのスキャン機能等、種々の機能が考えられる。

状態確認コントラクトは、何らかの修理が必要な状態が確認された場合、契約ＩＤ、電子機器３００を特定する情報、及び具体的な状態をパラメーターとして、修理手配コントラクトを起動する。

契約管理コントラクトは、契約ＩＤ及び収集対象となる電子機器３００を特定する情報を指定して状態コントラクトを起動する。契約管理コントラクトが実行タイミング情報に従って残量収集コントラクトを起動することによって、サービス提供者の決定した適切なタイミングで状態データの収集が可能になる。具体的な起動タイミングは種々の変形実施が可能である。修理が必要な状態を可能な限り遅延なく検出することを考慮すれば、状態確認コントラクトは、３０分に１回、１時間に１回等のある程度高い頻度で起動される。或いは契約管理コントラクトは、対象の全ての電子機器３００の状態確認が完了後、あらかじめ指定された状態確認インターバル経過したら、次の状態確認を行うようにしてもよい。ここでの状態確認インターバルは、例えば１分間である。

また状態データの収集タイミングは、サービス提供者とサービス利用者の間の契約によって決定されてもよい。その場合、契約内容情報は状態確認ルールを含む。契約管理コントラクトが状態確認ルールに従って状態確認コントラクトを起動することによって、契約内容に即した適切なタイミングで警告状態の確認が可能になる。

＜修理手配コントラクト＞
サービス提供処理プログラムは、状態確認プログラムによって起動され、電子機器３００の修理手配処理を行うための修理手配処理プログラムを含む。提供装置１００の処理部１１０は、修理手配プログラムを、ブロックチェーンに登録するためのトランザクションを生成する。スマートコントラクトを用いてブロックチェーンに書き込まれる修理手配プログラムを、修理手配コントラクトと表記する。このようにすれば、電子機器３００の修理を手配する処理を、ブロックチェーンを用いて共有されるプログラムに基づいて実行することが可能になる。

修理手配コントラクトは、修理の手配処理を行う。修理手配コントラクトは、状態確認コントラクトから契約ＩＤ、電子機器３００を特定する情報、及び具体的な状態を受け取る。修理手配コントラクトは、契約ＩＤに基づいて契約管理コントラクトに問い合わせを行うことによって、契約内容情報の修理形態に応じた修理の手配を行う。修理形態が訪問修理の場合、修理担当者の割り当てと訪問日時を決定する。訪問日時に関しては、修理担当者が決められるようにしてもよい。一方、修理形態が引取修理の場合、配送の手配を行う。

また修理手配コントラクトは、各修理案件に修理案件ＩＤを割り当てる。修理手配コントラクトは、修理案件ＩＤごとに、修理進捗状況確認、進捗状況の変更、修理内容および修理費用の入力が出来る手段を提供する。入力された値はブロックチェーンに保存される。例えば、Ｗｅｂページの形態で、請け負った修理案件の状況の確認、変更、修理内容、修理費用の入力が可能なインターフェースが提供され、当該インターフェースを用いて入力された情報がブロックチェーンに書き込まれる。

修理手配コントラクトは、所与の修理案件について修理費用が入力されると、契約ＩＤ、修理案件ＩＤ、電子機器３００を特定する情報、修理費用をパラメーターとして、課金コントラクトを起動する。

＜課金コントラクト＞
課金コントラクトは、修理案件ＩＤに対する課金額を決定する。課金コントラクトは、修理手配コントラクトから取得した契約ＩＤに基づいて契約管理コントラクトに問い合わせを行うことによって、保証期間、修理形態、年間サポート契約の有無、の各情報を取得する。

課金コントラクトは、取得した情報に基づいて課金額を決定する処理を行う。課金コントラクトは、保証期間内の場合や、年間サポート契約に含まれる修理の場合、課金額を０とする。一方、課金コントラクトは、保証期間が終了している場合、年間サポート契約外の修理である場合、年間サポート未契約である場合、修理手配コントラクトから受け取った修理費用に出張修理費用、配送料等を適切に加算することによって、課金額を算出する。

課金コントラクトは、算出した課金額をブロックチェーンに書き込む処理を行う。また課金コントラクトは、契約ＩＤ及び課金額をパラメーターとして、請求コントラクトを起動する。

＜請求コントラクト＞
請求コントラクトについては消耗品配送サービスと同様である。課金コントラクトは、契約ＩＤ及び課金額をパラメーターとして、請求コントラクトを起動する。請求コントラクトは、取得した契約ＩＤに基づいて契約管理コントラクトに問い合わせを行い、当該契約ＩＤに対応する請求方法を用いて請求処理を行う。

＜決済コントラクト＞
決済コントラクトについても消耗品配送サービスと同様である。請求コントラクトは、請求書をパラメーターとして決済コントラクトを起動する。決済コントラクトは、保持しているサービス利用者のアドレスから、請求書に指定された仮想通貨のアドレス宛に、請求された額の仮想通貨を支払う処理を行う。

４．２．２ ブロックチェーンの具体例
図１４は、本実施形態のブロックチェーンの例である。ブロックＩには契約管理コントラクトを含むトランザクションが書き込まれている。ブロックＪには状態確認コントラクトを含むトランザクションが書き込まれている。ブロックＫには修理手配コントラクトを含むトランザクションが書き込まれている。ブロックＬには課金コントラクトを含むトランザクションが書き込まれている。ブロックＭには請求コントラクトを含むトランザクションが書き込まれている。ブロックＮには決済コントラクトを含むトランザクションが書き込まれている。

ブロックＩ～Ｎがブロックチェーンに追加されることによって、ブロックチェーンネットワークＮＷの各ノードは、修理請負サービスに関する各処理を実行可能になる。

なお、上述したように契約管理コントラクトは、契約内容情報に含まれる情報が一部異なるものの、消耗品配送サービスと修理請負サービスの両方で共通とすることが可能である。消耗品配送サービスと修理請負サービスの両方をサービス提供プラットフォームにおいて提供する場合、図７のブロックＡに含まれる契約管理コントラクトと、図１４のブロックＩに含まれる契約管理コントラクトは別々に書き込まれる必要はなく、いずれか一方が書き込まれればよい。また、請求コントラクト及び決済コントラクトも複数のサービスにおいて共通化が可能である。ブロックＧとブロックＭ、ブロックＨとブロックＮも重複させる必要がない。所与の処理プログラムを複数のサービスにおいて利用することによって、サービス提供プラットフォームにおけるサービス提供を効率的に実現することが可能になる。例えば、複数のサービス提供者による利用が想定される汎用処理プログラムを、プラットフォーム管理者があらかじめ提供する実施形態が考えられる。

４．２．３ 処理の詳細
次に本実施形態の処理について詳細に説明する。なお、上述した各プログラムは、図４に示した処理を経て、スマートコントラクトによりブロックチェーンに書き込まれているものとして、説明を行う。

サービス提供者とサービス利用者との間で、修理請負サービスに関する契約が締結されると、まず契約アカウント情報のブロックチェーンへの登録処理が行われる。契約では、契約管理コントラクトが管理する保証期間、修理形態、年間サポート契約、請求方法の情報が決定される。各情報については上述した通りである。

図１５は、契約管理コントラクトの実行処理を説明するフローチャートである。契約管理コントラクトを実行する提供装置１００は、実行タイミング情報に基づいて、状態確認コントラクトの起動インターバルを登録する（Ｓ１００１）。起動インターバルとは、例えば３０分、１時間等の時間である。

次に提供装置１００は、前回の状態確認コントラクトの起動から現在時刻までの時間と、Ｓ１００１で取得した起動インターバルを比較することによって、起動インターバルを経過しているか否かを判定する（Ｓ１００２）。起動インターバルを経過していると判定した場合（Ｓ１００２でＹｅｓ）、提供装置１００は、状態確認コントラクトを起動する（Ｓ１００３）。Ｓ１００３の処理後、又は、Ｓ１００２においてＮｏの場合、Ｓ１００１に戻り処理が繰り返される。

図１５の処理を行うことによって、所定の起動インターバルに従った状態確認コントラクト起動が可能になる。なお、上述した消耗品配送サービスにおいては、ある程度高い頻度で消耗品の配送が行われることが想定されるため、課金処理を締め日に実行することによってユーザーの利便性向上が可能である。例えば、所与の締め日以降、次の締め日までの期間に複数回の発送が行われたとしても、請求や決済の頻度が抑制される。それに比べて、修理が必要な故障等の発生頻度は低いと考えられる。よってここでは、課金処理が修理案件ごとに行われる例について説明する。ただし、消耗品配送サービスと同様に、締め日ごとに課金処理が実行されてもよい。

図１６は、契約管理コントラクトによる状態確認コントラクトの定期起動処理を説明する他のフローチャートである。この処理が開始されると、まず契約管理コントラクトを実行する提供装置１００は、実行タイミング情報に基づいて、状態確認インターバルを登録する（Ｓ１１０１）。状態確認インターバルは、例えば１分程度の相対的に短い時間である。

次に、提供装置１００は、状態確認コントラクトを起動する（Ｓ１１０２）。そして提供装置１００は、確認対象である全ての電子機器３００について、状態の確認が完了したか否かを判定する（Ｓ１１０３）。確認が完了していない場合、Ｓ１１０２に戻り、確認対象である他の電子機器３００を対象として処理を繰り返す。確認が完了した場合、提供装置１００は、そこから状態確認インターバルによって指定される時間だけ待機し（Ｓ１１０４）、その後、Ｓ１１０２に戻る。

図１７は、状態確認コントラクトによる処理を説明するフローチャートである。状態確認コントラクトは、図１５のＳ１００３又は図１６のＳ１１０２において起動される。状態確認コントラクトを実行する処理装置２００は、契約管理コントラクトから収集対象である電子機器３００を特定する情報を取得する。そして処理装置２００は、対象の電子機器３００から、修理が必要な状態か否かを表すデータを含む状態データ、及び、定期交換部品の使用回数情報又は使用時間情報を含む使用状況データを収集する（Ｓ１２０１）。処理装置２００は、収集した状態データに基づいて、電子機器３００が、サービスコールが必要なエラー状態であるか否かを判定する（Ｓ１２０２）。Ｓ１２０２でＹｅｓの場合、対象の電子機器３００にサービスコールフラグを設定する（Ｓ１２０３）。Ｓ１２０２でＮｏの場合、Ｓ１２０３の処理は省略される。

また処理装置２００は、収集した使用状況データに基づいて、定期交換部品が交換時期を超えているか否かを判定する（Ｓ１２０４）。交換時期を超えているか否かの判定は、例えば使用状況データとして取得された使用回数と、あらかじめ部品ごとに設定されている耐用回数との比較処理によって行われる。或いは、使用年数と耐用年数の比較が行われてもよい。Ｓ１２０４でＹｅｓの場合、対象の定期交換部品に関する交換フラグを設定する（Ｓ１２０５）。Ｓ１２０４でＮｏの場合、Ｓ１２０５の処理は省略される。処理装置２００は、全ての定期交換部品について確認処理が終了したか否かを判定し（Ｓ１２０６）、終了していない場合はＳ１２０４に戻り処理を繰り返す。

処理装置２００は、全ての電子機器３００について処理が完了したか否かを判定する（Ｓ１２０７）。Ｓ１２０７でＮｏの場合、Ｓ１２０１に戻り処理を継続する。Ｓ１２０７でＹｅｓの場合、処理装置２００は、いずれかの電子機器３００について、サービスコールフラグ又は交換フラグが設定されているか否かを判定する（Ｓ１２０８）。少なくとも一方のフラグが設定されていた場合（Ｓ１２０８でＹｅｓ）、処理装置２００は、修理手配コントラクトを起動する（Ｓ１２０９）。Ｓ１２０８でＮｏの場合、修理手配コントラクトは起動されずに処理を終了する。

図１８は、修理手配コントラクトによる処理を説明するフローチャートである。修理手配コントラクトは、図１７のＳ１２０９において起動される。修理手配コントラクトを実行する提供装置１００は、起動時に受け取った契約ＩＤに基づいて契約管理コントラクトに問い合わせを行うことによって、修理形態を取得する（Ｓ１３０１）。提供装置１００は、修理案件ごとにユニークな修理案件ＩＤを割当てる（Ｓ１３０２）。

提供装置１００は、修理形態が訪問修理であるか否かを判定する（Ｓ１３０３）。修理形態が訪問修理の場合（Ｓ１３０３でＹｅｓ）、提供装置１００は、修理担当者の割当て、および訪問日時を決定する（Ｓ１３０４）。訪問日時は、システム側が決定してもよいし、修理担当者が決定した日時の入力を受け付けてもよい。その後、修理担当者が訪問修理を行い、修理手配コントラクトの該当する修理案件ＩＤに対して、修理進捗状況の入力を行う。提供装置１００は、修理進捗状況の入力を受け付け（Ｓ１３０５）、修理が完了したか否かを判定する（Ｓ１３０６）。修理が完了していない場合（Ｓ１３０６でＮｏ）、Ｓ１３０５に戻り、完了するまで処理を継続する。

修理形態が引取修理の場合（Ｓ１３０３でＮｏ）、提供装置１００は、引取対象の電子機器３００の配送手配処理を行う（Ｓ１３０７）。修理進捗状況の入力受け付け（Ｓ１３０８）、及び、修理が完了したか否かの判定（Ｓ１３０９）については訪問修理の場合と同様である。

修理が完了したと判定された場合（Ｓ１３０６又はＳ１３０９でＹｅｓ）、提供装置１００は、修理内容、修理費の入力を受け付ける（Ｓ１３１０）。提供装置１００は、契約ＩＤ、修理案件ＩＤ、電子機器３００を特定する情報、修理費用をパラメーターとして、課金コントラクトを起動する（Ｓ１３１１）。なお、図１８の処理において、修理案件ＩＤの決定や、何らかの入力を受け付けが行われた場合、該当する情報は、その都度ブロックチェーンに書き込まれる。

図１９は、課金コントラクト、請求コントラクト、決済コントラクトの処理を説明するフローチャートである。課金コントラクトは、図１８のＳ１３１１において、修理手配コントラクトによって起動される。課金コントラクトを実行する提供装置１００は、起動時に受け取った契約ＩＤに基づいて契約管理コントラクトに問い合わせを行うことによって、保証期間、年間サポート契約を含む契約内容情報を取得する（Ｓ１４０１）。

提供装置１００は、修理対象である電子機器３００が保証期間内であるか否かを判定する（Ｓ１４０２）。また提供装置１００は、該当する修理が年間サポート契約の範囲内で行われたか否かを判定する（Ｓ１４０３）。Ｓ１４０２とＳ１４０３のいずれか一方でＹｅｓの場合、提供装置１００は、課金額を０に設定する（Ｓ１４０４）。Ｓ１４０２とＳ１４０３の両方でＮｏの場合、提供装置１００は、起動時に受け取った修理費用に出張費、配送料等の経費を加算し、課金額を算出する（Ｓ１４０５）。なお、Ｓ１４０３においてＮｏとは、年間サポート契約が未契約の場合、契約済みであるが修理内容が年間サポート契約の範囲外である場合、等が考えられる。

課金額が決定されると、提供装置１００は、契約ＩＤ、課金額をパラメーターとして請求コントラクトを起動する（Ｓ１４０６）。

請求コントラクトを実行する提供装置１００は、パラメーターとして取得した契約ＩＤに基づいて契約管理コントラクトに問い合わせを行い、請求方法として宛先や送付方法の情報を取得する（Ｓ１４０７）。提供装置１００は、取得した方法で請求書を送付する（Ｓ１４０８）。支払い要求を行うために、請求コントラクトは、自分の仮想通貨の受信アドレスと請求額をパラメーターとして、請求対象である契約者の決済コントラクトを起動する（Ｓ１４０９）。

決済コントラクトを実行する提供装置１００は、自身が保持する契約者のアドレスを、仮想通貨の送信アドレスとする。そして提供装置１００は、当該送信アドレスから、パラメーターとして取得した受信アドレスへ、請求額分を送金するという取引データをブロックチェーンに書き込む処理を行う（Ｓ１４１０）。実際の仮想通貨の取引はコンセンサスアルゴリズムに基づく合意形成が承認された後、成立する。

これ以降についても、図１５～図１９に示した各処理を実行することによって、修理請負サービスを自動で実行する処理システム１０を実現できる。

５．変形例
以下、いくつかの変形例について説明する。

５．１ 他のサービス
以上ではサービスの具体例として消耗品配送サービスと修理請負サービスについて説明した。ただし、電子機器３００に関するサービスはこれに限定されず、種々の変形実施が可能である。

例えば、電子機器３００の配置や配線等の処理を行う設置サービス、電子機器３００の設定を行う設定サービス、印刷物の製本処理を行う製本受注サービス、写真印刷等の高精細印刷を行う高精細印刷受注サービス等が考えられる。いずれのサービスにおいても、サービス提供者は、サービス登録必須情報等の登録を行えばサービス提供が可能になる。また、サービス利用者は、ディレクトリーサービス等を用いてサービスを検索、選択することによって、種々のサービスを利用可能になる。そしてこれらの手続きがブロックチェーンを用いて自動化されるため、サービス提供者及びサービス利用者にとって使用しやすいプラットフォームの実現が可能である。

５．２ 契約管理プログラムの変形例
以上では、契約管理コントラクトが定期実行機能を有する例、及び定期実行機能を有さない契約管理コントラクトが外部プログラムにより起動される例を示した。いずれの場合も、契約管理プログラムがスマートコントラクトによりブロックチェーンに書き込まれるプログラムとして実現される例を示している。

ただし、契約管理プログラム自体を外部プログラムとしてもよい。当該外部プログラムは、収集コントラクト等の他のコントラクトを必要なタイミングで起動する。

消耗品配送サービスにおいては、提供装置１００の処理部１１０は、電子機器３００の消耗品の使用状況データを収集する残量収集プログラムを、ブロックチェーンに登録するためのトランザクションを生成し、当該残量収集プログラムは、外部プログラムによって起動されてもよい。或いは処理部１１０は、電子機器３００が消耗品の不足に基づく警告状態となっているか否かを確認する警告状態確認プログラムを、ブロックチェーンに登録するためのトランザクションを生成し、当該警告確認プログラムは、外部プログラムによって起動されてもよい。また修理請負サービスにおいては、電子機器３００のエラー状態の確認処理、及び、電子機器３００の部品交換の有無の判定処理の少なくとも一方の処理を行う状態確認プログラムをブロックチェーンに登録するためのトランザクションを生成し、当該状態確認プログラムは、外部プログラムによって起動されてもよい。このようにすれば、契約管理プログラムを種々の態様により実現することが可能になる。

５．３ 正規サービスか否かの判定
サービス提供者にはデジタルＩＤが割り当てられる。これは、第三者機関が発行したデジタルＩＤであってもよいし、サービス提供プラットフォームにおいて割り当てられるデジタルＩＤであってもよい。このデジタルＩＤは、スマートコントラクトを利用したサービス利用時に、当該サービスが正規サービスとして登録済みか否か確認するために用いられてもよい。

例えば、契約管理コントラクトは、サービスを提供するための処理プログラムを呼び出す際に、デジタルＩＤを用いて当該サービスが正規サービスであるか否かを判定する。サービスを提供するための処理プログラムとは、例えば消耗品配送サービスにおける残量収集コントラクト及び警告状態確認コントラクト、修理請負サービスにおける状態確認コントラクト等である。

契約管理コントラクトは、デジタルＩＤが第三者機関によって発行されたＩＤである場合、サービス利用時に第三者機関に問合せを行い、当該ＩＤが正規に取得されたＩＤであるか否かを確認する。或いは契約管理コントラクトは、デジタルＩＤがサービス提供プラットフォームの管理システムによって割り当てられたＩＤである場合、サービス利用時に管理システムに問合せを行い、当該ＩＤが正規に割り当てられたＩＤであるか否かを確認する。

なお、初回の問合せ時に承認済みのトークンを取得し、トークンの有効期間内はトークンを再利用して、正規に取得したＩＤであることを確認してもよい。

以上のように本実施形態の提供装置１００は、ブロックチェーンを用いたネットワークとの通信を行う通信部と、通信部を制御する処理部を含む。処理部は、管理対象である電子機器についてのサービス提供処理を行うためのサービス提供処理プログラムを、ブロックチェーンに登録するためのトランザクションを生成し、生成したトランザクションを、通信部を介してネットワークに発行する。サービス提供処理プログラムは、ブロックチェーンに記憶されたサービス提供者情報により表されるサービス提供者に、サービスを依頼する処理を行う。

このようにすれば、サービス提供処理プログラムは、ブロックチェーンを用いたネットワークの各ノードにおいて実行可能となる。これにより、ブロックチェーンを用いてサービスを適切に提供することが可能になる。その際、どのサービス提供者がサービスを実行するかを特定するためのサービス提供者情報についても、ブロックチェーン上で管理することが可能になる。

また本実施形態の処理部は、サービス提供処理の内容を決定するための契約内容情報、及び、サービス提供者情報を管理する契約管理プログラムを、ブロックチェーンに登録するためのトランザクションを生成してもよい。

このようにすれば、サービスの具体的な内容と、当該サービスを提供するサービス提供者を適切に対応づけて管理することが可能になる。

また本実施形態のサービス提供処理プログラムは、電子機器のエラー状態の確認処理、及び、電子機器の部品交換の有無の判定処理の少なくとも一方の処理を行う状態確認プログラムを含んでもよい。提供装置の処理部は、状態確認プログラムを、ブロックチェーンに登録するためのトランザクションを生成する。

このようにすれば、ブロックチェーンを用いて、電子機器の修理が必要か否かの確認を行うことが可能になる。

また本実施形態のサービス提供処理プログラムは、契約管理プログラムによって所与のスケジュールに従って起動され、電子機器のエラー状態の確認処理、及び、電子機器の部品交換の有無の判定処理の少なくとも一方の処理を行う状態確認プログラムを含んでもよい。提供装置の処理部は、状態確認プログラムを、ブロックチェーンに登録するためのトランザクションを生成する。

このようにすれば、ブロックチェーンを用いて、電子機器の修理が必要か否かの確認を行うことが可能になる。また、状態確認の実行タイミングを、契約管理プログラムによって管理することが可能になる。

また本実施形態のサービス提供処理プログラムは、状態確認プログラムによって起動され、電子機器の修理手配処理を行うための修理手配処理プログラムを含んでもよい。提供装置の処理部は、修理手配処理プログラムを、ブロックチェーンに登録するためのトランザクションを生成する。

このようにすれば、状態確認結果に基づく修理手配を、ブロックチェーンを用いて行うことが可能になる。

また本実施形態のサービス提供処理プログラムは、サービス提供により発生する費用を含むサービス提供データを、ブロックチェーンに書き込む処理を行う。提供装置の処理部は、ブロックチェーンに書き込まれたサービス提供データに基づいて、課金額を決定する課金処理プログラムをブロックチェーンに登録するためのトランザクションを生成する。

このようにすれば、サービス提供によって発生する費用の課金処理を、ブロックチェーンを用いて行うことが可能になる。

また本実施形態の処理部は、課金処理プログラムによって決定された課金額を、対応する契約アカウントに対して請求する請求プログラムをブロックチェーンに登録するためのトランザクションを生成する。そして請求プログラムは、課金処理プログラムによって起動される。

このようにすれば、ブロックチェーンを用いて課金額を請求すること、及び課金処理プログラムと請求プログラムを連携して動作させることが可能になる。

また本実施形態の処理部は、サービス提供処理プログラムを、スマートコントラクトを用いてブロックチェーンに登録するためのトランザクションを生成してもよい。

このようにすれば、ブロックチェーン技術におけるスマートコントラクトを用いて、サービス提供処理プログラムを提供することが可能になる。

また本実施形態の処理部は、電子機器に関するサービスを提供するサービス提供者を管理するための管理プログラムを、ブロックチェーンに登録するための第１トランザクションを生成し、生成した第１トランザクションを、通信部を介してネットワークに発行してもよい。管理プログラムは、サービス提供者を識別するサービス提供者情報と、サービス提供者によるサービスを提供するためのサービス提供処理プログラムとを対応付けた情報を、ブロックチェーンに登録するための第２トランザクションを生成し、生成した第２トランザクションを、通信部を介してネットワークに発行する。

このようにすれば、サービス提供者を管理するための管理プログラム、及び当該管理プログラムによって管理される情報がブロックチェーンに書き込まれる。サービス提供のための情報の登録処理が可能なるため、ブロックチェーンを利用したサービス提供プラットフォームを適切に構築できる。

また本実施形態の処理システムは、上記のいずれかに記載の提供装置と、電子機器に対応して設けられ、ブロックチェーンからサービス提供処理プログラムを取得してサービス提供処理プログラムを実行する処理装置と、を含む。

このようにすれば、ブロックチェーンを用いてサービスを提供するためのシステムを実現できる。

また本実施形態の処理システムは、上記の提供装置と、電子機器に対応して設けられる処理装置と、を含み、処理装置は、請求プログラムによる請求に対する決済を行う決済プログラムをブロックチェーンに登録するためのトランザクションを生成してもよい。決済プログラムは、ブロックチェーンにおける仮想通貨を用いて決済を行う。

このようにすれば、請求に対する決済処理を、ブロックチェーンを用いて実行することが可能になる。その際、請求を受ける側である処理装置が決済プログラムを登録するための処理を行うことによって、仮想通貨の送金処理を適切に実行することが可能になる。

なお、上記のように本実施形態について詳細に説明したが、本実施形態の新規事項および効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。従って、このような変形例はすべて本開示の範囲に含まれるものとする。例えば、明細書又は図面において、少なくとも一度、より広義または同義な異なる用語と共に記載された用語は、明細書又は図面のいかなる箇所においても、その異なる用語に置き換えることができる。また本実施形態及び変形例の全ての組み合わせも、本開示の範囲に含まれる。また提供装置、処理装置、処理システムの構成及び動作等も、本実施形態で説明したものに限定されず、種々の変形実施が可能である。

１０…処理システム、１００…提供装置、１１０…処理部、１２０…通信部、２００…処理装置、３００…電子機器、ＮＷ…ブロックチェーンネットワーク

Claims (10)

1. ブロックチェーンを用いたネットワークとの通信を行う通信部と、
   前記通信部を制御する処理部と、
   を含み、
   前記処理部は、
   契約管理プログラムを前記ブロックチェーンに登録するためのトランザクションを生成し、生成した前記トランザクションを、前記通信部を介して前記ネットワークに発行し、
   管理対象である電子機器についてのサービス提供処理を行うためのサービス提供処理プログラムを、前記ブロックチェーンに登録するための前記トランザクションを生成し、生成した前記トランザクションを、前記通信部を介して前記ネットワークに発行し、
   前記契約管理プログラムは、
   サービス提供者情報を前記ブロックチェーンに書き込む処理を行い、
   前記サービス提供処理プログラムは、
   前記契約管理プログラムにより前記ブロックチェーンに書き込まれた前記サービス提供者情報により表されるサービス提供者に、サービスを依頼する処理を行い、
   前記サービス提供者情報とサービス内容情報を含むサービス登録必須情報は、第三者機関又は証明書発行機関が発行したデジタルＩＤを含み、
   前記契約管理プログラムは、
   前記サービス登録必須情報に正当な前記デジタルＩＤが含まれている場合に、前記サービス登録必須情報を前記ブロックチェーンに書き込む処理を行うことを特徴とする提供装置。
2. 請求項１に記載の提供装置において、
   前記契約管理プログラムは、
   サービス利用者を特定する情報と契約内容を表す情報を含む契約アカウント情報と、前記サービス登録必須情報と、前記サービス提供処理プログラムを特定するスマートコントラクト情報とを対応づけて管理することを特徴とする提供装置。
3. 請求項２に記載の提供装置において、
   前記契約管理プログラムは、
   前記契約アカウント情報と、前記サービス登録必須情報と、前記スマートコントラクト情報と、前記サービス提供処理プログラムを実行するタイミングを表す実行タイミング情報とを対応づけて管理することを特徴とする提供装置。
4. 請求項１乃至３のいずれか一項に記載の提供装置において、
   前記サービス提供処理プログラムは、前記契約管理プログラムによって所与のスケジュールに従って起動され、前記電子機器のエラー状態の確認処理、及び、前記電子機器の部品交換の有無の判定処理の少なくとも一方の処理を行う状態確認プログラムを含み、
   前記処理部は、
   前記状態確認プログラムを、前記ブロックチェーンに登録するための前記トランザクションを生成することを特徴とする提供装置。
5. 請求項４に記載の提供装置において、
   前記サービス提供処理プログラムは、前記状態確認プログラムによって起動され、前記電子機器の修理手配処理を行うための修理手配処理プログラムを含み、
   前記処理部は、
   前記修理手配処理プログラムを、前記ブロックチェーンに登録するための前記トランザクションを生成することを特徴とする提供装置。
6. 請求項１乃至５のいずれか一項に記載の提供装置において、
   前記サービス提供処理プログラムは、サービス提供により発生する費用を含むサービス提供データを、前記ブロックチェーンに書き込む処理を行い、
   前記処理部は、
   前記ブロックチェーンに書き込まれた前記サービス提供データに基づいて、課金額を決定する課金処理プログラムを前記ブロックチェーンに登録するための前記トランザクションを生成することを特徴とする提供装置。
7. 請求項６に記載の提供装置において、
   前記処理部は、
   前記課金処理プログラムによって決定された前記課金額を、対応する契約アカウントに対して請求する請求プログラムを前記ブロックチェーンに登録するための前記トランザクションを生成し、
   前記請求プログラムは、前記課金処理プログラムによって起動されることを特徴とする提供装置。
8. 請求項１乃至７のいずれか一項に記載の提供装置において、
   前記処理部は、
   前記サービス提供処理プログラムを、スマートコントラクトを用いて前記ブロックチェーンに登録するための前記トランザクションを生成することを特徴とする提供装置。
9. 請求項１乃至８のいずれか一項に記載の提供装置と、
   前記電子機器に対応して設けられ、前記ブロックチェーンから前記サービス提供処理プログラムを取得して前記サービス提供処理プログラムを実行する処理装置と、
   を含むことを特徴とする処理システム。
10. 請求項７に記載の提供装置と、
    前記電子機器に対応して設けられる処理装置と、
    を含み、
    前記処理装置は、
    前記請求プログラムによる請求に対する決済を行う決済プログラムを前記ブロックチェーンに登録するための前記トランザクションを生成し、
    前記決済プログラムは、前記ブロックチェーンにおける仮想通貨を用いて決済を行うことを特徴とする処理システム。

Images