特許 7579041 ポイント取引システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-29

(45)【発行日】2024-11-07

(54)【発明の名称】ポイント取引システム

(51)【国際特許分類】

   H04L 9/32 20060101AFI20241030BHJP

   G06Q 20/04 20120101ALI20241030BHJP

【ＦＩ】

H04L9/32 200Z

G06Q20/04

【請求項の数】 1

(21)【出願番号】P 2021004542

(22)【出願日】2021-01-14

(65)【公開番号】P2022109163

(43)【公開日】2022-07-27

【審査請求日】2024-01-14

(73)【特許権者】

【識別番号】506149519

【氏名又は名称】株式会社Ｓｋｅｅｄ

(74)【代理人】

【識別番号】100136146

【弁理士】

【氏名又は名称】小谷 明生

(72)【発明者】

【氏名】柴田 巧一

【審査官】中里 裕正

(56)【参考文献】

【文献】特表２０２０－５１２７０８（ＪＰ，Ａ）

【文献】国際公開第２０１８／２２０７０９（ＷＯ，Ａ１）

【文献】米国特許出願公開第２０１９／０３０３６２１（ＵＳ，Ａ１）

【文献】中国特許出願公開第１０８８３３０８１（ＣＮ，Ａ）

【文献】佐中晋，Hyperledger Fabric v1.0｜合意形成と管理方式を一新，iMagazine，[online]，2018年03月26日，<URL:https://www.imagazine.co.jp/hyperledger-fabric-v1-0%EF%BD%9C%E5%90%88%E6%84%8F%E5%BD%A2%E6%88%90%E3%81%A8%E7%AE%A1%E7%90%86%E6%96%B9%E5%BC%8F%E3%82%92%E4%B8%80%E6%96%B0/>，[2022年11月14日検索]

【文献】MANEVICH, Y., BARGER,A. and TOCK, Y.，POSTER: Service Discovery for Hyperledger Fabric，arXiv，1805.02105v1， [online]，2018年05月05日，pp.1-4，<URL:https://arxiv.org/abs/1805.02105v1>

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ９／３２

Ｇ０６Ｑ ２０／０４

ＪＳＴＰｌｕｓ／ＪＭＥＤＰｌｕｓ／ＪＳＴ７５８０（ＪＤｒｅａｍＩＩＩ）

ＩＥＥＥ Ｘｐｌｏｒｅ

(57)【特許請求の範囲】

【請求項1】

ポイント取引端末と、複数のノードで構成される低消費電力広域通信網と、を備え、
前記ポイント取引端末は、前記複数のノードのうちの１つのノードであるウィンドウノードに対し、ユーザ間のポイント取引の内容を示すトランザクションデータを送信し、
前記ウィンドウノードは、自装置に記憶している台帳を参照し、前記トランザクションデータの有効性を確認すると、前記トランザクションデータの内容を当該台帳に反映するために当該台帳に追加すべきブロックの候補を生成し、当該ブロックの候補に自装置の署名を付与した後、前記低消費電力広域通信網内にブロードキャストし、
前記複数のノードのうち、前記ウィンドウノードからブロードキャストされた前記ブロックの候補を受信したノードは、前記ブロックの候補に付与されている署名を検証し、当該ブロックの候補の有効性を確認できた場合、当該ブロックの候補に自装置の署名を付与した後、前記低消費電力広域通信網内にブロードキャストし、
前記複数のノードの各々は、各々に異なるノードの署名が付与されたブロックの候補を所定数以上収集し、収集した所定数以上のブロックの候補の各々に付与されている署名を検証し、当該所定数以上のブロックの候補の内容が一致していることを確認すると、当該所定数以上のブロックの内容を正しい増分のブロックとして自装置に記憶している台帳に追加する
ポイント取引システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ポイント取引システムに関する。

【背景技術】

【0002】

低消費電力広域通信網(LPWAN)は、低コスト、低消費電力、長距離、多数接続の特性により、近年、IoTにアクセスするための主要技術となっている。同時に、ポイント取引システムは、典型的な第三者決済のための応用技術として、学術界や産業界からますます広範にわたる注目を集めている。そのため、LPWANのポイント取引システムの研究開発は、非常に実用的な重要性を持っている。

【0003】

例えば、非特許文献１には、LPWANが、IoTがネットワークにアクセスするための要件を満たす通信技術である点に関する記述がある。

【先行技術文献】

【非特許文献】

【0004】

【文献】総務省、“平成29年版 情報通信白書のポイント 第1部 特集 データ主導経済と社会変革 第3節 IoT化する情報通信産業 （2）LPWA”、[online]、［令和３年１月１４日検索］、インターネット＜URL: https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h29/html/nc133220.html＞

【発明の概要】

【発明が解決しようとする課題】

【0005】

モバイルIoTの急速な発展に伴い、多くのアプリケーション指向の第三者決済技術が、新しいIoTファイナンスを生み出している。典型的な第三者決済の応用技術として、アプリケーション指向のLPWANのためのポイント取引システムが広く注目を集めている。

【0006】

しかし、現在のポイント取引システムは、システムの整合性を確保するための会計データを維持するために、基本的に集中型のデータストレージを使用している。集中型のデータストレージは、単一で障害点となる可能性があり、データへのアクセス性能が不足するとサーバが利用できなくなる。従って、いかにデータセキュリティを確保するか、という点が大きな懸念事項である。

【0007】

台帳ベースの技術は、電子通貨の生成に用いられており、集中セキュリティの問題に対する優れた解決策となり得る。具体的には、台帳は、複数のサイト、異なる地理的位置、または複数の組織のネットワークで共有される資産のデータベースである。さらに、分散型共有台帳は、暗号技術により改ざん及び偽造が不可能であることが保証されている。そのため、分散型共有台帳はIoTファイナンスにおいて最も広く利用されている。

【0008】

しかし、IoT端末デバイスの演算能力は一般的に低く、大規模な演算処理を実行できない。

【0009】

上述した事情に鑑み、本発明は、データセキュリティを十分に保証し、演算能力の低いIoTデバイスに適した、アプリケーション指向のLPWAN用の軽量な台帳を用いたポイント取引システムを提供する。

【課題を解決するための手段】

【0010】

本発明は、ポイント取引端末と、複数のノードで構成される低消費電力広域通信網と、を備え、前記ポイント取引端末は、前記複数のノードのうちの１つのノードであるウィンドウノードに対し、ユーザ間のポイント取引の内容を示すトランザクションデータを送信し、前記ウィンドウノードは、自装置に記憶している台帳を参照し、前記トランザクションデータの有効性を確認すると、前記トランザクションデータの内容を当該台帳に反映するために当該台帳に追加すべきブロックの候補を生成し、当該ブロックの候補に自装置の署名を付与した後、前記低消費電力広域通信網内にブロードキャストし、前記複数のノードのうち、前記ウィンドウノードからブロードキャストされた前記ブロックの候補を受信したノードは、前記ブロックの候補に付与されている署名を検証し、当該ブロックの候補の有効性を確認できた場合、当該ブロックの候補に自装置の署名を付与した後、前記低消費電力広域通信網内にブロードキャストし、前記複数のノードの各々は、各々に異なるノードの署名が付与されたブロックの候補を所定数以上収集し、収集した所定数以上のブロックの候補の各々に付与されている署名を検証し、当該所定数以上のブロックの候補の内容が一致していることを確認すると、当該所定数以上のブロックの内容を正しい増分のブロックとして自装置に記憶している台帳に追加するポイント取引システムを提案する。

【発明の効果】

【0011】

本発明によれば、LPWAN内のIoT端末デバイス間におけるポイント取引が可能となる。

【図面の簡単な説明】

【0012】

【図1】本発明の一実施形態に係るポイント取引システムの構成の概要を示した図。

【図2】本発明の一実施形態に係るポイント取引システムにおいて行われる台帳の処理プロセスの概要を示した図。

【図3】本発明の一実施形態に係るポイント取引システムを構成するLPWAN内のノードにおいて実行される台帳の処理プロセスのためのアルゴリズムの例を示した図。

【図4】本発明の一実施形態に係るポイント取引システムを利用して、ユーザが店舗にポイントを支払う場合の取引の流れを例示した図。

【発明を実施するための形態】

【0013】

市場調査会社のGartnerによると、IoTデバイスの数は2020年までに204億台に達する。IoTデバイスの数が増えるにつれて、従来の集中型モデルで管理する場合はコストがかかり、セキュリティ上のリスクが伴う。これに対し、台帳ベースの技術の分散型の性質は、IoTの自律性を実現する手段を提供する。

【0014】

IoTデバイスがネットワークに接続されている場合、デバイスのIDを確認するために認証する必要がある。サードパーティ製のデバイスを使用せずに、IoTデバイス認証に台帳ベースの技術を適用することで、認証コストを効果的に削減し、IoTデバイスのセキュリティを提供し、不正なデバイス偽装を防ぐことができる。また、外部からの攻撃からIoTデバイスを保護することもできる。さらに、台帳のコンセンサスメカニズムを変更することで、IoTデバイスに適用されるコンセンサスネットワークを構築することが可能である。

【0015】

IoT環境では、スマートデバイスノードは、データ計算作業やワークロードメカニズムの証明を行うのではなく、データの暗号化と転送のみを実行する。そのデータの転送は、台帳トランザクションとしてネットワーク全体にブロードキャストされる。台帳ベースの技術は、デバイスとユーザまたはネットワークサービス間で交換されるデータの台帳を保持することにより、個々のデバイスの独自の履歴を追跡する方法を構築することができる。また、台帳ベースの技術により、スマートデバイスを独立したエージェントにしたり、トランザクションを個別に管理したりすることもできる。

【0016】

要すれば、IoTに対する台帳ベースの技術の適用により、膨大な数のIoTデバイスに対して、低コストで安全な運用を提供する自己維持型のシステムが確立できる。

【0017】

しかし、台帳ベースの技術には２つの深刻な問題がある。第１の問題は、システムスループットが低いと、ネットワーク内の未処理トランザクションが無限に蓄積され、トランザクションの平均処理時間が増加する、という点である。その場合、台帳ベースの技術は、リアルタイムな処理が求められる場面において使用できない。

【0018】

第２の問題は、各検証ノードは、完全な履歴データの台帳と対応する状態情報とを個別に維持する必要があり、そのため、大量のストレージ資源を消費する、という点である。

【0019】

システムスループットが低い、という問題に対処するために、さまざまなスケーリング技術が提案されている。しかし、それらのスケーリング技術のほとんどは、セキュリティ、分散化、スケーラビリティという、台帳の３つの課題を同時に解決することができていない。

【0020】

これに対し、台帳の３つの課題を解決できる効果的な方法として、断片化技術が考えられる。

【0021】

大量のストレージ資源を消費する、という問題に対処するために、剪定技術(pruning technique)というものが提案されている。この技術においては、一部のノードにおいて、トランザクションとブロックの検証に役立たない履歴データは消去（剪定）され、検証状態情報のみが維持される。この方法によれば、台帳全体のサイズと履歴データの同期の問題を効果的に低減できる。ただし、台帳を剪定する手法は、履歴データによるディスクの容量不足は解決できるが、メモリの容量不足を解決することはできない。

【0022】

［実施形態］
上記の課題を解消するシステムとして、以下に、本発明の一実施形態として、LPWAN用軽量台帳ベースのポイント取引システム（以下、「ポイント取引システム１」という）を提案する。

【0023】

ポイント取引システム１により以下が実現される。
（１）タグ間のポイント取引が容易に行われる。
（２）台帳により、ポイントの残高が厳密に管理される。ポイントは特定の状況下で取引のための特別な通貨として使用することができるので、ポイントの残高を厳密に管理できることは重要である。
（３）LPWANを使用することで、障害発生時でもポイントが転送できる。障害が発生した場合、インターネットが部分的に中断される可能性がある。そのような場合でも、物理的接触を必要としないLPWANベースのポイント取引システム１は正常に動作する。

【0024】

ポイント取引システム１は、以下の環境下で運用可能である。
（ａ）タグの機能が制限されている。システム内のタグはバッテリ駆動であり、バッテリ交換の頻度は低い。
（ｂ）LPWANのノードの機能も制限されている。LPWANのノードの演算能力は非常に低く、ストレージ容量は非常に小さい。

【0025】

ポイント取引システム１は、通常時及び災害時のいずれにおいても機能する決済システムである。ポイント取引システム１においては、各イベントにおけるポイントの取引が分散台帳によりトレース可能である。ポイント取引システム１においては、台帳の構築により、トランザクションデータが改ざんされず、高い信頼性が保証される。

【0026】

図１は、ポイント取引システム１の構成の概要を示した図である。ポイント取引システム１においては、様々なタグがBluetoothによりポイント取引端末（例えば、スマートフォン）に接続できる。また、ポイント取引システム１においては、ポイント取引端末に対し、BluetoothによりLPWANのウィンドウノードが接続されている。

【0027】

ポイント取引システム１においては、システム台帳全体の不変性とセキュリティを確保するために、LPWANの演算能力の低さを考慮して、PoA（Proof of Authority）を簡素化した処理負荷の少ないコンセンサスが採用されている。

【0028】

ポイント取引システム１は、オープンAPIを通じて外部のビジネスシステムにサービスを提供する。一般的に、ビジネスシステムの利用者は、ビジネス管理者と一般ユーザ（以下、単に「ユーザ」という）に区分される。ユーザはビジネス管理者からポイント（例えば、コミュニティのプロモーションポイントや災害時の補償ポイントなど）を取得できる。

【0029】

ユーザは、タグとポイント取引端末を携帯している。タグは、ユーザの識別子として機能する。ポイント取引端末（例えば、ポイント取引アプリに従い動作するスマートフォン）は、ユーザのアカウントのポイント残高を検索し、ポイントによる支払を行う機能を持つ。

【0030】

ユーザは、ポイント取引端末の検索機能を用いて、自分のポイント残高、ポイント取引の明細、関与した注文の履歴などを確認できる。

【0031】

ユーザは、ポイント取引端末の注文機能を用いて、各種注文を行うことができる。ポイント取引は注文の登録により開始される。ユーザがビジネスシステムで注文の登録のための一連の操作を完了すると、ビジネスシステムはトランザクションシステムAPIを呼び出して、支払対象のユーザのID、受取人のID、トランザクションのポイント、注文時刻、有効期限などの情報を示す注文を作成する。トランザクションシステムは、注文に含まれる各パラメータを検証し、その有効性を確認した後、注文に一意の注文IDを割り当てる。

【0032】

上記のように作成された注文に関し、ユーザがポイントの支払を指示する操作を行うと、ビジネスシステムは注文IDを受け取り、取引システムの支払ページをポイント取引端末に表示させる。ユーザが支払ページにおいて支払われるポイントが正しいことを確認した後、支払の実行のための操作を行うと、支払が完了する。

【0033】

支払が完了すると、取引システムは、ビジネスシステムの所定ページをポイント取引端末に表示させる。支払結果は、非同期通知として事前に設定されたURLに送信される。なお、支払は注文処理が実行されないオフラインショップにおいても行うことができる。

【0034】

ビジネス管理者は、ユーザにポイントシステムを提供する組織等である。ビジネス管理者は、ネットワークの管理者と、ポイントシステムの管理者に区分される。ネットワークの管理者は、システムに新しい正規のノードを追加する権限を持っている。

【0035】

なお、ポイント取引システム１において採用されている、分散型台帳ベースのネットワークシステムは、ポイント取引サービス以外のサービスにおいても利用できるように、インタフェースが準備されている。

【0036】

ポイント取引システム１においては、ビットコインのブロックチェーンと同じように、すべてのノードが同じデータを含む台帳を保持する。ビットコインのブロックチェーンにおいては、コンセンサスプロトコルとして高負荷の演算を要するPoWが採用されているが、PoWはリソースの限られた環境には適さない。そこで、ポイント取引システム１においては、PoA (Proof of Authority) と類似のコンセンサスプロトコルだが、近隣の信頼できるノードを権威者(Authority)とすることで軽量（演算負荷、通信負荷、ストレージに対する負荷等が軽量）な新たなコンセンサスプロトコルが用いられる。

【0037】

図２は、ポイント取引システム１において行われる台帳の処理プロセスの概要を示した図である。ウィンドウノード(N0000)は、ポイント取引端末から受信したトランザクションの内容を示すデータであるトランザクションデータ（以下、「トランザクション」という）の有効性を確認すると、既存の台帳を参照し、受信したトランザクションを台帳に反映するために台帳に追加すべき増分のブロックの候補（以下、「ブロック候補」という）を生成し、そのブロック候補に自装置の独自の署名を付与した後、ブロードキャストする。

【0038】

ウィンドウノード(N0000)からブロック候補を受け取ったノード(例えば、N0001、N0002、N0003)は、受信したブロック候補を他のノードに転送するとともに、受信したブロック候補に付与されているウィンドウノード(N0000)の署名を検証し、ブロック候補の有効性を確認できた場合、そのブロック候補に自装置の独自の署名を付与した後、ブロードキャストする。

【0039】

他のノードを経由してウィンドウノード(N0000)からブロードキャストされたブロック候補（N0000の署名付き）を受け取ったノードも、ウィンドウノード(N0000)から直接、ブロック候補（N0000の署名付き）を受け取ったノードと同様の処理を行う。

【0040】

ウィンドウノード(N0000)は、各々に異なるノードの署名が付与されたブロック候補を全ノードの過半数（N個以上）収集できると、収集したそれらのブロック候補の内容が一致していることを確認した後、そのブロック候補を正しい増分のブロックとして台帳に追加する。同様に、他のノードも、各々に異なるノードの署名が付与されたブロック候補をN個以上収集できると、収集したそれらのブロック候補の内容が一致していることを確認した後、そのブロック候補を正しい増分のブロックとして台帳に追加する。

【0041】

図３は、上記のプロセスをノードに行わせるアルゴリズムの例を示した図である。

【0042】

図４は、ポイント取引システム１を利用して、ユーザが店舗にて何らかのサービスを受け（又は商品を購入して）、その対価としてポイントを店舗に支払う場合の取引の流れを例示した図である。

【0043】

ユーザは、タグとして、例えばディスプレイを備える可搬性デバイス（ICタグ）を携帯している。ユーザが、店舗で何らかのサービスを受け（又は商品を購入して）、その対価として、例えば１０ポイントを店舗に支払う場合、まず、（１）可搬性デバイスがBluetoothで自身のIDをブロードキャストする。続いて、（２）店舗所有のスマートフォンが、可搬性デバイスからブロードキャストされたIDを受信し、可搬性デバイスのユーザを特定する。特定されたユーザは、店舗所有のスマートフォンの画面に表示され、店員（サービス提供者）により確認される。

【0044】

続いて、（３）店舗所有のスマートフォンから可搬性デバイスに対し、１０ポイントの支払請求に関するトランザクションが送信される。（４）可搬性デバイスは、支払請求のトランザクションの受信に応じて、ディスプレイに１０ポイントの支払の同意を促す画面を表示する。この画面において、ユーザが１０ポイントの支払を承諾する操作を行う。（５）その操作に応じて、可搬性デバイスはトランザクションに署名を付与した後、そのトランザクションを店舗所有のスマートフォンに送信する。（６）店舗所有のスマートフォンは、署名が付与されたトランザクションをLPWANに登録する。（７）店舗所有のスマートフォンは、登録に対する応答として、LPWANから登録完了の通知を受け取る。

【0045】

［変形例］
上述した実施形態に係るポイント取引システム１は、本発明の技術的思想の範囲内において、様々に変形されてよい。以下にそれらの変形の例を示す。

【0046】

（１）上述した実施形態において、ブロック候補はウィンドウノード(N0000)のみによって生成される。これに代えて、複数のノードの各々がブロック候補を生成してもよい。この変形例においては、例えば、ウィンドウノード(N0000)は、ポイント取引端末から受け取ったトランザクションに自装置の独自の署名を付与し、ブロードキャストする。

【0047】

トランザクションを受け取った複数のノードの各々は、受け取ったトランザクションを他のノードに転送するとともに、受け取ったトランザクションに付与されているウィンドウノード(N0000)の署名を検証し、トランザクションの有効性を確認できた場合、既存の台帳を参照し、受信したトランザクションを台帳に反映するために台帳に追加すべき増分のブロックの候補（ブロック候補）を生成し、そのブロック候補に自装置の独自の署名を付与した後、ブロードキャストする。

【0048】

ウィンドウノードを含む各ノードは、各々に異なるノードの署名が付与されたブロック候補を全ノードの過半数（N個以上）収集できると、収集したそれらのブロック候補の内容が一致していることを確認した後、そのブロック候補を正しい増分のブロックとして台帳に追加する。

【0049】

この変形例による場合、ブロック候補の生成が複数のノードにより行われるため、仮にブロック候補の生成において誤りが生じたとしても、その誤ったブロック候補が台帳に追加されることはない。

【0050】

（２）上述した実施形態において、各ノードは、全ノードの過半数のブロック候補（各々が異なるノードの署名付き）を収集できた場合、内容が一致するそれらのブロック候補を増分のブロックとして採用し、台帳に追加する。各ノードが台帳に追加するブロックを採用するにあたり、収集すべきブロック候補の数は過半数に限られない。例えば、過半数より少ない数（例えば、全ノードの数の４０％等）を収集すべきブロック候補の数の閾値としてもよい。

【0051】

過半数に満たない数であっても、所定数以上のノードが同じブロック候補を有効と認めている場合、実用上、そのブロック候補は正当であるとみなして問題ない場合がある。そのような場合、収集すべきブロック候補の数の閾値を小さくすることで、通信速度、通信可能なデータ量等に制約のあるネットワークにおいても、処理の遅れが発生しにくくなる。

【符号の説明】

【0052】

１…ポイント取引システム

【図1】

【図2】

【図3】

【図4】