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

Abstract

【課題】 電子マネーの運用を希望する事業者が簡便に電子マネーを発行することができる技術を提供すること。【解決手段】 情報処理装置は、発行すべき電子通貨に関する電子通貨情報を第１のユーザから取得し、取得した電子通貨情報に対応する電子通貨の発行の要求を第１のユーザから受け付け、受け付けた要求に対する承認を第２のユーザから受け付け、承認を受け付けた場合に、電子通貨を発行する。【選択図】図１

Description

本発明は、情報処理装置、情報処理方法、およびプログラムに関し、特に電子マネーに関する情報処理装置、情報処理方法、およびプログラムに関する。

これまで、複数の事業者によって、複数の電子通貨や仮想通貨などの電子決済システムが運営されている。例えば、特許文献１には、仮想通貨の移転（トランザクション）を有効化するシステムが開示されている。

特許６５２１４２１号公報

ここで、電子通貨の中には、事業者以外の者が提供するサービスでも利用可能なものがある。このような電子通貨は発行免許を有する者のみが新規に発行することができることが資金決済法によって定められている。そのため、電子通貨の発行を希望する事業者は、発行免許を取る、または発行免許を有する別の事業者に発行を依頼する必要がある。しかしながら、発行免許を有しない事業者が発行免許を取得するのには時間がかかり、発行免許を有する事業者であっても電子通貨の管理システムを開発するために時間がかかる。このため、電子通貨の運用を希望する事業者が電子通貨を発行させる際の利便性の低さが課題であった。

本発明は、上述の問題に鑑みて成されたものであり、電子通貨の運用を希望する事業者が簡便に電子通貨を発行することができる技術を提供することを目的とする。

本発明は、例えば情報処理装置であって、
外部装置への接続を提供するための通信部と、
プロセッサと、
を含み、前記プロセッサは、
前記通信部を介して、電子通貨の発行を希望する運用事業者に対応する第１の外部装置から、前記運用事業者が発行を希望する電子通貨の名称を含む電子通貨情報を取得し、
前記通信部を介して、取得した前記電子通貨情報に対応する前記電子通貨の発行の要求を前記第１の外部装置から受け付け、
前記要求を受け付けた場合に、電子通貨の発行免許を有する発行体に対応する第２の外部装置に前記要求に対する承認を要求し、
受け付けた前記要求に対する承認を前記第２の外部装置から受け付け、
前記承認を受け付けた場合に、前記電子通貨を発行する。

本発明によれば、電子通貨の運用を希望する事業者が簡便に電子通貨を発行することができる技術を提供することができる。

第１の実施形態に係る電子通貨管理システムを示す図。 図１の管理サーバのハードウェア構成を示す図。 図１の管理サーバのソフトウェア構成を示す図。 図１の発行体装置のソフトウェア構成を示す図。 図１の運用事業者装置のソフトウェア構成を示す図。 図１の利用者装置のソフトウェア構成を示す図。 管理サーバで管理される発行体情報の一例を示す図。 管理サーバで管理される発行事業者情報の一例を示す図。 管理サーバで管理される利用者情報の一例を示す図。 管理サーバで管理される電子通貨情報の一例を示す図。 管理サーバで管理されるウォレット情報の一例を示す図。 図１の電子通貨管理システムが実行するユーザ登録処理の一例を示す図。 図１の電子通貨管理システムが実行する電子通貨発行処理の一例を示す図。 管理サーバで管理される供託情報の一例を示す図。 図１の電子通貨管理システムが実行する残高生成処理の一例を示す図。 図１の電子通貨管理システムが実行する償却処理の一例を示す図。

以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態で説明されている特徴の組み合わせの全てが発明に必須のものとは限らない。実施形態で説明されている複数の特徴のうち二つ以上の特徴は任意に組み合わされてもよい。また、同一若しくは同様の構成には同一の参照番号を付し、重複した説明は省略する。

＜第１の実施形態＞
以下、本実施形態に係る電子通貨管理システムについて説明する。本実施形態に係る電子通貨管理システム１は、管理サーバ１０、発行体装置１１、運用事業者装置１２、および利用者装置１３を含む。管理サーバ１０、発行体装置１１、運用事業者装置１２、利用者装置１３はネットワークを介して通信可能に接続される。

管理サーバ１０は、発行体、運用事業者、および利用者の登録を行う登録処理、発行体または運用事業者からの要求に応じた電子通貨の発行処理、発行体、運用事業者、および利用者のいずれか要求に応じた電子通貨の移転処理を行うための情報処理装置である。管理サーバ１０は、運用事業者から発行の要求を受け付け、電子通貨の発行免許を有する発行体から発行の要求に対する承認を受け付けた場合に電子通貨を発行することで、運用事業者および発行体が簡便に電子通貨を発行するサービスを提供する。

発行体装置１１は、発行体によって操作されるパソコン、スマートフォン、タブレットなどの情報処理装置である。本実施形態において、発行体とは電子通貨の発行免許を有する銀行などの事業者である。運用事業者装置１２は、運用事業者によって操作されるパソコン、スマートフォン、タブレットなどの情報処理装置である。本実施形態において、運用事業者とは、運用事業者の経済圏で利用者に商品またはサービスを提供するために電子通貨の運用を希望する事業者である。本実施形態では、運用事業者は、電子通貨の発行免許を有していないものとして説明を行う。しかしながら、運用事業者が電子通貨の発行免許を有していてもよく、その場合は発行体と運用事業者が同一であってもよい。利用者装置１３は、運用事業者の経済圏で、商品またはサービスの提供を受ける対価として電子通貨を支払う利用者（消費者）が操作するパソコン、スマートフォン、タブレットなどの情報処理装置である。

なお、図１の例において、電子通貨管理システム１は、管理サーバ１０、発行体装置１１、運用事業者装置１２、および利用者装置１３をそれぞれ１つずつ含むものとして説明を行うが、管理サーバ１０、発行体装置１１、運用事業者装置１２、および利用者装置１３の少なくともいずれかが複数存在してもよい。また、本明細書では、発行体、運用事業者、および利用者をユーザと称する。

次に、図２を参照して、管理サーバ１０のハードウェア構成の一例について説明する。管理サーバ１０は、プロセッサ２０１、メモリ２０２、ストレージ２０３、ネットワークインタフェース（Ｉ／Ｆ）２０４、および入出力Ｉ／Ｆ２０５を備える。

プロセッサ２０１は、管理サーバ１０の全体を制御する制御部である。プロセッサ２０１は、ストレージ２０３に格納されたプログラムまたはオペレーティングシステム（ＯＳ）を実行するＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、およびマイクロコントローラの少なくとも何れかを含む。メモリ２０２は、プロセッサ２０１のワークメモリとして用いられるＤＲＡＭ（Dynamic Random Access Memory）、ＳＲＡＭ（Static Random Access Memory）などで構成される。

ストレージ２０３は、プロセッサ１０１が実行するプログラム、ＯＳ、並びにプログラムによって使用されるデータテーブルおよび設定値の少なくとも何れかを格納するＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）を含む。入出力Ｉ／Ｆ２０５は、ユーザ操作を受け付けるためのキーボード、タッチパネル、およびマイクの少なくともいずれかを含む入力機器、ならびにディスプレイ、スピーカー、およびＬＥＤの少なくともいずれかを含む出力機器を含むユーザインタフェースである。なお、本明細書では発行体装置１１、運用事業者装置１２、および利用者装置１３も、管理サーバ１０と同様のハードウェア構成であるものとして説明を行う。

また、管理サーバ１０のストレージ２０３は、発行体情報データベース（ＤＢ）、運用事業者情報ＤＢ、利用者情報ＤＢ、電子通貨情報ＤＢ、ウォレット情報ＤＢ、供託情報ＤＢを格納するものとして説明を行う。しかしながら、発行体情報ＤＢ、運用事業者情報ＤＢ、利用者情報ＤＢ、電子通貨情報ＤＢ、ウォレット情報ＤＢ、および供託情報ＤＢの少なくともいずれかは、外部のストレージデバイスに記憶されてもよいし、複数のデバイスに分散して記憶される分散型ＤＢであってもよい。一例では、発行体情報データベースＤＢ、運用事業者情報ＤＢ、利用者情報ＤＢ、電子通貨情報ＤＢ、ウォレット情報ＤＢ、および供託情報ＤＢの少なくともいずれかは、ブロックチェーン上に台帳の形式として保存されてもよい。これによって、データ改ざんに対する耐性を向上することができる。発行体情報ＤＢ、運用事業者情報ＤＢ、利用者情報ＤＢ、電子通貨情報ＤＢ、ウォレット情報ＤＢ、および供託情報ＤＢのデータ構造については後述する。

続いて、図３を参照して、管理サーバ１０のソフトウェア構成の一例について説明する。図３に示す機能は、ストレージ２０３に記憶されたプログラムをメモリ２０２に展開してプロセッサ２０１が実行することによって実現される。管理サーバ１０は、発行体情報管理部３０１、運用事業者情報管理部３０２、利用者情報管理部３０３、通貨情報管理部３０４、ウォレット情報管理部３０５、認証部３０６、通貨発行部３０７、通貨移転部３０８、通貨償却部３０９、および供託情報管理部３１０を備える。

発行体情報管理部３０１は、発行体から受け付けた登録要求に応じて発行体情報ＤＢに新たな発行体情報を登録する。本実施形態では、発行体情報ＤＢに発行体情報を登録することを、「発行体のアカウントを作成する」と称する。ここで、図７を参照して発行体情報ＤＢが有するデータ構造の一例について説明する。

図７の発行体情報は、識別子（ＩＤ）７０１、パスワード７０２、名称７０３、事業体識別番号７０４、および所在地７０５を含む。

ＩＤ７０１は、発行体のアカウントに関連付けられた一意の識別子である。パスワード７０２は、発行体装置１１から管理サーバ１０に発行体情報の登録要求、発行体情報の更新要求、通貨発行要求などの後述する操作を要求するために必要な認証情報である。名称７０３は、発行体の名称であり、例えば「株式会社ｘｘｘｘｘｘ」といった文字列である。事業体識別番号７０４は、例えばＤ−Ｕ−Ｎ−Ｓ番号などの企業識別コードである。所在地７０５は発行体の所在地を示す文字列である。

また、発行体情報管理部３０１は、発行体から受け付けた更新要求に応じて発行体情報ＤＢに登録された発行体情報を更新する。これらの発行体情報の登録処理、更新処理については後述する。

運用事業者情報管理部３０２は、運用事業者から受け付けた登録要求に応じて運用事業者情報を運用事業者情報ＤＢに登録する。本実施形態では、運用事業者情報ＤＢに運用事業者情報を登録することを、「運用事業者のアカウントを作成する」ここで、図８を参照して運用事業者情報ＤＢが有するデータ構造の一例について説明する。

図８の運用事業者情報は、識別子（ＩＤ）８０１、パスワード８０２、名称８０３、事業体識別番号８０４、所在地８０５、および発行体ＩＤ８０６を含む。

ＩＤ８０１は、運用事業者のアカウントに関連付けられた一意の識別子である。パスワード８０２は、運用事業者装置１２から管理サーバ１０に運用事業者情報の登録要求、運用事業者情報の更新要求、電子通貨の移転要求などの後述する操作を要求するために必要な認証情報である。名称８０３は、運用事業者の名称である。事業体識別番号８０４は、例えばＤ−Ｕ−Ｎ−Ｓ番号などの企業識別コードである。所在地８０５は運用事業者の所在地を示す文字列であり、発行体ＩＤ８０６は、運用事業者が電子通貨の発行を依頼する発行体のＩＤであり、発行体情報ＤＢの発行体情報のＩＤ７０１に対応する。

また、運用事業者情報管理部３０２は、運用事業者から受け付けた更新要求に応じて運用事業者情報ＤＢに登録された運用事業者情報を更新する。これらの運用事業者情報の登録処理、更新処理については後述する。

利用者情報管理部３０３は、電子通貨の利用者から受け付けた登録要求に応じて利用者情報を利用者情報ＤＢに登録する。ここで、図９を参照して利用者情報ＤＢが有するデータ構造の一例について説明する。

図９の利用者情報は、ＩＤ９０１、パスワード９０２、名称９０３、所在地９０４、および状態９０５を含む。

ＩＤ９０１は、利用者のアカウントに関連付けられた一意の識別子である。パスワード７０２は、利用者装置１３から管理サーバ１０に利用者情報の登録要求、利用者情報の更新要求、通貨移転要求などの後述する操作を要求するために必要な認証情報である。名称９０３は、利用者の名称であり、利用者が個人である場合には氏名である。所在地９０４は利用者の所在地を示す住所などの文字列である。状態９０５は、運用事業者によって利用者の本人確認が完了して電子通貨が利用可能であるか（ｖａｌｉｄ）、本人確認が完了していないか（ｉｎｖａｌｉｄ）を示す。

また、利用者情報管理部３０３は、利用者から受け付けた更新要求に応じて利用者情報ＤＢに登録された利用者情報を更新する。これらの利用者情報の登録処理、更新処理については後述する。

通貨情報管理部３０４は、発行予定、または既に発行された電子通貨に関する電子通貨情報を管理する。ここで、図１０を参照して電子通貨情報ＤＢが有するデータ構造の一例について説明する。

図１０の電子通貨情報は、ＩＤ１００１、名称１００２、ペッグペア１００３、レート１００４、有効期間１００５、状態１００６、供託ＩＤ１００７、残高１００８、シンボル名称１００９、および運用事業者ＩＤ１０１０を含む。

ＩＤ１００１は、電子通貨に関連付けられた一意の識別子である。名称１００２は、発行体または運用事業者によって付けられた電子通貨の名称である。ペッグペア１００３は、電子通貨との為替レートを一定に保つための特定の通貨であり、例えば日本円（JPY）、米国ドル（USD）などである。レート１００４は、電子通貨の単位当たりのペッグペアの数量を示す。例えば、ペッグペア１００３が「日本円」で、レート１００４が「２」である場合、その電子通貨は日本円で２円の価値を有することを示す。有効期間１００５は、電子通貨の有効期間を示す。例えば、期間を限定して電子通貨を流通させたい場合に、発行体または運用事業者によって設定される。これによって、運用事業者の要求に応じて、電子通貨の流通開始や流通終了をスケジューリングすることができる。状態１００６は、登録された電子通貨情報に対して発行体からの承認を受けたか（Ａｃｋｎｏｗｌｅｄｇｅｄ）否か（Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ）を判定可能な情報を格納する。供託ＩＤ１００７は、後述する供託情報ＤＢのＩＤに対応する。残高１００８は、供託によって移転可能な状態になった電子通貨の残量を示す。シンボル名称１００９は、通貨記号や略称など、通貨の名前を省略して表記するための情報を示す。運用事業者ＩＤ１０１０は、電子通貨の登録を依頼した運用事業者のＩＤを示し、図８のＩＤ８０１に対応する。

また、通貨情報管理部３０４は、ユーザから受け付けた更新要求に応じて通貨情報ＤＢに登録された電子通貨情報を更新する。これらの電子通貨情報の登録処理、更新処理については後述する。

ウォレット情報管理部３０５は、発行体、運用事業者、および利用者によって作成され、それぞれのユーザが保有する電子通貨の残高を管理するためのウォレット情報ＤＢを管理する。ここで、図１１を参照してウォレット情報ＤＢのデータ構造の一例について説明する。

図１１のウォレット情報は、ＩＤ１１０１、アカウント１１０２、残高１１０３を含む。

ＩＤ１１０１は、ウォレットに関連付けられた一意の識別子である。アカウント１１０２は、ウォレットの所有者のアカウントに関する情報である。例えば、利用者によってウォレットが作成された場合、当該ウォレットは利用者のＩＤに関連付けられる。すなわち、アカウント１１０２は、発行体のＩＤ７０１、運用事業者のＩＤ８０１、および利用者のＩＤ９０１の少なくともいずれかに対応し得る。残高１１０３は、ウォレットの所有者が有する電子通貨の残高である。一例では、ウォレット情報の残高１１０３は、電子通貨のＩＤと、残高との組み合わせからなる情報であってもよい。また、ウォレットが複数種類の電子通貨の残高を有する場合には、電子通貨のＩＤと残高との組み合わせを複数含んでもよい。

ウォレット情報管理部３０５は、ユーザから受け付けた更新要求に応じてウォレット情報ＤＢに登録されたウォレット情報を更新する。これらのウォレット情報の登録処理、更新処理については後述する。

認証部３０６は、ユーザから操作を受け付けるためにユーザ認証を行う。例えば、認証部３０６は、ユーザからＩＤとパスワードの組み合わせ（ＩＤ７０１およびパスワード７０２、ＩＤ８０１およびパスワード８０２、またはＩＤ９０１およびパスワード９０２）を受け付け、発行体情報ＤＢ、運用事業者情報ＤＢ、および利用者情報ＤＢからＩＤとパスワードの組み合わせが有効であると判断すると、応答としてアクセストークンを送信する。アクセストークンを受け取ったユーザは、アクセストークンの有効期間内にアクセストークンを使用することで管理サーバ１０に操作を要求することができる。

通貨発行部３０７は、運用事業者装置１２から受け付けた電子通貨の登録処理、発行体装置１１から受け付けた電子通貨の承認処理、供託物の確認処理を行い、電子通貨を移転可能な状態にする。本実施形態では、登録された電子通貨を移転可能な状態となった場合に、「電子通貨が発行された」と表現する。通貨移転部３０８は、発行された電子通貨の移転要求に応じてウォレットからウォレットへと移転する。通貨償却部３０９は、発行体または運用事業者からの要求に応じて発行した電子通貨を移転不可能な状態にする。本実施形態では、発行された電子通貨が移転不可能な状態となった場合に、「電子通貨が償却された」と表現する。

供託情報管理部３１０は、承認された電子通貨について、流通させるにあたって発行体から受領した供託物に関する情報を管理する。ここで、ここで、図１４を参照して供託情報ＤＢが有するデータ構造の一例について説明する。

図１４の供託情報は、ＩＤ１４０１、発行体ＩＤ１４０２、運用事業者ＩＤ１４０３、供託種別１４０４、受領日１４０５、受領者名１４０６、受領量１４０７、評価額１４０８、評価者名１４０９、評価日１４１０、状態１４１１を含む。

ＩＤ１４０１は、供託情報に関連付けられた一意の識別子である。発行体ＩＤ１４０２は、運用事業者から供託物を受領した発行体のＩＤに対応し、運用事業者ＩＤ１４０３は、供託した運用事業者のＩＤに対応する。供託種別１４０４は、供託物として発行体が受領した日本円などの通貨、不動産、株券などの資産の種別を示す。受領日１４０５は発行体が運用事業者から供託物を受領した日時を示し、受領者名１４０６は運用事業者から供託物を受領した発行体の担当者名を示す。受領量１４０７は通貨や株券など数量を有する資産が供託されている場合の供託された数量を示す。評価額１４０８は、供託物の評価額を示し、評価者名１４０９は評価額を決定した評価者の名称を示す。評価日１４１０は評価額を決定した日時を示す。状態１４１１は、未受領であるか（Ｐｅｎｄｉｎｇ）、受領済みであるか（Ｅｖａｌｕａｔｉｏｎ＿Ｐｅｎｄｉｎｇ）、受領済みかつ評価済みであるか（Ｅｖａｌｕａｔｅｄ）を示す供託の状態を示す。

続いて、図４を参照して、発行体装置１１のソフトウェア構成の一例について説明する。図４に示す機能は、発行体装置１１のストレージ２０３に記憶されたプログラムをメモリ２０２に展開してプロセッサ２０１が実行することによって実現される。発行体装置１１は、発行体登録部４０１、運用事業者登録部４０２、電子通貨承認部４０３、供託情報提供部４０４、および認証部４０５を有する。

発行体登録部４０１は、管理サーバ１０に発行体のアカウント登録を要求する。運用事業者登録部４０２は、発行体に電子通貨の依頼を要求した運用事業者に関する情報を登録する。電子通貨承認部４０３は、運用事業者装置１２によって登録された電子通貨について、ユーザからの承認操作に応じて管理サーバ１０に電子通貨の承認を行う。供託情報提供部４０４は、運用事業者から受領した供託物に関する情報を管理サーバ１０に提供する。認証部４０５は、管理サーバ１０との通信を行うために管理サーバ１０の認証部３０６と認証情報の送受信を行う。

続いて、図５を参照して、運用事業者装置１２のソフトウェア構成の一例について説明する。図５に示す機能は、運用事業者装置１２のストレージ２０３に記憶されたプログラムをメモリ２０２に展開してプロセッサ２０１が実行することによって実現される。運用事業者装置１２は、運用事業者情報提供部５０１、電子通貨登録要求部５０２、電子通貨情報提供部５０３、供託情報提供部５０４、残高生成要求部５０５、ウォレット生成要求部５０６、移転要求部５０７、償却要求部５０８、および認証部５０９を有する。

運用事業者情報提供部５０１は、発行体装置１１の運用事業者登録部４０２によって管理サーバ１０に登録された運用事業者情報を更新する情報を提供する。電子通貨登録要求部５０２は、発行体に発行を依頼する電子通貨を管理サーバ１０に登録するよう要求する。電子通貨情報提供部５０３は、電子通貨登録要求部５０２からの要求に応じて管理サーバ１０に登録された電子通貨に関する情報を更新する。供託情報提供部５０４は、電子通貨を発行するために運用事業者から発行体に受け渡した供託物についての情報を管理サーバ１０に提供する。残高生成要求部５０５は、電子通貨承認部４０３によって承認された電子通貨について管理サーバ１０に残高を生成するよう要求する。ウォレット生成要求部５０６は、運用事業者のアカウントに関連付けられたウォレットを生成するよう管理サーバに要求する。移転要求部５０７は、運用事業者のウォレットから利用者のウォレットへ、または利用者のウォレット間での電子通貨の移転を要求する。償却要求部５０８は、残高を生成した電子通貨について、移転不可能な状態に設定するよう管理サーバ１０に要求する。認証部５０９は、管理サーバ１０との通信を行うために管理サーバ１０の認証部３０６と認証情報の送受信を行う。

続いて、図６を参照して、利用者装置１３のソフトウェア構成の一例について説明する。図６に示す機能は、利用者装置１３のストレージ２０３に記憶されたプログラムをメモリ２０２に展開してプロセッサ２０１が実行することによって実現される。利用者装置１３は、登録要求部６０１、ウォレット生成要求部６０２、移転要求部６０３、および認証部６０４を有する。

登録要求部６０１は、管理サーバ１０に利用者のアカウントの登録を要求する。ウォレット生成要求部６０２は、登録要求部６０１で登録した利用者のアカウントに関連付けられたウォレットの生成を管理サーバ１０に要求する。移転要求部６０３は、ウォレット生成要求部６０２で生成したウォレットと、他の利用者または運用事業者のウォレットとの間での電子通貨の移転を管理サーバ１０に要求する。認証部６０４は、管理サーバ１０との通信を行うために管理サーバ１０の認証部３０６と認証情報の送受信を行う。

続いて、図１２を参照して、電子通貨管理システムが実行するユーザ登録処理の一例を説明する。図１２のシーケンスでは、管理サーバ１０、発行体装置１１、および運用事業者装置１２のプロセッサが、それぞれのストレージに記憶されたプログラムを実行することで実現される。

まず、Ｓ１２０１で、運用事業者装置１２は管理サーバ１０に対して、運用事業者および発行体の一時アカウント作成要求を送信する。一例では、一時アカウント作成要求とともに、運用事業者装置１２は、管理サーバ１０から発行体装置１１および運用事業者装置１２に情報を通知するためのメールアドレスなどの情報を送信する。一例では、一時アカウント作成要求には、発行体の名称、発行体の事業者識別番号、運用事業者の名称、および運用事業者の事業者識別番号の少なくともいずれかを含んでもよい。なお、一例では、Ｓ１２０１では運用事業者または管理サーバ１０の管理者が管理サーバ１０の入出力Ｉ／Ｆ２０５を介して、管理サーバ１０に一時アカウント作成要求を入力してもよい。

一時アカウント作成要求を受信した管理サーバ１０は、発行体および運用事業者のそれぞれのＩＤおよびパスワードが発行体情報ＤＢおよび運用事業者情報ＤＢに記憶されていなければ、新規に登録し（Ｓ１２０２）、一時アカウント作成要求に対する応答として、発行体装置１１に割り当てられたＩＤおよびパスワードを含むアカウント情報を通知し（Ｓ１２０３）、運用事業者装置１２に割り当てられたＩＤおよびパスワードを含むアカウント情報を通知する（Ｓ１２０４）。発行体装置１１および運用事業者装置１２は、通知されたＩＤおよびパスワードをストレージに記憶する、または発行体装置１１および運用事業者１２それぞれのユーザに通知する。これによって、発行体装置１１および運用事業者装置１２が、後述するアカウントの有効化を要求することができる。

続いて、発行体装置１１は、通知されたＩＤおよびパスワードを使用して管理サーバ１０の認証部３０６との認証を行う（Ｓ１２０５）。Ｓ１２０５で受信したＩＤおよびパスワードが発行体情報ＤＢに格納されている、すなわち発行体装置１１の認証が成功すると、管理サーバ１０は発行体装置１１にアクセストークンを送信する（Ｓ１２０６）。

続いて、発行体装置１１は受信したアクセストークンを使用して発行体アカウントの有効化を要求する（Ｓ１２０７）。Ｓ１２０７において、発行体装置１１は、発行体の名称、所在地、および識別番号の少なくともいずれかを含む発行体情報を管理サーバ１０に送信してもよい。例えば、発行体のＩＤを含む「https://.../issuers/（発行体ＩＤ）」のように管理サーバ１０にＨＴＴＰＳのＰＯＳＴリクエストＰＵＴリクエスト、またはＧＥＴリクエストを送信するとともに、リクエストに上述した発行体の名称、所在地、および識別番号の少なくともいずれかを含むパラメータを設定することでＳ１２０７の処理が行われてもよい。

続いて、管理サーバ１０はＳ１２０７で受信した発行体アカウントの要求に応じて、発行体情報管理部３０１によって発行体情報ＤＢを更新する（Ｓ１２０８）。これによって発行体のアカウントを有効化することができる。続いて、管理サーバ１０はＳ１２０７への応答として発行体アカウントのＩＤ（図７のＩＤ７０１）を発行体装置１１に送信する（Ｓ１２０９）。一例では、発行体装置１１は、運用事業者装置１２に発行体ＩＤを通知してもよい。

続いて、発行体装置１１は受信したアクセストークンを使用して運用事業者アカウントの有効化を要求する（Ｓ１２１０）。Ｓ１２１０において、発行体装置１１は運用事業者の名称、所在地、および識別番号の少なくともいずれかを含む運用事業者情報を管理サーバ１０に送信する。これによって、管理サーバ１０は、有効化すべき運用事業者を特定することができる。しかしながら、一例では、Ｓ１２０４でＩＤおよびパスワードを受信した運用事業者装置１２はＩＤを発行体装置１１に送信し、発行体装置１１はＳ１２１０において運用事業者アカウントのＩＤを用いて運用事業者アカウントの有効化を要求してもよい。また、Ｓ１２０７と同様に、例えば、発行体のＩＤを含む「https://.../issuers/（発行体ＩＤ）」のように管理サーバ１０にＨＴＴＰＳのＰＯＳＴリクエスト、ＰＵＴリクエスト、またはＧＥＴリクエストを送信するとともに、リクエストに上述した運用事業者の名称、所在地、および識別番号の少なくともいずれかを含むパラメータを設定することでＳ１２１０の処理が行われてもよい。

なお、Ｓ１２０７の発行体アカウントの有効化と、Ｓ１２１０の運用事業者アカウントの有効化とは連続せずに行われてもよい。そのような場合は、発行体装置１１は、Ｓ１２１０の運用事業者アカウントの有効化の前にもＳ１２０５と同様の認証処理を行い、アクセストークンを受信しなおしてもよい。

続いて、管理サーバ１０はＳ１２１０で受信した運用事業者アカウントの要求に応じて、運用事業者情報管理部３０２によって運用事業者情報ＤＢを更新する（Ｓ１２１１）。これによって運用事業者アカウントを有効化することができる。続いて、管理サーバ１０はＳ１２１０への応答として運用事業者アカウントのＩＤ（図８のＩＤ８０１）を発行体装置１１に送信する（Ｓ１２１２）。一例では、発行体装置１１は、運用事業者装置１２に発行体ＩＤを通知してもよい。

以上の処理によって、発行体装置１１および運用事業者装置１２によって管理サーバ１０の発行体情報ＤＢおよび運用事業者情報ＤＢにアカウントを登録することができる。

続いて、図１３を参照して、電子通貨管理システムが実行する電子通貨を発行する処理の一例を説明する。図１３のシーケンスでは、管理サーバ１０、発行体装置１１、および運用事業者装置１２のプロセッサが、それぞれのストレージに記憶されたプログラムを実行することで実現される。

まず、運用事業者装置１２は運用事業者に割り当てられたＩＤおよびパスワード使用して管理サーバ１０との認証を行い（Ｓ１３０１）、アクセストークンを受け取る（Ｓ１３０２）。Ｓ１３０１およびＳ１３０２の処理はＳ１２０５およびＳ１２０６と同様のため説明を省略する。

続いて、運用事業者装置１２はアクセストークンを使用して管理サーバ１０に、発行体ＩＤ、運用事業者ＩＤとともに電子通貨の登録要求を送信する（Ｓ１３０３）。例えば、Ｓ１３０３では、電子通貨の名称、シンボル名称、ペッグペア、交換レート、および有効期間の少なくともいずれかを含む電子通貨情報を管理サーバ１０に送信してもよい。一例では、Ｓ１３０３では、運用事業者装置１２は、発行体ＩＤおよび運用事業者ＩＤを含む「https://.../tokenSpec/（発行体ＩＤ）/（運用事業者ＩＤ）」のような形式のＨＴＴＰＳのＰＯＳＴリクエスト、ＰＵＴリクエスト、またはＧＥＴリクエストを管理サーバ１０に送信してもよい。電子通貨の登録要求を受信した管理サーバ１０は、アクセストークンの認証に成功すると、通貨情報管理部３０４によって電子通貨情報ＤＢに受け取った情報を登録するとともに電子通貨のＩＤを生成し（Ｓ１３０４）、運用事業者装置１２に電子通貨ＩＤを通知する（Ｓ１３０５）。電子通貨ＩＤを受信した運用事業者装置１２は、電子通貨ＩＤを発行体装置１１に通知する（Ｓ１３０６）。なお、一例では、Ｓ１３０６の処理は省略され、運用事業者装置１２のユーザが、発行体装置１１のユーザに伝える、または発行体装置１１に入力してもよい。一方、Ｓ１３０６の処理によってユーザ負荷を抑えてさらに簡便に電子通貨の発行処理を進めることができる。

続いて、運用事業者装置１２は、管理サーバ１０に、アクセストークンを使用して発行体ＩＤ、運用事業者ＩＤ、およびＳ１３０５で通知された電子通貨ＩＤとともに、電子通貨の承認処理の開始を要求する（Ｓ１３０７）。例えば、Ｓ１３０３では、承認要求を送信した運用事業者の担当者名などの付加的な情報を管理サーバ１０に送信してもよい。一例では、Ｓ１３０７では、運用事業者装置１２は、発行体ＩＤ、運用事業者ＩＤ、および電子通貨ＩＤを含む「https://.../tokenSpec/（発行体ＩＤ）/（運用事業者ＩＤ）/（電子通貨ＩＤ）」のような形式のＨＴＴＰＳのＰＯＳＴリクエスト、ＰＵＴリクエスト、またはＧＥＴリクエストを管理サーバ１０に送信してもよい。電子通貨の承認要求を受信した管理サーバ１０は、アクセストークンの認証に成功すると、登録されている電子通貨情報に基づいて電子通貨を発行するための条件を満たしているか否かを判断する。例えば、電子通貨情報に名称１００２、ペッグペア１００３およびレート１００４が登録されていることなどの所定の条件を満たすと判断した場合に、管理サーバ１０は電子通貨情報が電子通貨を発行するための条件を満たしていると判断する。電子通貨情報が電子通貨を発行するための条件を満たしていないと判断した場合は、管理サーバ１０は運用事業者装置１２にエラー通知を行う。電子通貨情報が電子通貨を発行するための条件を満たしていると判断した場合は、管理サーバ１０は運用事業者装置１２に肯定応答（ACK）を送信して以降の処理に進むよう通知を行う（Ｓ１３０８）。

Ｓ１３０９で通知を受けた運用事業者装置１２は、アクセストークンを使用して運用事業者からの承認を管理サーバ１０に通知する（Ｓ１３０９）。一例では、Ｓ１３０９では、運用事業者装置１２は、「https://.../tokenSpec/（発行体ＩＤ）/（運用事業者ＩＤ）/（電子通貨ＩＤ）」のような形式のＨＴＴＰＳのＰＯＳＴリクエスト、ＰＵＴリクエスト、またはＧＥＴリクエストを管理サーバ１０に送信してもよい。管理サーバ１０は、アクセストークンの認証に成功し、Ｓ１３０９の運用事業者からの承認を受信すると、電子通貨情報ＤＢの状態１００６を「承認済み」に設定し（Ｓ１３１０）、Ｓ１３１１で処理結果（肯定応答または否定応答）を運用事業者装置１２に送信する。一例では、管理サーバ１０は、発行体装置１１に承認の要求を送信してもよい。別の例では、運用事業者装置１２から発行体装置１１に承認要求を電子メールなどの形式で送信してもよい。

続いて、発行体装置１１は発行体に割り当てられたＩＤおよびパスワード使用して管理サーバ１０との認証を行い（Ｓ１３１２）、アクセストークンを受け取る（Ｓ１３１３）。Ｓ１３１２およびＳ１３１３の処理はＳ１２０５およびＳ１２０６と同様のため説明を省略する。

続いて、発行体装置１１はアクセストークンを使用して管理サーバ１０に、発行体ＩＤ、運用事業者ＩＤ、および電子通貨ＩＤを含む発行体の承認情報を送信する（Ｓ１３１４）。例えば、Ｓ１３１３では、承認した発行体の担当者名などの付加情報を管理サーバ１０に送信してもよい。一例では、Ｓ１３１３では、発行体装置１１は、発行体ＩＤおよび運用事業者ＩＤを含む「https://.../tokenSpec/（発行体ＩＤ）/（運用事業者ＩＤ）/（電子通貨ＩＤ）」のような形式のＨＴＴＰＳのＰＯＳＴリクエスト、ＰＵＴリクエスト、またはＧＥＴリクエストを管理サーバ１０に送信してもよい。発行体側の承認情報を受信した管理サーバ１０は、電子通貨情報ＤＢの状態１００６を「承認済み」に設定するとともに、肯定応答を発行体装置１１に送信する（Ｓ１３１５）。

続いて、運用事業者装置１２は、運用事業者に割り当てられたＩＤおよびパスワード使用して管理サーバ１０との認証を行い（Ｓ１３１６）、アクセストークンを受け取る（Ｓ１３１７）。Ｓ１３１６およびＳ１３１７の処理はＳ１２０５およびＳ１２０６と同様のため説明を省略する。

続いて、運用事業者装置１２はアクセストークンを使用して管理サーバ１０に、発行体ＩＤ、運用事業者ＩＤとともに供託情報を送信する（Ｓ１３１８）。例えば、Ｓ１３１８では、供託の種別や、供託量を管理サーバ１０に送信する。一例では、Ｓ１３１８では、発行体装置１１は、発行体ＩＤおよび運用事業者ＩＤを含む「https://.../deposits/（発行体ＩＤ）/（運用事業者ＩＤ）」のような形式のＨＴＴＰＳのＰＯＳＴリクエスト、ＰＵＴリクエスト、またはＧＥＴリクエストを管理サーバ１０に送信してもよい。このリクエストのパラメータとして供託の種別や、供託量を管理サーバ１０に送信してもよい。

続いて、管理サーバ１０は受信した供託情報に基づいて供託情報ＤＢに供託情報の登録を行い（Ｓ１３１９）、供託情報ＤＢのＩＤ１４０１を送信する（Ｓ１３２０）。

そして、運用事業者は、送信した供託情報に対応する供託物とともに供託ＩＤを発行体に受け渡す。発行体が供託物を受領すると、発行体による操作に応じて発行体装置１１は、発行体に割り当てられたＩＤおよびパスワード使用して管理サーバ１０との認証を行い（Ｓ１３２１）、アクセストークンを受け取る（Ｓ１３２２）。Ｓ１３２１およびＳ１３２２の処理はＳ１２０５およびＳ１２０６と同様のため説明を省略する。

続いて、発行体装置１１は、アクセストークンと、発行体ＩＤ、運用事業者ＩＤ、電子通貨ＩＤおよび供託ＩＤとを使用して供託物の受領を管理サーバ１０に報告する（Ｓ１３２３）。例えば、Ｓ１３２３では受領報告は受領者名１４０６、受領日１４０５、および受領量１４０７の情報を含む。例えば、発行体装置１１は「https://.../deposits/（発行体ＩＤ）/（運用事業者ＩＤ）/（電子通貨ＩＤ）/（供託ＩＤ）」のように管理サーバ１０にＨＴＴＰＳのＰＯＳＴリクエスト、ＰＵＴリクエスト、またはＧＥＴリクエストを送信するとともに、リクエストに上述した受領者名１４０６、受領日１４０５、および受領量１４０７、並びに供託物の状態（Ｅｖａｌｕａｔｉｏｎ＿Ｐｅｎｄｉｎｇ）の情報を含むパラメータを設定することでＳ１３２３の処理が行われてもよい。

Ｓ１３２３で供託物の受領報告を受けた管理サーバ１０は、アクセストークンの認証に成功すると受領報告に含まれる供託ＩＤに対応する供託情報ＤＢの状態を、供託物を受領したことを示す「Ｅｖａｌｕａｔｉｏｎ＿Ｐｅｎｄｉｎｇ」に設定し、受領者名１４０６、受領日１４０５、および受領量１４０７などの情報を受信した情報に基づいて供託情報ＤＢの更新を行う（Ｓ１３２４）。そして供託情報ＤＢの更新に成功した場合はＳ１３２１で肯定応答をＳ１３２５で運用事業者装置１２に送信する。発行体ＩＤ、運用事業者ＩＤ、電子通貨ＩＤ、および供託ＩＤの組み合わせに誤りがある、またはアクセストークンの認証に失敗した場合は、管理サーバ１０は否定応答をＳ１３２５で運用事業者装置１２に送信する。

続いて、発行体による供託物の評価が完了すると、発行体装置１１は、アクセストークンと、発行体ＩＤ、運用事業者ＩＤ、電子通貨ＩＤおよび供託ＩＤとを使用して供託物の評価完了を管理サーバ１０に報告する（Ｓ１３２６）。例えば、Ｓ１３２６では評価完了報告は供託種別１４０４、評価者名１４０９、評価日１４１０、および評価額１４０８の情報を含んでもよい。例えば、発行体装置１１は「https://.../deposits/（発行体ＩＤ）/（運用事業者ＩＤ）/（電子通貨ＩＤ）/（供託ＩＤ）」のように管理サーバ１０にＨＴＴＰＳのＰＯＳＴリクエスト、ＰＵＴリクエスト、またはＧＥＴリクエストを送信するとともに、リクエストに上述した評価者名１４０９、評価日１４１０、および評価額１４０８、並びに供託のステータス（Ｅｖａｌｕａｔｅｄ）の情報を含むパラメータを設定することでＳ１３２６の処理が行われてもよい。

Ｓ１３２６で供託物の受領報告を受けた管理サーバ１０は、アクセストークンの認証に成功すると受領報告に含まれる供託ＩＤに対応する供託情報ＤＢの状態を、供託を受領したことを示す「Ｅｖａｌｕａｔｅｄ」に設定し、受信した評価者名１４０９、評価日１４１０、および評価額１４０８に関する情報に基づいて供託情報ＤＢの更新を行う（Ｓ１３２７）。そして供託情報ＤＢの更新に成功した場合はＳ１３２８で肯定応答を運用事業者装置１２に送信し、発行体ＩＤ、運用事業者ＩＤ、電子通貨ＩＤ、および供託ＩＤの組み合わせに誤りがある、またはアクセストークンの認証に失敗した場合に否定応答をＳ１３２８で運用事業者装置１２に送信する。

以上の図１３の処理によって、発行体と運用事業者とが承認した電子通貨であって、発行体と運用事業者との間で送受された供託物の評価が完了している電子通貨を、移転可能な状態にする、すなわち発行することができる。

続いて、図１５を参照して、電子通貨管理システム１が実行する電子通貨移転処理の一例を説明する。図１５のシーケンスでは、管理サーバ１０、発行体装置１１、および運用事業者装置１２のプロセッサが、それぞれのストレージに記憶されたプログラムを実行することで実現される。

まず運用事業者装置１２は、運用事業者に割り当てられたＩＤおよびパスワード使用して管理サーバ１０との認証を行い（Ｓ１５０１）、アクセストークンを受け取る（Ｓ１５０２）。Ｓ１５０１およびＳ１５０２の処理はＳ１２０５およびＳ１２０６と同様のため説明を省略する。

続いて、Ｓ１５０３で、運用事業者装置１２は管理サーバ１０に対して、アクセストークンを使用して電子通貨の残高生成要求を送信する。残高生成要求は発行体ＩＤ、運用事業者ＩＤ、電子通貨ＩＤを含む。一例では、運用事業者装置１２は、残高生成要求とともに、発行数量を指定する情報を送信してもよい。運用事業者装置１２は、発行数量を指定する情報を入力Ｉ／Ｆを介して取得してもよい。別の例では、残高生成要求を受け付けた管理サーバが、供託された評価額に基づいて発行可能な量の残高の電子通貨を生成する場合には発行数量の指定を受信しなくてもよい。一例では、Ｓ１５０３では、運用事業者装置１２は、「https://.../tokenSpec/（発行体ＩＤ）/（運用事業者ＩＤ）/（電子通貨ＩＤ）/mint」のような形式のＨＴＴＰＳのＰＯＳＴリクエストＰＵＴリクエスト、またはＧＥＴリクエストを管理サーバ１０に送信してもよい。このリクエストに含まれる「mint」の文字列によって、管理サーバ１０は残高生成要求であると判断することができる。

続いて、管理サーバ１０は、Ｓ１５０４で、受信した残高生成要求に基づいて残高が生成可能か否かを判断する。例えば、管理サーバ１０は、残高生成要求に含まれる運用事業者ＩＤに対応する供託の状態が「Ｅｖａｌｕａｔｅｄ」である場合に、残高が生成可能であると判断してもよい。あるいは、管理サーバ１０は、残高生成要求に含まれる運用事業者ＩＤに対応する供託の状態が「Ｅｖａｌｕａｔｅｄ」であって、残高生成要求に含まれる発行数量×運用事業者に対応する電子通貨情報のレート１００４×ペッグペア１００３より、運用事業者に対応する供託情報の評価額１４０８の方が大きい場合に残高が生成可能であると判断してもよい。

Ｓ１５０４で残高が生成可能であると判断すると、管理サーバ１０は、電子通貨情報ＤＢの残高１００８に生成した残高の量を設定し（Ｓ１５０５）、生成した電子通貨の残高を運用事業者装置１２にＳ１５０３への応答として送信する（Ｓ１５０６）。

続いて、Ｓ１５０７で、運用事業者装置１２は管理サーバ１０に対して、アクセストークンを使用してウォレットの生成要求を送信する。一例では、Ｓ１５０９では、運用事業者装置１２は、「https://.../wallets/（発行体ＩＤ）/（運用事業者ＩＤ）/（電子通貨ＩＤ）」のような形式のＨＴＴＰＳのＰＯＳＴリクエスト、ＰＵＴリクエスト、またはＧＥＴリクエストを管理サーバ１０に送信してもよい。この「wallets」に対応する電子通貨ＩＤが電子通貨情報ＤＢに含まれていないと判断した場合、管理サーバ１０はウォレットの生成要求であると判断することができる。

ウォレットの生成要求を受信した管理サーバ１０は、Ｓ１５０８においてウォレット情報管理部３０５でウォレット情報ＤＢに運用事業者ＩＤに関連付けてウォレット情報を登録する。そして、ウォレットのＩＤ１１０１を運用事業者装置１２に送信する（Ｓ１５０９）。

なお、Ｓ１５０７〜Ｓ１５０９の処理は、Ｓ１５０１〜Ｓ１５０６の前に実行されてもよい。この場合、管理サーバ１０は、Ｓ１５０１〜Ｓ１５０６で生成した残高を運用事業者ＩＤに対応するウォレットの残高に生成した電子通貨を追加してもよい。

続いて、Ｓ１５１０で、利用者装置１３は運用事業者装置１２にアクセスし、利用契約を行う。Ｓ１５１０では、利用者装置１３は運用事業者装置１２に、銀行口座や住所などの本人確認（Know Your Customer）が可能な情報を送信する。

続いて、利用者装置１３は、管理サーバ１０にアクセスし、利用者アカウントの生成要求を行う（Ｓ１５１１）。本実施形態では、生成要求は、利用者が希望するＩＤおよびパスワードに関する情報を含むものとする。また、この際、利用者装置１３は、利用者の名称９０３および所在地９０４などの付加情報を送信してもよい。なお、管理サーバ１０は、生成要求に含まれるＩＤがすでに利用者情報ＤＢに登録されている場合には、変更するよう要求してもよい。

続いて、管理サーバ１０は利用者情報管理部３０３で利用者情報ＤＢにＩＤ９０１およびパスワード９０２を登録する（Ｓ１５１２）。また、ウォレット情報ＤＢに、Ｓ１５１２で生成したＩＤ９０１に対応するウォレットを生成し（Ｓ１５１３）、生成したウォレットのウォレット情報に含まれるＩＤ１１０１をＳ１５１１への応答として送信する（Ｓ１５１４）。これによって、利用者のアカウントおよびウォレットを生成することができる。

なお、本実施形態において、利用者は、運用事業者が提供するサービスを受けることを意図して管理サーバ１０にウォレットの生成を要求する。したがって、利用者装置１３は、利用を希望する電子通貨または運用事業者に関する情報を利用者アカウントの生成要求に含めてもよい。この場合、管理サーバ１０は、利用者のウォレット情報の残高１１０３に、利用を希望する電子通貨を示す情報を含めてもよい。例えば、上述したようにウォレット情報の残高１１０３が電子通貨のＩＤと残高との組み合わせを含む場合、新規に利用を希望する電子通貨に対応する電子通貨ＩＤをウォレット情報の残高１１０３に追加し、当該電子通貨ＩＤの残高を例えば０などの値に設定してもよい。

また、本実施形態に係る電子通貨管理システムは、複数種類の電子通貨を扱うことができる。このため、例えばすでにある電子通貨を利用している利用者が別の電子通貨の利用を希望する際、利用者装置１３は、電子通貨の利用要求をＳ１５１２と同様に電子通貨の利用要求を送信してもよい。この場合、管理サーバ１０は、利用要求に含まれるＩＤ、パスワードがすでに利用者情報ＤＢに登録されていると判断し、利用者ＩＤに基づいて利用者のウォレットを特定し、ウォレットの残高１１０３に利用を希望する電子通貨の電子通貨ＩＤを追加してもよい。

続いて、運用事業者装置１２はＳ１２０５およびＳ１２０６と同様に、運用事業者に割り当てられたＩＤおよびパスワード使用して管理サーバ１０との認証を行い（Ｓ１５１５）、アクセストークンを受け取る（Ｓ１５１６）。

運用事業者は、Ｓ１５１０で受け取った情報に基づいて、利用者の身元確認を行い、電子通貨を利用可能な顧客であるか否かを判断する。運用事業者が利用者による電子通貨の利用が可能であると判断すると、運用事業者は運用事業者装置１２を操作して管理サーバ１０に確認完了を通知する（Ｓ１５１７）。例えば、Ｓ１５１７では、運用事業者装置１２は、「https://.../wallets/（発行体ＩＤ）/（運用事業者ＩＤ）/（利用者のウォレットＩＤ）」のような形式のＨＴＴＰＳのＰＯＳＴリクエスト、ＰＵＴリクエスト、またはＧＥＴリクエストを管理サーバ１０に送信してもよい。このリクエストのパラメータとして本人確認種類の種別などの付加情報を管理サーバ１０に送信してもよい。これによって管理サーバ１０が利用者のウォレットを利用であると設定することができる。管理サーバ１０は利用者が電子通貨の移転が可能な状態であることを示す情報（ｖａｌｉｄ）を利用者情報ＤＢの状態９０５に設定して利用者情報ＤＢを更新し（Ｓ１５１８）、運用事業者装置１２に肯定応答を送信する（Ｓ１５１９）。

続いて、運用事業者装置１２または利用者装置１３による移転要求の一例について説明する。ここでは、運用事業者装置１２からの要求に応じて電子通貨を移転する例について説明するが、利用者装置１３からの要求に応じて電子通貨を移転する場合も同様に適用可能である。例えば、利用者が運用事業者の銀行口座に振り込みを行うことによって、管理サーバ１０は運用事業者装置１２から利用者アカウントに電子通貨を移転すると判断することができる。また、利用者間で電子通貨の送受を行うために利用者装置１３から移転要求を送信することで管理サーバ１０は電子通貨を移転すると判断することができる。

まず、運用事業者装置１２はＳ１２０５およびＳ１２０６と同様に、運用事業者に割り当てられたＩＤおよびパスワード使用して管理サーバ１０との認証を行い（Ｓ１５２０）、アクセストークンを受け取る（Ｓ１５２１）。

続いて、運用事業者装置１２は、管理サーバ１０に移転を要求する（Ｓ１５２２）。例えば、Ｓ１５１２では、運用事業者装置１２は、「https://.../wallets/（発行体ＩＤ）/（運用事業者ＩＤ）/（電子通貨ＩＤ）/（移転元のウォレットＩＤ）/transfer」のような形式のＨＴＴＰＳのＰＯＳＴリクエスト、ＰＵＴリクエスト、またはＧＥＴリクエストを管理サーバ１０に送信してもよい。このリクエストのパラメータとして、移転先のウォレットＩＤ、移転する数量、移転方法（単純移転またはスマートコントラクト）などの付加情報を管理サーバ１０に送信する。

管理サーバ１０は、Ｓ１５２２で受信した移転要求から、移転元のウォレットＩＤ、移転先のウォレットＩＤ，および移転させる電子通貨の量を取得する（Ｓ１５２３）。Ｓ１５２３では、移転させる電子通貨の種類をさらに特定してもよい。Ｓ１５２３で電子通貨の移転に必要な情報を取得した管理サーバ１０は、取得した情報に基づいてウォレット情報ＤＢを更新する（Ｓ１５２４）。具体的には、管理サーバ１０は、移転元のウォレットＩＤに含まれる残高から、指定された電子通貨ＩＤの移転する数量分だけ減らし、移転先のウォレットＩＤに含まれる残高から、指定された電子通貨ＩＤの移転する数量分だけ増やす。なお、移転元のウォレットＩＤに含まれる残高が、指定された移転する数量よりも少ない場合は、管理サーバ１０は、運用事業者装置１２にエラー通知を行ってもよい。移転に成功した場合には、管理サーバ１０は移転を要求元である運用事業者装置１２に肯定応答を送信する（Ｓ１５２５）。一例では、移転元と移転先のアカウントにも移転が完了した旨を通知する。

続いて、図１６を参照して、電子通貨を償却する処理について説明する。例えば、電子通貨情報ＤＢに登録された電子通貨の有効期間になった場合や、電子通貨の提供を終了すると判断した運用事業者が操作する運用事業者装置１２からの償却要求を受け付けた場合に、管理サーバ１０が電子通貨を償却すると判断する。図１６の例では、運用事業者装置１２からの償却要求を受け付けて電子通貨を償却する処理について説明する。

まず、運用事業者装置１２はＳ１２０５およびＳ１２０６と同様に、運用事業者に割り当てられたＩＤおよびパスワード使用して管理サーバ１０との認証を行い（Ｓ１６０１）、アクセストークンを受け取る（Ｓ１６０２）。

続いて、運用事業者装置１２はアクセストークンを使用して、管理サーバ１０に電子通貨の償却要求を送信する（Ｓ１６０３）。一例では、Ｓ１６０３では、運用事業者装置１２は、「https://.../tokenSpec/（発行体ＩＤ）/（運用事業者ＩＤ）/（電子通貨ＩＤ）/burn」のような形式のＨＴＴＰＳのＰＯＳＴリクエスト、ＰＵＴリクエスト、またはＧＥＴリクエストを管理サーバ１０に送信してもよい。このリクエスト内に含まれる「burn」という文字列によって、管理サーバ１０は電子通貨の償却要求であると判断することができる。一例では、償却要求は償却数量を指定する情報を含んでもよい。これによって、管理サーバ１０は、電子通貨の全量ではなく、一部を償却して、経済圏で流通させる電子通貨の数量を調整することができる。

償却要求を受信した管理サーバ１０は、電子通貨情報ＤＢから、指定された電子通貨ＩＤの残高を０にする、または状態１００６を「移転不可」などに設定するよう電子通貨情報ＤＢを更新する（Ｓ１６０４）。一例では、運用事業者装置１２は、続いて、管理サーバ１０は電子通貨の償却が完了を運用事業者装置１２に通知する（Ｓ１６０５）。一例では、管理サーバ１０は、運用事業者への供託物の払い渡しを発行体装置１１に通知してもよい。

以上説明したように、本実施形態に係る電子通貨管理システムは、運用事業者から発行すべき電子通貨に関する電子通貨情報を取得し、電子通貨情報の発行の要求を運用事業者から受け付け、受け付けた要求に対する承認を発行体から受け付けた場合に電子通貨を発行する。これによって、発行権限を有しない運用事業者であっても、電子通貨の発行を発行体に依頼することで電子通貨を発行することができる。また、運用事業者と発行体との両方にとって、電子通貨の発行を行うシステムの構築に必要な費用および時間を大きく節約することができ、電子通貨を発行するための利便性を向上することができる。電子通貨管理サーバ１０が運用事業者に対し金融ライセンス無しで電子通貨を発行することで、独自の経済圏構築や拡大の一助となることができる。

また、電子通貨管理システムは、運用事業者から発行体に預けられた供託物に関する情報を取得する。これによって、発行体の承認と、経済的な担保を確認した後に電子通貨を発行することができるため、安全に電子通貨を発行することができる。

また、電子通貨管理システムは、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）のＰＯＳＴメソッド、ＧＥＴメソッド、およびＰＵＴメソッドの少なくともいずれかを使用して、電子通貨の発行要求や要求に対する承認を送受信する。これによって、ｗｅｂブラウザを介して電子通貨管理システムの利用が可能となり、電子通貨管理システムの利便性が向上する。

また、電子通貨管理システムは、運用事業者によって電子通貨の移転可能な期間を設定することができる。これによって、運用事業者はイベントなどの所定期間に応じて電子通貨を発行し、利用を停止することができ、電子通貨の利便性が向上する。

また、電子通貨管理システムは、ユーザに対して電子通貨を管理するためのウォレットを提供する。また、ウォレットは、複数種類の電子通貨の残高を管理することができる。これによって、ユーザが有する複数種類の電子通貨の残高をユーザがまとめて把握または管理することができ、ユーザにとっての利便性が向上する。

また、電子通貨管理システムは、電子通貨を、現金通貨の種類と、その種類の現金通貨とのレートとが関連付けられた電子通貨情報を管理する。これによって、電子通貨の現金通貨での価値を保証することができる。また、電子通貨を償却する際に、現金通貨への変換が容易となり、現金通貨を管理する利便性を向上することができる。

＜その他の実施形態＞
発明は上記の実施形態に制限されるものではなく、発明の要旨の範囲内で、種々の変形・変更が可能である。

本実施形態では、管理サーバが１種類の電子通貨の発行、移転、償却を行う例について説明を行った。しかしながら、上述したように、管理サーバ１０は複数種類の電子通貨を発行、移転、償却を行ってもよい。また、管理サーバ１０は、複数種類の電子通貨について、それぞれの電子通貨情報のペッグペア１００３、レート１００４を用いて、複数種類の電子通貨の交換レートを決定することで、電子通貨と現金通貨との交換だけではなく、複数種類の電子通貨間の交換を行ってもよい。例えば、電子通貨Ａが単位量当たり日本円で１円であり、電子通貨Ｂが単位量あたり米国ドルで１ドルである場合、管理サーバ１０は、日本円と米国ドルとの為替レートを取得することで、電子通貨Ａと電子通貨Ｂとの交換レートを判断することができる。これによって、複数種類の電子通貨の相互運用性を実現することができ、複数種類の電子通貨の経済圏を共有することが可能となる。

また、上述の各実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読み出し実行する処理でも実現可能である。

１：電子通貨管理システム、１０：管理サーバ、１１：発行体装置、１２：運用事業者装置、１３：利用者装置

Claims (11)

1. 情報処理装置であって、
   外部装置への接続を提供するための通信部と、
   プロセッサと、
   を含み、前記プロセッサは、
   前記通信部を介して、電子通貨の発行を希望する運用事業者に対応する第１の外部装置から、前記運用事業者が発行を希望する電子通貨の名称を含む電子通貨情報を取得し、
   前記通信部を介して、取得した前記電子通貨情報に対応する前記電子通貨の発行の要求を前記第１の外部装置から受け付け、
   前記要求を受け付けた場合に、電子通貨の発行免許を有する発行体に対応する第２の外部装置に前記要求に対する承認を要求し、
   受け付けた前記要求に対する承認を前記第２の外部装置から受け付け、
   前記承認を受け付けた場合に、前記電子通貨を発行する、
   ことを特徴とする情報処理装置。
2. 前記電子通貨情報は、前記第１の外部装置から提供された現金通貨に対応付けられた前記電子通貨の価値を示す情報を含むことを特徴とする請求項１に記載の情報処理装置。
3. 前記プロセッサは、
   前記通信部を介して発行すべき前記電子通貨の数量の指定を前記第１の外部装置から受け付け、
   受け付けた前記数量の前記電子通貨を発行することを特徴とする請求項１または２に記載の情報処理装置。
4. 前記プロセッサは、
   前記第２の外部装置が前記電子通貨を発行するために前記第１の外部装置から受領した供託物に関する供託情報を前記第２の外部装置から取得し、
   前記承認を受け付けた場合に、取得した前記供託情報に基づいて前記数量の前記電子通貨を発行するか否かを判断することを特徴とする請求項３に記載の情報処理装置。
5. 前記プロセッサは、前記通信部を介して電子通貨の利用を希望する利用者に対応する外部装置から電子通貨の移転の要求を受け付けることを特徴とする請求項１から４のいずれか１項に記載の情報処理装置。
6. 前記プロセッサは、前記要求をＨｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ（ＨＴＴＰＳ）のＰＯＳＴメソッド、ＧＥＴメソッド、およびＰＵＴメソッドの少なくともいずれかによって受け付けることを特徴とする請求項１から５のいずれか１項に記載の情報処理装置。
7. 前記プロセッサは、前記承認をＨｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ（ＨＴＴＰＳ）のＰＯＳＴメソッド、ＧＥＴメソッド、およびＰＵＴメソッドの少なくともいずれかによって受け付けることを特徴とする請求項１から６のいずれか１項に記載の情報処理装置。
8. 前記電子通貨情報は、前記電子通貨の移転可能な期間を示す情報をさらに含むことを特徴とする請求項１から７のいずれか１項に記載の情報処理装置。
9. 前記プロセッサは、発行した前記電子通貨を償却することを特徴とする請求項１から８のいずれか１項に記載の情報処理装置。
10. 通信部を備える情報処理装置のプロセッサによって実行される情報処理方法であって、
    前記通信部を介して、電子通貨の発行を希望する運用事業者に対応する第１の外部装置から、前記運用事業者が発行を希望する電子通貨の名称を含む電子通貨情報を取得することと、
    前記通信部を介して、取得した前記電子通貨情報に対応する前記電子通貨の発行の要求を前記第１の外部装置から受け付けることと、
    前記要求を受け付けた場合に、電子通貨の発行免許を有する発行体に対応する第２の外部装置に前記要求に対する承認を要求することと、
    前記プロセッサが、受け付けた前記要求に対する承認を前記第２の外部装置から受け付けることと、
    前記プロセッサが、前記承認を受け付けた場合に、前記電子通貨を発行することと、
    を有することを特徴とする情報処理方法。
11. 請求項１から９のいずれか１項に記載の情報処理装置の各手段としてコンピュータを機能させるためのプログラム。

Images