電子的価値情報管理サーバ及び電子的価値情報送受信方法
【課題】二重使用を防止し、紛失したとしても復旧が可能であり、専用のＩＣカードやソフトウェアなど特別な装置を用いなくても流通が可能な電子的な価値情報を管理するサーバ装置などを提供する。
【解決手段】管理サーバのデータベースにおいて価値と関連付けられている照合用情報を含む管理データと利用者の識別情報とをデータベースにより関連づける代理サーバと、利用者の利用者端末と、利用者から購入の申込を受けるショップサーバと、管理データ含む照合用情報に関連付けられている価値の移動を行う保管サーバを有する決済システムを提供する。
【解決手段】管理サーバのデータベースにおいて価値と関連付けられている照合用情報を含む管理データと利用者の識別情報とをデータベースにより関連づける代理サーバと、利用者の利用者端末と、利用者から購入の申込を受けるショップサーバと、管理データ含む照合用情報に関連付けられている価値の移動を行う保管サーバを有する決済システムを提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子マネーの決済、電子マネーやその他の電子的な価値情報の譲渡などの処理を行う処理装置、電子的な価値情報の処理方法などに関する。
【背景技術】
【０００２】
電子マネーやその他の電子的な価値情報は、ビット列などの情報に貨幣などの価値が関連付けられている。そのビット列などの情報の交換により決済などの価値の譲渡が実現される。そして、電子マネーは急速に普及しつつあり、交通機関の改札での運賃の支払いや店舗での商品の代金の決済の手段として用いられている。
【０００３】
ところで、電子マネーやその他の電子的な価値情報に関する技術については、ビット列などの情報は容易に複製されてしまうので、複製後に二重に使用されたことを検出する方法を備える必要がある（例えば、特許文献１参照。）。また、一般的に電子マネーは無記名であり、また、実際の貨幣とは異なり無体物であるため、紛失してしまった場合に被害が甚大となる可能性がある。そこで紛失などに備える必要がある（例えば、特許文献２参照。）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許４，９７７，５９５号明細書
【特許文献２】特開２００７−３１０５６２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１及び特許文献２に開示された技術に限らず、従来は、電子マネー等には暗号理論の利用が不可欠であると考えられている。暗号理論を用いることにより二重使用や紛失などの対策を取ろうとしている。このため、電子マネー等を利用するためには、利用者は特殊なＩＣカードやソフトウェア等を使用する必要があり、店舗などでは、そのＩＣカード等の読取り装置を備える必要がある。このため、電子マネー等の普及には莫大なコストが必要となる。また、個人間などの一般の利用者間での電子マネー等の譲渡も困難である。また、利用者は常にＩＣカードなどを所持する必要があり、紛失などの危険がある。
【課題を解決するための手段】
【０００６】
そこで、本発明では、二重使用を防止し、紛失したとしても復旧が可能であり、専用のＩＣカードやソフトウェアなど特別な装置を用いなくても譲渡が可能な電子的な価値情報を管理するサーバ装置などを提供する。
【０００７】
本発明の一実施形態として、管理サーバのデータベースにおいて価値と関連付けられている照合用情報を含む管理データと利用者の識別情報とをデータベースにより関連づける代理サーバと、利用者の利用者端末と、利用者から購入の申込を受けるショップサーバと、管理データを含む照合用情報に関連付けられている価値の移動を行う保管サーバを有する決済システムを提供する。
【０００８】
さらに、本発明の一実施形態として、管理サーバのデータベースにおいて価値と関連付けられている照合用情報を含む管理データと利用者の識別情報とをデータベースにより関連づける代理サーバと、利用者の利用者端末と、利用者から購入の申込を受けるショップサーバと、管理データを含む照合用情報に関連付けられている価値の移動を行う保管サーバの動作方法を提供する。
【発明の効果】
【０００９】
本発明の一実施形態により、二重使用を防止し、紛失したとしても復旧が可能であり、専用のＩＣカードやソフトウェアなど特別な装置を用いなくても流通が可能な電子的な価値情報の利用などを提供できる。また、特別な装置を用いる必要がないので、利用者は、ウェブサーバを介して決済処理を従来の技術よりも簡単に行うことができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の一実施形態に係る管理サーバの機能ブロック図である。
【図２】本発明の一実施形態における管理データ発行の具体例を説明する図である。
【図３】本発明の一実施形態に係る管理サーバの処理のフローチャートである。
【図４】本発明の一実施形態における照合用データの書き換えの具体例を説明する図である。
【図５】本発明の一実施形態に係る管理サーバの処理のフローチャートである。
【図６】本発明の一実施形態に係る管理サーバ、入金サーバ、保管サーバ及び利用者端末からなるシステム構成図である。
【図７】本発明の一実施形態に係る管理サーバ、入金サーバ、保管サーバ及び利用者端末からなるシステムによる処理のシーケンス図である。
【図８】本発明の一実施形態に係る保管サーバの機能ブロック図である。
【図９】本発明の一実施形態における管理データを保管するためのテーブルの一例図である。
【図１０】本発明の一実施形態における保管データ発行の具体例を説明する図である。
【図１１】本発明の一実施形態における保管データ発行の具体例を説明する図である。
【図１２】本発明の一実施形態に係る利用者間で管理データを譲渡するシステムの構成図である。
【図１３】本発明の一実施形態に係る利用者間で管理データを譲渡するシステムによる処理のシーケンス図である。
【図１４】本発明の一実施形態に係る利用者間で管理データを譲渡するシステムによる処理のシーケンス図である。
【図１５】本発明の一実施形態に係る代理サーバとショップサーバとの間で管理データを交換するシステムの概要を示す図である。
【図１６】本発明の一実施形態に係る代理サーバとショップサーバとの間で管理データを交換するシステムの構成図である。
【図１７】本発明の一実施形態に係る代理サーバ及び利用者端末の機能ブロック図である。
【図１８】本発明の一実施形態に係る代理サーバが有するテーブル構成の一例を示す図である。
【図１９】本発明の一実施形態に係る代理サーバとショップサーバとの間で管理データを交換するシステムによる処理のシーケンス図である。
【図２０】本発明の一実施形態に係る管理データを用いた支払処理における代理サーバの処理の流れを説明するフローチャートである。
【図２１】本発明の一実施形態に係る管理データの発行処理を説明するためのシーケンス図である。
【図２２】本発明の一実施形態に係る管理データの発行処理における入金サーバの処理の流れを説明するフローチャートである。
【図２３】本発明の一実施形態における利用者端末の画面表示を示す図である。
【図２４】本発明の一実施形態における利用者端末の画面表示を示す図である。
【図２５】本発明の一実施形態における利用者端末の画面表示を示す図である。
【図２６】本発明の一実施形態に係る利用者によるユーザ登録処理を説明するためのシーケンス図である。
【図２７】本発明の一実施形態における利用者端末の画面表示を示す図である。
【図２８】本発明の一実施形態における商品などの購入の申込を行うための画面の一例図である。
【図２９】本発明の一実施形態に係るショップサーバの構成図である
【発明を実施するための形態】
【００１１】
以下、本発明を実施するための最良の形態について実施形態として図を参照しつつ説明を行う。なお、本発明は以下の実施形態に限定されるものではなく、その要旨を逸脱しない範囲において種々なる態様で実施することができる。
【００１２】
（実施形態１）
（管理サーバ）
本発明の一実施形態において、管理サーバとは、電子的な価値情報の譲渡処理を主に行うサーバ装置である。管理サーバが行うその他の処理としては、管理サーバとして必須の処理ではないが、電子的な価値情報の発行処理、発行した電子マネー等に関連付けられた価値を貨幣などとして払い戻す処理などがある。
【００１３】
図１は、本発明の一実施形態に係る管理サーバの機能ブロック図を例示する。管理サーバ１００は、データベース部１０１と、発行要求受信部１０２と、生成部１０３と、生成管理データ送信部１０４と、管理データ受信部１０５と、置換部１０６と、置換管理データ送信部１０７とを有する。なお、管理サーバ１００の実現の一態様としては、コンピュータにソフトウェアを読み込ませ、ソフトウェアとハードウェア資源とが協働した具体的手段によって、使用目的に応じた情報の演算又は加工を実現することにより、使用目的に応じた特有の情報処理装置とするものがある。このような実現は、本発明の以下の説明に接した当業者により理解される。
【００１４】
データベース部１０１は、電子的な価値情報と価値との関連付けを管理する。本発明の一実施形態においては、電子的な価値情報は管理サーバ１００により管理などされるデータであるので、「電子的な価値情報」という用語のかわりに「管理データ」という用語を用いる。そして、本発明の一実施形態においては、管理データは照合用データを含み、この照合用データが価値そのものあるいは価値を表す情報と関連付けられる。また、照合用データは他の情報とも関連付けることができる。
【００１５】
照合用データと関連付けることができる他の情報としては、例えば、その照合用データを含む管理データの譲渡が行われた回数（譲渡回数）、その照合用データを含む管理データが、どの利用者やどの利用者の端末装置などに対して発行されたかを示す利用者や端末装置などの識別情報などが挙げられ、これらは必要に応じてデータベース部１０１に格納されてもよい。
【００１６】
また、管理データは、照合用データに加えて、管理データの所持者の識別情報や管理データの所持者の識別情報を含んでいてもよい。あるいは、管理データは、それらの識別情報のハッシュ情報を含んでいてもよい。このような情報を含ませることにより、管理情報の不正な使用を防止することができる。
【００１７】
本発明の一実施形態においては、図２（ａ）に示すように、照合用データが格納される列と価値の情報が格納される列とを有し、照合用データと価値の情報とを関連付けるテーブルを用意する。このテーブルは、関係データベースシステムなどの表データとしてデータベース部１０１によって管理される。なお、価値の情報を単に「価値情報」という場合がある。
【００１８】
照合用データは、充分に長いビット長の乱数として生成されるデータである。「充分に長い」とは、発行される管理データの中で同じ照合用データを有するものが存在しない、あるいは、実質的に存在しないことを意味する。例えば、１２８ビット、５１２ビット、１０２４ビット、２０４８ビットなど設計上などの必要に応じて任意の長さを決めることができる。
【００１９】
価値情報は、照合用データを含む管理データが表すことになる価値の内容などを示す。具体的な例としては、貨幣により表される価値を示す。この場合、価値の単位は、円、ドル、ユーロ、元などである。また、価値の情報は、貨幣と同等の価値を有する有価証券の証券番号、貴金属の量や保管の番号などであってもよい。また、運営者が独自に発行する価値を表わすポイント数などであってもよい。
【００２０】
発行要求受信部１０２は、管理データ発行要求１０８を受信する。管理データ発行要求１０８は、なんらかの価値が管理サーバやその運営者などに移転されたことあるいは移転されることを示す情報である。このため、管理データ発行要求１０８は、管理サーバ１００の運営者の支配する領域の内部で生成されたり、運営者と特別な関係（例えば親会社子会社の関係や特別な契約関係）にある者から送信されたりするのが好ましい。
【００２１】
図２（ｂ）は、管理データ発行要求の具体的な例を示す。この例では、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）による表現がされている。管理データ発行要求はＸＭＬ以外にも種々の表現形式があるが、以下では、ＸＭＬを例にして説明を行う。図２（ｂ）では、＜価値＞と＜／価値＞とで囲まれている１０００円が、発行される管理データが表すべき価値となっている。発行要求受信部１０２が、このような管理データ発行要求を受信する際には、管理データ発行要求の送信者の認証を行い、受信した管理データ発行要求をメモリに展開して正しい構文であるかどうかの確認を行い、＜価値＞と＜／価値＞とで囲まれている部分を特定して、次に説明する生成部１０３に伝達する。伝達は、例えば、生成部１０３を実現するソフトウェアモジュールなどの関数の引数に＜価値＞と＜／価値＞とで囲まれている部分のメモリアドレスを価値の情報として引数に指定するなどしてその関数を呼び出すことで行われる。
【００２２】
なお、管理データ発行要求には、照合用データと関連付けることができる他の情報が必要に応じて含まれていてもよい。
【００２３】
生成部１０３は、照合用データを準備し、準備された照合用データと発行要求受信部１０２から伝達された価値の情報とを、データベース部１０１で管理される図２（ａ）のテーブルに行データとして挿入する。「照合用データを準備する」とは、乱数を生成してその乱数を照合用データとすること、又は、予め生成しておいた乱数のリストなどから乱数を選択して照合用データとすることをいう。挿入が完了すると、生成部１０３は、生成管理データ送信部１０４へ、照合用データを伝達する。なお価値の情報も伝達されてもよい。
【００２４】
図２（ｃ）は、照合用データとして“１３５７１１”が準備されて、“１３５７１１”と１０００円とを図２（ａ）に示されるテーブルに挿入した直後の状態を示している。挿入が行われると、“１３５７１１”という照合用データが生成管理データ送信部１０４へ伝達される。
【００２５】
生成管理データ送信部１０４は、生成部１０３から伝達された照合用データから管理データ１０９を生成して送信する。管理データ１０９の送信先は、管理データ発行要求１０８を送信した装置であることが主に想定される。もし、管理データ発行要求１０８に、管理データ１０９の送信先が、電子メールアドレスやＩＰアドレスなどによって指定されていれば、その送信先へ管理データ１０９が送信される。送信は暗号化されて行われてもよい。
【００２６】
図２（ｄ）は、生成管理データ送信部１０４で生成され送信される管理データの一例を示す。生成部１０３から照合用データとして“１３５７１１”が伝達されたとすれば、“＜管理データ＞＜照合用データ＞１３５７１１＜／照合用データ＞＜／管理データ＞”という管理データが生成され、インターネットなどのネットワークなどに送信される。なお管理データには、上述したように、照合用データ以外のデータが含まれていてもよい。上述した例以外の例としては、照合用データがどれだけの価値、例えばいくらの貨幣価値、に関連付けられているかを示す情報が含まれていてもよい。例えば、管理データが“＜管理データ＞＜照合用データ＞１３５７１１＜／照合用データ＞＜価値＞１０００円＜／価値＞＜／管理データ＞”のように貨幣価値などを含むようになっていてもよい。また、照合用データと関連付けることができる他の情報が含まれていてもよい。また、譲渡回数が管理データに含まれる場合には、０などの初期値にリセットが行われて送信がされる。さらに、管理データが管理サーバ１００により生成されたことを検証できるようにするために、照合用データなどに対する管理サーバ１００による署名データが含まれていてもよい。
【００２７】
なお、価値として、貨幣価値のように可分な価値が用いられる場合には、管理データが表す価値に上限を設けてもよい。例えば、一つの管理データは、５０００円までの貨幣価値を表すことにする。そして、５０００円以上の価値を表す管理データは、複数の管理データを組み合わせることによって表す。このように管理データが表す価値に上限を設けることにより、管理データを紛失したときに生じる損失が大きくならないようにすることができる。この上限の値は、管理サーバ１００に設定され、生成管理データ送信部１０４が上限を超える価値と関連付けられた管理データを生成しないようにする。また後に管理データの数の増大を防止するために、管理データの価値を譲受ける側も管理データを保管サーバと呼ばれるサーバに提示することが開示される。この場合においても、管理データの価値を譲受ける側も管理データに上限の値を越える価値が関連付けられないように、管理サーバが動作することになる。
【００２８】
管理データが表す価値に上限を設ける場合には、管理データ発行要求がその上限を越える価値の管理データを発行することを表している場合には、上限以下の価値を表す管理データを複数発行する。このため、図２（ａ）などに示すテーブルに複数の行データが挿入される。
【００２９】
図３は、データベース部１０１、発行要求受信部１０２、生成部１０３、生成管理データ送信部１０４による処理の流れを説明するフローチャートを例示する。このフローチャートが例示する処理は、ハードウェアを制御可能なソフトウェアによる情報処理として実行可能である。
【００３０】
ステップＳ３０１の処理として、発行要求受信部１０２により管理データ発行要求を受信する。例えば、ハードウェアとしてのネットワークアダプタがデータを受信し割り込みが発生すると、割り込みハンドラが呼ばれて、データを読取り、読取りデータキューに入れる。そして、発行要求受信部１０２を実現するモジュールなどが発行していたＲＥＡＤシステムコールなどから処理が戻り、読取りデータキューに入れられたデータを管理データ発行要求としてメモリに展開する。
【００３１】
ステップＳ３０２の処理として、発行要求受信部１０２は、メモリに展開された管理データ発行要求から価値の情報のアドレスを特定などすることにより、価値の情報を取得する。取得された価値の情報は生成部１０３へ伝達される。
【００３２】
ステップＳ３０３の処理として、生成部１０３が照合用データを準備する。そしてステップＳ３０４の処理として、生成部１０３は、準備した照合用データと伝達された価値の情報を関連付けてテーブルに挿入して格納する。照合用データは生成管理データ送信部１０４へ伝達される。なお、「照合用データを準備する」とは、照合用データを生成したり、あらかじめ生成した照合用データの集合から取り出すことをいう。また、照合用データを準備するさいには、過去に準備された照合用データが準備されないのが好ましい。また、次に準備される照合用データの値が第三者から予測が困難であることが好ましい。このため、照合用データは乱数として準備されるのが好ましい。
【００３３】
ステップＳ３０５の処理として、生成管理データ送信部１０４は、伝達された照合用データから管理データを生成する。そして、ステップＳ３０６の処理として、ＷＲＩＴＥシステムコールなどを発行することにより、生成された管理データを送信する。ＷＲＩＴＥシステムコールなどの発行により、管理データが送信データキューに格納され、ネットワークアダプタがデータを送信可能な状態になると、割り込みが発生し、割り込みハンドラにより、送信データキューのデータが読み出されて、ネットワークなどに送信される。
【００３４】
このようにして送信された管理データは、専用のＩＣカードなどに限らず、通常のパーソナルコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）や携帯電話などのメモリに格納することができる。また、後述するように、ウェブサーバに格納し、利用者がそのウェブサーバに支払の命令などを送信することにより、使用することが可能となる。あるいは、フレキシブルディスク、光ディスク、不揮発性の半導体メモリなどの着脱可能な一般的な記憶媒体に記録することができる。そして、その記憶媒体を譲渡することにより、その記憶媒体に格納されている管理データが表す価値の譲渡を行うことができる。ただし、二重の譲渡を防止するために以下に説明するようにして譲渡するのが望ましい。
【００３５】
管理データ受信部１０５は、譲渡の対象などとなる管理データ１１０を受信する。受信された管理データ１１０は、管理サーバ１００のメモリに展開される。そして、管理データ１１０に署名データなどが含まれていれば、その署名データが正しいかどうかを判断してもよい。
【００３６】
置換部１０６は、管理データ受信部１０５で受信された管理データから照合用データを取得し、まず、その照合用データがデータベース部１０１で管理されているテーブルに格納されているかどうかを判断する。例えば、図２（ｃ）に示されるテーブルの照合用データの列に格納されているかどうかを判断する。もし、その照合用データが格納されていなければ、管理データ１１０の送信者などに、無効な照合用データを含む管理データが送信された旨を返信などする。反対に、その照合用データがデータベース部１０１で管理されているテーブルに格納されていれば、有効な照合用データを含む管理データであると判断する。有効な照合用データを含めば、新たな照合用データを準備し、この照合用データにより、管理データ１１０に含まれる照合用データとデータベース部１０１で管理されているテーブルに格納されている照合用データを置き換える。これにより、価値の情報に新たな照合用データが関連付けされる。
【００３７】
また、照合用データと関連付けられている他の情報があれば、その情報を用いてさらにチェックを行ってもよい。例えば、上述したように、利用者や端末の識別情報が照合用データと関連付けられていれば、管理データを管理データ受信部１０５に受信させた利用者や端末装置の識別情報を取得し、比較を行う。比較の結果がＯＫでなければ、無効である旨の返信などを行う。比較の結果がＯＫであれば、照合用データと関連付けられている識別情報と管理データに含まれている識別情報を、次に説明する置換管理データ送信部１０７による管理データの送信先となる利用者や端末装置の識別情報に書き換える。
【００３８】
管理データに譲渡回数が含まれている場合には、譲渡回数を更新する。また、更新前の譲渡回数が初期値を示していれば、置き換え前の照合用データがデータベース部１０１で管理されているテーブルに格納されているかどうかに加えて、照合用データと関連付けられている他の情報を用いたチェックを行ってもよい。例えば、その管理データを発行した際に受信された管理データ発行要求が存在するかどうかを管理サーバのログによりチェックを行ったり、実際に銀行などから金銭の振り込みが実際に行われたかどうかを銀行などのサーバ装置に問い合せたりしてもよい。もちろん、このようなチェックや問い合わせの処理は、管理データが管理サーバ１００に受信されるたびに行ってもよい。しかし、一般には、このようなチェックや問い合せの処理には時間が要する。そこで、このようなチェックや問い合せの処理の実行は、更新前の譲渡回数が初期値を示していたり、所定の値以下であったり、所定の値以上である場合に行うことに限ることで、処理の時間を短縮することが可能となる。また、異なるサーバに格納されたデータと照合を行うことにより、管理データの不正な作出などを検出することができる。
【００３９】
置換管理データ送信部１０７は、置換部１０６により、新たに準備された照合用データによりその照合用データが置換された管理データ１１１を送信する。管理データ１１１の送信は、管理データ１１０の送信元に対して行ってもよい。あるいは管理データ１１０の受信とともに送信先を示す情報が受信されたり、あるいは、管理データ１１０の中に送信先を示す情報が含まれていたりすれば、その送信先へ管理データ１１１を送信するようになっていてもよい。
【００４０】
例えば、データベース部１０１で管理されているテーブルに、図４（ａ）に示すように、照合用データとして“１３１７１９２”が９９５円という価値の情報と関連付けられて格納されているとする。この状態で、管理データ１１０として、図４（ｂ）に示すような照合用データとして“１３１７１９２”を含む管理データ１１０が管理データ受信部１０５により受信されたとする。すると、管理データ１１０に含まれる照合用データ“１３１７１９２”は、図４（ａ）のテーブルに格納されているので、管理データ１１０は有効な照合用データを含む管理データであると判断される。そこで、置換部は、新たな照合用データとして、例えば“１４９１６２５”を準備する。そして、この照合用データにより、図４（ａ）に示すテーブルの照合用データ“１３１７１９２”と図４（ｂ）に示す管理データに含まれる照合用データ“１３１７１９２”とを置き換える。この結果、図４（ａ）に示すテーブルは図４（ｃ）に示すようになり、図４（ｂ）に示す管理データ１１０は図４（ｄ）に示すようになる。この結果、図４（ｄ）に示す管理データが管理データ１１１として送信される。
【００４１】
なお、照合用データを置き換える際に、照合用データに関連付けられている価値情報の表す金額などのうち一定の額や一定の割合を控除するようにしてもよい。このように控除を行うことにより、管理サーバの運営者が管理サーバの運営などのための費用を得ることが可能となる。
【００４２】
なお、図４（ａ）に示すテーブルの照合用データの書き換えは、照合用データの列に格納されているデータに対する更新操作として実行してもよい。あるいは、書き換えの対象となる照合用データ（上の例での“１３１７１９２”）に関連付けられている価値の情報などを読出して一時的に記憶し、書き換えの対象となる照合用データを含む行を削除し、新たに準備された照合用データ（上の例での“１４９１６２５”）と一時的に記憶した価値の情報などを新たな行のデータとして格納されるようにテーブルに対するデータの挿入の操作として実行してもよい。また、更新操作として実行するのではなく、照合用データが削除されたことを示す列（削除フラグ）をテーブルに備えておき、書き換えの対象となる照合用データを格納する行の削除フラグの値を、その行が削除されたことを示す値に更新するとともに、準備された照合用データを含む行を新たにテーブルに挿入してもよい。また、テーブルに挿入される行には、書き換え前の照合用データが格納されていてもよい。これにより、不正などが発覚した場合に、書き換えの履歴をさかのぼることができる。
【００４３】
また、管理データの照合用データの書き換えは、その文言通り、メモリに展開されている管理データの部分のうち照合用データの部分を書き換えて実行してもよい。あるいは、新たに準備された照合用データを含む管理データを新たに生成してもよい。
【００４４】
図４（ｄ）に示す管理データが置換管理データ送信部１０７により送信された後、再度、図４（ｂ）に示す管理データが管理データ受信部１０５で受信されても、それに含まれる照合用データ１３１７１９２は、図４（ｃ）に示すテーブルに格納されていない（あるいは、削除フラグの列がテーブルに備わっている場合には、削除フラグの値が削除されたことを示す値になっている）。したがって、無効な照合用データを含む管理データと判断される。これにより管理データの二重使用を防止できる。
【００４５】
図５は、データベース部１０１、管理データ受信部１０５、置換部１０６、置換管理データ送信部１０７における処理の流れを説明するフローチャートを例示する。このフローチャートが例示する処理は、ソフトウェアによる情報処理として実現可能である（他の図面のフローチャート、シーケンス図により例示される処理も同様である。）。
【００４６】
ステップＳ５０１の処理として、管理データ受信部１０５により、管理データ１１０が受信される。その後、管理データ１１０がメモリに展開などされる。そして、ステップＳ５０２の処理として、置換部１０６により、メモリに展開された管理データ１１０より照合用データが取得される。取得された照合用データが、ステップＳ５０３の処理において、価値の情報と関連付けてデータベース部１０１に格納されていることを確認する。もし、格納されていなければ、管理データ１１０に無効な照合用データが含まれている旨のエラーの返信などをする。
【００４７】
ステップＳ５０４の処理として、新しい照合用データを準備する。そしてステップＳ５０５の処理として、管理データ１１０の照合用データを新しい照合用データに置き換える。「管理データ１１０の照合用データ」とは、メモリに展開された管理データ１１０に含まれる照合用データのみならず、ステップＳ５０３において価値のデータと関連付けて格納されている照合用データをも意味する。最後にステップＳ５０６の処理として、照合用データを書き換えられて得られる管理データ１１１を置換管理データ送信部１０７により送信する。
【００４８】
このように、乱数として発生された照合用データに価値を関連付け、管理データが通過するたびにその照合用データを置き換えることにより、管理サーバから送信される管理データの照合用データの予測がつかないようにすることができる。この結果、異なる照合用データに同じ価値が関連付けられることを防止でき、また、管理データの二重使用等を防止することができる。
【００４９】
（保管サーバ）
上述した管理サーバを用いることにより、乱数として発生された照合用データを含む管理データが発行され、有効な照合用データを含む管理データを送信し返信される管理データを受信することにより照合用データが書き換えられる。これにより、管理データの二重使用を防止することができる。以下では、さらに管理データの譲渡等を、匿名性を保ちながら行うために管理サーバの機能を拡張するためなどに用いられる保管サーバについて説明を行う。
【００５０】
図６は、管理サーバ６０１と、入金サーバ６０２と、保管サーバ６０３と、利用者端末６０４とからなるシステム６００の構成を示す。管理サーバ６０１と、入金サーバ６０２と、保管サーバ６０３と、利用者端末６０４とは、通信アダプタなどのハードウェアを用いて通信が可能となっている。システム６００においては、利用者端末６０４の利用者が、管理サーバ６０１で発行される管理データを得るために、利用者端末６０４と入金サーバ６０２との間で決済の処理を行う。例えば、入金サーバ６０２が銀行の振り込みを処理するサーバとなっており、利用者が管理サーバ６０１の運営者などの銀行口座に振り込みを行うことにより決済の処理が行われる。そして決済の処理が行われたことを示す結果が管理データ発行要求として入金サーバ６０２から管理サーバ６０１に送信されると、管理データが管理サーバ６０１に返信される。その後、管理データは入金サーバ６０３から保管サーバ６０３を経由して利用者端末６０４へ譲渡されてもよい。保管サーバ６０３は、管理データを入金サーバ６０２から受信すると、管理データの二重使用を防止するために、新たな照合用データに置き換えるために、管理サーバ６０１に管理データを送信し、照合用データが置き換えられた管理データを受信し保管する。その後、保管サーバ６０３は、利用者端末６０４から管理データの要求があれば、保管されている管理データを送信する。
【００５１】
もちろん、保管サーバ６０３が入金サーバ６０２を認証などして信頼できるのであれば、保管サーバ６０３は入金サーバ６０２から受信した管理データを管理サーバ６０１に送信する必要はない。しかし、もし保管サーバ６０３に送信された管理データが入金サーバ６０２内に消去されずに残り、入金サーバ６０２が不正な侵入などされてしまうと、不正に入金サーバ６０２にアクセスを行った者が管理データを入手してしまう可能性があるので、保管サーバ６０３は入金サーバ６０２から受信した管理データを管理サーバ６０１に送信するのが好ましいと言える。
【００５２】
図７は、システム６００における決済処理から管理データの利用者への譲渡までの処理の一例を説明するシーケンス図である。
【００５３】
ステップＳ７０１の処理として、利用者端末６０４と入金サーバ６０２との間で、管理データの発行のための決済の処理が行われる。例えば、利用者端末６０４よりクレジットカード番号等と決済金額を提示して、入金サーバ６０２がクレジットカード番号等の正しさを確認等する。あるいは、利用者端末６０４より銀行口座への振り込みの申込を行い、入金サーバ６０２が振込先の銀行口座番号や振込人に付加する識別文字列などを返信する。その後、振込が行われたことについての確認を入金サーバ６０２側にて行う。なお、決済処理により、利用者端末６０４から入金サーバ６０２へ利用者や利用者端末６０４の識別情報が入金サーバに伝達されてもよい。この場合、識別情報は、後に入金サーバ６０２から管理サーバ６０１へ送信される管理データ発行要求の中に含まれる。
【００５４】
本発明の一実施形態において、ステップＳ７０１の処理における決済処理を特定する番号などが決定され、この番号が入金サーバと利用者端末とで共有される。決済処理を特定する番号は、例えば、入金サーバが、生成する管理データを一意に識別する番号であったり、利用者端末６０４と入金サーバ６０２との間の通信のセッションを特定するセッションＩＤ（セッションを一意に特定するセッション識別情報）であったりしてもよい。この決済処理を特定する番号は、乱数として管理サーバが生成するのが好ましい。以下、決済処理を特定する番号として、セッションＩＤが用いられるとして説明を行う。ただし、本発明では、決済処理を特定する番号はセッションＩＤに限定されない。また、決済処理を特定する番号をＩＤ情報と称する場合がある。
【００５５】
クレジットカード番号等の正しさや振込等の確認がされると、ステップＳ７０２の処理として、入金サーバ６０２から管理サーバ６０１へ管理データ発行要求が送信される。この管理データ発行要求の中に、決済された金額などの情報が含まれる。なお、「決済された金額」は、利用者端末６０４と入金サーバ６０２との間での決済金額から所定の手数料を差し引いた額であってもよい。
【００５６】
管理データの発行要求に応じて、ステップＳ７０３の処理として、管理サーバ６０１から管理データ（「管理データ１」と呼ぶ）が入金サーバ６０２へ送信される。
【００５７】
ステップＳ７０４の処理として、入金サーバ６０２は、受信した管理データ１と上述のセッションＩＤとを保管サーバ６０３に送信する。
【００５８】
保管サーバ６０３が入金サーバより管理データ１とセッションＩＤを受信すると、ステップＳ７０５の処理として、受信した管理データを管理サーバ６０１へ送信し、管理データ１に有効な照合用データが含まれていることの確認と、その照合用データの置き換えを管理サーバ６０１に依頼する。
【００５９】
なお、管理サーバ６０１は、保管サーバ６０３より照合用データの書き換えが依頼された場合、譲渡回数は増加させない構成になっており、また、照合用データと関連付けられている識別情報と管理データに含まれている識別情報を書き換えない構成となっているとよい。例えば、保管サーバ６０３のＩＰアドレスが管理サーバ６０１に登録されており、登録されているＩＰアドレスから管理データを受信した場合には、譲渡回数を増加させず、識別情報も書き換えない構成となっていてもよい。
【００６０】
ステップＳ７０６の処理として、管理サーバ６０１にて、管理データ１に有効な照合用データが含まれていることを確認して照合用データを書き換えた管理データ２を生成し、保管サーバ６０３に返信される。そして、保管サーバ６０３にて、その管理データ２がセッションＩＤに関連付けて記憶される。
【００６１】
管理データ２がセッションＩＤに関連付けて記憶されたことを通知するために、ステップＳ７０７の処理として、保管通知が保管サーバ６０３から入金サーバ６０２へ送信される。
【００６２】
入金サーバ６０２が保管通知を受信すると、ステップＳ７０８の処理として、利用者端末６０４へ寄託通知が送信され、管理データが保管サーバ６０３に保管されたことが利用者に伝えられる。
【００６３】
その後、利用者は、利用者端末６０４を操作して、保管サーバ６０３に保管された管理データを要求するために、ステップＳ７０９の処理として、保管サーバ６０３に対して、管理データの送信要求として、セッションＩＤを送信してもよい。保管サーバ６０３では、セッションＩＤに管理データ２が関連付けて記憶されていることを確認すると、ステップＳ７１０の処理として、管理データ２を返信し、セッションＩＤとの関連付けを破棄してもよい。
【００６４】
もちろん、図６と図７とに示される構成、処理などを用いなくても、管理データを利用者に発行することができる。例えば、入金サーバが管理サーバから管理データを受信し、直接その管理データを利用者端末へ送信するようにしてもよい。しかし、決済手段として銀行振込を採用した場合などには、決済の確認までタイムラグが生じるので、入金サーバは管理サーバから受信した管理データを次に利用者端末と通信可能になるまで保持しておく必要がある。しかしこれでは、どの管理データが誰に発行されたかの情報を入金サーバが知ることとなり、匿名性が損なわれる。
【００６５】
また、入金サーバが管理データの発行要求とともに管理データの送信先を管理サーバに送信し、管理サーバがその送信先に発行した管理データを送信する構成を採用することもできる。しかし、これでも、管理データが誰に発行されたかの情報を管理サーバが知ることとなり、やはり匿名性が損なわれる。
【００６６】
図６と図７とに示される構成、処理では、管理サーバ６０１は、どの利用者の利用者端末に対して管理データを発行して送信するか知る必要がなくなる。また、入金サーバ６０２は利用者端末６０４と管理サーバ６０１から送信される管理データを関連付けることはできるが、それは一時的なものに過ぎない。管理データを保管サーバ６０３に送信すると、保管サーバ６０３側で照合用データが書き換えられてしまうからである。また、保管サーバ６０３は、管理データを入金サーバ６０２と利用者端末６０４との通信セッションにより決まる情報と関連付けるので、利用者を識別する必要がない。
【００６７】
図８は、保管サーバ６０３の機能ブロック図を示す。図８の機能ブロック図において、保管サーバ８００は、預管理データ受信部８０１と、管理データ送信部８０２と、管理データ受信部８０３と、保管部８０４と、ＩＤ受信部８０５と、預管理データ送信部８０６と、命令部８１１とを有する。
【００６８】
預管理データ受信部８０１は、管理データ８０７とＩＤ８０８とを受信する。管理データ８０７とＩＤ８０８とは、図７のステップＳ７０４においての説明での入金サーバから保管サーバへ送信される管理データ１とセッションＩＤとに相当する。ただし、後に説明されるように、預管理データ受信部８０１は、管理データ８０７とＩＤ８０８を入金サーバのみより受信するとは限らない。
【００６９】
ＩＤ８０８は、管理データ８０７を一意に特定する情報であることが望ましい。このため、預管理データ受信部８０１は、受信したＩＤの履歴を管理し、過去に受信したＩＤと一致するものを受信した場合には、ＩＤの再送要求を返信してもよい。また、受信したＩＤの履歴は、後に説明される保管部８０４が管理するテーブルなどで管理することもできる。すなわち、保管部８０４が管理するテーブルに同じＩＤが格納されていればＩＤの再送要求を返信してもよい。
【００７０】
預管理データ受信部８０１は、受信した管理データ８０７とＩＤ８０８とをメモリに展開する。そして、管理データ８０７のメモリアドレスなどを管理データ送信部８０２へ渡すことにより管理データ８０７を伝達し、ＩＤ８０８のメモリアドレスを保管部８０４へ渡すことによりＩＤ８０８を伝達する。
【００７１】
管理データ送信部８０２は、預管理データ受信部８０１より伝達された管理データ８０７を送信する。送信先は、管理サーバである。送信の結果、管理サーバにて管理データ８０７に含まれる照合用データの有効性が確認されると、照合用データの書き換えが行われ、書き換え後の管理データ８０９が返信される。
【００７２】
管理データ受信部８０３は、管理データ送信部８０２からの管理データ８０７の送信に応じて管理サーバより返信される管理データ８０９を受信する。上述したように管理データ８０７の少なくとも照合用データが置き換えられたものが管理データ８０９となっている。管理データ受信部８０３は、受信した管理データ８０９をメモリに展開し、そのメモリアドレスなどを保管部８０４に渡すことにより、管理データ８０９を伝達する。
【００７３】
保管部８０４は、預管理データ受信部８０１より伝達されたＩＤ８０８と管理データ受信部８０３より伝達された管理データ８０９とを関連付けて保持する。ＩＤ８０８と管理データ８０９とは、異なる時に保管部８０４に伝達される。このために、保管サーバ８００は、例えば預管理データ受信部８０１が受信した管理データ８０７とＩＤ８０８とに一意の識別情報を付与するようにしてもよい。そして、預管理データ受信部はＩＤ８０８とともにその一意の識別情報を保管部８０４に伝達する。また、管理データ送信部８０２が管理データ８０７を送信するために管理サーバと通信セッションを開始するとその通信セッションをその一意の識別情報と関連付ける。そして、管理データ８０９が受信されると、通信セッションから一意の識別情報を取得し、管理データ受信部８０３は、管理データ８０９とともにその一意の識別情報を保管部８０４に伝達する。これにより、保管部８０４では、ＩＤ８０８と管理データ８０９とを関連付けることができる。また、保管サーバ８００が付与した一意の識別情報が管理データ８０７に含まれて送信されるようになっていてもよい。管理サーバは、その一意の識別情報を変更することなく、照合用データを書き換える。
【００７４】
保管部８０４は、ＩＤと管理データとを関連付けて保管するためにテーブルを用いてもよい。図９はそのようなテーブルを示している。図９では、“ｅ９８７ａｂｃ”というＩＤと照合用データとして“１４９１６２５”を含む管理データとが関連付けて保持されている。“ｅ９８７ａｂｃ”というＩＤは、例えば図７におけるステップＳ７０１の処理として行われる決済処理のための利用者端末と入金サーバと間の通信セッションのＩＤなどである。
【００７５】
なお、保管部８０４にＩＤ８０８と管理データ８０９とが関連付けて格納された場合、ステップＳ７０７の保管通知となる情報が送信されるようになっていてもよい。この保管通知は、例えば、預管理データ受信部８０１が管理データ８０７とＩＤ８０８とを受信したＡＣＫとして返信されるようになっていてもよい。
【００７６】
ＩＤ受信部８０５は、ＩＤ８１０を受信し、ＩＤ８１０と保管部８０４にて関連づけて保管されている管理データの検索を行う。検索の結果、ＩＤ８１０と関連付けて保管されている管理データが存在すれば、ＩＤ受信部８０５はその管理データを読出し、預管理データ送信部８０６へ伝達する。また、ＩＤ８１０とその管理データとの関連付けを解消あるいは破棄する。解消あるいは破棄は、具体的には、図９に示すテーブルからＩＤ８１０が格納されている行データを削除することにより実現される。あるいは、図９に示すテーブルに削除フラグを格納する列を設けて、削除されたことを示す値を格納することで、解消あるいは破棄されたことを表現するようになっていてもよい。
【００７７】
預管理データ送信部８０６は、ＩＤ受信部８０５から伝達された管理データを送信する。管理データの送信先は、ＩＤ８１０の送信元であることが想定される。ただし、管理データの送信先がＩＤ８１０とともにＩＤ受信部８０５により受信されたなどの場合には、その送信先へ管理データを送信するようになっていてもよい。
【００７８】
図１０は、保管サーバ８００における管理データとＩＤとを受信し保管するまでの処理の流れを説明するフローチャートの一例である。ステップＳ１００１の処理として、預管理データ受信部８０１により、管理データとＩＤとを受信する。ステップＳ１００２の処理として、その管理データを、管理データ送信部８０２により、管理サーバへ送信する。そしてステップＳ１００３の処理として、管理データ受信部８０３により、管理データを受信する。その後、ステップＳ１００４の処理として、保管部８０４により、ステップＳ１００１で受信されたＩＤとステップＳ１００３で受信された管理データを関連付けて保管する。
【００７９】
図１１は、保管サーバ８００におけるＩＤを受信しそのＩＤと関連付けられて保管されている管理データを送信するまでの処理の流れを説明するフローチャートの一例である。ステップＳ１１０１の処理として、ＩＤ受信部８０５により、ＩＤを受信する。ステップＳ１１０２の処理として、そのＩＤと関連付けられて管理データが保管部８０４に保管されていることを確認する。もし確認できなければ、エラーをＩＤの送信元などに返信する。確認ができれば、ステップＳ１１０３の処理として、ＩＤと関連づけて保管されている管理データを読み出す。そして、ステップＳ１１０４の処理として、ＩＤと管理データとが関連付けられて格納されている状態を解消する。例えば、図９に示されるテーブルから上述にように行データを削除する。その後ステップＳ１１０５の処理として、預管理データ送信部８０６により、管理データを送信する。
【００８０】
このような構成の保管サーバを、図６、図７に示すように入金サーバと管理サーバとを組み合わせることにより、匿名性を保ちつつ管理データの発行が行える。
【００８１】
また、このような保管サーバを経由することにより、利用者間でも管理データを譲渡することができる。「利用者間」と記載したが、この場合、一方の利用者は物やサービスを購入する者であり、他方はその物やサービスを提供する者であり、その物やサービスの対価として管理データが一方の者から他方の者へ譲渡される場合が想定される。特に、他方はＷＥＢサーバなどを用いてインターネットからアクセスされる仮想的な店舗であってもよい。すなわち、管理データを電子マネーとして使用することにより、財物や役務の提供に対する代金の決済処理を行うことができる。すなわち、保管サーバが決済処理を行うサーバとして動作することになる。また、保管サーバを用いることにより、個人間などの一般の利用者間でも管理データの譲渡をすることが可能となる。
【００８２】
図１２は、利用者間で管理データを譲渡するシステム１２００の構成を示す。システム１２００を参照しながら、管理サーバ１２０１と、保管サーバ１２０３と、譲渡者端末１２０４と、譲受者端末１２０５とを有する。譲渡者端末１２０４の利用者（譲渡人）が譲受者端末１２０５の利用者（譲受人）へ管理データを譲渡する場合の処理の流れについて以下に説明する。
【００８３】
譲渡人は、あらかじめ、管理サーバから管理データの発行を受けたり、入金サーバを介して管理データを取得したり、入金サーバと保管サーバを介して管理データから取得したりしておく。あるいは別の譲渡人より、管理データの譲渡を受ける。この場合の譲渡としては、これから説明されるように保管サーバを介して行われてもよいし、別の譲渡人から管理データが記録された光ディスクや可搬型の不揮発性半導体メモリなどの記憶媒体の譲渡を受けたり、電子メールの添付データなどとして譲渡を受けたりしていてもよい。
【００８４】
図１３は、保管サーバを介しての管理データの譲渡の流れを説明するシーケンス図である。ステップ１３０１の処理として、譲渡者端末１２０４と譲受者端末１２０５との間で管理データの譲渡の合意をする。この合意は、無償にて譲渡人が譲受人に管理データを譲渡する合意であったり、上述のように譲受人が物やサービスを提供することの引き替えに譲渡人が管理データを譲渡する合意であったりする。なお、この合意のために、譲渡人の使用する譲渡者端末（第１の端末）と譲受人の使用する譲受者端末（第２の端末）とが相互に認証し合ってもよい。例えば、暗号化された通信セッションを確立するために第１の端末と第２の端末との間で暗号化と復号化のための暗号鍵を共有する。
【００８５】
また、相互認証の際には、その相互認証を一意に特定する情報を決める。例えば、ＷＥＢショップで買い物などを行う場合には、ＷＥＢサーバと端末との間の暗号化された通信セッションのＩＤなどを用いる。
【００８６】
譲渡の合意あるいは相互認証が終了すると、譲渡人側の端末は新たに管理データの発行を受けたり、既に発行がされたり第三者から譲渡がされたりした管理データの中から選択を行い、管理データ３とセッションＩＤとを保管サーバ１２０３へ送信する。管理データ３とセッションＩＤとを受信した保管サーバは、ステップＳ１３０３の処理として管理データ３を管理サーバへ送信する。管理サーバが管理データ３に含まれる照合用データが有効であると確認を行うと、新たに準備した照合用データによる置換を行い、ステップＳ１３０４の処理として管理データ４を保管サーバへ返信する。これにより、管理データ３は無効な照合用データを含む管理データとなり二重に使用ができなくなる。
【００８７】
保管サーバが管理データ４を受信すると、ステップＳ１３０２で受信したセッションＩＤと関連付けて保管を行い、ステップＳ１３０５の処理として保管通知を譲渡者端末へ送信する。保管通知を受信した譲渡者端末は、ステップＳ１３０６の処理として、寄託通知を譲渡者端末へ送信する。
【００８８】
寄託通知を受信した譲受者端末は、ステップ１３０７の処理として、管理データの送信要求を譲渡合意の際のセッションＩＤとともに保管サーバへ送信し、これに応じて保管サーバは管理データ４をステップＳ１３０８の処理として返信してもよい。
【００８９】
以上のように保管サーバを構成することにより、管理データの発行の際、そして、管理データの譲渡の際に同じ処理を保管サーバで行うようにすることができる。また、管理データの匿名性なども確保できる。
【００９０】
（実施形態２）
上述の実施形態１において、価値として貨幣価値のように可分な価値が用いられる場合には、管理データが表す価値に上限を設けてもよいことについて説明した。例えば、５０００円を上限とすると、１３０００円の価値は、例えば、５０００円を表す管理データ２つと、３０００円を表す管理データ１つとにより表される。この場合の３０００円を表す管理データのように、上限の価値に満たない価値を表す管理データを「端数管理データ」と呼ぶことにする。
【００９１】
管理データを用いて商品や役務の代金の決済が行われる場合を考えると、代金の額が上記でいう上限になるとは限らない。このため、端数管理データを含む管理データにより代金が支払われたり、釣り銭の代わりに端数管理データを含む管理データが支払いとは逆の方向の管理データの流れで譲渡されたりする。このため、端数管理データの数は増加することになる。この結果、管理サーバのデータベース部の管理するデータが増加してしまうなどの問題が生ずる。そこで、以下では、端数管理データの増加を防ぐ構成について説明を行う。
【００９２】
（管理サーバ）
本実施形態に係る管理サーバは、実施形態１に係る管理サーバ１００において、管理データ受信部１０５が端数管理データ受信手段と、支払額受信手段とを有し、置換部１０６が端数変更手段と、釣管理データ生成手段とを有し、置換管理データ送信部１０７が端数管理データ送信手段と、釣管理データ送信手段とを有する。
【００９３】
端数管理データ受信手段は、端数管理データを受信する手段である。受信された端数管理データは、他の一または複数の管理データとともに、保管サーバより送信され管理サーバに受信され照合用データの有効性の確認がされることが主に想定される。端数管理データ受信手段は、端数管理データを受信するとメモリに展開し、端数管理データに含まれる照合用データのアドレスなどを取得して、端数変更手段に伝達する。
【００９４】
支払額受信手段は、管理データ受信部１０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データの表す価値のうち、譲渡が行われる価値を表す。すなわち、保管サーバを経由して譲渡者端末から譲受者端末へ譲渡されるべき価値を表すことが主に想定される。そして、譲渡が行われない価値が存在すれば、その価値は後述のように釣管理データとして譲渡者端末へ送信されることになる。
【００９５】
端数変更手段は、支払額受信手段が受信した価値を上述の上限の価値で除算を行った時の余りが０で無い場合に、端数管理データ受信手段により受信された端数管理データの表す価値にその余りを加算する処理を行う。例えば、上限額が５０００円で支払額受信手段が受信した価値が１３０００円であれば、１３０００円を５０００円で割り算を行うと、３０００円が余りとなる。そこで、端数管理データ受信手段が受信した端数管理データがデータベース部１０１により、１０００円を表していれば、１０００円に３０００円を加算した４０００円を表すようにデータベース部１０１が管理するデータベースの変更操作などを行う。
【００９６】
具体的には、端数変更手段は、端数管理データ受信手段から伝達されたアドレス等により指定される照合用データで図２（ａ）などに示されるテーブルの検索を行いその照合用データがテーブルに格納されているのを確認すると、その照合用データに関連付けられている価値の値に上述の余りを加算する。加算した結果がもし上述の上限を超えていれば、加算した結果のかわりに上限の価値をテーブルに登録し、新たに照合用データを準備してテーブルに挿入し、加算した結果から上述の上限を引いた額を関連付ける。例えば、端数管理データ受信手段から伝達されたアドレス等により指定される照合用データに１０００円が関連付けられており、上述の余りが４５００円であったとする。すると加算した結果は５５００円となり、上限の５０００円を超えている。そこで、端数管理データ受信手段から伝達されたアドレス等により指定される照合用データには上限の５０００円を関連づけ、新たに準備される照合用データには５００円を関連付ける。もちろん、５０００円と５００円とに関連付けるのは一例であり、５５００円の上限を超えないように複数の価値に任意に分けることができる。例えば、２５００円と３０００円とであってもよい。
【００９７】
釣管理データ生成手段は、管理データ受信部１０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データの表す価値のうち、支払額受信手段が受信した価値を引いた価値（「釣価値」という。）が０でなければ、釣価値を表す管理データを生成する。新たに管理データを生成してもよいし、管理データ受信部１０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データを再利用するように、その管理データが表す価値に釣価値を加えてもよい。そして、もし加えた結果が上限を超えていれば、新たな管理データを生成して、管理データに上限を超える価値が関連付けられないようにする。
【００９８】
端数変更手段、釣管理データ生成手段それぞれは、端数管理データ受信手段が受信した端数管理データが含む照合用データ、釣管理データ生成手段が生成した釣価値を表す管理データが含む照合用データのそれぞれを、新たな照合用データを準備して書き換えてもよい。
【００９９】
端数管理データ送信手段は、端数変更手段により価値が加算された管理データ、また必要に応じて新たに生成された管理データを送信する。
【０１００】
釣管理データ送信手段は、釣管理データ生成手段で生成された管理データを送信する。
【０１０１】
また、本実施形態において、保管サーバの預管理データ受信部８０１は、管理データ及びＩＤとともに、支払額情報を受信可能となっている。支払額情報とは、管理データの譲渡により譲渡されるべき価値を示す情報である。そして、預管理データ受信部８０１は、支払額情報が受信された場合には、受信したＩＤに関連付けられて保管部８０４に保管されている管理データを検索し、得られた管理データと受信した管理データとともに支払額情報を管理データ送信部８０２に伝達する。この場合、受信したＩＤに関連付けられて保管部８０４に保管されている管理データは、譲受者端末より送信された端数管理データとなっている。管理データ送信部８０２は、管理データとともに伝達された支払額情報を送信する。
【０１０２】
また、管理データ受信部８０３は、釣管理データも受信可能となっている。釣管理データが受信された場合には、保管サーバは、保管部８０４に管理データが保管されると、保管通知とともに釣管理データを、預管理データ受信部８０１が受信した管理データの送信元へ返信する。
【０１０３】
図１４は、本実施形態において、保管サーバを介しての管理データの譲渡の流れの一例を説明するシーケンス図である。ステップＳ１４０１の処理として、ステップＳ１３０１と同様に譲渡の合意を譲渡者端末と譲受者端末との間で行う。このとき、その合意では、単に管理データの譲渡のみならず、管理データの譲渡により譲渡される価値も合意する。例えば、商品の値段、送料などである。そして、このような場合に譲渡者端末が保管サーバへ送信する管理データを支払管理データという。
【０１０４】
ステップＳ１４０２の処理として、譲受者端末から保管サーバへ、端数管理データ１とセッションＩＤとを保管サーバへ送信する。このとき、譲受者端末である旨の情報も送信してもよい。ステップＳ１４０３の処理として、保管サーバは、受信した端数管理データ１を管理サーバへ送信し、その有効性を確認させ、ステップＳ１４０４の処理として、保管サーバは、端数管理データ２を管理サーバより受信する。そして、セッションＩＤと関連づけて端数管理データ２を保管する。
【０１０５】
なお、譲受者端末に端数管理データが無ければ、保管サーバには端数管理データを送信する必要はなく、したがって、保管サーバが端数管理データを管理サーバに送信する必要もない。
【０１０６】
譲渡者端末は、ステップＳ１４０５の処理として、支払額と支払いのための支払管理データ１とセッションＩＤを保管サーバに送信する。保管サーバは、支払管理データ１と支払額とを管理サーバに送信する。また、保管サーバは、図８に図示する命令部８１１にて、セッションＩＤからそれに関連付けられている端数管理データの有無を検出し、もしそのような端数管理データが存在すれば、その端数管理データもともに端数管理データ２として管理サーバへ送信する。
【０１０７】
なお、ステップＳ１４０２において、譲受者端末から譲受額が送信されてもよく、この場合は、譲渡者端末から送信される支払額と譲受額とが同じであることを確認してもよい。もし、同じでなければ譲受者端末、譲渡者端末へエラーを通知する。また、ステップＳ１４０２において、譲受者端末から譲受額が送信され、ステップＳ１４０５において、譲渡者端末から支払額が送信されない構成もある。この場合には、支払管理データ１に関連付けられている価値の値が譲受額以上であることを確認する。もし、譲渡に伴って手数料などを徴収する際には、支払管理データ１に関連付けられている価値の値から手数料などの額の値を引いたものが譲受額以上であることを確認する。また、端数管理データ１に関連付けられている価値から手数料などの額を徴収することにしてもよい。
【０１０８】
管理サーバは、ステップＳ１４０６の処理として受信した支払管理データ１、支払額、端数管理データ２から、置換部１０６、置換管理データ送信部１０７により、端数管理データ３と支払管理データ２と釣管理データとを生成して、ステップＳ１４０７の処理として、保管サーバへ送信する。ここで、端数管理データ３は、端数変更手段で変更、生成された管理データであり、釣管理データは釣管理データ生成手段で生成された管理データである。
【０１０９】
端数管理データ３と支払管理データ２と釣管理データとを受信した保管サーバは、支払管理データ３と端数管理データをステップＳ１４０２又はＳ１４０５で受信したセッションＩＤと関連づけて保管する。そして、ステップＳ１４０８の処理として、譲渡者端末へ釣管理データと保管通知を送信する。譲渡者端末は、ステップＳ１４０９において寄託通知を譲受者端末へ送信し、譲受者端末はステップＳ１４１０において、送信要求とセッションＩＤとを保管サーバへ送信し、これに応じて保管サーバは、セッションＩＤと関連付けて保管されている端数管理データ３と支払管理データ２をステップＳ１４１１の処理として、譲受者端末へ送信してもよい。そして、セッションＩＤと端数管理データ３及び支払管理データ２との関連付けを破棄してもよい。
【０１１０】
このようにして、譲渡者端末から譲受者端末へ、譲渡合意で合意された価値が電子的に譲渡される。また、本実施形態では、管理データが表す価値に上限を設けられている場合に、譲受者端末から端数管理データを提供することにより、その端数管理データに釣り銭に相当する価値を加えることができ、端数管理データの数の増大を防止することができる。これにより、管理サーバのデータベース部１０１で管理するべき照合用データの数の増加を防止することができる。なお、「譲受者端末」と記載したが、譲受者端末は端末装置と同等の機能を有していればよく、サーバ装置を端末装置として用いられる場合も含まれる。譲渡者端末についても同様である。
【０１１１】
（実施形態３）
本発明の実施形態３として、代理サーバとショップサーバとが管理データを交換するシステムについて説明する。ここで、代理サーバとは、利用者（消費者）に対して発行された管理データを管理するサーバであり、ショップサーバとは、物品の販売やサービスの提供を行うためのサーバである。本実施形態では、主に利用者が利用する利用者端末にインストールされたブラウザなどを介して発行される指示によって代理サーバがショップサーバへ管理データを送信させ、その管理データを受信したショップサーバが利用者に対して物品の販売やサービスの提供を行う形態について説明する。
【０１１２】
図１５は、本発明の実施形態３に係るシステムの概要を示す図である。システム１５００においては、利用者端末１５０２が、インターネットなどの通信網１５０１を介して、ショップサーバ１５０３及び代理サーバ１５０４と通信を行う。また、必要に応じて、ショップサーバ１５０３と代理サーバ１５０４とが通信を行うことができるようになっていてもよい。
【０１１３】
利用者端末１５０２は、商品や役務などの購入者である利用者が商取引を行うために用いる電子機器である。ショップサーバ１５０３は、利用者端末１５０２の利用者から商品、役務などの購入の申込を受け付け、利用者端末１５０２との決済処理を行うための装置である。代理サーバ１５０４は、利用者端末１５０２の利用者に発行された管理データを利用者端末１５０２の代わりに保持し、利用者端末１５０２を代理してショップサーバとの決済処理を行うための装置である。なお、決済処理は、商品や役務などの対価として行われる必要はなく、利用者が他の者に価値を贈与する場合にも行われてよい。
【０１１４】
なお、ショップサーバ１５０３と代理サーバ１５０４とは同じサーバ装置として実現されていても良い。この場合には、利用者端末１５０２にインストールされているブラウザが、そのサーバ装置のうちショップサーバ１５０３に相当する部分と代理サーバ１５０４に相当する部分とにアクセスするＵＲＬが異なっていればよい。例えば、ＵＲＬのパスの部分が異なっていればよい。あるいは、ショップサーバ１５０３と代理サーバ１５０４として動作するサーバ装置が複数のドメインを有し、一つのドメインがショップサーバ１５０３に割り当てられており、他のドメインが代理サーバ１５０４に割り当てられていればよい。
【０１１５】
図１６は、本発明の実施形態３に係るシステム１６００の全体の構成を示す。システム１６００は、利用者端末１６０１と、入金サーバ１６０２と、代理サーバ１６０３と、ショップサーバ１６０４と、決済機関サーバ１６０５と、発行サーバ１６０６と、管理サーバ１６０７と、保管サーバ１６０８とを有する。利用者端末１６０１と、入金サーバ１６０２と、代理サーバ１６０３と、ショップサーバ１６０４と、決済機関サーバ１６０５と、発行サーバ１６０６と、管理サーバ１６０７と、保管サーバ１６０８とは、それぞれ通信アダプタなどのハードウェアを備え、通信を行う。なお、上述したように、複数のサーバが同じサーバ装置として実現されてもよい。例えば、入金サーバ１６０２と、代理サーバ１６０３と、発行サーバ１６０６と、管理サーバ１６０７と、保管サーバ１６０８とが同じサーバ装置として実現されていてもよい。
【０１１６】
ショップサーバは、図２９に例示するように、利用者端末より購入の申込情報を受信する受信部２９０４と、受信された購入の申込情報に基づいて、利用者端末の利用者が支払う価格の情報を利用者端末へ返信する返信部２９０３と、管理データを保持する管理データ保持部２９０２と、管理データ保持部２９０２にて保持される管理データを価格の情報とともに保管サーバへ送信する送信部２９０１とを有する。
【０１１７】
図１７は、本発明の実施形態３に係る代理サーバ及び利用者端末の機能ブロック図である。代理サーバ１８００は、ユーザ情報管理部１８０２と、支払処理部１８０３と、釣受信部１８０９と、管理データ管理部１８０４とを有する。利用者端末１８０１には、ブラウザ１８０８がインストールされている。
【０１１８】
ユーザ情報管理部１８０２は、利用者端末１８０１の利用者を識別するためのユーザ情報を管理する。例えば、ユーザ情報として、利用者端末１８０１のブラウザに表示されるウェブページから利用者が入力されるユーザＩＤやパスワードなどの認証情報に基づいてユーザを認証する。また、新たに代理サーバ１８００を利用するユーザの登録の処理を行う。
【０１１９】
図１８（ａ）は、ユーザ情報管理部１８０２が保持するテーブル構成の一例を示す図である。図１８（ａ）は、ユーザ情報が格納されたテーブルであり、図１８（ａ）に示すように、「所有者ＩＤ」、「ユーザＩＤ」、「パスワード」、「属性」といった名前の列により構成される。本実施形態では、図１８（ａ）に示すユーザ情報テーブルは、ユーザ情報と所有者ＩＤ（所有者識別情報）とが関連づけられ、ユーザ情報管理部１８０２にて管理される。ここで、管理とは、データのファイルへの書き込み、読み出し、削除、更新を意味する。所有者ＩＤとは、管理データを所有している者を識別するＩＤである。管理データを所有している者とは、管理データが表す価値が帰属する権原を有している者をいう。
【０１２０】
所有者ＩＤとしては、例えば、管理サーバなどで発行されたＩＤ、電子メールアドレス、住民票コード、公開鍵証明書など、人を識別できる情報を、管理サーバから代理サーバにデータ連携して、図１８（ａ）に示すユーザ情報テーブルにおいて所有者ＩＤとして用いてもよい。そして、ユーザ情報管理部１８０２は、所有者ＩＤにパスワードなどを関連付けて保持するなどして、代理サーバ１８００に所有者ＩＤを提示してアクセスしてきた者を認証できるようにしておくのが好ましい。なお、所有者ＩＤ、パスワードをそのまま図１８（ａ）に示すテーブルに格納する必要はなく、所有者ＩＤ、パスワードのそれぞれのハッシュ値を算出し、そのハッシュ値を格納してもよい。なお、ハッシュ値とは不可逆的な演算を行う関数により得られる値である。不可逆的とは、関数の出力から入力を計算する逆関数の計算を行うことが事実上不可能であることをいう。このような関数としては、ＳＨＡ−１（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｍ−１）などが知られている。なお、以下では、ある値とそのハッシュ値とは均等データとして扱う場合がある。
【０１２１】
代理サーバ１８００における管理データ管理部１８０４は、保管サーバから、管理データ１８０５と所有者ＩＤ１８０６（あるいは所有者ＩＤ１８０６の均等データ）とを受信する。なお、管理データ１８０５と所有者ＩＤ１８０６とは、図７のステップＳ７０４での説明等における入金サーバから保管サーバへ送信される管理データ１とセッションＩＤとそれぞれに相当してもよい。この場合、入金サーバは、利用者端末との決済処理Ｓ７０１を行うときに、利用者端末の利用者を認証し、ユーザＩＤあるいはその均等データを得て、セッションＩＤとして用いる。なお、入金サーバが利用者端末の利用者を認証する場合には、代理サーバと通信を行い、利用者端末の利用者を認証するようになっていてもよい。
【０１２２】
受信された管理データ１８０５及び所有者ＩＤ（あるいはその均等データ）１８０６は、管理データ管理部１８０４が管理するテーブルに格納される。管理データ管理部１８０４は、図１８（ｂ）に示されるような管理情報テーブルを管理する。図１８（ｂ）に図示されるように、管理情報テーブルは、「所有者ＩＤ」、「管理データ」といった名前の列より構成される。本実施形態では、図１８（ｂ）に図示される管理情報テーブルにおいて、「管理データ」の列には、管理情報テーブルとは異なる別のテーブルや記憶領域に格納された管理データにアクセスするための記憶領域のアドレスが格納されている。そのため、図１８（ｂ）において、「管理データ」の列に格納されたアドレスを、管理データにアクセスする様子への矢印として図示している。管理データ管理部１８０４に保持されている管理データのアドレスは、管理データを用いた支払の処理等の際に、読み出し、削除、変更が行われる。
【０１２３】
代理サーバ１８００における支払処理部１８０３は、利用者端末１８０１の送信する、管理データによる支払を指示する情報が受信された際に、利用者端末１８０１を代理して支払処理を行うための部である。支払処理部１８０３は、利用者端末１８０１から支払指示の情報を受信すると、その受信と前後して利用者端末１８０１の利用者の認証を、ユーザ情報管理部１８０２により行い、利用者ＩＤあるいはその均等データを得る。この利用者の所有者ＩＤあるいはその均等データを用いて、管理データ管理部１８０４の管理する管理情報テーブルにて検索し、利用者端末１８０１の利用者が所有する管理データを検索する。検索された管理データ１８０７のうち、別途受信される支払額以上の価値を有する管理データが選択され、代理サーバ１８００の支払処理部１８０３から、保管サーバに送信される。
【０１２４】
図１９は、本発明の実施形態３に係る管理データを用いた支払処理のシーケンス図を示す。図１９は、保管サーバ及び管理サーバを介して、代理サーバとショップサーバとの管理データの交換による支払処理を説明するためのシーケンス図である。図１９は、図１４に対応していると言うことができる。すなわち、図１４における譲受者端末が、図１９におけるショップサーバに対応し、譲渡者端末が、利用者端末を代理する代理サーバに対応している。また、ショップサーバは、ＷＥＢサーバとしての機能を有し、ＷＥＢページの閲覧要求があれば、要求されたＷＥＢページを返信する。
【０１２５】
ステップＳ１９０１において、利用者端末のブラウザなどへＵＲＬの入力や、ブラウザを操作してリンクを辿るなどの処理を行い、ウェブページの閲覧要求がショップサーバへ送信される。ショップサーバが閲覧要求を受信すると、要求されたウェブページをステップＳ１９０２において返信する。
【０１２６】
ステップＳ１９０２にて、ブラウザに返信されるウェブページには、商品などの購入の申込を行うための画面の記述がされているとする。例えば、図２８に示すように、「○○」として、購入が行われる商品などの名称が表示され、代金が例えば１００円として表示される。また、「購入」という表示を有するボタンが表示されている。このボタンには、購入が行われる商品などの識別番号が関連付けられている。また、必要に応じて、ウェブページには商品の配送先などを入力するテキストエリアが含まれており、「購入」という表示を有するボタンが押下されると、そのテキストエリアに入力された情報が送信されるようになっていてもよい。「購入」という表示を有するボタンが押下されることによりショップサーバへ送信される情報を購入情報ということにする。
【０１２７】
「購入」という表示を有するボタンが押下されると、ステップＳ１９０３の処理として、購入情報がショップサーバに送信される。購入情報がショップサーバに送信され、これに対する返信がショップサーバからブラウザに対して送信されることにより、ブラウザを操作する利用者がショップサーバの運営者から商品などの購入の同意がされ、支払が管理データの譲渡によってされることの同意もされたことが示される。
【０１２８】
すなわち、ステップＳ１９０１からステップＳ１９０３までの処理が行われることにより、譲受者端末としてのショップサーバと、譲渡者端末としての利用者端末との間で譲渡の合意がされることになる。従って、ステップＳ１９０１からステップＳ１９０３までの処理は、ステップＳ１４０１に対応していると言うこともできる。
【０１２９】
ステップＳ１９０４の処理として、ショップサーバから支払指示とセッションＩＤとがブラウザに送信される。支払指示には、譲渡されるべき価値の額（支払額）が含まれている。また、セッションＩＤは、ステップＳ１９０１からステップＳ１９０３の通信をショップサーバから一意に特定する。「送り情報」と言う場合がある。
【０１３０】
また、ステップＳ１９０４においてショップサーバから送信される支払指示とセッションＩＤには、ブラウザを代理サーバのＵＲＬが含まれ、ブラウザをそのＵＲＬにリダイレクトする指令が含まれているのが好ましい。これにより、後に説明するステップＳ１９０８においてブラウザから代理サーバへのアクセスが行われる。あるいは、利用者端末に支払処理を行う専用アプリケーションがインストールされている場合には、支払指示とセッションＩＤをＭＩＭＥフォーマットで記述し、Ｃｏｎｔｅｎｔ−Ｔｙｐｅなどによって、そのアプリケーションを用いて表示されることが指定されていてもよい。本実施形態では、支払指示とセッションＩＤには、ブラウザを代理サーバのＵＲＬが含まれ、ブラウザをそのＵＲＬにリダイレクトする指令が含まれているとして説明を行う。
【０１３１】
また、ステップＳ１９０５の処理として、ショップサーバは、保管サーバに対して、端数管理データ１とセッションＩＤとを送信する。
【０１３２】
ショップサーバから端数管理データ１とセッションＩＤとを受信した保管サーバは、ステップＳ１９０６の処理として、端数管理データ１を管理サーバへ送信し、端数管理データ１が有効であるかどうかを判断させ、有効であれば、照合用データの書き換えを行わせ、その結果得られる管理データである端数管理データ２をステップ１９０７の処理において受信する。そして、セッションＩＤと関連付けて保管する。
【０１３３】
したがって、ステップＳ１９０５、Ｓ１９０６、Ｓ１９０７の処理は、ステップＳ１４０２、Ｓ１４０３、Ｓ１４０４の処理に対応していると言うことができる。
【０１３４】
ステップＳ１９０４にて、ショップサーバから支払指示とセッションＩＤとを受信したブラウザは、ステップＳ１９０８において、代理サーバへリダイレクトし、その時に代理サーバに支払指示とセッションＩＤとを代理サーバへ送信する。代理サーバは、ステップＳ１９０９において、利用者情報の入力を要求する認証要求を利用者端末に送信し、利用者端末のブラウザに利用者情報の入力画面を表示させる。利用者がブラウザから利用者情報を入力すると、ステップＳ１９１０において、代理サーバに認証情報が送信される。認証情報は、例えば、後述するように利用者の登録を行った際に代理サーバなどから送信されるクッキー情報を代理サーバに送信することにより行われてもよい。このクッキー情報の中には、利用者ＩＤ及びパスワードのハッシュ値が格納されている。なお、ステップＳ１９０８よりも前に利用者端末の利用者が代理サーバに対して認証を行っており、代理サーバが利用者を認識していれば、ステップＳ１９０９とＳ１９１０は不要となる。なお、代理サーバが利用者を認識していても、利用者の支払の意思を確認するために、ステップＳ１９０９とＳ１９１０が行われてもよい。
【０１３５】
ステップＳ１９１１において、代理サーバは、利用者端末の利用者が所有する管理データであって、ステップＳ１９０４で受信した支払指示に含まれる支払額以上となるように管理データを管理データ管理部１８０４から選択して読み出して支払管理データ１として、セッションＩＤとともに保管サーバに送信する。支払額以上とは、選択された管理データが表す価値の額の合計額が、支払額以上となるこという。管理データ管理部１８０４から読み出される管理データは複数であってもよい。また、代理サーバからの画面情報の送信により、支払額を画面に表示し、ボタン押下を利用者に行わせるなどして、支払管理データの額などの確認を行わせてもよい。また、管理データ管理部１８０４で管理されている管理データが暗号化されて記憶されている場合には、復号のためのパスワードなどの入力が求められるようになっていてもよい。
【０１３６】
ステップＳ１９１１において、代理サーバからセッションＩＤ、支払額、支払管理データ１を受信した保管サーバは、セッションＩＤに、支払額と支払管理データ１とを関連付けて保管する。また、他にセッションＩＤに関連付けて保管されている管理データがあるかどうかの検索を行い、そのような管理データがあれば、ステップＳ１９１２以降の処理を行う。
【０１３７】
図２０は、管理データを用いた支払処理における代理サーバの処理の流れを説明するフローチャートの一例である。代理サーバは、ステップＳ１９０８に相当するステップＳ２００１の処理として、支払処理部１８０３を動作させて、利用者端末のブラウザから送信された支払指示とセッションＩＤとを受信する。次に、ステップＳ１９１０に相当するステップＳ２００２の処理として、ユーザ情報管理部１８０２を動作させて、利用者端末のブラウザから送信された利用者の認証を行う。次に、ステップＳ２００３の処理として、ユーザ情報管理部１８０２を動作させて、ブラウザから取得された認証情報に基づき所有者ＩＤを検索し、管理データ管理部１８０４にて、その所有者ＩＤに関連づけられている管理データを検索する。検索された管理データは、ステップＳ１９１１に相当するステップＳ２００４の処理として、ステップＳ２００１において受信されたセッションＩＤとともに、保管サーバに送信される。
【０１３８】
ステップＳ１９１２とステップＳ１９１３の処理は、ステップＳ１４０６、Ｓ１４０７の処理に対応しているということができる。保管サーバは、端数管理データ２と支払額と支払管理データ１とを管理サーバに送信し、端数管理データ３と支払管理データ２と釣管理データとを管理サーバから受信する。
【０１３９】
ステップＳ１９１４の処理として、保管サーバは代理サーバに釣管理データを送信する。この釣管理データの送信は、ステップＳ１９１１にて受信された支払額と支払管理データ１の返信として行われてもよい。なお、代理サーバの支払処理部は、釣管理データを保管サーバより受信し、利用者端末の利用者の識別情報と関連付けて管理データ管理部に保持する釣受信部１８０９を有する。代理サーバは、釣管理データを利用者端末の利用者の所有する管理データとして図１８（ｂ）に例示されるテーブルに格納を行う。
【０１４０】
ステップＳ１９１５の処理として、代理サーバは、利用者端末のブラウザに、決済終了画面を表示させる。決済終了画面の記述は、ステップＳ１９１４にて、保管サーバが釣管理データとともに代理サーバに送信するようになっていてもよい。さらに、決済終了画面の記述は、ステップＳ１９０５において、ショップサーバが端数管理データ１とセッションＩＤとともに保管サーバに送信するようになっていてもよい。このように決済終了画面の記述が、ショップサーバから送信され、保管サーバを経由して、利用者端末へ送信されることにより、電子的なデータそのものや電子的なデータのダウンロードなどのために使用するＵＲＬを決済終了画面の記述に含ませることにより、電子的なデータの販売に本実施形態を利用することができる。
【０１４１】
ステップＳ１９１３にて管理サーバから受信された端数管理データ３と支払管理データ２とは、ステップＳ１９０５にて受信されたセッションＩＤとともに保管サーバからショップサーバへ送信される（ステップＳ１９１６）。端数管理データ３と支払管理データ２の送信は、ステップＳ１９０５にてショップサーバから送信された端数管理データ１とセッションＩＤに対する返信として行われてもよい。
【０１４２】
このように、支払指示とセッションＩＤとが利用者端末のブラウザなどにより受信されると、利用者端末から代理サーバに支払指示とセッションＩＤとが送信され、管理データを用いた支払を行うことができるようになる。したがって、本実施形態においては、利用者は、ブラウザを用いてショップサーバにステップＳ１９０３にて購入情報を送信した後、決済処理を行うために、従来技術における場合と異なり、クレジットカード番号や振込先の口座番号などの煩雑なデータを入力する必要がなくなる。また、代理サーバに保持された管理データを用いて支払を行うので、クレジットカードのようにその後の返済などについて心配する必要がない。したがって、利用者は簡便な操作で管理データを用いて支払を行うことができる。これにより、インターネットなどでの支払を安全かつ簡便に行うことができる。
【０１４３】
図２１は、本発明の実施形態に係るシステム１６００において、利用者が電子的な価値情報を有する管理データを購入する際に、利用者端末１６０１の利用者から管理データの表わすべき価値が決済されたことが決済機関サーバ１６０５から入金サーバ１６０２に通知され、入金サーバ１６０２が管理データ１６０６の発行を発行サーバに命令し、発行された管理データが代理サーバ１６０３に格納され、利用者端末１６０１に管理データの発行通知が送信されるまでの発行処理を説明するシーケンス図である。また、図２２は、本発明の実施形態に係る発行処理における入金サーバの処理の流れを説明するためのフローチャートである。
【０１４４】
利用者は、利用者端末にインストールされたブラウザに表示されるウェブページを通じて、システム１６００を構成する各サーバにアクセスする。
【０１４５】
利用者端末のディスプレイなどには、例えば、図２３（ａ）に示されるように、「入金（ポイント購入）」、「ポイントの受取」、「ポイントによる支払」の表示を有するボタンを含む画面表示が、ブラウザを通じて表示される。「入金（ポイント購入）」のボタンが押下されると、入金サーバにユーザ情報が送信され、入金サーバはユーザ情報に基づき画面情報を生成する。入金サーバが生成した画面情報が利用者端末に送信され、例えば、図２３（ｂ）に示されるような画面が、利用者端末のブラウザに表示される。
【０１４６】
ステップＳ２１０１において、利用者が、利用者端末のブラウザに表示された図２３（ｂ）に例示するようなウェブページにおいて、購入ポイント数をリスト等から選択し、「購入」ボタンを押下すると、ステップＳ２１０２において、利用者端末から入金サーバへ、購入開始情報が送信される。ステップＳ２１０２は、図２２に示すフローチャートのステップＳ２２０１に相当する。購入開始情報は、利用者が選択した購入ポイント数の情報を含む。また、購入開始情報は、利用者端末を識別するための識別情報も含んでいてもよい。本実施形態において、購入開始情報は、後述するユーザ登録処理の際に利用者端末のクッキーに保存されたユーザＩＤのハッシュ値、仮端末識別子のハッシュ値、及び入金サーバと利用者端末との間の通信のセッションを特定するセッションＩＤ（セッションを一意に特定するセッション識別情報）の情報等を含んでもよい。識別情報の例としては、利用者端末の製造番号や、ＭＡＣアドレス、ＩＰアドレスなどであってもよい。利用者端末の製造番号や、ＭＡＣアドレスなどは、ブラウザにプラグインなどを組み込んでおくことにより入金サーバが取得することが可能である。あるいは、利用者を識別する情報であるユーザＩＤや所有者ＩＤなどであってもよい。また、識別情報は、利用者端末の製造番号や、ＭＡＣアドレス、ＩＰアドレスなどの情報そのものである必要はなく、それらの情報に対して所定のハッシュ関数を適用して計算される値であってもよい。この識別情報あるいは等価データは、管理サーバにより後に発行される管理データに埋め込まれてもよい。識別情報を管理データに埋め込むことにより、管理データを譲渡などする場合に、管理データが不正に他の利用者から取得されたものであるかどうかを検出することができる。これにより、管理データの使用の際の安全性を高めることができる。また、識別情報には、乱数が含まれるようになっており、管理データが管理サーバへ送信され、返信される都度、変化する部分があってもよい。
【０１４７】
入金サーバは、購入開始情報を受信した後、代理サーバに問い合わせる等の処理により、識別情報を基に利用者を認証し、認証された利用者に応じて画面情報を生成する。ステップＳ２１０３（図２２のステップＳ２２０２に対応）において、入金サーバは、利用者端末のブラウザに表示される画面情報を送信する。画面情報は、例えば、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いて記述されてもよい。画面情報が送信されると、図２３（ｃ）に例示するような、決済方法を選択する画面がブラウザに表示される。図２３（ｃ）に示す画面のように、利用者が購入するポイント数及び決済金額が表示され、振込先の決済機関を選択する決済方法の選択リストがドロップダウンリストで表示されてもよい。また、複数の銀行の中から利用者端末の利用者が契約している銀行を選択できるように、複数の銀行それぞれに対応したボタンが表示されていてもよい。
【０１４８】
次に、ステップＳ２１０４において、図２３（ｃ）に示す画面上で決済方法を選択した状態で「振込へ」ボタンを押下すると、ステップＳ２１０５において、利用者端末から銀行などの決済機関サーバに対してアクセスが行われ、選択した決済機関のサーバに振込依頼の情報が送信される。なお、図２３（ｃ）の「振込へ」の表示を有するボタンには、振込先の口座の情報や、振込名義人名を含むＵＲＬが関連付けられており、そのＵＲＬにアクセスすると、決済機関サーバに振込先の口座の情報や振込名義人名が伝えられ、振込の画面が開かれた場合に、振込先の口座の情報や振込名義人名が既にデフォルト値などとして入力された状態となっていてもよい。
【０１４９】
次に、ステップＳ２１０６において、決済機関サーバから利用者端末に対し画面情報が送信され、利用者端末のブラウザに、図２４（ａ）に例示するような、インターネットバンキング等のためのログイン画面が表示される。このログイン画面において、ステップＳ２１０７にて、利用者がインターネットバンキング等の利用者情報を入力して「ログイン」ボタンを押下すると、ステップＳ２１０８にて、入力した利用者情報が利用者端末から決済機関サーバに送信される。
【０１５０】
決済機関サーバは、インターネットバンキング等の利用者情報を基に振込先を入力する画面情報を生成し、ステップＳ２１０９において、決済機関サーバから利用者端末に対し、振込先を入力する画面情報を送信する。利用者端末には、図２４（ｂ）に例示するような、振込先の口座番号や振込金額等を入力する画面が表示される。前述したように、図２３（ｃ）の「振込へ」の表示を有するボタンに、振込先の口座の情報や、振込名義人名を含むＵＲＬが関連付けられている場合には、図２４（ｂ）に例示する振込先を入力する画面に、既に振込先の口座の情報や振込名義人名がデフォルト値で入力された状態であってもよい。
【０１５１】
次に、振込先を入力する画面において、ステップＳ２１１０にて、振込先の口座情報及び振込金額等を入力し、「振込」ボタンを押下すると、ステップＳ２１１１にて、利用者端末から決済機関サーバへ、振込情報が送信される。
【０１５２】
振込情報が決済機関サーバに送信されると、決済機関サーバにおいて振込処理が行われる。振込処理が完了した場合には、振込処理が完了したことを利用者端末に表示するための画面情報が生成され、ステップＳ２１１２にて、決済機関サーバから利用者端末へ、画面情報が送信される。
【０１５３】
ステップＳ２１１２により、利用者端末には、図２４（ｃ）に例示されるような、振込処理完了の確認画面が表示され、利用者が「ＯＫ」ボタン等を押下し、別の取引が可能となる。また、利用者端末のブラウザ上には、図２５に例示されるような画面が表示される。
【０１５４】
図２５に例示される画面は、前述のステップＳ２１０４において、図２３（ｃ）に例示する画面の「振込へ」ボタンを押下した際に、振込依頼の情報が入金サーバに対しても送信され、入金サーバの処理により決済機関サーバと通信するための画面とともに表示されるものであってもよい。例えば、一つの画面の右半分に決済機関サーバと通信するための画面が表示され、左半分に図２５に例示される画面が表示されていてもよい。あるいは、図２５を示す画面が決済機関サーバと通信するための画面とは別に表示され、図２４（ａ）乃至（ｃ）に例示する振込処理の画面が表示されている裏で、図２５に例示する画面が表示されていてもよい。
【０１５５】
次に、図２５に例示される画面において、ステップＳ２１１３にて、利用者が「完了」ボタンを押下すると、ステップＳ２１１４において、利用者端末から入金サーバへ、振込通知が送信される。ステップＳ２１１４は、図２２に示すフローチャートのステップＳ２２０３に相当する。
【０１５６】
入金サーバは振込通知を受信すると、ステップＳ２１１５（ステップＳ２２０４）において、決済機関サーバに対し、振込がなされたかどうかを確認するために問合せの情報を送信する。この振込問合せの情報には利用者の情報が含まれており、振込問合せを受信した決済機関サーバは、利用者情報を基に、振込先口座や振込金額等の振込内容を検索する。振込内容を確認した決済機関サーバは、入金サーバに対し、ステップＳ２１１６（ステップＳ２２０５）において、検索された振込内容を含む情報を、入金情報として送信する。入金情報は、振込名義人名、振込先口座の情報、振込金額等の情報を含む。あるいは、入金サーバは５分など、所定の間隔で決済機関サーバに対して、入金サーバの運営者に対して行われた振込の情報を取得し、その情報をデータベースに格納してもよい。そして、振込問合せがあると、このデータベースを検索して、振込の有無を確認する。
【０１５７】
振込があったことを確認した入金サーバは、入金情報に、利用者が購入した管理データ数の情報を関連付けて、データを生成する。購入した管理データの情報とともに、入金情報は、ステップＳ２１１７（ステップＳ２２０６）において、入金通知として発行サーバに送信される。
【０１５８】
入金通知を受信した発行サーバは、発行用送り情報を生成し、ステップＳ２１１８（ステップＳ２２０７）において、入金サーバに対し、発行用送り情報を送信する。発行用送り情報とは、振込の決済処理を特定する番号を含む。発行用送り情報は、例えば、利用者端末と管理サーバとが通信を行ったセッションのＩＤであってもよい。また、発行サーバは、生成した発行用送り情報を管理データとともに保管サーバへ送信してもよい。保管サーバは、発行用送り情報と管理データとを関連付けて、その保管部に保持する。
【０１５９】
利用者はステップＳ２１１９において、利用者端末のブラウザに表示されるウェブページから入金サーバに対し、発行通知を確認するために、発行通知確認要求を送信する。入金サーバは、ステップＳ２１２０（ステップＳ２２０８）において、利用者端末に対し、発行用送り情報を基に生成した発行通知を送信する。
【０１６０】
次に、本発明の一実施形態に係るシステム１６００の利用にあたり、利用者が行うユーザ登録処理について説明する。図２６は、利用者によるユーザ登録処理を説明するためのシーケンス図である。
【０１６１】
ステップＳ２３０１にて、図２７に例示する利用者端末に表示されるユーザ登録画面から、利用者は、ユーザＩＤ、ユーザパスワード、及び支払い用パスワードを入力して送信する。ステップＳ２３０２において、ユーザＩＤ、ユーザパスワード、及び支払い用パスワードが代理サーバに送信され、代理サーバの管理するデータベースに格納される。代理サーバでは、受信したユーザＩＤに所定のハッシュ（ＨＡＳＨ）関数を適用してユーザＩＤのハッシュ値を計算してもよい。ここで、ユーザＩＤとは、好ましくは非公開のＩＤであり、通常はユーザＩＤのハッシュ値を認証に利用する。ただし、必要があればユーザＩＤの平文についても利用者に入力させるものとする。また、ユーザパスワード及び支払い用パスワードとは、利用者の認証のために、ユーザＩＤとともに入力するパスワードである。ただし、通常の購入時は、支払い用パスワードのみを利用するものとする。例えば、支払い用パスワードを紛失した場合や、管理データの換金等の場合において、ユーザパスワードを利用するものとする。さらに、代理サーバでは、利用者端末に対して仮端末識別子を自動的に発番し、仮端末識別子のハッシュ値を計算する。
【０１６２】
次に、ステップＳ２３０３において、ユーザＩＤのハッシュ値、仮端末識別子、及び仮端末識別子のハッシュ値が、代理サーバから利用者端末に送信される。これらの値は、利用者端末では例えば利用者端末のクッキー（Ｃｏｏｋｉｅ）として登録される。
【産業上の利用可能性】
【０１６３】
以上のように、本発明においては、金銭的な価値などと関連付けられた照合用データを含む管理データを、利用者端末又は代理サーバに保持し、利用者端末又は代理サーバにおいて処理された管理データを譲渡することにより、金銭的な価値などを譲渡することが電子的に行うことができる。これにより、管理データによる支払をインターネット上で行うことが可能となる。
【０１６４】
別の側面からさらに説明を加えると、従来技術において通常のブラウザを用いて支払を行う場合には、クレジットカードや銀行振込、プリペイドマネーであっても、支払を行う者が正当な利用者であることを確認するために、カード番号、ＩＤやパスワード、アクセスコードなどの入力が求められる。これらのカード番号、ＩＤやパスワード、アクセスコードなどが覚えやすいものであると、セキュリティが脆弱となるので、複雑なものであることが好ましいとされ、複雑なものであると、記憶することが困難となるなどにより、逆に不便なシステムとなってしまう。
【０１６５】
一方、本発明では、管理サーバにより発行された管理データを利用者端末又は代理サーバに格納し、必要に応じて、管理データを譲渡することにより価値の移転が行われる。管理データが有効なものであるかどうかは、管理サーバのデータベース部に管理データの照合用データの記録の有無により判断がされる、管理サーバを介して譲渡を行う都度、照合用データの書き換えが行われる。このため、管理データを所持しているものが正当な権利者であることが推定でき、ＩＤやパスワード、アクセスコードなどによって正当な所有者であることを証明する必要が低減でき、セキュリティを保ちつつ、利便性を維持することが可能となる。
【０１６６】
また、実施形態３などにおいて説明したように、ブラウザを用いてインターネットのウェブサイトを通じて購入などの申込を行った場合、サイトから送られる支払指示とセッションＩＤとを含む情報が、ブラウザから代理サーバに送信され、代理サーバを通じて支払処理を行うことができる。これにより、利用者端末には管理データが保持されないため、個々の利用者端末に何らかの問題が生じることにより管理データが失われるといった問題が生じない。また、一つのサーバシステムを構築すれば、一括して管理データの授受を管理することができ、セキュリティ対策やバックアップ運用、データ復旧等の障害対応についても一括して管理することができる。また、セッションＩＤはインターネットのサイトから送信されるため、利用者は従来技術であれば別途入力する必要のあった利用者の識別情報としてのセッションＩＤを入力する必要がなくなる。
【０１６７】
また、実施形態２などにおいて説明したように、管理データが表す価値に上限を持たせることもでき、管理データを紛失したとき際の損害が大きくならないようにすることができる。以上より、本願発明は、産業上有用である。
【符号の説明】
【０１６８】
１８００ 代理サーバ
１８０１ 利用者端末
１８０２ ユーザ情報管理部
１８０３ 支払処理部
１８０４ 管理データ管理部
１８０５、１８０７ 管理データ
１８０６ 所有者ＩＤ
１８０８ ブラウザ
【技術分野】
【０００１】
本発明は、電子マネーの決済、電子マネーやその他の電子的な価値情報の譲渡などの処理を行う処理装置、電子的な価値情報の処理方法などに関する。
【背景技術】
【０００２】
電子マネーやその他の電子的な価値情報は、ビット列などの情報に貨幣などの価値が関連付けられている。そのビット列などの情報の交換により決済などの価値の譲渡が実現される。そして、電子マネーは急速に普及しつつあり、交通機関の改札での運賃の支払いや店舗での商品の代金の決済の手段として用いられている。
【０００３】
ところで、電子マネーやその他の電子的な価値情報に関する技術については、ビット列などの情報は容易に複製されてしまうので、複製後に二重に使用されたことを検出する方法を備える必要がある（例えば、特許文献１参照。）。また、一般的に電子マネーは無記名であり、また、実際の貨幣とは異なり無体物であるため、紛失してしまった場合に被害が甚大となる可能性がある。そこで紛失などに備える必要がある（例えば、特許文献２参照。）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許４，９７７，５９５号明細書
【特許文献２】特開２００７−３１０５６２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１及び特許文献２に開示された技術に限らず、従来は、電子マネー等には暗号理論の利用が不可欠であると考えられている。暗号理論を用いることにより二重使用や紛失などの対策を取ろうとしている。このため、電子マネー等を利用するためには、利用者は特殊なＩＣカードやソフトウェア等を使用する必要があり、店舗などでは、そのＩＣカード等の読取り装置を備える必要がある。このため、電子マネー等の普及には莫大なコストが必要となる。また、個人間などの一般の利用者間での電子マネー等の譲渡も困難である。また、利用者は常にＩＣカードなどを所持する必要があり、紛失などの危険がある。
【課題を解決するための手段】
【０００６】
そこで、本発明では、二重使用を防止し、紛失したとしても復旧が可能であり、専用のＩＣカードやソフトウェアなど特別な装置を用いなくても譲渡が可能な電子的な価値情報を管理するサーバ装置などを提供する。
【０００７】
本発明の一実施形態として、管理サーバのデータベースにおいて価値と関連付けられている照合用情報を含む管理データと利用者の識別情報とをデータベースにより関連づける代理サーバと、利用者の利用者端末と、利用者から購入の申込を受けるショップサーバと、管理データを含む照合用情報に関連付けられている価値の移動を行う保管サーバを有する決済システムを提供する。
【０００８】
さらに、本発明の一実施形態として、管理サーバのデータベースにおいて価値と関連付けられている照合用情報を含む管理データと利用者の識別情報とをデータベースにより関連づける代理サーバと、利用者の利用者端末と、利用者から購入の申込を受けるショップサーバと、管理データを含む照合用情報に関連付けられている価値の移動を行う保管サーバの動作方法を提供する。
【発明の効果】
【０００９】
本発明の一実施形態により、二重使用を防止し、紛失したとしても復旧が可能であり、専用のＩＣカードやソフトウェアなど特別な装置を用いなくても流通が可能な電子的な価値情報の利用などを提供できる。また、特別な装置を用いる必要がないので、利用者は、ウェブサーバを介して決済処理を従来の技術よりも簡単に行うことができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の一実施形態に係る管理サーバの機能ブロック図である。
【図２】本発明の一実施形態における管理データ発行の具体例を説明する図である。
【図３】本発明の一実施形態に係る管理サーバの処理のフローチャートである。
【図４】本発明の一実施形態における照合用データの書き換えの具体例を説明する図である。
【図５】本発明の一実施形態に係る管理サーバの処理のフローチャートである。
【図６】本発明の一実施形態に係る管理サーバ、入金サーバ、保管サーバ及び利用者端末からなるシステム構成図である。
【図７】本発明の一実施形態に係る管理サーバ、入金サーバ、保管サーバ及び利用者端末からなるシステムによる処理のシーケンス図である。
【図８】本発明の一実施形態に係る保管サーバの機能ブロック図である。
【図９】本発明の一実施形態における管理データを保管するためのテーブルの一例図である。
【図１０】本発明の一実施形態における保管データ発行の具体例を説明する図である。
【図１１】本発明の一実施形態における保管データ発行の具体例を説明する図である。
【図１２】本発明の一実施形態に係る利用者間で管理データを譲渡するシステムの構成図である。
【図１３】本発明の一実施形態に係る利用者間で管理データを譲渡するシステムによる処理のシーケンス図である。
【図１４】本発明の一実施形態に係る利用者間で管理データを譲渡するシステムによる処理のシーケンス図である。
【図１５】本発明の一実施形態に係る代理サーバとショップサーバとの間で管理データを交換するシステムの概要を示す図である。
【図１６】本発明の一実施形態に係る代理サーバとショップサーバとの間で管理データを交換するシステムの構成図である。
【図１７】本発明の一実施形態に係る代理サーバ及び利用者端末の機能ブロック図である。
【図１８】本発明の一実施形態に係る代理サーバが有するテーブル構成の一例を示す図である。
【図１９】本発明の一実施形態に係る代理サーバとショップサーバとの間で管理データを交換するシステムによる処理のシーケンス図である。
【図２０】本発明の一実施形態に係る管理データを用いた支払処理における代理サーバの処理の流れを説明するフローチャートである。
【図２１】本発明の一実施形態に係る管理データの発行処理を説明するためのシーケンス図である。
【図２２】本発明の一実施形態に係る管理データの発行処理における入金サーバの処理の流れを説明するフローチャートである。
【図２３】本発明の一実施形態における利用者端末の画面表示を示す図である。
【図２４】本発明の一実施形態における利用者端末の画面表示を示す図である。
【図２５】本発明の一実施形態における利用者端末の画面表示を示す図である。
【図２６】本発明の一実施形態に係る利用者によるユーザ登録処理を説明するためのシーケンス図である。
【図２７】本発明の一実施形態における利用者端末の画面表示を示す図である。
【図２８】本発明の一実施形態における商品などの購入の申込を行うための画面の一例図である。
【図２９】本発明の一実施形態に係るショップサーバの構成図である
【発明を実施するための形態】
【００１１】
以下、本発明を実施するための最良の形態について実施形態として図を参照しつつ説明を行う。なお、本発明は以下の実施形態に限定されるものではなく、その要旨を逸脱しない範囲において種々なる態様で実施することができる。
【００１２】
（実施形態１）
（管理サーバ）
本発明の一実施形態において、管理サーバとは、電子的な価値情報の譲渡処理を主に行うサーバ装置である。管理サーバが行うその他の処理としては、管理サーバとして必須の処理ではないが、電子的な価値情報の発行処理、発行した電子マネー等に関連付けられた価値を貨幣などとして払い戻す処理などがある。
【００１３】
図１は、本発明の一実施形態に係る管理サーバの機能ブロック図を例示する。管理サーバ１００は、データベース部１０１と、発行要求受信部１０２と、生成部１０３と、生成管理データ送信部１０４と、管理データ受信部１０５と、置換部１０６と、置換管理データ送信部１０７とを有する。なお、管理サーバ１００の実現の一態様としては、コンピュータにソフトウェアを読み込ませ、ソフトウェアとハードウェア資源とが協働した具体的手段によって、使用目的に応じた情報の演算又は加工を実現することにより、使用目的に応じた特有の情報処理装置とするものがある。このような実現は、本発明の以下の説明に接した当業者により理解される。
【００１４】
データベース部１０１は、電子的な価値情報と価値との関連付けを管理する。本発明の一実施形態においては、電子的な価値情報は管理サーバ１００により管理などされるデータであるので、「電子的な価値情報」という用語のかわりに「管理データ」という用語を用いる。そして、本発明の一実施形態においては、管理データは照合用データを含み、この照合用データが価値そのものあるいは価値を表す情報と関連付けられる。また、照合用データは他の情報とも関連付けることができる。
【００１５】
照合用データと関連付けることができる他の情報としては、例えば、その照合用データを含む管理データの譲渡が行われた回数（譲渡回数）、その照合用データを含む管理データが、どの利用者やどの利用者の端末装置などに対して発行されたかを示す利用者や端末装置などの識別情報などが挙げられ、これらは必要に応じてデータベース部１０１に格納されてもよい。
【００１６】
また、管理データは、照合用データに加えて、管理データの所持者の識別情報や管理データの所持者の識別情報を含んでいてもよい。あるいは、管理データは、それらの識別情報のハッシュ情報を含んでいてもよい。このような情報を含ませることにより、管理情報の不正な使用を防止することができる。
【００１７】
本発明の一実施形態においては、図２（ａ）に示すように、照合用データが格納される列と価値の情報が格納される列とを有し、照合用データと価値の情報とを関連付けるテーブルを用意する。このテーブルは、関係データベースシステムなどの表データとしてデータベース部１０１によって管理される。なお、価値の情報を単に「価値情報」という場合がある。
【００１８】
照合用データは、充分に長いビット長の乱数として生成されるデータである。「充分に長い」とは、発行される管理データの中で同じ照合用データを有するものが存在しない、あるいは、実質的に存在しないことを意味する。例えば、１２８ビット、５１２ビット、１０２４ビット、２０４８ビットなど設計上などの必要に応じて任意の長さを決めることができる。
【００１９】
価値情報は、照合用データを含む管理データが表すことになる価値の内容などを示す。具体的な例としては、貨幣により表される価値を示す。この場合、価値の単位は、円、ドル、ユーロ、元などである。また、価値の情報は、貨幣と同等の価値を有する有価証券の証券番号、貴金属の量や保管の番号などであってもよい。また、運営者が独自に発行する価値を表わすポイント数などであってもよい。
【００２０】
発行要求受信部１０２は、管理データ発行要求１０８を受信する。管理データ発行要求１０８は、なんらかの価値が管理サーバやその運営者などに移転されたことあるいは移転されることを示す情報である。このため、管理データ発行要求１０８は、管理サーバ１００の運営者の支配する領域の内部で生成されたり、運営者と特別な関係（例えば親会社子会社の関係や特別な契約関係）にある者から送信されたりするのが好ましい。
【００２１】
図２（ｂ）は、管理データ発行要求の具体的な例を示す。この例では、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）による表現がされている。管理データ発行要求はＸＭＬ以外にも種々の表現形式があるが、以下では、ＸＭＬを例にして説明を行う。図２（ｂ）では、＜価値＞と＜／価値＞とで囲まれている１０００円が、発行される管理データが表すべき価値となっている。発行要求受信部１０２が、このような管理データ発行要求を受信する際には、管理データ発行要求の送信者の認証を行い、受信した管理データ発行要求をメモリに展開して正しい構文であるかどうかの確認を行い、＜価値＞と＜／価値＞とで囲まれている部分を特定して、次に説明する生成部１０３に伝達する。伝達は、例えば、生成部１０３を実現するソフトウェアモジュールなどの関数の引数に＜価値＞と＜／価値＞とで囲まれている部分のメモリアドレスを価値の情報として引数に指定するなどしてその関数を呼び出すことで行われる。
【００２２】
なお、管理データ発行要求には、照合用データと関連付けることができる他の情報が必要に応じて含まれていてもよい。
【００２３】
生成部１０３は、照合用データを準備し、準備された照合用データと発行要求受信部１０２から伝達された価値の情報とを、データベース部１０１で管理される図２（ａ）のテーブルに行データとして挿入する。「照合用データを準備する」とは、乱数を生成してその乱数を照合用データとすること、又は、予め生成しておいた乱数のリストなどから乱数を選択して照合用データとすることをいう。挿入が完了すると、生成部１０３は、生成管理データ送信部１０４へ、照合用データを伝達する。なお価値の情報も伝達されてもよい。
【００２４】
図２（ｃ）は、照合用データとして“１３５７１１”が準備されて、“１３５７１１”と１０００円とを図２（ａ）に示されるテーブルに挿入した直後の状態を示している。挿入が行われると、“１３５７１１”という照合用データが生成管理データ送信部１０４へ伝達される。
【００２５】
生成管理データ送信部１０４は、生成部１０３から伝達された照合用データから管理データ１０９を生成して送信する。管理データ１０９の送信先は、管理データ発行要求１０８を送信した装置であることが主に想定される。もし、管理データ発行要求１０８に、管理データ１０９の送信先が、電子メールアドレスやＩＰアドレスなどによって指定されていれば、その送信先へ管理データ１０９が送信される。送信は暗号化されて行われてもよい。
【００２６】
図２（ｄ）は、生成管理データ送信部１０４で生成され送信される管理データの一例を示す。生成部１０３から照合用データとして“１３５７１１”が伝達されたとすれば、“＜管理データ＞＜照合用データ＞１３５７１１＜／照合用データ＞＜／管理データ＞”という管理データが生成され、インターネットなどのネットワークなどに送信される。なお管理データには、上述したように、照合用データ以外のデータが含まれていてもよい。上述した例以外の例としては、照合用データがどれだけの価値、例えばいくらの貨幣価値、に関連付けられているかを示す情報が含まれていてもよい。例えば、管理データが“＜管理データ＞＜照合用データ＞１３５７１１＜／照合用データ＞＜価値＞１０００円＜／価値＞＜／管理データ＞”のように貨幣価値などを含むようになっていてもよい。また、照合用データと関連付けることができる他の情報が含まれていてもよい。また、譲渡回数が管理データに含まれる場合には、０などの初期値にリセットが行われて送信がされる。さらに、管理データが管理サーバ１００により生成されたことを検証できるようにするために、照合用データなどに対する管理サーバ１００による署名データが含まれていてもよい。
【００２７】
なお、価値として、貨幣価値のように可分な価値が用いられる場合には、管理データが表す価値に上限を設けてもよい。例えば、一つの管理データは、５０００円までの貨幣価値を表すことにする。そして、５０００円以上の価値を表す管理データは、複数の管理データを組み合わせることによって表す。このように管理データが表す価値に上限を設けることにより、管理データを紛失したときに生じる損失が大きくならないようにすることができる。この上限の値は、管理サーバ１００に設定され、生成管理データ送信部１０４が上限を超える価値と関連付けられた管理データを生成しないようにする。また後に管理データの数の増大を防止するために、管理データの価値を譲受ける側も管理データを保管サーバと呼ばれるサーバに提示することが開示される。この場合においても、管理データの価値を譲受ける側も管理データに上限の値を越える価値が関連付けられないように、管理サーバが動作することになる。
【００２８】
管理データが表す価値に上限を設ける場合には、管理データ発行要求がその上限を越える価値の管理データを発行することを表している場合には、上限以下の価値を表す管理データを複数発行する。このため、図２（ａ）などに示すテーブルに複数の行データが挿入される。
【００２９】
図３は、データベース部１０１、発行要求受信部１０２、生成部１０３、生成管理データ送信部１０４による処理の流れを説明するフローチャートを例示する。このフローチャートが例示する処理は、ハードウェアを制御可能なソフトウェアによる情報処理として実行可能である。
【００３０】
ステップＳ３０１の処理として、発行要求受信部１０２により管理データ発行要求を受信する。例えば、ハードウェアとしてのネットワークアダプタがデータを受信し割り込みが発生すると、割り込みハンドラが呼ばれて、データを読取り、読取りデータキューに入れる。そして、発行要求受信部１０２を実現するモジュールなどが発行していたＲＥＡＤシステムコールなどから処理が戻り、読取りデータキューに入れられたデータを管理データ発行要求としてメモリに展開する。
【００３１】
ステップＳ３０２の処理として、発行要求受信部１０２は、メモリに展開された管理データ発行要求から価値の情報のアドレスを特定などすることにより、価値の情報を取得する。取得された価値の情報は生成部１０３へ伝達される。
【００３２】
ステップＳ３０３の処理として、生成部１０３が照合用データを準備する。そしてステップＳ３０４の処理として、生成部１０３は、準備した照合用データと伝達された価値の情報を関連付けてテーブルに挿入して格納する。照合用データは生成管理データ送信部１０４へ伝達される。なお、「照合用データを準備する」とは、照合用データを生成したり、あらかじめ生成した照合用データの集合から取り出すことをいう。また、照合用データを準備するさいには、過去に準備された照合用データが準備されないのが好ましい。また、次に準備される照合用データの値が第三者から予測が困難であることが好ましい。このため、照合用データは乱数として準備されるのが好ましい。
【００３３】
ステップＳ３０５の処理として、生成管理データ送信部１０４は、伝達された照合用データから管理データを生成する。そして、ステップＳ３０６の処理として、ＷＲＩＴＥシステムコールなどを発行することにより、生成された管理データを送信する。ＷＲＩＴＥシステムコールなどの発行により、管理データが送信データキューに格納され、ネットワークアダプタがデータを送信可能な状態になると、割り込みが発生し、割り込みハンドラにより、送信データキューのデータが読み出されて、ネットワークなどに送信される。
【００３４】
このようにして送信された管理データは、専用のＩＣカードなどに限らず、通常のパーソナルコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）や携帯電話などのメモリに格納することができる。また、後述するように、ウェブサーバに格納し、利用者がそのウェブサーバに支払の命令などを送信することにより、使用することが可能となる。あるいは、フレキシブルディスク、光ディスク、不揮発性の半導体メモリなどの着脱可能な一般的な記憶媒体に記録することができる。そして、その記憶媒体を譲渡することにより、その記憶媒体に格納されている管理データが表す価値の譲渡を行うことができる。ただし、二重の譲渡を防止するために以下に説明するようにして譲渡するのが望ましい。
【００３５】
管理データ受信部１０５は、譲渡の対象などとなる管理データ１１０を受信する。受信された管理データ１１０は、管理サーバ１００のメモリに展開される。そして、管理データ１１０に署名データなどが含まれていれば、その署名データが正しいかどうかを判断してもよい。
【００３６】
置換部１０６は、管理データ受信部１０５で受信された管理データから照合用データを取得し、まず、その照合用データがデータベース部１０１で管理されているテーブルに格納されているかどうかを判断する。例えば、図２（ｃ）に示されるテーブルの照合用データの列に格納されているかどうかを判断する。もし、その照合用データが格納されていなければ、管理データ１１０の送信者などに、無効な照合用データを含む管理データが送信された旨を返信などする。反対に、その照合用データがデータベース部１０１で管理されているテーブルに格納されていれば、有効な照合用データを含む管理データであると判断する。有効な照合用データを含めば、新たな照合用データを準備し、この照合用データにより、管理データ１１０に含まれる照合用データとデータベース部１０１で管理されているテーブルに格納されている照合用データを置き換える。これにより、価値の情報に新たな照合用データが関連付けされる。
【００３７】
また、照合用データと関連付けられている他の情報があれば、その情報を用いてさらにチェックを行ってもよい。例えば、上述したように、利用者や端末の識別情報が照合用データと関連付けられていれば、管理データを管理データ受信部１０５に受信させた利用者や端末装置の識別情報を取得し、比較を行う。比較の結果がＯＫでなければ、無効である旨の返信などを行う。比較の結果がＯＫであれば、照合用データと関連付けられている識別情報と管理データに含まれている識別情報を、次に説明する置換管理データ送信部１０７による管理データの送信先となる利用者や端末装置の識別情報に書き換える。
【００３８】
管理データに譲渡回数が含まれている場合には、譲渡回数を更新する。また、更新前の譲渡回数が初期値を示していれば、置き換え前の照合用データがデータベース部１０１で管理されているテーブルに格納されているかどうかに加えて、照合用データと関連付けられている他の情報を用いたチェックを行ってもよい。例えば、その管理データを発行した際に受信された管理データ発行要求が存在するかどうかを管理サーバのログによりチェックを行ったり、実際に銀行などから金銭の振り込みが実際に行われたかどうかを銀行などのサーバ装置に問い合せたりしてもよい。もちろん、このようなチェックや問い合わせの処理は、管理データが管理サーバ１００に受信されるたびに行ってもよい。しかし、一般には、このようなチェックや問い合せの処理には時間が要する。そこで、このようなチェックや問い合せの処理の実行は、更新前の譲渡回数が初期値を示していたり、所定の値以下であったり、所定の値以上である場合に行うことに限ることで、処理の時間を短縮することが可能となる。また、異なるサーバに格納されたデータと照合を行うことにより、管理データの不正な作出などを検出することができる。
【００３９】
置換管理データ送信部１０７は、置換部１０６により、新たに準備された照合用データによりその照合用データが置換された管理データ１１１を送信する。管理データ１１１の送信は、管理データ１１０の送信元に対して行ってもよい。あるいは管理データ１１０の受信とともに送信先を示す情報が受信されたり、あるいは、管理データ１１０の中に送信先を示す情報が含まれていたりすれば、その送信先へ管理データ１１１を送信するようになっていてもよい。
【００４０】
例えば、データベース部１０１で管理されているテーブルに、図４（ａ）に示すように、照合用データとして“１３１７１９２”が９９５円という価値の情報と関連付けられて格納されているとする。この状態で、管理データ１１０として、図４（ｂ）に示すような照合用データとして“１３１７１９２”を含む管理データ１１０が管理データ受信部１０５により受信されたとする。すると、管理データ１１０に含まれる照合用データ“１３１７１９２”は、図４（ａ）のテーブルに格納されているので、管理データ１１０は有効な照合用データを含む管理データであると判断される。そこで、置換部は、新たな照合用データとして、例えば“１４９１６２５”を準備する。そして、この照合用データにより、図４（ａ）に示すテーブルの照合用データ“１３１７１９２”と図４（ｂ）に示す管理データに含まれる照合用データ“１３１７１９２”とを置き換える。この結果、図４（ａ）に示すテーブルは図４（ｃ）に示すようになり、図４（ｂ）に示す管理データ１１０は図４（ｄ）に示すようになる。この結果、図４（ｄ）に示す管理データが管理データ１１１として送信される。
【００４１】
なお、照合用データを置き換える際に、照合用データに関連付けられている価値情報の表す金額などのうち一定の額や一定の割合を控除するようにしてもよい。このように控除を行うことにより、管理サーバの運営者が管理サーバの運営などのための費用を得ることが可能となる。
【００４２】
なお、図４（ａ）に示すテーブルの照合用データの書き換えは、照合用データの列に格納されているデータに対する更新操作として実行してもよい。あるいは、書き換えの対象となる照合用データ（上の例での“１３１７１９２”）に関連付けられている価値の情報などを読出して一時的に記憶し、書き換えの対象となる照合用データを含む行を削除し、新たに準備された照合用データ（上の例での“１４９１６２５”）と一時的に記憶した価値の情報などを新たな行のデータとして格納されるようにテーブルに対するデータの挿入の操作として実行してもよい。また、更新操作として実行するのではなく、照合用データが削除されたことを示す列（削除フラグ）をテーブルに備えておき、書き換えの対象となる照合用データを格納する行の削除フラグの値を、その行が削除されたことを示す値に更新するとともに、準備された照合用データを含む行を新たにテーブルに挿入してもよい。また、テーブルに挿入される行には、書き換え前の照合用データが格納されていてもよい。これにより、不正などが発覚した場合に、書き換えの履歴をさかのぼることができる。
【００４３】
また、管理データの照合用データの書き換えは、その文言通り、メモリに展開されている管理データの部分のうち照合用データの部分を書き換えて実行してもよい。あるいは、新たに準備された照合用データを含む管理データを新たに生成してもよい。
【００４４】
図４（ｄ）に示す管理データが置換管理データ送信部１０７により送信された後、再度、図４（ｂ）に示す管理データが管理データ受信部１０５で受信されても、それに含まれる照合用データ１３１７１９２は、図４（ｃ）に示すテーブルに格納されていない（あるいは、削除フラグの列がテーブルに備わっている場合には、削除フラグの値が削除されたことを示す値になっている）。したがって、無効な照合用データを含む管理データと判断される。これにより管理データの二重使用を防止できる。
【００４５】
図５は、データベース部１０１、管理データ受信部１０５、置換部１０６、置換管理データ送信部１０７における処理の流れを説明するフローチャートを例示する。このフローチャートが例示する処理は、ソフトウェアによる情報処理として実現可能である（他の図面のフローチャート、シーケンス図により例示される処理も同様である。）。
【００４６】
ステップＳ５０１の処理として、管理データ受信部１０５により、管理データ１１０が受信される。その後、管理データ１１０がメモリに展開などされる。そして、ステップＳ５０２の処理として、置換部１０６により、メモリに展開された管理データ１１０より照合用データが取得される。取得された照合用データが、ステップＳ５０３の処理において、価値の情報と関連付けてデータベース部１０１に格納されていることを確認する。もし、格納されていなければ、管理データ１１０に無効な照合用データが含まれている旨のエラーの返信などをする。
【００４７】
ステップＳ５０４の処理として、新しい照合用データを準備する。そしてステップＳ５０５の処理として、管理データ１１０の照合用データを新しい照合用データに置き換える。「管理データ１１０の照合用データ」とは、メモリに展開された管理データ１１０に含まれる照合用データのみならず、ステップＳ５０３において価値のデータと関連付けて格納されている照合用データをも意味する。最後にステップＳ５０６の処理として、照合用データを書き換えられて得られる管理データ１１１を置換管理データ送信部１０７により送信する。
【００４８】
このように、乱数として発生された照合用データに価値を関連付け、管理データが通過するたびにその照合用データを置き換えることにより、管理サーバから送信される管理データの照合用データの予測がつかないようにすることができる。この結果、異なる照合用データに同じ価値が関連付けられることを防止でき、また、管理データの二重使用等を防止することができる。
【００４９】
（保管サーバ）
上述した管理サーバを用いることにより、乱数として発生された照合用データを含む管理データが発行され、有効な照合用データを含む管理データを送信し返信される管理データを受信することにより照合用データが書き換えられる。これにより、管理データの二重使用を防止することができる。以下では、さらに管理データの譲渡等を、匿名性を保ちながら行うために管理サーバの機能を拡張するためなどに用いられる保管サーバについて説明を行う。
【００５０】
図６は、管理サーバ６０１と、入金サーバ６０２と、保管サーバ６０３と、利用者端末６０４とからなるシステム６００の構成を示す。管理サーバ６０１と、入金サーバ６０２と、保管サーバ６０３と、利用者端末６０４とは、通信アダプタなどのハードウェアを用いて通信が可能となっている。システム６００においては、利用者端末６０４の利用者が、管理サーバ６０１で発行される管理データを得るために、利用者端末６０４と入金サーバ６０２との間で決済の処理を行う。例えば、入金サーバ６０２が銀行の振り込みを処理するサーバとなっており、利用者が管理サーバ６０１の運営者などの銀行口座に振り込みを行うことにより決済の処理が行われる。そして決済の処理が行われたことを示す結果が管理データ発行要求として入金サーバ６０２から管理サーバ６０１に送信されると、管理データが管理サーバ６０１に返信される。その後、管理データは入金サーバ６０３から保管サーバ６０３を経由して利用者端末６０４へ譲渡されてもよい。保管サーバ６０３は、管理データを入金サーバ６０２から受信すると、管理データの二重使用を防止するために、新たな照合用データに置き換えるために、管理サーバ６０１に管理データを送信し、照合用データが置き換えられた管理データを受信し保管する。その後、保管サーバ６０３は、利用者端末６０４から管理データの要求があれば、保管されている管理データを送信する。
【００５１】
もちろん、保管サーバ６０３が入金サーバ６０２を認証などして信頼できるのであれば、保管サーバ６０３は入金サーバ６０２から受信した管理データを管理サーバ６０１に送信する必要はない。しかし、もし保管サーバ６０３に送信された管理データが入金サーバ６０２内に消去されずに残り、入金サーバ６０２が不正な侵入などされてしまうと、不正に入金サーバ６０２にアクセスを行った者が管理データを入手してしまう可能性があるので、保管サーバ６０３は入金サーバ６０２から受信した管理データを管理サーバ６０１に送信するのが好ましいと言える。
【００５２】
図７は、システム６００における決済処理から管理データの利用者への譲渡までの処理の一例を説明するシーケンス図である。
【００５３】
ステップＳ７０１の処理として、利用者端末６０４と入金サーバ６０２との間で、管理データの発行のための決済の処理が行われる。例えば、利用者端末６０４よりクレジットカード番号等と決済金額を提示して、入金サーバ６０２がクレジットカード番号等の正しさを確認等する。あるいは、利用者端末６０４より銀行口座への振り込みの申込を行い、入金サーバ６０２が振込先の銀行口座番号や振込人に付加する識別文字列などを返信する。その後、振込が行われたことについての確認を入金サーバ６０２側にて行う。なお、決済処理により、利用者端末６０４から入金サーバ６０２へ利用者や利用者端末６０４の識別情報が入金サーバに伝達されてもよい。この場合、識別情報は、後に入金サーバ６０２から管理サーバ６０１へ送信される管理データ発行要求の中に含まれる。
【００５４】
本発明の一実施形態において、ステップＳ７０１の処理における決済処理を特定する番号などが決定され、この番号が入金サーバと利用者端末とで共有される。決済処理を特定する番号は、例えば、入金サーバが、生成する管理データを一意に識別する番号であったり、利用者端末６０４と入金サーバ６０２との間の通信のセッションを特定するセッションＩＤ（セッションを一意に特定するセッション識別情報）であったりしてもよい。この決済処理を特定する番号は、乱数として管理サーバが生成するのが好ましい。以下、決済処理を特定する番号として、セッションＩＤが用いられるとして説明を行う。ただし、本発明では、決済処理を特定する番号はセッションＩＤに限定されない。また、決済処理を特定する番号をＩＤ情報と称する場合がある。
【００５５】
クレジットカード番号等の正しさや振込等の確認がされると、ステップＳ７０２の処理として、入金サーバ６０２から管理サーバ６０１へ管理データ発行要求が送信される。この管理データ発行要求の中に、決済された金額などの情報が含まれる。なお、「決済された金額」は、利用者端末６０４と入金サーバ６０２との間での決済金額から所定の手数料を差し引いた額であってもよい。
【００５６】
管理データの発行要求に応じて、ステップＳ７０３の処理として、管理サーバ６０１から管理データ（「管理データ１」と呼ぶ）が入金サーバ６０２へ送信される。
【００５７】
ステップＳ７０４の処理として、入金サーバ６０２は、受信した管理データ１と上述のセッションＩＤとを保管サーバ６０３に送信する。
【００５８】
保管サーバ６０３が入金サーバより管理データ１とセッションＩＤを受信すると、ステップＳ７０５の処理として、受信した管理データを管理サーバ６０１へ送信し、管理データ１に有効な照合用データが含まれていることの確認と、その照合用データの置き換えを管理サーバ６０１に依頼する。
【００５９】
なお、管理サーバ６０１は、保管サーバ６０３より照合用データの書き換えが依頼された場合、譲渡回数は増加させない構成になっており、また、照合用データと関連付けられている識別情報と管理データに含まれている識別情報を書き換えない構成となっているとよい。例えば、保管サーバ６０３のＩＰアドレスが管理サーバ６０１に登録されており、登録されているＩＰアドレスから管理データを受信した場合には、譲渡回数を増加させず、識別情報も書き換えない構成となっていてもよい。
【００６０】
ステップＳ７０６の処理として、管理サーバ６０１にて、管理データ１に有効な照合用データが含まれていることを確認して照合用データを書き換えた管理データ２を生成し、保管サーバ６０３に返信される。そして、保管サーバ６０３にて、その管理データ２がセッションＩＤに関連付けて記憶される。
【００６１】
管理データ２がセッションＩＤに関連付けて記憶されたことを通知するために、ステップＳ７０７の処理として、保管通知が保管サーバ６０３から入金サーバ６０２へ送信される。
【００６２】
入金サーバ６０２が保管通知を受信すると、ステップＳ７０８の処理として、利用者端末６０４へ寄託通知が送信され、管理データが保管サーバ６０３に保管されたことが利用者に伝えられる。
【００６３】
その後、利用者は、利用者端末６０４を操作して、保管サーバ６０３に保管された管理データを要求するために、ステップＳ７０９の処理として、保管サーバ６０３に対して、管理データの送信要求として、セッションＩＤを送信してもよい。保管サーバ６０３では、セッションＩＤに管理データ２が関連付けて記憶されていることを確認すると、ステップＳ７１０の処理として、管理データ２を返信し、セッションＩＤとの関連付けを破棄してもよい。
【００６４】
もちろん、図６と図７とに示される構成、処理などを用いなくても、管理データを利用者に発行することができる。例えば、入金サーバが管理サーバから管理データを受信し、直接その管理データを利用者端末へ送信するようにしてもよい。しかし、決済手段として銀行振込を採用した場合などには、決済の確認までタイムラグが生じるので、入金サーバは管理サーバから受信した管理データを次に利用者端末と通信可能になるまで保持しておく必要がある。しかしこれでは、どの管理データが誰に発行されたかの情報を入金サーバが知ることとなり、匿名性が損なわれる。
【００６５】
また、入金サーバが管理データの発行要求とともに管理データの送信先を管理サーバに送信し、管理サーバがその送信先に発行した管理データを送信する構成を採用することもできる。しかし、これでも、管理データが誰に発行されたかの情報を管理サーバが知ることとなり、やはり匿名性が損なわれる。
【００６６】
図６と図７とに示される構成、処理では、管理サーバ６０１は、どの利用者の利用者端末に対して管理データを発行して送信するか知る必要がなくなる。また、入金サーバ６０２は利用者端末６０４と管理サーバ６０１から送信される管理データを関連付けることはできるが、それは一時的なものに過ぎない。管理データを保管サーバ６０３に送信すると、保管サーバ６０３側で照合用データが書き換えられてしまうからである。また、保管サーバ６０３は、管理データを入金サーバ６０２と利用者端末６０４との通信セッションにより決まる情報と関連付けるので、利用者を識別する必要がない。
【００６７】
図８は、保管サーバ６０３の機能ブロック図を示す。図８の機能ブロック図において、保管サーバ８００は、預管理データ受信部８０１と、管理データ送信部８０２と、管理データ受信部８０３と、保管部８０４と、ＩＤ受信部８０５と、預管理データ送信部８０６と、命令部８１１とを有する。
【００６８】
預管理データ受信部８０１は、管理データ８０７とＩＤ８０８とを受信する。管理データ８０７とＩＤ８０８とは、図７のステップＳ７０４においての説明での入金サーバから保管サーバへ送信される管理データ１とセッションＩＤとに相当する。ただし、後に説明されるように、預管理データ受信部８０１は、管理データ８０７とＩＤ８０８を入金サーバのみより受信するとは限らない。
【００６９】
ＩＤ８０８は、管理データ８０７を一意に特定する情報であることが望ましい。このため、預管理データ受信部８０１は、受信したＩＤの履歴を管理し、過去に受信したＩＤと一致するものを受信した場合には、ＩＤの再送要求を返信してもよい。また、受信したＩＤの履歴は、後に説明される保管部８０４が管理するテーブルなどで管理することもできる。すなわち、保管部８０４が管理するテーブルに同じＩＤが格納されていればＩＤの再送要求を返信してもよい。
【００７０】
預管理データ受信部８０１は、受信した管理データ８０７とＩＤ８０８とをメモリに展開する。そして、管理データ８０７のメモリアドレスなどを管理データ送信部８０２へ渡すことにより管理データ８０７を伝達し、ＩＤ８０８のメモリアドレスを保管部８０４へ渡すことによりＩＤ８０８を伝達する。
【００７１】
管理データ送信部８０２は、預管理データ受信部８０１より伝達された管理データ８０７を送信する。送信先は、管理サーバである。送信の結果、管理サーバにて管理データ８０７に含まれる照合用データの有効性が確認されると、照合用データの書き換えが行われ、書き換え後の管理データ８０９が返信される。
【００７２】
管理データ受信部８０３は、管理データ送信部８０２からの管理データ８０７の送信に応じて管理サーバより返信される管理データ８０９を受信する。上述したように管理データ８０７の少なくとも照合用データが置き換えられたものが管理データ８０９となっている。管理データ受信部８０３は、受信した管理データ８０９をメモリに展開し、そのメモリアドレスなどを保管部８０４に渡すことにより、管理データ８０９を伝達する。
【００７３】
保管部８０４は、預管理データ受信部８０１より伝達されたＩＤ８０８と管理データ受信部８０３より伝達された管理データ８０９とを関連付けて保持する。ＩＤ８０８と管理データ８０９とは、異なる時に保管部８０４に伝達される。このために、保管サーバ８００は、例えば預管理データ受信部８０１が受信した管理データ８０７とＩＤ８０８とに一意の識別情報を付与するようにしてもよい。そして、預管理データ受信部はＩＤ８０８とともにその一意の識別情報を保管部８０４に伝達する。また、管理データ送信部８０２が管理データ８０７を送信するために管理サーバと通信セッションを開始するとその通信セッションをその一意の識別情報と関連付ける。そして、管理データ８０９が受信されると、通信セッションから一意の識別情報を取得し、管理データ受信部８０３は、管理データ８０９とともにその一意の識別情報を保管部８０４に伝達する。これにより、保管部８０４では、ＩＤ８０８と管理データ８０９とを関連付けることができる。また、保管サーバ８００が付与した一意の識別情報が管理データ８０７に含まれて送信されるようになっていてもよい。管理サーバは、その一意の識別情報を変更することなく、照合用データを書き換える。
【００７４】
保管部８０４は、ＩＤと管理データとを関連付けて保管するためにテーブルを用いてもよい。図９はそのようなテーブルを示している。図９では、“ｅ９８７ａｂｃ”というＩＤと照合用データとして“１４９１６２５”を含む管理データとが関連付けて保持されている。“ｅ９８７ａｂｃ”というＩＤは、例えば図７におけるステップＳ７０１の処理として行われる決済処理のための利用者端末と入金サーバと間の通信セッションのＩＤなどである。
【００７５】
なお、保管部８０４にＩＤ８０８と管理データ８０９とが関連付けて格納された場合、ステップＳ７０７の保管通知となる情報が送信されるようになっていてもよい。この保管通知は、例えば、預管理データ受信部８０１が管理データ８０７とＩＤ８０８とを受信したＡＣＫとして返信されるようになっていてもよい。
【００７６】
ＩＤ受信部８０５は、ＩＤ８１０を受信し、ＩＤ８１０と保管部８０４にて関連づけて保管されている管理データの検索を行う。検索の結果、ＩＤ８１０と関連付けて保管されている管理データが存在すれば、ＩＤ受信部８０５はその管理データを読出し、預管理データ送信部８０６へ伝達する。また、ＩＤ８１０とその管理データとの関連付けを解消あるいは破棄する。解消あるいは破棄は、具体的には、図９に示すテーブルからＩＤ８１０が格納されている行データを削除することにより実現される。あるいは、図９に示すテーブルに削除フラグを格納する列を設けて、削除されたことを示す値を格納することで、解消あるいは破棄されたことを表現するようになっていてもよい。
【００７７】
預管理データ送信部８０６は、ＩＤ受信部８０５から伝達された管理データを送信する。管理データの送信先は、ＩＤ８１０の送信元であることが想定される。ただし、管理データの送信先がＩＤ８１０とともにＩＤ受信部８０５により受信されたなどの場合には、その送信先へ管理データを送信するようになっていてもよい。
【００７８】
図１０は、保管サーバ８００における管理データとＩＤとを受信し保管するまでの処理の流れを説明するフローチャートの一例である。ステップＳ１００１の処理として、預管理データ受信部８０１により、管理データとＩＤとを受信する。ステップＳ１００２の処理として、その管理データを、管理データ送信部８０２により、管理サーバへ送信する。そしてステップＳ１００３の処理として、管理データ受信部８０３により、管理データを受信する。その後、ステップＳ１００４の処理として、保管部８０４により、ステップＳ１００１で受信されたＩＤとステップＳ１００３で受信された管理データを関連付けて保管する。
【００７９】
図１１は、保管サーバ８００におけるＩＤを受信しそのＩＤと関連付けられて保管されている管理データを送信するまでの処理の流れを説明するフローチャートの一例である。ステップＳ１１０１の処理として、ＩＤ受信部８０５により、ＩＤを受信する。ステップＳ１１０２の処理として、そのＩＤと関連付けられて管理データが保管部８０４に保管されていることを確認する。もし確認できなければ、エラーをＩＤの送信元などに返信する。確認ができれば、ステップＳ１１０３の処理として、ＩＤと関連づけて保管されている管理データを読み出す。そして、ステップＳ１１０４の処理として、ＩＤと管理データとが関連付けられて格納されている状態を解消する。例えば、図９に示されるテーブルから上述にように行データを削除する。その後ステップＳ１１０５の処理として、預管理データ送信部８０６により、管理データを送信する。
【００８０】
このような構成の保管サーバを、図６、図７に示すように入金サーバと管理サーバとを組み合わせることにより、匿名性を保ちつつ管理データの発行が行える。
【００８１】
また、このような保管サーバを経由することにより、利用者間でも管理データを譲渡することができる。「利用者間」と記載したが、この場合、一方の利用者は物やサービスを購入する者であり、他方はその物やサービスを提供する者であり、その物やサービスの対価として管理データが一方の者から他方の者へ譲渡される場合が想定される。特に、他方はＷＥＢサーバなどを用いてインターネットからアクセスされる仮想的な店舗であってもよい。すなわち、管理データを電子マネーとして使用することにより、財物や役務の提供に対する代金の決済処理を行うことができる。すなわち、保管サーバが決済処理を行うサーバとして動作することになる。また、保管サーバを用いることにより、個人間などの一般の利用者間でも管理データの譲渡をすることが可能となる。
【００８２】
図１２は、利用者間で管理データを譲渡するシステム１２００の構成を示す。システム１２００を参照しながら、管理サーバ１２０１と、保管サーバ１２０３と、譲渡者端末１２０４と、譲受者端末１２０５とを有する。譲渡者端末１２０４の利用者（譲渡人）が譲受者端末１２０５の利用者（譲受人）へ管理データを譲渡する場合の処理の流れについて以下に説明する。
【００８３】
譲渡人は、あらかじめ、管理サーバから管理データの発行を受けたり、入金サーバを介して管理データを取得したり、入金サーバと保管サーバを介して管理データから取得したりしておく。あるいは別の譲渡人より、管理データの譲渡を受ける。この場合の譲渡としては、これから説明されるように保管サーバを介して行われてもよいし、別の譲渡人から管理データが記録された光ディスクや可搬型の不揮発性半導体メモリなどの記憶媒体の譲渡を受けたり、電子メールの添付データなどとして譲渡を受けたりしていてもよい。
【００８４】
図１３は、保管サーバを介しての管理データの譲渡の流れを説明するシーケンス図である。ステップ１３０１の処理として、譲渡者端末１２０４と譲受者端末１２０５との間で管理データの譲渡の合意をする。この合意は、無償にて譲渡人が譲受人に管理データを譲渡する合意であったり、上述のように譲受人が物やサービスを提供することの引き替えに譲渡人が管理データを譲渡する合意であったりする。なお、この合意のために、譲渡人の使用する譲渡者端末（第１の端末）と譲受人の使用する譲受者端末（第２の端末）とが相互に認証し合ってもよい。例えば、暗号化された通信セッションを確立するために第１の端末と第２の端末との間で暗号化と復号化のための暗号鍵を共有する。
【００８５】
また、相互認証の際には、その相互認証を一意に特定する情報を決める。例えば、ＷＥＢショップで買い物などを行う場合には、ＷＥＢサーバと端末との間の暗号化された通信セッションのＩＤなどを用いる。
【００８６】
譲渡の合意あるいは相互認証が終了すると、譲渡人側の端末は新たに管理データの発行を受けたり、既に発行がされたり第三者から譲渡がされたりした管理データの中から選択を行い、管理データ３とセッションＩＤとを保管サーバ１２０３へ送信する。管理データ３とセッションＩＤとを受信した保管サーバは、ステップＳ１３０３の処理として管理データ３を管理サーバへ送信する。管理サーバが管理データ３に含まれる照合用データが有効であると確認を行うと、新たに準備した照合用データによる置換を行い、ステップＳ１３０４の処理として管理データ４を保管サーバへ返信する。これにより、管理データ３は無効な照合用データを含む管理データとなり二重に使用ができなくなる。
【００８７】
保管サーバが管理データ４を受信すると、ステップＳ１３０２で受信したセッションＩＤと関連付けて保管を行い、ステップＳ１３０５の処理として保管通知を譲渡者端末へ送信する。保管通知を受信した譲渡者端末は、ステップＳ１３０６の処理として、寄託通知を譲渡者端末へ送信する。
【００８８】
寄託通知を受信した譲受者端末は、ステップ１３０７の処理として、管理データの送信要求を譲渡合意の際のセッションＩＤとともに保管サーバへ送信し、これに応じて保管サーバは管理データ４をステップＳ１３０８の処理として返信してもよい。
【００８９】
以上のように保管サーバを構成することにより、管理データの発行の際、そして、管理データの譲渡の際に同じ処理を保管サーバで行うようにすることができる。また、管理データの匿名性なども確保できる。
【００９０】
（実施形態２）
上述の実施形態１において、価値として貨幣価値のように可分な価値が用いられる場合には、管理データが表す価値に上限を設けてもよいことについて説明した。例えば、５０００円を上限とすると、１３０００円の価値は、例えば、５０００円を表す管理データ２つと、３０００円を表す管理データ１つとにより表される。この場合の３０００円を表す管理データのように、上限の価値に満たない価値を表す管理データを「端数管理データ」と呼ぶことにする。
【００９１】
管理データを用いて商品や役務の代金の決済が行われる場合を考えると、代金の額が上記でいう上限になるとは限らない。このため、端数管理データを含む管理データにより代金が支払われたり、釣り銭の代わりに端数管理データを含む管理データが支払いとは逆の方向の管理データの流れで譲渡されたりする。このため、端数管理データの数は増加することになる。この結果、管理サーバのデータベース部の管理するデータが増加してしまうなどの問題が生ずる。そこで、以下では、端数管理データの増加を防ぐ構成について説明を行う。
【００９２】
（管理サーバ）
本実施形態に係る管理サーバは、実施形態１に係る管理サーバ１００において、管理データ受信部１０５が端数管理データ受信手段と、支払額受信手段とを有し、置換部１０６が端数変更手段と、釣管理データ生成手段とを有し、置換管理データ送信部１０７が端数管理データ送信手段と、釣管理データ送信手段とを有する。
【００９３】
端数管理データ受信手段は、端数管理データを受信する手段である。受信された端数管理データは、他の一または複数の管理データとともに、保管サーバより送信され管理サーバに受信され照合用データの有効性の確認がされることが主に想定される。端数管理データ受信手段は、端数管理データを受信するとメモリに展開し、端数管理データに含まれる照合用データのアドレスなどを取得して、端数変更手段に伝達する。
【００９４】
支払額受信手段は、管理データ受信部１０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データの表す価値のうち、譲渡が行われる価値を表す。すなわち、保管サーバを経由して譲渡者端末から譲受者端末へ譲渡されるべき価値を表すことが主に想定される。そして、譲渡が行われない価値が存在すれば、その価値は後述のように釣管理データとして譲渡者端末へ送信されることになる。
【００９５】
端数変更手段は、支払額受信手段が受信した価値を上述の上限の価値で除算を行った時の余りが０で無い場合に、端数管理データ受信手段により受信された端数管理データの表す価値にその余りを加算する処理を行う。例えば、上限額が５０００円で支払額受信手段が受信した価値が１３０００円であれば、１３０００円を５０００円で割り算を行うと、３０００円が余りとなる。そこで、端数管理データ受信手段が受信した端数管理データがデータベース部１０１により、１０００円を表していれば、１０００円に３０００円を加算した４０００円を表すようにデータベース部１０１が管理するデータベースの変更操作などを行う。
【００９６】
具体的には、端数変更手段は、端数管理データ受信手段から伝達されたアドレス等により指定される照合用データで図２（ａ）などに示されるテーブルの検索を行いその照合用データがテーブルに格納されているのを確認すると、その照合用データに関連付けられている価値の値に上述の余りを加算する。加算した結果がもし上述の上限を超えていれば、加算した結果のかわりに上限の価値をテーブルに登録し、新たに照合用データを準備してテーブルに挿入し、加算した結果から上述の上限を引いた額を関連付ける。例えば、端数管理データ受信手段から伝達されたアドレス等により指定される照合用データに１０００円が関連付けられており、上述の余りが４５００円であったとする。すると加算した結果は５５００円となり、上限の５０００円を超えている。そこで、端数管理データ受信手段から伝達されたアドレス等により指定される照合用データには上限の５０００円を関連づけ、新たに準備される照合用データには５００円を関連付ける。もちろん、５０００円と５００円とに関連付けるのは一例であり、５５００円の上限を超えないように複数の価値に任意に分けることができる。例えば、２５００円と３０００円とであってもよい。
【００９７】
釣管理データ生成手段は、管理データ受信部１０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データの表す価値のうち、支払額受信手段が受信した価値を引いた価値（「釣価値」という。）が０でなければ、釣価値を表す管理データを生成する。新たに管理データを生成してもよいし、管理データ受信部１０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データを再利用するように、その管理データが表す価値に釣価値を加えてもよい。そして、もし加えた結果が上限を超えていれば、新たな管理データを生成して、管理データに上限を超える価値が関連付けられないようにする。
【００９８】
端数変更手段、釣管理データ生成手段それぞれは、端数管理データ受信手段が受信した端数管理データが含む照合用データ、釣管理データ生成手段が生成した釣価値を表す管理データが含む照合用データのそれぞれを、新たな照合用データを準備して書き換えてもよい。
【００９９】
端数管理データ送信手段は、端数変更手段により価値が加算された管理データ、また必要に応じて新たに生成された管理データを送信する。
【０１００】
釣管理データ送信手段は、釣管理データ生成手段で生成された管理データを送信する。
【０１０１】
また、本実施形態において、保管サーバの預管理データ受信部８０１は、管理データ及びＩＤとともに、支払額情報を受信可能となっている。支払額情報とは、管理データの譲渡により譲渡されるべき価値を示す情報である。そして、預管理データ受信部８０１は、支払額情報が受信された場合には、受信したＩＤに関連付けられて保管部８０４に保管されている管理データを検索し、得られた管理データと受信した管理データとともに支払額情報を管理データ送信部８０２に伝達する。この場合、受信したＩＤに関連付けられて保管部８０４に保管されている管理データは、譲受者端末より送信された端数管理データとなっている。管理データ送信部８０２は、管理データとともに伝達された支払額情報を送信する。
【０１０２】
また、管理データ受信部８０３は、釣管理データも受信可能となっている。釣管理データが受信された場合には、保管サーバは、保管部８０４に管理データが保管されると、保管通知とともに釣管理データを、預管理データ受信部８０１が受信した管理データの送信元へ返信する。
【０１０３】
図１４は、本実施形態において、保管サーバを介しての管理データの譲渡の流れの一例を説明するシーケンス図である。ステップＳ１４０１の処理として、ステップＳ１３０１と同様に譲渡の合意を譲渡者端末と譲受者端末との間で行う。このとき、その合意では、単に管理データの譲渡のみならず、管理データの譲渡により譲渡される価値も合意する。例えば、商品の値段、送料などである。そして、このような場合に譲渡者端末が保管サーバへ送信する管理データを支払管理データという。
【０１０４】
ステップＳ１４０２の処理として、譲受者端末から保管サーバへ、端数管理データ１とセッションＩＤとを保管サーバへ送信する。このとき、譲受者端末である旨の情報も送信してもよい。ステップＳ１４０３の処理として、保管サーバは、受信した端数管理データ１を管理サーバへ送信し、その有効性を確認させ、ステップＳ１４０４の処理として、保管サーバは、端数管理データ２を管理サーバより受信する。そして、セッションＩＤと関連づけて端数管理データ２を保管する。
【０１０５】
なお、譲受者端末に端数管理データが無ければ、保管サーバには端数管理データを送信する必要はなく、したがって、保管サーバが端数管理データを管理サーバに送信する必要もない。
【０１０６】
譲渡者端末は、ステップＳ１４０５の処理として、支払額と支払いのための支払管理データ１とセッションＩＤを保管サーバに送信する。保管サーバは、支払管理データ１と支払額とを管理サーバに送信する。また、保管サーバは、図８に図示する命令部８１１にて、セッションＩＤからそれに関連付けられている端数管理データの有無を検出し、もしそのような端数管理データが存在すれば、その端数管理データもともに端数管理データ２として管理サーバへ送信する。
【０１０７】
なお、ステップＳ１４０２において、譲受者端末から譲受額が送信されてもよく、この場合は、譲渡者端末から送信される支払額と譲受額とが同じであることを確認してもよい。もし、同じでなければ譲受者端末、譲渡者端末へエラーを通知する。また、ステップＳ１４０２において、譲受者端末から譲受額が送信され、ステップＳ１４０５において、譲渡者端末から支払額が送信されない構成もある。この場合には、支払管理データ１に関連付けられている価値の値が譲受額以上であることを確認する。もし、譲渡に伴って手数料などを徴収する際には、支払管理データ１に関連付けられている価値の値から手数料などの額の値を引いたものが譲受額以上であることを確認する。また、端数管理データ１に関連付けられている価値から手数料などの額を徴収することにしてもよい。
【０１０８】
管理サーバは、ステップＳ１４０６の処理として受信した支払管理データ１、支払額、端数管理データ２から、置換部１０６、置換管理データ送信部１０７により、端数管理データ３と支払管理データ２と釣管理データとを生成して、ステップＳ１４０７の処理として、保管サーバへ送信する。ここで、端数管理データ３は、端数変更手段で変更、生成された管理データであり、釣管理データは釣管理データ生成手段で生成された管理データである。
【０１０９】
端数管理データ３と支払管理データ２と釣管理データとを受信した保管サーバは、支払管理データ３と端数管理データをステップＳ１４０２又はＳ１４０５で受信したセッションＩＤと関連づけて保管する。そして、ステップＳ１４０８の処理として、譲渡者端末へ釣管理データと保管通知を送信する。譲渡者端末は、ステップＳ１４０９において寄託通知を譲受者端末へ送信し、譲受者端末はステップＳ１４１０において、送信要求とセッションＩＤとを保管サーバへ送信し、これに応じて保管サーバは、セッションＩＤと関連付けて保管されている端数管理データ３と支払管理データ２をステップＳ１４１１の処理として、譲受者端末へ送信してもよい。そして、セッションＩＤと端数管理データ３及び支払管理データ２との関連付けを破棄してもよい。
【０１１０】
このようにして、譲渡者端末から譲受者端末へ、譲渡合意で合意された価値が電子的に譲渡される。また、本実施形態では、管理データが表す価値に上限を設けられている場合に、譲受者端末から端数管理データを提供することにより、その端数管理データに釣り銭に相当する価値を加えることができ、端数管理データの数の増大を防止することができる。これにより、管理サーバのデータベース部１０１で管理するべき照合用データの数の増加を防止することができる。なお、「譲受者端末」と記載したが、譲受者端末は端末装置と同等の機能を有していればよく、サーバ装置を端末装置として用いられる場合も含まれる。譲渡者端末についても同様である。
【０１１１】
（実施形態３）
本発明の実施形態３として、代理サーバとショップサーバとが管理データを交換するシステムについて説明する。ここで、代理サーバとは、利用者（消費者）に対して発行された管理データを管理するサーバであり、ショップサーバとは、物品の販売やサービスの提供を行うためのサーバである。本実施形態では、主に利用者が利用する利用者端末にインストールされたブラウザなどを介して発行される指示によって代理サーバがショップサーバへ管理データを送信させ、その管理データを受信したショップサーバが利用者に対して物品の販売やサービスの提供を行う形態について説明する。
【０１１２】
図１５は、本発明の実施形態３に係るシステムの概要を示す図である。システム１５００においては、利用者端末１５０２が、インターネットなどの通信網１５０１を介して、ショップサーバ１５０３及び代理サーバ１５０４と通信を行う。また、必要に応じて、ショップサーバ１５０３と代理サーバ１５０４とが通信を行うことができるようになっていてもよい。
【０１１３】
利用者端末１５０２は、商品や役務などの購入者である利用者が商取引を行うために用いる電子機器である。ショップサーバ１５０３は、利用者端末１５０２の利用者から商品、役務などの購入の申込を受け付け、利用者端末１５０２との決済処理を行うための装置である。代理サーバ１５０４は、利用者端末１５０２の利用者に発行された管理データを利用者端末１５０２の代わりに保持し、利用者端末１５０２を代理してショップサーバとの決済処理を行うための装置である。なお、決済処理は、商品や役務などの対価として行われる必要はなく、利用者が他の者に価値を贈与する場合にも行われてよい。
【０１１４】
なお、ショップサーバ１５０３と代理サーバ１５０４とは同じサーバ装置として実現されていても良い。この場合には、利用者端末１５０２にインストールされているブラウザが、そのサーバ装置のうちショップサーバ１５０３に相当する部分と代理サーバ１５０４に相当する部分とにアクセスするＵＲＬが異なっていればよい。例えば、ＵＲＬのパスの部分が異なっていればよい。あるいは、ショップサーバ１５０３と代理サーバ１５０４として動作するサーバ装置が複数のドメインを有し、一つのドメインがショップサーバ１５０３に割り当てられており、他のドメインが代理サーバ１５０４に割り当てられていればよい。
【０１１５】
図１６は、本発明の実施形態３に係るシステム１６００の全体の構成を示す。システム１６００は、利用者端末１６０１と、入金サーバ１６０２と、代理サーバ１６０３と、ショップサーバ１６０４と、決済機関サーバ１６０５と、発行サーバ１６０６と、管理サーバ１６０７と、保管サーバ１６０８とを有する。利用者端末１６０１と、入金サーバ１６０２と、代理サーバ１６０３と、ショップサーバ１６０４と、決済機関サーバ１６０５と、発行サーバ１６０６と、管理サーバ１６０７と、保管サーバ１６０８とは、それぞれ通信アダプタなどのハードウェアを備え、通信を行う。なお、上述したように、複数のサーバが同じサーバ装置として実現されてもよい。例えば、入金サーバ１６０２と、代理サーバ１６０３と、発行サーバ１６０６と、管理サーバ１６０７と、保管サーバ１６０８とが同じサーバ装置として実現されていてもよい。
【０１１６】
ショップサーバは、図２９に例示するように、利用者端末より購入の申込情報を受信する受信部２９０４と、受信された購入の申込情報に基づいて、利用者端末の利用者が支払う価格の情報を利用者端末へ返信する返信部２９０３と、管理データを保持する管理データ保持部２９０２と、管理データ保持部２９０２にて保持される管理データを価格の情報とともに保管サーバへ送信する送信部２９０１とを有する。
【０１１７】
図１７は、本発明の実施形態３に係る代理サーバ及び利用者端末の機能ブロック図である。代理サーバ１８００は、ユーザ情報管理部１８０２と、支払処理部１８０３と、釣受信部１８０９と、管理データ管理部１８０４とを有する。利用者端末１８０１には、ブラウザ１８０８がインストールされている。
【０１１８】
ユーザ情報管理部１８０２は、利用者端末１８０１の利用者を識別するためのユーザ情報を管理する。例えば、ユーザ情報として、利用者端末１８０１のブラウザに表示されるウェブページから利用者が入力されるユーザＩＤやパスワードなどの認証情報に基づいてユーザを認証する。また、新たに代理サーバ１８００を利用するユーザの登録の処理を行う。
【０１１９】
図１８（ａ）は、ユーザ情報管理部１８０２が保持するテーブル構成の一例を示す図である。図１８（ａ）は、ユーザ情報が格納されたテーブルであり、図１８（ａ）に示すように、「所有者ＩＤ」、「ユーザＩＤ」、「パスワード」、「属性」といった名前の列により構成される。本実施形態では、図１８（ａ）に示すユーザ情報テーブルは、ユーザ情報と所有者ＩＤ（所有者識別情報）とが関連づけられ、ユーザ情報管理部１８０２にて管理される。ここで、管理とは、データのファイルへの書き込み、読み出し、削除、更新を意味する。所有者ＩＤとは、管理データを所有している者を識別するＩＤである。管理データを所有している者とは、管理データが表す価値が帰属する権原を有している者をいう。
【０１２０】
所有者ＩＤとしては、例えば、管理サーバなどで発行されたＩＤ、電子メールアドレス、住民票コード、公開鍵証明書など、人を識別できる情報を、管理サーバから代理サーバにデータ連携して、図１８（ａ）に示すユーザ情報テーブルにおいて所有者ＩＤとして用いてもよい。そして、ユーザ情報管理部１８０２は、所有者ＩＤにパスワードなどを関連付けて保持するなどして、代理サーバ１８００に所有者ＩＤを提示してアクセスしてきた者を認証できるようにしておくのが好ましい。なお、所有者ＩＤ、パスワードをそのまま図１８（ａ）に示すテーブルに格納する必要はなく、所有者ＩＤ、パスワードのそれぞれのハッシュ値を算出し、そのハッシュ値を格納してもよい。なお、ハッシュ値とは不可逆的な演算を行う関数により得られる値である。不可逆的とは、関数の出力から入力を計算する逆関数の計算を行うことが事実上不可能であることをいう。このような関数としては、ＳＨＡ−１（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｍ−１）などが知られている。なお、以下では、ある値とそのハッシュ値とは均等データとして扱う場合がある。
【０１２１】
代理サーバ１８００における管理データ管理部１８０４は、保管サーバから、管理データ１８０５と所有者ＩＤ１８０６（あるいは所有者ＩＤ１８０６の均等データ）とを受信する。なお、管理データ１８０５と所有者ＩＤ１８０６とは、図７のステップＳ７０４での説明等における入金サーバから保管サーバへ送信される管理データ１とセッションＩＤとそれぞれに相当してもよい。この場合、入金サーバは、利用者端末との決済処理Ｓ７０１を行うときに、利用者端末の利用者を認証し、ユーザＩＤあるいはその均等データを得て、セッションＩＤとして用いる。なお、入金サーバが利用者端末の利用者を認証する場合には、代理サーバと通信を行い、利用者端末の利用者を認証するようになっていてもよい。
【０１２２】
受信された管理データ１８０５及び所有者ＩＤ（あるいはその均等データ）１８０６は、管理データ管理部１８０４が管理するテーブルに格納される。管理データ管理部１８０４は、図１８（ｂ）に示されるような管理情報テーブルを管理する。図１８（ｂ）に図示されるように、管理情報テーブルは、「所有者ＩＤ」、「管理データ」といった名前の列より構成される。本実施形態では、図１８（ｂ）に図示される管理情報テーブルにおいて、「管理データ」の列には、管理情報テーブルとは異なる別のテーブルや記憶領域に格納された管理データにアクセスするための記憶領域のアドレスが格納されている。そのため、図１８（ｂ）において、「管理データ」の列に格納されたアドレスを、管理データにアクセスする様子への矢印として図示している。管理データ管理部１８０４に保持されている管理データのアドレスは、管理データを用いた支払の処理等の際に、読み出し、削除、変更が行われる。
【０１２３】
代理サーバ１８００における支払処理部１８０３は、利用者端末１８０１の送信する、管理データによる支払を指示する情報が受信された際に、利用者端末１８０１を代理して支払処理を行うための部である。支払処理部１８０３は、利用者端末１８０１から支払指示の情報を受信すると、その受信と前後して利用者端末１８０１の利用者の認証を、ユーザ情報管理部１８０２により行い、利用者ＩＤあるいはその均等データを得る。この利用者の所有者ＩＤあるいはその均等データを用いて、管理データ管理部１８０４の管理する管理情報テーブルにて検索し、利用者端末１８０１の利用者が所有する管理データを検索する。検索された管理データ１８０７のうち、別途受信される支払額以上の価値を有する管理データが選択され、代理サーバ１８００の支払処理部１８０３から、保管サーバに送信される。
【０１２４】
図１９は、本発明の実施形態３に係る管理データを用いた支払処理のシーケンス図を示す。図１９は、保管サーバ及び管理サーバを介して、代理サーバとショップサーバとの管理データの交換による支払処理を説明するためのシーケンス図である。図１９は、図１４に対応していると言うことができる。すなわち、図１４における譲受者端末が、図１９におけるショップサーバに対応し、譲渡者端末が、利用者端末を代理する代理サーバに対応している。また、ショップサーバは、ＷＥＢサーバとしての機能を有し、ＷＥＢページの閲覧要求があれば、要求されたＷＥＢページを返信する。
【０１２５】
ステップＳ１９０１において、利用者端末のブラウザなどへＵＲＬの入力や、ブラウザを操作してリンクを辿るなどの処理を行い、ウェブページの閲覧要求がショップサーバへ送信される。ショップサーバが閲覧要求を受信すると、要求されたウェブページをステップＳ１９０２において返信する。
【０１２６】
ステップＳ１９０２にて、ブラウザに返信されるウェブページには、商品などの購入の申込を行うための画面の記述がされているとする。例えば、図２８に示すように、「○○」として、購入が行われる商品などの名称が表示され、代金が例えば１００円として表示される。また、「購入」という表示を有するボタンが表示されている。このボタンには、購入が行われる商品などの識別番号が関連付けられている。また、必要に応じて、ウェブページには商品の配送先などを入力するテキストエリアが含まれており、「購入」という表示を有するボタンが押下されると、そのテキストエリアに入力された情報が送信されるようになっていてもよい。「購入」という表示を有するボタンが押下されることによりショップサーバへ送信される情報を購入情報ということにする。
【０１２７】
「購入」という表示を有するボタンが押下されると、ステップＳ１９０３の処理として、購入情報がショップサーバに送信される。購入情報がショップサーバに送信され、これに対する返信がショップサーバからブラウザに対して送信されることにより、ブラウザを操作する利用者がショップサーバの運営者から商品などの購入の同意がされ、支払が管理データの譲渡によってされることの同意もされたことが示される。
【０１２８】
すなわち、ステップＳ１９０１からステップＳ１９０３までの処理が行われることにより、譲受者端末としてのショップサーバと、譲渡者端末としての利用者端末との間で譲渡の合意がされることになる。従って、ステップＳ１９０１からステップＳ１９０３までの処理は、ステップＳ１４０１に対応していると言うこともできる。
【０１２９】
ステップＳ１９０４の処理として、ショップサーバから支払指示とセッションＩＤとがブラウザに送信される。支払指示には、譲渡されるべき価値の額（支払額）が含まれている。また、セッションＩＤは、ステップＳ１９０１からステップＳ１９０３の通信をショップサーバから一意に特定する。「送り情報」と言う場合がある。
【０１３０】
また、ステップＳ１９０４においてショップサーバから送信される支払指示とセッションＩＤには、ブラウザを代理サーバのＵＲＬが含まれ、ブラウザをそのＵＲＬにリダイレクトする指令が含まれているのが好ましい。これにより、後に説明するステップＳ１９０８においてブラウザから代理サーバへのアクセスが行われる。あるいは、利用者端末に支払処理を行う専用アプリケーションがインストールされている場合には、支払指示とセッションＩＤをＭＩＭＥフォーマットで記述し、Ｃｏｎｔｅｎｔ−Ｔｙｐｅなどによって、そのアプリケーションを用いて表示されることが指定されていてもよい。本実施形態では、支払指示とセッションＩＤには、ブラウザを代理サーバのＵＲＬが含まれ、ブラウザをそのＵＲＬにリダイレクトする指令が含まれているとして説明を行う。
【０１３１】
また、ステップＳ１９０５の処理として、ショップサーバは、保管サーバに対して、端数管理データ１とセッションＩＤとを送信する。
【０１３２】
ショップサーバから端数管理データ１とセッションＩＤとを受信した保管サーバは、ステップＳ１９０６の処理として、端数管理データ１を管理サーバへ送信し、端数管理データ１が有効であるかどうかを判断させ、有効であれば、照合用データの書き換えを行わせ、その結果得られる管理データである端数管理データ２をステップ１９０７の処理において受信する。そして、セッションＩＤと関連付けて保管する。
【０１３３】
したがって、ステップＳ１９０５、Ｓ１９０６、Ｓ１９０７の処理は、ステップＳ１４０２、Ｓ１４０３、Ｓ１４０４の処理に対応していると言うことができる。
【０１３４】
ステップＳ１９０４にて、ショップサーバから支払指示とセッションＩＤとを受信したブラウザは、ステップＳ１９０８において、代理サーバへリダイレクトし、その時に代理サーバに支払指示とセッションＩＤとを代理サーバへ送信する。代理サーバは、ステップＳ１９０９において、利用者情報の入力を要求する認証要求を利用者端末に送信し、利用者端末のブラウザに利用者情報の入力画面を表示させる。利用者がブラウザから利用者情報を入力すると、ステップＳ１９１０において、代理サーバに認証情報が送信される。認証情報は、例えば、後述するように利用者の登録を行った際に代理サーバなどから送信されるクッキー情報を代理サーバに送信することにより行われてもよい。このクッキー情報の中には、利用者ＩＤ及びパスワードのハッシュ値が格納されている。なお、ステップＳ１９０８よりも前に利用者端末の利用者が代理サーバに対して認証を行っており、代理サーバが利用者を認識していれば、ステップＳ１９０９とＳ１９１０は不要となる。なお、代理サーバが利用者を認識していても、利用者の支払の意思を確認するために、ステップＳ１９０９とＳ１９１０が行われてもよい。
【０１３５】
ステップＳ１９１１において、代理サーバは、利用者端末の利用者が所有する管理データであって、ステップＳ１９０４で受信した支払指示に含まれる支払額以上となるように管理データを管理データ管理部１８０４から選択して読み出して支払管理データ１として、セッションＩＤとともに保管サーバに送信する。支払額以上とは、選択された管理データが表す価値の額の合計額が、支払額以上となるこという。管理データ管理部１８０４から読み出される管理データは複数であってもよい。また、代理サーバからの画面情報の送信により、支払額を画面に表示し、ボタン押下を利用者に行わせるなどして、支払管理データの額などの確認を行わせてもよい。また、管理データ管理部１８０４で管理されている管理データが暗号化されて記憶されている場合には、復号のためのパスワードなどの入力が求められるようになっていてもよい。
【０１３６】
ステップＳ１９１１において、代理サーバからセッションＩＤ、支払額、支払管理データ１を受信した保管サーバは、セッションＩＤに、支払額と支払管理データ１とを関連付けて保管する。また、他にセッションＩＤに関連付けて保管されている管理データがあるかどうかの検索を行い、そのような管理データがあれば、ステップＳ１９１２以降の処理を行う。
【０１３７】
図２０は、管理データを用いた支払処理における代理サーバの処理の流れを説明するフローチャートの一例である。代理サーバは、ステップＳ１９０８に相当するステップＳ２００１の処理として、支払処理部１８０３を動作させて、利用者端末のブラウザから送信された支払指示とセッションＩＤとを受信する。次に、ステップＳ１９１０に相当するステップＳ２００２の処理として、ユーザ情報管理部１８０２を動作させて、利用者端末のブラウザから送信された利用者の認証を行う。次に、ステップＳ２００３の処理として、ユーザ情報管理部１８０２を動作させて、ブラウザから取得された認証情報に基づき所有者ＩＤを検索し、管理データ管理部１８０４にて、その所有者ＩＤに関連づけられている管理データを検索する。検索された管理データは、ステップＳ１９１１に相当するステップＳ２００４の処理として、ステップＳ２００１において受信されたセッションＩＤとともに、保管サーバに送信される。
【０１３８】
ステップＳ１９１２とステップＳ１９１３の処理は、ステップＳ１４０６、Ｓ１４０７の処理に対応しているということができる。保管サーバは、端数管理データ２と支払額と支払管理データ１とを管理サーバに送信し、端数管理データ３と支払管理データ２と釣管理データとを管理サーバから受信する。
【０１３９】
ステップＳ１９１４の処理として、保管サーバは代理サーバに釣管理データを送信する。この釣管理データの送信は、ステップＳ１９１１にて受信された支払額と支払管理データ１の返信として行われてもよい。なお、代理サーバの支払処理部は、釣管理データを保管サーバより受信し、利用者端末の利用者の識別情報と関連付けて管理データ管理部に保持する釣受信部１８０９を有する。代理サーバは、釣管理データを利用者端末の利用者の所有する管理データとして図１８（ｂ）に例示されるテーブルに格納を行う。
【０１４０】
ステップＳ１９１５の処理として、代理サーバは、利用者端末のブラウザに、決済終了画面を表示させる。決済終了画面の記述は、ステップＳ１９１４にて、保管サーバが釣管理データとともに代理サーバに送信するようになっていてもよい。さらに、決済終了画面の記述は、ステップＳ１９０５において、ショップサーバが端数管理データ１とセッションＩＤとともに保管サーバに送信するようになっていてもよい。このように決済終了画面の記述が、ショップサーバから送信され、保管サーバを経由して、利用者端末へ送信されることにより、電子的なデータそのものや電子的なデータのダウンロードなどのために使用するＵＲＬを決済終了画面の記述に含ませることにより、電子的なデータの販売に本実施形態を利用することができる。
【０１４１】
ステップＳ１９１３にて管理サーバから受信された端数管理データ３と支払管理データ２とは、ステップＳ１９０５にて受信されたセッションＩＤとともに保管サーバからショップサーバへ送信される（ステップＳ１９１６）。端数管理データ３と支払管理データ２の送信は、ステップＳ１９０５にてショップサーバから送信された端数管理データ１とセッションＩＤに対する返信として行われてもよい。
【０１４２】
このように、支払指示とセッションＩＤとが利用者端末のブラウザなどにより受信されると、利用者端末から代理サーバに支払指示とセッションＩＤとが送信され、管理データを用いた支払を行うことができるようになる。したがって、本実施形態においては、利用者は、ブラウザを用いてショップサーバにステップＳ１９０３にて購入情報を送信した後、決済処理を行うために、従来技術における場合と異なり、クレジットカード番号や振込先の口座番号などの煩雑なデータを入力する必要がなくなる。また、代理サーバに保持された管理データを用いて支払を行うので、クレジットカードのようにその後の返済などについて心配する必要がない。したがって、利用者は簡便な操作で管理データを用いて支払を行うことができる。これにより、インターネットなどでの支払を安全かつ簡便に行うことができる。
【０１４３】
図２１は、本発明の実施形態に係るシステム１６００において、利用者が電子的な価値情報を有する管理データを購入する際に、利用者端末１６０１の利用者から管理データの表わすべき価値が決済されたことが決済機関サーバ１６０５から入金サーバ１６０２に通知され、入金サーバ１６０２が管理データ１６０６の発行を発行サーバに命令し、発行された管理データが代理サーバ１６０３に格納され、利用者端末１６０１に管理データの発行通知が送信されるまでの発行処理を説明するシーケンス図である。また、図２２は、本発明の実施形態に係る発行処理における入金サーバの処理の流れを説明するためのフローチャートである。
【０１４４】
利用者は、利用者端末にインストールされたブラウザに表示されるウェブページを通じて、システム１６００を構成する各サーバにアクセスする。
【０１４５】
利用者端末のディスプレイなどには、例えば、図２３（ａ）に示されるように、「入金（ポイント購入）」、「ポイントの受取」、「ポイントによる支払」の表示を有するボタンを含む画面表示が、ブラウザを通じて表示される。「入金（ポイント購入）」のボタンが押下されると、入金サーバにユーザ情報が送信され、入金サーバはユーザ情報に基づき画面情報を生成する。入金サーバが生成した画面情報が利用者端末に送信され、例えば、図２３（ｂ）に示されるような画面が、利用者端末のブラウザに表示される。
【０１４６】
ステップＳ２１０１において、利用者が、利用者端末のブラウザに表示された図２３（ｂ）に例示するようなウェブページにおいて、購入ポイント数をリスト等から選択し、「購入」ボタンを押下すると、ステップＳ２１０２において、利用者端末から入金サーバへ、購入開始情報が送信される。ステップＳ２１０２は、図２２に示すフローチャートのステップＳ２２０１に相当する。購入開始情報は、利用者が選択した購入ポイント数の情報を含む。また、購入開始情報は、利用者端末を識別するための識別情報も含んでいてもよい。本実施形態において、購入開始情報は、後述するユーザ登録処理の際に利用者端末のクッキーに保存されたユーザＩＤのハッシュ値、仮端末識別子のハッシュ値、及び入金サーバと利用者端末との間の通信のセッションを特定するセッションＩＤ（セッションを一意に特定するセッション識別情報）の情報等を含んでもよい。識別情報の例としては、利用者端末の製造番号や、ＭＡＣアドレス、ＩＰアドレスなどであってもよい。利用者端末の製造番号や、ＭＡＣアドレスなどは、ブラウザにプラグインなどを組み込んでおくことにより入金サーバが取得することが可能である。あるいは、利用者を識別する情報であるユーザＩＤや所有者ＩＤなどであってもよい。また、識別情報は、利用者端末の製造番号や、ＭＡＣアドレス、ＩＰアドレスなどの情報そのものである必要はなく、それらの情報に対して所定のハッシュ関数を適用して計算される値であってもよい。この識別情報あるいは等価データは、管理サーバにより後に発行される管理データに埋め込まれてもよい。識別情報を管理データに埋め込むことにより、管理データを譲渡などする場合に、管理データが不正に他の利用者から取得されたものであるかどうかを検出することができる。これにより、管理データの使用の際の安全性を高めることができる。また、識別情報には、乱数が含まれるようになっており、管理データが管理サーバへ送信され、返信される都度、変化する部分があってもよい。
【０１４７】
入金サーバは、購入開始情報を受信した後、代理サーバに問い合わせる等の処理により、識別情報を基に利用者を認証し、認証された利用者に応じて画面情報を生成する。ステップＳ２１０３（図２２のステップＳ２２０２に対応）において、入金サーバは、利用者端末のブラウザに表示される画面情報を送信する。画面情報は、例えば、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いて記述されてもよい。画面情報が送信されると、図２３（ｃ）に例示するような、決済方法を選択する画面がブラウザに表示される。図２３（ｃ）に示す画面のように、利用者が購入するポイント数及び決済金額が表示され、振込先の決済機関を選択する決済方法の選択リストがドロップダウンリストで表示されてもよい。また、複数の銀行の中から利用者端末の利用者が契約している銀行を選択できるように、複数の銀行それぞれに対応したボタンが表示されていてもよい。
【０１４８】
次に、ステップＳ２１０４において、図２３（ｃ）に示す画面上で決済方法を選択した状態で「振込へ」ボタンを押下すると、ステップＳ２１０５において、利用者端末から銀行などの決済機関サーバに対してアクセスが行われ、選択した決済機関のサーバに振込依頼の情報が送信される。なお、図２３（ｃ）の「振込へ」の表示を有するボタンには、振込先の口座の情報や、振込名義人名を含むＵＲＬが関連付けられており、そのＵＲＬにアクセスすると、決済機関サーバに振込先の口座の情報や振込名義人名が伝えられ、振込の画面が開かれた場合に、振込先の口座の情報や振込名義人名が既にデフォルト値などとして入力された状態となっていてもよい。
【０１４９】
次に、ステップＳ２１０６において、決済機関サーバから利用者端末に対し画面情報が送信され、利用者端末のブラウザに、図２４（ａ）に例示するような、インターネットバンキング等のためのログイン画面が表示される。このログイン画面において、ステップＳ２１０７にて、利用者がインターネットバンキング等の利用者情報を入力して「ログイン」ボタンを押下すると、ステップＳ２１０８にて、入力した利用者情報が利用者端末から決済機関サーバに送信される。
【０１５０】
決済機関サーバは、インターネットバンキング等の利用者情報を基に振込先を入力する画面情報を生成し、ステップＳ２１０９において、決済機関サーバから利用者端末に対し、振込先を入力する画面情報を送信する。利用者端末には、図２４（ｂ）に例示するような、振込先の口座番号や振込金額等を入力する画面が表示される。前述したように、図２３（ｃ）の「振込へ」の表示を有するボタンに、振込先の口座の情報や、振込名義人名を含むＵＲＬが関連付けられている場合には、図２４（ｂ）に例示する振込先を入力する画面に、既に振込先の口座の情報や振込名義人名がデフォルト値で入力された状態であってもよい。
【０１５１】
次に、振込先を入力する画面において、ステップＳ２１１０にて、振込先の口座情報及び振込金額等を入力し、「振込」ボタンを押下すると、ステップＳ２１１１にて、利用者端末から決済機関サーバへ、振込情報が送信される。
【０１５２】
振込情報が決済機関サーバに送信されると、決済機関サーバにおいて振込処理が行われる。振込処理が完了した場合には、振込処理が完了したことを利用者端末に表示するための画面情報が生成され、ステップＳ２１１２にて、決済機関サーバから利用者端末へ、画面情報が送信される。
【０１５３】
ステップＳ２１１２により、利用者端末には、図２４（ｃ）に例示されるような、振込処理完了の確認画面が表示され、利用者が「ＯＫ」ボタン等を押下し、別の取引が可能となる。また、利用者端末のブラウザ上には、図２５に例示されるような画面が表示される。
【０１５４】
図２５に例示される画面は、前述のステップＳ２１０４において、図２３（ｃ）に例示する画面の「振込へ」ボタンを押下した際に、振込依頼の情報が入金サーバに対しても送信され、入金サーバの処理により決済機関サーバと通信するための画面とともに表示されるものであってもよい。例えば、一つの画面の右半分に決済機関サーバと通信するための画面が表示され、左半分に図２５に例示される画面が表示されていてもよい。あるいは、図２５を示す画面が決済機関サーバと通信するための画面とは別に表示され、図２４（ａ）乃至（ｃ）に例示する振込処理の画面が表示されている裏で、図２５に例示する画面が表示されていてもよい。
【０１５５】
次に、図２５に例示される画面において、ステップＳ２１１３にて、利用者が「完了」ボタンを押下すると、ステップＳ２１１４において、利用者端末から入金サーバへ、振込通知が送信される。ステップＳ２１１４は、図２２に示すフローチャートのステップＳ２２０３に相当する。
【０１５６】
入金サーバは振込通知を受信すると、ステップＳ２１１５（ステップＳ２２０４）において、決済機関サーバに対し、振込がなされたかどうかを確認するために問合せの情報を送信する。この振込問合せの情報には利用者の情報が含まれており、振込問合せを受信した決済機関サーバは、利用者情報を基に、振込先口座や振込金額等の振込内容を検索する。振込内容を確認した決済機関サーバは、入金サーバに対し、ステップＳ２１１６（ステップＳ２２０５）において、検索された振込内容を含む情報を、入金情報として送信する。入金情報は、振込名義人名、振込先口座の情報、振込金額等の情報を含む。あるいは、入金サーバは５分など、所定の間隔で決済機関サーバに対して、入金サーバの運営者に対して行われた振込の情報を取得し、その情報をデータベースに格納してもよい。そして、振込問合せがあると、このデータベースを検索して、振込の有無を確認する。
【０１５７】
振込があったことを確認した入金サーバは、入金情報に、利用者が購入した管理データ数の情報を関連付けて、データを生成する。購入した管理データの情報とともに、入金情報は、ステップＳ２１１７（ステップＳ２２０６）において、入金通知として発行サーバに送信される。
【０１５８】
入金通知を受信した発行サーバは、発行用送り情報を生成し、ステップＳ２１１８（ステップＳ２２０７）において、入金サーバに対し、発行用送り情報を送信する。発行用送り情報とは、振込の決済処理を特定する番号を含む。発行用送り情報は、例えば、利用者端末と管理サーバとが通信を行ったセッションのＩＤであってもよい。また、発行サーバは、生成した発行用送り情報を管理データとともに保管サーバへ送信してもよい。保管サーバは、発行用送り情報と管理データとを関連付けて、その保管部に保持する。
【０１５９】
利用者はステップＳ２１１９において、利用者端末のブラウザに表示されるウェブページから入金サーバに対し、発行通知を確認するために、発行通知確認要求を送信する。入金サーバは、ステップＳ２１２０（ステップＳ２２０８）において、利用者端末に対し、発行用送り情報を基に生成した発行通知を送信する。
【０１６０】
次に、本発明の一実施形態に係るシステム１６００の利用にあたり、利用者が行うユーザ登録処理について説明する。図２６は、利用者によるユーザ登録処理を説明するためのシーケンス図である。
【０１６１】
ステップＳ２３０１にて、図２７に例示する利用者端末に表示されるユーザ登録画面から、利用者は、ユーザＩＤ、ユーザパスワード、及び支払い用パスワードを入力して送信する。ステップＳ２３０２において、ユーザＩＤ、ユーザパスワード、及び支払い用パスワードが代理サーバに送信され、代理サーバの管理するデータベースに格納される。代理サーバでは、受信したユーザＩＤに所定のハッシュ（ＨＡＳＨ）関数を適用してユーザＩＤのハッシュ値を計算してもよい。ここで、ユーザＩＤとは、好ましくは非公開のＩＤであり、通常はユーザＩＤのハッシュ値を認証に利用する。ただし、必要があればユーザＩＤの平文についても利用者に入力させるものとする。また、ユーザパスワード及び支払い用パスワードとは、利用者の認証のために、ユーザＩＤとともに入力するパスワードである。ただし、通常の購入時は、支払い用パスワードのみを利用するものとする。例えば、支払い用パスワードを紛失した場合や、管理データの換金等の場合において、ユーザパスワードを利用するものとする。さらに、代理サーバでは、利用者端末に対して仮端末識別子を自動的に発番し、仮端末識別子のハッシュ値を計算する。
【０１６２】
次に、ステップＳ２３０３において、ユーザＩＤのハッシュ値、仮端末識別子、及び仮端末識別子のハッシュ値が、代理サーバから利用者端末に送信される。これらの値は、利用者端末では例えば利用者端末のクッキー（Ｃｏｏｋｉｅ）として登録される。
【産業上の利用可能性】
【０１６３】
以上のように、本発明においては、金銭的な価値などと関連付けられた照合用データを含む管理データを、利用者端末又は代理サーバに保持し、利用者端末又は代理サーバにおいて処理された管理データを譲渡することにより、金銭的な価値などを譲渡することが電子的に行うことができる。これにより、管理データによる支払をインターネット上で行うことが可能となる。
【０１６４】
別の側面からさらに説明を加えると、従来技術において通常のブラウザを用いて支払を行う場合には、クレジットカードや銀行振込、プリペイドマネーであっても、支払を行う者が正当な利用者であることを確認するために、カード番号、ＩＤやパスワード、アクセスコードなどの入力が求められる。これらのカード番号、ＩＤやパスワード、アクセスコードなどが覚えやすいものであると、セキュリティが脆弱となるので、複雑なものであることが好ましいとされ、複雑なものであると、記憶することが困難となるなどにより、逆に不便なシステムとなってしまう。
【０１６５】
一方、本発明では、管理サーバにより発行された管理データを利用者端末又は代理サーバに格納し、必要に応じて、管理データを譲渡することにより価値の移転が行われる。管理データが有効なものであるかどうかは、管理サーバのデータベース部に管理データの照合用データの記録の有無により判断がされる、管理サーバを介して譲渡を行う都度、照合用データの書き換えが行われる。このため、管理データを所持しているものが正当な権利者であることが推定でき、ＩＤやパスワード、アクセスコードなどによって正当な所有者であることを証明する必要が低減でき、セキュリティを保ちつつ、利便性を維持することが可能となる。
【０１６６】
また、実施形態３などにおいて説明したように、ブラウザを用いてインターネットのウェブサイトを通じて購入などの申込を行った場合、サイトから送られる支払指示とセッションＩＤとを含む情報が、ブラウザから代理サーバに送信され、代理サーバを通じて支払処理を行うことができる。これにより、利用者端末には管理データが保持されないため、個々の利用者端末に何らかの問題が生じることにより管理データが失われるといった問題が生じない。また、一つのサーバシステムを構築すれば、一括して管理データの授受を管理することができ、セキュリティ対策やバックアップ運用、データ復旧等の障害対応についても一括して管理することができる。また、セッションＩＤはインターネットのサイトから送信されるため、利用者は従来技術であれば別途入力する必要のあった利用者の識別情報としてのセッションＩＤを入力する必要がなくなる。
【０１６７】
また、実施形態２などにおいて説明したように、管理データが表す価値に上限を持たせることもでき、管理データを紛失したとき際の損害が大きくならないようにすることができる。以上より、本願発明は、産業上有用である。
【符号の説明】
【０１６８】
１８００ 代理サーバ
１８０１ 利用者端末
１８０２ ユーザ情報管理部
１８０３ 支払処理部
１８０４ 管理データ管理部
１８０５、１８０７ 管理データ
１８０６ 所有者ＩＤ
１８０８ ブラウザ
【特許請求の範囲】
【請求項１】
管理サーバのデータベースにおいて価値と関連付けられている照合用情報を含む管理データと利用者の識別情報とをデータベースにより関連づける代理サーバと、前記利用者の利用者端末と、前記利用者から購入の申込を受けるショップサーバと、前記管理データを含む照合用情報に関連付けられている価値の移動を行う保管サーバを有する決済システムであって、
前記利用者端末は、購入の申込のための画面情報を表示し、前記画面情報を用いて入力された購入の申込情報を前記ショップサーバへ送信し、購入の対価として支払う価格の情報を前記ショップサーバより受信し、前記画面情報を用いて入力された購入の申込情報を前記ショップサーバへ送信するブラウザを有し、
前記代理サーバは、
前記利用者端末の利用者の認証情報を管理するユーザ情報管理部と、
前記ユーザ情報管理部で管理される利用者の識別情報と関連付けて前記管理データを管理する管理データ管理部と、
前記利用者端末から送信された価格の情報を受信し、前記管理データ管理部より、前記利用者端末の利用者の識別情報と関連付けて管理されている管理データのうち、前記価格以上の価値と関連付けられている管理データを選択し、前記保管サーバへ送信する支払処理部と、
を有し、
前記ショップサーバは、
前記利用者端末より購入の申込情報を受信する受信部と、
前記受信された購入の申込情報に基づいて、前記利用者端末の利用者が支払う価格の情報を前記利用者端末へ返信する返信部と、
管理データを保持する管理データ保持部と、
前記管理データ保持部にて保持される管理データを前記価格の情報とともに前記保管サーバへ送信する送信部と、
を有し、
前記保管サーバは、
前記管理サーバに対して、前記利用者端末より受信された管理情報に含まれる照合用情報に、前記データベースにより関連付けられている価値を前記価格情報の示す価値を減じた価値が前記データベースにより関連付けられる照合用情報を含む第１の管理データの生成を命令し、また、前記ショップサーバより受信された管理情報に含まれる照合用情報に、前記データベースにより関連付けられている価値に前記価格情報の示す価値以下の価値を加えた価値が前記データベースにより関連付けられる照合用情報を含む第２の管理データの生成を命令する命令部と
を有する決済システム。
【請求項２】
前記保管サーバは、前記第１の管理データを前記代理サーバに送信し、また、前記第２の管理データを前記ショップサーバへ送信する管理データ送信部を有し、
前記代理サーバの支払処理部は、前記第１の管理データを前記保管サーバより受信し、前記利用者端末の利用者の識別情報と関連付けて前記管理データ管理部に保持する釣受信部を有し、
前記ショップサーバの前記受信部は、前記第２の管理データを受信する請求項１に記載の決済システム。
【請求項３】
前記ブラウザは、前記代理サーバにて前記利用者端末の利用者を認証するための利用者識別情報のハッシュ値を含むクッキー情報を前記代理サーバへ送信する請求項１に記載の決済システム。
【請求項４】
管理サーバのデータベースにおいて価値と関連付けられている照合用情報を含む管理データと利用者の識別情報とをデータベースにより関連づける代理サーバと、前記利用者の利用者端末と、前記利用者から購入の申込を受けるショップサーバと、前記管理データ含む照合用情報に関連付けられている価値の移動を行う保管サーバと通信が可能な代理サーバであって、
利用者端末の利用者の認証情報を管理するユーザ情報管理部と、
前記ユーザ情報管理部で管理される利用者の識別情報と関連付けて、管理データを管理する管理データ管理部と、
前記利用者端末から送信された支払の価格の情報を受信し、前記管理データ管理部より、前記利用者端末の利用者の識別情報と関連付けて管理されている管理データのうち、前記価格以上の価値と関連付けられている管理データを選択し、前記保管サーバへ送信する支払処理部と、
を有する代理サーバ。
【請求項５】
前記支払処理部が受信する支払の価格の情報は、前記利用者端末の有するブラウザをが、購入の申込のための画面情報を表示し、前記画面情報を用いて入力された購入の申込情報を前記ショップサーバへ送信し、購入の対価として支払う価格の情報を前記ショップサーバより受信して前記代理サーバへリダイレクトした情報である請求項４に記載の代理サーバ。
【請求項６】
管理サーバのデータベースにおいて価値と関連付けられている照合用情報を含む管理データと利用者の識別情報とをデータベースにより関連づける代理サーバと、前記利用者の利用者端末と、前記利用者から購入の申込を受けるショップサーバと、前記管理データを含む照合用情報に関連付けられている価値の移動を行う保管サーバの動作方法であって、
前記利用者端末は、購入の申込のための画面情報を受信し、
前記利用者端末は、前記画面情報を用いて入力された購入の申込情報を前記ショップサーバへ送信し、
前記ショップサーバは、前記申込情報に基づいて、前記利用者端末の利用者が支払う価格情報を前記利用者端末へ送信し、また、前記価格情報と前記ショップサーバが有する管理データを前記保管サーバへ送信し、
前記利用者端末は、前記価格情報を前記代理サーバへ送信し、
前記代理サーバは、前記利用者端末の利用者に関連付けられた管理データのうち、照合用データに関連付けられている価値が前記価格情報以上となる管理データを前記保管サーバへ送信し、
前記保管サーバは、前記管理サーバに対して、前記利用者端末より受信された管理情報に含まれる照合用情報に、前記データベースにより関連付けられている価値を前記価格情報の示す価値を減じた価値が前記データベースにより関連付けられる照合用情報を含む第１の管理データの生成を命令し、また、前記ショップサーバより受信された管理情報に含まれる照合用情報に、前記データベースにより関連付けられている価値に前記価格情報の示す価値以下の価値を加えた価値が前記データベースにより関連付けられる照合用情報を含む第２の管理データの生成を命令し、
前記保管サーバは、前記第１の管理データを前記代理サーバへ送信し、また、前記第２の管理データを前記ショップサーバへ送信することを含む決済方法。
【請求項７】
前記ショップサーバは、前記申込情報を特定する識別情報を生成し、前記価格情報とともに前記識別情報を前記利用者端末へ送信し、また、前記保管サーバへ前記管理データとともに送信し、
前記利用者端末は、前記価格情報とともに前記識別情報を前記代理サーバへ送信し、
前記代理サーバは、前記照合用データに関連付けられている価値が前記価格情報以上となる管理データとともに前記識別情報を前記保管サーバへ送信し、
前記保管サーバは、前記代理サーバから送信された前記識別情報に前記第１の管理データを関連付け、
前記保管サーバは、前記ショップサーバから送信された前記識別情報に前記第２の管理データを関連付け、
前記保管サーバは同一の前記識別情報に前記第１の管理データと前記第２の管理データが関連付けられると、前記識別情報と前記第１の管理データを前記代理サーバに送信し、また、前記識別情報と前記第２の管理データを前記ショップサーバに送信する請求項６に記載の決済方法。
【請求項８】
前記利用者端末においてブラウザが動作しており、
前記ブラウザは、前記利用者端末が受信した前記購入の申込のための画面情報を表示し、
前記ブラウザは、前記購入の申込情報とともに、前記利用者端末の利用者の前記代理サーバの利用者データベースに管理される利用者ＩＤのハッシュ値が格納されたクッキー情報を送信し、
前記ショップサーバは、前記利用者データベースに管理される利用者ＩＤに関連付けて管理データを保持する請求項６または７に記載の決済方法。
【請求項１】
管理サーバのデータベースにおいて価値と関連付けられている照合用情報を含む管理データと利用者の識別情報とをデータベースにより関連づける代理サーバと、前記利用者の利用者端末と、前記利用者から購入の申込を受けるショップサーバと、前記管理データを含む照合用情報に関連付けられている価値の移動を行う保管サーバを有する決済システムであって、
前記利用者端末は、購入の申込のための画面情報を表示し、前記画面情報を用いて入力された購入の申込情報を前記ショップサーバへ送信し、購入の対価として支払う価格の情報を前記ショップサーバより受信し、前記画面情報を用いて入力された購入の申込情報を前記ショップサーバへ送信するブラウザを有し、
前記代理サーバは、
前記利用者端末の利用者の認証情報を管理するユーザ情報管理部と、
前記ユーザ情報管理部で管理される利用者の識別情報と関連付けて前記管理データを管理する管理データ管理部と、
前記利用者端末から送信された価格の情報を受信し、前記管理データ管理部より、前記利用者端末の利用者の識別情報と関連付けて管理されている管理データのうち、前記価格以上の価値と関連付けられている管理データを選択し、前記保管サーバへ送信する支払処理部と、
を有し、
前記ショップサーバは、
前記利用者端末より購入の申込情報を受信する受信部と、
前記受信された購入の申込情報に基づいて、前記利用者端末の利用者が支払う価格の情報を前記利用者端末へ返信する返信部と、
管理データを保持する管理データ保持部と、
前記管理データ保持部にて保持される管理データを前記価格の情報とともに前記保管サーバへ送信する送信部と、
を有し、
前記保管サーバは、
前記管理サーバに対して、前記利用者端末より受信された管理情報に含まれる照合用情報に、前記データベースにより関連付けられている価値を前記価格情報の示す価値を減じた価値が前記データベースにより関連付けられる照合用情報を含む第１の管理データの生成を命令し、また、前記ショップサーバより受信された管理情報に含まれる照合用情報に、前記データベースにより関連付けられている価値に前記価格情報の示す価値以下の価値を加えた価値が前記データベースにより関連付けられる照合用情報を含む第２の管理データの生成を命令する命令部と
を有する決済システム。
【請求項２】
前記保管サーバは、前記第１の管理データを前記代理サーバに送信し、また、前記第２の管理データを前記ショップサーバへ送信する管理データ送信部を有し、
前記代理サーバの支払処理部は、前記第１の管理データを前記保管サーバより受信し、前記利用者端末の利用者の識別情報と関連付けて前記管理データ管理部に保持する釣受信部を有し、
前記ショップサーバの前記受信部は、前記第２の管理データを受信する請求項１に記載の決済システム。
【請求項３】
前記ブラウザは、前記代理サーバにて前記利用者端末の利用者を認証するための利用者識別情報のハッシュ値を含むクッキー情報を前記代理サーバへ送信する請求項１に記載の決済システム。
【請求項４】
管理サーバのデータベースにおいて価値と関連付けられている照合用情報を含む管理データと利用者の識別情報とをデータベースにより関連づける代理サーバと、前記利用者の利用者端末と、前記利用者から購入の申込を受けるショップサーバと、前記管理データ含む照合用情報に関連付けられている価値の移動を行う保管サーバと通信が可能な代理サーバであって、
利用者端末の利用者の認証情報を管理するユーザ情報管理部と、
前記ユーザ情報管理部で管理される利用者の識別情報と関連付けて、管理データを管理する管理データ管理部と、
前記利用者端末から送信された支払の価格の情報を受信し、前記管理データ管理部より、前記利用者端末の利用者の識別情報と関連付けて管理されている管理データのうち、前記価格以上の価値と関連付けられている管理データを選択し、前記保管サーバへ送信する支払処理部と、
を有する代理サーバ。
【請求項５】
前記支払処理部が受信する支払の価格の情報は、前記利用者端末の有するブラウザをが、購入の申込のための画面情報を表示し、前記画面情報を用いて入力された購入の申込情報を前記ショップサーバへ送信し、購入の対価として支払う価格の情報を前記ショップサーバより受信して前記代理サーバへリダイレクトした情報である請求項４に記載の代理サーバ。
【請求項６】
管理サーバのデータベースにおいて価値と関連付けられている照合用情報を含む管理データと利用者の識別情報とをデータベースにより関連づける代理サーバと、前記利用者の利用者端末と、前記利用者から購入の申込を受けるショップサーバと、前記管理データを含む照合用情報に関連付けられている価値の移動を行う保管サーバの動作方法であって、
前記利用者端末は、購入の申込のための画面情報を受信し、
前記利用者端末は、前記画面情報を用いて入力された購入の申込情報を前記ショップサーバへ送信し、
前記ショップサーバは、前記申込情報に基づいて、前記利用者端末の利用者が支払う価格情報を前記利用者端末へ送信し、また、前記価格情報と前記ショップサーバが有する管理データを前記保管サーバへ送信し、
前記利用者端末は、前記価格情報を前記代理サーバへ送信し、
前記代理サーバは、前記利用者端末の利用者に関連付けられた管理データのうち、照合用データに関連付けられている価値が前記価格情報以上となる管理データを前記保管サーバへ送信し、
前記保管サーバは、前記管理サーバに対して、前記利用者端末より受信された管理情報に含まれる照合用情報に、前記データベースにより関連付けられている価値を前記価格情報の示す価値を減じた価値が前記データベースにより関連付けられる照合用情報を含む第１の管理データの生成を命令し、また、前記ショップサーバより受信された管理情報に含まれる照合用情報に、前記データベースにより関連付けられている価値に前記価格情報の示す価値以下の価値を加えた価値が前記データベースにより関連付けられる照合用情報を含む第２の管理データの生成を命令し、
前記保管サーバは、前記第１の管理データを前記代理サーバへ送信し、また、前記第２の管理データを前記ショップサーバへ送信することを含む決済方法。
【請求項７】
前記ショップサーバは、前記申込情報を特定する識別情報を生成し、前記価格情報とともに前記識別情報を前記利用者端末へ送信し、また、前記保管サーバへ前記管理データとともに送信し、
前記利用者端末は、前記価格情報とともに前記識別情報を前記代理サーバへ送信し、
前記代理サーバは、前記照合用データに関連付けられている価値が前記価格情報以上となる管理データとともに前記識別情報を前記保管サーバへ送信し、
前記保管サーバは、前記代理サーバから送信された前記識別情報に前記第１の管理データを関連付け、
前記保管サーバは、前記ショップサーバから送信された前記識別情報に前記第２の管理データを関連付け、
前記保管サーバは同一の前記識別情報に前記第１の管理データと前記第２の管理データが関連付けられると、前記識別情報と前記第１の管理データを前記代理サーバに送信し、また、前記識別情報と前記第２の管理データを前記ショップサーバに送信する請求項６に記載の決済方法。
【請求項８】
前記利用者端末においてブラウザが動作しており、
前記ブラウザは、前記利用者端末が受信した前記購入の申込のための画面情報を表示し、
前記ブラウザは、前記購入の申込情報とともに、前記利用者端末の利用者の前記代理サーバの利用者データベースに管理される利用者ＩＤのハッシュ値が格納されたクッキー情報を送信し、
前記ショップサーバは、前記利用者データベースに管理される利用者ＩＤに関連付けて管理データを保持する請求項６または７に記載の決済方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【公開番号】特開２０１１−４８７８２（Ｐ２０１１−４８７８２Ａ）
【公開日】平成２３年３月１０日（２０１１．３．１０）
【国際特許分類】
【出願番号】特願２００９−１９８７４２（Ｐ２００９−１９８７４２）
【出願日】平成２１年８月２８日（２００９．８．２８）
【出願人】（３９７０７６３６１）有限会社アプリコシステム (5)
【出願人】（３０８０００２０７）有限会社エックス (3)
【Ｆターム（参考）】
【公開日】平成２３年３月１０日（２０１１．３．１０）
【国際特許分類】
【出願日】平成２１年８月２８日（２００９．８．２８）
【出願人】（３９７０７６３６１）有限会社アプリコシステム (5)
【出願人】（３０８０００２０７）有限会社エックス (3)
【Ｆターム（参考）】
[ Back to top ]