JPWO2009116415A1 - 電子的価値情報管理サーバ - Google Patents

Abstract

第１の照合用データを含む第１の管理データを受信する管理データ受信部と、第１の照合用データが第１の価値の情報に関連付けられていれば、新たな照合用データを準備して、第１の価値情報に前記新たな照合用データを関連付けるとともに第１の管理データに含まれる第１の照合用データを前記新たな照合用データに置換した第２の管理データを生成する置換部と、第１の管理データに第１の所有者識別情報が含まれていれば、第１の所有者識別情報に前記新たな照合用データを関連付ける所有者変更部と、第２の管理データを送信する置換管理データ送信部とを有することを特徴とする管理サーバなどを提供する。

Description

本発明は、電子マネーの決済、電子マネーやその他の電子的な価値情報の譲渡などの処理を行う処理装置、電子的な価値情報の処理方法などに関する。

電子マネーやその他の電子的な価値情報は、ビット列などの情報に貨幣などの価値が関連付けられている。そのビット列などの情報の交換により決済などの価値の譲渡が実現される。そして、電子マネーは急速に普及しつつあり、交通機関の改札での運賃の支払いや店舗での商品の代金の決済の手段として用いられている。

ところで、電子マネーやその他の電子的な価値情報に関する技術については、ビット列などの情報は容易に複製されてしまうので、複製後に二重に使用されたことを検出する方法を備える必要がある（例えば、特許文献１参照。）。また、一般的に電子マネーは無記名であり、また、実際の貨幣とは異なり無体物であるため、紛失してしまった場合に被害が甚大となる可能性がある。そこで紛失などに備える必要がある（例えば、特許文献２参照。）。

米国特許４，９７７，５９５号明細書 特開２００７−３１０５６２号公報

特許文献１及び特許文献２に開示された技術に限らず、従来は、電子マネー等には暗号理論の利用が不可欠であると考えられている。暗号理論を用いることにより二重使用や紛失などの対策を取ろうとしている。このため、電子マネー等を利用するためには、利用者は特殊なＩＣカード等を使用する必要があり、店舗などでは、そのＩＣカード等の読取り装置を備える必要がある。このため、電子マネー等の普及には莫大なコストが必要となる。また、個人間などの一般の利用者間での電子マネー等の譲渡も困難である。

そこで、本発明では、二重使用を防止し、紛失したとしても復旧が可能であり、専用のＩＣカードなど特別な装置を用いなくても譲渡が可能な電子的な価値情報を管理するサーバ装置などを提供する。

本発明の一実施形態として、照合用データに価値情報とその価値情報が表す価値を所有する者の所有者識別情報とを関連付けるデータベース部と、第１の照合用データを含む第１の管理データを受信する管理データ受信部と、前記第１の照合用データが前記データベース部により第１の価値情報に関連付けられていれば、新たな照合用データを準備して、前記第１の価値情報に前記新たな照合用データを関連付けるとともに前記第１の管理データに含まれる前記第１の照合用データを前記新たな照合用データに置換した第２の管理データを生成する置換部と、前記第１の管理データに第１の所有者識別情報が含まれていれば、前記第１の所有者識別情報に前記新たな照合用データを関連付ける変更操作を前記データベース部に対して実行する所有者変更部と、前記第２の管理データを送信する置換管理データ送信部と、を有することを特徴とする管理サーバを開示する。

本発明の別の実施形態として、管理サーバ装置によるデータの送受信方法であって、その管理サーバが、照合用データに価値情報とその価値情報が表す価値を所有する者の所有者識別情報とを関連付けて保持し、第１の照合用データを含む第１の管理データを受信し、前記第１の照合用データが第１の価値情報に関連付けられていれば、新たな照合用データを準備して、前記第１の価値情報に前記新たな照合用データを関連付けるとともに前記第１の管理データに含まれる前記第１の照合用データを前記新たな照合用データに置換した第２の管理データを生成し、前記第１の管理データに第１の所有者識別情報が含まれていれば、前記第１の所有者識別情報に前記新たな照合用データを関連付け、前記第２の管理データを送信することを特徴とする、価値情報に関連付けられたデータの送受信方法を開示する。

本発明の別の実施形態として、管理サーバにて、所有者識別情報と関連付けられた価値情報に関連付けられた照合用データを含む管理データの譲渡を仲介するための保管サーバの動作方法であって、前記保管サーバは、価値情報に関連付けられた照合用データを含む管理データを送信する第１の端末とその管理データを受信する第２の端末との間で通信セッションを確立し、前記確立された通信セッションにより前記第１の端末と前記第２の端末とで相互認証を行い、前記第１の端末より送信される管理データと前記確立された通信セッションの識別情報とを受信し、前記受信された管理データに含まれる照合用データを、新たに準備された照合用データに置換して置換済管理データを生成し、前記受信された通信セッションの識別情報に関連づけて前記置換済み管理データを保管し、前記第２の端末より、通信セッションの識別情報を受信してその通信セッションに関連づけられて保管されている置換済み管理データを返信することを特徴とする、価値情報に関連付けられた、保管サーバの動作方法を開示する。

本発明の別の実施形態として、照合用データに可分な価値を表す価値情報とを関連付けるデータベース部と、第１の端末より送信された、上限の量以下の価値を表す第１の価値情報に関連付けられた第１の照合用データを含む第１の管理データと、第２の端末より送信された、前記上限の量未満の価値を表す第２の価値情報に関連付けられた第２の照合用データを含む第２の管理データとを受信する管理データ受信部と、前記上限から前記第２の価値情報が表す価値の差を越えない価値を、前記第１の価値情報の価値から差し引き前記第２の価値情報が表す価値に加算するデータベース変更部と、前記第２の管理情報を前記第２の端末へ向けて送信する管理データ送信部と、有する管理サーバを開示する。

本発明の別の実施形態として、第１の端末より、上限の値以下の価値を表す第１の価値情報に関連付けられた第１の照合用データを含む第１の管理データを受信し、第２の端末より、前記上限の値未満の価値を表す第２の価値情報に関連付けられた第２の照合用データを含む第２の管理データを受信し、前記上限から前記第２の価値情報が表す価値の差を越えない価値を、前記第１の価値情報の価値から差し引き前記第２の価値情報が表す価値に加算し、前記第２の端末へ前記第２の管理データを含む管理データを送信し、前記第１の端末と前記第２の端末との間で決済処理を行うサーバの動作方法を開示する。

本発明の別の実施形態として、識別情報を管理サーバに送信する送信部と、前記識別情報の送信の返信として、振り込みの決済処理を行う際の名義人名を表示するための画面情報を受信する受信部と、前記受信された画面情報を表示し決済処理を行うブラウザを起動する起動部と、前記起動されたブラウザによる決済処理の後、前記決済処理が行われたことの確認を前記管理サーバに要求する要求部と、前記決済処理が行われたことの確認が前記管理サーバにされて前記決済処理にて振り込まれた金額の額に相当する価値情報に前記管理サーバにて関連付けられた照合用データを含む管理データを受信する管理データ受信部とを有する端末装置を開示する。

本発明の別の実施形態として、利用者端末より管理サーバへ前記利用者端末の識別情報を送信し、振り込みの決済処理を行う際の名義人名を前記管理サーバにて生成し、前記生成された名義人名を前記利用者端末へ送信し、前記利用者端末にてブラウザを起動して前記名義人名を用いて決済サーバにて決済処理を行い、前記決済サーバは前記管理サーバに、決済が行われた名義人名と金額とを含む決済情報を送信し、前記決済サーバは、前記決済情報に含まれる金額の額に相当する価値情報に関連付けられた照合用情報を含んで生成された管理データを、前記決済情報を識別するＩＤ情報と関連付けて保管サーバへとともに送信し、前記利用者端末は、前記決済処理を行った通知を前記管理サーバへ送信し、前記管理サーバは、前記名義人名を含む決済情報を受信した通知を前記利用者端末へ返信し、前記利用者端末は、前記決済処理を識別するＩＤ情報を前記保管サーバへ送信し、前記保管サーバは、前記利用者端末より送信されたＩＤ情報に関連付けて前記管理サーバが送信した管理情報を送信することを含む、価値情報に関連付けられたデータの送受信方法を開示する。

本発明の別の実施形態として、第１のサーバにおいて価値情報が関連付けられているデータを含む管理データを利用者端末に記憶し、前記利用者端末においてブラウザを起動し、商品の販売または役務の提供を行うための第２のサーバより、前記第１のサーバと前記ブラウザとの通信のセッションＩＤと支払うべき価格情報とを、前記ブラウザを経由して受信し、前記記憶されている管理データを１以上選択して前記選択された管理データに関連付けられている価値情報の額を前記価格情報の額以上とし、前記選択された管理データを前記セッションＩＤとともに第３のサーバへ送信するデータ送信方法を開示する。

なお、本発明において、データや情報の受信及び送信は、ハードウェアとしてのネットワークアダプタなどを制御してネットワークを介した通知を行うことを意味する。２つ以上のデータの関連付けは、ハードウェアとしての記憶装置に記憶されているテーブルに１行のデータとして２つ以上のデータを格納すること、また、それと均等な方法により実現される。

本発明の一実施形態により、二重使用を防止し、紛失したとしても復旧が可能であり、専用のＩＣカードなど特別な装置を用いなくても流通が可能な電子的な価値情報の利用などを提供できる。また、特別な装置を用いる必要がないので、インターネットなどを介した決済処理を従来の技術よりも簡単に行うことができる。

本発明の一実施形態に係る管理サーバの機能ブロック図である。 本発明の一実施形態における管理データ発行の具体例を説明する図である。 本発明の一実施形態に係る管理サーバの処理のフローチャートである。 本発明の一実施形態における照合用データの書き換えの具体例を説明する図である。 本発明の一実施形態に係る管理サーバの処理のフローチャートである。 本発明の一実施形態に係る管理サーバ、決済サーバ、保管サーバ及び利用者端末からなるシステム構成図である。 本発明の一実施形態に係る管理サーバ、決済サーバ、保管サーバ及び利用者端末からなるシステムによる処理のシーケンス図である。 本発明の一実施形態に係る保管サーバの機能ブロック図である。 本発明の一実施形態における管理データを保管するためのテーブルの一例図である。 本発明の一実施形態における管理データとＩＤとを受信し保管するまでの処理のフローチャートである。 本発明の一実施形態におけるＩＤと関連付けられて補間されている管理データを送信するまでの処理のフローチャートである。 本発明の一実施形態に係る利用者間で管理データを譲渡するシステムの構成図である。 本発明の一実施形態に係る利用者間で管理データを譲渡するシステムによる処理のシーケンス図である。 本発明の一実施形態に係る利用者間で管理データを譲渡するシステムによる処理のシーケンス図である。 本発明の一実施形態における管理データ発行の具体例を説明する図である。 本発明の一実施形態に係る管理サーバの機能ブロック図である。 本発明の一実施形態に係る管理サーバの処理のフローチャートである。 本発明の一実施形態に係る管理サーバの処理のフローチャートである。 本発明の一実施形態に係る管理サーバ、決済サーバ、保管サーバ及び利用者端末からなるシステム構成図である。 本発明の一実施形態において決済処理が行われ管理データが生成されて利用者端末に受信されるまでの処理のシーケンス図である。 本発明の一実施形態に係る利用者端末の画面表示を示す図である。 本発明の一実施形態に係る利用者端末の画面表示を示す図である。 本発明の一実施形態に係る管理サーバが保持するテーブルの構成と内容の遷移を示す図である。 本発明の一実施形態に係る利用者端末の機能ブロック図である。 本発明の一実施形態において決済処理が行われ管理データが生成されて利用者端末に受信されるまでの処理のシーケンス図である。 本発明の一実施形態に係る利用者端末の画面表示を示す図である。 本発明の一実施形態に係る管理データ管理アプリケーションの機能ブロック図である。 本発明の一実施形態に係る利用者端末から販売サーバへ管理データを譲渡する処理のシーケンス図である。 本発明の一実施形態における商品などの購入の申込を行うための画面の一例図である。 本発明の一実施形態に係る販売サーバと、ウェブサーバと、利用者端末とからなるシステムの構成図である。 本発明の一実施形態に係る販売サーバが管理するテーブルの一例図である。 本発明の一実施形態に係る販売サーバのファイルシステムの構成の一例図である。

符号の説明

１００ 管理サーバ
１０１ データベース部
１０２ 発行要求受信部
１０３ 生成部
１０５ 管理データ受信部
１０６ 置換部
１０７ 置換管理データ送信部
１０８ 管理データ発行要求
１０９、１１０、１１１ 管理データ

以下、本発明を実施するための最良の形態について実施形態として図を参照しつつ説明を行う。なお、本発明は以下の実施形態に限定されるものではなく、その要旨を逸脱しない範囲において種々なる態様で実施することができる。

（実施形態１）
（管理サーバ）
本発明の一実施形態において、管理サーバとは、電子的な価値情報の譲渡処理を主に行うサーバ装置である。管理サーバが行うその他の処理としては、管理サーバとして必須の処理ではないが、電子的な価値情報の発行処理、発行した電子マネー等に関連付けられた価値を貨幣などとして払い戻す処理などがある場合がある。

図１は、本発明の一実施形態に係る管理サーバの機能ブロック図を例示する。管理サーバ１００は、データベース部１０１と、発行要求受信部１０２と、生成部１０３と、生成管理データ送信部１０４と、管理データ受信部１０５と、置換部１０６と、置換管理データ送信部１０７とを有する。なお、管理サーバ１００の実現の一態様としては、コンピュータにソフトウェアを読み込ませ、ソフトウェアとハードウェア資源とが協働した具体的手段によって、使用目的に応じた情報の演算又は加工を実現することにより、使用目的に応じた特有の情報処理装置とするものがある。また、専用の回路によるハードウェアのみの構成も可能である。このような実現は、本発明の以下の説明に接した当業者により理解される。

データベース部１０１は、電子的な価値情報と価値との関連付けを管理する。本発明の一実施形態においては、電子的な価値情報は管理サーバ１００により管理などされるデータであるので、「電子的な価値情報」という用語のかわりに「管理データ」という用語を用いる。そして、本発明の一実施形態においては、管理データは照合用データを含み、この照合用データが価値そのものあるいは価値を表す情報と関連付けられる。また、照合用データは他の情報とも関連付けることができる。

照合用データと関連付けることができる他の情報としては、例えば、その照合用データを含む管理データの譲渡が行われた回数（譲渡回数）、その照合用データを含む管理データが、どの利用者やどの利用者の端末装置などに対して発行されたかを示す利用者や端末装置などの識別情報などが挙げられ、これらは必要に応じてデータベース部１０１に格納されてもよい。

本発明の一実施形態においては、図２（ａ）に示すように、照合用データが格納される列と価値の情報が格納される列とを有し、照合用データと価値の情報とを関連付けるテーブルを用意する。このテーブルは、関係データベースシステムなどの表データとしてデータベース部１０１によって管理される。なお、価値の情報を単に「価値情報」という場合がある。

照合用データは、充分に長いビット長の乱数として生成されるデータである。「充分に長い」とは、発行される管理データの中で同じ照合用データを有するものが存在しない、あるいは、実質的に存在しないことを意味する。例えば、１２８ビット、５１２ビット、１０２４ビット、２０４８ビットなど設計上などの必要に応じて任意の長さを決めることができる。

価値情報は、照合用データを含む管理データが表すことになる価値の内容などを示す。具体的な例としては、貨幣により表される価値を示す。この場合、価値の単位は、円、ドル、ユーロ、元などである。また、価値の情報は、貨幣と同等の価値を有する有価証券の証券番号、貴金属の量や保管の番号などであってもよい。

発行要求受信部１０２は、管理データ発行要求１０８を受信する。管理データ発行要求１０８は、なんらかの価値が管理サーバやその運営者などに移転されたことあるいは移転されることを示す情報である。このため、管理データ発行要求１０８は、管理サーバ１００の運営者の支配する領域の内部で生成されたり、運営者と特別な関係（例えば親会社子会社の関係や特別な契約関係）にある者から送信されたりするのが好ましい。

図２（ｂ）は、管理データ発行要求の具体的な例を示す。この例では、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）による表現がされている。管理データ発行要求はＸＭＬ以外にも種々の表現形式があるが、以下では、ＸＭＬを例にして説明を行う。図２（ｂ）では、＜価値＞と＜／価値＞とで囲まれている１０００円が、発行される管理データが表すべき価値となっている。発行要求受信部１０２が、このような管理データ発行要求を受信する際には、管理データ発行要求の送信者の認証を行い、受信した管理データ発行要求をメモリに展開して正しい構文であるかどうかの確認を行い、＜価値＞と＜／価値＞とで囲まれている部分を特定して、次に説明する生成部１０３に伝達する。伝達は、例えば、生成部１０３を実現するソフトウェアモジュールなどの関数の引数に＜価値＞と＜／価値＞とで囲まれている部分のメモリアドレスを価値の情報として引数に指定するなどしてその関数を呼び出すことで行われる。

なお、管理データ発行要求には、照合用データと関連付けることができる他の情報が必要に応じて含まれていてもよい。

生成部１０３は、照合用データを準備し、準備された照合用データと発行要求受信部１０２から伝達された価値の情報とを、データベース部１０１で管理される図２（ａ）のテーブルに行データとして挿入する。「照合用データを準備する」とは、乱数を生成してその乱数を照合用データとすること、又は、予め生成しておいた乱数のリストなどから乱数を選択して照合用データとすることをいう。挿入が完了すると、生成部１０３は、生成管理データ送信部１０４へ、照合用データを伝達する。なお価値の情報も伝達されてもよい。

図２（ｃ）は、照合用データとして"１３５７１１"が準備されて、"１３５７１１"と１０００円とを図２（ａ）に示されるテーブルに挿入した直後の状態を示している。挿入が行われると、"１３５７１１"という照合用データが生成管理データ送信部１０４へ伝達される。

生成管理データ送信部１０４は、生成部１０３から伝達された照合用データから管理データ１０９を生成して送信する。管理データ１０９の送信先は、管理データ発行要求１０８を送信した装置であることが主に想定される。もし、管理データ発行要求１０８に、管理データ１０９の送信先が、電子メールアドレスやＩＰアドレスなどによって指定されていれば、その送信先へ管理データ１０９が送信される。送信は暗号化されて行われてもよい。

図２（ｄ）は、生成管理データ送信部１０４で生成され送信される管理データの一例を示す。生成部１０３から照合用データとして"１３５７１１"が伝達されたとすれば、"＜管理データ＞＜照合用データ＞１３５７１１＜／照合用データ＞＜／管理データ＞"という管理データが生成され、インターネットなどのネットワークなどに送信される。なお管理データには、照合用データ以外のデータが含まれていてもよい。例えば、照合用データがどれだけの価値、例えばいくらの貨幣価値、に関連付けられているかを示す情報が含まれていてもよい。例えば、管理データが"＜管理データ＞＜照合用データ＞１３５７１１＜／照合用データ＞＜価値＞１０００円＜／価値＞＜／管理データ＞"のように貨幣価値などを含むようになっていてもよい。また、照合用データと関連付けることができる他の情報が含まれていてもよい。また、譲渡回数が管理データに含まれる場合には、０などの初期値にリセットが行われて送信がされる。さらに、管理データが管理サーバ１００により生成されたことを検証できるようにするために、照合用データなどに対する管理サーバ１００による署名データが含まれていてもよい。

なお、価値として、貨幣価値のように可分な価値が用いられる場合には、管理データが表す価値に上限を設けてもよい。例えば、一つの管理データは、５０００円までの貨幣価値を表すことにする。そして、５０００円以上の価値を表す管理データは、複数の管理データを組み合わせることによって表す。このように管理データが表す価値に上限を設けることにより、管理データを紛失したときに生じる損失が大きくならないようにすることができる。

管理データが表す価値に上限を設ける場合には、管理データ発行要求がその上限を越える価値の管理データを発行することを表している場合には、上限以下の価値を表す管理データを複数発行する。このため、図２（ａ）などに示すテーブルに複数の行データが挿入される。

図３は、データベース部１０１、発行要求受信部１０２、生成部１０３、生成管理データ送信部１０４による処理の流れを説明するフローチャートを例示する。このフローチャートが例示する処理は、ハードウェアを制御可能なソフトウェアによる情報処理として実行可能である。あるいは、上述したように専用の回路によるハードウェアのみの構成によってもこのフローチャートが例示する処理を実行することも可能である。また、ソフトウェアによる情報処理として実行可能性、専用の回路によるハードウェアのみの構成による実行可能性は、他の図面のフローチャート、シーケンス図により例示される処理について同様である。

ステップＳ３０１の処理として、発行要求受信部１０２により管理データ発行要求を受信する。例えば、ハードウェアとしてのネットワークアダプタがデータを受信し割り込みが発生すると、割り込みハンドラが呼ばれて、データを読取り、読取りデータキューに入れる。そして、発行要求受信部１０２を実現するモジュールなどが発行していたＲＥＡＤシステムコールなどから処理が戻り、読取りデータキューに入れられたデータを管理データ発行要求としてメモリに展開する。

ステップＳ３０２の処理として、発行要求受信部１０２は、メモリに展開された管理データ発行要求から価値の情報のアドレスを特定などすることにより、価値の情報を取得する。取得された価値の情報は生成部１０３へ伝達される。

ステップＳ３０３の処理として、生成部１０３が照合用データを準備する。そしてステップＳ３０４の処理として、生成部１０３は、準備した照合用データと伝達された価値の情報を関連付けて行データとしてテーブルに挿入して格納する。なお、テーブルはハードディスク装置などの記憶装置により記憶することができる。データベース部１０１は、そのような記憶装置を用いて実現される。そして、準備された照合用データは生成管理データ送信部１０４へ伝達される。

ステップＳ３０５の処理として、生成管理データ送信部１０４は、伝達された照合用データから管理データを生成する。そして、ステップＳ３０６の処理として、ＷＲＩＴＥシステムコールなどを発行することにより、生成された管理データを送信する。ＷＲＩＴＥシステムコールなどの発行により、管理データが送信データキューに格納され、ネットワークアダプタがデータを送信可能な状態になると、割り込みが発生し、割り込みハンドラにより、送信データキューのデータが読み出されて、ネットワークなどに送信される。

このようにして送信された管理データは、専用のＩＣカードなどに限らず、通常のパーソナルコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）や携帯電話などのメモリに格納することができる。また、フレキシブルディスク、光ディスク、不揮発性の半導体メモリなどの着脱可能な一般的な記憶媒体に記録することができる。そして、その記憶媒体を譲渡することにより、その記憶媒体に格納されている管理データが表す価値の譲渡を行うことができる。ただし、二重の譲渡を防止するために以下に説明するようにして譲渡するのが望ましい。

管理データ受信部１０５は、譲渡の対象などとなる管理データ１１０を受信する。受信された管理データ１１０は、管理サーバ１００のメモリに展開される。そして、管理データ１１０に署名データなどが含まれていれば、その署名データが正しいかどうかを判断してもよい。

置換部１０６は、管理データ受信部１０５で受信された管理データから照合用データを取得し、まず、その照合用データがデータベース部１０１で管理されているテーブルに格納されているかどうかを判断する。例えば、図２（ｃ）に示されるテーブルの照合用データの列に格納されているかどうかを判断する。もし、その照合用データが格納されていなければ、管理データ１１０の送信者などに、無効な照合用データを含む管理データが送信された旨を返信などする。反対に、その照合用データがデータベース部１０１で管理されているテーブルに格納されていれば、有効な照合用データを含む管理データであると判断する。有効な照合用データを含めば、新たな照合用データを準備し、この照合用データにより、管理データ１１０に含まれる照合用データとデータベース部１０１で管理されているテーブルに格納されている照合用データを置き換える。これにより、価値の情報に新たな照合用データが関連付けされる。

また、照合用データと関連付けられている他の情報があれば、その情報を用いてさらにチェックを行ってもよい。例えば、識別情報が照合用データと関連付けられていれば、管理データを管理データ受信部１０５に受信させた利用者や端末装置の識別情報を取得し、比較を行う。比較の結果がＯＫでなければ、無効である旨の返信などを行う。比較の結果がＯＫであれば、照合用データと関連付けられている識別情報と管理データに含まれている識別情報を、次に説明する置換管理データ送信部１０７による管理データの送信先となる利用者や端末装置の識別情報に書き換える。

管理データに譲渡回数が含まれている場合には、譲渡回数を更新する。また、更新前の譲渡回数が初期値を示していれば、置き換え前の照合用データがデータベース部１０１で管理されているテーブルに格納されているかどうかに加えて、照合用データと関連付けられている他の情報を用いたチェックを行ってもよい。例えば、その管理データを発行した際に受信された管理データ発行要求が存在するかどうかを管理サーバのログによりチェックを行ったり、実際に銀行などから金銭の振り込みが実際に行われたかどうかを銀行などのサーバ装置に問い合せたりしてもよい。もちろん、このようなチェックや問い合わせの処理は、管理データが管理サーバ１００に受信されるたびに行ってもよい。しかし、一般には、このようなチェックや問い合せの処理には時間を要する。そこで、このようなチェックや問い合せの処理の実行は、更新前の譲渡回数が初期値を示していたり、所定の値以下であったり、所定の値以上である場合に行うことに限ることで、処理の時間を短縮することが可能となる。また、異なるサーバに格納されたデータと照合を行うことにより、管理データの不正な作出などを検出することができる。

置換管理データ送信部１０７は、置換部１０６により、新たに準備された照合用データによりその照合用データが置換された管理データ１１１を送信する。管理データ１１１の送信は、管理データ１１０の送信元に対して行ってもよい。あるいは管理データ１１０の受信とともに送信先を示す情報が受信されたり、あるいは、管理データ１１０の中に送信先を示す情報が含まれていたりすれば、その送信先へ管理データ１１１を送信するようになっていてもよい。

例えば、データベース部１０１で管理されているテーブルに、図４（ａ）に示すように、照合用データとして"１３１７１９２"が９９５円という価値の情報と関連付けられて格納されているとする。この状態で、管理データ１１０として、図４（ｂ）に示すような照合用データとして"１３１７１９２"を含む管理データ１１０が管理データ受信部１０５により受信されたとする。すると、管理データ１１０に含まれる照合用データ"１３１７１９２"は、図４（ａ）のテーブルに格納されているので、管理データ１１０は有効な照合用データを含む管理データであると判断される。そこで、置換部は、新たな照合用データとして、例えば"１４９１６２５"を準備する。そして、この照合用データにより、図４（ａ）に示すテーブルの照合用データ"１３１７１９２"と図４（ｂ）に示す管理データに含まれる照合用データ"１３１７１９２"とを置き換える。この結果、図４（ａ）に示すテーブルは図４（ｃ）に示すような、データを有するテーブルになり、図４（ｂ）に示す管理データ１１０は図４（ｄ）に示すようになる。この結果、図４（ｄ）に示す管理データが管理データ１１１として送信される。

なお、照合用データを置き換える際に、照合用データに関連付けられている価値情報の表す金額などのうち一定の額や一定の割合を控除するようにしてもよい。このように控除を行うことにより、管理サーバの運営者が管理サーバの運営などのための費用を得ることが可能となる。

なお、図４（ａ）に示すテーブルの照合用データの書き換えは、照合用データの列に格納されているデータに対する更新操作として実行してもよい。あるいは、書き換えの対象となる照合用データ（上の例での"１３１７１９２"）に関連付けられている価値の情報などを読出して一時的に記憶し、書き換えの対象となる照合用データを含む行を削除し、新たに準備された照合用データ（上の例での"１４９１６２５"）と一時的に記憶した価値の情報などを新たな行のデータとして格納されるようにテーブルに対するデータの挿入の操作として実行してもよい。また、更新操作として実行するのではなく、照合用データが削除されたことを示す列（削除フラグ）をテーブルに備えておき、書き換えの対象となる照合用データを格納する行の削除フラグの値を、その行が削除されたことを示す値に更新するとともに、準備された照合用データを含む行を新たにテーブルに挿入してもよい。また、テーブルに挿入される行には、書き換え前の照合用データが格納されていてもよい。これにより、不正などが発覚した場合に、書き換えの履歴をさかのぼることができる。

また、管理データの照合用データの書き換えは、その文言通り、メモリに展開されている管理データの部分のうち照合用データの部分を書き換えて実行してもよい。あるいは、新たに準備された照合用データを含む管理データを新たに生成してもよい。

図４（ｄ）に示す管理データが置換管理データ送信部１０７により送信された後、再度、図４（ｂ）に示す管理データが管理データ受信部１０５で受信されても、それに含まれる照合用データ１３１７１９２は、図４（ｃ）に示すテーブルに格納されていない（あるいは、削除フラグの列がテーブルに備わっている場合には、削除フラグの値が削除されたことを示す値になっている）。したがって、無効な照合用データを含む管理データと判断される。これにより管理データの二重使用を防止できる。

図５は、データベース部１０１、管理データ受信部１０５、置換部１０６、置換管理データ送信部１０７における処理の流れを説明するフローチャートを例示する。このフローチャートが例示する処理は、ソフトウェアによる情報処理として実現可能である（他の図面のフローチャート、シーケンス図により例示される処理も同様である。）。あるいは、上述したように専用の回路によるハードウェアのみの構成によってもこのフローチャートが例示する処理を実行することも可能である（他の図面のフローチャート、シーケンス図により例示される処理も同様である。）。

ステップＳ５０１の処理として、管理データ受信部１０５により、管理データ１１０が受信される。その後、管理データ１１０がメモリに展開などされる。そして、ステップＳ５０２の処理として、置換部１０６により、メモリに展開された管理データ１１０より照合用データが取得される。取得された照合用データが、ステップＳ５０３の処理において、価値の情報と関連付けてデータベース部１０１に格納されていることを確認する。もし、格納されていなければ、管理データ１１０に無効な照合用データが含まれている旨のエラーの返信などをする。

ステップＳ５０４の処理として、新しい照合用データを準備する。例えば、乱数発生器により得られる乱数を新しい照合用データとする。そしてステップＳ５０５の処理として、管理データ１１０の照合用データを新しい照合用データに置き換える。「管理データ１１０の照合用データ」とは、メモリに展開された管理データ１１０に含まれる照合用データのみならず、ステップＳ５０３において価値のデータと関連付けて格納されている照合用データをも意味する。最後にステップＳ５０６の処理として、照合用データを書き換えられて得られる管理データ１１１を置換管理データ送信部１０７により送信する。

このように、乱数として発生された照合用データに価値を関連付け、管理データが通過するたびにその照合用データを置き換えることにより、管理サーバから送信される管理データの照合用データの予測がつかないようにすることができる。この結果、異なる照合用データに同じ価値が関連付けられることを防止でき、また、管理データの二重使用等を防止することができる。

（保管サーバ）
上述した管理サーバを用いることにより、乱数として発生された照合用データを含む管理データが発行され、有効な照合用データを含む管理データを送信し返信される管理データを受信することにより照合用データが書き換えられる。これにより、管理データの二重使用を防止することができる。以下では、さらに管理データの譲渡等を、匿名性を保ちながら行うために管理サーバの機能を拡張するためなどに用いられる保管サーバについて説明を行う。

図６は、管理サーバ６０１と、決済サーバ６０２と、保管サーバ６０３と、利用者端末６０４とからなるシステム６００の構成を示す。管理サーバ６０１と、決済サーバ６０２と、保管サーバ６０３と、利用者端末６０４とは、それぞれのサーバと端末の通信アダプタなどのハードウェアを用いて通信が可能となっている。システム６００においては、利用者端末６０４の利用者が、管理サーバ６０１で発行される管理データを得るために、利用者端末６０４と決済サーバ６０２との間で決済の処理を行う。例えば、決済サーバ６０２が銀行の振り込みを処理するサーバとなっており、利用者が管理サーバ６０１の運営者などの銀行口座に振り込みを行うことにより決済の処理が行われる。そして決済の処理が行われたことを示す結果が管理データ発行要求として決済サーバ６０２から管理サーバ６０１に送信されると、管理データが管理サーバ６０１に返信される。その後、管理データは決済サーバ６０３から保管サーバ６０３を経由して利用者端末６０４へ譲渡される。保管サーバ６０３は、管理データを決済サーバ６０２から受信すると、管理データの二重使用を防止するために、新たな照合用データに置き換えるために、管理サーバ６０１に管理データを送信し、照合用データが置き換えられた管理データを受信し保管する。その後、保管サーバ６０３は、利用者端末６０４から管理データの要求があれば、保管されている管理データを送信する。

もちろん、保管サーバ６０３が決済サーバ６０２を認証などして信頼できるのであれば、保管サーバ６０３は決済サーバ６０２から受信した管理データを管理サーバ６０１に送信する必要はない。しかし、もし保管サーバ６０３に送信された管理データが決済サーバ６０２内に消去されずに残り、決済サーバ６０２が不正な侵入などされてしまうと、不正に決済サーバ６０２にアクセスを行った者が管理データを入手してしまう可能性があるので、保管サーバ６０３は決済サーバ６０２から受信した管理データを管理サーバ６０１に送信するのが好ましいと言える。

図７は、システム６００における決済処理から管理データの利用者への譲渡までの処理の一例を説明するシーケンス図である。

ステップＳ７０１の処理として、利用者端末６０４と決済サーバ６０２との間で、管理データの発行のための決済の処理が行われる。例えば、利用者端末６０４よりクレジットカード番号等と決済金額を提示して、決済サーバ６０２がクレジットカード番号等の正しさを確認等する。あるいは、利用者端末６０４より銀行口座への振り込みの申込を行い、決済サーバ６０２が振込先の銀行口座番号や振込人に付加する識別文字列などを返信する。その後、振込が行われたことについての確認を決済サーバ６０２側にて行う。なお、決済処理により、利用者端末６０４から決済サーバ６０２へ利用者や利用者端末６０４の識別情報が決済サーバに伝達されてもよい。この場合、識別情報は、後に決済サーバ６０２から管理サーバ６０１へ送信される管理データ発行要求の中に含まれる。

本発明の一実施形態において、ステップＳ７０１の処理における決済処理を特定する番号などが決定され、この番号が決済サーバと利用者端末とで共有される。決済処理を特定する番号は、例えば、決済サーバが、生成する管理データを一意に識別する番号であったり、利用者端末６０４と決済サーバ６０２との間の通信のセッションを特定するセッションＩＤ（セッションを一意に特定するセッション識別情報）であったりしてもよい。この決済処理を特定する番号は、乱数として管理サーバが生成するのが好ましい。また番号の一部が乱数であってもよい。この場合、乱数以外の部分には利用者や利用者端末６０４を特定する番号などが含まれていてもよい。以下、決済処理を特定する番号として、セッションＩＤが用いられるとして説明を行う。ただし、本発明では、決済処理を特定する番号はセッションＩＤに限定されない。また、決済処理を特定する番号をＩＤ情報と称する場合がある。

クレジットカード番号等の正しさや振込等の確認がされると、ステップＳ７０２の処理として、決済サーバ６０２から管理サーバ６０１へ管理データ発行要求が送信される。この管理データ発行要求の中に、決済された金額などの情報が含まれる。なお、「決済された金額」は、利用者端末６０４と決済サーバ６０２との間での決済金額から所定の手数料を差し引いた額であってもよい。

管理データの発行要求に応じて、ステップＳ７０３の処理として、管理サーバ６０１から管理データ（「管理データ１」と呼ぶ）が決済サーバ６０２へ送信される。

ステップＳ７０４の処理として、決済サーバ６０２は、受信した管理データ１と上述のセッションＩＤとを保管サーバ６０３に送信する。

保管サーバ６０３が決済サーバより管理データ１とセッションＩＤを受信すると、ステップＳ７０５の処理として、受信した管理データを管理サーバ６０１へ送信し、管理データ１に有効な照合用データが含まれていることの確認と、その照合用データの置き換えを管理サーバ６０１に依頼する。

なお、管理サーバ６０１は、保管サーバ６０３より照合用データの書き換えが依頼された場合、譲渡回数は増加させない構成になっており、また、照合用データと関連付けられている識別情報と管理データに含まれている識別情報を書き換えない構成となっているとよい。例えば、保管サーバ６０３のＩＰアドレスが管理サーバ６０１に登録されており、登録されているＩＰアドレスから管理データを受信した場合には、譲渡回数を増加させず、識別情報も書き換えない構成となっていてもよい。

ステップＳ７０６の処理として、管理サーバ６０１にて、管理データ１に有効な照合用データが含まれていることを確認して照合用データを書き換えた管理データ２を生成し、保管サーバ６０３に返信される。そして、保管サーバ６０３にて、その管理データ２がセッションＩＤに関連付けて記憶される。

管理データ２がセッションＩＤに関連付けて記憶されたことを通知するために、ステップＳ７０７の処理として、保管通知が保管サーバ６０３から決済サーバ６０２へ送信される。

決済サーバ６０２が保管通知を受信すると、ステップＳ７０８の処理として、利用者端末６０４へ寄託通知が送信され、管理データが保管サーバ６０３に保管されたことが利用者に伝えられる。

その後、利用者は、利用者端末６０４を操作して、保管サーバ６０３に保管された管理データを要求するために、ステップＳ７０９の処理として、保管サーバ６０３に対して、管理データの送信要求として、セッションＩＤを送信する。保管サーバ６０３では、セッションＩＤに管理データ２が関連付けて記憶されていることを確認すると、ステップＳ７１０の処理として、管理データ２を返信し、セッションＩＤとの関連付けを破棄する。

もちろん、図６と図７とに示される構成、処理などを用いなくても、管理データを利用者に発行することができる。例えば、決済サーバが管理サーバから管理データを受信し、直接その管理データを利用者端末へ送信するようにしてもよい。しかし、決済手段として銀行振込を採用した場合などには、決済の確認までタイムラグが生じるので、決済サーバは管理サーバから受信した管理データを次に利用者端末と通信可能になるまで保持しておく必要がある。しかしこれでは、どの管理データが誰に発行されたかの情報を決済サーバが知ることとなり、匿名性が損なわれる。

また、決済サーバが管理データの発行要求とともに管理データの送信先を管理サーバに送信し、管理サーバがその送信先に発行した管理データを送信する構成を採用することもできる。しかし、これでも、管理データが誰に発行されたかの情報を管理サーバが知ることとなり、やはり匿名性が損なわれる。

図６と図７とに示される構成、処理では、管理サーバ６０１は、どの利用者の利用者端末に対して管理データを発行して送信するか知る必要がなくなる。また、決済サーバ６０２は利用者端末６０４と管理サーバ６０１から送信される管理データを関連付けることはできるが、それは一時的なものに過ぎない。管理データを保管サーバ６０３に送信すると、保管サーバ６０３側で照合用データが書き換えられてしまうからである。また、保管サーバ６０３は、管理データを決済サーバ６０２と利用者端末６０４との通信セッションにより決まる情報と関連付けるので、利用者を識別する必要がない。

図８は、保管サーバ６０３の機能ブロック図を示す。図８の機能ブロック図において、保管サーバ８００は、預管理データ受信部８０１と、管理データ送信部８０２と、管理データ受信部８０３と、保管部８０４と、ＩＤ受信部８０５と、預管理データ送信部８０６とを有する。

預管理データ受信部８０１は、管理データ８０７とＩＤ８０８とを受信する。管理データ８０７とＩＤ８０８とは、図７のステップＳ７０４においての説明での決済サーバから保管サーバへ送信される管理データ１とセッションＩＤとに相当する。ただし、後に説明されるように、預管理データ受信部８０１は、管理データ８０７とＩＤ８０８を決済サーバのみより受信するとは限らない。

ＩＤ８０８は、管理データ８０７を一意に特定する情報であることが望ましい。このため、預管理データ受信部８０１は、受信したＩＤの履歴を管理し、過去に受信したＩＤと一致するものを受信した場合には、ＩＤの再送要求を返信してもよい。また、受信したＩＤの履歴は、後に説明される保管部８０４が管理するテーブルなどで管理することもできる。すなわち、保管部８０４が管理するテーブルに同じＩＤが格納されていればＩＤの再送要求を返信してもよい。

預管理データ受信部８０１は、受信した管理データ８０７とＩＤ８０８とをメモリに展開する。そして、管理データ８０７のメモリアドレスなどを管理データ送信部８０２へ渡すことにより管理データ８０７を伝達し、ＩＤ８０８のメモリアドレスを保管部８０４へ渡すことによりＩＤ８０８を伝達する。

管理データ送信部８０２は、預管理データ受信部８０１より伝達された管理データ８０７を送信する。送信先は、管理サーバである。送信の結果、管理サーバにて管理データ８０７に含まれる照合用データの有効性が確認されると、照合用データの書き換えが行われ、書き換え後の管理データ８０９が返信される。

管理データ受信部８０３は、管理データ送信部８０２からの管理データ８０７の送信に応じて管理サーバより返信される管理データ８０９を受信する。上述したように管理データ８０７の少なくとも照合用データが置き換えられたものが管理データ８０９となっている。管理データ受信部８０３は、受信した管理データ８０９をメモリに展開し、そのメモリアドレスなどを保管部８０４に渡すことにより、管理データ８０９を伝達する。

保管部８０４は、預管理データ受信部８０１より伝達されたＩＤ８０８と管理データ受信部８０３より伝達された管理データ８０９とを関連付けて保持する。ＩＤ８０８と管理データ８０９とは、異なる時に保管部８０４に伝達される。このために、保管サーバ８００は、例えば預管理データ受信部８０１が受信した管理データ８０７とＩＤ８０８とに一意の識別情報を付与するようにしてもよい。そして、預管理データ受信部はＩＤ８０８とともにその一意の識別情報を保管部８０４に伝達する。また、管理データ送信部８０２が管理データ８０７を送信するために管理サーバと通信セッションを開始するとその通信セッションをその一意の識別情報と関連付ける。そして、管理データ８０９が受信されると、通信セッションから一意の識別情報を取得し、管理データ受信部８０３は、管理データ８０９とともにその一意の識別情報を保管部８０４に伝達する。これにより、保管部８０４では、ＩＤ８０８と管理データ８０９とを関連付けることができる。また、保管サーバ８００が付与した一意の識別情報が管理データ８０７に含まれて送信されるようになっていてもよい。管理サーバは、その一意の識別情報を変更することなく、照合用データを書き換える。

保管部８０４は、ＩＤと管理データとを関連付けて保管するためにテーブルを用いてもよい。図９はそのようなテーブルを示している。図９では、"ｅ９８７ａｂｃ"というＩＤと照合用データとして"１４９１６２５"を含む管理データとが関連付けて保持されている。"ｅ９８７ａｂｃ"というＩＤは、例えば図７におけるステップＳ７０１の処理として行われる決済処理のための利用者端末と決済サーバと間の通信セッションのＩＤなどである。

なお、保管部８０４にＩＤ８０８と管理データ８０９とが関連付けて格納された場合、ステップＳ７０７の保管通知となる情報が送信されるようになっていてもよい。この保管通知は、例えば、預管理データ受信部８０１が管理データ８０７とＩＤ８０８とを受信したＡＣＫとして返信されるようになっていてもよい。

ＩＤ受信部８０５は、ＩＤ８１０を受信し、ＩＤ８１０と保管部８０４にて関連づけて保管されている管理データの検索を行う。検索の結果、ＩＤ８１０と関連付けて保管されている管理データが存在すれば、ＩＤ受信部８０５はその管理データを読出し、預管理データ送信部８０６へ伝達する。また、ＩＤ８１０とその管理データとの関連付けを解消あるいは破棄する。解消あるいは破棄は、具体的には、図９に示すテーブルからＩＤ８１０が格納されている行データを削除することにより実現される。あるいは、図９に示すテーブルに削除フラグを格納する列を設けて、削除されたことを示す値を格納することで、解消あるいは破棄されたことを表現するようになっていてもよい。

預管理データ送信部８０６は、ＩＤ受信部８０５から伝達された管理データを送信する。管理データの送信先は、ＩＤ８１０の送信元であることが想定される。ただし、管理データの送信先がＩＤ８１０とともにＩＤ受信部８０５により受信されたなどの場合には、その送信先へ管理データを送信するようになっていてもよい。

図１０は、保管サーバ８００における管理データとＩＤとを受信し保管するまでの処理の流れを説明するフローチャートの一例である。ステップＳ１００１の処理として、預管理データ受信部８０１により、管理データとＩＤとを受信する。ステップＳ１００２の処理として、その管理データを、管理データ送信部８０２により、管理サーバへ送信する。そしてステップＳ１００３の処理として、管理データ受信部８０３により、管理データを受信する。その後、ステップＳ１００４の処理として、保管部８０４により、ステップＳ１００１で受信されたＩＤとステップＳ１００３で受信された管理データを関連付けて保管する。

図１１は、保管サーバ８００におけるＩＤを受信しそのＩＤと関連付けられて保管されている管理データを送信するまでの処理の流れを説明するフローチャートの一例である。ステップＳ１１０１の処理として、ＩＤ受信部８０５により、ＩＤを受信する。ステップＳ１１０２の処理として、そのＩＤと関連付けられて管理データが保管部８０４に保管されていることを確認する。もし確認できなければ、エラーをＩＤの送信元などに返信する。確認ができれば、ステップＳ１１０３の処理として、ＩＤと関連づけて保管されている管理データを読み出す。そして、ステップＳ１１０４の処理として、ＩＤと管理データとが関連付けられて格納されている状態を解消する。例えば、図９に示されるテーブルから上述にように行データを削除する。その後ステップＳ１１０５の処理として、預管理データ送信部８０６により、管理データを送信する。

このような構成の保管サーバを、図６、図７に示すように決済サーバと管理サーバとを組み合わせることにより、匿名性を保ちつつ管理データの発行が行える。

また、このような保管サーバを経由することにより、利用者間でも管理データを譲渡することができる。「利用者間」と記載したが、この場合、一方の利用者は物やサービスを購入する者であり、他方はその物やサービスを提供する者であり、その物やサービスの対価として管理データが一方の者から他方の者へ譲渡される場合が想定される。特に、他方はＷＥＢサーバなどを用いてインターネットからアクセスされる仮想的な店舗であってもよい。すなわち、管理データを電子マネーとして使用することにより、財物や役務の提供に対する代金の決済処理を行うことができる。すなわち、保管サーバが決済処理を行うサーバとして動作することになる。また、保管サーバを用いることにより、個人間などの一般の利用者間でも管理データの譲渡をすることが可能となる。

図１２は、利用者間で管理データを譲渡するシステム１２００の構成を示す。システム１２００を参照しながら、管理サーバ１２０１と、保管サーバ１２０３と、譲渡者端末１２０４と、譲受者端末１２０５とを有する。譲渡者端末１２０４の利用者（譲渡人）が譲受者端末１２０５の利用者（譲受人）へ管理データを譲渡する場合の処理の流れについて以下に説明する。

譲渡人は、あらかじめ、管理サーバから管理データの発行を受けたり、決済サーバを介して管理データを取得したり、決済サーバと保管サーバを介して管理データから取得したりしておく。あるいは別の譲渡人より、管理データの譲渡を受ける。この場合の譲渡としては、これから説明されるように保管サーバを介して行われてもよいし、別の譲渡人から管理データが記録された光ディスクや可搬型の不揮発性半導体メモリなどの記憶媒体の譲渡を受けたり、電子メールの添付データなどとして譲渡を受けたりしていてもよい。

図１３は、保管サーバを介しての管理データの譲渡の流れを説明するシーケンス図である。ステップ１３０１の処理として、譲渡者端末１２０４と譲受者端末１２０５との間で管理データの譲渡の合意をする。この合意は、無償にて譲渡人が譲受人に管理データを譲渡する合意であったり、上述のように譲受人が物やサービスを提供することの引き替えに譲渡人が管理データを譲渡する合意であったりする。なお、この合意のために、譲渡人の使用する譲渡者端末（第１の端末）と譲受人の使用する譲受者端末（第２の端末）とが相互に認証し合ってもよい。例えば、暗号化された通信セッションを確立するために第１の端末と第２の端末との間で暗号化と復号化のための暗号鍵を共有する。

また、相互認証の際には、その相互認証を一意に特定する情報を決める。例えば、ＷＥＢショップで買い物などを行う場合には、ＷＥＢサーバと端末との間の暗号化された通信セッションのＩＤなどを用いる。

譲渡の合意あるいは相互認証が終了すると、譲渡人側の端末は新たに管理データの発行を受けたり、既に発行がされたり第三者から譲渡がされたりした管理データの中から選択を行い、管理データ３とセッションＩＤとを保管サーバ１２０３へ送信する。管理データ３とセッションＩＤとを受信した保管サーバは、ステップＳ１３０３の処理として管理データ３を管理サーバへ送信する。管理サーバが管理データ３に含まれる照合用データが有効であると確認を行うと、新たに準備した照合用データによる置換を行い、ステップＳ１３０４の処理として管理データ４を保管サーバへ返信する。これにより、管理データ３は無効な照合用データを含む管理データとなり二重に使用ができなくなる。

保管サーバが管理データ４を受信すると、ステップＳ１３０２で受信したセッションＩＤと関連付けて保管を行い、ステップＳ１３０５の処理として保管通知を譲渡者端末へ送信する。保管通知を受信した譲渡者端末は、ステップＳ１３０６の処理として、寄託通知を譲渡者端末へ送信する。

寄託通知を受信した譲受者端末は、ステップ１３０７の処理として、管理データの送信要求を譲渡合意の際のセッションＩＤとともに保管サーバへ送信し、これに応じて保管サーバは管理データ４をステップＳ１３０８の処理として返信する。

以上のように保管サーバを構成することにより、管理データの発行の際、そして、管理データの譲渡の際に同じ処理を保管サーバで行うようにすることができる。また、管理データの匿名性なども確保できる。

（実施形態２）
上述の実施形態１において、価値として貨幣価値のように可分な価値が用いられる場合には、管理データが表す価値に上限を設けてもよいことについて説明した。例えば、５０００円を上限とすると、１３０００円の価値は、例えば、５０００円を表す管理データ２つと、３０００円を表す管理データ１つとにより表される。この場合の３０００円を表す管理データのように、上限の価値に満たない価値を表す管理データを「端数管理データ」と呼ぶことにする。

管理データを用いて商品や役務の代金の決済が行われる場合を考えると、代金の額が上記でいう上限になるとは限らない。このため、端数管理データを含む管理データにより代金が支払われたり、釣り銭の代わりに端数管理データを含む管理データが支払いとは逆の方向の管理データの流れで譲渡されたりする。このため、端数管理データの数は増加することになる。この結果、管理サーバのデータベース部の管理するデータが増加してしまうなどの問題が生ずる。そこで、以下では、端数管理データの増加を防ぐ構成について説明を行う。

（管理サーバ）
本実施形態に係る管理サーバは、実施形態１に係る管理サーバ１００において、管理データ受信部１０５が端数管理データ受信手段と、支払額受信手段とを有し、置換部１０６が端数変更手段と、釣管理データ生成手段とを有し、置換管理データ送信部１０７が端数管理データ送信手段と、釣管理データ送信手段とを有する。

端数管理データ受信手段は、端数管理データを受信する手段である。受信された端数管理データは、他の一または複数の管理データとともに、保管サーバより送信され管理サーバに受信され照合用データの有効性の確認がされることが主に想定される。端数管理データ受信手段は、端数管理データを受信するとメモリに展開し、端数管理データに含まれる照合用データのアドレスなどを取得して、端数変更手段に伝達する。

支払額受信手段は、管理データ受信部１０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データの表す価値のうち、譲渡が行われる価値を表す。すなわち、保管サーバを経由して譲渡者端末から譲受者端末へ譲渡されるべき価値を表すことが主に想定される。そして、譲渡が行われない価値が存在すれば、その価値は後述のように釣管理データとして譲渡者端末へ送信されることになる。

端数変更手段は、支払額受信手段が受信した価値を上述の上限の価値で除算を行った時の余りが０で無い場合に、端数管理データ受信手段により受信された端数管理データの表す価値にその余りを加算する処理を行う。例えば、上限額が５０００円で支払額受信手段が受信した価値が１３０００円であれば、１３０００円を５０００円で割り算を行うと、３０００円が余りとなる。そこで、端数管理データ受信手段が受信した端数管理データがデータベース部１０１により、１０００円を表していれば、１０００円に３０００円を加算した４０００円を表すようにデータベース部１０１が管理するデータベースの変更操作などを行う。

具体的には、端数変更手段は、端数管理データ受信手段からで伝達されたアドレス等により指定される照合用データで図２（ａ）などに示されるテーブルの検索を行いその照合用データがテーブルに格納されているのを確認すると、その照合用データに関連付けられている価値の値に上述の余りを加算する。加算した結果がもし上述の上限を超えていれば、加算した結果のかわりに上限の価値をテーブルに登録し、新たに照合用データを準備してテーブルに挿入し、加算した結果から上述の上限を引いた額を関連付ける。例えば、端数管理データ受信手段からで伝達されたアドレス等により指定される照合用データに１０００円が関連付けられており、上述の余りが４５００円であったとする。すると加算した結果は５５００円となり、上限の５０００円を超えている。そこで、端数管理データ受信手段からで伝達されたアドレス等により指定される照合用データには上限の５０００円を関連づけ、新たに準備される照合用データには５００円を関連付ける。もちろん、５０００円と５００円とに関連付けるのは一例であり、５５００円の上限を超えないように複数の価値に任意に分けることができる。例えば、２５００円と３０００円とであってもよい。

釣管理データ生成手段は、管理データ受信部１０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データの表す価値のうち、支払額受信手段が受信した価値を引いた価値（「釣価値」という。）が０でなければ、釣価値を表す管理データを生成する。新たに管理データを生成してもよいし、管理データ受信部１０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データを再利用するように、その管理データが表す価値に釣価値を加えてもよい。そして、もし加えた結果が上限を超えていれば、新たな管理データを生成して、管理データに上限を超える価値が関連付けられないようにする。

端数変更手段、釣管理データ生成手段それぞれは、端数管理データ受信手段が受信した端数管理データが含む照合用データ、釣管理データ生成手段が生成した釣価値を表す管理データが含む照合用データのそれぞれを、新たな照合用データを準備して書き換えてもよい。

端数管理データ送信手段は、端数変更手段により価値が加算された管理データ、また必要に応じて新たに生成された管理データを送信する。

釣管理データ送信手段は、釣管理データ生成手段で生成された管理データを送信する。

また、本実施形態において、保管サーバの預管理データ受信部８０１は、管理データ及びＩＤとともに、支払額情報を受信可能となっている。支払額情報とは、管理データの譲渡により譲渡されるべき価値を示す情報である。そして、預管理データ受信部８０１は、支払額情報が受信された場合には、受信したＩＤに関連付けられて保管部８０４に保管されている管理データを検索し、得られた管理データと受信した管理データとともに支払額情報を管理データ送信部８０２に伝達する。この場合、受信したＩＤに関連付けられて保管部８０４に保管されている管理データは、譲受者端末より送信された端数管理データとなっている。管理データ送信部８０２は、管理データとともに伝達された支払額情報を送信する。

また、管理データ受信部８０３は、釣管理データも受信可能となっている。釣管理データが受信された場合には、保管サーバは、保管部８０４に管理データが保管されると、保管通知とともに釣管理データを、預管理データ受信部８０１が受信した管理データの送信元へ返信する。

図１４は、本実施形態において、保管サーバを介しての管理データの譲渡の流れの一例を説明するシーケンス図である。ステップＳ１４０１の処理として、ステップＳ１３０１と同様に譲渡の合意を譲渡者端末と譲受者端末との間で行う。このとき、その合意では、単に管理データの譲渡のみならず、管理データの譲渡により譲渡される価値も合意する。例えば、商品の値段、送料などである。そして、このような場合に譲渡者端末が保管サーバへ送信する管理データを支払管理データという。

ステップＳ１４０２の処理として、譲受者端末から保管サーバへ、端数管理データ１とセッションＩＤとを保管サーバへ送信する。このとき、譲受者端末である旨の情報も送信してもよい。ステップＳ１４０３の処理として、保管サーバは、受信した端数管理データ１を管理サーバへ送信し、その有効性を確認させ、ステップＳ１４０４の処理として、保管サーバは、端数管理データ２を管理サーバより受信する。そして、セッションＩＤと関連づけて端数管理データ２を保管する。

なお、譲受者端末に端数管理データが無ければ、保管サーバには端数管理データを送信する必要はなく、したがって、保管サーバが端数管理データを管理サーバに送信する必要もない。

譲渡者端末は、ステップＳ１４０５の処理として、支払額と支払いのための支払管理データ１とセッションＩＤを保管サーバに送信する。保管サーバは、支払管理データ１と支払額とを管理サーバに送信する。また、保管サーバは、セッションＩＤからそれに関連付けられている端数管理データの有無を検出し、もしそのような端数管理データが存在すれば、その端数管理データもともに管理サーバへ送信する。なお、ステップＳ１４０２において、譲受者端末から譲受額が送信されてもよく、この場合は、譲渡者端末から送信される支払額と譲受額とが同じであることを確認してもよい。もし、同じでなければ譲受者端末、譲渡者端末へエラーを通知する。また、ステップＳ１４０２において、譲受者端末から譲受額が送信され、ステップＳ１４０５において、譲渡者端末から支払額が送信されない構成もある。この場合には、支払管理データ１に関連付けられている価値の値が譲受額以上であることを確認する。もし、譲渡に伴って手数料などを徴収する際には、支払管理データ１に関連付けられている価値の値から手数料などの額の値を引いたものが譲受額以上であることを確認する。また、端数管理データ１に関連付けられている価値から手数料などの額を徴収することにしてもよい。

管理サーバは、受信した支払管理データ２、支払額、端数管理データ１から、置換部１０６、置換管理データ送信部１０７により、端数管理データ３と支払管理データ２と釣管理データとを生成して、ステップＳ１４０７の処理として、保管サーバへ送信する。ここで、端数管理データ３は、端数変更手段で変更、生成された管理データであり、釣管理データは釣管理データ生成手段で生成された管理データである。

端数管理データ３と支払管理データ２と釣管理データとを受信した保管サーバは、支払管理データ３と端数管理データをステップＳ１４０２又はＳ１４０５で受信したセッションＩＤと関連づけて保管する。そして、ステップＳ１４０８の処理として、譲渡者端末へ釣管理データと保管通知を送信する。譲渡者端末は、ステップＳ１４０９において寄託通知を譲受者端末へ送信し、譲受者端末はステップＳ１４１０において、送信要求とセッションＩＤとを保管サーバへ送信し、これに応じて保管サーバは、セッションＩＤと関連付けて保管されている端数管理データ３と支払管理データ２をステップＳ１４１１の処理として、譲受者端末へ送信する。そして、セッションＩＤと端数管理データ３及び支払管理データ２との関連付けを破棄する。

このようにして、譲渡者端末から譲受者端末へ、譲渡合意で合意された価値が電子的に譲渡される。また、本実施形態では、管理データが表す価値に上限を設けられている場合に、譲受者端末から端数管理データを提供することにより、その端数管理データに釣り銭に相当する価値を加えることができ、端数管理データの数の増大を防止することができる。これにより、管理サーバのデータベース部１０１で管理するべき照合用データの数の増加を防止することができる。なお、「譲受者端末」と記載したが、譲受者端末は端末装置と同等の機能を有していればよく、サーバ装置を端末装置として用いられる場合も含まれる。譲渡者端末についても同様である。

（実施形態３）
本発明の実施形態３として、管理データを紛失しても回復が可能な構成について説明する。

図１５（ａ）は、本実施形態において管理サーバのデータベース部１０１にて管理するべきテーブルの一例を示す。本実施形態では、実施形態１または２のように照合用データと価値データとを関連付けるテーブルの他に、照合用データと所有者ＩＤ（所有者識別情報）とを関連づけるテーブルがデータベース部１０１にて管理される。所有者ＩＤとは、管理データを所有している者を識別するＩＤである。管理データを所有しているとは、管理データが表す価値が帰属する権原を有している者をいう。

所有者ＩＤとしては、例えば、管理サーバなどで発行されたＩＤ、電子メールアドレス、住民票コード、公開鍵証明書など人を識別できる情報を用いることができる。そして、管理サーバは、所有者ＩＤにパスワードなどを関連付けて保持するなどして、管理サーバなどに所有者ＩＤを提示してアクセスしてきた者を認証できるようにしておくのが好ましい。なお、所有者ＩＤをそのまま図１５（ａ）に示すテーブルに格納する必要はなく、所有者ＩＤのハッシュ値を算出し、そのハッシュ値を格納してもよい。

図１５（ｂ）は、本実施形態での管理データ発行要求を例示している。実施形態１又は２における管理データ発行要求と比較すると、本実施形態では、所有者ＩＤを示すタグを用いた＜所有者ＩＤ＞ＭＥＫＡＪＩＫＡ＜／所有者ＩＤ＞が追加されている。これは、発行される管理データの所有者が"ＭＥＫＡＪＩＫＡ"というＩＤ（識別情報）で識別されるべきことを表している。この"ＭＥＫＡＪＩＫＡ"は、例えば、決済サーバを識別するＩＤであったり、決済サーバと決済を行った利用者端末を識別したり、その利用者を識別するＩＤであったりする。

図１５（ｂ）のような管理データ発行要求を受信した管理サーバは、実施形態１又は２のように管理データを発行するとともに、発行された管理データに含まれる照合用データと管理データ発行要求で示される所有者ＩＤと、を照合用データと所有者ＩＤとを関連づけるテーブルに挿入する。なお、もし受信した管理データ発行要求に所有者ＩＤが含まれていなければ、照合用データと所有者ＩＤとを関連づけるテーブルに挿入などの操作を行う必要はない。

図１５（ｃ）は、照合用データとして"３５１１１３"を含む管理データが、図１５（ｂ）に示す管理データ発行要求に応じて生成された場合のテーブルを示す。照合用データと所有者ＩＤとを関連づけるテーブルには、"３５１１１３"と"ＭＥＫＡＪＩＫＡ"とが関連付けて格納されている。

図１５（ｄ）は、本実施形態における管理データの一例を示す。管理データは、照合用データを含む。また、所有者ＩＤを含んでいる。ただし、管理データに所有者ＩＤが含まれていることは必須ではないが、管理データを譲渡する場合に、譲渡人が管理データとともに譲受人の所有者ＩＤを管理サーバや保管サーバへ送信することにより、管理サーバや保管サーバにて管理データに含まれる所有者ＩＤを変更する。あるいは、譲渡人が譲受人の所有者ＩＤを、＜所有者ＩＤ＞と＜／所有者ＩＤ＞とにより囲まれた状態でその管理データに含ませて管理サーバや保管サーバへ送信することにより、管理サーバのデータベース部１０１が管理する照合用データと所有者ＩＤとを関連づけるテーブルの更新を行うことができる。

すなわち、管理データ受信部１０５が所有者ＩＤを含む管理データを受信した場合、置換部は、その管理データに含まれる照合用データに関連付けられている所有者ＩＤを、その管理データに含まれる所有者ＩＤに置き換えるなどして、その管理データに含まれる照合用データにその管理データに含まれる所有者ＩＤを関連づける。また、管理データ受信部１０５が受信した管理データに所有者ＩＤが含まれていなければ、その管理データに含まれる照合用データと所有者ＩＤとの関連付けを解消するようになっていてもよい。この操作を「照合用データと所有者ＩＤとの関連付けの変更操作」ということにする。また、この「照合用データと所有者ＩＤとの関連付けの変更操作」を行う部を所有者変更部という。所有者変更部は、例えば、置換部の内部モジュールとして実現されてもよい。

所有者変更部による変更操作は、新たな照合用データを準備し、受信した管理データに含まれる照合用データでありデータベース部に格納されている照合用データを、準備された照合用データに置換するとともに、受信した管理データに含まれる照合用データを準備された照合用データに置換してから、実行されるようになっていてもよい。

図１６は、本実施形態に係る管理サーバの機能ブロック図を例示する。管理サーバ１６００は、実施形態１又は２におけるように、データベース部１０１と、発行要求受信部１０２と、生成部１０３と、生成管理データ送信部１０４と、管理データ受信部１０５と、置換部１０６と、置換管理データ送信部１０７とを有し、さらに、所有者ＩＤ取得部１６０１と、照合用データ検索部１６０２と、検索データ送信部１６０３とを有している。また、実施形態１又は２における管理サーバがさらに認証用管理データ取得部１６０４と、所有者ＩＤ検索部１６０５と、所有者ＩＤ送信部１６０６とを有していてもよい。また、管理サーバ１６００は図１６に示すように、所有者ＩＤ取得部１６０１と、照合用データ検索部１６０２と、検索データ送信部１６０３と、認証用管理データ取得部１６０４と、所有者ＩＤ検索部１６０５と、所有者ＩＤ送信部１６０６とを有していてもよい。

所有者ＩＤ取得部１６０１は、所有者ＩＤ１６０７を取得する。例えば、利用者端末から送信された所有者ＩＤ１６０７をネットワークなどに接続されたネットワークアダプタを介して受信することにより取得する。そして、所有者ＩＤ１６０７を取得させた者の認証を行うのが好ましい。この認証としては、所有者ＩＤに関連付けられているパスワードが一致するかどうか、乱数などを生成し所有者ＩＤに関連づけられている公開鍵で暗号化して返信し、復号化の結果を受信して生成した乱数などに一致するかどうかなどで判断する。もし、認証できなければ、エラーを返信して処理を中止する。

照合用データ検索部１６０２は、所有者ＩＤ取得部１６０１が取得した所有者ＩＤにより、照合用データと所有者ＩＤとを関連付けるテーブルを検索し、その所有者ＩＤに関連付けられている照合用データを取得する。

検索管理データ送信部１６０３は、照合用データ検索部１６０２により取得された照合用データから管理データを生成して送信する。所有者ＩＤ取得部１６０１での認証ができなかったことによる処理の中止により、検索管理データ送信部１６０３が管理データを送信しなくなるようになっていてもよい。

図１７は、所有者ＩＤ取得部１６０１と、照合用データ検索部１６０２と、検索データ送信部１６０３による管理サーバ１６００の処理の流れを説明するフローチャートである。ステップＳ１７０１の処理として、所有者ＩＤ取得部１６０１により、所有者ＩＤを受信などにより取得する。ステップＳ１７０２の処理として、照合用データ検索部１６０２により、所有者ＩＤに関連付けられている照合用データを検索する。そして、検索データ送信部１６０３により、ステップＳ１７０３の処理として、検索された照合用データにより管理データを生成し、ステップＳ１７０４の処理として、管理データを送信する。

このように、管理サーバ１６００が所有者ＩＤ取得部１６０１と、照合用データ検索部１６０２と、検索データ送信部１６０３とを有することにより、所有者ＩＤを管理サーバ１６００に提示することで、その所有者ＩＤが所有している管理データを復元することができる。すなわち、管理データを紛失したとしても、所有者ＩＤにより管理データを復元することができる。

また、認証用管理データ取得部１６０４は、管理データ１６０９を取得する。ネットワークなどに接続されたネットワークアダプタなどを介した受信などにより取得を行う。

所有者ＩＤ検索部１６０５は、認証用データ取得部１６０４が取得した管理データ１６０９に含まれる照合用データを取得し、この照合用データにより、照合用データと所有者ＩＤとを関連付けるテーブルを検索し、所有者ＩＤを取得する。

所有者ＩＤ送信部１６０６は、所有者ＩＤ検索部１６０５により取得されたＩＤを送信する。なお、異なる複数の所有者ＩＤが所有者ＩＤ検索部１６０５により取得される場合が考えられる。例えば、また、複数の管理データが認証用管理データ取得部１６０４で取得された場合に異なる複数の所有者ＩＤが取得される可能性がある。この場合には、所有者ＩＤ検索部１６０５により取得された中で最も多く出現する所有者ＩＤのみを送信するようになっていてもよい。また、所有者ＩＤ送信部１６０６は、所有者ＩＤごとにパスワードなどにより送信先の端末装置や送信先の端末装置を利用する利用者の認証を行い、認証が成功した所有者ＩＤを送信するようにしてもよい。

図１８は、認証用管理データ取得部１６０４と、所有者ＩＤ検索部１６０５と、所有者ＩＤ送信部１６０６による管理サーバ１６００の処理の流れを説明するフローチャートである。ステップＳ１８０１の処理として、認証用管理データ取得部１６０４により、管理データを受信する。そして、所有者ＩＤ検索部１６０５により、ステップＳ１８０２の処理として、受信された管理データより照合用データを取得し、照合用データと関連付けられている所有者ＩＤを検索する。ステップＳ１８０４の処理として、検索により得られた所有者ＩＤを送信する。

このように管理サーバ１６００が認証用管理データ取得部１６０４と、所有者ＩＤ検索部１６０５と、所有者ＩＤ送信部１６０６とを有することにより、所有者ＩＤを失念してしまった場合であっても、手許に存在する管理データを管理サーバ１６００に提示することにより、所有者ＩＤを得ることができる。すなわち、管理データが一種の認証のデータとして用いられて、認証が行われると考えることができる。また、所有者ＩＤを管理サーバに提示することにより、他の管理データを得ることもできる。

（実施形態４）
上記の実施形態２のように管理データの表す価値に上限が定められている場合の実施形態３の変形例として、次のものがある。すなわち、譲受者端末が業として商品又は役務を提供しその提供の対価として管理データの譲受けを受ける場合などにおいて、そのような譲受者端末が管理データを保持するかわりに、保管サーバに保持させるようになっていてもよい。この場合、保管サーバが譲受者端末のかわりに保持する管理データの所有者ＩＤを、保管サーバに登録しておく。そして、保管サーバは、その所有者ＩＤの管理データを、価値の上限を表す管理データと端数管理データとに分けて保持しておく。例えば、異なるテーブルに保持しておく。

このように、本来は譲受者端末で保持するべき管理データを保管サーバで保持することにより、図１４のシーケンス図のステップＳ１４０２、ステップＳ１４０３、Ｓ１４０４、Ｓ１４１０、Ｓ１４１１の処理の実行を省略することが可能となり、ステップＳ１４０６において端数管理データ２は、保管サーバが譲受人のために保管している端数管理データを用いることになる。

以上のような構成により、例えば、価値の上限を表す管理データを譲受人の公開鍵により暗号化して保持する場合に新たな効果が発生する。すなわち、保管サーバが管理データを保管している際に外部からの不正侵入がされても、不正侵入者による管理データの不正な取得は、端数管理データに限定され、被害を小さくすることが可能となる。

また、保管サーバは、譲受人の識別情報を格納し、ステップＳ１４０７において受信される端数管理データ３と支払管理データ２に含まれる識別情報が、譲受人の識別情報となるようにしてもよい。これにより、保管データが不正にアクセスされ、端数管理データや支払管理データが不正に使用されることを防止できる。

保管サーバに保管された管理データは、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などを用いて譲受人が保管サーバの認証を受けてログインなどを行い、その端末装置にダウンロードするようになっていてもよい。これにより、譲受人は、ダウンロードした管理データを用いて支払などに充てることができる。

（実施形態５）
実施形態１において、図６、図７などを参照して、管理サーバ、決済サーバ、保管サーバ及び利用者端末からなるシステムの構成などについて説明した。本発明の実施形態５として、別のシステムの構成などについて説明する。

図１９は、本発明の実施形態５に係るシステム１９００の構成を示す。システム１９００は、管理サーバ１９０１と、決済サーバ１９０２と、保管サーバ１９０３と、利用者端末１９０４とを有する。実施形態１と同様に、管理サーバ１９０１と、決済サーバ１９０２と、保管サーバ１９０３と、利用者端末１９０４とは、それぞれ通信アダプタなどのハードウェアを備え、通信を行う。実施形態１では、利用者端末６０４の利用者は、管理サーバ６０１と直接通信を行う必要は無かったが、本実施形態では、様々な決済サーバの構成に対応できるように、利用者端末１９４０の利用者は、管理サーバ１９０１とも通信を行う構成となっている。

本実施形態では、管理サーバ１９０１と、決済サーバ１９０２と、保管サーバ１９０３と、利用者端末１９０４とは、基本的に実施形態１における管理サーバ６０１と、決済サーバ６０２と、保管サーバ６０３と、利用者端末６０４と同じ構成でよい。ただし、本実施形態では、管理サーバ１９０１と利用者端末１９０４とが通信を行うので、この点を実現する構成が異なる。すなわち、管理サーバ１９０１は、利用者端末１９０４に対してサービスを提供するための部が備わった構成となっている。例えば、管理サーバ６０１に、ウェブサーバとして動作する部が備わっており、端末装置１９０４に対してサービスを提供するようになっている。したがって、この場合には、利用者端末１９０４は、ウェブブラウザなどの閲覧ソフトウェアを用いて管理サーバ１９０１と通信を行う。また、利用者端末１９０４には、ウェブブラウザなどの他に、管理データを管理するアプリケーションプログラム（「管理データ管理アプリケーション」という）がインストールされていてもよく、管理データ管理アプリケーションを用いて管理サーバ１９０１と通信を行うようになっていてもよい。

図２０は、本実施形態におけるシステム１９００での決済処理が行われて管理データが生成されて利用者端末に受信されるまでの処理を説明するシーケンス図である。

ステップＳ２００１において、利用者端末１９０４から管理サーバ１９０１へ、利用者端末１９０４の識別情報を含む情報を送信する。識別情報とは、利用者端末１９０４を識別するための情報である。識別情報の例としては、利用者端末１９０４の製造番号や、ＭＡＣアドレス、ＩＰアドレスなどである。あるいは、利用者を識別する情報であるユーザＩＤや所有者ＩＤなどであってもよい。また、識別情報は、利用者端末１９０４の製造番号や、ＭＡＣアドレス、ＩＰアドレスなどの情報そのものである必要はなく、それらの情報に対して所定のハッシュ関数を適用して計算される値であってもよい。この識別情報は、管理サーバ１９０１により後に発行される管理データに埋め込まれてもよい。識別情報を管理データに埋め込むことにより、管理データを譲渡などする場合に、管理データが不正に他の利用者端末から取得されたものであるかどうかを検出することができる。これにより、管理データの使用の際の安全性を高めることができる。また、識別情報には、乱数が含まれるようになっており、管理サーバ１９０１への送信の都度、変化する部分があってもよい。

管理サーバ１９０１において、識別情報を受信する部を識別情報受信部という。

なお、ステップＳ２００１において、識別情報は、例えば、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のＰＯＳＴメッセージとして、利用者端末１９０４から管理サーバ１９０１に送信される。ただし、識別情報は、ブラウザで送信される必要はなく、上述した管理データ管理アプリケーションによって送信されてもよい。管理データ管理アプリケーションを用いれば、端末装置１９０４のハードウェアなどにアクセスを行い、ＭＡＣアドレスなどを取得することが容易に行える。

ステップＳ２００２においては、管理サーバ１９０１は、画面情報を利用者端末１９０４へ返信する。画面情報は、例えば、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いて記述され、管理データを発行するための入金処理や、発行された管理データを受け取るための処理を行うために使用することができる。

利用者端末１９０４が画面情報を受信すると、その画面情報の記述に従って画面表示を行う。例えば、受信された画面情報を、利用者端末１９０４で動作する管理データ管理アプリケーションがＲＥＡＤシステムコールなどを用いて取得すると、ウェブブラウザを起動して、そのウェブブラウザによって画面情報を表示させる。

図２１は、表示される画面情報の例を示す。例えば管理データ管理アプリケーションによりブラウザが起動されて画面情報が表示されると、図２１（ａ）に示されるように、「入金」、「管理データ受取」という表示を有するボタンが表示される。「入金」の表示を有するボタンが押下されると、画面情報に含まれるスクリプトなどの処理により、図２１（ｂ）に示される画面が表示される。

図２１（ｂ）は、銀行振込を行うための画面であって、「振込名義人名を１２３４５としてください」というメッセージが表示され、「振込」という表示を有するボタンが表示されている。１２３４５というのは、管理サーバ１９０１がステップＳ２００１において識別情報を受信した際に、管理サーバ１９０１側などで生成される情報である。あるいは、利用者端末１９０４側で生成され、ステップＳ２００１において管理サーバ１９０１に送信され、管理サーバ１９０１で承認などされた番号であってもよい。承認とは、利用者端末１９０４側で生成された情報が適切でることを確認することである。例えば、同じ情報を他の利用者端末で生成されて管理サーバ１９０１に送信されていないことを確認する。あるいは、識別情報がユーザＩＤであれば、そのユーザＩＤそのものやユーザＩＤに関連付けられた値である。利用者が銀行振込を行う際に、この情報を振込名義人名に含ませることにより、管理サーバ１９０１が銀行から振込通知を受信などした際に、その振込がどの識別情報の受信に対して返信した画面情報によって行われたかを知ることができる。また、図２１（ｂ）の画面には、振込先の銀行口座の情報が含まれていてもよい。

管理サーバ１９０１において、振込名義人名を生成あるいは承認、取得し、利用者端末１９０４に送信する部を、振込名義人名送信部という。

なお、図２１（ｂ）において、複数の銀行の中から利用者端末１９０４の利用者が契約している銀行を選択できるように、複数の銀行それぞれに対応したボタンが表示されていてもよい。

図２１（ｂ）の「振込へ」の表示を有するボタンが押下されると、利用者端末１９０４から銀行などの決済サーバ１９０２に対してアクセスが行われ、図２２（ａ）のようなインターネットバンキングなどのためのログイン画面が表示される。このログイン画面を介して利用者がログインを行い、振込の依頼を行うと、ステップＳ２２０４の処理として、利用者端末１９０４から決済サーバ１９０２に対して振込依頼が送信される。この振込依頼には、管理サーバ１９０１などの運営者の銀行口座の情報、振込名義人名、振込額が含まれる。なお、図２１（ｂ）の「振込へ」の表示を有するボタンには、振込先の口座の情報や、振込名義人名を含むＵＲＬが関連付けられており、そのＵＲＬにアクセスすると、決済サーバ１９０２に振込先の口座の情報や振込名義人名が伝えられ、振込の画面が開かれた場合に、振込先の口座の情報や振込名義人名が既にデフォルト値などとして入力された状態となっていてもよい。

振込の依頼が終わると、ステップＳ２２０４の処理として、利用者端末１９０４から管理サーバ１９０１へ、振込の依頼の処理が終わったこと旨を表す入金通知が送信される。この際には、ステップＳ２２０１で送信された識別情報や振込名義人名も送信される。すなわち、利用者端末１９０４にて、振込の依頼の処理が終了すると、利用者端末１９０４では、図２２（ｂ）に示されるような画面が表示される。図２２（ｂ）に示される画面は、「入金通知」という表示を有するボタンが表示されている。このボタンが押下されると、ステップＳ２００４の処理として、入金通知が利用者端末１９０４から管理サーバ１９０１へ送信される。入金通知は、利用者端末１９０４にて振込の依頼の処理が終了したことを、利用者端末１９０４から管理サーバ１９０１に知らせる情報である。

入金通知を受信した管理サーバ１９０１は、ステップＳ２２０５の処理として、入金通知とともに送信された情報から振込名義人名を取得し、決済サーバ１９０２に対して、その振込名義人名による振込が実際に依頼されたかどうかを問い合せる。決済サーバ１９０２は、その振込名義人名による振込があれば、ステップＳ２２０６の処理として振込通知を返信する。この振込通知には振込額も含まれていてよく、これにより、管理サーバ１９０１は振込額を得ることができる。

また、ステップＳ２００５とＳ２００６の処理の代わりに、管理サーバ１９０１は、例えば、５分に一回、振込の有無の問い合せを管理サーバ１９０１に行い、振込の有無を確認してもよい。

もし、振込がされていなければ、管理サーバ１９０１は、ステップＳ２００４の入金通知に対して、振込が確認できなかったことを通知する。この場合、管理データ管理アプリケーションなどによって振込の確認ができていないことの表示がされ、利用者は、しばらく時間が経過してから再度入金通知を行うことになる。

管理サーバ１９０１は、振込を確認すると、振込通知に含まれる振込名義人名から、どの識別情報の受信に対して画面情報によって行われたかをテーブルなどを検索して取得し、管理データを生成し、また、実施形態１で説明したように、振り込みの決済処理を特定する番号を生成する。決済処理を特定する番号は、本実施形態では、「送り情報」と称することにする。送り情報は、例えば、利用者端末１９０４と管理サーバ１９０１とがステップＳ２００１とＳ２００２とで通信を行ったセッションのＩＤであってもよい。また、振込み名義人名送信部で送信された振込名義人名を用いてもよい。ステップＳ２００７の処理として、生成した送り情報と管理データとを保管サーバ１９０３へ送信する。保管サーバ１９０３は、送り情報と管理データとを関連付けて、その保管部に保持する。

管理サーバ１９０１において、振込通知を受信する部を振込通知受信部と称する。また、管理データを生成するために、新たな照合用データを準備して、振込通知受信部が受信した振込通知に含まれる金額の額に相当する価値情報を関連づけてデータベース部１０１に記憶する部を照合用データ生成部と称する。また、新たに準備された照合用データから生成された管理データを送信する部を管理データ送信部と称する。また、本実施形態では、管理サーバ１９０１は、準備された照合用データと、識別情報受信部で受信された識別情報を関連付けてデータベース部１０１などに記憶する。

ステップＳ２００８の処理として、管理サーバ１９０１は、入金が確認された旨と送り情報とを利用者端末１９０４へ返信する。なお、ステップＳ２００１とＳ２００２とにおいて利用者端末１９０４と管理サーバ１９０１との通信において、送り情報が、セッションＩＤや振込名義人名として利用者端末１９０４に送り情報が通知されていれば、ステップＳ２００８では、送り情報を利用者端末１９０４へ返信する必要はない。

管理サーバ１９０１にて、その振込によって生成された送り情報を取得し、ステップＳ２００８の処理として、入金確認と送り情報とを利用者端末１９０４へ返信する。

利用者端末１９０４が、入金確認と送り情報とを受信すると、図２２（ｃ）に示される画面が表示される。図２２（ｃ）に示される画面においては、「入金の確認がされましたので、管理データ受取を押して下さい」というメッセージと、「管理データ受取」という表示を有するボタンが表示される。なお、図２２（ｃ）の画面は、ブラウザによって表示される必要はなく、管理データ管理アプリケーションによって表示されてもよい。例えば、ステップＳ２００８にて返信される入金確認と送り情報とが、ＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎ）のフォーマットを用いて送信され、そのフォーマットにおいてＣｏｎｔｅｎｔ−Ｔｙｐｅなどによって、管理データ管理アプリケーションがアプリケーションプログラムとして用いられることが指定されていてもよい。このような指定により、ブラウザが入金確認と送り情報とを受信すると、管理データ管理アプリケーションが起動され、図２２（ｃ）に示される画面が表示できる。

「管理データ受信」のボタンが押下されると、ステップＳ２００９の処理として、利用者端末１９０４から保管サーバ１９０３へ、送り情報が送信される。この送り情報が保管サーバ１９０３にて受信されると、ステップＳ２００６において格納部に送り情報と関連付けられて保管された管理データが読み出される。そして、ステップＳ２０１０の処理として、その管理データが保管サーバ１９０３から利用者端末１９０４に受信されて、利用者端末１９０４内に格納される。

図２３は、管理サーバ１９０１が、ステップＳ２００１において利用者端末１９０４から識別情報を受信してから、ステップＳ２００８において入金確認と送り情報とを送信するまでの処理を行うために参照するテーブルの構成と格納されるデータの遷移を説明する。図２３（ａ）に示すように、管理サーバ１９０１は、「識別情報」、「振込番号」、「金額」、「送り情報」という名前の列により構成されるテーブルを保持し、管理を行う。

管理サーバ１９０１がステップＳ２００１において識別情報を受信すると、そのテーブルに対して行データの挿入が行われる。識別情報が例えば９８７６５であれば、図２３（ｂ）に示されるように、識別情報の列の値が９８７６５である行がテーブルに挿入される。その行において、識別情報の列以外の列の値は、例えば、ＮＵＬＬ（図示せず）とされる。ＮＵＬＬとされることにより、まだ値が定まっていないことが表現される。

識別情報がステップＳ２００１において受信され、その識別情報に基づいて振込名義人名が決定されると、挿入された行の振込番号の列の値が、その振込名義人名に更新される。例えば、振込名義人名が図２１（ｂ）に示されるように１２３４５であれば、図２３（ｃ）に示すように、識別情報の列の値が９８７６５である行の振込番号の列の値が１２３４５に更新される。

管理サーバ１９０１がステップＳ２００６において振込通知を受信すると、その振込通知に含まれる振込名義人名を振込番号の列に有する行が検索され、振込通知に含まれる振込金額により金額の列の値が更新される。例えば、振込通知により、１２３４５という振込名義人名により５０００円が振り込まれたとすると、図２３（ｄ）に示すように、識別情報の列の値が９８７６５である行の金額の列の値が５０００に更新される。これにより、管理サーバ１９０１は、振込があったことが確認できるようになる。

管理サーバ１９０１が送り情報を生成し、ステップＳ２００７において保管サーバ１９０３に、送り情報を送信すると、「送り情報」の列の値が更新される。例えば、１２３４５という振込名義人名により５０００円が振り込まれ、２４６８１０という送り情報が生成されると、図２３（ｅ）に示すように、識別情報の列の値が９８７６５である行の送り情報の列の値が２４６８１０に更新される。これにより、管理サーバ１９０１は、９８７６５という識別番号に対して、管理データを生成して、保管サーバ１９０３に送信したことが確認できるようになる。

図２４は、利用者端末１９０４の機能ブロック図を示す。この機能ブロック図は、利用者端末１９０４にインストールされているアプリケーションプログラムの構成を示している。利用者端末１９０４には、ブラウザと管理データ管理アプリケーションとがインストールされている。ブラウザと管理データ管理アプリケーションとが協調して動作して決済処理から管理データの受信の処理を行う。

図２５は、利用者端末１９０４にインストールされているブラウザと管理データ管理アプリケーションとが協調して、図２０に示される決済処理が行われ、管理データが生成されて利用者端末に受信されるまでの処理のシーケンス図を示す。

ステップＳ２５０１は、ステップＳ２００１に対応している。ステップＳ２５０１においては、識別情報が、管理データ管理アプリケーションより送信されることを示している。管理データ管理アプリケーションを用いれば、ブラウザを用いるよりも容易に利用者端末１９０４のハードウェアなどにアクセスを行い、ＭＡＣアドレスなどのハードウェア固有の情報を取得することができる。

なお、ステップＳ２５０１の処理を実行するには、利用者端末１９０４にて管理データ管理アプリケーションを起動する。管理データ管理アプリケーションの起動により、例えば、図２６に示されるように、「入金（ポイント購入）」、「ポイントの受取」、「ポイントによる支払」の表示を有するボタンを含む画面表示が利用者端末１９０４のディスプレイなどに表示がされる。「入金（ポイント購入）」のボタンが押下されると、管理データ管理アプリケーションは、識別情報を算出などして、管理サーバ１９０１へ送信する。

ステップＳ２５０２は、ステップＳ２００２に対応している。ステップＳ２５０２においては、ステップＳ２５０１にて送信された識別情報に対して管理サーバ１９０１から返信される画面情報が、管理データ管理アプリケーションにより受信される。

管理データ管理アプリケーションが画面情報を受信すると、ステップＳ２５０３の処理として、管理データ管理アプリケーションはブラウザを起動し、画面情報の記述に従った画面表示を行う処理が行われる。例えば、管理データ管理アプリケーションは、受信した画面情報を一時ファイルに書き込み、その一時ファイルの名前をコマンドの引数などとしてブラウザに与えてブラウザを起動する。例えば、一時ファイルの拡張子と関連付けられているブラウザが起動されるようになっている。

ステップＳ２５０４、ステップＳ２５０５、ステップＳ２５０６、ステップＳ２５０７、ステップＳ２５０８は、それぞれステップＳ２００３、ステップＳ２００４、ステップＳ２００５、ステップＳ２００６、ステップＳ２００７、ステップＳ２００８に対応している。これらのステップの処理では、利用者端末１９０４では、ブラウザが管理サーバ１９０１、決済サーバ１９０２と通信を行う。

ステップＳ２５０９にて、ブラウザが入金確認と送り情報とを管理サーバ１９０１より受信すると、ブラウザは、管理データ管理アプリケーションを起動し、送り情報を管理データ管理アプリケーションに処理をさせる。上述したように入金確認と送り情報とが、ＭＩＭＥのフォーマットを用いた情報としてブラウザにより受信されると、そのフォーマットにおいてＣｏｎｔｅｎｔ−Ｔｙｐｅなどによって、管理データ管理アプリケーションにより処理することが指定されているので、ブラウザは管理データ管理アプリケーションを起動し、起動した管理データ管理アプリケーションは、送り情報を取得する。ステップＳ２５１０の処理として、管理データ管理アプリケーションは、保管サーバ１９０３へ送り情報を送信する。保管サーバ１９０３から返信される管理データを受信する処理をステップＳ２５１１の処理として行う。管理データ管理アプリケーションが管理データを受信すると、受信した管理データを、利用者端末１９０４の記憶装置（ハードディスクなど）に書き込む。

ブラウザから管理データ管理アプリケーションが起動された場合には、図２６の画面が表示されてもよい。利用者端末１９０４の利用者が「ポイントの受取」の表示を有するボタンを押下すると、ステップＳ２５１１とステップＳ２５１２との処理が開始されるようになっていてもよい。

図２７は、管理データ管理アプリケーションのモジュール構成図を示す。管理データ管理アプリケーション２７００は、識別情報取得部２７０１と、送り情報管理部２７０２と、管理データ管理部２７０３と、送受信部２７０４と、制御部２７０５とを有している。

識別情報取得部２７０１は、ステップＳ２５０１において送信される識別情報を取得する。例えば、利用者端末１９０４のハードウェアにシステムコールなどを用いてアクセスを行い、ＭＡＣアドレスや製造番号などを取得する。また、利用者端末１９０４の利用者のＩＤやパスワードなどの認証情報を識別情報として取得してもよい。また認証情報は、ファイルに格納されていたり、キーボードやカードリーダなどにより読み取られるようになっていたりしてもよい。また、認証情報の一部に乱数が含まれる場合には、識別情報取得部２７０１がその乱数を生成するようになっていてもよい。

また、識別情報取得部２７０１により取得された識別情報は、ステップＳ２５１１の処理により管理データが受信されるまで、利用者端末のハードディスクなどの二次記憶に記憶されるようになっていてもよい。管理データ管理アプリケーションが起動すると、二次記憶に識別情報が記憶されているかどうかを調べ、もし、記憶されていれば、受け取られていない管理データが保管サーバ１９０３に保管されている旨の表示を行い、利用者に注意を喚起してもよい。この場合、利用者が振込の依頼の処理を行っているのならば、管理データ管理アプリケーションは利用者にステップＳ２５０５の入金通知を管理サーバ１９０１に送信し、入金確認と送り情報を受信することができるように、ボタンなどを表示する。そして、そのボタンが押下されると、管理データ管理アプリケーションは入金通知を管理サーバ１９０１に送信する。

送り情報管理部２７０２は、ステップＳ２３１０において、ブラウザから渡された送り情報を管理する。管理とは、データのファイルへの書き込み、読み出し、削除、更新を意味する。ステップＳ２５０９の処理により、ブラウザから管理データ管理アプリケーションが起動される際に、ブラウザから渡された送り情報を所定のファイルに書き込む。また、ステップＳ２５１１の処理により、管理データが受信されると、所定のファイルを削除したり、所定のファイルから送り情報を削除したりする。これにより、送り情報が受信されたが、受信されていない管理データの有無をしらべることができる。

管理データ管理部２７０３は、管理データを管理する。ステップＳ２５１１にて受信された管理データは、管理データ管理部２７０３により、利用者端末１９０４の記憶装置（ハードディスクなど）に書き込まれ、また、管理データを用いた支払の処理の際に読み出し、削除、変更が行われる。

送受信部２７０４は、管理サーバ１９０１、保管サーバ１９０３と通信を行うための部である。

制御部２７０５は、識別情報取得部２７０１と、送り情報管理部２７０２と、管理データ管理部２７０３と、送受信部２７０４とを制御し、管理データの受信の処理、管理データを用いた支払の処理を行う。

図２８は、管理データを用いた支払の処理のシーケンス図を示す。図２８は、保管サーバを介しての管理データの譲渡についてのシーケンス図である図１４に対応している。図１４での譲受者端末が図２８での販売サーバに対応し、譲渡者端末が利用者端末に対応している。本実施形態では、利用者端末の内部で管理データ管理アプリケーションとブラウザとが協調して動作している。また、販売サーバは、ＷＥＢサーバとしての機能を有しており、ＷＥＢページの閲覧要求があれば、要求されたＷＥＢページを返信する。

ステップＳ２８０１において、利用者端末のブラウザなどへＵＲＬの入力や、ブラウザを操作してリンクを辿るなどの処理を行い、ウェブページの閲覧要求が販売サーバへ送信される。販売サーバが閲覧要求を受信すると、要求されたウェブページをステップＳ２８０２において返信する。

ステップＳ２８０２においてブラウザに返信されるウェブページには、商品などの購入の申込を行うための画面の記述がされているとする。例えば、図２９に示すように、「○○」として、購入が行われる商品などの名称が表示され、代金が例えば１００円として表示される。また、「購入」という表示を有するボタンが表示されている。このボタンには、購入が行われる商品などの識別番号が関連付けられている。また、必要に応じて、ウェブページには商品の配送先などを入力するテキストエリアが含まれており、「購入」という表示を有するボタンが押下されると、そのテキストエリアに入力された情報が送信されるようになっていてもよい。

「購入」という表示を有するボタンが押下されると、ステップＳ２８０３の処理として、購入情報が保管サーバに送信される。購入情報とは、販売サーバの識別情報、購入が行われる商品などの識別番号、商品などの数量、代金額を含む情報である。また、上述した商品などの発送先を含んでいてもよい。この購入情報は、図２９に示されるボタンに関連付けられた情報を用いて生成され、販売サーバに送信される。購入情報が販売サーバに送信されることにより、ブラウザを操作する利用者が販売サーバの運営者から商品などの購入の同意がされ、支払が管理データの譲渡によってされることの同意もされたことが示される。

すなわち、ステップＳ２８０１からステップＳ２８０３までの処理が行われることにより、譲受端末としての販売サーバと譲渡者端末としての利用者端末との間で譲渡の合意がされることになる。従って、ステップＳ２８０１からステップＳ２８０３までの処理がステップＳ１４０１に対応していることになる。

ステップＳ２８０４の処理として、販売サーバから支払指示とセッションＩＤがブラウザに送信される。支払指示には、譲渡されるべき価値の額（支払額）が含まれている。また、セッションＩＤは、上述の送り情報に対応する。支払指示とセッションＩＤとは、例えば、ＭＩＭＥフォーマットで記述され、Ｃｏｎｔｅｎｔ−Ｔｙｐｅなどによって、管理データ管理アプリケーションを用いて表示されることが指定されていてもよい。

また、販売サーバは、保管サーバに対して、端数管理データ１とセッションＩＤを送信する。これは、利用者端末から送信される管理データによる支払を受けるためである。

販売サーバから端数管理データ１とセッションＩＤを受信した保管サーバは、ステップＳ２８０６の処理として、端数管理データ１を管理サーバへ送信し、端数管理データ１が有効であるかどうかを判断させ、有効であれば、照合用データの書き換えを行わせ、その結果得られる管理データである端数管理データ２をステップ２８０７の処理において受信する。そして、送り情報と関連付けて保管する。

したがって、ステップＳ２８０５、Ｓ２８０６、Ｓ２８０７の処理は、ステップＳ１４０２，Ｓ１４０３、Ｓ１４０４の処理に対応している。

ステップＳ２８０４にて、販売サーバから支払指示とセッションＩＤを受信したブラウザは、管理データ管理アプリケーションを起動させ、販売サーバから受信した支払指示とセッションＩＤとの処理を行わせる。すなわち、起動した管理データ管理アプリケーションは、ステップＳ２８０９の処理として、ステップＳ２８０４で受信したセッションＩＤと支払指示に含まれる支払額とを、また、その支払額以上となるように管理データを管理データ管理部２７０３から選択して読み出して支払管理データ１として、保管サーバに送信する。支払額以上とは、選択された管理データが表す価値の額の合計額が、支払額以上となるこという。管理データ管理部２７０３から読み出される管理データは複数であってもよい。また、管理データ管理アプリケーションが起動すると、支払額を画面に表示し、ボタン押下を利用者に行わせるなどして、支払管理データの額などの確認を行わせてもよい。また、管理データ管理部２７０３で管理されている管理データが暗号化されて記憶されている場合には、復号のためのパスワードなどの入力が求められるようになっていてもよい。

ステップＳ２８０９において、管理データ管理アプリケーションからセッションＩＤ、支払額、支払管理データ１を受信した保管サーバは、セッションＩＤに、支払額と支払管理データ１を関連付けて保管する。また、他にセッションＩＤに関連付けて保管されている管理データがあるかどうかの検索を行い、そのような管理データがあれば、ステップＳ２８１０以降の処理を行う。

ステップＳ２８１０とステップＳ２８１１の処理は、ステップＳ１４０６、Ｓ１４０７の処理に対応している。保管サーバは、端数管理データ２と支払額と支払管理データ１を管理データに送信し、端数管理データ３、支払管理データ２と釣管理データとを受信する。

ステップＳ２８１２の処理として、保管サーバは管理データ管理アプリケーションに釣管理データを送信する。この釣管理データの送信は、ステップＳ２８０９にて受信された支払額と支払管理データ１の返信として行われてもよい。

ステップＳ２８１３の処理として、管理データ管理アプリケーションは、ブラウザを起動し、決済終了画面を表示させる。決済終了画面の記述は、ステップＳ２８１２にて、保管サーバが釣管理データとともに管理データ管理アプリケーションに送信するようになっていてもよい。さらに、決済終了画面の記述は、ステップＳ２８０５において、販売サーバが端数管理データ１とセッションＩＤとともに保管サーバに送信するようになっていてもよい。このように決済終了画面の記述が、販売サーバから送信され、保管サーバを経由して、利用者端末へ送信されることにより、電子的なデータそのものや電子的なデータのダウンロードなどのために使用するＵＲＬを決済終了画面の記述に含ませることにより、電子的なデータを販売に本実施形態を利用することができる。

ステップＳ２８１４にて管理サーバから受信された端数管理データ３と支払管理データ２は、ステップＳ２８０５にて受信されたセッションＩＤとともに保管サーバから販売サーバへ送信される（ステップＳ２８１４）。端数管理データ３と支払管理データ２の送信は、ステップＳ２８０５にて販売サーバから送信された端数管理データ１とセッションＩＤに対する返信として行われてもよい。

このように、支払指示とセッションＩＤとがブラウザなどにより受信されると、管理データ管理アプリケーションが起動し、管理データを用いた支払を行うことができるようになる。したがって、本実施形態においては、利用者は、ステップＳ２８０３にて購入情報を、ブラウザを用いて販売サーバに送信した後の決済の処理を行うために、従来技術におけるのと異なり、クレジットカード番号や振込先の口座番号などの煩雑なデータを入力する必要がなくなる。また、利用者端末１９０４に記憶された管理データを用いて支払を行うので、クレジットカードのようにその後の返済などについて心配する必要がない。したがって、利用者は簡便な操作で管理データを用いて支払を行うことができる。これにより、インターネットなどでの支払を安全かつ簡便に行うことができる。

（実施形態６）
本発明の実施形態６として、利用者が簡単にウェブサーバを用いた仮想的な店舗を開設できる技術について説明する。上述の実施形態５においては、販売サーバは保管サーバと通信を行う。このため、インターネットの一般的な利用者が自身のホームページを開設するために用いられているウェブサーバをそのまま販売サーバとして使用できない場合がある。そこで、本実施形態では、インターネットの一般的な利用者が自身のホームページを開設するために用いるウェブサーバと、保管サーバと通信を行い、利用者に代わって管理データの受信を行うように構成された販売サーバとの組み合わせについて説明を行う。

図３０は、インターネットなどの通信網３００１を介して、販売サーバ３００２とウェブサーバ３００３とが利用者端末３００４から利用可能になっているシステムの概要を示す。販売サーバ３００２は、実施形態５にて説明した販売サーバである。例えば、販売サーバ３００２は、注文画面ファイル３００５をそのファイルシステムに格納しており、ステップＳ２８０１において、利用者端末３００４にインストールされたブラウザ３００７からの閲覧要求が受信されると、ステップＳ２８０２において、注文画面ファイル３００５を返信することができる。

また、販売サーバ３００２は、特定の利用者のみが商品などの販売に用いるサーバではなく、複数の利用者が商品などの販売などに用いることができる。複数の利用者の間に特別な人間関係が存在していなくてもよい。複数の利用者が販売サーバ３００２を用いて商品などの販売を行う仮想的な店舗には、店舗を識別する情報として、店舗識別番号などがそれぞれ割り振られている。販売サーバ３００２の外部からは、店舗識別番号を用いて仮想的な店舗がアクセス可能であるとする。例えば、ある利用者が開設した店舗に４５６７という店舗識別番号が割り振られているとすると、４５６７を用いて、その店舗を販売サーバ３００２の外部からアクセスすることができる。

ウェブサーバ３００３は、インターネットの一般的な利用者が自身のホームページを開設するために用いられているウェブサーバである。インターネットの一般的な利用者は、ウェブサーバ３００３に割り当てられた自分のスペースに、ウェブページ３００６を置く。このとき、ウェブページ３００６には、販売サーバ３００２に格納された注文画面ファイル３００５へのリンクを設けておく。このリンクのＵＲＬには、上述した店舗の識別情報が含まれて構成される。例えば、ＵＲＬには、ｓｈｏｐｉｄ＝４５６７などを含み、店舗の店舗識別番号が４５６７であることを表す。

このようにリンクを設けることにより、インターネットの一般的な利用者は、ウェブページに商品などの広告を掲載し、その広告を見た利用者を注文画面ファイル３００５へ誘導し、商品などの販売の対価として得られる管理データを得ることが可能となる。

販売サーバ３００２に店舗を開設した利用者は、例えば、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などを用いて、販売サーバ３００２と通信を確立し、注文画面ファイル３００５や、注文を受け付けた旨を示す受注確認ファイル、注文を受け付けることができなかった旨を示す受注失敗ファイルなどをアップロードする。

図３１は、販売サーバ３００２が、アップロードされた注文画面ファイルの管理を行うためのテーブルの構成の一例である。販売サーバ３００２の外部から店舗の識別情報を用いてアクセスが行われた場合には、このテーブルを参照し、識別情報で指定される店舗を開設した利用者がアップロードした注文画面ファイルなどを取得して返信などする。例えば、ステップＳ２８０１において、販売サーバ３００２にて店舗の店舗識別番号を含む閲覧要求が受信された場合には、販売サーバ３００２は、店舗の店舗識別番号をキーとして、図３１のテーブルを検索し、注文画面ファイルＩＤを得て、その注文画面ファイルＩＤで指定されるウェブページを読み出して、ステップＳ２８０２にて返信を行う。

また、ステップＳ２８０４において、販売サーバ３００２にて購入情報が受信された場合には、販売サーバ３００２は、購入情報に含まれる店舗のＩＤを取得して、図３１のテーブルを検索し、受注確認ファイルＩＤと受注失敗ファイルＩＤとを得て、それらで指定されるウェブページを読み出して、ステップＳ２８０５にて、保管サーバへ端数管理データ１とセッションＩＤとともに送信する。

図３２は、販売サーバ３００２のファイルシステムの構成の一例を示す。「ｓｈｏｐｉｄ＝４５６７」、「ｓｈｏｐｉｄ＝６７８９」は店舗の店舗識別番号に対応したフォルダ（ディレクトリ）を示している。以下では、このようなフォルダを店舗フォルダと称することにする。店舗フォルダの中に、注文画面ファイル、受注確認ファイル、受注失敗ファイルが格納される。また、管理ファイルは、店舗に支払われた管理データを格納しているファイルを示す。例えば、管理ファイル３２０１は、店舗識別番号として４５６７を有する店舗に譲渡された管理データを格納する。ステップＳ２８０５において送信される端数管理データは、店舗フォルダの管理ファイルから読み出される端数の額の管理データとなる。また、ステップＳ２８１５で販売サーバが受信する端数管理データと支払管理データは、店舗フォルダの管理フィルに格納される。

店舗フォルダの管理ファイルに格納された管理データは、店舗の開設者がＦＴＰなどを用いてダウンロードすることが可能となっている。

なお、管理サーバに不正なアクセスが行われ、店舗フォルダの管理ファイルに格納された管理データが不正にダウンロードされ、不正に使用されることを防止するために、店舗フォルダには、店舗の開設者の利用する端末装置の識別情報などを含むファイル３２０２がアップロードされる。ステップＳ２８０５において販売サーバから保管サーバに送られるデータの中に、ファイル３２０２を含めることにより、ステップＳ２８１５にて保管サーバから販売サーバに送信される端数管理データ、支払管理データが、店舗の開設者のみが使用可能にすることができる。これにより安全性を高めることが可能である。

このように本実施形態によれば、誰でも仮想的な店舗を開設することができ、管理データにより支払を受けることができる。

以上のように、本発明においては、金銭的な価値などと関連付けられた照合用データを含む管理データを、利用者端末に記憶し、記憶された管理データを譲渡することにより、金銭的な価値などを譲渡することが電子的に行うことができる。これにより、管理データによる支払をインターネット上で行うことが可能となる。

従来、インターネットで金銭的な価値の譲渡を行うには、金銭的な価値と関連付けられたデータをサーバに保存して利用する技術と、金銭的な価値と関連付けられたデータをＩＣカードなどの記憶領域に記憶させ、そのＩＣカードなどを利用者に保持させて利用する技術に分類することができる。前者では、サーバにデータが管理されているので、安全性が高いが、支払などのためにデータの譲渡を行う都度、パスワードの入力などによって利用者を認証する必要がある。このため、使用が煩わしいという問題がある。一方、後者では、利用者はＩＣカードリーダなどにＩＣカードをかざすだけで支払が簡便に行うことができるが、データの偽造などの虞があり、また、ＩＣカードを紛失した場合に取り戻すことが困難であるという問題がある。また、前者、後者ともに、データのみを一般の利用者に譲渡するのは困難である。

一方、本発明は、照合用データをサーバで管理し、同時に、照合用データを含む管理データを利用者の端末装置に記憶するという点で折衷型であり、安全性と支払の簡便さを併せ持っている技術を提供する。

別の側面から説明を加えると、従来技術において通常のブラウザを用いて支払を行う場合には、クレジットカードや銀行振込、サーバ方のプリペイドマネーであっても、支払を行う者が正当な利用者であることを確認するために、カード番号、ＩＤやパスワード、アクセスコードなどの入力が求められる。これらのカード番号、ＩＤやパスワード、アクセスコードなどが覚えやすいものであると、セキュリティが脆弱となるので、複雑なものであることが好ましいとされ、複雑なものであると、記憶することが困難となるなどにより、逆に不便なシステムとなってしまう。

一方、本発明では、実施形態１などにおいて説明したように、管理サーバにより発行された管理データを利用者端末に格納し、必要に応じて、管理データを譲渡することにより価値の移転が行われる。管理データが有効なものであるかどうかは、管理サーバのデータベース部に管理データの照合用データの記録の有無により判断がされる、管理サーバを介して譲渡を行う都度、照合用データの書き換えが行われる。このため、管理データを所持しているものが正当な権利者であることが推定でき、ＩＤやパスワード、アクセスコードなどによって正当な所有者であることを証明する必要が低減でき、セキュリティを保ちつつ、利便性を維持することが可能となる。

また、実施形態５などにおいて説明したように、ブラウザを用いてインターネットのサイトに購入などの申込を行った場合、サイトからは送られる支払指示とセッションＩＤとを含む情報がブラウザにより受信されると、管理データ管理アプリケーションを自動的に起動させることができ、管理データ管理アプリケーションによる支払を行うことができる。セッションＩＤは、従来技術における例えば銀行口座に対応しているが、セッションＩＤはインターネットのサイトから送信されるので、利用者はセッションＩＤを入力する必要がなくなる。

また、実施形態２などにおいて説明したように、管理データが表す価値に上限を持たせることもでき、管理データを紛失したとき際の損害が大きくならないようにすることができる。以上より、本願発明は、産業上有用である。

Claims (18)

1. 照合用データに、価値情報とその価値情報が表す価値を所有する者の所有者識別情報とを関連付けるデータベース部と、
   第１の照合用データを含む第１の管理データを受信する管理データ受信部と、
   前記第１の照合用データが前記データベース部により第１の価値情報に関連付けられていれば、新たな照合用データを準備して、前記第１の価値情報に前記新たな照合用データを関連付けるとともに前記第１の管理データに含まれる前記第１の照合用データを前記新たな照合用データに置換した第２の管理データを生成する置換部と、
   前記第１の管理データに第１の所有者識別情報が含まれていれば、前記第１の所有者識別情報に前記新たな照合用データを関連付ける変更操作を前記データベース部に対して実行する所有者変更部と、
   前記第２の管理データを送信する置換管理データ送信部と、
   を有することを特徴とする管理サーバ。
2. 照合用データを含む管理データを受信する認証用管理データ受信部と、
   前記認証用管理データ受信部で受信された管理データに含まれる照合用データに、前記データベース部によって関連付けられている所有者識別情報を検索する所有者識別情報検索部と、
   前記所有者識別情報検索部により検索された所有者識別情報を送信する所有者識別情報送信部と、
   を有することを特徴とする請求項１に記載の管理サーバ。
3. 前記所有者識別情報送信部は、所有者識別情報の送信先を認証しその認証が成功することを条件に前記検索された所有者識別情報を送信することを特徴とする請求項２に記載の管理サーバ。
4. 前記所有者情報送信部は、前記検索された所有者識別情報が複数あれば、それら所有者識別情報に対する認証を行い認証が成功する所有者識別情報を送信することを特徴とする請求項３に記載の管理サーバ。
5. 送信された所有者識別情報を受信する所有者識別情報受信部と、
   前記所有者識別情報受信部で受信された所有者識別情報に、前記データベース部によって関連付けられている照合用データを検索する照合用データ検索部と、
   前記照合用データ検索部で検索された照合用データを含む管理データを生成して送信する検索管理データ送信部と、
   を有することを特徴とする請求項１から４のいずれか一に記載の管理サーバ。
6. 前記所有者識別情報受信部が受信する所有者識別情報の送信元を認証しその認証が成功することを条件に前記検索管理データ送信部が、検索された照合用データを含む管理データを生成して送信することを特徴とする請求項５に記載の管理サーバ。
7. 前記管理データ受信部は、
   第１の管理データとして、第１の端末より送信された、上限の量以下の価値を表す第１の価値情報に関連付けられた第１の照合用データを含む管理データを受信し、
   第２の端末より送信された、前記上限の量未満の価値を表す第３の価値情報に関連付けられた第３の照合用データを含む第３の管理データを受信する第３管理データ受信部を備え、
   前記上限と前記第３の価値情報が表す価値との差を越えない価値を、前記第１の価値情報の価値から差し引き前記第３の価値情報が表す価値に加算するデータベース変更部と、
   を有し、前記置換管理データ送信部は、
   前記第３の管理情報を前記第２の端末へ向けて送信することを特徴とする請求項１に記載の管理サーバ。
8. 端末装置より識別情報を受信する識別情報受信部と、
   振込名義人名を生成し、前記端末装置へ送信する振込名義人名送信部と、
   振り込まれた金銭の額と振り込みを行った振込名義人名を含む振込通知を受信する振込通知受信部と、
   新たな照合用データを準備して、前記受信された振込通知に含まれる金銭の額に相当する価値情報を関連づける照合用データ生成部と、
   前記照合用データを含む管理データを生成して送信する管理データ送信部と、
   を有し、
   前記データベース部は、前記受信された識別情報を所有者情報として前記生成された管理データに含まれる照合用データに関連付ける請求項１に記載の管理サーバ。
9. 前記管理データ送信部は、振込通知により行われた決済処理を一意に特定するＩＤ情報を、前記端末装置と異なる第２のサーバに前記管理データとともに送信し、前記決済処理を一意に特定するＩＤ情報を前記端末装置に送信する請求項８に記載の管理サーバ。
10. 前記決済処理を一意に特定するＩＤ情報は、前記生成された振込名義人名である請求項９に記載の管理サーバ。
11. 管理サーバ装置によるデータの送受信方法であって、
    前記管理サーバ装置が、照合用データに、価値情報とその価値情報が表す価値を所有する者の所有者識別情報とを関連付けて保持し、
    前記管理サーバ装置が、第１の照合用データを含む第１の管理データを受信し、
    前記管理サーバ装置が、前記第１の照合用データが第１の価値情報に関連付けられていれば、新たな照合用データを準備して、前記第１の価値情報に前記新たな照合用データを関連付けるとともに前記第１の管理データに含まれる前記第１の照合用データを前記新たな照合用データに置換した第２の管理データを生成し、
    前記管理サーバ装置が、前記第１の管理データに第１の所有者識別情報が含まれていれば、前記第１の所有者識別情報に前記新たな照合用データを関連付け、
    前記管理サーバ装置が、前記第２の管理データを送信することを特徴とする、価値情報に関連付けられたデータの送受信方法。
12. 前記管理サーバが、第１の端末より、上限の値以下の価値を表す第１の価値情報に関連付けられた第１の照合用データを含む第１の管理データを受信し、
    前記管理サーバが、第２の端末より、前記上限の値未満の価値を表す第２の価値情報に関連付けられた第２の照合用データを含む第２の管理データを受信し、
    前記管理サーバが、前記上限から前記第２の価値情報が表す価値の差を越えない価値を、前記第１の価値情報の価値から差し引き前記第２の価値情報が表す価値に加算し、
    前記管理サーバが、前記第２の端末へ前記第２の管理データを含む管理データを送信し前記第１の端末と前記第２の端末との間で決済処理を行う請求項１１に記載のデータの送受信方法。
13. 前記管理サーバ装置が、第３の管理データを受信し、
    前記管理サーバ装置が、前記第３の管理データに含まれる照合用データに関連付けられている所有者識別情報を検索し、
    前記管理サーバ装置が、検索された所有者識別情報を送信することを特徴とする請求項１１に記載の、価値情報に関連付けられたデータの送受信方法。
14. サーバ装置と決済サーバと保管サーバと利用者端末とのデータの送受信方法であって、
    前記利用者端末が、管理サーバへ前記利用者端末の識別情報を送信し、
    前記サーバ装置が、振り込みの決済処理を行う際の名義人名を前記管理サーバにて生成し、
    前記サーバ装置が、前記生成された名義人名を前記利用者端末へ送信し、
    前記利用者端末が、ブラウザを起動して前記名義人名を用いて前記決済サーバにて決済処理を行い前記決済処理を識別するＩＤ情報を取得し、
    前記決済サーバが、前記管理サーバに、決済が行われた名義人名と金額とを含む決済情報を送信し、
    前記管理サーバが、前記決済情報に含まれる金額の額に相当する価値情報に関連付けられた照合用情報を含んで生成された管理データに、前記識別情報を、価値を所有する者の識別情報として、関連付けてデータベースに記憶し、前記決済情報を識別するＩＤ情報と関連付けて前記保管サーバへ送信し、
    前記利用者端末が、前記決済処理を行った通知を前記管理サーバへ送信し、
    前記管理サーバが、前記名義人名を含む決済情報を受信した通知を前記利用者端末へ返信し、
    前記利用者端末が、前記決済処理を識別するＩＤ情報を前記保管サーバへ送信し、
    前記保管サーバが、前記利用者端末より送信されたＩＤ情報に関連付けて前記管理サーバが送信した管理情報を送信することを含む、価値情報に関連付けられたデータの送受信方法。
15. 管理データの譲渡を仲介するための保管サーバの動作方法であって、
    価値情報に関連付けられた照合用データを含む管理データを送信する第１の端末とその管理データを受信する第２の端末とが、相互の間で通信セッションを確立し、
    前記確立された通信セッションにより前記第１の端末と前記第２の端末とが、相互認証を行い、
    前記保管サーバが、前記第１の端末より送信される管理データと前記確立された通信セッションの識別情報とを受信し、
    前記保管サーバが、請求項１に記載の管理サーバと通信を行い、前記受信された管理データを前記管理サーバに送信し、前記管理データに含まれる照合用データを、新たに準備された照合用データに置換した置換済管理データを受信し、
    前記保管サーバが、前記受信された通信セッションの識別情報に関連づけて前記置換済み管理データを保管し、
    前記保管サーバが、前記第２の端末より、通信セッションの識別情報を受信してその通信セッションに関連づけられて保管されている置換済み管理データを返信することを特徴とする、価値情報に関連付けられたデータの処理方法。
16. 前記利用者端末が、前記サーバにおいて価値情報が関連付けられている照合用データを含む管理データを利用者端末に記憶し、
    前記利用者端末が、ブラウザを起動し、商品の販売または役務の提供を行うための第２のサーバより、前記サーバと前記ブラウザとの通信のセッションＩＤと支払うべき価格情報とを、前記ブラウザを経由して受信し、
    前記利用者端末が、前記記憶されている管理データを１以上選択して前記選択された管理データに関連付けられている価値情報の額を前記価格情報の額以上とし、
    前記利用者端末が、前記選択された管理データを前記セッションＩＤとともに第３のサーバへ送信する請求項１５に記載のデータ送信方法。
17. 識別情報を管理サーバに送信する送信部と、
    前記識別情報の送信の返信として、振り込みの決済処理を行う際の名義人名を表示するための画面情報を受信する受信部と、
    前記受信された画面情報を表示し決済処理を行うブラウザを起動する起動部と、
    前記起動されたブラウザによる決済処理の後、前記決済処理が行われたことの確認を前記管理サーバに要求する要求部と、
    前記決済処理が行われたことの確認が前記管理サーバにされて前記決済処理にて振り込まれた金額の額に相当する価値情報及び前記識別情報が前記管理サーバにて関連付けられた照合用データを含む管理データを受信する管理データ受信部と
    を有する端末装置。
18. 前記管理データ受信部は、前記決済処理が行われたことの確認が前記管理サーバによって行われて前記管理サーバより受信される情報であって、前記管理サーバが前記決済処理を一意に特定するＩＤ情報を前記管理サーバと異なるサーバへ送信して、管理データを受信する請求項１７に記載の端末装置。

Images