JP6657972B2 - 負荷分散システム、負荷分散装置、負荷分散方法、および、プログラム - Google Patents

負荷分散システム、負荷分散装置、負荷分散方法、および、プログラム Download PDF

Info

Publication number
JP6657972B2
JP6657972B2 JP2016002829A JP2016002829A JP6657972B2 JP 6657972 B2 JP6657972 B2 JP 6657972B2 JP 2016002829 A JP2016002829 A JP 2016002829A JP 2016002829 A JP2016002829 A JP 2016002829A JP 6657972 B2 JP6657972 B2 JP 6657972B2
Authority
JP
Japan
Prior art keywords
transaction data
edge server
store
edge
unit
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
JP2016002829A
Other languages
English (en)
Other versions
JP2017123116A (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.)
NEC Corp
Original Assignee
NEC Corp
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 NEC Corp filed Critical NEC Corp
Priority to JP2016002829A priority Critical patent/JP6657972B2/ja
Publication of JP2017123116A publication Critical patent/JP2017123116A/ja
Application granted granted Critical
Publication of JP6657972B2 publication Critical patent/JP6657972B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

本発明は、負荷分散システム、負荷分散装置、負荷分散方法、および、プログラムに関する。
クレジットカード、IC(Integrated Circuit)カードなどを用いた電子決済が行われている。例えば、特許文献1には、携帯電話を用いた電子マネーによる決済処理に関する技術が記載されている。
特開2014−11762号公報
特定の地域で利用可能な、商品券が各地域で発行されている。このような商品券は、紙媒体であることが多い。しかしながら、紙媒体の商品券は、発行コストがかかる。また、紙媒体の商品券の購入には、購入可能な店舗まで利用者が赴く必要があるため、この店舗に赴くことができない利用者は、商品券を購入できない。また、利用者にとっても、紙媒体は、紛失してしまう可能性がある。
また、特定の地域で利用可能な商品券を、例えば、クレジットカード、IC(Integrated Circuit)カードなどを用いた既存の電子決済に適用した場合、各店舗には、例えば、カードリーダライタのような設備の投資費および維持費、電子決済利用のための手数料がかかってしまう。また、利用者も上記カードを保有する必要がある。
これらの課題を解決するために、特定の地域で利用可能な商品券の決済を、例えば、P2P(peer−to−peer)型の決済網を利用した電子取引で行うことが考えられる。このような電子取引では、特定の地域でのみの取引にもかかわらず、決済処理に所定時間(例えば、10分)を要してしまう。その理由は、このような電子取引では、1以上の取引データをまとめたブロックのハッシュ値(ナンス値)を、上記決済網の参加者の何れかが計算するという計算処理が行われからである。このナンス値は、一般的に、計算量の大きな計算を行うことにより得られる値であるため、計算を行う装置には、大きな負荷が掛かってしまう。
本発明は上記課題に鑑みてなされたものであり、その目的は、利用者と店舗との間の電子取引における負荷を分散することが可能な技術を提供することにある。
本発明の一態様に係る負荷分散システムは、利用者が有する利用者端末と、店舗に設けられた店舗端末と、所定の金銭的価値を有する電子バリューを用いた、前記利用者と前記店舗との間の取引に関する取引データを所定のプロトコルに従って仲介する複数のエッジサーバと、負荷分散装置とを含み、前記負荷分散装置は、前記複数のエッジサーバの夫々の状態を示す状態情報を取得する取得手段と、前記複数のエッジサーバの夫々における、前記取得した状態情報に基づいて、前記複数のエッジサーバのうち、1以上の前記取引データを含む取引データ群に対するナンス値を計算するエッジサーバを決定する決定手段と、を備える。
また、本発明の一態様に係る負荷分散装置は、所定の金銭的価値を有する電子バリューを用いた、利用者と店舗との間の取引に関する取引データを所定のプロトコルに従って仲介する複数のエッジサーバの夫々の状態を示す状態情報を取得する取得手段と、前記複数のエッジサーバの夫々における、前記取得した状態情報に基づいて、前記複数のエッジサーバのうち、1以上の前記取引データを含む取引データ群に対するナンス値を計算するエッジサーバを決定する決定手段と、を備える。
また、本発明の一態様に係る負荷分散方法は、所定の金銭的価値を有する電子バリューを用いた、利用者と店舗との間の取引に関する取引データを所定のプロトコルに従って仲介する複数のエッジサーバの夫々の状態を示す状態情報を取得し、前記複数のエッジサーバの夫々における、前記取得した状態情報に基づいて、前記複数のエッジサーバのうち、1以上の前記取引データを含む取引データ群に対するナンス値を計算するエッジサーバを決定する。
なお、上記システム、装置または方法を、コンピュータによって実現するコンピュータプログラム、およびそのコンピュータプログラムが格納されている、コンピュータ読み取り可能な非一時的記録媒体も、本発明の範疇に含まれる。
本発明によれば、利用者と店舗との間の電子取引における負荷を分散することができる。
本発明の第1の実施の形態に係るシステムの構成の一例を示す図である。 本発明の第1の実施の形態に係る負荷分散装置の処理の流れの一例を示すフローチャートである。 本発明の第2の実施の形態に係るシステムの全体構成の一例を示す図である。 本発明の第2の実施の形態に係るシステムの全体構成の他の例を示す図である。 本発明の第2の実施の形態に係るシステムに含まれる各装置の機能構成の一例を示す機能ブロック図である。 本発明の第2の実施の形態における、利用者登録処理の流れの一例を示すフローチャートである。 本発明の第2の実施の形態における、店舗登録処理の流れの一例を示すフローチャートである。 本発明の第2の実施の形態における、決済処理の流れの一例を示すフローチャートである。 本発明の第2の実施の形態における、決済処理の流れの一例を示すフローチャートである。 本発明の第2の実施の形態における、決済処理の流れの一例を示すフローチャートである。 本発明の第2の実施の形態に係るシステムのネットワーク構成の一例を示す図である。 本発明の第2の実施の形態に係るシステムのネットワーク構成の一例を示す図である。 本発明の第2の実施の形態に係るシステムのネットワーク構成の一例を示す図である。 本発明の各実施の形態を実現可能なコンピュータ(情報処理装置)のハードウェア構成を例示的に説明する図である。
<第1の実施の形態>
本発明の第1の実施の形態について、図面を参照して詳細に説明する。図1は、本発明の第1の実施の形態に係るシステム(負荷分散システム)1の構成の一例を示すブロック図である。なお、図1に示すシステム1は、本発明に特有な構成について示したものであり、図1に示すシステム1が図1に示されていない構成を有していてもよいことは言うまでもない。図1に示す通り、システム1は、負荷分散装置10と、複数のエッジサーバ(40−1〜40−n(n>=2))と、利用者が所持する利用者端末20と、店舗に設けられた店舗端末30とを含む。なお、本実施の形態では、複数のエッジサーバ(40−1〜40−n)の夫々を区別しない場合、または、総称する場合には、これらをエッジサーバ40と呼ぶ。
また、図1に示す通り、本実施の形態に係る負荷分散装置10は、取得部11と、決定部12とを備える。なお、負荷分散装置10は、エッジサーバとは異なる装置で実現されることを例に説明を行うが、エッジサーバ内に設けられるものであってもよい。負荷分散装置10がエッジサーバ40内に設けられる場合、負荷分散装置10は、複数のエッジサーバ40の全てに設けられてもよいし、一部のエッジサーバ40に設けられてもよい。また、負荷分散装置10は、例えば、決済処理をまとめて管理する中央決済機関に設けられてもよい。システム1に含まれる複数のエッジサーバ40と利用者端末20と店舗端末30とは、所定のネットワーク上の装置である。所定のネットワークとは、例えば、所定の地域である。
エッジサーバ40は、所定の金銭的価値を有する電子バリュー(仮想通貨、仮想コインとも呼ぶ)を用いた取引に関する取引データを所定のプロトコルに従って仲介する。所定のプロトコルとは、例えば、ブロックチェーン技術が挙げられる。本実施の形態では、所定のプロトコルとして、ブロックチェーン技術を用いるとして説明を行う。
所定の金銭的価値を有する電子バリューとは、ポイントのような実際の紙幣や貨幣が存在しない通貨であってもよいし、実際の紙幣や通貨を基準として電子決済する際に利用する電子貨幣であってもよい。また、所定の金銭的価値を有する電子バリューとは、商品券のような有価証券を電子化したものであってもよい。
負荷分散装置10の取得部11は、複数のエッジサーバ40の夫々の状態を示す状態情報を取得する。取得部11は、状態情報を、複数のエッジサーバ40の夫々から取得してもよいし、複数のエッジサーバ40の夫々の状態を監視する図示しない監視サーバ等から取得してもよい。状態情報は、例えば、エッジサーバ40に掛かる負荷状態を表す負荷状態情報であってもよいし、エッジサーバ40の動作状態を表す動作状態情報であってもよいし、エッジサーバ40が有する性能を表す性能情報であってもよい。状態情報は、例えば、エッジサーバ40のCPU(Central Processing Unit)の使用率、エッジサーバ40に含まれるメモリの使用率等が挙げられるがこれに限定されるものではない。取得部11は、複数のエッジサーバ40の夫々に対する状態情報を、決定部12に供給する。
決定部12は、取得部11から複数のエッジサーバ40の夫々に対する状態情報を受け取る。決定部12は、受け取った状態情報に基づいて、複数のエッジサーバ40のうち、ナンス(nonce)値を計算するエッジサーバを決定する。ナンス値とは、1以上の取引データを含む取引データ群(ブロックとも呼ぶ)に含まれる、該取引データ群固有の値である。決定部12は、状態情報が負荷状態情報の場合、この負荷状態情報に基づいて、複数のエッジサーバ40のうち、例えば、最も負荷が小さいエッジサーバを、ナンス値を計算するエッジサーバとして決定する。
図2は、本実施の形態に係る負荷分散装置10の処理の流れの一例を示すフローチャートである。図2に示す通り、取得部11が、複数のエッジサーバの夫々の状態を示す状態情報を取得する(ステップS1)。そして、ステップS1で取得した状態情報に基づいて、決定部12が、複数のエッジサーバのうち、取引データ群のナンス値を計算するエッジサーバを決定する(ステップS2)。以上により、負荷分散装置10は、処理を終了する。
一般的に、ナンス値の計算には、大きな負荷が掛かる。したがって、1つのエッジサーバのみが、複数の取引データ群の夫々のナンス値の計算を行うと、この1つのエッジサーバに大きな負荷が掛かってしまう。しかしながら、本実施の形態に係るシステム1では、負荷分散装置10の決定部12が複数のエッジサーバの夫々の状態情報に基づいて、ナンス値を計算するエッジサーバを決定する。これにより、ナンス値の計算を行うタイミングにおいて、負荷分散装置10は、例えば、負荷がより小さいエッジサーバ、高性能なエッジサーバなど、ナンス値を計算するのに適したエッジサーバを決定することができる。これにより、システム1は、システム1に含まれるある特定のエッジサーバに負荷が掛からないようにすることができる。したがって、システム1は、システム1に含まれるエッジサーバ40の負荷分散を行うことができる。
また、エッジサーバの負荷分散を行うことにより、システム1は、利用者と店舗との間の取引に対する決済処理の時間を短くすることができる。
<第2の実施の形態>
次に、上述した第1の実施の形態を基本とする第2の実施の形態について説明する。まず、本実施の形態に係るシステム(負荷分散システム)2の全体構成を、図3を用いて説明する。図3は、本実施の形態に係るシステム2の全体構成の一例を示す図である。図3に示す通り、本実施の形態に係るシステム2は、複数のエッジサーバ(100−1〜100−n(n>=2))と、利用者端末200と、店舗端末300と、を含む。なお、図3に示すシステム2に含まれる装置は、本実施の形態に特有な構成について示したものであり、図3に示すシステム2が、図3に示されていない構成を有していてもよいことは言うまでもない。
なお、本実施の形態では、複数のエッジサーバ(100−1〜100−n)の夫々を区別しない場合、または、総称する場合には、これらをエッジサーバ100と呼ぶ。また、図3では、利用者端末200と、店舗端末300とを1つずつ示しているが、利用者端末200と店舗端末300とは、複数であってもよい。
エッジサーバ100と、利用者端末200と、店舗端末300とは、ネットワークを介して、互いに通信可能に接続している。
店舗端末300は、複数の店舗の夫々に設置された、例えば、POS(Point Of Sales)端末によって実現される。店舗端末300は、1つの店舗において、複数であってもよい。また、店舗端末300は、1以上のPOS端末が設置されている店舗において、1以上のPOS端末から出力された情報を管理するPOSシステムであってもよい。また、店舗が電子商店の場合、店舗端末300は、例えば、該電子商店を関するサーバであってもよい。また、本実施の形態では、店舗は、所定の範囲内(例えば、所定の地域)で商品の販売を行っている店舗であるとする。
利用者端末200は、利用者が所持する端末であり、例えば、スマートフォン、タブレットおよびウェアラブル端末等の移動端末であってもよく、デスクトップ型のパーソナルコンピュータであってもよい。利用者端末200は、所定の範囲内で商品の販売を行う店舗と、取引を行うことができる端末である。
エッジサーバ100は、上述した所定の範囲内の店舗が有する店舗端末300、および、所定の範囲内の店舗を利用可能な利用者の利用者端末200に接続するサーバである。エッジサーバ100は、例えば、所定の閉域網上に配置されている。エッジサーバ100は、所定の金銭的価値を有する電子バリューを用いた利用者と店舗との間の取引に関する取引データを所定のプロトコルに従って仲介する。本実施の形態では、所定のプロトコルが、ブロックチェーン技術であるとして説明を行う。また、本実施の形態では、電子バリューを仮想通貨と呼ぶ。
なお、本実施の形態では、図3に示す通り、第1の実施の形態において説明した負荷分散装置10が複数のエッジサーバ100の夫々に含まれる構成について説明する。なお、負荷分散装置10は、一部のエッジサーバ100に含まれるものであってもよい。また、負荷分散装置10は、エッジサーバ100とは異なる装置内に設けられるものであってもよい。負荷分散装置10がエッジサーバ100とは異なる装置内に設けられる例を、図4を用いて説明する。図4は、システム2の他の構成の一例を示す図である。図4に示すシステム2に含まれる負荷分散装置10は、エッジサーバ100とネットワークを介して接続された、決済処理をまとめて管理する中央決済機関に設けられるものであってもよい。
図5は、本実施の形態に係るシステム2における、エッジサーバ100、利用者端末200および店舗端末300の機能構成の一例を示す機能ブロック図である。
(利用者端末200)
図5に示す通り、本実施の形態に係るシステム2における利用者端末200は、生成部210と、送信部220と、記憶部230と、取得部240と、受信部250とを備えている。なお、本実施の形態では、店舗または利用者が所持する仮想通貨が管理(保持)されている場所を仮想通貨の財布の場所と呼ぶ。つまり、説明の便宜上、この場所に管理された仮想通貨をひとまとめにしたものを、仮想通貨の財布と呼ぶ。仮想通貨の財布には、該財布を有する店舗または利用者が保持する仮想通貨が含まれるとも言える。仮想通貨の財布は、例えばフォルダ等で表現することができる。この場合、仮想通貨の財布の場所とは、このフォルダの場所である。
取得部240は、店舗端末300から、商品情報と、店舗アドレスとを取得する。取得部240による商品情報と店舗アドレスとの取得方法は、後述する。取得部240が店舗端末300から取得した商品情報と店舗アドレスとは、店舗端末300の秘密鍵で暗号化されている。取得部240は、この暗号化された商品情報と店舗アドレスとを生成部210に供給する。
生成部210は、利用者固有の秘密鍵と公開鍵とを生成する。生成部210が生成した秘密鍵と公開鍵とを、夫々、利用者の秘密鍵、利用者の公開鍵と呼ぶ。この秘密鍵は、数字と記号との組み合わせで表現されるものであってもよい。生成部210は、まず、秘密鍵を生成し、生成した秘密鍵に基づいて、公開鍵を生成してもよい。
また、生成部210は、生成した秘密鍵と公開鍵とを用いて、利用者端末200を有する利用者が利用する、仮想通貨の財布の場所(例えば、口座番号)に相当するアドレスを生成する。生成部210は、秘密鍵と公開鍵とを用いて、例えば、ハッシュ計算を行うことにより、上記アドレスを生成する。利用者端末200が生成するアドレスを、以下では利用者アドレスと呼ぶ。
これにより、利用者は、利用者アドレスによって示される場所で管理された仮想通貨を用いて、取引を行うことができる。
本実施の形態では、この利用者アドレスによって示される、仮想通貨の財布の場所は、利用者端末200内であるとするが、利用者端末200と通信可能に接続された他の装置上であってもよい。例えば、仮想通貨の財布の場所は、インターネットを介して接続された他のサーバ上であってもよい。
また、仮想通貨の財布に含まれる仮想通貨は、該財布内の仮想通貨を利用可能に設定された複数の利用者端末200で利用されてもよい。例えば、利用者が複数の利用者端末200を有している場合、これら複数の利用者端末200の夫々において仮想通貨の財布を利用可能な設定を行うことによって、利用者が複数の利用者端末200の夫々から該財布内の仮想通貨を利用できるようにしてもよい。
生成部210は、生成した秘密鍵、公開鍵および利用者アドレスを、互いに関連付けて、記憶部230に格納する。また、生成部210は、生成した公開鍵を、送信部220に供給する。
また、生成部210は、取得部240から商品情報と店舗アドレスとを受け取る。生成部210は、受け取った商品情報および店舗情報と、利用者アドレスとを含み、利用者の秘密鍵で暗号化した取引データを生成する。
また、生成部210は、受信部250から、店舗の公開鍵を受け取ると、利用者の電子署名を生成する。また、生成部210は、受信部250がブロックチェーンにブロック(取引データ群)が追加される度に受信する、追加されたブロックのハッシュ値を、受信部250から受け取る。生成部210は、取引データに対して、受け取ったハッシュ値と、受け取った店舗の公開鍵とを加えたデータのハッシュ値を計算する。そして、計算したハッシュ値を、利用者の秘密鍵で暗号化し、暗号化したハッシュ値を電子署名として生成する。そして、生成部210は、生成した電子署名を添付した取引データを生成する。生成部210は、この電子署名を添付した取引データを送信部220に供給する。
送信部220は、生成部210から、生成部210が生成した、利用者の公開鍵を受け取る。送信部220は、エッジサーバ100に対し、受け取った利用者の公開鍵を送信する。送信部220が利用者の公開鍵を送信する宛先(送信先)のエッジサーバ100は、複数のエッジサーバ100の何れであってもよいし、利用者端末200との距離が最も近いエッジサーバ100であってもよい。なお、送信部220は、利用者の公開鍵の送信先のエッジサーバ100に関する情報を、記憶部230に格納してもよい。例えば、送信部220は、利用者端末200が通信可能なエッジサーバ100(例えば、利用者端末200との距離が最も近いエッジサーバ100)に関する情報を、記憶部230に格納してもよい。エッジサーバ100に関する情報は、たとえば、エッジサーバ100のIP(Internet Protocol)アドレスであってもよいし、その他の情報であってもよい。
また、送信部220は、エッジサーバ100に対し、利用者端末200の認証を要求する認証要求メッセージを送信する。また、送信部220は、エッジサーバ100に対し、店舗の公開鍵の送信依頼を送信する。
また、送信部220は、生成部210から、電子署名が添付された取引データを受け取る。送信部220は、この電子署名が添付された取引データを、エッジサーバ100に送信する。送信部220が取引データを送信する宛先(送信先)のエッジサーバ100は、複数のエッジサーバ100の何れであってもよいし、所定のエッジサーバであってもよい。所定のエッジサーバとは、例えば、利用者端末200との距離が最も近いエッジサーバ100であるが、これに限定されるものではない。利用者端末200と距離が近いエッジサーバ100に取引データを送信する構成の場合、システム2は、取引データの送信に掛かる時間を削減することができる。
記憶部230は、互いに関連付けられた、利用者の秘密鍵、公開鍵および利用者アドレスを格納する。なお、記憶部230は、利用者端末200とは別個の記憶装置によって実現されるものであってもよい。つまり、利用者の秘密鍵、公開鍵および利用者アドレスは、利用者端末200とは別個のサーバ上で管理されるものであってもよい。また、利用者の秘密鍵、公開鍵および利用者アドレスは、例えば、これらが印字された紙によって管理されるものであってもよい。
受信部250は、ブロックチェーンにブロックが追加される度に、追加されたブロックのハッシュ値を受信する。受信部250は受信したハッシュ値を生成部210に供給する。
受信部250は、エッジサーバ100から認証要求メッセージの応答メッセージを受信する。認証要求メッセージ受信後の処理は、図8から図10に示すフローチャートを用いて説明する。
また、受信部250は、エッジサーバ100から、店舗の公開鍵の送信要求に対する応答として、店舗の公開鍵を受信する。受信部250は、受信した店舗の公開鍵を、生成部210に供給する。
また、受信部250は、エッジサーバ100から、最新のブロックのナンス値を受信する。受信部250は、受信したナンス値を、生成部210に供給する。
なお、利用者端末200上において、仮想通貨を利用する際に用いる専用のアプリケーションプログラムが起動した状態の場合に、利用者が仮想通貨を用いた取引を行うことができてもよい。つまり、利用者端末200内の各部の機能は、この専用のアプリケーションプログラムが実行されることで実現されてもよい。
(店舗端末300)
図5に示す通り、本実施の形態に係るシステム2における、店舗端末300は、生成部310と、送信部320と、記憶部330と、出力部340とを備えている。
生成部310は、店舗固有の秘密鍵と公開鍵とを生成する。生成部310が生成した秘密鍵と公開鍵とを、夫々、該店舗の秘密鍵、店舗の公開鍵と呼ぶ。この秘密鍵は、数字と記号との組み合わせで表現されるものであってもよい。生成部310は、まず、秘密鍵を生成し、生成した秘密鍵に基づいて、公開鍵を生成してもよい。
また、生成部310は、生成した秘密鍵と公開鍵とを用いて、店舗端末300が設けられた店舗が利用する、仮想通貨の財布の場所(例えば、口座番号)に相当するアドレスを生成する。生成部310は、秘密鍵と公開鍵とを用いて、例えば、ハッシュ計算を行うことにより、上記アドレスを生成する。店舗端末300が生成するアドレスを、以下では店舗アドレスと呼ぶ。
なお、本実施の形態では、店舗アドレスによって示される仮想通貨の財布の場所は、店舗端末300内であるとするが、店舗端末300と通信可能に接続された他の装置上であってもよい。例えば、仮想通貨の財布の場所は、インターネットを介して接続された他のサーバ上であってもよい。
また、店舗の財布に含まれる仮想通貨は、利用者の財布に含まれる仮想通貨と同様に、利用可能に設定された複数の店舗端末300で利用されてもよい。
生成部310は、生成した秘密鍵、公開鍵および店舗アドレスを、互いに関連付けて、記憶部330に格納する。また、生成部310は、生成した公開鍵を、送信部320に供給する。
また、生成部310は、商品の金額(仮想通貨の取引量)を示す情報を少なくとも含む商品情報と、店舗の財布の場所(店舗アドレス)とを暗号化したデータを生成する。このとき、生成部310は、暗号化したデータ(商品データと呼ぶ)を表現する識別子を生成してもよい。この識別子は、例えば、バーコードであってもよいし、二次元コードであってもよいし、その他の情報であってもよい。生成部310は、生成した商品データまたは識別子を出力部340に供給する。
送信部320は、生成部310から、生成部310が生成した店舗の公開鍵を受け取る。送信部320は、エッジサーバ100に対し、受け取った店舗の公開鍵を送信する。送信部320が店舗の公開鍵を送信する宛先(送信先)のエッジサーバ100は、複数のエッジサーバ100の何れであってもよいし、店舗端末300との距離が最も近いエッジサーバ100であってもよい。
記憶部330は、互いに関連付けられた、店舗の秘密鍵、公開鍵および店舗アドレスを格納する。なお、記憶部330は、店舗端末300とは別個の記憶装置によって実現されるものであってもよい。つまり、店舗の秘密鍵、公開鍵および店舗アドレスは、店舗端末300とは別個のサーバ上で管理されるものであってもよい。また、店舗の秘密鍵、公開鍵および店舗アドレスは、例えば、これらが印字された紙によって管理されるものであってもよい。
出力部340は、生成部310から商品データまたは識別子を受け取る。出力部340は、生成部310から受け取った商品データまたは識別子を出力する。出力部340が生成部310から受け取ったデータが識別子の場合、出力部340は、所定の用紙に識別子を印字することにより、識別子を出力してもよい。また、出力部340が生成部310から受け取ったデータが識別子の場合、出力部340は、図示しない表示画面に識別子を表示させることにより、識別子を出力してもよい。このような構成によって、本実施の形態における店舗端末300は、例えば、電子貨幣の利用の際に必要なリーダライタなどを設けることなく、商品の取引を行うことができる。
また、出力部340が受け取ったデータが商品データの場合、出力部340は、利用者端末200に商品データを出力(送信)してもよい。この場合、出力部340は、送信部320と一体となって形成されていてもよい。
出力部340は、例えば、近距離無線通信規格を用いた通信によって、商品データを利用者端末200に送信してもよい。近距離無線通信規格としては、例えば、Bluetooth(登録商標)、NFC(Near Field Communication)等であってもよい。また、出力部340は、赤外線通信によって、商品データを利用者端末200に送信してもよい。また、利用者端末200と店舗端末300との間で通信を行うことができる、アプリケーションプログラムを、利用者端末200および店舗端末300上で起動させることにより、店舗端末300は、利用者端末200に、商品データを送信してもよい。また、店舗端末300は、SMS(Short Message Service)、SNS(Social Network Service)等のサービスを利用して、利用者端末200に、商品データを送信してもよい。また、店舗端末300は、電子メールを用いて、利用者端末200に商品データを送信してもよい。以上のように、店舗端末300が、利用者端末200に対し、商品データを送信する方法は特に限定されない。
なお、店舗端末300上において、仮想通貨を利用する際に用いる専用のアプリケーションプログラムが起動した状態の場合に、店舗が仮想通貨を用いた取引を行うことができてもよい。つまり、店舗端末300内の各部の機能は、この専用のアプリケーションプログラムが実行されることで実現されてもよい。
(エッジサーバ100)
図5に示す通り、本実施の形態に係るシステム2における、エッジサーバ100は、取得部110と、決定部120と、記憶部130と、受信部140と、送信部150と、計算部160と、認証部170と、を備える。取得部110および決定部120は、夫々、上述した第1の実施の形態における取得部11および決定部12に相当する。つまり、図5において、破線の枠で囲った部分は、上述した第1の実施の形態における負荷分散装置10に相当する。
取得部110は、後述する、承認前のブロックが生成されたことを示す通知を、計算部160から受け取る。取得部110は、上記通知を受け取ると、複数のエッジサーバ100の夫々の状態を示す状態情報を取得する。取得部110は、状態情報を、複数のエッジサーバ100の夫々から取得してもよいし、複数のエッジサーバ100の夫々の状態を監視する図示しない監視サーバ等から取得してもよい。状態情報は、例えば、エッジサーバ100に掛かる負荷状態を表す負荷状態情報であってもよいし、エッジサーバ100の動作状態を表す動作状態情報であってもよいし、エッジサーバ100が有する性能を表す性能情報であってもよい。取得部110は、取得した、複数のエッジサーバ100の夫々に対する状態情報を、決定部120に供給する。
決定部120は、取得部110から複数のエッジサーバ100の夫々に対する状態情報を受け取る。決定部120は、受け取った状態情報に基づいて、複数のエッジサーバ100のうち、承認前のブロックのナンス値を計算するエッジサーバを決定する。例えば、決定部120は、状態情報が負荷状態情報の場合、この負荷状態情報に基づいて、複数のエッジサーバ100のうち、最も負荷が小さいエッジサーバを、ナンス値を計算するエッジサーバとして決定する。決定部120は、決定したエッジサーバを示す情報(決定結果)を計算部160に供給する。
受信部140は、利用者端末200から利用者の公開鍵を受信する。受信部140は利用者の公開鍵の送信元である利用者端末200を識別する情報を、受信した利用者の公開鍵に関連付けて、記憶部130に格納する。また、受信部140は、店舗端末300から店舗の公開鍵を受信する。受信部140は店舗の公開鍵の送信元である店舗端末300を識別する情報を、受信した店舗の公開鍵に関連付けて、記憶部130に格納する。
また、受信部140は、利用者端末200から認証要求メッセージを受信する。受信部140は、受信した認証要求メッセージを認証部170に供給する。
また、受信部140は、利用者端末200から、店舗の公開鍵の送信依頼を受信する。受信部140は、受信した、店舗の公開鍵の送信依頼を、送信部150に供給する。
また、受信部140は、利用者端末200から、電子署名が添付された取引データを受信する。受信部140は、受信した取引データを計算部160に供給する。
なお、この受信部140における、認証要求メッセージおよび/または電子署名が添付された取引データを受信する機能は、エッジサーバ100が備える受信部140の全てに含まれる機能であってもよいし、一部に含まれる機能であってもよい。例えば、認証要求メッセージを受信するエッジサーバ100がエッジサーバ100−1のみの場合、後述する認証部170による認証処理を集約することができる。この場合、このエッジサーバ100−1以外のエッジサーバ100は、後述する認証部170を備えなくてもよい。
また、受信部140は、他のエッジサーバ100から、ナンス値が含まれている、または、ナンス値が含まれていないブロックを受信すると、該ブロックを計算部160に供給する。
記憶部130は、店舗を識別する情報に関連付けられた、店舗の公開鍵を格納する。また、記憶部130は、利用者を識別する情報に関連付けられた、利用者の公開鍵を格納する。なお、記憶部130内に格納された店舗の公開鍵および利用者の公開鍵が更新(追加)される度に、エッジサーバ100は、各エッジサーバ100の記憶部130に格納された公開鍵の整合を取ることが好ましい。これにより、利用者端末200または店舗端末300から送信された暗号化データを、全てのエッジサーバ100で復号することができる。
また、記憶部130は、ブロックチェーンにつながった、1以上の取引データを含むブロックを格納する。
なお、記憶部130は、エッジサーバ100とは別個の記憶装置で実現されるものであってもよい。この記憶装置は、複数のエッジサーバ100の夫々からアクセス可能な位置に配置されていればよい。これにより、複数のエッジサーバ100で、記憶部130に格納されたデータを共有することができる。
また、記憶部130に格納されたデータの一部(例えば、店舗の公開鍵および利用者の公開鍵)が、エッジサーバ100とは異なる記憶装置に格納されていてもよい。
計算部160は、受信部140が受信した取引データを、該取引データを送信した送信元の利用者端末200に関する公開鍵で復号する。取引データには、店舗の秘密鍵で暗号化された商品情報および店舗アドレスが含まれる。そのため、計算部160は、記憶部130に格納された全ての店舗の公開鍵を用いて、暗号化された商品情報および店舗アドレスを復号する。そして、計算部160は、新たなブロックに含める取引データを、取引データが生成された順にまとめる。この取引データをまとめたブロックは、承認が行われる前のブロックであるため、承認前のブロックとも呼ぶ。そして、計算部160は、この承認前のブロックが生成されたことを示す通知を、取得部110に供給する。
また、計算部160は、決定部120から決定結果を受け取る。計算部160は、決定結果に基づいて、決定部120が決定したエッジサーバが自サーバか否かを確認する。自サーバではない場合、計算部160は、決定結果と承認前のブロックとを、送信部150に供給する。
計算部160は、確認結果が自サーバの場合、または、受信部140からナンス値が含まれていない承認前のブロックを受信した場合、承認前のブロックのナンス値を計算する。計算部160は、計算したナンス値と、承認前のブロックの直前のブロックのハッシュ値(ブロックチェーンに含まれるブロックのうち最新のブロックのナンス値)とを、承認前のブロックに含めて、該承認前のブロックを送信部150に供給する。
また、計算部160は、受信部140からナンス値が含まれる承認前のブロックを受信すると、該承認前のブロックに含まれるナンス値を検算する。
認証部170は、受信部140から認証要求メッセージを受け取る。受信部140は、受け取った認証要求メッセージの送信元(つまり、利用者端末200)に関する公開鍵を記憶部130から取得し、該公開鍵を用いて、認証要求メッセージを復号する。そして、認証部170は、復号した認証要求メッセージに基づいて、認証要求メッセージを送信した利用者端末200の認証を行う。そして、認証部170は、認証結果を送信部150に供給する。
送信部150は、認証部170から認証結果を受け取る。送信部150は、認証要求メッセージの応答メッセージとして、受け取った認証結果を、認証要求メッセージの送信元である利用者端末200に送信する。
また、送信部150は、受信部140から、店舗の公開鍵の送信依頼を受け取る。そして、該送信依頼に関連する店舗の公開鍵を記憶部130から取得し、取得した公開鍵を、利用者端末200に送信する。
また、送信部150は、計算部160から、計算されたナンス値を含む、承認前のブロックを受信すると、該承認前のブロックを他のエッジサーバ100に同報する。
また、送信部150は、計算部160から、ナンス値を含まない承認前のブロックを決定結果と共に受信すると、該承認前のブロックを、決定結果によって示されるエッジサーバに送信する。
(利用者登録処理の流れ)
次に、利用者が仮想通貨を利用する際の、登録(利用者登録)処理の流れについて説明する。この利用者登録処理は、利用者端末200からエッジサーバ100に対して、仮想通貨を利用した取引を行うために必要な情報を送信する処理である。図6は、本実施の形態における、利用者登録処理の流れの一例を示すフローチャートである。
図6に示す通り、まず、利用者端末200の生成部210が、利用者固有の秘密鍵と公開鍵とを生成する(ステップS61)。そして、生成部210は、生成した秘密鍵と公開鍵とを用いて、利用者アドレスを生成する(ステップS62)。
その後、生成部210は、生成した秘密鍵、公開鍵および利用者アドレスを、互いに関連付けて、記憶部230に格納する(ステップS63)。そして、送信部220は、エッジサーバ100に対し、生成部210から供給された公開鍵を送信する(ステップS64)。なお、ステップS63とステップS64とは同時に行われてもよいし、逆順で行われてもよい。
以上により、利用者登録処理を終了する。
このように、利用者端末200がエッジサーバ100に対して、利用者の公開鍵を送信することにより、利用者端末200は、利用者アドレスによって示される場所で管理された仮想通貨を利用することができる。
(店舗登録処理の流れ)
次に、店舗が仮想通貨を利用する際の、登録(店舗登録)処理の流れについて説明する。この店舗登録処理は、店舗端末300からエッジサーバ100に対して、仮想通貨を利用した取引を行うために必要な情報を送信する処理である。図7は、本実施の形態における、店舗登録処理の流れの一例を示すフローチャートである。
図7に示す通り、まず、店舗端末300の生成部310が、店舗固有の秘密鍵と公開鍵とを生成する(ステップS71)。そして、生成部310は、生成した秘密鍵と公開鍵とを用いて、店舗アドレスを生成する(ステップS72)。
その後、生成部310は、生成した秘密鍵、公開鍵および店舗アドレスを、互いに関連付けて、記憶部330に格納する(ステップS73)。そして、送信部320は、エッジサーバ100に対し、生成部310から供給された公開鍵を送信する(ステップS74)。なお、ステップS73とステップS74とは同時に行われてもよいし、逆順で行われてもよい。
以上により、店舗登録処理を終了する。
このように、店舗端末300がエッジサーバ100に対して、店舗の公開鍵を送信することにより、店舗端末300は、店舗アドレスによって示される場所で管理された仮想通貨を利用することができる。
(仮想通貨を用いた商品の取引について)
本実施の形態に係るシステム2では、仮想通貨を用いた取引は、上述したシステム1と同様に、一般的なブロックチェーン技術を用いる。したがって、エッジサーバ100の送信部150は、ブロックチェーンにブロックが追加される度に、追加されたブロックのハッシュ値を、仮想通貨を利用可能な利用者の利用者端末200に送信する。追加されたブロックは、ブロックチェーンにおける、最新のブロックであって、承認済みのブロックである。ブロックチェーンにブロックが追加されたこと(つまり、全てのエッジサーバ100で承認が行われたブロックが、記憶部130に格納されたこと)は、送信部150が確認してもよいし、計算部160が確認してもよい。これにより、仮想通貨を利用可能な利用者の利用者端末200間で、最新のブロックのハッシュ値を共有することができる。
(利用者端末200による商品情報の取得の流れ)
利用者端末200が、商品の金額を示す情報を少なくとも含む商品情報を、店舗の財布の場所(店舗アドレス)と共に、受信するまでの流れについて説明する。なお、店舗の店舗端末300は、予め販売する商品または提供するサービスの代金を仮想通貨に換算しているとする。
例えば、店舗が、実際に存在する実店舗であり、利用者端末200が、移動端末である場合について説明する。利用者が実店舗において、商品の購入手続きを行うと、店舗の店舗端末300の生成部310は、商品情報と、店舗アドレスとを情報として含み、店舗の秘密鍵で暗号化した識別子を生成する。本実施の形態では、識別子が二次元コードであるとして説明を行う。そして、出力部340は、生成部310が生成した識別子を出力する。
利用者は、利用者端末200に、店舗端末300から出力された二次元コードを読み取らせる。つまり、利用者端末200の取得部240が、店舗端末300から出力された二次元コードを読み取る。上述したとおり、二次元コードには、商品情報と、店舗アドレスとが含まれる。これにより、利用者端末200は、店舗の秘密鍵で暗号化された、商品情報と店舗アドレスとを取得することができる。
また、店舗端末300の生成部310が生成したデータが、商品情報と店舗アドレスとを該生成部310によって暗号化した商品データの場合、利用者端末200の取得部240は、店舗端末300から、例えば、上述した所定のサービス等を利用して、商品情報と店舗アドレスとを受信(取得)してもよい。
また、例えば、店舗が電子商店の場合、店舗端末300は、商品情報と店舗アドレスとを暗号化した商品データを生成する。そして、利用者端末200の取得部240は、ネットワークを介して、暗号化された商品データを受信する。この商品データには、上述したとおり、商品情報と店舗アドレスとが含まれるため、利用者端末200は、店舗の秘密鍵で暗号化された商品情報と店舗アドレスとを取得することができる。
以上のように、利用者端末200は、店舗端末300から、店舗の秘密鍵で暗号化された商品情報と店舗アドレスとを取得することができる。
なお、利用者端末200は、店舗端末300から送信される商品情報によって示される商品の金額を、図示しない表示画面に表示してもよい。このとき、店舗端末300は、店舗の秘密鍵で暗号化した商品情報とは別に、利用者端末200に商品情報を送付してもよい。また、このとき、利用者端末200は、エッジサーバ100から店舗端末300の公開鍵を取得し、暗号化された商品情報を、取得した店舗の公開鍵で復号してもよい。これにより、利用者は、取引する商品の金額を確認することができる。
(システム2の決済処理の流れ)
次に、利用者端末200が商品情報と店舗アドレスとを受信した後の、システム2の決済処理について説明する。図8から図10は夫々、本実施の形態における、決済処理の流れの一例を示すフローチャートである。なお、図8および図9では、利用者端末200の処理を左側に、エッジサーバ100の処理を右側に示している。また、エッジサーバ100の処理と、利用者端末200の処理との間の破線の矢印はデータの流れを示している。また、本実施の形態において、後述するナンス値を計算するエッジサーバを決定するエッジサーバは、あらかじめ決まっているとして説明を行う。
図8に示す通り、利用者端末200の生成部210が、取得部240が読み取った(取得した)、店舗の秘密鍵で暗号化された商品情報および店舗アドレスと、利用者の財布の場所(利用者アドレス)とを含み、利用者の秘密鍵で暗号化した取引データを生成する(ステップS81)。
そして、利用者端末200の送信部220は、エッジサーバ100に対し、取引の認証要求メッセージを送信する(ステップS82)。認証要求メッセージには、利用者の秘密鍵で暗号化された、利用者を識別する情報(利用者識別情報)が含まれる。そして、エッジサーバ100の受信部140は、利用者端末200から送信された認証要求メッセージを受信する(ステップS83)。
そして、認証部170が、認証要求メッセージを送信した利用者端末200の認証を行う(ステップS84)。送信部150は、認証要求メッセージの応答メッセージとして、利用者端末200に送信する(ステップS85)。
その後、利用者端末200の受信部250は、応答メッセージを受信する(ステップS86)。そして、受信部250は、応答メッセージに基づいて、認証されたか否かを確認し(ステップS87)する。認証された場合(ステップS87にてYES)、受信部250は、送信部220に、商品の購入手続きを行っている店舗の公開鍵の送信依頼の送信指示を行い、送信部220は、該送信依頼を、エッジサーバ100に送信する(ステップS88)。送信部220が送信する送信依頼に関連する店舗を特定する情報は、例えば、識別子を読み取る際に、識別子と共に取得されるものであってもよいし、商品データを取得する際に、該商品データと共に取得するものであってもよい。また、商品データがネットワークを介して送信されたものであった場合、送信部220が送信する送信依頼に関連する店舗を特定する情報は、商品データの送信元から特定されるものであってもよい。
なお、本実施の形態では、認証されなかった場合(ステップS87にてNO)、認証処理を終了するとするが、利用者端末200は、例えば、ステップS82に戻って、再度、認証要求メッセージを送信してもよい。
また、認証結果が認証されなかったことを示す場合、送信部150は、応答メッセージを送信しなくてもよい。この場合、利用者端末200は、認証要求メッセージを送信してから所定期間内に応答メッセージを受信しなかった場合に、認証されなかったことを示す情報を表示画面に表示し、決済処理を終了してもよい。
ステップS88終了後、エッジサーバ100の受信部140が店舗の公開鍵の送信依頼を、受信する(ステップS89)。その後、送信部150は、受信部140が受信した送信依頼に関連する店舗の公開鍵を記憶部130から取得し、取得した公開鍵を、利用者端末200に送信する(ステップS90)。
利用者端末200の受信部250は、エッジサーバ100から、店舗の公開鍵を受信する(ステップS91)。そして、生成部210は、利用者の電子署名を生成する(ステップS92)。その後、送信部220は、ステップS92で生成された電子署名が添付された、ステップS81で生成された取引データを、エッジサーバ100に送信する(ステップS93)。これにより、利用者のなりすましを防ぐことができる。
その後、エッジサーバ100の受信部140は、利用者端末200から送信された、電子署名が添付された取引データを受信する(ステップS94)。なお、この取引データを受信するエッジサーバ100は、ステップS90までの処理を行ったエッジサーバ100と同じエッジサーバであってもよいし、異なるエッジサーバであってもよい。
エッジサーバ100の計算部160は、受信部140が受信した取引データを、該取引データを送信した送信元の利用者端末200に関する公開鍵で復号する(ステップS95)。取引データには、上述したとおり、店舗の秘密鍵で暗号化された商品情報および店舗アドレスが含まれる。そのため、計算部160は、記憶部130に格納された全ての店舗の公開鍵を用いて、暗号化された商品情報および店舗アドレスを復号する(ステップS96)。ステップS96以降のエッジサーバ100および利用者端末200の処理は、図9に示す。
その後、エッジサーバ100の計算部160は、取引データを、該取引データが生成された順にまとめた、承認前のブロックを生成する(ステップS97)。このとき、計算部160は、所定数または所定サイズの取引データをまとめてもよいし、所定時間毎に取引データをまとめてもよい。なお、取引データが他のエッジサーバ100に送信されている場合、ステップS97を行う前に、所定のエッジサーバに取引データを集約する構成であってもよい。所定のエッジサーバとは、承認前のブロックに含まれる取引データのうち、最も古い(取引が行われた時刻が一番早い)取引データを受信したエッジサーバであってもよい。また、所定の取引データは、ナンス値を計算するエッジサーバを決定する処理を行うエッジサーバに集約される構成であってもよい。
そして、エッジサーバ100の取得部110は、自サーバ(エッジサーバ100)および他のエッジサーバ100の負荷の状態を示す情報(状態情報)を取得する(ステップS98)。そして、決定部120は、取得した状態情報に基づいて、新たなブロックに含めるナンス値を計算するエッジサーバを決定する(ステップS99)。
そして、計算部160は、決定部120がステップS99で決定したエッジサーバが、自サーバか否かを確認する(ステップS100)。ステップS99で決定されたエッジサーバが、他のエッジサーバの場合(ステップS100にてNO)、送信部150は、計算部160がステップS97でまとめた取引データ(つまり、承認前のブロック)を、決定されたエッジサーバに送信する(ステップS101)。この承認前のブロックが送信されたエッジサーバの処理は、図10を参照して後述する。そして、ステップS104に進む。
ステップS99で決定されたエッジサーバが、自サーバの場合(ステップS100にてYES)、計算部160がステップS97でまとめたブロックのナンス値を計算する(ステップS102)。この構成により、エッジサーバ100は、ブロックを送信する処理に掛かる負荷を削減することができる。また、ブロックの送受信に掛かる時間を削減することができる。
そして、計算部160は、計算したナンス値と、承認前のブロックの直前のブロックのハッシュ値(ブロックチェーンに含まれるブロックのうち最新のブロックのナンス値)とを、承認前のブロックに含めて、該承認前のブロックを送信部150に供給する。そして送信部150は、この承認前のブロックを他のエッジサーバに対して同報する(ステップS103)。その後、エッジサーバ100は、ステップS108の処理に進む。
ナンス値を計算するエッジサーバが他のエッジサーバの場合、ステップS101の後に、受信部140は、該ステップS101にて、ブロックの送信先のエッジサーバ100から、該エッジサーバ100が計算したナンス値と直前のブロックのハッシュ値と含むブロックを受信する(ステップS104)。計算部160は、受信したブロックに含まれるナンス値を検算する(ステップS105)。この計算部160による検算が完了すると、検算の対象となったナンス値を含むブロックが承認されることになる。そして、計算部160は、承認されたブロックを、記憶部130に格納し、新たなブロックチェーンを形成する(ステップS106)。承認されたブロックは、ブロックチェーンの最新のブロックとなる。そして、検算を行ったエッジサーバ100は、ナンス値を計算したエッジサーバ100に対し、ブロックを承認したことを示す通知(承認通知)を送信する(ステップS107)。
エッジサーバ100がナンス値を計算するサーバである場合、ステップS103の終了後、受信部140がブロックを承認したことを示す通知を受信する(ステップS108)。その後、計算部160は、ステップS106と同様に承認されたブロックを、記憶部130に格納し、新たなブロックチェーンを形成する(ステップS109)。
そして、送信部150は、ブロックチェーンに追加されたブロックのハッシュ値(承認されたブロックのナンス値)を、利用者端末200に送信する(ステップS110)。
そして、利用者端末200の受信部250は、エッジサーバ100から送信された、最新のブロックのハッシュ値を受信する(ステップS111)。
また、送信部150は、ブロックチェーンに追加されたブロックに含まれる1以上の取引データの夫々に関連する店舗の店舗端末300に対し、取引が完了したことを示す通知(取引完了通知)を送信する(ステップS112)。なお、ステップS112は、ステップS109の後であれば、どのタイミングで行われてもよい。また、ステップS112を行うエッジサーバ100は、複数のエッジサーバのうち、どのエッジサーバであってもよい。
これにより、店舗端末300を有する店舗は、取引が完了したことを確認することができる。以上の処理により、例えば、店舗から商品を購入するという取引を行った利用者の財布に含まれる仮想通貨から購入した商品の金額分の仮想通貨が差し引かれる。また、上記店舗の財布には、購入された商品の金額分の仮想通貨が追加される。
図10は、エッジサーバ100が、図8および図9に処理を示したエッジサーバとは異なるエッジサーバである場合の処理の一例を示す図である。図10に示す通り、エッジサーバ100の受信部140は、上述したステップS101で送信された、承認前のブロックを受信する(ステップS121)。
そして、計算部160がステップS121で受信した、承認前のブロックのナンス値を計算する(ステップS122)。そして、計算部160は、計算したナンス値と、承認前のブロックの直前のブロックのハッシュ値とを、承認前のブロックに含めて、該承認前のブロックを送信部150に供給する。そして送信部150は、この承認前のブロックを他のエッジサーバに対して同報する(ステップS123)。これにより、ステップS99で決定したエッジサーバ以外のエッジサーバは、図9に示したステップS104〜ステップS107の処理を行うことができる。
その後、ステップS107で、承認通知が送信されると、受信部140がブロックを承認したことを示す通知を受信する(ステップS124)。そして、計算部160は、承認されたブロックを、記憶部130に格納し、新たなブロックチェーンを形成する(ステップS125)。
以上により、承認前のブロックが送信されたエッジサーバの処理を終了する。
このような決済処理により、システム2は、取引データの改ざん、否認、仮想通貨の二重支払いを防止した、セキュアな電子取引を行うことができる。
次に、図11から図13を参照して、複数のエッジサーバ100が配置される位置について説明する。図11から図13は、夫々、システム2のネットワーク構成の一例を示す図である。
図11から図13に示すネットワークには、基地局であるeNodeB(eNB)、MME(Mobility Management Entity)、S−GW(Serving−Gateway)およびP−GW(Packet Data Network−Gateway)が含まれる。エッジサーバ100は、図11に示す通り、eNBと、S−GWとの間に配置されてもよいし、図12に示す通り、S−GWとP−GWとの間に配置されてもよいし、図13に示す通り、P−GWが接続する外部のネットワーク上に配置されていてもよい。
図13に示すように、エッジサーバ100が、eNBよりもP−GW側に配置されることにより、エッジサーバ100と通信する店舗が存在する範囲を広げることができる。したがって、システム2は、エッジサーバ100の台数を減らすことができるため、エッジサーバ100の設置にかかるコストを削減することができる。また、図11に示すように、エッジサーバ100が、P−GWよりもeNB側に配置されることにより、利用者端末200または店舗端末300と、エッジサーバ100との距離が近くなる。これにより、システム2は、利用者端末200または店舗端末300と、エッジサーバ100との間の通信遅延を低減することができる。
本実施の形態では、第1の実施の形態における負荷分散装置10の機能が、エッジサーバ100内に内蔵されることについて説明を行ったが、上述したとおり、負荷分散装置10は、エッジサーバ100とは異なる装置で実現されるものであってもよい。この場合、ステップS97において、承認前のブロックを生成したエッジサーバ100は、負荷分散装置10を有する装置に、承認前のブロックが生成されたことを示す通知を送信してもよい。これにより、負荷分散装置10の取得部11が上述した取得部110と同様に上記通知を受け取ることにより、負荷分散装置10は、第1の実施の形態において説明した処理を行うことができる。
そして、負荷分散装置10は、承認前のブロックを生成したエッジサーバ(上述したステップS97を行ったエッジサーバ)に対し、決定したエッジサーバに承認前のブロックを送信する指示を送信する。これにより、承認前のブロックを生成したエッジサーバは、ステップS104からステップS107の処理を行うことができる。また、負荷分散装置10が決定したエッジサーバは、図9のステップS102以降の処理を行うことができる。
また、本実施の形態では、店舗端末300が出力した識別子または取引データに商品情報と店舗アドレスとが含まれることについて説明したが、店舗端末300は、識別子または取引データに商品情報と該取引を特定する情報(取引識別子)とを含めて出力してもよい。この場合、店舗端末300は、暗号化した店舗アドレスを上記取引識別子に関連付けてエッジサーバ100に送信する。店舗アドレスを受信したエッジサーバ100は、店舗アドレスの送信元の店舗端末300の公開鍵で復号する。そして、利用者端末200が、エッジサーバ100に取引データを、上記取引識別子と共に送信する。これにより、エッジサーバ100は、取引データと、店舗アドレスとを関連付けることができるため、エッジサーバ100は、ステップS96において、全ての店舗の公開鍵を用いなくとも、取引データに含まれる商品情報を復号することができる。
(効果)
本実施の形態に係るシステム2によれば、エッジサーバ100の取得部110が、所定のネットワークにおける複数のエッジサーバの夫々の状態を示す状態情報を取得する。この複数のエッジサーバは、利用者と店舗との間の、所定の金銭的価値を有する電子バリューを用いた取引に関する取引データを所定のプロトコルに従って仲介するサーバである。そして、エッジサーバ100の決定部120が、複数のエッジサーバ100の夫々における状態情報に基づいて、複数のエッジサーバのうち、ナンス値を計算するエッジサーバを決定する。
一般的に、ナンス値の計算には、大きな負荷が掛かる。したがって、1つのエッジサーバのみが、複数の取引データ群(ブロック)の夫々のナンス値の計算を行うと、この1つのエッジサーバに大きな負荷が掛かってしまう。しかしながら、本実施の形態に係るシステム2におけるエッジサーバの決定部120は、複数のエッジサーバの夫々の状態情報に基づいて、ナンス値を計算するエッジサーバを決定する。これにより、ナンス値の計算を行うタイミングにおいて、決定部120は、例えば、負荷がより小さいエッジサーバ、高性能なエッジサーバなど、ナンス値を計算するのに適したエッジサーバを決定することができる。これにより、システム2は、ある特定のエッジサーバに負荷が掛からないようにすることができる。したがって、システム2は、利用者と店舗との間の電子取引における、システム2に含まれるエッジサーバの負荷分散を行うことができる。また、エッジサーバの負荷分散を行うことにより、利用者と店舗との間の取引に対する決済処理の時間を短くすることができる。
また、本実施の形態に係るシステム2では、ナンス値の計算処理を、エッジサーバ100で行う。また、システム2では利用者端末200の認証処理および取引データの復号処理もエッジサーバ100で行う。これにより、決済網の参加者の何れかがナンス値を計算する場合、または、中央決済機関が決済処理を行う場合に比べ、利用者と店舗との間の取引に対する決済処理の時間を短くすることができる。
また、本実施の形態に係るシステム2は、既存のシステムにも適用可能である。既存のシステムとは、例えば、電子貨幣を用いた電子決済システム、クレジットカードを用いた電子決済システム、サービス提供会社が管理するポイントを用いた決済システム、サービス提供会社によって貨幣価値が設定された仮想通貨を用いた決済システム等が挙げられる。
また、本実施の形態に係るシステム2では、所定の範囲内における取引であるため、システム2は、所定の範囲において、通貨交換のレートの設定や変更を容易に行うことができる。また、システム2は、所定の範囲における仮想通貨の使用用途、使用場所を制御することもできる。
(ハードウェア構成について)
本発明の各実施形態において、各装置の各構成要素は、機能単位のブロックを示している。各装置の各構成要素の一部又は全部は、例えば図14に示すような情報処理装置900とプログラムとの任意の組み合わせにより実現される。情報処理装置900は、一例として、以下のような構成を含む。
・CPU(Central Processing Unit)901
・ROM(Read Only Memory)902
・RAM(Random Access Memory)903
・RAM903にロードされるプログラム904
・プログラム904を格納する記憶装置905
・記録媒体906の読み書きを行うドライブ装置907
・通信ネットワーク909と接続する通信インターフェース908
・データの入出力を行う入出力インターフェース910
・各構成要素を接続するバス911
各実施形態における各装置の各構成要素は、これらの機能を実現するプログラム904をCPU901が取得して実行することで実現される。各装置の各構成要素の機能を実現するプログラム904は、例えば、予め記憶装置905やRAM903に格納されており、必要に応じてCPU901が読み出す。なお、プログラム904は、通信ネットワーク909を介してCPU901に供給されてもよいし、予め記録媒体906に格納されており、ドライブ装置907が当該プログラムを読み出してCPU901に供給してもよい。
各装置の実現方法には、様々な変形例がある。例えば、各装置は、構成要素毎にそれぞれ別個の情報処理装置900とプログラムとの任意の組み合わせにより実現されてもよい。また、各装置が備える複数の構成要素が、一つの情報処理装置900とプログラムとの任意の組み合わせにより実現されてもよい。
また、各装置の各構成要素の一部又は全部は、その他の汎用または専用の回路、プロセッサ等やこれらの組み合わせによって実現される。これらは、単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。
各装置の各構成要素の一部又は全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。
各装置の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。
なお、上述した各実施の形態は、本発明の好適な実施の形態であり、上記各実施の形態にのみ本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において当業者が上記各実施の形態の修正や代用を行い、種々の変更を施した形態を構築することが可能である。
1 システム
2 システム
10 負荷分散装置
11 取得部
12 決定部
20 利用者端末
30 店舗端末
40 エッジサーバ
100 エッジサーバ
110 取得部
120 決定部
130 記憶部
140 受信部
150 送信部
160 計算部
170 認証部
200 利用者端末
210 生成部
220 送信部
230 記憶部
240 取得部
250 受信部
300 店舗端末
310 生成部
320 送信部
330 記憶部
340 出力部

Claims (13)

  1. 利用者が有する利用者端末と、店舗に設けられた店舗端末と、所定の金銭的価値を有する電子バリューを用いた、前記利用者と前記店舗との間の取引に関する取引データを所定のプロトコルに従って仲介する複数のエッジサーバと、負荷分散装置とを含み、
    前記負荷分散装置は、前記複数のエッジサーバの夫々の状態を示す状態情報を取得する取得手段と、
    前記複数のエッジサーバの夫々における、前記取得した状態情報に基づいて、前記複数のエッジサーバのうち、1以上の前記取引データを含む取引データ群に対するナンス値を計算するエッジサーバを決定する決定手段と、
    を備え
    前記取引データ群に新たな取引データが追加された場合、前記決定されたエッジサーバが、当該新たな取引データが追加された前記取引データ群に対するナンス値を計算し、他のエッジサーバが、当該計算されたナンス値に基づいて、当該新たな取引データが追加された前記取引データ群を承認し、
    前記取引データ群が承認された場合、前記利用者と前記店舗との間の取引が完了する、
    ことを特徴とする負荷分散システム。
  2. 前記複数のエッジサーバの夫々は、前記ナンス値を計算する計算手段を備え、
    前記決定手段によって決定されたエッジサーバの前記計算手段は、前記ナンス値を計算する、ことを特徴とする請求項1に記載の負荷分散システム。
  3. 前記複数のエッジサーバの夫々は、前記取引データ群を送信する送信手段を備え、
    前記複数のエッジサーバの少なくとも1つは、前記利用者端末から、前記取引データを受信する受信手段を備え、
    前記計算手段は、前記受信手段が受信した取引データに基づいて、前記取引データ群を生成し、前記決定手段によって決定されたエッジサーバが他のエッジサーバの場合、前記生成した取引データ群を、前記送信手段を介して前記他のエッジサーバに送信し、前記決定手段によって決定されたエッジサーバが自サーバの場合、前記生成した取引データ群のナンス値を計算する、ことを特徴とする請求項2に記載の負荷分散システム。
  4. 前記受信手段は、該受信手段を備えるエッジサーバと前記利用者端末との距離が、前記他のエッジサーバと該利用者端末との距離より近い場合に、該利用者端末から、前記取引データを受信する、ことを特徴とする請求項3に記載の負荷分散システム。
  5. 前記取得手段は、前記状態情報として、前記エッジサーバに掛かる負荷状態を表す負荷状態情報、前記エッジサーバの動作状態を表す動作状態情報、前記エッジサーバが有する性能を表す性能情報の少なくとも何れかを取得する、ことを特徴とする請求項1から4の何れか1項に記載の負荷分散システム。
  6. 前記負荷分散装置は、前記複数のエッジサーバのうち、少なくとも一つのエッジサーバに設けられることを特徴とする請求項1から5の何れか1項に記載の負荷分散システム。
  7. 前記複数のエッジサーバは、基地局とサービングゲートウェイとの間、サービングゲートウェイとパケットデータネットワークゲートウェイとの間、または、パケットデータネットワークゲートウェイが接続する外部のネットワーク上に配置される、ことを特徴とする請求項1から6の何れか1項に記載の負荷分散システム。
  8. 所定の金銭的価値を有する電子バリューを用いた、利用者と店舗との間の取引に関する取引データを所定のプロトコルに従って仲介する複数のエッジサーバの夫々の状態を示す状態情報を取得する取得手段と、
    前記複数のエッジサーバの夫々における、前記取得した状態情報に基づいて、前記複数のエッジサーバのうち、1以上の前記取引データを含む取引データ群に対するナンス値を計算するエッジサーバを決定する決定手段と、
    を備え
    前記取引データ群に新たな取引データが追加された場合、前記決定されたエッジサーバが、当該新たな取引データが追加された前記取引データ群に対するナンス値を計算し、他のエッジサーバが、当該計算されたナンス値に基づいて、当該新たな取引データが追加された前記取引データ群を承認し、
    前記取引データ群が承認された場合、前記利用者と前記店舗との間の取引が完了する、
    ことを特徴とする負荷分散装置。
  9. 前記取得手段は、前記状態情報として、前記エッジサーバに掛かる負荷状態を表す負荷状態情報、前記エッジサーバの動作状態を表す動作状態情報、前記エッジサーバが有する性能を表す性能情報の少なくとも何れかを取得する、ことを特徴とする請求項8に記載の負荷分散装置。
  10. コンピュータが備える取得手段が、所定の金銭的価値を有する電子バリューを用いた、利用者と店舗との間の取引に関する取引データを所定のプロトコルに従って仲介する複数のエッジサーバの夫々の状態を示す状態情報を取得し、
    前記コンピュータが備える決定手段が、前記複数のエッジサーバの夫々における、前記取得した状態情報に基づいて、前記複数のエッジサーバのうち、1以上の前記取引データを含む取引データ群に対するナンス値を計算するエッジサーバを決定
    前記取引データ群に新たな取引データが追加された場合、前記決定されたエッジサーバが、当該新たな取引データが追加された前記取引データ群に対するナンス値を計算し、他のエッジサーバが、当該計算されたナンス値に基づいて、当該新たな取引データが追加された前記取引データ群を承認し、
    前記取引データ群が承認された場合、前記利用者と前記店舗との間の取引が完了する、
    ことを特徴とする負荷分散方法。
  11. 前記状態情報は、前記エッジサーバに掛かる負荷状態を表す負荷状態情報、前記エッジサーバの動作状態を表す動作状態情報、前記エッジサーバが有する性能を表す性能情報の少なくとも何れかである、ことを特徴とする請求項10に記載の負荷分散方法。
  12. 所定の金銭的価値を有する電子バリューを用いた、利用者と店舗との間の取引に関する取引データを所定のプロトコルに従って仲介する複数のエッジサーバの夫々の状態を示す状態情報を取得する処理と、
    前記複数のエッジサーバの夫々における、前記取得した状態情報に基づいて、前記複数のエッジサーバのうち、1以上の前記取引データを含む取引データ群に対するナンス値を計算するエッジサーバを決定する処理と、
    をコンピュータに実行させることを特徴とするプログラムであって、
    前記取引データ群に新たな取引データが追加された場合、前記決定されたエッジサーバが、当該新たな取引データが追加された前記取引データ群に対するナンス値を計算し、他のエッジサーバが、当該計算されたナンス値に基づいて、当該新たな取引データが追加された前記取引データ群を承認し、
    前記取引データ群が承認された場合、前記利用者と前記店舗との間の取引が完了する、
    プログラム
  13. 前記状態情報は、前記エッジサーバに掛かる負荷状態を表す負荷状態情報、前記エッジサーバの動作状態を表す動作状態情報、前記エッジサーバが有する性能を表す性能情報の少なくとも何れかである、ことを特徴とする請求項12に記載のプログラム。
JP2016002829A 2016-01-08 2016-01-08 負荷分散システム、負荷分散装置、負荷分散方法、および、プログラム Active JP6657972B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2016002829A JP6657972B2 (ja) 2016-01-08 2016-01-08 負荷分散システム、負荷分散装置、負荷分散方法、および、プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2016002829A JP6657972B2 (ja) 2016-01-08 2016-01-08 負荷分散システム、負荷分散装置、負荷分散方法、および、プログラム

Publications (2)

Publication Number Publication Date
JP2017123116A JP2017123116A (ja) 2017-07-13
JP6657972B2 true JP6657972B2 (ja) 2020-03-04

Family

ID=59306611

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016002829A Active JP6657972B2 (ja) 2016-01-08 2016-01-08 負荷分散システム、負荷分散装置、負荷分散方法、および、プログラム

Country Status (1)

Country Link
JP (1) JP6657972B2 (ja)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6754319B2 (ja) * 2017-05-25 2020-09-09 日本電信電話株式会社 ブロックチェーン更新システム、サーバ装置、クライアント装置、ブロックチェーン更新方法、およびプログラム
GB201711879D0 (en) * 2017-07-24 2017-09-06 Nchain Holdings Ltd Computer-implemented system and method
JP6391128B1 (ja) * 2017-09-27 2018-09-19 株式会社Artrigger 取引管理方法、通信端末、及びプログラム
CN111164636A (zh) 2017-09-27 2020-05-15 株式会社Artrigger 交易管理方法、使用权管理方法、通信终端以及程序
CN107734021B (zh) 2017-09-30 2020-04-07 深圳壹账通智能科技有限公司 区块链数据上传方法、系统、计算机系统及存储介质
JP7019380B2 (ja) 2017-11-06 2022-02-15 東芝テック株式会社 プログラム及び決済端末
KR102005158B1 (ko) * 2017-11-29 2019-07-29 신한카드 주식회사 여신 가상화폐 생성 장치 및 여신 가상화폐 관리 장치
CN111418182B (zh) * 2017-12-08 2023-10-27 索尼公司 信息处理装置、登记装置、信息处理方法、登记方法和计算机程序
JP7031374B2 (ja) * 2018-03-01 2022-03-08 株式会社デンソー 検証端末、検証システム
JP6487096B1 (ja) * 2018-04-17 2019-03-20 株式会社電通 ポイント付与システム及びポイント付与方法
US10831530B2 (en) * 2018-06-13 2020-11-10 International Business Machines Corporation Secure consensus-based endorsement for self-monitoring blockchain
JP6583841B1 (ja) * 2018-06-26 2019-10-02 国立大学法人佐賀大学 情報通信装置、情報通信方法及び情報通信プログラム
JP6647495B1 (ja) * 2018-08-21 2020-02-14 株式会社スマイルメーカー 仮想通貨管理システム及び方法
KR102412687B1 (ko) * 2018-12-24 2022-06-24 한국전자기술연구원 초소형 Disposable IoT 기반의 건강 모니터링 방법
KR102423544B1 (ko) * 2019-10-14 2022-07-21 주식회사 빗썸코리아 다수의 매칭 서버를 로드 밸런싱하는 통합 가상화폐 시스템 및 로드 밸런싱 방법
CN115334081A (zh) * 2021-04-23 2022-11-11 华为技术有限公司 一种边缘应用服务器的选择方法及装置
KR102533866B1 (ko) * 2021-05-13 2023-05-26 광운대학교 산학협력단 Mecs 사이의 부하 분산 방법 및 동 방법을 컴퓨터에서 실행하기 위한 컴퓨터 프로그램이 기록된, 컴퓨터 판독 가능한 기록 매체
JP7039756B1 (ja) 2021-07-30 2022-03-22 PayPay株式会社 情報処理装置、情報処理方法および情報処理プログラム

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005071081A (ja) * 2003-08-25 2005-03-17 Bitwallet Inc 販売サーバ、販売方法、及び販売プログラム

Also Published As

Publication number Publication date
JP2017123116A (ja) 2017-07-13

Similar Documents

Publication Publication Date Title
JP6657972B2 (ja) 負荷分散システム、負荷分散装置、負荷分散方法、および、プログラム
US10652028B2 (en) Systems and methods for secure detokenization
US20230283597A1 (en) Communication device using virtual access device and transaction applet
KR102232649B1 (ko) 보안 디바이스 기능에 대한 온라인 액세스 확인
US11240217B1 (en) Wireless peer to peer mobile wallet connections
US20170213206A1 (en) Conducting transactions using electronic devices with geographically restricted non-native credentials
CN105139193B (zh) 一种电子资源处理方法、装置及服务器
US10972257B2 (en) Multi-level communication encryption
JP6482601B2 (ja) 電子デバイスとサービスプロバイダの間のセキュリティ保護された取引の管理
US20110131102A1 (en) Secure mobile payment processing
CN102985885A (zh) 用于基于附近的点对点支付交易的系统、设备及方法
US9691109B2 (en) Mechanism for reputation feedback based on real time interaction
AU2016220072A1 (en) Secure authentication of user and mobile device
CN105556551A (zh) 使用电子设备的安全元件来进行在线支付
WO2017020618A1 (zh) 一种电子资源处理方法、设备
AU2015308090B2 (en) System and method for electronic payments
US20160125407A1 (en) Systems and Methods for Secure Remote Payments
JP6667498B2 (ja) リモート取引システム、方法およびpos端末
CN113632124A (zh) 用于交换交易数据的系统、方法和计算机程序产品
US20150073999A1 (en) Method and system for conducting a payment transaction and corresponding devices
KR101946330B1 (ko) 보안 응용 모듈 간 공유를 제공하는 결제 처리 방법 및 그 장치
US20230368190A1 (en) Virtual terminal
CN114119024A (zh) 一种数据交互方法、装置及相关设备
JP2020053968A (ja) 持続的な無線接続を介した無線トランザクション

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20181214

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20191029

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20191105

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20191226

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: 20200107

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200120

R150 Certificate of patent or registration of utility model

Ref document number: 6657972

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150