(57)【要約】【課題】小額取引の詳細を記録することなく決済回数を少なくする安全な決済方法及びその装置を提供するようにする。【解決手段】ユーザ毎の購入情報を蓄積する購入情報蓄積手段と、ユーザ端末からの新たな購入申込に基づいて、前記購入情報蓄積手段に蓄積された購入情報をユーザ端末に送信する購入情報送信手段と、前記ユーザ端末により前記新たな購入申込分を加えて送信された購入情報を検証する追加購入情報検証手段と、前記追加購入情報検証手段により検証された購入情報に基づいて、前記購入情報蓄積手段に蓄積された購入情報を更新する購入情報処理手段と、前記購入情報蓄積手段に蓄積された購入情報に基づいて、販売店署名を生成する販売店署名生成手段と、前記購入情報蓄積手段に蓄積された購入情報と、前記販売店署名生成手段により生成された販売店署名とに基づいて作成した購入情報を、金融機関サーバに送信する決済送信手段とを備える構成にする。【選択図】        図１
2005018706.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ毎の購入情報を蓄積する購入情報蓄積手段と、
ユーザ端末からの新たな購入申込に基づいて、前記購入情報蓄積手段に蓄積された購入情報をユーザ端末に送信する購入情報送信手段と、
前記ユーザ端末により前記新たな購入申込分を加えて送信された購入情報を検証する追加購入情報検証手段と、
前記追加購入情報検証手段により検証された購入情報に基づいて、前記購入情報蓄積手段に蓄積された購入情報を更新する購入情報処理手段と、
前記購入情報蓄積手段に蓄積された購入情報に基づいて、販売店署名を生成する販売店署名生成手段と、
前記購入情報蓄積手段に蓄積された購入情報と、前記販売店署名生成手段により生成された販売店署名とに基づいて作成した購入情報を、金融機関サーバに送信する決済送信手段と
を備えることを特徴とする販売店サーバ。
【請求項２】
前記追加購入情報検証手段は、前記購入情報として販売店名と決済日と購入金額合計と前記ユーザ端末によるユーザ署名とを有し、前記販売店名と前記決済日及び前記購入金額合計の確認を行い、前記ユーザ署名の検証を行うこと
を特徴とする請求項１記載の販売店サーバ。
【請求項３】
販売店サーバに購入申込を送信する購入申込送信手段と、
販売店サーバから送信された購入情報を検証する購入情報検証手段と、
前記購入情報検証手段により検証された購入情報に基づいて、新たな購入申込分を加えた購入金額の合計を算出する購入金額合計算出手段と、
前記購入情報検証手段により検証された購入情報と、前記購入金額合計算出手段により算出された購入金額合計とに基づいて、ユーザ署名を生成するユーザ署名生成手段と、
前記購入情報検証手段により検証された購入情報と、前記ユーザ署名生成手段により生成されたユーザ署名とに基づいて、前記購入申込分を追加した購入情報を販売店サーバに送信する追加購入情報送信手段と
を備えることを特徴とするユーザ端末。
【請求項４】
前記購入情報検証手段は、前記購入情報として販売店名と決済日と購入金額合計と前記ユーザ署名生成手段により生成されたユーザ署名とを有し、前記販売店名と前記決済日及び前記購入金額合計の確認を行い、前記ユーザ署名の検証を行うこと
を特徴とする請求項３記載のユーザ端末。
【請求項５】
販売店サーバにより送信されたユーザ毎の購入情報を検証する決済検証手段と、
前記決済検証手段により検証された購入情報に基づいて、決済処理を行う決済処理手段と
を備えることを特徴とする金融機関サーバ。
【請求項６】
前記決済検証手段は、前記購入情報として販売店名と決済日と購入金額合計とユーザ端末によるユーザ署名と販売店サーバによる販売店署名とを有し、前記販売店名と前記決済日及び前記購入金額合計の確認を行い、前期ユーザ署名及び販売店署名の検証を行うこと
を特徴とする請求項５記載の金融機関サーバ。
【請求項７】
前記購入情報蓄積手段は、前記購入情報として販売店名と決済日と購入金額合計と前記ユーザ署名生成手段により生成されたユーザ署名とを有すること、
前記購入金額合計が基準額に達しているか否かを確認する購入金額合計確認手段を備えること、
前記購入情報処理手段は、前記購入金額合計確認手段による確認結果に基づいて、前記購入情報に既に含まれる決済日を残し、さらに新たな決済日を追加すること
を特徴とする請求項１記載の販売店サーバ。
【請求項８】
ユーザ毎の購入情報を蓄積するステップと、
販売店サーバに購入申込を送信するステップと、
ユーザ端末からの前記購入申込に基づいて、前記蓄積された購入情報をユーザ端末に送信するステップと、
販売店サーバから送信された購入情報を検証するステップと、
前記検証された購入情報に基づいて、前記購入申込分を加えた購入金額の合計を算出するステップと、
前記検証された購入情報と、前記算出された購入金額合計とに基づいて、ユーザ署名を生成するステップと、
前記検証された購入情報と、前記生成されたユーザ署名とに基づいて、前記購入申込分を追加した購入情報を販売店サーバに送信するステップと、
前記ユーザ端末により前記購入申込分を加えて送信された購入情報を検証するステップと、
前記検証された購入情報に基づいて、前記蓄積された購入情報を更新するステップと、
前記蓄積された購入情報に基づいて、販売店署名を生成するステップと、
前記蓄積された購入情報と、前記生成された販売店署名とに基づいて作成した購入情報を、金融機関サーバに送信するステップと、
販売店サーバにより送信されたユーザ毎の購入情報を検証するステップと、
前記検証された購入情報に基づいて、決済処理を行うステップと
を備えることを特徴とする決済方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、通信装置を利用した商品購入における決済方法及びその装置に関するものである。
【０００２】
【従来の技術】
インターネット上のオンラインショップでの商品購入の決済手段としてクレジットカードの利用が増加してきているが、小額の商品を購入する場合には購入金額に比べてクレジットカードの決済手数料が高額であるといった問題がある。この問題を解決するものとして、例えば特開２００２−１５２５９号公報のような、複数の小額取引を取りまとめることにより決済回数を減らしてクレジットカードで決済を行う方法が提案されている。
【０００３】
【特許文献１】
特開２００２−１５２５９号公報
【０００４】
【発明が解決しようとする課題】
従来の決済方法においても、複数の取引の金額を取りまとめることにより決済数を減らすことができる。しかし、不正に決済が行われないようにするには販売店側、ユーザー側双方が取引の履歴を管理し、決済額を確認しなければならない。小額の取引は高額の取引と比べて取引回数が大幅に多くなることが予想されるため、販売店側のシステムの容量の問題や、ユーザー側がすべてを確認するのは困難であるという問題がある。このため、取引の詳細をすべて記録していなくても不正を行うことができないような仕組みが必要である。
【０００５】
この発明は、小額取引の詳細を記録することなく決済回数を少なくする安全な決済方法及びその装置を提供することを目的とする。
【０００６】
【課題を解決するための手段】
この発明に係る販売店サーバは、ユーザ毎の購入情報を蓄積する購入情報蓄積手段と、ユーザ端末からの新たな購入申込に基づいて、前記購入情報蓄積手段に蓄積された購入情報をユーザ端末に送信する購入情報送信手段と、前記ユーザ端末により前記新たな購入申込分を加えて送信された購入情報を検証する追加購入情報検証手段と、前記追加購入情報検証手段により検証された購入情報に基づいて、前記購入情報蓄積手段に蓄積された購入情報を更新する購入情報処理手段と、前記購入情報蓄積手段に蓄積された購入情報に基づいて、販売店署名を生成する販売店署名生成手段と、前記購入情報蓄積手段に蓄積された購入情報と、前記販売店署名生成手段により生成された販売店署名とに基づいて作成した購入情報を、金融機関サーバに送信する決済送信手段とを備えるものである。
【０００７】
【発明の実施の形態】
実施の形態１．
図１は、本発明の実施の形態１における決済システムの構成を示す説明図である。
図１において、１は商品を購入する利用者が使用するユーザ端末、２は購入や決済に関する処理を利用者や金融機関と行う販売店サーバ、３は決済処理を行う金融機関サーバである。また、ユーザ端末１と販売店サーバ２とはインターネット４で接続され、販売店サーバ２と金融機関サーバ３とは専用線５で接続され、販売店サーバ２は、ユーザ毎の購入情報を蓄積する購入情報ＤＢ２１を接続する。例えば、購入情報ＤＢ２１はソフトウェアで実現する。
【０００８】
また、ユーザ端末１は、商品購入の申込みを販売店サーバ２に送信する申込送信手段１１と、販売店サーバ２から送られてくる購入情報を検証する購入情報検証手段１２と、購入する商品の合計金額を算出する購入金額合計算出手段１３と、ユーザ署名を生成するユーザ署名生成手段１４と、新たな購入情報を送信する追加購入情報送信手段１５とを備える。ユーザ端末１として、例えばパーソナルコンピュータ（ＰＣ）などが考えられる。
また、販売店サーバ２は、ユーザ端末１に購入情報を送信する購入情報送信手段２２と、ユーザ端末１から送られてくる新たな購入情報を検証する追加購入情報検証手段２３と、購入情報ＤＢ２１の内容を更新する購入情報処理手段２４と、販売店署名を生成する販売店署名生成手段２５と、決済の情報を金融機関サーバ３へ送信する決済送信手段２６とを備える。
また、金融機関サーバ３は、販売店サーバ２から送られてくる決済の情報を検証する決済検証手段３１と、決済の処理を行う決済処理手段３２とを備える。
また、ユーザ端末１、販売店サーバ２には、公開鍵暗号方式に基づく公開鍵と秘密鍵及び認証局が発行した公開鍵証明書とルート証明書とが保持されており、金融機関サーバ３には、ルート証明書が保持されている。なお、公開鍵暗号方式は一般的な暗号方式のため、本実施の形態１では詳細な動作の説明は省略する。
【０００９】
図２は、実施の形態１における決済システムの動作シーケンスを示す説明図である。
以下に、図１及び図２を用いて、ユーザがインターネットを使用して商品を購入する処理の動作を説明する。
ステップＳ１において、ユーザ端末１の申込送信手段１１は、販売店サーバ２に対して商品の購入の申込み（データＤ１）を送信する。
【００１０】
ステップＳ２において、ユーザ端末１から購入申込みを受け取った販売店サーバ２の購入情報処理手段２４は、購入情報ＤＢ２１からユーザを検索し、販売店名と蓄積されている合計金額、決済日、ユーザ署名とをデータＤ２としてユーザ端末１に送信する。合計金額が０の場合にはユーザ署名は購入情報ＤＢ２１に格納されていないため送信しない（合計金額０と決済日のみ送信）。
【００１１】
ステップＳ３において、ユーザ端末１の購入情報検証手段１２は、販売店サーバ２から送信されたデータＤ２のユーザ署名を検証して販売店名と決済日と合計金額とを確認する。購入金額合計算出手段１３は、購入申込みを行った商品の購入金額を加算する。これらの処理に基づいて、ユーザ署名生成手段１４は再度ユーザ署名を生成し、追加購入情報送信手段１５は販売店サーバ３にデータＤ３を送信する。
【００１２】
ステップＳ４において、販売店サーバ２の追加購入情報検証手段２３は、ユーザ端末１から受け取ったデータＤ３中のユーザ署名を検証する。販売店名と決済日と合計金額とを確認して正しければ、購入情報処理手段２４は合計金額とユーザ署名とを購入情報ＤＢ２１に格納し、サービスを提供する。
【００１３】
決済日までステップＳ１からステップＳ４を繰り返すことにより、購入情報ＤＢ２１に蓄積された合計金額とユーザ署名とを更新する。
【００１４】
決済日になったら、ステップＳ５において、販売店サーバ２の決済送信手段２６は、ユーザごとに購入情報ＤＢ２１からユーザ名、決済日、合計金額、ユーザ署名を取り出し、販売店署名生成手段２５により生成した販売店署名を添付したデータＤ４を金融機関サーバ３に送信する。
【００１５】
ステップＳ６において、金融機関サーバ３の決済検証手段３１は、販売店サーバ２から送信されたデータＤ４中の決済日を確認し、販売店署名とユーザ署名とを検証し、販売店名、ユーザ名、決済日、金額合計を確認する。決済検証手段３１により正しいことが確認されれば、決済処理手段３２は、決済処理を行う。
なお、通常決済処理手段３２により処理された決済は、販売店サーバ２、ユーザ端末１に伝えられる（図示せず）。
【００１６】
次に、図２におけるステップＳ２〜Ｓ６における詳細な動作について説明する。ステップ１については、上記記載の通りであるため、詳細な動作の説明は省略する。
【００１７】
図３は、購入情報ＤＢ２１に蓄積される購入情報のデータ構造を示す説明図である。購入情報ＤＢ２１には、ユーザ毎に、ユーザ名Ｕ、合計金額Ｃ、決済日Ｔ、ユーザ署名ＳＵが蓄積される。合計金額Ｃの初期値は０である。
ステップＳ２において、販売店サーバ２の購入情報処理手段２４は、ユーザ端末１から送信された購入申込みであるデータＤ１に基づいて、購入情報ＤＢ２１からユーザ名Ｕを検索し、販売店名Ｍと蓄積されている合計金額Ｃ、決済日Ｔ、ユーザ署名ＳＵとをデータＤ２としてユーザ端末１に送信する。合計金額が０の場合にはユーザ署名は購入情報ＤＢ２１に格納されていないため送信しない。
【００１８】
図４、図５は、データＤ２のデータ構造を示した説明図である。図４は合計金額が０の場合、図５は合計金額が０でない場合のデータＤ２のデータ構造を示している。
【００１９】
図６は、ユーザ端末１のステップＳ３の処理を示すフローチャートである。以下に、ユーザ端末１のステップＳ３の詳細な動作について説明する。
図６におけるステップＳ３１において、購入情報検証手段１２は、販売店サーバ２からデータＤ２を受信する。
ステップＳ３２において、購入情報検証手段１２は、データＤ２の販売店名Ｍを確認し、購入する販売店と一致しなければ終了する（ステップＳ３２でＮｏ）。
ステップＳ３３において、購入情報検証手段１２は、データＤ２の決済日Ｔを確認し、過去の日付であれば終了する（ステップＳ３３でＮｏ）。
ステップＳ３４において、購入情報検証手段１２は、データＤ２の合計金額Ｃが０であればステップＳ３６に進む（ステップＳ３４でＹｅｓ）。
ステップＳ３５において、購入情報検証手段１２は、データＤ２のユーザ署名ＵＳを検証し、検証に失敗した場合には終了する（ステップＳ３５でＮｏ）。
ステップＳ３６において、購入金額合計算出手段１３は、データＤ２の合計金額Ｃに今回の購入金額を加算したＣ’を計算する。
ステップＳ３７において、ユーザ署名生成手段１４は、販売店名Ｍと決済日Ｔと加算後の合計金額Ｃ’とに対するユーザ署名ＳＵ’を生成する。
ステップＳ３８において、追加購入情報送信手段１５は、販売店名Ｍと決済日Ｔと加算後の合計金額Ｃ’とユーザ署名ＳＵ’とからなるデータＤ３を販売店サーバ２に送信する。
【００２０】
図７は、データＤ３のデータ構造を示した説明図である。販売店サーバ２より送信されたデータＤ２と比較して、合計金額Ｃ’とユーザ署名ＳＵ’とが更新されている。
【００２１】
図８は、販売店サーバ２のステップＳ４の処理を示すフローチャートである。以下に、販売店サーバ２のステップＳ４の詳細な動作について説明する。
図８におけるステップＳ４１において、追加購入情報検証手段２３は、ユーザ端末１からデータＤ３を受信する。
ステップＳ４２において、追加購入情報検証手段２３は、受信したデータＤ３の販売店名Ｍを確認し、自身の販売店名と一致しなければ終了する（ステップＳ４２でＮｏ）。
ステップＳ４３において、追加購入情報検証手段２３は、受信したデータＤ３の決済日Ｔを確認し、データＤ２で送信した日付と一致しなければ終了する（ステップＳ４３でＮｏ）。
ステップＳ４４において、追加購入情報検証手段２３は、受信したデータＤ３の合計金額Ｃ’が、データＤ２で送信した合計金額Ｃに今回の購入金額が正しく加算された値でなければ終了する（ステップＳ４４でＮｏ）。
ステップＳ４５において、追加購入情報検証手段２３は、受信したデータＤ３のユーザ署名ＳＵ’を検証し、検証に失敗した場合は終了する（ステップＳ４５でＮｏ）。
ステップＳ４６において、購入情報処理手段２４は、データＤ３の合計金額Ｃ’とユーザ署名ＳＵ’とに基づいて、購入情報ＤＢ２１のデータを更新する。
【００２２】
決済日ＴまでステップＳ１からステップＳ４を繰り返すことにより、合計金額Ｃ’とユーザ署名ＳＵ’とに基づいて、購入情報ＤＢ２１に蓄積されたデータを更新する。
その後、決済日になったら、ステップＳ５において、販売店サーバ２の決済送信手段２６は、ユーザごとに購入情報ＤＢ２１からユーザ名Ｕ、決済日Ｔ、合計金額Ｃ、ユーザ署名ＳＵを取り出し、販売店署名生成手段２５により生成した販売店署名を添付したデータＤ４を金融機関サーバ３に送信する。
図９は、データＤ４のデータ構造を示した説明図である。
【００２３】
図１０は、金融機関サーバ３のステップＳ６の処理を示すフローチャートである。以下に金融機関サーバ３のステップＳ６の詳細な動作について説明する。
図１０におけるステップＳ６１において、決済検証手段３１は、販売店サーバ２からデータＤ４を受信する。
ステップＳ６２において、決済検証手段３１は、データＤ４の販売店名Ｍが送信されてきた販売店と一致しなければ処理を終了する（ステップＳ６２でＮｏ）。
ステップＳ６３において、決済検証手段３１は、データＤ４の決済日Ｔが不正であれば処理を終了する（ステップＳ６３Ｎｏ）。
ステップＳ６４において、決済検証手段３１は、データＤ４の販売店署名ＳＭを検証し、検証に失敗した場合は終了する（ステップＳ６４Ｎｏ）。
ステップＳ６５おいて、決済検証手段３１は、データＤ４のユーザ署名ＳＵを検証し、検証に失敗した場合は終了する（ステップＳ６５Ｎｏ）。
ステップＳ６６おいて、決済処理手段３２は、ユーザＵに対する合計金額Ｃの決済処理を行う。
【００２４】
以上説明したように、ユーザ端末により生成された署名を用いて、販売店サーバの購入情報を更新することにより、複数の取引をまとめて決済することができ、小額取引もクレジットカード決済できるという効果を得ることができる。
【００２５】
また、販売店サーバではユーザ端末からの署名を検証して購入情報を更新することにより、個々の取引の詳細な情報（履歴）を保持する必要がないため、小規模な容量のシステムでも対応でき、かつ安全に小額取引の決済処理を行うことができる。
【００２６】
また、ユーザ端末では自装置が販売店サーバに送付した購入情報を販売店サーバから受け取って検証し、正しければ新たな購入分を追加して署名を生成して販売店サーバに送付することにより、ユーザ端末で購入情報（履歴を含む）を保持する必要がないため、携帯電話やＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）等のような携帯端末でも、安全に小額取引の決済処理を行うことができる。
【００２７】
また、本実施の形態１では金融機関及び販売店においてサーバを用いる場合について説明したが、上記のような機能を備えていればどのような装置であってもよく、これに限られない。
【００２８】
実施の形態２．
上記実施形態１では、決済日になったら決済処理を行う場合について説明したが、本実施の形態２では、購入金額合計によって決済処理を延長可能とする場合について説明する。
【００２９】
図１１は、本実施の形態２における決済システムの構成を示す説明図である。上記実施の形態１とは、販売店サーバ２が購入金額合計確認手段２７を備える点が異なる。その他の構成については上記実施の形態１と同様であるが、決済処理を延長可能とするために、決済システムの各装置で扱うデータのデータ構造とそれに伴う動作を、上記実施の形態１から変更している。
図１２は、本実施の形態２における購入情報ＤＢ２５に蓄積される購入情報のデータ構造を示す説明図である。
【００３０】
以下に動作について説明する。
ステップＳ１、Ｓ２においては、データ構造が異なる以外は上記実施の形態１と同様である。
図１３は、本実施の形態２におけるデータＤ２のデータ構造を示す説明図である。
図６のステップＳ３のフローチャートにおいて、ユーザ端末１の購入情報検証手段１２は、販売店サーバ２から受信したデータＤ２中の決済日のリストのうち、最新の日付を決済日として扱う点が、上記実施の形態１と異なり、その他は同様である。例えば図１３の例では、決済日のリストが「Ｔ、Ｔ’、Ｔ”…」とあるが、このうち最新の決済日であるＴを決済日としてステップＳ３の処理を行う。
【００３１】
図１４は、本実施の形態２におけるデータＤ３のデータ構造を示す説明図である。
図８のステップＳ４のフローチャートにおいて、販売店サーバ２の追加購入情報検証手段２３は、ユーザ端末１から受信したデータＤ３中の決済日のリストのうち、最新の日付を決済日として扱う点が、上記実施の形態１と異なり、その他は同様である。例えば図１４の例では、決済日のリストが「Ｔ、Ｔ’、Ｔ”…」とあるが、このうち最新の決済日であるＴを決済日としてステップＳ４の処理を行う。
【００３２】
決済日ＴまでステップＳ１からステップＳ４を繰り返すことにより、合計金額Ｃ’とユーザ署名ＳＵ’とに基づいて、購入情報ＤＢ２１に蓄積されたデータを更新する点も、上記実施の形態１と同様である。
図１５は、本実施の形態２におけるデータＤ４のデータ構造を示す説明図である。
ステップＳ５において、決済日になると、販売店サーバ２の購入金額合計確認手段２７は、例えば販売店毎に予め決定している基準額に、購入した合計金額が達しているか否かを確認する。
基準額に達している場合、販売店サーバ２は、最新の決済日であるＴを決済日として、上記実施の形態１と同様の処理を行う。
基準額に達していない場合、購入情報処理手段２４は、次回の決済日を購入情報ＤＢ２１の決済日のリストに追加して終了する。例えば、図１２のような購入情報ＤＢ２１の購入情報において、決済日Ｔに基準額に達していない場合、図１６のように次回の決済日ｔを、購入情報ＤＢ２１の決済日のリストに追加する。その後は、最新の決済日であるｔを決済日として上記処理を行う。
【００３３】
図１７は、本実施の形態２における金融機関サーバ３のステップＳ６の処理を示すフローチャートである。図１７において、ステップＳ６０１が上記実施の形態１と異なる動作である。金融機関サーバ３の決済検証手段３１は、決済日のリストに含まれる過去の決済日に、決済が行われているか否かを確認する。決済日のリストに含まれる過去の決済日に決済が行われている場合は、一部二重決済が行われることになるため、処理を終了する（ステップＳ６０１でＮｏ）。
【００３４】
以上説明したように、販売店サーバにおいて、決済日になると予め決定している基準額に購入した合計金額が達しているか否かを確認し、基準額に達していない場合は決済を行わずに、次の決済日を設定することにより、さらに決済回数を少なくすることができ、複数の取引の金額をとりまとめても決済金額が小さい場合でも対応できるという効果がある。
【００３５】
また、決済せずに繰り越した場合の決済日をリストとしてデータ中に含めることにより、二重の決済を防止できるという効果がある。
【００３６】
【発明の効果】
以上のように、ユーザ毎の購入情報を蓄積する購入情報蓄積手段と、ユーザ端末からの新たな購入申込に基づいて、前記購入情報蓄積手段に蓄積された購入情報をユーザ端末に送信する購入情報送信手段と、前記ユーザ端末により前記新たな購入申込分を加えて送信された購入情報を検証する追加購入情報検証手段と、前記追加購入情報検証手段により検証された購入情報に基づいて、前記購入情報蓄積手段に蓄積された購入情報を更新する購入情報処理手段と、前記購入情報蓄積手段に蓄積された購入情報に基づいて、販売店署名を生成する販売店署名生成手段と、前記購入情報蓄積手段に蓄積された購入情報と、前記販売店署名生成手段により生成された販売店署名とに基づいて作成した購入情報を、金融機関サーバに送信する決済送信手段とを備えることにより、小額取引の詳細を記録することなく決済回数を少なくする安全な決済を実現することができる。
【図面の簡単な説明】
【図１】決済システムの構成を示す説明図
【図２】決済システムの動作シーケンスを示す説明図
【図３】購入情報ＤＢ２１に蓄積される購入情報のデータ構造を示す説明図
【図４】合計金額が０の場合のデータＤ２のデータ構造を示した説明図
【図５】合計金額が０でない場合のデータＤ２のデータ構造を示した説明図
【図６】ユーザ端末１のステップＳ３の処理を示すフローチャート
【図７】データＤ３のデータ構造を示した説明図
【図８】販売店サーバ２のステップＳ４の処理を示すフローチャート
【図９】データＤ４のデータ構造を示した説明図
【図１０】金融機関サーバ３のステップＳ６の処理を示すフローチャート
【図１１】実施の形態２における決済システムの構成を示す説明図
【図１２】実施の形態２における購入情報ＤＢ２５に蓄積される購入情報のデータ構造を示す説明図
【図１３】実施の形態２におけるデータＤ２のデータ構造を示す説明図
【図１４】実施の形態２におけるデータＤ３のデータ構造を示す説明図
【図１５】実施の形態２におけるデータＤ４のデータ構造を示す説明図
【図１６】実施の形態２における購入情報ＤＢ２５に蓄積される購入情報のデータ構造を示す説明図
【図１７】実施の形態２における金融機関サーバ３のステップＳ６の処理を示すフローチャート
【符号の説明】
１  ユーザ端末
２  販売店サーバ
３  金融機関サーバ
４  インターネット
５  専用線
１１  申込送信手段
１２  購入情報検証手段
１３  購入金額合計算出手段
１４  ユーザ署名生成手段
１５  追加購入情報送信手段
２１  購入情報ＤＢ
２２  購入情報送信手段
２３  追加購入情報検証手段
２４  購入情報処理手段
２５  販売店署名生成手段
２６  決済送信手段
２７  購入金額合計確認手段
３１  決済検証手段
３２  決済処理手段
【図１】
2005018706.tif 000003
【図２】
2005018706.tif 000004
【図３】
2005018706.tif 000005
【図４】
2005018706.tif 000006
【図５】
2005018706.tif 000007
【図６】
2005018706.tif 000008
【図７】
2005018706.tif 000009
【図８】
2005018706.tif 000010
【図９】
2005018706.tif 000011
【図１０】
2005018706.tif 000012
【図１１】
2005018706.tif 000013
【図１２】
2005018706.tif 000014
【図１３】
2005018706.tif 000015
【図１４】
2005018706.tif 000016
【図１５】
2005018706.tif 000017
【図１６】
2005018706.tif 000018
【図１７】
2005018706.tif 000019