JP7402187B2 - 制御方法、サーバ、および、プログラム - Google Patents

制御方法、サーバ、および、プログラム Download PDF

Info

Publication number
JP7402187B2
JP7402187B2 JP2020571245A JP2020571245A JP7402187B2 JP 7402187 B2 JP7402187 B2 JP 7402187B2 JP 2020571245 A JP2020571245 A JP 2020571245A JP 2020571245 A JP2020571245 A JP 2020571245A JP 7402187 B2 JP7402187 B2 JP 7402187B2
Authority
JP
Japan
Prior art keywords
fee
transaction
transaction data
terminal
distributed ledger
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2020571245A
Other languages
English (en)
Other versions
JPWO2020162515A1 (ja
Inventor
勇二 海上
淳児 道山
雄揮 廣瀬
哲司 渕上
基司 大森
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Publication of JPWO2020162515A1 publication Critical patent/JPWO2020162515A1/ja
Application granted granted Critical
Publication of JP7402187B2 publication Critical patent/JP7402187B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Databases & Information Systems (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

本発明は、制御方法、サーバ、および、プログラムに関する。
特許文献１には、仮想通貨において、仮想通貨を投資対象とさせずにユーザに仮想通貨の消費を促すために、仮想通貨の購入時からの時間の経過とともに、購入した仮想通貨が減価する仕組みについて開示されている。
特開２０１６－１７０５３０号公報
しかしながら、仮想通貨などのトークンの取引を管理する複数のサーバの処理が不安定になるおそれがある。
そこで、本開示は、トークンの取引を管理する各サーバの処理を安定化することができる制御方法などを提供する。
本発明の一態様に係る制御方法は、複数の分散台帳を利用してトークンの取り引きを管理する複数のサーバであって、それぞれが前記複数の分散台帳のうちの１以上の分散台帳を管理する複数のサーバのうちの一のサーバによって実行される制御方法であって、第１ユーザにより操作された端末から、前記第１ユーザが取り引きを行う予定の日時を含む申し込み情報を受信し、前記一のサーバが管理する第１分散台帳を参照し、受信した前記申し込み情報に含まれる前記予定の日時以前に前記第１分散台帳に記録されている前記第１ユーザによる取り引きに基づいて手数料を算出し、算出した前記手数料を含む手数料情報を前記端末に送信し、前記端末から前記予定に対応する取り引きにかかるトークンの量を示す第１トークン量を含む第１トランザクションデータを受信し、受信した前記第１トランザクションデータを前記複数のサーバのうちの前記一のサーバとは異なる複数の他のサーバに転送し、かつ、前記第１トランザクションデータを含む第１ブロックを前記第１分散台帳に格納し、前記端末から前記手数料にかかるトークンの量を示す第２トークン量を含む第２トランザクションデータを受信し、受信した前記第２トランザクションデータを前記複数の他のサーバに転送し、かつ、前記第２トランザクションデータを含む第２ブロックを前記第１分散台帳に格納する。
なお、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
本開示の制御方法は、トークンの取引を管理する各サーバの処理を安定化することができる。
図１は、本実施の形態における取引管理システムの構成を模式的に示すブロック図である。 図２は、本実施の形態におけるサーバの構成を模式的に示すブロック図である。 図３は、本実施の形態における手数料算出情報の一例を示す説明図である。 図４は、本実施の形態における申込トランザクションデータを模式的に示す説明図である。 図５は、本実施の形態における支払トランザクションデータを模式的に示す説明図である。 図６は、本実施の形態における手数料トランザクションデータを模式的に示す説明図である。 図７は、本実施の形態における取引管理システムの処理の一例を示すフロー図である。 図８は、端末の表示部が表示するＵＩの一例を示す図である。 図９は、端末の表示部が表示するＵＩを示す図である。 図１０は、端末の表示部が表示するＵＩの一例を示す図である。 図１１は、端末の表示部が表示するＵＩの一例を示す図である。 図１２は、変形例３における取引管理システムの構成を模式的に示すブロック図である。 図１３は、変形例３における取引管理システムの構成を模式的に示すブロック図である。 図１４は、変形例４におけるサーバの処理を示すフロー図である。 図１５は、実施の形態の変形例４におけるサーバの構成を模式的に示すブロック図である。 図１６は、ブロックチェーンのデータ構造を示す説明図である。 図１７は、トランザクションデータのデータ構造を示す説明図である。
（本発明の基礎となった知見）
本発明者は、「背景技術」の欄において記載した、トークンの取り引きに関する技術に関し、以下の問題が生じることを見出した。
特許文献１に記載の仕組みでは、時間の経過に応じた仮想通貨などのトークンの減価量が予め定められているため、取り引きの状況に応じて取り引きの制御が難しい。例えば、ある期間に多くの取り引きが集中した場合、トークンを管理している複数のサーバの処理負荷が増加して複数のサーバによる処理が不安定になるおそれがある。また、例えば、他の期間では取り引きが生じずに取り引きに関する処理が複数のサーバで行われないおそれがあり、この場合、複数のサーバは、取り引きが発生するのを待機することとなるため、取り引きに関する処理が行われていないのにもかかわらず電力を消費するおそれがある。
そこで、本開示は、トークンの取り引きを管理する複数のサーバの処理が特定の期間に偏らないように取り引きが発生するタイミングを制御することで、複数のサーバの処理の安定化を図り、かつ、取り引きに関する処理が行われずに電力が消費されることを低減することができる制御方法などを提供する。
このような問題を解決するために、本発明の一態様に係る制御方法は、複数の分散台帳を利用してトークンの取り引きを管理する複数のサーバであって、それぞれが前記複数の分散台帳のうちの１以上の分散台帳を管理する複数のサーバのうちの一のサーバによって実行される制御方法であって、第１ユーザにより操作された端末から、前記第１ユーザが取り引きを行う予定の日時を含む申し込み情報を受信し、前記一のサーバが管理する第１分散台帳を参照し、受信した前記申し込み情報に含まれる前記予定の日時以前に前記第１分散台帳に記録されている前記第１ユーザによる取り引きに基づいて手数料を算出し、算出した前記手数料を含む手数料情報を前記端末に送信し、前記端末から前記予定に対応する取り引きにかかるトークンの量を示す第１トークン量を含む第１トランザクションデータを受信し、受信した前記第１トランザクションデータを前記複数のサーバのうちの前記一のサーバとは異なる複数の他のサーバに転送し、かつ、前記第１トランザクションデータを含む第１ブロックを前記第１分散台帳に格納し、前記端末から前記手数料にかかるトークンの量を示す第２トークン量を含む第２トランザクションデータを受信し、受信した前記第２トランザクションデータを前記複数の他のサーバに転送し、かつ、前記第２トランザクションデータを含む第２ブロックを前記第１分散台帳に格納する。
これによれば、トークンの取り引きを管理する複数のサーバの処理が特定の期間に偏らないように取り引きが発生するタイミングを制御することができる。このため、複数のサーバの処理の安定化を図り、かつ、取り引きに関する処理が行われずに電力が消費されることを低減することができる。
例えば、前記申し込み情報は、前記予定の日時を含む第３トランザクションデータであり、前記複数の分散台帳のそれぞれは、前記第３トランザクションデータに基づいて前記手数料を算出するためのコントラクトコードを含み、前記手数料の算出では、前記第３トランザクションデータを受信すると、前記第１分散台帳に含まれる前記コントラクトコードを実行することで前記手数料を算出してもよい。
これによれば、手数料の算出を、他の人または他のシステムを介在することなく、早期かつ安全に実行することができる。よって、本開示に係る制御方法は、トークンの取り引きを管理する複数のサーバの消費電力を削減することができる。
例えば、前記第１ブロックの前記第１分散台帳への格納では、前記複数の他のサーバと共にコンセンサスアルゴリズムを実行し、前記第１ブロックを前記第１分散台帳に格納し、前記第２ブロックの前記第１分散台帳への格納では、前記複数の他のサーバと共にコンセンサスアルゴリズムを実行し、前記第２ブロックを前記第１分散台帳に格納してもよい。
これによれば、コンセンサスアルゴリズムの実行を経て分散台帳を格納する。よって、本開示に係る制御方法は、コンセンサスアルゴリズムの実行を経ることによって、より容易に、トークンの取り引きを適切に管理することができる。
例えば、前記手数料の算出では、前記第１分散台帳における前記第１ユーザの前記トークンの残高が多いほど高い額の手数料を算出してもよい。
このため、第１ユーザにトークンを早く使用するように促すことができる。よって、取り引きが発生するタイミングを制御することができる。
例えば、前記手数料の算出では、前記第１分散台帳における前記第１ユーザによる前回の取り引きタイミングからの経過時間が長いほど高い額の手数料を算出してもよい。
このため、第１ユーザにトークンを早く使用するように促すことができる。よって、取り引きが発生するタイミングを制御することができる。
例えば、前記手数料の算出では、前記第１分散台帳における前記第１ユーザによる取り引きにおいて、現時点から所定時間前までの期間における取引量の単位時間当たりの平均が小さいほど高い額の手数料を算出してもよい。
このため、第１ユーザにトークンを早く使用するように促すことができる。よって、取り引きが発生するタイミングを制御することができる。
例えば、前記手数料情報は、前記端末の表示部に前記手数料を表示させるための情報であってもよい。
このため、手数料を端末の表示部に表示させることで、第１ユーザにトークンを早く使用するように促すことができる。よって、取り引きが発生するタイミングを制御することができる。
例えば、前記トークンは、複数種類のトークンを含み、前記第１分散台帳は、異なる種類のトークン毎に異なる複数のサブ分散台帳を含み、前記手数料の算出では、前記申し込み情報に含まれる前記予定の日時以前に前記複数のサブ分散台帳に記録されている前記第１ユーザによる取り引きに基づいて、異なる種類のトークン毎に手数料を複数算出し、前記手数料の送信では、前記手数料情報として、算出した前記複数の手数料を含む情報を前記端末に送信してもよい。
これによれば、複数種類のトークン毎に手数料を算出するため、トークンの種類毎に取引量の調整を行うことができる。
例えば、前記手数料情報は、前記端末の表示部に、異なる種類のトークン毎に前記手数料を表示させるための情報であってもよい。
このため、トークンの種類毎に手数料を端末の表示部に表示させることで、第１ユーザに種類毎にトークンを早く使用するように促すことができる。よって、トークンの種類毎に取り引きが発生するタイミングを制御することができる。
例えば、前記手数料情報は、前記第１ユーザに前記手数料情報に含まれる前記手数料に同意するか否かを問い合わせる問い合わせ情報を含んでもよい。
これによれば、端末を介して、手数料に同意するか否かを第１ユーザに問い合わせることができるため、第１ユーザがトークンを使用するタイミングを調整することができる。例えば、手数料の額を大きくするほどトークンを使用するタイミングを早めることができる。よって、取り引きが発生するタイミングを制御することができる。
また、本発明の一態様にかかるサーバは、複数の分散台帳を利用してトークンの取り引きを管理する複数のサーバであって、それぞれが前記複数の分散台帳のうちの１以上の分散台帳を管理する複数のサーバのうちの一のサーバであって、前記複数の分散台帳のうちの第１分散台帳を管理する管理部と、第１ユーザにより操作された端末から、前記第１ユーザにより取り引きを行う予定の日時を含む申し込み情報と、前記端末から前記予定に対応する取り引きにかかるトークンの量を示す第１トークン量を含む第１トランザクションデータと、前記端末から手数料にかかるトークンの量を示す第２トークン量を含む第２トランザクションデータとを受信する受信部と、前記管理部における前記第１分散台帳を参照し、受信された前記申し込み情報に含まれる前記予定の日時以前に前記第１分散台帳に記録されている前記第１ユーザによる取り引きに基づいて前記手数料を算出する算出部と、前記端末に算出した前記手数料を含む手数料情報を送信する送信部と、を備え、（ｉ）前記受信部が前記第１トランザクションデータを受信すると、前記送信部は、受信された前記第１トランザクションデータを前記複数のサーバのうちの前記一のサーバとは異なる複数の他のサーバに転送し、かつ、前記管理部は、前記第１トランザクションデータを含む第１ブロックを前記第１分散台帳に記録し、（ｉｉ）前記受信部が前記第２トランザクションデータを受信すると、前記送信部は、受信された前記第２トランザクションデータを前記複数の他のサーバに転送し、かつ、前記管理部は、前記第２トランザクションデータを含む第２ブロックを前記第１分散台帳に記録する。
これによれば、トークンの取り引きを管理する複数のサーバの処理が特定の期間に偏らないように取り引きが発生するタイミングを制御することができる。このため、複数のサーバの処理の安定化を図り、かつ、取り引きに関する処理が行われずに電力が消費されることを低減することができる。
また、本発明の一態様に係るプログラムは、上記の制御方法をコンピュータに実行させるためのプログラムである。
上記態様により、上記制御方法と同様の効果を奏する。
なお、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
以下、実施の形態について、図面を参照しながら具体的に説明する。
なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
（実施の形態）
本実施の形態において、トークンの取引管理システムの複数のサーバの処理の安定化、および、無駄な電力消費の低減を図ることができる取引管理システムおよびその制御方法などについて説明する。
図１は、本実施の形態における取引管理システム１の構成を模式的に示すブロック図である。
図１に示されるように、取引管理システム１は、サーバ１０Ａ、１０Ｂ及び１０Ｃと、端末４０、４１および４２とを備える。取引管理システム１が備える各装置は、ネットワークＮによって互いに通信可能に接続されている。ネットワークＮは、どのような通信回線又はネットワークから構成されてもよく、例えば、インターネット、携帯電話のキャリアネットワークなどを含む。サーバ１０Ａ、１０Ｂ及び１０Ｃを「サーバ１０Ａ等」ともいう。
複数のサーバ１０Ａ、１０Ｂ及び１０Ｃは、複数の分散台帳を利用してトークンの取引を管理する。サーバ１０Ａは、複数のサーバ１０Ａ、１０Ｂ及び１０Ｃのうちの１つである。サーバ１０Ａは、分散台帳を保有している複数のサーバ１０Ａ、１０Ｂ及び１０Ｃのうちの１つである。サーバ１０Ａが保有している分散台帳には、取り引き通貨の取り引きにおける手続または処理（申込、支払い、手数料の支払いなど）に関する各種トランザクションデータが格納される。サーバ１０Ａは、上記トランザクションデータを受信することで、トークンの取り引きにおける手続または処理を受け付ける。なお、トークンは、例えば、トークンである。トークンは、分散台帳により管理されている価値情報であり、金銭、ポイント（ロイヤリティ）、商品券またはクーポン等に相当し、又は、交換可能である。
サーバ１０Ｂ及び１０Ｃは、それぞれ、サーバ１０Ａと同じ機能を有する装置であり、サーバ１０Ａとは独立に動作する。なお、サーバの台数は、３に限られず、複数であればよい。また、サーバ１０Ａ等同士は、通信可能に接続されており、ネットワークＮを介して接続されていてもよい。
ここでは例として、サーバ１０Ａ等のうち、サーバ１０Ａが端末４０等からトランザクションデータを受信したり、端末４０等に通知を送信したりする場合を説明するが、他のサーバ（サーバ１０Ｂまたは１０Ｃ）が上記の処理を行ってもよい。
端末４０は、支払者Ｕ１が保有する端末装置である。端末４０は、サーバ１０Ａ等に対してトークンの取り引きの申し込み、トークンの取り引き、および、手数料の支払いを行うための端末である。端末４０は、例えば、トークンの取り引きの予定日時を示す入力、および、取り引き予定額を示す入力を支払者Ｕ１から受け付ける。端末４０は、受け付けた入力に基づいて、取り引きの申込のためのトランザクションデータ（申込トランザクションデータ、第３トランザクションデータともいう）を生成し、生成した申込トランザクションデータをサーバ１０Ａ等に送信する。端末４０は、具体的には、取り引き予定日時、および、取り引き予定額を含むトランザクションデータを、申込トランザクションデータとして生成する。なお、申込トランザクションデータは、取り引き予定を示す情報を含んでいればよく、取り引き予定日時および取り引き予定額を含んでいなくてもよい。
また、端末４０は、サーバ１０Ａ等から受信した手数料情報を受信し、受信した手数料情報を表示してもよい。つまり、手数料情報は、端末４０の表示部６０（図８参照）に手数料を表示させるための情報である。また、端末４０は、受信した手数料情報に基づいて手数料を取り引きの手続きを管理する業者Ｘに支払うためのトランザクションデータ（手数料トランザクションデータ、第２トランザクションデータともいう）を生成し、生成したトランザクションデータをサーバ１０Ａ等に送信する。端末４０は、具体的には、手数料情報に含まれる手数料の額を含むトランザクションデータを、手数料トランザクションデータとして生成する。
また、端末４０は、申し込みのための入力に基づいて支払い取り引きのためのトランザクションデータ（支払トランザクションデータ、第１トランザクションデータともいう）を生成し、生成した支払トランザクションデータをサーバ１０Ａ等に送信する。端末４０は、具体的には、取り引き予定日時と同じ取り引き日時、および、取り引き予定額と同じ額の取り引き額を含むトランザクションデータを、支払トランザクションデータとして生成する。手数料情報は、端末４０のユーザである支払者Ｕ１に手数料情報に含まれる手数料に同意するか否かを問い合わせる問い合わせ情報を含んでいてもよい。つまり、端末４０は、手数料情報に含まれる手数料の額に同意するか否かを支払者Ｕ１に問い合わせるＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を提示してもよい。端末４０は、提示したＵＩに対して同意を示す入力を受け付けたか否かを判定し、同意を示す入力を受け付けた場合に、手数料トランザクションデータを生成し、同意を示す入力を受け付けなかった場合に、手数料トランザクションデータを生成しなくてもよい。
端末４０は、例えばパーソナルコンピュータ、スマートフォン、タブレットなどである。
端末４１は、支払者Ｕ１による取り引きによる支払いが行われる先である支払先Ｕ２のユーザが保有する端末装置である。端末４１は、取り引きによる支払いが行われたことを示す通知をサーバ１０Ａ等から受信する。端末４１は、通知を受信すると、支払トランザクションデータに含まれる支払額の支払いが支払者Ｕ１によって取り引き日時に行われたことを示す情報を表示してもよい。
端末４１は、例えばパーソナルコンピュータ、スマートフォン、タブレットなどである。
端末４２は、業者Ｘが保有する端末装置である。端末４２は、支払者Ｕ１による手数料の支払いが行われたことを示す通知をサーバ１０Ａ等から受信する。端末４２は、通知を受信すると、手数料トランザクションデータに含まれる手数料の額の支払いが支払者Ｕ１によって取り引き日時に行われたことを示す情報を表示してもよい。
端末４２は、例えばパーソナルコンピュータ、スマートフォン、タブレットなどである。
端末４０は、さらに、端末４１の機能を有していてもよいし、端末４２の機能を有していてもよい。同様に、端末４１は、端末４０の機能を有していてもよいし、端末４２の機能を有していてもよい。同様に、端末４２は、端末４０の機能を有していてもよいし、端末４１の機能を有していてもよい。各端末４０～４２は、他の端末とは独立に動作する。
以降において、取引管理システム１が備えるサーバ１０Ａ等の構成について詳細に説明する。
図２は、本実施の形態におけるサーバ１０Ａの構成を模式的に示すブロック図である。
図２に示されるように、サーバ１０Ａは、処理部１１と、台帳管理部１２と、制御部１３とを備える。サーバ１０Ａが備える上記機能部は、例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）がメモリを用いてプログラムを実行することで実現され得る。
処理部１１は、分散台帳によって各種情報の管理を行う処理部である。処理部１１は、取引管理システム１内の装置からトランザクションデータを受信した場合、又は、制御部１３が生成したトランザクションデータを取得した場合に、受信又は取得したトランザクションデータを台帳管理部１２に提供することで分散台帳に格納する。トランザクションデータには、申込トランザクションデータ、支払トランザクションデータおよび手数料トランザクションデータが含まれる。各トランザクションデータの詳細は後述する。
台帳管理部１２は、分散台帳を管理している処理部である。具体的には、台帳管理部１２は、トランザクションデータを受信した場合、受信したトランザクションデータを他の複数のサーバに転送し、かつ、受信したトランザクションデータを分散台帳に格納する。例えば、台帳管理部１２は、端末４０から支払トランザクションデータを受信し、受信した支払トランザクションデータを複数のサーバ１０Ａ、１０Ｂ及び１０Ｃのうちのサーバ１０Ａとは異なる複数の他のサーバ１０Ｂ及び１０Ｃに転送し、かつ、支払トランザクションデータを含む第１ブロックを台帳記憶部１６に記憶されている分散台帳に格納する。また、台帳管理部１２は、端末４０から手数料トランザクションデータを受信し、受信した手数料トランザクションデータを複数の他のサーバ１０Ｂ及び１０Ｃに転送し、かつ、第２トランザクションデータを含む第２ブロックを台帳記憶部１６に記憶されている分散台帳に格納する。
このように、台帳管理部１２は、処理部１１から提供されたトランザクションデータを分散台帳に格納する。分散台帳には、過去から現在までのトランザクションデータが格納される。分散台帳では、分散台帳に記録された情報の改ざんが困難であるという特性に基づいて、上記トランザクションデータが改ざんされないように管理されている。
台帳管理部１２は、格納部１５と、台帳記憶部１６とを有する。
格納部１５は、分散台帳に格納すべき新しいトランザクションデータを台帳記憶部１６に格納する処理部である。格納部１５は、分散台帳の種別に応じた方式で新しいトランザクションデータを台帳記憶部１６に格納する。また、格納部１５は、サーバ１０Ａ等のうちの他のサーバの格納部１５との間で通信データを送受信し、他のサーバの台帳記憶部１６にも上記新しいトランザクションデータを格納させる。例えば、格納部１５は、分散台帳がブロックチェーンである場合には、新しいトランザクションデータを含むブロックを生成し、生成したブロックをサーバ１０Ａ等の間で同期をとった上で、上記ブロックを台帳記憶部１６に格納する。格納部１５は、例えば、第１ブロックの分散台帳への格納では、複数の他のサーバ１０Ｂ及び１０Ｃと共にコンセンサスアルゴリズムを実行し、第１ブロックを分散台帳に格納する。また、格納部１５は、例えば、第２ブロックの分散台帳への格納では、複数の他のサーバ１０Ｂ及び１０Ｃと共にコンセンサスアルゴリズムを実行し、第２ブロックを分散台帳に格納する。
台帳記憶部１６は、分散台帳を記憶している記憶装置である。台帳記憶部１６に格納されている分散台帳は、１以上のトランザクションデータを記憶しており、ハッシュ値などの特性を用いて改ざんが困難であるように管理されている。この詳細は、後述する。
また、台帳記憶部１６に格納されている分散台帳には、支払者による支払いの手続きを行うための手数料を算出に用いられる手数料算出情報が予め格納されている。また、分散台帳には、申込トランザクションデータに基づいて手数料を算出するためのスマートコントラクトのコードが含まれている。手数料の算出については、後述する。
なお、分散台帳は、例えばブロックチェーンであり、この場合を例として説明するが、他の方式の分散台帳（例えば、ＩＯＴＡ又はハッシュグラフ等）を採用することも可能である。なお、分散台帳は、新しいデータの格納の際にコンセンサスアルゴリズム（例えば、ＰＢＦＴ（Ｐｒａｃｔｉｃａｌ Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｌｅｒａｎｃｅ）、ＰｏＷ（Ｐｒｏｏｆ ｏｆ Ｗｏｒｋ）又はＰｏＳ（Ｐｒｏｏｆ ｏｆ Ｓｔａｋｅ））を実行するものであってもよいし、実行しないものであってもよい。コンセンサスアルゴリズムを実行しない分散台帳技術の一例としてＨｙｐｅｒｌｅｄｇｅｒ ｆａｂｒｉｃがある。
制御部１３は、トークンの提供に係る処理を制御する処理部である。制御部１３は、申込トランザクションデータを端末４０から受信することにより、支払者がトークンの取り引きを行う予定の日時を含む情報を端末４０から受信する。また、制御部１３は、台帳記憶部１６に格納されている分散台帳を参照し、申込トランザクションデータに含まれる取り引き予定の日時以前に分散台帳に記録されている支払者Ｕ１による取り引きに基づいて、支払者Ｕ１の取り引き予定の取り引きにかかる手数料の額を算出する。制御部１３は、算出した手数料の額を含む手数料情報を端末４０に送信する。
制御部１３は、例えば、取り引き予定日時における、分散台帳における支払者のトークンの残高が多いほど高い額の手数料を算出する。また、制御部１３は、例えば、分散台帳における支払者による前回の取り引きタイミングからの経過時間が長いほど高い額の手数料を算出する。経過時間は、例えば、前回の取り引きタイミングから申込トランザクションデータを受信したタイミングまでの時間である。また、制御部１３は、例えば、分散台帳における支払者による取り引きにおいて、申込トランザクションデータを受信したタイミングから所定時間前までの期間における取引量の単位時間当たりの平均が小さいほど高い額の手数料を算出する。なお、期間における取引量とは、例えば、支払者の当該期間における支払額の合計である。支払いとは送金、出金、振り込みなどであってもよい。
なお、制御部１３の上記の処理の一部または全部は、台帳記憶部１６に記憶されたコントラクトコードを実行することで実現されるスマートコントラクトによりなされる。制御部１３は、申込トランザクションデータを端末４０から受信すると、分散台帳に含まれるコントラクトコードを実行することで手数料を算出する。コントラクトコードは、スマートコントラクトを実現するために実行されるコードである。
以降において、支払者に請求される、支払者による取り引きにかかる手数料について説明する。
支払者に請求される手数料は、手数料算出情報に基づいて、支払者による取り引きの申し込みのタイミングに基づいて決定される。具体的には、手数料は、（ｉ）申し込みのタイミングにおける、分散台帳における支払者のトークンの残高、（ｉｉ）分散台帳における支払者による前回の取り引きタイミングからの経過時間、および、（ｉｉｉ）分散台帳における支払者による取り引きにおいて、申込トランザクションデータを受信したタイミングから所定時間前までの期間における取引量の単位時間当たりの平均の少なくとも１つに基づいて決定される。手数料算出情報は、例えば、手数料を規定する関数またはテーブルである。
図３は、本実施の形態における手数料算出情報の一例を示す説明図である。図３に示される手数料算出情報は、手数料額を関数によって規定する手数料算出情報の例である。
図３において、横軸は、支払者のトークンの残高ｘを示しており、縦軸は、各残高ｘにおける手数料額Ｆ（ｘ）を示している。
関数Ｆ（ｘ）は、原則として、ｘの増加に対して増加する傾向を有する。言い換えれば、手数料額は、残高が多くなるにつれて増加する傾向を有する。より具体的には、関数Ｆ（ｘ）は、ｘに対して単調増加の関数である。ただし、関数Ｆ（ｘ）は、ｘの変化に対して値を維持する区間を含んでもよい。
制御部１３は、図３に示される手数料算出情報である関数Ｆ（ｘ）を用いて以下のように手数料額を算出することで決定する。
以降において、処理部１１が分散台帳に格納する各種トランザクションデータである、（１）申込トランザクションデータ、（２）支払トランザクションデータ、および（３）手数料トランザクションデータについて説明する。
（１）申込トランザクションデータ
図４は、本実施の形態における申込トランザクションデータを模式的に示す説明図である。申込トランザクションデータは、支払者Ｕ１が取り引きを行う際に、支払者Ｕ１が保有する端末４０によって生成され、サーバ１０Ａ等に送信される。
図４に示されるように、申込トランザクションデータは、支払者ＩＤと、支払先ＩＤと、支払い予定日時と、支払い予定額と、指示と、署名とを含む。
支払者ＩＤは、取り引き（支払い）予定における支払者を一意に特定するための識別子である。
支払先ＩＤは、取り引き（支払い）予定における支払先を一意に特定するための識別子である。
支払い予定日時は、取り引き（支払い）が行われる予定のタイミングを示す情報である。支払い予定日時は、取り引きが行われる予定の日時が示されているが、取り引きが行われる予定の時刻が示されていなくてもよく、日時のうちの日のみが示されていてもよい。
支払い予定額は、取り引きで支払われる予定の額を示す情報である。額は、例えば、トークンの量である。
指示は、取り引きにかかる手数料の算出処理をサーバ１０Ａに行わせることを指示するための情報である。なお、申込トランザクションデータは、指示の代わりに、当該トランザクションデータが、取り引きが行われる予定を示す情報が含まれる申込トランザクションデータであることを示す情報を含んでいてもよい。この場合、サーバ１０Ａ等は、申込トランザクションデータを受信した場合、申込トランザクションデータであることを示す情報が受信したトランザクションデータに含まれていることを検出すると、手数料の算出を行ってもよい。
署名は、当該申込トランザクションデータを生成した装置又は人が付した電子署名である。
図４に示される申込トランザクションデータは、支払者ＩＤが「ａａａ００１」である支払者が、支払先ＩＤが「ｂｂｂ０１」である支払先に支払う予定を示す申込トランザクションデータである。この取り引きの予定において、支払い予定額は「５」トークンであり、支払い予定日時は「２０１８．１０．１０ １５：００」である。署名は、支払者の電子署名である。
（２）支払トランザクションデータ
図５は、本実施の形態における支払トランザクションデータを模式的に示す説明図である。支払トランザクションデータは、支払者Ｕ１が取り引きを行う際に、支払者Ｕ１が保有する端末４０によって生成され、サーバ１０Ａ等に送信される。
図５に示されるように、支払トランザクションデータは、支払者ＩＤと、支払先ＩＤと、支払い日時と、支払い額と、署名とを含む。
支払者ＩＤは、取り引き（支払い）における支払者を一意に特定するための識別子である。
支払先ＩＤは、取り引き（支払い）における支払先を一意に特定するための識別子である。
支払い日時は、取り引き（支払い）が行われるタイミングを示す情報である。支払い日時は、取り引きが行われる日時が示されているが、取り引きが行われる時刻が示されていなくてもよく、日時のうちの日のみが示されていてもよい。
支払い額は、取り引きで支払われる額を示す情報である。額は、例えば、トークンの量である。
署名は、当該支払トランザクションデータを生成した装置又は人が付した電子署名である。
図５に示される支払トランザクションデータは、支払者ＩＤが「ａａａ００１」である支払者が、支払先ＩＤが「ｂｂｂ０１」である支払先に支払う取り引きの支払トランザクションデータである。この取り引きにおいて、支払い額は「５」トークンであり、支払い日時は「２０１８．１０．１０ １５：００」である。署名は、支払者の電子署名である。
（３）手数料トランザクションデータ
図６は、本実施の形態における手数料トランザクションデータを模式的に示す説明図である。手数料トランザクションデータは、支払者Ｕ１が取り引き行う際に、支払者Ｕ１が保有する端末４０によって生成され、サーバ１０Ａ等に送信される。
図６に示されるように、手数料トランザクションデータは、支払者ＩＤと、支払先ＩＤと、支払い日時と、手数料額と、署名とを含む。
支払者ＩＤは、取り引きにかかる手数料の支払いにおける支払者を一意に特定するための識別子である。
支払先ＩＤは、取り引きにかかる手数料の支払先を一意に特定するための識別子である。
支払い日時は、取り引きにかかる手数料の支払いが行われるタイミングを示す情報である。支払い日時は、手数料の支払いが行われる日時が示されているが、手数料の支払いが行われる時刻が示されていなくてもよく、日時のうちの日のみが示されていてもよい。
手数料額は、取り引きにかかる手数料の額を示す情報である。額は、例えば、トークンの量である。
署名は、当該申込トランザクションデータを生成した装置又は人が付した電子署名である。
図６に示される申込トランザクションデータは、支払者ＩＤが「ａａａ００１」である支払者が、支払先ＩＤが「ｆｌｊａｄ４０１９」である支払先に手数料を支払うこと示す手数料トランザクションデータである。この手数料の支払いにおいて、支払い額は「１」トークンであり、支払い予定日時は「２０１８．１０．１０ １５：００」である。署名は、支払者の電子署名である。
以降において、取引管理システム１の処理について、具体例を説明する。
図７は、本実施の形態における取引管理システム１の処理の一例を示すフロー図である。
支払者Ｕ１の端末４０は、支払者Ｕ１から取り引き予定の日時を示す入力、および、取り引き予定の額を示す入力を受け付けて（Ｓ１０１）。
端末４０は、受け付けた入力に基づいて、取り引き予定の日時、および、取り引き予定の額を含む申込トランザクションデータを生成する（Ｓ１０２）。
端末４０は、生成した申込トランザクションデータをサーバ１０Ａ等に送信する（Ｓ１０３）。このとき、端末４０は、生成した申込トランザクションデータをサーバ１０Ａ等のうちの１つのサーバに送信してもよいし、複数のサーバに送信してもよい。
サーバ１０Ａ等は、端末４０により送信された申込トランザクションデータを受信し、分散台帳に格納する（Ｓ１０４）。
サーバ１０Ａ等は、申込トランザクションデータの送信元である端末４０に係る支払者Ｕ１による支払いの手続きを行うために要する手数料の額を算出する（Ｓ１０５）。
サーバ１０Ａ等は、算出した手数料の額を含む手数料情報を支払者Ｕ１が保有する端末４０に送信する（Ｓ１０６）。この時、サーバ１０Ａ等に含まれる複数のサーバの全てが手数料情報を端末４０に送信しなくてもよい。例えば、手数料の額を算出し終えたサーバは、手数料情報を端末４０に送信すると共に、手数料の額を算出し終えたことを示す完了情報を他のサーバに送信してもよい。他のサーバは、完了情報を受信したときに手数料情報を端末４０へ送信していない場合、手数料情報を端末４０に送信しなくてもよい。
端末４０は、サーバ１０Ａ等から送信された手数料情報を受信すると、手数料情報に含まれる手数料の額を端末４０に表示させる（Ｓ１０７）。このとき、端末４０は、手数料情報に含まれる手数料の額に同意するか否かを支払者Ｕ１に問い合わせるＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を提示してもよい。
図８は、端末４０の表示部６０が表示するＵＩ５０の一例を示す図である。
ＵＩ５０は、手数料の額５１と、手数料の支払いに同意することを示す入力を受け付けるための同意ボタン５２と、手数料の支払いに同意しないこと（不同意）を示す入力を受け付けるための不同意ボタン５３とを含む。
端末４０は、提示したＵＩに対して同意を示す入力を受け付けたか否かを判定する（Ｓ１０８）。
端末４０は、同意を示す入力を受け付けた場合（Ｓ１０８でＹｅｓ）、例えばＵＩ５０において同意ボタン５２への入力を受け付けた場合、ステップＳ１０１で受け付けた入力に基づく、取り引き予定日時と同じ取り引き日時、および、取り引き予定額と同じ額の取り引き額を含む支払トランザクションデータを生成する（Ｓ１０９）。一方で、端末４０は、不同意を示す入力を受け付けた場合、例えばＵＩ５０において不同意ボタン５３への入力を受け付けた場合、または、同意を示す入力を一定期間受け付けない場合（Ｓ１０８でＮｏ）、当該取り引きに係る処理を終了する。この場合、端末４０は、処理が終了したことを示す終了情報をサーバ１０Ａ等に送信してもよい。サーバ１０Ａ等は、終了情報を受信すると、当該取り引きに係る処理を終了する。なお、サーバ１０Ａ等は、終了情報を受信することに限らずに、手数料情報を送信してから一定期間端末４０から情報（例えば、支払トランザクションデータまたは手数料トランザクションデータ）を受信しない場合、当該取り引きに係る処理を終了してもよい。
ステップＳ１０９の後で、端末４０は、生成した支払トランザクションデータをサーバ１０Ａ等に送信する（Ｓ１１０）。このとき、端末４０は、生成した支払トランザクションデータをサーバ１０Ａ等のうちの１つのサーバに送信してもよいし、複数のサーバに送信してもよい。
サーバ１０Ａ等は、端末４０により送信された支払トランザクションデータを受信し、分散台帳に格納する（Ｓ１１１）。
サーバ１０Ａ等は、支払トランザクションデータに含まれる支払額の支払いが支払者Ｕ１によって取り引き日時に行われたことを支払先Ｕ２の端末４１に通知する（Ｓ１１２）。
また、ステップＳ１０９の後で、端末４０は、手数料情報に基づく、手数料の額を含む手数料トランザクションデータを生成する（Ｓ１１３）。
端末４０は、生成した手数料トランザクションデータをサーバ１０Ａ等に送信する（Ｓ１１４）。このとき、端末４０は、生成した手数料トランザクションデータをサーバ１０Ａ等のうちの１つのサーバに送信してもよいし、複数のサーバに送信してもよい。
サーバ１０Ａ等は、端末４０により送信された手数料トランザクションデータを受信し、分散台帳に格納する（Ｓ１１５）。
サーバ１０Ａ等は、手数料トランザクションデータに含まれる手数料の額の支払いが支払者Ｕ１によって取り引き日時に行われたことを業者Ｘの端末４２に通知する（Ｓ１１６）。
なお、ステップＳ１０９は、ステップＳ１１３の後に行われてもよいし、ステップＳ１１３と並行して行われてもよい。また、ステップＳ１１０は、ステップＳ１１４の後に行われてもよいし、ステップＳ１１４と並行して行われてもよい。また、ステップＳ１１１は、ステップＳ１１５の後に行われてもよいし、ステップＳ１１５と並行して行われてもよい。また、ステップＳ１１２は、ステップＳ１１６の後に行われてもよいし、ステップＳ１１６と並行して行われてもよい。
以上のように、本実施の形態に係る制御方法によれば、受信した申込トランザクションデータに含まれる予定の日時以前に分散台帳に記録されている支払者Ｕ１による取り引きに基づいて手数料を算出し、手数料を支払うように要求する。このため、例えば、算出する手数料の額の大きさを調整することで、トークンの取り引きを管理する複数のサーバの処理が特定の期間に偏らないように取り引きが発生するタイミングを制御することができる。このため、複数のサーバの処理の安定化を図り、かつ、取り引きに関する処理が行われずに電力が消費されることを低減することができる。
また、手数料の算出を、他の人または他のシステムを介在することなく、早期かつ安全に実行することができる。よって、本開示に係る制御方法は、トークンの取り引きを管理する複数のサーバの消費電力を削減することができる。
また、コンセンサスアルゴリズムの実行を経て分散台帳を格納する。よって、本開示に係る制御方法は、コンセンサスアルゴリズムの実行を経ることによって、より容易に、トークンの取り引きを適切に管理することができる。
また、手数料の算出では、分散台帳における支払者Ｕ１のトークンの残高が多いほど高い額の手数料を算出する。また、手数料の算出では、分散台帳における支払者Ｕ１による前回の取り引きタイミングからの経過時間が長いほど高い額の手数料を算出する。また、手数料の算出では、分散台帳における支払者Ｕ１による取り引きにおいて、現時点から所定時間前までの期間における取引量の単位時間当たりの平均が小さいほど高い額の手数料を算出する。このため、支払者Ｕ１がトークンを使用していないほど高い額の手数料を要求することができる。よって、支払者Ｕ１にトークンを早く使用するように促すことができ、取り引きが発生するタイミングを制御することができる。
また、手数料情報は、端末４０の表示部６０に手数料を表示させるための情報である。このため、手数料を端末４０の表示部６０に表示させることで、支払者Ｕ１にトークンを早く使用するように促すことができる。よって、取り引きが発生するタイミングを制御することができる。
また、手数料情報は、支払者Ｕ１に手数料情報に含まれる手数料に同意するか否かを問い合わせる問い合わせ情報を含む。これによれば、端末４０を介して、手数料に同意するか否かを支払者Ｕ１に問い合わせることができるため、支払者Ｕ１がトークンを使用するタイミングを調整することができる。例えば、手数料の額を大きくするほどトークンを使用するタイミングを早めることができる。よって、取り引きが発生するタイミングを制御することができる。
（変形例１）
上記実施の形態では、トークンは、複数種類のトークンを含んでいてもよい。つまり、取引管理システム１は、複数種類のトークンの取り引きを管理していてもよい。この場合、サーバ１０Ａ等が保有する分散台帳は、異なる種類のトークン毎に異なる複数のサブ分散台帳を含む。分散台帳は、例えば、２種類のトークンＡおよびトークンＢがある場合、トークンＡの取り引きを示すサブ分散台帳Ａと、トークンＢの取り引きを示すサブ分散台帳Ｂとを含む。
サーバ１０Ａ等の制御部１３は、手数料の算出（Ｓ１０５）において、申し込み情報に含まれる予定の日時以前に複数のサブ分散台帳に記録されている支払者Ｕ１による取り引きに基づいて、異なる種類のトークン毎に手数料を複数算出する。制御部１３は、例えば、申し込み情報に含まれる予定の日時以前にサブ分散台帳Ａに記録されている支払者Ｕ１によるトークンＡの取り引きに基づいて、トークンＡの取り引きにかかる手数料Ａを算出する。これと共に、制御部１３は、申し込み情報に含まれる予定の日時以前にサブ分散台帳Ｂに記録されている支払者Ｕ１によるトークンＢの取り引きに基づいて、トークンＢの取り引きにかかる手数料Ｂを算出する。
なお、手数料の算出では、制御部１３は、トークンＡの流通量が多く、トークンＢの流通量がトークンＡと比較して少ない場合、トークンＢの流通量を増加させるために、トークンＢの取り引きにかかる手数料をトークンＡの取り引きに係る手数料よりも少なくしてもよい。ここで、流通量とは、例えば、現時点から所定時間前までの期間における、複数のユーザによる取引量の単位時間当たりの平均であってもよい。複数のユーザによる取引量とは、特定の種類のトークンを利用しているユーザ全ての取引量の総和であってもよい。平均とは、単位時間当たりの平均に加えて、さらに、一人当たりのユーザの平均であってもよい。トークンＢの取り引きにかかる手数料をトークンＡの取り引きに係る手数料よりも少なくするとは、トークンＡの価値およびトークンＢの価値を比較するための共通の価値で比較したときに当該価値に換算したときのトークンＢの価値がトークンＡの価値よりも少なくなるように算出することである。また、この場合、例えば、手数料の算出では、トークンＢの手数料を算出するための手数料算出情報を示す関係が、トークンＡの手数料を算出するための手数料算出情報を示す関係よりも、上記の共通の価値換算における手数料額が、どの残高、どの経過時間、またはどの平均においても小さくなるように調整し、調整後の２つの関係を用いてトークンＡの手数料およびトークンＢの手数料を算出してもよい。調整では、例えば、トークンＢの関係における手数料額に１より小さい係数を乗じることで、トークンＢの関係をトークンＡの関係よりも小さくしてもよいし、トークンＡの関係における手数料額に１より大きい係数を乗じることで、トークンＢの関係をトークンＡの関係よりも小さくしてもよい。また、調整では、例えば、トークンＢの関係における手数料額に所定の手数料額を減算する（つまり、負の方向にオフセットする）ことで、トークンＢの関係をトークンＡの関係よりも小さくしてもよいし、トークンＡの関係における手数料額に所定の手数料額を加算する（つまり、正の方向にオフセットする）ことで、トークンＢの関係をトークンＡの関係よりも小さくしてもよい。
制御部１３は、手数料の送信（Ｓ１０６）において、手数料情報として、算出した複数の手数料、つまり、手数料Ａおよび手数料Ｂを含む情報を端末４０に送信する。このように、複数種類のトークン毎に手数料を算出するため、トークンの種類毎に取引量の調整を行うことができる。
端末４０は、サーバ１０Ａ等から送信された手数料情報を受信すると、手数料情報に含まれる手数料の額を、異なる種類のトークン毎に端末４０の表示部６０に表示させる（Ｓ１０７）。つまり、手数料情報は、端末４０の表示部６０に、異なる種類のトークン毎に手数料を表示させるための情報である。このため、トークンの種類毎に手数料を端末の表示部に表示させることで、支払者Ｕ１に種類毎にトークンを早く使用するように促すことができる。よって、トークンの種類毎に取り引きが発生するタイミングを制御することができる。
図９は、端末４０の表示部６０が表示するＵＩ５０Ａの一例を示す図である。
ＵＩ５０Ａは、トークンＡの取り引きにかかる手数料Ａを表示する。ＵＩ５０Ａは、手数料Ａの額５１Ａと、手数料Ａの支払いに同意することを示す入力を受け付けるための同意ボタン５２Ａと、手数料Ａの支払いに同意しないこと（不同意）を示す入力を受け付けるための不同意ボタン５３Ａと、手数料Ｂを表示するＵＩ５０Ｂに表示を切り替える切り替えボタン５４Ａとを含む。
端末４０は、トークンＡの手数料Ａへの同意を示す入力を受け付けた場合、例えばＵＩ５０Ａにおいて同意ボタン５２Ａへの入力を受け付けた場合、ステップＳ１０１で受け付けた入力に基づく、取り引き予定日時と同じ取り引き日時、および、取り引き予定額と同じ額の取り引き額を含む支払トランザクションデータを生成する。生成される支払トランザクションデータは、トークンＡを取り引きに用いることを示す情報をさらに含む。一方で、端末４０は、不同意を示す入力を受け付けた場合、例えばＵＩ５０Ａにおいて不同意ボタン５３Ａへの入力を受け付けた場合、または、同意を示す入力を一定期間受け付けない場合、当該取り引きに係る処理を終了する、または、手数料Ｂを表示するＵＩ５０Ｂに表示を切り替える。
図１０は、端末４０の表示部６０が表示するＵＩ５０Ｂの一例を示す図である。
ＵＩ５０Ｂは、トークンＢの取り引きにかかる手数料Ｂを表示する。ＵＩ５０Ｂは、手数料Ｂの額５１Ｂと、手数料Ｂの支払いに同意することを示す入力を受け付けるための同意ボタン５２Ｂと、手数料Ｂの支払いに同意しないこと（不同意）を示す入力を受け付けるための不同意ボタン５３Ｂと、手数料Ａを表示するＵＩ５０Ａに表示を切り替える切り替えボタン５４Ｂとを含む。
端末４０は、トークンＢの手数料Ｂへの同意を示す入力を受け付けた場合、例えばＵＩ５０Ｂにおいて同意ボタン５２Ｂへの入力を受け付けた場合、ステップＳ１０１で受け付けた入力に基づく、取り引き予定日時と同じ取り引き日時、および、取り引き予定額と同じ額の取り引き額を含む支払トランザクションデータを生成する。生成される支払トランザクションデータは、トークンＢを取り引きに用いることを示す情報をさらに含む。一方で、端末４０は、不同意を示す入力を受け付けた場合、例えばＵＩ５０Ｂにおいて不同意ボタン５３Ｂへの入力を受け付けた場合、または、同意を示す入力を一定期間受け付けない場合、当該取り引きに係る処理を終了する、または、手数料Ａを表示するＵＩ５０Ａに表示を切り替える。
なお、処理を終了する場合、端末４０は、処理が終了したことを示す終了情報をサーバ１０Ａ等に送信してもよい。サーバ１０Ａ等は、終了情報を受信すると、当該取り引きに係る処理を終了する。なお、サーバ１０Ａ等は、終了情報を受信することに限らずに、手数料情報を送信してから一定期間端末４０から情報（例えば、支払トランザクションデータまたは手数料トランザクションデータ）を受信しない場合、当該取り引きに係る処理を終了してもよい。
図１１は、端末４０の表示部６０が表示するＵＩ５０Ｃを示す図である。ＵＩ５０Ｃは、ＵＩ５０ＡおよびＵＩ５０Ｂとは別の例におけるＵＩである。
ＵＩ５０Ｃは、トークンＡおよびトークンＢのうちで、手数料がお得である（つまり安い）方のトークンＡの取り引きにかかる手数料Ａを表示する。ＵＩ５０Ｃは、手数料Ｃの額５１Ｃと、手数料Ｃの支払いに同意することを示す入力を受け付けるための同意ボタン５２Ｃと、手数料Ｃの支払いに同意しないこと（不同意）を示す入力を受け付けるための不同意ボタン５３Ｃとを含む。なお、ＵＩ５０Ｃは、さらに、手数料Ｂを表示するＵＩに表示を切り替える切り替えボタンを含んでいてもよい。
なお、各ＵＩには、さらに、提示する手数料が算出されることとなった理由を示すメッセージを含んでいてもよい。メッセージは、例えば、取り引き予定日時における、分散台帳における支払者のトークンの残高が所定の残高であることが理由で、提示された手数料が算出されたことを示してもよい。この場合、メッセージには、トークンの残高が少ないほど手数料が安くなることが示されてもよい。また、メッセージは、例えば、分散台帳における支払者による前回の取り引きタイミングからの経過時間が所定の経過時間であることが理由で、提示された手数料が算出されたことを示してもよい。この場合、メッセージには、経過時間が短いほど手数料が安くなることが示されてもよい。また、メッセージは、例えば、分散台帳における支払者による取り引きにおいて、申込トランザクションデータを受信したタイミングから所定時間前までの期間における取引量の単位時間当たりの平均が所定の平均値であることが理由で、提示された手数料が算出されたことを示してもよい。この場合、メッセージには、平均値が大きいほど手数料が安くなることが示されてもよい。
（変形例２）
本変形例において、上記各実施の形態の取引管理システムの別の構成について説明する。
図１２は、本変形例における取引管理システム２の構成を模式的に示すブロック図である。
図１２に示されるように、取引管理システム２は、サーバ１０Ａ、１０Ｂ及び１０Ｃと、端末４０、４１および４２とを備える。取引管理システム２が備える各装置は、ネットワークＮによって互いに通信可能に接続されている。ネットワークＮは、どのような通信回線又はネットワークから構成されてもよく、例えば、インターネット、携帯電話のキャリアネットワークなどを含む。
特に、取引管理システム２では、サーバ１０Ａ、１０Ｂ及び１０Ｃが互いにネットワークＮを介して接続されている。また、サーバ１０Ａに端末４０が接続されており、サーバ１０Ｂに端末４１が接続されており、サーバ１０Ｃに端末４２が接続されている。
このような構成は、例えば、複数の団体が取引管理システム２を運営する場合において、各団体が管理するサーバを、ネットワークＮを介して接続する場合に利用され得る。例えば、団体Ａにサーバ１０Ａと端末４０とが所属しており、団体Ｂにサーバ１０Ｂと端末４１とが所属しており、団体Ｃにサーバ１０Ｃと端末４２とが所属している。
サーバ１０Ａ等及び端末４０等の動作は、上記各実施の形態における場合と同様であるので説明を省略する。
（変形例３）
本変形例において、上記各実施の形態の取引管理システムの別の構成について説明する。
図１３は、本変形例における取引管理システム３の構成を模式的に示すブロック図である。
図１３に示されるように、取引管理システム３は、サーバ１０Ｄと、端末４０、４１および４２とを備える。取引管理システム３が備える各装置は、ネットワークＮによって互いに通信可能に接続されている。ネットワークＮは、どのような通信回線又はネットワークから構成されてもよく、例えば、インターネット、携帯電話のキャリアネットワークなどを含む。
特に、取引管理システム３では、サーバ１０Ｄ、並びに、端末４０および４１が互いにネットワークＮを介して接続されている。また、サーバ１０Ｄに端末４２が接続されている。この場合、サーバ１０Ｄ、端末４０および４１それぞれが、上記各実施の形態におけるサーバ１０Ａ等の動作をする。
このような構成は、例えば、１以上の団体と１以上の個人とが取引管理システム３を運営する場合において、各団体又は各個人が管理するサーバ又は端末を、ネットワークＮを介して接続する場合に利用され得る。例えば、団体Ｄにサーバ１０Ｄと端末４２とが所属しており、団体Ｄと、個人である支払者Ｕ１及び支払先Ｕ２とが取引管理システム３を運営している。
サーバ１０Ａ等及び端末４０等の動作は、上記各実施の形態における場合と同様であるので説明を省略する。
（変形例４）
ここで、実施の形態の変形例４について説明する。
図１４は、本変形例におけるサーバの処理を示すフロー図である。
図１４に示されるように、サーバ１０Ａ等は、第１ユーザとしての支払者Ｕ１により操作された端末４０から、支払者Ｕ１が取り引きを行う予定の日時を含む申し込み情報を受信する（Ｓ２０１）。
各サーバ１０Ａ～１０Ｃは、当該サーバが管理する第１分散台帳を参照し、受信した申し込み情報に含まれる予定の日時以前に第１分散台帳に記録されている支払者Ｕ１による取り引きに基づいて手数料を算出する（Ｓ２０２）。
各サーバ１０Ａ～１０Ｃは、端末４０に算出した手数料を含む手数料情報を送信する（Ｓ２０３）。
各サーバ１０Ａ～１０Ｃは、端末４０から取り引きの予定に対応する取り引きにかかるトークンの量を示す第１トークン量を含む第１トランザクションデータを受信し、受信した第１トランザクションデータを複数のサーバ１０Ａ～１０Ｃのうちの当該サーバ（ステップＳ２０４の処理の主体となるサーバ）とは異なる複数の他のサーバに転送し、かつ、第１トランザクションデータを含む第１ブロックを第１分散台帳に格納する（Ｓ２０４）。
各サーバ１０Ａ～１０Ｃは、端末４０から手数料にかかるトークンの量を示す第２トークン量を含む第２トランザクションデータを受信し、受信した第２トランザクションデータを複数の他のサーバに転送し、かつ、第２トランザクションデータを含む第２ブロックを第１分散台帳に格納する（Ｓ２０５）。
これにより、トークンの取り引きを管理する複数のサーバの処理が特定の期間に偏らないように取り引きが発生するタイミングを制御することができる。よって、複数のサーバの処理の安定化を図り、かつ、取り引きに関する処理が行われずに電力が消費されることを低減することができる。
図１５は、実施の形態の変形例４におけるサーバの構成を模式的に示すブロック図である。
図１５に示されるように、分散台帳を保有している複数のサーバを備える取り引き管理システムにおいて、当該複数のサーバのうちの一のサーバ６０Ａは、処理部６１と制御部６３とを備える。
処理部６１は、第１ユーザとしての支払者Ｕ１により操作された端末４０から、支払者Ｕ１が取り引きを行う予定の日時を含む申し込み情報を受信する。
制御部６３は、当該サーバが管理する第１分散台帳を参照し、受信した申し込み情報に含まれる予定の日時以前に第１分散台帳に記録されている支払者Ｕ１による取り引きに基づいて手数料を算出する。制御部６３は、端末４０に算出した手数料を含む手数料情報を送信する。
処理部６１は、さらに、端末４０から取り引きの予定に対応する取り引きにかかるトークンの量を示す第１トークン量を含む第１トランザクションデータを受信し、受信した第１トランザクションデータを複数のサーバ１０Ａ～１０Ｃのうちの当該サーバ（当該処理部６１を備えるサーバ）とは異なる複数の他のサーバに転送し、かつ、第１トランザクションデータを含む第１ブロックを第１分散台帳に格納する。また、処理部６１は、さらに、端末４０から手数料にかかるトークンの量を示す第２トークン量を含む第２トランザクションデータを受信し、受信した第２トランザクションデータを複数の他のサーバに転送し、かつ、第２トランザクションデータを含む第２ブロックを第１分散台帳に格納する。
これにより、トークンの取り引きを管理する複数のサーバの処理が特定の期間に偏らないように取り引きが発生するタイミングを制御することができる。よって、複数のサーバの処理の安定化を図り、かつ、取り引きに関する処理が行われずに電力が消費されることを低減することができる。
（補足）
上記各実施の形態、又は、変形例におけるブロックチェーンについて補足的に説明する。
図１６は、ブロックチェーンのデータ構造を示す説明図である。
ブロックチェーンは、その記録単位であるブロックがチェーン（鎖）状に接続されたものである。それぞれのブロックは、複数のトランザクションデータと、直前のブロックのハッシュ値とを有している。具体的には、ブロックＢ２には、その前のブロックＢ１のハッシュ値が含まれている。そして、ブロックＢ２に含まれる複数のトランザクションデータと、ブロックＢ１のハッシュ値とから演算されたハッシュ値が、ブロックＢ２のハッシュ値として、ブロックＢ３に含められる。このように、前のブロックの内容をハッシュ値として含めながら、ブロックをチェーン状に接続することで、記録されたトランザクションデータの改ざんを有効に防止する。
仮に過去のトランザクションデータが変更されると、ブロックのハッシュ値が変更前と異なる値になり、改ざんしたブロックを正しいものとみせかけるには、それ以降のブロックすべてを作り直さなければならず、この作業は現実的には非常に困難である。この性質を使用して、ブロックチェーンに改ざん困難性が担保されている。
図１７は、トランザクションデータのデータ構造を示す説明図である。
図１７に示されるトランザクションデータは、トランザクション本体Ｐ１と、電子署名Ｐ２とを含む。トランザクション本体Ｐ１は、当該トランザクションデータに含まれるデータ本体である。電子署名Ｐ２は、トランザクション本体Ｐ１のハッシュ値に対して、当該トランザクションデータの作成者の署名鍵で署名する、より具体的には、作成者の秘密鍵で暗号化することで生成されたものである。
トランザクションデータは、電子署名Ｐ２を有するので、改ざんが実質的に不可能である。これにより、トランザクション本体の改ざんが防止される。
なお、上記実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記実施の形態のコンテンツ管理システムなどを実現するソフトウェアは、次のようなプログラムである。
すなわち、このプログラムは、コンピュータに、複数の分散台帳を利用してトークンの取り引きを管理する複数のサーバであって、それぞれが前記複数の分散台帳のうちの１以上の分散台帳を管理する複数のサーバのうちの一のサーバによって実行される制御方法であって、第１ユーザにより操作された端末から、前記第１ユーザが取り引きを行う予定の日時を含む申し込み情報を受信し、前記一のサーバが管理する第１分散台帳を参照し、受信した前記申し込み情報に含まれる前記予定の日時以前に前記第１分散台帳に記録されている前記第１ユーザによる取り引きに基づいて手数料を算出し、算出した前記手数料を含む手数料情報を前記端末に送信し、前記端末から前記予定に対応する取り引きにかかるトークンの量を示す第１トークン量を含む第１トランザクションデータを受信し、受信した前記第１トランザクションデータを前記複数のサーバのうちの前記一のサーバとは異なる複数の他のサーバに転送し、かつ、前記第１トランザクションデータを含む第１ブロックを前記第１分散台帳に格納し、前記端末から前記手数料にかかるトークンの量を示す第２トークン量を含む第２トランザクションデータを受信し、受信した前記第２トランザクションデータを前記複数の他のサーバに転送し、かつ、前記第２トランザクションデータを含む第２ブロックを前記第１分散台帳に格納する制御方法を実行させるプログラムである。
以上、一つまたは複数の態様に係るファンド管理システムなどについて、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。
本開示は、トークンの取り引きを管理する取引管理システムに利用可能である。
１～３ 取引管理システム
１０Ａ～１０Ｃ、６０Ａ サーバ
１１、６１ 処理部
１２ 台帳管理部
１３、６３ 制御部
１５ 格納部
１６ 台帳記憶部
４０～４２ 端末
５０、５０Ａ～５０Ｃ ＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）
５１、５１Ａ～５１Ｃ 手数料の額
５２、５２Ａ～５２Ｃ 同意ボタン
５３、５３Ａ～５３Ｃ 不同意ボタン
５４Ａ、５４Ｂ 切り替えボタン
Ｂ１、Ｂ２、Ｂ３ ブロック
Ｎ ネットワーク
Ｕ１ 支払者
Ｕ２ 支払先
Ｘ 業者

Claims (12)

  1. 複数の分散台帳を利用してトークンの取り引きを管理する複数のサーバであって、それぞれが前記複数の分散台帳のうちの１以上の分散台帳を管理する複数のサーバのうちの一のサーバによって実行される制御方法であって、
    第１ユーザにより操作された端末から、前記第１ユーザが取り引きを行う予定の日時を含む申し込み情報を受信し、
    前記一のサーバが管理する第１分散台帳を参照し、受信した前記申し込み情報に含まれる前記予定の日時以前に前記第１分散台帳に記録されている前記第１ユーザによる取り引きに基づいて手数料を算出し、
    算出した前記手数料を含む手数料情報を前記端末に送信し、
    前記端末から前記予定に対応する取り引きにかかるトークンの量を示す第１トークン量を含む第１トランザクションデータを受信し、受信した前記第１トランザクションデータを前記複数のサーバのうちの前記一のサーバとは異なる複数の他のサーバに転送し、かつ、前記第１トランザクションデータを含む第１ブロックを前記第１分散台帳に格納し、
    前記端末から前記手数料にかかるトークンの量を示す第２トークン量を含む第２トランザクションデータを受信し、受信した前記第２トランザクションデータを前記複数の他のサーバに転送し、かつ、前記第２トランザクションデータを含む第２ブロックを前記第１分散台帳に格納する
    制御方法。
  2. 前記申し込み情報は、前記予定の日時を含む第３トランザクションデータであり、
    前記複数の分散台帳のそれぞれは、前記第３トランザクションデータに基づいて前記手数料を算出するためのコントラクトコードを含み、
    前記手数料の算出では、前記第３トランザクションデータを受信すると、前記第１分散台帳に含まれる前記コントラクトコードを実行することで前記手数料を算出する
    請求項１に記載の制御方法。
  3. 前記第１ブロックの前記第１分散台帳への格納では、前記複数の他のサーバと共にコンセンサスアルゴリズムを実行し、前記第１ブロックを前記第１分散台帳に格納し、
    前記第２ブロックの前記第１分散台帳への格納では、前記複数の他のサーバと共にコンセンサスアルゴリズムを実行し、前記第２ブロックを前記第１分散台帳に格納する
    請求項１または２に記載の制御方法。
  4. 前記手数料の算出では、前記第１分散台帳における前記第１ユーザの前記トークンの残高が多いほど高い額の手数料を算出する
    請求項１から３のいずれか１項に記載の制御方法。
  5. 前記手数料の算出では、前記第１分散台帳における前記第１ユーザによる前回の取り引きタイミングからの経過時間が長いほど高い額の手数料を算出する
    請求項１から４のいずれか１項に記載の制御方法。
  6. 前記手数料の算出では、前記第１分散台帳における前記第１ユーザによる取り引きにおいて、現時点から所定時間前までの期間における取引量の単位時間当たりの平均が小さいほど高い額の手数料を算出する
    請求項１から５のいずれか１項に記載の制御方法。
  7. 前記手数料情報は、前記端末の表示部に前記手数料を表示させるための情報である
    請求項１から６のいずれか１項に記載の制御方法。
  8. 前記トークンは、複数種類のトークンを含み、
    前記第１分散台帳は、異なる種類のトークン毎に異なる複数のサブ分散台帳を含み、
    前記手数料の算出では、前記申し込み情報に含まれる前記予定の日時以前に前記複数のサブ分散台帳に記録されている前記第１ユーザによる取り引きに基づいて、異なる種類のトークン毎に手数料を複数算出し、
    前記手数料の送信では、前記手数料情報として、算出した前記複数の手数料を含む情報を前記端末に送信する
    請求項１から６のいずれか１項に記載の制御方法。
  9. 前記手数料情報は、前記端末の表示部に、異なる種類のトークン毎に前記手数料を表示させるための情報である
    請求項８に記載の制御方法。
  10. 前記手数料情報は、前記第１ユーザに前記手数料情報に含まれる前記手数料に同意するか否かを問い合わせる問い合わせ情報を含む
    請求項１から９のいずれか１項に記載の制御方法。
  11. 複数の分散台帳を利用してトークンの取り引きを管理する複数のサーバであって、それぞれが前記複数の分散台帳のうちの１以上の分散台帳を管理する複数のサーバのうちの一のサーバであって、
    前記複数の分散台帳のうちの第１分散台帳を管理する管理部と、
    第１ユーザにより操作された端末から、前記第１ユーザにより取り引きを行う予定の日時を含む申し込み情報と、前記端末から前記予定に対応する取り引きにかかるトークンの量を示す第１トークン量を含む第１トランザクションデータと、前記端末から手数料にかかるトークンの量を示す第２トークン量を含む第２トランザクションデータとを受信する受信部と、
    前記管理部における前記第１分散台帳を参照し、受信された前記申し込み情報に含まれる前記予定の日時以前に前記第１分散台帳に記録されている前記第１ユーザによる取り引きに基づいて前記手数料を算出する算出部と、
    前記端末に算出した前記手数料を含む手数料情報を送信する送信部と、を備え、
    （ｉ）前記受信部が前記第１トランザクションデータを受信すると、前記送信部は、受信された前記第１トランザクションデータを前記複数のサーバのうちの前記一のサーバとは異なる複数の他のサーバに転送し、かつ、前記管理部は、前記第１トランザクションデータを含む第１ブロックを前記第１分散台帳に記録し、
    （ｉｉ）前記受信部が前記第２トランザクションデータを受信すると、前記送信部は、受信された前記第２トランザクションデータを前記複数の他のサーバに転送し、かつ、前記管理部は、前記第２トランザクションデータを含む第２ブロックを前記第１分散台帳に記録する
    サーバ。
  12. 請求項１から１０のいずれか１項に記載の制御方法をコンピュータに実行させるためのプログラム。
JP2020571245A 2019-02-08 2020-02-06 制御方法、サーバ、および、プログラム Active JP7402187B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201962802856P 2019-02-08 2019-02-08
US62/802,856 2019-02-08
PCT/JP2020/004453 WO2020162515A1 (ja) 2019-02-08 2020-02-06 制御方法、サーバ、および、プログラム

Publications (2)

Publication Number Publication Date
JPWO2020162515A1 JPWO2020162515A1 (ja) 2021-12-23
JP7402187B2 true JP7402187B2 (ja) 2023-12-20

Family

ID=71947218

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020571245A Active JP7402187B2 (ja) 2019-02-08 2020-02-06 制御方法、サーバ、および、プログラム

Country Status (4)

Country Link
US (1) US20210365936A1 (ja)
JP (1) JP7402187B2 (ja)
CN (1) CN113383358A (ja)
WO (1) WO2020162515A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116724324A (zh) * 2021-01-28 2023-09-08 松下电器（美国）知识产权公司 控制方法、服务器和程序
CN113781227B (zh) * 2021-09-17 2024-03-29 北京快来文化传播集团有限公司 虚拟金币兑换方法、电子设备及计算机可读存储介质
JP7490916B1 (ja) 2024-02-02 2024-05-28 株式会社Synquery 情報処理装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018515833A (ja) 2015-03-31 2018-06-14 ナスダック， インコーポレイテッドＮａｓｄａｑ， Ｉｎｃ． ブロックチェーン取引記録のシステムおよび方法
US20180189753A1 (en) 2017-01-05 2018-07-05 Beskatta, LLC Infrastructure for obligation management and validation

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11341488B2 (en) * 2017-02-06 2022-05-24 Northern Trust Corporation Systems and methods for issuing and tracking digital tokens within distributed network nodes
US10944546B2 (en) * 2017-07-07 2021-03-09 Microsoft Technology Licensing, Llc Blockchain object interface
US10880074B2 (en) * 2018-10-15 2020-12-29 Adobe Inc. Smart contract platform for generating and customizing smart contracts

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018515833A (ja) 2015-03-31 2018-06-14 ナスダック， インコーポレイテッドＮａｓｄａｑ， Ｉｎｃ． ブロックチェーン取引記録のシステムおよび方法
US20180189753A1 (en) 2017-01-05 2018-07-05 Beskatta, LLC Infrastructure for obligation management and validation

Also Published As

Publication number Publication date
CN113383358A (zh) 2021-09-10
WO2020162515A1 (ja) 2020-08-13
JPWO2020162515A1 (ja) 2021-12-23
US20210365936A1 (en) 2021-11-25

Similar Documents

Publication Publication Date Title
KR101920015B1 (ko) 이종 블록체인 기반의 토큰 관리 방법 및 이를 이용한 토큰 관리 서버
JP7402187B2 (ja) 制御方法、サーバ、および、プログラム
US20200020032A1 (en) System and method for cryptocurrency trading
US9773237B2 (en) Synchronous split payment transaction management
US20170221053A1 (en) Digital asset conversion
US20170124556A1 (en) Event synchronization systems and methods
KR20200091882A (ko) 증분적으로 완성되는 디지털 자산 담보 지갑
WO2018060951A1 (en) A system for trading in a contract-free manner
JP2019523495A (ja) 分散トランザクションコンセンサスネットワークのデジタル財管理
CA3163323A1 (en) Electronic trading and settlement system for blockchain-integrated cryptographic difficulty-based financial instruments
CN109643415A (zh) 交易管理技术
US20200211109A1 (en) Methods and systems for margin lending and trading on a decentralized exchange
US20180341972A1 (en) System and method for distributing sales profit
CN109426955A (zh) 目标对象提供方法、装置及系统
US10140658B1 (en) Commodity backed virtual currency method and system for network transactions
KR20190118376A (ko) 암호화폐 거래소내 실거래 전자지갑 기반의 블록체인 거래 처리 방법
US20180341966A1 (en) System and method for promoting product sales by using distribution of sales profit according to event success
JP2023041922A (ja) サーバおよび端末
US20220058599A1 (en) Settlement operation support system and settlement operation support method
CN110930257A (zh) 一种数据处理方法、装置、设备及存储介质
JP7410890B2 (ja) 制御方法、サーバおよびプログラム
JP6885457B2 (ja) 仮想通貨の支払代行装置、仮想通貨の支払代行方法及びプログラム
JP7524066B2 (ja) 制御方法、ファンド管理システム、及び、プログラム
TWM631250U (zh) 換匯交易管理系統
JP2023016582A (ja) プログラム、情報処理方法、システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20221122

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20231114

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20231208

R150 Certificate of patent or registration of utility model

Ref document number: 7402187

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150