JP7159689B2 - 決済装置、決済方法及びプログラム - Google Patents

Description

本発明は、決済装置、決済方法及びプログラムに関する。

互いに信頼関係を築けていない相手とのオンライン取引において、サービスの提供前の支払には、サービスが架空であるリスクが利用者側に有る。したがって、サービスの利用者は、サービスに対する決済をサービス提供後に行いたい。

一方、無条件でキャンセル可能な受注には、無断キャンセルのリスクがサービスの提供者側に有る。実際に、予約サイトで予約をしたにも関わらず利用者が来店せずにレストランが困っている状況が発生している。したがって、サービスの提供者は、無断キャンセルによる機会損失を防ぐために予約時に決済を行いたい。

サービスの利用者と提供者との間における、決済のタイミングに関する相容れない要望に対する解決策として、クレジットカードの利用が一般的である。

特表２０１７－５１５２５２号公報 国際公開２０１７／０１０４５５号 特開２０１７－９１１４９号公報

しかしながら、クレジットカードの利用には、利用者側が提供者側を信じる必要があり、信頼関係を築けていない小規模ビジネスには向かない。すなわち、利用者は、信頼できない相手にクレジットカードの決済情報を渡したくない。

一方、予約時に信頼できるＥＣサイトでの決済は、第三者が関わるのでコストが高くなるため、やはり小規模ビジネスには向かない。

そこで、一側面では、本発明は、取引の信用性を向上させることを目的とする。

一つの態様では、決済装置は、サービスの利用要求に応じて、前記サービスの利用に関する支払の保留を示す情報をブロックチェーンの第１の台帳に記録し、前記利用要求に含まれる決済条件を前記ブロックチェーンの第２の台帳に記録する記録部と、前記サービスの決済要求に応じ、当該決済要求と、前記第２の台帳に記録された前記決済条件とに基づいて、前記第１の台帳に記録された前記サービスの利用に関する支払を実行するか否かを判定する判定部と、を有する。

一側面として、取引の信用性を向上させることができる。

決済の保留を実現するためのフローと保留を管理する台帳の例を示す図である。 保留口座が無い場合の仮想通貨台帳の変化の例を示す図である。 保留口座が有る場合の仮想通貨台帳の変化の例を示す図である。 本発明の実施の形態におけるシステム構成例を示す図である。 本発明の実施の形態におけるブロックチェーンＢＣを構成する各ノード１０のハードウェア構成例を示す図である。 本発明の実施の形態における利用者端末２０、提供者端末３０及びブロックチェーンＢＣの機能構成例を示す図である。 本実施の形態において実行される各処理の関係を説明するためのフローチャートである。 サービス予約処理の処理手順の一例を説明するためのシーケンス図である。 予約時における決済情報の一例を示す図である。 予約時における決済ポリシーの一例を示す図である。 提供者の署名の付与後の決済情報の一例を示す図である。 通常決済処理の処理手順の一例を説明するためのシーケンス図である。 利用者事前キャンセル時の決済処理の処理手順の一例を説明するためのシーケンス図である。 利用者無断キャンセル時の決済処理の処理手順の一例を説明するためのシーケンス図である。 提供者事前キャンセル時の決済処理の処理手順の一例を説明するためのシーケンス図である。 提供者無断キャンセル時の決済処理の処理手順の一例を説明するためのシーケンス図である。

以下、図面に基づいて本発明の実施の形態を説明する。まず、本実施の形態の概要について説明する。

ブロックチェーン上では仮想通貨の送金によって決済が行える。サービスの予約システムとブロックチェーン上の仮想通貨での決済機能とを組み合わせると、予約時に仮想通貨を使った決済が可能になる。しかし、予約者は予約時に決済を行うと、サービスが架空であった場合に取戻しができないリスクが発生する。

そこで、本実施の形態では、決済を行う条件が満たされるまで決済（支払）を保留するトランザクション機能をブロックチェーンに持たせる。決済を行う条件は、予約時にポリシーとして定義される。当該ポリシーは、改ざん防止のためブロックチェーンの台帳に格納される。当該条件が満たされればサービスの提供者（以下、単に「提供者」という。）が決済要求を行うことで、決済の保留が解除される。

このような仕組みにより、サービスの利用者（以下、単に「利用者」という。）は、サービスが提供されるまで決済を保留することができ、提供者は、無断キャンセル時に決済を実行してキャンセル代を徴収することができる。

なお、本実施の形態において、サービスの予約（サービスの利用要求）はオンラインで行われ、サービスの提供は、レストランや宿泊施設等、利用者と提供者とが対面する状況で行われる。

決済を行う条件としてのポリシーの定義は、例えば、以下の通りである。
（１）正常にサービスが提供された場合、提供者から決済要求が行われ、当該決済要求に利用者の署名が含まれていれば、保留されている決済の保留が解除される（すなわち、正常に決済が行われる。）。なお、サービス提供時に利用者は提供者に署名を渡す
（２）利用者又は提供者が原因でサービスがキャンセルされた場合、利用者からの決済要求に応じ、保留されている決済について、ポリシーに従った金額での決済が行われる。ポリシーに従った金額の一例として、前日までのキャンセルは無料、当日以降のキャンセルは全額、当日に指定場所（店舗）からのキャンセルは無料等が挙げられる。当日に指定場所（店舗）からのキャンセルとは、サービスが提供される予定の日に利用者がサービスの提供場所まで行ったにも関わらず、サービスが提供されなかった場合（例えば、サービスが架空であった場合）でのキャンセルである。
（３）無断キャンセルが行われた場合、サービス提供者からの決済要求に応じ、提供者の署名をもってポリシーに従った金額での決済が行われる。

上記のように、ブロックチェーンが、決済を保留する機能を有し、サービスの提供状況に応じてポリシーに従って決済する機能を有することで、信頼できない者同士でも予約時に決済の準備を行い、最終的なサービスの提供状況に応じて決済を行うことができる。その結果、利用者はサービス提供まで決済を保留でき、提供者は無断キャンセルによる損失を削減できる。すなわち、取引の信用性を向上させることができる。

但し、一般的な仮想通貨のブロックチェーンは、トランザクション（決済）を保留し、決済を遅延する機能を有さない。そこで、本実施の形態では、保留された決済を管理するための保留口座がブロックチェーンに用意される。

図１は、決済の保留を実現するためのフローと保留を管理する台帳の例を示す図である。

図１の（１）に示されるように、通常の決済では、利用者の口座Ａから提供者の口座Ｂへ資産（仮想通貨）が移転される。

一方、（２）では、決済の保留を実現するために、利用者の口座Ａから口座Ａの（すなわち、利用者の）保留口座に資産（５０００円）が移転され、台帳Ｆａにおいて、保留されている決済のトランザクション（以下、「保留決済」という。）の情報が管理される。保留決済には、利用者と提供者との間で予め了解されている決済条件（ポリシー）が関連付けられる。その後、サービスの提供状況に応じた決済条件にしたがって、資産の移動が行われる。例えば、正常にサービスが提供されれば、（２）に示されているように、保留決済に係る資産（５０００円）が、提供者の口座Ｂへ移転される。

このように、決済に係るトランザクションの保留は、保留口座に仮想通貨を移動させることで実現される。保留口座の有無の違いは次のようになる。

図２は、保留口座が無い場合の仮想通貨台帳の変化の例を示す図である。図２に示されるように、保留口座が無い場合、口座Ａから口座Ｂへ５０００円が送金されると、口座Ａから５０００円が減額され、口座Ｂに５０００円が増額される。

一方、図３は、保留口座が有る場合の仮想通貨台帳の変化の例を示す図である。図３に示されるように、保留口座が有る場合、まず、口座Ａから５０００円が減額され、保留決済を管理する台帳に、「保留金額」が５０００円である新たなエントリが追加される。決済後には、当該「保留金額」が０に減額され、口座Ｂに５０００円が増額される。

このように、決済の保留は、口座の残高管理から仮想通貨を保留口座に移すことにより、決済予定金を担保として扱うことを可能にする。

以下において、上記のような仕組みを実現するためのシステムの一例について具体的に説明する。

図４は、本発明の実施の形態におけるシステム構成例を示す図である。図４において、１以上の利用者端末２０は、移動体網又は無線ＬＡＮ（Local Area Network）等を介して予約システム４０に接続される。提供者端末３０は、移動体網、無線ＬＡＮ、又はインターネット等を介して予約システム４０に接続される。予約システム４０は、インターネット等を介してブロックチェーンＢＣのいずれかのノード１０に接続される。

利用者端末２０は、利用者が利用する端末である。例えば、スマートフォン、タブレット端末又は携帯電話等が利用者端末２０として利用されてもよい。

提供者端末３０は、提供者が利用する端末である。例えば、スマートフォン、タブレット端末若しくは携帯電話、又はＰＣ（Personal Computer）若しくはＰＯＳ（Point Of Sales system）端末等が提供者端末３０として利用されてもよい。なお、以下の説明において、提供者は、レストランＲ１であるとする。

予約システム４０は、サービスの予約やキャンセル等をオンラインで受け付けるコンピュータシステムである。予約システム４０は、レストランＲ１に専用のシステム（例えば、レストランＲ１のホームページ等）であってもよいし、他のサービスと共用されるシステムであってもよい。

ブロックチェーンＢＣは、いわゆる分散型ネットワークとしてのブロックチェーンである。ブロックチェーンＢＣでは、トランザクションの履歴の台帳を管理する複数のノード１０としてのコンピュータが、相互にＰ２Ｐで通信可能なように接続される。ブロックチェーンＢＣは、図１～図３において説明したような決済の保留や、ポリシーに従った決済を可能とするために拡張が行われている。

なお、利用者及び提供者からは予約システム４０が操作され、利用者及び提供者にはブロックチェーンＢＣの存在は意識されない。

図５は、本発明の実施の形態におけるブロックチェーンＢＣを構成する各ノード１０のハードウェア構成例を示す図である。図５に示されるように、ノード１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

ノード１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってノード１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

なお、記録媒体１０１の一例としては、ＣＤ－ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び補助記憶装置１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。

図６は、本発明の実施の形態における利用者端末２０、提供者端末３０及びブロックチェーンＢＣの各ノード１０の機能構成例を示す図である。

図６において、利用者端末２０は、予約要求部２１、決済破棄部２２、利用者署名部２３及び位置情報取得部２４等を有する。これら各部は、利用者端末２０にインストールされた１以上のプログラムが、利用者端末２０のＣＰＵに実行させる処理により実現される。

予約要求部２１は、サービスの予約の要求（サービスの利用要求）を予約システム４０に送信する。予約要求部２１は、サービスの予約の際、サービスの決済に関する情報（決済情報）や、当該決済のポリシー（決済ポリシー）等を予約システム４０に送信する。

決済破棄部２２は、利用者が事前に予約をキャンセルする場合や、提供者によってサービスが提供されなかった場合に、キャンセル要求を予約システム４０へ送信する。

利用者署名部２３は、決済情報及び決済ポリシーや、サービスのキャンセルの際に予約システム４０に送信される情報等に対して、利用者の秘密鍵を利用して利用者の署名を付与する。

位置情報取得部２４は、例えば、利用者端末２０のＧＰＳ（Global Positioning System）機能等を利用して、利用者端末２０の位置情報を取得する。

提供者端末３０は、決済要求部３１、決済破棄部３２及び提供者署名部３３等を有する。これら各部は、提供者端末３０にインストールされた１以上のプログラムが、提供者端末３０のＣＰＵに実行させる処理により実現される。

決済要求部３１は、サービスが正常に提供された際に、予約システム４０に対して決済の実行を要求する。

決済破棄部３２は、提供者が事前にキャンセルする場合や利用者が無断でキャンセルした場合に、サービスのキャンセルを予約システム４０に要求する。

提供者署名部３３は、サービスの決済の要求やサービスのキャンセルの要求に際して予約システム４０に送信される情報に対して、提供者の秘密鍵を利用して提供者の署名を付与する。

各ノード１０は、決済ポリシー制御部１１、署名検証部１２、ポリシー判定部１３及び仮想通貨制御部１４等を有する。これら各部は、各ノード１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。各ノード１０は、また、ポリシー台帳１２１及び仮想通貨台帳１２２等の記憶部を利用する。これら各記憶部は、例えば、補助記憶装置１０２、又は各ノード１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

決済ポリシー制御部１１は、予約システム４０からのサービスの予約、決済又はキャンセルに関する要求に応じた処理を制御する。サービスの決済及びキャンセルに関して、決済ポリシー制御部１１は、当該サービスの予約時に指定された決済ポリシーに従って決済を制御する。なお、決済ポリシー制御部１１は、スマートコントラクトを用いて実現されてもよい。

署名検証部１２は、決済ポリシー制御部１１が受信する情報に付与されている署名を検証する。

ポリシー判定部１３は、サービスの決済又はキャンセルの際に、当該サービスの決済ポリシーに基づいて、決済に係る支払を実行するか否かや、決済方法等を判定する。

仮想通貨制御部１４は、サービスの予約、決済及びキャンセル時における仮想通貨の移動に関するトランザクションを仮想通貨台帳１２２に登録する。なお、サービスの予約時の仮想通貨の移動とは、利用者の口座から利用者の保留口座への決済金額の移動である。

ポリシー台帳１２１は、サービスの予約ごとの決済ポリシーを記憶するブロックチェーンの台帳である。

仮想通貨台帳１２２は、サービスの予約、決済及びキャンセルに関するトランザクションを記憶するブロックチェーンの台帳である。

なお、本実施の形態では、ポリシー台帳１２１と仮想通貨台帳１２２とが区別されているが、ポリシー台帳１２１及び仮想通貨台帳１２２は、一つの台帳を用いて実現されてもよい。

図７は、本実施の形態において実行される各処理の関係を説明するためのフローチャートである。

まず、レストランＲ１の予約（レストランＲ１の利用要求）に関してサービス予約処理が実行される（Ｓ１）。当該予約は、利用者端末２０が利用されて予約システム４０にアクセスすることで行われる。当該予約時に、サービス提供時に仮想通貨でサービス代を払う手続きや、キャンセル時の決済条件を示す決済ポリシーが定義される。なお、サービス代の決済（に係るトランザクション）は保留される。

サービスについて利用者及び提供者のいずれによっても事前にキャンセルが行われず、正常にサービスの提供が行われると（すなわち、利用者が予定通りレストランＲ１で食事を行うと）、通常決済処理が実行される（Ｓ２）。この際、利用者は、サービスを受けたことを証明する電子情報（以下、「享受情報」という。）を利用者端末２０から提供者端末３０へ送信する。提供者端末３０は、享受情報に提供者の署名を付与して当該享受情報を予約システム４０へ送信する。当該享受情報に基づいて、ブロックチェーンＢＣ上において保留決済の保留が解除され、提供者に対してサービス代としての仮想通貨が支払われる。

一方、利用者が予約を事前にキャンセルした場合、利用者事前キャンセル時の決済処理が実行される（Ｓ３）。この場合、予約時に決済ポリシーで定義されたキャンセル代が保留決済から提供者に支払われる。

利用者が無断でキャンセルした場合、利用者無断キャンセル時の決済処理が実行される（Ｓ４）。この場合も、予約時に決済ポリシーで定義されたキャンセル代が保留決済から提供者に支払われる。

また、提供者が事前にキャンセルした場合、提供者事前キャンセル時の決済処理が実行される（Ｓ５）。この場合、保留決済に係るサービス代が、利用者に払い戻される。

更に、提供者が無断でキャンセルした場合（例えば、提供者が存在せずサービスが提供されない場合）、利用者は、レストランＲ１が存在する位置（又はレストランＲ１が存在するとされていた位置）の近辺で、サービスが受けられなかったことを予約システム４０に通知する。その結果、保留決済に係るサービス代が、利用者に払い戻される。

以下、Ｓ１～Ｓ６のそれぞれの処理について詳細に説明する。まず、ステップＳ１の詳細について説明する。

図８は、サービス予約処理の処理手順の一例を説明するためのシーケンス図である。

まず、提供者による操作に応じ、提供者端末３０から予約システム４０に対し、サービス情報が登録される（Ｓ１０１）。サービス情報は、サービスの内容やサービスの予約に関する契約内容を含む情報である。例えば、予約をキャンセルした場合の条件（前日まで無料、当日以降３０００円等）が含まれる。

その後、レストランＲ１を予約しようとする利用者による操作に応じ、利用者端末２０の予約要求部２１が、サービス情報の提供を予約システム４０に要求すると（Ｓ１０２）、予約システム４０はサービス情報を含む予約画面を返信する（Ｓ１０３）。利用者端末２０は、当該予約画面を表示する。

利用者は、当該予約画面を介して予約操作を行う。この際、予約の日時等が入力される。また、利用者は、サービス情報に含まれる、キャンセルした場合の条件等の確認を行う。利用者によって、予約の実行が指示されると、予約要求部２１は、図９に示される決済情報及び図１０に示される決済ポリシーを生成すると共に、当該決済情報及び当該決済ポリシーを含む予約要求を予約システム４０に送信する（Ｓ１０４）。

図９は、予約時における決済情報の一例を示す図である。図９において、決済情報は、決済ＩＤ、利用者名、提供者名、決済金額、状態、ポリシーＩＤ及び利用者登録署名等を含む。決済ＩＤは、各決済（各予約）の識別情報である。利用者名は、利用者の名前である。提供者名は、提供者の名前である。決済金額は、利用者が選択したサービスの料金である。状態は、当該決済情報に係る決済の状態である。「保留中」は、決済が保留中であることを示す。ポリシーＩＤは、当該決済に対して適用される決済ポリシーのポリシーＩＤである。ポリシーＩＤによって、当該決済情報と決済ポリシーとが関連付けられる。利用者登録署名は、利用者の署名（電子署名）である。

このうち、利用者名及び決済金額は、利用者による予約画面に対する入力情報から取得される。提供者名は、サービス情報から取得される。決済ＩＤ及びポリシーＩＤは、予約要求部２１によって自動的に生成される。利用者登録署名は、利用者による予約の実行指示に応じて、利用者署名部２３が決済情報に対して付与する。

また、図１０は、予約時における決済ポリシーの一例を示す図である。図１０において、決済ポリシーは、ポリシーＩＤ、利用者名、提供者名、決済金額、決済ＩＤ、決済条件、サービス提供日時、サービス提供場所、利用者キャンセル条件、利用者無断キャンセル条件、提供者キャンセル条件、提供者無断キャンセル条件、及び利用者署名等を含む。

ポリシーＩＤは、当該決済ポリシーの識別情報である。利用者名、提供者名、決済金額は、決済情報に関して説明した通りである。決済ＩＤは、当該決済ポリシーが適用される決済情報の決済ＩＤである。決済条件は、決済ＩＤに係る決済が実行されるための条件であり、“利用者の署名”は、利用者による署名が決済の条件であることを示す。サービス提供日時は、サービスが提供される日時であり、利用者による予約内容に基づいて特定される。サービス提供場所は、サービスが提供される場所（すなわち、レストランＲ１の場所）であり、サービス情報から取得される。

利用者キャンセル条件は、利用者による事前キャンセルが発生した場合の決済の条件である。利用者無断キャンセル条件は、利用者による無断キャンセルが発生した場合の決済の条件である。提供者キャンセル条件は、提供者による事前キャンセルが発生した場合の決済の条件である。提供者無断キャンセル条件は、提供者による無断キャンセルが発生した場合の決済の条件である。図１０では、サービス提供日時にサービス提供場所からの要求が有れば、全額返済されることが当該条件として示されている。すなわち、利用者が実際にレストランＲ１に行くことが要件とされている。なお、これら各キャンセル条件は、サービス情報から取得される。利用者署名は、サービス情報の内容を確認した利用者による了承を示す入力に応じて、利用者署名部２３が決済ポリシーに付与する利用者の署名である。

予約システム４０は、予約要求を受信すると、当該予約要求を提供者端末３０へ転送する（Ｓ１０５）。提供者端末３０の提供者署名部３３は、当該予約要求に含まれている決済情報に提供者の署名を付与する（Ｓ１０６）。なお、当該署名の付与は、例えば、提供者端末３０において当該決済情報の内容が表示された状態において、提供者によって予約を了承する旨の入力が行われた場合に実行されるようにしてもよい。

図１１は、提供者の署名の付与後の決済情報の一例を示す図である。図１１における決済情報は、図１０に示した決済情報に対して提供者登録署名が追加されている。

続いて、提供者端末３０は、提供者の署名が付与された決済情報を含む予約要求を予約システム４０へ送信する（Ｓ１０７）。予約システム４０は、当該予約要求を受信すると、当該予約要求に含まれている決済情報及び決済ポリシーの登録要求（サービスの利用要求）を、ブロックチェーンＢＣのノード１０の決済ポリシー制御部１１に送信する（Ｓ１０８）。

決済ポリシー制御部１１は、当該登録要求に応じ、当該登録要求に含まれている決済情報及び決済ポリシーのそれぞれに付与されている署名の検証を署名検証部１２へ要求する（Ｓ１０９）。署名検証部１２は、当該決済情報（図１０）に付与されている利用者登録署名及び提供者登録署名のそれぞれと、当該決済ポリシーに付与されている利用者署名とを検証し、検証結果を決済ポリシー制御部１１に応答する（Ｓ１１０）。当該検証結果が、各署名が正しいことを示す場合、ステップＳ１１１以降が実行され、それ以外の場合、ステップＳ１１１～Ｓ１１４は実行されない。

ステップＳ１１１において、決済ポリシー制御部１１は、決済ポリシーの登録をポリシー判定部１３に要求する。ポリシー判定部１３は、当該決済ポリシーについて論理矛盾等の問題の有無を確認し、問題が無ければ、当該決済ポリシーをポリシー台帳１２１に登録（記録）して（Ｓ１１２）、問題が無いことを示す応答を決済ポリシー制御部１１に返信する（Ｓ１１３）。一方、問題が有る場合、ポリシー判定部１３は、当該決済ポリシーをポリシー台帳１２１へは登録せずに、問題が有ることを示す応答を決済ポリシー制御部１１に返信する（Ｓ１１３）。

ポリシー判定部１３からの応答が、問題が無いことを示す場合、決済ポリシー制御部１１は、決済情報の決済金額を、当該決済情報の利用者の口座から当該利用者の保留口座へ移動させるためのトランザクションを仮想通貨制御部１４へ発行する（Ｓ１１４）。仮想通貨制御部１４は、当該トランザクションを仮想通貨台帳１２２に登録（記録）すると共に、当該決済金額を、利用者の口座から保留口座へ移動する。すなわち、当該決済金額に係る決済の保留を示す情報が、仮想通貨台帳１２２に記録される。なお、当該決済情報は、仮想通貨台帳１２２とは別の書き換え可能な記憶領域に記憶される。

続いて、決済ポリシー制御部１１は、決済情報及び決済ポリシーの登録結果を示す応答を予約システム４０に返信する（Ｓ１１５）。当該応答は、ステップＳ１１４が正常に実行された場合は、登録の成功を示す情報であり、ステップＳ１１４が実行されなかった場合は、登録の失敗を示す情報である。

続いて、予約システム４０は、予約結果を示す応答を利用者端末２０へ返信する（Ｓ１１６）。当該応答は、ステップＳ１１５における登録結果が登録の成功を示す場合には、予約の成功を示す情報であり、当該登録結果が登録の失敗を示す場合には、予約の失敗を示す情報である。

なお、図８の処理により、予約と並行してサービス代の領収を提供者に対して担保することができる。

続いて、図７のステップＳ２の詳細について説明する。図１２は、通常決済処理の処理手順の一例を説明するためのシーケンス図である。図１２の処理手順は、例えば、利用者がレストランＲ１において食事をした後に実行される。

例えば、利用者端末２０が予約システム４０にアクセスすることで表示される、サービスが正常に享受したことを受け付ける画面に対して、利用者が了解を示す操作を行うと、利用者端末２０の利用者署名部２３は、享受情報に対して利用者の署名を付与する（Ｓ２０１）。当該享受情報には、例えば、図９に示した決済ＩＤが含まれていればよい。

続いて、利用者端末２０は、当該享受情報を提供者端末３０に送信する（Ｓ２０２）。例えば、利用者端末２０が、当該享受情報をＱＲコード（登録商標）に変換して当該ＱＲコード（登録商標）を表示し、提供者端末３０が、当該ＱＲコード（登録商標）を読み取ることで、当該享受情報が提供者端末３０に送信されてもよい。又は、近距離無線通信等、利用者と提供者とが対面している場合に利用可能な通信手段を利用して、当該享受情報が利用者端末２０から提供者端末３０へ送信されてもよい。

続いて、提供者端末３０の提供者署名部３３は、当該享受情報に対して提供者の署名を付与する（Ｓ２０３）。続いて、提供者端末３０の決済要求部３１は、当該享受情報を含む決済要求を予約システム４０へ送信する（Ｓ２０４）。予約システム４０は、当該決済要求を受信すると、当該決済要求に含まれている享受情報を含む決済要求を、ブロックチェーンＢＣのノード１０の決済ポリシー制御部１１へ送信する（Ｓ２０５）。

決済ポリシー制御部１１は、当該決済要求に応じ、当該決済要求に含まれている享受情報に付与されている署名の検証を署名検証部１２へ要求する（Ｓ２０６）。署名検証部１２は、当該享受情報に付与されている利用者の署名及び提供者の署名のそれぞれを検証し、検証結果を決済ポリシー制御部１１に応答する（Ｓ２０７）。当該検証結果が、各署名が正しいことを示す場合、ステップＳ２０８以降が実行され、それ以外の場合、ステップＳ２０８～Ｓ２１０は実行されない。

ステップＳ２０８において、決済ポリシー制御部１１は、当該享受情報に対応する決済ポリシーに基づく決済の実行の判定（決済を実行するか否かの判定）をポリシー判定部１３に要求する。ポリシー判定部１３は、ポリシー台帳１２１に格納されている決済ポリシーのうち、当該享受情報に含まれている決済ＩＤを含む決済ポリシーに基づいて判定を行い、判定結果を示す応答を決済ポリシー制御部１１に返信する（Ｓ２０９）。例えば、決済ポリシー制御部１１は、決済ポリシー（図１０）の決済条件が満たされていることが確認され（図１０の例によれば、当該享受情報に利用者の署名が付与されていることが確認され）、当該決済条件が満たされている場合には、当該決済ポリシーの決済金額を、利用者の保留口座から提供者の口座に移動することを判定する。決済ポリシー制御部１１は、斯かる判定結果を示す応答を決済ポリシー制御部１１に返信する。

続いて、決済ポリシー制御部１１は、当該判定結果に従って、当該決済金額を利用者の保留口座から提供者の口座に移動させるためのトランザクションを仮想通貨制御部１４へ発行する（Ｓ２１０）。仮想通貨制御部１４は、当該トランザクションを仮想通貨台帳１２２に登録すると共に、当該決済金額を利用者の保留口座から提供者の口座に移動させる。すなわち、この場合、決済金額の全額が支払われる。

続いて、決済ポリシー制御部１１は、決済結果を予約システム４０に返信する（Ｓ２１１）。当該決済結果は、ステップＳ２１０が正常に実行された場合には決済の成功を示し、ステップＳ２１０が実行されなかった場合には決済の失敗を示す情報である。予約システム４０は、当該決済結果を提供者端末３０へ送信する（Ｓ２１２）。なお、決済ポリシー制御部１１は、決済の成功を示す決済結果を応答する場合、書き換え可能な状態で記憶されている決済情報（図９）の「状態」を決済済みに更新した後で、当該応答を行う。

続いて、図７のステップＳ３の詳細について説明する。図１３は、利用者事前キャンセル時の決済処理の処理手順の一例を説明するためのシーケンス図である。

例えば、予約システム４０に対するキャンセル要求に応じて利用者端末２０に表示されるキャンセル画面において、図９の決済情報に係るサービスの予約についてキャンセルの指示が入力されると、利用者署名部２３は、当該決済情報の決済ＩＤを含み、キャンセルを示す情報であるキャンセル情報に対して利用者の署名を付与する（Ｓ３０１）。続いて、決済破棄部２２は、当該キャンセル情報を含むキャンセル要求を予約システム４０へ送信する（Ｓ３０２）。

続いて、予約システム４０は、当該キャンセル情報を含むキャンセル要求を、ブロックチェーンＢＣのノード１０の決済ポリシー制御部１１へ送信する（Ｓ３０３）。続いて、決済ポリシー制御部１１は、当該キャンセル要求に含まれているキャンセル情報に付与されている署名の検証を署名検証部１２へ要求する（Ｓ３０４）。署名検証部１２は、当該キャンセル情報に付与されている利用者の署名を検証し、検証結果を決済ポリシー制御部１１に応答する（Ｓ３０５）。当該検証結果が、当該署名が正しいことを示す場合、ステップＳ３０６以降が実行され、それ以外の場合、ステップＳ３０６～Ｓ３０８は実行されない。

ステップＳ３０６において、決済ポリシー制御部１１は、当該キャンセル情報に対応する決済ポリシーに基づく決済の判定をポリシー判定部１３に要求する。ポリシー判定部１３は、ポリシー台帳１２１に格納されている決済ポリシーのうち、当該キャンセル情報に含まれている決済ＩＤを含む決済ポリシーに基づいて決済の実行の判定を行い、判定結果を示す応答を決済ポリシー制御部１１に返信する（Ｓ３０７）。当該判定結果には、当該決済ポリシーの利用者キャンセル条件に従った決済の内容（決済金額の分配方法）が含まれる。例えば、当該決済条件が図１０に示す通りであり、現在日時がサービス提供日の前日までであれば、利用者の保留口座から利用者の口座へ決済金額を移動することを示す情報が当該判定結果に含まれる。一方、現在日時がサービス提供日以降であれば、利用者の保留口座から提供者の口座へ３０００円を移動することを示す情報が当該判定結果に含まれる。

続いて、決済ポリシー制御部１１は、当該判定結果に従ったトランザクションを仮想通貨制御部１４へ発行する（Ｓ３０８）。仮想通貨制御部１４は、当該トランザクションを仮想通貨台帳１２２に登録すると共に、当該トランザクションに従って、利用者の保留口座から決済金額を移動する。すなわち、当該決済金額が、決済ポリシーに基づいて利用者及び提供者に分配される。

続いて、決済ポリシー制御部１１は、キャンセル結果を示す応答を予約システム４０に返信する（Ｓ３０９）。当該キャンセル結果は、ステップＳ３０８が正常に実行された場合にはキャンセルの成功を示す情報であり、ステップＳ３０８が実行されなかった場合にはキャンセルの失敗を示す情報である。なお、決済ポリシー制御部１１は、キャンセルの成功を示すキャンセル結果を応答する場合、書き換え可能な状態で記憶されている決済情報（図９）の「状態」を決済済みに更新した後で、当該応答を行う。

続いて、予約システム４０は、当該キャンセル結果を利用者端末２０に返信する（Ｓ３１０）。また、キャンセルが成功した場合、予約システム４０は、当該キャンセル結果を提供者端末３０に送信する（Ｓ３１１）。

続いて、図７のステップＳ４の詳細について説明する。図１４は、利用者無断キャンセル時の決済処理の処理手順の一例を説明するためのシーケンス図である。

例えば、サービス提供日に利用者が事前キャンセルもせずに来店しなかった場合、予約システム４０に対する無断キャンセル要求に応じて提供者端末３０に表示される無断キャンセル画面において、図９の決済情報に係るサービスについて無断キャンセルを示す入力が提供者によって行われると、提供者署名部３３は、当該決済情報の決済ＩＤを含み、無断キャンセルを示す情報である無断キャンセル情報に対して提供者の署名を付与する（Ｓ４０１）。続いて、決済破棄部３２は、当該無断キャンセル情報を予約システム４０へ送信する（Ｓ４０２）。

続いて、予約システム４０は、当該無断キャンセル情報を、ブロックチェーンＢＣのノード１０の決済ポリシー制御部１１へ送信する（Ｓ４０３）。続いて、決済ポリシー制御部１１は、当該無断キャンセル情報に付与されている署名の検証を署名検証部１２へ要求する（Ｓ４０４）。署名検証部１２は、当該無断キャンセル情報に付与されている提供者の署名を検証し、検証結果を決済ポリシー制御部１１に応答する（Ｓ４０５）。当該検証結果が、当該署名が正しいことを示す場合、ステップＳ４０６以降が実行され、それ以外の場合、ステップＳ４０６～Ｓ４０８は実行されない。

ステップＳ４０６において、決済ポリシー制御部１１は、当該無断キャンセル情報に対応する決済ポリシーに基づく決済の判定をポリシー判定部１３に要求する。ポリシー判定部１３は、ポリシー台帳１２１に格納されている決済ポリシーのうち、当該無断キャンセル情報に含まれている決済ＩＤを含む決済ポリシーに基づいて決済の実行の判定を行い、判定結果を示す応答を決済ポリシー制御部１１に返信する（Ｓ４０７）。例えば、現在日時が当該決済ポリシーの「サービス提供日時」を経過していれば、当該判定結果には、当該決済ポリシーの利用者無断キャンセル条件に応じた決済金額の移動を示す情報が含まれる。例えば、当該決済条件が図１０に示す通りであれば、決済金額の全額を利用者の保留口座から提供者の口座へ移動することを示す情報が当該判定結果に含まれる。一方、現在日時が当該決済ポリシーの「サービス提供日時」を経過していない場合、この時点では無断キャンセルが発生したとは断定できない。したがって、この場合、決済金額の移動を行わないことを示す情報が当該判定結果に含まれる。決済金額の移動を行わないことを示す情報が当該判定結果に含まれる場合、ステップＳ４０８は実行されない。

続いて、決済ポリシー制御部１１は、当該判定結果に従ったトランザクションを仮想通貨制御部１４へ発行する（Ｓ４０８）。仮想通貨制御部１４は、当該トランザクションを仮想通貨台帳１２２に登録すると共に、当該トランザクションに従って、決済金額の全額を利用者の保留口座から提供者の口座へ移動する。すなわち、当該決済金額の全額が支払われる。当該トランザクションが仮想通貨台帳１２２に登録されることで、利用者は評判を落とす（信頼を失う）ことになる。

続いて、決済ポリシー制御部１１は、無断キャンセル結果を示す応答を予約システム４０に返信する（Ｓ４０９）。当該無断キャンセル結果は、ステップＳ４０８が正常に実行された場合には無断キャンセルの成功を示す情報であり、ステップＳ４０８が実行されなかった場合には無断キャンセルの失敗を示す情報である。なお、決済ポリシー制御部１１は、無断キャンセルの成功を示す無断キャンセル結果を応答する場合、書き換え可能な状態で記憶されている決済情報（図９）の「状態」を決済済みに更新した後で、当該応答を行う。

続いて、予約システム４０は、当該無断キャンセル結果を提供者端末３０に返信する（Ｓ４１０）。また、無断キャンセルが成功した場合、予約システム４０は、当該無断キャンセル結果を利用者端末２０に送信する（Ｓ４１１）。

図１４の処理は、無断キャンセルされた場合の救済処理である。この処理では、担保されていたサービス代が解放され、保留状態の仮想通貨は決済ポリシーに従い分配される。

続いて、図７のステップＳ５の詳細について説明する。図１５は、提供者事前キャンセル時の決済処理の処理手順の一例を説明するためのシーケンス図である。

例えば、提供者が何らかの理由でサービスを提供できないため事前にサービスの提供をキャンセルする場合、提供者は、予約システム４０に対するキャンセル要求に応じて提供者端末３０に表示されるキャンセル画面において、図９の決済情報に係るサービスについてキャンセルの指示を提供者端末３０に入力する。当該指示に応じ、提供者署名部３３は、当該決済情報の決済ＩＤを含み、提供者によるキャンセルを示す情報である提供者キャンセル情報に対して提供者の署名を付与する（Ｓ５０１）。続いて、決済破棄部３２は、当該提供者キャンセル情報を含むキャンセル要求を予約システム４０へ送信する（Ｓ５０２）。

続いて、予約システム４０は、当該提供者キャンセル情報を含むキャンセル要求を、ブロックチェーンＢＣのノード１０の決済ポリシー制御部１１へ送信する（Ｓ５０３）。続いて、決済ポリシー制御部１１は、当該キャンセル要求に含まれている提供者キャンセル情報に付与されている署名の検証を署名検証部１２へ要求する（Ｓ５０４）。署名検証部１２は、当該提供者キャンセル情報に付与されている提供者の署名を検証し、検証結果を決済ポリシー制御部１１に応答する（Ｓ５０５）。当該検証結果が、当該署名が正しいことを示す場合、ステップＳ５０６以降が実行され、それ以外の場合、ステップＳ５０６～Ｓ５０８は実行されない。

ステップＳ５０６において、決済ポリシー制御部１１は、当該提供者キャンセル情報に対応する決済ポリシーに基づく決済の判定をポリシー判定部１３に要求する。ポリシー判定部１３は、ポリシー台帳１２１に格納されている決済ポリシーのうち、当該提供者キャンセル情報に含まれている決済ＩＤを含む決済ポリシーに基づいて決済の実行の判定を行い、判定結果を示す応答を決済ポリシー制御部１１に返信する（Ｓ５０７）。当該判定結果には、当該決済ポリシーの提供者キャンセル条件に応じた決済金額の移動を示す情報が含まれる。例えば、当該決済条件が図１０に示す通りであれば、決済金額の全額を利用者の保留口座から利用者の口座へ移動することを示す情報が当該判定結果に含まれる。

続いて、決済ポリシー制御部１１は、当該判定結果に従ったトランザクションを仮想通貨制御部１４へ発行する（Ｓ５０８）。仮想通貨制御部１４は、当該トランザクションを仮想通貨台帳１２２に登録すると共に、当該トランザクションに従って、決済金額の全額を利用者の保留口座から利用者の口座へ移動する。すなわち、この場合、決済金額の支払が行われない。

続いて、決済ポリシー制御部１１は、キャンセル結果を示す応答を予約システム４０に返信する（Ｓ５０９）。当該キャンセル結果は、ステップＳ５０８が正常に実行された場合にはキャンセルの成功を示す情報であり、ステップＳ５０８が実行されなかった場合にはキャンセルの失敗を示す情報である。なお、決済ポリシー制御部１１は、キャンセルの成功を示すキャンセル結果を応答する場合、書き換え可能な状態で記憶されている決済情報（図９）の「状態」を決済済みに更新した後で、当該応答を行う。

続いて、予約システム４０は、当該キャンセル結果を提供者端末３０に返信する（Ｓ５１０）。また、キャンセルが成功した場合、予約システム４０は、提供者キャンセル情報を含むキャンセルの通知を利用者端末２０に送信する（Ｓ５１１）。

図１５の処理は、提供者がサービスを提供できない場合の救済処理である。この場合、担保されていたサービス代が決済ポリシーに従い分配される。

続いて、図７のステップＳ６の詳細について説明する。図１６は、提供者無断キャンセル時の決済処理の処理手順の一例を説明するためのシーケンス図である。

例えば、利用者がサービスの提供場所（レストランＲ１）に予定通りに赴いたが、サービスの提供を受けられなかった場合（例えば、レストランＲ１が存在しなかった場合等）、利用者は、その場で、予約システム４０に対する提供者無断キャンセル要求に応じて利用者端末２０に表示される提供者無断キャンセル画面において、図９の決済情報に係るサービスについて提供者無断キャンセルの指示を入力する。当該指示に応じ、位置情報取得部２４は、利用者端末２０の現在位置の位置情報（例えば、緯度及び経度）を取得する（Ｓ６０１）。なお、利用者は、利用者端末２０を携帯しているという前提である。

続いて、利用者署名部２３は、当該決済情報の決済ＩＤと、現在日時と、当該位置情報とを含み、提供者による無断キャンセルを示す情報である提供者無断キャンセル情報に対して利用者の署名を付与する（Ｓ６０２）。続いて、決済破棄部２２は、当該提供者無断キャンセル情報を予約システム４０へ送信する（Ｓ６０３）。

続いて、予約システム４０は、当該提供者無断キャンセル情報を、ブロックチェーンＢＣのノード１０の決済ポリシー制御部１１へ送信する（Ｓ６０４）。続いて、決済ポリシー制御部１１は、当該提供者無断キャンセル情報に付与されている署名の検証を署名検証部１２へ要求する（Ｓ６０５）。署名検証部１２は、当該提供者無断キャンセル情報に付与されている利用者の署名を検証し、検証結果を決済ポリシー制御部１１に応答する（Ｓ６０６）。当該検証結果が、当該署名が正しいことを示す場合、ステップＳ６０７以降が実行され、それ以外の場合、ステップＳ６０７～Ｓ６０９は実行されない。

ステップＳ６０７において、決済ポリシー制御部１１は、当該提供者無断キャンセル情報に対応する決済ポリシーに基づく決済の判定をポリシー判定部１３に要求する。ポリシー判定部１３は、ポリシー台帳１２１に格納されている決済ポリシーのうち、当該提供者無断キャンセル情報に含まれている決済ＩＤを含む決済ポリシーに基づいて決済の実行の判定を行い、判定結果を示す応答を決済ポリシー制御部１１に返信する（Ｓ６０８）。例えば、図１０の決済ポリシーによれば、当該決済ポリシーの提供者無断キャンセル条件について確認が行われる。すなわち、当該提供者無断キャンセル情報に含まれている現在日時が、当該決済ポリシーの「サービス提供日時」から所定の範囲内（当該サービス提供日時より前の時点も含む。）であり、当該提供者無断キャンセル情報に含まれている位置情報が、当該決済ポリシーの「サービス提供場所」から所定の範囲内であれば、利用者の保留口座から決済金額の全額を利用者の口座へ移動することを示す情報が判定結果として応答される。

続いて、決済ポリシー制御部１１は、当該判定結果に従ったトランザクションを仮想通貨制御部１４へ発行する（Ｓ６０９）。仮想通貨制御部１４は、当該トランザクションを仮想通貨台帳１２２に登録すると共に、当該トランザクションに従って、決済金額の全額を利用者の保留口座から利用者の口座へ移動する。すなわち、この場合、決済金額の支払は行われない。

続いて、決済ポリシー制御部１１は、キャンセル結果を示す応答を予約システム４０に返信する（Ｓ６１０）。当該キャンセル結果は、ステップＳ６０９が正常に実行された場合にはキャンセルの成功を示す情報であり、ステップＳ６０９が実行されなかった場合にはキャンセルの失敗を示す情報である。なお、決済ポリシー制御部１１は、キャンセルの成功を示すキャンセル結果を応答する場合、書き換え可能な状態で記憶されている決済情報（図９）の「状態」を決済済みに更新した後で、当該応答を行う。

続いて、予約システム４０は、当該キャンセル結果を利用者端末２０に返信する（Ｓ６１１）。また、キャンセルが成功した場合、予約システム４０は、当該キャンセル結果を提供者端末３０に送信する（Ｓ６１２）。

図１６の処理は、サービスが架空で、提供者が最初からサービスを提供する気がなかった場合の救済処理である。この場合、担保されていたサービス代が決済ポリシーに従い利用者に戻される。

なお、仮想通貨台帳１２２に蓄積された情報（トランザクション）を活用して、架空のサービスの防止や、利用者による無断キャンセルの防止が図られてもよい。例えば、利用者による無断キャンセルに基づくトランザクションが記録されている利用者については、予約システム４０を利用した予約が制限されるようにしてもよい。また、提供者による無断キャンセルに基づくトランザクションが記録されている提供者については、予約システム４０を利用して予約できなくなるようにしてもよい。

なお、悪意の有る提供者が、ステップＳ６（図１６）の処理が実行されないようにするために、ステップＳ４（図１４）（利用者による無断キャンセル）を実行することが考えられる。但し、ステップＳ６（提供者による無断キャンセル）との競合は、以下のように回避可能である。

上記したように、利用者無断キャンセルは、サービス提供日時が経過した場合に成功する。一方、提供者無断キャンセルは、サービス提供日時の経過前に成功しうる。すなわち、提供者無断キャンセルの方が、時期的に前のタイミングで成功条件が満たされる。したがって、利用者がレストランＲ１に予定通り到着し、利用者端末２０から提供者無断キャンセル情報を送信していれば、その後に、悪意の有る提供者が利用者無断キャンセル情報を送信したとしても、当該利用者無断キャンセルに基づく処理は失敗する。

上述したように、本実施の形態によれば、サービスの予約時において、決済の金額は利用者の保留口座に移動されるため、当該決済が保留されると共に、当該決済に関する決済ポリシーがポリシー台帳１２１に記録される。決済要求が発生した際には、当該決済要求（の原因）と、当該決済ポリシーとに基づいて、当該サービスの利用に関する支払を実行するか否かが判定される。したがって、サービスが正常に提供されるまで、決済が保留されると共に、サービスの提供に異常が発生した場合には、決済ポリシーに基づいて決済が行われる。その結果、取引の信用性を向上させることができる。

なお、本実施の形態において、各ノード１０は、決済装置の一例である。仮想通貨台帳１２２は、第１の台帳の一例である。ポリシー台帳１２１は、第２の台帳の一例である。決済ポリシー制御部１１及び仮想通貨制御部１４は、記録部の一例である。決済ポリシー制御部１１及びポリシー判定部１３は、判定部の一例である。

以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

以上の説明に関し、更に以下の項を開示する。
（付記１）
サービスの利用要求に応じて、前記サービスの利用に関する支払の保留を示す情報をブロックチェーンの第１の台帳に記録し、前記利用要求に含まれる決済条件を前記ブロックチェーンの第２の台帳に記録する記録部と、
前記サービスの決済要求に応じ、当該決済要求と、前記第２の台帳に記録された前記決済条件とに基づいて、前記第１の台帳に記録された前記サービスの利用に関する支払を実行するか否かを判定する判定部と、
を有することを特徴とする決済装置。
（付記２）
前記判定部は、前記決済要求が前記サービスの利用者による無断キャンセルに基づく場合、前記支払を実行すると判定する、
ことを特徴とする付記１記載の決済装置。
（付記３）
前記判定部は、前記決済要求が前記サービスの提供を受けられなかったことに基づく場合、前記支払を実行しないと判定する、
ことを特徴とする付記１又は２記載の決済装置。
（付記４）
前記判定部は、前記決済要求が、前記サービスの利用者による事前のキャンセルに基づく場合、前記決済条件に基づいて、前記支払に係る金額について、前記利用者と前記サービスの提供者とへの分配方法を判定する、
ことを特徴とする付記１乃至３いずれか一項記載の決済装置。
（付記５）
サービスの利用要求に応じて、前記サービスの利用に関する支払の保留を示す情報をブロックチェーンの第１の台帳に記録し、前記利用要求に含まれる決済条件を前記ブロックチェーンの第２の台帳に記録する記録手順と、
前記サービスの決済要求に応じ、当該決済要求と、前記第２の台帳に記録された前記決済条件とに基づいて、前記第１の台帳に記録された前記サービスの利用に関する支払を実行するか否かを判定する判定手順と、
をコンピュータが実行することを特徴とする決済方法。
（付記６）
前記判定手順は、前記決済要求が前記サービスの利用者による無断キャンセルに基づく場合、前記支払を実行すると判定する、
ことを特徴とする付記５記載の決済方法。
（付記７）
前記判定手順は、前記決済要求が前記サービスの提供を受けられなかったことに基づく場合、前記支払を実行しないと判定する、
ことを特徴とする付記５又は６記載の決済方法。
（付記８）
前記判定手順は、前記決済要求が、前記サービスの利用者による事前のキャンセルに基づく場合、前記決済条件に基づいて、前記支払に係る金額について、前記利用者と前記サービスの提供者とへの分配方法を判定する、
ことを特徴とする付記５乃至７いずれか一項記載の決済方法。
（付記９）
サービスの利用要求に応じて、前記サービスの利用に関する支払の保留を示す情報をブロックチェーンの第１の台帳に記録し、前記利用要求に含まれる決済条件を前記ブロックチェーンの第２の台帳に記録する記録手順と、
前記サービスの決済要求に応じ、当該決済要求と、前記第２の台帳に記録された前記決済条件とに基づいて、前記第１の台帳に記録された前記サービスの利用に関する支払を実行するか否かを判定する判定手順と、
をコンピュータに実行させることを特徴とするプログラム。
（付記１０）
前記判定手順は、前記決済要求が前記サービスの利用者による無断キャンセルに基づく場合、前記支払を実行すると判定する、
ことを特徴とする付記９記載のプログラム。
（付記１１）
前記判定手順は、前記決済要求が前記サービスの提供を受けられなかったことに基づく場合、前記支払を実行しないと判定する、
ことを特徴とする付記９又は１０記載のプログラム。
（付記１２）
前記判定手順は、前記決済要求が、前記サービスの利用者による事前のキャンセルに基づく場合、前記決済条件に基づいて、前記支払に係る金額について、前記利用者と前記サービスの提供者とへの分配方法を判定する、
ことを特徴とする付記９乃至１１いずれか一項記載のプログラム。

１０ ノード
１１ 決済ポリシー制御部
１２ 署名検証部
１３ ポリシー判定部
１４ 仮想通貨制御部
２０ 利用者端末
２１ 予約要求部
２２ 決済破棄部
２３ 利用者署名部
２４ 位置情報取得部
３０ 提供者端末
３１ 決済要求部
３２ 決済破棄部
３３ 提供者署名部
４０ 予約システム
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１２１ ポリシー台帳
１２２ 仮想通貨台帳
Ｂ バス
ＢＣ ブロックチェーン

Claims (5)

1. サービスの利用要求に応じて、前記サービスの利用に関する支払の保留を示す情報をブロックチェーンの第１の台帳に記録し、前記利用要求に含まれる決済条件を前記ブロックチェーンの第２の台帳に記録する記録部と、
   前記サービスの決済要求に応じ、当該決済要求と、前記第２の台帳に記録された前記決済条件とに基づいて、前記第１の台帳に記録された前記サービスの利用に関する支払を実行するか否かを判定する判定部と、
   を有し、
   前記判定部は、前記決済要求が前記サービスの提供を受けられなかったことに基づく場合、前記サービスの提供予定の日時の前後の所定の範囲内において、前記サービスの提供を受けられなかった者の位置が前記サービスの提供予定の場所の所定の範囲内であることを示す情報を前記決済要求が含む場合には、前記支払を実行しないと判定する、
   ことを特徴とする決済装置。
2. 前記判定部は、前記決済要求が前記サービスの利用者による無断キャンセルに基づく場合、前記サービスの提供予定の日時を経過していれば、前記支払を実行すると判定する、
   ことを特徴とする請求項１記載の決済装置。
3. 前記判定部は、前記決済要求が、前記サービスの利用者による事前のキャンセルに基づく場合、前記決済条件に基づいて、前記支払に係る金額について、前記利用者と前記サービスの提供者とへの分配方法を判定する、
   ことを特徴とする請求項１又は２記載の決済装置。
4. サービスの利用要求に応じて、前記サービスの利用に関する支払の保留を示す情報をブロックチェーンの第１の台帳に記録し、前記利用要求に含まれる決済条件を前記ブロックチェーンの第２の台帳に記録する記録手順と、
   前記サービスの決済要求に応じ、当該決済要求と、前記第２の台帳に記録された前記決済条件とに基づいて、前記第１の台帳に記録された前記サービスの利用に関する支払を実行するか否かを判定する判定手順と、
   をコンピュータが実行し、
   前記判定手順は、前記決済要求が前記サービスの提供を受けられなかったことに基づく場合、前記サービスの提供予定の日時の前後の所定の範囲内において、前記サービスの提供を受けられなかった者の位置が前記サービスの提供予定の場所の所定の範囲内であることを示す情報を前記決済要求が含む場合には、前記支払を実行しないと判定する、
   ことを特徴とする決済方法。
5. サービスの利用要求に応じて、前記サービスの利用に関する支払の保留を示す情報をブロックチェーンの第１の台帳に記録し、前記利用要求に含まれる決済条件を前記ブロックチェーンの第２の台帳に記録する記録手順と、
   前記サービスの決済要求に応じ、当該決済要求と、前記第２の台帳に記録された前記決済条件とに基づいて、前記第１の台帳に記録された前記サービスの利用に関する支払を実行するか否かを判定する判定手順と、
   をコンピュータに実行させ、
   前記判定手順は、前記決済要求が前記サービスの提供を受けられなかったことに基づく場合、前記サービスの提供予定の日時の前後の所定の範囲内において、前記サービスの提供を受けられなかった者の位置が前記サービスの提供予定の場所の所定の範囲内であることを示す情報を前記決済要求が含む場合には、前記支払を実行しないと判定する、
   ことを特徴とするプログラム。

Images