JP2019211925A - 情報処理方法、情報処理装置およびプログラム - Google Patents

Abstract

【課題】様々な状況のユーザがゲームを楽しめる情報処理方法等を提供すること。【解決手段】情報処理方法は、オンラインゲームに利用可能であり、有効期限が定められたチケットを所定の仮想通貨を用いて購入するための、前記オンラインゲームのユーザから前記オンラインゲームの管理者に宛てたトランザクションを、前記仮想通貨にかかるブロックチェーンに送信させ、前記ユーザが保有する前記仮想通貨の量が、送信された前記トランザクションにかかる条件を満たす場合に、前記チケットを前記ユーザに対して販売させるスマートコントラクトを実行させる。【選択図】図１

Description

本発明は、情報処理方法、情報処理装置およびプログラムに関する。

ユーザが、スマートフォンまたはタブレット等の情報処理装置を使用して楽しむゲームが提供されている。ユーザは、有償でキャラクタおよび武器等のアイテムを購入し、ゲーム内で育成して、強化することにより、ゲームの勝率を上げることができる。有償でゲームを楽しむユーザに対して、商品を購入する機会を提供するゲームシステムが提案されている（特許文献１）。

特開２０１８−８０８３号公報

ゲームに費やせる時間が少ないユーザは、キャラクタおよび武器等のアイテム等を十分に育成できないため、ゲームに勝つことが難しい。そのために、十分にゲームを楽しめない場合がある。一方、経済的に厳しいユーザは、欲しいアイテムを購入できないため、十分にゲームを楽しめない場合がある。さらに、日本のゲーム会社が運用している有償のオンラインゲームについて、外国のユーザが日本円での決済を行なって楽しむことが困難な場合がある。

特許文献１に記載のゲームシステムにおいては、このような様々な状況のユーザが、十分にゲームを楽しむことができない。

一つの側面では、様々な状況のユーザがゲームを楽しめる情報処理方法等を提供することを目的とする。

情報処理方法は、オンラインゲームに利用可能であり、有効期限が定められたチケットを所定の仮想通貨を用いて購入するための、前記オンラインゲームのユーザから前記オンラインゲームの管理者に宛てたトランザクションを、前記仮想通貨にかかるブロックチェーンに送信させ、前記ユーザが保有する前記仮想通貨の量が、送信された前記トランザクションにかかる条件を満たす場合に、前記チケットを前記ユーザに対して販売させるスマートコントラクトを実行させる。

情報処理方法は、オンラインゲームの第１ユーザから、販売を希望するアイテムと、該アイテムの価格とを取得し、取得した前記アイテムと前記価格とを公開し、前記オンラインゲームの第２ユーザから前記アイテムにかかる購入希望を取得し、前記第２ユーザから前記第１ユーザに宛てたトランザクションをブロックチェーンに送信させ、前記ブロックチェーンを介して、前記第２ユーザによる前記価格の支払いを条件に、取得した購入希望にかかる前記アイテムの所有権を前記第１ユーザから前記第２ユーザに移転させるスマートコントラクトを実行させる。

一つの側面では、ユーザ間でアイテムを売買可能な情報処理方法等を提供できる。

情報処理システムの概要を説明する説明図である。 情報処理システムの概要を説明する説明図である。 情報処理システムの概要を説明する説明図である。 情報処理システムの構成を説明する説明図である。 ユーザＤＢのレコードレイアウトを説明する説明図である。 チケットＤＢのレコードレイアウトを説明する説明図である。 アイテムＤＢのレコードレイアウトを説明する説明図である。 マーケットＤＢのレコードレイアウトを説明する説明図である。 情報処理装置が表示部に表示する画面を示す説明図である。 情報処理装置が表示部に表示する画面を示す説明図である。 情報処理装置が表示部に表示する画面を示す説明図である。 情報処理装置が表示部に表示する画面を示す説明図である。 プログラムの処理の流れを説明するフローチャートである。 チケット購入のサブルーチンの処理の流れを説明するフローチャートである。 アイテム購入のサブルーチンの処理の流れを説明するフローチャートである。 アイテム出品のサブルーチンの処理の流れを説明するフローチャートである。 アイテム取引のサブルーチンの処理の流れを説明するフローチャートである。 取引マイニングのサブルーチンの処理の流れを説明するフローチャートである。 実施の形態２のプログラムの処理の流れを説明するフローチャートである。 実施の形態２のアイテム購入のサブルーチンの処理の流れを説明するフローチャートである。 実施の形態３の情報処理システムの概要を説明する説明図である。 実施の形態３のユーザＤＢのレコードレイアウトを説明する説明図である。 実施の形態３のアイテム出品のサブルーチンの処理の流れを説明するフローチャートである。 実施の形態３の取引マイニングのサブルーチンの処理の流れを説明するフローチャートである。 実施の形態４のアイテム取引のサブルーチンの処理の流れを説明するフローチャートである。 実施の形態５のアイテム取引のサブルーチンの処理の流れを説明するフローチャートである。 実施の形態６の情報処装置の機能ブロック図である。 実施の形態７の情報処理システムの構成を示す説明図である。

［実施の形態１］
本実施の形態においては、「三国志」を題材にした対戦型のオンラインカードゲームを例にして説明する。ユーザは、三国志に登場する武将および武器等のアイテムを示す仮想的なカードを使用して、ネットワークを介して他のユーザまたはＡＩ（Artificial Intelligence）との対戦を行なう。カードには、それぞれのアイテムの特性が記録されている。

図１から図３は、情報処理システム１０の概要を説明する説明図である。図１は、ユーザがゲーム内通貨であるチケットを購入する過程を説明する説明図である。本実施の形態においては、ゲームを提供するゲーム会社とユーザとは、たとえばイーサリアム（Ethereum）、リスク（Lisk）、ネオ（NEO）またはクオンタム（Qtum）のような、スマートコントラクト機能を有する仮想通貨を用いて取引を行なう。ゲーム会社は、本実施の形態の管理者の一例である。

ユーザは、仮想通貨を用いてゲーム内で使用するチケットを購入する。この際、ユーザの使用する情報処理装置２０は、チケット購入にかかるスマートコントラクトを含むトランザクションをブロックチェーン４０（図４参照）に送信する。

ここで、トランザクションに含まれるスマートコントラクトは、いわゆるショップコントラクトであり、ユーザが価格相当額の仮想通貨を支払うことを条件にして、チケットが販売される。チケットには固有のチケットＩＤ（Identifier）が付与される。付与されたチケットＩＤは、トランザクションに書き込まれる。トランザクションは、マイニングにより検証されて、ブロックチェーン４０に組み込まれる。

ゲーム会社が管理する管理者サーバ３０に、ユーザの口座に固有に付与された口座ＩＤと、チケットＩＤと、チケットの販売日とが関連づけて記録される。チケットには有効期限が定められており、販売日から所定の期間を過ぎると無効になる。

図２は、ユーザがチケットを用いてゲーム会社からゲーム内アイテムを購入する過程を説明する説明図である。ユーザは、チケットを用いてアイテムを購入する。アイテムは、たとえば武将等のキャラクタ、および、キャラクタが使用する武器等である。ゲーム会社は、たとえば１０体の武将または武器等のアイテムを組み合わせたセットを販売しても良い。

ゲーム会社は、複数のセットのなかから、ユーザが選択したセットを販売しても良い。ゲーム会社は、ユーザが購入するアイテムをくじ引きにより決定しても良い。各アイテムには、レベル、攻撃力および防御力等の特性が定められている。なお、ゲーム会社が販売する段階では、アイテムは比較的弱い状態に設定されている。

ユーザは、購入したアイテムを使用して、ゲームを楽しむ。ゲームの回数を重ねることにより、ユーザは使用したアイテムの特性を強化する、いわゆる育成を行なえる。アイテムの育成が進むことにより、ユーザは有利に対戦できるようになる。

図３は、ユーザ間でアイテムの売買を行なう過程を説明する説明図である。ユーザは、育成したアイテムをゲーム会社が運営するマーケットに出品する。以下ではアイテムを出品するユーザを第１ユーザ、マーケットからアイテムを購入するユーザを第２ユーザと記載する。なお、マーケットには複数のユーザがアイテムを出品する。あるアイテムを出品したユーザが、他のアイテムを購入する場合もある。

第１ユーザは、特定の価格でアイテムを販売するスマートコントラクトを含むトランザクションを、ブロックチェーン４０に送信する。トランザクションは、マイニングにより検証されて、ブロックチェーン４０に組み込まれる。

第２ユーザは、アイテム購入にかかるスマートコントラクトを含むトランザクションを、ブロックチェーン４０に送信する。トランザクションは、マイニングにより検証されて、ブロックチェーン４０に組み込まれる。スマートコントラクトに基づいて、第２ユーザから第１ユーザに価格相当額の仮想通貨が支払われる。

なお、価格相当額の仮想通貨の一部が、図３に示すように第２ユーザからゲーム会社に支払われることがスマートコントラクトに定められていても良い。ゲーム会社に支払われた仮想通貨は、マーケットの運営手数料、および、アイテムの名義変更手数料に使用される。以上により、ユーザ間でのアイテムの売買が実現される。

第１ユーザからゲーム会社に対して、手数料が支払われても良い。第１ユーザと第２ユーザの双方からゲーム会社に手数料が支払われても良い。手数料の額は、売買されたアイテムの価格に基づいて定められてもよく、定額であっても良い。

第１ユーザは、育成したアイテムを売却して得た利益により、他のアイテム等を購入できる。第１ユーザは利益をゲーム以外の用途に利用しても良い。第２ユーザは、育成の手間をかけずに、育成により強化されたアイテムを用いてゲームを楽しむことができる。

図４は、情報処理システム１０の構成を説明する説明図である。前述のとおり、情報処理システム１０は、複数の情報処理装置２０と、管理者サーバ３０とを含む。情報処理装置２０と、管理者サーバ３０とは、ネットワークを介してブロックチェーン４０に接続されている。

情報処理装置２０は、ＣＰＵ（Central Processing Unit）２１、主記憶装置２２、補助記憶装置２３、通信部２４、タッチパネル２５およびバスを備える。ＣＰＵ２１は、本実施の形態のプログラムを実行する演算制御装置である。ＣＰＵ２１には、一または複数のＣＰＵまたはマルチコアＣＰＵ等が使用される。ＣＰＵ２１は、バスを介して情報処理装置２０を構成するハードウェア各部と接続されている。

主記憶装置２２は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等の記憶装置である。主記憶装置２２には、ＣＰＵ２１が行なう処理の途中で必要な情報およびＣＰＵ２１で実行中のプログラムが一時的に保存される。

補助記憶装置２３は、ＳＲＡＭ、フラッシュメモリまたはハードディスク等の記憶装置である。補助記憶装置２３には、ＣＰＵ２１に実行させるプログラム、およびプログラムの実行に必要な各種データが保存される。

通信部２４は、情報処理装置２０とネットワークとの間のデータ通信を行なうインターフェイスである。タッチパネル２５は、液晶表示パネル等の表示部２５１と、表示部２５１に積層された入力部２５２とを備える。情報処理装置２０は、ユーザが使用するスマートフォン、タブレット、またはパソコン等の、汎用の情報処理装置である。

管理者サーバ３０は、ＣＰＵ３１、主記憶装置３２、補助記憶装置３３、通信部３４およびバスを備える。ＣＰＵ３１は、本実施の形態のプログラムを実行する演算制御装置である。ＣＰＵ３１には、一または複数のＣＰＵまたはマルチコアＣＰＵ等が使用される。ＣＰＵ２１は、バスを介して管理者サーバ３０を構成するハードウェア各部と接続されている。

主記憶装置３２は、ＳＲＡＭ、ＤＲＡＭ、フラッシュメモリ等の記憶装置である。主記憶装置３２には、ＣＰＵ３１が行なう処理の途中で必要な情報およびＣＰＵ３１で実行中のプログラムが一時的に保存される。

補助記憶装置３３は、ＳＲＡＭ、フラッシュメモリまたはハードディスク等の記憶装置である。補助記憶装置３３には、ユーザＤＢ（Database）５１、チケットＤＢ５２、アイテムＤＢ５３、マーケットＤＢ５４、ＣＰＵ３１に実行させるプログラム、およびプログラムの実行に必要な各種データが保存される。ユーザＤＢ５１、チケットＤＢ５２、アイテムＤＢ５３、マーケットＤＢ５４は、管理者サーバ３０に接続された外部の大容量記憶装置、または、ネットワークを介して管理者サーバ３０に接続された他のサーバに記録されていても良い。

通信部３４は、管理者サーバ３０とネットワークとの間のデータ通信を行なうインターフェイスである。管理者サーバ３０は、ゲーム会社が管理するパソコンまたはサーバマシン等の汎用の情報処理装置である。管理者サーバ３０は、大型計算機上で動作する仮想マシンでも良い。管理者サーバ３０は、複数の複数のコンピュータまたはサーバマシンを組み合わせて構成されても良い。

図５は、ユーザＤＢ５１のレコードレイアウトを説明する説明図である。ユーザＤＢ５１は、ユーザの口座ＩＤと、ログインパスワードと、ユーザのレベルとを関連づけて記録するＤＢである。なお、本実施の形態においては、ユーザがブロックチェーン４０を用いた取引に使用する口座ＩＤを使用して、個々のユーザを識別する。

ユーザＤＢ５１は、口座ＩＤフィールド、ログインパスワードフィールドおよびレベルフィールドを有する。口座ＩＤフィールドには、ユーザの口座ＩＤが記録されている。ログインパスワードフィールドには、ユーザが情報処理システム１０にログインする際に使用するログインパスワードが記録されている。

レベルフィールドにはユーザのレベルが記録されている。ユーザのレベルは、ユーザがゲームを行ない、所定の課題を達成することにより、随時更新されて、ユーザＤＢ５１に記録される。ユーザＤＢ５１は、一人のユーザについて１つのレコードを有する。

なお、ＣＰＵ３１がユーザに固有のユーザＩＤを付与しても良い。そのようにする場合には、ユーザＤＢ５１にユーザＩＤフィールドが設けられ、ユーザＩＤと口座ＩＤとが関連づけて記録される。

図６は、チケットＤＢ５２のレコードレイアウトを説明する説明図である。チケットＤＢ５２は、チケットと、チケットを保有するユーザと、販売日と、有効期限と、使用済であるか否かを関連づけて記録するＤＢである。

チケットＤＢ５２は、チケットＩＤフィールド、口座ＩＤフィールド、販売日フィールド、有効期限フィールドおよび使用済フィールドを有する。チケットＩＤフィールドには、チケットに固有に付与されたチケットＩＤが記録されている。口座ＩＤフィールドには、チケットを所有するユーザの口座ＩＤが記録されている。販売日フィールドには、ゲームメーカからチケットが販売された日付が記録されている。

有効期限フィールドには、チケットの有効期限が記録されている。使用済フィールドには、チケットの使用状況が記録されている。使用済フィールドの「ＹＥＳ」は、チケットが使用済であることを示し、「ＮＯ」は未使用であることを示す。未使用のまま有効期限が過ぎた場合には、無効を意味する「ＶＯＩＤ」が有効期限フィールドに記録される。

チケットＤＢ５２は、１枚のチケットについて、１つのレコードを有する。なお、本実施の形態においては、チケットは１種類であり、ユーザは支払いに対応する枚数のチケットを使用するが、価値の異なる複数の種類のチケットが設けられても良い。そのようにする場合には、チケットＤＢ５２に価値フィールドが設けられる。

図７は、アイテムＤＢ５３のレコードレイアウトを説明する説明図である。アイテムＤＢ５３は、アイテムに固有に付与されたアイテムＩＤと、アイテムの詳細と、アイテムを保有するユーザの口座ＩＤとを関連づけて記録するＤＢである。アイテムＤＢ５３は、アイテムＩＤフィールド、アイテム詳細フィールドおよび口座ＩＤフィールドを有する。

アイテム詳細フィールドは、種類フィールド、名称フィールド、レベルフィールド等を有する。アイテム詳細フィールドには、アイテムの攻撃力、防御力、得意技、他のアイテムとの相性等、ゲームの特性に応じたアイテムの特性を記録するフィールドを有するが、詳細については省略する。

アイテムＩＤフィールドには、アイテムＩＤが記録されている。種類フィールドには、アイテムの種類が記録されている。名称フィールドには、アイテムの名称が記録されている。レベルフィールドにはアイテムのレベルが記録されている。口座ＩＤフィールドには、アイテムを所有するユーザのＩＤが記録されている。アイテムＤＢ５３は、一つのアイテムについて、一つのレコードを有する。

図８は、マーケットＤＢ５４のレコードレイアウトを説明する説明図である。マーケットＤＢ５４は、ユーザによるアイテムの出品対象アイテムごとに固有に付与された出品ＩＤと、出品情報と、購入情報と、状況とを関連づけて記録するＤＢである。

マーケットＤＢ５４は、出品ＩＤフィールド、出品情報フィールド、購入情報フィールドおよび状態フィールドを有する。出品情報フィールドは、アイテムＩＤフィールド、名称フィールド、出品者口座ＩＤフィールド、価格フィールド、出品期限フィールドおよび第１パスワードフィールドを有する。購入情報フィールドは、希望者口座ＩＤフィールド、取引期限フィールドおよび第２パスワードフィールドを有する。

出品ＩＤフィールドには、出品ＩＤが記録されている。アイテムＩＤフィールドには、アイテムＩＤが記録されている。名称フィールドには、出品されたアイテムの名称が記録されている。出品者口座ＩＤフィールドには、出品者の口座ＩＤが記録されている。価格フィールドには、出品時に出品者が定めた価格が記録されている。出品期限フィールドには、出品期限が記録されている。第１パスワードフィールドには、出品者がアイテムを出品する際に、出品者が使用する情報処理装置２０のＣＰＵ２１により作成された第１パスワードが記録されている。

購入者口座ＩＤフィールドには、アイテムを購入する購入者の口座ＩＤが記録されている。取引期限フィールドには、取引期限が記録されている。第２パスワードフィールドには、購入者がアイテムの購入を申し込む際に、購入者が使用する情報処理装置２０のＣＰＵ２１により作成された第２パスワードが記録されている。

状態フィールドには、取引状態が記録されている。状態フィールドの「成立済」は、取引が成立して、アイテムの所有権が出品者から購入者に移転したことを示す。「不成立」は、出品期限内に取引が成立しなかったことを示す。「取引中」は、購入者から購入申し込みが行なわれたが、ブロックチェーン４０におけるマイニング処理待ち等により、まだ取引が成立していないことを意味する。「販売可」は、販売可能であり、購入申し込みを待っていることを示す。「登録処理中」は、出品者から情報を受信して、登録処理を行っている途中であることを示す。

マーケットＤＢ５４は、出品された一つのアイテムについて、１つのレコードを有する。なお、ＣＰＵ３１は、取引状態が「成立済」または「不成立」であるレコードを、マーケットＤＢ５４から削除しても良い。

図９から図１２は、情報処理装置２０が表示部２５１に表示する画面を示す説明図である。図９は、第１ユーザがマーケットに出品するアイテムを選択する画面を示す。第１ユーザが所有するそれぞれのアイテムの概要が、カード欄７１に表示されている。第１ユーザは、タッチパネル２５をタップすることにより、所望のカード欄７１を選択できる。

図１０は、図９の画面においてカード欄７１の選択を受け付けた後に、出品する価格を受け付ける画面を示す。選択を受け付けたカードを示すカード欄７１の下に、価格入力欄７２および決定ボタン７３が表示されている。ＣＰＵ２１は、タッチパネル２５または音声入力等のユーザインターフェイスを介して、価格入力欄７２への価格の入力を受け付ける。決定ボタン７３がタップされた場合、ＣＰＵ２１は出品価格の決定を受け付け、アイテムをマーケットに出品する処理を実行する。

図１１は、マーケットに出品されたアイテムの一覧を表示するマーケット画面を示す。マーケット画面には、出品されたそれぞれのアイテムの概要がカード欄７１に表示されている。それぞれのカード欄７１の上部に、出品者が設定した価格を表示する価格表示欄７６が設けられている。それぞれのカード欄７１の下部に、購入ボタン７４および検索ボタン７５が設けられている。

他のユーザからアイテムを購入したい第２ユーザは、図１１に示すマーケット画面を閲覧する。たとえば、一番上のカード欄７１に表示された「張允」について、他のユーザから出品されたカードと比較したい場合、ユーザは検索ボタン７５を選択する。ＣＰＵ２１は、ネットワークを介して、名称をキーとしてマーケットＤＢ５４を検索して抽出されたレコードを取得して、表示部２５１に表示する。第２ユーザは、価格およびレベル等の条件を比較して、所望の購入アイテムを選択できる。

図１２は、購入ボタン７４の選択を受け付けた後にＣＰＵ２１が表示する画面を示す。ＣＰＵ２１は、第２ユーザによる選択を受け付けたカードの詳細を表示部２５１に大きく表示する。図１１に示す画面では表示されなかった、アイテムの絵柄全体およびアイテムに関する説明が表示される。

アイテムに関する説明の下に、同意欄７７および購入ボタン７４が表示されている。第２ユーザから同意欄７７の選択を受け付けた場合、ＣＰＵ２１は同意欄７７にチェックマークを表示する。同意欄７７にチェックマークが表示された状態で、購入ボタン７４の選択を受け付けた場合、ＣＰＵ２１は第２ユーザから購入希望を受け付け、マーケットからアイテムを購入する処理を実行する。

図１３は、プログラムの処理の流れを説明するフローチャートである。ＣＰＵ２１は、ログイン処理を行なう（ステップＳ５０１）。ログイン処理は、たとえばＣＰＵ２１が口座ＩＤおよびパスワードの入力を受け付けて管理者サーバ３０に送信し、ＣＰＵ３１がユーザＤＢ５１に記録された口座ＩＤおよびパスワードと照合することにより行なう。ログイン処理は、指紋認証、顔認証、その他の任意の認証手段により行なわれても良い。ログイン処理は情報処理装置２０の内部で完結しても良い。

ログイン完了後、ＣＰＵ２１は操作メニューが表示されたメニュー画面を表示部２５１に表示する。表示部２５１に表示される画面は、たとえば、補助記憶装置２３に記憶されたデータと、管理者サーバ３０から受信したデータとに基づいて、ＣＰＵ２１が作成する。ＣＰＵ３１により作成された画面を、ネットワークを介してＣＰＵ２１が受信して、表示部２５１に表示しても良い。

なお、ＣＰＵ２１はメニュー画面を表示せずにゲームを開始しても良い。そのようにする場合には、ユーザにより所定の操作が行なわれた場合に、ＣＰＵ２１はメニュー画面を表示する。

ＣＰＵ２１は、ユーザからチケット購入の指示を受け付けたか否かを判定する（ステップＳ５０２）。チケット購入の指示を受け付けたと判定した場合（ステップＳ５０２でＹＥＳ）、ＣＰＵ２１はチケット購入のサブルーチンを起動する（ステップＳ５０３）。チケット購入のサブルーチンは、仮想通貨を用いてゲーム会社からチケットを購入するサブルーチンである。チケット購入のサブルーチンの処理の流れは後述する。

チケット購入の指示を受け付けていないと判定した場合（ステップＳ５０２でＮＯ）、または、ステップＳ５０３の終了後、ＣＰＵ２１は、ユーザからアイテム購入の指示を受け付けたか否かを判定する（ステップＳ５０４）。アイテム購入の指示を受け付けたと判定した場合（ステップＳ５０４でＹＥＳ）、ＣＰＵ２１はアイテム購入のサブルーチンを起動する（ステップＳ５０５）。アイテム購入のサブルーチンは、チケットを用いてゲーム会社からアイテムを購入するサブルーチンである。アイテム購入のサブルーチンの処理の流れは後述する。

アイテム購入の指示を受け付けていないと判定した場合（ステップＳ５０４でＮＯ）、または、ステップＳ５０５の終了後、ＣＰＵ２１は、ユーザからアイテム出品の指示を受け付けたか否かを判定する（ステップＳ５０６）。アイテム出品の指示を受け付けたと判定した場合（ステップＳ５０６でＹＥＳ）、ＣＰＵ２１はアイテム出品のサブルーチンを起動する（ステップＳ５０７）。アイテム出品のサブルーチンは、ユーザが所有するアイテムをマーケットに出品するサブルーチンである。アイテム出品のサブルーチンの処理の流れは後述する。

アイテム出品の指示を受け付けていないと判定した場合（ステップＳ５０６でＮＯ）、または、ステップＳ５０７の終了後、ＣＰＵ２１は、ユーザからアイテム取引の指示を受け付けたか否かを判定する（ステップＳ５０８）。アイテム取引の指示を受け付けたと判定した場合（ステップＳ５０８でＹＥＳ）、ＣＰＵ２１はアイテム取引のサブルーチンを起動する（ステップＳ５０９）。アイテム取引のサブルーチンは、マーケットを介して他のユーザとの間でアイテムの取引を行なうサブルーチンである。アイテム取引のサブルーチンの処理の流れは後述する。

アイテム取引の指示を受け付けていないと判定した場合（ステップＳ５０８でＮＯ）、または、ステップＳ５０９の終了後、ＣＰＵ２１は、ＣＰＵ３１と連携してゲームを実行する（ステップＳ５１０）。ステップＳ５１０において、ユーザは所有するアイテムを用いてゲームを楽しむことができる。ユーザは、ゲーム内の所定の条件を満たすことにより、アイテムを育成できる。育成によるアイテムのレベル等の変化は、アイテムＤＢ５３に随時記録される。

ＣＰＵ２１は、処理を終了するか否かを判定する（ステップＳ５１１）。処理を終了しないと判定した場合（ステップＳ５１１でＮＯ）、ＣＰＵ２１はステップＳ５０２に戻る。処理を終了すると判定した場合（ステップＳ５１１でＹＥＳ）、ＣＰＵ２１は処理を終了する。

図１４は、チケット購入のサブルーチンの処理の流れを説明するフローチャートである。チケット購入のサブルーチンは、仮想通貨を用いてゲーム会社からチケットを購入するサブルーチンである。

ブロックチェーン４０には、ＣＰＵ３１から送信された、チケット販売トランザクションが既に記録されている。チケット販売トランザクションには、チケットの価格と、販売者であるゲーム会社の口座ＩＤとが記録されている。なお、チケットの販売数量に制限を設ける場合には、最大販売数量もチケット販売トランザクションに含まれる。

ＣＰＵ２１は、ユーザにより入力されたチケットの購入数を取得する（ステップＳ５２１）。ＣＰＵ２１は、チケット購入トランザクションを作成してブロックチェーン４０に送信する（ステップＳ５２２）。チケット購入トランザクションは、支払元の口座ＩＤ、支払先の口座ＩＤ、支払額、および、価格相当額の仮想通貨が支払われることを条件にして所定の数のチケットが販売される、いわゆるショップコントラクトを含む。ここで、支払元はユーザであり、支払先はゲーム会社である。チケット購入トランザクションは、未検証情報としてブロックチェーン４０に記録される。

ブロックチェーン４０においては、複数のＣＰＵにより平行してマイニングが行なわれる。以下の説明では１つのＣＰＵを例にして、マイニングの概要を説明する。ＣＰＵは、未検証情報を取得する（ステップＳ６０１）。以下では、ステップＳ６０１で取得した未検証情報が、ステップＳ５２２で送信されたチケット購入トランザクションである場合を例にして説明を続ける。

ＣＰＵは、ブロックチェーンからチケット販売トランザクションを抽出する（ステップＳ６０２）。ＣＰＵは、チケット販売トランザクションからチケットの価格を取得する（ステップＳ６０３）。ＣＰＵは、支払元の口座ＩＤが保有する仮想通貨の額が、チケットを購入可能な額であるか否かを判定する（ステップＳ６０４）。保有する仮想通貨の額が不足すると判定した場合（ステップＳ６０４でＮＯ）、ＣＰＵはステップＳ６０１で取得した未検証情報の処理を中止して、ステップＳ６０１に戻る。

保有する仮想通貨の額が十分であると判定した場合（ステップＳ６０４でＹＥＳ）、ＣＰＵは、チケット購入トランザクションの検証を完了する。ＣＰＵは、検証済の複数のトランザクションをまとめてブロックチェーン４０の仕様に沿った新たなブロックを作り、ブロックチェーン４０に接続する（ステップＳ６０５）。

ステップＳ６０１からステップＳ６０５のマイニングの処理により、チケット購入トランザクションはブロックチェーン４０に組み込まれる。マイニングの完了に伴い、チケット代金に相当する仮想通貨が、ユーザの口座ＩＤからゲーム会社の口座ＩＤに送られる。

ＣＰＵ３１は、ブロックチェーン４０を随時参照して、新たに販売されたチケットにかかる情報を取得する（ステップＳ７０１）。ＣＰＵ３１は、販売されたチケットの数に対応する数のチケットＩＤを発行する（ステップＳ７０２）。

ＣＰＵ３１は、チケットＤＢ５２に新規レコードを追加して、新たに販売されたチケットにかかる情報を記録する（ステップＳ７０３）。具体的には、ＣＰＵ３１はブロックチェーン４０から取得したチケットＩＤ、購入者の口座ＩＤ、および販売日を、新規レコードのチケットＩＤフィールド、口座ＩＤフィールドおよび販売日フィールドにそれぞれ記録する。ＣＰＵ３１は、販売日に基づいて算出した有効期限を有効期限フィールドに記録する。ＣＰＵ３１は、使用済フィールドに「ＮＯ」を記録する。

以上により、ＣＰＵ３１は決済等の複雑な処理を行なわずに、自動的にチケットを販売できる。チケットの販売にブロックチェーンを使用することにより、詐欺および未払い等のトラブルを防止できる。販売されたチケットに固有のチケットＩＤを発行して、チケットＤＢ５２に記録することにより、チケット販売および使用状況を管理できる。ユーザは、金融機関等を介した法定通貨の送金手続を行なわずに、容易にチケットを購入できる。

図１５は、アイテム購入のサブルーチンの処理の流れを説明するフローチャートである。アイテム購入のサブルーチンは、チケットを用いてゲーム会社からアイテムを購入するサブルーチンである。

ＣＰＵ２１は、ユーザの口座ＩＤを送信して、ＣＰＵ３１にショップ情報を要求する（ステップＳ５３１）。ＣＰＵ３１は、要求を受信する（ステップＳ７１１）。ＣＰＵ３１は、販売可能なアイテムを抽出する（ステップＳ７１２）。たとえば、ＣＰＵ３１は所定のアイテムのセットを販売可能であると判定して抽出する。ＣＰＵ３１は、アイテムごとに定められた所定の販売数に達していないアイテムを販売可能であると判定して抽出しても良い。

ＣＰＵ３１は、口座ＩＤをキーとしてユーザＤＢ５１を検索してユーザのレベルを抽出し、レベルごとに定められた所定のアイテムを販売可能であると判定して抽出しても良い。ＣＰＵ３１は、販売可能なアイテムをランダムに抽出しても良い。ＣＰＵ３１は、所定の期間に販売可能な、いわゆる期間限定アイテムを抽出しても良い。ＣＰＵ３１は、口座ＩＤに基づいてブロックチェーン４０からユーザの保有する仮想通貨額を取得して、購入可能な価格にかかるアイテムを抽出しても良い。

ＣＰＵ３１は、抽出したアイテムを送信する（ステップＳ７１３）。ＣＰＵ２１は、送信されたアイテムを受信して、表示部２５１に表示する（ステップＳ５３３）。ＣＰＵ２１は、ユーザによるアイテムの選択を受け付けて、管理者サーバ３０に送信する（ステップＳ５３４）。

ＣＰＵ３１は、選択されたアイテムを受信する（ステップＳ７１４）。ＣＰＵ３１は、ユーザＩＤをキーとしてチケットＤＢ５２を検索して、チケットレコードを抽出する。ＣＰＵ３１は、ユーザが保有する未使用チケットにより、選択されたアイテムを購入できるか否かを判定する（ステップＳ７１５）。

購入できると判定した場合（ステップＳ７１５でＹＥＳ）、ＣＰＵ３１はチケットＤＢ５２を更新する（ステップＳ７１６）。具体的には、ＣＰＵ３１は、有効期限までの期間が短いチケットレコードから優先して、アイテムの価格に対応する数のチケットレコードを抽出し、使用済フィールドに「ＹＥＳ」を記録する。

ＣＰＵ３１は、アイテムＤＢ５３を更新する（ステップＳ７１７）。具体的には、ＣＰＵ３１はユーザが購入したアイテム数に対応する数の新規レコードをアイテムＤＢ５３に追加する。ＣＰＵ３１はユーザが購入したアイテムに固有のアイテムＩＤを付与し、アイテム詳細にかかる情報および購入したユーザの口座ＩＤを記録する。

ユーザが保有する未使用チケットにより、選択されたアイテムを購入できないと判定した場合（ステップＳ７１５でＮＯ）、または、ステップＳ７１７の終了後、ＣＰＵ３１は、情報処理装置２０にアイテムの購入に成功したか、失敗したかにかかる情報を送信する（ステップＳ７１８）。ＣＰＵ２１は情報を受信して表示部２５１に表示する（ステップＳ５３６）。ＣＰＵ２１は、処理を終了する。

ゲーム会社からユーザへのアイテムの販売にはブロックチェーン４０を使用しないので、ユーザはマイニングの終了を待たずに、欲しいアイテムをすぐに入手できる。チケットＤＢ５２を使用することにより、チケットの二重使用等の不正を防止できる。

図１６は、アイテム出品のサブルーチンの処理の流れを説明するフローチャートである。アイテム出品のサブルーチンは、第１ユーザが所有するアイテムをマーケットに出品するサブルーチンである。

ＣＰＵ２１は、図９および図１０を使用して説明した画面を介して、マーケットに出品するアイテムおよび価格を取得する（ステップＳ５４１）。ＣＰＵ２１は、ユーザの口座ＩＤ、出品するアイテムのアイテムＩＤおよび価格等の情報を、管理者サーバ３０に送信する（ステップＳ５４２）。

ＣＰＵ３１は、送信された情報を受信する（ステップＳ７２０）。ＣＰＵ３１は、受信した情報に対して、出品ＩＤと、第１パスワードとを発行する（ステップＳ７２１）。出品ＩＤは、ステップＳ７２０で受信した出品情報ごとに固有に付与される。第１パスワードは、たとえば乱数と日時とを組み合わせる等の所定のルールに基づいて発行される。

ＣＰＵ３１は、マーケットＤＢ５４に新規レコードを追加して、出品ＩＤおよび出品情報を記録する（ステップＳ７２２）。ＣＰＵ３１は、出品期限フィールドに、出品日から算出した所定の出品期限を記録する。ＣＰＵ２１は、ユーザから出品期限を取得してＣＰＵ３１に送信しても良い。ＣＰＵ３１は、状態フィールドに「登録処理中」を記録する（ステップＳ７２３）。

ＣＰＵ３１は、出品ＩＤおよび第１パスワードを情報処理装置２０に送信する（ステップＳ７２４）。ＣＰＵ２１は、出品ＩＤおよびパスワードを受信する（ステップＳ５４４）。ＣＰＵ２１は、出品トランザクションを作成してブロックチェーン４０に送信する（ステップＳ５４５）。出品トランザクションは、出品ＩＤ、ユーザの口座ＩＤ、第１パスワード、および指定の価格相当額の仮想通貨が支払われることを条件にして、出品ＩＤに対応するアイテムが販売されるスマートコントラクトを含む。出品トランザクションは、未検証情報としてブロックチェーン４０に記録される。

ブロックチェーン４０においては、複数のＣＰＵにより平行してマイニングが行なわれる。以下の説明では１つのＣＰＵを例にして説明する。ＣＰＵは、未検証情報を取得する（ステップＳ６２１）。以下では、ステップＳ６２１で取得した未検証情報が、ステップＳ５４５で送信された出品トランザクションである場合を例にして説明を続ける。

ＣＰＵは、マイニングを行ない、ステップＳ６２１で取得した出品トランザクションを含む複数のトランザクションをまとめた新たなブロックを、ブロックチェーン４０に接続する（ステップＳ６２２）。

ＣＰＵ３１は、ブロックチェーン４０を随時参照する（ステップＳ７２６）。ＣＰＵ３１は、ステップＳ７２１で発行した出品ＩＤにかかる出品トランザクションの登録の有無を判定する（ステップＳ７２７）。具体的には、ＣＰＵ３１はブロックチェーンから出品ＩＤを含むトランザクションを抽出する。ＣＰＵ３１は、抽出したトランザクションに、ステップＳ７２１で発行した第１パスワードが含まれている場合に、出品ＩＤにかかる出品トランザクションが登録されていると判定する。

出品ＩＤを含むトランザクションが登録されていると判定した場合（ステップＳ７２７でＹＥＳ）、ＣＰＵ３１はステップＳ７２２で作成したマーケットレコードの状態フィールドを「販売可」に変更する（ステップＳ７２８）。登録されていないと判定した場合（ステップＳ７２７でＮＯ）、ＣＰＵ３１は、所定の時間が経過した後にステップＳ７２６に戻る。

第１パスワードを使用することにより、故意または偶然により、所有者の意図しないアイテム、または、本来存在しないアイテムがマーケットを介して販売されることを防止できる。出品ＩＤが、第１パスワードを兼ねても良い。この場合ステップＳ７２１において、ＣＰＵ３１は、第３者による推測が困難であり、かつ固有の文字列を作成して、出品ＩＤ兼第１パスワードに使用する。

なお、ＣＰＵ２１は、所有者が出品中のアイテムをゲームで使用できないようにしても、売却が確定するまで通常通り使用できるようにしても良い。

ユーザが、出品したアイテムの状態を確認したい場合には、タッチパネル２５を操作して、所有するアイテム、または、マーケットの最新状態を表示するように、ＣＰＵ２１に指示する。ＣＰＵ２１は、アイテムＤＢ５３、または、マーケットＤＢにアクセスしてユーザが所有しているアイテムにかかる最新情報を取得する。ＣＰＵ２１は、取得した情報をタッチパネル２５に表示する。

マーケットＤＢ５４に、「登録処理中」の状態で新規レコードを作成し、トランザクションが登録された後に「販売可」の状態に変更することにより、ブロックチェーン上の情報と、マーケットＤＢ５４に記録された情報との間の齟齬、および、それによる取引の混乱を防止できる。

ＣＰＵ３１は所定の時間が経過しても「販売可」に変化しないレコードを、マーケットＤＢから削除しても良い。このようなレコードの発生数が所定の値を超える場合、ＣＰＵ３１からゲーム会社の担当者に通知することにより、ゲーム会社は不正アクセス等の外部からの攻撃に速やかに対処できる。ゲーム会社は、たとえば不正な行為を行なっていないにもかかわらず取引が成立しなかったユーザに対して、ブロックチェーン４０を介して支払った仮想通貨に対応するアイテムを提供するなどの処理を行なっても良い。

図１７は、アイテム取引のサブルーチンの処理の流れを説明するフローチャートである。アイテム取引のサブルーチンは、マーケットを介して他のユーザとの間でアイテムの取引を行なうサブルーチンである。図１７は、アイテムを購入する第２ユーザの情報処理装置２０において実行される。

ＣＰＵ２１は、マーケットに出品されているアイテムにかかる情報の要求を管理者サーバ３０に送信する（ステップＳ５６１）。ＣＰＵ３１は、要求を受信する（ステップＳ７３１）。ＣＰＵ３１は、マーケットＤＢ５４から状態フィールドに「販売中」と記録されているマーケットレコードを抽出する（ステップＳ７３２）。

なお、ＣＰＵ３１は、第２ユーザの口座ＩＤをキーとしてユーザＤＢ５１を検索して第２ユーザのレベルを抽出し、抽出したレベルに基づいてマーケットレコードの絞込みを行なっても良い。ＣＰＵ３１は、口座ＩＤに基づいてブロックチェーン４０から第２ユーザが保有する仮想通貨額を取得して、購入可能な価格にかかるマーケットレコードを抽出しても良い。

ＣＰＵ３１は、抽出したマーケットレコードにかかる情報を情報処理装置２０に送信する（ステップＳ７３３）。ＣＰＵ２１は、図１１を使用して説明した画面により、マーケットで販売されているアイテムを表示する（ステップＳ５６２）。

ＣＰＵ２１は、図１１および図１２を使用して説明した画面を介して、第２ユーザによるアイテムの選択を受け付ける。ＣＰＵ２１は、選択を受け付けたアイテムにかかる、出品ＩＤを管理者サーバ３０に送信する（ステップＳ５６３）。

ＣＰＵ３１は、出品ＩＤを受信する（ステップＳ７３４）。ＣＰＵ３１は、受け付けた出品ＩＤに対して、第２パスワードを発行する（ステップＳ７３５）。ここで第２パスワードは、たとえば乱数と日時とを組み合わせる等の所定のルールに基づいて作成される。ＣＰＵ３１は、受信した情報に基づいてマーケットＤＢ５４を更新する（ステップＳ７３６）。

具体的には、ＣＰＵ３１は、出品ＩＤをキーとしてマーケットＤＢ５４からレコードを抽出する。ＣＰＵ３１は、希望者口座ＩＤフィールドにステップＳ７３４で受信した口座ＩＤを記録する。ＣＰＵ３１は、第２パスワードフィールドにステップＳ７３５で発行した第２パスワードを記録する。ＣＰＵ３１は、取引期限フィールドに、現在日時から算出した所定の取引期限を記録する。ＣＰＵ２１は、第２ユーザから取引期限を取得してＣＰＵ３１に送信しても良い。ＣＰＵ３１は、状態フィールドに「取引中」を記録する。

ＣＰＵ３１は、第２パスワードを情報処理装置２０に送信する（ステップＳ７３７）。ＣＰＵ２１は、第２パスワードを受信する（ステップＳ５６５）。ＣＰＵ２１は、アイテム購入トランザクションを作成してブロックチェーン４０に送信する（ステップＳ５６６）。

アイテム購入トランザクションは、出品ＩＤ、購入者である第２ユーザの口座ＩＤ、第２パスワード、およびアイテムの価格相当額の仮想通貨が支払われることを条件にして、出品ＩＤに対応するアイテムを購入するスマートコントラクトを含む。アイテム購入トランザクションは、未検証情報としてブロックチェーン４０に記録される。

ＣＰＵは取引マイニングのサブルーチンを起動する（ステップＳ６３１）。取引マイニングのサブルーチンは、アイテム購入トランザクションを含むブロックのマイニングを行なうサブルーチンである。取引マイニングのサブルーチンの処理の流れは後述する。

ＣＰＵ３１は、ブロックチェーン４０を随時参照する（ステップＳ７４１）。ＣＰＵ３１は、ステップＳ７３４で受信した出品ＩＤを含むアイテム購入トランザクションの登録の有無を判定する（ステップＳ７４２）。具体的には、ＣＰＵ３１はブロックチェーンから出品ＩＤを含むトランザクションを抽出する。ＣＰＵ３１は、抽出したトランザクションに、ステップＳ７３４で受信した第１パスワードが含まれている場合に、出品ＩＤにかかるアイテム購入トランザクションが登録されていると判定する。

アイテム購入トランザクションが登録されていると判定した場合（ステップＳ７４２でＹＥＳ）、ＣＰＵ３１はステップＳ７３６で更新したマーケットレコードの状態フィールドを「成立済」に変更する（ステップＳ７４３）。

ＣＰＵ３１は、アイテムＤＢ５３を更新する（ステップＳ７４４）。具体的にはＣＰＵ３１は、処理中のマーケットレコードのアイテムＩＤフィールドに記録されたアイテムＩＤをキーとしてアイテムＤＢ５３を検索し、アイテムレコードを抽出する。ＣＰＵ３１は、抽出したアイテムレコードの口座ＩＤフィールドを、アイテムを購入したユーザの口座ＩＤに変更する。

アイテム購入トランザクションがブロックチェーンに登録されていないと判定した場合（ステップＳ７４２でＮＯ）、ＣＰＵ３１は、所定の時間が経過した後にステップＳ７４１に戻る。

マーケットＤＢ５４の状態フィールドに、「取引中」の状態を記録し、トランザクションが登録された後に「成立済」の状態に変更することにより、ブロックチェーン上の情報と、マーケットＤＢ５４に記録された情報との間の齟齬、および、それによる取引の混乱を防止できる。

ＣＰＵ３１は所定の時間が経過しても「成立済」に変化しないレコードの購入情報フィールドに記録された情報を削除しても良い。このようなレコードの発生数が所定の値を超える場合、ＣＰＵ３１からゲーム会社の担当者に通知することにより、ゲーム会社は不正アクセス等の外部からの攻撃に速やかに対処できる。ゲーム会社は、たとえば不正な行為を行なっていないにもかかわらず取引が成立しなかったユーザに対して、ブロックチェーン４０を介して支払った仮想通貨に対応するアイテムを提供するなどの処理を行なっても良い。

図１８は、取引マイニングのサブルーチンの処理の流れを説明するフローチャートである。取引マイニングのサブルーチンは、アイテム購入トランザクションを含むブロックのマイニングを行なうサブルーチンである。

ブロックチェーン４０においては、複数のＣＰＵにより平行してマイニングが行なわれる。以下の説明では１つのＣＰＵを例にして、マイニングの概要を説明する。ＣＰＵは、未検証情報を取得する（ステップＳ６４１）。以下では、ステップＳ６４１で取得した未検証情報が、アイテム取引のサブルーチンにおいてブロックチェーン４０に送信されたアイテム購入トランザクションである場合を例にして説明を続ける。

ＣＰＵは、アイテム購入のトランザクションに記録された出品ＩＤをキーとしてブロックチェーン４０から出品トランザクションを抽出する（ステップＳ６４２）。ＣＰＵは、出品トランザクションに記録されたアイテムの価格を取得する（ステップＳ６４３）。ＣＰＵは、支払元の口座ＩＤが保有する仮想通貨の額が、アイテムを購入可能な額であるか否かを判定する（ステップＳ６４４）。保有する仮想通貨の額が不足すると判定した場合（ステップＳ６４４でＮＯ）、ＣＰＵはステップＳ６４１で取得した未検証情報の処理を中止して、ステップＳ６４１に戻る。

保有する仮想通貨の額が十分であると判定した場合（ステップＳ６４４でＹＥＳ）、ＣＰＵはスマートコントラクトに記載された条件に基づき、ゲーム会社に支払う手数料を算出して、アイテム購入のトランザクションに記録する（ステップＳ６４５）。

ゲーム会社に支払う手数料は、たとえばアイテムの価格の５パーセントの定率である。図１１および図１２を使用して説明した画面において、アイテムの価格は、ゲーム会社に支払う手数料を含んだ額で表示されても、含まない金額で表示されても良い。手数料の率は、ユーザのレベル等によって異なるように定められても良い。

ＣＰＵは、複数のトランザクションをまとめてブロックチェーン４０の仕様に沿った新たなブロックを作り、ブロックチェーン４０に接続する（ステップＳ６４６）。ＣＰＵは、処理を終了する。

以上に説明したマイニングの処理により、アイテム購入トランザクションはブロックチェーン４０に組み込まれる。マイニングの完了に伴い、アイテムの価格またはアイテムの価格から手数料を引いた額に相当する仮想通貨が、購入者である第２ユーザの口座ＩＤから出品者である第１ユーザの口座ＩＤに送られる。手数料に相当する仮想通貨が、第２ユーザの口座ＩＤからゲーム会社の口座ＩＤに送られる。

なお、スマートコントラクトは、出品者からゲーム会社に対して手数料を支払うように設定されていても良い。このようにする場合、出品者はアイテムをマーケットに出品する際に手数料を支払うように設定されていても、出品したアイテムが売却された際に手数料を支払うように設定されていても良い。

スマートコントラクトは、出品者と購入者の双方からゲーム会社に対して手数料を支払うように設定されていても良い。

本実施の形態によると、様々な状況のユーザがゲームを楽しめる情報処理システム１０を提供できる。本実施の形態によると、ユーザ間でアイテムを売買可能な情報処理システム１０を提供できる。そのため、十分な時間を費やせないユーザと、経済的に厳しい状況のユーザとの間での助け合いが実現し、双方のユーザがゲームを楽しめる。

アイテムの取引が行なわれたこと、および、取引当事者の口座ＩＤがブロックチェーン４０に記録されるので、不正行為または詐欺などを防止できる。また、取引が記録されたブロックチェーン４０は公開されているので、ユーザに安心感と信頼感とを与えることができる。

ゲーム会社は、決済等の複雑な処理を行なわずに、自動的にチケットを販売できる。ゲーム会社がブロックチェーン４０からチケットＩＤを取得して、チケットＤＢ５２に記録することにより、チケットの偽造または二重使用等の不正を防止できる。ユーザは、金融機関等を介した法定通貨の送金手続を行なわずに、容易にチケットを購入できる。ゲーム会社からユーザへのアイテムの販売にはブロックチェーン４０を使用しないので、ユーザはマイニングの終了を待たずに、欲しいアイテムをすぐに入手できる。法定通貨を使用しないので、各国のユーザが同等の条件でゲームを楽しめる。

ブロックチェーン４０で使用される口座ＩＤをユーザＩＤに使用するので、ゲーム会社およびユーザがゲーム用のユーザＩＤを管理する労力を省ける。また、ゲーム会社がユーザの個人情報を取り扱う必要がない。

第１パスワードおよび第２パスワードを使用することにより、故意または偶然により、所有者の意図しないアイテム、または、本来存在しないアイテムがマーケットを介して販売されて、ユーザが損害を被ること、および、ゲーム全体のバランスが乱れることを防止できる。

アイテムＤＢ５３を使用することにより、取引されたアイテムの詳細情報を秘匿できる。そのため、たとえばいわゆるレアキャラに関する情報の流出を防止できる。ブロックチェーン４０に掲載する情報量を少なくすることにより、たとえばイーサリアムではガス（Gas）と称される手数料を節約できる。

ゲームは、対戦型のカードゲームに限定しない。ゲームは、たとえば、ロールプレイングゲーム、シューティングゲーム、または、コミュニュケーションゲーム等の任意の種類のゲームであっても良い。アイテムは、武将および武器に限定しない。ゲーム内で有償またはくじ引きで配布される任意のキャラクタおよび道具がアイテムに含まれる。

［実施の形態２］
本実施の形態は、ユーザ間の取引にチケットを使用する情報処理システム１０に関する。実施の形態１と共通する部分については、説明を省略する。

図１９は、実施の形態２のプログラムの処理の流れを説明するフローチャートである。ステップＳ５０７までは、図１３を使用して説明した実施の形態１のフローチャートと同様である。ただし、ステップＳ５０５で起動するアイテム購入のサブルーチンは、後述するように実施の形態１と異なるサブルーチンである。

アイテム出品の指示を受け付けていないと判定した場合（ステップＳ５０６でＮＯ）、または、ステップＳ５０７の終了後、ＣＰＵ２１は、ＣＰＵ２１は、ＣＰＵ３１と連携してゲームを実行する（ステップＳ５１０）。以後の処理は、図１３を使用して説明した実施の形態１のフローチャートと同様である。

図２０は、実施の形態２のアイテム購入のサブルーチンの処理の流れを説明するフローチャートである。

ＣＰＵ２１は、ユーザの口座ＩＤを送信して、ＣＰＵ３１にアイテムの販売情報を要求する（ステップＳ５８１）。ＣＰＵ３１は、要求を受信する（ステップＳ７５１）。ＣＰＵ３１は、ユーザに販売可能なアイテムを抽出する（ステップＳ７５２）。ここで、販売可能なアイテムには、ゲーム会社がユーザに直接販売するアイテムと、マーケットを介して他のユーザが販売するアイテムとの双方を含む。

ＣＰＵ３１は、抽出したアイテムを送信する（ステップＳ７５３）。ＣＰＵ２１は、送信されたアイテムを受信して、表示部２５１に表示する（ステップＳ５８３）。ＣＰＵ２１は、ゲーム会社が直接販売するアイテムと、マーケットを介して他のユーザが販売するアイテムとを、区別して表示しても良く、区別せずに表示しても良い。

ＣＰＵ２１は、ユーザによるアイテムの選択を受け付けて、管理者サーバ３０に送信する（ステップＳ５８４）。ＣＰＵ３１は、選択されたアイテムを受信する（ステップＳ７５４）。

ＣＰＵ３１は、ユーザＩＤをキーとしてチケットＤＢ５２を検索して、チケットレコードを抽出する。ＣＰＵ３１は、ＣＰＵ３１は、ユーザが保有する未使用チケットにより、選択したアイテムを購入できるか否かを判定する（ステップＳ７５５）。購入できると判定した場合（ステップＳ７５５でＹＥＳ）、ＣＰＵ３１は選択されたアイテムの売主はゲーム会社であるか否かを判定する（ステップＳ７５６）。

売主はゲーム会社であると判定した場合（ステップＳ７５６でＹＥＳ）、ＣＰＵ３１はチケットＤＢ５２を更新する（ステップＳ７５７）。具体的には、ＣＰＵ３１は、有効期限までの期間が短いチケットレコードから優先して、アイテムの価格に対応する数のチケットレコードを抽出し、使用済フィールドに「ＹＥＳ」を記録する。

ＣＰＵ３１は、アイテムＤＢ５３を更新する（ステップＳ７５８）。具体的には、ＣＰＵ３１はユーザが購入したアイテム数に対応する数の新規レコードをアイテムＤＢ５３に追加する。ＣＰＵ３１はユーザが購入したアイテムに固有のアイテムＩＤを付与し、アイテム詳細にかかる情報および購入したユーザの口座ＩＤを記録する。

売主はゲーム会社ではないと判定した場合（ステップＳ７５６でＮＯ）、ＣＰＵ３１は、マーケットＤＢ５４を更新する（ステップＳ７６１）。具体的には、ＣＰＵ３１は、出品ＩＤをキーとしてマーケットＤＢ５４からレコードを抽出する。ＣＰＵ３１は、希望者口座ＩＤフィールドに、受信した口座ＩＤを記録する。ＣＰＵ３１は、状態フィールドに「成立済」を記録する。

ＣＰＵ３１はチケットＤＢ５２を更新する（ステップＳ７６２）。具体的には、ＣＰＵ３１は、購入者のユーザＩＤをキーとしてチケットＤＢ５２を検索して、チケットレコードを抽出する。ＣＰＵ３１は、有効期限までの期間が短いチケットレコードから優先して、アイテムの価格に対応する数のチケットレコードを抽出し、使用済フィールドに「ＹＥＳ」を記録する。ステップＳ７６２およびステップＳ７６３の処理により、第１ユーザが所有するアイテムと、第２ユーザが所有するチケットとが交換される。

ＣＰＵ３１は、チケットＤＢ５２にアイテムの価格に対応する数の新規レコードを追加する。ＣＰＵ３１は、チケットＩＤフィールドに新しく作成したチケットＩＤを記録する。ＣＰＵ３１は、口座ＩＤフィールドにアイテムの売主の口座ＩＤを記録する。ＣＰＵ３１は、当日の日付を販売日フィールドに、販売日に基づいて算出した有効期限を有効期限フィールドに記録する。ＣＰＵ３１は、使用済フィールドに「ＮＯ」を記録する。

ＣＰＵ３１は、アイテムＤＢ５３を更新する（ステップＳ７６３）。具体的にはＣＰＵ３１は、処理中のマーケットレコードのアイテムＩＤフィールドに記録されたアイテムＩＤをキーとしてアイテムＤＢ５３を検索し、アイテムレコードを抽出する。ＣＰＵ３１は、抽出したアイテムレコードの口座ＩＤフィールドを、アイテムを購入したユーザの口座ＩＤに変更する。

ユーザが保有する未使用チケットにより、選択されたアイテムを購入できないと判定した場合（ステップＳ７５５でＮＯ）、または、ステップＳ７５８もしくはステップＳ７６３の終了後、ＣＰＵ３１は、情報処理装置２０にアイテムの購入に成功したか、失敗したかにかかる情報を送信する（ステップＳ７６４）。ＣＰＵ２１は情報を受信して表示部２５１に表示する（ステップＳ５８６）。ＣＰＵ２１は、処理を終了する。

ステップＳ７５７においてチケットＤＢ５２に新しいレコードを追加する代わりに、ＣＰＵ３１はチケットＤＢ５２から抽出したチケットレコードの口座ＩＤフィールドを、売主の口座ＩＤに書き換えても良い。このようにする場合、販売日フィールドおよび有効期限フィールドを新たな日付に変更しても良い。

ＣＰＵ３１は、マーケットを利用した、ユーザが所有するチケットの使用済フィールドを「ＮＯ」から「ＹＥＳ」に変更することにより、マーケットの利用手数料を徴収しても良い。ＣＰＵ３１は、マーケットを利用する権利をアイテムの一種としてユーザに販売しても良い。ＣＰＵ３１は、マーケットを利用する権利をゲームの報酬としてユーザに配布しても良い。

本実施の形態によると、ブロックチェーン４０を使用しないので、ユーザはマイニングの終了を待たずに、マーケットからすぐにアイテムを入手できる。また、ユーザ間の取引がブロックチェーン４０に記録されないので、ユーザのプライバシーを保護できる。

なお、ＣＰＵ３１は、ＣＰＵ２１を介してユーザからアイテムの対価をチケットで支払うか、仮想通貨で支払うかの選択を受け付けて、ユーザの選択に応じて処理を行っても良い。このようにする場合、ＣＰＵ３１はユーザがマーケットから購入するアイテムに限り、対価をチケットで支払うか、仮想通貨で支払うかの選択を受け付けても良い。ＣＰＵ３１は、売主がチケットと仮想通貨との双方を受け付ける場合に、対価をチケットで支払うか、仮想通貨で支払うかの選択を受け付けても良い。

チケットは、チケットＤＢ５２の代わりにブロックチェーン４０で管理されても良い。チケットは、チケット専用のブロックチェーン４０で管理されても、たとえばイーサリアムのような既存の仮想通貨のブロックチェーン４０で管理されても良い。

チケットがブロックチェーン４０で管理される場合、図２０を使用して説明したアイテム購入のサブルーチンにおいて、ステップＳ７５７およびステップＳ７６２の処理は、スマートコントラクトによりブロックチェーン上で実行される。

［実施の形態３］
本実施の形態は、ユーザからオンラインゲームに新たに参加するユーザの紹介を受け付け、紹介されたユーザがマーケットを介して取引をした場合に、ゲーム会社から紹介者に対して紹介料を支払う情報処理システム１０に関する。実施の形態１と共通する部分については、説明を省略する。

図２１は、実施の形態３の情報処理システム１０の概要を説明する説明図である。図２１は、図３と同様にユーザ間でアイテムの売買を行なう過程を説明する説明図である。以下ではアイテムを出品するユーザを第３ユーザ、マーケットからアイテムを購入するユーザを第４ユーザ、第３ユーザをゲーム会社に紹介したユーザを第１ユーザと記載する。また、図２１においては、マーケットの図示を省略する。

第３ユーザと第４ユーザとの間で売買されるアイテムは、本実施の形態の第２アイテムの一例である。第３ユーザが定めるアイテムの価格は、本実施の形態の第２価格の一例である。第３ユーザは、第２価格でアイテムを販売するスマートコントラクトを含むトランザクションを、ブロックチェーン４０に送信する。トランザクションは、マイニングにより検証されて、ブロックチェーン４０に組み込まれる。

第４ユーザは、アイテム購入にかかるスマートコントラクトを含むトランザクションを、ブロックチェーン４０に送信する。トランザクションは、マイニングにより検証されて、ブロックチェーン４０に組み込まれる。スマートコントラクトに基づいて、第４ユーザから第３ユーザに第２価格相当額の仮想通貨が支払われる。

スマートコントラクトに基づいて、第３ユーザまたは第４ユーザからゲーム会社に手数料相当額の仮想通貨が支払われる。なお、手数料は、第２価格相当額の一部に対応する額に定められる。スマートコントラクトに基づいて、ゲーム会社から第１ユーザに紹介料相当額の仮想通貨が支払われる。なお、紹介料はゲーム会社が受け取る紹介料の一部に対応する額に定められる。

図２２は、実施の形態３のユーザＤＢ５１のレコードレイアウトを説明する説明図である。ユーザＤＢ５１は、ユーザの口座ＩＤと、ログインパスワードと、ユーザのレベルと、紹介者の口座ＩＤとを関連づけて記録するＤＢである。紹介者の口座ＩＤは、本実施の形態の紹介情報の一例である。

ユーザＤＢ５１は、口座ＩＤフィールド、ログインパスワードフィールド、レベルフィールドおよび紹介者口座ＩＤフィールドを有する。口座ＩＤフィールドには、ユーザの口座ＩＤが記録されている。ログインパスワードフィールドには、ユーザが情報処理システム１０にログインする際に使用するログインパスワードが記録されている。

レベルフィールドにはユーザのレベルが記録されている。紹介者口座ＩＤフィールドには、ユーザをゲーム会社に紹介したユーザの口座ＩＤが記録されている。紹介者がいないユーザの紹介者口座ＩＤフィールドには「なし」と記録されている。ユーザＤＢ５１は、一人のユーザについて１つのレコードを有する。

図２３は、実施の形態３のアイテム出品のサブルーチンの処理の流れを説明するフローチャートである。図２３に示すサブルーチンは、図１６を使用して説明したサブルーチンの代わりに使用されるサブルーチンである。ステップＳ７２３までの処理は、図１６を使用して説明したサブルーチンの処理と同様であるので、説明を省略する。

ＣＰＵ３１は、口座ＩＤをキーとしてユーザＤＢ５１を検索してレコードを抽出し、紹介者口座ＩＤフィールドから紹介者の口座ＩＤを取得する（ステップＳ７７１）。なお、紹介者口座ＩＤフィールドに「なし」と記録されている場合には、口座ＩＤの代わりに紹介者がない旨が取得される。ＣＰＵ３１は、出品ＩＤ、紹介者の口座ＩＤおよび第１パスワードを情報処理装置２０に送信する（ステップＳ７７２）。

ＣＰＵ２１は、出品ＩＤ、紹介者の口座ＩＤおよび第１パスワードを受信する（ステップＳ５８１）。ＣＰＵ２１は、出品トランザクションを作成してブロックチェーン４０に送信する（ステップＳ５８２）。出品トランザクションは、出品ＩＤ、ユーザの口座ＩＤ、紹介者の口座ＩＤ、第１パスワード、および指定の価格相当額の仮想通貨が支払われることを条件にして、出品ＩＤに対応するアイテムが販売されるスマートコントラクトを含む。出品トランザクションは、未検証情報としてブロックチェーン４０に記録される。

ブロックチェーン４０においては、複数のＣＰＵにより平行してマイニングが行なわれる。ＣＰＵは、未検証情報を取得する（ステップＳ６２１）。以後の処理は、図１６を使用して説明したサブルーチンの処理と同様であるので、説明を省略する。

以上により、出品者の紹介者にかかる情報を含むトランザクションが、ブロックチェーン４０に記録される。

図２４は、実施の形態３の取引マイニングのサブルーチンの処理の流れを説明するフローチャートである。図２４に示すサブルーチンは、図１８を使用して説明したサブルーチンの代わりに使用されるサブルーチンである。ステップＳ６４５までの処理は、図１８を使用して説明したサブルーチンの処理と同様であるので、説明を省略する。

ＣＰＵは、出品トランザクションに基づいて出品者に紹介者がいるか否かを判定する（ステップＳ６５１）。紹介者がいると判定した場合（ステップＳ６５１でＹＥＳ）、ＣＰＵはスマートコントラクトに記載された条件に基づき、ゲーム会社から紹介者に支払う紹介料を算出して、アイテム購入のトランザクションに記録する（ステップＳ６５２）。紹介料は、たとえばゲーム会社が受け取る手数料の１パーセントの定率である。

紹介者がいないと判定した場合（ステップＳ６５１でＮＯ）、または、ステップＳ６５２の終了後、ＣＰＵは、複数のトランザクションをまとめてブロックチェーン４０の仕様に沿った新たなブロックを作り、ブロックチェーン４０に接続する（ステップＳ６５３）。ＣＰＵは、処理を終了する。

以上に説明したマイニングの処理により、アイテム購入トランザクションはブロックチェーン４０に組み込まれる。マイニングの完了に伴い、アイテムの代金に相当する仮想通貨が、購入者の口座ＩＤから出品者の口座ＩＤに送られる。手数料に相当する仮想通貨が、購入者の口座ＩＤからゲーム会社の口座ＩＤに送られる。紹介料に相当する仮想通貨が、ゲーム会社の口座ＩＤから紹介者に送られる。

なお、スマートコントラクトは、出品者または購入者から紹介者に対して紹介料を支払うように設定されていても良い。スマートコントラクトは、ゲーム会社、出品者および購入者の３者のうちの２者または３者から紹介者に対して紹介料を支払うように設定されていても良い。

［実施の形態４］
本実施の形態は、紹介料をチケットで支払う情報処理システム１０に関する。実施の形態３と共通する部分については、説明を省略する。

本実施の形態においては、アイテム出品のサブルーチン、および、取引マイニングのサブルーチンは、図１６および図１８を使用して説明した実施の形態１のアイテム出品のサブルーチン、および、取引マイニングのサブルーチンを使用する。

図２５は、実施の形態４のアイテム取引のサブルーチンの処理の流れを説明するフローチャートである。図２５に示すアイテム取引のサブルーチンは、図１７を使用して説明したアイテム取引のサブルーチンの代わりに使用されるサブルーチンである。ステップＳ７４４までの処理は、図１７を使用して説明したサブルーチンの処理と同様であるので、説明を省略する。

ＣＰＵ３１は、出品者に紹介者がいるか否かを判定する（ステップＳ７８１）。具体的には、ＣＰＵ３１は、ステップＳ７３４で受信した出品ＩＤをキーとしてマーケットＤＢ５４を検索してレコードを抽出し、出品者口座ＩＤフィールドから出品者の口座ＩＤを取得する。ＣＰＵ３１は、出品者の口座ＩＤをキーとしてユーザＤＢ５１を検索してレコードを抽出する。抽出したレコードの紹介者口座ＩＤフィールドに口座ＩＤが記録されている場合、ＣＰＵ３１は紹介者がいると判定する。

紹介者がいると判定した場合（ステップＳ７８１でＹＥＳ）、ＣＰＵ３１はチケットＤＢ５２を更新して、紹介者にチケットを付与する（ステップＳ７８２）。紹介者がないと判定した場合（ステップＳ７８１でＮＯ）、ＣＰＵ３１は以後の処理を行なわない。

本実施の形態によると、紹介料をチケットで支払う情報処理システム１０を提供できる。チケットを支払うことにより、紹介者がゲームを行なう意欲を高めることができる。

［実施の形態５］
本実施の形態は、ユーザ間でアイテムの貸し借りを行なう情報処理システム１０に関する。すなわち、本実施の形態においては、マーケットにおけるアイテムの「販売」はアイテムを所定の期間使用する権利の販売を意味する。実施の形態１と共通する部分については、説明を省略する。

図２６は、実施の形態５のアイテム取引のサブルーチンの処理の流れを説明するフローチャートである。図２６に示すアイテム取引のサブルーチンは、図１７を使用して説明したアイテム取引のサブルーチンの代わりに使用されるサブルーチンである。ステップＳ７４４までの処理は、図１７を使用して説明したサブルーチンの処理と同様であるので、説明を省略する。

ＣＰＵ３１は、所定の貸し出し期間の経過を待つ（ステップＳ７９１）。ＣＰＵ３１は、たとえばマーケットＤＢ５４の出品期限フィールドに記録された日を、貸し出し期間の終了日であると判定する。ＣＰＵ３１は、貸し出しを開始した日を基準に、貸し出し期間の終了日を判定しても良い。貸し出し期間は、時間単位または分単位等の短い期間で定めても良い。貸し出し期間をユーザが任意に定められるようにしても良い。

貸し出し期間の経過後、ＣＰＵ３１はアイテムＤＢ５３を更新する（ステップＳ７９２）。具体的にはＣＰＵ３１は、処理中のマーケットレコードのアイテムＩＤフィールドに記録されたアイテムＩＤをキーとしてアイテムＤＢ５３を検索し、アイテムレコードを抽出する。ＣＰＵ３１は、抽出したアイテムレコードの口座ＩＤフィールドを、アイテムの元の持ち主のユーザの口座ＩＤに戻す。

本実施の形態によると、出品者は、たとえば試験前などあまりゲームで遊べない期間に、アイテムを他のユーザに貸し出すことができる。購入者は、使用経験のないアイテムを他のユーザから借りて試すことにより、自分の好みに合うアイテムを探すことができる。また、十分に育成されたアイテムを他のユーザから借りて試すことにより、アイテムを育成する意欲を高めることができる。

なお、出品者がアイテムの売却と一時貸し出しとを選択できるようにしても良い。購入者が、アイテムの購入と一時借用とを選択できるようにしても良い。

［実施の形態６］
図２７は、実施の形態６の情報処理装置２０の機能ブロック図である。情報処理装置２０は、ネットワークを介して仮想通貨にかかるブロックチェーン４０に接続されている。情報処理装置２０は、送信部２４１を有する。

送信部２４１は、オンラインゲームに利用可能であり、有効期限が定められたチケットを所定の仮想通貨を用いて購入するための、オンラインゲームのユーザからオンラインゲームの管理者に宛てたトランザクション４１を、仮想通貨にかかるブロックチェーン４０に送信させる。

トランザクション４１は、ユーザが保有する仮想通貨の量が、送信されたトランザクション４１にかかる条件を満たす場合に、チケットをユーザに対して販売させるスマートコントラクト４２を含む。

［実施の形態７］
本実施の形態は、汎用のサーバコンピュータ９０とプログラム９７とを組み合わせて動作させることにより、本実施の形態の情報処理システム１０を実現する形態に関する。図２８は、実施の形態７の情報処理システム１０の構成を示す説明図である。なお、実施の形態１と共通する部分の説明は省略する。

本実施の形態の情報処理システム１０は、ネットワークを介して接続された多数の情報処理装置２０およびサーバコンピュータ９０を備える。情報処理装置２０と、サーバコンピュータ９０とは、ネットワークを介してブロックチェーン４０に接続されている。

サーバコンピュータ９０は、ＣＰＵ３１、主記憶装置３２、補助記憶装置３３、通信部３４、読取部３６およびバスを備える。

プログラム９７は、可搬型記録媒体９６に記録されている。ＣＰＵ３１は、読取部３６を介してプログラム９７を読み込み、補助記憶装置３３に保存する。またＣＰＵ３１は、サーバコンピュータ９０に実装されたフラッシュメモリ等の半導体メモリ９８に記憶されたプログラム９７を読出しても良い。さらに、ＣＰＵ３１は、通信部３４および図示しないネットワークを介して接続される図示しない他のサーバコンピュータからプログラム９７をダウンロードして補助記憶装置３３に保存しても良い。

プログラム９７は、サーバコンピュータ９０の制御プログラムとしてインストールされ、主記憶装置３２にロードして実行される。これにより、これにより、サーバコンピュータ９０は上述した管理者サーバ３０として機能する。

それぞれの情報処理装置２０には、図示しないアプリケーション提供サーバからネットワークを介して補助記憶装置２３に本実施の形態のプログラムが転送される。プログラムは、情報処理装置２０の制御プログラムとしてインストールされ、主記憶装置２２にロードして実行される。以上によりサーバコンピュータ９０と情報処理装置２０とブロックチェーン４０とは連動して上述の情報処理システム１０として機能する。

各実施例で記載されている技術的特徴（構成要件）はお互いに組合せ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１０ 情報処理システム
２０ 情報処理装置
２１ ＣＰＵ
２２ 主記憶装置
２３ 補助記憶装置
２４ 通信部
２４１ 送信部
２５ タッチパネル
２５１ 表示部
２５２ 入力部
３０ 管理者サーバ
３１ ＣＰＵ
３２ 主記憶装置
３３ 補助記憶装置
３４ 通信部
３６ 読取部
４０ ブロックチェーン
４１ トランザクション
４２ スマートコントラクト４２
５１ ユーザＤＢ
５２ チケットＤＢ
５３ アイテムＤＢ
５４ マーケットＤＢ
７１ カード欄
７２ 価格入力欄
７３ 決定ボタン
７４ 購入ボタン
７５ 検索ボタン
７６ 価格表示欄
７７ 同意欄
９０ サーバコンピュータ
９６ 可搬型記録媒体
９７ プログラム
９８ 半導体メモリ

Claims (16)

1. オンラインゲームに利用可能であり、有効期限が定められたチケットを所定の仮想通貨を用いて購入するための、前記オンラインゲームのユーザから前記オンラインゲームの管理者に宛てたトランザクションを、前記仮想通貨にかかるブロックチェーンに送信させ、
   前記ユーザが保有する前記仮想通貨の量が、送信された前記トランザクションにかかる条件を満たす場合に、前記チケットを前記ユーザに対して販売させるスマートコントラクトを実行させる
   情報処理方法。
2. 販売された前記チケットに付与されたチケットＩＤを管理者サーバに記憶させる
   請求項１に記載の情報処理方法。
3. 前記チケットの価値に対応するアイテムと、該チケットとを交換する
   請求項１または請求項２に記載の情報処理方法。
4. 前記オンラインゲームの第１ユーザから、販売を希望するアイテムと、該アイテムの価格とを取得し、
   取得した前記アイテムと前記価格とを公開し、
   前記オンラインゲームの第２ユーザから前記アイテムにかかる購入希望を取得し、
   前記アイテムと、前記第２ユーザが保有する前記価格に対応する前記チケットとを交換する
   請求項１から請求項３のいずれか一つに記載の情報処理方法。
5. オンラインゲームの第１ユーザから、販売を希望するアイテムと、該アイテムの価格とを取得し、
   取得した前記アイテムと前記価格とを公開し、
   前記オンラインゲームの第２ユーザから前記アイテムにかかる購入希望を取得し、
   前記第２ユーザから前記第１ユーザに宛てたトランザクションをブロックチェーンに送信させ、
   前記ブロックチェーンを介して、前記第２ユーザによる前記価格の支払いを条件に、取得した購入希望にかかる前記アイテムの所有権を前記第１ユーザから前記第２ユーザに移転させるスマートコントラクトを実行させる
   情報処理方法。
6. 前記ブロックチェーンは、所定の仮想通貨にかかる取引を記録し、
   前記価格は、前記仮想通貨の額で定められている
   請求項５に記載の情報処理方法。
7. 前記ブロックチェーンは、前記オンラインゲームに利用可能なチケットにかかる取引を記録し、
   前記価格は、前記チケットの量で定められている
   請求項５に記載の情報処理方法。
8. 前記スマートコントラクトが実行された場合、前記アイテムの所有権が前記第１ユーザから前記第２ユーザに移転されたことを管理者サーバに記憶させる
   請求項５から請求項７のいずれか一つに記載の情報処理方法。
9. 前記価格の一部を、前記第１ユーザまたは前記第２ユーザから前記オンラインゲームの管理者に対して送金させる処理を実行させる
   請求項８に記載の情報処理方法。
10. 前記第１ユーザから、前記オンラインゲームを新たに参加する第３ユーザの紹介情報を取得し、
    取得した前記紹介情報を記録する
    請求項５から請求項９のいずれか一つに記載の情報処理方法。
11. 前記第３ユーザから、販売を希望する第２アイテムと、該第２アイテムの第２価格とを取得し、
    取得した前記第２アイテムと前記第２価格とを公開し、
    前記オンラインゲームの第４ユーザから前記第２アイテムにかかる購入希望を取得し、
    前記第４ユーザから前記第３ユーザに宛てたトランザクションを前記ブロックチェーンに送信させ、
    前記ブロックチェーンを介して、前記第４ユーザによる前記第２価格の支払いを条件に、取得した購入希望にかかる前記第２アイテムの所有権を前記第３ユーザから前記第４ユーザに移転させる前記スマートコントラクトを実行させる
    請求項１０に記載の情報処理方法。
12. 前記スマートコントラクトが実行された場合、前記第２アイテムの所有権が前記第３ユーザから前記第４ユーザに移転されたことを管理者サーバに記憶させる
    請求項１１に記載の情報処理方法。
13. 前記第２価格の一部を、前記第３ユーザまたは前記第４ユーザから前記オンラインゲームの管理者に対して送金させる処理を実行させる
    請求項１１に記載の情報処理方法。
14. 前記第２価格の一部を、前記管理者、前記第３ユーザまたは前記第４ユーザから前記第１ユーザに対して送金させる処理を実行させる
    請求項１３に記載の情報処理方法。
15. オンラインゲームに利用可能であり、有効期限が定められたチケットを所定の仮想通貨を用いて購入するための、前記オンラインゲームのユーザから前記オンラインゲームの管理者に宛てたトランザクションを、前記仮想通貨にかかるブロックチェーンに送信させる送信部を備え、
    前記トランザクションは、前記ユーザが保有する前記仮想通貨の量が、送信された前記トランザクションにかかる条件を満たす場合に、前記チケットを前記ユーザに対して販売させるスマートコントラクトを含む
    情報処理装置。
16. オンラインゲームのサーバから、販売中のアイテムと、該アイテムの価格との一覧を取得し、
    取得した一覧を表示し、
    表示した一覧から購入アイテムの選択を受け付け、
    前記購入アイテムの所有者に宛てた、該購入アイテムを購入するスマートコントラクトを含むトランザクションをブロックチェーンに送信する
    処理をコンピュータに実行させるプログラム。

Images