JP2022000765A - アプリケーション実績処理方法、コンピュータプログラム及びアプリケーション実績処理システム - Google Patents

Abstract

【課題】アプリケーション間の情報共有を、ブロックチェーンシステムを用いて実現するアプリケーション実績処理方法、コンピュータプログラム及びアプリケーション実績処理システムを提供する。【解決手段】アプリケーション実績処理方法は、アプリケーションを提供する装置が、前記アプリケーションのユーザのアプリアカウントデータと、ブロックチェーンシステムにおける各ユーザのブロックチェーンアカウントデータとを取得し、ユーザ毎に、前記アプリケーションに紐づけられる使用実績に基づくトークンを、ユーザのブロックチェーンアカウントに付与するリクエストを前記ブロックチェーンシステムへ送信し、前記ブロックチェーンシステムは、前記トークンの有無、前記トークンの量、前記トークンの内容又は条件のデータの確認リクエストを受け付ける。【選択図】図１

Description

本出願は、２０１９年１２月２６日に出願された米国仮特許出願６２／９５３７３８号の優先権の利益を主張し、参照によってその全体が組み込まれる。

本発明は、ブロックチェーンを利用したアプリケーション実績処理方法、コンピュータプログラム及びアプリケーション実績処理システムに関する。

近年、デジタルコンテンツ（ゲーム、アニメーション、テレビコンテンツ、ラジオコンテンツ、漫画、雑誌、新聞等）に関し、個人による一次コンテンツの消費（ゲームをプレイする、アニメーションを視聴する、テレビコンテンツを視聴する、ラジオコンテンツを聴く、漫画を読む、雑誌を読む、新聞を読む等）のみならず、コミュニティによるｎ次コンテンツの消費が盛んに実施されている。つまり、デジタルコンテンツの二次商圏が拡大している。また、並行して個人（コンテンツクリエイター、スポーツ選手、芸能人等）がコンテンツを発信できるメディアの多様化が進行したことにより、これらの個人に関しても、前記デジタルコンテンツと同様、コンテンツ消費の幅が広がっている（プロスポーツ選手の私生活をＹｏｕＴｕｂｅ（登録商標） チャンネルを通じて視聴する等）。

しかも、その二次商圏では、複数のアプリケーション（例えばゲームの場合、ゲームそのもの、動画配信プラットフォーム、ＳＮＳ等）を横断して構築される。二次商圏におけるアプリケーションの横断では、アプリケーション間の情報連携が課題となる。一方のアプリケーションにおける活動を、他方のアプリケーションにおける活動で還元することで連携を実施するには、アプリケーション間で特定ユーザの各アプリケーションにおけるアカウント同士を紐づける必要がある。

アプリケーション連携においては従来、一方のアプリケーションにてユーザ情報を提供するためのＡＰＩ（Application Programming Interface）を開発して提供している（特許文献１等）。

特開２０１９−０５７７７８号公報

ＡＰＩの提供による連携では、ＡＰＩの開発・運用コスト、セキュリティのリスクの低減が課題となる。

本発明は、斯かる事情を鑑みてなされたものであり、アプリケーション間の情報共有を、ブロックチェーンシステムを用いて実現するアプリケーション実績処理方法、コンピュータプログラム及びアプリケーション実績処理システムを提供することを目的とする。

本開示の一実施形態のアプリケーション実績処理方法は、アプリケーションを提供する装置が、前記アプリケーションのユーザのアプリアカウントデータと、ブロックチェーンシステムにおける各ユーザのブロックチェーンアカウントデータとを取得し、ユーザ毎に、前記アプリケーションに紐づけられる使用実績に基づくトークンを、ユーザのブロックチェーンアカウントに付与するリクエストを前記ブロックチェーンシステムへ送信し、前記ブロックチェーンシステムは、前記トークンの有無、前記トークンの量、前記トークンの内容又は条件のデータの確認リクエストを受け付ける。

本開示によれば、ＡＰＩの開発・運用コストなしにブロックチェーンシステムを利用して低コスト且つセキュアにアプリケーション間を連携させることが可能である。

本開示のシステムの概要図である。 システムにおけるアプリケーション連携の処理の基本を示すシーケンス図である。 比較例のアプリケーション連携の既存手法の処理手順を示すシーケンス図である。 情報端末装置の構成を示すブロック図である。 管理装置の構成を示すブロック図である。 ブロックチェーンシステムにおけるノードの構成を示すブロック図である。 アプリケーション連携における認証処理手順の一例を示すシーケンス図である。 トークンの内容を確認する処理手順の一例を示すシーケンス図である。 チケット型のトークンに基づく処理実行の一例を示すシーケンス図である。 実施例１におけるシステムの概要図である。 実施例１におけるアプリケーション間の連携手順の一例を示すシーケンス図である。 実施例１におけるアプリケーション間の連携手順の一例を示すシーケンス図である。 実施例２におけるｎ次利用関連権利に相当する権利トークンの構造を示す概要図である。 実施例２におけるシステムの概要図である。 実施例２におけるアプリケーション間の連携手順の一例を示すシーケンス図である。 実施例２におけるアプリケーション間の連携手順の一例を示すシーケンス図である。

本開示をその実施の形態を示す図面を参照して具体的に説明する。

本開示において「ブロックチェーンシステム」は、相互に通信接続が可能な複数のコンピュータ及び複数のコンピュータを接続するネットワークを含み、前記複数のコンピュータの分散処理によってブロックチェーンを作成するシステムを言う。ブロックチェーンには、要求されるトランザクションが実行され、その結果が取り込まれる。

二次商圏的なコンテンツ消費の例として、一次コンテンツであるゲームのプレイを、動画配信プラットフォームで配信することが挙げられる。ゲームプレイの動画配信、特にライブ配信は、「他人のゲームプレイ動画」という二次コンテンツを「他の視聴者と一緒に視聴する」こと、また二次コンテンツを題材として「配信者と視聴者とがＳＮＳで会話する」こと、といった消費がオンラインで完結、成立している。配信された動画の視聴時間は、主要な複数の動画配信プラットフォームで合計すると数億時間／月に達すると推測されており、ゲームという一次コンテンツの二次商圏は実際に大きな盛り上がりを見せている。

一次コンテンツであるゲームの製作又は運営の事業者にとっても、このような二次商圏に関する指標、例えばゲームに関する配信のゲーム毎の視聴者数等の重要度が上がっている。例えば、数億人規模のプレイヤを抱えるオンラインゲームの中には、そのような視聴者数等の指標をＫＰＩ（Key Performance Indicator）として設定した上で、ライブ配信を軸として公式パートナープログラムを取り入れ、意図的に二次商圏の活性化を促している場合もある。公式パートナープログラムは例えば、一定条件を満たした優良配信者をパートナーとして扱い、様々な非金融的特典によってオンラインソーシャル活動をサポートするプログラムである。

しかしながら、ゲーム自体、配信プラットフォーム、ＳＮＳ等の異なるアプリケーションを横断して構築される二次商圏の活性化で課題となるのは、アプリケーション間の情報連携である。上述のゲームプレイの配信の例でも、「ゲーム」そのもののアプリケーションと、動画配信プラットフォーム用アプリケーションとの間の横断が発生している。特定のゲームに関する動画配信活動を評価して、配信者に対し、そのゲームをプレイする際に何等かの還元（アイテム付与等）を行ないたい場合、ゲーム運営事業者は、ゲームと動画配信プラットフォームとの間で配信者のアカウントを紐づける必要がある。

アプリケーション連携を行なう場合、一般的には、アカウントに対応付けられた利用履歴、実績等を含むユーザ情報を提供する側、上述の例であれば動画配信プラットフォーム側が、情報を要求する側からアクセス可能なＡＰＩを開発・運用する必要がある。しかもこのＡＰＩは、適切なプロトコル（OAuth、OpenID Connect等）に準拠した認証・認可を実施した上で、ＡＰＩへのアクセスを制御する必要がある。ここで、ＡＰＩの開発・運用コストやセキュリティリスクが課題になる。特に、大組織であってもアカウント等のユーザ情報の大規模な漏洩事故が発生してしまうと大きな損害になるため、セキュリティリスクの増大はできる限り避けるべきである。

ユーザ情報を要求してＡＰＩへアクセスする側、上述の例であれば特定のゲームの運営事業者にも、開発・運用コスト及びセキュリティリスクが課せられる。例えばセキュリティリスクとして、例えばOAuthという認可プロトコルに準拠した場合、ユーザ情報の要求側は、ユーザ情報にアクセスするための秘密情報（アクセストークン）を保管しなければならない。秘密情報の保管は、その漏洩が大きなリスクとなる。セキュリティリスク、連携するアプリケーションのＡＰＩの仕様に合わせた開発・運用コストは、連携するアプリケーションの数に比例して膨大になりかねない。

このような状況を鑑みると、アプリケーション間を横断して構築されるコンテンツの二次商圏の活性化にあたっては、ユーザ情報（主に、二次商圏の活性化に貢献する活動実績等）の低コスト且つセキュアな共有方法が求められる。

本開示のアプリケーション連携方法は、情報端末装置が、第１のアプリケーション及び第２のアプリケーションのユーザのアプリアカウントデータと、ブロックチェーンシステムにおける前記ユーザのブロックチェーンアカウントデータとを記憶し、前記第１のアプリケーションを提供する第１装置、又は、前記第２のアプリケーションを提供する第２装置へ、前記第１及び第２のアプリケーションの連携のリクエストを、前記ブロックチェーンアカウントデータと対応付けて送信し、前記連携のリクエストに基づき、前記第１装置に、前記アプリアカウントデータに対応付けられる前記ユーザの前記第１のアプリケーションの使用実績に基づくトークンの、前記ブロックチェーンアカウントデータへの付与のリクエストを前記ブロックチェーンシステムへ送信させ、前記第２装置に、前記ブロックチェーンアカウントデータに付与された前記トークンの有無、前記トークンの量、前記トークンの内容又は条件のデータを取得させる。

本開示のアプリケーション連携方法では、異なるアプリケーション間で、公開可能なデジタルアセットがトークン化されて共有される。デジタルアセットとは、各アプリケーションプログラムに紐づいた実績、権利などであって、ＢＴＣ又はＥＴＨ等のような暗号資産とは異なる。一方のアプリケーションにおけるユーザの使用実績というアセットがブロックチェーンシステムで記録されていることが他方のアプリケーションにて確認でき、これによって他方のアプリケーションに関してユーザは権利行使が可能になる。

ブロックチェーンシステムに記録されたデータは、データ構造的に、高い耐改ざん性を有するので、記録されたデータ（権利付与等）に対する不正な操作は極めて困難である。したがって、極めてセキュアな共有を実現できる。ＡＰＩの開発・運営コストが不要であるからコストも低減できる。

以下、このようなアプリケーション連携方法を具体的に説明する。

図１は、本実施形態のシステム１００の概要図である。システム１００は、ブロックチェーンシステム３００外の第１のユーザの情報端末装置１と、異なるアプリケーションＡ，Ｂ夫々の管理装置２Ａ，２Ｂとを含む。以下の実施の形態では、２つのアプリケーション間の連携を例に説明するが、３つ以上のアプリケーション間の連携であっても同様である。

管理装置２Ａは、ブロックチェーンシステム３００外のネットワークＮを介し、クライアントサーバの関係で情報端末装置１上のアプリケーションＡ用のプログラムに基づくインスタンスと通信が可能である。管理装置２Ｂについても同様に、情報端末装置１上のアプリケーションＢ用のプログラムに基づくインスタンスと通信可能である。なお、管理装置２Ａ，２Ｂは、各アプリケーションＡ，Ｂの情報端末装置１上のインスタンスによって実現されてもよい。

本実施形態のシステム１００では、ユーザは、情報端末装置１にてアプリケーションＡ及びアプリケーションＢのいずれにもサインイン（ログイン）が可能となるようにアカウント（以下、アプリアカウントと称する）を保有している。情報端末装置１には各アプリケーションＡ，Ｂのサインイン用データが、予め、又は、ユーザの入力操作によって記憶される。

情報端末装置１はまた、ブロックチェーンシステム３００におけるアカウントデータ（以下、ブロックチェーンアカウントと称する）を記憶し、ブロックチェーンシステム３００へのアクセスが可能である。本開示において「ブロックチェーンシステム」は、相互に通信接続が可能な複数のコンピュータ及び複数のコンピュータを接続するネットワークを含み、前記複数のコンピュータの分散処理によってブロックチェーンを作成するシステムを言う。

管理装置２Ａ，２Ｂはブロックチェーンアカウントを保有し、ブロックチェーンシステム３００へのトランザクションのブロードキャスト、及び、ブロックチェーンシステム３００に取り込まれたブロック内のデータの閲覧が可能である。

本実施形態のシステム１００は、ブロックチェーンシステム３００をデジタルアセット管理基盤として活用し、ユーザが使用する異なるアプリケーションＡ，Ｂ間で、公開可能なユーザの活動実績をデジタルアセットとして扱い、トークン化して共有可能とする。ここでデジタルアセットは、アプリケーションに紐づいた実績又は権利であって、暗号資産とは異なる。

活動実績、権利に相当するデジタルアセットはブロックチェーンシステム３００にてスマートコントラクトとして実装され、ユーザのアプリケーションＡ，Ｂの実行・利用に応じて、デプロイ済みである。ブロックチェーンシステム３００におけるトークンの保有状況は、デジタルアセットのスマートコントラクトによって管理される。デジタルアセットに相当するスマートコントラクトは以下、トークンコントラクトと称する。

システム１００では、管理装置２Ａ，２Ｂはそれぞれ、ユーザのブロックチェーンアカウントの認証を実行するアカウント管理機能と、アプリケーションＡ，Ｂにおける実績をデジタルアセットとしてトークン化するデジタルアセット管理機能とを有する。

アカウント管理機能においてアプリケーションＡ，Ｂ夫々の管理装置２Ａ，２Ｂは夫々、ユーザの情報端末装置１からアカウント連携が要求されると、ユーザのブロックチェーンアカウントの存在を認証する処理を実行する。

管理装置２Ａ，２Ｂにおけるブロックチェーンアカウント（後述する秘密鍵を含む）の保有、ブロックチェーンシステム３００へのトランザクションのブロードキャスト、及び、ブロックチェーンシステム３００に取り込まれたブロック内のデータの閲覧機能は、管理装置２Ａ，２Ｂが提供するアプリケーションとは分離して実装されてよい。ブロックチェーンシステム３００に関わる機能（アカウント管理機能、デジタルアセット管理機能）は、管理装置２Ａ，２Ｂとブロックチェーンシステム３００との間に実装されるＳａａＳ、ＰａａＳとして、提供されてもよい。また、これらの機能は、情報端末装置１上で稼働するアプリケーションを介してユーザが利用できてもよい。

図２は、システム１００におけるアプリケーション連携の処理の基本を示すシーケンス図である。

システム１００では、ユーザの情報端末装置１から一方のアプリケーションＡ用のプログラムを通じて管理装置２Ａへ、アプリケーションＡのアカウントデータを含むアプリケーション連携のリクエストを送信する（ステップＳ１）。

情報端末装置１、管理装置２Ａ及びブロックチェーンシステム３００の間で、ユーザのブロックチェーンアカウントの認証処理を実行する（ステップＳ２）。

管理装置２Ａはデジタルアセット管理機能に基づき、ユーザのアカウントデータに紐付けられたアプリケーションＡにおける公開可能な活動実績（暗号資産を除く）をデジタルアセットとして、ユーザのブロックチェーンアカウントへそのアセットを付与するトランザクションを作成する（ステップＳ３）。管理装置２Ａは、作成したトランザクションをブロックチェーンシステム３００へブロードキャストする（ステップＳ４）。

ブロックチェーンシステム３００では、管理装置Ａからのトランザクションを受信すると（ステップＳ５）、トランザクションを検証し（ステップＳ６）、承諾する（ステップＳ７）。ステップＳ７では、ユーザのトークンコントラクトが、トークン保有状況を更新する。

ユーザの情報端末装置１は、連携対象のアプリケーションＢ用のプログラムを通じて管理装置２Ｂへ、アプリケーションＢのアカウントデータを含むアプリケーション連携のリクエストを送信する（ステップＳ８）。

情報端末装置１、管理装置２Ｂ及びブロックチェーンシステム３００の間で、ユーザのブロックチェーンアカウントの認証処理を実行する（ステップＳ９）。

管理装置２Ｂは、ユーザのブロックチェーンアカウントに紐づくトークンの内容を確認し（ステップＳ１０）、ユーザのアプリアカウントに対し、ステップＳ１０で確認した内容に基づく連携処理を実行する（ステップＳ１１）。ブロックチェーンシステム３００に取り込まれたブロック内のデジタルアセットは、異なるアプリケーションＡ，Ｂから確認可能である。したがって、アプリケーションＡにおける実績がトークン化されてアプリケーションＢにてこれを元に還元することが可能である。

このような手順により、アプリケーションＡ，Ｂの運営事業者は、ユーザのブロックチェーンアカウントに基づく認証機能及び管理機能を実装すれば、他のアプリケーションとの連携用のＡＰＩの運用は不要である。ブロックチェーンシステム３００におけるトークンの確認であるからセキュアに実装することも可能である。

図２のシーケンス図に示した処理手順では、ユーザが使用する情報端末装置１にてユーザの操作を受け付けたことを契機に、アプリケーション連携のリクエストが管理装置２Ａへ送信されることとした。しかしながら、これに限らず、連携のリクエストの送信は任意のタイミングでもよいし、アプリケーションＡ，Ｂの処理中に開始されてもよい。管理装置２Ｂへのリクエスト送信を契機にアプリケーションＡに連携開始のリクエストが送信されてもよい。

図３は、比較例のアプリケーション連携の既存手法の処理手順を示すシーケンス図である。図３のシーケンス図は、「OAuth 2.0 Authorization Code Grant」の処理を示す。既存手法では、図３のシーケンス図に示すように、連携のリクエストを契機に、ユーザが使用するクライアントが、認可リクエスト及び認可コードのアプリケーションＸ，Ｙ同士の送受信のリダイレクトを担う。認可コードが連携対象のアプリケーションＹへ渡った後は、認可コードの検証を経てアプリケーションＸがアクセストークンをアプリケーションＹへ渡し、アプリケーションＹからアプリケーションＸにおけるユーザ情報の取得リクエストを送信し、これに応じてアプリケーションＸからアプリケーションＹへユーザ情報が送信される。

図３で示したように、既存手法では、適切なプロトコルでの認証・認可を実施した上で、アクセストークン（秘密情報）のやり取りが必要である。アプリケーションＹはアクセストークンを保管しなければならないため、アプリケーションＹの事業者はその漏洩のリスクを抱える必要があるだけでなく、連携するアプリケーションの数に比例して、このリスクや連携処理の開発コストが増大する。またアプリケーションＸ側は、図３に示したようにユーザ情報の提供のためのＡＰＩの開発・運用コスト、ユーザ情報の漏洩のリスクがあり、これも連携するアプリケーションの数に応じて増大する。連携を促進するためには、これらのリスクやコストの増大は回避されるべきである。またアプリケーションＸ側では、図３に示したようにユーザ情報の提供のためのＡＰＩの開発・運用コストが連携するアプリケーションの数に応じて増大する。連携を促進するためには、このコストの増大は回避されるべきである。

以下、図３に示したような、ＡＰＩ及びアクセストークンを使用しないアプリケーション間の連携を実現するためのシステムの具体的な構成について説明する。

図４は、情報端末装置１の構成を示すブロック図である。情報端末装置１は、例えばスマートフォン、又はタブレット端末である。情報端末装置１は、パーソナルコンピュータであってもよい。情報端末装置１は、後述する（図７）秘密鍵による電子署名処理と、認証を実行する管理装置２Ａ，２Ｂとの間でデータ通信が可能なデバイスであれば、態様は問わない。情報端末装置１は、秘密鍵管理と電子署名処理を専門に実行するデバイス（ハードウェアウォレット）とスマートフォン又はパーソナルコンピュータとの組み合わせで実現されてもよい。

情報端末装置１は、処理部１０、記憶部１１、通信部１２、表示部１３、及び操作部１４を備える。処理部１０は、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）等のプロセッサと、メモリ等を用いる。なお処理部１０は、プロセッサ、メモリ、更には記憶部１１及び通信部１２を集積した１つのハードウェア（ＳｏＣ：System On a Chip）として構成されていてもよい。

記憶部１１はフラッシュメモリを用い、情報端末プログラム１Ｐを始めとする処理部１０が参照するプログラム、データが記憶される。情報端末プログラム１Ｐは、コンピュータを、本開示のシステム１００の情報端末装置１として機能させるためのプログラムである。記憶部１１には、ブロックチェーンアカウントが記憶される。また記憶部１１には、異なるアプリケーションＡ，Ｂを含む各アプリケーションのアプリアカウントが記憶され、これらのアカウントデータを用いてアプリケーションにサインインが可能である。

記憶部１１に記憶されている情報端末プログラム１Ｐは、コンピュータから読み取り可能な記憶媒体８に記憶されていた情報端末プログラム８Ｐを処理部１０が読み出して記憶部１１に記憶したものであってもよい。

記憶部１１には、図４に示すように、ブロックチェーンシステム３００におけるユーザの秘密鍵が記憶されていてもよい。秘密鍵は、処理部１０のメモリ又は記憶部１１に書き換え不可に記憶されているとよい（ウォレットのチップ化）。秘密鍵は、上述したように秘密鍵専門のハードウェアウォレットにて管理されてもよい。

通信部１２は、管理装置２Ａ，２Ｂ及び他の通信装置との通信接続を実現する通信モジュールである。通信部１２は、ネットワークカード、無線通信デバイス又はキャリア通信用モジュールを用いる。通信部１２は、管理装置２Ａ，２Ｂの通信部２２と近距離通信（Near Field Communication）によって通信を実現するモジュールを用いてもよい。

表示部１３は液晶パネル又は有機ＥＬディスプレイ等のディスプレイ装置を用いる。操作部１４は、ユーザの操作を受け付けるインタフェースであり、物理ボタン、ディスプレイ内蔵のタッチパネルデバイス、スピーカ及びマイクロフォン等を用いる。操作部１４は、物理ボタン又はタッチパネルにて表示部１３で表示している画面上で操作を受け付けてもよいし、マイクロフォンにて入力音声から操作内容を認識し、スピーカで出力する音声との対話形式で操作を受け付けてもよい。

図５は、管理装置２Ａ，２Ｂの構成を示すブロック図である。管理装置２Ａ，２Ｂは、サーバコンピュータであってもよいし、デスクトップ型又はラップトップ型パーソナルコンピュータであってもよいし、スマートフォン又はタブレット端末等の通信端末であってもよい。管理装置２Ａ，２Ｂは、所謂インターネット等のネットワークを介した遠距離通信が可能なデバイスに限らず、情報端末装置１との間で近距離通信によってデータ通信するデバイスであってもよい。

管理装置２Ａ，２Ｂはそれぞれ、処理部２０、記憶部２１、及び通信部２２を備える。図５では、管理装置２Ａのみについて示す。管理装置２Ｂの構成は、管理装置２Ａと同様であるから詳細な説明を省略する。

処理部２０は、ＣＰＵ、ＧＰＵ等のプロセッサと、メモリ等を用いる。処理部２０は、記憶部２１に記憶されている管理プログラム２Ｐに基づき、認証機能と、トランザクションの作成、トランザクションの実行を含むブロックチェーンシステム３００におけるアセット管理機能とを実現する。記憶部２１は、ハードディスク又はフラッシュメモリを用い、管理プログラム２Ｐを始めとする処理部２０が参照するプログラム、データを記憶する。

記憶部２１に記憶されている管理プログラム２Ｐは、コンピュータから読み取り可能な記憶媒体９に記憶されていた管理プログラム９Ｐを処理部２０が読み出して記憶部２１に記憶したものであってもよい。

通信部２２は、情報端末装置１又はブロックチェーンシステム３００との通信接続を実現する通信モジュールである。通信部２２は、ネットワークカード、無線通信デバイス又はキャリア通信用モジュールを用いる。通信部２２は、情報端末装置１の通信部１２と近距離通信によって通信を実現するモジュールを用いてもよい。

図６は、ブロックチェーンシステム３００におけるノード３０の構成を示すブロック図である。ノード３０は、サーバコンピュータであってもよいし、デスクトップ型又はラップトップ型パーソナルコンピュータであってもよいし、スマートフォン等の通信端末機器であってもよい。ノード３０は、処理部３１、記憶部３２及び通信部３３を備える。またノード３０は、少なくとも処理部３１及び通信部３３を備える装置であれば、処理部３１の一部によってノードの一部又は全部を構成することができる。

処理部３１は、ＣＰＵ、ＧＰＵ等のプロセッサと、メモリ等を用いる。処理部３１は、プロセッサ、メモリ、更には記憶部３２及び通信部３３を集積した１つのハードウェアとして構成されていてもよい。処理部３１のメモリには、ノード３夫々独自に所有する秘密鍵が記憶されているとよい。そして処理部３１は、記憶部３２に記憶されているノードプログラムに基づいた各処理を実行し、汎用コンピュータをブロックチェーンシステム３００におけるノードとして機能させる。

記憶部３２は、ハードディスク又はフラッシュメモリを用い、ノードプログラムを始めとする処理部３１が参照するプログラム、データを記憶する。記憶部３２は、ブロックチェーンを記憶する。ノードプログラムには、後述するスマートコントラクト（トランザクションに対する所定の演算処理を実行する処理部３１）として機能させるためのプログラムが含まれる。上述の秘密鍵は記憶部３２に記憶されてもよい。記憶部３２は、秘密鍵に基づく公開鍵及びアドレスを記憶してもよい。

通信部３３は、ノード３０の相互通信を実現する通信モジュールである。通信部３３は、ネットワークカード、光通信用デバイス、又は無線通信デバイス等を用いる。

このように構成されるシステム１００におけるアプリケーション連携についてシーケンス図を参照しながら詳細を説明する。

基本の処理の前に、アプリケーションＡ，Ｂにおける活動実績等に応じてユーザは、デジタルアセットを保有する。ユーザの情報端末装置１は、これらのデジタルアセットを管理するためのブロックチェーンアカウントを記憶する。一般的なブロックチェーンアカウントには非対称鍵ペアが１つ以上紐づいているため、基本の処理のステップＳ２にて、各アプリケーションＡ，Ｂの管理装置２Ａ，２Ｂは、これを活用してユーザの認証（本当にそのブロックチェーンアカウントの持ち主であるか）を行なうことができる。

以下に、非対称鍵を活用したチャレンジレスポンス認証について説明する。図７は、アプリケーション連携における認証処理手順の一例を示すシーケンス図である。図７のシーケンス図に示す手順は、図２のシーケンス図に示した処理における「アカウントの認証処理」の詳細に相当する。

情報端末装置１の処理部１０は、アカウント連携のリクエスト（Ｓ１）に伴い、ブロックチェーンアカウントの識別子を管理装置２Ａ，２Ｂへ送信する（Ｓ１０１）。

管理装置２Ａ（又は２Ｂ）の処理部２０は、通信部２２によってブロックチェーンアカウントの識別子を受信すると（ステップＳ２０１）、ブロックチェーンアカウントの存在をブロックチェーンシステム３００に照会する（ステップＳ２０２）。

ステップＳ２０２において処理部２０は、ステップＳ２０１で受信した識別子がブロックチェーンシステム３００のアカウントとして存在し、何等かのトークンを保有しているか否かを判断するとよい。ステップＳ２０２において処理部２０は、情報端末装置１から送信されたブロックチェーンアカウントの識別子に紐づく公開鍵そのもの、若しくは、その算出に必要な情報をブロックチェーンシステム３００から取得する。

管理装置２Ａ（又は２Ｂ）の処理部２０は、疑似乱数を生成し（ステップＳ２０３）、作成した疑似乱数を、連携依頼元の情報端末装置１へ送信する（ステップＳ２０４）。

情報端末装置１の処理部１０は、管理装置２Ａ（又は２Ｂ）から疑似乱数を受信し（ステップＳ１０２）、ユーザのブロックチェーンアカウントに紐づく秘密鍵によって、受信した疑似乱数に対する電子署名を生成する（ステップＳ１０３）。処理部１０は、生成した電子署名を、疑似乱数を送信してきた管理装置２Ａ（又は２Ｂ）へ送信する（ステップＳ１０４）。

管理装置２Ａ（又は２Ｂ）の処理部２０は、電子署名を受信し（ステップＳ２０５）、ステップＳ２０１で受信した識別子から公開鍵を決定する（ステップＳ２０６）。ステップＳ２０６において処理部２０は、公開鍵そのものを取得している場合にはその公開鍵を読み出し、算出に必要な情報を取得している場合は公開鍵を算出する。

処理部２０は、ステップＳ２０３で生成した疑似乱数と、ステップＳ２０６で決定した公開鍵を用い、ステップＳ２０５の電子署名の正当性を検証する（ステップＳ２０７）。ステップＳ２０７にて正当であると導出できた場合、管理装置２Ａ（又は２Ｂ）は、連携リクエストの送信元の情報端末装置１のユーザのブロックチェーンアカウントの認証に成功したと判断する。

基本の処理においてステップＳ３（図２参照）では、管理装置２Ａ又は管理装置２Ｂは、認証に成功した場合、アプリケーション連携を求めるユーザに、そのアプリケーションＡ又はアプリケーションＢに関するトークンを付与する。

付与されるトークンの性質、トークン付与の条件、又はプロセスは、特に問わない。付与されるトークンのパターンを以下に挙げる。

トークンの性質については大きく以下の３つ軸が考えられる。

［代替可能性］
代替可能（ＦＴ：Fungible Token）であってもよいし、代替不可能（ＮＦＴ：Non-Fungible Token）であってもよい。

［譲渡可能性］
付与されるトークンは、譲渡可能であってもよいし、譲渡不可能であってもよい。

［焼却可能性］
付与されるトークンは、ブロックチェーンシステム３００において焼却可能であってもよいし、焼却不可能であってもよい。
焼却が可能である場合、焼却はトークンの発行者（管理装置２Ａ，２Ｂ）が可能である態様であってもよいし、トークンを保有するユーザが可能であってもよい（一定の条件を満たすことで可能であればよい）。
「焼却」は、トークンの量を減らすことで表現されてもよいし、焼却フラグ等のメタデータで表現されてもよい。

上述の３つの軸における選択の組み合わせによってトークンの基本的な性質が定義されてよい。例えば、アプリケーションＡにおける何等かの実績（成績、達成度等）に相当するトークンは、他人に譲渡できない保有者であるユーザ固有のものであり、半永続的に利用できることが望ましいので、譲渡不可能且つ代替不可能且つ焼却不可能、といった組み合わせで実現されることが妥当である。代替不可能なトークンの場合、トークン固有の識別情報、アプリケーションＡによって作成される固有の画像、といったデータで単位トークンの識別が可能である。代替可能なトークンであれば、量の概念が存在するため、トークン発行量又は各ブロックチェーンアカウントの保有可能量、譲渡可能量、焼却可能量等に上限が設けられてもよい。また、トークンに関するメタデータ（例えば、実績アセットの画像、詳細な説明といった比較的容量が大きいデータ等）は、ブロックチェーンシステム３００内で保有してもよいし、ブロックチェーンシステム３００外で保有されてもよい。ブロックチェーンシステム３００外で保有される場合は、例えば特定のリンク情報（ＵＲＬ）でメタデータを例えばＪＳＯＮ形式で公開し、そのリンク情報をブロックチェーンシステム３００内でトークンと紐付けて記録するという手法が考えられる。

トークンは上述したように、トークンコントラクトとして実装されてよい。この場合、譲渡不可能且つ代替不可能なトークン（Non-Fungible Token）の場合、デプロイされたトークンコントラクトは例えば移転の呼び出しを無効化させておくとよい。逆に、譲渡可能なトークンの場合には移転の呼び出しが可能であり、また、量の指定が可能な状態でデプロイされるとよい。

トークン付与の条件については、各アプリケーションＡ，Ｂでの概念、指標と紐付けて設定可能である。

トークン付与（Ｓ３）のプロセスについては例えば、アプリケーションＡの管理装置２Ａが事前に発行し、管理装置２Ａが保有（管理可能）するブロックチェーンアカウントに保有されていたトークンを、ユーザのブロックチェーンアカウントに譲渡することで実現されてもよい。又は、管理装置２Ａが、ユーザのブロックチェーンアカウントに対してトークンを直接的に発行してもよい。これらの譲渡又は発行は、管理装置２Ａが任意のタイミングで行なってもよいし、付与条件を満たしたユーザのアプリケーション連携を含むトークン付与の要求があったタイミングで実行されてもよい。

基本の処理においてステップＳ１０（図２参照）では、連携先の管理装置２Ｂの処理部２０は、ユーザのブロックチェーンアカウントに紐づくトークンの内容を確認する。この確認処理は基本的に、ブロックチェーンアカウントの認証が済んでいれば任意のタイミングで、ユーザのブロックチェーンアカウントに保有されているトークン情報を、ブロックチェーンシステム３００上で参照すればよい。任意のタイミングでよいが、トークンの確認タイミングは、以下の３つのパターンが考えられる。
（１）情報端末装置１（ユーザ）からのリクエストを受信したタイミング
（２）アプリケーションＢが、参照を必要とするタイミング
（３）ユーザに対してトークンが付与されたタイミング

（３）のタイミングについてシーケンス図を参照して説明する。図８は、トークンの内容を確認する処理手順の一例を示すシーケンス図である。確認の主体はアプリケーションＢの管理装置２Ｂである。図８のシーケンス図は、図２の基本の処理におけるステップＳ９まで、つまり、連携する管理装置２Ａ及び管理装置２Ｂの双方でブロックチェーンアカウントの認証処理が完了している状態で実施される。

管理装置２Ｂの処理部２０は、所定の監視タイミングが到来したか否かを判断する（ステップＳ４０１）。監視タイミングが到来していないと判断された場合（Ｓ４０１：ＮＯ）、処理部２０は、処理をステップＳ４０１へ戻し、タイミングが到来したと判断するまで待機する。所定の監視タイミングは、例えば、一定の周期時間の到来である。その他何等かのイベントによって監視タイミングの到来を判断してもよい。

所定の監視タイミングが到来したと判断された場合（Ｓ４０１：ＹＥＳ）、ブロックチェーンシステム３００上のユーザのブロックチェーンアカウントに、アプリケーションＡの管理装置２Ａによってトークンが付与されているか否かを判断する（ステップＳ４０２）。トークンが付与されていると判断された場合（Ｓ４０２：ＹＥＳ）、確認ができたと判断する（ステップＳ４０３）。

ステップＳ４０２でトークンが付与されていないと判断された場合（Ｓ４０２：ＮＯ）、処理部２０は処理をステップＳ４０１へ戻す。

ステップＳ４０１を継続的に繰り返す間に、図２の基本の処理で示したように、ステップＳ３〜Ｓ７によって、アセット付与のトランザクションが承認され、ブロックチェーンシステム３００のブロックに取り込まれると、ステップＳ４０２で付与されたと判断し、トークン付与の検知が可能である。

この場合、監視タイミングを適宜設定することで、アプリケーションＡの管理装置２Ａによってユーザに対してトークンが付与されると直ちに、アプリケーションＢの管理装置２Ｂで、これを把握することが可能になる。

そもそも、ブロックチェーンシステム３００上で稼働するスマートコントラクト（トークンコントラクト）は、ブロックチェーンシステム３００外の装置へ直接的にアクセスすることが困難である。ブロックチェーンシステム３００内のノード３等が主体となってアプリケーションＢの管理装置２Ｂに対してトークン付与を通知することは難しい。よって、ブロックチェーンシステム３００上における情報更新をできるだけリアルタイムで把握する必要がある場合には、図８に示したように、対象となるブロックチェーンアカウント又は対象のトークンに関するデータの更新を継続的に監視することで達成できる。

本実施形態で付与されるトークンは、上述したように、アプリケーションと紐付けて発行される実績又は権利であり、所謂ＢＴＣ，ＥＴＨ等の暗号資産とは異なる。したがって、トークンの発行元となるアプリケーションＡの管理装置２Ａ、又はアプリケーションＡを管理する事業者がトークンの価値に影響する。このような場合、確認プロセスにおいて、トークンの保有のみならず、その発行元を確認できることが重要になる。

ブロックチェーンのトランザクションは基本的に、これを実行するブロックチェーンアカウントと紐づいた秘密鍵に基づいて生成された電子署名の検証が行われた上で承認（承諾）される。そのため、トークンを発行するトランザクションを実行したブロックチェーンアカウントは暗号学的に検証が可能である。つまり、トークン発行元のアプリケーションＡ又はアプリケーションＡを管理する事業者がトークン発行に用いられた秘密鍵と対応する公開鍵（ブロックチェーンアカウントアドレス、公開鍵を算出可能なデータ）を公開しておけば、連携先のアプリケーションＢ又はその管理事業者は、トークンの発行元の確認を正確に実行することができる。発行元の検証を可能とする形式で実施されてもよい。アプリケーションＢの事業者にとっては、ユーザのブロックチェーンアカウントに対するトークンの付与を確認できるだけでは承認できない場合がある。ブロックチェーンアカウントと紐づいているため、トークンが、アプリケーションＡの事業者によって正当に付与されたものであるのかを検証することができるため、このようにして発行元の検証をも実施することができる。

基本の処理においてステップＳ１１（図２参照）では、確認されたトークンに紐づく権利に基づき、連携先のアプリケーションＢの管理装置２Ｂによって何等かの処理が認可される。トークンに紐づいた権利には、大きく分けて以下の２つがある。
（１）永続的に権利行使が可能なパターン（会員権型）
（２）一定回数の権利行使によって権利が失われるパターン（チケット型）

（１）の会員権型については、ステップＳ２、Ｓ９の認証処理、ステップＳ１０のトークン確認処理さえ実行されれば、以後いつでも、権利行使が可能になる。（２）のチケット型については、管理装置２Ｂにおいて何等かの形式で権利行使できる回数や権利行使された回数を記録するなどして、権利行使が可能であるかどうかのデータを記憶しておく必要がある。例えば、トークンの保有量で権利行使できる回数を管理装置２Ｂの内外の記憶装置に記憶しておき、アプリケーションＢ内で権利が行使される都度に回数を削減してもよい。権利行使の元となるトークンが、権利の行使の都度に一部又は全部焼却されれば、残りの権利行使可能回数がブロックチェーンシステム３００上で確実に管理可能である。

図９は、チケット型のトークンに基づく処理実行の一例を示すシーケンス図である。アプリケーションＡでの実績に基づき付与されたトークンを元にアプリケーションＢにおける処理を所望するユーザの情報端末装置１からの要求に応じて以下の処理が実行される。

情報端末装置１の処理部１０は、ユーザの操作部１４における操作（権利行使の意思）に基づいて、アプリケーションＢの管理装置２Ｂに対し、ユーザのブロックチェーンアカウントの識別子を送信する（ステップＳ１１１）。

管理装置２Ｂの処理部２０は、ユーザのブロックチェーンアカウントの識別子を受信し（ステップＳ４１１）、受信した識別子に対応付けられているトークンの有無、量又は条件を確認（取得）する（ステップＳ４１２）。

情報端末装置１の処理部１０は、アプリケーションＡから付与されたトークンを所望の権利行使に応じた量で焼却するトランザクションを作成する（ステップＳ１１２）。

処理部１０は、ステップＳ１１２で作成したトランザクションを、ブロックチェーンシステム３００へブロードキャスト（送信）する（ステップＳ１１３）。

ブロックチェーンシステム３００では、ステップＳ１１３でブロードキャストキャストされたトランザクションを受信する（ステップＳ３０１）。ブロックチェーンシステム３００は、受信したトランザクションをユーザのブロックチェーンアカウントで検証し（ステップＳ３０２）、承諾する（ステップＳ３０３）。

ステップＳ３０３の承諾によってトランザクションはブロックに取り込まれ、ユーザのブロックチェーンアカウントに対応付けられていたアプリケーションＡからのトークンは、ステップＳ１１２で指定された量だけ焼却される。

管理装置２Ｂの処理部２０は、ステップＳ４１２から所定時間経過後、又は情報端末装置１からの通知に応じてステップＳ４１１で受信した識別子に対応付けられているトークンの有無、量又は条件を確認（取得）する（ステップＳ４１３）。

処理部２０は、ステップＳ４１３で取得したトークンの有無、量又は条件は、ステップＳ４１３で取得したトークンの有無、量又は条件と比較して、一部又は全部が焼却されているか否かを判断する（ステップＳ４１４）。

焼却されていない（変化がない）と判断された場合（Ｓ４１４：ＮＯ）、処理部２０は、ステップＳ４１３へ戻し、所定時間経過、又は情報端末装置１からの通知イベント等を契機として再度確認する。

焼却されている（変化した）と判断された場合（Ｓ４１４：ＹＥＳ）、処理部２０は、要求及び焼却されたトークンの内容、量又は条件に応じてアプリケーションＢにおけるユーザへの特典となる処理を実行し（ステップＳ４１５）、処理を終了する。

図９のシーケンス図に示した処理により、ユーザに付与されたアプリケーションＡでの実績に基づくトークンが焼却され、チケットのようにしてトークンの焼却を代償とした特典がユーザに与えられる。

図９のシーケンス図に示したようなチケット型の権利行使は、基本的に、権利行使の主体であるユーザが使用する情報端末装置１と、権利行使を確認する管理装置２Ａ，２Ｂとによって互いに通信しながら実施される。もちろん、情報端末装置１と管理装置２Ａ，２Ｂとの間のような所謂インターネットを含む遠距離通信を介した権利行使の実施に限られない。管理装置２Ａ，２Ｂの具体的な適用例は例えば、ＰＯＳレジと連動した決済関連の権利行使を行なうデバイス、スマートロックデバイスと連動して権利行使（開錠）を行なうデバイス、コネクテッドカーと連動して権利行使（ドア開錠やエンジン始動）を行なうデバイス等が考えられる。これらの近距離通信での通信を経て実施されてもよい。また、このようなチケット型の権利行使は、トライアル型の権利（月額課金制のメディアやコミュニティで提供されるコンテンツを時間や回数の制限付きで閲覧できる権利等）とも相性が良く、さらにトークンが譲渡可能であれば流動による拡散も期待できるため、マーケティング施策などと組み合わせて実施されてもよい。

なお、これらの権利行使は情報端末装置１と管理装置２Ａ，２Ｂがデジタル化された情報を通信することで行われるが、その結果として行使される権利の範囲がデジタル完結する必要はない。例えば、ＩｏＴ（Internet of Things）が高度に発達した環境（スマートシティなど）であれば、その環境下にある施設やモビリティを介してパーソナライズされたサービスを提供する権利をトークンとして発行してもよい。例えばそれは、施設やその内部で提供される設備（エレベータ、空調機器、照明機器、インターネット回線機器等）、モビリティ（タクシー、バス等）の優先的な利用権であってもよい。また、施設が販売店舗の場合、特定の顧客が有する権利を考慮した在庫管理を行ってもよい。

上述のアプリケーション連携を、複数の実施例を参照して具体的に説明する。

［実施例１］
実施例１では、二次商圏における実績まで考慮したキャンペーン又はロイヤリティプログラムでの活用を例にアプリケーション連携を説明する。デジタルコンテンツビジネスでは、二次商圏の活用が重要な課題である。そこで、このような課題を解決することを目的とし、一次商圏活動（ゲームであれば、ゲームの中で完結した活動）のみならず、二次商圏活動（ゲームのプレイ動画配信）までを評価し、それらの活動に対して還元を行なうキャンペーン又はロイヤリティ付与のプログラムを構築できる。

図１０は、実施例１におけるシステム１００の概要図である。実施例１ではアプリケーションＡが動画配信プラットフォーム（アプリケーション）であって、アプリケーションＢが一次商圏のゲーム事業者によって提供されるサービスに関するアプリケーションである。図１０は、図１に示したシステム１００の概要に対応し、アプリケーションＡ，Ｂを夫々、動画配信プラットフォーム及びゲームとしたものである。

ゲームのプレイ動画の配信では、動画配信プラットフォーム上でのユーザの活動が二次商圏活動に相当するので、その動画配信プラットフォームでの活動の実績をトークン化し、ゲームの運営事業者がそのトークンを参照できるようにすることで、キャンペーン又はロイヤリティを付与するシステムが構築できる。

図１１及び図１２は、実施例１におけるアプリケーション間の連携手順の一例を示すシーケンス図である。図１１及び図１２のシーケンス図では、ゲームと動画配信プラットフォームとの間の連携を示す。図１１及び図１２のシーケンス図に示す処理手順の内、図２の基本の処理手順に示した処理から変更のない手順については同一の符号を付して詳細な説明を省略する。

情報端末装置１からアプリケーション連携のリクエストが送信されると（Ｓ１）、動画配信プラットフォームを提供する管理装置２Ａと情報端末装置１及びブロックチェーンシステム３００の間で、認証処理が実行される（Ｓ２）。

認証処理が完了している状態で管理装置２Ａの処理部２０は、連携要求に含まれていたユーザのアプリアカウント（サービスアカウント）に基づき、ユーザの動画配信プラットフォームの使用実績が一定条件を満たすか否かを判断する（ステップＳ２２１）。

処理部２０は、一定条件を満たさないと判断された場合（Ｓ２２１：ＮＯ）、処理をステップＳ２２１へ戻し、条件を満たすまで待機する。一定条件を満たさないと判断された場合（Ｓ２２１：ＮＯ）、連携条件を満たさないと情報端末装置１へ通知して処理を終了させるとよい。

ステップＳ２２１において処理部２０は、動画配信の時間数、動画配信の再生回数、動画配信の視聴者数、ライブ配信時の視聴者数、コメント数等に対して一定条件を満たすか否かを判断するとよい。また処理部２０は、動画視聴の時間数、動画視聴回数、動画に対する「投げ銭」の金額の総計に基づいて判断してもよい。一定条件は予め、記憶部２１に記憶してあり、管理者によって書き換え可能であってもよい。一定条件には、配信した動画にゲームアプリケーションが含まれていること、視聴した動画にゲームアプリケーションが含まれていることが含まれていてもよい。

一定条件を満たすと判断された場合（Ｓ２２１：ＹＥＳ）、処理部２０は、ステップＳ１，Ｓ２で受信したブロックチェーンアカウントに対し、動画配信プラットフォームの使用実績に基づいて、アセット（実績）を実績トークンとして付与するトランザクションを作成する（ステップＳ２２２）。処理部２０は、作成したトランザクションをブロードキャストする（Ｓ４）。

ブロードキャストされたトランザクションは、ブロックチェーンシステム３００にて受信され（Ｓ５）、検証され（Ｓ６）、承諾される（Ｓ７）。

情報端末装置１の処理部１０は、ゲームアプリケーションの管理装置２Ｂへ、アプリケーション連携のリクエストを送信する（Ｓ８）。これにより管理装置２Ｂと情報端末装置１及びブロックチェーンシステム３００の間で、認証処理が実行される（Ｓ９）。

管理装置２Ｂの処理部２０は、ユーザのブロックチェーンアカウントについて認証処理が完了している状態で、ブロックチェーンアカウントに紐づく実績トークンを確認する（Ｓ４２１）。ステップＳ４２１で実績トークンが確認できなかった場合、連携処理はこの時点で中断される。この場合、連携に失敗したことが情報端末装置１に通知されるとよい。

内容が確認できたことで実施例１のゲームアプリケーションの管理装置２Ｂの処理部２０は、ユーザのブロックチェーンアカウントに対し、以後、ゲームアプリケーション又は連携先の動画配信プラットフォームで行使可能な権利の権利トークンを付与するトランザクションを作成する（ステップＳ４２２）。

管理装置２Ｂの処理部２０は、ステップＳ４２２で作成したトランザクションをブロックチェーンシステム３００へブロードキャスト（送信）する（ステップＳ４２３）。

ステップＳ４２３で送信されたトランザクションは、ブロックチェーンシステム３００で受信され（ステップＳ３２１）、検証され（ステップＳ３２２）、承諾される（ステップＳ３２３）。

これにより、ユーザは動画配信プラットフォームにおける使用実績に基づいてゲームアプリケーションから後に使用できる権利トークンを得られる。この際、ＡＰＩは使用されないし、ブロックチェーンシステム３００ではトランザクションを受信し、検証し、承諾すればよく（アセットはトークンコントラクトとして実装される）、大掛かりな工程は不要である。

権利トークンは、ゲームアプリケーションで行使可能としてユーザに還元するもののみならず、動画配信プラットフォームを含むゲームアプリケーション以外のアプリケーションで利用可能な権利であってもよい。例えば権利としては、ゲームアプリケーションと関連するグッズを販売する電子商取引サイトで、一定の割引が受けられる権利でもよい。又は、権利は、ゲームアプリケーションと関連する同一の事業者から提供される他のゲームアプリケーション（続編であってもよい）のβ版テストに参加できる権利でもよい。又は、権利は、ゲームアプリケーションと関連するコミュニティ（グループチャット、サロン）に参加できる権利であってもよい。又は、権利は、ゲームアプリケーションと関連のある特定の施設（実体でも仮想でもよい）に入場できる権利であってもよい。

ゲームアプリケーションの提供事業者は、このような実績と権利を自由に組み合わせてゲームの二次商圏を活性化させるためのキャンペーンやロイヤリティの付与システムを構築することができる。もちろん、ゲームに関する実績又は権利は、上述の例には限られない。動画配信プラットフォームの使用のみならず、ゲームアプリケーションの関連アプリケーションをアプリケーションＡとし、関連アプリケーションからアクセスする電子商取引サイト上でゲーム関連グッズを一定金額分購入したことを実績としてもよい。また、ＳＮＳアプリケーションをアプリケーションＡとし、ＳＮＳ上でゲームアプリケーションに関するハッシュタグ付きの投稿を一定数以上行なったことを実績としてもよい。また、ｅＳｐｏｒｔｓの大会運営に関連するシステムをアプリケーションＡとし、特定の大会で一定の成績を収めたことを実績としてもよい。

このようにゲーム以外のアプリケーション（二次商圏）上で発生する価値のある活動であれば、どのような活動でも、ゲームアプリケーションに関する実績と見なされ得る。当然ゲーム以外に対しても同様にして二次商圏の活性化を促すことができる。

二次商圏における実績のみならず、一次商圏における実績を二次商圏で活用することによって二次商圏の活性化を習うようにしてもよい。ゲームアプリケーションでの実績（特定のステージをクリア、一定のスコア獲得、ランキング上位に入る）に対して実施例１で説明したような権利で還元を行なうことによって、ゲーム内外を横断しながら多角的にゲームに対するエンゲージメントを高めることが期待できる。

なお、実績を保有するユーザに対し、実績が発生するアプリケーション（動画配信プラットフォーム等）の提供者でも実績を直接的に活用したいアプリケーション（ゲームアプリケーション等）の提供者でもない第三者が、実績管理専用のアプリケーションを提供してもよい。もちろん、このような実績管理アプリケーションでは、単一のアプリケーションにまつわる実績だけでなく、複数のアプリケーションにまつわる実績を横断的に管理できてもよい。

［実施例２］
実施例２では、著作物の二次利用（イラスト投稿等）への活用を例に説明する。漫画、イラスト、動画等の著作物の違法なデジタルコンテンツ化、及びその無料配信を防ぎつつ、適切なデジタルコンテンツの流通を活性化させることに、本実施形態のアプリケーション連携方法が寄与できる。

様々なデジタルコンテンツが多様なアプリケーションを横断して流通している現状、これらの漫画等の著作物のｎ次利用管理を行なう場合、複数のアプリケーション間の連携は必須である。しかしながら、各アプリケーション間で連携を設計、開発、運用することは、連携コストが膨大となる。何等かの共通基盤システムを構築し、そこに各アプリケーションが接続するようなモデルも考えられるが、その共通基盤システムが単独の事業者、組織によって管理・運用される場合、その単独の事業者、組織がシステムのＳＰＯＦ（Single Point Of Failure）となる。またその事業者、組織が管理者権限をもって恣意的に他のステークホルダーの利益を侵害するリスクもある。この場合、共通基盤システムに連携するアプリケーションの数が増大するほど、そのリスクは深刻になる。即ち、以後、より多くのアプリケーションを横断して行なわれる著作物のｎ次利用管理システムには、コスト、冗長性・信頼性の課題を解決したアプリケーション連携の方法が求められる。

そこで、実施例２では、本実施の形態のアプリケーション連携方法を、原著作物のｎ次利用管理に適用する例を挙げて説明する。

図１３は、実施例２におけるｎ次利用関連権利に相当する権利トークンの構造を示す概要図である。権利トークンは、図１３に示すように、原著作物である「コンテンツ」のＩＤに対して複数発行され得る。「ＩＤ」は原著作物のデジタルコンテンツ（データ）を一意に特定できる識別子（以下、コンテンツＩＤと称する）である。コンテンツＩＤの具体例としては、ＵＲＬ、ＤＩＤ（Decentralized IDentifier）、ＩＰＦＳ（Inter Planetary File System）のコンテンツアドレス、若しくは、これらの組み合わせ、又は、コンテンツ自体のハッシュが挙げられる。

実施例２では、ブロックチェーンシステム３００内にデプロイされているトークンコントラクトにて、各デジタルコンテンツに対してコンテンツＩＤと紐付けてトークンを管理する。これにより、ｎ次利用関連権利に基づく商圏活性を実現できる。

図１４は、実施例２におけるシステム１００の概要図である。実施例２ではアプリケーションＡが出版社システム（コンテンツの権限管理に関するアプリケーション）であって、アプリケーションＢが画像、動画などのコンテンツの投稿が可能なＳＮＳ（以下、単にＳＮＳと証する）を使用するためのアプリケーションである。図１４は、図１に示したシステム１００の概要に対応し、アプリケーションＡ，Ｂを夫々、出版社システム及びＳＮＳとしたものである。

図１５及び図１６は、実施例２におけるアプリケーション間の連携手順の一例を示すシーケンス図である。図１５及び図１６のシーケンス図では、出版社システムとＳＮＳプラットフォームとの間の連携を示す。図１５及び図１６のシーケンス図に示す処理手順の内、図２の基本の処理手順に示した処理から変更のない手順については同一の符号を付して詳細な説明を省略する。

出版社システムの管理装置２Ａは、管理装置２Ｂへ、ＳＮＳでデータを二次利用できるように漫画データ（デジタルコンテンツ）を提供（送信）する（ステップＳ２３１）。

ＳＮＳの管理装置２Ｂは、漫画データを受信し（ステップＳ４３１）、記憶しておく（ステップＳ４３２）。

そして、ＳＮＳで、ステップＳ２３１にて提供された漫画データを使用することを希望するユーザによって、情報端末装置１からアプリケーション連携のリクエストが送信される（Ｓ１）。出版社システムのシステムサービスを提供する管理装置２Ａと情報端末装置１及びブロックチェーンシステム３００の間で、認証処理が実行される（Ｓ２）。

認証処理が完了している状態で管理装置２Ａの処理部２０は、連携要求に含まれていたユーザのアプリアカウント（サービスアカウント）に基づき、ユーザが出版社システム（使用権限管理）へ一定の対価の支払いを済ませているか否か等の条件を満たしているか否かを判断する（ステップＳ２３２）。

処理部２０は、一定条件を満たさないと判断された場合（Ｓ２３２：ＮＯ）、処理をステップＳ２３２へ戻し、条件を満たすまで待機する。一定条件を満たさないと判断された場合（Ｓ２３２：ＮＯ）、連携条件を満たさないと情報端末装置１へ通知して処理を終了させるとよい。

ステップＳ２３２において処理部２０は、ユーザによるコンテンツ利用に係る対価の支払い以外に、サービスにおけるポイント、又は権利トークン所有等を一定条件として判断してもよい。

一定条件を満たすと判断された場合（Ｓ２３２：ＹＥＳ）、処理部２０は、ステップＳ１，Ｓ２で受信したブロックチェーンアカウントに対し、対価の支払いを条件とした権利トークンを付与するトランザクションを作成する（ステップＳ２３３）。処理部２０は、作成したトランザクションをブロードキャストする（Ｓ４）。

ブロードキャストされたトランザクションは、ブロックチェーンシステム３００にて受信され（Ｓ５）、検証され（Ｓ６）、承諾される（Ｓ７）。

情報端末装置１の処理部１０は、ＳＮＳの管理装置２Ｂへ、アプリケーション連携のリクエストを送信する（Ｓ８）。これにより管理装置２Ｂと情報端末装置１及びブロックチェーンシステム３００の間で、認証処理が実行される（Ｓ９）。

管理装置２Ｂの処理部２０は、ユーザのブロックチェーンアカウントについて認証処理が完了している状態で、ブロックチェーンアカウントに紐づく権利トークンを確認する（Ｓ４３３）。ステップＳ４３３で権利トークンが確認できなかった場合、連携処理はこの時点で中断される。この場合、連携に失敗したことが情報端末装置１に通知されるとよい。

内容が確認できたことで実施例２のＳＮＳの管理装置２Ｂの処理部２０は、ＳＮＳ上で、ユーザのアプリアカウントデータに対してステップＳ４３１で受信していた漫画データへのアクセスを許可し（ステップＳ４３４）、処理を終了する。

ステップＳ４３４により、以後ユーザは、ＳＮＳ上で、漫画データにアクセスでき、投稿が可能である。例えばユーザは、漫画の台詞部分を差し替えたパロディ漫画や、特定のコマ画像を改変したイラストをＳＮＳで公開することが許可される。

実施例２では図１５及び図１６のシーケンス図を参照して説明したように、漫画データの使用権利を管理する出版社システムが、条件を満たしたユーザに対して漫画の二次利用権をトークン化して付与し、漫画を活用したいアプリケーションに対して漫画データを提供しておく。これにより、ユーザはアプリケーションを横断して二次利用権を活用することが可能である。図１５及び図１６のシーケンス図で示したように、ＳＮＳにて漫画データに対する二次利用権を活用し、例えばユーザがその漫画データを二次創作コンテンツの公開を許可することができる。

実施例２では、漫画のデジタルコンテンツを例に説明したが、勿論これに限られない。様々な形式の画像、音声、動画（イラスト、楽曲、アニメーション、ＴＶ番組等）がデジタルコンテンツの例として考えられる。二次利用権を活用するのはＳＮＳに勿論限られない。その他、デジタルコンテンツ制作プラットフォーム、動画配信プラットフォーム（音声配信アプリケーション、ラジオ配信アプリケーション、短尺動画ＳＮＳ、ライブ配信アプリケーション）でもよい。

ｎ次利用関連にとどまらず、様々な権利をトークン化してアプリケーションを横断的に管理することは、マネタイズに関する課題の解決にも繋がる可能性がある。例えば、トークンコントラクトにトークンの販売・取引機能を実装し、その販売益、取引手数料を自動的に原著作者のブロックチェーンアカウントへ送るようにしてもよい。これにより、様々な形式のデジタルコンテンツ利用権の販売・流通を通じて正当な原著作物者への対価の支払いが可能となる。こコンテンツ利用権とは例えば閲覧・視聴権、ライブ配信等での二次利用権、公開前のコンテンツに対するアーリーアクセス権等であってもよい。

各コンテンツのＩＤに紐づけられて各コンテンツの権限を管理するトークンコントラクト自体にマネタイズ関連を実装し、権利トークンが利用されるに際して、原著作者のブロックチェーンアカウントへ販売益、取引手数料に相当する暗号資産が送信されるようにしてもよい。これにより、原著作者にとっては二次商圏でもマネタイズが可能である。

上述の詳細な説明において、デジタルアセットとしてトークンを提供するアプリケーション（管理装置２Ａ）は、トークン化して共有するデジタルアセットに関し、その情報を取得（提供）するためのＡＰＩの開発・運用の必要がない。ＡＰＩを使用しないのでセキュリティホールのリスクもない。

トークン化されたデジタルアセットを利用する側のアプリケーション（管理装置２Ｂ）は、トークンコントラクトを構築すれば、連携するアプリケーションに併せて実装を変える必要が無い。連携するアプリケーションの数の増加に伴う開発コストの増大をまぬがれることができる。ブロックチェーン上で公開されている情報にアクセスする際には、OAuthで必要だった秘密情報が必要ないので、その管理に伴うセキュリティリスクも生じない。

トークンの発行元の検証を可能な形式で実施することにより、トークンの偽造は実質的に不可能である。したがって、デジタルアセットの利用側が虚偽のデジタルアセットのデータに騙される可能性を大きく低減させることができる。

上述の説明の通り、本開示のアプリケーション連携方法では、単独の管理主体が存在しない透明性の高い分散型システムであるブロックチェーンシステム３００を、デジタルアセットの管理基盤として活用する。これにより、単独の組織が管理する基盤システムを利用する場合に懸念される冗長性・信頼性の問題は大きく緩和される。また、ブロックチェーンシステム３００に記録されたデータは、データ構造的に、高い耐改ざん性を有するので、記録されたデータ（権利付与等）に対する不正な操作は極めて困難である。このような基盤システムにより、競合するステークホルダー同士のアプリケーション連携（コンテンツ共同利用）も現実的に可能である。

上述のように開示された実施の形態は全ての点で例示であって、制限的なものではない。本発明の範囲は、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内での全ての変更が含まれる。

１ 情報端末装置
１０ 処理部
１１ 記憶部
１３ 表示部
１４ 操作部
１Ｐ 情報端末プログラム
２ 管理装置（第１装置、第２装置）
２０ 処理部
２１ 記憶部
２Ｐ 管理プログラム
３００ ブロックチェーンシステム

Claims (7)

1. アプリケーションを提供する装置が、
   前記アプリケーションのユーザのアプリアカウントデータと、ブロックチェーンシステムにおける各ユーザのブロックチェーンアカウントデータとを取得し、
   ユーザ毎に、前記アプリケーションに紐づけられる使用実績に基づくトークンを、ユーザのブロックチェーンアカウントに付与するリクエストを前記ブロックチェーンシステムへ送信し、
   前記ブロックチェーンシステムは、前記トークンの有無、前記トークンの量、前記トークンの内容又は条件のデータの確認リクエストを受け付ける
   アプリケーション実績処理方法。
2. アプリケーションを提供する装置と通信可能なコンピュータが、
   前記装置から、前記アプリケーションに紐づけられる前記アプリケーションのユーザの使用実績に基づくトークンの発行と、前記アプリケーションのユーザのブロックチェーンシステムにおけるブロックチェーンアカウントデータへの前記トークンの付与を含むリクエストを受け付け、
   受け付けたリクエストに基づき、ブロックチェーンシステムにおける前記トークンの発行及び前記ブロックチェーンアカウントデータへの前記トークンの付与を実行し、
   前記装置又は他の装置から、前記ブロックチェーンアカウントデータに対応付けられた前記トークンの有無、前記トークンの量、前記トークンの内容又は条件の参照リクエストを受け付け、
   前記参照リクエストに応じて参照結果をリクエストの送信元へ送信する
   アプリケーション実績処理方法。
3. 前記アプリケーションは、デジタルコンテンツ制作、デジタルコンテンツ配信、又はデジタルコンテンツ投稿のためのアプリケーションである
   請求項１又は２に記載のアプリケーション実績処理方法。
4. 前記アプリケーションは、ゲーム事業者提供サービスのアプリケーションである
   請求項１又は２に記載のアプリケーション実績処理方法。
5. 前記アプリケーションは、決済のためのアプリケーションである
   請求項１又は２に記載のアプリケーション実績処理方法。
6. コンピュータに、
   アプリケーションのユーザのアプリアカウントデータと、ブロックチェーンシステムにおける各ユーザのブロックチェーンアカウントデータとを取得し、
   ユーザ毎に、前記アプリケーションに紐づけられる使用実績に基づくトークンを、ユーザのブロックチェーンアカウントに付与するリクエストを前記ブロックチェーンシステムへ送信する
   処理を実行させるコンピュータプログラム。
7. ユーザの情報端末装置、及びアプリケーションを提供する提供装置を含み、
   前記提供装置は、
   前記情報端末装置から、前記アプリケーションの前記ユーザのアプリアカウントデータと、ブロックチェーンシステムにおけるユーザのブロックチェーンアカウントデータとを取得し、
   前記ユーザのブロックチェーンアカウントに対し、前記アプリケーションに紐づけられる前記ユーザの使用実績に基づくトークンを付与するトランザクションを、前記ブロックチェーンシステムへブロードキャストし、
   前記ブロックチェーンシステムは、前記ユーザに対する前記トークンの有無、前記トークンの量、前記トークンの内容又は条件のデータの確認リクエストを受け付ける
   アプリケーション実績処理システム。

Images