利用者端末の動作方法及びサーバ装置
【課題】ダウンロードしたコンテンツの形式を扱うことができるプログラムが利用者の利用する電子機器にインストールされていないと利用者は損害を蒙る。
【解決手段】ブラウザがインストールされている利用者端末にプログラムをインストールし、前記ブラウザが第１のサーバへ送信するＨＴＴＰ要求とともに送信するクッキー情報を前記利用者端末に記憶し、前記ブラウザが第２のサーバ装置へＨＴＴＰ要求を送信して前記第１のＵＲＬへのリダイレクト命令を返信として受信し、前記ブラウザが前記リダイレクト命令に従って前記第１のサーバへＨＴＴＰ要求とともに前記クッキー情報を送信して前記第１のサーバにて前記クッキー情報の確認がされることを条件として送信される前記第２のサーバ装置へのリダイレクト命令を返信として受信する。
【解決手段】ブラウザがインストールされている利用者端末にプログラムをインストールし、前記ブラウザが第１のサーバへ送信するＨＴＴＰ要求とともに送信するクッキー情報を前記利用者端末に記憶し、前記ブラウザが第２のサーバ装置へＨＴＴＰ要求を送信して前記第１のＵＲＬへのリダイレクト命令を返信として受信し、前記ブラウザが前記リダイレクト命令に従って前記第１のサーバへＨＴＴＰ要求とともに前記クッキー情報を送信して前記第１のサーバにて前記クッキー情報の確認がされることを条件として送信される前記第２のサーバ装置へのリダイレクト命令を返信として受信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツを利用者端末にダウンロードして処理する際に、その利用者端末にそのコンテンツを処理するプログラムがインストールされているかどうかをサーバ装置側から検出する技術に関する。コンテンツとしては、例えば電子的な価値を表す情報があり、そのようなコンテンツを処理するプログラム電子財布がある。
【背景技術】
【０００２】
現実の貨幣の価値やチケットなどの債権・債務の関係を電子的なデータに関連付け、このような電子的なデータの交換によって決済処理を行う技術が知られている（例えば、特許文献１参照。）。また、その技術を用いて、インターネットでの商取引の決済が行われている。この場合、現実の貨幣などの価値を電子的なデータを管理するためのアプリケーションプログラムなどとして電子財布が用いられる（例えば、特許文献２参照。）。
【特許文献１】特開２００２−７４２３７号公報
【特許文献２】特開２００７−９４９８４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、利用者が利用する電子機器に電子財布がインストールされていない状態で、決済処理が開始すると、不利益が生じる。例えば、決済処理の途中まで進んだ段階で、利用者が利用する電子機器に電子財布がインストールされていないことが発覚すると、決済処理を最後まで行うことができないことになる。そして、利用者は注文の商品などを購入することができず、また、商品などの販売者は売り上げを計上できないという不利益を蒙る。
【０００４】
同様のことが、文書情報、音楽情報や動画情報のダウンロードについても言え、ダウンロードした文書情報、音楽情報や動画情報の形式を扱うことができるプログラムが利用者の利用する電子機器にインストールされていないと、別の形式の文書情報、音楽情報や動画情報を扱うことができるプログラムがインストールされていても、新たにプログラムをインストールしなければならない。
【課題を解決するための手段】
【０００５】
本発明の一実施形態として、次のような、ブラウザがインストールされている利用者端末と、ＨＴＴＰ要求を処理する第１と第２のサーバ装置を有するシステムの動作方法を提供する。すなわち、ブラウザは、第１のサーバ装置へ第１のＨＴＴＰ要求を送信する。例えば、電子財布で決済を行う商取引を開始するためのウェブページの要求を送信する。あるいは、特定のプログラムで再生や編集などを行うコンテンツのダウンロードを開始するためのウェブページの要求を送信する。その要求に対して、第１のサーバ装置は、第２のサーバ装置への第１のアクセス命令を返信する。ブラウザが第１のアクセス命令を受信すると、第１のアクセス命令に従って第２のサーバ装置へ第２のＨＴＴＰ要求を送信する。この第２のＨＴＴＰ要求には、第１のＨＴＴＰ要求のＵＲＬが含まれていてもよい。また、利用者端末に電子財布や特定のプログラムがインストールされているかどうかを示す所定のクッキー情報が記憶されていれば、その所定のクッキー情報が第２のＨＴＴＰ要求とともに送信されるようになっている。
【０００６】
第２のサーバ装置は、第２のＨＴＴＰ要求とともに所定のクッキー情報が受信されるか否かに依存して返信される第２のアクセス命令を、ブラウザへ返信する。ブラウザは、第２のアクセス命令を受信すると、第２のアクセス命令に従って第１のサーバ装置への第３のＨＴＴＰ要求を送信する。この第３のＨＴＴＰ要求のＵＲＬは、第１のＨＴＴＰ要求のＵＲＬに所定のパラメータとその値などを付加したものであってもよい。そして、第１のサーバ装置は、第３のＨＴＴＰ要求が、前記第２のサーバ装置が前記第２のＨＴＴＰ要求とともに所定のクッキー情報を受信していない場合に返信する第２のアクセス命令に従ったＨＴＴＰ要求である場合には、所定のクッキー情報を前記利用者端末に記憶させるプログラムをダウンロードするためのリンク情報を含む返信を行う。
【０００７】
これにより、利用者端末に電子財布や特定のプログラムがインストールされていなければ、利用者端末には、その電子財布などの必要なプログラムをダウンロードしてインストールするためのリンク情報が表示される。したがって、利用者端末の利用者は、利用者端末に必要なプログラムがダウンロードされていないことを知ることができる。また、容易にその必要なプログラムをダウンロードしてインストールすることができる。
【０００８】
また、その必要なプログラムが利用者端末にダウンロードされると、所定の種類のコンテンツとのその必要なプログラムが関連付けられるようになってもよい。これにより、ブラウザがその種類のコンテンツを受信すると、その必要なプログラムがブラウザにより起動され、コンテンツが必要なプログラムに入力されるようになっていてもよい。また、その必要なプログラムが利用者端末にダウンロードされると、所定のクッキー情報がブラウザの管理する記憶領域に記憶あれるようになっていてもよい。
【０００９】
これにより、第１のサーバ装置が、第３のＨＴＴＰ要求が、第２のサーバ装置が前記第２のＨＴＴＰ要求とともに所定のクッキー情報を受信している場合に返信される第２のアクセス命令に従ったＨＴＴＰ要求である場合には、所定の種類のコンテンツをダウンロードするためのリンク情報を含む返信を行うことにより、スムーズにコンテンツの処理ができ、電子財布を用いた決済やコンテンツの再生や編集などを行うことができる。
【００１０】
また、第１のサーバ装置が、第３のＨＴＴＰ要求に対して行う返信には、次の別のプログラムが含まれていてもよい。すなわち、ブラウザが利用者端末に記憶させた第３のＨＴＴＰ要求のＵＲＬの全体または一部を取得する。そして、所定のパラメータの値を取得する。その値と所定の値とを比較し、その比較結果に応じて、プログラムをダウンロードするためのリンク情報を利用者端末のディスプレイなどに表示するようになっていてもよい。
【００１１】
これにより、第１のサーバ装置は、プログラムをダウンロードするためのリンク情報と所定の種類のコンテンツをダウンロードするためのリンク情報とを別々に記憶する必要がなくなる。
【００１２】
なお、上記では、第１のＨＴＴＰ要求を受信するサーバ装置と第３のＨＴＴＰ要求を受信するサーバ装置とを同一としたが、異なるサーバ装置であってもよい。
【００１３】
本発明の別の一実施形態として、ブラウザがインストールされている利用者端末に別のプログラムをインストールし、そのブラウザが第１のサーバ装置へ送信するＨＴＴＰ要求とともに送信するクッキー情報であってその別のプログラムがインストールされていることを表すクッキー情報を利用者端末に記憶し、そのブラウザが第２のサーバ装置へＨＴＴＰ要求を送信して第１のサーバ装置への第１のアクセス命令を返信として受信し、そのブラウザが第１のアクセス命令に従って第１のサーバ装置へＨＴＴＰ要求とともにそのクッキー情報を送信して第１のサーバ装置にてそのクッキー情報の確認がされることを条件として送信される前記第２のサーバ装置への第２のアクセス命令を返信として受信し、そのブラウザが第２のアクセス命令に従って第２のサーバ装置へＨＴＴＰ要求をして得られるコンテンツをその別のプログラムへの入力とする、利用者端末の動作方法が提供される。
【００１４】
この利用者端末の動作方法によれば、利用者端末にその別のプログラムがインストールされているかどうかを第１のサーバ装置が判断した結果を第２のサーバ装置に伝達することができるので、第２のサーバ装置は、適切なコンテンツを利用者端末に送信できるようになり、課題が解決される。
【００１５】
また、その別のプログラムに入力されるコンテンツの種類とその別のプログラムとを前記利用者端末において関連付け、そのブラウザが第２のサーバ装置へＨＴＴＰ要求を送信して返信されるコンテンツを受信すると、受信されたコンテンツの種類に関連付けられたその別のプログラムが起動されるようになっていてもよい。
【００１６】
これにより、そのブラウザがコンテンツを受信すると、そのブラウザによりその別のプログラムが自動的に起動されることになり、例えば、利用者端末の利用者にコンテンツ利用を容易に提供できる。
【００１７】
また、第２のアクセス命令に含まれるＵＲＬにはパラメータが含まれており、第２のアクセス命令にしたがって第２のサーバ装置へ送信されるＨＴＴＰ要求の返信には、そのブラウザが利用者端末のメモリに記憶したＵＲＬを取得させ、取得されたＵＲＬに含まれるそのパラメータの値を変数に記憶させ、その変数の値を所定の値と比較させ、その別のプログラムがインストールされているかどうかを利用者端末に判断させる第３のプログラムが含まれていてもよい。
【００１８】
これにより、第２のアクセス命令に含まれるＵＲＬのパラメータの値として、利用者端末にその別のプログラムがインストールされているかどうかが示されるので、例えば、第２のサーバ装置には、利用者端末にその別のプログラムがインストールされている場合とそうでない場合との２つの返信を用意する必要がなくなる。
【００１９】
その別のプログラムは、価値が関連付けられた情報を管理する電子財布であり、そのブラウザが第２のアクセス命令に従って第２のサーバ装置へＨＴＴＰ要求をして得られるコンテンツは、その電子財布が管理するべき価値が関連付けられた情報と、その電子財布が管理する価値の関連付けられた情報の一部または全てとの送信先と、のいずれか一以上を含んでいてもよい。
【００２０】
これにより、例えば、第２のサーバ装置に対する第１のＨＴＴＰ要求が商品などの購入の申込である場合、利用者端末にその電子財布がインストールされているかどうかを第１のサーバ装置により判断し、その結果が第２のサーバ装置に伝達されるので、第２のサーバ装置は、適切な支払命令などをコンテンツとして送信することができる。
【００２１】
また、本発明の一実施形態として、利用者端末より第１のＨＴＴＰ要求を受信する第１要求受信部と、受信された第１のＨＴＴＰ要求に対して、その第１のＨＴＴＰ要求とは別のＵＲＬへの第１のアクセス命令を返信する返信部と、返信された第１のアクセス命令に応じて利用者端末が返信として受信した第２のアクセス命令に応じて利用者端末より第２のＨＴＴＰ要求を受信する第２要求受信部と、第２のＨＴＴＰ要求に対する応答を行う応答部と、を有するサーバ装置が提供される。
【００２２】
これにより、サーバ装置は、第１のアクセス命令の示すＵＲＬへ利用者端末をアクセスさせて、利用者端末にその別のプログラムがインストールされているかどうかを判断させた結果を第２のＨＴＴＰ要求として得ることができる。
【００２３】
また、その利用者端末は、第１のアクセス命令に応じて送信するＨＴＴＰ要求とともに送信するクッキー情報を記憶し、返信部による第１のアクセス命令によるその別のＵＲＬへのアクセスをその利用者端末が行うと、そのクッキー情報が送信されるようになっていてもよい。
【００２４】
これにより、その別のプログラムがその利用者端末にインストールされているかどうかを第１のサーバ装置は、クッキー情報によって判断することができる。
【発明の効果】
【００２５】
本発明の実施形態によれば、利用者が用いる電子機器としての利用者端末に、必要なプログラムがインストールされているかどうかを、サーバ装置側が検出することができる。これにより、コンテンツのダウンロードなどを行う前に、利用者に警告を発したり、必要なプログラムのインストールを勧めたり、利用者が用いる電子機器にインストールされているプログラムが扱える情報の形式でダウンロードなどを行うことができる。
【００２６】
特に電子財布については、本発明の実施形態によれば、利用者が用いる電子機器に電子財布がインストールされているかどうかを、サーバ装置側が検出することができる。これにより、決済処理を行う前に、利用者に警告を発したり、電子財布のインストールを勧めたり、インストールされている電子財布が扱える形式の情報を利用者端末に送信して決済処理を行うことができる。
【発明を実施するための最良の形態】
【００２７】
以下、本発明を実施するための最良の形態について、図を参照しながら実施形態として説明を行う。なお、本発明はこれらの実施形態に何ら限定されるものではない。本発明の属する技術分野における通常の知識を利用しながらこれらの実施形態を変形して本発明を実施することも可能である。なお、以下では、サーバ装置をサーバと略記する場合がある
【００２８】
（実施形態１）
図１は、本発明の実施形態１に係る電子商取引システムの概要を示す図である。電子商取引システム１００においては、利用者端末１０２が、インターネットなどの通信網１０１を介して、ショップサーバ１０３及び確認サーバ１０４と通信を行う。また、必要に応じて、ショップサーバ１０３と確認サーバ１０４とが通信を行うことができるようになっていてもよい。
【００２９】
利用者端末１０２は、商品や役務などの購入者である利用者が商取引を行うために用いる電子機器である。ショップサーバ１０３は、利用者端末１０２の利用者から商品、役務などの購入の申込を受け付け、利用者端末１０２との決済処理を行うための装置である。確認サーバ１０４は、ショップサーバ１０３が決済処理を行うために必要な電子財布が利用者端末１０２にインストールされているかどうかを確認するための装置である。なお、決済処理は、商品や役務などの対価として行われる必要はなく、利用者が他の者に価値を贈与する場合にも行われてよい。
【００３０】
なお、ショップサーバ１０３と確認サーバ１０４とは同じサーバ装置として実現されていても良い。この場合には、利用者端末１０２にインストールされているブラウザが、そのサーバ装置のうちショップサーバ１０３に相当する部分と確認サーバ１０４に相当する部分とにアクセスするＵＲＬが異なっていればよい。例えば、ＵＲＬのパスの部分が異なっていればよい。
【００３１】
なお、利用者端末１０２と，ショップサーバ１０３と、確認サーバ１０４とのそれぞれは、例えば、計算機によって構成することが可能である。図２（ａ）は計算機のハードウェア構成の一例を示す。計算機２００は、ＣＰＵ２０１と、メモリ２０２と、二次記憶２０３と、入出力Ｉ／Ｆ２０４とを有し、それぞれが相互にバス２０５により接続されている。ＣＰＵ２０１は、プログラムを構成する命令を実行する回路である。メモリ２０２は、ＣＰＵ２０１によりその命令が実行されるプログラムや必要なデータを記憶する。二次記憶２０３はプログラムやデータを記憶する。一般的に二次記憶２０３は、記憶内容が不揮発に構成されており、例えば、磁気ディスクやフラッシュメモリなどにより構成される。また、二次記憶２０３に記憶されたプログラムやデータをＣＰＵ２０１が処理を行うためには、一般的には、メモリ２０２へコピーなどがされる必要がある。入出力Ｉ／Ｆ２０４は、計算機２００の外部との情報の入出力を行うための部である。例えば、ディスプレイインターフェース、キーボード、インターフェース、通信インターフェースなどのいずれか一以上を含む。
【００３２】
図２（ｂ）は、ＣＰＵ２０１によりプログラムが実行されている計算機２００の状態を模式的に示す。最下層２１１として、図２（ａ）に例示したハードウェアの階層があり、その上の階層２１２として、例えばオペレーティングシステムという特別なソフトウェアの階層がある。オペレーティングシステムの上の階層２１３にてアプリケーションプログラムが動作する。例えばアプリケーションプログラムがハードウェアにアクセスを行う場合には、直接アクセスを行うことができず、オペレーティングシステムを介してアクセスを行うことになる。例えば、入出力Ｉ／Ｆ２０４を介してデータの入出力を行うには、アプリケーションプログラムは、システムコールを呼び出し、オペレーティングシステムにデータの入出力を依頼する。なお、上述した電子財布や、ブラウザ、ウェブサーバプログラムは、アプリケーションプログラム２１３として実現することが可能である。
【００３３】
なお、利用者端末１０２と，ショップサーバ１０３と、確認サーバ１０４との全ては、計算機にアプリケーションプログラムを動作させることのみにより実現されることはなく、大規模集積回路などを用いたハードウェアにより実現することも可能である。
【００３４】
（利用者端末）
図３は、利用者端末の機能ブロック図を示す。利用者端末１０２は、ブラウザ３０２と、電子財布３０３とがインストールされている。また、利用者端末１０２は、タイプ関連付部３０４を有する。ブラウザ３０２は、利用者の操作によりＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）による要求を送信し、その応答を受信し、画面の表示などを行う。ブラウザ３０２は、一般的に閲覧ソフトウェアとして知られているものと同一または同等の機能を有するのが好ましい。なお、ブラウザ３０２と、電子財布３０３とは同時にインストールされる必要はない。
【００３５】
図４は、ブラウザの機能ブロック図の一例を示す。ブラウザ３０２は、クッキー情報管理部４０１と、履歴管理部４０２と、ブックマーク管理部４０３と、操作部４０４と、表示部４０５と、送受信部４０６と、制御部４０７とを有している。
【００３６】
クッキー情報管理部４０１は、クッキー情報の記憶、検索、読み出し、削除、変更その他の管理を行う部である。例えば、クッキー情報は二次記憶に記憶され、クッキー情報管理部４０１により管理がされる。クッキー情報とは、ブラウザ３０２が通信を行うサーバから送られた、何らかの状態を表す情報である。例えば、ＲＦＣ２１０９に規定されている。クッキー情報は、サーバからのＨＴＴＰ応答のＳｅｔ−Ｃｏｏｋｉｅヘッダとして送られ、クッキー情報管理部４０１に記憶、変更がされる。また、クッキー情報は、ブラウザ３０２がサーバにＨＴＴＰの要求を送信する際に、クッキー情報管理部４０１により検索、読み出しが行われてサーバへ送信される。
【００３７】
図５は、クッキー情報の構造を模式的に示す。クッキー情報は、１以上のＮＡＭＥ＝ＶＡＬＵＥの形式である、名前とその値の組と、ｅｘｐｉｒｅｓ＝ＤＡＴＥで示される、クッキー情報の有効期限と、ｄｏｍａｉｎ＝ＤＯＭＡＩＮで示される、クッキー情報を送信するべきサーバのドメインと、ｐａｔｈ＝ＰＡＴＨで示される、クッキー情報を送信するべきＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）またはＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）のサブセットから構成される。なお、本発明では、ＵＲＩをＵＲＬとして扱う。
【００３８】
本実施形態では、クッキー情報管理部４０１には、確認サーバ１０４へ送信されるクッキー情報が格納されている。すなわち、クッキー情報管理部４０１には、クッキー情報を送信するべきサーバのドメインが、確認サーバ１０４のＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）と一致または一部となっているクッキー情報が格納されている。例えば、確認サーバのＦＱＤＮがｗｗｗ．ｆｏｏ．ｂａｒであれば、ｄｏｍａｉｎ＝ｆｏｏ．ｂａｒとなりｐａｔｈ＝／となっているクッキー情報がクッキー情報管理部４０１に格納されている。したがって、ブラウザ３０２が、ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｂａｒ／のＵＲＬにより、ｗｗｗ．ｆｏｏ．ｂａｒをアクセスすると、そのクッキー情報が読み出され、確認サーバに送信される。
【００３９】
確認サーバ１０４へ送信されるクッキー情報をクッキー情報管理部４０１に格納する方法には種々の方法がある。例えば、電子財布３０３をインストールするためのプログラムをダウンロードするためのウェブサーバにブラウザ３０２がアクセスした場合、そのウェブサーバが、確認サーバ１０４へ送信されるクッキー情報を送信する。あるいは、電子財布３０３をインストールするためのプログラムが実行された場合、そのプログラムがクッキー情報管理部４０１の管理する二次記憶２０３の領域にアクセスを行い、確認サーバ１０４へ送信されるクッキー情報を格納する。あるいは、電子財布３０３をインストールするためのプログラムがブラウザ３０２を起動させ、確認サーバ１０４やその他の所定のサーバにアクセスをさせて、そのアクセスがされたサーバが、確認サーバ１０４へ送信されるクッキー情報をブラウザ３０２に送信する。あるいは、電子財布３０３を起動させると、確認サーバ１０４やその他の所定のサーバにアクセスが行われ、そのアクセスがされたサーバが、確認サーバ１０４へ送信されるクッキー情報をブラウザ３０２に送信する。例えば、電子財布３０３を起動させるとボタン表示を有する画面が表示され、そのボタンを押下すると、ブラウザ３０２が起動されて確認サーバ１０４やその他の所定のサーバにアクセスが行われるようになっていてもよい。また、電子財布３０３をインストールした後、ブラウザ３０２により所定のサーバにブラウザ３０２によってアクセスし、会員登録をした際に、その所定のサーバより、確認サーバ１０４へ送信されるクッキー情報がブラウザ３０２に送信されるようになっていてもよい。
【００４０】
履歴管理部４０２は、ブラウザ４００で閲覧を行ったウェブページなどの履歴を保持する部である。ブックマーク管理部４０３は、ブックマークの記憶、検索、読み出し、削除、変更などの管理を行う部である。操作部４０４は、利用者端末のキーボードやマウスなどの利用者による操作を検出する部である。表示部４０５は、サーバからの応答を表示などする部である。送受信部４０６は、サーバに対して要求を送信し、返答を受信する部である。制御部４０７は、クッキー情報管理部４０１と、履歴管理部４０２と、ブックマーク管理部４０３と、操作部４０４と、表示部４０５と、送受信部４０６とを制御し、ブラウザとして動作するように制御する部である。例えば、クッキー情報管理部４０１と、履歴管理部４０２と、ブックマーク管理部４０３と、操作部４０４と、表示部４０５と、送受信部４０６のそれぞれの部を構成するモジュールを統括するモジュールである。
【００４１】
利用者はブラウザ３０２を用いてショップサーバ１０３などのサーバと通信を行い、ショッピングなどを行う。ショッピングなどの対価の支払の決済処理のために、本実施形態では、電子財布３０３が起動されて動作する。後述するタイプ関連付部３０４により、電子財布３０３の起動は、ブラウザ３０２により行われるようにすることができる。
【００４２】
図６は、電子財布の機能ブロック図の一例を示す。電子財布５００は、管理データ管理部５０１と、送受信部５０２と、制御部５０３とを有する。管理データ管理部５０１は、管理データの記憶、検索、読み出し、削除、変更その他の管理を行う部である。例えば、管理データは二次記憶に記憶され、管理データ管理部５０１により管理される。管理データとは、現実の貨幣などの価値が関連付けられたデータをいう。管理データと呼ばれる代わりに、電子マネーや電子バリューなどと呼ばれる場合がある。送受信部５０２は、決済処理のために通信を行う部である。例えば、新たに利用者が購入した管理データを受信したり、決済のために支払うべき額を含む請求データを受信したり、支払のために管理データを送信したりする。制御部５０３は、管理データ管理部５０１と送受信部５０２とを制御する部である。
【００４３】
タイプ関連付部３０４は、ブラウザ３０２が扱うコンテンツの種類（タイプ）を保持する部である。本実施形態では特に、ブラウザ３０２が他のアプリケーションプログラムにコンテンツの処理を依頼するために、アプリケーションプログラムをその種類と関連付けて保持する部である。
【００４４】
図７は、タイプ関連付部３０４を実現するために、コンテンツのタイプとアプリケーションプログラムとを関連付ける表である。コンテンツのタイプは例えば、ＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎｓ）のタイプにより表され、ｔｅｘｔ／ｐｌａｉｎというタイプにはテキストエディタが関連付けられ、ｉｍａｎｇｅ／ｐｎｇというタイプにはイメージビュアーが関連付けられている。また、タイプ関連付部３０４は、ファイルの拡張子とアプリケーションプログラムが関連付けられるようになっていてもよい。このような関連付けは、例えば、二次記憶に記憶され、オペレーティングシステムなどにより管理される。
【００４５】
本実施形態では、タイプ関連付部３０４により、決済処理のためにショップサーバ１０３から送信される請求データのコンテンツのタイプに電子財布が関連付けられる。
【００４６】
図８は、本実施形態における利用者端末の動作を説明するフローチャートの一例を示す。このフローチャートの処理を実行する前に、利用者端末の利用者は、ブラウザなどを用いてショッピングなどを行い、購入などをする商品などを決定する。その決定された商品などに対する対価を支払う際に、図８のフローチャートの処理が実行される。
【００４７】
ステップＳ８０１の処理として、利用者端末１０２のブラウザ３０２が、ショップサーバ１０３へ注文データなどをＨＴＴＰ要求として送信する。注文データは、商品などの注文を確定し、商品などの対価の支払処理をショップサーバ１０３に開始させるデータである。例えば、注文データは、ＨＴＴＰのＰＯＳＴコマンドとして表現され、商品番号と商品の個数、商品の配送先を含むデータであってもよい。また、注文データのかわりに、商品や役務の提供を行うウェブページの要求が送信されてもよい。
【００４８】
ステップＳ８０２の処理としては、ステップＳ８０１で送信されたＨＴＴＰ要求に対して返信されるアクセス命令を受信する。このアクセス命令は、ショップサーバ１０３から返信される。このアクセス命令は、ブラウザ３０２に対して、確認サーバ１０４へアクセスを行うことを要求する。
【００４９】
アクセス命令は、ＨＴＴＰ要求に対する応答として、例えば、＜ｍｅｔａ ｈｔｔｐ−ｅｑｕｉｖ＝”ｒｅｆｒｅｓｈ” ｃｏｎｔｅｎｔ＝”０；ｕｒｌ＝確認サーバのＵＲＬ”＞により表すことができる。ここでの「確認サーバのＵＲＬ」には、ステップＳ８０１で送信されたＨＴＴＰ要求を、ショップサーバ１０３にて一意に識別できる情報が含まれるようになっていてもよい。例えば、ショップサーバ１０３は、注文データを受信すると、注文データに対して連番を付与し、その連番と注文データとを関連付けて二次記憶などに格納し、連番を含む確認サーバのＵＲＬを返信する。その連番は、例えば、ＵＲＬにパラメータとして含ませることができる。また、そのＵＲＬには、ショップサーバ１０３のＦＱＤＮなどのショップサーバ１０３を識別する識別情報を含ませる。なお、「０；」は待ち時間なしで直ちに「確認サーバのＵＲＬ」にアクセスすることを意味している。「０；」の代わりに必要に応じて任意の時間を指定することができる。
【００５０】
また、アクセス命令は、ショップサーバ１０３が、ＲＦＣ２６１６の１０．３節に規定されている３００番台のステータスコードとともに応答する返信によっても実現できる。例えば、３０１のステータスコードや３０２のステータスコードとともにアクセスするべきＵＲＬを返信することによって、ブラウザ３０２を、確認サーバ１０４へアクセスさせるようにすることができる。
【００５１】
なお、本発明の明細書、請求の範囲、図面においては、アクセス命令をＲＦＣ２６１６に倣い、リダイレクト命令と呼ぶ場合がある。
【００５２】
ステップＳ８０３の処理として、ステップＳ８０２にて受信したリダイレクト命令に従って、確認サーバへＨＴＴＰ要求を送信する。例えば、ステップＳ８０２にて＜ｍｅｔａ ｈｔｔｐ−ｅｑｕｉｖ＝”ｒｅｆｒｅｓｈ” ｃｏｎｔｅｎｔ＝”０；ｕｒｌ＝確認サーバのＵＲＬ”＞が受信された場合には「確認サーバのＵＲＬ」を用いて確認サーバ１０４にアクセスが行われる。また、確認サーバへＨＴＴＰ要求が送信される際には、クッキー情報管理部４０１で管理されているクッキー情報のうち、確認サーバへ送信されるクッキー情報も送信される。
【００５３】
ステップＳ８０３にて送信されたＨＴＴＰ要求を受信した確認サーバ１０４は、そのＨＴＴＰ要求とともにクッキー情報を受信したことを確認する。また、必要ならば、クッキー情報に含まれるＮＡＭＥ＝ＶＡＬＵＥを確認する。クッキー情報管理部４０１が格納している、確認サーバへ送信されるクッキー情報の定義により、このようにクッキー情報などを確認することは、利用者端末１０２に電子財布３０３がインストールされていることが確認されたことを意味する。確認ができれば、確認サーバ１０４は、ショップサーバ１０３へのリダイレクト命令を返信する。このとき確認サーバは、利用者端末１０２から送信されたＨＴＴＰ要求に含まれる確認サーバの識別情報を用いてショップサーバのＦＱＤＮを生成などしてリダイレクト命令に含める。
【００５４】
また、このリダイレクト命令によりブラウザ３０２がアクセスするＵＲＬに、確認サーバへ送信されるクッキー情報が確認されたかどうかを「＆」で区切られるパラメータとして含めるようになっていてもよい。例えば、確認サーバへ送信されるクッキー情報が確認された場合には、そのＵＲＬに「＆ｅｗａｌｌｅｔ＝１」が含められ、確認されない場合には、「＆ｅｗａｌｌｅｔ＝０」が含められるようになっていてもよい。
【００５５】
また、ショップサーバの二次記憶に格納された注文データの連番などが、そのＨＴＴＰ要求に含まれていれば、その連番などをリダイレクト命令に含まれるショップサーバ１０３へのＵＲＬに含ませる。その連番などはそのＵＲＬのパラメータとして含ませることができる。また、そのＵＲＬには、確認サーバ１０４が、利用者端末１０２に電子財布３０３がインストールされていることを確認した旨の情報が含まれるようになっていてもよい。例えば、確認サーバ１０４による連番などの署名データが含まれるようになっていてもよい。署名データそのものが含まれる必要はなく、確認サーバ１０４が、連番などの署名データに識別子を付与して、ショップサーバ１０３よりアクセス可能にその識別子に署名データを関連付けて格納し、その識別子をそのＵＲＬに含ませてもよい。
【００５６】
また、ステップＳ８０３にて送信されたＨＴＴＰ要求を受信した確認サーバ１０４は、クッキー情報に含まれるＮＡＭＥ＝ＶＡＬＵＥの組から、どのような種類の電子財布が利用者端末１０２にインストールされているかを判断し、その種類を、そのＵＲＬに含ませてもよい。
【００５７】
また、確認サーバ１０４が、クッキー情報を確認できなければ、電子財布３０３をインストールするためのウェブページへのリダイレクト命令を返信する。電子財布３０３をインストールするためのウェブページには、例えば、電子財布３０３をダウンロードするためのリンク情報が含まれている。あるいは、そのウェブページには、電子財布３０３のインストールの方法が記載されている。
【００５８】
ステップＳ８０４の処理として、上述したように確認サーバ１０４から送信されたリダイレクト命令を受信する。このリダイレクト命令が受信されたということは、上述したように、確認サーバ１０４が、利用者端末１０２に電子財布３０３がインストールされていることの確認の結果が受信されたことを意味する。
【００５９】
ステップＳ８０５の処理として、ステップＳ８０４にて受信されたリダイレクト命令に応じて、ショップサーバ１０３へＨＴＴＰ要求を送信する。このＨＴＴＰ要求がショップサーバ１０３にて受信されることで、ショップサーバ１０３は、利用者端末１０２に電子財布３０３がインストールされていることを確認できる。したがって、ショップサーバ１０３は、電子財布３０３が扱えるコンテンツの種類のデータとして支払を請求する請求データを送信する。また、ショップサーバ１０３が受信したＨＴＴＰサーバに電子財布の種類が含まれていれば、請求データを表すための適切なコンテンツの選択を行って、請求データを生成して、送信することもできる。
【００６０】
なお、ステップＳ８０５の後、ショップサーバ１０３から返信される情報は、請求データではなく、商品や役務の申込を行うためのウェブページの記述であってもよい。そして、このウェブページには、スクリプト言語や利用者端末１０２にインストールされている仮想マシンで実行するコードあるいは利用者端末１０２のネイティブコードなどで記述されたプログラムが含まれていてもよい。
【００６１】
そのプログラムは、まず、ブラウザ３０２がステップＳ８０５でのＨＴＴＰ要求によりアクセスしたＵＲＬのパラメータ部分を取得する。このＵＲＬのパラメータ部分は、ブラウザ３０２が、ＨＴＴＰ要求を行ったときに、利用者端末１０２のメモリに記憶したＵＲＬのパラメータ部分として得られる。例えば、ある種のスクリプト言語では、ｌｏｃａｌｔｉｏｎ．ｓｅａｒｃｈ属性を参照することにより、メモリより読み出すことが可能である。そして、そのプログラムは、ＵＲＬに含まれるパラメータの値を変数（あるいはレジスタ）に代入する。例えば、上述のように、確認サーバへ送信されるクッキー情報が確認されたかどうかが、確認サーバより受信されるリダイレクト命令によるアクセスするべきショップサーバへのＵＲＬに「＆ｅｗａｌｌｅｔ＝１」が含められるか、「＆ｅｗａｌｌｅｔ＝０」が含められるかで表される場合には、１あるいは０をその変数に代入する。なお、「＆ｅｗａｌｌｅｔ＝１」も「＆ｅｗａｌｌｅｔ＝０」も含められていなければ、その変数には０が代入されるとする。
【００６２】
そして、そのプログラムは、その変数の値を０または１と比較して、１と等しければ、商品や役務の種類などの選択、数量などの入力結果をショップサーバに送信するためのボタンなどを利用者端末１０２の画面に表示する。また、１と等しくなければ、電子財布をインストールするためのリンクを表示などする。
【００６３】
例えば、商品や役務の種類などの選択、数量などの入力結果をショップサーバに送信するためのボタンが押下されると、商品や役務の種類などの選択、数量などの入力結果がショップサーバ１０３に送信され、その返信として、請求データがブラウザ３０２により受信される。
【００６４】
ステップＳ８０６の処理として、ショップサーバ１０３より、請求データを受信する。
【００６５】
この請求データをブラウザ３０２が受信すると、コンテンツのタイプを参照し、そのコンテンツのタイプに電子財布３０３が関連付けられているので、ステップＳ８０４の処理として、電子財布３０３を起動し、請求データを電子財布３０３への入力などとして、読み込ませて処理をさせる。
【００６６】
なお、請求データには、利用者が支払うべき金額や利用者が履行するべき債権・債務に関する情報が含まれていてもよい。また、金額の支払先や債権・債務の相手方の情報が請求データに含まれていてもよい。例えば、管理データの送信先が請求データに含まれていてもよい。電子財布３０３は、電子財布３０３に設定された情報や請求データに含まれる情報から決済を行うための通信先を取得して、その通信先と通信を行い、決済などを行う。
【００６７】
（ショップサーバ）
図９は、ショップサーバの機能ブロック図の一例を示す。ショップサーバ１０３は、注文データ受信部９０１と、受注管理部０２と、ＵＲＬ転送部９０３と、請求データ発行部９０４とを有する。
【００６８】
注文データ受信部９０１（第１要求受信部）は、注文データを受信する。注文データは、上述したように利用者端末１０２より、ＨＴＴＰ要求の形式にて送信される。注文データ受信部９０１は、注文データを受信すると、その注文データより、商品番号と商品の個数など、支払われるべき金額を計算するために必要な情報である受注情報を抽出する。また、必要に応じて、商品などの配送先を抽出する。
【００６９】
受注管理部９０２は、受注を管理する。すなわち、注文データが注文データ受信部９０１により受信され、受注情報が抽出されると、まず、それを格納する。このとき、受注管理部９０２は、受注情報を一意に識別するための連番などを受注情報に付与する。付与された連番などは、ＵＲＬ転送部９０３に伝達されるようになっていてもよい。また、受注管理部９０２は、連番などが請求データ発行部９０４により指定されると、その連番などが付与された受注情報を読み出して返答する。
【００７０】
ＵＲＬ転送部９０３（返信部）は、注文データ受信部９０１により注文データが受信され、受注情報が抽出されて受注管理部９０２に格納されると、注文データを送信した利用者端末１０２に対して、確認サーバ１０４へのリダイレクト命令を返信する。このリダイレクト命令には、受注管理部９０２によって付与された連番などが含まれていてもよい。
【００７１】
なお、確認サーバ１０４へのリダイレクト命令により、利用者端末１０２がＨＴＴＰ要求を送信するためのＵＲＬは、例えば、ショップサーバ１０３がアクセスされたパスに応じて対応関係が定められていてもよい。図１０は、この対応関係を定めるためのテーブルの一例を示す。例えば、／ｓｈｏｐ１２３が利用者端末１０２からのＨＴＴＰ要求によりアクセスされた場合には、ＵＲＬ転送部９０３は、リダイレクト命令に、ｗｗｗ．ｆｏｏ．ｂａｒの／ｃｏｎｆ３４２をアクセスするためのＵＲＬを含める。また、このＵＲＬに、受注管理部９０２によって付与された連番などがパラメータとして付加されるようになっていてもよい。また、／ｄｏｗｎｌｏａｄ２３４が利用者端末１０２からのＨＴＴＰ要求によりアクセスされた場合には、ＵＲＬ転送部９０３は、リダイレクト命令に、ｗｗｗ．ｂａｚ．ｑｕｘの／ｋａｋｕｎｉｎ５７９をアクセスするためのＵＲＬを含める。これにより、ショップサーバ１０３が複数の店舗により共有されている場合、店舗ごとに扱う管理データが異なり、決済に用いる電子財布の種類が異なる場合に対応できる。
【００７２】
請求データ発行部９０４（第２要求受信部及び応答部）は、ＵＲＬ転送部９０３により返信されたリダイレクト命令に基づいて、利用者端末１０２から返信されるＨＴＴＰ要求を受信すると、受注管理部９０２より受注情報を読み出して、請求データを生成して返信する。すなわち、ＵＲＬ転送部９０３により返信されたリダイレクト命令に従って、利用者端末１０２は、（１）確認サーバへＨＴＴＰ要求を送信し、（２）その返信として受信されるリダイレクト命令に従って、ショップサーバ１０３に対してＨＴＴＰ要求を再度送信した場合に、受注管理部９０２より受注情報を読み出して、請求データを生成して返信する。読み出す受注情報は、例えば、利用者端末１０２より再度送信されたＨＴＴＰ要求に含まれる連番などを用いて特定されるようになっていてもよい。また、利用者端末１０２より再度送信されたＨＴＴＰ要求に電子財布の種類が含まれていれば、請求データを表すための適切なコンテンツの選択を行って請求データを生成する。
【００７３】
図１１と図１２は、ショップサーバ１０３における処理を説明するフローチャートである。
【００７４】
図１１は、利用者端末１０２における処理のうち図８のステップＳ８０１からＳ８０２までの処理に対応してショップサーバ１０３で行われる処理のフローチャートである。ステップＳ１１０１の処理として、利用者端末１０２より、注文データをＨＴＴＰ要求として受信する。そして、注文データ受信部９０１は、受注データを抽出する。
【００７５】
ステップＳ１１０２の処理として、ステップＳ１１０１において抽出された受注情報が受注管理部９０２により格納される。
【００７６】
ステップＳ１１０３の処理として、ＵＲＬ転送部９０３により、確認サーバ１０４へのリダイレクト命令を、ＨＴＴＰ応答して返信する。
【００７７】
図１２は、利用者端末１０２における処理のうち図８のステップＳ８０４からＳ８０６までの処理に対応してショップサーバ１０３で行われる処理のフローチャートである。ステップＳ１２０１の処理として、確認サーバ１０４からのリダイレクト命令により利用者端末１０２のブラウザ３０２から送信されたＨＴＴＰ要求を受信する。ステップＳ１２０２の処理として、請求データ発行部９０４により、対応する受注情報を読み出す。対応する受注情報とは、ステップＳ１２０１においてＨＴＴＰ要求が受信される原因となった、確認サーバへのリダイレクト命令が送信されるトリガーとして受信された受注情報である。対応する受注情報は、ステップＳ１２０１で受信されたＨＴＴＰ要求に含まれる連番などで特定することができる。ステップＳ１２０３の処理として、ステップＳ１２０２で読み出された受注情報に応じて請求データを生成して、利用者端末１０２へ送信する。
【００７８】
（確認サーバ）
図１３は、確認サーバ１０４で行われる処理を説明するフローチャートである。確認サーバ１０４は、ＨＴＴＰ要求を受信し、特定のパスがアクセスされた場合に、図１３の処理を行うウェブサーバとして構成される。例えば、確認サーバ１０４は、計算機にウェブサーバプログラムを動作させて実現される。
【００７９】
ステップＳ１３０１の処理において、ショップサーバ１０３から送信されたリダイレクト命令により利用者端末１０２のブラウザ３０２から送信されたＨＴＴＰ要求を受信する。ステップＳ１３０２の処理においては、ステップＳ１３０１においてＨＴＴＰ要求とともにクッキー情報が受信されたかどうか、また、そのクッキー情報の内容を確認する。確認がされれば、ステップＳ１３０３の処理において、ブラウザ３０２をショップサーバ１０３へリダイレクトさせる命令をＨＴＴＰ応答として返信する。上述したようにこのＨＴＴＰ応答には、ステップＳ１３０１で受信されたＨＴＴＰ要求に含まれる連番などを含ませる。また、ＨＴＴＰ要求とともに受信されたクッキー情報から電子財布の種類が決定される場合には、その種類をそのＨＴＴＰ応答に含ませてもよい。
【００８０】
もし、利用者端末１０２のブラウザ３０２から送信されたＨＴＴＰ要求とともにクッキー情報が受信されなかったことが確認されていなかったり、クッキー情報の内容が正しいものとして確認できなかったりすれば、確認サーバ１０４は、エラーを返信してもよい。また、エラーの代わりに、電子財布のインストールを勧める内容のＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）情報を返信してもよい。また、上述したように、クッキー情報の内容が正しいものとして確認できたかどうかを、ＨＴＴＰ応答に含めてもよい。例えば、確認ができた場合には、ＨＴＴＰ応答に含められるショップサーバ１０３へリダイレクトさせる命令のＵＲＬにパラメータとして「＆ｅｗａｌｌｅｔ＝１」を含め、そうでなければ「＆ｅｗａｌｌｅｔ＝０」を含める。
【００８１】
（全体の流れ）
図１４は、電子商取引システム１００の全体の処理を説明するシーケンス図である。ステップＳ１４０１の処理として、注文データが利用者端末１０２のブラウザ３０２からショップサーバ１０３へ送信される。これは、図８におけるステップＳ８０１、図１１におけるステップＳ１１０１に相当する。ステップＳ１４０２の処理として、ショップサーバ１０３から確認サーバ１０４へのリダイレクト命令が送信される。これは、図１１におけるステップＳ１１０３、図８におけるステップＳ８０２に相当する。ステップＳ１４０３の処理として、利用者端末１０２のブラウザ３０２から、ＨＴＴＰ要求とクッキー情報が確認サーバに送信される。これは、図８におけるＳ８０３、図１３におけるＳ１３０１に相当する。ステップＳ１４０４の処理として、確認サーバ１０４は、ショップサーバ１０３へのリダイレクト命令を返信する。これは、図１３におけるＳ１３０３、図８におけるＳ８０４に相当する。ステップＳ１４０５の処理として、利用者端末１０２のブラウザ３０２からＨＴＴＰ要求がショップサーバ１０３へ送信される。これは、図８のＳ８０５と、図１２のＳ１２０１に相当する。ステップＳ１４０６の処理として、ショップサーバから請求データが返信される。これは、図１２におけるステップＳ１２０３、ステップＳ８０６に相当する。ステップＳ１４０７の処理として、利用者端末１０２のブラウザ３０２は、電子財布３０３を起動し、請求データを処理させる。これは、図８のステップＳ８０７に相当する。
【００８２】
ステップＳ１４０７以降は、電子財布３０３により処理がされる。例えば、請求データにより請求された金額の支払の決済処理が行われる。
【００８３】
（主な効果）
本実施形態においては、利用者端末に電子財布がインストールされていることを、確認サーバに対するＨＴＴＰ要求とともに送信されるクッキー情報によって表すことにより、ショップサーバが利用者端末に電子財布がインストールされていることを確認することができる。
【００８４】
また、利用者端末において請求データのコンテンツのタイプと電子財布とが関連付けられていることにより、請求データに応じて決済処理を行う際には、自動的に電子財布が起動することになるので、利用者端末の利用者は簡便に電子決済を行うことができる。例えば、従来のように銀行振込のために銀行のホームページにアクセスをして口座番号、振込金額を入力する手間よりも少ない手間で決済を行うことができる。
【００８５】
上述の実施形態においては、注文データをショップサーバが受信する際に、利用者端末に電子財布がインストールされていることを確認することを主に説明した。しかし、本発明はこれに限定されるものではなく、利用者がショッピングのためのホームページをアクセスする際に、利用者端末に電子財布がインストールされていることを確認することも可能である。
【００８６】
上述の実施形態においては、電子財布をプログラムの例とし、請求データをコンテンツの例として扱ったが、本発明は、電子財布、請求データに限定されるものではない。
【００８７】
例えば、上述の実施形態において、利用者端末にインストールされているプログラムごとに、確認サーバへ送信されるクッキー情報をクッキー情報管理部４０１に格納しておく。そして、ステップＳ１４０１にて、注文データのかわりに、ブラウザからショップサーバというサーバに対して、音楽情報、動画情報、文書情報などの種々のコンテンツのダウンロードの要求が送信されてもよい。すると、ステップＳ１４０３にて、ブラウザから確認サーバへ利用者端末にインストールされているプログラムを表すクッキー情報が送信され、ステップＳ１４０４にて、確認サーバからブラウザに返信されるリダイレクト命令のＵＲＬに、利用者端末にインストールされているプログラムをパラメータなどして含めることができる。すると、ステップＳ１４０５にて、ショップサーバは、利用者端末にインストールされているプログラムを知ることができ、ステップＳ１４０６において、請求データのかわりに、ショップサーバというサーバは、利用者端末にインストールされているプログラムが扱える形式の情報を送信することができる。
【００８８】
（実施形態２）
本発明の実施形態２として、電子財布による処理などについて詳細に説明を行う。
【００８９】
まず、管理サーバについて説明を行う。本実施形態において、管理サーバとは、電子的な価値情報の譲渡処理を主に行うサーバ装置である。管理サーバが行うその他の処理としては、管理サーバとして必須の処理ではないが、電子的な価値情報の発行処理、発行した電子マネー等に関連付けられた価値を貨幣などとして払い戻す処理などがある。
【００９０】
図１５は、本発明の一実施形態に係る管理サーバの機能ブロック図を例示する。管理サーバ１５００は、データベース部１５０１と、発行要求受信部１５０２と、生成部１５０３と、生成管理データ送信部１５０４と、管理データ受信部１５０５と、置換部１５０６と、置換管理データ送信部１５０７とを有する。なお、管理サーバ１５００の実現の一態様としては、上述したように計算機を用いることができる。
【００９１】
データベース部１５０１は、電子的な価値情報と価値との関連付けを管理する。また、照合用データと関連付けることができる他の情報としては、例えば、その照合用データを含む管理データの譲渡が行われた回数（譲渡回数）、その照合用データを含む管理データが、どの利用者やどの利用者の端末装置などに対して発行されたかを示す利用者や端末装置などの識別情報などが挙げられ、これらは必要に応じてデータベース部１５０１に格納されてもよい。
【００９２】
本発明の一実施形態においては、図１６（ａ）に示すように、照合用データが格納される列と価値の情報が格納される列とを有し、照合用データと価値の情報とを関連付けるテーブルを用意する。このテーブルは、関係データベースシステムなどの表データとしてデータベース部１５０１によって管理される。なお、価値の情報を単に「価値情報」という場合がある。
【００９３】
照合用データは、充分に長いビット長の乱数として生成されるデータである。「充分に長い」とは、発行される管理データの中で同じ照合用データを有するものが存在しない、あるいは、実質的に存在しないことを意味する。例えば、１２８ビット、５１２ビット、１０２４ビット、２０４８ビットなど設計上などの必要に応じて任意の長さを決めることができる。
【００９４】
価値情報は、照合用データを含む管理データが表すことになる価値の内容などを示す。具体的な例としては、貨幣により表される価値を示す。この場合、価値の単位は、円、ドル、ユーロ、元などである。また、価値の情報は、貨幣と同等の価値を有する有価証券の証券番号、貴金属の量や保管の番号などであってもよい。
【００９５】
発行要求受信部１５０２は、管理データ発行要求１５０８を受信する。管理データ発行要求１５０８は、なんらかの価値が管理サーバやその運営者などに移転されたことあるいは移転されることを示す情報である。このため、管理データ発行要求１５０８は、管理サーバ１５００の運営者の支配する領域の内部で生成されたり、運営者と特別な関係（例えば親会社子会社の関係や特別な契約関係）にある者から送信されたりするのが好ましい。
【００９６】
図１６（ｂ）は、管理データ発行要求の具体的な例を示す。この例では、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）による表現がされている。管理データ発行要求はＸＭＬ以外にも種々の表現形式があるが、以下では、ＸＭＬを例にして説明を行う。図１６（ｂ）では、＜価値＞と＜／価値＞とで囲まれている１０００円が、発行される管理データが表すべき価値となっている。発行要求受信部１５０２が、このような管理データ発行要求を受信する際には、管理データ発行要求の送信者の認証を行い、受信した管理データ発行要求をメモリに展開して正しい構文であるかどうかの確認を行い、＜価値＞と＜／価値＞とで囲まれている部分を特定して、次に説明する生成部１５０３に伝達する。伝達は、例えば、生成部１５０３を実現するソフトウェアモジュールなどの関数の引数に＜価値＞と＜／価値＞とで囲まれている部分のメモリアドレスを価値の情報として引数に指定するなどしてその関数を呼び出すことで行われる。
【００９７】
なお、管理データ発行要求には、照合用データと関連付けることができる他の情報が必要に応じて含まれていてもよい。
【００９８】
生成部１５０３は、照合用データを準備し、準備された照合用データと発行要求受信部１５０２から伝達された価値の情報とを、データベース部１５０１で管理される図１６（ａ）のテーブルに行データとして挿入する。「照合用データを準備する」とは、乱数を生成してその乱数を照合用データとすること、又は、予め生成しておいた乱数のリストなどから乱数を選択して照合用データとすることをいう。挿入が完了すると、生成部１５０３は、生成管理データ送信部１５０４へ、照合用データを伝達する。なお価値の情報も伝達されてもよい。
【００９９】
図１６（ｃ）は、照合用データとして"１３５７１１"が準備されて、"１３５７１１"と１０００円とを図１６（ａ）に示されるテーブルに挿入した直後の状態を示している。挿入が行われると、"１３５７１１"という照合用データが生成管理データ送信部１５０４へ伝達される。
【０１００】
生成管理データ送信部１５０４は、生成部１５０３から伝達された照合用データから管理データ１５０９を生成して送信する。管理データ１５０９の送信先は、管理データ発行要求１５０８を送信した装置であることが主に想定される。もし、管理データ発行要求１５０８に、管理データ１５０９の送信先が、電子メールアドレスやＩＰアドレスなどによって指定されていれば、その送信先へ管理データ１５０９が送信される。送信は暗号化されて行われてもよい。
【０１０１】
図１６（ｄ）は、生成管理データ送信部１５０４で生成され送信される管理データの一例を示す。生成部１５０３から照合用データとして"１３５７１１"が伝達されたとすれば、"＜管理データ＞＜照合用データ＞１３５７１１＜／照合用データ＞＜／管理データ＞"という管理データが生成され、インターネットなどのネットワークなどに送信される。なお管理データには、照合用データ以外のデータが含まれていてもよい。例えば、照合用データがどれだけの価値、例えばいくらの貨幣価値、に関連付けられているかを示す情報が含まれていてもよい。例えば、管理データが"＜管理データ＞＜照合用データ＞１３５７１１＜／照合用データ＞＜価値＞１０００円＜／価値＞＜／管理データ＞"のように貨幣価値などを含むようになっていてもよい。また、照合用データと関連付けることができる他の情報が含まれていてもよい。また、譲渡回数が管理データに含まれる場合には、０などの初期値にリセットが行われて送信がされる。さらに、管理データが管理サーバ１５００により生成されたことを検証できるようにするために、照合用データなどに対する管理サーバ１５００による署名データが含まれていてもよい。
【０１０２】
なお、価値として、貨幣価値のように可分な価値が用いられる場合には、管理データが表す価値に上限を設けてもよい。例えば、一つの管理データは、５０００円までの貨幣価値を表すことにする。そして、５０００円以上の価値を表す管理データは、複数の管理データを組み合わせることによって表す。このように管理データが表す価値に上限を設けることにより、管理データを紛失したときに生じる損失が大きくならないようにすることができる。
【０１０３】
管理データが表す価値に上限を設ける場合には、管理データ発行要求がその上限を越える価値の管理データを発行することを表している場合には、上限以下の価値を表す管理データを複数発行する。このため、図１６（ａ）などに示すテーブルに複数の行データが挿入される。
【０１０４】
図１７は、データベース部１５０１、発行要求受信部１５０２、生成部１５０３、生成管理データ送信部１５０４による処理の流れを説明するフローチャートを例示する。このフローチャートが例示する処理は、ハードウェアを制御可能なソフトウェアによる情報処理として実行可能である。
【０１０５】
ステップＳ１７０１の処理として、発行要求受信部１５０２により管理データ発行要求を受信する。例えば、ハードウェアとしてのネットワークアダプタがデータを受信し割り込みが発生すると、割り込みハンドラが呼ばれて、データを読取り、読取りデータキューに入れる。そして、発行要求受信部１５０２を実現するモジュールなどが発行していたＲＥＡＤシステムコールなどから処理が戻り、読取りデータキューに入れられたデータを管理データ発行要求としてメモリに展開する。
【０１０６】
ステップＳ１７０２の処理として、発行要求受信部１５０２は、メモリに展開された管理データ発行要求から価値の情報のアドレスを特定などすることにより、価値の情報を取得する。取得された価値の情報は生成部１５０３へ伝達される。
【０１０７】
ステップＳ１７０３の処理として、生成部１５０３が照合用データを準備する。そしてステップＳ１７０４の処理として、生成部１５０３は、準備した照合用データと伝達された価値の情報を関連付けてテーブルに挿入して格納する。照合用データは生成管理データ送信部１５０４へ伝達される。
【０１０８】
ステップＳ１７０５の処理として、生成管理データ送信部１５０４は、伝達された照合用データから管理データを生成する。そして、ステップＳ１７０６の処理として、ＷＲＩＴＥシステムコールなどを発行することにより、生成された管理データを送信する。ＷＲＩＴＥシステムコールなどの発行により、管理データが送信データキューに格納され、ネットワークアダプタがデータを送信可能な状態になると、割り込みが発生し、割り込みハンドラにより、送信データキューのデータが読み出されて、ネットワークなどに送信される。
【０１０９】
このようにして送信された管理データは、専用のＩＣカードなどに限らず、通常のパーソナルコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）や携帯電話などのメモリに格納することができる。また、フレキシブルディスク、光ディスク、不揮発性の半導体メモリなどの着脱可能な一般的な記憶媒体に記録することができる。そして、その記憶媒体を譲渡することにより、その記憶媒体に格納されている管理データが表す価値の譲渡を行うことができる。ただし、二重の譲渡を防止するために以下に説明するようにして譲渡するのが望ましい。
【０１１０】
管理データ受信部１５０５は、譲渡の対象などとなる管理データ１５１０を受信する。受信された管理データ１５１０は、管理サーバ１５００のメモリに展開される。そして、管理データ１５１０に署名データなどが含まれていれば、その署名データが正しいかどうかを判断してもよい。
【０１１１】
置換部１５０６は、管理データ受信部１５０５で受信された管理データから照合用データを取得し、まず、その照合用データがデータベース部１５０１で管理されているテーブルに格納されているかどうかを判断する。例えば、図１６（ｃ）に示されるテーブルの照合用データの列に格納されているかどうかを判断する。もし、その照合用データが格納されていなければ、管理データ１５１０の送信者などに、無効な照合用データを含む管理データが送信された旨を返信などする。反対に、その照合用データがデータベース部１５０１で管理されているテーブルに格納されていれば、有効な照合用データを含む管理データであると判断する。有効な照合用データを含めば、新たな照合用データを準備し、この照合用データにより、管理データ１５１０に含まれる照合用データとデータベース部１５０１で管理されているテーブルに格納されている照合用データを置き換える。これにより、価値の情報に新たな照合用データが関連付けされる。
【０１１２】
また、照合用データと関連付けられている他の情報があれば、その情報を用いてさらにチェックを行ってもよい。例えば、識別情報が照合用データと関連付けられていれば、管理データを管理データ受信部１５０５に受信させた利用者や端末装置の識別情報を取得し、比較を行う。比較の結果がＯＫでなければ、無効である旨の返信などを行う。比較の結果がＯＫであれば、照合用データと関連付けられている識別情報と管理データに含まれている識別情報を、次に説明する置換管理データ送信部１５０７による管理データの送信先となる利用者や端末装置の識別情報に書き換える。
【０１１３】
管理データに譲渡回数が含まれている場合には、譲渡回数を更新する。また、更新前の譲渡回数が初期値を示していれば、置き換え前の照合用データがデータベース部１５０１で管理されているテーブルに格納されているかどうかに加えて、照合用データと関連付けられている他の情報を用いたチェックを行ってもよい。例えば、その管理データを発行した際に受信された管理データ発行要求が存在するかどうかを管理サーバのログによりチェックを行ったり、実際に銀行などから金銭の振り込みが実際に行われたかどうかを銀行などのサーバ装置に問い合せたりしてもよい。もちろん、このようなチェックや問い合わせの処理は、管理データが管理サーバ１５００に受信されるたびに行ってもよい。しかし、一般には、このようなチェックや問い合せの処理には時間が要する。そこで、このようなチェックや問い合せの処理の実行は、更新前の譲渡回数が初期値を示していたり、所定の値以下であったり、所定の値以上である場合に行うことに限ることで、処理の時間を短縮することが可能となる。また、異なるサーバに格納されたデータと照合を行うことにより、管理データの不正な作出などを検出することができる。
【０１１４】
置換管理データ送信部１５０７は、置換部１５０６により、新たに準備された照合用データによりその照合用データが置換された管理データ１５１１を送信する。管理データ１５１１の送信は、管理データ１５１０の送信元に対して行ってもよい。あるいは管理データ１５１０の受信とともに送信先を示す情報が受信されたり、あるいは、管理データ１５１０の中に送信先を示す情報が含まれていたりすれば、その送信先へ管理データ１５１１を送信するようになっていてもよい。
【０１１５】
例えば、データベース部１５０１で管理されているテーブルに、図１８（ａ）に示すように、照合用データとして"１３１７１９２"が９９５円という価値の情報と関連付けられて格納されているとする。この状態で、管理データ１１０として、図１８（ｂ）に示すような照合用データとして"１３１７１９２"を含む管理データ１５１０が管理データ受信部１５０５により受信されたとする。すると、管理データ１５１０に含まれる照合用データ"１３１７１９２"は、図１８（ａ）のテーブルに格納されているので、管理データ１５１０は有効な照合用データを含む管理データであると判断される。そこで、置換部は、新たな照合用データとして、例えば"１４９１６２５"を準備する。そして、この照合用データにより、図１８（ａ）に示すテーブルの照合用データ"１３１７１９２"と図１８（ｂ）に示す管理データに含まれる照合用データ"１３１７１９２"とを置き換える。この結果、図１８（ａ）に示すテーブルは図１８（ｃ）に示すようになり、図１８（ｂ）に示す管理データ１１０は図１８（ｄ）に示すようになる。この結果、図１８（ｄ）に示す管理データが管理データ１５１１として送信される。
【０１１６】
なお、照合用データを置き換える際に、照合用データに関連付けられている価値情報の表す金額などのうち一定の額や一定の割合を控除するようにしてもよい。このように控除を行うことにより、管理サーバの運営者が管理サーバの運営などのための費用を得ることが可能となる。
【０１１７】
なお、図１８（ａ）に示すテーブルの照合用データの書き換えは、照合用データの列に格納されているデータに対する更新操作として実行してもよい。あるいは、書き換えの対象となる照合用データ（上の例での"１３１７１９２"）に関連付けられている価値の情報などを読出して一時的に記憶し、書き換えの対象となる照合用データを含む行を削除し、新たに準備された照合用データ（上の例での"１４９１６２５"）と一時的に記憶した価値の情報などを新たな行のデータとして格納されるようにテーブルに対するデータの挿入の操作として実行してもよい。また、更新操作として実行するのではなく、照合用データが削除されたことを示す列（削除フラグ）をテーブルに備えておき、書き換えの対象となる照合用データを格納する行の削除フラグの値を、その行が削除されたことを示す値に更新するとともに、準備された照合用データを含む行を新たにテーブルに挿入してもよい。また、テーブルに挿入される行には、書き換え前の照合用データが格納されていてもよい。これにより、不正などが発覚した場合に、書き換えの履歴をさかのぼることができる。
【０１１８】
また、管理データの照合用データの書き換えは、その文言通り、メモリに展開されている管理データの部分のうち照合用データの部分を書き換えて実行してもよい。あるいは、新たに準備された照合用データを含む管理データを新たに生成してもよい。
【０１１９】
図１８（ｄ）に示す管理データが置換管理データ送信部１５０７により送信された後、再度、図１８（ｂ）に示す管理データが管理データ受信部１５０５で受信されても、それに含まれる照合用データ１３１７１９２は、図１８（ｃ）に示すテーブルに格納されていない（あるいは、削除フラグの列がテーブルに備わっている場合には、削除フラグの値が削除されたことを示す値になっている）。したがって、無効な照合用データを含む管理データと判断される。これにより管理データの二重使用を防止できる。
【０１２０】
図１９は、データベース部１５０１、管理データ受信部１５０５、置換部１５０６、置換管理データ送信部１５０７における処理の流れを説明するフローチャートを例示する。このフローチャートが例示する処理は、ソフトウェアによる情報処理として実現可能である（他の図面のフローチャート、シーケンス図により例示される処理も同様である。）。
【０１２１】
ステップＳ１９０１の処理として、管理データ受信部１５０５により、管理データ１５１０が受信される。その後、管理データ１５１０がメモリに展開などされる。そして、ステップＳ１９０２の処理として、置換部１５０６により、メモリに展開された管理データ１５１０より照合用データが取得される。取得された照合用データが、ステップＳ１９０３の処理において、価値の情報と関連付けてデータベース部１５０１に格納されていることを確認する。もし、格納されていなければ、管理データ１５１０に無効な照合用データが含まれている旨のエラーの返信などをする。
【０１２２】
ステップＳ１９０４の処理として、新しい照合用データを準備する。そしてステップＳ１９０５の処理として、管理データ１５１０の照合用データを新しい照合用データに置き換える。「管理データ１５１０の照合用データ」とは、メモリに展開された管理データ１５１０に含まれる照合用データのみならず、ステップＳ１９０３において価値のデータと関連付けて格納されている照合用データをも意味する。最後にステップＳ１９０６の処理として、照合用データを書き換えられて得られる管理データ１５１１を置換管理データ送信部１５０７により送信する。
【０１２３】
このように、乱数として発生された照合用データに価値を関連付け、管理データが通過するたびにその照合用データを置き換えることにより、管理サーバから送信される管理データの照合用データの予測がつかないようにすることができる。この結果、異なる照合用データに同じ価値が関連付けられることを防止でき、また、管理データの二重使用等を防止することができる。
【０１２４】
（保管サーバ）
次に、保管データについて説明を行う。上述した管理サーバを用いることにより、乱数として発生された照合用データを含む管理データが発行され、有効な照合用データを含む管理データを送信し返信される管理データを受信することにより照合用データが書き換えられる。これにより、管理データの二重使用を防止することができる。以下では、さらに管理データの譲渡等を、匿名性を保ちながら行うために管理サーバの機能を拡張するためなどに用いられる保管サーバについて説明を行う。
【０１２５】
図２０は、管理サーバ２００１と、決済サーバ２００２と、保管サーバ２００３と、利用者端末２００４とからなるシステム２０００の構成を示す。管理サーバ２００１と、決済サーバ２００２と、保管サーバ２００３と、利用者端末２００４とは、通信アダプタなどのハードウェアを用いて通信が可能となっている。システム２０００においては、利用者端末２００４の利用者が、管理サーバ２００１で発行される管理データを得るために、利用者端末２００４と決済サーバ２００２との間で決済の処理を行う。例えば、決済サーバ２００２が銀行の振り込みを処理するサーバとなっており、利用者が管理サーバ２００１の運営者などの銀行口座に振り込みを行うことにより決済の処理が行われる。そして決済の処理が行われたことを示す結果が管理データ発行要求として決済サーバ２００２から管理サーバ２００１に送信されると、管理データが管理サーバ２００１に返信される。その後、管理データは決済サーバ２００２から保管サーバ２００３を経由して利用者端末２００４へ譲渡される。利用者端末２００４には電子財布がインストールされており、管理データは、電子財布により管理されることになる。保管サーバ２００３は、管理データを決済サーバ２００２から受信すると、管理データの二重使用を防止するために、新たな照合用データに置き換えるために、管理サーバ２００１に管理データを送信し、照合用データが置き換えられた管理データを受信し保管する。その後、保管サーバ２００３は、利用者端末２００４から管理データの要求があれば、保管されている管理データを送信する。
【０１２６】
もちろん、保管サーバ２００３が決済サーバ２００２を認証などして信頼できるのであれば、保管サーバ２００３は決済サーバ２００２から受信した管理データを管理サーバ２００１に送信する必要はない。しかし、もし保管サーバ２００３に送信された管理データが決済サーバ２００２内に消去されずに残り、決済サーバ２００２が不正な侵入などされてしまうと、不正に決済サーバ２００２にアクセスを行った者が管理データを入手してしまう可能性があるので、保管サーバ２００３は決済サーバ２００２から受信した管理データを管理サーバ２００１に送信するのが好ましいと言える。
【０１２７】
図２１は、システム２０００における決済処理から管理データの利用者への譲渡までの処理の一例を説明するシーケンス図である。
【０１２８】
ステップＳ２１０１の処理として、利用者端末２００４と決済サーバ２００２との間で、管理データの発行のための決済の処理が行われる。例えば、利用者端末２００４よりクレジットカード番号等と決済金額を提示して、決済サーバ２００２がクレジットカード番号等の正しさを確認等する。あるいは、利用者端末２００４より銀行口座への振り込みの申込を行い、決済サーバ２００２が振込先の銀行口座番号や振込人に付加する識別文字列などを返信する。その後、振込が行われたことについての確認を決済サーバ２００２側にて行う。なお、決済処理により、利用者端末２００４から決済サーバ２００２へ利用者や利用者端末２００４の識別情報が決済サーバに伝達されてもよい。この場合、識別情報は、後に決済サーバ２００２から管理サーバ２００１へ送信される管理データ発行要求の中に含まれる。
【０１２９】
本発明の一実施形態において、ステップＳ２１０１の処理における決済処理を特定する番号などが決定され、この番号が決済サーバと利用者端末とで共有される。決済処理を特定する番号は、例えば、決済サーバが、生成する管理データを一意に識別する番号であったり、利用者端末２００４と決済サーバ２００２との間の通信のセッションを特定するセッションＩＤ（セッションを一意に特定するセッション識別情報）であったりしてもよい。この決済処理を特定する番号は、乱数として管理サーバが生成するのが好ましい。以下、決済処理を特定する番号として、セッションＩＤが用いられるとして説明を行う。ただし、本発明では、決済処理を特定する番号はセッションＩＤに限定されない。また、決済処理を特定する番号をＩＤ情報と称する場合がある。
【０１３０】
クレジットカード番号等の正しさや振込等の確認がされると、ステップＳ２１０２の処理として、決済サーバ２００２から管理サーバ２００１へ管理データ発行要求が送信される。この管理データ発行要求の中に、決済された金額などの情報が含まれる。なお、「決済された金額」は、利用者端末２００４と決済サーバ２００２との間での決済金額から所定の手数料を差し引いた額であってもよい。
【０１３１】
管理データの発行要求に応じて、ステップＳ２１０３の処理として、管理サーバ２００１から管理データ（「管理データ１」と呼ぶ）が決済サーバ２００２へ送信される。
【０１３２】
ステップＳ２１０４の処理として、決済サーバ２００２は、受信した管理データ１と上述のセッションＩＤとを保管サーバ２００３に送信する。
【０１３３】
保管サーバ２００３が決済サーバより管理データ１とセッションＩＤを受信すると、ステップＳ２１０５の処理として、受信した管理データを管理サーバ２００１へ送信し、管理データ１に有効な照合用データが含まれていることの確認と、その照合用データの置き換えを管理サーバ２００１に依頼する。
【０１３４】
なお、管理サーバ２００１は、保管サーバ２００３より照合用データの書き換えが依頼された場合、譲渡回数は増加させない構成になっており、また、照合用データと関連付けられている識別情報と管理データに含まれている識別情報を書き換えない構成となっているとよい。例えば、保管サーバ２００３のＩＰアドレスが管理サーバ２００１に登録されており、登録されているＩＰアドレスから管理データを受信した場合には、譲渡回数を増加させず、識別情報も書き換えない構成となっていてもよい。
【０１３５】
ステップＳ２１０６の処理として、管理サーバ２００１にて、管理データ１に有効な照合用データが含まれていることを確認して照合用データを書き換えた管理データ２を生成し、保管サーバ２００３に返信される。そして、保管サーバ２００３にて、その管理データ２がセッションＩＤに関連付けて記憶される。
【０１３６】
管理データ２がセッションＩＤに関連付けて記憶されたことを通知するために、ステップＳ２１０７の処理として、保管通知が保管サーバ２００３から決済サーバ２００２へ送信される。
【０１３７】
決済サーバ２００２が保管通知を受信すると、ステップＳ２１０８の処理として、利用者端末２００４へ寄託通知が送信され、管理データが保管サーバ２００３に保管されたことが利用者に伝えられる。寄託通知は電子メールによって送信されてもよい。あるいは利用者端末２００４にインストールされたブラウザへ送信されてもよい。そして、寄託通知のコンテンツの種類が電子財布に関連付けられており、利用者が電子メールに添付された寄託通知をダブルクリックしたり、ブラウザが寄託通知を受信したりすると、電子財布が電子メールプログラムやブラウザにより起動され、寄託通知が電子財布により処理されるようになっていることが好ましい。
【０１３８】
その後、利用者は、利用者端末２００４にインストールされた電子財布を操作するなどして、保管サーバ２００３に保管された管理データを要求するために、ステップＳ２１０９の処理として、保管サーバ２００３に対して、管理データの送信要求として、セッションＩＤを送信する。保管サーバ２００３では、セッションＩＤに管理データ２が関連付けて記憶されていることを確認すると、ステップＳ２１１０の処理として、管理データ２を返信し、セッションＩＤとの関連付けを破棄する。
【０１３９】
もちろん、図２０と図２１とに示される構成、処理などを用いなくても、管理データを利用者に発行することができる。例えば、決済サーバが管理サーバから管理データを受信し、直接その管理データを利用者端末へ送信するようにしてもよい。しかし、決済手段として銀行振込を採用した場合などには、決済の確認までタイムラグが生じるので、決済サーバは管理サーバから受信した管理データを次に利用者端末と通信可能になるまで保持しておく必要がある。しかしこれでは、どの管理データが誰に発行されたかの情報を決済サーバが知ることとなり、匿名性が損なわれる。
【０１４０】
また、決済サーバが管理データの発行要求とともに管理データの送信先を管理サーバに送信し、管理サーバがその送信先に発行した管理データを送信する構成を採用することもできる。しかし、これでも、管理データが誰に発行されたかの情報を管理サーバが知ることとなり、やはり匿名性が損なわれる。
【０１４１】
図２０と図２１とに示される構成、処理では、管理サーバ２００１は、どの利用者の利用者端末に対して管理データを発行して送信するか知る必要がなくなる。また、決済サーバ２００２は利用者端末２００４と管理サーバ２００１から送信される管理データを関連付けることはできるが、それは一時的なものに過ぎない。管理データを保管サーバ２００３に送信すると、保管サーバ２００３側で照合用データが書き換えられてしまうからである。また、保管サーバ２００３は、管理データを決済サーバ２００２と利用者端末２００４との通信セッションにより決まる情報と関連付けるので、利用者を識別する必要がない。
【０１４２】
図２２は、保管サーバ２００３の機能ブロック図を示す。図２２の機能ブロック図において、保管サーバ２２００は、預管理データ受信部２２０１と、管理データ送信部２２０２と、管理データ受信部２２０３と、保管部２２０４と、ＩＤ受信部２２０５と、預管理データ送信部２２０６とを有する。
【０１４３】
預管理データ受信部２２０１は、管理データ２２０７とＩＤ２２０８とを受信する。管理データ２２０７とＩＤ２２０８とは、図２１のステップＳ２１０４においての説明での決済サーバから保管サーバへ送信される管理データ１とセッションＩＤとに相当する。ただし、後に説明されるように、預管理データ受信部２２０１は、管理データ２２０７とＩＤ２２０８を決済サーバのみより受信するとは限らない。
【０１４４】
ＩＤ２２０８は、管理データ２２０７を一意に特定する情報であることが望ましい。このため、預管理データ受信部２２０１は、受信したＩＤの履歴を管理し、過去に受信したＩＤと一致するものを受信した場合には、ＩＤの再送要求を返信してもよい。また、受信したＩＤの履歴は、後に説明される保管部８０４が管理するテーブルなどで管理することもできる。すなわち、保管部２２０４が管理するテーブルに同じＩＤが格納されていればＩＤの再送要求を返信してもよい。
【０１４５】
預管理データ受信部２２０１は、受信した管理データ２２０７とＩＤ２２０８とをメモリに展開する。そして、管理データ２２０７のメモリアドレスなどを管理データ送信部２２０２へ渡すことにより管理データ２２０７を伝達し、ＩＤ２２０８のメモリアドレスを保管部２２０４へ渡すことによりＩＤ２２０８を伝達する。
【０１４６】
管理データ送信部２２０２は、預管理データ受信部２２０１より伝達された管理データ２２０７を送信する。送信先は、管理サーバである。送信の結果、管理サーバにて管理データ２２０７に含まれる照合用データの有効性が確認されると、照合用データの書き換えが行われ、書き換え後の管理データ２２０９が返信される。
【０１４７】
管理データ受信部２２０３は、管理データ送信部２２０２からの管理データ２２０７の送信に応じて管理サーバより返信される管理データ２２０９を受信する。上述したように管理データ２２０７の少なくとも照合用データが置き換えられたものが管理データ２２０９となっている。管理データ受信部２２０３は、受信した管理データ２２０９をメモリに展開し、そのメモリアドレスなどを保管部２２０４に渡すことにより、管理データ２２０９を伝達する。
【０１４８】
保管部２２０４は、預管理データ受信部２２０１より伝達されたＩＤ２２０８と管理データ受信部２２０３より伝達された管理データ２２０９とを関連付けて保持する。ＩＤ２２０８と管理データ２２０９とは、異なる時に保管部２２０４に伝達される。このために、保管サーバ２２００は、例えば預管理データ受信部２２０１が受信した管理データ２２０７とＩＤ２２０８とに一意の識別情報を付与するようにしてもよい。そして、預管理データ受信部はＩＤ２２０８とともにその一意の識別情報を保管部２２０４に伝達する。また、管理データ送信部２２０２が管理データ２２０７を送信するために管理サーバと通信セッションを開始するとその通信セッションをその一意の識別情報と関連付ける。そして、管理データ２２０９が受信されると、通信セッションから一意の識別情報を取得し、管理データ受信部２２０３は、管理データ２２０９とともにその一意の識別情報を保管部２２０４に伝達する。これにより、保管部２２０４では、ＩＤ２２０８と管理データ２２０９とを関連付けることができる。また、保管サーバ２２００が付与した一意の識別情報が管理データ２２０７に含まれて送信されるようになっていてもよい。管理サーバは、その一意の識別情報を変更することなく、照合用データを書き換える。
【０１４９】
保管部２２０４は、ＩＤと管理データとを関連付けて保管するためにテーブルを用いてもよい。図２３はそのようなテーブルを示している。図２３では、"ｅ９８７ａｂｃ"というＩＤと照合用データとして"１４９１６２５"を含む管理データとが関連付けて保持されている。"ｅ９８７ａｂｃ"というＩＤは、例えば図２１におけるステップＳ２１０１の処理として行われる決済処理のための利用者端末と決済サーバと間の通信セッションのＩＤなどである。
【０１５０】
なお、保管部２２０４にＩＤ２２０８と管理データ２２０９とが関連付けて格納された場合、ステップＳ２１０７の保管通知となる情報が送信されるようになっていてもよい。この保管通知は、例えば、預管理データ受信部２２０１が管理データ２２０７とＩＤ２２０８とを受信したＡＣＫとして返信されるようになっていてもよい。
【０１５１】
ＩＤ受信部２２０５は、ＩＤ２２１０を受信し、ＩＤ２２１０と保管部２２０４にて関連づけて保管されている管理データの検索を行う。検索の結果、ＩＤ２２１０と関連付けて保管されている管理データが存在すれば、ＩＤ受信部２２０５はその管理データを読出し、預管理データ送信部２２０６へ伝達する。また、ＩＤ２２１０とその管理データとの関連付けを解消あるいは破棄する。解消あるいは破棄は、具体的には、図２３に示すテーブルからＩＤ２２１０が格納されている行データを削除することにより実現される。あるいは、図２３に示すテーブルに削除フラグを格納する列を設けて、削除されたことを示す値を格納することで、解消あるいは破棄されたことを表現するようになっていてもよい。
【０１５２】
預管理データ送信部２２０６は、ＩＤ受信部２２０５から伝達された管理データを送信する。管理データの送信先は、ＩＤ２２１０の送信元であることが想定される。ただし、管理データの送信先がＩＤ２２１０とともにＩＤ受信部２２０５により受信されたなどの場合には、その送信先へ管理データを送信するようになっていてもよい。
【０１５３】
図２４は、保管サーバ２２００における管理データとＩＤとを受信し保管するまでの処理の流れを説明するフローチャートの一例である。ステップＳ２４０１の処理として、預管理データ受信部２２０１により、管理データとＩＤとを受信する。ステップＳ２４０２の処理として、その管理データを、管理データ送信部２２０２により、管理サーバへ送信する。そしてステップＳ２４０３の処理として、管理データ受信部８０３により、管理データを受信する。その後、ステップＳ２４０４の処理として、保管部２２０４により、ステップＳ２４０１で受信されたＩＤとステップＳ２４０３で受信された管理データを関連付けて保管する。
【０１５４】
図２５は、保管サーバ２２００におけるＩＤを受信しそのＩＤと関連付けられて保管されている管理データを送信するまでの処理の流れを説明するフローチャートの一例である。ステップＳ２５０１の処理として、ＩＤ受信部２２０５により、ＩＤを受信する。ステップＳ２５０２の処理として、そのＩＤと関連付けられて管理データが保管部２２０４に保管されていることを確認する。もし確認できなければ、エラーをＩＤの送信元などに返信する。確認ができれば、ステップＳ２５０３の処理として、ＩＤと関連づけて保管されている管理データを読み出す。そして、ステップＳ２５０４の処理として、ＩＤと管理データとが関連付けられて格納されている状態を解消する。例えば、図２３に示されるテーブルから上述にように行データを削除する。その後ステップＳ２５０５の処理として、預管理データ送信部２２０６により、管理データを送信する。
【０１５５】
このような構成の保管サーバを、図２０、図２１に示すように決済サーバと管理サーバとを組み合わせることにより、匿名性を保ちつつ管理データの発行が行える。
【０１５６】
また、このような保管サーバを経由することにより、利用者間でも管理データを譲渡することができる。「利用者間」と記載したが、この場合、一方の利用者は物やサービスを購入する者であり、他方はその物やサービスを提供する者であり、その物やサービスの対価として管理データが一方の者から他方の者へ譲渡される場合が想定される。特に、他方はＷＥＢサーバなどを用いてインターネットからアクセスされる仮想的な店舗であってもよい。すなわち、管理データを電子マネーとして使用することにより、財物や役務の提供に対する代金の決済処理を行うことができる。すなわち、保管サーバが決済処理を行うサーバとして動作することになる。また、保管サーバを用いることにより、個人間などの一般の利用者間でも管理データの譲渡をすることが可能となる。
【０１５７】
図２６は、利用者間で管理データを譲渡するシステム２６００の構成を示す。システム２６００を参照しながら、管理サーバ２６０１と、保管サーバ２６０３と、譲渡者端末２６０４と、譲受者端末２６０５とを有する。譲渡者端末２６０４、譲受者端末２６０５にはそれぞれブラウザ、電子財布がインストールされていてもよい。また、譲渡者端末２６０４の利用者（譲渡人）が譲受者端末２６０５の利用者（譲受人）へ管理データを譲渡する場合の処理の流れについて以下に説明する。
【０１５８】
譲渡人は、あらかじめ、管理サーバから管理データの発行を受けたり、決済サーバを介して管理データを取得したり、決済サーバと保管サーバを介して管理データから取得したりしておく。この管理データは譲渡者端末２６０４にインストールされている電子財布により管理されていてもよい。あるいは別の譲渡人より、管理データの譲渡を受ける。この場合の譲渡としては、これから説明されるように保管サーバを介して行われてもよいし、別の譲渡人から管理データが記録された光ディスクや可搬型の不揮発性半導体メモリなどの記憶媒体の譲渡を受けたり、電子メールの添付データなどとして譲渡を受けたりしていてもよい。このように譲渡を受けた管理データも譲渡者端末２６０４にインストールされている電子財布により管理されてもよい。
【０１５９】
図２７は、保管サーバを介しての管理データの譲渡の流れを説明するシーケンス図である。ステップＳ２７０１の処理として、譲渡者端末２６０４と譲受者端末２６０５との間で管理データの譲渡の合意をする。この合意は、無償にて譲渡人が譲受人に管理データを譲渡する合意であったり、上述のように譲受人が物やサービスを提供することの引き替えに譲渡人が管理データを譲渡する合意であったりする。なお、この合意のために、譲渡人の使用する譲渡者端末（第１の端末）と譲受人の使用する譲受者端末（第２の端末）とが相互に認証し合ってもよい。例えば、暗号化された通信セッションを確立するために第１の端末と第２の端末との間で暗号化と復号化のための暗号鍵を共有する。
【０１６０】
また、相互認証の際には、その相互認証を一意に特定する情報を決める。例えば、ＷＥＢショップで買い物などを行う場合には、ＷＥＢサーバと端末との間の暗号化された通信セッションのＩＤなどを用いる。
【０１６１】
譲渡の合意あるいは相互認証が終了すると、譲渡人側の端末では、電子財布を動作して、新たに管理データの発行を受けたり、既に発行がされたり第三者から譲渡がされたりした管理データの中から選択を行い、管理データ３とセッションＩＤとを保管サーバ２６０３へ送信する。管理データ３とセッションＩＤとを受信した保管サーバは、ステップＳ２７０３の処理として管理データ３を管理サーバへ送信する。管理サーバが管理データ３に含まれる照合用データが有効であると確認を行うと、新たに準備した照合用データによる置換を行い、ステップＳ２７０４の処理として管理データ４を保管サーバへ返信する。これにより、管理データ３は無効な照合用データを含む管理データとなり二重に使用ができなくなる。
【０１６２】
保管サーバが管理データ４を受信すると、ステップＳ２７０２で受信したセッションＩＤと関連付けて保管を行い、ステップＳ２７０５の処理として保管通知を譲渡者端末へ送信する。保管通知を受信した譲渡者端末は、ステップＳ２７０６の処理として、寄託通知を譲渡者端末へ送信する。
【０１６３】
寄託通知を受信した譲受者端末は、ステップＳ２７０７の処理として、管理データの送信要求を譲渡合意の際のセッションＩＤとともに保管サーバへ送信し、これに応じて保管サーバは管理データ４をステップＳ２７０８の処理として返信する。このとき、譲受者端末では電子財布が起動されてもよい。
【０１６４】
以上のように保管サーバを構成することにより、管理データの発行の際、そして、管理データの譲渡の際に同じ処理を保管サーバで行うようにすることができる。また、管理データの匿名性なども確保できる。
【０１６５】
（実施形態３）
上述の実施形態２において、価値として貨幣価値のように可分な価値が用いられる場合には、管理データが表す価値に上限を設けてもよいことについて説明した。例えば、５０００円を上限とすると、１３０００円の価値は、例えば、５０００円を表す管理データ２つと、３０００円を表す管理データ１つとにより表される。この場合の３０００円を表す管理データのように、上限の価値に満たない価値を表す管理データを「端数管理データ」と呼ぶことにする。
【０１６６】
管理データを用いて商品や役務の代金の決済が行われる場合を考えると、代金の額が上記でいう上限になるとは限らない。このため、端数管理データを含む管理データにより代金が支払われたり、釣り銭の代わりに端数管理データを含む管理データが支払いとは逆の方向の管理データの流れで譲渡されたりする。このため、端数管理データの数は増加することになる。この結果、管理サーバのデータベース部の管理するデータが増加してしまうなどの問題が生ずる。そこで、以下では、端数管理データの増加を防ぐ構成について説明を行う。
【０１６７】
（管理サーバ）
本実施形態に係る管理サーバは、実施形態２に係る管理サーバ１５００において、管理データ受信部１５０５が端数管理データ受信手段と、支払額受信手段とを有し、置換部１５０６が端数変更手段と、釣管理データ生成手段とを有し、置換管理データ送信部１５０７が端数管理データ送信手段と、釣管理データ送信手段とを有する。
【０１６８】
端数管理データ受信手段は、端数管理データを受信する手段である。受信された端数管理データは、他の一または複数の管理データとともに、保管サーバより送信され管理サーバに受信され照合用データの有効性の確認がされることが主に想定される。端数管理データ受信手段は、端数管理データを受信するとメモリに展開し、端数管理データに含まれる照合用データのアドレスなどを取得して、端数変更手段に伝達する。
【０１６９】
支払額受信手段は、管理データ受信部１５０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データの表す価値のうち、譲渡が行われる価値を表す。すなわち、保管サーバを経由して譲渡者端末から譲受者端末へ譲渡されるべき価値を表すことが主に想定される。そして、譲渡が行われない価値が存在すれば、その価値は後述のように釣管理データとして譲渡者端末へ送信されることになる。
【０１７０】
端数変更手段は、支払額受信手段が受信した価値を上述の上限の価値で除算を行った時の余りが０で無い場合に、端数管理データ受信手段により受信された端数管理データの表す価値にその余りを加算する処理を行う。例えば、上限額が５０００円で支払額受信手段が受信した価値が１３０００円であれば、１３０００円を５０００円で割り算を行うと、３０００円が余りとなる。そこで、端数管理データ受信手段が受信した端数管理データがデータベース部１５０１により、１０００円を表していれば、１０００円に３０００円を加算した４０００円を表すようにデータベース部１５０１が管理するデータベースの変更操作などを行う。
【０１７１】
具体的には、端数変更手段は、端数管理データ受信手段からで伝達されたアドレス等により指定される照合用データで図１６（ａ）などに示されるテーブルの検索を行いその照合用データがテーブルに格納されているのを確認すると、その照合用データに関連付けられている価値の値に上述の余りを加算する。加算した結果がもし上述の上限を超えていれば、加算した結果のかわりに上限の価値をテーブルに登録し、新たに照合用データを準備してテーブルに挿入し、加算した結果から上述の上限を引いた額を関連付ける。例えば、端数管理データ受信手段からで伝達されたアドレス等により指定される照合用データに１０００円が関連付けられており、上述の余りが４５００円であったとする。すると加算した結果は５５００円となり、上限の５０００円を超えている。そこで、端数管理データ受信手段からで伝達されたアドレス等により指定される照合用データには上限の５０００円を関連づけ、新たに準備される照合用データには５００円を関連付ける。もちろん、５０００円と５００円とに関連付けるのは一例であり、５５００円の上限を超えないように複数の価値に任意に分けることができる。例えば、２５００円と３０００円とであってもよい。
【０１７２】
釣管理データ生成手段は、管理データ受信部１５０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データの表す価値のうち、支払額受信手段が受信した価値を引いた価値（「釣価値」という。）が０でなければ、釣価値を表す管理データを生成する。新たに管理データを生成してもよいし、管理データ受信部１５０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データを再利用するように、その管理データが表す価値に釣価値を加えてもよい。そして、もし加えた結果が上限を超えていれば、新たな管理データを生成して、管理データに上限を超える価値が関連付けられないようにする。
【０１７３】
端数変更手段、釣管理データ生成手段それぞれは、端数管理データ受信手段が受信した端数管理データが含む照合用データ、釣管理データ生成手段が生成した釣価値を表す管理データが含む照合用データのそれぞれを、新たな照合用データを準備して書き換えてもよい。
【０１７４】
端数管理データ送信手段は、端数変更手段により価値が加算された管理データ、また必要に応じて新たに生成された管理データを送信する。
【０１７５】
釣管理データ送信手段は、釣管理データ生成手段で生成された管理データを送信する。
【０１７６】
また、本実施形態において、保管サーバの預管理データ受信部２２０１は、管理データ及びＩＤとともに、支払額情報を受信可能となっている。支払額情報とは、管理データの譲渡により譲渡されるべき価値を示す情報である。そして、預管理データ受信部２２０１は、支払額情報が受信された場合には、受信したＩＤに関連付けられて保管部２２０４に保管されている管理データを検索し、得られた管理データと受信した管理データとともに支払額情報を管理データ送信部２２０２に伝達する。この場合、受信したＩＤに関連付けられて保管部２２０４に保管されている管理データは、譲受者端末より送信された端数管理データとなっている。管理データ送信部２２０２は、管理データとともに伝達された支払額情報を送信する。
【０１７７】
また、管理データ受信部２２０３は、釣管理データも受信可能となっている。釣管理データが受信された場合には、保管サーバは、保管部２２０４に管理データが保管されると、保管通知とともに釣管理データを、預管理データ受信部２２０１が受信した管理データの送信元へ返信する。
【０１７８】
図２８は、本実施形態において、保管サーバを介しての管理データの譲渡の流れの一例を説明するシーケンス図である。ステップＳ２８０１の処理として、ステップＳ２７０１と同様に譲渡の合意を譲渡者端末と譲受者端末との間で行う。このとき、その合意では、単に管理データの譲渡のみならず、管理データの譲渡により譲渡される価値も合意する。例えば、商品の値段、送料などである。そして、このような場合に譲渡者端末が保管サーバへ送信する管理データを支払管理データという。
【０１７９】
ステップＳ２８０２の処理として、譲受者端末から保管サーバへ、端数管理データ１とセッションＩＤとを保管サーバへ送信する。このとき、譲受者端末である旨の情報も送信してもよい。ステップＳ２８０３の処理として、保管サーバは、受信した端数管理データ１を管理サーバへ送信し、その有効性を確認させ、ステップＳ２８０４の処理として、保管サーバは、端数管理データ２を管理サーバより受信する。そして、セッションＩＤと関連づけて端数管理データ２を保管する。
【０１８０】
なお、譲受者端末に端数管理データが無ければ、保管サーバには端数管理データを送信する必要はなく、したがって、保管サーバが端数管理データを管理サーバに送信する必要もない。
【０１８１】
譲渡者端末は、ステップＳ２８０５の処理として、支払額と支払いのための支払管理データ１とセッションＩＤを保管サーバに送信する。保管サーバは、支払管理データ１と支払額とを管理サーバに送信する。また、保管サーバは、セッションＩＤからそれに関連付けられている端数管理データの有無を検出し、もしそのような端数管理データが存在すれば、その端数管理データもともに管理サーバへ送信する。なお、ステップＳ２８０２において、譲受者端末から譲受額が送信されてもよく、この場合は、譲渡者端末から送信される支払額と譲受額とが同じであることを確認してもよい。もし、同じでなければ譲受者端末、譲渡者端末へエラーを通知する。また、ステップＳ２８０２において、譲受者端末から譲受額が送信され、ステップＳ２８０５において、譲渡者端末から支払額が送信されない構成もある。この場合には、支払管理データ１に関連付けられている価値の値が譲受額以上であることを確認する。もし、譲渡に伴って手数料などを徴収する際には、支払管理データ１に関連付けられている価値の値から手数料などの額の値を引いたものが譲受額以上であることを確認する。また、端数管理データ１に関連付けられている価値から手数料などの額を徴収することにしてもよい。
【０１８２】
管理サーバは、受信した支払管理データ２、支払額、端数管理データ２から、置換部１５０６、置換管理データ送信部１５０７により、端数管理データ３と支払管理データ２と釣管理データとを生成して、ステップＳ２８０７の処理として、保管サーバへ送信する。ここで、端数管理データ３は、端数変更手段で変更、生成された管理データであり、釣管理データは釣管理データ生成手段で生成された管理データである。
【０１８３】
端数管理データ３と支払管理データ２と釣管理データとを受信した保管サーバは、支払管理データ３と端数管理データをステップＳ２８０２又はＳ２８０５で受信したセッションＩＤと関連づけて保管する。そして、ステップＳ２８０８の処理として、譲渡者端末へ釣管理データと保管通知を送信する。譲渡者端末は、ステップＳ２８０９において寄託通知を譲受者端末へ送信し、譲受者端末はステップＳ２８１０において、送信要求とセッションＩＤとを保管サーバへ送信し、これに応じて保管サーバは、セッションＩＤと関連付けて保管されている端数管理データ３と支払管理データ２をステップＳ２８１１の処理として、譲受者端末へ送信する。そして、セッションＩＤと端数管理データ３及び支払管理データ２との関連付けを破棄する。
【０１８４】
このようにして、譲渡者端末から譲受者端末へ、譲渡合意で合意された価値が電子的に譲渡される。また、本実施形態では、管理データが表す価値に上限を設けられている場合に、譲受者端末から端数管理データを提供することにより、その端数管理データに釣り銭に相当する価値を加えることができ、端数管理データの数の増大を防止することができる。これにより、管理サーバのデータベース部１５０１で管理するべき照合用データの数の増加を防止することができる。なお、「譲受者端末」と記載したが、譲受者端末は端末装置と同等の機能を有していればよく、サーバ装置を端末装置として用いられる場合も含まれる。譲渡者端末についても同様である。
【０１８５】
（実施形態４）
実施形態２において、図２０、図２１などを参照して、管理サーバ、決済サーバ、保管サーバ及び利用者端末からなるシステムの構成などについて説明した。本発明の実施形態４として、別のシステムの構成などについて説明する。
【０１８６】
図２９は、本発明の実施形態５に係るシステム２９００の構成を示す。システム２９００は、管理サーバ２９０１と、決済サーバ２９０２と、保管サーバ２９０３と、利用者端末２９０４とを有する。実施形態２と同様に、管理サーバ２９０１と、決済サーバ２９０２と、保管サーバ２９０３と、利用者端末２９０４とは、それぞれ通信アダプタなどのハードウェアを備え、通信を行う。実施形態２では、利用者端末２００４の利用者は、管理サーバ２００１と直接通信を行う必要は無かったが、本実施形態では、様々な決済サーバの構成に対応できるように、利用者端末２９４０の利用者は、管理サーバ２９０１とも通信を行う構成となっている。
【０１８７】
本実施形態では、管理サーバ２９０１と、決済サーバ２９０２と、保管サーバ２９０３と、利用者端末２９０４とは、基本的に実施形態１における管理サーバ２００１と、決済サーバ２００２と、保管サーバ２００３と、利用者端末２００４と同じ構成でよい。ただし、本実施形態では、管理サーバ２９０１と利用者端末２９０４とが通信を行うので、この点を実現する構成が異なる。すなわち、管理サーバ２９０１は、利用者端末２９０４に対してサービスを提供するための部が備わった構成となっている。例えば、管理サーバ２００１に、ウェブサーバとして動作する部が備わっており、利用者端末２９０４に対してサービスを提供するようになっている。したがって、この場合には、利用者端末２９０４は、ウェブブラウザなどの閲覧ソフトウェアを用いて管理サーバ２９０１と通信を行う。また、利用者端末２９０４には、ウェブブラウザなどの他に、管理データを管理するアプリケーションプログラムである電子財布（以下、電子財布を、管理データを管理するアプリケーションプログラムという意味で「管理データ管理アプリケーション」という）がインストールされていてもよく、管理データ管理アプリケーションを用いて管理サーバ２９０１と通信を行うようになっていてもよい。
【０１８８】
図３０は、本実施形態におけるシステム２９００での決済処理が行われて管理データが生成されて利用者端末に受信されるまでの処理を説明するシーケンス図である。
【０１８９】
ステップＳ３００１において、利用者端末２９０４から管理サーバ２９０１へ、利用者端末２９０４の識別情報を含む情報を送信する。識別情報とは、利用者端末２９０４を識別するための情報である。識別情報の例としては、利用者端末２９０４の製造番号や、ＭＡＣアドレス、ＩＰアドレスなどである。あるいは、利用者を識別する情報であるユーザＩＤや所有者ＩＤなどであってもよい。また、識別情報は、利用者端末２９０４の製造番号や、ＭＡＣアドレス、ＩＰアドレスなどの情報そのものである必要はなく、それらの情報に対して所定のハッシュ関数を適用して計算される値であってもよい。この識別情報は、管理サーバ２９０１により後に発行される管理データに埋め込まれてもよい。識別情報を管理データに埋め込むことにより、管理データを譲渡などする場合に、管理データが不正に他の利用者端末から取得されたものであるかどうかを検出することができる。これにより、管理データの使用の際の安全性を高めることができる。また、識別情報には、乱数が含まれるようになっており、管理サーバ２９０１への送信の都度、変化する部分があってもよい。
【０１９０】
管理サーバ２９０１において、識別情報を受信する部を識別情報受信部という。
【０１９１】
なお、ステップＳ３００１において、識別情報は、例えば、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のＰＯＳＴメッセージとして、利用者端末２９０４から管理サーバ２９０１に送信される。ただし、識別情報は、ブラウザで送信される必要はなく、上述した管理データ管理アプリケーションによって送信されてもよい。管理データ管理アプリケーションを用いれば、利用者端末２９０４のハードウェアなどにアクセスを行い、ＭＡＣアドレスなどを取得することが容易に行える。
【０１９２】
ステップＳ３００２においては、管理サーバ２９０１は、画面情報を利用者端末２９０４へ返信する。画面情報は、例えば、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いて記述され、管理データを発行するための入金処理や、発行された管理データを受け取るための処理を行うために使用することができる。
【０１９３】
利用者端末１９０４が画面情報を受信すると、その画面情報の記述に従って画面表示を行う。例えば、受信された画面情報を、利用者端末２９０４で動作する管理データ管理アプリケーションがＲＥＡＤシステムコールなどを用いて取得すると、ウェブブラウザを起動して、そのウェブブラウザによって画面情報を表示させる。
【０１９４】
図３１は、表示される画面情報の例を示す。例えば管理データ管理アプリケーションによりブラウザが起動されて画面情報が表示されると、図３１（ａ）に示されるように、「入金」、「管理データ受取」という表示を有するボタンが表示される。「入金」の表示を有するボタンが押下されると、画面情報に含まれるスクリプトなどの処理により、図３１（ｂ）に示される画面が表示される。
【０１９５】
図３１（ｂ）は、銀行振込を行うための画面であって、「振込名義人名を１２３４５としてください」というメッセージが表示され、「振込」という表示を有するボタンが表示されている。１２３４５というのは、管理サーバ２９０１がステップＳ３００１において識別情報を受信した際に、管理サーバ２９０１側などで生成される情報である。あるいは、利用者端末２９０４側で生成され、ステップＳ３００１において管理サーバ２９０１に送信され、管理サーバ２９０１で承認などされた番号であってもよい。承認とは、利用者端末２９０４側で生成された情報が適切でることを確認することである。例えば、同じ情報を他の利用者端末で生成されて管理サーバ２９０１に送信されていないことを確認する。あるいは、識別情報がユーザＩＤであれば、そのユーザＩＤそのものやユーザＩＤに関連付けられた値である。利用者が銀行振込を行う際に、この情報を振込名義人名に含ませることにより、管理サーバ２９０１が銀行から振込通知を受信などした際に、その振込がどの識別情報の受信に対して返信した画面情報によって行われたかを知ることができる。また、図３１（ｂ）の画面には、振込先の銀行口座の情報が含まれていてもよい。
【０１９６】
管理サーバ２９０１において、振込名義人名を生成あるいは承認、取得し、利用者端末２９０４に送信する部を、振込名義人名送信部という。
【０１９７】
なお、図３１（ｂ）において、複数の銀行の中から利用者端末２９０４の利用者が契約している銀行を選択できるように、複数の銀行それぞれに対応したボタンが表示されていてもよい。
【０１９８】
図３１（ｂ）の「振込へ」の表示を有するボタンが押下されると、利用者端末２９０４から銀行などの決済サーバ２９０２に対してアクセスが行われ、図３２（ａ）のようなインターネットバンキングなどのためのログイン画面が表示される。このログイン画面を介して利用者がログインを行い、振込の依頼を行うと、ステップＳ３２０４の処理として、利用者端末２９０４から決済サーバ２９０２に対して振込依頼が送信される。この振込依頼には、管理サーバ２９０１などの運営者の銀行口座の情報、振込名義人名、振込額が含まれる。なお、図３１（ｂ）の「振込へ」の表示を有するボタンには、振込先の口座の情報や、振込名義人名を含むＵＲＬが関連付けられており、そのＵＲＬにアクセスすると、決済サーバ２９０２に振込先の口座の情報や振込名義人名が伝えられ、振込の画面が開かれた場合に、振込先の口座の情報や振込名義人名が既にデフォルト値などとして入力された状態となっていてもよい。
【０１９９】
振込の依頼が終わると、ステップＳ３２０４の処理として、利用者端末２９０４から管理サーバ２９０１へ、振込の依頼の処理が終わったこと旨を表す入金通知が送信される。この際には、ステップＳ３２０１で送信された識別情報や振込名義人名も送信される。すなわち、利用者端末２９０４にて、振込の依頼の処理が終了すると、利用者端末２９０４では、図３２（ｂ）に示されるような画面が表示される。図３２（ｂ）に示される画面は、「入金通知」という表示を有するボタンが表示されている。このボタンが押下されると、ステップＳ３００４の処理として、入金通知が利用者端末２９０４から管理サーバ２９０１へ送信される。入金通知は、利用者端末２９０４にて振込の依頼の処理が終了したことを、利用者端末２９０４から管理サーバ２９０１に知らせる情報である。
【０２００】
入金通知を受信した管理サーバ２９０１は、ステップＳ３２０５の処理として、入金通知とともに送信された情報から振込名義人名を取得し、決済サーバ２９０２に対して、その振込名義人名による振込が実際に依頼されたかどうかを問い合せる。決済サーバ２９０２は、その振込名義人名による振込があれば、ステップＳ３２０６の処理として振込通知を返信する。この振込通知には振込額も含まれていてよく、これにより、管理サーバ２９０１は振込額を得ることができる。
【０２０１】
また、ステップＳ３００５とＳ３００６の処理の代わりに、管理サーバ２９０１は、例えば、５分に一回、振込の有無の問い合せを管理サーバ２９０１に行い、振込の有無を確認してもよい。
【０２０２】
もし、振込がされていなければ、管理サーバ２９０１は、ステップＳ３００４の入金通知に対して、振込が確認できなかったことを通知する。この場合、管理データ管理アプリケーションなどによって振込の確認ができていないことの表示がされ、利用者は、しばらく時間が経過してから再度入金通知を行うことになる。
【０２０３】
管理サーバ２９０１は、振込を確認すると、振込通知に含まれる振込名義人名から、どの識別情報の受信に対して画面情報によって行われたかをテーブルなどを検索して取得し、管理データを生成し、また、実施形態２で説明したように、振り込みの決済処理を特定する番号を生成する。決済処理を特定する番号は、本実施形態では、「送り情報」と称することにする。送り情報は、例えば、利用者端末２９０４と管理サーバ２９０１とがステップＳ３００１とＳ３００２とで通信を行ったセッションのＩＤであってもよい。また、振込み名義人名送信部で送信された振込名義人名を用いてもよい。ステップＳ３００７の処理として、生成した送り情報と管理データとを保管サーバ２９０３へ送信する。保管サーバ２９０３は、送り情報と管理データとを関連付けて、その保管部に保持する。
【０２０４】
管理サーバ２９０１において、振込通知を受信する部を振込通知受信部と称する。また、管理データを生成するために、新たな照合用データを準備して、振込通知受信部が受信した振込通知に含まれる金額の額に相当する価値情報を関連づけてデータベース部１５０１に記憶する部を照合用データ生成部と称する。また、新たに準備された照合用データから生成された管理データを送信する部を管理データ送信部と称する。また、本実施形態では、管理サーバ２９０１は、準備された照合用データと、識別情報受信部で受信された識別情報を関連付けてデータベース部１５０１などに記憶する。
【０２０５】
ステップＳ３００８の処理として、管理サーバ２９０１は、入金が確認された旨と送り情報とを利用者端末２９０４へ返信する。なお、ステップＳ３００１とＳ３００２とにおいて利用者端末２９０４と管理サーバ２９０１との通信において、送り情報が、セッションＩＤや振込名義人名として利用者端末２９０４に送り情報が通知されていれば、ステップＳ３００８では、送り情報を利用者端末２９０４へ返信する必要はない。
【０２０６】
管理サーバ２９０１にて、その振込によって生成された送り情報を取得し、ステップＳ３００８の処理として、入金確認と送り情報とを利用者端末２９０４へ返信する。
【０２０７】
利用者端末２９０４が、入金確認と送り情報とを受信すると、図３２（ｃ）に示される画面が表示される。図３２（ｃ）に示される画面においては、「入金の確認がされましたので、管理データ受取を押して下さい」というメッセージと、「管理データ受取」という表示を有するボタンが表示される。なお、図３２（ｃ）の画面は、ブラウザによって表示される必要はなく、管理データ管理アプリケーションによって表示されてもよい。例えば、ステップＳ３００８にて返信される入金確認と送り情報とが、ＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎ）のフォーマットを用いて送信され、そのフォーマットにおいてＣｏｎｔｅｎｔ−Ｔｙｐｅなどによって、管理データ管理アプリケーションがアプリケーションプログラムとして用いられることが指定されていてもよい。このような指定により、ブラウザが入金確認と送り情報とを受信すると、管理データ管理アプリケーションが起動され、図３２（ｃ）に示される画面が表示できる。
【０２０８】
「管理データ受信」のボタンが押下されると、ステップＳ３００９の処理として、利用者端末２９０４から保管サーバ２９０３へ、送り情報が送信される。この送り情報が保管サーバ２９０３にて受信されると、ステップＳ３００６において格納部に送り情報と関連付けられて保管された管理データが読み出される。そして、ステップＳ３０１０の処理として、その管理データが保管サーバ２９０３から利用者端末２９０４に受信されて、利用者端末２９０４内に格納される。
【０２０９】
図３３は、管理サーバ２９０１が、ステップＳ３００１において利用者端末２９０４から識別情報を受信してから、ステップＳ３００８において入金確認と送り情報とを送信するまでの処理を行うために参照するテーブルの構成と格納されるデータの遷移を説明する。図３３（ａ）に示すように、管理サーバ２９０１は、「識別情報」、「振込番号」、「金額」、「送り情報」という名前の列により構成されるテーブルを保持し、管理を行う。
【０２１０】
管理サーバ２９０１がステップＳ３００１において識別情報を受信すると、そのテーブルに対して行データの挿入が行われる。識別情報が例えば９８７６５であれば、図３３（ｂ）に示されるように、識別情報の列の値が９８７６５である行がテーブルに挿入される。その行において、識別情報の列以外の列の値は、例えば、ＮＵＬＬ（図示せず）とされる。ＮＵＬＬとされることにより、まだ値が定まっていないことが表現される。
【０２１１】
識別情報がステップＳ３００１において受信され、その識別情報に基づいて振込名義人名が決定されると、挿入された行の振込番号の列の値が、その振込名義人名に更新される。例えば、振込名義人名が図３１（ｂ）に示されるように１２３４５であれば、図３３（ｃ）に示すように、識別情報の列の値が９８７６５である行の振込番号の列の値が１２３４５に更新される。
【０２１２】
管理サーバ２９０１がステップＳ３００６において振込通知を受信すると、その振込通知に含まれる振込名義人名を振込番号の列に有する行が検索され、振込通知に含まれる振込金額により金額の列の値が更新される。例えば、振込通知により、１２３４５という振込名義人名により５０００円が振り込まれたとすると、図３３（ｄ）に示すように、識別情報の列の値が９８７６５である行の金額の列の値が５０００に更新される。これにより、管理サーバ２９０１は、振込があったことが確認できるようになる。
【０２１３】
管理サーバ２９０１が送り情報を生成し、ステップＳ３００７において保管サーバ２９０３に、送り情報を送信すると、「送り情報」の列の値が更新される。例えば、１２３４５という振込名義人名により５０００円が振り込まれ、２４６８１０という送り情報が生成されると、図３３（ｅ）に示すように、識別情報の列の値が９８７６５である行の送り情報の列の値が２４６８１０に更新される。これにより、管理サーバ２９０１は、９８７６５という識別番号に対して、管理データを生成して、保管サーバ２９０３に送信したことが確認できるようになる。
【０２１４】
図３４は、利用者端末２９０４の図３とは別の機能ブロック図を示す。この機能ブロック図は、利用者端末２９０４にインストールされているアプリケーションプログラムの構成を示している。利用者端末２９０４には、ブラウザと管理データ管理アプリケーションとがインストールされている。ブラウザと管理データ管理アプリケーションとが協調して動作して決済処理から管理データの受信の処理を行う。
【０２１５】
図３５は、利用者端末２９０４にインストールされているブラウザと管理データ管理アプリケーションとが協調して、図３０に示される決済処理が行われ、管理データが生成されて利用者端末に受信されるまでの処理のシーケンス図を示す。
【０２１６】
ステップＳ３５０１は、ステップＳ３００１に対応している。ステップＳ３５０１においては、識別情報が、管理データ管理アプリケーションより送信されることを示している。管理データ管理アプリケーションを用いれば、ブラウザを用いるよりも容易に利用者端末２９０４のハードウェアなどにアクセスを行い、ＭＡＣアドレスなどのハードウェア固有の情報を取得することができる。
【０２１７】
なお、ステップＳ３５０１の処理を実行するには、利用者端末２９０４にて管理データ管理アプリケーションを起動する。管理データ管理アプリケーションの起動により、例えば、図３６に示されるように、「入金（ポイント購入）」、「ポイントの受取」、「ポイントによる支払」の表示を有するボタンを含む画面表示が利用者端末２９０４のディスプレイなどに表示がされる。「入金（ポイント購入）」のボタンが押下されると、管理データ管理アプリケーションは、識別情報を算出などして、管理サーバ２９０１へ送信する。
【０２１８】
ステップＳ３５０２は、ステップＳ３００２に対応している。ステップＳ３５０２においては、ステップＳ３５０１にて送信された識別情報に対して管理サーバ２９０１から返信される画面情報が、管理データ管理アプリケーションにより受信される。
【０２１９】
管理データ管理アプリケーションが画面情報を受信すると、ステップＳ３５０３の処理として、管理データ管理アプリケーションはブラウザを起動し、画面情報の記述に従った画面表示を行う処理が行われる。例えば、管理データ管理アプリケーションは、受信した画面情報を一時ファイルに書き込み、その一時ファイルの名前をコマンドの引数などとしてブラウザに与えてブラウザを起動する。例えば、一時ファイルの拡張子と関連付けられているブラウザが起動されるようになっている。
【０２２０】
ステップＳ３５０４、ステップＳ３５０５、ステップＳ３５０６、ステップＳ３５０７、ステップＳ３５０８は、それぞれステップＳ３００３、ステップＳ３００４、ステップＳ３００５、ステップＳ３００６、ステップＳ３００７、ステップＳ３００８に対応している。これらのステップの処理では、利用者端末２９０４では、ブラウザが管理サーバ２９０１、決済サーバ２９０２と通信を行う。
【０２２１】
ステップＳ３５０９にて、ブラウザが入金確認と送り情報とを管理サーバ２９０１より受信すると、ブラウザは、管理データ管理アプリケーションを起動し、送り情報を管理データ管理アプリケーションに処理をさせる。上述したように入金確認と送り情報とが、ＭＩＭＥのフォーマットを用いた情報としてブラウザにより受信されると、そのフォーマットにおいてＣｏｎｔｅｎｔ−Ｔｙｐｅなどによって、管理データ管理アプリケーションにより処理することが指定されているので、ブラウザは管理データ管理アプリケーションを起動し、起動した管理データ管理アプリケーションは、送り情報を取得する。ステップＳ３５１０の処理として、管理データ管理アプリケーションは、保管サーバ２９０３へ送り情報を送信する。保管サーバ２９０３から返信される管理データを受信する処理をステップＳ３５１１の処理として行う。管理データ管理アプリケーションが管理データを受信すると、受信した管理データを、利用者端末２９０４の記憶装置（ハードディスクなど）に書き込む。
【０２２２】
ブラウザから管理データ管理アプリケーションが起動された場合には、図３６の画面が表示されてもよい。利用者端末２９０４の利用者が「ポイントの受取」の表示を有するボタンを押下すると、ステップＳ３５１１とステップＳ３５１２との処理が開始されるようになっていてもよい。
【０２２３】
図３７は、管理データ管理アプリケーションの図６とは別のモジュール構成図を示す。管理データ管理アプリケーション３７００は、識別情報取得部３７０１と、送り情報管理部３７０２と、管理データ管理部３７０３と、送受信部３７０４と、制御部３７０５とを有している。
【０２２４】
識別情報取得部３７０１は、ステップＳ３５０１において送信される識別情報を取得する。例えば、利用者端末２９０４のハードウェアにシステムコールなどを用いてアクセスを行い、ＭＡＣアドレスや製造番号などを取得する。また、利用者端末２９０４の利用者のＩＤやパスワードなどの認証情報を識別情報として取得してもよい。また認証情報は、ファイルに格納されていたり、キーボードやカードリーダなどにより読み取られるようになっていたりしてもよい。また、認証情報の一部に乱数が含まれる場合には、識別情報取得部３７０１がその乱数を生成するようになっていてもよい。
【０２２５】
また、識別情報取得部３７０１により取得された識別情報は、ステップＳ３５１１の処理により管理データが受信されるまで、利用者端末のハードディスクなどの二次記憶に記憶されるようになっていてもよい。管理データ管理アプリケーションが起動すると、二次記憶に識別情報が記憶されているかどうかを調べ、もし、記憶されていれば、受け取られていない管理データが保管サーバ２９０３に保管されている旨の表示を行い、利用者に注意を喚起してもよい。この場合、利用者が振込の依頼の処理を行っているのならば、管理データ管理アプリケーションは利用者にステップＳ３５０５の入金通知を管理サーバ２９０１に送信し、入金確認と送り情報を受信することができるように、ボタンなどを表示する。そして、そのボタンが押下されると、管理データ管理アプリケーションは入金通知を管理サーバ２９０１に送信する。
【０２２６】
送り情報管理部３７０２は、ステップＳ３３１０において、ブラウザから渡された送り情報を管理する。管理とは、データのファイルへの書き込み、読み出し、削除、更新を意味する。ステップＳ３５０９の処理により、ブラウザから管理データ管理アプリケーションが起動される際に、ブラウザから渡された送り情報を所定のファイルに書き込む。また、ステップＳ３５１１の処理により、管理データが受信されると、所定のファイルを削除したり、所定のファイルから送り情報を削除したりする。これにより、送り情報が受信されたが、受信されていない管理データの有無をしらべることができる。
【０２２７】
管理データ管理部３７０３は、管理データを管理する。ステップＳ３５１１にて受信された管理データは、管理データ管理部３７０３により、利用者端末２９０４の記憶装置（ハードディスクなど）に書き込まれ、また、管理データを用いた支払の処理の際に読み出し、削除、変更が行われる。
【０２２８】
送受信部３７０４は、管理サーバ２９０１、保管サーバ２９０３と通信を行うための部である。
【０２２９】
制御部３７０５は、識別情報取得部３７０１と、送り情報管理部３７０２と、管理データ管理部３７０３と、送受信部３７０４とを制御し、管理データの受信の処理、管理データを用いた支払の処理を行う。
【０２３０】
図３８は、管理データを用いた支払の処理のシーケンス図を示す。図３８は、保管サーバを介しての管理データの譲渡についてのシーケンス図である図２８に対応している。図２８での譲受者端末が図３８での販売サーバに対応し、譲渡者端末が利用者端末に対応している。本実施形態では、利用者端末の内部で管理データ管理アプリケーションとブラウザとが協調して動作している。また、販売サーバは、ＷＥＢサーバとしての機能を有しており、ＷＥＢページの閲覧要求があれば、要求されたＷＥＢページを返信する。
【０２３１】
ステップＳ３８０１において、利用者端末のブラウザなどへＵＲＬの入力や、ブラウザを操作してリンクを辿るなどの処理を行い、ウェブページの閲覧要求が販売サーバへ送信される。販売サーバが閲覧要求を受信すると、要求されたウェブページをステップＳ３８０２において返信する。
【０２３２】
ステップＳ３８０２においてブラウザに返信されるウェブページには、商品などの購入の申込を行うための画面の記述がされているとする。例えば、図３９に示すように、「○○」として、購入が行われる商品などの名称が表示され、代金が例えば１００円として表示される。また、「購入」という表示を有するボタンが表示されている。このボタンには、購入が行われる商品などの識別番号が関連付けられている。また、必要に応じて、ウェブページには商品の配送先などを入力するテキストエリアが含まれており、「購入」という表示を有するボタンが押下されると、そのテキストエリアに入力された情報が送信されるようになっていてもよい。
【０２３３】
「購入」という表示を有するボタンが押下されると、ステップＳ３８０３の処理として、購入情報が保管サーバに送信される。購入情報とは、販売サーバの識別情報、購入が行われる商品などの識別番号、商品などの数量、代金額を含む情報である。また、上述した商品などの発送先を含んでいてもよい。この購入情報は、図３９に示されるボタンに関連付けられた情報を用いて生成され、販売サーバに送信される。購入情報が販売サーバに送信されることにより、ブラウザを操作する利用者が販売サーバの運営者から商品などの購入の同意がされ、支払が管理データの譲渡によってされることの同意もされたことが示される。
【０２３４】
すなわち、ステップＳ３８０１からステップＳ３８０３までの処理が行われることにより、譲受端末としての販売サーバと譲渡者端末としての利用者端末との間で譲渡の合意がされることになる。従って、ステップＳ３８０１からステップＳ３８０３までの処理がステップＳ２８０１に対応していることになる。
【０２３５】
ステップＳ３８０４の処理として、販売サーバから支払指示とセッションＩＤがブラウザに送信される。支払指示には、譲渡されるべき価値の額（支払額）が含まれている。また、セッションＩＤは、上述の送り情報に対応する。支払指示とセッションＩＤとは、例えば、ＭＩＭＥフォーマットで記述され、Ｃｏｎｔｅｎｔ−Ｔｙｐｅなどによって、管理データ管理アプリケーションを用いて表示されることが指定されていてもよい。
【０２３６】
また、販売サーバは、保管サーバに対して、端数管理データ１とセッションＩＤを送信する。これは、利用者端末から送信される管理データによる支払を受けるためである。
【０２３７】
販売サーバから端数管理データ１とセッションＩＤを受信した保管サーバは、ステップＳ３８０６の処理として、端数管理データ１を管理サーバへ送信し、端数管理データ１が有効であるかどうかを判断させ、有効であれば、照合用データの書き換えを行わせ、その結果得られる管理データである端数管理データ２をステップＳ３８０７の処理において受信する。そして、送り情報と関連付けて保管する。
【０２３８】
したがって、ステップＳ３８０５、Ｓ３８０６、Ｓ３８０７の処理は、ステップＳ２８０２，Ｓ２８０３、Ｓ２８０４の処理に対応している。
【０２３９】
ステップＳ３８０４にて、販売サーバから支払指示とセッションＩＤを受信したブラウザは、管理データ管理アプリケーションを起動させ、販売サーバから受信した支払指示とセッションＩＤとの処理を行わせる。すなわち、起動した管理データ管理アプリケーションは、ステップＳ３８０９の処理として、ステップＳ３８０４で受信したセッションＩＤと支払指示に含まれる支払額とを、また、その支払額以上となるように管理データを管理データ管理部３７０３から選択して読み出して支払管理データ１として、保管サーバに送信する。支払額以上とは、選択された管理データが表す価値の額の合計額が、支払額以上となるこという。管理データ管理部３７０３から読み出される管理データは複数であってもよい。また、管理データ管理アプリケーションが起動すると、支払額を画面に表示し、ボタン押下を利用者に行わせるなどして、支払管理データの額などの確認を行わせてもよい。また、管理データ管理部３７０３で管理されている管理データは暗号化されて記憶されている場合には、復号のためのパスワードなどの入力が求められるようになっていてもよい。
【０２４０】
ステップＳ３８０９において、管理データ管理アプリケーションからセッションＩＤ、支払額、支払管理データ１を受信した保管サーバは、セッションＩＤに、支払額と支払管理データ１を関連付けて保管する。また、他にセッションＩＤに関連付けて保管されている管理データがあるかどうかの検索を行い、そのような管理データがあれば、ステップＳ３８１０以降の処理を行う。
【０２４１】
ステップＳ３８１０とステップＳ３８１１の処理は、ステップＳ２８０６、Ｓ２８０７の処理に対応している。保管サーバは、端数管理データ２と支払額と支払管理データ１を管理データに送信し、端数管理データ３、支払管理データ２と釣管理データとを受信する。
【０２４２】
ステップＳ３８１２の処理として、保管サーバは管理データ管理アプリケーションに釣管理データを送信する。この釣管理データの送信は、ステップＳ３８０９にて受信された支払額と支払管理データ１の返信として行われてもよい。
【０２４３】
ステップＳ３８１３の処理として、管理データ管理アプリケーションは、ブラウザを起動し、決済終了画面を表示させる。決済終了画面の記述は、ステップＳ３８１２にて、保管サーバが釣管理データとともに管理データアプリケーションに送信するようになっていてもよい。さらに、決済終了画面の記述は、ステップＳ３８０５において、販売サーバが端数管理データ１とセッションＩＤとともに保管サーバに送信するようになっていてもよい。このように決済終了画面の記述が、販売サーバから送信され、保管サーバを経由して、利用者端末へ送信されることにより、電子的なデータそのものや電子的なデータのダウンロードなどのために使用するＵＲＬを決済終了画面の記述に含ませることにより、電子的なデータを販売に本実施形態を利用することができる。
【０２４４】
ステップＳ３８１４にて管理サーバから受信された端数管理データ３と支払管理データ２は、ステップＳ３８０５にて受信されたセッションＩＤとともに保管サーバから販売サーバへ送信される（ステップＳ３８１４）。端数管理データ３と支払管理データ２の送信は、ステップＳ３８０５にて販売サーバから送信された端数管理データ１とセッションＩＤに対する返信として行われてもよい。
【０２４５】
このように、支払指示とセッションＩＤとがブラウザなどにより受信されると、管理データアプリケーションが起動し、管理データを用いた支払を行うことができるようになる。したがって、本実施形態においては、利用者は、ステップＳ３８０３にて購入情報を、ブラウザを用いて販売サーバに送信した後の決済の処理を行うために、従来技術におけるのと異なり、クレジットカード番号や振込先の口座番号などの煩雑なデータを入力する必要がなくなる。また、利用者端末２９０４に記憶された管理データを用いて支払を行うので、クレジットカードのようにその後の返済などについて心配する必要がない。したがって、利用者は簡便な操作で管理データを用いて支払を行うことができる。これにより、インターネットなどでの支払を安全かつ簡便に行うことができる。
【図面の簡単な説明】
【０２４６】
【図１】本発明の一実施形態に係る電子商取引システムの概要を示す図である。
【図２】計算機のハードウェアとソフトウェアの構成の一例図である。
【図３】本発明の一実施形態に係る利用者端末の機能ブロック図である。
【図４】本発明の一実施形態に係るブラウザの機能ブロック図である。
【図５】クッキー情報の構造の模式図である。
【図６】本発明の一実施形態に係る電子財布の機能ブロック図である。
【図７】コンテンツのタイプとアプリケーションプログラムとを関連付ける表の一例図である。
【図８】本発明の一実施形態に係る利用者端末の動作を説明するフローチャートである。
【図９】本発明の一実施形態に係るショップサーバの機能ブロック図である。
【図１０】本発明の一実施形態に係るショップサーバのＵＲＬ転送部が管理する表の一例図である。
【図１１】本発明の一実施形態に係るショップサーバにおける処理を説明するフローチャートである。
【図１２】本発明の一実施形態に係るショップサーバにおける処理を説明するフローチャートである。
【図１３】本発明の一実施形態に係る確認サーバで行われる処理を説明するフローチャートである。
【図１４】本発明の一実施形態に係る電子商取引システムの全体の処理を説明するシーケンス図である。
【図１５】本発明の一実施形態に係る管理サーバの機能ブロック図である。
【図１６】本発明の一実施形態における管理データ発行の具体例を説明する図である。
【図１７】本発明の一実施形態に係る管理サーバの処理のフローチャートである。
【図１８】本発明の一実施形態における照合用データの書き換えの具体例を説明する図である。
【図１９】本発明の一実施形態に係る管理サーバの処理のフローチャートである。
【図２０】本発明の一実施形態に係る管理サーバ、決済サーバ、保管サーバ及び利用者端末からなるシステム構成図である。
【図２１】本発明の一実施形態に係る管理サーバ、決済サーバ、保管サーバ及び利用者端末からなるシステムによる処理のシーケンス図である。
【図２２】本発明の一実施形態に係る保管サーバの機能ブロック図である。
【図２３】本発明の一実施形態における管理データを保管するためのテーブルの一例図である。
【図２４】本発明の一実施形態における保管データ発行の具体例を説明する図である。
【図２５】本発明の一実施形態における保管データ発行の具体例を説明する図である。
【図２６】本発明の一実施形態に係る利用者間で管理データを譲渡するシステムの構成図である。
【図２７】本発明の一実施形態に係る利用者間で管理データを譲渡するシステムによる処理のシーケンス図である。
【図２８】本発明の一実施形態に係る利用者間で管理データを譲渡するシステムによる処理のシーケンス図である。
【図２９】本発明の一実施形態に係る管理サーバ、決済サーバ、保管サーバ及び利用者端末からなるシステム構成図である。
【図３０】本発明の一実施形態において決済処理が行われ管理データが生成されて利用者端末に受信されるまでの処理のシーケンス図である。
【図３１】本発明の一実施形態に係る利用者端末の画面表示を示す図である。
【図３２】本発明の一実施形態に係る利用者端末の画面表示を示す図である。
【図３３】本発明の一実施形態に係る管理サーバが保持するテーブルの構成と内容の遷移を示す図である。
【図３４】本発明の一実施形態に係る利用者端末の機能ブロック図である。
【図３５】本発明の一実施形態において決済処理が行われ管理データが生成されて利用者端末に受信されるまでの処理のシーケンス図である。
【図３６】本発明の一実施形態に係る利用者端末の画面表示を示す図である。
【図３７】本発明の一実施形態に係る管理データ管理アプリケーションの機能ブロック図である。
【図３８】本発明の一実施形態に係る利用者端末から販売サーバへ管理データを譲渡する処理のシーケンス図である。
【図３９】本発明の一実施形態における商品などの購入の申込を行うための画面の一例図である。
【技術分野】
【０００１】
本発明は、コンテンツを利用者端末にダウンロードして処理する際に、その利用者端末にそのコンテンツを処理するプログラムがインストールされているかどうかをサーバ装置側から検出する技術に関する。コンテンツとしては、例えば電子的な価値を表す情報があり、そのようなコンテンツを処理するプログラム電子財布がある。
【背景技術】
【０００２】
現実の貨幣の価値やチケットなどの債権・債務の関係を電子的なデータに関連付け、このような電子的なデータの交換によって決済処理を行う技術が知られている（例えば、特許文献１参照。）。また、その技術を用いて、インターネットでの商取引の決済が行われている。この場合、現実の貨幣などの価値を電子的なデータを管理するためのアプリケーションプログラムなどとして電子財布が用いられる（例えば、特許文献２参照。）。
【特許文献１】特開２００２−７４２３７号公報
【特許文献２】特開２００７−９４９８４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、利用者が利用する電子機器に電子財布がインストールされていない状態で、決済処理が開始すると、不利益が生じる。例えば、決済処理の途中まで進んだ段階で、利用者が利用する電子機器に電子財布がインストールされていないことが発覚すると、決済処理を最後まで行うことができないことになる。そして、利用者は注文の商品などを購入することができず、また、商品などの販売者は売り上げを計上できないという不利益を蒙る。
【０００４】
同様のことが、文書情報、音楽情報や動画情報のダウンロードについても言え、ダウンロードした文書情報、音楽情報や動画情報の形式を扱うことができるプログラムが利用者の利用する電子機器にインストールされていないと、別の形式の文書情報、音楽情報や動画情報を扱うことができるプログラムがインストールされていても、新たにプログラムをインストールしなければならない。
【課題を解決するための手段】
【０００５】
本発明の一実施形態として、次のような、ブラウザがインストールされている利用者端末と、ＨＴＴＰ要求を処理する第１と第２のサーバ装置を有するシステムの動作方法を提供する。すなわち、ブラウザは、第１のサーバ装置へ第１のＨＴＴＰ要求を送信する。例えば、電子財布で決済を行う商取引を開始するためのウェブページの要求を送信する。あるいは、特定のプログラムで再生や編集などを行うコンテンツのダウンロードを開始するためのウェブページの要求を送信する。その要求に対して、第１のサーバ装置は、第２のサーバ装置への第１のアクセス命令を返信する。ブラウザが第１のアクセス命令を受信すると、第１のアクセス命令に従って第２のサーバ装置へ第２のＨＴＴＰ要求を送信する。この第２のＨＴＴＰ要求には、第１のＨＴＴＰ要求のＵＲＬが含まれていてもよい。また、利用者端末に電子財布や特定のプログラムがインストールされているかどうかを示す所定のクッキー情報が記憶されていれば、その所定のクッキー情報が第２のＨＴＴＰ要求とともに送信されるようになっている。
【０００６】
第２のサーバ装置は、第２のＨＴＴＰ要求とともに所定のクッキー情報が受信されるか否かに依存して返信される第２のアクセス命令を、ブラウザへ返信する。ブラウザは、第２のアクセス命令を受信すると、第２のアクセス命令に従って第１のサーバ装置への第３のＨＴＴＰ要求を送信する。この第３のＨＴＴＰ要求のＵＲＬは、第１のＨＴＴＰ要求のＵＲＬに所定のパラメータとその値などを付加したものであってもよい。そして、第１のサーバ装置は、第３のＨＴＴＰ要求が、前記第２のサーバ装置が前記第２のＨＴＴＰ要求とともに所定のクッキー情報を受信していない場合に返信する第２のアクセス命令に従ったＨＴＴＰ要求である場合には、所定のクッキー情報を前記利用者端末に記憶させるプログラムをダウンロードするためのリンク情報を含む返信を行う。
【０００７】
これにより、利用者端末に電子財布や特定のプログラムがインストールされていなければ、利用者端末には、その電子財布などの必要なプログラムをダウンロードしてインストールするためのリンク情報が表示される。したがって、利用者端末の利用者は、利用者端末に必要なプログラムがダウンロードされていないことを知ることができる。また、容易にその必要なプログラムをダウンロードしてインストールすることができる。
【０００８】
また、その必要なプログラムが利用者端末にダウンロードされると、所定の種類のコンテンツとのその必要なプログラムが関連付けられるようになってもよい。これにより、ブラウザがその種類のコンテンツを受信すると、その必要なプログラムがブラウザにより起動され、コンテンツが必要なプログラムに入力されるようになっていてもよい。また、その必要なプログラムが利用者端末にダウンロードされると、所定のクッキー情報がブラウザの管理する記憶領域に記憶あれるようになっていてもよい。
【０００９】
これにより、第１のサーバ装置が、第３のＨＴＴＰ要求が、第２のサーバ装置が前記第２のＨＴＴＰ要求とともに所定のクッキー情報を受信している場合に返信される第２のアクセス命令に従ったＨＴＴＰ要求である場合には、所定の種類のコンテンツをダウンロードするためのリンク情報を含む返信を行うことにより、スムーズにコンテンツの処理ができ、電子財布を用いた決済やコンテンツの再生や編集などを行うことができる。
【００１０】
また、第１のサーバ装置が、第３のＨＴＴＰ要求に対して行う返信には、次の別のプログラムが含まれていてもよい。すなわち、ブラウザが利用者端末に記憶させた第３のＨＴＴＰ要求のＵＲＬの全体または一部を取得する。そして、所定のパラメータの値を取得する。その値と所定の値とを比較し、その比較結果に応じて、プログラムをダウンロードするためのリンク情報を利用者端末のディスプレイなどに表示するようになっていてもよい。
【００１１】
これにより、第１のサーバ装置は、プログラムをダウンロードするためのリンク情報と所定の種類のコンテンツをダウンロードするためのリンク情報とを別々に記憶する必要がなくなる。
【００１２】
なお、上記では、第１のＨＴＴＰ要求を受信するサーバ装置と第３のＨＴＴＰ要求を受信するサーバ装置とを同一としたが、異なるサーバ装置であってもよい。
【００１３】
本発明の別の一実施形態として、ブラウザがインストールされている利用者端末に別のプログラムをインストールし、そのブラウザが第１のサーバ装置へ送信するＨＴＴＰ要求とともに送信するクッキー情報であってその別のプログラムがインストールされていることを表すクッキー情報を利用者端末に記憶し、そのブラウザが第２のサーバ装置へＨＴＴＰ要求を送信して第１のサーバ装置への第１のアクセス命令を返信として受信し、そのブラウザが第１のアクセス命令に従って第１のサーバ装置へＨＴＴＰ要求とともにそのクッキー情報を送信して第１のサーバ装置にてそのクッキー情報の確認がされることを条件として送信される前記第２のサーバ装置への第２のアクセス命令を返信として受信し、そのブラウザが第２のアクセス命令に従って第２のサーバ装置へＨＴＴＰ要求をして得られるコンテンツをその別のプログラムへの入力とする、利用者端末の動作方法が提供される。
【００１４】
この利用者端末の動作方法によれば、利用者端末にその別のプログラムがインストールされているかどうかを第１のサーバ装置が判断した結果を第２のサーバ装置に伝達することができるので、第２のサーバ装置は、適切なコンテンツを利用者端末に送信できるようになり、課題が解決される。
【００１５】
また、その別のプログラムに入力されるコンテンツの種類とその別のプログラムとを前記利用者端末において関連付け、そのブラウザが第２のサーバ装置へＨＴＴＰ要求を送信して返信されるコンテンツを受信すると、受信されたコンテンツの種類に関連付けられたその別のプログラムが起動されるようになっていてもよい。
【００１６】
これにより、そのブラウザがコンテンツを受信すると、そのブラウザによりその別のプログラムが自動的に起動されることになり、例えば、利用者端末の利用者にコンテンツ利用を容易に提供できる。
【００１７】
また、第２のアクセス命令に含まれるＵＲＬにはパラメータが含まれており、第２のアクセス命令にしたがって第２のサーバ装置へ送信されるＨＴＴＰ要求の返信には、そのブラウザが利用者端末のメモリに記憶したＵＲＬを取得させ、取得されたＵＲＬに含まれるそのパラメータの値を変数に記憶させ、その変数の値を所定の値と比較させ、その別のプログラムがインストールされているかどうかを利用者端末に判断させる第３のプログラムが含まれていてもよい。
【００１８】
これにより、第２のアクセス命令に含まれるＵＲＬのパラメータの値として、利用者端末にその別のプログラムがインストールされているかどうかが示されるので、例えば、第２のサーバ装置には、利用者端末にその別のプログラムがインストールされている場合とそうでない場合との２つの返信を用意する必要がなくなる。
【００１９】
その別のプログラムは、価値が関連付けられた情報を管理する電子財布であり、そのブラウザが第２のアクセス命令に従って第２のサーバ装置へＨＴＴＰ要求をして得られるコンテンツは、その電子財布が管理するべき価値が関連付けられた情報と、その電子財布が管理する価値の関連付けられた情報の一部または全てとの送信先と、のいずれか一以上を含んでいてもよい。
【００２０】
これにより、例えば、第２のサーバ装置に対する第１のＨＴＴＰ要求が商品などの購入の申込である場合、利用者端末にその電子財布がインストールされているかどうかを第１のサーバ装置により判断し、その結果が第２のサーバ装置に伝達されるので、第２のサーバ装置は、適切な支払命令などをコンテンツとして送信することができる。
【００２１】
また、本発明の一実施形態として、利用者端末より第１のＨＴＴＰ要求を受信する第１要求受信部と、受信された第１のＨＴＴＰ要求に対して、その第１のＨＴＴＰ要求とは別のＵＲＬへの第１のアクセス命令を返信する返信部と、返信された第１のアクセス命令に応じて利用者端末が返信として受信した第２のアクセス命令に応じて利用者端末より第２のＨＴＴＰ要求を受信する第２要求受信部と、第２のＨＴＴＰ要求に対する応答を行う応答部と、を有するサーバ装置が提供される。
【００２２】
これにより、サーバ装置は、第１のアクセス命令の示すＵＲＬへ利用者端末をアクセスさせて、利用者端末にその別のプログラムがインストールされているかどうかを判断させた結果を第２のＨＴＴＰ要求として得ることができる。
【００２３】
また、その利用者端末は、第１のアクセス命令に応じて送信するＨＴＴＰ要求とともに送信するクッキー情報を記憶し、返信部による第１のアクセス命令によるその別のＵＲＬへのアクセスをその利用者端末が行うと、そのクッキー情報が送信されるようになっていてもよい。
【００２４】
これにより、その別のプログラムがその利用者端末にインストールされているかどうかを第１のサーバ装置は、クッキー情報によって判断することができる。
【発明の効果】
【００２５】
本発明の実施形態によれば、利用者が用いる電子機器としての利用者端末に、必要なプログラムがインストールされているかどうかを、サーバ装置側が検出することができる。これにより、コンテンツのダウンロードなどを行う前に、利用者に警告を発したり、必要なプログラムのインストールを勧めたり、利用者が用いる電子機器にインストールされているプログラムが扱える情報の形式でダウンロードなどを行うことができる。
【００２６】
特に電子財布については、本発明の実施形態によれば、利用者が用いる電子機器に電子財布がインストールされているかどうかを、サーバ装置側が検出することができる。これにより、決済処理を行う前に、利用者に警告を発したり、電子財布のインストールを勧めたり、インストールされている電子財布が扱える形式の情報を利用者端末に送信して決済処理を行うことができる。
【発明を実施するための最良の形態】
【００２７】
以下、本発明を実施するための最良の形態について、図を参照しながら実施形態として説明を行う。なお、本発明はこれらの実施形態に何ら限定されるものではない。本発明の属する技術分野における通常の知識を利用しながらこれらの実施形態を変形して本発明を実施することも可能である。なお、以下では、サーバ装置をサーバと略記する場合がある
【００２８】
（実施形態１）
図１は、本発明の実施形態１に係る電子商取引システムの概要を示す図である。電子商取引システム１００においては、利用者端末１０２が、インターネットなどの通信網１０１を介して、ショップサーバ１０３及び確認サーバ１０４と通信を行う。また、必要に応じて、ショップサーバ１０３と確認サーバ１０４とが通信を行うことができるようになっていてもよい。
【００２９】
利用者端末１０２は、商品や役務などの購入者である利用者が商取引を行うために用いる電子機器である。ショップサーバ１０３は、利用者端末１０２の利用者から商品、役務などの購入の申込を受け付け、利用者端末１０２との決済処理を行うための装置である。確認サーバ１０４は、ショップサーバ１０３が決済処理を行うために必要な電子財布が利用者端末１０２にインストールされているかどうかを確認するための装置である。なお、決済処理は、商品や役務などの対価として行われる必要はなく、利用者が他の者に価値を贈与する場合にも行われてよい。
【００３０】
なお、ショップサーバ１０３と確認サーバ１０４とは同じサーバ装置として実現されていても良い。この場合には、利用者端末１０２にインストールされているブラウザが、そのサーバ装置のうちショップサーバ１０３に相当する部分と確認サーバ１０４に相当する部分とにアクセスするＵＲＬが異なっていればよい。例えば、ＵＲＬのパスの部分が異なっていればよい。
【００３１】
なお、利用者端末１０２と，ショップサーバ１０３と、確認サーバ１０４とのそれぞれは、例えば、計算機によって構成することが可能である。図２（ａ）は計算機のハードウェア構成の一例を示す。計算機２００は、ＣＰＵ２０１と、メモリ２０２と、二次記憶２０３と、入出力Ｉ／Ｆ２０４とを有し、それぞれが相互にバス２０５により接続されている。ＣＰＵ２０１は、プログラムを構成する命令を実行する回路である。メモリ２０２は、ＣＰＵ２０１によりその命令が実行されるプログラムや必要なデータを記憶する。二次記憶２０３はプログラムやデータを記憶する。一般的に二次記憶２０３は、記憶内容が不揮発に構成されており、例えば、磁気ディスクやフラッシュメモリなどにより構成される。また、二次記憶２０３に記憶されたプログラムやデータをＣＰＵ２０１が処理を行うためには、一般的には、メモリ２０２へコピーなどがされる必要がある。入出力Ｉ／Ｆ２０４は、計算機２００の外部との情報の入出力を行うための部である。例えば、ディスプレイインターフェース、キーボード、インターフェース、通信インターフェースなどのいずれか一以上を含む。
【００３２】
図２（ｂ）は、ＣＰＵ２０１によりプログラムが実行されている計算機２００の状態を模式的に示す。最下層２１１として、図２（ａ）に例示したハードウェアの階層があり、その上の階層２１２として、例えばオペレーティングシステムという特別なソフトウェアの階層がある。オペレーティングシステムの上の階層２１３にてアプリケーションプログラムが動作する。例えばアプリケーションプログラムがハードウェアにアクセスを行う場合には、直接アクセスを行うことができず、オペレーティングシステムを介してアクセスを行うことになる。例えば、入出力Ｉ／Ｆ２０４を介してデータの入出力を行うには、アプリケーションプログラムは、システムコールを呼び出し、オペレーティングシステムにデータの入出力を依頼する。なお、上述した電子財布や、ブラウザ、ウェブサーバプログラムは、アプリケーションプログラム２１３として実現することが可能である。
【００３３】
なお、利用者端末１０２と，ショップサーバ１０３と、確認サーバ１０４との全ては、計算機にアプリケーションプログラムを動作させることのみにより実現されることはなく、大規模集積回路などを用いたハードウェアにより実現することも可能である。
【００３４】
（利用者端末）
図３は、利用者端末の機能ブロック図を示す。利用者端末１０２は、ブラウザ３０２と、電子財布３０３とがインストールされている。また、利用者端末１０２は、タイプ関連付部３０４を有する。ブラウザ３０２は、利用者の操作によりＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）による要求を送信し、その応答を受信し、画面の表示などを行う。ブラウザ３０２は、一般的に閲覧ソフトウェアとして知られているものと同一または同等の機能を有するのが好ましい。なお、ブラウザ３０２と、電子財布３０３とは同時にインストールされる必要はない。
【００３５】
図４は、ブラウザの機能ブロック図の一例を示す。ブラウザ３０２は、クッキー情報管理部４０１と、履歴管理部４０２と、ブックマーク管理部４０３と、操作部４０４と、表示部４０５と、送受信部４０６と、制御部４０７とを有している。
【００３６】
クッキー情報管理部４０１は、クッキー情報の記憶、検索、読み出し、削除、変更その他の管理を行う部である。例えば、クッキー情報は二次記憶に記憶され、クッキー情報管理部４０１により管理がされる。クッキー情報とは、ブラウザ３０２が通信を行うサーバから送られた、何らかの状態を表す情報である。例えば、ＲＦＣ２１０９に規定されている。クッキー情報は、サーバからのＨＴＴＰ応答のＳｅｔ−Ｃｏｏｋｉｅヘッダとして送られ、クッキー情報管理部４０１に記憶、変更がされる。また、クッキー情報は、ブラウザ３０２がサーバにＨＴＴＰの要求を送信する際に、クッキー情報管理部４０１により検索、読み出しが行われてサーバへ送信される。
【００３７】
図５は、クッキー情報の構造を模式的に示す。クッキー情報は、１以上のＮＡＭＥ＝ＶＡＬＵＥの形式である、名前とその値の組と、ｅｘｐｉｒｅｓ＝ＤＡＴＥで示される、クッキー情報の有効期限と、ｄｏｍａｉｎ＝ＤＯＭＡＩＮで示される、クッキー情報を送信するべきサーバのドメインと、ｐａｔｈ＝ＰＡＴＨで示される、クッキー情報を送信するべきＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）またはＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）のサブセットから構成される。なお、本発明では、ＵＲＩをＵＲＬとして扱う。
【００３８】
本実施形態では、クッキー情報管理部４０１には、確認サーバ１０４へ送信されるクッキー情報が格納されている。すなわち、クッキー情報管理部４０１には、クッキー情報を送信するべきサーバのドメインが、確認サーバ１０４のＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）と一致または一部となっているクッキー情報が格納されている。例えば、確認サーバのＦＱＤＮがｗｗｗ．ｆｏｏ．ｂａｒであれば、ｄｏｍａｉｎ＝ｆｏｏ．ｂａｒとなりｐａｔｈ＝／となっているクッキー情報がクッキー情報管理部４０１に格納されている。したがって、ブラウザ３０２が、ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｂａｒ／のＵＲＬにより、ｗｗｗ．ｆｏｏ．ｂａｒをアクセスすると、そのクッキー情報が読み出され、確認サーバに送信される。
【００３９】
確認サーバ１０４へ送信されるクッキー情報をクッキー情報管理部４０１に格納する方法には種々の方法がある。例えば、電子財布３０３をインストールするためのプログラムをダウンロードするためのウェブサーバにブラウザ３０２がアクセスした場合、そのウェブサーバが、確認サーバ１０４へ送信されるクッキー情報を送信する。あるいは、電子財布３０３をインストールするためのプログラムが実行された場合、そのプログラムがクッキー情報管理部４０１の管理する二次記憶２０３の領域にアクセスを行い、確認サーバ１０４へ送信されるクッキー情報を格納する。あるいは、電子財布３０３をインストールするためのプログラムがブラウザ３０２を起動させ、確認サーバ１０４やその他の所定のサーバにアクセスをさせて、そのアクセスがされたサーバが、確認サーバ１０４へ送信されるクッキー情報をブラウザ３０２に送信する。あるいは、電子財布３０３を起動させると、確認サーバ１０４やその他の所定のサーバにアクセスが行われ、そのアクセスがされたサーバが、確認サーバ１０４へ送信されるクッキー情報をブラウザ３０２に送信する。例えば、電子財布３０３を起動させるとボタン表示を有する画面が表示され、そのボタンを押下すると、ブラウザ３０２が起動されて確認サーバ１０４やその他の所定のサーバにアクセスが行われるようになっていてもよい。また、電子財布３０３をインストールした後、ブラウザ３０２により所定のサーバにブラウザ３０２によってアクセスし、会員登録をした際に、その所定のサーバより、確認サーバ１０４へ送信されるクッキー情報がブラウザ３０２に送信されるようになっていてもよい。
【００４０】
履歴管理部４０２は、ブラウザ４００で閲覧を行ったウェブページなどの履歴を保持する部である。ブックマーク管理部４０３は、ブックマークの記憶、検索、読み出し、削除、変更などの管理を行う部である。操作部４０４は、利用者端末のキーボードやマウスなどの利用者による操作を検出する部である。表示部４０５は、サーバからの応答を表示などする部である。送受信部４０６は、サーバに対して要求を送信し、返答を受信する部である。制御部４０７は、クッキー情報管理部４０１と、履歴管理部４０２と、ブックマーク管理部４０３と、操作部４０４と、表示部４０５と、送受信部４０６とを制御し、ブラウザとして動作するように制御する部である。例えば、クッキー情報管理部４０１と、履歴管理部４０２と、ブックマーク管理部４０３と、操作部４０４と、表示部４０５と、送受信部４０６のそれぞれの部を構成するモジュールを統括するモジュールである。
【００４１】
利用者はブラウザ３０２を用いてショップサーバ１０３などのサーバと通信を行い、ショッピングなどを行う。ショッピングなどの対価の支払の決済処理のために、本実施形態では、電子財布３０３が起動されて動作する。後述するタイプ関連付部３０４により、電子財布３０３の起動は、ブラウザ３０２により行われるようにすることができる。
【００４２】
図６は、電子財布の機能ブロック図の一例を示す。電子財布５００は、管理データ管理部５０１と、送受信部５０２と、制御部５０３とを有する。管理データ管理部５０１は、管理データの記憶、検索、読み出し、削除、変更その他の管理を行う部である。例えば、管理データは二次記憶に記憶され、管理データ管理部５０１により管理される。管理データとは、現実の貨幣などの価値が関連付けられたデータをいう。管理データと呼ばれる代わりに、電子マネーや電子バリューなどと呼ばれる場合がある。送受信部５０２は、決済処理のために通信を行う部である。例えば、新たに利用者が購入した管理データを受信したり、決済のために支払うべき額を含む請求データを受信したり、支払のために管理データを送信したりする。制御部５０３は、管理データ管理部５０１と送受信部５０２とを制御する部である。
【００４３】
タイプ関連付部３０４は、ブラウザ３０２が扱うコンテンツの種類（タイプ）を保持する部である。本実施形態では特に、ブラウザ３０２が他のアプリケーションプログラムにコンテンツの処理を依頼するために、アプリケーションプログラムをその種類と関連付けて保持する部である。
【００４４】
図７は、タイプ関連付部３０４を実現するために、コンテンツのタイプとアプリケーションプログラムとを関連付ける表である。コンテンツのタイプは例えば、ＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎｓ）のタイプにより表され、ｔｅｘｔ／ｐｌａｉｎというタイプにはテキストエディタが関連付けられ、ｉｍａｎｇｅ／ｐｎｇというタイプにはイメージビュアーが関連付けられている。また、タイプ関連付部３０４は、ファイルの拡張子とアプリケーションプログラムが関連付けられるようになっていてもよい。このような関連付けは、例えば、二次記憶に記憶され、オペレーティングシステムなどにより管理される。
【００４５】
本実施形態では、タイプ関連付部３０４により、決済処理のためにショップサーバ１０３から送信される請求データのコンテンツのタイプに電子財布が関連付けられる。
【００４６】
図８は、本実施形態における利用者端末の動作を説明するフローチャートの一例を示す。このフローチャートの処理を実行する前に、利用者端末の利用者は、ブラウザなどを用いてショッピングなどを行い、購入などをする商品などを決定する。その決定された商品などに対する対価を支払う際に、図８のフローチャートの処理が実行される。
【００４７】
ステップＳ８０１の処理として、利用者端末１０２のブラウザ３０２が、ショップサーバ１０３へ注文データなどをＨＴＴＰ要求として送信する。注文データは、商品などの注文を確定し、商品などの対価の支払処理をショップサーバ１０３に開始させるデータである。例えば、注文データは、ＨＴＴＰのＰＯＳＴコマンドとして表現され、商品番号と商品の個数、商品の配送先を含むデータであってもよい。また、注文データのかわりに、商品や役務の提供を行うウェブページの要求が送信されてもよい。
【００４８】
ステップＳ８０２の処理としては、ステップＳ８０１で送信されたＨＴＴＰ要求に対して返信されるアクセス命令を受信する。このアクセス命令は、ショップサーバ１０３から返信される。このアクセス命令は、ブラウザ３０２に対して、確認サーバ１０４へアクセスを行うことを要求する。
【００４９】
アクセス命令は、ＨＴＴＰ要求に対する応答として、例えば、＜ｍｅｔａ ｈｔｔｐ−ｅｑｕｉｖ＝”ｒｅｆｒｅｓｈ” ｃｏｎｔｅｎｔ＝”０；ｕｒｌ＝確認サーバのＵＲＬ”＞により表すことができる。ここでの「確認サーバのＵＲＬ」には、ステップＳ８０１で送信されたＨＴＴＰ要求を、ショップサーバ１０３にて一意に識別できる情報が含まれるようになっていてもよい。例えば、ショップサーバ１０３は、注文データを受信すると、注文データに対して連番を付与し、その連番と注文データとを関連付けて二次記憶などに格納し、連番を含む確認サーバのＵＲＬを返信する。その連番は、例えば、ＵＲＬにパラメータとして含ませることができる。また、そのＵＲＬには、ショップサーバ１０３のＦＱＤＮなどのショップサーバ１０３を識別する識別情報を含ませる。なお、「０；」は待ち時間なしで直ちに「確認サーバのＵＲＬ」にアクセスすることを意味している。「０；」の代わりに必要に応じて任意の時間を指定することができる。
【００５０】
また、アクセス命令は、ショップサーバ１０３が、ＲＦＣ２６１６の１０．３節に規定されている３００番台のステータスコードとともに応答する返信によっても実現できる。例えば、３０１のステータスコードや３０２のステータスコードとともにアクセスするべきＵＲＬを返信することによって、ブラウザ３０２を、確認サーバ１０４へアクセスさせるようにすることができる。
【００５１】
なお、本発明の明細書、請求の範囲、図面においては、アクセス命令をＲＦＣ２６１６に倣い、リダイレクト命令と呼ぶ場合がある。
【００５２】
ステップＳ８０３の処理として、ステップＳ８０２にて受信したリダイレクト命令に従って、確認サーバへＨＴＴＰ要求を送信する。例えば、ステップＳ８０２にて＜ｍｅｔａ ｈｔｔｐ−ｅｑｕｉｖ＝”ｒｅｆｒｅｓｈ” ｃｏｎｔｅｎｔ＝”０；ｕｒｌ＝確認サーバのＵＲＬ”＞が受信された場合には「確認サーバのＵＲＬ」を用いて確認サーバ１０４にアクセスが行われる。また、確認サーバへＨＴＴＰ要求が送信される際には、クッキー情報管理部４０１で管理されているクッキー情報のうち、確認サーバへ送信されるクッキー情報も送信される。
【００５３】
ステップＳ８０３にて送信されたＨＴＴＰ要求を受信した確認サーバ１０４は、そのＨＴＴＰ要求とともにクッキー情報を受信したことを確認する。また、必要ならば、クッキー情報に含まれるＮＡＭＥ＝ＶＡＬＵＥを確認する。クッキー情報管理部４０１が格納している、確認サーバへ送信されるクッキー情報の定義により、このようにクッキー情報などを確認することは、利用者端末１０２に電子財布３０３がインストールされていることが確認されたことを意味する。確認ができれば、確認サーバ１０４は、ショップサーバ１０３へのリダイレクト命令を返信する。このとき確認サーバは、利用者端末１０２から送信されたＨＴＴＰ要求に含まれる確認サーバの識別情報を用いてショップサーバのＦＱＤＮを生成などしてリダイレクト命令に含める。
【００５４】
また、このリダイレクト命令によりブラウザ３０２がアクセスするＵＲＬに、確認サーバへ送信されるクッキー情報が確認されたかどうかを「＆」で区切られるパラメータとして含めるようになっていてもよい。例えば、確認サーバへ送信されるクッキー情報が確認された場合には、そのＵＲＬに「＆ｅｗａｌｌｅｔ＝１」が含められ、確認されない場合には、「＆ｅｗａｌｌｅｔ＝０」が含められるようになっていてもよい。
【００５５】
また、ショップサーバの二次記憶に格納された注文データの連番などが、そのＨＴＴＰ要求に含まれていれば、その連番などをリダイレクト命令に含まれるショップサーバ１０３へのＵＲＬに含ませる。その連番などはそのＵＲＬのパラメータとして含ませることができる。また、そのＵＲＬには、確認サーバ１０４が、利用者端末１０２に電子財布３０３がインストールされていることを確認した旨の情報が含まれるようになっていてもよい。例えば、確認サーバ１０４による連番などの署名データが含まれるようになっていてもよい。署名データそのものが含まれる必要はなく、確認サーバ１０４が、連番などの署名データに識別子を付与して、ショップサーバ１０３よりアクセス可能にその識別子に署名データを関連付けて格納し、その識別子をそのＵＲＬに含ませてもよい。
【００５６】
また、ステップＳ８０３にて送信されたＨＴＴＰ要求を受信した確認サーバ１０４は、クッキー情報に含まれるＮＡＭＥ＝ＶＡＬＵＥの組から、どのような種類の電子財布が利用者端末１０２にインストールされているかを判断し、その種類を、そのＵＲＬに含ませてもよい。
【００５７】
また、確認サーバ１０４が、クッキー情報を確認できなければ、電子財布３０３をインストールするためのウェブページへのリダイレクト命令を返信する。電子財布３０３をインストールするためのウェブページには、例えば、電子財布３０３をダウンロードするためのリンク情報が含まれている。あるいは、そのウェブページには、電子財布３０３のインストールの方法が記載されている。
【００５８】
ステップＳ８０４の処理として、上述したように確認サーバ１０４から送信されたリダイレクト命令を受信する。このリダイレクト命令が受信されたということは、上述したように、確認サーバ１０４が、利用者端末１０２に電子財布３０３がインストールされていることの確認の結果が受信されたことを意味する。
【００５９】
ステップＳ８０５の処理として、ステップＳ８０４にて受信されたリダイレクト命令に応じて、ショップサーバ１０３へＨＴＴＰ要求を送信する。このＨＴＴＰ要求がショップサーバ１０３にて受信されることで、ショップサーバ１０３は、利用者端末１０２に電子財布３０３がインストールされていることを確認できる。したがって、ショップサーバ１０３は、電子財布３０３が扱えるコンテンツの種類のデータとして支払を請求する請求データを送信する。また、ショップサーバ１０３が受信したＨＴＴＰサーバに電子財布の種類が含まれていれば、請求データを表すための適切なコンテンツの選択を行って、請求データを生成して、送信することもできる。
【００６０】
なお、ステップＳ８０５の後、ショップサーバ１０３から返信される情報は、請求データではなく、商品や役務の申込を行うためのウェブページの記述であってもよい。そして、このウェブページには、スクリプト言語や利用者端末１０２にインストールされている仮想マシンで実行するコードあるいは利用者端末１０２のネイティブコードなどで記述されたプログラムが含まれていてもよい。
【００６１】
そのプログラムは、まず、ブラウザ３０２がステップＳ８０５でのＨＴＴＰ要求によりアクセスしたＵＲＬのパラメータ部分を取得する。このＵＲＬのパラメータ部分は、ブラウザ３０２が、ＨＴＴＰ要求を行ったときに、利用者端末１０２のメモリに記憶したＵＲＬのパラメータ部分として得られる。例えば、ある種のスクリプト言語では、ｌｏｃａｌｔｉｏｎ．ｓｅａｒｃｈ属性を参照することにより、メモリより読み出すことが可能である。そして、そのプログラムは、ＵＲＬに含まれるパラメータの値を変数（あるいはレジスタ）に代入する。例えば、上述のように、確認サーバへ送信されるクッキー情報が確認されたかどうかが、確認サーバより受信されるリダイレクト命令によるアクセスするべきショップサーバへのＵＲＬに「＆ｅｗａｌｌｅｔ＝１」が含められるか、「＆ｅｗａｌｌｅｔ＝０」が含められるかで表される場合には、１あるいは０をその変数に代入する。なお、「＆ｅｗａｌｌｅｔ＝１」も「＆ｅｗａｌｌｅｔ＝０」も含められていなければ、その変数には０が代入されるとする。
【００６２】
そして、そのプログラムは、その変数の値を０または１と比較して、１と等しければ、商品や役務の種類などの選択、数量などの入力結果をショップサーバに送信するためのボタンなどを利用者端末１０２の画面に表示する。また、１と等しくなければ、電子財布をインストールするためのリンクを表示などする。
【００６３】
例えば、商品や役務の種類などの選択、数量などの入力結果をショップサーバに送信するためのボタンが押下されると、商品や役務の種類などの選択、数量などの入力結果がショップサーバ１０３に送信され、その返信として、請求データがブラウザ３０２により受信される。
【００６４】
ステップＳ８０６の処理として、ショップサーバ１０３より、請求データを受信する。
【００６５】
この請求データをブラウザ３０２が受信すると、コンテンツのタイプを参照し、そのコンテンツのタイプに電子財布３０３が関連付けられているので、ステップＳ８０４の処理として、電子財布３０３を起動し、請求データを電子財布３０３への入力などとして、読み込ませて処理をさせる。
【００６６】
なお、請求データには、利用者が支払うべき金額や利用者が履行するべき債権・債務に関する情報が含まれていてもよい。また、金額の支払先や債権・債務の相手方の情報が請求データに含まれていてもよい。例えば、管理データの送信先が請求データに含まれていてもよい。電子財布３０３は、電子財布３０３に設定された情報や請求データに含まれる情報から決済を行うための通信先を取得して、その通信先と通信を行い、決済などを行う。
【００６７】
（ショップサーバ）
図９は、ショップサーバの機能ブロック図の一例を示す。ショップサーバ１０３は、注文データ受信部９０１と、受注管理部０２と、ＵＲＬ転送部９０３と、請求データ発行部９０４とを有する。
【００６８】
注文データ受信部９０１（第１要求受信部）は、注文データを受信する。注文データは、上述したように利用者端末１０２より、ＨＴＴＰ要求の形式にて送信される。注文データ受信部９０１は、注文データを受信すると、その注文データより、商品番号と商品の個数など、支払われるべき金額を計算するために必要な情報である受注情報を抽出する。また、必要に応じて、商品などの配送先を抽出する。
【００６９】
受注管理部９０２は、受注を管理する。すなわち、注文データが注文データ受信部９０１により受信され、受注情報が抽出されると、まず、それを格納する。このとき、受注管理部９０２は、受注情報を一意に識別するための連番などを受注情報に付与する。付与された連番などは、ＵＲＬ転送部９０３に伝達されるようになっていてもよい。また、受注管理部９０２は、連番などが請求データ発行部９０４により指定されると、その連番などが付与された受注情報を読み出して返答する。
【００７０】
ＵＲＬ転送部９０３（返信部）は、注文データ受信部９０１により注文データが受信され、受注情報が抽出されて受注管理部９０２に格納されると、注文データを送信した利用者端末１０２に対して、確認サーバ１０４へのリダイレクト命令を返信する。このリダイレクト命令には、受注管理部９０２によって付与された連番などが含まれていてもよい。
【００７１】
なお、確認サーバ１０４へのリダイレクト命令により、利用者端末１０２がＨＴＴＰ要求を送信するためのＵＲＬは、例えば、ショップサーバ１０３がアクセスされたパスに応じて対応関係が定められていてもよい。図１０は、この対応関係を定めるためのテーブルの一例を示す。例えば、／ｓｈｏｐ１２３が利用者端末１０２からのＨＴＴＰ要求によりアクセスされた場合には、ＵＲＬ転送部９０３は、リダイレクト命令に、ｗｗｗ．ｆｏｏ．ｂａｒの／ｃｏｎｆ３４２をアクセスするためのＵＲＬを含める。また、このＵＲＬに、受注管理部９０２によって付与された連番などがパラメータとして付加されるようになっていてもよい。また、／ｄｏｗｎｌｏａｄ２３４が利用者端末１０２からのＨＴＴＰ要求によりアクセスされた場合には、ＵＲＬ転送部９０３は、リダイレクト命令に、ｗｗｗ．ｂａｚ．ｑｕｘの／ｋａｋｕｎｉｎ５７９をアクセスするためのＵＲＬを含める。これにより、ショップサーバ１０３が複数の店舗により共有されている場合、店舗ごとに扱う管理データが異なり、決済に用いる電子財布の種類が異なる場合に対応できる。
【００７２】
請求データ発行部９０４（第２要求受信部及び応答部）は、ＵＲＬ転送部９０３により返信されたリダイレクト命令に基づいて、利用者端末１０２から返信されるＨＴＴＰ要求を受信すると、受注管理部９０２より受注情報を読み出して、請求データを生成して返信する。すなわち、ＵＲＬ転送部９０３により返信されたリダイレクト命令に従って、利用者端末１０２は、（１）確認サーバへＨＴＴＰ要求を送信し、（２）その返信として受信されるリダイレクト命令に従って、ショップサーバ１０３に対してＨＴＴＰ要求を再度送信した場合に、受注管理部９０２より受注情報を読み出して、請求データを生成して返信する。読み出す受注情報は、例えば、利用者端末１０２より再度送信されたＨＴＴＰ要求に含まれる連番などを用いて特定されるようになっていてもよい。また、利用者端末１０２より再度送信されたＨＴＴＰ要求に電子財布の種類が含まれていれば、請求データを表すための適切なコンテンツの選択を行って請求データを生成する。
【００７３】
図１１と図１２は、ショップサーバ１０３における処理を説明するフローチャートである。
【００７４】
図１１は、利用者端末１０２における処理のうち図８のステップＳ８０１からＳ８０２までの処理に対応してショップサーバ１０３で行われる処理のフローチャートである。ステップＳ１１０１の処理として、利用者端末１０２より、注文データをＨＴＴＰ要求として受信する。そして、注文データ受信部９０１は、受注データを抽出する。
【００７５】
ステップＳ１１０２の処理として、ステップＳ１１０１において抽出された受注情報が受注管理部９０２により格納される。
【００７６】
ステップＳ１１０３の処理として、ＵＲＬ転送部９０３により、確認サーバ１０４へのリダイレクト命令を、ＨＴＴＰ応答して返信する。
【００７７】
図１２は、利用者端末１０２における処理のうち図８のステップＳ８０４からＳ８０６までの処理に対応してショップサーバ１０３で行われる処理のフローチャートである。ステップＳ１２０１の処理として、確認サーバ１０４からのリダイレクト命令により利用者端末１０２のブラウザ３０２から送信されたＨＴＴＰ要求を受信する。ステップＳ１２０２の処理として、請求データ発行部９０４により、対応する受注情報を読み出す。対応する受注情報とは、ステップＳ１２０１においてＨＴＴＰ要求が受信される原因となった、確認サーバへのリダイレクト命令が送信されるトリガーとして受信された受注情報である。対応する受注情報は、ステップＳ１２０１で受信されたＨＴＴＰ要求に含まれる連番などで特定することができる。ステップＳ１２０３の処理として、ステップＳ１２０２で読み出された受注情報に応じて請求データを生成して、利用者端末１０２へ送信する。
【００７８】
（確認サーバ）
図１３は、確認サーバ１０４で行われる処理を説明するフローチャートである。確認サーバ１０４は、ＨＴＴＰ要求を受信し、特定のパスがアクセスされた場合に、図１３の処理を行うウェブサーバとして構成される。例えば、確認サーバ１０４は、計算機にウェブサーバプログラムを動作させて実現される。
【００７９】
ステップＳ１３０１の処理において、ショップサーバ１０３から送信されたリダイレクト命令により利用者端末１０２のブラウザ３０２から送信されたＨＴＴＰ要求を受信する。ステップＳ１３０２の処理においては、ステップＳ１３０１においてＨＴＴＰ要求とともにクッキー情報が受信されたかどうか、また、そのクッキー情報の内容を確認する。確認がされれば、ステップＳ１３０３の処理において、ブラウザ３０２をショップサーバ１０３へリダイレクトさせる命令をＨＴＴＰ応答として返信する。上述したようにこのＨＴＴＰ応答には、ステップＳ１３０１で受信されたＨＴＴＰ要求に含まれる連番などを含ませる。また、ＨＴＴＰ要求とともに受信されたクッキー情報から電子財布の種類が決定される場合には、その種類をそのＨＴＴＰ応答に含ませてもよい。
【００８０】
もし、利用者端末１０２のブラウザ３０２から送信されたＨＴＴＰ要求とともにクッキー情報が受信されなかったことが確認されていなかったり、クッキー情報の内容が正しいものとして確認できなかったりすれば、確認サーバ１０４は、エラーを返信してもよい。また、エラーの代わりに、電子財布のインストールを勧める内容のＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）情報を返信してもよい。また、上述したように、クッキー情報の内容が正しいものとして確認できたかどうかを、ＨＴＴＰ応答に含めてもよい。例えば、確認ができた場合には、ＨＴＴＰ応答に含められるショップサーバ１０３へリダイレクトさせる命令のＵＲＬにパラメータとして「＆ｅｗａｌｌｅｔ＝１」を含め、そうでなければ「＆ｅｗａｌｌｅｔ＝０」を含める。
【００８１】
（全体の流れ）
図１４は、電子商取引システム１００の全体の処理を説明するシーケンス図である。ステップＳ１４０１の処理として、注文データが利用者端末１０２のブラウザ３０２からショップサーバ１０３へ送信される。これは、図８におけるステップＳ８０１、図１１におけるステップＳ１１０１に相当する。ステップＳ１４０２の処理として、ショップサーバ１０３から確認サーバ１０４へのリダイレクト命令が送信される。これは、図１１におけるステップＳ１１０３、図８におけるステップＳ８０２に相当する。ステップＳ１４０３の処理として、利用者端末１０２のブラウザ３０２から、ＨＴＴＰ要求とクッキー情報が確認サーバに送信される。これは、図８におけるＳ８０３、図１３におけるＳ１３０１に相当する。ステップＳ１４０４の処理として、確認サーバ１０４は、ショップサーバ１０３へのリダイレクト命令を返信する。これは、図１３におけるＳ１３０３、図８におけるＳ８０４に相当する。ステップＳ１４０５の処理として、利用者端末１０２のブラウザ３０２からＨＴＴＰ要求がショップサーバ１０３へ送信される。これは、図８のＳ８０５と、図１２のＳ１２０１に相当する。ステップＳ１４０６の処理として、ショップサーバから請求データが返信される。これは、図１２におけるステップＳ１２０３、ステップＳ８０６に相当する。ステップＳ１４０７の処理として、利用者端末１０２のブラウザ３０２は、電子財布３０３を起動し、請求データを処理させる。これは、図８のステップＳ８０７に相当する。
【００８２】
ステップＳ１４０７以降は、電子財布３０３により処理がされる。例えば、請求データにより請求された金額の支払の決済処理が行われる。
【００８３】
（主な効果）
本実施形態においては、利用者端末に電子財布がインストールされていることを、確認サーバに対するＨＴＴＰ要求とともに送信されるクッキー情報によって表すことにより、ショップサーバが利用者端末に電子財布がインストールされていることを確認することができる。
【００８４】
また、利用者端末において請求データのコンテンツのタイプと電子財布とが関連付けられていることにより、請求データに応じて決済処理を行う際には、自動的に電子財布が起動することになるので、利用者端末の利用者は簡便に電子決済を行うことができる。例えば、従来のように銀行振込のために銀行のホームページにアクセスをして口座番号、振込金額を入力する手間よりも少ない手間で決済を行うことができる。
【００８５】
上述の実施形態においては、注文データをショップサーバが受信する際に、利用者端末に電子財布がインストールされていることを確認することを主に説明した。しかし、本発明はこれに限定されるものではなく、利用者がショッピングのためのホームページをアクセスする際に、利用者端末に電子財布がインストールされていることを確認することも可能である。
【００８６】
上述の実施形態においては、電子財布をプログラムの例とし、請求データをコンテンツの例として扱ったが、本発明は、電子財布、請求データに限定されるものではない。
【００８７】
例えば、上述の実施形態において、利用者端末にインストールされているプログラムごとに、確認サーバへ送信されるクッキー情報をクッキー情報管理部４０１に格納しておく。そして、ステップＳ１４０１にて、注文データのかわりに、ブラウザからショップサーバというサーバに対して、音楽情報、動画情報、文書情報などの種々のコンテンツのダウンロードの要求が送信されてもよい。すると、ステップＳ１４０３にて、ブラウザから確認サーバへ利用者端末にインストールされているプログラムを表すクッキー情報が送信され、ステップＳ１４０４にて、確認サーバからブラウザに返信されるリダイレクト命令のＵＲＬに、利用者端末にインストールされているプログラムをパラメータなどして含めることができる。すると、ステップＳ１４０５にて、ショップサーバは、利用者端末にインストールされているプログラムを知ることができ、ステップＳ１４０６において、請求データのかわりに、ショップサーバというサーバは、利用者端末にインストールされているプログラムが扱える形式の情報を送信することができる。
【００８８】
（実施形態２）
本発明の実施形態２として、電子財布による処理などについて詳細に説明を行う。
【００８９】
まず、管理サーバについて説明を行う。本実施形態において、管理サーバとは、電子的な価値情報の譲渡処理を主に行うサーバ装置である。管理サーバが行うその他の処理としては、管理サーバとして必須の処理ではないが、電子的な価値情報の発行処理、発行した電子マネー等に関連付けられた価値を貨幣などとして払い戻す処理などがある。
【００９０】
図１５は、本発明の一実施形態に係る管理サーバの機能ブロック図を例示する。管理サーバ１５００は、データベース部１５０１と、発行要求受信部１５０２と、生成部１５０３と、生成管理データ送信部１５０４と、管理データ受信部１５０５と、置換部１５０６と、置換管理データ送信部１５０７とを有する。なお、管理サーバ１５００の実現の一態様としては、上述したように計算機を用いることができる。
【００９１】
データベース部１５０１は、電子的な価値情報と価値との関連付けを管理する。また、照合用データと関連付けることができる他の情報としては、例えば、その照合用データを含む管理データの譲渡が行われた回数（譲渡回数）、その照合用データを含む管理データが、どの利用者やどの利用者の端末装置などに対して発行されたかを示す利用者や端末装置などの識別情報などが挙げられ、これらは必要に応じてデータベース部１５０１に格納されてもよい。
【００９２】
本発明の一実施形態においては、図１６（ａ）に示すように、照合用データが格納される列と価値の情報が格納される列とを有し、照合用データと価値の情報とを関連付けるテーブルを用意する。このテーブルは、関係データベースシステムなどの表データとしてデータベース部１５０１によって管理される。なお、価値の情報を単に「価値情報」という場合がある。
【００９３】
照合用データは、充分に長いビット長の乱数として生成されるデータである。「充分に長い」とは、発行される管理データの中で同じ照合用データを有するものが存在しない、あるいは、実質的に存在しないことを意味する。例えば、１２８ビット、５１２ビット、１０２４ビット、２０４８ビットなど設計上などの必要に応じて任意の長さを決めることができる。
【００９４】
価値情報は、照合用データを含む管理データが表すことになる価値の内容などを示す。具体的な例としては、貨幣により表される価値を示す。この場合、価値の単位は、円、ドル、ユーロ、元などである。また、価値の情報は、貨幣と同等の価値を有する有価証券の証券番号、貴金属の量や保管の番号などであってもよい。
【００９５】
発行要求受信部１５０２は、管理データ発行要求１５０８を受信する。管理データ発行要求１５０８は、なんらかの価値が管理サーバやその運営者などに移転されたことあるいは移転されることを示す情報である。このため、管理データ発行要求１５０８は、管理サーバ１５００の運営者の支配する領域の内部で生成されたり、運営者と特別な関係（例えば親会社子会社の関係や特別な契約関係）にある者から送信されたりするのが好ましい。
【００９６】
図１６（ｂ）は、管理データ発行要求の具体的な例を示す。この例では、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）による表現がされている。管理データ発行要求はＸＭＬ以外にも種々の表現形式があるが、以下では、ＸＭＬを例にして説明を行う。図１６（ｂ）では、＜価値＞と＜／価値＞とで囲まれている１０００円が、発行される管理データが表すべき価値となっている。発行要求受信部１５０２が、このような管理データ発行要求を受信する際には、管理データ発行要求の送信者の認証を行い、受信した管理データ発行要求をメモリに展開して正しい構文であるかどうかの確認を行い、＜価値＞と＜／価値＞とで囲まれている部分を特定して、次に説明する生成部１５０３に伝達する。伝達は、例えば、生成部１５０３を実現するソフトウェアモジュールなどの関数の引数に＜価値＞と＜／価値＞とで囲まれている部分のメモリアドレスを価値の情報として引数に指定するなどしてその関数を呼び出すことで行われる。
【００９７】
なお、管理データ発行要求には、照合用データと関連付けることができる他の情報が必要に応じて含まれていてもよい。
【００９８】
生成部１５０３は、照合用データを準備し、準備された照合用データと発行要求受信部１５０２から伝達された価値の情報とを、データベース部１５０１で管理される図１６（ａ）のテーブルに行データとして挿入する。「照合用データを準備する」とは、乱数を生成してその乱数を照合用データとすること、又は、予め生成しておいた乱数のリストなどから乱数を選択して照合用データとすることをいう。挿入が完了すると、生成部１５０３は、生成管理データ送信部１５０４へ、照合用データを伝達する。なお価値の情報も伝達されてもよい。
【００９９】
図１６（ｃ）は、照合用データとして"１３５７１１"が準備されて、"１３５７１１"と１０００円とを図１６（ａ）に示されるテーブルに挿入した直後の状態を示している。挿入が行われると、"１３５７１１"という照合用データが生成管理データ送信部１５０４へ伝達される。
【０１００】
生成管理データ送信部１５０４は、生成部１５０３から伝達された照合用データから管理データ１５０９を生成して送信する。管理データ１５０９の送信先は、管理データ発行要求１５０８を送信した装置であることが主に想定される。もし、管理データ発行要求１５０８に、管理データ１５０９の送信先が、電子メールアドレスやＩＰアドレスなどによって指定されていれば、その送信先へ管理データ１５０９が送信される。送信は暗号化されて行われてもよい。
【０１０１】
図１６（ｄ）は、生成管理データ送信部１５０４で生成され送信される管理データの一例を示す。生成部１５０３から照合用データとして"１３５７１１"が伝達されたとすれば、"＜管理データ＞＜照合用データ＞１３５７１１＜／照合用データ＞＜／管理データ＞"という管理データが生成され、インターネットなどのネットワークなどに送信される。なお管理データには、照合用データ以外のデータが含まれていてもよい。例えば、照合用データがどれだけの価値、例えばいくらの貨幣価値、に関連付けられているかを示す情報が含まれていてもよい。例えば、管理データが"＜管理データ＞＜照合用データ＞１３５７１１＜／照合用データ＞＜価値＞１０００円＜／価値＞＜／管理データ＞"のように貨幣価値などを含むようになっていてもよい。また、照合用データと関連付けることができる他の情報が含まれていてもよい。また、譲渡回数が管理データに含まれる場合には、０などの初期値にリセットが行われて送信がされる。さらに、管理データが管理サーバ１５００により生成されたことを検証できるようにするために、照合用データなどに対する管理サーバ１５００による署名データが含まれていてもよい。
【０１０２】
なお、価値として、貨幣価値のように可分な価値が用いられる場合には、管理データが表す価値に上限を設けてもよい。例えば、一つの管理データは、５０００円までの貨幣価値を表すことにする。そして、５０００円以上の価値を表す管理データは、複数の管理データを組み合わせることによって表す。このように管理データが表す価値に上限を設けることにより、管理データを紛失したときに生じる損失が大きくならないようにすることができる。
【０１０３】
管理データが表す価値に上限を設ける場合には、管理データ発行要求がその上限を越える価値の管理データを発行することを表している場合には、上限以下の価値を表す管理データを複数発行する。このため、図１６（ａ）などに示すテーブルに複数の行データが挿入される。
【０１０４】
図１７は、データベース部１５０１、発行要求受信部１５０２、生成部１５０３、生成管理データ送信部１５０４による処理の流れを説明するフローチャートを例示する。このフローチャートが例示する処理は、ハードウェアを制御可能なソフトウェアによる情報処理として実行可能である。
【０１０５】
ステップＳ１７０１の処理として、発行要求受信部１５０２により管理データ発行要求を受信する。例えば、ハードウェアとしてのネットワークアダプタがデータを受信し割り込みが発生すると、割り込みハンドラが呼ばれて、データを読取り、読取りデータキューに入れる。そして、発行要求受信部１５０２を実現するモジュールなどが発行していたＲＥＡＤシステムコールなどから処理が戻り、読取りデータキューに入れられたデータを管理データ発行要求としてメモリに展開する。
【０１０６】
ステップＳ１７０２の処理として、発行要求受信部１５０２は、メモリに展開された管理データ発行要求から価値の情報のアドレスを特定などすることにより、価値の情報を取得する。取得された価値の情報は生成部１５０３へ伝達される。
【０１０７】
ステップＳ１７０３の処理として、生成部１５０３が照合用データを準備する。そしてステップＳ１７０４の処理として、生成部１５０３は、準備した照合用データと伝達された価値の情報を関連付けてテーブルに挿入して格納する。照合用データは生成管理データ送信部１５０４へ伝達される。
【０１０８】
ステップＳ１７０５の処理として、生成管理データ送信部１５０４は、伝達された照合用データから管理データを生成する。そして、ステップＳ１７０６の処理として、ＷＲＩＴＥシステムコールなどを発行することにより、生成された管理データを送信する。ＷＲＩＴＥシステムコールなどの発行により、管理データが送信データキューに格納され、ネットワークアダプタがデータを送信可能な状態になると、割り込みが発生し、割り込みハンドラにより、送信データキューのデータが読み出されて、ネットワークなどに送信される。
【０１０９】
このようにして送信された管理データは、専用のＩＣカードなどに限らず、通常のパーソナルコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）や携帯電話などのメモリに格納することができる。また、フレキシブルディスク、光ディスク、不揮発性の半導体メモリなどの着脱可能な一般的な記憶媒体に記録することができる。そして、その記憶媒体を譲渡することにより、その記憶媒体に格納されている管理データが表す価値の譲渡を行うことができる。ただし、二重の譲渡を防止するために以下に説明するようにして譲渡するのが望ましい。
【０１１０】
管理データ受信部１５０５は、譲渡の対象などとなる管理データ１５１０を受信する。受信された管理データ１５１０は、管理サーバ１５００のメモリに展開される。そして、管理データ１５１０に署名データなどが含まれていれば、その署名データが正しいかどうかを判断してもよい。
【０１１１】
置換部１５０６は、管理データ受信部１５０５で受信された管理データから照合用データを取得し、まず、その照合用データがデータベース部１５０１で管理されているテーブルに格納されているかどうかを判断する。例えば、図１６（ｃ）に示されるテーブルの照合用データの列に格納されているかどうかを判断する。もし、その照合用データが格納されていなければ、管理データ１５１０の送信者などに、無効な照合用データを含む管理データが送信された旨を返信などする。反対に、その照合用データがデータベース部１５０１で管理されているテーブルに格納されていれば、有効な照合用データを含む管理データであると判断する。有効な照合用データを含めば、新たな照合用データを準備し、この照合用データにより、管理データ１５１０に含まれる照合用データとデータベース部１５０１で管理されているテーブルに格納されている照合用データを置き換える。これにより、価値の情報に新たな照合用データが関連付けされる。
【０１１２】
また、照合用データと関連付けられている他の情報があれば、その情報を用いてさらにチェックを行ってもよい。例えば、識別情報が照合用データと関連付けられていれば、管理データを管理データ受信部１５０５に受信させた利用者や端末装置の識別情報を取得し、比較を行う。比較の結果がＯＫでなければ、無効である旨の返信などを行う。比較の結果がＯＫであれば、照合用データと関連付けられている識別情報と管理データに含まれている識別情報を、次に説明する置換管理データ送信部１５０７による管理データの送信先となる利用者や端末装置の識別情報に書き換える。
【０１１３】
管理データに譲渡回数が含まれている場合には、譲渡回数を更新する。また、更新前の譲渡回数が初期値を示していれば、置き換え前の照合用データがデータベース部１５０１で管理されているテーブルに格納されているかどうかに加えて、照合用データと関連付けられている他の情報を用いたチェックを行ってもよい。例えば、その管理データを発行した際に受信された管理データ発行要求が存在するかどうかを管理サーバのログによりチェックを行ったり、実際に銀行などから金銭の振り込みが実際に行われたかどうかを銀行などのサーバ装置に問い合せたりしてもよい。もちろん、このようなチェックや問い合わせの処理は、管理データが管理サーバ１５００に受信されるたびに行ってもよい。しかし、一般には、このようなチェックや問い合せの処理には時間が要する。そこで、このようなチェックや問い合せの処理の実行は、更新前の譲渡回数が初期値を示していたり、所定の値以下であったり、所定の値以上である場合に行うことに限ることで、処理の時間を短縮することが可能となる。また、異なるサーバに格納されたデータと照合を行うことにより、管理データの不正な作出などを検出することができる。
【０１１４】
置換管理データ送信部１５０７は、置換部１５０６により、新たに準備された照合用データによりその照合用データが置換された管理データ１５１１を送信する。管理データ１５１１の送信は、管理データ１５１０の送信元に対して行ってもよい。あるいは管理データ１５１０の受信とともに送信先を示す情報が受信されたり、あるいは、管理データ１５１０の中に送信先を示す情報が含まれていたりすれば、その送信先へ管理データ１５１１を送信するようになっていてもよい。
【０１１５】
例えば、データベース部１５０１で管理されているテーブルに、図１８（ａ）に示すように、照合用データとして"１３１７１９２"が９９５円という価値の情報と関連付けられて格納されているとする。この状態で、管理データ１１０として、図１８（ｂ）に示すような照合用データとして"１３１７１９２"を含む管理データ１５１０が管理データ受信部１５０５により受信されたとする。すると、管理データ１５１０に含まれる照合用データ"１３１７１９２"は、図１８（ａ）のテーブルに格納されているので、管理データ１５１０は有効な照合用データを含む管理データであると判断される。そこで、置換部は、新たな照合用データとして、例えば"１４９１６２５"を準備する。そして、この照合用データにより、図１８（ａ）に示すテーブルの照合用データ"１３１７１９２"と図１８（ｂ）に示す管理データに含まれる照合用データ"１３１７１９２"とを置き換える。この結果、図１８（ａ）に示すテーブルは図１８（ｃ）に示すようになり、図１８（ｂ）に示す管理データ１１０は図１８（ｄ）に示すようになる。この結果、図１８（ｄ）に示す管理データが管理データ１５１１として送信される。
【０１１６】
なお、照合用データを置き換える際に、照合用データに関連付けられている価値情報の表す金額などのうち一定の額や一定の割合を控除するようにしてもよい。このように控除を行うことにより、管理サーバの運営者が管理サーバの運営などのための費用を得ることが可能となる。
【０１１７】
なお、図１８（ａ）に示すテーブルの照合用データの書き換えは、照合用データの列に格納されているデータに対する更新操作として実行してもよい。あるいは、書き換えの対象となる照合用データ（上の例での"１３１７１９２"）に関連付けられている価値の情報などを読出して一時的に記憶し、書き換えの対象となる照合用データを含む行を削除し、新たに準備された照合用データ（上の例での"１４９１６２５"）と一時的に記憶した価値の情報などを新たな行のデータとして格納されるようにテーブルに対するデータの挿入の操作として実行してもよい。また、更新操作として実行するのではなく、照合用データが削除されたことを示す列（削除フラグ）をテーブルに備えておき、書き換えの対象となる照合用データを格納する行の削除フラグの値を、その行が削除されたことを示す値に更新するとともに、準備された照合用データを含む行を新たにテーブルに挿入してもよい。また、テーブルに挿入される行には、書き換え前の照合用データが格納されていてもよい。これにより、不正などが発覚した場合に、書き換えの履歴をさかのぼることができる。
【０１１８】
また、管理データの照合用データの書き換えは、その文言通り、メモリに展開されている管理データの部分のうち照合用データの部分を書き換えて実行してもよい。あるいは、新たに準備された照合用データを含む管理データを新たに生成してもよい。
【０１１９】
図１８（ｄ）に示す管理データが置換管理データ送信部１５０７により送信された後、再度、図１８（ｂ）に示す管理データが管理データ受信部１５０５で受信されても、それに含まれる照合用データ１３１７１９２は、図１８（ｃ）に示すテーブルに格納されていない（あるいは、削除フラグの列がテーブルに備わっている場合には、削除フラグの値が削除されたことを示す値になっている）。したがって、無効な照合用データを含む管理データと判断される。これにより管理データの二重使用を防止できる。
【０１２０】
図１９は、データベース部１５０１、管理データ受信部１５０５、置換部１５０６、置換管理データ送信部１５０７における処理の流れを説明するフローチャートを例示する。このフローチャートが例示する処理は、ソフトウェアによる情報処理として実現可能である（他の図面のフローチャート、シーケンス図により例示される処理も同様である。）。
【０１２１】
ステップＳ１９０１の処理として、管理データ受信部１５０５により、管理データ１５１０が受信される。その後、管理データ１５１０がメモリに展開などされる。そして、ステップＳ１９０２の処理として、置換部１５０６により、メモリに展開された管理データ１５１０より照合用データが取得される。取得された照合用データが、ステップＳ１９０３の処理において、価値の情報と関連付けてデータベース部１５０１に格納されていることを確認する。もし、格納されていなければ、管理データ１５１０に無効な照合用データが含まれている旨のエラーの返信などをする。
【０１２２】
ステップＳ１９０４の処理として、新しい照合用データを準備する。そしてステップＳ１９０５の処理として、管理データ１５１０の照合用データを新しい照合用データに置き換える。「管理データ１５１０の照合用データ」とは、メモリに展開された管理データ１５１０に含まれる照合用データのみならず、ステップＳ１９０３において価値のデータと関連付けて格納されている照合用データをも意味する。最後にステップＳ１９０６の処理として、照合用データを書き換えられて得られる管理データ１５１１を置換管理データ送信部１５０７により送信する。
【０１２３】
このように、乱数として発生された照合用データに価値を関連付け、管理データが通過するたびにその照合用データを置き換えることにより、管理サーバから送信される管理データの照合用データの予測がつかないようにすることができる。この結果、異なる照合用データに同じ価値が関連付けられることを防止でき、また、管理データの二重使用等を防止することができる。
【０１２４】
（保管サーバ）
次に、保管データについて説明を行う。上述した管理サーバを用いることにより、乱数として発生された照合用データを含む管理データが発行され、有効な照合用データを含む管理データを送信し返信される管理データを受信することにより照合用データが書き換えられる。これにより、管理データの二重使用を防止することができる。以下では、さらに管理データの譲渡等を、匿名性を保ちながら行うために管理サーバの機能を拡張するためなどに用いられる保管サーバについて説明を行う。
【０１２５】
図２０は、管理サーバ２００１と、決済サーバ２００２と、保管サーバ２００３と、利用者端末２００４とからなるシステム２０００の構成を示す。管理サーバ２００１と、決済サーバ２００２と、保管サーバ２００３と、利用者端末２００４とは、通信アダプタなどのハードウェアを用いて通信が可能となっている。システム２０００においては、利用者端末２００４の利用者が、管理サーバ２００１で発行される管理データを得るために、利用者端末２００４と決済サーバ２００２との間で決済の処理を行う。例えば、決済サーバ２００２が銀行の振り込みを処理するサーバとなっており、利用者が管理サーバ２００１の運営者などの銀行口座に振り込みを行うことにより決済の処理が行われる。そして決済の処理が行われたことを示す結果が管理データ発行要求として決済サーバ２００２から管理サーバ２００１に送信されると、管理データが管理サーバ２００１に返信される。その後、管理データは決済サーバ２００２から保管サーバ２００３を経由して利用者端末２００４へ譲渡される。利用者端末２００４には電子財布がインストールされており、管理データは、電子財布により管理されることになる。保管サーバ２００３は、管理データを決済サーバ２００２から受信すると、管理データの二重使用を防止するために、新たな照合用データに置き換えるために、管理サーバ２００１に管理データを送信し、照合用データが置き換えられた管理データを受信し保管する。その後、保管サーバ２００３は、利用者端末２００４から管理データの要求があれば、保管されている管理データを送信する。
【０１２６】
もちろん、保管サーバ２００３が決済サーバ２００２を認証などして信頼できるのであれば、保管サーバ２００３は決済サーバ２００２から受信した管理データを管理サーバ２００１に送信する必要はない。しかし、もし保管サーバ２００３に送信された管理データが決済サーバ２００２内に消去されずに残り、決済サーバ２００２が不正な侵入などされてしまうと、不正に決済サーバ２００２にアクセスを行った者が管理データを入手してしまう可能性があるので、保管サーバ２００３は決済サーバ２００２から受信した管理データを管理サーバ２００１に送信するのが好ましいと言える。
【０１２７】
図２１は、システム２０００における決済処理から管理データの利用者への譲渡までの処理の一例を説明するシーケンス図である。
【０１２８】
ステップＳ２１０１の処理として、利用者端末２００４と決済サーバ２００２との間で、管理データの発行のための決済の処理が行われる。例えば、利用者端末２００４よりクレジットカード番号等と決済金額を提示して、決済サーバ２００２がクレジットカード番号等の正しさを確認等する。あるいは、利用者端末２００４より銀行口座への振り込みの申込を行い、決済サーバ２００２が振込先の銀行口座番号や振込人に付加する識別文字列などを返信する。その後、振込が行われたことについての確認を決済サーバ２００２側にて行う。なお、決済処理により、利用者端末２００４から決済サーバ２００２へ利用者や利用者端末２００４の識別情報が決済サーバに伝達されてもよい。この場合、識別情報は、後に決済サーバ２００２から管理サーバ２００１へ送信される管理データ発行要求の中に含まれる。
【０１２９】
本発明の一実施形態において、ステップＳ２１０１の処理における決済処理を特定する番号などが決定され、この番号が決済サーバと利用者端末とで共有される。決済処理を特定する番号は、例えば、決済サーバが、生成する管理データを一意に識別する番号であったり、利用者端末２００４と決済サーバ２００２との間の通信のセッションを特定するセッションＩＤ（セッションを一意に特定するセッション識別情報）であったりしてもよい。この決済処理を特定する番号は、乱数として管理サーバが生成するのが好ましい。以下、決済処理を特定する番号として、セッションＩＤが用いられるとして説明を行う。ただし、本発明では、決済処理を特定する番号はセッションＩＤに限定されない。また、決済処理を特定する番号をＩＤ情報と称する場合がある。
【０１３０】
クレジットカード番号等の正しさや振込等の確認がされると、ステップＳ２１０２の処理として、決済サーバ２００２から管理サーバ２００１へ管理データ発行要求が送信される。この管理データ発行要求の中に、決済された金額などの情報が含まれる。なお、「決済された金額」は、利用者端末２００４と決済サーバ２００２との間での決済金額から所定の手数料を差し引いた額であってもよい。
【０１３１】
管理データの発行要求に応じて、ステップＳ２１０３の処理として、管理サーバ２００１から管理データ（「管理データ１」と呼ぶ）が決済サーバ２００２へ送信される。
【０１３２】
ステップＳ２１０４の処理として、決済サーバ２００２は、受信した管理データ１と上述のセッションＩＤとを保管サーバ２００３に送信する。
【０１３３】
保管サーバ２００３が決済サーバより管理データ１とセッションＩＤを受信すると、ステップＳ２１０５の処理として、受信した管理データを管理サーバ２００１へ送信し、管理データ１に有効な照合用データが含まれていることの確認と、その照合用データの置き換えを管理サーバ２００１に依頼する。
【０１３４】
なお、管理サーバ２００１は、保管サーバ２００３より照合用データの書き換えが依頼された場合、譲渡回数は増加させない構成になっており、また、照合用データと関連付けられている識別情報と管理データに含まれている識別情報を書き換えない構成となっているとよい。例えば、保管サーバ２００３のＩＰアドレスが管理サーバ２００１に登録されており、登録されているＩＰアドレスから管理データを受信した場合には、譲渡回数を増加させず、識別情報も書き換えない構成となっていてもよい。
【０１３５】
ステップＳ２１０６の処理として、管理サーバ２００１にて、管理データ１に有効な照合用データが含まれていることを確認して照合用データを書き換えた管理データ２を生成し、保管サーバ２００３に返信される。そして、保管サーバ２００３にて、その管理データ２がセッションＩＤに関連付けて記憶される。
【０１３６】
管理データ２がセッションＩＤに関連付けて記憶されたことを通知するために、ステップＳ２１０７の処理として、保管通知が保管サーバ２００３から決済サーバ２００２へ送信される。
【０１３７】
決済サーバ２００２が保管通知を受信すると、ステップＳ２１０８の処理として、利用者端末２００４へ寄託通知が送信され、管理データが保管サーバ２００３に保管されたことが利用者に伝えられる。寄託通知は電子メールによって送信されてもよい。あるいは利用者端末２００４にインストールされたブラウザへ送信されてもよい。そして、寄託通知のコンテンツの種類が電子財布に関連付けられており、利用者が電子メールに添付された寄託通知をダブルクリックしたり、ブラウザが寄託通知を受信したりすると、電子財布が電子メールプログラムやブラウザにより起動され、寄託通知が電子財布により処理されるようになっていることが好ましい。
【０１３８】
その後、利用者は、利用者端末２００４にインストールされた電子財布を操作するなどして、保管サーバ２００３に保管された管理データを要求するために、ステップＳ２１０９の処理として、保管サーバ２００３に対して、管理データの送信要求として、セッションＩＤを送信する。保管サーバ２００３では、セッションＩＤに管理データ２が関連付けて記憶されていることを確認すると、ステップＳ２１１０の処理として、管理データ２を返信し、セッションＩＤとの関連付けを破棄する。
【０１３９】
もちろん、図２０と図２１とに示される構成、処理などを用いなくても、管理データを利用者に発行することができる。例えば、決済サーバが管理サーバから管理データを受信し、直接その管理データを利用者端末へ送信するようにしてもよい。しかし、決済手段として銀行振込を採用した場合などには、決済の確認までタイムラグが生じるので、決済サーバは管理サーバから受信した管理データを次に利用者端末と通信可能になるまで保持しておく必要がある。しかしこれでは、どの管理データが誰に発行されたかの情報を決済サーバが知ることとなり、匿名性が損なわれる。
【０１４０】
また、決済サーバが管理データの発行要求とともに管理データの送信先を管理サーバに送信し、管理サーバがその送信先に発行した管理データを送信する構成を採用することもできる。しかし、これでも、管理データが誰に発行されたかの情報を管理サーバが知ることとなり、やはり匿名性が損なわれる。
【０１４１】
図２０と図２１とに示される構成、処理では、管理サーバ２００１は、どの利用者の利用者端末に対して管理データを発行して送信するか知る必要がなくなる。また、決済サーバ２００２は利用者端末２００４と管理サーバ２００１から送信される管理データを関連付けることはできるが、それは一時的なものに過ぎない。管理データを保管サーバ２００３に送信すると、保管サーバ２００３側で照合用データが書き換えられてしまうからである。また、保管サーバ２００３は、管理データを決済サーバ２００２と利用者端末２００４との通信セッションにより決まる情報と関連付けるので、利用者を識別する必要がない。
【０１４２】
図２２は、保管サーバ２００３の機能ブロック図を示す。図２２の機能ブロック図において、保管サーバ２２００は、預管理データ受信部２２０１と、管理データ送信部２２０２と、管理データ受信部２２０３と、保管部２２０４と、ＩＤ受信部２２０５と、預管理データ送信部２２０６とを有する。
【０１４３】
預管理データ受信部２２０１は、管理データ２２０７とＩＤ２２０８とを受信する。管理データ２２０７とＩＤ２２０８とは、図２１のステップＳ２１０４においての説明での決済サーバから保管サーバへ送信される管理データ１とセッションＩＤとに相当する。ただし、後に説明されるように、預管理データ受信部２２０１は、管理データ２２０７とＩＤ２２０８を決済サーバのみより受信するとは限らない。
【０１４４】
ＩＤ２２０８は、管理データ２２０７を一意に特定する情報であることが望ましい。このため、預管理データ受信部２２０１は、受信したＩＤの履歴を管理し、過去に受信したＩＤと一致するものを受信した場合には、ＩＤの再送要求を返信してもよい。また、受信したＩＤの履歴は、後に説明される保管部８０４が管理するテーブルなどで管理することもできる。すなわち、保管部２２０４が管理するテーブルに同じＩＤが格納されていればＩＤの再送要求を返信してもよい。
【０１４５】
預管理データ受信部２２０１は、受信した管理データ２２０７とＩＤ２２０８とをメモリに展開する。そして、管理データ２２０７のメモリアドレスなどを管理データ送信部２２０２へ渡すことにより管理データ２２０７を伝達し、ＩＤ２２０８のメモリアドレスを保管部２２０４へ渡すことによりＩＤ２２０８を伝達する。
【０１４６】
管理データ送信部２２０２は、預管理データ受信部２２０１より伝達された管理データ２２０７を送信する。送信先は、管理サーバである。送信の結果、管理サーバにて管理データ２２０７に含まれる照合用データの有効性が確認されると、照合用データの書き換えが行われ、書き換え後の管理データ２２０９が返信される。
【０１４７】
管理データ受信部２２０３は、管理データ送信部２２０２からの管理データ２２０７の送信に応じて管理サーバより返信される管理データ２２０９を受信する。上述したように管理データ２２０７の少なくとも照合用データが置き換えられたものが管理データ２２０９となっている。管理データ受信部２２０３は、受信した管理データ２２０９をメモリに展開し、そのメモリアドレスなどを保管部２２０４に渡すことにより、管理データ２２０９を伝達する。
【０１４８】
保管部２２０４は、預管理データ受信部２２０１より伝達されたＩＤ２２０８と管理データ受信部２２０３より伝達された管理データ２２０９とを関連付けて保持する。ＩＤ２２０８と管理データ２２０９とは、異なる時に保管部２２０４に伝達される。このために、保管サーバ２２００は、例えば預管理データ受信部２２０１が受信した管理データ２２０７とＩＤ２２０８とに一意の識別情報を付与するようにしてもよい。そして、預管理データ受信部はＩＤ２２０８とともにその一意の識別情報を保管部２２０４に伝達する。また、管理データ送信部２２０２が管理データ２２０７を送信するために管理サーバと通信セッションを開始するとその通信セッションをその一意の識別情報と関連付ける。そして、管理データ２２０９が受信されると、通信セッションから一意の識別情報を取得し、管理データ受信部２２０３は、管理データ２２０９とともにその一意の識別情報を保管部２２０４に伝達する。これにより、保管部２２０４では、ＩＤ２２０８と管理データ２２０９とを関連付けることができる。また、保管サーバ２２００が付与した一意の識別情報が管理データ２２０７に含まれて送信されるようになっていてもよい。管理サーバは、その一意の識別情報を変更することなく、照合用データを書き換える。
【０１４９】
保管部２２０４は、ＩＤと管理データとを関連付けて保管するためにテーブルを用いてもよい。図２３はそのようなテーブルを示している。図２３では、"ｅ９８７ａｂｃ"というＩＤと照合用データとして"１４９１６２５"を含む管理データとが関連付けて保持されている。"ｅ９８７ａｂｃ"というＩＤは、例えば図２１におけるステップＳ２１０１の処理として行われる決済処理のための利用者端末と決済サーバと間の通信セッションのＩＤなどである。
【０１５０】
なお、保管部２２０４にＩＤ２２０８と管理データ２２０９とが関連付けて格納された場合、ステップＳ２１０７の保管通知となる情報が送信されるようになっていてもよい。この保管通知は、例えば、預管理データ受信部２２０１が管理データ２２０７とＩＤ２２０８とを受信したＡＣＫとして返信されるようになっていてもよい。
【０１５１】
ＩＤ受信部２２０５は、ＩＤ２２１０を受信し、ＩＤ２２１０と保管部２２０４にて関連づけて保管されている管理データの検索を行う。検索の結果、ＩＤ２２１０と関連付けて保管されている管理データが存在すれば、ＩＤ受信部２２０５はその管理データを読出し、預管理データ送信部２２０６へ伝達する。また、ＩＤ２２１０とその管理データとの関連付けを解消あるいは破棄する。解消あるいは破棄は、具体的には、図２３に示すテーブルからＩＤ２２１０が格納されている行データを削除することにより実現される。あるいは、図２３に示すテーブルに削除フラグを格納する列を設けて、削除されたことを示す値を格納することで、解消あるいは破棄されたことを表現するようになっていてもよい。
【０１５２】
預管理データ送信部２２０６は、ＩＤ受信部２２０５から伝達された管理データを送信する。管理データの送信先は、ＩＤ２２１０の送信元であることが想定される。ただし、管理データの送信先がＩＤ２２１０とともにＩＤ受信部２２０５により受信されたなどの場合には、その送信先へ管理データを送信するようになっていてもよい。
【０１５３】
図２４は、保管サーバ２２００における管理データとＩＤとを受信し保管するまでの処理の流れを説明するフローチャートの一例である。ステップＳ２４０１の処理として、預管理データ受信部２２０１により、管理データとＩＤとを受信する。ステップＳ２４０２の処理として、その管理データを、管理データ送信部２２０２により、管理サーバへ送信する。そしてステップＳ２４０３の処理として、管理データ受信部８０３により、管理データを受信する。その後、ステップＳ２４０４の処理として、保管部２２０４により、ステップＳ２４０１で受信されたＩＤとステップＳ２４０３で受信された管理データを関連付けて保管する。
【０１５４】
図２５は、保管サーバ２２００におけるＩＤを受信しそのＩＤと関連付けられて保管されている管理データを送信するまでの処理の流れを説明するフローチャートの一例である。ステップＳ２５０１の処理として、ＩＤ受信部２２０５により、ＩＤを受信する。ステップＳ２５０２の処理として、そのＩＤと関連付けられて管理データが保管部２２０４に保管されていることを確認する。もし確認できなければ、エラーをＩＤの送信元などに返信する。確認ができれば、ステップＳ２５０３の処理として、ＩＤと関連づけて保管されている管理データを読み出す。そして、ステップＳ２５０４の処理として、ＩＤと管理データとが関連付けられて格納されている状態を解消する。例えば、図２３に示されるテーブルから上述にように行データを削除する。その後ステップＳ２５０５の処理として、預管理データ送信部２２０６により、管理データを送信する。
【０１５５】
このような構成の保管サーバを、図２０、図２１に示すように決済サーバと管理サーバとを組み合わせることにより、匿名性を保ちつつ管理データの発行が行える。
【０１５６】
また、このような保管サーバを経由することにより、利用者間でも管理データを譲渡することができる。「利用者間」と記載したが、この場合、一方の利用者は物やサービスを購入する者であり、他方はその物やサービスを提供する者であり、その物やサービスの対価として管理データが一方の者から他方の者へ譲渡される場合が想定される。特に、他方はＷＥＢサーバなどを用いてインターネットからアクセスされる仮想的な店舗であってもよい。すなわち、管理データを電子マネーとして使用することにより、財物や役務の提供に対する代金の決済処理を行うことができる。すなわち、保管サーバが決済処理を行うサーバとして動作することになる。また、保管サーバを用いることにより、個人間などの一般の利用者間でも管理データの譲渡をすることが可能となる。
【０１５７】
図２６は、利用者間で管理データを譲渡するシステム２６００の構成を示す。システム２６００を参照しながら、管理サーバ２６０１と、保管サーバ２６０３と、譲渡者端末２６０４と、譲受者端末２６０５とを有する。譲渡者端末２６０４、譲受者端末２６０５にはそれぞれブラウザ、電子財布がインストールされていてもよい。また、譲渡者端末２６０４の利用者（譲渡人）が譲受者端末２６０５の利用者（譲受人）へ管理データを譲渡する場合の処理の流れについて以下に説明する。
【０１５８】
譲渡人は、あらかじめ、管理サーバから管理データの発行を受けたり、決済サーバを介して管理データを取得したり、決済サーバと保管サーバを介して管理データから取得したりしておく。この管理データは譲渡者端末２６０４にインストールされている電子財布により管理されていてもよい。あるいは別の譲渡人より、管理データの譲渡を受ける。この場合の譲渡としては、これから説明されるように保管サーバを介して行われてもよいし、別の譲渡人から管理データが記録された光ディスクや可搬型の不揮発性半導体メモリなどの記憶媒体の譲渡を受けたり、電子メールの添付データなどとして譲渡を受けたりしていてもよい。このように譲渡を受けた管理データも譲渡者端末２６０４にインストールされている電子財布により管理されてもよい。
【０１５９】
図２７は、保管サーバを介しての管理データの譲渡の流れを説明するシーケンス図である。ステップＳ２７０１の処理として、譲渡者端末２６０４と譲受者端末２６０５との間で管理データの譲渡の合意をする。この合意は、無償にて譲渡人が譲受人に管理データを譲渡する合意であったり、上述のように譲受人が物やサービスを提供することの引き替えに譲渡人が管理データを譲渡する合意であったりする。なお、この合意のために、譲渡人の使用する譲渡者端末（第１の端末）と譲受人の使用する譲受者端末（第２の端末）とが相互に認証し合ってもよい。例えば、暗号化された通信セッションを確立するために第１の端末と第２の端末との間で暗号化と復号化のための暗号鍵を共有する。
【０１６０】
また、相互認証の際には、その相互認証を一意に特定する情報を決める。例えば、ＷＥＢショップで買い物などを行う場合には、ＷＥＢサーバと端末との間の暗号化された通信セッションのＩＤなどを用いる。
【０１６１】
譲渡の合意あるいは相互認証が終了すると、譲渡人側の端末では、電子財布を動作して、新たに管理データの発行を受けたり、既に発行がされたり第三者から譲渡がされたりした管理データの中から選択を行い、管理データ３とセッションＩＤとを保管サーバ２６０３へ送信する。管理データ３とセッションＩＤとを受信した保管サーバは、ステップＳ２７０３の処理として管理データ３を管理サーバへ送信する。管理サーバが管理データ３に含まれる照合用データが有効であると確認を行うと、新たに準備した照合用データによる置換を行い、ステップＳ２７０４の処理として管理データ４を保管サーバへ返信する。これにより、管理データ３は無効な照合用データを含む管理データとなり二重に使用ができなくなる。
【０１６２】
保管サーバが管理データ４を受信すると、ステップＳ２７０２で受信したセッションＩＤと関連付けて保管を行い、ステップＳ２７０５の処理として保管通知を譲渡者端末へ送信する。保管通知を受信した譲渡者端末は、ステップＳ２７０６の処理として、寄託通知を譲渡者端末へ送信する。
【０１６３】
寄託通知を受信した譲受者端末は、ステップＳ２７０７の処理として、管理データの送信要求を譲渡合意の際のセッションＩＤとともに保管サーバへ送信し、これに応じて保管サーバは管理データ４をステップＳ２７０８の処理として返信する。このとき、譲受者端末では電子財布が起動されてもよい。
【０１６４】
以上のように保管サーバを構成することにより、管理データの発行の際、そして、管理データの譲渡の際に同じ処理を保管サーバで行うようにすることができる。また、管理データの匿名性なども確保できる。
【０１６５】
（実施形態３）
上述の実施形態２において、価値として貨幣価値のように可分な価値が用いられる場合には、管理データが表す価値に上限を設けてもよいことについて説明した。例えば、５０００円を上限とすると、１３０００円の価値は、例えば、５０００円を表す管理データ２つと、３０００円を表す管理データ１つとにより表される。この場合の３０００円を表す管理データのように、上限の価値に満たない価値を表す管理データを「端数管理データ」と呼ぶことにする。
【０１６６】
管理データを用いて商品や役務の代金の決済が行われる場合を考えると、代金の額が上記でいう上限になるとは限らない。このため、端数管理データを含む管理データにより代金が支払われたり、釣り銭の代わりに端数管理データを含む管理データが支払いとは逆の方向の管理データの流れで譲渡されたりする。このため、端数管理データの数は増加することになる。この結果、管理サーバのデータベース部の管理するデータが増加してしまうなどの問題が生ずる。そこで、以下では、端数管理データの増加を防ぐ構成について説明を行う。
【０１６７】
（管理サーバ）
本実施形態に係る管理サーバは、実施形態２に係る管理サーバ１５００において、管理データ受信部１５０５が端数管理データ受信手段と、支払額受信手段とを有し、置換部１５０６が端数変更手段と、釣管理データ生成手段とを有し、置換管理データ送信部１５０７が端数管理データ送信手段と、釣管理データ送信手段とを有する。
【０１６８】
端数管理データ受信手段は、端数管理データを受信する手段である。受信された端数管理データは、他の一または複数の管理データとともに、保管サーバより送信され管理サーバに受信され照合用データの有効性の確認がされることが主に想定される。端数管理データ受信手段は、端数管理データを受信するとメモリに展開し、端数管理データに含まれる照合用データのアドレスなどを取得して、端数変更手段に伝達する。
【０１６９】
支払額受信手段は、管理データ受信部１５０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データの表す価値のうち、譲渡が行われる価値を表す。すなわち、保管サーバを経由して譲渡者端末から譲受者端末へ譲渡されるべき価値を表すことが主に想定される。そして、譲渡が行われない価値が存在すれば、その価値は後述のように釣管理データとして譲渡者端末へ送信されることになる。
【０１７０】
端数変更手段は、支払額受信手段が受信した価値を上述の上限の価値で除算を行った時の余りが０で無い場合に、端数管理データ受信手段により受信された端数管理データの表す価値にその余りを加算する処理を行う。例えば、上限額が５０００円で支払額受信手段が受信した価値が１３０００円であれば、１３０００円を５０００円で割り算を行うと、３０００円が余りとなる。そこで、端数管理データ受信手段が受信した端数管理データがデータベース部１５０１により、１０００円を表していれば、１０００円に３０００円を加算した４０００円を表すようにデータベース部１５０１が管理するデータベースの変更操作などを行う。
【０１７１】
具体的には、端数変更手段は、端数管理データ受信手段からで伝達されたアドレス等により指定される照合用データで図１６（ａ）などに示されるテーブルの検索を行いその照合用データがテーブルに格納されているのを確認すると、その照合用データに関連付けられている価値の値に上述の余りを加算する。加算した結果がもし上述の上限を超えていれば、加算した結果のかわりに上限の価値をテーブルに登録し、新たに照合用データを準備してテーブルに挿入し、加算した結果から上述の上限を引いた額を関連付ける。例えば、端数管理データ受信手段からで伝達されたアドレス等により指定される照合用データに１０００円が関連付けられており、上述の余りが４５００円であったとする。すると加算した結果は５５００円となり、上限の５０００円を超えている。そこで、端数管理データ受信手段からで伝達されたアドレス等により指定される照合用データには上限の５０００円を関連づけ、新たに準備される照合用データには５００円を関連付ける。もちろん、５０００円と５００円とに関連付けるのは一例であり、５５００円の上限を超えないように複数の価値に任意に分けることができる。例えば、２５００円と３０００円とであってもよい。
【０１７２】
釣管理データ生成手段は、管理データ受信部１５０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データの表す価値のうち、支払額受信手段が受信した価値を引いた価値（「釣価値」という。）が０でなければ、釣価値を表す管理データを生成する。新たに管理データを生成してもよいし、管理データ受信部１５０５で受信された管理データのうち端数管理データ受信手段で受信されたものを除く管理データを再利用するように、その管理データが表す価値に釣価値を加えてもよい。そして、もし加えた結果が上限を超えていれば、新たな管理データを生成して、管理データに上限を超える価値が関連付けられないようにする。
【０１７３】
端数変更手段、釣管理データ生成手段それぞれは、端数管理データ受信手段が受信した端数管理データが含む照合用データ、釣管理データ生成手段が生成した釣価値を表す管理データが含む照合用データのそれぞれを、新たな照合用データを準備して書き換えてもよい。
【０１７４】
端数管理データ送信手段は、端数変更手段により価値が加算された管理データ、また必要に応じて新たに生成された管理データを送信する。
【０１７５】
釣管理データ送信手段は、釣管理データ生成手段で生成された管理データを送信する。
【０１７６】
また、本実施形態において、保管サーバの預管理データ受信部２２０１は、管理データ及びＩＤとともに、支払額情報を受信可能となっている。支払額情報とは、管理データの譲渡により譲渡されるべき価値を示す情報である。そして、預管理データ受信部２２０１は、支払額情報が受信された場合には、受信したＩＤに関連付けられて保管部２２０４に保管されている管理データを検索し、得られた管理データと受信した管理データとともに支払額情報を管理データ送信部２２０２に伝達する。この場合、受信したＩＤに関連付けられて保管部２２０４に保管されている管理データは、譲受者端末より送信された端数管理データとなっている。管理データ送信部２２０２は、管理データとともに伝達された支払額情報を送信する。
【０１７７】
また、管理データ受信部２２０３は、釣管理データも受信可能となっている。釣管理データが受信された場合には、保管サーバは、保管部２２０４に管理データが保管されると、保管通知とともに釣管理データを、預管理データ受信部２２０１が受信した管理データの送信元へ返信する。
【０１７８】
図２８は、本実施形態において、保管サーバを介しての管理データの譲渡の流れの一例を説明するシーケンス図である。ステップＳ２８０１の処理として、ステップＳ２７０１と同様に譲渡の合意を譲渡者端末と譲受者端末との間で行う。このとき、その合意では、単に管理データの譲渡のみならず、管理データの譲渡により譲渡される価値も合意する。例えば、商品の値段、送料などである。そして、このような場合に譲渡者端末が保管サーバへ送信する管理データを支払管理データという。
【０１７９】
ステップＳ２８０２の処理として、譲受者端末から保管サーバへ、端数管理データ１とセッションＩＤとを保管サーバへ送信する。このとき、譲受者端末である旨の情報も送信してもよい。ステップＳ２８０３の処理として、保管サーバは、受信した端数管理データ１を管理サーバへ送信し、その有効性を確認させ、ステップＳ２８０４の処理として、保管サーバは、端数管理データ２を管理サーバより受信する。そして、セッションＩＤと関連づけて端数管理データ２を保管する。
【０１８０】
なお、譲受者端末に端数管理データが無ければ、保管サーバには端数管理データを送信する必要はなく、したがって、保管サーバが端数管理データを管理サーバに送信する必要もない。
【０１８１】
譲渡者端末は、ステップＳ２８０５の処理として、支払額と支払いのための支払管理データ１とセッションＩＤを保管サーバに送信する。保管サーバは、支払管理データ１と支払額とを管理サーバに送信する。また、保管サーバは、セッションＩＤからそれに関連付けられている端数管理データの有無を検出し、もしそのような端数管理データが存在すれば、その端数管理データもともに管理サーバへ送信する。なお、ステップＳ２８０２において、譲受者端末から譲受額が送信されてもよく、この場合は、譲渡者端末から送信される支払額と譲受額とが同じであることを確認してもよい。もし、同じでなければ譲受者端末、譲渡者端末へエラーを通知する。また、ステップＳ２８０２において、譲受者端末から譲受額が送信され、ステップＳ２８０５において、譲渡者端末から支払額が送信されない構成もある。この場合には、支払管理データ１に関連付けられている価値の値が譲受額以上であることを確認する。もし、譲渡に伴って手数料などを徴収する際には、支払管理データ１に関連付けられている価値の値から手数料などの額の値を引いたものが譲受額以上であることを確認する。また、端数管理データ１に関連付けられている価値から手数料などの額を徴収することにしてもよい。
【０１８２】
管理サーバは、受信した支払管理データ２、支払額、端数管理データ２から、置換部１５０６、置換管理データ送信部１５０７により、端数管理データ３と支払管理データ２と釣管理データとを生成して、ステップＳ２８０７の処理として、保管サーバへ送信する。ここで、端数管理データ３は、端数変更手段で変更、生成された管理データであり、釣管理データは釣管理データ生成手段で生成された管理データである。
【０１８３】
端数管理データ３と支払管理データ２と釣管理データとを受信した保管サーバは、支払管理データ３と端数管理データをステップＳ２８０２又はＳ２８０５で受信したセッションＩＤと関連づけて保管する。そして、ステップＳ２８０８の処理として、譲渡者端末へ釣管理データと保管通知を送信する。譲渡者端末は、ステップＳ２８０９において寄託通知を譲受者端末へ送信し、譲受者端末はステップＳ２８１０において、送信要求とセッションＩＤとを保管サーバへ送信し、これに応じて保管サーバは、セッションＩＤと関連付けて保管されている端数管理データ３と支払管理データ２をステップＳ２８１１の処理として、譲受者端末へ送信する。そして、セッションＩＤと端数管理データ３及び支払管理データ２との関連付けを破棄する。
【０１８４】
このようにして、譲渡者端末から譲受者端末へ、譲渡合意で合意された価値が電子的に譲渡される。また、本実施形態では、管理データが表す価値に上限を設けられている場合に、譲受者端末から端数管理データを提供することにより、その端数管理データに釣り銭に相当する価値を加えることができ、端数管理データの数の増大を防止することができる。これにより、管理サーバのデータベース部１５０１で管理するべき照合用データの数の増加を防止することができる。なお、「譲受者端末」と記載したが、譲受者端末は端末装置と同等の機能を有していればよく、サーバ装置を端末装置として用いられる場合も含まれる。譲渡者端末についても同様である。
【０１８５】
（実施形態４）
実施形態２において、図２０、図２１などを参照して、管理サーバ、決済サーバ、保管サーバ及び利用者端末からなるシステムの構成などについて説明した。本発明の実施形態４として、別のシステムの構成などについて説明する。
【０１８６】
図２９は、本発明の実施形態５に係るシステム２９００の構成を示す。システム２９００は、管理サーバ２９０１と、決済サーバ２９０２と、保管サーバ２９０３と、利用者端末２９０４とを有する。実施形態２と同様に、管理サーバ２９０１と、決済サーバ２９０２と、保管サーバ２９０３と、利用者端末２９０４とは、それぞれ通信アダプタなどのハードウェアを備え、通信を行う。実施形態２では、利用者端末２００４の利用者は、管理サーバ２００１と直接通信を行う必要は無かったが、本実施形態では、様々な決済サーバの構成に対応できるように、利用者端末２９４０の利用者は、管理サーバ２９０１とも通信を行う構成となっている。
【０１８７】
本実施形態では、管理サーバ２９０１と、決済サーバ２９０２と、保管サーバ２９０３と、利用者端末２９０４とは、基本的に実施形態１における管理サーバ２００１と、決済サーバ２００２と、保管サーバ２００３と、利用者端末２００４と同じ構成でよい。ただし、本実施形態では、管理サーバ２９０１と利用者端末２９０４とが通信を行うので、この点を実現する構成が異なる。すなわち、管理サーバ２９０１は、利用者端末２９０４に対してサービスを提供するための部が備わった構成となっている。例えば、管理サーバ２００１に、ウェブサーバとして動作する部が備わっており、利用者端末２９０４に対してサービスを提供するようになっている。したがって、この場合には、利用者端末２９０４は、ウェブブラウザなどの閲覧ソフトウェアを用いて管理サーバ２９０１と通信を行う。また、利用者端末２９０４には、ウェブブラウザなどの他に、管理データを管理するアプリケーションプログラムである電子財布（以下、電子財布を、管理データを管理するアプリケーションプログラムという意味で「管理データ管理アプリケーション」という）がインストールされていてもよく、管理データ管理アプリケーションを用いて管理サーバ２９０１と通信を行うようになっていてもよい。
【０１８８】
図３０は、本実施形態におけるシステム２９００での決済処理が行われて管理データが生成されて利用者端末に受信されるまでの処理を説明するシーケンス図である。
【０１８９】
ステップＳ３００１において、利用者端末２９０４から管理サーバ２９０１へ、利用者端末２９０４の識別情報を含む情報を送信する。識別情報とは、利用者端末２９０４を識別するための情報である。識別情報の例としては、利用者端末２９０４の製造番号や、ＭＡＣアドレス、ＩＰアドレスなどである。あるいは、利用者を識別する情報であるユーザＩＤや所有者ＩＤなどであってもよい。また、識別情報は、利用者端末２９０４の製造番号や、ＭＡＣアドレス、ＩＰアドレスなどの情報そのものである必要はなく、それらの情報に対して所定のハッシュ関数を適用して計算される値であってもよい。この識別情報は、管理サーバ２９０１により後に発行される管理データに埋め込まれてもよい。識別情報を管理データに埋め込むことにより、管理データを譲渡などする場合に、管理データが不正に他の利用者端末から取得されたものであるかどうかを検出することができる。これにより、管理データの使用の際の安全性を高めることができる。また、識別情報には、乱数が含まれるようになっており、管理サーバ２９０１への送信の都度、変化する部分があってもよい。
【０１９０】
管理サーバ２９０１において、識別情報を受信する部を識別情報受信部という。
【０１９１】
なお、ステップＳ３００１において、識別情報は、例えば、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のＰＯＳＴメッセージとして、利用者端末２９０４から管理サーバ２９０１に送信される。ただし、識別情報は、ブラウザで送信される必要はなく、上述した管理データ管理アプリケーションによって送信されてもよい。管理データ管理アプリケーションを用いれば、利用者端末２９０４のハードウェアなどにアクセスを行い、ＭＡＣアドレスなどを取得することが容易に行える。
【０１９２】
ステップＳ３００２においては、管理サーバ２９０１は、画面情報を利用者端末２９０４へ返信する。画面情報は、例えば、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いて記述され、管理データを発行するための入金処理や、発行された管理データを受け取るための処理を行うために使用することができる。
【０１９３】
利用者端末１９０４が画面情報を受信すると、その画面情報の記述に従って画面表示を行う。例えば、受信された画面情報を、利用者端末２９０４で動作する管理データ管理アプリケーションがＲＥＡＤシステムコールなどを用いて取得すると、ウェブブラウザを起動して、そのウェブブラウザによって画面情報を表示させる。
【０１９４】
図３１は、表示される画面情報の例を示す。例えば管理データ管理アプリケーションによりブラウザが起動されて画面情報が表示されると、図３１（ａ）に示されるように、「入金」、「管理データ受取」という表示を有するボタンが表示される。「入金」の表示を有するボタンが押下されると、画面情報に含まれるスクリプトなどの処理により、図３１（ｂ）に示される画面が表示される。
【０１９５】
図３１（ｂ）は、銀行振込を行うための画面であって、「振込名義人名を１２３４５としてください」というメッセージが表示され、「振込」という表示を有するボタンが表示されている。１２３４５というのは、管理サーバ２９０１がステップＳ３００１において識別情報を受信した際に、管理サーバ２９０１側などで生成される情報である。あるいは、利用者端末２９０４側で生成され、ステップＳ３００１において管理サーバ２９０１に送信され、管理サーバ２９０１で承認などされた番号であってもよい。承認とは、利用者端末２９０４側で生成された情報が適切でることを確認することである。例えば、同じ情報を他の利用者端末で生成されて管理サーバ２９０１に送信されていないことを確認する。あるいは、識別情報がユーザＩＤであれば、そのユーザＩＤそのものやユーザＩＤに関連付けられた値である。利用者が銀行振込を行う際に、この情報を振込名義人名に含ませることにより、管理サーバ２９０１が銀行から振込通知を受信などした際に、その振込がどの識別情報の受信に対して返信した画面情報によって行われたかを知ることができる。また、図３１（ｂ）の画面には、振込先の銀行口座の情報が含まれていてもよい。
【０１９６】
管理サーバ２９０１において、振込名義人名を生成あるいは承認、取得し、利用者端末２９０４に送信する部を、振込名義人名送信部という。
【０１９７】
なお、図３１（ｂ）において、複数の銀行の中から利用者端末２９０４の利用者が契約している銀行を選択できるように、複数の銀行それぞれに対応したボタンが表示されていてもよい。
【０１９８】
図３１（ｂ）の「振込へ」の表示を有するボタンが押下されると、利用者端末２９０４から銀行などの決済サーバ２９０２に対してアクセスが行われ、図３２（ａ）のようなインターネットバンキングなどのためのログイン画面が表示される。このログイン画面を介して利用者がログインを行い、振込の依頼を行うと、ステップＳ３２０４の処理として、利用者端末２９０４から決済サーバ２９０２に対して振込依頼が送信される。この振込依頼には、管理サーバ２９０１などの運営者の銀行口座の情報、振込名義人名、振込額が含まれる。なお、図３１（ｂ）の「振込へ」の表示を有するボタンには、振込先の口座の情報や、振込名義人名を含むＵＲＬが関連付けられており、そのＵＲＬにアクセスすると、決済サーバ２９０２に振込先の口座の情報や振込名義人名が伝えられ、振込の画面が開かれた場合に、振込先の口座の情報や振込名義人名が既にデフォルト値などとして入力された状態となっていてもよい。
【０１９９】
振込の依頼が終わると、ステップＳ３２０４の処理として、利用者端末２９０４から管理サーバ２９０１へ、振込の依頼の処理が終わったこと旨を表す入金通知が送信される。この際には、ステップＳ３２０１で送信された識別情報や振込名義人名も送信される。すなわち、利用者端末２９０４にて、振込の依頼の処理が終了すると、利用者端末２９０４では、図３２（ｂ）に示されるような画面が表示される。図３２（ｂ）に示される画面は、「入金通知」という表示を有するボタンが表示されている。このボタンが押下されると、ステップＳ３００４の処理として、入金通知が利用者端末２９０４から管理サーバ２９０１へ送信される。入金通知は、利用者端末２９０４にて振込の依頼の処理が終了したことを、利用者端末２９０４から管理サーバ２９０１に知らせる情報である。
【０２００】
入金通知を受信した管理サーバ２９０１は、ステップＳ３２０５の処理として、入金通知とともに送信された情報から振込名義人名を取得し、決済サーバ２９０２に対して、その振込名義人名による振込が実際に依頼されたかどうかを問い合せる。決済サーバ２９０２は、その振込名義人名による振込があれば、ステップＳ３２０６の処理として振込通知を返信する。この振込通知には振込額も含まれていてよく、これにより、管理サーバ２９０１は振込額を得ることができる。
【０２０１】
また、ステップＳ３００５とＳ３００６の処理の代わりに、管理サーバ２９０１は、例えば、５分に一回、振込の有無の問い合せを管理サーバ２９０１に行い、振込の有無を確認してもよい。
【０２０２】
もし、振込がされていなければ、管理サーバ２９０１は、ステップＳ３００４の入金通知に対して、振込が確認できなかったことを通知する。この場合、管理データ管理アプリケーションなどによって振込の確認ができていないことの表示がされ、利用者は、しばらく時間が経過してから再度入金通知を行うことになる。
【０２０３】
管理サーバ２９０１は、振込を確認すると、振込通知に含まれる振込名義人名から、どの識別情報の受信に対して画面情報によって行われたかをテーブルなどを検索して取得し、管理データを生成し、また、実施形態２で説明したように、振り込みの決済処理を特定する番号を生成する。決済処理を特定する番号は、本実施形態では、「送り情報」と称することにする。送り情報は、例えば、利用者端末２９０４と管理サーバ２９０１とがステップＳ３００１とＳ３００２とで通信を行ったセッションのＩＤであってもよい。また、振込み名義人名送信部で送信された振込名義人名を用いてもよい。ステップＳ３００７の処理として、生成した送り情報と管理データとを保管サーバ２９０３へ送信する。保管サーバ２９０３は、送り情報と管理データとを関連付けて、その保管部に保持する。
【０２０４】
管理サーバ２９０１において、振込通知を受信する部を振込通知受信部と称する。また、管理データを生成するために、新たな照合用データを準備して、振込通知受信部が受信した振込通知に含まれる金額の額に相当する価値情報を関連づけてデータベース部１５０１に記憶する部を照合用データ生成部と称する。また、新たに準備された照合用データから生成された管理データを送信する部を管理データ送信部と称する。また、本実施形態では、管理サーバ２９０１は、準備された照合用データと、識別情報受信部で受信された識別情報を関連付けてデータベース部１５０１などに記憶する。
【０２０５】
ステップＳ３００８の処理として、管理サーバ２９０１は、入金が確認された旨と送り情報とを利用者端末２９０４へ返信する。なお、ステップＳ３００１とＳ３００２とにおいて利用者端末２９０４と管理サーバ２９０１との通信において、送り情報が、セッションＩＤや振込名義人名として利用者端末２９０４に送り情報が通知されていれば、ステップＳ３００８では、送り情報を利用者端末２９０４へ返信する必要はない。
【０２０６】
管理サーバ２９０１にて、その振込によって生成された送り情報を取得し、ステップＳ３００８の処理として、入金確認と送り情報とを利用者端末２９０４へ返信する。
【０２０７】
利用者端末２９０４が、入金確認と送り情報とを受信すると、図３２（ｃ）に示される画面が表示される。図３２（ｃ）に示される画面においては、「入金の確認がされましたので、管理データ受取を押して下さい」というメッセージと、「管理データ受取」という表示を有するボタンが表示される。なお、図３２（ｃ）の画面は、ブラウザによって表示される必要はなく、管理データ管理アプリケーションによって表示されてもよい。例えば、ステップＳ３００８にて返信される入金確認と送り情報とが、ＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎ）のフォーマットを用いて送信され、そのフォーマットにおいてＣｏｎｔｅｎｔ−Ｔｙｐｅなどによって、管理データ管理アプリケーションがアプリケーションプログラムとして用いられることが指定されていてもよい。このような指定により、ブラウザが入金確認と送り情報とを受信すると、管理データ管理アプリケーションが起動され、図３２（ｃ）に示される画面が表示できる。
【０２０８】
「管理データ受信」のボタンが押下されると、ステップＳ３００９の処理として、利用者端末２９０４から保管サーバ２９０３へ、送り情報が送信される。この送り情報が保管サーバ２９０３にて受信されると、ステップＳ３００６において格納部に送り情報と関連付けられて保管された管理データが読み出される。そして、ステップＳ３０１０の処理として、その管理データが保管サーバ２９０３から利用者端末２９０４に受信されて、利用者端末２９０４内に格納される。
【０２０９】
図３３は、管理サーバ２９０１が、ステップＳ３００１において利用者端末２９０４から識別情報を受信してから、ステップＳ３００８において入金確認と送り情報とを送信するまでの処理を行うために参照するテーブルの構成と格納されるデータの遷移を説明する。図３３（ａ）に示すように、管理サーバ２９０１は、「識別情報」、「振込番号」、「金額」、「送り情報」という名前の列により構成されるテーブルを保持し、管理を行う。
【０２１０】
管理サーバ２９０１がステップＳ３００１において識別情報を受信すると、そのテーブルに対して行データの挿入が行われる。識別情報が例えば９８７６５であれば、図３３（ｂ）に示されるように、識別情報の列の値が９８７６５である行がテーブルに挿入される。その行において、識別情報の列以外の列の値は、例えば、ＮＵＬＬ（図示せず）とされる。ＮＵＬＬとされることにより、まだ値が定まっていないことが表現される。
【０２１１】
識別情報がステップＳ３００１において受信され、その識別情報に基づいて振込名義人名が決定されると、挿入された行の振込番号の列の値が、その振込名義人名に更新される。例えば、振込名義人名が図３１（ｂ）に示されるように１２３４５であれば、図３３（ｃ）に示すように、識別情報の列の値が９８７６５である行の振込番号の列の値が１２３４５に更新される。
【０２１２】
管理サーバ２９０１がステップＳ３００６において振込通知を受信すると、その振込通知に含まれる振込名義人名を振込番号の列に有する行が検索され、振込通知に含まれる振込金額により金額の列の値が更新される。例えば、振込通知により、１２３４５という振込名義人名により５０００円が振り込まれたとすると、図３３（ｄ）に示すように、識別情報の列の値が９８７６５である行の金額の列の値が５０００に更新される。これにより、管理サーバ２９０１は、振込があったことが確認できるようになる。
【０２１３】
管理サーバ２９０１が送り情報を生成し、ステップＳ３００７において保管サーバ２９０３に、送り情報を送信すると、「送り情報」の列の値が更新される。例えば、１２３４５という振込名義人名により５０００円が振り込まれ、２４６８１０という送り情報が生成されると、図３３（ｅ）に示すように、識別情報の列の値が９８７６５である行の送り情報の列の値が２４６８１０に更新される。これにより、管理サーバ２９０１は、９８７６５という識別番号に対して、管理データを生成して、保管サーバ２９０３に送信したことが確認できるようになる。
【０２１４】
図３４は、利用者端末２９０４の図３とは別の機能ブロック図を示す。この機能ブロック図は、利用者端末２９０４にインストールされているアプリケーションプログラムの構成を示している。利用者端末２９０４には、ブラウザと管理データ管理アプリケーションとがインストールされている。ブラウザと管理データ管理アプリケーションとが協調して動作して決済処理から管理データの受信の処理を行う。
【０２１５】
図３５は、利用者端末２９０４にインストールされているブラウザと管理データ管理アプリケーションとが協調して、図３０に示される決済処理が行われ、管理データが生成されて利用者端末に受信されるまでの処理のシーケンス図を示す。
【０２１６】
ステップＳ３５０１は、ステップＳ３００１に対応している。ステップＳ３５０１においては、識別情報が、管理データ管理アプリケーションより送信されることを示している。管理データ管理アプリケーションを用いれば、ブラウザを用いるよりも容易に利用者端末２９０４のハードウェアなどにアクセスを行い、ＭＡＣアドレスなどのハードウェア固有の情報を取得することができる。
【０２１７】
なお、ステップＳ３５０１の処理を実行するには、利用者端末２９０４にて管理データ管理アプリケーションを起動する。管理データ管理アプリケーションの起動により、例えば、図３６に示されるように、「入金（ポイント購入）」、「ポイントの受取」、「ポイントによる支払」の表示を有するボタンを含む画面表示が利用者端末２９０４のディスプレイなどに表示がされる。「入金（ポイント購入）」のボタンが押下されると、管理データ管理アプリケーションは、識別情報を算出などして、管理サーバ２９０１へ送信する。
【０２１８】
ステップＳ３５０２は、ステップＳ３００２に対応している。ステップＳ３５０２においては、ステップＳ３５０１にて送信された識別情報に対して管理サーバ２９０１から返信される画面情報が、管理データ管理アプリケーションにより受信される。
【０２１９】
管理データ管理アプリケーションが画面情報を受信すると、ステップＳ３５０３の処理として、管理データ管理アプリケーションはブラウザを起動し、画面情報の記述に従った画面表示を行う処理が行われる。例えば、管理データ管理アプリケーションは、受信した画面情報を一時ファイルに書き込み、その一時ファイルの名前をコマンドの引数などとしてブラウザに与えてブラウザを起動する。例えば、一時ファイルの拡張子と関連付けられているブラウザが起動されるようになっている。
【０２２０】
ステップＳ３５０４、ステップＳ３５０５、ステップＳ３５０６、ステップＳ３５０７、ステップＳ３５０８は、それぞれステップＳ３００３、ステップＳ３００４、ステップＳ３００５、ステップＳ３００６、ステップＳ３００７、ステップＳ３００８に対応している。これらのステップの処理では、利用者端末２９０４では、ブラウザが管理サーバ２９０１、決済サーバ２９０２と通信を行う。
【０２２１】
ステップＳ３５０９にて、ブラウザが入金確認と送り情報とを管理サーバ２９０１より受信すると、ブラウザは、管理データ管理アプリケーションを起動し、送り情報を管理データ管理アプリケーションに処理をさせる。上述したように入金確認と送り情報とが、ＭＩＭＥのフォーマットを用いた情報としてブラウザにより受信されると、そのフォーマットにおいてＣｏｎｔｅｎｔ−Ｔｙｐｅなどによって、管理データ管理アプリケーションにより処理することが指定されているので、ブラウザは管理データ管理アプリケーションを起動し、起動した管理データ管理アプリケーションは、送り情報を取得する。ステップＳ３５１０の処理として、管理データ管理アプリケーションは、保管サーバ２９０３へ送り情報を送信する。保管サーバ２９０３から返信される管理データを受信する処理をステップＳ３５１１の処理として行う。管理データ管理アプリケーションが管理データを受信すると、受信した管理データを、利用者端末２９０４の記憶装置（ハードディスクなど）に書き込む。
【０２２２】
ブラウザから管理データ管理アプリケーションが起動された場合には、図３６の画面が表示されてもよい。利用者端末２９０４の利用者が「ポイントの受取」の表示を有するボタンを押下すると、ステップＳ３５１１とステップＳ３５１２との処理が開始されるようになっていてもよい。
【０２２３】
図３７は、管理データ管理アプリケーションの図６とは別のモジュール構成図を示す。管理データ管理アプリケーション３７００は、識別情報取得部３７０１と、送り情報管理部３７０２と、管理データ管理部３７０３と、送受信部３７０４と、制御部３７０５とを有している。
【０２２４】
識別情報取得部３７０１は、ステップＳ３５０１において送信される識別情報を取得する。例えば、利用者端末２９０４のハードウェアにシステムコールなどを用いてアクセスを行い、ＭＡＣアドレスや製造番号などを取得する。また、利用者端末２９０４の利用者のＩＤやパスワードなどの認証情報を識別情報として取得してもよい。また認証情報は、ファイルに格納されていたり、キーボードやカードリーダなどにより読み取られるようになっていたりしてもよい。また、認証情報の一部に乱数が含まれる場合には、識別情報取得部３７０１がその乱数を生成するようになっていてもよい。
【０２２５】
また、識別情報取得部３７０１により取得された識別情報は、ステップＳ３５１１の処理により管理データが受信されるまで、利用者端末のハードディスクなどの二次記憶に記憶されるようになっていてもよい。管理データ管理アプリケーションが起動すると、二次記憶に識別情報が記憶されているかどうかを調べ、もし、記憶されていれば、受け取られていない管理データが保管サーバ２９０３に保管されている旨の表示を行い、利用者に注意を喚起してもよい。この場合、利用者が振込の依頼の処理を行っているのならば、管理データ管理アプリケーションは利用者にステップＳ３５０５の入金通知を管理サーバ２９０１に送信し、入金確認と送り情報を受信することができるように、ボタンなどを表示する。そして、そのボタンが押下されると、管理データ管理アプリケーションは入金通知を管理サーバ２９０１に送信する。
【０２２６】
送り情報管理部３７０２は、ステップＳ３３１０において、ブラウザから渡された送り情報を管理する。管理とは、データのファイルへの書き込み、読み出し、削除、更新を意味する。ステップＳ３５０９の処理により、ブラウザから管理データ管理アプリケーションが起動される際に、ブラウザから渡された送り情報を所定のファイルに書き込む。また、ステップＳ３５１１の処理により、管理データが受信されると、所定のファイルを削除したり、所定のファイルから送り情報を削除したりする。これにより、送り情報が受信されたが、受信されていない管理データの有無をしらべることができる。
【０２２７】
管理データ管理部３７０３は、管理データを管理する。ステップＳ３５１１にて受信された管理データは、管理データ管理部３７０３により、利用者端末２９０４の記憶装置（ハードディスクなど）に書き込まれ、また、管理データを用いた支払の処理の際に読み出し、削除、変更が行われる。
【０２２８】
送受信部３７０４は、管理サーバ２９０１、保管サーバ２９０３と通信を行うための部である。
【０２２９】
制御部３７０５は、識別情報取得部３７０１と、送り情報管理部３７０２と、管理データ管理部３７０３と、送受信部３７０４とを制御し、管理データの受信の処理、管理データを用いた支払の処理を行う。
【０２３０】
図３８は、管理データを用いた支払の処理のシーケンス図を示す。図３８は、保管サーバを介しての管理データの譲渡についてのシーケンス図である図２８に対応している。図２８での譲受者端末が図３８での販売サーバに対応し、譲渡者端末が利用者端末に対応している。本実施形態では、利用者端末の内部で管理データ管理アプリケーションとブラウザとが協調して動作している。また、販売サーバは、ＷＥＢサーバとしての機能を有しており、ＷＥＢページの閲覧要求があれば、要求されたＷＥＢページを返信する。
【０２３１】
ステップＳ３８０１において、利用者端末のブラウザなどへＵＲＬの入力や、ブラウザを操作してリンクを辿るなどの処理を行い、ウェブページの閲覧要求が販売サーバへ送信される。販売サーバが閲覧要求を受信すると、要求されたウェブページをステップＳ３８０２において返信する。
【０２３２】
ステップＳ３８０２においてブラウザに返信されるウェブページには、商品などの購入の申込を行うための画面の記述がされているとする。例えば、図３９に示すように、「○○」として、購入が行われる商品などの名称が表示され、代金が例えば１００円として表示される。また、「購入」という表示を有するボタンが表示されている。このボタンには、購入が行われる商品などの識別番号が関連付けられている。また、必要に応じて、ウェブページには商品の配送先などを入力するテキストエリアが含まれており、「購入」という表示を有するボタンが押下されると、そのテキストエリアに入力された情報が送信されるようになっていてもよい。
【０２３３】
「購入」という表示を有するボタンが押下されると、ステップＳ３８０３の処理として、購入情報が保管サーバに送信される。購入情報とは、販売サーバの識別情報、購入が行われる商品などの識別番号、商品などの数量、代金額を含む情報である。また、上述した商品などの発送先を含んでいてもよい。この購入情報は、図３９に示されるボタンに関連付けられた情報を用いて生成され、販売サーバに送信される。購入情報が販売サーバに送信されることにより、ブラウザを操作する利用者が販売サーバの運営者から商品などの購入の同意がされ、支払が管理データの譲渡によってされることの同意もされたことが示される。
【０２３４】
すなわち、ステップＳ３８０１からステップＳ３８０３までの処理が行われることにより、譲受端末としての販売サーバと譲渡者端末としての利用者端末との間で譲渡の合意がされることになる。従って、ステップＳ３８０１からステップＳ３８０３までの処理がステップＳ２８０１に対応していることになる。
【０２３５】
ステップＳ３８０４の処理として、販売サーバから支払指示とセッションＩＤがブラウザに送信される。支払指示には、譲渡されるべき価値の額（支払額）が含まれている。また、セッションＩＤは、上述の送り情報に対応する。支払指示とセッションＩＤとは、例えば、ＭＩＭＥフォーマットで記述され、Ｃｏｎｔｅｎｔ−Ｔｙｐｅなどによって、管理データ管理アプリケーションを用いて表示されることが指定されていてもよい。
【０２３６】
また、販売サーバは、保管サーバに対して、端数管理データ１とセッションＩＤを送信する。これは、利用者端末から送信される管理データによる支払を受けるためである。
【０２３７】
販売サーバから端数管理データ１とセッションＩＤを受信した保管サーバは、ステップＳ３８０６の処理として、端数管理データ１を管理サーバへ送信し、端数管理データ１が有効であるかどうかを判断させ、有効であれば、照合用データの書き換えを行わせ、その結果得られる管理データである端数管理データ２をステップＳ３８０７の処理において受信する。そして、送り情報と関連付けて保管する。
【０２３８】
したがって、ステップＳ３８０５、Ｓ３８０６、Ｓ３８０７の処理は、ステップＳ２８０２，Ｓ２８０３、Ｓ２８０４の処理に対応している。
【０２３９】
ステップＳ３８０４にて、販売サーバから支払指示とセッションＩＤを受信したブラウザは、管理データ管理アプリケーションを起動させ、販売サーバから受信した支払指示とセッションＩＤとの処理を行わせる。すなわち、起動した管理データ管理アプリケーションは、ステップＳ３８０９の処理として、ステップＳ３８０４で受信したセッションＩＤと支払指示に含まれる支払額とを、また、その支払額以上となるように管理データを管理データ管理部３７０３から選択して読み出して支払管理データ１として、保管サーバに送信する。支払額以上とは、選択された管理データが表す価値の額の合計額が、支払額以上となるこという。管理データ管理部３７０３から読み出される管理データは複数であってもよい。また、管理データ管理アプリケーションが起動すると、支払額を画面に表示し、ボタン押下を利用者に行わせるなどして、支払管理データの額などの確認を行わせてもよい。また、管理データ管理部３７０３で管理されている管理データは暗号化されて記憶されている場合には、復号のためのパスワードなどの入力が求められるようになっていてもよい。
【０２４０】
ステップＳ３８０９において、管理データ管理アプリケーションからセッションＩＤ、支払額、支払管理データ１を受信した保管サーバは、セッションＩＤに、支払額と支払管理データ１を関連付けて保管する。また、他にセッションＩＤに関連付けて保管されている管理データがあるかどうかの検索を行い、そのような管理データがあれば、ステップＳ３８１０以降の処理を行う。
【０２４１】
ステップＳ３８１０とステップＳ３８１１の処理は、ステップＳ２８０６、Ｓ２８０７の処理に対応している。保管サーバは、端数管理データ２と支払額と支払管理データ１を管理データに送信し、端数管理データ３、支払管理データ２と釣管理データとを受信する。
【０２４２】
ステップＳ３８１２の処理として、保管サーバは管理データ管理アプリケーションに釣管理データを送信する。この釣管理データの送信は、ステップＳ３８０９にて受信された支払額と支払管理データ１の返信として行われてもよい。
【０２４３】
ステップＳ３８１３の処理として、管理データ管理アプリケーションは、ブラウザを起動し、決済終了画面を表示させる。決済終了画面の記述は、ステップＳ３８１２にて、保管サーバが釣管理データとともに管理データアプリケーションに送信するようになっていてもよい。さらに、決済終了画面の記述は、ステップＳ３８０５において、販売サーバが端数管理データ１とセッションＩＤとともに保管サーバに送信するようになっていてもよい。このように決済終了画面の記述が、販売サーバから送信され、保管サーバを経由して、利用者端末へ送信されることにより、電子的なデータそのものや電子的なデータのダウンロードなどのために使用するＵＲＬを決済終了画面の記述に含ませることにより、電子的なデータを販売に本実施形態を利用することができる。
【０２４４】
ステップＳ３８１４にて管理サーバから受信された端数管理データ３と支払管理データ２は、ステップＳ３８０５にて受信されたセッションＩＤとともに保管サーバから販売サーバへ送信される（ステップＳ３８１４）。端数管理データ３と支払管理データ２の送信は、ステップＳ３８０５にて販売サーバから送信された端数管理データ１とセッションＩＤに対する返信として行われてもよい。
【０２４５】
このように、支払指示とセッションＩＤとがブラウザなどにより受信されると、管理データアプリケーションが起動し、管理データを用いた支払を行うことができるようになる。したがって、本実施形態においては、利用者は、ステップＳ３８０３にて購入情報を、ブラウザを用いて販売サーバに送信した後の決済の処理を行うために、従来技術におけるのと異なり、クレジットカード番号や振込先の口座番号などの煩雑なデータを入力する必要がなくなる。また、利用者端末２９０４に記憶された管理データを用いて支払を行うので、クレジットカードのようにその後の返済などについて心配する必要がない。したがって、利用者は簡便な操作で管理データを用いて支払を行うことができる。これにより、インターネットなどでの支払を安全かつ簡便に行うことができる。
【図面の簡単な説明】
【０２４６】
【図１】本発明の一実施形態に係る電子商取引システムの概要を示す図である。
【図２】計算機のハードウェアとソフトウェアの構成の一例図である。
【図３】本発明の一実施形態に係る利用者端末の機能ブロック図である。
【図４】本発明の一実施形態に係るブラウザの機能ブロック図である。
【図５】クッキー情報の構造の模式図である。
【図６】本発明の一実施形態に係る電子財布の機能ブロック図である。
【図７】コンテンツのタイプとアプリケーションプログラムとを関連付ける表の一例図である。
【図８】本発明の一実施形態に係る利用者端末の動作を説明するフローチャートである。
【図９】本発明の一実施形態に係るショップサーバの機能ブロック図である。
【図１０】本発明の一実施形態に係るショップサーバのＵＲＬ転送部が管理する表の一例図である。
【図１１】本発明の一実施形態に係るショップサーバにおける処理を説明するフローチャートである。
【図１２】本発明の一実施形態に係るショップサーバにおける処理を説明するフローチャートである。
【図１３】本発明の一実施形態に係る確認サーバで行われる処理を説明するフローチャートである。
【図１４】本発明の一実施形態に係る電子商取引システムの全体の処理を説明するシーケンス図である。
【図１５】本発明の一実施形態に係る管理サーバの機能ブロック図である。
【図１６】本発明の一実施形態における管理データ発行の具体例を説明する図である。
【図１７】本発明の一実施形態に係る管理サーバの処理のフローチャートである。
【図１８】本発明の一実施形態における照合用データの書き換えの具体例を説明する図である。
【図１９】本発明の一実施形態に係る管理サーバの処理のフローチャートである。
【図２０】本発明の一実施形態に係る管理サーバ、決済サーバ、保管サーバ及び利用者端末からなるシステム構成図である。
【図２１】本発明の一実施形態に係る管理サーバ、決済サーバ、保管サーバ及び利用者端末からなるシステムによる処理のシーケンス図である。
【図２２】本発明の一実施形態に係る保管サーバの機能ブロック図である。
【図２３】本発明の一実施形態における管理データを保管するためのテーブルの一例図である。
【図２４】本発明の一実施形態における保管データ発行の具体例を説明する図である。
【図２５】本発明の一実施形態における保管データ発行の具体例を説明する図である。
【図２６】本発明の一実施形態に係る利用者間で管理データを譲渡するシステムの構成図である。
【図２７】本発明の一実施形態に係る利用者間で管理データを譲渡するシステムによる処理のシーケンス図である。
【図２８】本発明の一実施形態に係る利用者間で管理データを譲渡するシステムによる処理のシーケンス図である。
【図２９】本発明の一実施形態に係る管理サーバ、決済サーバ、保管サーバ及び利用者端末からなるシステム構成図である。
【図３０】本発明の一実施形態において決済処理が行われ管理データが生成されて利用者端末に受信されるまでの処理のシーケンス図である。
【図３１】本発明の一実施形態に係る利用者端末の画面表示を示す図である。
【図３２】本発明の一実施形態に係る利用者端末の画面表示を示す図である。
【図３３】本発明の一実施形態に係る管理サーバが保持するテーブルの構成と内容の遷移を示す図である。
【図３４】本発明の一実施形態に係る利用者端末の機能ブロック図である。
【図３５】本発明の一実施形態において決済処理が行われ管理データが生成されて利用者端末に受信されるまでの処理のシーケンス図である。
【図３６】本発明の一実施形態に係る利用者端末の画面表示を示す図である。
【図３７】本発明の一実施形態に係る管理データ管理アプリケーションの機能ブロック図である。
【図３８】本発明の一実施形態に係る利用者端末から販売サーバへ管理データを譲渡する処理のシーケンス図である。
【図３９】本発明の一実施形態における商品などの購入の申込を行うための画面の一例図である。
【特許請求の範囲】
【請求項１】
ブラウザがインストールされている利用者端末と、ＨＴＴＰ要求を処理する第１と第２のサーバ装置を有するシステムの動作方法であって、
前記ブラウザは、前記第１のサーバ装置へ第１のＨＴＴＰ要求を送信し、
前記第１のサーバ装置は、前記第２のサーバ装置への第１のアクセス命令を返信し、
前記ブラウザは、前記第１のアクセス命令に従って前記第２のサーバ装置へ第２のＨＴＴＰ要求を送信し、
前記第２のサーバ装置は、前記第２のＨＴＴＰ要求とともに所定のクッキー情報が受信されるか否かに依存して返信される第２のアクセス命令を返信し、
前記ブラウザは、前記第２のアクセス命令に従って前記第１のサーバ装置への第３のＨＴＴＰ要求を送信し、
前記第１のサーバ装置は、前記第３のＨＴＴＰ要求が、前記第２のサーバ装置が前記第２のＨＴＴＰ要求とともに所定のクッキー情報を受信していない場合に返信する第２のアクセス命令に従ったＨＴＴＰ要求である場合に、前記所定のクッキー情報を前記利用者端末に記憶させるプログラムをダウンロードするためのリンク情報を含む返信を行う、システムの動作方法。
【請求項２】
前記プログラムが前記利用者端末にインストールされると、所定の種類のコンテンツと前記プログラムとが関連付けられ、前記所定の種類のコンテンツを前記ブラウザが受信すると、前記ブラウザはそのコンテンツを前記プログラムに入力可能となり、また、前記ブラウザの管理する記憶領域に前記所定のクッキー情報が記憶され、
前記第１のサーバ装置は、前記第３のＨＴＴＰ要求が、前記第２のサーバ装置が前記第２のＨＴＴＰ要求とともに所定のクッキー情報を受信している場合に返信される第２のアクセス命令に従ったＨＴＴＰ要求である場合に、前記所定の種類のコンテンツをダウンロードするためのリンク情報を含む返信を行う請求項１に記載の、システムの動作方法。
【請求項３】
前記第２のアクセス命令に含まれるＵＲＬにはパラメータが含まれており、
前記第２のアクセス命令に従った前記第１のサーバ装置へ送信されるＨＴＴＰ要求の返信には、前記利用者端末に、前記ブラウザが前記利用者端末のメモリに記憶した前記ＵＲＬの全てまたは一部を取得させ、前記ＵＲＬに含まれる前記パラメータの値を変数に記憶させ、前記変数の値を所定の値と比較させ、前記他のプログラムがインストールされているかどうか判断させる第２のプログラムが含まれている請求項２に記載の、システムの動作方法。
【請求項４】
前記プログラムは、価値が関連付けられた情報を管理する電子財布であり、
前記コンテンツは、前記電子財布が管理するべき価値が関連付けられた情報と、前記電子財布が管理する価値が関連付けられた情報の一部または全てとの送信先と、のいずれか一以上を含む、請求項２または３に記載の、システムの動作方法。
【請求項５】
利用者端末より第１のＨＴＴＰ要求を受信する第１要求受信部と、
受信された第１のＨＴＴＰ要求に対して、前記第１のＨＴＴＰ要求とは別のＵＲＬへの第１のアクセス命令を返信する返信部と、
返信された第１のアクセス命令に応じて前記利用者端末が返信として受信した第２のアクセス命令に応じて前記利用者端末より第２のＨＴＴＰ要求を受信する第２要求受信部と、
第２のＨＴＴＰ要求に対する応答を行う応答部と、
を有するサーバ装置。
【請求項６】
前記利用者端末は、前記第１のアクセス命令に応じて送信するＨＴＴＰ要求とともに送信するクッキー情報を記憶し、
前記返信部による第１のアクセス命令による前記別のＵＲＬへのアクセスを前記利用者端末が行うと、前記クッキー情報が送信される請求項５に記載のサーバ装置。
【請求項１】
ブラウザがインストールされている利用者端末と、ＨＴＴＰ要求を処理する第１と第２のサーバ装置を有するシステムの動作方法であって、
前記ブラウザは、前記第１のサーバ装置へ第１のＨＴＴＰ要求を送信し、
前記第１のサーバ装置は、前記第２のサーバ装置への第１のアクセス命令を返信し、
前記ブラウザは、前記第１のアクセス命令に従って前記第２のサーバ装置へ第２のＨＴＴＰ要求を送信し、
前記第２のサーバ装置は、前記第２のＨＴＴＰ要求とともに所定のクッキー情報が受信されるか否かに依存して返信される第２のアクセス命令を返信し、
前記ブラウザは、前記第２のアクセス命令に従って前記第１のサーバ装置への第３のＨＴＴＰ要求を送信し、
前記第１のサーバ装置は、前記第３のＨＴＴＰ要求が、前記第２のサーバ装置が前記第２のＨＴＴＰ要求とともに所定のクッキー情報を受信していない場合に返信する第２のアクセス命令に従ったＨＴＴＰ要求である場合に、前記所定のクッキー情報を前記利用者端末に記憶させるプログラムをダウンロードするためのリンク情報を含む返信を行う、システムの動作方法。
【請求項２】
前記プログラムが前記利用者端末にインストールされると、所定の種類のコンテンツと前記プログラムとが関連付けられ、前記所定の種類のコンテンツを前記ブラウザが受信すると、前記ブラウザはそのコンテンツを前記プログラムに入力可能となり、また、前記ブラウザの管理する記憶領域に前記所定のクッキー情報が記憶され、
前記第１のサーバ装置は、前記第３のＨＴＴＰ要求が、前記第２のサーバ装置が前記第２のＨＴＴＰ要求とともに所定のクッキー情報を受信している場合に返信される第２のアクセス命令に従ったＨＴＴＰ要求である場合に、前記所定の種類のコンテンツをダウンロードするためのリンク情報を含む返信を行う請求項１に記載の、システムの動作方法。
【請求項３】
前記第２のアクセス命令に含まれるＵＲＬにはパラメータが含まれており、
前記第２のアクセス命令に従った前記第１のサーバ装置へ送信されるＨＴＴＰ要求の返信には、前記利用者端末に、前記ブラウザが前記利用者端末のメモリに記憶した前記ＵＲＬの全てまたは一部を取得させ、前記ＵＲＬに含まれる前記パラメータの値を変数に記憶させ、前記変数の値を所定の値と比較させ、前記他のプログラムがインストールされているかどうか判断させる第２のプログラムが含まれている請求項２に記載の、システムの動作方法。
【請求項４】
前記プログラムは、価値が関連付けられた情報を管理する電子財布であり、
前記コンテンツは、前記電子財布が管理するべき価値が関連付けられた情報と、前記電子財布が管理する価値が関連付けられた情報の一部または全てとの送信先と、のいずれか一以上を含む、請求項２または３に記載の、システムの動作方法。
【請求項５】
利用者端末より第１のＨＴＴＰ要求を受信する第１要求受信部と、
受信された第１のＨＴＴＰ要求に対して、前記第１のＨＴＴＰ要求とは別のＵＲＬへの第１のアクセス命令を返信する返信部と、
返信された第１のアクセス命令に応じて前記利用者端末が返信として受信した第２のアクセス命令に応じて前記利用者端末より第２のＨＴＴＰ要求を受信する第２要求受信部と、
第２のＨＴＴＰ要求に対する応答を行う応答部と、
を有するサーバ装置。
【請求項６】
前記利用者端末は、前記第１のアクセス命令に応じて送信するＨＴＴＰ要求とともに送信するクッキー情報を記憶し、
前記返信部による第１のアクセス命令による前記別のＵＲＬへのアクセスを前記利用者端末が行うと、前記クッキー情報が送信される請求項５に記載のサーバ装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【公開番号】特開２０１０−１５２７３５（Ｐ２０１０−１５２７３５Ａ）
【公開日】平成２２年７月８日（２０１０．７．８）
【国際特許分類】
【出願番号】特願２００８−３３１２５９（Ｐ２００８−３３１２５９）
【出願日】平成２０年１２月２５日（２００８．１２．２５）
【出願人】（３９７０７６３６１）有限会社アプリコシステム (5)
【出願人】（３０８０００２０７）有限会社エックス (3)
【Ｆターム（参考）】
【公開日】平成２２年７月８日（２０１０．７．８）
【国際特許分類】
【出願日】平成２０年１２月２５日（２００８．１２．２５）
【出願人】（３９７０７６３６１）有限会社アプリコシステム (5)
【出願人】（３０８０００２０７）有限会社エックス (3)
【Ｆターム（参考）】
[ Back to top ]