(57)【特許請求の範囲】
【請求項１】
情報通信網を介して通信可能な集金側装置と支払側装置とから構成され、前記集金側装置からの支払請求があると、前記支払側装置が、当該支払請求に基づき電子マネーによる自動決済を行う電子マネー自動決済システムであって、
前記支払側装置は、
当該支払側装置の利用者に商品を注文するための項目を入力させてなる注文データに基づいて、その商品について予定された支払金額を含む支払に関する情報である支払予約情報、該支払予約情報に対応した支払予約番号、請求元を確認するためのパスワード、および、注文する商品に関する発注情報を生成する支払予約生成手段と、
該支払予約生成手段により生成された支払予約情報，支払予約番号，パスワードおよび発注情報を対応づけて登録する情報登録手段と、
前記支払予約生成手段によって生成された支払予約番号，発注情報およびパスワードを前記集金側装置へ送信する確認情報送信手段と、
前記集金側装置から支払請求データが送信されると、当該支払請求データに含まれるパスワードが、同支払請求データに含まれる支払予約番号に対応づけて前記情報登録手段が登録したパスワードと一致している場合に、その支払請求データによる請求元が正しいと判定する請求元判定手段と、
前記集金側装置から支払請求データが送信されると、当該支払請求データに含まれる請求金額が、同支払請求データに含まれる支払予約番号に対応づけて前記情報登録手段が登録した支払予約情報における支払金額と一致している場合に、その支払請求データに係る請求内容が支払予約情報に一致していると判定する請求内容判定手段と、
前記請求元判定手段によって前記請求元が正しいと判定され、かつ、前記請求内容判定手段によって請求内容が支払予約情報に一致していると判定された場合に、当該支払側装置を介した支払を行う利用者のサイバーバンクにおける口座から、前記集金側装置を介した集金を行うサービス提供者のサイバーバンクにおける口座へと、前記請求内容判定手段により一致していると判定された支払金額に相当する電子マネーの振り込みまたは振替を行うことで、支払金額の支払を実行する支払実行手段と、を有しており、
前記集金側装置は、
前記確認情報送信手段によって送信されてくる発注情報に基づいて、注文する商品の請求金額を含む請求情報を作成する請求情報作成手段と、
前記確認情報送信手段によって送信されてくる支払予約番号およびパスワードと、これら情報と共に送信されてくる発注情報に基づいて前記請求情報作成手段が作成した請求情報と、を含むデータとして支払請求データを作成する支払請求作成手段と、
前記支払側装置に対する支払請求を行う際、前記支払請求作成手段により作成された支払請求データを前記支払側装置へ送信する支払請求データ送信手段と、を有する
ことを特徴とする電子マネー自動決済システム。
【請求項２】
請求項１に記載の電子マネー自動決済システムにおいて、
前記支払予約生成手段は、支払上限金額を含む支払予約情報を生成し、
前記請求内容判定手段は、前記支払請求データ送信手段によって送信されてくる支払請求データに含まれる請求金額が、前記支払予約生成手段によって生成された支払予約情報に含まれる支払上限金額を上回っている場合に、その支払請求データに係る請求内容が支払予約情報に一致していないと判定する、よう構成されている
ことを特徴とする電子マネー自動決済システム。
【請求項３】
請求項１〜２のいずれかに記載の電子マネー自動決済システムにおいて、
前記支払予約生成手段は、予定される支払タイミングを含む支払予約情報を生成し、
前記支払実行手段は、前記支払予約生成手段により生成された支払予約情報に含まれる支払タイミングとなっていることを条件に、前記集金側装置へ電子マネーの払い込みを行う、よう構成されている
ことを特徴とする電子マネー自動決済システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えばインターネットに代表されるような情報通信網を介して行われる決済を自動的に行うシステムに関し、特に、情報通信網を介して流通する電子マネーを用いて決済を行うシステムに関する。
【０００２】
【従来の技術】
近年、インターネットが急速に普及するに伴い、ネット社会において料金の決済を行う用途に開発されつつあるものとして電子マネーがある。
ここで「電子マネー」とは、ネット上を流通し、換金自由な電子化通貨である。電子マネーは、例えば金融機関や電子通信事業者等が発行するものであり、通貨に準じた信用力を有しており、ネット上の銀行（以下「サイバーバンク」という。）の口座に貯蓄されるだけでなく、所定形式のデータ群であるため、例えば電子メールに添付してやりとりすることもできる。
【０００３】
ネット社会が発展するにつれ、このような電子マネーを用いたバリュー（貨幣価値）のやり取りが頻繁に行われることが予想される。例えばオンラインショッピングというようなネット上で行われる種々のサービスに対して電子マネーによる決済が主流となってくることが予想される。
【０００４】
【発明が解決しようとする課題】
ところで、ネットワーク上のサービスに対し、サービスを受けた後に電子マネーによる支払いを行う場合を想定する。例えばオンラインショッピングを例に挙げれば、商品の到着を待って商品を確認してから代金を支払うという具合である。このような場合、例えば電子メール等によってサービス提供者側から請求書が送付され、その請求書に従ってサービス利用者が端末を操作し電子マネーによる決済を行うことが考えられるが、このように請求書が電子メールにて送信されてくる度に、利用者が端末を操作して決済を行うのでは労力と時間がかかってしまう。従って、サービス提供者側からの請求書に基づき自動的に決済を行うことが好ましい。
【０００５】
しかしながら、自動的に決済を行うというのは、利用者側が払い込み時に払い込み内容を確認しないことを意味する。つまり、サービス提供者側の一方的な支払請求に基づいて支払いを行うことになるため、意図しない相手に払い込んでしまったり、意図しない払い込みをしてしまったりするというような不都合が生じる可能性が高くなる。
【０００６】
本発明は、上述した問題点を解決するためになされたものであり、異なる支払請求があった場合であっても、各支払請求に応じた電子マネーによる自動決済を可能とし、かつ、意図しない相手に払い込んでしまったり、意図しない払い込みをしてしまったりというような不都合を解消することを目的とする。
【０００７】
【課題を解決するための手段及び発明の効果】
上述した目的を達成するためになされた第１の構成に係る自動決済システムは、情報通信網を介して通信可能な集金側装置と支払側装置とから構成され、集金側装置からの支払請求があると、支払側装置が、当該支払請求に基づき電子マネーによる自動決済を行う電子マネー自動決済システムであって、支払側装置は、予定された支払に関する情報である支払予約情報と、当該支払予約情報に対応した支払予約番号とを生成する支払予約生成手段と、支払予約生成手段によって生成された支払予約情報及び当該支払予約情報に対応する支払予約番号とを記憶するための支払予約記憶手段と、請求元を確認するためのパスワードと支払予約情報に対応する支払予約番号とを集金側装置へ送信する確認情報送信手段と、集金側装置から支払請求データが送信されると、当該支払請求データに含まれるパスワードが、確認情報送信手段によって集金側装置へ送信したものと一致しているか否かを判定する請求元判定手段と、集金側装置から支払請求データが送信されると、当該支払請求データに含まれる支払予約番号によって、支払予約情報記憶手段に記憶された支払予約情報を特定し、支払請求データに基づく請求内容が当該特定した支払予約情報に一致しているか否かを判定する請求内容判定手段と、請求元判定手段によって請求元が正しいと判定され、かつ、請求内容判定手段によって請求内容が支払予約情報に一致していると判定された場合には、集金側装置へ電子マネーの払い込みを行う支払実行手段とを有し、一方、集金側装置は、確認情報送信手段によって送信されてくる支払予約番号及びパスワードを記憶するための確認情報記憶手段と、支払側装置に対する支払請求を行う際、確認情報記憶手段に記憶された支払予約番号及びパスワードを含む支払請求データを送信する支払請求データ送信手段とを有することを特徴とする。
【０００８】
本発明の自動決済システムは、例えばインターネット等の情報通信網と、当該情報通信網を介して通信可能な集金側装置及び支払側装置とから構成される。なお、ここで集金側装置は、サービスを提供するサービス提供者側の装置であり、一方、支払側装置は、サービスを受けるサービス利用者側の装置である。従って、サービス提供者により提供されたサービスの対価を、サービス利用者は、集金側装置からの支払請求に基づき、支払側装置により電子マネーにて集金側装置へ払い込むのであるが、ここで特に、集金側装置と支払側装置との間で以下のようなやり取りが行われ、支払側装置から集金側装置へ自動的に電子マネーが支払われる。
【０００９】
まず、支払側装置では、支払予約情報生成手段が、予定された支払に関する情報である支払予約情報と、当該支払予約情報に対応する支払予約番号とを生成する。この生成された支払予約情報及び支払予約番号は、支払予約情報記憶手段に記憶される。ここで、予定された支払とは、例えばオンラインショッピングを利用して商品を注文した場合の商品到着後の支払等が考えられる。支払予約情報生成手段は、例えば、利用者によって入力された商品の注文データから支払予約情報を生成することが考えられる。このように、支払側装置では、後に発生する支払に関する情報を予め生成して記憶しておく。
【００１０】
そして、支払側装置の確認情報送信手段は、請求元を確認するためのパスワードと、上述した支払予約情報に対応する支払予約番号とを集金側装置へ送信する。例えばオンラインショッピングの例では、商品の注文データと共に、このパスワード及び支払予約番号を送信する。なお、パスワードは、例えばサービス利用者がキーボードなどを介して入力したものであってもよいし、あるいは、支払側装置が自動的に生成したものであってもよい。
【００１１】
一方、集金側装置では、支払側装置の確認情報送信手段によって送信されてくる支払予約番号及びパスワードを確認情報記憶手段に記憶しておく。なお、この段階で、上述したようなオンラインショッピングを例を挙げれば、支払予約番号とパスワードと共に注文データが送信されてくるため、サービス提供者は、注文のあった商品をサービス利用者に発送する。
【００１２】
その後、サービス提供者は、発送した商品の代金を請求するのであるが、このとき、集金側装置の支払請求データ送信手段は、確認情報記憶手段に記憶されたパスワード及び支払予約番号を含む支払請求データを送信する。
支払側装置では、集金側装置から支払請求データが送信されてくると、請求元判定手段が、その支払請求データに含まれるパスワードが以前に集金側装置へ送信したものと一致しているか否かを判定し、請求内容判定手段が、支払予約情報記憶手段に記憶された支払予約情報の中から、その支払請求データに含まれる支払予約番号に対応する支払予約情報を特定し、支払請求データに基づく請求内容が支払予約情報に一致しているか否かを判定する。
【００１３】
そして、支払実行手段は、請求元が正しいと判定され、かつ、請求内容が支払予約情報に一致している場合に、集金側装置へ電子マネーの払い込みを行う。支払実行手段は、支払側装置内に電子マネーが用意されている場合、この電子マネーを直接集金側装置へ送信することも考えられるし、ネット上のサイバーバンクにサービス提供者の電子マネーの口座がある場合には、そのサイバーバンクの口座への振り込み指示をそのサイバーバンクに対して行うことも考えられる。また、支払側装置内に電子マネーが用意されておらず、サービス利用者の電子マネーの口座がネット上のサイバーバンクにある場合、その口座から電子マネーを引き出し、集金側装置へ送信してもよいし、その口座からサービス提供者の口座へ振り替えるようにしてもよい。
【００１４】
このように、本発明の自動決済システムでは、パスワード及び支払予約という概念を取り入れた点を特徴としている。以下、この点について説明し、本発明の発揮する効果を説明する。
上述したように、集金側装置からの支払請求に基づいて自動的に決済を行う場合、サービス利用者が、決済時に支払内容を確認しないことを意味する。つまり、集金側装置からの一方的な支払請求に基づいて支払を行うことになるため、意図しない相手に払い込んでしまったり、意図しない払い込みをしてしまったりというような不都合が生じる可能性が高い。
【００１５】
そこで、本発明では、例えばオンラインショッピングで言えば商品の注文時というような、支払時期よりも前の段階において、支払側装置で支払予約情報を生成しておき、この支払予約情報に基づいて、実際の支払いを行うようにした。つまり、サービス利用者側の情報としての支払予約情報を生成し、この支払予約情報に基づき、サービス提供者側の支払請求が正しいか否かを判断することによって、集金側装置からの一方的な支払請求だけに基づく支払をなくしたのである。これによって、支払予約情報と異なる請求内容の場合には払い込みが行われないため、サービス利用者の意図しない払い込みが行われることがなくなる。また、サービス利用者とサービス提供者とで共通のパスワードを設けたことによって、請求元が真正であるか否かを判定することができ、意図しない相手に払い込んでしまうという不都合も解消できる。また、上述した支払予約情報は、支払予約番号と対応付けられているため、異なる集金側装置から異なる支払請求があった場合であっても、各集金側装置から送信される支払予約番号に従って支払予約情報を特定することができるため、異なる支払請求に応じた自動決済を実現することができる。
【００１６】
ところで、上述したようなオンラインショッピングの例では、商品の注文時に支払うべき金額が確定する。従って、第２の構成のように、支払予約生成手段は、予定される支払金額を含む支払予約情報を生成し、請求内容判定手段は、支払請求データ送信手段によって送信されてくる支払請求データに含まれる請求金額と支払予約生成手段によって生成された支払予約情報に含まれる支払金額とが少なくとも一致している場合に、請求内容が支払予約情報に一致していると判定するようにすることが考えられる。この場合、例えば商品の注文時に分かる支払金額を支払予約情報の一部として生成しておき、請求金額が支払予約情報に含まれる支払金額と少なくとも一致している場合に、請求内容が支払予約情報に一致していると判定して、電子マネーによる払い込みを行うのである。ここで「少なくとも」としたのは、請求金額と支払金額との一致に加え、他の条件を判断することも考えられるからである。例えば支払予約生成手段が、支払金額と共に注文した商品名を含む支払予約情報を生成するようにしておき、集金側装置からの支払請求データに商品名が含まれている場合には、その商品名の一致を確認するようにすることも考えられる。このように請求金額と支払金額との一致を判断するようにすれば、予定した金額以上の払い込みが行われないため、サービス利用者にとって安心感の高いシステムとなる。
【００１７】
また、上述したようにオンラインで注文した商品の代金を支払う場合には、予定される支払金額が予め分かっているが、例えば、このシステムを用いて公共料金等の支払いを行うことを考える。例えば、支払予約生成手段が、パスワード及び支払予約番号を生成し、確認情報送信手段によりパスワード及び支払予約番号を集金側装置へ一度送信しておくことによって、集金側装置が、このパスワード及び支払予約番号を通知し、毎月使用した分の水道料金を請求するという具合である。このような水道料金等の公共料金は、使用した分だけ請求されるため、その支払金額が予め分からない。
【００１８】
そこで、第３の構成のように、支払予約生成手段は、支払上限金額を含む支払予約情報を生成し、請求内容判定手段は、支払請求データ送信手段によって送信されてくる支払請求データに含まれる請求金額が、支払予約生成手段によって生成された支払予約情報に含まれる支払上限金額を上回っている場合には、請求内容が支払予約情報に一致していないと判定するようにしてもよい。例えば公共料金であれば、支払金額が多くてもいくら位になるかということを推定できる可能性が高い。従って、推定される支払金額よりも大きな支払上限金額を支払予約情報の一部として生成しておき、請求金額がこの支払上限金額を上回る場合には、正当な請求でないとみなすのである。これによって、支払上限金額以上の電子マネーが支払われることがなくなるため、この場合も、サービス利用者の安心感を向上させることができる。
【００１９】
なお、上述した公共料金の場合には、集金側装置の不具合によって間違った金額を請求される可能性があることに着目し、支払上限金額を設定しておくことによって間違った請求に対する支払いを極力なくそうとするものであった。ところで、以下のような状況を考えると、支払上限金額を設定する構成は、上記第２の構成を前提とした場合も有効である。例えばネット社会が発展し、家に居ながら様々な商品が購入できるようになると、ついつい買い過ぎてしまい、予想以上の支払請求がなされるという状況が生じることが考えられる。そこで、第２の構成に加え、さらに、第３の構成のような支払上限金額を設定する構成を採用すれば、例えば一ヶ月のショッピング代金を支払上限金額としておくことで、請求金額と支払金額とが一致しても、支払上限金額を越える場合には支払が行われない。従って、例えば複数の商品を注文するという状況下では、オンラインショッピング等にありがちな買い物のし過ぎを防止することもできる。
【００２０】
以上のようにすれば、予め意図していた金額以上の払い込みが行われることがなくなるが、支払タイミングに関して言えば、集金側装置からの支払請求のタイミングで自動的に払い込みが行われてしまう。ところが、サービス利用者側にも都合があり、例えば商品の返品期間が過ぎてから集金側装置への支払を行いたいという場合も考えられる。
【００２１】
そこで、第４の構成を採用してもよい。すなわち、その構成は、上記第１〜３の構成に加え、支払予約生成手段は、予定される支払タイミングを含む支払予約情報を生成し、支払実行手段は、さらに、前記支払予約情報に含まれる支払タイミングとなったことを判断して、集金側装置へ電子マネーの払い込みを行うことを特徴とするものである。支払タイミングは、例えば支払予約情報を生成した時点を基準にして何日後というように設定されるものであることも考えられるし、例えば一月に一回というように設定されるものであってもよい。このように支払タイミングを設定しておけば、意図しないタイミングで自動的に支払が行われることがなくなる。これによって、上述したように例えば商品の返品期間が過ぎてから集金側装置への電子マネーの支払いを行うこともできるし、また、支払タイミングが分かっているため、その支払いタイミングまでに支払側装置内に電子マネーを用意しておけばよく、常に、支払側装置内に電子マネーを用意しておく必要がないため、利用者にとってさらに使い勝手のよいシステムとなる。
【００２２】
また、上述したように支払側装置で電子マネーを払い込むタイミングを制御することも考えられるが、逆に、集金側装置が、支払請求のタイミングを制御するようにしてもよい。すなわち、第５の構成のように、支払請求データ送信手段は、さらに、予め設定された請求タイミングとなったことを判断すると、支払側装置へ支払請求データを送信するよう構成してもよい。この場合も、集金側装置からの支払請求タイミングが分かっていれば、サービス利用者は、支払タイミングまでに支払側装置内に電子マネーを用意しておけばよく、常に、支払側装置内に電子マネーを用意しておく必要がないため、サービス利用者にとって便利である。
【００２３】
【発明の実施の形態】
以下、本発明を具体化した実施形態を図面を参照して説明する。
［第１実施形態］
図１は、第１実施形態の自動決済システムの構成を示す説明図である。
【００２４】
本第１実施形態の自動決済システムは、「情報通信網」としてのインターネット９１と、このインターネット９１に接続され、インターネット９１を介して情報交換可能な「支払側装置」としての支払側装置１０及び「集金側装置」としての集金側装置３０から構成されている。支払側装置１０及び集金側装置３０は、周知の電子メールサービスを行うメールサーバ５２，５３を介して情報交換可能となっている。以下、支払側装置１０が電子メールサービスの提供を受けるメールサーバ５２をＡメールサーバ５２と記述し、集金側装置３０が電子メールサービスの提供を受けるメールサーバ５３をＢメールサーバ５３と記述して区別する。なお、集金側装置３０は、サービス提供者側のサーバであり、一方、支払側装置１０は、サービス利用者側のパーソナルコンピュータである。この支払側装置１０は、インターネットサービスプロバイダ（以下「ＩＳＰ」という。）５１を介してインターネット９１に接続されている。
【００２５】
また、インターネット９１には、サイバーバンク５４が接続されている。このサイバーバンク５４は、金融業者によって運営されるサーバであり、電子マネーの発行を行うものである。このサイバーバンク５４にインターネット９１を介しアクセスすることによって、電子マネーの購入をしたり、電子マネーを換金したりすることができる。また、このサイバーバンク５４には、電子マネーの口座を開設することができるようになっており、本第１実施形態では、サービス利用者の電子マネーの口座５４ａが開設されている。
【００２６】
さらにまた、インターネット９１には、ダウンロードサーバ５５が接続されている。このダウンロードサーバ５５は、サービス提供者側が運営するものであり、販売している商品を注文するための注文書式データが記憶されている。
支払側装置１０は、ハードディスク１１と、演算部１２とを備えている。このハードディスク１１には、サイバーバンク２０から購入した電子マネー１１ｂが記憶されている。また、上述したようにサイバーバンク５４にはサービス利用者の口座５４ａが開設されており、この口座に預け入れてある電子マネーの情報１１ａも記憶されている。支払側装置１０は、サイバーバンク５４へアクセスした際、サイバーバンク５４の口座５４ａの最新情報を取得する。従って、ハードディスク１１に記憶された電子マネー情報１１ａは、サイバーバンク５４へアクセスする毎に更新される。なお、支払側装置１０のハードディスク１１には、以下説明する処理によってテーブル１１ｔが記憶される。このテーブル１１ｔについては後述する。演算部１２は、周知のＣＰＵ、ＲＯＭ、ＲＡＭから構成されており、ＣＰＵが、ＲＯＭに記憶されたプログラムに基づき、後述する各処理を実行する。
【００２７】
一方、集金側装置３０も、ハードディスク３１と、演算部３２とを備えている。上述した支払側装置１０と同様に、演算部３２は、周知のＣＰＵ、ＲＯＭ、ＲＡＭから構成されており、ＣＰＵが、ＲＯＭに記憶されたプログラムに基づき、後述する各処理を実行する。
【００２８】
次に、本第１実施形態の自動決済システムの動作を説明する。なお、以下の説明では、オンラインショッピングを例に挙げ、商品の注文から決済までを順を追って説明する。
はじめに、支払側装置１０の演算部１２が実行する発注処理を図２のフローチャートに基づいて説明する。
【００２９】
まず最初のステップＳ１００において、注文書式データを読み込む。この処理は、上述したサービス提供者の運営するダウンロードサーバ５４から商品を注文するための注文書式データをダウンロードするものである。
続くＳ１１０では、Ｓ１００にて読み込んだ注文書式データに対応する注文データが入力される。例えば、注文書式データに基づく注文書式が支払側装置１０の備えるディスプレイ（不図示）に表示され、この注文書式に応じて、サービス利用者が、例えば支払側装置１０の備えるキーボード（不図示）を介して注文データを入力するという具合である。本第１実施形態では、注文書式の項目として、注文商品名、商品型番などの発注情報項目に加え、支払金額、パスワード、支払タイミングが用意されているものとし、サービス利用者は、これらの項目を順次入力していくものとする。
【００３０】
Ｓ１１０の処理にて注文データが入力されると、続くＳ１２０では、電子マネー決済プログラムが起動される。以下、Ｓ１３０以降の処理は、電子マネー決済プログラムに基づく処理である。
Ｓ１３０では、電子マネーの支払方法を判断する。支払方法には、「先払い」、「後払い（手動）」及び「後払い（自動）」の３つの方法が用意されており、支払側装置１０のディスプレイに選択メニューとして表示される。従って、サービス利用者は、支払側装置１０のキーボードを操作し、この選択メニューから支払方法を選択することになる。この処理は、サービス利用者が選択メニューからどの支払方法を選択したかを判断するものである。ここで「先払い」が選択されたと判断した場合、Ｓ１４０へ移行する。また、「後払い（手動）」が選択されたと判断した場合、Ｓ１５０へ移行する。さらにまた、「後払い（自動）」が選択入力されたと判断した場合、Ｓ１６０へ移行する。
【００３１】
「先払い」が選択された場合に移行するＳ１４０では、注文書式データに対応して入力された注文データから注文商品に対して入力された支払金額を読み込み、この支払金額分の電子マネーを生成する。電子マネーを生成するというのは、図１に示した支払側装置１０のハードディスク１１に記憶された電子マネー１１ｂを分割し、支払用の電子マネーを生成するという意味である。電子マネー１１ｂは、所定形式のデータ群であり、所定のアルゴリズムで分割可能となっている。例えば、ハードディスク１１に記憶された電子マネーが例えば１００００円分の電子マネーである場合に、所定のアルゴリズムで５０００円分の電子マネー２つに分割することができる。続くＳ１４５では発注データを作成する。ここでは、注文データから注文商品名、商品型番等の発注情報を読み込み、この発注情報に電子マネーを添付した発注データを作成する。その後、Ｓ１７０へ移行する。
【００３２】
「後払い（手動）」が選択された場合に移行するＳ１５０では、注文書式データに対応して入力された注文データからパスワードを読み込む。続くＳ１５５では、発注データを作成する。ここでは、注文データから注文商品名、商品型番等の発注情報を読み込み、この発注情報とパスワードとからなる発注データを作成する。その後、Ｓ１７０へ移行する。
【００３３】
「後払い（自動）」が選択された場合に移行するＳ１６０では、注文書式データに対応して入力された注文データから、注文商品に対応して入力された支払金額、パスワード、支払タイミングを読み込む。そして、支払予約番号を生成し、支払側装置１０のハードディスク１１に記憶された電子マネー１１ｂを分割して支払金額に対応する電子マネーを生成し、さらに、ハードディスク１１に記憶された電子マネー１１ｂから支払金額を差し引いた後の残金を計算する。そして、これらの情報に基づいて、電子マネーを管理するための予約情報テーブルを作成する。この予約情報テーブルが、図１に示した支払側装置１０のハードディスク１１に記憶されたテーブル１１ｔである。以下、テーブル１１ｔを予約情報テーブル１１ｔと記述する。図７に示すように、予約情報テーブル１１ｔには、支払予約番号、パスワード、支払金額、残金及び支払タイミングが記憶されたものである。図７では、２つの支払予約情報が記憶されている様子を示しており、支払予約番号「１０」に対応して、パスワード「ＸＹＺ」、支払金額「２５０」、残金「９７５０」、支払タイミングは「５月１０日以降」となっている。また、支払予約番号「２０」に対応して、パスワード「ＶＷ」、支払金額「８００」、残金「８９５０」、支払タイミング「５月１２日以降」となっている。すなわち、ハードディスク１１に記憶された電子マネー１１ｂが当初「１００００」あったことを示しており、支払金額「２５０」が予約されたことによって残金「９７５０」となっており、次に、支払金額「８００」が予約されたことによって残金「８９５０」となっているのである。Ｓ１６０の処理により、このような予約情報テーブル１１ｔが作成される。続くＳ１６５では、発注データを作成する。ここでは、注文データから注文商品名、商品型番等の発注情報を読み込み、この発注情報、パスワード及び支払予約番号とからなる発注データを作成する。その後、Ｓ１７０へ移行する。
【００３４】
Ｓ１７０では、Ｓ１４５、Ｓ１５５、Ｓ１６５のいずれかの処理で作成された発注データを電子メールの添付ファイルとして送信する。すなわち、集金側装置３０のメールアドレスを指定し、Ａメールサーバ５２への送信を行う。これによって、Ａメールサーバ５２は、Ｂメールサーバ５３へこの電子メールを送信することになる。
【００３５】
次に、上述した発注処理に対応して集金側装置３０の演算部３２で実行される受注処理を図３のフローチャートに基づいて説明する。
まず最初のステップＳ２００において、Ｂメールサーバ５３から電子メールを受信する。続くＳ２１０では、受信した電子メールを展開して解析する。この処理は、電子メール及び電子メールに添付されたファイルを所定の形式で展開し、どのようなデータが含まれているかを解析するものである。
【００３６】
そして、Ｓ２２０では、電子メールに発注データが添付されていたか否かを判断する。支払側装置１０から送信される電子メールであれば、上述した図２中のＳ１４５、Ｓ１５５、Ｓ１６５のいずれかの処理にて作成された発注データが添付されているため肯定判断されることになる。ここで受信した電子メールに発注データが添付されていない場合（Ｓ２２０：ＮＯ）、本受注処理を終了する。一方、受信した電子メールに発注データが添付されていた場合（Ｓ２２０：ＹＥＳ）、Ｓ２３０へ移行する。
【００３７】
Ｓ２３０では、受注処理を実行する。この処理は、発注データ中の発注情報、すなわち注文商品名、商品型番等を抽出する処理である。この処理によって抽出された発注情報から受注情報が生成され、その後、注文された商品は、サービス利用者へ発送されることになる。
【００３８】
Ｓ２４０では、電子マネーによる決済であるか否かを判断する。本第１実施形態の支払側装置１０は、電子マネーによる決済を前提としたものであり、支払側装置１０から送信された発注データである場合には肯定判断されることになる。ここで電子マネーによる決済であると判断された場合（Ｓ２４０：ＹＥＳ）、すなわち支払側装置１０からの発注データである場合には、Ｓ２５０へ移行する。一方、電子マネーによる決済でないと判断された場合（Ｓ２４０：ＮＯ）、すなわち支払側装置１０以外の装置からの発注データである場合には、本受注処理を終了する。
【００３９】
Ｓ２５０では、電子マネーが添付されているか否かを判断する。この処理は、電子メールに添付された発注データが、発注情報及び電子マネーで構成されたものであるか否かを判断するものである。上述したように、図２中のＳ１４５の処理では、発注情報に電子マネーを添付した発注データを作成する。従って、図２中のＳ１４５の処理にて発注データが作成された場合には、ここで肯定判断されることになる。電子マネーが添付されている場合（Ｓ２５０：ＹＥＳ）、Ｓ２６０へ移行する。一方、電子マネーが添付されていない場合（Ｓ２５０：ＮＯ）、Ｓ２７０へ移行する。
【００４０】
Ｓ２６０では、電子マネー入金処理プログラムが起動される。電子マネー入金処理プログラムは、添付された電子マネーを集金側装置３０のハードディスク３１に記憶するための処理手順である。ここでは、このプログラムに基づく処理が実行され、添付された電子マネーが集金側装置３０のハードディスク３１に記憶される。その後、本受注処理を終了する。なお、電子マネー入金処理プログラムに基づく入金処理については、特徴部分でないため、詳しい説明は省略する。
【００４１】
Ｓ２７０では、電子マネー請求プログラムが起動される。電子マネー請求プログラムは、商品代金を電子マネーにて回収するための処理手順である。その後、本受注処理を終了する。
次に、Ｓ２７０で起動される電子マネー請求プログラムに基づく請求処理を図４のフローチャートに基づいて説明する。この処理は、もちろん、集金側装置３０の演算部３２で実行される処理である。
【００４２】
まず最初のステップＳ３００において、請求情報を作成する。この処理は、支払側装置１０からの電子メールに添付された発注データ中の発注情報を読み出し、請求金額を含む請求情報を作成するものである。
Ｓ３１０では、請求タイミングであるか否かを判断する。この処理は、発送した商品が到着してから支払請求を行うという場合に、例えば、支払側装置１０からの発注があってから商品の到着に十分な１０日というような所定時間の経過を判断するものである。ここで請求タイミングであると判断された場合（Ｓ３１０：ＹＥＳ）、Ｓ３２０へ移行する。一方、請求タイミングであると判断されないうちは（Ｓ３１０：ＮＯ）、この判断処理を繰り返す。
【００４３】
Ｓ３２０では、支払側装置１０からの発注データ中に支払予約番号が含まれているか否かを判断する。この処理は、支払側装置１０からの発注データにパスワード及び支払予約番号が添付されているか、あるいは、パスワードのみが添付されているかを判断するものである。ここで支払予約番号が添付されている場合（Ｓ３２０：ＹＥＳ）、すなわちパスワード及び支払予約番号が発注データに含まれている場合には、Ｓ３３０にて、Ｓ３００で作成した請求情報、パスワード及び支払予約番号とを含む支払請求データを作成する。一方、支払予約番号が含まれていない場合（Ｓ３２０：ＮＯ）、すなわちパスワードのみが支払側装置１０からの発注データに含まれている場合には、Ｓ３４０にて、Ｓ３００で作成した請求情報、パスワードを含む支払請求データを作成する。
【００４４】
Ｓ３５０では、Ｓ３３０、Ｓ３４０のいずれかの処理にて作成した支払請求データを電子メールの添付ファイルとして送信する。すなわち、支払側装置１０のメールアドレスを指定し、Ｂメールサーバ５３への送信を行う。これによって、Ｂメールサーバ５３は、Ａメールサーバ５２へ、この電子メールを送信することになる。
【００４５】
次に、上述した請求処理に対応して支払側装置１０の演算部１２で実行される決済処理を図５のフローチャートに基づいて説明する。
まず最初のステップＳ４００において、Ａメールサーバ５２から電子メールを受信する。続くＳ４１０では、受信した電子メールを展開して解析する。この処理は、電子メール及び電子メールに添付されたファイルを所定の形式で展開し、どのようなデータが含まれているかを解析するものである。
【００４６】
そして、Ｓ４２０では、電子メールに支払請求データが添付されているか否かを判断する。集金側装置３０から送信される電子メールであれば、上述した図４中のＳ３３０、Ｓ３４０のいずれかの処理にて作成された支払請求データが添付されているため肯定判断されることになる。ここで受信した電子メールに支払請求データが添付されていない場合（Ｓ４２０：ＮＯ）、Ｓ４７０にて電子メールをそのまま格納し、その後、本決済処理を終了する。一方、受信した電子メールに発注データが添付されていた場合は（Ｓ４２０：ＹＥＳ）、Ｓ４３０へ移行する。
【００４７】
Ｓ４３０では、支払請求データにパスワードが含まれているか否かを判断する。集金側装置３０から送信される支払請求データは、図４中のＳ３３０、Ｓ３４０のいずれかの処理にて作成されたものであるため、必ずパスワードが含まれる。ここで支払請求データにパスワードが含まれていない場合（Ｓ４３０：ＮＯ）、Ｓ４７０にて電子メールをそのまま格納し、その後、本決済処理を終了する。一方、支払請求データにパスワードが含まれている場合（Ｓ４３０：ＹＥＳ）、Ｓ４４０へ移行する。
【００４８】
Ｓ４４０では、支払請求データに支払予約番号が含まれているか否かを判断する。図４中のＳ３３０で作成された支払請求データには、パスワードと共に支払予約番号が含まれている。この処理は、支払請求データにパスワードのみが含まれているか、あるいは、パスワードと共に支払予約番号も含まれているか否かを判断するものである。ここで支払請求データに支払予約番号が含まれている場合（Ｓ４４０：ＹＥＳ）、Ｓ４５０へ移行する。一方、支払請求データに支払予約番号が含まれていない場合（Ｓ４４０：ＮＯ）、Ｓ４６０にて、電子マネーの手動による決済を行うために、支払側装置１０のハードディスク１１に電子マネーの手動決済データとして支払請求データを格納し、その後、本決済処理を終了する。なお、電子マネーの手動決済では、サービス利用者が支払請求データに含まれるパスワードによって請求元が真正であるか否かを確認し、さらに、支払請求データに含まれる請求情報に基づき請求内容、例えば請求金額が正しいか否かを確認して、支払側装置１０によって電子マネーを集金側装置３０へ払い込む。
【００４９】
Ｓ４５０では、電子マネー自動払い込み処理プログラムが起動される。電子マネー自動払い込み処理プログラムは、上述の支払請求データに基づいて電子マネーを集金側装置３０へ自動的に払い込むための処理手順である。ここでは、このプログラムに基づく処理が実行され、電子マネーが自動的に集金側装置３０へ払い込まれる。
【００５０】
次に、Ｓ４５０で起動される電子マネー自動払い込み処理プログラムに基づく自動払い込み処理を図６のフローチャートに基づいて説明する。
まず最初のステップＳ５００において、集金側装置３０からの支払請求データに含まれるパスワードを読み込み、次にＳ５１０にて、支払請求データに含まれる支払予約番号を読み込み、続いてＳ５２０にて、支払請求データに含まれる請求情報から請求金額を読み込む。
【００５１】
そして、Ｓ５２５では、Ｓ５１０にて読み込んだ支払予約番号によって、支払側装置１０のハードディスク１１に記憶された予約情報テーブル１１ｔ中で対応する支払予約情報を特定する。
続くＳ５３０では、この支払予約情報中のパスワードが、Ｓ５００にて読み込んだパスワードと一致しているか否かを判断する。ここでパスワードが一致していない場合（Ｓ５３０：ＮＯ）、請求元が真正でないと判断して本自動払い込み処理を終了する。一方、パスワードが一致している場合（Ｓ５３０：ＹＥＳ）、請求元が真正であると判断し、Ｓ５４０へ移行する。
Ｓ５４０では、支払予約情報中の支払金額が、Ｓ５２０にて読み込んだ請求金額と一致しているか否かを判断する。ここで請求金額が一致していない場合（Ｓ５４０：ＮＯ）、請求内容が正しくないと判断して本自動払い込み処理を終了する。一方、金額が一致している場合（Ｓ５４０：ＹＥＳ）、請求内容が正しいと判断し、Ｓ５６０へ移行する。
【００５２】
Ｓ５６０では、図２中のＳ１６０にて予め生成した支払金額分の電子マネーを読み込む。続くＳ５７０では、支払予約情報中の支払タイミングを参照し、支払タイミングとなっているか否かを判断する。ここで支払タイミングとなっていると判断された場合（Ｓ５７０：ＹＥＳ）、Ｓ５８０へ移行する。一方、支払タイミングとなっていないと判断された場合（Ｓ５７０：ＮＯ）、支払タイミングとなるまで、この判断処理を繰り返す。
【００５３】
Ｓ５８０では、この電子マネーを電子メールの添付ファイルとして送信する。すなわち、集金側装置３０のメールアドレスを指定し、Ａメールサーバ５２への送信を行う。これによって、Ａメールサーバ５２は、Ｂメールサーバ５３へ、この電子メールを送信することになる。集金側装置３０は、Ｂメールサーバからこの電子メールを受信することによって電子メールに添付された電子マネーを回収する。
【００５４】
次に、本第１実施形態の自動決済システムの発揮する効果を説明する。なお、ここでの説明に対する理解を容易にするため、最初に電子マネーにて自動決済を行う場合の問題点を説明する。
集金側装置３０からの支払請求に基づいて自動的に決済を行う場合、サービス利用者が、決済時に支払内容を確認しないことになる。つまり、集金側装置３０からの一方的な支払請求に基づいて支払を行うことになるため、意図しない相手に払い込んでしまったり、意図しない払い込みをしてしまったりというような不都合が生じる可能性が高い。
【００５５】
これに対して、本第１実施形態の自動決済システムでは、支払側装置１０によって電子マネーによる自動決済を行う場合、すなわち、サービス利用者によって「後払い（自動）」が選択された場合には（図２中のＳ１３０）、商品の注文時において、支払側装置１０で支払予約情報を生成し（図２中のＳ１６０）、これら予約情報を予約情報テーブル１１ｔ（図７参照）としてハードディスク１１に記憶しておく。そして、集金側装置３０からの支払請求があると、予約情報テーブル１１ｔに記憶された支払予約情報が、集金側装置３０からの支払請求データと一致しているか否かを判断し、一致している場合にのみ電子マネーの払い込みを行う。このように集金側装置３０からの一方的な支払請求データだけに基づく支払をなくした。
【００５６】
具体的には、支払側装置１０では、商品の発注時に、支払金額、パスワード、支払タイミングを含む支払予約情報を生成し、予約情報テーブル１１ｔに記憶しておく（図２中のＳ１６０）、そして、集金側装置３０へは、商品名、商品型番等を含む発注情報、パスワード及び上述した支払予約情報に対応する支払予約番号を送信する（図２中のＳ１７０）。これに応じて、集金側装置３０では、請求金額等を含む請求情報、パスワード及び支払予約番号を含む支払請求データを生成し（図４中のＳ３３０）、この支払請求データを支払側装置１０へ送信することによって（図４中のＳ３５０）電子マネーの支払を請求する。
【００５７】
支払側装置１０では、支払請求データに含まれる支払予約番号を読み出し（図６中のＳ５１０）、この支払予約番号によって予約情報テーブル１１ｔ中の支払予約情報を特定する（図６中のＳ５２５）。そして、支払請求データから読み出したパスワードが、特定した支払予約情報のパスワードと一致し（図６中のＳ５３０：ＹＥＳ）、また、支払請求データから読み出した請求金額が、支払予約情報の支払金額と一致した場合に（図６中のＳ５４０：ＹＥＳ）、電子マネーの払い込みを行う。つまり、パスワードの一致を判断することによって請求元が真正であるか否かを判定することができ、意図しない相手に払い込んでしまうことがなくなる。
【００５８】
また、支払側装置１０では、支払予約情報に含まれる支払タイミングとなったことを判断し（図６中のＳ５７０）、支払タイミングとなってはじめて電子マネーの払い込みを実行する。これによって、意図しないタイミングで自動的に支払が行われることがないため、例えば商品の返品期間が過ぎた後に支払うようにすることもでき、サービス利用者にとって便利である。
［第２実施形態］
上記第１実施形態の自動決済システムは、オンラインショッピングを例に挙げ、注文した商品の対価を支払うものであったが、同様の構成によって、例えば公共料金等を電子マネーによって決済することも考えられる。
【００５９】
以下、公共料金を電子マネーによって決済する第２実施形態に関して説明する。公共料金を電子マネーによって決済する場合、図２に示した発注処理に代えて、図８に示す登録処理を行い、図６に示した自動払い込み処理の一部を変更することによって実現することができる。従って、以下の説明では、図２に示した発注処理に代わる図８の登録処理、及び、図６に示した自動払い込み処理の変更部分のみを説明することとする。
【００６０】
上記第１実施形態では、商品の注文時点において、予定される支払金額が予め分かっているが、水道料金などの公共料金は、使用した分だけ請求されるため、その支払金額が予め分からない。そこで、図８に示す登録処理をまず支払側装置１０の演算部１２が実行する。なお、この登録処理の流れは、基本的には、図２で説明した発注処理と同様であるため、簡単に説明する。
【００６１】
まず最初のステップＳ６００において、登録書式データを読み込む。続くＳ６１０では、Ｓ６００にて読み込んだ登録書式データに対応する登録データが入力される。Ｓ６１０の処理にて登録データが入力されると、続くＳ６２０では、登録書式プログラムが起動される。以下、Ｓ６３０以降の処理は、登録書式プログラムに基づく処理である。
【００６２】
Ｓ６３０では、電子マネーの支払方法を判断する。支払方法には、「後払い（手動）」、「後払い（自動）」及び「その他」の３つの方法が用意されており、この処理は、サービス利用者が選択メニューからどの支払方法を選択したかを判断するものである。ここで「その他」が選択されたと判断した場合、Ｓ６４０へ移行する。また、「後払い（手動）」が選択されたと判断した場合、Ｓ６５０へ移行する。さらにまた、「後払い（自動）」が選択入力されたと判断した場合、Ｓ６６０へ移行する。
【００６３】
「後払い（自動）」が選択された場合に移行するＳ６６０では、登録データからパスワード、支払タイミング及び支払上限金額を読み込む。そして、支払予約番号を生成し、支払予約情報を管理するための予約情報テーブルを作成する。この場合の予約情報テーブルは、パスワード、支払予約番号、支払タイミング及び支払上限金額が記憶されたものである。続くＳ６６５では、支払登録データを作成する。ここでは、登録情報を読み込み、この発注情報、パスワード及び支払予約番号とからなる支払登録データを作成し、Ｓ６７０にて、作成された支払登録データを電子メールの添付ファイルとして送信する。この支払登録データが、図２の発注処理における発注データに相当する。この場合も、支払登録データには、パスワード及び支払予約情報が添付されるため、集金側装置３０は、このパスワード及び支払予約番号を含む支払請求データを生成し、支払側装置１０への支払請求を行う。
【００６４】
「後払い（手動）」が選択された場合に移行するＳ６５０では、登録データからパスワードを読み込み、Ｓ６５５にて、登録情報とパスワードとを含む支払登録データを作成し、Ｓ６７０でこの支払登録データを送信する。この場合、集金側装置３０は、パスワードを含む支払請求データを生成して支払請求を行う。
【００６５】
また、「その他」が選択された場合に移行するＳ６４０では、登録データから電子マネー以外の支払方法を読み込む。例えばクレジットカードなどによる決済が考えられる。この場合は、Ｓ６４５にて、支払方法に応じた支払請求データを生成し、Ｓ６７０でこの支払登録データを送信する。
【００６６】
上記第１実施形態では「後払い（自動）」が選択された場合には、注文データから支払金額を読み込んだが、本第２実施形態では、登録データから支払上限金額を読み込む。この支払上限金額は、サービス利用者が公共料金が多くともいくら位になるかを推定し、登録データとしてＳ６１０の処理にて入力したものである。
【００６７】
集金側装置３０から支払請求データが送信されると、支払側装置１０は、図５に示した決済処理を実行するのであるが、この処理中で、電子マネー自動払い込み処理プログラムが起動されると（図５中のＳ４５０）、図６に示した自動払い込み処理が実行される。
【００６８】
次に、この自動払い込み処理中の変更点を説明する。上述したようにＳ６６０にて支払予約情報が生成されるのであるが、公共料金の場合は予め支払金額が確定していないため、支払金額は生成されていない。そこで、図６に示した自動払い込み処理では、Ｓ５４０の判断、すなわち請求金額の一致判断を行わなわず、その代わりに、請求金額が支払上限金額を下回っているか否かを判断するようにする。請求金額が、上述した支払上限金額を下回る場合には、正当な請求であるとみなして、電子マネーの払い込みを行う。
【００６９】
このように構成することによって、公共料金の払い込み処理をも実行することが可能となる。
以上、本発明はこのような実施形態に何等限定されるものではなく、本発明の主旨を逸脱しない範囲において種々なる形態で実施し得る。
【００７０】
例えば、上記第１実施形態では、図６中のＳ５４０で請求金額の一致のみを判断しているが、例えば支払上限金額を以下のように設定しておき、この支払上限金額について判断を行うようにしてもよい。例えば一ヶ月毎に支払上限金額を入力する構成とし、注文した商品に対して電子マネーを払い込む度に支払上限金額から支払金額を差し引いていき、請求金額が一致した場合であっても、請求金額が支払上限金額を越えた場合には、例えば利用者に警告するようにしてもよい。このようにすることで、オンラインショッピングにありがちな買い物のし過ぎを防止することができる。
【００７１】
また、上記第１及び第２実施形態では、支払側装置１０のハードディスク１１に記憶された電子マネー１１ｂを分割し、支払金額分の電子マネーを生成し、この電子マネーを電子メールに添付して集金側装置３０へ払い込むようにしていたが、上述したようにサイバーバンク５４に用意されたサービス利用者の口座５４ａから電子マネーを引き出し、その電子マネーを集金側装置３０へ払い込むようにしてもよい。また、インターネット９１に接続されたサイバーバンクにサービス提供者の口座が用意されている場合には、電子マネーをその口座に振り込むようにしてもよいし、サービス利用者の口座５４ａからサービス提供者の口座へ電子マネーを振り替えるようにしてもよい。
【図面の簡単な説明】
【図１】第１実施形態の自動決済システムの概略構成を示す説明図である。
【図２】支払側装置が実行する発注処理を示すフローチャートである。
【図３】集金側装置が実行する受注処理を示すフローチャートである。
【図４】受注処理中で実行される請求処理を示すフローチャートである。
【図５】支払側装置が実行する決済処理を示すフローチャートである。
【図６】決済処理中で実行される自動払い込み処理を示すフローチャートである。
【図７】支払側装置で作成される予約情報テーブルを示す説明図である。
【図８】第２実施形態の支払側装置が実行する登録処理を示すフローチャートである。
【符号の説明】
１０…支払側装置                      １１…ハードディスク
１１ａ…情報                          １１ｂ…電子マネー
１１ｔ…予約情報テーブル              １２…演算部
３０…集金側装置                      ３１…ハードディスク
３２…演算部                          ５１…ＩＳＰ
５２，５３…メールサーバ              ５４…サイバーバンク
５４ａ…口座                          ５５…ダウンロードサーバ
９１…インターネット
【図１】
0004095716.tif 000002
【図２】
0004095716.tif 000003
【図３】
0004095716.tif 000004
【図４】
0004095716.tif 000005
【図５】
0004095716.tif 000006
【図６】
0004095716.tif 000007
【図７】
0004095716.tif 000008
【図８】
0004095716.tif 000009