IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社ジェーシービーの特許一覧 ▶ 合同会社Keychainの特許一覧

特許7266620プログラム、デバイス、コンピュータ、決済システム
<>
  • 特許-プログラム、デバイス、コンピュータ、決済システム 図1
  • 特許-プログラム、デバイス、コンピュータ、決済システム 図2
  • 特許-プログラム、デバイス、コンピュータ、決済システム 図3
  • 特許-プログラム、デバイス、コンピュータ、決済システム 図4
  • 特許-プログラム、デバイス、コンピュータ、決済システム 図5
  • 特許-プログラム、デバイス、コンピュータ、決済システム 図6
  • 特許-プログラム、デバイス、コンピュータ、決済システム 図7
  • 特許-プログラム、デバイス、コンピュータ、決済システム 図8
  • 特許-プログラム、デバイス、コンピュータ、決済システム 図9
  • 特許-プログラム、デバイス、コンピュータ、決済システム 図10
  • 特許-プログラム、デバイス、コンピュータ、決済システム 図11
  • 特許-プログラム、デバイス、コンピュータ、決済システム 図12
  • 特許-プログラム、デバイス、コンピュータ、決済システム 図13
  • 特許-プログラム、デバイス、コンピュータ、決済システム 図14
  • 特許-プログラム、デバイス、コンピュータ、決済システム 図15
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-04-20
(45)【発行日】2023-04-28
(54)【発明の名称】プログラム、デバイス、コンピュータ、決済システム
(51)【国際特許分類】
   G06Q 10/0633 20230101AFI20230421BHJP
   G06Q 20/08 20120101ALI20230421BHJP
【FI】
G06Q10/0633
G06Q20/08
【請求項の数】 18
(21)【出願番号】P 2021000571
(22)【出願日】2021-01-05
(65)【公開番号】P2022105930
(43)【公開日】2022-07-15
【審査請求日】2022-01-11
(73)【特許権者】
【識別番号】593022629
【氏名又は名称】株式会社ジェーシービー
(73)【特許権者】
【識別番号】521008248
【氏名又は名称】合同会社Keychain
(74)【代理人】
【識別番号】100079108
【弁理士】
【氏名又は名称】稲葉 良幸
(74)【代理人】
【識別番号】100109346
【弁理士】
【氏名又は名称】大貫 敏史
(74)【代理人】
【識別番号】100117189
【弁理士】
【氏名又は名称】江口 昭彦
(74)【代理人】
【識別番号】100134120
【弁理士】
【氏名又は名称】内藤 和彦
(72)【発明者】
【氏名】間下 公照
(72)【発明者】
【氏名】南井 享
(72)【発明者】
【氏名】ジョナサン ホープ
【審査官】岡北 有平
(56)【参考文献】
【文献】国際公開第2018/179805(WO,A1)
【文献】特開2016-218861(JP,A)
【文献】特許第6782392(JP,B1)
【文献】特開2002-342515(JP,A)
【文献】特開2011-138301(JP,A)
【文献】米国特許出願公開第2015/0033286(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 - 99/00
(57)【特許請求の範囲】
【請求項1】
第1デバイスに、
前記第1デバイスと通信可能な取引情報記憶部であって、
前記第1デバイスの第1デバイス識別情報と、
前記第1デバイスと通信可能な第2デバイスの第2デバイス識別情報と、
前記第1デバイスと通信可能な第3デバイスのデバイス識別情報と、
前記第1デバイスが承認可能な取引の条件を少なくとも一つ含み、前記第1デバイスで承認可能ではない取引の承認の要求先として前記第3デバイス識別情報を含む、承認情報と、
前記第3デバイスが承認可能な取引の条件を少なくとも一つ含む上位承認情報と、
が記録され取引情報記憶部から前記承認情報を取得する承認情報取得処理と、
前記承認情報に基づいて、前記第1デバイスと前記第2デバイスとの間における通信により行われる第1取引が承認可能であるかを判断する判断処理と、
前記判断処理において、前記第1取引が前記第1デバイスで承認可能でないと判断した場合に、前記上位承認情報に基づいて前記第1取引が承認可能であるかを判断する前記第3デバイスに、前記第1取引の承認を要求する、承認要求処理と、
前記判断処理において、前記第1取引が前記第1デバイスで承認可能であると判断した場合に、前記判断処理の結果に基づいて、前記第1取引を示す第1取引情報を生成し、前記判断処理において、前記第1取引が前記第1デバイスで承認可能でないと判断した場合に、前記第3デバイスによる前記第1取引の承認結果に基づいて、前記第1取引情報を生成する、取引情報生成処理と、
前記第1取引情報を前記取引情報記憶部に格納する取引情報格納処理と、
を実行させる、プログラム。
【請求項2】
請求項に記載のプログラムであって、
前記第1デバイスに、
前記第1デバイスが、前記取引情報記憶部と一時的に通信不可能であり、前記第2デバイスと通信可能である場合に、前記第1取引情報を前記第1デバイスの記憶部に保持する取引情報保持処理、をさらに実行させ、
前記取引情報格納処理は、前記第1デバイスが前記取引情報記憶部と通信可能となった場合に、前記第1デバイスの前記記憶部に保持された前記第1取引情報を前記取引情報記憶部に格納する、プログラム。
【請求項3】
請求項1又は2に記載のプログラムであって、
前記承認情報は、前記第1デバイスが承認可能な取引の条件として、第1承認条件及び前記第1承認条件とは異なる基準に基づく第2承認条件を含む、プログラム。
【請求項4】
第1デバイス及び第2デバイスと通信可能な第3デバイスに、
前記第3デバイスと通信可能な取引情報記憶部であって、
前記第1デバイスの第1デバイス識別情報と、
前記第2デバイスの第2デバイス識別情報と、
前記第1デバイスが承認可能な取引の条件を少なくとも一つ含む承認情報と、
前記第3デバイスが承認可能な取引の条件を少なくとも一つ含む上位承認情報と、
が記録され取引情報記憶部から前記上位承認情報を取得する上位情報取得処理と、
前記承認情報に基づいて前記第1デバイスと前記第2デバイスとの間における通信により行われる第1取引が承認可能であるかを判断する第1デバイスが、前記第1取引が前記第1デバイスで承認可能でないと判断した場合に、前記第1デバイスと通信し、前記第1デバイスから前記第1取引の承認の要求を取得する、要求取得処理と、
前記上位承認情報に基づいて、前記第1取引が承認可能であるかを判断する、上位判断処理と、を実行させる、プログラム。
【請求項5】
請求項に記載のプログラムであって、
前記第3デバイスに、
前記上位判断処理の判断結果を前記第1デバイスに送信する、上位判断送信処理、をさらに実行させる、プログラム。
【請求項6】
請求項に記載のプログラムであって、
前記第3デバイスに、
前記上位判断処理の判断結果に基づいて、前記第1取引を示す第1取引情報を生成する取引情報生成処理と、
前記第1取引情報を前記取引情報記憶部に格納する取引情報格納処理と、をさらに実行させる、プログラム。
【請求項7】
請求項に記載のプログラムであって、
前記第3デバイスに、
前記第3デバイスが、前記取引情報記憶部と一時的に通信不可能であり、前記第1デバイスと通信可能である場合に、前記第1取引情報を前記第3デバイスの記憶部に保持する取引情報保持処理、をさらに実行させ、
前記取引情報格納処理は、前記第3デバイスが前記取引情報記憶部と通信可能となった場合に、前記第3デバイスの前記記憶部に保持された前記第1取引情報を前記取引情報記憶部に格納する、プログラム。
【請求項8】
請求項4から7のいずれか一項に記載のプログラムであって、
前記上位承認情報は、前記第3デバイスが承認可能な取引の条件として、第1上位承認条件及び前記第1上位承認条件とは異なる基準に基づく第2上位承認条件を含む、プログラム。
【請求項9】
ネットワークに接続されるコンピュータに、
請求項1から3のいずれか一項に記載のプログラムが記録された前記第1デバイスが接続された前記取引情報記憶部に記憶される前記承認情報を更新する、承認情報更新処理、を実行させる、プログラム。
【請求項10】
請求項に記載のプログラムであって、
前記承認情報更新処理は、
請求項4から8のいずれか一項に記載のプログラムが記録された前記第3デバイスがさらに接続された前記取引情報記憶部に記憶される前記上位承認情報を更新する、プログラム。
【請求項11】
ネットワークに接続されるコンピュータに、
請求項1から3のいずれか一項に記載のプログラムが記録された前記第1デバイスの前記取引情報記憶部における取引の履歴である取引履歴を前記取引情報記憶部から取得する、取引履歴取得処理と、
前記第1デバイス、前記第1デバイスが取引可能な第2デバイス、及び前記第3デバイスのそれぞれのデバイスの識別情報が、前記それぞれのデバイスのユーザのユーザ情報と関連付けて記憶されたユーザ情報記憶部から、前記第1デバイスのユーザの前記ユーザ情報を取得する、ユーザ情報取得処理と、
前記取引履歴と前記ユーザ情報とに基づいて、前記取引の精算に用いられる精算情報を生成する精算情報生成処理と、を実行させるプログラム。
【請求項12】
請求項1から3のいずれか一項に記載のプログラムが記録された、第1デバイス。
【請求項13】
請求項4から8のいずれか一項に記載のプログラムが記録された、第3デバイス。
【請求項14】
請求項9又は10に記載のプログラムが記録された、コンピュータ。
【請求項15】
請求項11に記載のプログラムが記録された、コンピュータ。
【請求項16】
決済システムであって、
請求項12に記載の第1デバイスと、
請求項14に記載のコンピュータと、
前記ネットワークに接続された第2デバイスと、を備える、決済システム。
【請求項17】
請求項16に記載の決済システムであって、
請求項13に記載の第3デバイス、をさらに備える、決済システム。
【請求項18】
請求項16又は17に記載の決済システムであって、
請求項15に記載のコンピュータ、をさらに備える、決済システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、決済システムの技術に関する。
【背景技術】
【0002】
通信技術の発達に伴い、多数のデバイスが接続されるモノのインターネット(Internet of Things:IoT)の利用が行われている。IoTにおいては、相互に接続されたデバイスが、デバイス間で取引して決済を行う場合が想定される。例えば、家庭で利用される電気製品におけるデバイス間での取引に関する技術が特許文献1に示される。特許文献1では、デバイスに支払口座に関する情報を設定し、デバイスがデバイス自身が必要とするリソースを例えば購入することを可能とするプラットフォームが示される。
【先行技術文献】
【特許文献】
【0003】
【文献】特表2018-506770
【発明の概要】
【発明が解決しようとする課題】
【0004】
IoTでは、多数のデバイスが接続されて取引を行う。デバイス間の取引は、最終的に各デバイスの管理者によって精算される必要がある。また、デバイス間の取引は、少額、高頻度となる場合がある。少額、高頻度の取引に際して、従来のクレジットカード決済のように、多数のデバイスごとに決済識別番号を付与して、オーソリゼーションをセンターで受信し承認を判断する処理方法では、十分な処理速度を提供するための処理コストが増大する。
【0005】
そこで、本発明は、処理コストの増大を抑えつつ、デバイス間の決済を可能とする決済システムを提供することを目的とする。
【課題を解決するための手段】
【0006】
本発明の一態様に係るプログラムは、第1デバイスに、第1デバイスの第1デバイス識別情報と、第1デバイスと通信可能な第2デバイスの第2デバイス識別情報と、第1デバイスが承認可能な取引の条件を含む承認情報と、が記録され、第1デバイス及び第2デバイスと通信可能な取引情報記憶部から承認情報を取得する承認情報取得処理と、承認情報に基づいて、第1デバイスと第2デバイスとの間における通信により行われる第1取引が承認可能であるかを判断する判断処理と、判断処理の結果に基づいて、第1取引を示す第1取引情報を生成する取引情報生成処理と、第1取引情報を取引情報記憶部に格納する取引情報格納処理と、を実行させる。
【0007】
本発明の他の態様に係るプログラムは、第1デバイス及び第2デバイスと通信可能な第3デバイスに、第1デバイスの第1デバイス識別情報と、第2デバイスの第2デバイス識別情報と、第1デバイスが承認可能な取引の条件を含む承認情報と、第3デバイスが承認可能な取引の条件を含む上位承認情報と、が記録された、第3デバイスと通信可能な取引情報記憶部から上位承認情報を取得する上位情報取得処理と、承認情報に基づいて第1デバイスと第2デバイスとの間における通信により行われる第1取引が承認可能であるかを判断する第1デバイスが、第1取引が第1デバイスで承認可能でないと判断した場合に、前記第1デバイスと通信し、第1デバイスから第1取引の承認の要求を取得する、要求取得処理と、上位承認情報に基づいて、第1取引が承認可能であるかを判断する、上位判断処理と、を実行させる。
【0008】
本発明の他の態様に係るプログラムは、ネットワークに接続されるコンピュータに、所定のプログラムが記録された第1デバイスが接続された取引情報記憶部に記憶される承認情報を更新する、承認情報更新処理、を実行させる。
【0009】
上記態様において、承認情報更新処理は、コンピュータに、所定のプログラムが記録された第3デバイスがさらに接続された取引情報記憶部に記憶される上位承認情報を更新してもよい。
【0010】
本発明の他の態様に係るプログラムは、ネットワークに接続されるコンピュータに、所定のプログラムが記録された第1デバイスの取引情報記憶部における取引の履歴である取引履歴を取引情報記憶部から取得する、取引履歴取得処理と、第1デバイス、第1デバイスが取引可能な第2デバイス、及び第1デバイスによる第1取引を承認可能な第3デバイスのそれぞれのデバイスの識別情報が、それぞれのデバイスのユーザのユーザ情報と関連付けて記憶されたユーザ情報記憶部から、ユーザ情報を取得する、ユーザ情報取得処理と、取引履歴とユーザ情報とに基づいて、取引の精算に用いられる清算情報を生成する精算情報生成処理と、を実行させる。
【0011】
本発明の他の態様に係る決済システムは、上記プログラムが記録された第1デバイスと、上記プログラムが記録されたコンピュータと、ネットワークに接続された第2デバイスと、を備える。
【発明の効果】
【0012】
本発明によれば、処理コストの増大を抑えつつ、デバイス間の決済を可能とする決済システムを提供することができる。
【図面の簡単な説明】
【0013】
図1】本実施形態に係る決済システムの構成の概略図である。
図2】本実施形態に係るデバイスのブロック図である。
図3】分散台帳に記録されるデバイス識別情報の一例である。
図4】デバイス間の取引に用いられる商取引情報の一例である。
図5】デバイスでの取引の承認に用いられる承認情報の一例である。
図6】本実施形態に係るデバイスの他のブロック図である。
図7】デバイスでの取引の承認に用いられる上位承認情報の一例である。
図8】デバイスでの取引の承認に用いられる上位承認情報の他の一例である。
図9】本実施形態に係る取引管理システムのブロック図である。
図10】分散台帳に記録される取引履歴の一例である。
図11】精算端末による精算に用いられるユーザ情報の一例である。
図12】精算端末により生成される精算情報の一例である。
図13】決済システム10における処理の動作の例を説明する図である。
図14】決済システム10における処理の動作の他の例を説明する図である。
図15】決済システム10における精算処理の動作の例を説明する図である。
【発明を実施するための形態】
【0014】
添付図面を参照して、本発明の好適な実施形態について説明する。なお、各図において、同一の符号を付したものは、同一又は同様の構成を有する。
【0015】
図1には本実施形態に係る決済システム10の概略図が示される。決済システム10は、デバイス101,102,103,104,105、分散台帳106及び取引管理システム107を備える。
【0016】
デバイス101は、デバイス102,103,104,105、分散台帳106、及び取引管理システム107とネットワークNを通じて通信可能に接続される。ネットワークNは例えばインターネットである。ネットワークNは、例えばイントラネットのようにプライベートネットワークであってもよい。また、デバイス101は、ネットワークN以外の通信手段(例えばBluetooth(登録商標)等)を介して、他のデバイス102,103,104,105と通信可能であってもよい。デバイス101は、所定のプログラムを実行することによって所定の処理を行うコンピュータを有する情報処理装置である。デバイス102から105も同様に、所定の処理を行うコンピュータを有する情報処理装置である。デバイスはそれぞれがネットワークN及び分散台帳106に接続可能にさらに複数台あってもよい。
【0017】
ユースケースの一例として、デバイス101,103は、ユーザが所有する電子機器である。より具体的な例としては、デバイス101はイヤホンであり、デバイス103はスマートフォンであるとする。デバイス102は、デバイス101,103の充電に用いる電力を無線で供給する電源機器であるとする。デバイス101,103が自身が充電が必要であると判断した場合に、デバイス102へとアクセスし、充電を行う。
【0018】
分散台帳106は、トランザクションの記録、トランザクションの履歴及び承認情報を複数の端末が共有することが可能なシステムである。本実施形態において、分散台帳106は、デバイス間の取引を示す取引情報を記憶する取引情報記憶部として機能する。なお、本実施形態では、取引情報記憶部の一例として分散台帳106を用いて説明するが、取引情報記憶部は、分散台帳106のように分散して取引情報が記録される形態に限られない。例えば、取引情報記憶部として、ネットワークNを通じてサーバに取引情報が記録されるような集中型の記憶手段を用いてもよい。
【0019】
取引管理システム107は、各デバイスが取引の判断に用いるために分散台帳106に記録される承認情報及び上位承認情報の設定、分散台帳106におけるデバイス間の取引履歴の分散台帳106からの取得及び各デバイスのユーザに対して取引の精算を行う情報処理システムである。取引管理システム107は1のサーバによって各機能が実現されてもよく、あるいはそれぞれの機能を有する複数のサーバによって構成されてもよい。
【0020】
図2を参照して、デバイス101,102及び103の各部について説明する。デバイス101,102及び103は共通した部分を有するので、ここではデバイス101について説明する。
【0021】
デバイス101は、通信部201、記憶部202、判断部203、取引情報生成部204、商取引生成部205、承認情報取得部206及び承認要求部207を有する。デバイス101の各部は、例えば、デバイス101において、メモリ等の記憶領域を用いたり、記憶領域に格納されたプログラムをプロセッサが実行したりすることによって、実現することができる。
【0022】
デバイス101をはじめとする各デバイスは、分散台帳106においてそれぞれのデバイスを識別するためのアドレスを有する。図3には、デバイス識別情報として、各デバイスのデバイス名及びそのデバイスアドレスの例が示される。デバイス101はデバイスアドレスとして「アドレスA」を有する。デバイス識別情報は、分散台帳106に記録される。デバイス識別情報は、例えば、分散台帳106上に設けられるスマートコントラクトに記録され、各デバイスが参照可能であるとする。各デバイスは自身のデバイス名及びデバイスアドレスを記憶している。なお、本実施形態において、デバイス識別情報はデバイス名とデバイスアドレスの組としているが、デバイスアドレスのみを分散台帳106に記録するようにしてもよい。
【0023】
通信部201は、デバイス101の外部のデバイス及び端末とのネットワークを通じた通信を制御する。
【0024】
記憶部202は、デバイス101での処理に用いられる各種の情報を記憶する。
【0025】
判断部203は、デバイス間での取引(商取引:Commercial transaction)が承認可能であるかを判断する。
【0026】
取引情報生成部204は、判断部203による判断結果に基づいて、商取引を示す取引情報を生成する。本実施形態では、取引情報生成部204は、取引情報として、分散台帳106で処理されるトランザクションを生成する。取引情報生成部204が生成する取引情報には、トランザクションの基となる商取引を識別する取引IDが含まれる。
【0027】
ここで、トランザクションとは商取引そのものではなく、分散台帳106において処理される所定の形式を有するコードである。取引情報生成部204は、生成された取引情報を、通信部201を通じて、分散台帳106に格納する取引情報格納処理を行う。また、デバイス101がネットワークに接続した場合に、デバイス101は、記憶部202に記憶される過去のデバイス101の取引情報を、同様に分散台帳106に格納するようにしてもよい。
【0028】
商取引生成部205は、デバイス間での取引に用いられる商取引情報を生成する。図4には、商取引情報の一例が示される。商取引情報は、「支払デバイス」、「受取デバイス」、「取引金額」、「取引回数」及び「デバイス位置」の各項目を有する。図4では、デバイス101からデバイス102に対して、100円の取引を一回行うこと及びデバイス101の位置は日本国内であることを示す商取引情報の一例が示される。先述の例では、イヤホンであるデバイス101が、充電機器であるデバイス102から充電サービスの提供を受けるために100円を支払うことを意味する。
【0029】
なお、取引金額は、分散台帳106において発行される電子的価値であるトークンによって規定されてもよい。この場合、トークンと法定通貨との換算を行って、最終的な精算が行われるようにできる。また、トークンを用いる場合に、トークンはデバイス間すなわちユーザ間の債権債務の関係を記録するのみにとどまるようにしてもよい。この場合、トークンが分散台帳106において交換されることそのものによっては、価値が移動せず、債権債務の関係が整理される場合に、トークンに基づいて価値の移動が行われる。
【0030】
承認情報取得部206は、分散台帳106から、商取引の承認に用いる承認情報を取得する。図5には承認情報の一例が示される。承認情報は、承認項目として「金額」、「回数」、「位置」、及び「上位デバイス」の項目を有する。なお、各項目は一例であって、項目はこれらに限定されない。例えば他の承認項目としては、デバイスの所有者に関する情報や、リスク情報が含まれてもよい。リスク情報とは、例えばネガティブチェックに用いられる利用停止に関する情報や、過去の取引履歴に基づくユーザへの評価に関する情報である。承認項目の他の例としては、特定の条件の下で行われる取引であることを示す取引種別が含まれてもよい。承認情報に含まれる各条件は、1つの承認項目を用いる1つの条件であってもよく、複数の承認項目を用いる複数の条件であってもよい。また、各項目の追加または削除は、決済システム10の管理者などによって適宜行われ得る。
【0031】
「金額」の項目には、デバイス101によって承認可能な金額の上限が設定される。図5では、デバイス101は100円までの取引を承認可能である場合が示される。なお、金額の条件は上限値ではなく金額範囲によって指定されてもよい。あるいは、金額の条件は、一定期間における取引金額の累計額によって指定されてもよい。
【0032】
「回数」の項目には、デバイス101によって承認可能な取引回数の上限が設定される。図5では、デバイス101が、デバイス101の累積取引回数が5回までであれば取引を承認可能である場合が示される。なお、取引回数の条件は、一定期間内の取引回数の累積であるが、この期間は複数の期間が設定されてもよい。例えば、累積取引回数が、10分間に2回かつ1時間に10回までであれば、取引を承認可能とするようにできる。
【0033】
「位置」の項目には、デバイス101の位置に関する条件が設定される。図5では、デバイス101は、デバイス101の位置情報によって判断されるデバイス101の位置が日本国内である場合に、取引を承認可能である場合が示される。なお、位置情報には、デバイス101に予め紐づけられたユーザの位置情報が含まれてもよい。
【0034】
「上位デバイス」の項目には、デバイス101が承認情報に基づいて商取引の承認判断を行い、デバイス101は商取引を承認可能でないと判断された場合に、商取引の承認を要求する要求先のデバイス(上位デバイス)に関する情報が記録される。図5では、デバイス101は、自身で取引を承認可能でない場合の要求先としてデバイス104が指定される場合が示される。なお、上位デバイスに関する情報はデバイス名ではなく、デバイスアドレスによって記録されてもよい。
【0035】
承認情報取得部206は、分散台帳106から承認情報を取得した場合、承認情報を取得したことを示す情報を分散台帳106に記録してもよい。
【0036】
承認情報取得部206は、他のデバイスを通じて、分散台帳106に記録される承認情報を取得してもよい。例えば、デバイス101がネットワークNに接続されていない場合に、デバイス101が、ネットワークNに接続されているデバイス102とネットワークN以外の通信手段を介して通信可能な状態となった際、デバイス102から承認情報を取得するようにしてよい。他のデバイスから承認情報を取得したことを示す情報も、分散台帳106に記録されるようにしてもよい。
【0037】
承認要求部207は、承認情報取得部206が取得した承認情報に基づいて判断部203が、商取引が承認可能でないと判断した場合に、上位デバイスへと取引の承認を要求する。承認の要求はネットワークNを通じてデバイス101がデバイス104へと通信を行うことによって送信される。
【0038】
図6を参照して、デバイス104及び105の各部について説明する。デバイス104及び105は共通した部分を有するので、ここではデバイス104について説明する。
【0039】
デバイス104は、通信部601、記憶部602、判断部603、取引情報生成部604、上位承認情報取得部605及び承認要求部606を有する。デバイス104の各部は、例えば、デバイス104において、メモリ等の記憶領域を用いたり、記憶領域に格納されたプログラムをプロセッサが実行したりすることによって、実現することができる。
【0040】
通信部601、記憶部602、判断部603及び取引情報生成部604は、デバイス101の通信部201、記憶部202、判断部203及び取引情報生成部204と同様である。ただし、判断部603は承認の判断に後述する上位承認情報を用いた上位判断処理を行う。
【0041】
上位承認情報取得部605は、分散台帳106から、商取引の承認に用いる上位承認情報を取得する。図7にはデバイス104が取得する上位承認情報の一例が示される。上位承認情報は、承認項目として「金額」、「回数」、「位置」及び「上位デバイス」及び「下位デバイス」の項目を有する。なお、各項目は一例であって、上位承認情報の項目は、承認情報の項目と同様にこれらに限定されない。
【0042】
図5の承認情報と図7の上位承認情報とは共通の項目に対応する内容が異なる。例えば、図7では、「金額」は5000円まで、「回数」は10回までという条件になっている。また、上位承認情報においても、さらに上位の承認を必要とする場合に承認の要求を行う上位デバイスの情報が記録される。図7では、デバイス104は、自身で取引を承認可能でない場合の要求先としてデバイス105が指定される場合が示される。なお、上位承認情報の条件は、下位のデバイスにおける承認情報の条件と同じ内容である項目があってもよい。例えば図7の例において、「位置」の項目は「日本国内」であり、図5の承認情報と共通の条件となっている。
【0043】
「下位デバイス」の項目には、商取引の承認要求を送信する側のデバイス(下位デバイス)に関する情報が記録される。図7では、デバイス104に対して承認要求を送信するデバイスとして、デバイス101及びデバイス103を含むように、「下位デバイス」の内容が設定される場合が示される。なお、下位デバイスに関する情報はデバイス名ではなく、デバイスアドレスによって記録されてもよい。これにより、デバイス104が承認要求を処理するにあたって、承認要求を送信するデバイスを限定することができる。よって、不正なデバイスからの承認要求は処理されないようにでき、決済システム10の安全性を向上させることができる。
【0044】
承認要求部606は、上位承認情報に基づく判断の要求を例えば下位のデバイス101等から取得する。また、承認要求部606は、デバイス104が商取引を承認可能でないと判断部603が判断した場合に、さらに上位のデバイスへと取引の承認を要求する。承認の要求の取得並びに送信は、ネットワークNを通じて通信を行うことによって行われる。
【0045】
図8には、デバイス105が取引の承認に用いる上位承認情報の例が示される。図7の上位承認情報の各項目よりも「金額」、「回数」、「位置」に関する条件が広く、より高度な判断を行うことを可能とする。また、「下位デバイス」として、デバイス104が含まれるような設定がなされている。
【0046】
図9を参照して、取引管理システム107の各部について説明する。取引管理システム107は通信部901、記憶部902、ユーザ情報記憶部9021、承認情報更新部903、取引履歴取得部904、ユーザ情報取得部905及び精算情報生成部906を有する。取引管理システム107の各部は、例えば、取引管理システム107において、メモリ等の記憶領域を用いたり、記憶領域に格納されたプログラムをプロセッサが実行したりすることによって、実現することができる。また、取引管理システム107の各部は、複数のサーバに分散して設けられてもよい。
【0047】
通信部901は、取引管理システム107の外部のデバイス及び端末とのネットワークNを通じた通信を制御する。
【0048】
記憶部902は、取引管理システム107での処理に用いられる各種の情報を記憶する。記憶部902はユーザ情報記憶部9021を含み、ユーザ情報記憶部9021には後述するユーザ情報が記憶されている。
【0049】
承認情報更新部903は、例えば決済システム10の管理者によって入力される承認情報及び上位承認情報を取得し、承認情報及び上位承認情報を分散台帳106に送信する。承認情報及び上位承認情報は、デバイスごと又はデバイスのグループごとに、分散台帳106に記録される。
【0050】
あるいは、承認情報更新部903は、後述する取引履歴取得部904が取得した商取引の取引履歴に基づいて、承認情報を更新するようにしてもよい。例えば、分散台帳106に接続されるデバイスが、短時間に複数回にわたる異常取引を行っているとする。この場合に、承認情報更新部903は、分散台帳106に記録される取引履歴を参照し、当該異常取引が発生していることを検出すると、より厳格な条件を設定するように、分散台帳106における承認情報又は上位承認情報を更新してもよい。
【0051】
承認情報及び上位承認情報は、例えば、分散台帳106上の承認情報・上位承認情報記録手段に記録される。承認情報・上位承認情報記録手段は、各デバイスからアクセスされた場合に、各デバイスに対応する承認情報又は上位承認情報を対象のデバイスに送信する。例えば、承認情報・上位承認情報記録手段では、承認情報及び上位承認情報が各デバイスのアドレスに関連付けられる。デバイスアドレスと承認情報の関連付けは、承認情報更新部903によって行われてもよく、あるいは他の端末によって行われてもよい。
【0052】
取引履歴取得部904は、分散台帳106から、分散台帳106に接続されたデバイスによって行われた商取引の取引履歴を取得する。取引履歴は、複数のトランザクションを含む情報である。取引履歴取得部904は、同一の商取引について、複数のデバイスから記録された複数のトランザクションがある場合、取引IDに基づいて複数のトランザクションを統合し、一つの商取引として取引履歴を取得する。取引履歴取得部904が、ある取引IDが示す取引履歴を既に取得している場合、取引履歴取得部は、再度当該取引IDが含まれる取引履歴を取得した際に、当該取引履歴を取得済みの取引履歴に統合して取引履歴を取得する。
【0053】
図10には取引履歴の一例が示される。取引履歴は、「取引ID」、「支払デバイス」、「受取デバイス」及び「取引金額」の項目を有する。「取引ID」の項目は、分散台帳106に送信されたトランザクションの基となる商取引を識別するIDである。「支払デバイス」の項目は、商取引において支払を行うデバイスが記録される。「受取デバイス」の項目は、商取引において受取を行うデバイスが記録される。「取引金額」の項目には、各取引における金額が記録される。例えば、図4の商取引情報に基づく取引は、取引IDが「取引A」として記録されている。また、デバイス101とは異なる承認情報に基づく、デバイス103とデバイス102との取引が、取引IDが「取引B」の取引として記録されている。また、取引の承認を行ったデバイスに関する情報が取引履歴に記録されてもよい。
【0054】
ユーザ情報取得部905は、ユーザ情報記憶部9021を参照してユーザ情報を取得する。図11にはユーザ情報の一例が示される。ユーザ情報は「ユーザ名」、「精算方法」、「精算方法情報」「デバイス名」及び「デバイスアドレス」の項目を有する。
【0055】
「ユーザ名」の項目には、デバイスの保有者であるユーザの情報が記憶される。「精算方法」の項目には、ユーザが取引の精算を行うための方法が記憶される。「精算方法情報」には、「精算方法」による精算のための情報が記憶される。例えば、カード番号や口座情報である。他の精算方法としては、送金事業者等のバリューアカウントや暗号資産のアカウントであってもよい。「デバイス名」及び「デバイスアドレス」の項目には、各ユーザが管理するデバイスの名前およびアドレスが記憶される。
【0056】
例えば、図11において、ユーザAは、デバイス101,103を管理しており、カード番号「Xxx」のクレジットカードによって精算を行うことが記憶される。ユーザBは、デバイス102を管理しており、口座情報「Yyy」の口座による口座振替によって精算を行うことが記憶される。なお、ユーザ情報は取引管理システム107とは異なる端末に記憶されていてもよく、この場合、取引管理システム107は当該端末からユーザ情報を取得する。また、ユーザ情報では、取引の承認を行うデバイス104,105のユーザすなわち承認者の情報が、デバイス104,105に関連付けられて記憶される。
【0057】
精算情報生成部906は、取引履歴とユーザ情報とに基づいて、取引の精算に用いられる精算情報を生成する。図12には精算情報の一例が示される。精算情報は、各ユーザについて、所定のタイミングで、その時点までの取引履歴を集計して生成される。生成された精算情報に基づいて、各ユーザの精算方法による精算が行われる。
【0058】
精算情報は、「ユーザ名」、「精算方法」、「精算方法情報」、「精算対象取引」、「デバイス名」、及び「精算金額」の項目を有する。「ユーザ名」、「精算方法」及び「精算情報」の項目には、ユーザ情報の「ユーザ名」、「精算方法」及び「精算情報」が記録される。
【0059】
「精算対象取引」の項目には、各ユーザについて精算対象となる各取引を示す取引IDが記録される。「デバイス名」の項目には、各取引を行ったデバイスの名前が記録される。「精算金額」の項目には、各取引における取引金額に基づく金額が記録される。例えば、図10の取引履歴及び図11のユーザ情報に基づいて、ユーザAに対しては、デバイス101,103の各取引について、「-100円」、「―900円」、「―200円」のように精算金額が記録される。ここで、マイナスの符号は、ユーザAから精算金額を徴収することを意味する。ユーザBに対しても同様に、デバイス102による各取引について、「100円」、「900円」、「200円」と精算金額が記録される。マイナス符号がない場合は、ユーザBへ精算金額が入金されることを意味する。なお、ユーザ毎に精算対象取引の精算金額を合計した金額をユーザに関連付けるようにして精算情報が生成されてもよい。
【0060】
精算情報が生成されるタイミングは、取引が行われた際に即時行われる場合や、日次、週次、月次又は四半期毎に行われる場合がある。例えば、金額が大きい取引は、即時あるいは日次にて、精算情報が生成されて精算が行われる。また、マイクロペイメントのように取引金額が小さい取引については、週次や月次等のある期間における取引をまとめて精算情報を生成し、精算を行うことで、処理コストを低減させることが可能である。また、取引管理システム107が、精算に関わるユーザあるいはイシュアやアクワイアラ等の事業者から、精算を行うリクエストを取得して生成された精算情報に基づいて、精算が行われてもよい。
【0061】
図13を参照して、上位デバイスへの承認要求がない場合の決済システム10の動作について説明する。
【0062】
ステップS1301において、取引管理システム107は、例えば管理者から承認情報及び上位承認情報を取得する。ステップS1302において、取引管理システム107は、分散台帳106に記憶される承認情報及び上位承認情報を送信する。
【0063】
ステップS1303において、分散台帳106は、承認情報及び上位承認情報を記録する。
【0064】
ステップS1304において、デバイス101は分散台帳106からデバイス101に対応する承認情報を取得する。ステップS1305において、デバイス102は分散台帳106からデバイス102に対応する承認情報を取得する。
【0065】
ステップS1306において、デバイス102は、商取引情報を生成する。ステップS1307において、デバイス102は、デバイス101に生成された商取引情報を送信する。デバイス102とデバイス101との間の通信は、ネットワークNを介して行われてもよく、BluetoothやNFC(Near Field Communication)等のデバイス間通信手段を介して行われてもよい。なお、商取引情報の生成及び送信は、デバイス101からデバイス102に対して行われてもよい。
【0066】
ステップS1308において、デバイス101は、承認情報に基づいて、商取引の承認を判断する。例えば、図4の商取引情報を取得した場合、図5の承認情報に基づいて判断が行われる。図4の商取引情報は、承認情報を満たすためデバイス101は、取引が承認可能であると判断する。
【0067】
ステップS1309において、デバイス101は、分散台帳106において処理されるトランザクションを商取引情報に基づいて生成する。ステップS1310において、デバイス101は分散台帳106に生成したトランザクションを送信する。
【0068】
ステップS1311において、分散台帳106でトランザクションが処理され、トランザクションが分散台帳106に記録される。
【0069】
ステップS1312及びステップS1313において、デバイス102及びデバイス101はそれぞれ分散台帳106を参照して、トランザクションの処理結果すなわちトランザクションが記録されたことを示す情報を取得する。これにより、デバイス101とデバイス102との間の商取引が完了する。商取引の完了をもって、デバイス102はデバイス101に対して、取引の対価としての機能あるいは情報等を提供する。先述の例では、デバイス102がデバイス101への充電サービスの提供を開始する。
【0070】
なお、デバイス101ではなく、デバイス102が、トランザクションを分散台帳106に送信して記録を行ってもよい。
【0071】
また、デバイス101とデバイス102の双方が、トランザクションを分散台帳106に送信して記録を行ってもよい。この場合、2つのデバイスから同一の取引について、重複してトランザクションが記録される。これらの重複するトランザクションは、トランザクションの生成の基となる商取引ごとに共通の取引IDを有している。
【0072】
これらの重複するトランザクションは、取引履歴取得部904による取引履歴の取得時に、取引IDに基づいて統合されて取得される。これにより、同一の取引に対して複数のトランザクションが記録された場合であっても、取引履歴の取得が重複して行われることを避けることができる。複数のデバイスによりトランザクションを分散台帳106に記憶することで、例えばデバイス102が破損あるいは紛失したり、ネットワーク接続が切断されてしまったりした場合であっても、決済システム10は、取引履歴を把握可能となる。
【0073】
また、デバイス101が、分散台帳106と一時的に通信不可能な状態すなわちオフライン状態にあることも想定される。この場合、デバイス101とデバイス102は、ネットワークN以外のデバイス間通信手段を介して商取引情報の送受信を行う。
【0074】
この場合も、デバイス101は、ステップS1307にてデバイス102から商取引情報を取得する。ステップS1308にて、デバイス101は、承認情報に基づいて、商取引の承認を判断する。オフライン状態の場合、デバイス101は、ステップS1309にて生成したトランザクションを、記憶部202に保持しておく。デバイス101は、デバイス間通信手段を介して、デバイス102に対して、商取引の承認結果を送信してもよい。
【0075】
デバイス101は、デバイス101と分散台帳106との間の通信が可能となった際に、記憶部202に保持されたトランザクションを分散台帳106に送信する。これにより、デバイス101が分散台帳106と一時的に通信不可能な状態となった場合でも、商取引の承認を行い、トランザクションを分散台帳106に格納することができる。
【0076】
図14を参照して、上位デバイスへの承認要求を伴う場合の決済システム10の動作について説明する。なお、ここでは、図13を参照して説明した場合と同様に、取引管理システム107によって、分散台帳106には承認情報及び上位承認情報が記録されているものとする。
【0077】
ステップS1401,S1402において、デバイス101及びデバイス102はそれぞれの承認情報を分散台帳106から取得する。ステップS1403,S1404において、デバイス104及びデバイス105はそれぞれの上位承認情報を分散台帳106から取得する。
【0078】
ステップS1405において、デバイス102は、商取引情報を生成する。ステップS1406において、デバイス102は、デバイス101に生成された商取引情報を送信する。なお、商取引情報の生成及び送信は、デバイス101からデバイス102に対して行われてもよい。ここでは、商取引情報の取引金額が「6000円」であるとする。先述の例のようにデバイス101がイヤホンであってデバイス102が充電機器である場合に、取引金額が6000円となる状況とは、僻地であることなどの理由から、電力コストが高い場合などが想定される。
【0079】
ステップS1407において、デバイス101は、承認情報に基づいて、商取引の承認を判断する。図5の承認情報に基づいて判断が行われる場合、取引金額が6000円であるので、商取引情報は、承認情報を満たさない。この場合、デバイス101は、取引が承認可能でないと判断する。
【0080】
デバイス101にて取引が承認可能でないと判断された場合、ステップS1408において、バイス101は承認情報に含まれる上位デバイスに関する情報に基づいて、デバイス104に承認要求を送信する。承認要求には商取引情報が含まれている。
【0081】
ステップS1409において、デバイス104は上位承認情報に基づいて、取引の承認を判断する。デバイス104が図7の上位承認情報に基づいて判断する場合、商取引での取引金額が6000円であるため、デバイス104は取引が承認可能でないと判断する。
【0082】
ステップS1410において、取引が承認可能でないと判断したデバイス104は、図7の上位承認情報に含まれる上位デバイスに関する情報に基づいて、デバイス105に対して承認要求を送信する。
【0083】
ステップS1411において、デバイス105は上位承認情報に基づいて、取引の承認を判断する。デバイス105が図8の上位承認情報に基づいて判断する場合、取引金額が6000円の商取引は承認される。ステップS1412において、デバイス105はデバイス104へ取引が承認されたことを示す承認結果を送信する。
【0084】
ステップS1413において、デバイス104はデバイス105からの承認結果をデバイス101へと送信する。
【0085】
ステップS1414において、デバイス101は、分散台帳106において処理されるトランザクションを商取引情報に基づいて生成する。ステップ1515において、デバイス101は分散台帳106に生成したトランザクションを送信する。デバイス101は、トランザクションを分散台帳106に処理させることで、トランザクションを分散台帳106に格納する。
【0086】
ステップS1416において、分散台帳106でトランザクションが処理され、トランザクションが分散台帳106に記録される。
【0087】
ステップS1417及びステップS1418において、デバイス102及びデバイス101はそれぞれ分散台帳106を参照して、トランザクションの処理結果を取得する。これにより、デバイス101とデバイス102との間の商取引が完了する。商取引の完了をもって、デバイス102はデバイス101に対して、取引の対価としての機能あるいは情報等を提供する。
【0088】
なお、デバイス101がトランザクションを生成せずに、デバイス104又はデバイス105がトランザクションを生成して分散台帳106に送信してもよい。例えばデバイス105が取引を承認した場合にデバイス104へ承認結果を送信することと合わせて、対象の商取引に基づいて、トランザクションの生成及び送信を行ってもよい。この場合、図14のステップS1414,S1415のプロセスはスキップされる。
【0089】
デバイス105がトランザクションを送信することで、デバイス101とデバイス102との商取引を示すトランザクションが分散台帳106に記録される。これにより、例えば、デバイス101又は102が、破損あるいは紛失したり、ネットワーク接続が切断されてしまったりした場合であっても、取引管理システム107が、当該商取引についての取引履歴を取得することが可能となる。
【0090】
また、デバイス101とデバイス102との商取引を示すトランザクションは、取引に関与したデバイス、例えばデバイス101,102,104及び105のうち少なくとも2つ以上のデバイスによって、重複して分散台帳106に記録されてもよい。この場合も、取引履歴取得部904による取引履歴の取得時に、重複したトランザクションが、取引IDに基づいて統合される。これにより、同一の取引に対して複数のトランザクションが記録された場合であっても、取引履歴の取得が重複して行われることを避けることができる。
【0091】
また、分散台帳106にトランザクションを送信するデバイスが分散台帳106と一時的に通信不可能な状態すなわちオフライン状態にあることも想定される。例えば、デバイス104が承認処理及びトランザクションの生成送信を行う場合がある。この場合、デバイス101,デバイス102,デバイス104及びデバイス105は、ネットワークN以外のデバイス間通信手段を介して商取引情報、承認要求又は承認結果の送受信を行う。
【0092】
デバイス104は、ステップS1406にてデバイス101から承認要求を取得する。ステップS1407にて、デバイス104は、承認要求に基づいて、商取引の承認を判断する。承認結果は。デバイス間通信手段を通じてデバイス101に送信される。また、デバイス101とデバイス102の双方に承認結果が送信されるようにしてもよい。
【0093】
デバイス104にて商取引が承認された際にデバイス104がオフライン状態の場合、デバイス104は、生成したトランザクションを、記憶部602に保持しておく。デバイス104は、デバイス間通信手段を介して、デバイス101及びデバイス102に対して、商取引の承認に関する情報を送信してもよい。デバイス104は、デバイス104と分散台帳106との間の通信が可能となった際に、記憶部602に保持されたトランザクションを分散台帳106に送信する。
【0094】
これにより、デバイス104が分散台帳106と一時的に通信不可能な状態となった場合でも、商取引の承認を行いデバイス間の商取引を成立させ、その後にトランザクションを分散台帳106に格納することができる。デバイス104がデバイス101とデバイス102の間の商取引の承認を分散台帳106との接続なしに行うようにできるので。その後、トランザクションを分散台帳106に格納することで取引を記録できる。
【0095】
図15を参照して、取引管理システム107による精算処理の動作について説明する。ステップS1501において、図13及び図14で説明したような商取引の処理が行われる。
【0096】
ステップS1502において、取引管理システム107は、分散台帳106から取引履歴を取得する。
【0097】
ステップS1503において、取引管理システム107は、取引管理システム107のユーザ情報記憶部9021に記憶されるユーザ情報を参照して取得する。
【0098】
ステップS1504において、取引管理システム107は、取引履歴及びユーザ情報に基づいて、精算情報を生成する。生成された精算情報に基づいて、各デバイスにおける取引の各ユーザに対しての精算が行われる。
【0099】
なお、決済システム10が、同一の取引について複数のデバイスから複数のトランザクションを、重複して分散台帳106に記録するような場合、取引履歴取得部904は、重複するトランザクションを統合して取引履歴を取得するので、精算情報生成部906が重複して精算情報を生成することを避けることができる。
【0100】
以上説明した実施形態は、デバイス間いわゆるM2M(Machine to Machine)の取引について説明したものである。ここで、M2M決済とはやや異なり、ユーザの意志が関与して行われる取引についても、本実施形態に係る決済システム10が応用可能であることを、ユーザ端末と加盟店端末とを用いる取引を例に説明する。
【0101】
ユーザ端末は、例えばクレジットカード情報がスマートフォン等の電子機器に記録された端末である。ユーザ端末は、ユーザの口座、クレジットカード、送金事業者のバリューアカウント又は暗号資産のアカウントに関連付けられた二次元コードを表示することができる電子機器であってもよい。二次元コードは、ユーザ端末によって表示される場合の他にも、所定の二次元コードが印刷された紙やカード等の物体によって表示されてもよい。この場合、当該物体がユーザ端末として機能する。ユーザ端末は、クレジットカード情報が記録されたICチップを有するクレジットカードなどであってもよい。あるいは、ユーザはネットワーク接続機能を有しないNFC(Near Field Communication)タグなどによって、加盟店端末と決済に必要な情報のやりとりを行ってもよい。
【0102】
加盟店端末は、例えばクレジットカード情報を取得することで決済を行う端末である。クレジットカード情報の取得は、加盟店端末が物理的なクレジットカードを読み取り、ICチップから情報を取得することや、クレジットカード情報が記録された端末からクレジットカード情報を取得することによって行われる。加盟店端末の他の例としては、ユーザ端末に表示された二次元コードを読み取って決済を行う端末であってもよい。他の例としては、ユーザのNFCタグを読み取って決済を行う端末であってもよい。
【0103】
加盟店端末が図1におけるデバイス101に相当する。また、ユーザ端末は分散台帳106に接続されない端末(図1では不図示)である。ユーザ端末と加盟店端末とが上位デバイスに承認を必要としない場合、例えば、取引の承認はEMVに準拠して行われる。加盟店端末の承認条件は、分散台帳106を通じて、加盟店端末に提供される。加盟店端末の承認条件は、クレジットカードのイシュア、アクワイアラ又はブランド等の各事業者が各加盟店に対して行うリスク評価に基づいてもよい。また、位置情報が承認条件に含まれる場合には、ユーザ端末に紐づけられたユーザ情報に含まれるカード発行国又はイシュア所在国、あるいは、加盟店端末に紐づけられた加盟店の登録国を位置情報とすることができる。
【0104】
ユーザ端末と加盟店端末との間のみで取引の承認ができない場合は、加盟店端末が、上位デバイス(例えばデバイス104又はデバイス105)に対して、本実施形態と同様に取引の承認を要求し、上位デバイスが所定の上位承認条件に基づく承認判断をするようなSTIP(Stand-In Processing)処理を行うようにできる。ユーザ端末、加盟店端末又は上位デバイスによる承認を経た取引の結果は、分散台帳106に記録される。また、ネットワーク接続機能を有しないNFCタグ等をユーザ端末に用いる場合は、加盟店端末側で承認情報や上位承認情報に基づく判定が行われて、取引の承認がなされる。
【0105】
これにより、オーソリゼーションをセンターで受信し承認を判断する処理方法よりも、ネットワーク接続コストやセンターでの処理コストを低減可能となる。また、取引履歴を分散台帳106から取得することで、精算に必要なデータの取得コストを低減可能となる。
【0106】
なお、ユーザ端末と加盟店端末の分散台帳106への接続は、上述のように加盟店端末だけが分散台帳106に接続される場合以外にも、以下の場合がある。
【0107】
1つは、ユーザ端末と加盟店端末とが共に分散台帳106に接続される場合である。この場合、ユーザ端末はネットワークに接続可能な通信機能を備える必要がある。ユーザ端末及び加盟店端末は、分散台帳106を通じて承認条件を取得する。取引が承認された場合、ユーザ端末及び加盟店端末の双方もしくは一方によって分散台帳106に処理が記録される。
【0108】
また、ユーザ端末のみが分散台帳106に接続される場合があってもよい。例えば、加盟店は、決済に必要な2次元コードを表示する端末あるいは固定の二次元コードが印刷された紙やカード、その他の形状の物体を用いるなどしてユーザ端末が読み取り可能に2次元コードを提供する。ユーザ端末はその2次元コードを読み取り、決済を行い、取引履歴を分散台帳106上に記録する。あるいは、加盟店はネットワーク接続機能を有しないNFC(Near Field Communication)タグなどによって、ユーザ端末と決済に必要な情報のやりとりを行ってもよい。
【0109】
また、ユーザ端末と加盟店端末とを用いる取引ではなく、両方がユーザによって操作される端末間の個人間決済にも本実施形態に係る決済システム10は応用可能である。この場合、複数のユーザ端末が分散台帳106に接続される。複数のユーザ端末はそれぞれ承認条件を取得し、本実施形態と同様に上位承認条件を考慮した取引を行うようにすることも可能である。
【0110】
以上本実施形態について説明した。本実施形態におけるデバイス101は、デバイス101のデバイス識別情報と、デバイス101と通信可能なデバイス102のデバイス識別情報と、デバイス101が承認可能な取引の条件を含む承認情報と、が記録され、デバイス101及びデバイス102と通信可能な分散台帳106から承認情報を取得する承認情報取得処理と、承認情報に基づいて、デバイス101とデバイス102との間の通信により行われる取引が承認可能であるかを判断する判断処理と、判断処理の結果に基づいて、デバイス101とデバイス102との間における取引を示すトランザクションを生成する取引情報生成処理と、トランザクションを分散台帳106に格納する取引情報格納処理と、を実行する。
【0111】
これにより、デバイス101は取得した承認情報に基づいて、取引の承認を行うことができる。よって、取引の承認に関する処理を、デバイス101で完結させることが可能となる。これにより、高頻度の取引がデバイス101とデバイス102との間で行われる際に、他のシステムあるいは端末へと接続して承認を得るための処理コストの増大を抑えることが可能となる。また、分散台帳106にトランザクションを送信して取引を行うことによって、取引の記録を分散台帳106上に残すことが可能となる。デバイス101が紛失した場合やデバイスを使い捨てる場合であっても、デバイス101による支払の決済を他のデバイスで行うことが可能となる。
【0112】
デバイス101では、承認情報は、デバイス101で承認可能ではない取引の承認の要求先であるデバイス104のデバイス識別情報を含み、デバイス101に、判断処理において、取引がデバイス101で承認可能でないと判断した場合に、取引の承認をデバイス104に要求する承認要求処理、をさらに実行する。
【0113】
これにより、デバイス101が承認可能でない処理に限って、デバイス104によって承認を判断することが可能となる。決済システム10のエッジにあるデバイス101による承認プロセスとあわせて、中間(フォグ)にあるデバイス104による承認を行うことで、処理コストの増大を抑えることが可能となる。
【0114】
デバイス101では、取引情報生成処理は、デバイス104による取引の承認結果に基づいて、トランザクションを生成する。これによって、デバイス101が承認できない取引についてトランザクションを生成させないようにすることができ、決済システム10の安全性を高めることができる。
【0115】
デバイス101は、デバイス101が、分散台帳106と一時的に通信不可能であり、デバイス102と通信可能である場合に、トランザクションをデバイス101の記憶部202に保持する取引情報保持処理、をさらに実行し、取引情報格納処理は、デバイス101が分散台帳106と通信可能となった場合に、デバイス101の記憶部202に保持されたトランザクションを分散台帳106に格納する。
【0116】
これにより、デバイス101が分散台帳106と一時的に通信を行えない場合であっても、デバイス101とデバイス102との間の通信により行われる取引の承認を行うことができる。承認結果はデバイス101,デバイス102に送信され、各デバイスは、商取引に基づく処理を行うことができる。デバイス101に一時的に保持されたトランザクションは、デバイス101が分散台帳106と通信可能となった場合に、分散台帳106に格納される。トランザクションは最終的に分散台帳106に記録される。
【0117】
デバイス101では、承認情報は取引の取引金額に関する条件を含む。これにより、少額取引はデバイス101で承認可能とする設定が可能となり、処理コスト増大を抑制できる。
【0118】
デバイス101では、承認情報は取引の取引回数に関する条件を含む。これにより、デバイス101の不正な操作によって、複数回の取引が実行されてしまう可能性を低下させることができ、決済システム10の安全性を向上させることができる。
【0119】
デバイス101では、承認情報はデバイス101の位置情報に関する位置条件を含む。これにより、例えばデバイス101が盗難された場合に、位置情報に基づいて取引の承認を判断することによって、不正利用される可能性を低下させることができ、決済システム10の安全性を向上させることができる。
【0120】
また、本実施形態では、デバイス101とデバイス102が接続されたインターネットに接続されたデバイス104に、デバイス101のデバイス識別情報と、デバイス102のデバイス識別情報と、デバイス101が承認可能な取引の条件を含む承認情報と、デバイス104が承認可能な取引の条件を含む上位承認情報と、が記録された分散台帳106から上位承認情報を取得する上位情報取得処理と、承認情報に基づいてデバイス101とデバイス102との間における取引が承認可能であるかを判断するデバイス101が、取引がデバイス101で承認可能でないと判断した場合に、デバイス101から取引の承認の要求を取得する、要求取得処理と、上位承認情報に基づいて、取引が承認可能であるかを判断する、上位判断処理と、を実行させる。
【0121】
デバイス101(下位デバイス)は、分散台帳106あるいはネットワークNに接続されないオフライン状態で動作する可能性が高い。他方、デバイス104(上位デバイス)は、分散台帳106あるいはネットワークNに接続するための接続環境を備える可能性が高い。また、デバイス104の方が、デバイス101よりも高い情報処理能力を有する場合が多い。よって、階層の上位にあるデバイス104は、分散台帳106から取得したより新しい上位承認条件を素早く処理し、最新の上位承認条件に基づく承認の判断が可能となる。
【0122】
また、デバイス101とデバイス102との間で承認可能な少額取引等はデバイス101とデバイス102との間で承認を行い、上位のデバイス104で承認を必要とする取引に限って、デバイス104による承認を要求するようにできる。これにより、デバイス101又はデバイス102が、全ての取引において、承認のための通信をデバイス104と行う場合に比べて、処理コストの増大を抑制できる。
【0123】
デバイス104は、上位判断処理の判断結果をデバイス101に送信する、上位判断送信処理、をさらに実行する。これにより、デバイス101は取引の承認結果に関する情報を取得することが可能となる。取引が承認されなかった場合に、デバイス101は、別のデバイスとの代替的な取引を行う動作をすることで、デバイス101の取引動作に柔軟性を与えることが可能となる。
【0124】
デバイス104は、上位判断処理の判断結果に基づいて、デバイス101とデバイス102との間の取引を示すトランザクションを生成する取引情報生成処理と、トランザクションを分散台帳106に送信する取引情報送信処理と、を実行してもよい。
【0125】
これにより、デバイス101が承認結果を受けてトランザクションを生成する場合より早いステップで、トランザクションを分散台帳106に送信できる。分散台帳106でのトランザクションの処理もより早いステップにおいて行われるため、取引の処理速度を向上させることができる。
【0126】
また、デバイス104は、デバイス104が、分散台帳106と一時的に通信不可能であり、デバイス101と通信可能である場合に、トランザクションをデバイス104の記憶部602に保持する取引情報保持処理、をさらに実行し、取引情報格納処理は、デバイス104が分散台帳106と通信可能となった場合に、デバイス104の記憶部602に保持されたトランザクションを分散台帳106に格納する。
【0127】
デバイス101では、承認情報は、デバイス101が承認可能な取引の条件として、第1承認条件及び第1承認条件とは異なる基準に基づく第2承認条件を含む。デバイス104では、上位承認情報は、デバイス101が承認可能な取引の条件として、第1上位承認条件及び第1上位承認条件とは異なる基準に基づく第2上位承認条件を含む。例えば、承認情報は取引の取引金額に関する第1金額条件を含み、デバイス104では上位承認情報は、第2金額条件を含む。また、デバイス101では、承認情報は取引の取引回数に関する第1回数条件を含み、デバイス104では上位承認情報は、第2回数条件を含む。また、承認情報は、デバイス101の位置情報に関する第1位置条件を含み、上位承認情報は、デバイス104の位置情報に関する第2位置条件を含む。
【0128】
これにより、取引金額、取引回数、位置情報に関する条件を階層的に設定することが可能となる。少額高頻度な取引はデバイス101で承認可能とし、デバイス101で処理できない場合に限って、デバイス104で承認処理を行うような設定が可能となり、処理コスト増大を抑制できる。また、各デバイスに、取引金額、取引回数、位置情報等に関する条件を組み合わせた承認情報又は上位承認情報を設定することができる。
【0129】
本実施形態において、取引管理システム107は、デバイス101が接続された分散台帳106に承認情報を送信する、承認情報送信処理を実行する。また、取引管理システム107は、デバイス104が接続された分散台帳106に上位承認情報を送信する、上位承認情報送信処理を実行する。これによって、承認情報及び上位承認情報を適宜更新することが可能となるため、新規のデバイスの追加等が可能となり、決済システム10の利便性が向上する。
【0130】
本実施形態において、取引管理システム107は、デバイス101の分散台帳106における取引の履歴である取引履歴を分散台帳106から取得する、取引履歴取得処理と、デバイス101のユーザに関するユーザ情報がデバイス101に関連付けられて記憶されるユーザ情報記憶部9021から、ユーザ情報を取得する、ユーザ情報取得処理と、取引履歴とユーザ情報とに基づいて、取引の精算に用いられる精算情報を生成する精算情報生成処理と、を実行する。
【0131】
これにより、複数のデバイスにおける取引を各精算の主体であるユーザに関連付けることが可能となる。よって、決済システム10は、分散台帳106において、多数のデバイス間での取引をより短い時間で成立させつつ、最終的なユーザへの精算を可能とすることができる。つまり、短時間で成立する必要のあるデバイス間での多数の取引の度に、精算情報を生成しないため、精算情報の生成の高速化のための処理コストを抑えることができる。
【0132】
以上説明した実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。実施形態が備える各要素並びにその条件、接続関係及びサイズ等は、例示したものに限定されるわけではなく適宜変更することができる。また、構成同士を部分的に置換し又は組み合わせることが可能である。
【符号の説明】
【0133】
10…決済システム、101,102,103,104,105…デバイス、106…分散台帳、107…取引管理システム、201,601,901…通信部、202,602,902…記憶部、203,603…判断部、204,604…取引情報生成部、205…商取引生成部、206…承認情報取得部、207,606…承認要求部、605…上位承認情報取得部、9021…ユーザ情報記憶部、903…承認情報更新部、904…取引履歴取得部、905…ユーザ情報取得部、906…精算情報生成部
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15