(57)【要約】【課題】利用者の利便性と秘密鍵管理の安全性とを両立するためのデジタルアセット管理システムの提供。【解決手段】  利用者と、サービス提供者と、管理業者との間でデジタルアセットを管理するためのデジタルアセット管理システムであって、前記デジタルアセットにアクセスするための秘密情報を秘密分散法を用いて少なくとも４つの割符に分割する割符生成手段と、前記割符のうち、所定の閾値の数以上の前記割符が集まったことを条件として前記利用者の前記アクセスを正当なものとみなすための同意判定手段と、を有し、前記割符は、少なくとも３つが常用割符として前記利用者と前記サービス提供者と前記管理業者とのそれぞれに分配され、前記割符の数と前記閾値の数との差分の数が冗長化割符として保管されることを特徴とするデジタルアセット管理システム。【選択図】図２
2020058008.tif 000002
【特許請求の範囲】
【請求項１】
利用者、サービス提供者、管理業者との間で相互に利用者のデジタルアセットを管理するためのデジタルアセット管理システムであって、
前記デジタルアセットにアクセスするための秘密情報を秘密分散法を用いて少なくとも４つの割符に分割する割符生成手段と、
前記割符のうち、所定の閾値の数以上の前記割符が集まったことを条件として前記利用者の前記アクセスを正当なものとみなすための同意判定手段と、
を有し、
前記割符は、少なくとも３つが常用割符として前記利用者と前記サービス提供者と前記管理業者とのそれぞれに分配され、前記割符の数と前記閾値の数との差分の数が冗長化割符として保管されることを特徴とするデジタルアセット管理システム。
【請求項２】
請求項１に記載のデジタルアセット管理システムにおいて、
前記割符は、４つまたは５つに分割され、前記閾値の数の２倍を超えないように分割されることを特徴とするデジタルアセット管理システム。
【請求項３】
請求項１または２に記載のデジタルアセット管理システムにおいて、
前記割符生成手段は、ハードウェアセキュリティモジュール上で前記割符の生成を行うとともに、前記割符のうち１つを前記利用者に送付されるＩＣカードに格納することを特徴とするデジタルアセット管理システム。
【請求項４】
請求項１乃至３の何れか１つに記載のデジタルアセット管理システムにおいて、
前記デジタルアセットの移転はブロックチェーン技術を用いたトランザクションとして記録され、
前記同意判定手段が前記アクセスを正当なものとみなしたことを条件として、前記トランザクションに署名が行われることを特徴とするデジタルアセット管理システム。
【請求項５】
請求項４に記載のデジタルアセット管理システムにおいて、
前記冗長化割符を２つ生成し、
前記冗長化割符のうち少なくとも１つを受益者代理人に付与することを特徴とするデジタルアセット管理システム。
【請求項６】
請求項１乃至３の何れか１つに記載のデジタルアセット管理システムと、
前記デジタルアセットのアクセスによって決済が承認される承認手段と、を有し、
前記デジタルアセットを用いた支払い決済を行う情報処理システム。
【請求項７】
複数間で相互にデジタルアセットを管理するための秘密情報の管理システムであって、
秘密情報を導出する秘密情報生成手段と、
前記秘密情報に基づいて複数の割符を生成し、当該割符の少なくとも１つを送付する割符生成手段と、
前記割符を送付する際に当該割符を非活性化する非活性化手段と、
前記複数の割符から前記秘密情報を復元する復号手段と、
を有することを特徴とする管理システム。
【請求項８】
請求項７に記載の管理システムであって、
前記割符生成手段と前記復号手段とはハードウェアセキュリティモジュール上に設けられることを特徴とする管理システム。
【請求項９】
請求項７または８に記載の管理システムであって、
前記非活性化手段は、前記割符を暗号化することで当該割符から前記復号手段によらずに前記秘密情報を導出出来なくすることを特徴とする管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デジタルアセット管理システムおよびデジタルアセット管理システムを用いて行われる情報処理システムおよび管理システムに関する。
【背景技術】
【０００２】
近年では仮想通貨、暗号通貨、コイン、トークン等の様々な電子情報によって構成された資産（デジタルアセット）を活用する機会が増加してきている。
こうしたデジタルアセットの管理を行う上では、秘密鍵と公開鍵のペアを生成し、秘密鍵を知っていることを以て本人であることを確認する、所謂公開鍵暗号方式が広く用いられている。
しかしながら、このように秘密鍵を用いて本人であることを証明するシステムでは、秘密鍵の盗難や紛失等のリスクが非常に高くなってしまうという課題があった。
また、秘密鍵の厳密な管理は、サービスの利用者にとってはハードルが高く、利便性の低下につながってしまうという懸念も生じていた。
このような課題を解決する方法の１つとして複数人でトランザクションへの署名を行う所謂マルチシグ等の方法も考えられてはいるが、利便性とセキュリティ向上との両立が十分になされているとは言い難い。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−２３１４０４号公報
【特許文献２】特開２００７−４２０２７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明は、かかる問題を解決するためのものであり、利用者の利便性と秘密鍵管理の安全性とを両立するためのデジタルアセット管理システムの提供を目的とする。
【課題を解決するための手段】
【０００５】
上述した課題を解決するため、本発明のデジタルアセット管理システムは、前記デジタルアセットにアクセスするための秘密情報を秘密分散法を用いて少なくとも４つの割符に分割する割符生成手段と、前記割符のうち、所定の閾値の数以上の前記割符が集まったことを条件として前記利用者の前記アクセスを正当なものとみなすための同意判定手段と、を有し、前記割符は、少なくとも３つが常用割符として前記利用者と前記サービス提供者と前記管理業者とのそれぞれに分配され、前記割符の数と前記閾値の数との差分の数が冗長化割符として保管されることを特徴とする。
【発明の効果】
【０００６】
本発明によれば、デジタルアセットの使用に必要な秘密情報を安全に管理することができる。
【図面の簡単な説明】
【０００７】
【図１】本発明の実施形態に係る情報処理システムの全体構成の一例を示す図である。
【図２】本発明の管理システムの動作の一例を示す図である。
【図３】本発明の実施形態に用いられる秘密分散法の概念を示す図である。
【図４】本発明の実施形態における管理システムのデータの流れを示す図である。
【図５】本発明の実施形態における管理システムの動作の一例を示す図である。
【図６】デジタルアセットの管理の従来例を示す図である。
【図７】本発明の実施形態において、割符の紛失時に用いられる秘密分散法の概念を示す図である。
【図８】本発明の実施形態において、割符を更に分散する方法の概念図である。
【図９】本発明の実施形態において、割符を更に分散することで非活性化する方法の概念図である。
【図１０】本発明の実施形態において、認証・認可を別のシステムを利用して行う場合のシステムの動作の一例を示す図である。
【発明を実施するための形態】
【０００８】
本発明の第１の実施形態として、ビットコインなどの仮想通貨と現実の貨幣等を交換する仮想通貨取引所のシステムを用いて説明を行う。
なお、以降の説明において、「デジタルアセット」とは仮想通貨、暗号通貨、コイン、トークン等の様々な電子情報によって構成された資産を指し、デジタルアセットの管理とは、かかる資産を構成する電子情報を適切に取り出し可能に保管することを言う。デジタルアセットの管理には例えば本実施形態に於いて述べるような保管の他、利用者の同意に基づいて運用を行う所謂信託のような業態や、支払い決済の代行等を含んでも良い。
【０００９】
管理システム１００は、利用者Ｐに送付されるＩＣカード１０と、利用者Ｐが用いる端末１１と、利用者Ｐに対して仮想通貨の交換サービスを提供するサービス提供者Ｑが有するサーバ２０と、保管代行業者Ｒの備える管理用サーバ３０と、を含んだネットワーク９上に構成される情報処理システムである。
【００１０】
なお、本実施形態においては特に、サービス提供者Ｑは仮想通貨の交換業を行う仮想通貨交換業者であるとし、かかるサービス提供者Ｑに預けられたデジタルアセットの管理業務を行う管理業者が保管代行業者Ｒである。
【００１１】
ＩＣカード１０は、後述する割符５１Ａがデータとして内部に格納されたカードである。端末１１は、かかるＩＣカード１０を読み取るカードリーダとしての機能を有するパソコンあるいはその他電子計算機を含む電子機器である。
【００１２】
サーバ２０は、端末１１から送付されてきた割符５１Ａをサービス提供者Ｑの保管する割符５１Ｂと合成するハードウェアセキュリティモジュールたる第１ＨＳＭ２１と、利用者Ｐの登録を行う登録手段としての認証用ＤＢ２２と、を有している。
【００１３】
管理用サーバ３０は、保管代行業者Ｒの割符５１Ｃを有する割符ＤＢ３２と、サーバ２０から送付されてきた割符５１Ａと割符５１Ｂとの合成割符を割符５１Ｃと合成するハードウェアセキュリティモジュールたる第２ＨＳＭ３１と、を有している。
ハードウェアセキュリティモジュールは、耐タンパー性（物理的あるいは論理的な攻撃に対する耐性）を備え、複号中や計算中の秘密情報（本実施形態では暗号鍵）の外部からの読取が不可能なハードウェアである。
なお、本実施形態においては、第２ＨＳＭ３１が、割符生成手段としての機能を有している。また、第１ＨＳＭ２１と、第２ＨＳＭ３１とが同意判定手段を構成している。かかる機能については、図２を用いて後述する。
【００１４】
まず、利用者Ｐが仮想通貨交換業者であるサービス提供者Ｑのサーバ２０に接続して、認証用ＤＢ２２にユーザとして登録すると、サーバ２０は、かかる利用者Ｐの登録情報に基づいて管理用サーバ３０に一対の鍵ペアの生成を申請する（ステップＳ１０１）。
【００１５】
次に管理用サーバ３０は、第２ＨＳＭ３１上で乱数から一対の公開鍵５０と秘密鍵５１との鍵ペアを生成する（ステップＳ１０２）。なお、かかる鍵生成は、一般的なＲＳＡ暗号方式を用いても良いし、その他の公開鍵暗号方式を用いても構わない。
【００１６】
第２ＨＳＭ３１はさらに、ステップＳ１０２において生成された公開鍵５０と秘密鍵５１とを、利用者Ｐのデジタルアセットに紐づける（ステップＳ１０３）。
第２ＨＳＭ３１は、秘密鍵５１を秘密情報として、秘密分散法によって割符５１Ａ〜割符５１Ｄの４つに分割する（ステップＳ１０４）。
なお、以降は、閾値３に設定したシャノアの秘密分散法を用いて、説明を行う。
かかる割符５１Ａ〜５１Ｄは、それぞれ所定のデータ型なるように形成されたデータ群であって、割符５１Ａ〜５１Ｄのうち、何れか３つ以上が集まったときに、元となった秘密情報である秘密鍵５１を復元可能な分割データである。
また、図３から明らかなように、割符５１Ａ〜５１Ｄは、閾値の数である３未満すなわち何れか１つあるいは２つが盗み見られた場合であっても、それぞれはデータ群に過ぎないため、秘密鍵５１を復元することができないという特性を有している。
【００１７】
このような秘密分散法について、図３を用いて概略を説明する。
図３に示したように、秘密情報となる秘密鍵５１がｆ（ｘ＝０）の解となる任意の２次関数ｆ（ｘ）を仮定する。
このとき、関数ｆ（ｘ）は、閾値の数３とすると、閾値の数−次数が１となるように、次数が２であることが望ましい。
第２ＨＳＭ３１は、かかる関数ｆ（ｘ）上の任意の４点を、割符５１Ａ〜５１Ｄとして引数を返す。
【００１８】
このとき、割符５１Ａ〜５１Ｄは何れもバラバラで単体では情報を持たない単なる数字であるが、『与えられた３つあるいは４つの点を全て通る次数２の関数』であることが分かっていれば、その関数ｆ（ｘ）は一意に求められる。このように関数ｆ（ｘ）がわかると、ｆ（ｘ＝０）も明らかとなるため、秘密情報である秘密鍵５１がわかる。
秘密分散法は、このような仕組みを用いて、データ群である割符５１Ａ〜５１Ｄを用いて、秘密鍵５１を復元する。
なお、ここでは２次関数を用いているが、かかる構成に限定されるものではなく、閾値の数より１だけ小さい次数を持つ関数であれば良い。ただし、５次以上の方程式については一般に代数的には解けないため用いられない。従って、閾値の数は２以上５以下である。
【００１９】
第２ＨＳＭ３１は、このような秘密分散法を用いて割符５１Ａ〜５１Ｄを生成するとともに、そのうちの割符５１ＡをＩＣカード１０に格納する（ステップＳ１０４）。
ステップＳ１０４においてＩＣカード１０に割符５１Ａが電子データとして格納されると、保管代行業者Ｒは、ＩＣカード１０を利用者Ｐに送付して（ステップＳ１０５）、利用者Ｐの仮想通貨と、公開鍵５０とが紐づけられる。
保管代行業者Ｒはさらに、ステップＳ１０４で生成した割符５１Ｂをサービス提供者Ｑのサーバ２０へと送信し、割符５１Ｃを保管代行業者Ｒの有する割符ＤＢ３２に保管する（ステップＳ１０５）。
割符５１Ｄは、例えば割符ＤＢ３２にバックアップ用として保管される。なお、割符５１Ｄの保管場所は、かかる構成に限定されるものではなく、信頼できる第三者に送付して保管してもらうのでも良いし、利用者Ｐまたはサービス提供者Ｑが保持しても良い。
かかる割符５１Ｄは、後述するように、ＩＣカード１０を紛失した際にバックアップとして機能する冗長化割符である。
【００２０】
このようにして、利用者Ｐ、サービス提供者Ｑ、保管代行業者Ｒのそれぞれが割符５１Ａ、割符５１Ｂ、割符５１Ｃを所持した状態で、利用者Ｐが秘密鍵５１を用いて自身のデジタルアセットにアクセスする場合の処理を図４、５に示す。
【００２１】
まず、利用者Ｐが、端末１１にＩＣカード１０を挿入し、サーバ２０へと接続すると、端末１１はＩＣカード１０から割符５１Ａを読みだして第１ＨＳＭ２１へと送信する（ステップＳ２０１）。
次に、第１ＨＳＭ２１は、認証用ＤＢ２２から割符５１Ｂを受け取り、ステップＳ２０１において受け取った割符５１Ａと合成して割符５１Ａ＋Ｂを生成する（ステップＳ２０２）。
【００２２】
ステップＳ２０２で合成された割符５１Ａ＋Ｂは、管理用サーバ３０の第２ＨＳＭ３１へと送信される（ステップＳ２０３）。
第２ＨＳＭ３１は、割符ＤＢ３２から割符５１Ｃを受け取って、割符５１Ａ＋Ｂと合成する（ステップＳ２０４）。
【００２３】
このように割符５１Ａ〜Ｃを常用割符として用い、割符５１Ａ〜ＣがステップＳ２０４において合成されたことをもって、第２ＨＳＭ３１は復号した秘密鍵５１を用いて利用者Ｐの送信したトランザクションに署名を行う（ステップＳ２０５）。
すなわち第２ＨＳＭ３１は、４つの割符５１Ａ〜５１Ｄのうち、少なくとも３つが第２ＨＳＭ３１に集まったことを条件として、秘密鍵５１を復元し、秘密鍵５１を用いてトランザクションに対して署名を行う同意判定手段としての機能を有している。
かかる構成にすることで、秘密鍵５１がハードウェアセキュリティモジュール上のみで復元されるから、外部からの読取に対して強い安全性を維持することができる。
また、割符５１Ａ〜５１Ｃを常用割符として、利用者Ｐ、サービス提供者Ｑ、保管代行業者Ｒの三者に配布するから、三者の同意に基づいて、デジタルアセットの管理をすることができる。
【００２４】
ここでデジタルアセットとは例えば仮想通貨等の電子データで構成された資産を示し、デジタルアセットの管理とは、かかるデジタルアセットを使用して何らかのサービスを受けたり、決済を行ったりする行為を指す。
すなわち、本実施形態では、管理システム１００は、『デジタルアセットのアクセスによって決済が承認される承認手段を有し、デジタルアセットを用いた支払い決済を行う』構成を有している。このとき、第２ＨＳＭ３１の署名によって、デジタルアセットのアクセスが承認されるから、第２ＨＳＭ３１は、承認手段としての機能を有している。
【００２５】
また、かかる構成において、かりに何れかの常用割符５１Ａ、５１Ｂ、５１Ｃのうち１つが紛失したり、盗難されてしまった場合であっても、秘密鍵５１を復号するには閾値の数以上の割符を集める必要があるため、管理システム１００は割符５１Ａ〜５１Ｃの紛失や盗難に対して強固なセキュリティを持つ。
【００２６】
ところで、従来の仮想通貨取引においては、仮想通貨の所謂ウォレットと秘密鍵とが関連付けて保管されている。そのため秘密鍵管理においては図６に示すように、利用者Ｐ’が自身の秘密鍵５１’を管理し、トランザクションに署名を行うことで自身の行う決済や移転の同意をするのが一般的であった。
しかしながら、例えば従来の銀行ＡＴＭ等のように、秘密鍵５１’をＩＣカード１０’に格納して運搬するような形態をとると、ＩＣカード１０’の不正な読取や、紛失、盗難等が生じたとき、利用者Ｐ’もサービス提供者Ｑ’も、自身のデジタルアセットをいかなる手段でも取り返すことが困難であるという問題が生じていた。
このような問題点を解決するために、トランザクションに複数の署名で承認を行う、所謂マルチシグ等の方法が考えられているが、利用者Ｐ’、サービス提供者Ｑ’、それぞれの署名を必要とするから、何れか１方が失われてしまうと、やはり自身のデジタルアセットの移動が不可能になってしまうという困難性がある。そのため、例えば秘密鍵５１’を可搬性のあるＩＣカード１０’に格納するような用途には向かなかった。
【００２７】
他方、管理システム１００において、例えばＩＣカード１０を紛失した場合を考える。
本実施形態において既に述べたように、ＩＣカード１０内部に格納された割符５１Ａは、それ単体では署名を行うことは不可能である。
また、割符５１Ａから秘密鍵５１を復号するためには、割符５１Ｂ、割符５１Ｃが必要となるから、かりに割符５１Ａが流出してしまったとしても、利用者Ｐのデジタルアセットは守られた状態が維持される。
【００２８】
従って、本実施形態ではＩＣカード１０をかりに紛失したとしても、利用者Ｐから速やかにサービス提供者Ｑに連絡をし、かかる割符５１Ａを使用不可能にするとともに、冗長化割符５１Ｄを用いて、割符５１Ｂ、５１Ｃ、冗長化割符５１Ｄの３つから、デジタルアセットの管理が可能となるように構成されている。
具体的には、利用者Ｐからの連絡を受けたサービス提供者Ｑが、管理用サーバ３０にアクセスし、再度ステップＳ１０１〜Ｓ１０５のように手続きを進めることで、割符の再発行を容易に行うことができる。
また、このとき、新たに生成された鍵ペアを公開鍵６０と秘密鍵６１とし、図７に示すように秘密鍵６１の割符６１Ａ〜６１Ｄとすれば、秘密鍵６１に利用者Ｐのデジタルアセットを紐づけるときには、割符５１Ｂ〜５１Ｄを用いて旧秘密鍵５１を復号し、旧秘密鍵５１と紐づいたウォレットから秘密鍵６１と紐づいた新たなウォレットへのトランザクションを旧秘密鍵５１を用いて署名すれば良い。
【００２９】
あるいは、同じ秘密鍵５１に対して異なる関数ｇ（ｘ）を用いて新たな割符５１Ｅ、５１Ｆ、５１Ｇ、５１Ｈを設けるとしても良い。
このように同一の秘密鍵に対して異なる関数を用いることとすれば、デジタルアセットの移転が必要ではなくなるというメリットがあるが、セキュリティ向上の観点からすると、異なる秘密鍵に異なる関数を用いた方が好ましい。
【００３０】
すなわち、本実施形態では、第２ＨＳＭ３１は『デジタルアセットにアクセスするための秘密鍵５１を秘密分散法を用いて少なくとも４つの割符に分割する割符生成手段と、割符５１Ａ〜５１Ｄのうち、所定の閾値の数３以上の割符が集まったことを条件として利用者Ｐのアクセスを正当なものとみなすための同意判定手段と』を有している。
また、管理システム１００において、『割符５１Ａ〜５１Ｄは、少なくとも３つが常用割符として利用者Ｐとサービス提供者Ｑと保管代行業者Ｒとのそれぞれに分配され、割符の数と閾値の数との差分の数が冗長化割符として保管される』。
かかる構成により、冗長化割符５１Ｄがあることで、常用割符５１Ａがかりに失われてしまったときにも、利用者Ｐのデジタルアセットを失うことなく、新たな割符６１Ａ〜６１Ｄを容易に再発行することができる。
【００３１】
また、本実施形態では、『割符生成手段は、ハードウェアセキュリティモジュール上で割符５１Ａ〜５１Ｄの生成を行うとともに、割符のうち１つを利用者Ｐに送付されるＩＣカード１０に格納する』構成を有している。
かかる構成により、利用者Ｐは、ＩＣカード１０を持ち歩くことで、端末１１を経由してサーバ２０に接続することで容易に自身のデジタルアセットにアクセスすることが可能となる。
【００３２】
また本実施形態では、『デジタルアセットの移転はブロックチェーン技術を用いたトランザクションとして記録され、同意判定手段がアクセスを正当なものとみなしたことを条件として、トランザクションに署名が行われる』構成を有している。
かかる構成によれば、利用者Ｐは、自身の仮想通貨用のウォレットから、仮想通貨の支払いを簡易に行うことができるから、仮想通貨の利便性が向上する。
【００３３】
さらに、第１の実施形態の応用例として、図８に第２の実施形態を説明する。
第２の実施形態においては、第１の実施形態で生成された冗長化割符５１Ｄまたは割符５１Ｃを、更に秘密分散法を用いて割符を生成する。
図８に示すように、割符生成手段たる第３ＨＳＭ９１が、かかる冗長化割符５１Ｄの割符として、割符９１Ａ〜９１Ｄを生成する。
かかる割符９１Ａ〜９１Ｃを、ハードウェアセキュリティモジュール上で合成することによって、割符５１Ｄを取り出すことができるようになるとすれば、例えば割符９１Ａ〜９１Ｄを図示しないそれぞれ異なるデータセンター９２Ａ〜９２Ｄで保管することで、リスク分散を行うことができる。
このように、割符を受け取ったものが更に割符を生成する割符生成手段として機能することで、セキュリティを維持しつつも災害などによるデータセンターの物理的破損についてのリスク分散を行うことができる。
【００３４】
このように、第２の実施形態における管理システム１００は、『秘密情報を導出する秘密情報生成手段』でありかつ『前記秘密情報に基づいて複数の割符を生成し、当該割符の少なくとも１つを送付する割符生成手段』としてのハードウェアセキュリティモジュールたる第２ＨＳＭ３１と、『前記割符を送付する際に当該割符を非活性化する非活性化手段』としての第３ＨＳＭ９１とを有している。
かかる構成において、非活性化手段は割符５１Ｄを更に割符９１Ａ〜９１Ｄへと変換することで、単体では秘密情報である秘密鍵５１を復号できなくする、すなわち割符の非活性化を行っている。このように、秘密鍵５１の割符５１Ａ〜Ｄを更にそれ単体では用いることができないようにすることを、『非活性化』と称している。また、本実施形態における第３ＨＳＭ９１は何所に置かれていても良い。また、第１ＨＳＭ２１や第２ＨＳＭ３１が非活性手段として、割符５１Ａ〜５１Ｄの何れかあるいは複数を分割して割符化する構成であっても良い。
【００３５】
なお、非活性化手段はかかる構成に限定されるものではなく、例えば図９に示すように、秘密鍵５１から２つの割符５１Ａ、５１Ｂを生成したあと、割符５１Ａを更に割符５１ａ、５１ｂへと分割して、利用者Ｐとサービス提供者Ｑへとそれぞれ送付することとしても良い。
このような場合には、第１ＨＳＭ２１は、割符５１ａと割符５１ｂとを用いて割符５１Ａを復元し、かかる割符５１Ａを第２ＨＳＭ３１へと送付する。
第２ＨＳＭ３１は、割符５１Ａと割符５１Ｂとを用いて秘密情報である秘密鍵５１を復号化することができる。
【００３６】
また、このように割符を割符化することのみならず、例えば利用者Ｐの端末１１の公開鍵暗号を用いた暗号化によって非活性化するとすれば、利用者Ｐの端末１１の秘密鍵によってのみ復号化できるので、よりセキュリティが向上する。このように『非活性化』は暗号化や割符化等を含み、かかる暗号化に用いる鍵は、公開鍵暗号方式における公開鍵や秘密鍵の他、任意の共通鍵を用いても良い。
このような非活性化手段を用いることによれば、鍵が外部には露出せずに鍵生成手段から非活性化した状態で送付されるから、より安全に割符のやり取りを行うことが可能となる。
【００３７】
また、第１、第２の実施形態においては、何れも認証用ＤＢ２２、割符用ＤＢ３２、をそれぞれサービス提供者Ｑ、保管代行業者Ｒがそれぞれ管理するサーバーであるとしたが、かかる構成に限定されるものではない。
例えば、図１０に示すように、外部の認証システム２３と、認証システム２３からの認証に基づいてユーザーが正当なものであると認可する認可システム２４Ｑ、２４Ｒとを有し、かかる認可システム２４Ｑ、２４Ｒからの認可に基づいてそれぞれの所持する割符５１Ｂ、５１Ｃを送信する構成であっても良い。また、認可システム２４Ｑ、２４Ｒは別体であっても同一のシステムであっても良い。
【００３８】
以上本発明の好ましい実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、上述の説明で特に限定していない限り、特許請求の範囲に記載された本発明の趣旨の範囲内において、種々の変形・変更が可能である。
【００３９】
例えば、本実施形態では、常用割符５１Ａ〜５１Ｃを３つ、冗長化割符を１つの構成について説明したが、全体の割符の数を３として、常用割符を２つ、冗長化割符を１つとする構成であっても良い。
【００４０】
本発明の実施の形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施の形態に記載されたものに限定されるものではない。
【符号の説明】
【００４１】
１０        ＩＣカード
１１        端末
２０        サーバ
２１        同意判定手段（第１ＨＳＭ）
２２        認証用ＤＢ
３０        管理用サーバ
３１        同意判定手段、割符生成手段（第２ＨＳＭ）
３２        割符ＤＢ
１００      管理システム
２００      管理システム
Ｐ          利用者
Ｑ          サービス提供者
Ｒ          保管代行業者
【図１】
2020058008.tif 000003
【図２】
2020058008.tif 000004
【図３】
2020058008.tif 000005
【図４】
2020058008.tif 000006
【図５】
2020058008.tif 000007
【図６】
2020058008.tif 000008
【図７】
2020058008.tif 000009
【図８】
2020058008.tif 000010
【図９】
2020058008.tif 000011
【図１０】
2020058008.tif 000012