(57)【特許請求の範囲】
【請求項１】
利用者が有する利用者端末と、店舗に設けられた店舗端末と、所定の金銭的価値を有する電子バリューを用いた、前記利用者と前記店舗との間の取引に関する取引データを所定のプロトコルに従って仲介する複数のエッジサーバと、負荷分散装置とを含み、
前記負荷分散装置は、前記複数のエッジサーバの夫々の状態を示す状態情報を取得する取得手段と、
前記複数のエッジサーバの夫々における、前記取得した状態情報に基づいて、前記複数のエッジサーバのうち、１以上の前記取引データを含む取引データ群に対するナンス値を計算するエッジサーバを決定する決定手段と、
を備え、
前記取引データ群に新たな取引データが追加された場合、前記決定されたエッジサーバが、当該新たな取引データが追加された前記取引データ群に対するナンス値を計算し、他のエッジサーバが、当該計算されたナンス値に基づいて、当該新たな取引データが追加された前記取引データ群を承認し、
前記取引データ群が承認された場合、前記利用者と前記店舗との間の取引が完了する、
ことを特徴とする負荷分散システム。
【請求項２】
前記複数のエッジサーバの夫々は、前記ナンス値を計算する計算手段を備え、
前記決定手段によって決定されたエッジサーバの前記計算手段は、前記ナンス値を計算する、ことを特徴とする請求項１に記載の負荷分散システム。
【請求項３】
前記複数のエッジサーバの夫々は、前記取引データ群を送信する送信手段を備え、
前記複数のエッジサーバの少なくとも１つは、前記利用者端末から、前記取引データを受信する受信手段を備え、
前記計算手段は、前記受信手段が受信した取引データに基づいて、前記取引データ群を生成し、前記決定手段によって決定されたエッジサーバが他のエッジサーバの場合、前記生成した取引データ群を、前記送信手段を介して前記他のエッジサーバに送信し、前記決定手段によって決定されたエッジサーバが自サーバの場合、前記生成した取引データ群のナンス値を計算する、ことを特徴とする請求項２に記載の負荷分散システム。
【請求項４】
前記受信手段は、該受信手段を備えるエッジサーバと前記利用者端末との距離が、前記他のエッジサーバと該利用者端末との距離より近い場合に、該利用者端末から、前記取引データを受信する、ことを特徴とする請求項３に記載の負荷分散システム。
【請求項５】
前記取得手段は、前記状態情報として、前記エッジサーバに掛かる負荷状態を表す負荷状態情報、前記エッジサーバの動作状態を表す動作状態情報、前記エッジサーバが有する性能を表す性能情報の少なくとも何れかを取得する、ことを特徴とする請求項１から４の何れか１項に記載の負荷分散システム。
【請求項６】
前記負荷分散装置は、前記複数のエッジサーバのうち、少なくとも一つのエッジサーバに設けられることを特徴とする請求項１から５の何れか１項に記載の負荷分散システム。
【請求項７】
前記複数のエッジサーバは、基地局とサービングゲートウェイとの間、サービングゲートウェイとパケットデータネットワークゲートウェイとの間、または、パケットデータネットワークゲートウェイが接続する外部のネットワーク上に配置される、ことを特徴とする請求項１から６の何れか１項に記載の負荷分散システム。
【請求項８】
所定の金銭的価値を有する電子バリューを用いた、利用者と店舗との間の取引に関する取引データを所定のプロトコルに従って仲介する複数のエッジサーバの夫々の状態を示す状態情報を取得する取得手段と、
前記複数のエッジサーバの夫々における、前記取得した状態情報に基づいて、前記複数のエッジサーバのうち、１以上の前記取引データを含む取引データ群に対するナンス値を計算するエッジサーバを決定する決定手段と、
を備え、
前記取引データ群に新たな取引データが追加された場合、前記決定されたエッジサーバが、当該新たな取引データが追加された前記取引データ群に対するナンス値を計算し、他のエッジサーバが、当該計算されたナンス値に基づいて、当該新たな取引データが追加された前記取引データ群を承認し、
前記取引データ群が承認された場合、前記利用者と前記店舗との間の取引が完了する、
ことを特徴とする負荷分散装置。
【請求項９】
前記取得手段は、前記状態情報として、前記エッジサーバに掛かる負荷状態を表す負荷状態情報、前記エッジサーバの動作状態を表す動作状態情報、前記エッジサーバが有する性能を表す性能情報の少なくとも何れかを取得する、ことを特徴とする請求項８に記載の負荷分散装置。
【請求項１０】
コンピュータが備える取得手段が、所定の金銭的価値を有する電子バリューを用いた、利用者と店舗との間の取引に関する取引データを所定のプロトコルに従って仲介する複数のエッジサーバの夫々の状態を示す状態情報を取得し、
前記コンピュータが備える決定手段が、前記複数のエッジサーバの夫々における、前記取得した状態情報に基づいて、前記複数のエッジサーバのうち、１以上の前記取引データを含む取引データ群に対するナンス値を計算するエッジサーバを決定し、
前記取引データ群に新たな取引データが追加された場合、前記決定されたエッジサーバが、当該新たな取引データが追加された前記取引データ群に対するナンス値を計算し、他のエッジサーバが、当該計算されたナンス値に基づいて、当該新たな取引データが追加された前記取引データ群を承認し、
前記取引データ群が承認された場合、前記利用者と前記店舗との間の取引が完了する、
ことを特徴とする負荷分散方法。
【請求項１１】
前記状態情報は、前記エッジサーバに掛かる負荷状態を表す負荷状態情報、前記エッジサーバの動作状態を表す動作状態情報、前記エッジサーバが有する性能を表す性能情報の少なくとも何れかである、ことを特徴とする請求項１０に記載の負荷分散方法。
【請求項１２】
所定の金銭的価値を有する電子バリューを用いた、利用者と店舗との間の取引に関する取引データを所定のプロトコルに従って仲介する複数のエッジサーバの夫々の状態を示す状態情報を取得する処理と、
前記複数のエッジサーバの夫々における、前記取得した状態情報に基づいて、前記複数のエッジサーバのうち、１以上の前記取引データを含む取引データ群に対するナンス値を計算するエッジサーバを決定する処理と、
をコンピュータに実行させることを特徴とするプログラムであって、
前記取引データ群に新たな取引データが追加された場合、前記決定されたエッジサーバが、当該新たな取引データが追加された前記取引データ群に対するナンス値を計算し、他のエッジサーバが、当該計算されたナンス値に基づいて、当該新たな取引データが追加された前記取引データ群を承認し、
前記取引データ群が承認された場合、前記利用者と前記店舗との間の取引が完了する、
プログラム。
【請求項１３】
前記状態情報は、前記エッジサーバに掛かる負荷状態を表す負荷状態情報、前記エッジサーバの動作状態を表す動作状態情報、前記エッジサーバが有する性能を表す性能情報の少なくとも何れかである、ことを特徴とする請求項１２に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、負荷分散システム、負荷分散装置、負荷分散方法、および、プログラムに関する。
【背景技術】
【０００２】
クレジットカード、ＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）カードなどを用いた電子決済が行われている。例えば、特許文献１には、携帯電話を用いた電子マネーによる決済処理に関する技術が記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１４−１１７６２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特定の地域で利用可能な、商品券が各地域で発行されている。このような商品券は、紙媒体であることが多い。しかしながら、紙媒体の商品券は、発行コストがかかる。また、紙媒体の商品券の購入には、購入可能な店舗まで利用者が赴く必要があるため、この店舗に赴くことができない利用者は、商品券を購入できない。また、利用者にとっても、紙媒体は、紛失してしまう可能性がある。
【０００５】
また、特定の地域で利用可能な商品券を、例えば、クレジットカード、ＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）カードなどを用いた既存の電子決済に適用した場合、各店舗には、例えば、カードリーダライタのような設備の投資費および維持費、電子決済利用のための手数料がかかってしまう。また、利用者も上記カードを保有する必要がある。
【０００６】
これらの課題を解決するために、特定の地域で利用可能な商品券の決済を、例えば、Ｐ２Ｐ（ｐｅｅｒ−ｔｏ−ｐｅｅｒ）型の決済網を利用した電子取引で行うことが考えられる。このような電子取引では、特定の地域でのみの取引にもかかわらず、決済処理に所定時間（例えば、１０分）を要してしまう。その理由は、このような電子取引では、１以上の取引データをまとめたブロックのハッシュ値（ナンス値）を、上記決済網の参加者の何れかが計算するという計算処理が行われからである。このナンス値は、一般的に、計算量の大きな計算を行うことにより得られる値であるため、計算を行う装置には、大きな負荷が掛かってしまう。
【０００７】
本発明は上記課題に鑑みてなされたものであり、その目的は、利用者と店舗との間の電子取引における負荷を分散することが可能な技術を提供することにある。
【課題を解決するための手段】
【０００８】
本発明の一態様に係る負荷分散システムは、利用者が有する利用者端末と、店舗に設けられた店舗端末と、所定の金銭的価値を有する電子バリューを用いた、前記利用者と前記店舗との間の取引に関する取引データを所定のプロトコルに従って仲介する複数のエッジサーバと、負荷分散装置とを含み、前記負荷分散装置は、前記複数のエッジサーバの夫々の状態を示す状態情報を取得する取得手段と、前記複数のエッジサーバの夫々における、前記取得した状態情報に基づいて、前記複数のエッジサーバのうち、１以上の前記取引データを含む取引データ群に対するナンス値を計算するエッジサーバを決定する決定手段と、を備える。
【０００９】
また、本発明の一態様に係る負荷分散装置は、所定の金銭的価値を有する電子バリューを用いた、利用者と店舗との間の取引に関する取引データを所定のプロトコルに従って仲介する複数のエッジサーバの夫々の状態を示す状態情報を取得する取得手段と、前記複数のエッジサーバの夫々における、前記取得した状態情報に基づいて、前記複数のエッジサーバのうち、１以上の前記取引データを含む取引データ群に対するナンス値を計算するエッジサーバを決定する決定手段と、を備える。
【００１０】
また、本発明の一態様に係る負荷分散方法は、所定の金銭的価値を有する電子バリューを用いた、利用者と店舗との間の取引に関する取引データを所定のプロトコルに従って仲介する複数のエッジサーバの夫々の状態を示す状態情報を取得し、前記複数のエッジサーバの夫々における、前記取得した状態情報に基づいて、前記複数のエッジサーバのうち、１以上の前記取引データを含む取引データ群に対するナンス値を計算するエッジサーバを決定する。
【００１１】
なお、上記システム、装置または方法を、コンピュータによって実現するコンピュータプログラム、およびそのコンピュータプログラムが格納されている、コンピュータ読み取り可能な非一時的記録媒体も、本発明の範疇に含まれる。
【発明の効果】
【００１２】
本発明によれば、利用者と店舗との間の電子取引における負荷を分散することができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の第１の実施の形態に係るシステムの構成の一例を示す図である。
【図２】本発明の第１の実施の形態に係る負荷分散装置の処理の流れの一例を示すフローチャートである。
【図３】本発明の第２の実施の形態に係るシステムの全体構成の一例を示す図である。
【図４】本発明の第２の実施の形態に係るシステムの全体構成の他の例を示す図である。
【図５】本発明の第２の実施の形態に係るシステムに含まれる各装置の機能構成の一例を示す機能ブロック図である。
【図６】本発明の第２の実施の形態における、利用者登録処理の流れの一例を示すフローチャートである。
【図７】本発明の第２の実施の形態における、店舗登録処理の流れの一例を示すフローチャートである。
【図８】本発明の第２の実施の形態における、決済処理の流れの一例を示すフローチャートである。
【図９】本発明の第２の実施の形態における、決済処理の流れの一例を示すフローチャートである。
【図１０】本発明の第２の実施の形態における、決済処理の流れの一例を示すフローチャートである。
【図１１】本発明の第２の実施の形態に係るシステムのネットワーク構成の一例を示す図である。
【図１２】本発明の第２の実施の形態に係るシステムのネットワーク構成の一例を示す図である。
【図１３】本発明の第２の実施の形態に係るシステムのネットワーク構成の一例を示す図である。
【図１４】本発明の各実施の形態を実現可能なコンピュータ（情報処理装置）のハードウェア構成を例示的に説明する図である。
【発明を実施するための形態】
【００１４】
＜第１の実施の形態＞
本発明の第１の実施の形態について、図面を参照して詳細に説明する。図１は、本発明の第１の実施の形態に係るシステム（負荷分散システム）１の構成の一例を示すブロック図である。なお、図１に示すシステム１は、本発明に特有な構成について示したものであり、図１に示すシステム１が図１に示されていない構成を有していてもよいことは言うまでもない。図１に示す通り、システム１は、負荷分散装置１０と、複数のエッジサーバ（４０−１〜４０−ｎ（ｎ＞＝２））と、利用者が所持する利用者端末２０と、店舗に設けられた店舗端末３０とを含む。なお、本実施の形態では、複数のエッジサーバ（４０−１〜４０−ｎ）の夫々を区別しない場合、または、総称する場合には、これらをエッジサーバ４０と呼ぶ。
【００１５】
また、図１に示す通り、本実施の形態に係る負荷分散装置１０は、取得部１１と、決定部１２とを備える。なお、負荷分散装置１０は、エッジサーバとは異なる装置で実現されることを例に説明を行うが、エッジサーバ内に設けられるものであってもよい。負荷分散装置１０がエッジサーバ４０内に設けられる場合、負荷分散装置１０は、複数のエッジサーバ４０の全てに設けられてもよいし、一部のエッジサーバ４０に設けられてもよい。また、負荷分散装置１０は、例えば、決済処理をまとめて管理する中央決済機関に設けられてもよい。システム１に含まれる複数のエッジサーバ４０と利用者端末２０と店舗端末３０とは、所定のネットワーク上の装置である。所定のネットワークとは、例えば、所定の地域である。
【００１６】
エッジサーバ４０は、所定の金銭的価値を有する電子バリュー（仮想通貨、仮想コインとも呼ぶ）を用いた取引に関する取引データを所定のプロトコルに従って仲介する。所定のプロトコルとは、例えば、ブロックチェーン技術が挙げられる。本実施の形態では、所定のプロトコルとして、ブロックチェーン技術を用いるとして説明を行う。
【００１７】
所定の金銭的価値を有する電子バリューとは、ポイントのような実際の紙幣や貨幣が存在しない通貨であってもよいし、実際の紙幣や通貨を基準として電子決済する際に利用する電子貨幣であってもよい。また、所定の金銭的価値を有する電子バリューとは、商品券のような有価証券を電子化したものであってもよい。
【００１８】
負荷分散装置１０の取得部１１は、複数のエッジサーバ４０の夫々の状態を示す状態情報を取得する。取得部１１は、状態情報を、複数のエッジサーバ４０の夫々から取得してもよいし、複数のエッジサーバ４０の夫々の状態を監視する図示しない監視サーバ等から取得してもよい。状態情報は、例えば、エッジサーバ４０に掛かる負荷状態を表す負荷状態情報であってもよいし、エッジサーバ４０の動作状態を表す動作状態情報であってもよいし、エッジサーバ４０が有する性能を表す性能情報であってもよい。状態情報は、例えば、エッジサーバ４０のＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）の使用率、エッジサーバ４０に含まれるメモリの使用率等が挙げられるがこれに限定されるものではない。取得部１１は、複数のエッジサーバ４０の夫々に対する状態情報を、決定部１２に供給する。
【００１９】
決定部１２は、取得部１１から複数のエッジサーバ４０の夫々に対する状態情報を受け取る。決定部１２は、受け取った状態情報に基づいて、複数のエッジサーバ４０のうち、ナンス（ｎｏｎｃｅ）値を計算するエッジサーバを決定する。ナンス値とは、１以上の取引データを含む取引データ群（ブロックとも呼ぶ）に含まれる、該取引データ群固有の値である。決定部１２は、状態情報が負荷状態情報の場合、この負荷状態情報に基づいて、複数のエッジサーバ４０のうち、例えば、最も負荷が小さいエッジサーバを、ナンス値を計算するエッジサーバとして決定する。
【００２０】
図２は、本実施の形態に係る負荷分散装置１０の処理の流れの一例を示すフローチャートである。図２に示す通り、取得部１１が、複数のエッジサーバの夫々の状態を示す状態情報を取得する（ステップＳ１）。そして、ステップＳ１で取得した状態情報に基づいて、決定部１２が、複数のエッジサーバのうち、取引データ群のナンス値を計算するエッジサーバを決定する（ステップＳ２）。以上により、負荷分散装置１０は、処理を終了する。
【００２１】
一般的に、ナンス値の計算には、大きな負荷が掛かる。したがって、１つのエッジサーバのみが、複数の取引データ群の夫々のナンス値の計算を行うと、この１つのエッジサーバに大きな負荷が掛かってしまう。しかしながら、本実施の形態に係るシステム１では、負荷分散装置１０の決定部１２が複数のエッジサーバの夫々の状態情報に基づいて、ナンス値を計算するエッジサーバを決定する。これにより、ナンス値の計算を行うタイミングにおいて、負荷分散装置１０は、例えば、負荷がより小さいエッジサーバ、高性能なエッジサーバなど、ナンス値を計算するのに適したエッジサーバを決定することができる。これにより、システム１は、システム１に含まれるある特定のエッジサーバに負荷が掛からないようにすることができる。したがって、システム１は、システム１に含まれるエッジサーバ４０の負荷分散を行うことができる。
【００２２】
また、エッジサーバの負荷分散を行うことにより、システム１は、利用者と店舗との間の取引に対する決済処理の時間を短くすることができる。
【００２３】
＜第２の実施の形態＞
次に、上述した第１の実施の形態を基本とする第２の実施の形態について説明する。まず、本実施の形態に係るシステム（負荷分散システム）２の全体構成を、図３を用いて説明する。図３は、本実施の形態に係るシステム２の全体構成の一例を示す図である。図３に示す通り、本実施の形態に係るシステム２は、複数のエッジサーバ（１００−１〜１００−ｎ（ｎ＞＝２））と、利用者端末２００と、店舗端末３００と、を含む。なお、図３に示すシステム２に含まれる装置は、本実施の形態に特有な構成について示したものであり、図３に示すシステム２が、図３に示されていない構成を有していてもよいことは言うまでもない。
【００２４】
なお、本実施の形態では、複数のエッジサーバ（１００−１〜１００−ｎ）の夫々を区別しない場合、または、総称する場合には、これらをエッジサーバ１００と呼ぶ。また、図３では、利用者端末２００と、店舗端末３００とを１つずつ示しているが、利用者端末２００と店舗端末３００とは、複数であってもよい。
【００２５】
エッジサーバ１００と、利用者端末２００と、店舗端末３００とは、ネットワークを介して、互いに通信可能に接続している。
【００２６】
店舗端末３００は、複数の店舗の夫々に設置された、例えば、ＰＯＳ（Ｐｏｉｎｔ  Ｏｆ  Ｓａｌｅｓ）端末によって実現される。店舗端末３００は、１つの店舗において、複数であってもよい。また、店舗端末３００は、１以上のＰＯＳ端末が設置されている店舗において、１以上のＰＯＳ端末から出力された情報を管理するＰＯＳシステムであってもよい。また、店舗が電子商店の場合、店舗端末３００は、例えば、該電子商店を関するサーバであってもよい。また、本実施の形態では、店舗は、所定の範囲内（例えば、所定の地域）で商品の販売を行っている店舗であるとする。
【００２７】
利用者端末２００は、利用者が所持する端末であり、例えば、スマートフォン、タブレットおよびウェアラブル端末等の移動端末であってもよく、デスクトップ型のパーソナルコンピュータであってもよい。利用者端末２００は、所定の範囲内で商品の販売を行う店舗と、取引を行うことができる端末である。
【００２８】
エッジサーバ１００は、上述した所定の範囲内の店舗が有する店舗端末３００、および、所定の範囲内の店舗を利用可能な利用者の利用者端末２００に接続するサーバである。エッジサーバ１００は、例えば、所定の閉域網上に配置されている。エッジサーバ１００は、所定の金銭的価値を有する電子バリューを用いた利用者と店舗との間の取引に関する取引データを所定のプロトコルに従って仲介する。本実施の形態では、所定のプロトコルが、ブロックチェーン技術であるとして説明を行う。また、本実施の形態では、電子バリューを仮想通貨と呼ぶ。
【００２９】
なお、本実施の形態では、図３に示す通り、第１の実施の形態において説明した負荷分散装置１０が複数のエッジサーバ１００の夫々に含まれる構成について説明する。なお、負荷分散装置１０は、一部のエッジサーバ１００に含まれるものであってもよい。また、負荷分散装置１０は、エッジサーバ１００とは異なる装置内に設けられるものであってもよい。負荷分散装置１０がエッジサーバ１００とは異なる装置内に設けられる例を、図４を用いて説明する。図４は、システム２の他の構成の一例を示す図である。図４に示すシステム２に含まれる負荷分散装置１０は、エッジサーバ１００とネットワークを介して接続された、決済処理をまとめて管理する中央決済機関に設けられるものであってもよい。
【００３０】
図５は、本実施の形態に係るシステム２における、エッジサーバ１００、利用者端末２００および店舗端末３００の機能構成の一例を示す機能ブロック図である。
【００３１】
（利用者端末２００）
図５に示す通り、本実施の形態に係るシステム２における利用者端末２００は、生成部２１０と、送信部２２０と、記憶部２３０と、取得部２４０と、受信部２５０とを備えている。なお、本実施の形態では、店舗または利用者が所持する仮想通貨が管理（保持）されている場所を仮想通貨の財布の場所と呼ぶ。つまり、説明の便宜上、この場所に管理された仮想通貨をひとまとめにしたものを、仮想通貨の財布と呼ぶ。仮想通貨の財布には、該財布を有する店舗または利用者が保持する仮想通貨が含まれるとも言える。仮想通貨の財布は、例えばフォルダ等で表現することができる。この場合、仮想通貨の財布の場所とは、このフォルダの場所である。
【００３２】
取得部２４０は、店舗端末３００から、商品情報と、店舗アドレスとを取得する。取得部２４０による商品情報と店舗アドレスとの取得方法は、後述する。取得部２４０が店舗端末３００から取得した商品情報と店舗アドレスとは、店舗端末３００の秘密鍵で暗号化されている。取得部２４０は、この暗号化された商品情報と店舗アドレスとを生成部２１０に供給する。
【００３３】
生成部２１０は、利用者固有の秘密鍵と公開鍵とを生成する。生成部２１０が生成した秘密鍵と公開鍵とを、夫々、利用者の秘密鍵、利用者の公開鍵と呼ぶ。この秘密鍵は、数字と記号との組み合わせで表現されるものであってもよい。生成部２１０は、まず、秘密鍵を生成し、生成した秘密鍵に基づいて、公開鍵を生成してもよい。
【００３４】
また、生成部２１０は、生成した秘密鍵と公開鍵とを用いて、利用者端末２００を有する利用者が利用する、仮想通貨の財布の場所（例えば、口座番号）に相当するアドレスを生成する。生成部２１０は、秘密鍵と公開鍵とを用いて、例えば、ハッシュ計算を行うことにより、上記アドレスを生成する。利用者端末２００が生成するアドレスを、以下では利用者アドレスと呼ぶ。
【００３５】
これにより、利用者は、利用者アドレスによって示される場所で管理された仮想通貨を用いて、取引を行うことができる。
【００３６】
本実施の形態では、この利用者アドレスによって示される、仮想通貨の財布の場所は、利用者端末２００内であるとするが、利用者端末２００と通信可能に接続された他の装置上であってもよい。例えば、仮想通貨の財布の場所は、インターネットを介して接続された他のサーバ上であってもよい。
【００３７】
また、仮想通貨の財布に含まれる仮想通貨は、該財布内の仮想通貨を利用可能に設定された複数の利用者端末２００で利用されてもよい。例えば、利用者が複数の利用者端末２００を有している場合、これら複数の利用者端末２００の夫々において仮想通貨の財布を利用可能な設定を行うことによって、利用者が複数の利用者端末２００の夫々から該財布内の仮想通貨を利用できるようにしてもよい。
【００３８】
生成部２１０は、生成した秘密鍵、公開鍵および利用者アドレスを、互いに関連付けて、記憶部２３０に格納する。また、生成部２１０は、生成した公開鍵を、送信部２２０に供給する。
【００３９】
また、生成部２１０は、取得部２４０から商品情報と店舗アドレスとを受け取る。生成部２１０は、受け取った商品情報および店舗情報と、利用者アドレスとを含み、利用者の秘密鍵で暗号化した取引データを生成する。
【００４０】
また、生成部２１０は、受信部２５０から、店舗の公開鍵を受け取ると、利用者の電子署名を生成する。また、生成部２１０は、受信部２５０がブロックチェーンにブロック（取引データ群）が追加される度に受信する、追加されたブロックのハッシュ値を、受信部２５０から受け取る。生成部２１０は、取引データに対して、受け取ったハッシュ値と、受け取った店舗の公開鍵とを加えたデータのハッシュ値を計算する。そして、計算したハッシュ値を、利用者の秘密鍵で暗号化し、暗号化したハッシュ値を電子署名として生成する。そして、生成部２１０は、生成した電子署名を添付した取引データを生成する。生成部２１０は、この電子署名を添付した取引データを送信部２２０に供給する。
【００４１】
送信部２２０は、生成部２１０から、生成部２１０が生成した、利用者の公開鍵を受け取る。送信部２２０は、エッジサーバ１００に対し、受け取った利用者の公開鍵を送信する。送信部２２０が利用者の公開鍵を送信する宛先（送信先）のエッジサーバ１００は、複数のエッジサーバ１００の何れであってもよいし、利用者端末２００との距離が最も近いエッジサーバ１００であってもよい。なお、送信部２２０は、利用者の公開鍵の送信先のエッジサーバ１００に関する情報を、記憶部２３０に格納してもよい。例えば、送信部２２０は、利用者端末２００が通信可能なエッジサーバ１００（例えば、利用者端末２００との距離が最も近いエッジサーバ１００）に関する情報を、記憶部２３０に格納してもよい。エッジサーバ１００に関する情報は、たとえば、エッジサーバ１００のＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレスであってもよいし、その他の情報であってもよい。
【００４２】
また、送信部２２０は、エッジサーバ１００に対し、利用者端末２００の認証を要求する認証要求メッセージを送信する。また、送信部２２０は、エッジサーバ１００に対し、店舗の公開鍵の送信依頼を送信する。
【００４３】
また、送信部２２０は、生成部２１０から、電子署名が添付された取引データを受け取る。送信部２２０は、この電子署名が添付された取引データを、エッジサーバ１００に送信する。送信部２２０が取引データを送信する宛先（送信先）のエッジサーバ１００は、複数のエッジサーバ１００の何れであってもよいし、所定のエッジサーバであってもよい。所定のエッジサーバとは、例えば、利用者端末２００との距離が最も近いエッジサーバ１００であるが、これに限定されるものではない。利用者端末２００と距離が近いエッジサーバ１００に取引データを送信する構成の場合、システム２は、取引データの送信に掛かる時間を削減することができる。
【００４４】
記憶部２３０は、互いに関連付けられた、利用者の秘密鍵、公開鍵および利用者アドレスを格納する。なお、記憶部２３０は、利用者端末２００とは別個の記憶装置によって実現されるものであってもよい。つまり、利用者の秘密鍵、公開鍵および利用者アドレスは、利用者端末２００とは別個のサーバ上で管理されるものであってもよい。また、利用者の秘密鍵、公開鍵および利用者アドレスは、例えば、これらが印字された紙によって管理されるものであってもよい。
【００４５】
受信部２５０は、ブロックチェーンにブロックが追加される度に、追加されたブロックのハッシュ値を受信する。受信部２５０は受信したハッシュ値を生成部２１０に供給する。
【００４６】
受信部２５０は、エッジサーバ１００から認証要求メッセージの応答メッセージを受信する。認証要求メッセージ受信後の処理は、図８から図１０に示すフローチャートを用いて説明する。
【００４７】
また、受信部２５０は、エッジサーバ１００から、店舗の公開鍵の送信要求に対する応答として、店舗の公開鍵を受信する。受信部２５０は、受信した店舗の公開鍵を、生成部２１０に供給する。
【００４８】
また、受信部２５０は、エッジサーバ１００から、最新のブロックのナンス値を受信する。受信部２５０は、受信したナンス値を、生成部２１０に供給する。
【００４９】
なお、利用者端末２００上において、仮想通貨を利用する際に用いる専用のアプリケーションプログラムが起動した状態の場合に、利用者が仮想通貨を用いた取引を行うことができてもよい。つまり、利用者端末２００内の各部の機能は、この専用のアプリケーションプログラムが実行されることで実現されてもよい。
【００５０】
（店舗端末３００）
図５に示す通り、本実施の形態に係るシステム２における、店舗端末３００は、生成部３１０と、送信部３２０と、記憶部３３０と、出力部３４０とを備えている。
【００５１】
生成部３１０は、店舗固有の秘密鍵と公開鍵とを生成する。生成部３１０が生成した秘密鍵と公開鍵とを、夫々、該店舗の秘密鍵、店舗の公開鍵と呼ぶ。この秘密鍵は、数字と記号との組み合わせで表現されるものであってもよい。生成部３１０は、まず、秘密鍵を生成し、生成した秘密鍵に基づいて、公開鍵を生成してもよい。
【００５２】
また、生成部３１０は、生成した秘密鍵と公開鍵とを用いて、店舗端末３００が設けられた店舗が利用する、仮想通貨の財布の場所（例えば、口座番号）に相当するアドレスを生成する。生成部３１０は、秘密鍵と公開鍵とを用いて、例えば、ハッシュ計算を行うことにより、上記アドレスを生成する。店舗端末３００が生成するアドレスを、以下では店舗アドレスと呼ぶ。
【００５３】
なお、本実施の形態では、店舗アドレスによって示される仮想通貨の財布の場所は、店舗端末３００内であるとするが、店舗端末３００と通信可能に接続された他の装置上であってもよい。例えば、仮想通貨の財布の場所は、インターネットを介して接続された他のサーバ上であってもよい。
【００５４】
また、店舗の財布に含まれる仮想通貨は、利用者の財布に含まれる仮想通貨と同様に、利用可能に設定された複数の店舗端末３００で利用されてもよい。
【００５５】
生成部３１０は、生成した秘密鍵、公開鍵および店舗アドレスを、互いに関連付けて、記憶部３３０に格納する。また、生成部３１０は、生成した公開鍵を、送信部３２０に供給する。
【００５６】
また、生成部３１０は、商品の金額（仮想通貨の取引量）を示す情報を少なくとも含む商品情報と、店舗の財布の場所（店舗アドレス）とを暗号化したデータを生成する。このとき、生成部３１０は、暗号化したデータ（商品データと呼ぶ）を表現する識別子を生成してもよい。この識別子は、例えば、バーコードであってもよいし、二次元コードであってもよいし、その他の情報であってもよい。生成部３１０は、生成した商品データまたは識別子を出力部３４０に供給する。
【００５７】
送信部３２０は、生成部３１０から、生成部３１０が生成した店舗の公開鍵を受け取る。送信部３２０は、エッジサーバ１００に対し、受け取った店舗の公開鍵を送信する。送信部３２０が店舗の公開鍵を送信する宛先（送信先）のエッジサーバ１００は、複数のエッジサーバ１００の何れであってもよいし、店舗端末３００との距離が最も近いエッジサーバ１００であってもよい。
【００５８】
記憶部３３０は、互いに関連付けられた、店舗の秘密鍵、公開鍵および店舗アドレスを格納する。なお、記憶部３３０は、店舗端末３００とは別個の記憶装置によって実現されるものであってもよい。つまり、店舗の秘密鍵、公開鍵および店舗アドレスは、店舗端末３００とは別個のサーバ上で管理されるものであってもよい。また、店舗の秘密鍵、公開鍵および店舗アドレスは、例えば、これらが印字された紙によって管理されるものであってもよい。
【００５９】
出力部３４０は、生成部３１０から商品データまたは識別子を受け取る。出力部３４０は、生成部３１０から受け取った商品データまたは識別子を出力する。出力部３４０が生成部３１０から受け取ったデータが識別子の場合、出力部３４０は、所定の用紙に識別子を印字することにより、識別子を出力してもよい。また、出力部３４０が生成部３１０から受け取ったデータが識別子の場合、出力部３４０は、図示しない表示画面に識別子を表示させることにより、識別子を出力してもよい。このような構成によって、本実施の形態における店舗端末３００は、例えば、電子貨幣の利用の際に必要なリーダライタなどを設けることなく、商品の取引を行うことができる。
【００６０】
また、出力部３４０が受け取ったデータが商品データの場合、出力部３４０は、利用者端末２００に商品データを出力（送信）してもよい。この場合、出力部３４０は、送信部３２０と一体となって形成されていてもよい。
【００６１】
出力部３４０は、例えば、近距離無線通信規格を用いた通信によって、商品データを利用者端末２００に送信してもよい。近距離無線通信規格としては、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＮＦＣ（Ｎｅａｒ  Ｆｉｅｌｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）等であってもよい。また、出力部３４０は、赤外線通信によって、商品データを利用者端末２００に送信してもよい。また、利用者端末２００と店舗端末３００との間で通信を行うことができる、アプリケーションプログラムを、利用者端末２００および店舗端末３００上で起動させることにより、店舗端末３００は、利用者端末２００に、商品データを送信してもよい。また、店舗端末３００は、ＳＭＳ（Ｓｈｏｒｔ  Ｍｅｓｓａｇｅ  Ｓｅｒｖｉｃｅ）、ＳＮＳ（Ｓｏｃｉａｌ  Ｎｅｔｗｏｒｋ  Ｓｅｒｖｉｃｅ）等のサービスを利用して、利用者端末２００に、商品データを送信してもよい。また、店舗端末３００は、電子メールを用いて、利用者端末２００に商品データを送信してもよい。以上のように、店舗端末３００が、利用者端末２００に対し、商品データを送信する方法は特に限定されない。
【００６２】
なお、店舗端末３００上において、仮想通貨を利用する際に用いる専用のアプリケーションプログラムが起動した状態の場合に、店舗が仮想通貨を用いた取引を行うことができてもよい。つまり、店舗端末３００内の各部の機能は、この専用のアプリケーションプログラムが実行されることで実現されてもよい。
【００６３】
（エッジサーバ１００）
図５に示す通り、本実施の形態に係るシステム２における、エッジサーバ１００は、取得部１１０と、決定部１２０と、記憶部１３０と、受信部１４０と、送信部１５０と、計算部１６０と、認証部１７０と、を備える。取得部１１０および決定部１２０は、夫々、上述した第１の実施の形態における取得部１１および決定部１２に相当する。つまり、図５において、破線の枠で囲った部分は、上述した第１の実施の形態における負荷分散装置１０に相当する。
【００６４】
取得部１１０は、後述する、承認前のブロックが生成されたことを示す通知を、計算部１６０から受け取る。取得部１１０は、上記通知を受け取ると、複数のエッジサーバ１００の夫々の状態を示す状態情報を取得する。取得部１１０は、状態情報を、複数のエッジサーバ１００の夫々から取得してもよいし、複数のエッジサーバ１００の夫々の状態を監視する図示しない監視サーバ等から取得してもよい。状態情報は、例えば、エッジサーバ１００に掛かる負荷状態を表す負荷状態情報であってもよいし、エッジサーバ１００の動作状態を表す動作状態情報であってもよいし、エッジサーバ１００が有する性能を表す性能情報であってもよい。取得部１１０は、取得した、複数のエッジサーバ１００の夫々に対する状態情報を、決定部１２０に供給する。
【００６５】
決定部１２０は、取得部１１０から複数のエッジサーバ１００の夫々に対する状態情報を受け取る。決定部１２０は、受け取った状態情報に基づいて、複数のエッジサーバ１００のうち、承認前のブロックのナンス値を計算するエッジサーバを決定する。例えば、決定部１２０は、状態情報が負荷状態情報の場合、この負荷状態情報に基づいて、複数のエッジサーバ１００のうち、最も負荷が小さいエッジサーバを、ナンス値を計算するエッジサーバとして決定する。決定部１２０は、決定したエッジサーバを示す情報（決定結果）を計算部１６０に供給する。
【００６６】
受信部１４０は、利用者端末２００から利用者の公開鍵を受信する。受信部１４０は利用者の公開鍵の送信元である利用者端末２００を識別する情報を、受信した利用者の公開鍵に関連付けて、記憶部１３０に格納する。また、受信部１４０は、店舗端末３００から店舗の公開鍵を受信する。受信部１４０は店舗の公開鍵の送信元である店舗端末３００を識別する情報を、受信した店舗の公開鍵に関連付けて、記憶部１３０に格納する。
【００６７】
また、受信部１４０は、利用者端末２００から認証要求メッセージを受信する。受信部１４０は、受信した認証要求メッセージを認証部１７０に供給する。
【００６８】
また、受信部１４０は、利用者端末２００から、店舗の公開鍵の送信依頼を受信する。受信部１４０は、受信した、店舗の公開鍵の送信依頼を、送信部１５０に供給する。
【００６９】
また、受信部１４０は、利用者端末２００から、電子署名が添付された取引データを受信する。受信部１４０は、受信した取引データを計算部１６０に供給する。
【００７０】
なお、この受信部１４０における、認証要求メッセージおよび／または電子署名が添付された取引データを受信する機能は、エッジサーバ１００が備える受信部１４０の全てに含まれる機能であってもよいし、一部に含まれる機能であってもよい。例えば、認証要求メッセージを受信するエッジサーバ１００がエッジサーバ１００−１のみの場合、後述する認証部１７０による認証処理を集約することができる。この場合、このエッジサーバ１００−１以外のエッジサーバ１００は、後述する認証部１７０を備えなくてもよい。
【００７１】
また、受信部１４０は、他のエッジサーバ１００から、ナンス値が含まれている、または、ナンス値が含まれていないブロックを受信すると、該ブロックを計算部１６０に供給する。
【００７２】
記憶部１３０は、店舗を識別する情報に関連付けられた、店舗の公開鍵を格納する。また、記憶部１３０は、利用者を識別する情報に関連付けられた、利用者の公開鍵を格納する。なお、記憶部１３０内に格納された店舗の公開鍵および利用者の公開鍵が更新（追加）される度に、エッジサーバ１００は、各エッジサーバ１００の記憶部１３０に格納された公開鍵の整合を取ることが好ましい。これにより、利用者端末２００または店舗端末３００から送信された暗号化データを、全てのエッジサーバ１００で復号することができる。
【００７３】
また、記憶部１３０は、ブロックチェーンにつながった、１以上の取引データを含むブロックを格納する。
【００７４】
なお、記憶部１３０は、エッジサーバ１００とは別個の記憶装置で実現されるものであってもよい。この記憶装置は、複数のエッジサーバ１００の夫々からアクセス可能な位置に配置されていればよい。これにより、複数のエッジサーバ１００で、記憶部１３０に格納されたデータを共有することができる。
【００７５】
また、記憶部１３０に格納されたデータの一部（例えば、店舗の公開鍵および利用者の公開鍵）が、エッジサーバ１００とは異なる記憶装置に格納されていてもよい。
【００７６】
計算部１６０は、受信部１４０が受信した取引データを、該取引データを送信した送信元の利用者端末２００に関する公開鍵で復号する。取引データには、店舗の秘密鍵で暗号化された商品情報および店舗アドレスが含まれる。そのため、計算部１６０は、記憶部１３０に格納された全ての店舗の公開鍵を用いて、暗号化された商品情報および店舗アドレスを復号する。そして、計算部１６０は、新たなブロックに含める取引データを、取引データが生成された順にまとめる。この取引データをまとめたブロックは、承認が行われる前のブロックであるため、承認前のブロックとも呼ぶ。そして、計算部１６０は、この承認前のブロックが生成されたことを示す通知を、取得部１１０に供給する。
【００７７】
また、計算部１６０は、決定部１２０から決定結果を受け取る。計算部１６０は、決定結果に基づいて、決定部１２０が決定したエッジサーバが自サーバか否かを確認する。自サーバではない場合、計算部１６０は、決定結果と承認前のブロックとを、送信部１５０に供給する。
【００７８】
計算部１６０は、確認結果が自サーバの場合、または、受信部１４０からナンス値が含まれていない承認前のブロックを受信した場合、承認前のブロックのナンス値を計算する。計算部１６０は、計算したナンス値と、承認前のブロックの直前のブロックのハッシュ値（ブロックチェーンに含まれるブロックのうち最新のブロックのナンス値）とを、承認前のブロックに含めて、該承認前のブロックを送信部１５０に供給する。
【００７９】
また、計算部１６０は、受信部１４０からナンス値が含まれる承認前のブロックを受信すると、該承認前のブロックに含まれるナンス値を検算する。
【００８０】
認証部１７０は、受信部１４０から認証要求メッセージを受け取る。受信部１４０は、受け取った認証要求メッセージの送信元（つまり、利用者端末２００）に関する公開鍵を記憶部１３０から取得し、該公開鍵を用いて、認証要求メッセージを復号する。そして、認証部１７０は、復号した認証要求メッセージに基づいて、認証要求メッセージを送信した利用者端末２００の認証を行う。そして、認証部１７０は、認証結果を送信部１５０に供給する。
【００８１】
送信部１５０は、認証部１７０から認証結果を受け取る。送信部１５０は、認証要求メッセージの応答メッセージとして、受け取った認証結果を、認証要求メッセージの送信元である利用者端末２００に送信する。
【００８２】
また、送信部１５０は、受信部１４０から、店舗の公開鍵の送信依頼を受け取る。そして、該送信依頼に関連する店舗の公開鍵を記憶部１３０から取得し、取得した公開鍵を、利用者端末２００に送信する。
【００８３】
また、送信部１５０は、計算部１６０から、計算されたナンス値を含む、承認前のブロックを受信すると、該承認前のブロックを他のエッジサーバ１００に同報する。
【００８４】
また、送信部１５０は、計算部１６０から、ナンス値を含まない承認前のブロックを決定結果と共に受信すると、該承認前のブロックを、決定結果によって示されるエッジサーバに送信する。
【００８５】
（利用者登録処理の流れ）
次に、利用者が仮想通貨を利用する際の、登録（利用者登録）処理の流れについて説明する。この利用者登録処理は、利用者端末２００からエッジサーバ１００に対して、仮想通貨を利用した取引を行うために必要な情報を送信する処理である。図６は、本実施の形態における、利用者登録処理の流れの一例を示すフローチャートである。
【００８６】
図６に示す通り、まず、利用者端末２００の生成部２１０が、利用者固有の秘密鍵と公開鍵とを生成する（ステップＳ６１）。そして、生成部２１０は、生成した秘密鍵と公開鍵とを用いて、利用者アドレスを生成する（ステップＳ６２）。
【００８７】
その後、生成部２１０は、生成した秘密鍵、公開鍵および利用者アドレスを、互いに関連付けて、記憶部２３０に格納する（ステップＳ６３）。そして、送信部２２０は、エッジサーバ１００に対し、生成部２１０から供給された公開鍵を送信する（ステップＳ６４）。なお、ステップＳ６３とステップＳ６４とは同時に行われてもよいし、逆順で行われてもよい。
【００８８】
以上により、利用者登録処理を終了する。
【００８９】
このように、利用者端末２００がエッジサーバ１００に対して、利用者の公開鍵を送信することにより、利用者端末２００は、利用者アドレスによって示される場所で管理された仮想通貨を利用することができる。
【００９０】
（店舗登録処理の流れ）
次に、店舗が仮想通貨を利用する際の、登録（店舗登録）処理の流れについて説明する。この店舗登録処理は、店舗端末３００からエッジサーバ１００に対して、仮想通貨を利用した取引を行うために必要な情報を送信する処理である。図７は、本実施の形態における、店舗登録処理の流れの一例を示すフローチャートである。
【００９１】
図７に示す通り、まず、店舗端末３００の生成部３１０が、店舗固有の秘密鍵と公開鍵とを生成する（ステップＳ７１）。そして、生成部３１０は、生成した秘密鍵と公開鍵とを用いて、店舗アドレスを生成する（ステップＳ７２）。
【００９２】
その後、生成部３１０は、生成した秘密鍵、公開鍵および店舗アドレスを、互いに関連付けて、記憶部３３０に格納する（ステップＳ７３）。そして、送信部３２０は、エッジサーバ１００に対し、生成部３１０から供給された公開鍵を送信する（ステップＳ７４）。なお、ステップＳ７３とステップＳ７４とは同時に行われてもよいし、逆順で行われてもよい。
【００９３】
以上により、店舗登録処理を終了する。
【００９４】
このように、店舗端末３００がエッジサーバ１００に対して、店舗の公開鍵を送信することにより、店舗端末３００は、店舗アドレスによって示される場所で管理された仮想通貨を利用することができる。
【００９５】
（仮想通貨を用いた商品の取引について）
本実施の形態に係るシステム２では、仮想通貨を用いた取引は、上述したシステム１と同様に、一般的なブロックチェーン技術を用いる。したがって、エッジサーバ１００の送信部１５０は、ブロックチェーンにブロックが追加される度に、追加されたブロックのハッシュ値を、仮想通貨を利用可能な利用者の利用者端末２００に送信する。追加されたブロックは、ブロックチェーンにおける、最新のブロックであって、承認済みのブロックである。ブロックチェーンにブロックが追加されたこと（つまり、全てのエッジサーバ１００で承認が行われたブロックが、記憶部１３０に格納されたこと）は、送信部１５０が確認してもよいし、計算部１６０が確認してもよい。これにより、仮想通貨を利用可能な利用者の利用者端末２００間で、最新のブロックのハッシュ値を共有することができる。
【００９６】
（利用者端末２００による商品情報の取得の流れ）
利用者端末２００が、商品の金額を示す情報を少なくとも含む商品情報を、店舗の財布の場所（店舗アドレス）と共に、受信するまでの流れについて説明する。なお、店舗の店舗端末３００は、予め販売する商品または提供するサービスの代金を仮想通貨に換算しているとする。
【００９７】
例えば、店舗が、実際に存在する実店舗であり、利用者端末２００が、移動端末である場合について説明する。利用者が実店舗において、商品の購入手続きを行うと、店舗の店舗端末３００の生成部３１０は、商品情報と、店舗アドレスとを情報として含み、店舗の秘密鍵で暗号化した識別子を生成する。本実施の形態では、識別子が二次元コードであるとして説明を行う。そして、出力部３４０は、生成部３１０が生成した識別子を出力する。
【００９８】
利用者は、利用者端末２００に、店舗端末３００から出力された二次元コードを読み取らせる。つまり、利用者端末２００の取得部２４０が、店舗端末３００から出力された二次元コードを読み取る。上述したとおり、二次元コードには、商品情報と、店舗アドレスとが含まれる。これにより、利用者端末２００は、店舗の秘密鍵で暗号化された、商品情報と店舗アドレスとを取得することができる。
【００９９】
また、店舗端末３００の生成部３１０が生成したデータが、商品情報と店舗アドレスとを該生成部３１０によって暗号化した商品データの場合、利用者端末２００の取得部２４０は、店舗端末３００から、例えば、上述した所定のサービス等を利用して、商品情報と店舗アドレスとを受信（取得）してもよい。
【０１００】
また、例えば、店舗が電子商店の場合、店舗端末３００は、商品情報と店舗アドレスとを暗号化した商品データを生成する。そして、利用者端末２００の取得部２４０は、ネットワークを介して、暗号化された商品データを受信する。この商品データには、上述したとおり、商品情報と店舗アドレスとが含まれるため、利用者端末２００は、店舗の秘密鍵で暗号化された商品情報と店舗アドレスとを取得することができる。
【０１０１】
以上のように、利用者端末２００は、店舗端末３００から、店舗の秘密鍵で暗号化された商品情報と店舗アドレスとを取得することができる。
【０１０２】
なお、利用者端末２００は、店舗端末３００から送信される商品情報によって示される商品の金額を、図示しない表示画面に表示してもよい。このとき、店舗端末３００は、店舗の秘密鍵で暗号化した商品情報とは別に、利用者端末２００に商品情報を送付してもよい。また、このとき、利用者端末２００は、エッジサーバ１００から店舗端末３００の公開鍵を取得し、暗号化された商品情報を、取得した店舗の公開鍵で復号してもよい。これにより、利用者は、取引する商品の金額を確認することができる。
【０１０３】
（システム２の決済処理の流れ）
次に、利用者端末２００が商品情報と店舗アドレスとを受信した後の、システム２の決済処理について説明する。図８から図１０は夫々、本実施の形態における、決済処理の流れの一例を示すフローチャートである。なお、図８および図９では、利用者端末２００の処理を左側に、エッジサーバ１００の処理を右側に示している。また、エッジサーバ１００の処理と、利用者端末２００の処理との間の破線の矢印はデータの流れを示している。また、本実施の形態において、後述するナンス値を計算するエッジサーバを決定するエッジサーバは、あらかじめ決まっているとして説明を行う。
【０１０４】
図８に示す通り、利用者端末２００の生成部２１０が、取得部２４０が読み取った（取得した）、店舗の秘密鍵で暗号化された商品情報および店舗アドレスと、利用者の財布の場所（利用者アドレス）とを含み、利用者の秘密鍵で暗号化した取引データを生成する（ステップＳ８１）。
【０１０５】
そして、利用者端末２００の送信部２２０は、エッジサーバ１００に対し、取引の認証要求メッセージを送信する（ステップＳ８２）。認証要求メッセージには、利用者の秘密鍵で暗号化された、利用者を識別する情報（利用者識別情報）が含まれる。そして、エッジサーバ１００の受信部１４０は、利用者端末２００から送信された認証要求メッセージを受信する（ステップＳ８３）。
【０１０６】
そして、認証部１７０が、認証要求メッセージを送信した利用者端末２００の認証を行う（ステップＳ８４）。送信部１５０は、認証要求メッセージの応答メッセージとして、利用者端末２００に送信する（ステップＳ８５）。
【０１０７】
その後、利用者端末２００の受信部２５０は、応答メッセージを受信する（ステップＳ８６）。そして、受信部２５０は、応答メッセージに基づいて、認証されたか否かを確認し（ステップＳ８７）する。認証された場合（ステップＳ８７にてＹＥＳ）、受信部２５０は、送信部２２０に、商品の購入手続きを行っている店舗の公開鍵の送信依頼の送信指示を行い、送信部２２０は、該送信依頼を、エッジサーバ１００に送信する（ステップＳ８８）。送信部２２０が送信する送信依頼に関連する店舗を特定する情報は、例えば、識別子を読み取る際に、識別子と共に取得されるものであってもよいし、商品データを取得する際に、該商品データと共に取得するものであってもよい。また、商品データがネットワークを介して送信されたものであった場合、送信部２２０が送信する送信依頼に関連する店舗を特定する情報は、商品データの送信元から特定されるものであってもよい。
【０１０８】
なお、本実施の形態では、認証されなかった場合（ステップＳ８７にてＮＯ）、認証処理を終了するとするが、利用者端末２００は、例えば、ステップＳ８２に戻って、再度、認証要求メッセージを送信してもよい。
【０１０９】
また、認証結果が認証されなかったことを示す場合、送信部１５０は、応答メッセージを送信しなくてもよい。この場合、利用者端末２００は、認証要求メッセージを送信してから所定期間内に応答メッセージを受信しなかった場合に、認証されなかったことを示す情報を表示画面に表示し、決済処理を終了してもよい。
【０１１０】
ステップＳ８８終了後、エッジサーバ１００の受信部１４０が店舗の公開鍵の送信依頼を、受信する（ステップＳ８９）。その後、送信部１５０は、受信部１４０が受信した送信依頼に関連する店舗の公開鍵を記憶部１３０から取得し、取得した公開鍵を、利用者端末２００に送信する（ステップＳ９０）。
【０１１１】
利用者端末２００の受信部２５０は、エッジサーバ１００から、店舗の公開鍵を受信する（ステップＳ９１）。そして、生成部２１０は、利用者の電子署名を生成する（ステップＳ９２）。その後、送信部２２０は、ステップＳ９２で生成された電子署名が添付された、ステップＳ８１で生成された取引データを、エッジサーバ１００に送信する（ステップＳ９３）。これにより、利用者のなりすましを防ぐことができる。
【０１１２】
その後、エッジサーバ１００の受信部１４０は、利用者端末２００から送信された、電子署名が添付された取引データを受信する（ステップＳ９４）。なお、この取引データを受信するエッジサーバ１００は、ステップＳ９０までの処理を行ったエッジサーバ１００と同じエッジサーバであってもよいし、異なるエッジサーバであってもよい。
【０１１３】
エッジサーバ１００の計算部１６０は、受信部１４０が受信した取引データを、該取引データを送信した送信元の利用者端末２００に関する公開鍵で復号する（ステップＳ９５）。取引データには、上述したとおり、店舗の秘密鍵で暗号化された商品情報および店舗アドレスが含まれる。そのため、計算部１６０は、記憶部１３０に格納された全ての店舗の公開鍵を用いて、暗号化された商品情報および店舗アドレスを復号する（ステップＳ９６）。ステップＳ９６以降のエッジサーバ１００および利用者端末２００の処理は、図９に示す。
【０１１４】
その後、エッジサーバ１００の計算部１６０は、取引データを、該取引データが生成された順にまとめた、承認前のブロックを生成する（ステップＳ９７）。このとき、計算部１６０は、所定数または所定サイズの取引データをまとめてもよいし、所定時間毎に取引データをまとめてもよい。なお、取引データが他のエッジサーバ１００に送信されている場合、ステップＳ９７を行う前に、所定のエッジサーバに取引データを集約する構成であってもよい。所定のエッジサーバとは、承認前のブロックに含まれる取引データのうち、最も古い（取引が行われた時刻が一番早い）取引データを受信したエッジサーバであってもよい。また、所定の取引データは、ナンス値を計算するエッジサーバを決定する処理を行うエッジサーバに集約される構成であってもよい。
【０１１５】
そして、エッジサーバ１００の取得部１１０は、自サーバ（エッジサーバ１００）および他のエッジサーバ１００の負荷の状態を示す情報（状態情報）を取得する（ステップＳ９８）。そして、決定部１２０は、取得した状態情報に基づいて、新たなブロックに含めるナンス値を計算するエッジサーバを決定する（ステップＳ９９）。
【０１１６】
そして、計算部１６０は、決定部１２０がステップＳ９９で決定したエッジサーバが、自サーバか否かを確認する（ステップＳ１００）。ステップＳ９９で決定されたエッジサーバが、他のエッジサーバの場合（ステップＳ１００にてＮＯ）、送信部１５０は、計算部１６０がステップＳ９７でまとめた取引データ（つまり、承認前のブロック）を、決定されたエッジサーバに送信する（ステップＳ１０１）。この承認前のブロックが送信されたエッジサーバの処理は、図１０を参照して後述する。そして、ステップＳ１０４に進む。
【０１１７】
ステップＳ９９で決定されたエッジサーバが、自サーバの場合（ステップＳ１００にてＹＥＳ）、計算部１６０がステップＳ９７でまとめたブロックのナンス値を計算する（ステップＳ１０２）。この構成により、エッジサーバ１００は、ブロックを送信する処理に掛かる負荷を削減することができる。また、ブロックの送受信に掛かる時間を削減することができる。
【０１１８】
そして、計算部１６０は、計算したナンス値と、承認前のブロックの直前のブロックのハッシュ値（ブロックチェーンに含まれるブロックのうち最新のブロックのナンス値）とを、承認前のブロックに含めて、該承認前のブロックを送信部１５０に供給する。そして送信部１５０は、この承認前のブロックを他のエッジサーバに対して同報する（ステップＳ１０３）。その後、エッジサーバ１００は、ステップＳ１０８の処理に進む。
【０１１９】
ナンス値を計算するエッジサーバが他のエッジサーバの場合、ステップＳ１０１の後に、受信部１４０は、該ステップＳ１０１にて、ブロックの送信先のエッジサーバ１００から、該エッジサーバ１００が計算したナンス値と直前のブロックのハッシュ値と含むブロックを受信する（ステップＳ１０４）。計算部１６０は、受信したブロックに含まれるナンス値を検算する（ステップＳ１０５）。この計算部１６０による検算が完了すると、検算の対象となったナンス値を含むブロックが承認されることになる。そして、計算部１６０は、承認されたブロックを、記憶部１３０に格納し、新たなブロックチェーンを形成する（ステップＳ１０６）。承認されたブロックは、ブロックチェーンの最新のブロックとなる。そして、検算を行ったエッジサーバ１００は、ナンス値を計算したエッジサーバ１００に対し、ブロックを承認したことを示す通知（承認通知）を送信する（ステップＳ１０７）。
【０１２０】
エッジサーバ１００がナンス値を計算するサーバである場合、ステップＳ１０３の終了後、受信部１４０がブロックを承認したことを示す通知を受信する（ステップＳ１０８）。その後、計算部１６０は、ステップＳ１０６と同様に承認されたブロックを、記憶部１３０に格納し、新たなブロックチェーンを形成する（ステップＳ１０９）。
【０１２１】
そして、送信部１５０は、ブロックチェーンに追加されたブロックのハッシュ値（承認されたブロックのナンス値）を、利用者端末２００に送信する（ステップＳ１１０）。
【０１２２】
そして、利用者端末２００の受信部２５０は、エッジサーバ１００から送信された、最新のブロックのハッシュ値を受信する（ステップＳ１１１）。
【０１２３】
また、送信部１５０は、ブロックチェーンに追加されたブロックに含まれる１以上の取引データの夫々に関連する店舗の店舗端末３００に対し、取引が完了したことを示す通知（取引完了通知）を送信する（ステップＳ１１２）。なお、ステップＳ１１２は、ステップＳ１０９の後であれば、どのタイミングで行われてもよい。また、ステップＳ１１２を行うエッジサーバ１００は、複数のエッジサーバのうち、どのエッジサーバであってもよい。
【０１２４】
これにより、店舗端末３００を有する店舗は、取引が完了したことを確認することができる。以上の処理により、例えば、店舗から商品を購入するという取引を行った利用者の財布に含まれる仮想通貨から購入した商品の金額分の仮想通貨が差し引かれる。また、上記店舗の財布には、購入された商品の金額分の仮想通貨が追加される。
【０１２５】
図１０は、エッジサーバ１００が、図８および図９に処理を示したエッジサーバとは異なるエッジサーバである場合の処理の一例を示す図である。図１０に示す通り、エッジサーバ１００の受信部１４０は、上述したステップＳ１０１で送信された、承認前のブロックを受信する（ステップＳ１２１）。
【０１２６】
そして、計算部１６０がステップＳ１２１で受信した、承認前のブロックのナンス値を計算する（ステップＳ１２２）。そして、計算部１６０は、計算したナンス値と、承認前のブロックの直前のブロックのハッシュ値とを、承認前のブロックに含めて、該承認前のブロックを送信部１５０に供給する。そして送信部１５０は、この承認前のブロックを他のエッジサーバに対して同報する（ステップＳ１２３）。これにより、ステップＳ９９で決定したエッジサーバ以外のエッジサーバは、図９に示したステップＳ１０４〜ステップＳ１０７の処理を行うことができる。
【０１２７】
その後、ステップＳ１０７で、承認通知が送信されると、受信部１４０がブロックを承認したことを示す通知を受信する（ステップＳ１２４）。そして、計算部１６０は、承認されたブロックを、記憶部１３０に格納し、新たなブロックチェーンを形成する（ステップＳ１２５）。
【０１２８】
以上により、承認前のブロックが送信されたエッジサーバの処理を終了する。
【０１２９】
このような決済処理により、システム２は、取引データの改ざん、否認、仮想通貨の二重支払いを防止した、セキュアな電子取引を行うことができる。
【０１３０】
次に、図１１から図１３を参照して、複数のエッジサーバ１００が配置される位置について説明する。図１１から図１３は、夫々、システム２のネットワーク構成の一例を示す図である。
【０１３１】
図１１から図１３に示すネットワークには、基地局であるｅＮｏｄｅＢ（ｅＮＢ）、ＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）、Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ−Ｇａｔｅｗａｙ）およびＰ−ＧＷ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｎｅｔｗｏｒｋ−Ｇａｔｅｗａｙ）が含まれる。エッジサーバ１００は、図１１に示す通り、ｅＮＢと、Ｓ−ＧＷとの間に配置されてもよいし、図１２に示す通り、Ｓ−ＧＷとＰ−ＧＷとの間に配置されてもよいし、図１３に示す通り、Ｐ−ＧＷが接続する外部のネットワーク上に配置されていてもよい。
【０１３２】
図１３に示すように、エッジサーバ１００が、ｅＮＢよりもＰ−ＧＷ側に配置されることにより、エッジサーバ１００と通信する店舗が存在する範囲を広げることができる。したがって、システム２は、エッジサーバ１００の台数を減らすことができるため、エッジサーバ１００の設置にかかるコストを削減することができる。また、図１１に示すように、エッジサーバ１００が、Ｐ−ＧＷよりもｅＮＢ側に配置されることにより、利用者端末２００または店舗端末３００と、エッジサーバ１００との距離が近くなる。これにより、システム２は、利用者端末２００または店舗端末３００と、エッジサーバ１００との間の通信遅延を低減することができる。
【０１３３】
本実施の形態では、第１の実施の形態における負荷分散装置１０の機能が、エッジサーバ１００内に内蔵されることについて説明を行ったが、上述したとおり、負荷分散装置１０は、エッジサーバ１００とは異なる装置で実現されるものであってもよい。この場合、ステップＳ９７において、承認前のブロックを生成したエッジサーバ１００は、負荷分散装置１０を有する装置に、承認前のブロックが生成されたことを示す通知を送信してもよい。これにより、負荷分散装置１０の取得部１１が上述した取得部１１０と同様に上記通知を受け取ることにより、負荷分散装置１０は、第１の実施の形態において説明した処理を行うことができる。
【０１３４】
そして、負荷分散装置１０は、承認前のブロックを生成したエッジサーバ（上述したステップＳ９７を行ったエッジサーバ）に対し、決定したエッジサーバに承認前のブロックを送信する指示を送信する。これにより、承認前のブロックを生成したエッジサーバは、ステップＳ１０４からステップＳ１０７の処理を行うことができる。また、負荷分散装置１０が決定したエッジサーバは、図９のステップＳ１０２以降の処理を行うことができる。
【０１３５】
また、本実施の形態では、店舗端末３００が出力した識別子または取引データに商品情報と店舗アドレスとが含まれることについて説明したが、店舗端末３００は、識別子または取引データに商品情報と該取引を特定する情報（取引識別子）とを含めて出力してもよい。この場合、店舗端末３００は、暗号化した店舗アドレスを上記取引識別子に関連付けてエッジサーバ１００に送信する。店舗アドレスを受信したエッジサーバ１００は、店舗アドレスの送信元の店舗端末３００の公開鍵で復号する。そして、利用者端末２００が、エッジサーバ１００に取引データを、上記取引識別子と共に送信する。これにより、エッジサーバ１００は、取引データと、店舗アドレスとを関連付けることができるため、エッジサーバ１００は、ステップＳ９６において、全ての店舗の公開鍵を用いなくとも、取引データに含まれる商品情報を復号することができる。
【０１３６】
（効果）
本実施の形態に係るシステム２によれば、エッジサーバ１００の取得部１１０が、所定のネットワークにおける複数のエッジサーバの夫々の状態を示す状態情報を取得する。この複数のエッジサーバは、利用者と店舗との間の、所定の金銭的価値を有する電子バリューを用いた取引に関する取引データを所定のプロトコルに従って仲介するサーバである。そして、エッジサーバ１００の決定部１２０が、複数のエッジサーバ１００の夫々における状態情報に基づいて、複数のエッジサーバのうち、ナンス値を計算するエッジサーバを決定する。
【０１３７】
一般的に、ナンス値の計算には、大きな負荷が掛かる。したがって、１つのエッジサーバのみが、複数の取引データ群（ブロック）の夫々のナンス値の計算を行うと、この１つのエッジサーバに大きな負荷が掛かってしまう。しかしながら、本実施の形態に係るシステム２におけるエッジサーバの決定部１２０は、複数のエッジサーバの夫々の状態情報に基づいて、ナンス値を計算するエッジサーバを決定する。これにより、ナンス値の計算を行うタイミングにおいて、決定部１２０は、例えば、負荷がより小さいエッジサーバ、高性能なエッジサーバなど、ナンス値を計算するのに適したエッジサーバを決定することができる。これにより、システム２は、ある特定のエッジサーバに負荷が掛からないようにすることができる。したがって、システム２は、利用者と店舗との間の電子取引における、システム２に含まれるエッジサーバの負荷分散を行うことができる。また、エッジサーバの負荷分散を行うことにより、利用者と店舗との間の取引に対する決済処理の時間を短くすることができる。
【０１３８】
また、本実施の形態に係るシステム２では、ナンス値の計算処理を、エッジサーバ１００で行う。また、システム２では利用者端末２００の認証処理および取引データの復号処理もエッジサーバ１００で行う。これにより、決済網の参加者の何れかがナンス値を計算する場合、または、中央決済機関が決済処理を行う場合に比べ、利用者と店舗との間の取引に対する決済処理の時間を短くすることができる。
【０１３９】
また、本実施の形態に係るシステム２は、既存のシステムにも適用可能である。既存のシステムとは、例えば、電子貨幣を用いた電子決済システム、クレジットカードを用いた電子決済システム、サービス提供会社が管理するポイントを用いた決済システム、サービス提供会社によって貨幣価値が設定された仮想通貨を用いた決済システム等が挙げられる。
【０１４０】
また、本実施の形態に係るシステム２では、所定の範囲内における取引であるため、システム２は、所定の範囲において、通貨交換のレートの設定や変更を容易に行うことができる。また、システム２は、所定の範囲における仮想通貨の使用用途、使用場所を制御することもできる。
【０１４１】
（ハードウェア構成について）
本発明の各実施形態において、各装置の各構成要素は、機能単位のブロックを示している。各装置の各構成要素の一部又は全部は、例えば図１４に示すような情報処理装置９００とプログラムとの任意の組み合わせにより実現される。情報処理装置９００は、一例として、以下のような構成を含む。
【０１４２】
・ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）９０１
・ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）９０２
・ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）９０３
・ＲＡＭ９０３にロードされるプログラム９０４
・プログラム９０４を格納する記憶装置９０５
・記録媒体９０６の読み書きを行うドライブ装置９０７
・通信ネットワーク９０９と接続する通信インターフェース９０８
・データの入出力を行う入出力インターフェース９１０
・各構成要素を接続するバス９１１
各実施形態における各装置の各構成要素は、これらの機能を実現するプログラム９０４をＣＰＵ９０１が取得して実行することで実現される。各装置の各構成要素の機能を実現するプログラム９０４は、例えば、予め記憶装置９０５やＲＡＭ９０３に格納されており、必要に応じてＣＰＵ９０１が読み出す。なお、プログラム９０４は、通信ネットワーク９０９を介してＣＰＵ９０１に供給されてもよいし、予め記録媒体９０６に格納されており、ドライブ装置９０７が当該プログラムを読み出してＣＰＵ９０１に供給してもよい。
【０１４３】
各装置の実現方法には、様々な変形例がある。例えば、各装置は、構成要素毎にそれぞれ別個の情報処理装置９００とプログラムとの任意の組み合わせにより実現されてもよい。また、各装置が備える複数の構成要素が、一つの情報処理装置９００とプログラムとの任意の組み合わせにより実現されてもよい。
【０１４４】
また、各装置の各構成要素の一部又は全部は、その他の汎用または専用の回路、プロセッサ等やこれらの組み合わせによって実現される。これらは、単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。
【０１４５】
各装置の各構成要素の一部又は全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。
【０１４６】
各装置の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。
【０１４７】
なお、上述した各実施の形態は、本発明の好適な実施の形態であり、上記各実施の形態にのみ本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において当業者が上記各実施の形態の修正や代用を行い、種々の変更を施した形態を構築することが可能である。
【符号の説明】
【０１４８】
１    システム
２    システム
１０    負荷分散装置
１１    取得部
１２    決定部
２０    利用者端末
３０    店舗端末
４０    エッジサーバ
１００    エッジサーバ
１１０    取得部
１２０    決定部
１３０    記憶部
１４０    受信部
１５０    送信部
１６０    計算部
１７０    認証部
２００    利用者端末
２１０    生成部
２２０    送信部
２３０    記憶部
２４０    取得部
２５０    受信部
３００    店舗端末
３１０    生成部
３２０    送信部
３３０    記憶部
３４０    出力部
【図１】
0006657972.tif 000002
【図２】
0006657972.tif 000003
【図３】
0006657972.tif 000004
【図４】
0006657972.tif 000005
【図５】
0006657972.tif 000006
【図６】
0006657972.tif 000007
【図７】
0006657972.tif 000008
【図８】
0006657972.tif 000009
【図９】
0006657972.tif 000010
【図１０】
0006657972.tif 000011
【図１１】
0006657972.tif 000012
【図１２】
0006657972.tif 000013
【図１３】
0006657972.tif 000014
【図１４】
0006657972.tif 000015