知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-11-08
(45)【発行日】2022-11-16
(54)【発明の名称】署名サーバ、署名方法および署名プログラム
(51)【国際特許分類】
G06Q 20/38 20120101AFI20221109BHJP
【ＦＩ】
G06Q20/38
【請求項の数】
10
(21)【出願番号】P 2019003858
(22)【出願日】2019-01-11
(65)【公開番号】P2020113085
(43)【公開日】2020-07-27
【審査請求日】2021-10-07
(73)【特許権者】
【識別番号】000005223
【氏名又は名称】富士通株式会社
(74)【代理人】
【識別番号】100104190
【弁理士】
【氏名又は名称】酒井 昭徳
(72)【発明者】
【氏名】竹内 琢磨
(72)【発明者】
【氏名】東角 芳樹
(72)【発明者】
【氏名】藤本 真吾
(72)【発明者】
【氏名】鎌倉 健
【審査官】岡北 有平
(56)【参考文献】
【文献】特開２０１８－０９２４４６（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１８／０３７５７９１（ＵＳ，Ａ１）
【文献】中国特許出願公開第１０３４４１８５７（ＣＮ，Ａ）
【文献】米国特許出願公開第２０１７／０１０３３９１（ＵＳ，Ａ１）
【文献】Coinbase Connect (Oauth2)，[online]，2017年02月27日，1-2ページ，[検索日：２０２２年９月２８日], <URL:https://web.archive.org/web/20170226221023/https://developers.coinbase.com/docs/wallet/coinbase-connect/>
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００ ー ９９／００
(57)【特許請求の範囲】
【請求項1】
利用者からの取引情報を含むトークン発行リクエストの受信に応じて、取引内容の許可範囲を定める許可ルールを前記取引情報に基づいて生成するとともに、前記利用者の代理取引の処理を行うＷｅｂアプリケーションに前記許可ルールに対応するトークンを送信し、前記Ｗｅｂアプリケーションからのトークンを含む前記利用者による取引リクエストに基づく署名発行要求の受信に応じて、前記取引リクエストに含まれる取引内容が前記署名発行要求に含まれる前記トークンに対応する許可ルールで定められた前記許可範囲内か否かに基づき、前記署名発行要求に対応する電子署名の発行可否を判定する処理部、
を備えたことを特徴とする署名サーバ。
【請求項2】
前記取引が、前記利用者による通貨価値を有する金額またはポイントの送金の場合、前記処理部は、前記利用者からの前記トークン発行リクエスト時には、前記許可ルールに送金額の許可範囲を定め、
前記利用者による送金リクエスト時には、前記送金リクエストに含まれる前記送金額が前記許可ルールで定めた許可範囲内か否かを判定する、
ことを特徴とする請求項１に記載の署名サーバ。
【請求項3】
前記処理部は、前記送金リクエストに含まれる前記送金額が前記許可ルールで定めた許可範囲内の場合のみ、前記Ｗｅｂアプリケーションに前記取引情報の電子署名を発行可と判定し、前記Ｗｅｂアプリケーションに対して前記電子署名を発行する、
ことを特徴とする請求項２に記載の署名サーバ。
【請求項4】
前記処理部は、前記利用者による取引処理を認証する認証情報を保持し、当該認証情報を用いて前記電子署名を作成する、
ことを特徴とする請求項３に記載の署名サーバ。
【請求項5】
前記処理部は、前記利用者からの取引情報を含むトークン発行リクエスト毎に、前記許可ルールの情報として、前記利用者毎の送金元、送金先、前記送金額の許可範囲、前記トークンの情報、をそれぞれ関連付けた情報をテーブルに追加作成し、
前記利用者による送金リクエスト時には、前記テーブルの前記許可ルールを参照し、当該送金リクエストに対応する前記許可ルールを抽出し、抽出した前記許可ルールの前記送金額が前記送金額の許可範囲内であるか否かを判定する、
ことを特徴とする請求項２～４のいずれか一つに記載の署名サーバ。
【請求項6】
前記処理部は、前記許可ルール作成時の前記取引情報に含まれる前記送金額に所定の係数を掛けた値を前記送金額の許可範囲を規定する最大値および最小値として算出する、
ことを特徴とする請求項２～５のいずれか一つに記載の署名サーバ。
【請求項7】
前記処理部は、前記利用者、あるいは他の利用者の現在あるいは過去の取引情報に含まれる通貨変換レートを用いて、前記送金額の許可範囲を算出する、
ことを特徴とする請求項２～６のいずれか一つに記載の署名サーバ。
【請求項8】
前記処理部は、算出した前記許可ルールを前記利用者に通知し、当該利用者の承認により前記許可ルールを用いた判定を行い、
前記利用者の承認拒否時には、前記利用者が作成した前記許可ルールを用いた判定を行う、
ことを特徴とする請求項２～７のいずれか一つに記載の署名サーバ。
【請求項9】
利用者からの取引情報を含むトークン発行リクエストに応じて、取引内容の許可範囲を定める許可ルールを前記取引情報に基づいて生成するとともに、前記利用者の代理取引の処理を行うＷｅｂアプリケーションに前記許可ルールに対応するトークンを渡し、前記利用者による取引リクエストに基づく前記Ｗｅｂアプリケーションからのトークンを含む署名発行要求に応じて、前記取引リクエストに含まれる取引内容が前記署名発行要求に含まれる前記トークンに対応する許可ルールで定めた前記許可範囲内か否かに基づき、前記署名発行要求に対応する電子署名の発行可否を判定する、
処理をコンピュータが実行することを特徴とする署名方法。
【請求項10】
利用者からの取引情報を含むトークン発行リクエストに応じて、取引内容の許可範囲を定める許可ルールを前記取引情報に基づいて生成するとともに、前記利用者の代理取引の処理を行うＷｅｂアプリケーションに前記許可ルールに対応するトークンを渡し、前記利用者による取引リクエストに基づく前記Ｗｅｂアプリケーションからの前記トークンを含む署名発行要求に応じて、前記取引リクエストに含まれる取引内容が前記署名発行要求に含まれる前記トークンに対応する許可ルールで定めた前記許可範囲内か否かに基づき、前記署名発行要求に対応する電子署名の発行可否を判定する、
処理をコンピュータに実行させることを特徴とする署名プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、電子署名発行にかかる処理を行う署名サーバ、署名方法および署名プログラムに関する。
【背景技術】
【0002】
ブロックチェーンは、仮想通貨の管理システムとして使われており、安全な運用が求められる。仮想通貨やブロックチェーンの種類は爆発的に増加しており、異なる仮想通貨やブロックチェーン間の連携のニーズが高まっている。異なる仮想通貨やブロックチェーンを連携させる際、取引実行には異なる認証情報が必要になる。こうした認証情報をサービス利用者自身が保有して自ら電子署名発行および取引実行するのは、一般の利用者にとって煩雑である。そのため、認証情報の管理、電子署名の発行、および取引の実行を、利用者の許可を得て代理で実行するＷｅｂアプリケーションのニーズがある。
【0003】
ブロックチェーンや仮想通貨の管理に関連する従来技術としては、ブロックチェーンを利用した取引に連動して勘定系操作を実行し、実行結果を突き合せて取引の成否を判定する技術がある（例えば、下記特許文献１参照。）。また、利用者に仮想化データトークンにより分散型ブロックチェーン台帳が管理されるノードにアクセス可能な暗号ウォレットが提供され、利用者間で証券を譲渡する技術がある（例えば、下記特許文献２参照。）。また、仮想通貨管理装置が、仮想通貨と法定通貨間の変換率を含む変換依頼をブロックチェーンが格納されたサーバへ送信してブロックをブロックチェーンへ追加させ、仮想通貨と法定通貨の変換後の変換率を受信する技術がある（例えば、下記特許文献３参照。）。
【先行技術文献】
【特許文献】
【0004】
【文献】特開２０１８－１３９０６７号公報
【文献】特表２０１８－５２１４３７号公報
【文献】特開２０１８－１３６６５７号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
上記のＷｅｂアプリケーションのニーズに関して、多くの利用者がアクセスするＷｅｂアプリケーションのサーバ上で認証情報を管理すると、認証情報が外部漏洩してしまうリスクがある。そのため、電子署名発行にかかる処理を行う署名サーバを別途用意し、署名サーバはＷｅｂアプリケーションのアクセスのみを許可する運用形態が考えられる。その際、署名サーバは、Ｗｅｂアプリケーションを介した利用者からのリクエストによって特定の取引内容に関してのみ署名発行を許可され、Ｗｅｂアプリケーションから事前に許可された取引のリクエストを受け取ったときに電子署名を発行する。また、Ｗｅｂアプリケーションは、署名サーバから受け取った電子署名を用いて、ブロックチェーン上の取引が発行する。
【0006】
上記の運用を行う際に、例えば、仮想通貨の変換では、短時間で通貨変換レートが変動するため、利用者が取引署名を許可した時点と、利用者が実際に送金を行う時点で取引金額が異なる状況が発生することがある。この場合、従来技術では、利用者が意図した許可内容と実際の取引内容との照合ができなかった。
【0007】
一つの側面では、本発明は、利用者の許可内容と取引内容の照合が行えることを目的とする。
【課題を解決するための手段】
【0008】
本発明の一側面によれば、電子署名発行にかかる処理を行う署名サーバは、利用者からの取引情報を含むトークン発行リクエストの受信に応じて、取引内容の許可範囲を定める許可ルールを前記取引情報に基づいて生成するとともに、前記利用者の代理取引の処理を行うＷｅｂアプリケーションに前記許可ルールに対応するトークンを送信し、前記Ｗｅｂアプリケーションからのトークンを含む前記利用者による取引リクエストに基づく署名発行要求の受信に応じて、前記取引リクエストに含まれる取引内容が前記署名発行要求に含まれる前記トークンに対応する許可ルールで定められた許可範囲内か否かに基づき、前記署名発行要求に対応する電子署名の発行可否を判定する処理部、を備えたことを要件とする。
【発明の効果】
【0009】
本発明の一態様によれば、利用者の許可内容と取引内容の照合が行えるという効果を奏する。
【図面の簡単な説明】
【0010】
【発明を実施するための形態】
【0011】
以下に図面を参照して、開示の署名サーバ、署名方法および署名プログラムの実施の形態を詳細に説明する。
【0012】
開示の技術は、例えば、ブロックチェーンと、電子署名発行にかかる処理を行う署名サーバによる、代理取引に適用できる。この場合、予め、署名サーバは、利用者の取引情報をもとに取引処理でのパラメータの許可範囲（例えば、送金額の許可範囲）を算出し、この許可範囲の情報を付与した許可ルールを設定する。また、開示の技術では、利用者の認証情報（秘密鍵）を署名サーバが預かり保持する。
【0013】
例えば、利用者のアクセストークンの発行要求時に署名サーバは、取引処理でのパラメータの許可範囲として送金額の許可範囲を含む許可ルールを設定する。この後、時間が経過して利用者が実際に送金リクエストを行う際、署名サーバは、送金リクエストの送金額が、設定済みの送金額の許可範囲内であるか否かを判定する。これにより、署名サーバは、送金リクエストの送金額が、設定してある送金額の許可範囲内であれば電子署名を発行し、Ｗｅｂアプリケーション（Ｗｅｂアプリ）での送金取引を実行させる。Ｗｅｂアプリケーションは、例えば、サーバ・クライアント型のＷｅｂアプリケーション、ブロックチェーン上のスマートコントラクト、ブロックチェーン上のプログラムなどを含む。代理取引では、例えば、利用者の権限をＷｅｂアプリに委譲して、利用者本人の代わりにＷｅｂアプリが取引を実行する。
【0014】
仮想通貨等では、短時間で通貨変換レートが変動するため、利用者が取引を許可した時点（例えば、アクセストークンの発行時点）と、利用者が実際にＷｅｂアプリを介して送金リクエストを発行する時点と、で取引金額が異なる状況が発生する。この点、実施の形態では、署名サーバは、代理取引時の利用者の許可内容と取引内容の照合を行うことができる。利用者が実際に送金を行う送金リクエスト時に、もし通貨変換レートが変動しても送金額が許可範囲内であれば、署名サーバが電子署名を発行し、利用者は送金取引を行うことができる。もし送金額が許可範囲外であれば、署名サーバは送金取引を許可せず、利用者は送金取引を行うことができない。これにより、利用者は、署名サーバに設定された送金額の許可範囲内で送金を行うことができる。
【0015】
（実施の形態１）
図１は、実施の形態１にかかる取引処理にかかる署名サーバの機能を示すブロック図である。取引処理にかかる署名サーバＡ（１００）の他に、利用者Ｌ、Ｗｅｂアプリ１６０、ブロックチェーンＢＣを記載してある。
図１は、実施の形態１にかかる取引処理にかかる署名サーバの機能を示すブロック図である。取引処理にかかる署名サーバＡ（１００）の他に、利用者Ｌ、Ｗｅｂアプリ１６０、ブロックチェーンＢＣを記載してある。
【0016】
取引処理の流れに沿って説明する。はじめに、利用者Ｌは、署名サーバＡ（１００）に対し、アクセストークン発行リクエストを送る（ステップＳ１）。これにより、署名サーバＡ（１００）に取引情報を登録する。
【0017】
署名サーバＡ（１００）は、リクエスト受付／回答部１０１、許可範囲算出部１０２、許可ルール登録部１０３、アクセストークン作成部１０４、許可ルール判定部１０５、電子署名作成部１０６、の各機能を含む。
【0018】
リクエスト受付／回答部１０１は、アクセストークンの発行リクエストと、署名発行リクエストをそれぞれ受け付ける。署名発行リクエストは、アクセストークンと取引情報を含む。
【0019】
許可範囲算出部１０２は、アクセストークン発行リクエストの取引情報に基づいて、許可ルールの許可範囲（送金額の許可範囲）を算出する（ステップＳ２）。許可ルール登録部１０３は、許可範囲算出部１０２が算出した許可ルールの許可範囲（送金額の許可範囲）を記録部に記録する（ステップＳ３）。
【0020】
アクセストークン作成部１０４は、アクセストークンを取引情報（送金額）と許可ルールに紐付けて（関連付けて）記録部に記録する（ステップＳ４）。この際、リクエスト受付／回答部１０１は、Ｗｅｂアプリ１６０に対しアクセストークンを発行する（ステップＳ５）。
【0021】
次に、利用者Ｌが実際に送金取引リクエストをＷｅｂアプリ１６０に送信する（ステップＳ６）。これにより、Ｗｅｂアプリ１６０は、署名サーバＡ（１００）に対し、署名発行リクエスト（アクセストークン、取引情報（送金額）を添付）を行う（ステップＳ７）。
【0022】
許可ルール判定部１０５は、Ｗｅｂアプリ１６０から送付された取引情報（送金額）が記録部に記録された許可ルールを満たすか否かを判定する（ステップＳ８）。後述するが、許可ルール判定部１０５は、取引情報（送金額）が記録部に記録された許可ルールを満たす場合のみ、電子署名を作成してＷｅｂアプリ１６０に送付する。
【0023】
電子署名作成部１０６は、署名発行リクエスト内のアクセストークンに対応する取引の電子署名を作成する（ステップＳ９）。この際、電子署名作成部１０６は、署名サーバＡ（１００）内部に保持する秘密鍵１１０を用いて電子署名を作成する。秘密鍵１１０は、利用者Ｌの取引処理のアカウントを認証する認証情報に相当する。
【0024】
そして、署名サーバＡ（１００）のリクエスト受付／回答部１０１は、Ｗｅｂアプリ１６０に対し、アクセストークンに対応する取引の電子署名を送付する（ステップＳ１０）。Ｗｅｂアプリ１６０は、ブロックチェーンＢＣに対し、署名サーバＡ（１００）から送付された電子署名を添付した送金取引を発行する（ステップＳ１１）。
【0025】
図２は、実施の形態１にかかる取引処理の例を説明する図である。実施の形態１では、ブロックチェーン（ＢＣ）が一つ、署名サーバＡ（１００）が一つであり、利用者Ｌから利用者Ｓに取引処理として送金を行う例について説明する。
【0026】
ここで、利用者Ｌは、ブロックチェーンＢＣにアカウントａを持っており、利用者ＳもブロックチェーンＢＣにアカウントｂを持っているとする。そして、利用者ＬがブロックチェーンＢＣに連携するＷｅｂアプリ１６０を介して、アカウントａの仮想通貨を利用者Ｓのアカウントｂに送金するとする。図２に示すＷｅｂアプリ１６０は、利用者Ｌが保持するスマートフォン等の端末上でＷｅｂアプリ１６０が処理を実行した際の表示画面である。符号１５０は、Ｗｅｂアプリ１６０の処理を実際に実行するサーバである。
【0027】
以下、図２の記載内容に基づき、主に署名サーバＡ（１００）が行う処理内容を順次説明する。
【0028】
１．利用者Ｌは、特定の送金リクエストに限り、利用者Ｌの代わりに署名サーバＡ（１００）が署名を発行することを許可しておく（ステップＳ２０１）。
２．署名サーバＡ（１００）は、利用者Ｌの取引情報をもとに送金額の許容範囲を算出した許可ルールを作成し、アクセストークンと許可ルールを紐付けて（関連付けて）記録部に登録しておく（ステップＳ２０２）。
３．署名サーバＡ（１００）は、Ｗｅｂアプリ１６０にアクセストークンを発行する（ステップＳ２０３）。
２．署名サーバＡ（１００）は、利用者Ｌの取引情報をもとに送金額の許容範囲を算出した許可ルールを作成し、アクセストークンと許可ルールを紐付けて（関連付けて）記録部に登録しておく（ステップＳ２０２）。
３．署名サーバＡ（１００）は、Ｗｅｂアプリ１６０にアクセストークンを発行する（ステップＳ２０３）。
【0029】
４．利用者Ｌは、送金額の情報を含む送金リクエストをＷｅｂアプリ１６０に送付する（ステップＳ２０４）。
５．Ｗｅｂアプリ１６０は、送付されたアクセストークンと、送金額等の取引情報を含む署名発行リクエストを署名サーバＡ（１００）に送付する（ステップＳ２０５）。
５．Ｗｅｂアプリ１６０は、送付されたアクセストークンと、送金額等の取引情報を含む署名発行リクエストを署名サーバＡ（１００）に送付する（ステップＳ２０５）。
【0030】
６．署名サーバＡ（１００）は、受け取った送金額を含む取引情報が、受け取ったアクセストークンに紐付く許可ルール（送金額の許可範囲）を満たすか否かを判定する。判定の結果が許可ルールを満たす場合、署名サーバＡ（１００）は、受け取ったアクセストークンに対応する取引情報の電子署名を作成する（ステップＳ２０６）。
７．署名サーバＡ（１００）は、作成した電子署名をＷｅｂアプリ１６０に送付する（ステップＳ２０７）。
８．Ｗｅｂアプリ１６０は、受け取った電子署名を添付し、送金取引をブロックチェーンＢＣ上で発行する。
７．署名サーバＡ（１００）は、作成した電子署名をＷｅｂアプリ１６０に送付する（ステップＳ２０７）。
８．Ｗｅｂアプリ１６０は、受け取った電子署名を添付し、送金取引をブロックチェーンＢＣ上で発行する。
【0031】
【0032】
例えば、署名サーバＡ（１００）は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１、メモリ３０２、ネットワークインタフェース（ＩＦ）３０３、記録媒体ＩＦ３０４、記録媒体３０５、を含む。３００は各部を接続するバスである。
【0033】
ＣＰＵ３０１は、署名サーバ１００の全体の処理を司る処理部として機能する演算処理装置である。メモリ３０２は、不揮発性メモリおよび揮発性メモリを含む。不揮発性メモリは、例えば、ＣＰＵ３０１のプログラムを格納するＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）である。揮発性メモリは、例えば、ＣＰＵ３０１のワークエリアとして使用されるＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等である。
【0034】
ネットワークＩＦ３０３は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワーク３１０を介して、外部の端末（利用者のＰＣやスマートフォン等）に通信接続する。
【0035】
記録媒体ＩＦ３０４は、ＣＰＵ３０１が処理した情報を記録媒体３０５との間で読み書きするためのインタフェースである。記録媒体３０５は、メモリ３０２を補助する記録装置である。記録媒体３０５は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）や、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）フラッシュドライブ等を用いることができる。
【0036】
メモリ３０２または記録媒体３０５に記録されたプログラムをＣＰＵ３０１が実行することにより、図１に示した署名サーバＡ（１００）の各機能を実現する。また、メモリ３０２や記録媒体３０５により、図１に示したアクセストークン、許可ルール、電子署名等の情報を記録保持する記録部の機能を実現できる。
【0037】
図３に示したハードウェア構成は、図２に示したＷｅｂアプリ用サーバ１５０や、Ｗｅｂアプリ１６０を実行する利用者の端末（スマートフォン等）においても同様であり、実施の形態のシステムは、汎用のハードウェア構成を用いて実現できる。
【0038】
図４Ａおよび図４Ｂは、実施の形態１にかかる取引処理の例を示すフローチャートである。図４Ａには、主に署名サーバＡ（１００）の処理部（ＣＰＵ３０１）が実行する許可ルールの登録フェーズ（図２のステップＳ２０１～Ｓ２０３に相当）の各処理の流れを示す。図４Ｂには、主に署名サーバＡ（１００）の処理部（ＣＰＵ３０１）、およびＷｅｂアプリ１６０（例えば、Ｗｅｂアプリ用サーバ１５０のＣＰＵ３０１）が実行する送金フェーズ（図２のステップＳ２０４～Ｓ２０８に相当）の各処理の流れを示す。
【0039】
但し、以下のステップＳ４０５，ステップＳ４０６は、利用者Ｌへの許可ルールの検証のためのサブプロセスである。利用者Ｌの許可ルール検証が不要な場合は、署名サーバＡ（１００）は、ステップＳ４０４の処理後、ステップＳ４０７を実行処理すればよい。
【0040】
図４Ａに示す許可ルールの登録フェーズの処理では、まず、事前準備として、利用者Ｌの仮想通貨のアカウントの秘密鍵１１０を預かる署名サーバＡ（１００）を準備する（ステップＳ４０１）。
【0041】
そして、利用者Ｌは、送金元（アカウントａ）、送金先（アカウントｂ）、送金額を指定した取引情報を添付し、アクセストークン発行リクエストを、署名サーバＡに送付する（ステップＳ４０２）。
【0042】
これにより、署名サーバＡ（１００）は、発行リクエストの取引情報に基づいて許可ルールの許可範囲を算出する（ステップＳ４０３）。そして、署名サーバＡ（１００）は、許可範囲（上記送金額の許可範囲）を付与した許可ルールを、利用者Ｌに送付する（Ｓ４０４）。
【0043】
そして、署名サーバＡ（１００）は、利用者Ｌの許可ルールに対するレスポンス（許可または拒否）を判定する（ステップＳ４０５）。利用者Ｌのレスポンスが許可であれば（ステップＳ４０５：Ｙｅｓ）、署名サーバＡ（１００）は、ステップＳ４０７の処理に移行する。一方、利用者Ｌのレスポンスが拒否であれば（ステップＳ４０５：Ｎｏ）、利用者Ｌによるパラメータ許可範囲（送金額の許可範囲）に基づいて、許可範囲付き許可ルールを生成し（ステップＳ４０６）、ステップＳ４０７の処理に移行する。
【0044】
次に、署名サーバＡ（１００）は、生成したパラメータ許可範囲を付与した許可範囲付き許可ルールを署名サーバＡ内部で登録する（ステップＳ４０７）。そして、署名サーバＡ（１００）は、新しいアクセストークンを作成し、ステップＳ４０２で受け取った取引情報、および登録した許可ルールに紐付けて署名サーバＡ内部で登録する（ステップＳ４０８）。また、署名サーバＡ（１００）は、作成した新しいアクセストークンをＷｅｂアプリ１６０に発行する（ステップＳ４０９）。以上により、署名サーバＡ（１００）は、許可ルールの登録フェーズにかかる一連の処理を終了する。
【0045】
次に、図４Ｂに示す送金フェーズの処理では、はじめに、利用者Ｌは、送金額の情報を含む送金リクエストをＷｅｂアプリ１６０に送付する（ステップＳ４１０）。次に、Ｗｅｂアプリ１６０は、送付されたアクセストークンを添付し、署名発行リクエストを署名サーバＡ（１００）に送付する（ステップＳ４１１）。
【0046】
これにより、署名サーバＡ（１００）は、送金額を含む取引情報が、アクセストークンに紐付く許可範囲付き許可ルール（送金額の許可範囲）を満たすか否かを判定する（ステップＳ４１２）。判定の結果が許可ルールを満たす（送金額が許可範囲内の）場合（ステップＳ４１３：Ｙｅｓ）、署名サーバＡ（１００）は、ステップＳ４１４の処理に移行する。一方、判定の結果が許可ルールを満たさない（送金額が許可範囲外の）場合（ステップＳ４１３：Ｎｏ）、署名サーバＡ（１００）は、ステップＳ４１７の処理に移行する。
【0047】
ステップＳ４１４の処理では、署名サーバＡ（１００）は、受け取ったアクセストークンに対応する取引情報の電子署名を作成する（ステップＳ４１４）。次に、署名サーバＡ（１００）は、作成した電子署名をＷｅｂアプリ１６０に送付する（ステップＳ４１５）。
【0048】
これにより、Ｗｅｂアプリ１６０は、受け取った電子署名を添付し、送金取引をブロックチェーンＢＣ上で発行する（ステップＳ４１６）。また、ステップＳ４１７では、署名サーバＡ（１００）は、Ｗｅｂアプリ１６０に電子署名を発行しないと回答する（ステップＳ４１７）。ステップＳ４１６、またはステップＳ４１７の処理後、署名サーバＡ（１００）は、送金フェーズにかかる一連の処理を終了する。
【0049】
次に、上記の図４Ａ，図４Ｂを用いて説明した取引処理について、送金の具体例について説明する。ステップＳ４０１の事前準備では、利用者ＬがブロックチェーンＢＣにアカウントａを持っており、利用者ＳがブロックチェーンＢＣにアカウントｂを持っている。そして、アカウントａの秘密鍵は、ブロックチェーン用の署名サーバＡ（１００）で管理されている。
【0050】
そして、ステップＳ４０２では、利用者Ｌによるアクセストークン発行リクエストの際、利用者Ｌのアカウントａの仮想通貨を、利用者Ｓのアカウントｂに送金する。ここで、仮想通貨に比べて、法定通貨（例えばドル＄や円￥など）の方が一般に価値が安定しており、法定通貨での価値をもとに署名の発行ルールを構築することを考える。なお、以下の説明では、法定通貨としてドル＄を扱う。
【0051】
図５は、実施の形態１にかかる署名許可時の取引情報の例を示す図表である。図５には、ステップＳ４０２における利用者Ｌからのアクセストークン発行リクエストの際、署名サーバＡ（１００）に送付する取引情報５００の例を示す。取引情報５００は、送金元が「利用者Ｌのアカウントａ」、送金相手が「利用者Ｓのアカウントｂ」、送金額が「仮想通貨２００ポイント」であったとする。
【0052】
次に、ステップＳ４０３では、署名サーバＡ（１００）は、許可範囲を以下の手順で作成する。許可ルール設定時の取引情報に含まれる送金額をＸとしたとき、送金リクエストに含まれる送金額Ｙに対し、下記式（１）に示す許可範囲を算出する。
【0053】
Ｘ＊（１－Ｋ）≦Ｙ≦Ｘ＊（１＋Ｋ） …（１）
（但し、Ｋは、０＜Ｋ＜１を満たす定数）
（但し、Ｋは、０＜Ｋ＜１を満たす定数）
【0054】
このとき、署名サーバＡ（１００）は、例えば、予めＫ＝０．３と設定したうえで、許可ルール作成時の取引情報に含まれる送金額が仮想通貨１００ポイントであったとき、送金リクエストに含まれる送金額Ｙの許可範囲を、下記式（２）に示す許可ルールを作成する。
７０≦Ｙ≦１３０ …（２）
７０≦Ｙ≦１３０ …（２）
【0055】
例えば、Ｋ＝０．３で、図５に示した取引情報５００の取引を署名サーバＡ（１００）が受け取った際、ドル／仮想通貨のレートが３．０［ドル／仮想通貨Ａ］であったとする。このとき、上記許可ルールに基づくと、送金額の範囲は、法定通貨換算で４２０～７８０ドルの区間内となる。
【0056】
図６は、実施の形態１にかかる署名サーバが生成する許可ルールの例を示す図表である。ステップＳ４０３の処理により、署名サーバＡ（１００）は、許可ルール（送金額の許可範囲）６００として、送金元「利用者Ｌのアカウントａ」、送金相手「利用者Ｓのアカウントｂ」、送金額の範囲「ドル換算で４２０～７８０ドル」の情報を含む。
【0057】
また、ステップＳ４０８の処理では、署名サーバＡ（１００）は、新規のアクセストークンとして適当な文字列（例えば「Ｐ８ｍＯｃｖ＋６ＳＷ」）を作成する。署名サーバＡ（１００）は、ステップＳ４０４で生成した許可ルール（あるいは利用者ＬがステップＳ４０７で作成した許可ルール）を、アクセストークンと紐付け、署名サーバＡ（１００）内部の記録部（テーブル）に新規の許可ルールとして追加する。
【0058】
図７は、実施の形態１にかかる署名サーバが保持する許可ルールのテーブルの例を示す図表である。ステップＳ４０８の処理により、署名サーバＡ（１００）は、許可ルールのテーブル７００に、新規の許可ルールの行７０１を追加する。新規の行７０１の許可ルールは、新規のアクセストークン「Ｐ８ｍＯｃｖ＋６ＳＷ」、送金元「利用者Ｌのアカウントａ」、送金相手「利用者Ｓのアカウントｂ」、送金額の範囲「ドル換算で４２０～７８０ドル」の各情報を含む。
【0059】
次に、ステップＳ４０９の処理では、署名サーバＡ（１００）は、新規のアクセストークン「Ｐ８ｍＯｃｖ＋６ＳＷ」を、Ｗｅｂアプリ１６０に発行する。
【0060】
図８は、実施の形態１にかかる送金リクエストの例を示す図表である。ステップＳ４１０では、利用者Ｌは、送金リクエスト８００をＷｅｂアプリ１６０に送付する。送金リクエスト８００は、送金元「利用者Ｌのアカウントａ」、送金相手「利用者Ｓのアカウントｂ」、送金額「仮想通貨２００ポイント」の情報を含む。
【0061】
図９は、実施の形態１にかかるＷｅｂアプリから署名サーバに送付される送金リクエストの例を示す図表である。ステップＳ４１１では、Ｗｅｂアプリ１６０は、受け取った新規のアクセストークンを付与し、送金リクエスト９００を署名サーバＡ（１００）に送付する。送金リクエスト９００は、送金元「利用者Ｌのアカウントａ」、送金相手「利用者Ｓのアカウントｂ」、送金額「仮想通貨２００ポイント」、アクセストークン「Ｐ８ｍＯｃｖ＋６ＳＷ」の情報を含む。
【0062】
図１０は、実施の形態１にかかる署名サーバで抽出された許可ルールの例を示す図表である。ステップＳ４１２では、署名サーバＡ（１００）は、送金リクエスト９００に含まれるアクセストークン「Ｐ８ｍＯｃｖ＋６ＳＷ」を基に、署名サーバＡ（１００）が保有する許可ルールのテーブル７００から、アクセストークンが一致する行７０１を抜き出す。そして、抜き出した行７０１に含まれる許可ルール１０００を抽出する。図１０に示す許可ルール１０００は、図６と同様の情報からなり、送金元「利用者Ｌのアカウントａ」、送金相手「利用者Ｓのアカウントｂ」、送金額の範囲「４２０～７８０ドル」の情報を含む。
【0063】
そして、ステップＳ４１３では、署名サーバＡ（１００）は、受け取った送金リクエスト９００の送金額が、抽出した許可ルール１０００を満たすか判定する。例えば、送金リクエスト９００の際、仮想通貨のレートが署名許可時の３．０から変動して３．２［ドル／仮想通貨］になったとする。このとき、送金額はドル換算で６４０ドル（レートが３．２［ドル／仮想通貨］であるため）となるが、許可ルール１０００（図１０）の送金額の範囲内であるため、署名サーバＡ（１００）は、「許可ルールを満たす」と判定する（ステップＳ４１３：Ｙｅｓ）。
【0064】
一方、例えば、送金リクエスト９００の際の仮想通貨のレートが、署名許可時の３．０から大きく変動して２．０［ドル／仮想通貨］となったとする。この場合、送金額のドルでの価値は４００ドルになるため、許可ルール１０００の送金額の範囲外となるため、署名サーバＡ（１００）は、「許可ルールを満たさない」と判定する（ステップＳ４１３：Ｎｏ）。この場合、ステップＳ４１７の処理により、署名サーバＡ（１００）は、Ｗｅｂアプリ１６０に署名を発行しないと回答する。
【0065】
次に、ステップＳ４１４では、署名サーバＡ（１００）は、ステップＳ４１３にて「許可ルールを満たす（ステップＳ４１３：Ｙｅｓ）」と判定されたときのみ、取引情報に相当する電子署名を作成する。次に、ステップＳ４１５では、署名サーバＡ（１００）は、作成した電子署名をＷｅｂアプリ１６０に送付する。
【0066】
そして、ステップＳ４１６では、Ｗｅｂアプリ１６０は、受け取った電子署名を添付し、送金取引をブロックチェーンＢＣ上で発行する。
【0067】
実施の形態１によれば、ブロックチェーンＢＣが一つ、署名サーバＡ（１００）が一つであり、利用者Ｌから利用者Ｓに取引処理として送金を行う場合の通貨レートの変動に対応し、利用者Ｌの取引の許可内容と、実際の送金時の取引内容を照合できるようになる。署名サーバＡ（１００）は、取引の許可時にアクセストークンを発行する際、送金額の許可範囲を算出しておき、実際の送金時に送金額が許可範囲内の場合のみ電子署名を発行する。送金の取引処理を許可する。
【0068】
これにより、ブロックチェーンＢＣ上で仮想通貨の送金操作を行う利用者Ｌは、取引を許可したときと、実際に取引リクエストを出すときとの間の時間差や、状況の違いがあった場合でも、送金額が意図した許可内容に沿うか否かを照合できる。また、利用者Ｌの秘密鍵１１０は、Ｗｅｂアプリ１６０に預けることなく署名サーバＡ（１００）上で保持するため、代理取引を安全に実行できるようになる。
【0069】
（実施の形態２）
図１１は、実施の形態２にかかる取引処理の例を説明する図である。実施の形態２では、現在の送金額をベースに取引の許可ルールを決定する例について説明する。実施の形態２において、実施の形態１と同様の構成部には同様の符号を付してある。
図１１は、実施の形態２にかかる取引処理の例を説明する図である。実施の形態２では、現在の送金額をベースに取引の許可ルールを決定する例について説明する。実施の形態２において、実施の形態１と同様の構成部には同様の符号を付してある。
【0070】
この実施の形態２では、利用者Ｌが、ブロックチェーンＡ（仮想通貨Ａ）とブロックチェーンＢ（仮想通貨Ｂ）にそれぞれアカウントａ、ｂを持っているとする。そして、利用者Ｌが、ブロックチェーン連携のＷｅｂアプリ１６０を介して、アカウントａの仮想通貨Ａをアカウントｂの仮想通貨Ｂに変換する例について説明する。
【0071】
アカウントａの秘密鍵１１０は、ブロックチェーンＡ用の署名サーバＡ（１００）が管理している。アカウントｂの秘密鍵１１０は、ブロックチェーンＢ用の署名サーバＢ（１００）が管理している。以下に説明する取引処理では、仮想通貨Ａを仮想通貨Ｂに交換する場合であり、署名サーバＡ（１００）が処理を行う。仮に、仮想通貨Ｂを仮想通貨Ａに変換する場合は、支払い元であるブロックチェーンＢ用の署名サーバＢが必要となる。
【0072】
以下、図１１の記載内容に基づき、主に署名サーバＡ（１００）が行う処理内容を順次説明する。
【0073】
１．利用者Ｌは、特定の送金リクエストに限り、利用者Ｌの代わりに署名サーバＡ（１００）が署名を発行することを許可しておく（ステップＳ１１０１）。
２．署名サーバＡ（１００）は、利用者Ｌの取引情報をもとに送金額の許容範囲を算出した許可ルールを作成し、アクセストークンと許可ルールを紐付けて（関連付けて）記録部に登録しておく（ステップＳ１１０２）。
３．署名サーバＡ（１００）は、Ｗｅｂアプリ１６０にアクセストークンを発行する（ステップＳ１１０３）。
２．署名サーバＡ（１００）は、利用者Ｌの取引情報をもとに送金額の許容範囲を算出した許可ルールを作成し、アクセストークンと許可ルールを紐付けて（関連付けて）記録部に登録しておく（ステップＳ１１０２）。
３．署名サーバＡ（１００）は、Ｗｅｂアプリ１６０にアクセストークンを発行する（ステップＳ１１０３）。
【0074】
４．利用者Ｌは、送金額の情報を含む送金リクエストをＷｅｂアプリ１６０に送付する（ステップＳ１１０４）。
５．Ｗｅｂアプリ１６０は、送付されたアクセストークンと、送金額等の取引情報を含む署名発行リクエストを署名サーバＡ（１００）に送付する（ステップＳ１１０５）。
５．Ｗｅｂアプリ１６０は、送付されたアクセストークンと、送金額等の取引情報を含む署名発行リクエストを署名サーバＡ（１００）に送付する（ステップＳ１１０５）。
【0075】
６．署名サーバＡ（１００）は、受け取った送金額を含む取引情報が、受け取ったアクセストークンに紐付く許可ルール（送金額の許可範囲）を満たすか否かを判定する。判定の結果が許可ルールを満たす場合、署名サーバＡ（１００）は、受け取ったアクセストークンに対応する取引情報の電子署名を作成する（ステップＳ１１０６）。
７．署名サーバＡ（１００）は、作成した電子署名をＷｅｂアプリ１６０に送付する（ステップＳ１１０７）。
８．Ｗｅｂアプリ１６０は、受け取った電子署名を添付し、送金取引をブロックチェーンＡ，Ｂ上で発行する（ステップＳ１１０８）。
７．署名サーバＡ（１００）は、作成した電子署名をＷｅｂアプリ１６０に送付する（ステップＳ１１０７）。
８．Ｗｅｂアプリ１６０は、受け取った電子署名を添付し、送金取引をブロックチェーンＡ，Ｂ上で発行する（ステップＳ１１０８）。
【0076】
図１２Ａおよび図１２Ｂは、実施の形態２にかかる取引処理の例を示すフローチャートである。図１２Ａには、主に署名サーバＡ（１００）の処理部（ＣＰＵ３０１）が実行する許可ルールの登録フェーズ（図１１のステップＳ１１０１～Ｓ１１０３に相当）の各処理の流れを示す。図１２Ｂには、主に署名サーバＡ（１００）の処理部（ＣＰＵ３０１）、およびＷｅｂアプリ１６０（例えば、Ｗｅｂアプリ用サーバ１５０のＣＰＵ３０１）が実行する送金フェーズ（図１１のステップＳ１１０４～Ｓ１１０８に相当）の各処理の流れを示す。
【0077】
但し、以下のステップＳ１２０５，ステップＳ１２０６は、利用者Ｌへの許可ルールの検証のためのサブプロセスである。利用者Ｌの許可ルール検証が不要な場合は、署名サーバＡ（１００）は、ステップＳ１２０４の処理後、ステップＳ１２０７を実行処理すればよい。
【0078】
図１２Ａに示す許可ルールの登録フェーズの処理では、まず、事前準備として、利用者Ｌの仮想通貨のアカウントの秘密鍵１１０を預かる署名サーバＡ（１００）を準備する（ステップＳ１２０１）。
【0079】
そして、利用者Ｌは、送金元（アカウントａ）、送金先（アカウントｂ）、送金額を指定した取引情報を添付し、アクセストークン発行リクエストを、署名サーバＡに送付する（ステップＳ１２０２）。
【0080】
これにより、署名サーバＡ（１００）は、発行リクエストの取引情報に基づいて許可ルールの許可範囲を算出する（ステップＳ１２０３）。そして、署名サーバＡ（１００）は、許可範囲（上記送金額の許可範囲）を付与した許可ルールを、利用者Ｌに送付する（Ｓ１２０４）。
【0081】
そして、署名サーバＡ（１００）は、利用者Ｌの許可ルールに対するレスポンス（許可または拒否）を判定する（ステップＳ１２０５）。利用者Ｌのレスポンスが許可であれば（ステップＳ１２０５：Ｙｅｓ）、署名サーバＡ（１００）は、ステップＳ１２０７の処理に移行する。一方、利用者Ｌのレスポンスが拒否であれば（ステップＳ１２０５：Ｎｏ）、利用者Ｌによるパラメータ許可範囲（送金額の許可範囲）に基づいて、許可範囲付き許可ルールを生成し（ステップＳ１２０６）、ステップＳ１２０７の処理に移行する。
【0082】
次に、署名サーバＡ（１００）は、生成したパラメータ許可範囲を付与した許可範囲付き許可ルールを署名サーバＡ内部で登録する（ステップＳ１２０７）。そして、署名サーバＡ（１００）は、新しいアクセストークンを作成し、ステップＳ１２０２で受け取った取引情報、および登録した許可ルールに紐付けて署名サーバＡ内部で登録する（ステップＳ１２０８）。また、署名サーバＡ（１００）は、作成した新しいアクセストークンをＷｅｂアプリ１６０に発行する（ステップＳ１２０９）。以上により、署名サーバＡ（１００）は、許可ルールの登録フェーズにかかる一連の処理を終了する。
【0083】
次に、図１２Ｂに示す送金フェーズの処理では、はじめに、利用者Ｌは、送金額の情報を含む送金リクエストをＷｅｂアプリ１６０に送付する（ステップＳ１２１０）。次に、Ｗｅｂアプリ１６０は、送付されたアクセストークンを添付し、署名発行リクエストを署名サーバＡ（１００）に送付する（ステップＳ１２１１）。
【0084】
これにより、署名サーバＡ（１００）は、送金額を含む取引情報が、アクセストークンに紐付く許可範囲付き許可ルール（送金額の許可範囲）を満たすか否かを判定する（ステップＳ１２１２）。判定の結果が許可ルールを満たす（送金額が許可範囲内の）場合（ステップＳ１２１３：Ｙｅｓ）、署名サーバＡ（１００）は、ステップＳ１２１４の処理に移行する。一方、判定の結果が許可ルールを満たさない（送金額が許可範囲外の）場合（ステップＳ１２１３：Ｎｏ）、署名サーバＡ（１００）は、ステップＳ１２１７の処理に移行する。
【0085】
ステップＳ１２１４の処理では、署名サーバＡ（１００）は、受け取ったアクセストークンに対応する取引情報の電子署名を作成する（ステップＳ１２１４）。次に、署名サーバＡ（１００）は、作成した電子署名をＷｅｂアプリ１６０に送付する（ステップＳ１２１５）。
【0086】
これにより、Ｗｅｂアプリ１６０は、受け取った電子署名を添付し、送金取引をブロックチェーンＡ，Ｂ上で発行する（ステップＳ１２１６）。また、ステップＳ１２１７では、署名サーバＡ（１００）は、Ｗｅｂアプリ１６０に電子署名を発行しないと回答する（ステップＳ１２１７）。ステップＳ１２１６、またはステップＳ１２１７の処理後、署名サーバＡ（１００）は、送金フェーズにかかる一連の処理を終了する。
【0087】
次に、上記の図１２Ａ，図１２Ｂを用いて説明した取引処理について、送金の具体例について説明する。ステップＳ１２０１の事前準備では、利用者Ｌが、ブロックチェーンＡ（仮想通貨Ａ）と、ブロックチェーンＢ（仮想通貨Ｂ）にそれぞれアカウントａ、ｂを持っている。ここで、アカウントａの秘密鍵は、ブロックチェーンＡ用の署名サーバＡで管理されている。ここで、仮想通貨Ａを仮想通貨Ｂに交換する例を説明するが、仮に、仮想通貨Ｂを仮想通貨Ａに変換する場合は、支払い元であるブロックチェーンＢ用の署名サーバＢ（１００）が必要となる。
【0088】
そして、ステップＳ１２０２では、利用者Ｌがアカウントａの仮想通貨Ａをアカウントｂの仮想通貨Ｂに変換する。ここで、仮想通貨Ａに比べて仮想通貨Ｂの方が価値が安定しており、仮想通貨Ｂでの価値をもとに署名の発行ルールを構築することとする。但し、この例では、送金元が仮想通貨Ａであるため、秘密鍵は署名サーバＡ（１００）で管理されているため、署名サーバＡ（１００）が取引の許可ルールを設定することとする。
【0089】
図１３は、実施の形態２にかかる署名許可時の取引情報の例を示す図表である。図１３には、ステップＳ１２０２における利用者Ｌからのアクセストークン発行リクエストの際、署名サーバＡ（１００）に送付する取引情報１３００の例を示す。取引情報１３００は、送金元が「利用者Ｌのアカウントａ（仮想通貨Ａ）」、送金相手が「利用者Ｌのアカウントｂ（仮想通貨Ｂ）」、送金額が「仮想通貨Ａ２００ポイント」であったとする。
【0090】
次に、ステップＳ１２０３では、署名サーバＡ（１００）は、許可範囲を以下の手順で作成する。許可ルール設定時の取引情報に含まれる送金額をＸとしたとき、送金リクエストに含まれる送金額Ｙに対し、下記式（３）に示す許可範囲を算出する。
【0091】
Ｘ＊（１－Ｋ）≦Ｙ≦Ｘ＊（１＋Ｋ） …（３）
（但し、Ｋは、０＜Ｋ＜１を満たす定数）
（但し、Ｋは、０＜Ｋ＜１を満たす定数）
【0092】
このとき、署名サーバＡ（１００）は、予めＫ＝０．３と設定したうえで、許可ルール作成時の取引情報に含まれる送金額が仮想通貨１００ポイントであったとき、送金リクエストに含まれる送金額Ｙの許可範囲を、下記式（４）に示す許可ルールを作成する。
【0093】
７０≦Ｙ≦１３０ …（４）
【0094】
例えば、Ｋ＝０．３で、図１３に示した取引情報１３００の取引を署名サーバＡ（１００）が受け取った際、仮想通貨Ｂ／仮想通貨Ａのレートが３．０［仮想通貨Ｂ／仮想通貨Ａ］であったとする。このとき、上記許可ルールに基づくと、送金額の範囲は、仮想通貨Ｂ換算で４２０～７８０ポイントの区間内となる。
【0095】
図１４は、実施の形態２にかかる署名サーバが生成する許可ルールの例を示す図表である。ステップＳ１２０３の処理により、署名サーバＡ（１００）は、許可ルール（送金額の許可範囲）１４００を作成する。許可ルール（送金額の許可範囲）１４００は、送金先「利用者Ｌのアカウントａ（仮想通貨Ａ）」、送金相手「利用者Ｌのアカウントｂ（仮想通貨Ｂ）」、送金額の範囲「仮想通貨Ｂ換算で４２０～７８０ポイント」の情報を含む。
【0096】
また、ステップＳ１２０８の処理では、署名サーバＡ（１００）は、新規のアクセストークンとして適当な文字列（例えば「Ｐ８ｍＯｃｖ＋６ＳＷ」）を作成する。署名サーバＡ（１００）は、ステップＳ１２０４で生成した許可ルール（あるいは利用者ＬがステップＳ１２０７で作成した許可ルール）を、アクセストークンと紐付け、署名サーバＡ（１００）内部の記録部（テーブル）に新規の許可ルールとして追加する。
【0097】
図１５は、実施の形態２にかかる署名サーバが保持する許可ルールのテーブルの例を示す図表である。ステップＳ１２０８の処理により、署名サーバＡ（１００）は、許可ルールのテーブル１５００に、新規の許可ルールの行１５０１を追加する。新規の行１５０１は、新規のアクセストークン「Ｐ８ｍＯｃｖ＋６ＳＷ」、送金元「利用者Ｌのアカウントａ（仮想通貨Ａ）」、送金先「利用者Ｌのアカウントｂ（仮想通貨Ｂ）」、送金額の範囲「仮想通貨Ｂ換算で４２０～７８０ポイント」の各情報を含む。
【0098】
次に、ステップＳ１２０９の処理では、署名サーバＡ（１００）は、新規のアクセストークン「Ｐ８ｍＯｃｖ＋６ＳＷ」を、Ｗｅｂアプリ１６０に発行する。
【0099】
図１６は、実施の形態２にかかる送金リクエストの例を示す図表である。ステップＳ１２１０では、利用者Ｌは、送金リクエスト１６００をＷｅｂアプリ１６０に送付する。送金リクエスト１６００は、送金元「利用者Ｌのアカウントａ（仮想通貨Ａ）」、送金相手「利用者Ｌのアカウントｂ（仮想通貨Ｂ）」、送金額「仮想通貨Ａ２００ポイント」の情報を含む。
【0100】
図１７は、実施の形態２にかかるＷｅｂアプリから署名サーバに送付される送金リクエストの例を示す図表である。ステップＳ１２１１では、Ｗｅｂアプリ１６０は、受け取った新規のアクセストークンを付与し、送金リクエスト１７００を署名サーバＡ（１００）に送付する。送金リクエスト１７００は、送金元「利用者Ｌのアカウントａ（仮想通貨Ａ）」、送金相手「利用者Ｌのアカウントｂ（仮想通貨Ｂ）」、送金額「仮想通貨Ａ２００ポイント」、アクセストークン「Ｐ８ｍＯｃｖ＋６ＳＷ」の情報を含む。
【0101】
図１８は、実施の形態２にかかる署名サーバで抽出された許可ルールの例を示す図表である。ステップＳ１２１２では、署名サーバＡ（１００）は、送金リクエスト１７００のアクセストークン「Ｐ８ｍＯｃｖ＋６ＳＷ」を基に、署名サーバＡ（１００）が保有する許可ルールのテーブル１５００から、アクセストークンが一致する行１５０１を抜き出す。そして、抜き出した行１５０１に含まれる許可ルール１８００を抽出する。図１８に示す許可ルール１８００は、図１４と同様の情報からなり、送金先「利用者Ｌのアカウントａ（仮想通貨Ａ）」、送金相手「利用者Ｌのアカウントｂ（仮想通貨Ｂ）」、送金額の範囲「仮想通貨Ｂ換算で４２０～７８０ポイント」の情報を含む。
【0102】
そして、ステップＳ１２１３では、署名サーバＡ（１００）は、受け取った送金リクエスト１７００の送金額が、抽出した許可ルール１８００を満たすか判定する。例えば、送金リクエスト１７００の際、仮想通貨のレートが署名許可時の３．０から変動して３．２［仮想通貨Ｂ／仮想通貨Ａ］になったとする。このとき、送金額は仮想通貨Ｂ換算で６４０ポイント（レートが３．２［仮想通貨Ｂ／仮想通貨Ａ］であるため）となる。この送金額６４０ポイントは、許可ルール１８００（図１８）の送金額の範囲内であるため、署名サーバＡ（１００）は、「許可ルールを満たす」と判定する（ステップＳ１２１３：Ｙｅｓ）。
【0103】
一方、例えば、送金リクエスト１７００の際の仮想通貨のレートが、署名許可時の３．０から大きく変動して２．０［仮想通貨Ｂ／仮想通貨Ａ］となったとする。この場合、送金額の仮想通貨Ｂでの価値は４００ポイントになるため、許可ルール１８００の送金額の範囲外となるため、署名サーバＡ（１００）は、「許可ルールを満たさない」と判定する（ステップＳ１２１３：Ｎｏ）。この場合、ステップＳ１２１７の処理により、署名サーバＡ（１００）は、Ｗｅｂアプリ１６０に署名を発行しないと回答する。
【0104】
次に、ステップＳ１２１４では、署名サーバＡ（１００）は、ステップＳ１２１３にて「許可ルールを満たす（ステップＳ１２１３：Ｙｅｓ）」と判定されたときのみ、取引情報に相当する電子署名を作成する。次に、ステップＳ１２１５では、署名サーバＡ（１００）は、作成した電子署名をＷｅｂアプリ１６０に送付する。
【0105】
そして、ステップＳ１２１６では、Ｗｅｂアプリ１６０は、受け取った電子署名を添付し、送金取引をブロックチェーンＡ，Ｂ上で発行する。
【0106】
以上の実施の形態２によれば、利用者Ｌが２つのブロックチェーンＡ，Ｂの仮想通貨Ａ，Ｂを変換する送金を行う場合の通貨レートの変動に対応し、利用者Ｌの取引の許可内容と、実際の送金時の取引内容を照合できるようになる。署名サーバＡ（１００）は、取引の許可時にアクセストークンを発行する際、送金額の許可範囲を算出しておき、実際の送金時に送金額が許可範囲内の場合のみ電子署名を発行する。そして、送金の取引処理を許可する。
【0107】
これにより、ブロックチェーンＡ上で仮想通貨Ａの送金操作を行う利用者Ｌは、取引を許可したときと、実際に取引リクエストを出すときと、の間の時間差や、状況の違いがあった場合でも、送金額が意図した許可内容に沿うか否かを照合できる。また、利用者Ｌの秘密鍵１１０は、Ｗｅｂアプリ１６０に預けることなく署名サーバＡ（１００）上で保持するため、代理取引を安全に実行できるようになる。
【0108】
（実施の形態３）
実施の形態３では、利用者Ｌの過去の取引を利用して許可ルールを決定する例について説明する。上述した実施の形態１，２で説明した署名サーバＡ（１００）による送金額の許可範囲の算出時（ステップＳ４０３，ステップＳ１２０３に相当）における他の算出例を説明する。
実施の形態３では、利用者Ｌの過去の取引を利用して許可ルールを決定する例について説明する。上述した実施の形態１，２で説明した署名サーバＡ（１００）による送金額の許可範囲の算出時（ステップＳ４０３，ステップＳ１２０３に相当）における他の算出例を説明する。
【0109】
署名サーバＡ（１００）は、許可ルール設定時の取引情報（５００，１３００）に含まれる送金額をＸとしたとき、送金リクエスト（９００，１７００）に含まれる送金額Ｙに対し、下記式（５）に示す範囲で許可範囲を算出する。
【0110】
Ｘ＊（Ｍ／Ｕ）≦Ｙ≦Ｘ＊（Ｍ／Ｌ） …（５）
（但し、Ｍは直近一定期間の通貨変換レートの平均、Ｌは直近一定期間の通貨変換レートの９５％信頼区間の下限、Ｕは直近一定期間の通貨変換レートの９５％信頼区間の上限である。）
直近一定期間の通貨変換レート、および信頼区間の下限、上限の値は、それぞれ署名サーバＡ（１００）の処理部（ＣＰＵ３０１）が記録部（記録媒体３０５等）に記録しておく。
（但し、Ｍは直近一定期間の通貨変換レートの平均、Ｌは直近一定期間の通貨変換レートの９５％信頼区間の下限、Ｕは直近一定期間の通貨変換レートの９５％信頼区間の上限である。）
直近一定期間の通貨変換レート、および信頼区間の下限、上限の値は、それぞれ署名サーバＡ（１００）の処理部（ＣＰＵ３０１）が記録部（記録媒体３０５等）に記録しておく。
【0111】
また、通貨変換レートは、基軸通貨（通貨変換の中心となる通貨）を定めたうえで、［仮想通貨／基軸通貨］の比率のレートを用いる。但し、信頼区間の上限と下限の算出の際、通貨変換レートの値の分布は正規分布を仮定する。
【0112】
図１９は、実施の形態３にかかる許可ルールの決定の他の例を説明する図表である。例えば、許可ルール作成時の取引情報（５００，１３００）に含まれる送金額が仮想通貨１００ポイントであり、直近１週間の通貨変換レート［仮想通貨／米ドル］が図１９に示す状態であるとする。この場合、署名サーバＡ（１００）は、平均と９５％信頼区間の計算により、Ｍ＝１５．８３、Ｌ＝１３．２０、Ｕ＝１８．４６を算出する。このとき、Ｘ＊（Ｍ／Ｕ）＝８５．８、Ｘ＊（Ｍ／Ｌ）＝１１９．９となり、送金リクエストに含まれる送金額Ｙの許可範囲として、８５．８≦Ｙ≦１１９．９を算出する。
【0113】
この実施の形態３によれば、過去の一定期間に行った取引の通貨変換レートに基づき送金額の許可範囲を算出することができる。これにより、利用者Ｌが実際に取引処理した情報に基づいて利用者Ｌの取引の意向に沿った許可ルールを作成できるようになる。また、上記例では、送金額の許可範囲は、利用者Ｌの過去の一定期間に行った取引に基づき算出したが、これに限らず、他の利用者の過去の一定期間に行った取引に基づき算出してもよい。例えば、利用者Ｌが過去の一定期間に取引を行っていない場合等には、他の利用者の過去の一定期間に行った取引に基づき算出した送金額の許可範囲を利用者Ｌが用いることもでき、取引回数が少ない利用者であっても適切な送金が行えるようになる。
【0114】
（実施の形態４）
実施の形態４では、スマートコントラクトのバリエーション（各種システムへの適用例）について説明する。上述した各実施の形態では、仮想通貨の送金についての代理認証システムへの適用例を説明した。これに限らず、ブロックチェーンにおけるスマートコントラクト発行・操作用のＷｅｂアプリ１６０の代理認証機能についても、同様に適用できる。
実施の形態４では、スマートコントラクトのバリエーション（各種システムへの適用例）について説明する。上述した各実施の形態では、仮想通貨の送金についての代理認証システムへの適用例を説明した。これに限らず、ブロックチェーンにおけるスマートコントラクト発行・操作用のＷｅｂアプリ１６０の代理認証機能についても、同様に適用できる。
【0115】
Ｗｅｂアプリ１６０からの電子署名発行の要求を署名サーバＡ（１００）が検証する際、スマートコントラクトの実行を行う取引の場合は、引数の値に対して許可範囲を持たせて許可ルールを設定すればよい。なお、この点について、上記各実施の形態では、送金リクエストの際、署名サーバＡ（１００）が送金額の許可範囲を算出して許可ルールを作成している。
【0116】
各種システムへの適用例としては、例えば、スーパーマーケットの惣菜売り場のスマートコントラクトがある。利用者からは、「惣菜３００グラムを仮想通貨１ポイントで支払う」権限を予め測量機器に付与する。測量機器が惣菜２５０～３５０グラムの範囲で計測したとき、測量機器と連動したスマートコントラクトが利用者の代行で仮想通貨支払いを行う構成とすることができる。
【0117】
このように、仮想通貨に限らず、ポイントカードによる取引等を含め、各種の取引処理におけるスマートコントラクトのパラメータ（許可範囲の設定値や条件）について、上記実施の形態と同様に設定することができる。これにより、利用者の取引の許可内容と、実際のシステム利用時の取引内容を照合できるようになる。また、Ｗｅｂアプリの利用者は、取引を許可したときと、実際に取引リクエストを出すときと、の間の時間差や、状況の違いがあった場合でも、送金額等の取引処理を意図した許可内容に沿って実行できるようになる。
【0118】
（従来技術と実施の形態との差異について）
従来の技術と実施の形態との差異について説明しておく。従来、利用者の権限を他のアプリに委譲する仕組みとして、例えば、ＯＡｕｔｈ２．０の技術が広く知られている。この技術は、利用者が持つアクセス権限をＷｅｂアプリにアクセストークンを使って一部委譲して、Ｗｅｂアプリが利用者の代理で処理を可能にする仕組みである。なお、アクセストークンは、上述したように、利用者の代行として特定の操作に限り許可することを示す記号（文字列）である。
従来の技術と実施の形態との差異について説明しておく。従来、利用者の権限を他のアプリに委譲する仕組みとして、例えば、ＯＡｕｔｈ２．０の技術が広く知られている。この技術は、利用者が持つアクセス権限をＷｅｂアプリにアクセストークンを使って一部委譲して、Ｗｅｂアプリが利用者の代理で処理を可能にする仕組みである。なお、アクセストークンは、上述したように、利用者の代行として特定の操作に限り許可することを示す記号（文字列）である。
【0119】
図２０は、従来技術による利用者の権限の代理認証の例を説明する図である。図２０の例では、利用者Ｌが投稿サイト２０１０（動画投稿サイト用サーバ２０１１）、およびＳＮＳサイト２０２０（ＳＮＳサイト用サーバ２０２１）にそれぞれアクセス権限を有しているとする。そして、予め、利用者ＬがＳＮＳサイト２０２０に対し、「動画投稿サイト２０１０が、利用者Ｌ本人の代わりにＳＮＳサイト２０２０上で投稿を行う」ことを許可しておく（ステップＳ２００１）。この場合、ＳＮＳサイト２０２０は、動画投稿サイト２０１０にアクセストークンを発行する（ステップＳ２００２）。
【0120】
そして、利用者Ｌが動画投稿サイト２０１０に動画を投稿したとする（ステップＳ２００３）。この場合、動画投稿サイト２０１０は、利用者Ｌの代行でＳＮＳサイト２０２０にアクセストークンを添付し、動画を投稿する（ステップＳ２００４）。このように、利用者Ｌが動画投稿サイト２０１０に動画を登録した場合、事前に登録したアクセストークンを使って、動画投稿サイト２０１０が利用者Ｌの権限を借りて自動でＳＮＳサイト２０２０に動画等を投稿する際、代理認証することができる。
【0121】
図２１は、従来技術によるブロックチェーンの代理取引システムの構成例を説明する図である。上述したＯＡｕｔｈ２．０の技術を用いて、図２１に示すような代理認証込みの仮想通貨取引システム構成の構築を行ったとする。署名サーバＡ，Ｂ（２１０１）は、利用者ＬのブロックチェーンＡ，Ｂ用の秘密鍵２１１０を保有する。また、図示のように、利用者Ｌは、Ｗｅｂアプリ２１６０（Ｗｅｂアプリ用サーバ２１５０）にアクセス可能である。
【0122】
図２１に示したシステム構成における代理認証の流れを順に説明すると、はじめに、利用者Ｌは、特定の送金リクエスト（送金元、送金相手、送金金額）に限り、署名サーバＡ，Ｂ（２１０１）が署名を発行することを許可しておく（ステップＳ２１０１）。署名サーバＡ，Ｂ（２１０１）は、アクセストークンを取引情報に紐付けて登録しておく（ステップＳ２１０２）。そして、署名サーバＡ，Ｂ（２１０１）は、アクセストークンをＷｅｂアプリ２１６０に発行する（ステップＳ２１０３）。
【0123】
この後、利用者Ｌにより送金リクエストがあると（ステップＳ２１０４）、Ｗｅｂアプリ２１６０は、署名サーバＡ，Ｂ（２１０１）に電子署名の発行を要求する（ステップＳ２１０５）。署名サーバＡ，Ｂ（２１０１）は、アクセストークンの仕組みを用いて、取引内容が利用者Ｌの許可内容と合致しているか検証し（ステップＳ２１０６）、合致している場合はＷｅｂアプリ２１６０に署名を発行する（ステップＳ２１０７）。これにより、Ｗｅｂアプリ２１６０は、署名サーバＡ，Ｂ（２１０１）から受け取った署名を用いて、利用者Ｌの代理取引としてブロックチェーンＡ，Ｂ上に取引を発行する（ステップＳ２１０８）。
【0124】
上記従来技術によるシステム構成では、利用者が意図した許可内容と実際の取引内容との照合が困難であった。例えば、仮想通貨の変換では、短時間で通貨変換レートが変動する。このため、利用者Ｌが署名を許可した時点（アクセストークン発行時、ステップＳ２１０１）と、実際にＷｅｂアプリ２１６０を介した送金を行う時点（送金リクエスト発行時、ステップＳ２１０４）とで取引金額が異なることになる。
【0125】
具体例を用いて説明すると、仮想通貨の取引システムにおいて、仮想通貨が基軸となる通貨（例えば、米ドル）とのレートが変動し、かつ署名サーバＡ，Ｂ（２１０１）の許可ルールを基軸通貨の価値を元に構成したとする。ここで、署名を許可したとき（「利用日：２０１８年９月１４日、１５：００、ステップＳ２１０１）では「仮想通貨Ａと米ドルのレートが２．０ＵＳＤ／仮想通貨Ａ」であったとする。この場合、仮想通貨Ａを１００ポイント移転させる場合、米ドルにおける価値は２００ＵＳＤである。そのため、署名サーバＡ，Ｂ（２１０１）は、「利用者が指定された宛先に２００ＵＳＤ相当の取引を送るときに署名を渡す」ものとして書名発行ルールを設定している。
【0126】
しかし、実際に送金を行うとき（「利用日：２０１８年９月１４日、１５：３０、ステップＳ２１０４）までの間に仮想通貨のレートが変動し、「仮想通貨Ａと米ドルのレートが１．８ＵＳＤ／仮想通貨Ａ」となったとする。この場合、同じ仮想通貨Ａを１００ポイント移転させる取引であっても、米ドル上での価値は１８０ＵＳＤとなり、この取引には署名サーバＡ，Ｂ（２１０１）は、ステップＳ２１０７での署名を発行できない。
【0127】
このように、従来、ＯＡｕｔｈ２．０の技術を単に代理認証込みの仮想通貨取引システムに適用しただけでは、利用者Ｌが取引を許可したときと、実際に取引リクエストを出すときに時間差や状況の違いがあると、許可内容と取引内容を照合することができない。この場合、例えば、利用者は、送金額が意図した送金額の許可範囲に沿っているか否かを検討することができない。また、署名サーバが署名を発行しない場合、取引自体を行うことができない。
【0128】
また、従来技術では、Ｗｅｂアプリケーションが利用者の秘密鍵を保持し、取引処理時にブロックチェーンとの間で情報をやり取りしていた。秘密鍵をＷｅｂアプリケーションが保持することで代理取引を安全に実行できない恐れも生じた。
【0129】
これに対し、上述した実施の形態では、署名サーバが、利用者の取引情報をもとに送金額の許可範囲を算出した許可ルールを設定しておき、利用者の送金リクエストが許可ルール内か否かを判定する。これにより、Ｗｅｂアプリの利用者が取引を許可したときと、実際に送金リクエストを出すときに時間差や状況の違いにより通貨変換レートが変動しても、署名サーバは、許可ルールに基づき利用者の送金額が意図した許可範囲内であるかを照合できるようになる。加えて、利用者は、送金額の許可範囲で送金することができ、意図しない過小または過大な送金を防ぐことができる。
【0130】
また、実施の形態では、署名サーバが利用者の秘密鍵を保持しており、従来に比して代理取引を安全に実行できるようになる。また、複数のブロックチェーンの連携時においても、対応する複数の署名サーバがそれぞれの利用者の秘密鍵を分散して保持することとなり、複数のブロックチェーンの連携時においても代理取引を安全に実行できるようになる。
【0131】
以上説明した実施の形態によれば、署名サーバは、利用者からの取引情報を含むトークン発行リクエストの受信に応じて、取引内容の許可範囲を定める許可ルールを取引情報に基づいて生成するとともに、利用者の代理取引の処理を行うＷｅｂアプリケーションに許可ルールに対応するトークンを送信する。また、Ｗｅｂアプリケーションからのトークンを含む利用者による取引リクエストに基づく署名発行要求の受信に応じて、取引リクエストに含まれる取引内容が署名発行要求に含まれるトークンに対応する許可ルールで定められた許可範囲内か否かに基づき、署名発行要求に対応する電子署名の発行可否を判定する。これにより、トークン発行リクエスト時の取引の許可内容と、実際の取引内容の照合が行える。すなわち、利用者の送金額が意図した送金額の許可範囲に沿うか否かを照合できるようになる。また、署名サーバは、実際の取引内容が許可ルールの許可範囲を満たしているか否かを判定し、満たしていれば、電子署名を発行してＷｅｂアプリケーション（Ｗｅｂアプリ）での送金取引を実行させる。そして、実施の形態で行う取引処理は、ブロックチェーンと署名サーバによる代理取引に適用できる。
【0132】
また、取引が、利用者による通貨価値を有する金額またはポイントの送金の場合、署名サーバは、利用者からのトークン発行リクエスト時には、許可ルールに送金額の許可範囲を定める。そして、利用者による実際の送金リクエスト時には、送金リクエストに含まれる送金額が許可ルールで定めた許可範囲内か否かを判定する。これにより、仮想通貨等における送金に適用して、代理取引時の利用者の許可内容と、実際の取引内容の照合を行うことができるようになる。仮想通貨等では、短時間で通貨変換レートが変動するため、利用者が許可した時点（アクセストークンの発行時点）と、利用者が実際にＷｅｂアプリを介して送金リクエストを発行する時点と、で同じ送金額でも通貨変換レートの変動で実際の取引金額が異なる状況が発生する。この点、送金額が許可範囲内であるか否かを照合でき、実際の送金時に通貨変換レートで送金額が変動しても許可範囲内にあれば電子署名を発行し、Ｗｅｂアプリによる代理取引を適切に行える。
【0133】
また、署名サーバは、送金リクエストに含まれる送金額が許可ルールで定めた許可範囲内の場合のみ、Ｗｅｂアプリケーションに取引情報の電子署名を発行可と判定し、Ｗｅｂアプリケーションに対して電子署名を発行してもよい。これにより、利用者が実際に送金を行う送金リクエスト時に、送金額が許可範囲内であれば署名サーバが電子署名を発行し、利用者は送金取引を行うことができる。一方、送金額が許可範囲外であれば送金取引を許可しない。また、利用者は、署名サーバに設定された送金額の許可範囲内で送金を行うことができるようになる。
【0134】
また、署名サーバは、利用者による取引処理を認証する認証情報を保持し、認証情報を用いて電子署名を作成してもよい。利用者の認証情報（秘密鍵）を署名サーバが預かり保持することで、従来のようにＷｅｂアプリケーションが秘密鍵を保持する必要がなく、代理取引を安全に実行できるようになる。
【0135】
また、署名サーバは、利用者からの取引情報を含むトークン発行リクエスト毎に、許可ルールの情報として、利用者毎の送金元、送金先、送金額の許可範囲、トークンの情報、をそれぞれ関連付けた情報をテーブルに追加作成する。そして、利用者による実際の送金リクエスト時には、テーブルの許可ルールを参照し、送金リクエストに対応する許可ルールを抽出し、抽出した許可ルールの送金額が送金額の許可範囲内であるか否かを判定してもよい。これにより、利用者が取引を行った都度、取引内容の履歴をテーブル化して蓄積していくことができ、利用者別に適した許可ルールを作成できるようになり、利用者別に適した許可ルールに基づき、送金を適正に処理できるようになる。
【0136】
また、署名サーバは、許可ルール作成時の取引情報に含まれる送金額に所定の係数を掛けた値を送金額の許可範囲を規定する最大値および最小値として算出してもよい。これにより、送金額の許可範囲を適切に設定することができ、許可範囲を用いて実際の送金の処理を適切に実行できるようになる。
【0137】
また、署名サーバは、利用者、あるいは他の利用者の現在あるいは過去の取引情報に含まれる通貨変換レートを用いて、送金額の許可範囲を算出してもよい。これにより、利用者の取引状況に対応して送金額の許可範囲を適切に設定できるようになり、利用者別に適した許可ルールに基づき、送金を適正に処理できるようになる。また、取引回数が少ない利用者であっても他の利用者の取引情報を用いて適切な送金が行えるようになる。
【0138】
また、署名サーバは、算出した許可ルールを利用者に通知し、利用者の承認により許可ルールを用いた判定を行い、利用者の承認拒否時には、利用者が作成した許可ルールを用いた判定を行うこととしてもよい。これにより、署名サーバが作成した許可ルールについて、利用者の承認の元で送金を適切に行うことができるようになる。また、署名サーバが作成した許可ルールを利用者が承認拒否したときには、利用者が作成した許可ルールを用いて送金できるため、利用者の意向に沿った送金の取引を行えるようになる。
【0139】
また、前記取引が、一つまたは複数のブロックチェーンのアカウントを利用したスマートコントラクトであってもよく、スマートコントラクトの実行を行う取引の際、Ｗｅｂアプリケーションからの電子署名発行の要求に対し、許可ルールを用いた判定を行う。これにより、実施の形態で説明した取引処理を各種システムに適用でき、適用した各種システムにおける取引処理を、許可ルールを用いて適切に実行できるようになる。
【0140】
なお、本発明の実施の形態で説明した署名方法は、予め用意されたプログラムをサーバ等のプロセッサに実行させることにより実現することができる。本署名方法は、ハードディスク、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ－Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フラッシュメモリ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることにより実行される。また本署名方法は、インターネット等のネットワークを介して配布してもよい。
【0141】
上述した実施の形態に関し、さらに以下の付記を開示する。
【0142】
（付記１）利用者からの取引情報を含むトークン発行リクエストの受信に応じて、取引内容の許可範囲を定める許可ルールを前記取引情報に基づいて生成するとともに、前記利用者の代理取引の処理を行うＷｅｂアプリケーションに前記許可ルールに対応するトークンを送信し、
前記Ｗｅｂアプリケーションからのトークンを含む前記利用者による取引リクエストに基づく署名発行要求の受信に応じて、前記取引リクエストに含まれる取引内容が前記署名発行要求に含まれる前記トークンに対応する許可ルールで定められた前記許可範囲内か否かに基づき、前記署名発行要求に対応する電子署名の発行可否を判定する処理部、
を備えたことを特徴とする署名サーバ。
前記Ｗｅｂアプリケーションからのトークンを含む前記利用者による取引リクエストに基づく署名発行要求の受信に応じて、前記取引リクエストに含まれる取引内容が前記署名発行要求に含まれる前記トークンに対応する許可ルールで定められた前記許可範囲内か否かに基づき、前記署名発行要求に対応する電子署名の発行可否を判定する処理部、
を備えたことを特徴とする署名サーバ。
【0143】
（付記２）前記取引が、前記利用者による通貨価値を有する金額またはポイントの送金の場合、前記処理部は、
前記利用者からの前記トークン発行リクエスト時には、前記許可ルールに送金額の許可範囲を定め、
前記利用者による送金リクエスト時には、前記送金リクエストに含まれる前記送金額が前記許可ルールで定めた許可範囲内か否かを判定する、
ことを特徴とする付記１に記載の署名サーバ。
前記利用者からの前記トークン発行リクエスト時には、前記許可ルールに送金額の許可範囲を定め、
前記利用者による送金リクエスト時には、前記送金リクエストに含まれる前記送金額が前記許可ルールで定めた許可範囲内か否かを判定する、
ことを特徴とする付記１に記載の署名サーバ。
【0144】
（付記３）前記処理部は、
前記送金リクエストに含まれる前記送金額が前記許可ルールで定めた許可範囲内の場合のみ、前記Ｗｅｂアプリケーションに前記取引情報の電子署名を発行可と判定し、前記Ｗｅｂアプリケーションに対して前記電子署名を発行する、
ことを特徴とする付記２に記載の署名サーバ。
前記送金リクエストに含まれる前記送金額が前記許可ルールで定めた許可範囲内の場合のみ、前記Ｗｅｂアプリケーションに前記取引情報の電子署名を発行可と判定し、前記Ｗｅｂアプリケーションに対して前記電子署名を発行する、
ことを特徴とする付記２に記載の署名サーバ。
【0145】
（付記４）前記処理部は、
前記利用者による取引処理を認証する認証情報を保持し、当該認証情報を用いて前記電子署名を作成する、
ことを特徴とする付記３に記載の署名サーバ。
前記利用者による取引処理を認証する認証情報を保持し、当該認証情報を用いて前記電子署名を作成する、
ことを特徴とする付記３に記載の署名サーバ。
【0146】
（付記５）前記処理部は、
前記利用者からの取引情報を含むトークン発行リクエスト毎に、前記許可ルールの情報として、前記利用者毎の送金元、送金先、前記送金額の許可範囲、前記トークンの情報、をそれぞれ関連付けた情報をテーブルに追加作成し、
前記利用者による送金リクエスト時には、前記テーブルの前記許可ルールを参照し、当該送金リクエストに対応する前記許可ルールを抽出し、抽出した前記許可ルールの前記送金額が前記送金額の許可範囲内であるか否かを判定する、
ことを特徴とする付記２～４のいずれか一つに記載の署名サーバ。
前記利用者からの取引情報を含むトークン発行リクエスト毎に、前記許可ルールの情報として、前記利用者毎の送金元、送金先、前記送金額の許可範囲、前記トークンの情報、をそれぞれ関連付けた情報をテーブルに追加作成し、
前記利用者による送金リクエスト時には、前記テーブルの前記許可ルールを参照し、当該送金リクエストに対応する前記許可ルールを抽出し、抽出した前記許可ルールの前記送金額が前記送金額の許可範囲内であるか否かを判定する、
ことを特徴とする付記２～４のいずれか一つに記載の署名サーバ。
【0147】
（付記６）前記処理部は、
前記許可ルール作成時の前記取引情報に含まれる前記送金額に所定の係数を掛けた値を前記送金額の許可範囲を規定する最大値および最小値として算出する、
ことを特徴とする付記２～５のいずれか一つに記載の署名サーバ。
前記許可ルール作成時の前記取引情報に含まれる前記送金額に所定の係数を掛けた値を前記送金額の許可範囲を規定する最大値および最小値として算出する、
ことを特徴とする付記２～５のいずれか一つに記載の署名サーバ。
【0148】
（付記７）前記処理部は、
前記利用者、あるいは他の利用者の現在あるいは過去の取引情報に含まれる通貨変換レートを用いて、前記送金額の許可範囲を算出する、
ことを特徴とする付記２～６のいずれか一つに記載の署名サーバ。
前記利用者、あるいは他の利用者の現在あるいは過去の取引情報に含まれる通貨変換レートを用いて、前記送金額の許可範囲を算出する、
ことを特徴とする付記２～６のいずれか一つに記載の署名サーバ。
【0149】
（付記８）前記処理部は、
算出した前記許可ルールを前記利用者に通知し、当該利用者の承認により前記許可ルールを用いた判定を行い、
前記利用者の承認拒否時には、前記利用者が作成した前記許可ルールを用いた判定を行う、
ことを特徴とする付記２～７のいずれか一つに記載の署名サーバ。
算出した前記許可ルールを前記利用者に通知し、当該利用者の承認により前記許可ルールを用いた判定を行い、
前記利用者の承認拒否時には、前記利用者が作成した前記許可ルールを用いた判定を行う、
ことを特徴とする付記２～７のいずれか一つに記載の署名サーバ。
【0150】
（付記９）前記取引が、一つまたは複数のブロックチェーンのアカウントを利用したスマートコントラクトであり、
当該スマートコントラクトの実行を行う取引の際、前記Ｗｅｂアプリケーションからの電子署名発行の要求に対し、前記許可ルールを用いた判定を行う、
ことを特徴とする付記１～８のいずれか一つに記載の署名サーバ。
当該スマートコントラクトの実行を行う取引の際、前記Ｗｅｂアプリケーションからの電子署名発行の要求に対し、前記許可ルールを用いた判定を行う、
ことを特徴とする付記１～８のいずれか一つに記載の署名サーバ。
【0151】
（付記１０）利用者からの取引情報を含むトークン発行リクエストに応じて、取引内容の許可範囲を定める許可ルールを前記取引情報に基づいて生成するとともに、前記利用者の代理取引の処理を行うＷｅｂアプリケーションに前記許可ルールに対応するトークンを渡し、
前記利用者による取引リクエストに基づく前記Ｗｅｂアプリケーションからのトークンを含む署名発行要求に応じて、前記取引リクエストに含まれる取引内容が前記署名発行要求に含まれる前記トークンに対応する許可ルールで定めた前記許可範囲内か否かに基づき、前記署名発行要求に対応する電子書名の発行可否を判定する、
処理をコンピュータが実行することを特徴とする署名方法。
前記利用者による取引リクエストに基づく前記Ｗｅｂアプリケーションからのトークンを含む署名発行要求に応じて、前記取引リクエストに含まれる取引内容が前記署名発行要求に含まれる前記トークンに対応する許可ルールで定めた前記許可範囲内か否かに基づき、前記署名発行要求に対応する電子書名の発行可否を判定する、
処理をコンピュータが実行することを特徴とする署名方法。
【0152】
（付記１１）利用者からの取引情報を含むトークン発行リクエストに応じて、取引内容の許可範囲を定める許可ルールを前記取引情報に基づいて生成するとともに、前記利用者の代理取引の処理を行うＷｅｂアプリケーションに前記許可ルールに対応するトークンを渡し、
前記利用者による取引リクエストに基づく前記Ｗｅｂアプリケーションからのトークンを含む署名発行要求に応じて、前記取引リクエストに含まれる取引内容が前記署名発行要求に含まれる前記トークンに対応する許可ルールで定めた前記許可範囲内か否かに基づき、前記署名発行要求に対応する電子署名の発行可否を判定する、
処理をコンピュータに実行させることを特徴とする署名プログラム。
前記利用者による取引リクエストに基づく前記Ｗｅｂアプリケーションからのトークンを含む署名発行要求に応じて、前記取引リクエストに含まれる取引内容が前記署名発行要求に含まれる前記トークンに対応する許可ルールで定めた前記許可範囲内か否かに基づき、前記署名発行要求に対応する電子署名の発行可否を判定する、
処理をコンピュータに実行させることを特徴とする署名プログラム。
【符号の説明】
【0153】
１００ 署名サーバ
１０１ リクエスト受付／回答部
１０２ 許可範囲算出部
１０３ 許可ルール登録部
１０４ アクセストークン作成部
１０５ 許可ルール判定部
１０６ 電子署名作成部
１１０ 秘密鍵
１６０ Ｗｅｂアプリ
３０１ ＣＰＵ（処理部）
３０２ メモリ
３０３ ネットワークインタフェース
３０５ 記録媒体
３１０ ネットワーク
Ｌ 利用者（ユーザ）
１０１ リクエスト受付／回答部
１０２ 許可範囲算出部
１０３ 許可ルール登録部
１０４ アクセストークン作成部
１０５ 許可ルール判定部
１０６ 電子署名作成部
１１０ 秘密鍵
１６０ Ｗｅｂアプリ
３０１ ＣＰＵ（処理部）
３０２ メモリ
３０３ ネットワークインタフェース
３０５ 記録媒体
３１０ ネットワーク
Ｌ 利用者（ユーザ）
【図1】
【図2】
【図3】
【図4A】
【図4B】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12A】
【図12B】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】