JPWO2001097118A1 - 携帯電話機を用いた決済方法および携帯電話機 - Google Patents

Abstract

携帯電話機（１３）の利用者（１２）ごとに携帯電話会社（１０）内に仮想口座（１１０）を設ける。利用者（１２）は携帯電話機（１３）を用いて仮想口座（１１０）に前払金を入金しておく。前払金は、通話料と合せて支払ったり、クレジットカードやデビットカードで支払う。携帯電話機（１３）には仮想口座（１１０）の残高が記憶されている。インターネット上の仮想店舗で買物をする場合は携帯電話機（１３）の電話番号を送信し、実在店舗で買物をする場合は電話番号をＰＯＳ端末に送信する。各店舗は、携帯電話会社（１０）に決済金額を請求する。したがって、高いセキュリティで簡単に携帯電話機を用いて決済することができる。

Description

技術分野
この発明は、携帯電話機およびその携帯電話機を用いた決済方法に関し、さらに詳しくは、インターネット上の仮想店舗や実在店舗における決済を仲介するサービスに関する。
背景技術
現在、携帯電話機を用いた種々の決済方法が提案されている。日経エレクトロニクス「携帯で決済」第７６９号，日経ＢＰ社（２０００年５月８日）発行，１０９〜１２９頁には、ＩＣカードを搭載した携帯電話機が記載されている。この携帯電話機では、ＩＣカードにクレジットカード番号をセキュアな状態で予め記録しておき、決済時にクレジットカード番号を暗号化して送信するようにしている。また、非接触型ＩＣカード用のリーダ／ライタを搭載した携帯電話機も記載されている。この携帯電話機では、プリペイドカードの度数のような電子バリューをダウンロードし、これをリーダ／ライタにより非接触型ＩＣカードに無線経由で転送するようにしている。利用者はこの非接触型ＩＣカードを使って決済を行なう。
上記ＩＣカードを搭載した携帯電話機ではクレジットカード番号を暗号化しているが、クレジットカード番号を送信していることに変わりはないので、インターネット上の電子商取引では十分なセキュリティとは言えない。
一方、上記リーダ／ライタを搭載した携帯電話機では、利用者は携帯電話機とともに非接触型ＩＣカードを持ち歩かなければならない。また、リーダ／ライタはサイズが大きく、コストも高いなど、問題も多い。
この他、携帯電話機を用いた種々の決済方法が提案されているが、いずれも決済時に与信照会が必要であったり、決済データの送信が必要なため、決済時に電波を飛ばす必要があり、電波圏外では使用することができず、また、決済に時間がかかるという問題がある。
発明の開示
この発明は、上記のような問題を解決するためになされたもので、セキュリティが高く使い勝手のよい携帯電話機およびその携帯電話機を用いた決済方法を提供することを目的とする。
この発明による携帯電話機を用いた決済方法は、売り主と携帯電話機の利用者たる買い主との間の決済を仲介する方法であって、利用者の金銭を蓄積するための口座を利用者ごとに設けたサーバコンピュータにおいて、携帯電話機から送信された金額を受信するステップと、受信した金額を利用者の口座に入金してその口座の残高を更新するステップと、更新した口座の残高を携帯電話機に送信するステップと、決済金額を受信するステップと、受信した決済金額を口座の残高から減じるステップと、受信した決済金額を売り主に支払うステップとを含む。ここでのサーバコンピュータは、携帯電話局（会社）、金融機関（会社）、決済機関（会社）などに設置され得るが、その位置は特に限定されない。
一方、この発明による携帯電話機は、売り主と携帯電話機の利用者たる買い主との間の決済に用いられる携帯電話機であって、利用者の金銭を蓄積するための口座がサーバコンピュータに利用者ごとに設けられ、利用者の操作に応じて口座に入金される所望の金額を入力する手段と、入力された金額を携帯電話局のコンピュータに送信し、サーバコンピュータから送信された仮想口座の残高を受信する送受信手段と、受信した口座の残高を記憶する手段とを備える。
この決済方法または携帯電話機によれば、利用者は携帯電話機を用いて所望の金額を携帯電話局または携帯電話局を通じて金融機関もしくは決済機関に送信する。携帯電話局、金融機関または決済機関は、携帯電話機から送信された金額を受信し、その金額を利用者の口座に入金してその口座の残高を更新して携帯電話機に送信する。携帯電話機は、携帯電話局から送信された口座の残高を受信して記憶する。したがって、利用者は携帯電話機を財布のように使って決済を行なうことができる。ここでは、クレジット番号などを送信する必要がないので、セキュリティが高い。また、ＩＣカードなどを持ち歩く必要もないので、使い勝手がよい。
発明を実施するための最良の形態
以下、この発明の実施の形態を図面を参照して詳しく説明する。図中同一または相当部分には同一符号を付してその説明は繰返さない。
［第１の実施の形態］
１．サービスの概要
この発明の実施の形態は、携帯電話会社が提供する新規サービス（「お財布サービス」と呼び、以下単に「本サービス」という）を実現するためのコンピュータシステムに関するものである。本サービスは、携帯電話機を財布のように使用できるようにするものである。以下、本サービスの概要を説明する。
携帯電話機購入の際、通話料金を引落す銀行口座以外に、クレジットカード番号やキャッシュカード番号などを携帯電話会社に登録する。携帯電話会社は、携帯電話機の利用者ごとに仮想口座を設ける。利用者は、決済の前に、仮想口座に前払金を入金するように、携帯電話機を用いて携帯電話会社に要請する。携帯電話会社は、予め登録されている銀行口座、クレジットカード番号、キャッシュカード番号などを用い、利用者に対して前払金の請求を行なう。前払金の支払方法は、利用者が選択することができる。前払金の請求後、携帯電話会社は、仮想口座に前払金を入金したうえで仮想口座の残高を携帯電話機に送信する。携帯電話機は、送信された仮想口座の残高を記憶する。利用者は、この携帯電話機を財布代わりに使ってインターネット上の仮想店舗や実在店舗で決済を行なう。店舗は、携帯電話会社に対して請求を行なう。
２．前払金の支払方法
次に、４通りの前払金の支払方法について説明する。
２−１．通話料と併せて支払う場合
図１は、前払金を通話料と併せて支払う場合の資金移動を示す概略図である。図１に示すように、携帯電話会社（携帯電話局）１０には、個人情報データベース１１が設けられている。個人情報データベース１１には、各利用者１２の個人情報が登録されている。具体的には、前払金（携帯電話会社にとっては前受金）を蓄積するための仮想口座１１０が設けられ、携帯電話機１３の電話番号の他、電子メールアドレス、パスワード、利用状況、キーコード、口座番号、クレジットカード番号、デビットカード番号などが予め登録されている。
まず、利用者１２は携帯電話機１３を用いて所望の前払金額とその支払方法（ここでは「通話料に加算」）とを携帯電話会社１０に送信する。このとき、携帯電話機１３の電話番号も併せて送信する。
携帯電話会社１０は、送信された携帯電話番号に基づいて個人情報データベース１１を検索し、利用者１２の仮想口座１１０の利用状況を照会する。利用者１２に問題がなければ（利用状況が「ＯＫ」であれば）、携帯電話会社１０は送信された前払金額を仮想口座１１０の前受残高に加算し、更新した最新の前受残高を送信する。一方、利用者１２の支払いが滞っていたり、本サービスの利用が停止されている場合、利用状況は「ＮＧ」となっている。この場合、携帯電話会社１０は携帯電話機１３を通じて本サービスを利用できない旨を利用者１２に通知する。
上記のように利用者１２が支払方法として「通話料に加算」を選択した場合、携帯電話会社１０は、基本料金と通話料金の請求書１４と併せて本サービスの利用明細書１５を利用者１２に送付する。
携帯電話会社１０は、個人情報データベース１１に登録されている口座番号に基づいて利用者１２の取引銀行１７に利用料金の引落しを依頼する。これに応じて銀行１７は、利用者１２の口座１６から、銀行１８に開設されている携帯電話会社１０の口座１９に資金を振替える。
２−２．クレジットカードで支払う場合
図２は、前払金をクレジットカードで支払う場合の資金移動を示す概略図である。この場合、図２に示すように、利用者１２は携帯電話機１３を用いて前払金額とその支払方法（ここでは「クレジットカード」）とを携帯電話会社１０に送信する。
携帯電話会社１０は、利用者１２の利用状況に問題がなければ、予め登録されているクレジットカード番号に基づいて信販会社２０に承認を依頼する。信販会社２０は、承認できる場合はその旨を携帯電話会社１０に通知する。これに応じて、携帯電話会社１０は仮想口座１１０の前受残高を更新し、その最新の前受残高を携帯電話機１３に送信する。一方、承認できない場合は、信販会社２０はその旨を携帯電話会社１０に通知する。これに応じて、携帯電話会社１０は前受残高を更新することなく、クレジットカードによる支払いができない旨を利用者１２に通知する。
支払いを承認した場合、信販会社２０は、利用者１２が所望した前払金額を携帯電話会社１０の口座１９に振込む。次いで信販会社２０は、銀行１７に対して利用者１２の口座１６から前払金額を引落すように依頼する。これに応じて銀行１７は、利用者１２の口座１６から信販会社２０に資金を振替える。
２−３．デビットカードで支払う場合
図３は、前払金をデビットカードで支払う場合の資金移動を示す概略図である。この場合、図３に示すように、利用者１２は携帯電話機１３を用いて前払金額とその決済方法（ここでは「デビットカード」）とを携帯電話会社１０に送信する。
携帯電話会社１０は、利用者１２の利用状況に問題がなければ、予め登録されているデビットカード番号に基づいてそのデビットカードを発行した銀行１７に資金の振替えを依頼する。振替え依頼を承認した場合、銀行１７はその振替えデータをクリアリングセンター２１に送信するとともに、振替えの完了を携帯電話会社１０に通知する。これに応じて携帯電話会社１０は、前受残高を更新し、その最新の前受残高を携帯電話機１３に送信する。一方、銀行１７が振替え依頼を承認しない場合、振替えできない旨を携帯電話会社１０に通知する。これに応じて携帯電話会社１０は、前受残高を更新することなく、デビットカードで支払いできない旨を利用者１２に通知する。
クリアリングセンター２１は、銀行１７の他、多数の銀行から送信された振替えデータに基づいて振替えの相殺および集計を行ない、銀行間の決済尻データを決済銀行２２に送信する。これに応じて決済銀行２２は、銀行１７から加盟店銀行２３に資金を振替える。これに応じて加盟店銀行２３は、その資金を携帯電話会社１０の口座１９に入金する。
２−４．自動引落しで支払う場合
図４は、前受金を銀行口座から自動引落しで支払う場合の資金移動を示す概略図である。この場合、図４に示すように、利用者１２は携帯電話機１３を用いて前払金額とその支払方法（ここでは「自動引落」）とを携帯電話会社１０に送信する。携帯電話会社１０は、利用者１２の利用状況に問題がなければ、予め登録されている口座番号に基づいて銀行１７に資金の引落しを依頼する。引落しが可能な場合、銀行１７はその旨を携帯電話会社１０に通知する。これに応じて携帯電話会社１０は、前受残高を更新し、最新の前受残高を携帯電話機１３に送信する。引落しが不可能な場合、銀行１７はその旨を携帯電話会社１０に通知する。これに応じて携帯電話会社１０は、支払いできない旨を利用者１２に通知する。携帯電話会社１０から引落し依頼を受けた銀行１７は直ちに、利用者１２の口座１６から携帯電話会社１０の口座１９に資金を振替える。これとは別に、利用明細書１５は請求書１４と併せて利用者１２に送付される。
３．決済
次に、携帯電話機１３を使って上述した前払金で決済を行なう方法について説明する。
３−１．インターネット上の仮想店舗での決済
図５は、インターネット上の仮想店舗で携帯電話機を使って決済する方法を示す概略図である。図５に示すように、まず、利用者１２は携帯電話機１３またはパーソナルコンピュータ４０でインターネット上の仮想店舗２４に商品やサービスを注文し、その決済方法（ここでは「携帯電話決済」）を選択する。パーソナルコンピュータ４０を用いる場合、利用者１２は携帯電話機１３の電話番号をパーソナルコンピュータ４０に手で入力し、インターネット６０を通じて仮想店舗２４に送信する。
注文を受けた仮想店舗２４は、送信された携帯電話番号に基づいて携帯電話会社１０に決済金額の請求を依頼する。
請求依頼を受けた携帯電話会社１０は、利用者１２の利用状況に問題があれば本サービスが利用できない旨を仮想店舗２４に通知する。これに応じて仮想店舗２４は、本サービスが利用できない旨を利用者１２に通知する。利用者１２の利用状況に問題がなければ、携帯電話会社１０は予め登録されている利用者１２の電子メールアドレスに基づいて利用者１２の携帯電話機１３に電子メールで電子請求書を送信する。電子請求書は、仮想口座１１０からの支払いを利用者１２に確認するためのものである。
また、電子請求書を受取った利用者１２は、その決済を承認するか否かを選択する。利用者１２が決済を承認した場合、電子請求書を受信した携帯電話機１３は、前払残高を検証し、前払残高が決済金額を下回っている場合、携帯電話機１３は残高不足として決済ができない旨を携帯電話会社１０に通知する。これに応じて携帯電話会社１０は、残高が不足しているから決済できない旨を仮想店舖２４を通じて利用者１２に通知する。利用者１２が決済を取消しまたは拒否した場合、決済取消しまたは決済拒否を携帯電話会社１０に通知する。これに応じて携帯電話会社１０は、決済が取消しまたは拒否されたから決済できない旨を仮想店舗２４に通知する。これに応じて仮想店舗２４は、決済できない旨を利用者１２に通知する。
また、利用者１２が決済を承認した場合において、前払残高の検証の結果、決済金額が前払残高以内のとき、その決済を了承する旨を携帯電話会社１０に通知する。このとき、予め携帯電話会社１０に登録されているパスワード、携帯電話番号、キーコードなどを併せて送信する。携帯電話会社１０は、送信された携帯電話番号に基づいて個人情報データベース１１を検索し、送信されたパスワードおよびキーコードが予め登録されているパスワードおよびキーコードとそれぞれ一致するか否かを判別する。キーコードが一致しない場合、携帯電話会社１０はキーコードが異常であるから本サービスを利用できない旨を利用者１２に通知するとともに、決済できない旨を仮想店舗２４を通じて利用者１２に通知する。両者とも一致する場合、携帯電話会社１０は仮想口座１１０の前受残高から決済金額を減算して前受残高を更新するとともに、その更新した前受残高を携帯電話機１３に送信する。これに応じて携帯電話機１３は内部の前受残高を更新する。また、携帯電話会社１０は決済完了を仮想店舗２４に通知する。これに応じて仮想店舗２４は決済完了を利用者１２に通知する。
その後、仮想店舗２４は注文を受けた商品を利用者１２に届けたり、注文を受けたサービスを利用者１２に提供する。携帯電話会社１０は、上記決済金額を仮想店舗２４に入金する。仮想店舗２４は、本サービスを利用した手数料を携帯電話会社１０に支払う。
３−２．実在店舗での決済
図６は、実在店舗で携帯電話機を使って決済する方法を示す概略図である。図６に示すように、実在店舗において、利用者１２は携帯電話機１３をＰＯＳ端末２７に接続された読取装置２７０にセットする。店員は商品の金額をＰＯＳ端末２７に打ち込み、決済金額を計算する。この決済金額はＰＯＳ端末２７から読取装置２７０を通じて携帯電話機１３に送信される。携帯電話機１３は、内部に記憶されている残高と決済金額とを比較し、決済が不可能であればエラーをＰＯＳ端末２７に送信する。一方、決済が可能であれば、携帯電話機１３は携帯電話番号とキーコードとをＰＯＳ端末２７に送信する。携帯電話番号は、ＰＯＳ端末２７に手で直接入力することはできない。
携帯電話番号とキーコードとを受信したＰＯＳ端末２７は決済を完了して、その旨を携帯電話機１３に通知する。決済完了を受けて、携帯電話機１３はその決済金額を内部メモリに記憶し、決済モードがオフになる。その後、利用者１２は携帯電話機１３を読取装置２７０から取り除く。
次に、決済金額とともに携帯電話番号およびキーコードを携帯電話会社１０に送信する。これに応じて携帯電話会社１０は、仮想口座１１０の前受残高から決済金額を減算して前受残高を更新するとともに、決済完了をＰＯＳ端末２７に通知する。
４．ハードウェア構成
図７は、携帯電話機１３、および携帯電話会社１０に設置されるサーバコンピュータ（以下、単にサーバという）３０のハードウェア構成を示すブロック図である。
図７に示すように、携帯電話機１３は、ＣＰＵからなるデータ処理部１３１と、ＲＡＭ１３２と、ＥＥＰＲＯＭのようなＲＯＭ１３３と、アンテナ１３４と、送受信部１３５と、テンキーやカーソルキーのような入力装置１３６と、液晶ディスプレイのような表示装置１３７と、バッテリ１３８と、インターフェイス（Ｉ／Ｆ）部１３９とを備える。この携帯電話機１３は電源アダプタ１４０に装着され、電源アダプタ１４０からＩ／Ｆ部１３９を通じてバッテリ１３８に電流が供給され、バッテリ１３８が充電される。データ処理部１３１は、ＲＡＭ１３２、ＲＯＭ１３３、送受信部１３５、入力装置１３６、表示装置１３７およびＩ／Ｆ部１３９を用いて通常の携帯電話機能を実行する他、後述する決済機能を実行する。
携帯電話会社１０に設置されているサーバ３０は、ＣＰＵからなるデータ処理部３０１と、データベース３０２とを備える。データベース３０２は、個人情報データベース１１と、利用履歴データベース２８と、決済履歴データベース２９とを含む。データ処理部３０１はデータベース３０２を用いて後述する決済機能を実行する。データ処理部３０１は無線基地局３０３に接続されている。無線基地局３０３のアンテナ３０４と携帯電話機１３のアンテナ１３４との間で電波が送受信される。利用履歴データベース２８は、携帯電話機１３とのデータの取引内容を記録するためのログファイルである。具体的には、仮想口座１１０の入出金日時、入出金額、残高などが記録される。決済履歴データベース２９は、店舗とのデータの取引内容を記録するためのログファイルである。具体的には、決済日時、決済金額などが記録される。
５．前払い時の処理動作
５−１．通話料と併せて支払う場合
図８は、図１に示した前払金を通話料と併せて支払う場合における携帯電話機１３およびサーバ３０の動作を示すフローチャートである。図９は、この場合に携帯電話機１３の表示装置１３７に表示される表示画面の遷移図である。
まず、携帯電話機１３のデータ処理部１３１は、表示装置１３７上に図９に示した画面Ｄ１を表示し、利用者１２に対してパスワードの入力を促す。利用者１２が入力装置１３６を操作してパスワードを入力すると、入力装置１３６はその入力されたパスワードをデータ処理部１３１に与える（Ｓ１０１）。
続いて、データ処理部１３１はその入力されたパスワードをＲＡＭ１３２またはＲＯＭ１３３に予め登録されているパスワードと比較することにより入力されたパスワードの検証を行なう（Ｓ１０２）。入力されたパスワードが誤っている場合、データ処理部１３１は表示装置１３７上に図９に示した画面Ｄ２を表示する（Ｓ１０３）。一方、入力されたパスワードが正しい場合、データ処理部１３１は表示装置１３７上に図９にした画面Ｄ３を表示し、利用者１２に対し、「▲１▼お金を払う」、「▲２▼お財布の中を見る」、「▲３▼お財布にお金を入れる」の中から１つを選択するよう促す。利用者１２が入力装置１３６を操作し、「▲３▼お財布にお金を入れる」を選択すると、データ処理部１３１は表示装置１３７上に画面Ｄ４を表示し、利用者１２に対して前払金額の入力を促す。このとき、未通知データ（詳細は後述する）がない場合はＲＡＭ１３２に記憶されている前払残高を現在の残高として表示し、未通知データがある場合はＲＡＭ１３２に記憶されている前払残高から未通知の決済金額を減算して真の前払残高を計算し、それを現在の残高として表示する。利用者１２が入力装置１３６を操作して所望の前払金額を入力すると、入力装置１３６がその入力された前払金額をデータ処理部１３１に与える（Ｓ１０４）。
続いて、データ処理部１３１は表示装置１３７上に画面Ｄ５を表示し、利用者１２に対して前払金額の支払方法を選択するよう促す。利用者１２が入力装置１３６を操作すると、「通話料に加算」という支払方法の他、「クレジット」、「デビットカード」、「自動引落」といういくつかの支払方法が表示される。ここでは利用者１２が「通話料に加算」という支払方法を選択するものとする。これに応じて、入力装置１３６は「通話料に加算」という支払方法の選択をデータ処理部１３１に与える（Ｓ１０５）。
続いて、データ処理部１３１は選択された支払方法および入力された前払金額を送受信部１３５に与え、送受信部１３５はこれらを携帯電話会社１０に送信する（Ｓ１０６）。このとき、ＲＯＭ１３３に予め記憶されている利用者１２に固有の携帯電話番号と、ＲＯＭ１３３に予め記憶されている携帯電話機１３に固有のキーコードと、ＲＡＭ１３２に記憶されている未通知データとを併せて送信する。携帯電話番号は、携帯電話会社１０が携帯電話機１３を販売する際にＥＥＰＲＯＭのようなＲＯＭ１３３に予めプログラムする。キーコードは、携帯電話機メーカが携帯電話機を製造する際に製造番号や各携帯電話機固有の管理番号（サブスクライバＩＤ（識別子）、機体ＩＤ、端末ＩＤなどと呼ばれる）などをＥＥＰＲＯＭのようなＲＯＭ１３３に予めプログラムする。したがって、携帯電話番号は利用者１２に固有のもので、携帯電話機１３を買い換えた場合でも同じ携帯電話番号を登録することができる。ただし、利用者１２自身は携帯電話番号を書き換えることはできず、利用者１２の依頼に応じて携帯電話会社１０が書き換えることになる。これに対し、キーコードは携帯電話機１３に固有のものである。キーコードに製造番号を用いた場合、利用者１２はもちろん、携帯電話会社１０さえも書き換えることができない。キーコードに上述したサブスクライバＩＤのような管理番号を用いた場合、携帯電話会社１０は書き換えることができるが、利用者１２は書き換えることができない。
続いて、データ処理部１３１はこれまでの処理が正常に終了したか否かを判別し（Ｓ１０７）、正常に終了していない場合はその旨を表示装置１３７に表示し（Ｓ１０８）、接続を切断する（Ｓ１０９）。一方、正常に終了した場合は異常終了の表示をすることなく接続を一旦切断する（Ｓ１０９）。
一方、携帯電話会社１０に設置されているサーバ３０において、データ処理部３０１は、携帯電話機１３から送信された前払金額、支払方法、携帯電話番号およびキーコードを無線基地局３０３を通じて受信する（Ｓ２０１）。
続いて、データ処理部３０１は受信した携帯電話番号に基づいて個人情報データベース１１を検索する（Ｓ２０２）。
続いて、データ処理部３０１は受信したキーコードを検索した個人情報データベース１１のキーコードと比較し、キーコードが一致するか否か確認する（Ｓ２０３）。キーコードが一致した場合、データ処理部３０１は個人情報データベース１１の利用状況を確認し、問題があるか否か判別する（Ｓ２０４）。上記ステップＳ２０２でキーコードが一致しない場合、またはこのステップＳ２０４で利用状況に問題がある場合、データ処理部３０１は本サービス利用不可の情報を携帯電話機１３に送信する（Ｓ２０５）。
携帯電話機１３においては、送受信部１３５が携帯電話機１３から送信された本サービス利用不可能の情報を受信する（Ｓ１１０）
続いて、データ処理部１３１は図９に示した画面Ｄ６を表示装置１３７上に表示し、本サービスを利用できない旨を利用者１２に通知する（Ｓ１１１）。そして、データ処理部１３１は表示装置１３７上に異常に終了した旨を表示する（Ｓ１１２）。
一方、上記ステップＳ２０４で利用状況に問題がなければ、利用履歴データベース２８を更新する（Ｓ２０６）。具体的には、現在の日時と、今回の前受金額（利用者１２にとっては前払金額）と、現在の前受残高と、未通知データ（未通知の決済金額）とを利用履歴データベース２８に記録する。
続いて、データ処理部３０１は現在の前受残高を携帯電話機１３に送信する（Ｓ２０７）。
続いて、データ処理部３０１はこの前受金額について請求データを作成する（Ｓ２０８）。
続いて、データ処理部３０１は作成した請求データを毎月一括して通話料に加算し、図１に示すように請求書１４とともに本サービスの利用明細書１５を発行する。
以降の処理は既存の処理と同じで、利用者１２の個人情報データベース１１に登録されている口座番号に基づき利用者１２の取引銀行１７に対して料金の引落しを依頼する（Ｓ２０９）。これに応じて、本サービスの利用料金が通話料と併せて利用者の口座１６から携帯電話会社の口座１９に振替えられる。
携帯電話機１３においては、上記ステップＳ２０７でサーバ３０から送信された前受残高を送受信部１３５が受信する（Ｓ１１３）。
続いて、データ処理部１３１は受信した前受残高を前払残高としてＲＡＭ１３２に格納し、これにより前受残高を更新する（Ｓ１１６）。
続いて、データ処理部１３１は図９に示した画面Ｄ７を表示装置１３７に表示する（Ｓ１１７）。具体的には、これまでの前払処理が完了した旨と現在の前払残高とを表示する。
５−２．クレジットカードで支払う場合
図１０は、図２に示した前払金額をクレジットカードで支払う場合における携帯電話機１３およびサーバ３０の動作を示すフローチャートである。図１１は、この場合に携帯電話機１３の表示装置１３７に表示される画面の遷移図である。
上記と異なり前払金額をクレジットカードで支払う場合は、図１１に示した画面Ｄ５で利用者１２は「クレジット（一括）」を選択する。これに応じて、入力装置１３６はクレジットカードによる支払いという支払方法の選択をデータ処理部１３１に与える（図１０，Ｓ１０５）。
また、携帯電話会社１０のサーバ３０においては、利用状況に問題がない場合、個人情報データベース１１に予め登録されているクレジットカード番号に基づいて信販会社２０に利用者１２の与信照会を行なう（Ｓ２１０）。
続いて、データ処理部３０１は信販会社２０からの返信に基づいて信販会社２０がクレジットカードによる支払いを承認したか否かを判別する（Ｓ２１１）。
非承認の場合、データ処理部３０１は支払できない旨を携帯電話機１３に送信する（Ｓ２１２）。承認の場合は、利用履歴データベース２８を更新する（Ｓ２０５）。
一方、携帯電話機１３においては、送受信部１３５がサーバ３０からクレジットカードによる支払いは不可能な旨を受信した場合、図１２に示した画面Ｄ８を表示装置１３７に表示し、クレジットカードによる支払いが不可能な旨を利用者１２に通知する（Ｓ１２０）。
５−３．デビットカードで支払う場合
図１２は、前払金額をデビットカードで支払う場合の携帯電話機１３およびサーバ３０の動作を示すフローチャートである。図１３は、この場合に携帯電話機１３の表示装置１３７に表示される画面の遷移図である。
上記と異なり前払金額をデビットカードで支払う場合、図１３に示した表示画面Ｄ５において利用者１２は「デビットカード」を選択する。これに応じて、入力装置１３６はその選択情報をデータ処理部１３１に与える（Ｓ１０５）。
一方、携帯電話会社１０のサーバ３０においては、利用状況に問題がない場合、データ処理部３０１は個人情報データベース１１に予め登録されているデビットカード番号に基づいてそのデビットカードの発行銀行１７に引落し（承認）依頼を送信する（Ｓ２２０）。これに応じて、既存のデビットカード処理が実行される（Ｓ２２１）。
続いて、データ処理部３０１はデビットカードの発行銀行１７から送信された振替え結果に基づいて振替えが完了したか否かを判別する（Ｓ２２２）。振替えができなかった場合、データ処理部３０１はその旨を携帯電話機１３に送信する（Ｓ２１２）。
これに応じて携帯電話機１３のデータ処理部１３１は、図１３に示した画面Ｄ９を表示装置１３７に表示し（Ｓ１２０）、デビットカードによる支払いができない旨を利用者１２に通知する。
５−４．自動引落で即時支払う場合
図１４は、図４に示した前払金額を利用者の口座１６から自動的に引落す場合における携帯電話機１３およびサーバ３０の動作を示すフローチャートである。図１５は、この場合に携帯電話機１３の表示装置１３７に表示される画面の遷移図である。
上記と異なり自動引落しの場合、図１５に示した画面Ｄ５で利用者１２は「自動引落」を選択し、この利用者１２の操作に応じて入力装置１３６はデータ処理部１３１にその選択情報を与える（Ｓ１０５）。
一方、サーバ３０においては、利用状況に問題がない場合、データ処理部３０１は受信した前払金額が引落し可能か否かを利用者１２の取引銀行１７に照会する（Ｓ２３０）。
続いて、データ処理部３０１は銀行１７から返信された照会結果に基づいて引落しが可能か否かを判別する（Ｓ２３１）。引落しが不可能な場合、データ処理部３０１はその旨を携帯電話機１３に送信する（Ｓ２３２）。
これに応じて携帯電話機１３のデータ処理部１３１は、図１５に示した画面Ｄ１０を表示し（Ｓ１２０）、利用者の口座１６からは所望の前払金額を引落すことができない旨を利用者１２に通知する。
一方、引落しが可能な場合、携帯電話会社１０は既存の方法で銀行１７に引落しを依頼する（Ｓ２２３）。
６．決済時の処理動作
次に、携帯電話機１３を用いてインターネット上の仮想店舗および実在店舗で決済を行なう場合の動作について説明する。
６−１．仮想店舗で決済する場合
図１６は、仮想店舗で決済を行なう場合に用いられる利用者のパーソナルコンピュータ（ＰＣ）４０および携帯電話機１３、携帯電話会社のサーバ３０、ならびに仮想店舗のサーバコンピュータ（以下、単にサーバという）５０のハードウェア構成を示すブロック図である。
図１６に示すように、利用者１２のパーソナルコンピュータ４０は、ＣＰＵのようなデータ処理部４０１と、ＲＯＭやＲＡＭのようなメモリ４０２と、ハードディスク（ＨＤ）４０３と、モデム４０４と、キーボードやマウスのような入力装置４０５と、ＣＲＴディスプレイや液晶ディスプレイのような表示装置４０６とを備える。仮想店舗２４のサーバ５０も同様に、データ処理部５０１と、メモリ５０２と、ハードディスク５０３と、モデム５０４と、入力装置５０５と、表示装置５０６とを備える。パーソナルコンピュータ４０はモデム４０４を通じてインターネット６０に接続される。サーバ５０もモデム５０４を通じてインターネット６０に接続される。携帯電話会社１０のサーバ３０もモデム３０３を通じてインターネット６０に接続される。
図１７および図１８は、図１６に示したパーソナルコンピュータ４０、携帯電話機１３、サーバ３０および５０の動作を示すフローチャートである。
利用者１２はパーソナルコンピュータ４０の入力装置４０５を操作して仮想店舗２４に商品やサービスの注文を行ない、その決済方法として携帯電話決済を選択する。これに応じて、パーソナルコンピュータ４０のデータ処理部４０１は入力された注文情報および携帯電話番号をインターネット６０を通じて仮想店舗２４のサーバ５０に送信する（Ｓ３０１）。
サーバ５０のデータ処理部５０１は、送信された注文情報および携帯電話番号を受信する（Ｓ６０１）。
続いて、データ処理部５０１は、店舗名、決済金額、携帯電話番号などの請求情報をインターネット６０を通じて携帯電話会社１０のサーバ３０に送信することにより、携帯電話会社１０に利用者１２の決済金額を請求する（Ｓ６０２）。
サーバ３０のデータ処理部３０１は、送信された請求情報を受信する（Ｓ５０１）。
続いて、データ処理部３０１は受信した携帯電話番号に基づいて個人情報データベース１１を検索する（Ｓ５０２）。
続いて、データ処理部３０１は検索した利用者１２の個人情報の中から利用状況を照会し、問題がないか否か確認する（Ｓ５０３）。問題がある場合、データ処理部３０１は本サービス利用不可の情報をサーバ５０に送信する。これにより、本サービスを利用できない旨を仮想店舖２４に通知する（Ｓ５０４）。一方、利用状況に問題がない場合、データ処理部３０１は検索した個人情報の中から利用者１２の電子メールアドレスを特定し、電子メールで請求データを携帯電話機１３に送信する（Ｓ５０５）。これは、携帯電話会社１０が仮想店舗２４に代わって利用者１２に請求書を発行することを意味する。利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０のサーバ３０から送信された請求データを受信する（Ｓ４０１）。
利用者１２が携帯電話機１３の入力装置１３６を操作して「受信メール一覧」を選択すると、携帯電話機１３のデータ処理部１３１は図１９に示した画面Ｄ１１を表示装置１３７上に表示する。利用者１２が入力装置１３６を操作して請求データの電子メールを選択すると、データ処理部１３１は画面Ｄ１２を表示装置１３７上に表示する。これは電子請求書であり、注文日、注文者（通常は利用者１２と同じ）、請求者（通常は仮想店舗２４と同じ）、請求額（通常は決済金額と同じ）が表示されている。
利用者１２が請求内容を確認し、同意できれば「支払」を選択し、同意できなければ「拒否」を選択する。携帯電話機１３の入力装置１３６はこのような利用者１２の操作に応じて選択情報をデータ処理部１３１に入力する。データ処理部１３１は入力された選択情報に基づいて決済が承認されたか否かを判別する（Ｓ４０２）。決済が承認されなかった場合、送受信部１３５は決済取消・拒否の情報を携帯電話機１０のサーバ３０に送信する（Ｓ４０３）。この場合、データ処理部１３１は、図１９に示した画面Ｄ１３を表示装置１３７上に表示する（Ｓ４０４）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された決済取消・拒否の情報を受信し（Ｓ５０６）、さらにその情報を仮想店舗２４のサーバ５０に送信する（Ｓ５０７）。
仮想店舗２４のサーバ５０においては、データ処理部５０１が携帯電話会社１０のサーバ３０から送信された決済取消・拒否の情報を受信する（Ｓ６０５）。
続いて、データ処理部５０１は受信した決済取消・拒否の情報をインターネット６０を通じて利用者１２のパーソナルコンピュータ４０に送信し、これにより仮想店舗２４は利用者１２に決済が取消しまたは拒否された旨を利用者１２に通知する（Ｓ６０６）。
利用者１２のパーソナルコンピュータ４０においては、データ処理部４０１が仮想店舗２４のサーバ５０から送信された決済取消・拒否の情報を受信し（Ｓ３０４）、決済が取消しまたは拒否された旨を表示装置４０６上に表示する。
上記ステップＳ４０２で決済が承認された場合、携帯電話機１３のデータ処理部１３１は、ＲＡＭ１３２内に未通知データ（電波圏外の店舗で決済したために携帯電話会社１０に未だ通知できていない決済日時、決済金額などで、その詳細は後述する。）が存在しないか否かを判別する（Ｓ４０５）。未通知データがある場合、データ処理部１３１は未通知の決済金額を合計して累計未通知金額を計算し（Ｓ４０６）、続いてＲＡＭ１３２に記憶されている前払残高から累計未通知金額を減算して現時点における真の前払金額を計算する（Ｓ４０７）。
上記ステップＳ４０５で未通知データがない場合、または上記ステップＳ４０７の後、データ処理部１３１は前払残高を検証し、決済金額が前受残高以内か否かを判別する（Ｓ４０８）。決済金額が前受残高を超えている場合、データ処理部１３１は図１９に示した画面Ｄ１４を表示装置１３７上に表示して残高不足を利用者１２に通知し（Ｓ４０９）、続いて残高不足の情報を電波で携帯電話会社１０のサーバ３０に送信する（Ｓ４１０）。
これに応じて携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された残高不足の情報を受信し（Ｓ５０８）、続いてこの残高不足の情報をインターネット６０を通じて仮想店舗２４のサーバ５０に送信する（Ｓ５０９）。
仮想店舗２４のサーバ５０においては、データ処理部５０１が携帯電話会社１０のサーバ３０から送信された残高不足の情報を受信し（Ｓ６０７）、続いてこの残高不足の情報をインターネット６０を通じて利用者１２のパーソナルコンピュータ４０に送信する（Ｓ６０８）。利用者１２のパーソナルコンピュータ４０はこの残高不足の情報を受信し、その旨を表示装置４０６上に表示する（Ｓ３０５）。
一方、携帯電話機１３において、上記ステップＳ４０８で決済金額が前払残高以内の場合、データ処理部１３１は図１９に示した画面Ｄ１を表示し、利用者１２にパスワードの入力を促す。利用者１２がパスワードを入力すると、入力装置１３６は入力されたパスワードをデータ処理部１３１に与える（Ｓ４１１）。
続いて、送受信部１３５は、決済承認の情報および未通知データを携帯電話会社１０のサーバ３０に電波で送信する（Ｓ４１２）。具体的には、携帯電話機１３の電話番号、ＲＯＭ１３３に予めハード的に登録されているキーコード、上記ステップＳ４１１で入力されたパスワード、未通知の決済金額を送信する。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された決済承認の情報を受信する（Ｓ５１０）。
続いて、データ処理部３０１は個人情報データベース１１を検索し、受信した携帯電話番号に基づいて利用者１２の個人情報を特定する。データ処理部３０１はさらに、受信したキーコードを利用者１２の個人情報として予め登録されているキーコードと比較し、キーコードが一致するか否かを判別する（Ｓ５１１）。キーコードが一致した場合、データ処理部３０１は、受信したパスワードを利用者１２の個人情報として予め登録されているパスワードと比較し、パスワードが一致するか否かを判別する（Ｓ５１２）。
キーコードが一致しない場合、またはパスワードが一致しない場合、データ処理部３０１は本サービス利用不可の情報を携帯電話機１３に電波で送信し、これにより携帯電話会社１０は利用者１２に本サービスが利用できない旨を通知する（Ｓ５１３）。
利用者の携帯電話機１３においては、送受信部１３５が携帯電話会社１０のサーバ３０から送信された本サービス利用不可の情報を受信する（Ｓ４１３）。
続いて、データ処理部１３１は本サービスが利用できない旨を表示装置１３７上に表示する（Ｓ４１４）。
続いて、データ処理部１３１は本サービス手続が異常に終了した旨を表示装置１３７上に表示する（Ｓ４１５）。
一方、携帯電話会社１０の携帯電話機１３において、データ処理部３０１は決済不可の情報をインターネット６０を通じて仮想店舗２４のサーバ５０に送信する（Ｓ５１４）。
仮想店舗２４のサーバ５０においては、データ処理部５０１が携帯電話会社１０のサーバ３０から送信された決済不可の情報を受信する（Ｓ６０９）。
これに応じて、データ処理部５０１は決済不可の情報をインターネット６０を通じて利用者１２のパーソナルコンピュータ４０に送信し、これにより仮想店舗２４は利用者１２に決済ができない旨を通知する（Ｓ６１０）。
利用者１２のパーソナルコンピュータ４０においては、データ処理部４０１が仮想店舗２１のサーバ５０から送信された決済不可の情報を受信し（Ｓ３０６）、決済ができない旨を表示装置４０６上に表示する。
一方、携帯電話会社１０のサーバ３０においては、上記ステップＳ５１２でパスワードが一致した場合、データ処理部３０１は利用履歴データベース２８を更新し、利用者１２の仮想口座１１０の前受残高を更新する（Ｓ５１５）。利用履歴データベース２８には具体的には、決済日時、決済金額などを記録する。
続いて、データ処理部３０１は更新した前受残高を電波で携帯電話機１３に送信する（Ｓ５１６）。
携帯電話機１３においては、データ処理部１３１が携帯電話会社１０のサーバ３０から送信された仮想口座１１０の前受残高を受信する（Ｓ４１６）。
続いて、データ処理部１３１は受信した仮想口座の前受残高と同じになるようにＲＡＭ１３２に記憶されている前払残高を更新し、さらにＲＡＭ１３２に記憶されている未通知データをクリアする（Ｓ４１７）。これにより、携帯電話機１３内の前払残高と携帯電話会社内の仮想口座１１０の前受残高とが同期する。
そして、データ処理部１３１は図１９に示した画面Ｄ１５を表示装置１３７上に表示し、決済が完了した旨を利用者１２に通知する。
携帯電話会社１０のサーバ３０においては、上記ステップＳ５１６の後、決済完了の情報をインターネット６０を通じて仮想店舗２４のサーバ５０に送信し、これにより携帯電話会社１０は決済が完了した旨を仮想店舗２４に通知する（Ｓ５１７）。そして、携帯電話会社１０は既存の方法で仮想店舗２４に決済金額を支払う（Ｓ５１８）。
一方、仮想店舗２４のサーバ５０においては、データ処理部５０１は携帯電話会社１０のサーバ３０から送信された決済完了の情報を受信する（Ｓ６１１）。
続いて、データ処理部５０１は受注明細および決済完了の情報をインターネット６０を通じて利用者１２のパーソナルコンピュータ４０に送信する（Ｓ６１２）。
利用者１２のパーソナルコンピュータ４０においては、データ処理部４０１が仮想店舗２４のサーバ５０から送信された受注明細および決済完了の情報を受信する（Ｓ３０７）。
６−２．実在店舗で決済する場合
図２０は、実在店舖で決済する場合に用いられる携帯電話機１３、ＰＯＳ端末３７およびサーバ３０のハードウェア構成を示すブロック図である。
図２０に示すように、ＰＯＳ端末２７も同様に、データ処理部２７１と、ＲＡＭ２７２と、ハードディスク２７３と、入力装置２７４と、表示装置２７５と、インターフェイス（Ｉ／Ｆ）部２７６とを備える。決済時に携帯電話機１３がセットされる読取装置２７０はインターフェイス２７６に接続される。商品バーコードを読取るためのスキャナもインターフェイス部２７６に接続される。現金引出し部２７８もインターフェイス部２７６に接続される。
図２１および図２２は、図６に示したように実在店舗で決済する場合における携帯電話機１３、ＰＯＳ端末２７およびサーバ３０の動作を示すフローチャートである。
まず利用者１２は実在店舗２６で買物する前に、図２３に示した画面Ｄ１で携帯電話機１３の入力装置１３６を操作してパスワードを入力し、これに応じて入力装置１３６は入力されたパスワードをデータ処理部１３１に与える（Ｓ７０１）。
続いて、データ処理部１３１は入力されたパスワードを、図２４に示すようにＲＡＭ１３２に予め登録されているパスワードと比較し、パスワードの検証を行なう（Ｓ７０２）。パスワードが一致しない場合、データ処理部１３１は図２３に示した画面Ｄ２を表示装置１３７上に表示する（Ｓ７０３）。
一方、パスワードが一致した場合、データ処理部１３１は図２３に示したメニュー画面Ｄ３を表示する。利用者１２が「▲１▼お金を払う」を選択すると、データ処理部１３１は未通知データがあるか否かを判別する（Ｓ７０４）。未通知データは、電波圏外の店舗で決済した場合に、その決済金額、決済日時、決済店舗なｄが図２４に示すようにＲＡＭ１３２に累積的に格納されたものである。未通知データがある場合、データ処理部１３１は電波圏内か否かを判別し（Ｓ７０５）、電波圏内の場合、送受信部１３５は電波で携帯電話会社１０のサーバ３０に未通知データを図２４に示すようにＲＯＭ１３３に予め登録されたキーコードとともに送信する（Ｓ７０６）。電波圏外の場合、ＲＡＭ１３２に記憶されている未通知の決済金額を合計して累計未通知金額を計算し（Ｓ７０７）、続いてＲＡＭ１３２に記憶されている前払残高からその累計未通知金額を減算し、現在の真の前払残高を計算する（Ｓ７０８）。携帯電話機１３内の前払残高は、携帯電話会社１０から仮想口座１１０の前受残高が送信されて来ない限り更新されない。したがって、電波圏外の実在店舗で連続して携帯電話機１３で決済を行なった場合などは、その各決済金額を未通知データとしてＲＡＭ１３２に記憶しておく。
一方、携帯電話会社１０のサーバ３０においては、上記ステップＳ７０６で利用者１２の携帯電話機１３から送信された未通知データをデータ処理部３０１が受信する（Ｓ９０１）。
続いて、データ処理部３０１は、携帯電話機１３から送信されたキーコードを、個人情報データベース１１に予め登録されているキーコードと比較し、キーコードが一致するか否かを確認する（Ｓ９０２）。キーコードが一致しない場合、データ処理部３０１は本サービス利用不可の情報を携帯電話機１３に電波で送信し、これにより携帯電話会社１０は利用者１２に本サービスが利用できない旨を通知する（Ｓ９０３）。キーコードが一致する場合、データ処理部３０１は受信した未通知データに基づいて利用履歴データベース２８を更新し、仮想口座１１０の前受残高を更新する（Ｓ９０４）。続いて、データ処理部３０１は更新した最新の前受残高を携帯端末機１３に送信する（Ｓ９０５）。
携帯電話機１３においては、上記ステップＳ９０３で携帯電話会社１０のサーバ３０から送信された本サービス利用不可の情報を送受信部１３５が受信する（Ｓ７０９）。続いて、データ処理部１３１は本サービスが利用できない旨を表示装置１３７上に表示し（Ｓ７１０）、さらに本サービス手続が異常に終了した旨を表示装置１３７上に表示する（Ｓ７１１）。
また、上記ステップＳ９０５で携帯電話会社１０のサーバ３０から送信された前受残高を送受信部１３５が受信する（Ｓ７１２）。続いて、データ処理部１３１は受信した前受残高と同じになるようにＲＡＭ１３２に記憶されている前払残高を更新し、さらに未通知データをクリアする（Ｓ７１３）。
上記ステップＳ７０４で未通知データがない場合、または上記ステップＳ７０８もしくはＳ７１３の後、データ処理部１０３は図２３に示した画面Ｄ１６のように現在利用可能な残高を表示する（Ｓ７１４）。
続いて、携帯電話機１３の決済モードがオンになり、データ処理部１３１は図２３に示した画面Ｄ１７を表示装置１３７上に表示する（Ｓ７１５）。
続いて、利用者１２は携帯電話機１３を読取装置２７０にセットする（Ｓ７１６）。これにより、データ処理部１３１は図２３に示した画面Ｄ１８を表示装置１３７上に表示する。このとき、実在店舗のＰＯＳ端末２７においては、データ処理部２７１が読取装置２８を通じて携帯電話機１３に決済金額を送信する（Ｓ８０１）。
携帯電話機１３においては、データ処理部１３１はＰＯＳ端末２７から送信された決済金額を受信する（Ｓ７１７）。
続いて、データ処理部１３１は受信した決済金額が現在の残高内か否かを判別する（Ｓ７１８）。決済金額が残高を超えている場合、データ処理部１３１は図２３に示した画面Ｄ１９を表示装置１３７上に表示し、残高不足を利用者１２に通知する（Ｓ７１９）。
決済金額が残高内の場合、データ処理部１３１は携帯電話機１３の電話番号およびＲＯＭ１３３に予めハード的に登録されているキーコードを読取装置２８を通じてＰＯＳ端末２７に送信する（Ｓ７２０）。
ＰＯＳ端末２７においては、データ処理部２７１が携帯端末機１３から送信された携帯電話番号およびキーコードを受信する（Ｓ８０２）。
続いて、データ処理部２７１は受信した携帯電話番号およびキーコードならびに決済内容をハードディスク２７３に記録する（Ｓ８０３）。
続いて、データ処理部２７１は決済完了の情報を読取装置２７０を通じて携帯電話機１３に送信する（Ｓ８０４）。
携帯電話機１３においては、データ処理部１３１がＰＯＳ端末２７から送信された決済完了の情報を受信し、取引完了を確認する（Ｓ７２１）。
続いて、データ処理部１３１はこのときの決済金額などを含む決済内容を未通知データとしてＲＡＭ１３２に記憶する（Ｓ７２２）。
上記ステップＳ７１６〜Ｓ７２２の間、データ処理部１３１は図２３に示した画面Ｄ１８を表示装置１３７上に表示する。また、携帯電話機１３が途中で読取装置２７０から取外された場合は異常終了となる。上記ステップＳ７２２で決済内容をＲＡＭ１３２に記憶した後、データ処理部１３１は図２３に示した画面Ｄ２０を表示装置１３７上に表示する。そして、上記決済モードはオフになる（Ｓ７２３）。
続いて、データ処理部１３１は電波圏内か否かを判別し（Ｓ７２４）、電波圏内の場合、ＲＡＭ１３２に蓄積されている未通知データをＲＯＭ１３３にプログラムされているキーコードとともに携帯電話会社１０のサーバ３０に送信する（Ｓ７２５）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された未通知データをキーコードとともに受信する（Ｓ９０９）。
続いて、データ処理部３０１は、携帯電話機１３から送信されたキーコードを、個人情報データベース１１に予め登録されているキーコードと比較し、キーコードが一致するか否かを確認する（Ｓ９１０）。キーコードが一致しない場合、データ処理部３０１は本サービス利用不可の情報を携帯電話機１３に電波で送信する（Ｓ９１１）。携帯電話機１３は、この情報を受信し（Ｓ７２６）、続いて本サービスが利用できない旨を表示装置１３７上に表示し（Ｓ７２７）、そして本サービス手続が異常に終了した旨を表示装置１３７上に表示する（Ｓ７２８）。
上記ステップＳ９１０でキーコードが一致する場合、データ処理部３０１は受信した未通知データに基づいて利用履歴データベース２８を更新し、仮想口座１１０の前受残高を更新する（Ｓ９１２）。
続いて、データ処理部３０１は最新の前受残高を携帯電話機１３に送信する（Ｓ９１３）。
携帯電話機１３においては、携帯電話会社１０のサーバ３０から送信された前受残高を受信し、この受信した前受残高と同じになるようにＲＡＭ１３２に記憶されている前払残高を更新し、さらに未通知データをクリアする（Ｓ７２９）。
一方、実在店舗２６のＰＯＳ端末２７においては、データ処理部２７１が上記決済内容を携帯電話会社１０のサーバ３０に送信する（Ｓ８０５）。決済内容の送信は取引ごと、つまりリアルタイムで行なうのが望ましいが、営業終了後に一括してバッチ処理で行なってもよい。
携帯電話会社１０のサーバ３０においては、データ処理部３０１はＰＯＳ端末２７から送信された決済内容を受信する（Ｓ９０６）。
続いて、データ処理部３０１は決済完了の情報をＰＯＳ端末２７に送信する（Ｓ９０７）。そして、携帯電話会社１０は決済内容に基づいて実在店舗２６に対して支払処理を行なう（Ｓ９０８）。
ＰＯＳ端末２７においては、データ処理部２７１が携帯電話会社１０のサーバ３０から送信された決済完了の情報を受信する（Ｓ８０６）。
上記第１の実施の形態ではＰＯＳ端末２７から決済金額を携帯電話機１３に送信し、携帯電話機１３が決済の可否を判定しているが、携帯電話機１３から仮想口座の残高をＰＯＳ端末２７に送信し、ＰＯＳ端末２７が決済の可否を判定するようにしてもよい。また、上記第１の実施の形態では携帯電話機１３を読取装置２７０を用いてＰＯＳ端末２７に電気的に接続しているが、近距離無線（たとえばブルートゥース（Ｂｌｕｅｔｏｏｔｈ））、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）またはＩｒＤＡ（Ｉｎｆｒａｒｅｄ Ｄａｔａ Ａｓｓｏｃｉａｔｉｏｎ）で接続したり、あるいはバーコードリーダを用いて光学的に接続してもよい。バーコードリーダを用いる場合、携帯電話機１３からＰＯＳ端末２７に送信するデータをバーコードで表示装置１３７に表示し、これをバーコードリーダで読取るようにすればよい。これらの変更は後述する実施の形態でも適用可能である。
７．本サービスの利点
７−１．クレジットカード番号、キャッシュカード番号、口座番号がインターネット上に流れない。
クレジットによる決済の場合、クレジットカード番号さえあれば決済可能な場合があり、特にインターネット上の決済においては、利用者はクレジットカード番号を入力することに強い不安と抵抗を感じることになり、事実、第三者にクレジットカード番号を知られると決済されてしまう危険性や、店頭においてもカード番号が盗まれる危険性は否定できない。しかしながら、この実施の形態ではインターネット上に流れる決済取引データにクレジットカード番号は含まれておらず、携帯電話番号がその役目を果たすものである。また、携帯電話番号はその利用目的上、広く第三者に知られているが、第三者が他人の携帯電話番号のみを知っていても携帯電話機そのものを持っていないと、実在店舗でもインターネット上の仮想店舗でも決済を完了できないうえ、決済限度額が仮想口座内の残高に限定されるため、安全性は高い。
７−２．決済の際に信用照会および承認が不要である。
利用者が携帯電話会社の仮想口座に資金を預ける（前払）する際に、その支払方法ごとに必要とされる信用照会および承認が行なわれるので、利用者がインターネット上の仮想店舗や実在店頭で決済するときには、決済金額が前払残高以内であるか否かを確認するだけでよい。現在、店頭決済時に必要とされている承認番号の取得や本人の署名などの手続が不要となる。
７−３．店頭決済時に電波を飛ばす必要がない（電波圏外でもよい）。
この実施の形態では、店頭決済時に携帯電話機から必ずしも電波を飛ばす必要はない。したがって、店頭決済を行なう場所が電波圏内であるかどうかを意識する必要がない。よって、電波圏外の多い都市圏の地下街やビル内部、地下鉄構内、地下に設置されている自動販売機や券売機などでも決済することが可能である。携帯電話機が電波圏外にあり、決済金額が携帯電話会社に未通知状態になっていても、携帯電話機の内部メモリに未通知金額が記憶された状態で残り、次回取引発生時には未通知データが必ず送信され、仮想口座の残高が携帯電話機と携帯電話会社との間で同期がとれている状態になってから次の決済処理に入る。
７−４．２４時間仮想口座への振替が可能である。
インターネット上の仮想店舖または実在店舗での決済時に仮想口座の残高が不足しても、原則としてその場で２４時間いつでも仮想口座への資金の振替（前払）をすることが可能であるので、時間を問わず買物ができる。
７−５．決済の際に与信枠や残高を意識する必要がない。
従来、店頭でクレジットカードによる決済をする際に利用限度額を超過するため、クレジットカードによる決済を拒否されることがあり、現金の持ち合せが十分でないときには決済そのものが不可能になることもある。そのため、複数のクレジットカードを使い分けている利用者も多く、かといって利用者が各社クレジットカードごとにその限度額を認識しておくことは現実的には困難である。これに対し、この実施の形態では利用者がいつでも携帯電話会社内の仮想口座に振替済である金額、つまり前払残高を携帯電話機で確認することが可能であり、その上その残高内であれば常に決済可能であることが保証されている。
７−６．利用者は、クレジットカードやデビットカードなどの既存決済手段を提供している売り手から提供されている各サービスプログラムを継続して利用可能である。
利用者は、クレジットカードなどの既存決済手段等を利用して携帯電話会社の仮想口座に資金を振込むことで、信販会社などが提供しているサービスを継続して受けることができる。
７−７．クレジットカードを持てない世代でも後払が可能である。
利用者が携帯電話会社内の仮想口座に「通話料に加算」という支払方法で資金の振替を指定する場合、実際に利用者の口座から資金が引落されるのは通話料金の引落し時点である。よって、クレジットカードを持てない世代でも通話料の引落し時に口座に資金があればよいことになり、クレジットカードのような「擬似翌月一括払」が可能となる。
７−８．宅配業者が提供する「代金引換え」において利用可能となれば、利用者は予め現金を準備しておく必要がなくなる。
宅配業者は、商品配達時に代金を回収する手段として、携帯電話機による決済を導入することにより、利用者は現金を予め用意する必要がなくなり、宅配業者は配達員に釣銭を持たせる必要が軽減する。店頭のＰＯＳ端末のように携帯電話会社のサーバと決済ごとにデータの送受信を行なわず、一括してその日の業務終了後に送信する方法や、その都度無線で送受信する方法等が考えられる。また、こういった移動先での決済を可能とする端末は、小規模店舗等でも流用可能であるうえ、導入が容易である。
７−９．銀行振込やコンビニエンスストアでの決済と比較して手数料が割安である。
携帯電話会社内の仮想口座への資金の振替を「通話料に加算」という支払方法で行なう場合、利用者は１００円〜２００円程度の月額使用料を支払う。少額決済を同じ月内に繰返し行なう場合等は、銀行振込みやコンビニエンスストアでの決済を利用する場合よりも利用者が負担する手数料が安く済むことになる。
７−１０．手数料負担が公平である。
現行のクレジットカードやデビットカードによる決済では、手数料を加盟店が負担しており、その課金方法では少額決済では売上利益を圧迫するため、クレジットカードやデビットカードによる決済を採用していない（加盟していない）店舗がある。一方、この実施の形態では携帯電話会社への資金振込みの際にクレジットカードやデビットカードを利用する場合、極端な少額を振替える例は少ないと想定され、必要に応じて携帯電話会社が資金振替の際の最低金額やその単位を予め設定することにより、携帯電話会社が負担する信販会社等に支払う手数料と収入金額のバランスを取ることが可能である。一方、携帯電話会社から加盟店へ資金を振替える際には、その振替金額の一定期間中の合計に対して手数料が計算され、課金される。つまり、利用者が決済するごとに、その決済金額に対して手数料が加盟店に課金される現状のクレジットカードやデビットカードによる決済方法とは違い、加盟店は携帯電話会社からその合計金額に対する手数料を課金されることになり、少額決済の多い店舗（企業）であっても導入しやすく、個々の取引決済金額の大小にかかわらず、手数料負担が公平である。つまり、従来の決済システムでは、少額決済が大半を占める店舗、企業（たとえばコンビニエンスストア）でも、利益率を圧迫されることがない。
７−１１．少額取引に適した決済システムである。
上記７−１０のとおり、手数料負担が公平であることから、少額決済が大半を占める店舗や企業（たとえばコンビニエンスストア）でも、売上利益を圧迫されることはない。また、クレジットカードやデビットカードによる決済方法を導入している店舗や企業でも、負担する手数料の売上金額に対する割合を考慮し、利用可能な最低決済金額（たとえば３０００円以上）が設けられていることが多いが、この実施の形態では手数料は一定期間中の合計決済金額に対して課金されるので、限度額設定の必要がない。
７−１２．携帯電話機に金銭的な価値を付加するものではない。
現在、進行中の電子マネー計画では携帯電話機に金銭情報そのものをダウンロードして利用することを目的としているが、この実施の形態では仮想口座から振込を実現するための道具として携帯電話機を使用するものであり、電子マネーを仮想口座に振込む資金として利用することも可能である。商取引に携帯電話会社および決済サイトを介在させることにより、その安全性と利便性を高めることが目的であり、携帯電話機に金銭価値を付加するものではない。したがって、電子マネーは紛失したら現金を紛失することと同じであるが、この実施の形態では携帯電話機を落としても金銭的価値が消失するものではない。
７−１３．端末の不正使用に対する安全性
紛失や盗難の際も携帯電話会社にサービス停止を依頼することが可能であり、サービス停止になるまでに店頭で悪用されたとしても、利用できる金額は仮想口座内の残高内である。また、本人が携帯電話機を所有しているにもかかわらず、その携帯電話番号がインターネット上で第三者に悪用された場合でも、他の決済手段では決済が完了するまでまたは利用明細書が届くまで本人が認識することが困難であるのに対し、この実施の形態では決済確認がすべて携帯電話機に送信されることから、決済が完了する前に本人が認識し、未然に防ぐことが可能である。なお、携帯電話機の利用契約者が本サービスの停止を携帯電話会社に申告している場合は、インターネット上での決済の場合は携帯電話機の利用状況の確認の際に、実在店舗での決済の場合は決済モードをオンにする際にサービスの利用不可として通知される。
７−１４．携帯電話機と携帯電話会社のサーバ間での取引の安全性が高い。
携帯電話機から携帯電話会社のサーバには携帯電話番号とキーコードとがペアで送信され、携帯電話会社はこの両者を用いて認証を行なっている。携帯電話番号は利用者に固有で、キーコードは携帯電話機に固有であるから、利用者１２の携帯電話番号を知っている第三者であっても、利用者１２自身の携帯電話機１３以外の携帯電話機を使って上述した取引を行なうことはできない。
７−１５．短時間で決済が完了する。
上記７−２のとおり、与信照会は前払い時に行ない、決済時には行なう必要がないので、決済にかかる時間は短い。この時間は、現在実在店舗で行なわれているクレジットカードやデビッドカードによる決済にかかる時間よりも短い。
［第２の実施の形態］
以上、本発明の実施の形態を説明したが、本発明はその他の形態でも実施可能なものである。たとえば上記実施の形態では携帯電話会社に仮想口座を設けているが、銀行のような金融機関に仮想口座を設けでもよく、要するに携帯電話機と直接または間接的に通信可能なサーバに仮想口座を設ければよい。以下、本発明の第２の実施の形態を上記第１の実施の形態との相違点を中心に説明する。
１．資金移動
図２５は、この発明の第２の実施の形態における資金移動を示す概略図である。図１に示した第１の実施の形態と異なり、この第２の実施の形態では図２５に示すように、利用者１２の仮想口座１１０が銀行などの金融機関７０のサーバコンピュータに設けられる。この仮想口座１１０には残高の他、実在口座番号、仮想口座番号、携帯電話会社、および携帯電話番号が記憶される。実在口座番号としては、利用者１２が金融機関７０に実際に開設している口座の番号が登録される。仮想口座番号としては、この仮想口座１１０を特定するための番号が登録される。携帯電話会社としては、利用者１２が契約している携帯電話会社１０の名称が登録される。携帯電話番号としては、利用者１２の携帯電話機１３の携帯電話番号が登録される。
金融機関７０には仮想口座１１０の他、利用者１２の実在口座７１０、仮想口座１１０の入出金履歴データベース７１２、および仮想口座１１０の決済履歴データベース７１４が設けられる。利用者１２の実在口座７１０には、実在口座番号および口座残高が記憶される。入出金履歴データベース７１２には、仮想口座１１０の口座番号と、仮想口座１１０の入出金の日付と、その入出金額とが記憶される。決済履歴データベース７１４には、仮想口座１１０の口座番号と、仮想口座１１０の入出金の日付と、決済金額と、携帯電話機１３にその時点での仮想口座残高を携帯電話機１３に通知したか否かを示す状態とが記憶される。一方、携帯電話会社１０のサーバコンピュータにおける個人情報データベース１１には利用者１２が取引している金融機関７０の名称が記憶される。
図２６は、資金移動に用いられる携帯電話機、携帯電話会社のサーバ、および金融機関のサーバのハードウェア構成を示すブロック図である。上記図７に示した第１の実施の形態と異なり、この第２の実施の形態では図２６に示すように携帯電話会社１０のサーバ３０のデータベース３０２には前受け履歴や決済履歴は記録されない。また、この個人情報データベース１１には仮想口座情報は記録されない。その代わり、金融機関７０のサーバ７２にはデータベース７０２が設けられ、このデータベース７０２に仮想口座情報１１０、仮想口座入出金履歴７１２、および仮想口座決済履歴７１４が記録される。サーバ７２のデータ処理部７０１はサーバ３０のデータ処理部３０１と通信し、データベース７０２を用いて決済処理を行なう。
図２７および図２８は、金融機関７０の仮想口座１１０に資金を振替える場合における携帯電話機１３、携帯電話会社のサーバ３０、および金融機関のサーバ７２の動作を示すフローチャートである。図２９は、この場合に携帯電話機１３に表示される画面の遷移図である。
図２７に示すようにこの第２の実施の形態では、ステップＳ１０４において、利用者１２は携帯電話機１３の入力装置１３６を操作して所望の振替金額を入力する。これにより、入力装置１３６はその入力された振替金額をデータ処理部１３１に与える。
続いて、携帯電話機１３の送受信部１３５は、携帯電話番号、キーコードおよび未通知データとともに、その入力された振替金額を携帯電話会社１０のサーバ３０に送信する。
携帯電話会社１０のサーバ３０においては、上記第１の実施の形態と同様に、受信した携帯電話番号およびキーコードを用いて認証を行なった後（Ｓ２０２，Ｓ２０３）、図２８に示すように利用者１２の取引銀行へ振替依頼を送信する（Ｓ２４０）。具体的には、利用者１２の個人情報データベース１１から利用者１２の取引銀行の名称（ここではＢ銀行）を読出し、Ｂ銀行のサーバ７２に利用者１２の携帯電話番号および振替金額を送信し、これにより利用者１２の実在口座７１０から仮想口座１１０にその送信した金額を振替えるよう依頼する。
金融機関７０のサーバ７２においては、データ処理部７０１が携帯電話会社１０から送信された上記振替依頼を受信する（Ｓ１０００）。
続いて、データ処理部７０１は利用者１２の実在口座７１０を参照して振替が可能か否かを判定する（Ｓ１００１）。依頼のあった振替金額が実在口座７１０の残高を超えている場合、データ処理部７０１は振替不可の情報を携帯電話会社１０のサーバ３０に送信する（Ｓ１００２）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が金融機関７０から送信された振替不可の情報を受信し（Ｓ２４１）、引続きこれを利用者１２の携帯電話機１３に送信する（Ｓ２４２）。
利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０から送信された振替不可の情報を受信する（Ｓ１４０）。
続いて、データ処理部１３１は表示装置１３７上に図２９に示した画面Ｄ２１を表示し（Ｓ１４１）、残高不足のために振替ができない旨を利用者１２に通知する。
続いて、データ処理部１３１は表示装置１３７上に異常終了を表示する（Ｓ１４２）。
上記ステップＳ１００１において依頼のあった振替金額が実在口座７１０の残高以内の場合、データ処理部７０１はその依頼のあった金額を実在口座７１０から仮想口座１１０に振替える（Ｓ１００４）。
続いて、データ処理部７０１は上記振替金額に基づいて入出金履歴データベース７１２を更新する（Ｓ１００５）。
続いて、上記ステップＳ１０００で受信した情報の中に未通知データがあるか否かをデータ処理部７０１が判別する（Ｓ１００５）。上記ステップＳ７０４で未通知データが存在し、上記ステップＳ１０６で携帯電話機１３から携帯電話会社１０に未通知データを送信し、さらに上記ステップＳ２４０で携帯電話会社１０から金融機関７０に未通知データを送信している場合、データ処理部７０１はその未通知データに基づいて決済履歴データベース７１４を更新する（Ｓ１００６）。未通知データが存在しない場合、データ処理部７０１は仮想口座１１０の残高を携帯電話会社１０に送信する（Ｓ１００７）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が金融機関７０から送信された仮想口座１１０の残高を受信し（Ｓ２４３）、引続きこれを利用者１２の携帯電話機１３に送信する（Ｓ２０７）。
携帯電話機１３においては、上記第１の実施の形態と同様に送受信部１３５が携帯電話会社１０から送信された仮想口座１１０の残高を受信し（Ｓ１１３）、データ処理部１３１がＲＡＭ１３２に記録されている仮想口座の残高を更新し（Ｓ１１４）、最後に表示装置１３７上に振替が完了した旨を表示する（Ｓ１１５）。ここで、未通知データが存在する場合はその未通知データをクリアする（Ｓ１４３）。
２．仮想店舗での決済
図３０は、この発明の第２の実施の形態による仮想店舗での決済を示す概略図である。図３０に示すように、ここではインターネット上の仮想店舗２４と金融機関７０との間に決済機関８０が設けられる。決済機関８０は本サービスが利用される度に決済情報８１０を蓄積し、蓄積した多数の決済情報８１０に基づいて仮想店舗２４に対して利用代金を一括して支払う。決済情報８１０には、銀行名として金融機関７０の名称、支払者名として利用者１２の氏名または名称、振替金額、仮想口座１１０の仮想口座番号、および支払先としてインターネット上の仮想店舗２４の名称が含まれている。
図３１は、仮想店舗での決済に用いられるパーソナルコンピュータ４０、携帯電話機１３、携帯電話会社１０のサーバ３０、金融機関７０のサーバ７２、決済機関８０のサーバ８２、および仮想店舗２４のサーバ５０のハードウェア構成を示すブロック図である。図３１に示すように、決済機関８０のサーバ８２には、データ処理部８０１と、データベース８０２とが設けられる。データベース８０２には決済情報８１０が蓄積される。データ処理部８０１はサーバ７２のデータ処理部７０１と通信し、データベース８０２に蓄積した決済情報８１０に従って仮想店舗２４に対して支払処理を行なう。
図３２〜図３４は、仮想店舗２４で決済を行なう場合におけるパーソナルコンピュータ４０、携帯電話機１３、携帯電話会社１０のサーバ３０、仮想店舗２４のサーバ５０、および金融機関７０のサーバ７２の動作を示すフローチャートである。ここでは説明を簡単にするために、決済機関８０のサーバ８２の動作を省略する。
図１７に示した第１の実施の形態と同様に、携帯電話会社１０のサーバ３０は仮想店舗２４からの請求データを携帯電話機１３に送信する（Ｓ５０５）。
携帯電話機１３においては、送受信部１３５がその請求データを受信する（Ｓ４０１）。
続いて、その電子メールで送られてきた電子請求書を開封する（Ｓ４２０）。 続いて、上記第１の実施の形態と同様に未通知データを処理した後（Ｓ４０５〜Ｓ４０７）、データ処理部１３１が表示装置１３７上に請求内容および利用可能残高（たとえば図３５に示した画面Ｄ２２またはＤ２３）を表示する（Ｓ４２１）。
続いて、データ処理部１３１は請求額が利用可能残高以内か否かを検証する（Ｓ４２２）。請求額が利用可能残高以内の場合、図３５の画面Ｄ２２のように「支払」のボタンが表示される。請求額が利用可能残高を超えている場合、図３５の画面Ｄ２３のように「お財布にお金を入れる」のボタンが表示される。
請求額が利用可能残高を超えている場合、データ処理部１３１は利用者１２の操作に応じて追加資金を振替えるか否かを判別する（Ｓ４２３）。追加資金を振替える場合は上述した資金振替を行ない（Ｓ４２４）、追加資金を振替えない場合はステップＳ４０３に移る。
上記ステップＳ４２２で請求額が利用可能残高以内の場合、上記第１の実施の形態と同様に利用者１２が決済を承認したか否かを判別する（Ｓ４０２）。
また、携帯電話会社１０のサーバ３０において、パスワードを確認した後（Ｓ５１２）、データ処理部３０１は金融機関７０に対して決済依頼の情報を送信するとともに、未通知データが存在する場合はその未通知データを送信する（Ｓ５２０）。
金融機関７０のサーバ７２においては、データ処理部７０１が携帯電話会社１０から送信された決済依頼の情報を受信する（Ｓ１１００）。
続いて、データ処理部７０１は受信した決済金額を利用者１２の仮想口座１１０から振替える（Ｓ１１０１）。未通知データを受信している場合、その未通知の決済金額も利用者１２の仮想口座１１０から振替える。ここでは、仮想店舗２４への決済金額の振替を決済機関８０に依頼する。決済機関８０は依頼のたびにその決済金額を仮想店舗２４に支払うのではなく、たとえば所定の月度単位で複数の決済金額をまとめて仮想店舗２４に支払う。このような決済機関８０は必ずしも必要なく、金融機関７０が決済金額を直接仮想店舖２４に支払うようにしてもよい。ただし、決済機関８０を設けた方が振替の度に発生する手数料を抑えることができる。
続いて、データ処理部７０１はその決済金額に基づいて入出金履歴データベース７１２を更新する。（Ｓ１１０２）。
続いて、データ処理部７０１はその決済金額に基づいて決済履歴データベース７１４を更新する。（Ｓ１１０３）。
続いて、データ処理部７０１は仮想口座１１０の残高を読出して携帯電話会社１０に送信する（Ｓ１１０４）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が金融機関７０から送信された仮想口座残高を受信し（Ｓ５２１）、引続きこれを利用者１２の携帯電話機１３に送信する（Ｓ５１６）。
３．実在店舗での決済
図３６は、この発明の第２の実施の形態による実在店舗での決済を示す概略図である。図３６に示すように、実在店舖で決済する場合も決済機関８０が金融機関７０からの振替依頼を一括して実在店舗２６に対して支払を行なう。
図３７は、実在店舗での決済に設けられる携帯電話機１３、ＰＯＳ端末２７、携帯電話会社１０のサーバ３０、金融機関７０のサーバ７２、および決済機関８０のサーバ８２のハードウェア構成を示すブロック図である。
図３７に示すように、決済機関８０のサーバ８２におけるデータ処理部８０１はサーバ７２のデータ処理部７０１と通信し、決済情報８１０に従って実在店舗２６に対する支払を行なう。
図３８〜図４０は、実在店舗で決済する場合における携帯電話機１３、ＰＯＳ端末２７、携帯電話会社１０のサーバ３０、および金融機関７０のサーバ７２の動作を示すフローチャートである。
上記図２１に示した第１の実施の形態と異なり、この第２の実施の形態では図３８に示したステップＳ７０７において、携帯電話機１３のデータ処理部１３１はＲＡＭ１３２に記録されている仮想口座残高からステップＳ７０７で計算した累計未通知金額を減算する。
また、携帯電話会社１０のサーバ３０において、ステップＳ９０２でキーコードの一致を確認した場合、データ処理部３０１は未通知データを金融機関７０のサーバ７２に送信する（Ｓ９２０）。
金融機関７０のサーバ７２においては、データ処理部７０１が携帯電話会社１０から送信された未通知データを受信する（Ｓ１２００）。
続いて、データ処理部７０１は受信した未通知データに基づいて決済履歴データベース７１４を更新する（Ｓ１２０１）。
続いて、データ処理部７０１は仮想口座１１０の仮想口座残高を携帯電話会社１０のサーバ３０に送信する（Ｓ１２０２）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が金融機関７０から送信された仮想口座残高を受信し（Ｓ９２１）、引続きこれを利用者１２の携帯電話機１３に送信する（Ｓ１０５）。
携帯電話機１３においては、送受信部１３５が携帯電話会社１０から送信された仮想口座残高を受信し（Ｓ７１２）、さらにデータ処理部１３１はその受信した仮想口座残高に基づいてＲＡＭ１３２に記録されている仮想口座残高を更新しかつ未通知データをクリアする（Ｓ７１３）。
また、携帯電話会社１０のサーバ３０においては、ステップＳ９０６で実在店舗２６から送信された決済内容を受信した後、データ処理部３０１がその受信した決済内容を金融機関７０のサーバ７２に送信する（Ｓ９２２）。金融機関７０のサーバ７２においては、データ処理部７０１が携帯電話会社１０から送信された決済内容を受信する（Ｓ１２０３）。
続いて、データ処理部７０１はその受信した決済内容に基づいて決済履歴データベース７１４を更新する（Ｓ１２０４）。
続いて、データ処理部７０１は決済完了の情報を携帯電話会社１０のサーバ３０に送信する（Ｓ１２０５）。そして、金融機関７０は上記仮想店舗の場合と同様に決済機関８０を通じて実在店舗２６に対する支払処理を行なう（Ｓ１２０６）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が金融機関７０から送信された決済完了の情報を受信し（Ｓ９２３）、引続きこれを実在店舗２６のＰＯＳ端末２７に送信する（Ｓ９０７）。
また、携帯電話会社１０のサーバ３０においては、ステップＳ９０９でキーコードの一致を確認した場合、データ処理部３０１はステップＳ９０９で受信した未通知データを金融機関７０のサーバ７２に送信する（Ｓ９２４）。
金融機関７０のサーバ７２においては、データ処理部７０１が携帯電話会社１０から送信された未通知データを受信しする（Ｓ１２０７）。
続いて、データ処理部７０１はその受信した未通知データに基づいて決済履歴データベース７１４を更新する（Ｓ１２０８）
続いて、データ処理部７０１は仮想口座１１０の仮想口座残高を読出して携帯電話会社１０のサーバ３０に送信する（Ｓ１２０９）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が金融機関７０から送信された仮想口座残高を受信し（Ｓ９２５）、引続きこれを利用者１２の携帯電話機１３に送信する（Ｓ９１３）。
利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０から送信された仮想口座残高を受信し（Ｓ７３０）、さらにその受信した仮想口座残高に基づいてＲＡＭ１３２に記録されている仮想口座残高を更新しかつ未通知データをクリアする（Ｓ７２９）。
以上のようにこの発明の第２の実施の形態によれば、仮想口座１１０を金融機関７０に設けているため、仮想口座１１０への資金移動が上記第１の実施の形態に比べて簡単になる。
上記第２の実施の形態では金融機関７０に実在口座７１０とは別に仮想口座１１０を設けているが、実在口座７１０をそのまま仮想口座１１０として取扱うようにしてもよい。この場合、実在口座７１０から仮想口座１１０への資金移動が不要となるため、処理手続はさらに簡単になる。
上記実施の形態のインターネット上の仮想店舗での決済では利用者はパーソナルコンピュータを用いて注文をしているが、携帯電話機を用いて注文をする場合もある。この場合、携帯電話機がパーソナルコンピュータの代わりの機能を果たす。
［第３の実施の形態］
仮想口座を上記第１の実施の形態では携帯電話会社に設け、上記第２の実施の形態では金融機関に設けているが、以下に述べる第３の実施の形態では携帯電話会社や金融機関とは別個の決済機関に仮想口座を設ける。
１．サービスの概要
この第３の実施の形態によるサービスの利用を希望する利用者は、仮想口座に前払金を入金するために必要な銀行の口座番号や信販会社のクレジットカード番号などを決済機関に予め登録しておく。利用者は、決済の前に、仮想口座に前払金を入金するように、携帯電話機を用いて携帯電話会社を通じて決済機関に要請する。決済機関は、予め登録されている銀行の口座番号や信販会社のクレジットカード番号などを用い、利用者に対して前払金の請求を行なう。決済機関は、前払金の請求後、前払金を仮想口座に入金した上で仮想口座の残高を携帯電話会社を介して携帯電話機に送信する。仮想店舗や実在店舗は、上記第１および第２の実施の形態のように携帯電話会社や金融機関ではなく、決済機関に対して請求を行なう。
１−１．利用登録
図４１は、携帯電話機１３の利用者１２が本サービスの利用を希望する場合に最初に行なう利用登録の方法を示す概略図である。図４１に示すように、本サービスの利用を希望する利用者１２は、加入している携帯電話会社、携帯電話番号、および前払金を引落すための銀行の口座番号や信販会社のクレジットカード番号といった決済情報を所定の引落口座登録用紙２５に記入して決済機関９０に郵送する。決済機関９０は、引落口座登録用紙２５に基づいて利用者情報９１０をデータベースに登録する。
続いて、決済機関９０は、利用者１２に付与した会員番号（利用者情報９１０中の顧客番号）を携帯電話会社１０を通じて利用者１２に通知する。利用者１２はその通知内容を確認し、問題がなければ携帯電話会社１０を通じて決済機関９０に対して本サービスの申込を承認する。これに応じて決済機関９０は、仮想口座１１０を開設するとともに、仮想口座の入出金履歴９１２や決済履歴９１４を記録するための領域をデータベース内に開設する。
なお、決済機関９０のデータベースには、本サービスの利用が可能な加盟店（仮想店舗および実在店舗を含む）とその加盟店における利用金額を振込むための振込口座などの加盟店情報９１６が登録されている。
続いて、決済機関９０は、本サービスの開始を携帯電話会社１０を通じて利用者１２の携帯電話機１３に通知する。このとき、携帯電話会社１０は個人情報１１の利用状況を「未登録」から「利用可」に変更する。利用者１２の携帯電話機１３が携帯電話会社１０から本サービス開始の通知を受けると、携帯電話機１３の利用状況を「利用不可」から「利用可」に変更する。
上記手続により、利用者１２は本サービスの利用が可能となる。
１−２．仮想口座への資金移動
図４２は、決済機関９０に設けた仮想口座１１０に入金する前払金を金融機関の口座から引落しする場合の資金移動を示す概略図である。図４２に示すように、利用者１２は携帯電話機１３を用い、携帯電話会社１０を通じて決済機関９０に対して所望の前払金を仮想口座１１０に入金するよう要請する。ここでは仮想口座１１０に５０００円を入金する場合を例示している。決済機関９０は仮想口座１１０への前払の要請を受けると、利用者情報９１０に基づき、利用者１２の口座１６０が開設されている銀行や信販会社のような金融機関１７０に対して前払金の引落しを依頼する。引落し依頼を受けた金融機関１７０は引落しが可能か否かを確認し、可能な場合は振替データを決済機関９０に送り、前払金を決済機関９０に支払う。引落しが不可能な場合はその旨決済機関９０に通知する。決済機関９０は金融機関１７０から振替データを受けると、入出金履歴９１２を更新し、さらに仮想口座１１０を更新する。続いて、決済機関９０はその更新した仮想口座１１０の残高を携帯電話会社１０に通知する。携帯電話会社１０では、携帯電話番号や仮想口座残高などの送信データ１０２が作成される。携帯電話会社１０はこの送信データ１０２に基づいて利用者１２に仮想口座残高を通知する。この通知に応じて利用者１２の携帯電話機１３は仮想口座残高を更新する。携帯電話会社１０から利用者１２の携帯電話機１３への送信データ１０２の送信が完了すると、送信データ１０２はクリアされる。利用者１２が電波圏外にいる場合など、送信データ１０２の送信が不可能な場合、送信データ１０２はクリアされずにそのまま保持される。
１−３．仮想店舗での決済
図４３は、携帯電話機１３を用いてインターネット上の仮想店舗２４で決済する方法を示す概略図である。図４３に示すように、利用者１２は携帯電話機１３またはパーソナルコンピュータ４０を用いて仮想店舗２４に対して注文を出す。注文を受けた仮想店舗２４は、利用者１２の顧客番号や請求内容などを記載した電子請求書を決済機関９０および携帯電話会社１０を通じて利用者１２の携帯電話機１３に送信する。利用者１２はその送信された電子請求書を携帯電話機１３で確認し、その請求内容が自らの注文内容と一致する場合は決済の承認を携帯電話会社１０を通じて決済機関９０に通知する。決済機関９０は決済の承認を得ると、その請求内容に応じて入出金履歴９１２および決済履歴９１４を更新するとともに、仮想口座１１０の残高も更新する。ここではＢ店という仮想店舗２４で３０００円の商品を購入した場合を例示している。
続いて、決済機関９０はその更新した仮想口座残高を携帯電話会社１０に通知する。携帯電話会社１０はその仮想口座残高を送信データ１０２とし、さらに利用者１２の携帯電話機１３に送信する。これに応じて携帯電話機１３の仮想口座残高が更新される。携帯電話会社１０から利用者１２への仮想口座残高の送信が完了すると、送信データ１０２はクリアされる。
一方、決済機関９０は仮想口座残高の更新を終えると、決済の完了を仮想店舗２４を通じて利用者１２に通知する。また、決済機関９０は加盟店情報９１６に基づいてその決済金額を加盟店の振込口座に入金する。
１−４．実在店舗での決済
図４４は、携帯電話機１３を用いて実在店舗２６で決済する方法を示す概略図である。図４４に示すように、実在店舗２６に設置されているＰＯＳ端末２７に携帯電話機１３が装着されると、ＰＯＳ端末２７は決済金額を携帯電話機１３に送信する。決済金額が仮想口座残高以内の場合、携帯電話機１３は決済内容を未通知データに記録するとともに、携帯雷話番号、キーコードおよびパスワードをＰＯＳ端末２７に送信する。これに応じて、ＰＯＳ端末２７は決済の完了を携帯電話機１３に通知する。
その後、ＰＯＳ端末２７は、携帯電話番号、キーコードおよびパスワードとともに決済内容を決済機関９０に通知する。決済機関９０は、受信した携帯電話番号、キーコードおよびパスワードを携帯電話会社１０に送信することにより認証を依頼する。認証依頼を受けた携帯電話会社１０は、個人情報１１の未通知を「無」から「有」に変更する。受信した携帯電話番号、キーコードおよびパスワードが個人情報１１として登録されている携帯電話番号、キーコードおよびパスワードと一致しない場合、携帯電話会社１０は個人情報１１の利用状況を「認証異常」に変更し、その旨を利用者１２および決済機関９０に通知する。この通知に応じて、携帯電話機１３は利用状況を「認証異常」に変更する。
一方、受信した携帯電話番号、キーコードおよびパスワードが個人情報１１として登録されている携帯電話番号、キーコードおよびパスワードと一致した場合、携帯電話会社１０は認証が正常に完了した旨を決済機関９０に通知する。この通知に応じて、決済機関９０は入出金履歴９１２および決済履歴９１４を更新する。決済機関９０はさらに、仮想口座１１０の残高を更新するとともに、未通知を「無」から「有」に変更する。ここでは、Ｄ店という実在店舗２６で１０００円の商品を購入した場合を例示している。
続いて、決済機関９０は決済が完了した旨を実在店舗２６に通知する。また、決済機関９０は加盟店情報９１６に基づいて加盟店の振込口座にその決済金額を入金する。
１−５．未通知データの要求
図４５は、利用者１２が実在店舗２６で決済をしたために携帯電話機１３内に未通知データが発生して携帯電話機１３の仮想口座残高が決済機関９０の仮想口座残高と一致しなくなった場合に決済機関９０が仮想口座残高の同期をとるために携帯電話機１３に対して未通知データの送信を要求する方法を示す概略図である。図４５に示すように、決済機関９０は携帯電話会社１０を通じて利用者１２の携帯電話機１３に未通知データを要求する。これに応じて、携帯電話機１３は携帯電話会社１０を通じて未通知データを決済機関９０に送信する。決済機関９０は、受信した未通知データに基づいて決済履歴９１４のうち該当の決済の状態を「未通知」から「通知済」に変更する。
続いて、決済機関９０は仮想口座１１０の残高を携帯電話会社１０に送信する。携帯電話会社１０は受信した仮想口座残高を送信データ１０２とするとともに、個人情報１１中の未通知を「有」から「無」に変更する。携帯電話会社１０は仮想口座残高を携帯電話機１３に送信する。これに応じて、携帯電話機１３は仮想口座残高を更新するとともに、未通知データをクリアする。携帯電話会社１０は仮想口座残高の送信を完了すると、送信データ１０２をクリアする。
１−６．請求代行
図４６は、仮想店舗２４に代わって決済機関９０が利用者１２による仮想店舗２４での決済金額を信販会社２０に請求する方法を示す概略図である。この請求代行は、決済機関９０に設けた仮想口座１１０を利用するものではなく、利用者情報９１０として登録されている銀行の口座番号や信販会社のクレジットカード番号を利用してデビット決済やカード決済を行なうものである。
図４６に示すように、利用者１２が携帯電話機１３またはパーソナルコンピュータ４０を用いて仮想店舗２４に対して注文をすると、仮想店舗２４は顧客番号や請求内容などからなる電子請求書を決済機関９０および携帯電話会社１０を通じて利用者１２に発行する。利用者１２は携帯電話機１３に送信された電子請求書を確認し、決済を承認する場合はその旨を携帯電話会社１０を通じて決済機関９０に通知する。その際に、予め登録している決済方法の中から１つを選択する。ここでは、信販会社Ｅ社のクレジットカードによる決済を選択した場合を例示している。
決済機関９０は決済の承認を仮想店舗２４に通知するとともに、利用者情報９１０を用いてクレジットカード番号や決済金額などの決済内容を信販会社２０に通知する。これに応じて信販会社２０は仮想店舗２４に対して決済金額の支払処理を行ない、決済が完了した旨を仮想店舗２４に通知する。
利用者１２が決済方法としてデビットカードによる決済を選択した場合、決済機関９０は利用者情報９１０を用いて口座番号や決済金額などの決済内容を銀行１７に通知する。銀行１７はその決済金額を利用者１２の口座から引落し、さらに仮想店舗２４に対してその決済金額の支払処理を行なう。
上記請求代行サービスでは、銀行の口座番号や信販会社のクレジットカード番号といった重要な決済情報は予め決済機関９０に登録されており、携帯電話機１３やパーソナルコンピュータ４０から送信されることはない。認証は携帯電話番号、キーコードおよびパスワードを用いて携帯電話会社１０で行なわれ、認証が得られた場合だけ予め登録されている口座番号やクレジットカード番号が決済機関９０から金融機関１７０や信販会社２０に通知される。したがって、高い安全性を確保することができる。
２．システム構成およびその動作
次に、上記サービスを実現するためのシステム構成およびその動作について説明する。
２−１．利用登録
図４７は、図４１に示した利用登録のためのハードウェア構成を示すブロック図である。上記第１および第２の実施の形態と異なり、この第３の実施の形態では、携帯電話会社１０のサーバ３０には、送信データ１０２を記憶するためのメモリ３０３が設けられる。また、決済機関９０のサーバ９２には、データ処理部９２１と、データベース９２２とが設けられる。データベース９２２には、利用者情報９１０、仮想口座の入出金履歴９１２、仮想口座の決済履歴９１４および加盟店情報９１６が蓄積される。データ処理部９２１は、携帯電話会社１０に設置されているサーバ３０のデータ処理部３０１と接続され、データベース９２２に対して所定のデータ処理を行なう。
図４８は、利用登録を行なう場合における利用者１２の携帯電話機１３、携帯電話会社１０のサーバ３０および決済機関９０のサーバ９２の動作を示すフローチャートである。
まず、利用者１２は携帯電話機１３の入力装置１３６を操作して本サービスの利用申込を携帯電話機１３から携帯電話会社１０に送信する（Ｓ１１）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された利用申込を受信し（Ｓ２１）、これを決済機関９０に送信する（Ｓ２２）。決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話会社１０から送信された利用申込を受信する（Ｓ１３０１）。これに応じて、決済会社９２は所定の申込用紙を利用者１２に発送する（Ｓ１３０２）。利用者１２は申込用紙に引落しを希望する銀行の口座番号や信販会社のクレジットカード番号などを記入した後、決済機関９０に返送する。決済機関９０は利用者１２から返送された申込用紙を受取る（Ｓ１３０２）。この申込用紙に記入された事項に基づいて、データ処理部３０１は利用者情報９１０をデータベース９２２に登録する（Ｓ１３０３）。具体的には、利用者１２の会員番号、携帯電話番号、携帯電話会社、銀行の口座番号、信販会社のクレジットカード番号などを登録する。続いて、データ処理部９２１は会員番号を携帯電話会社１０に通知する（Ｓ１３０４）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０から送信された会員番号を受信し（Ｓ２３）、これを利用者１２に通知する（Ｓ２４）。利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０から送信された会員番号を受信し（Ｓ１２）、利用者１２がその申込を承認した場合はその旨を携帯電話会社１０に通知する（Ｓ１３）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された申込承認の通知を受信し（Ｓ２５）、これを決済機関９０に通知する（Ｓ２６）。
決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話会社１０から送信された申込承認の通知を受信し（Ｓ１３０５）、仮想口座１１０を開設し（Ｓ１３０６）、本サービスの開始を携帯電話会社１０に通知する（Ｓ１３０７）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０から送信されたサービス開始の通知を受信し（Ｓ２７）、個人情報１１の利用状況を「未登録」から「利用可」に更新する（Ｓ２８）。続いて、データ処理部３０１は本サービスの開始を利用者１２に通知する（Ｓ２９）。利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０から送信されたサービス開始の通知を受信し（Ｓ１４）、利用状況を「利用不可」から「利用可」に更新する（Ｓ１５）。
２−２．仮想口座への資金移動
図４９は、図４２に示した資金移動に用いられる利用者１２の携帯電話機１３、携帯電話会社１０のサーバ３０、決済機関９０のサーバ９２、金融機関１７０のサーバ１７２のハードウェア構成を示すブロック図である。図４９に示すように、金融機関１７０に設置されるサーバ１７２は、データ処理部１７４と、データベース１７６とを備える。データ処理部１７４はデータベース１７６のデータを処理するとともに、携帯電話会社１０に設置されているサーバ３０のデータ処理部３０１に接続される。データベース１７６には、利用者の住所や氏名などの利用者情報１７７と、金融機関１７０に開設されている実在口座に関する実在口座情報１７８と、実在口座における入出金などの実在口座履歴１７９とが登録される。
図５０〜図５２は、図４２に示したように金融機関１７０から決済機関９０の仮想口座１１０に資金を移動する場合における携帯電話機１３、携帯電話会社１０のサーバ３０および決済機関９０のサーバ９２の動作を示すフローチャートである。
ここでは、パスワードの入力（Ｓ１０１）前に、携帯電話機１３が利用状況を確認し、利用不可の場合はその旨を表示装置１３７に表示する（Ｓ１００）。利用可の場合は利用者１２に対してパスワードの入力を促す（Ｓ１０１）。また、パスワードの検証（Ｓ１０２）後、前払金額の入力（Ｓ１０４）前に、図２１と同様に未通知データを確認して利用可能残高を表示する（Ｓ７１４）。
続いて、携帯電話機１３の送受信部１３５はステップＳ１０４で入力された前払金額などを携帯電話会社１０に送信するが（Ｓ１０６）、ここではステップＳ１０１で入力されたパスワードも携帯電話会社１０に送信する。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が受信した携帯電話番号に基づいて個人情報１１を検索した後（Ｓ２０２）、受信したキーコードおよびパスワードを検証する（Ｓ２０３）。キーコードまたはパスワードが一致しない場合、個人情報１１の利用状況を「利用可」から「利用不可」に変更し（Ｓ２５０）、認証の異常を利用者１２に通知する（Ｓ２５１）。
利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０から認証異常の通知を受信し（Ｓ１５０）、これに応じてデータ処理部１３１は携帯電話機１３の利用状況を「利用可」から「認証異常」に変更し（Ｓ１５１）、本サービスの利用停止を表示装置１３７に表示する（Ｓ１５２）。
一方、ステップＳ２０３でキーコードおよびパスワードの両方が一致した場合、データ処理部３０１は個人情報１１の利用状況を確認し（Ｓ２０４）、利用状況が「利用可」の場合は未通知データがあるか否かを判定する（Ｓ２５３）。未通知データがある場合、データ処理部３０１はステップＳ２０１で受信した前払金額とともに未通知データを決済機関９０に送信する（Ｓ２５４）。一方、未通知データがない場合、データ処理部３０１は前払金額のみを決済機関９０に送信する（Ｓ２５５）。このように携帯電話会社１０から決済機関９０に前払金額を送信する際には、利用者１２の携帯電話番号も送信する。
決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話会社１０から送信された携帯電話番号や前払金額などを受信し（Ｓ１３００）、その受信した情報およびデータベース９２２に登録されている利用者情報９１０に基づいて利用者１２が口座を開設している金融機関１７０に対する請求データを作成する（Ｓ１３０１）。決済機関９０はその請求データに従って金融機関１７０に前払金額の引落しを依頼する（Ｓ１３０２）。
金融機関１７０は、決済機関９０からの引落し依頼に応じて利用者１２の口座１６０から前払金額を引落す（Ｓ１４００）。続いて、データ処理部１７４は引落しが可能か否か、すなわち前払金額が口座残高以内か否かを判定する（Ｓ１４０１）。引落しが不可能な場合、データ処理部１７４は決済機関９０にその旨を通知する（Ｓ１４０２）。決済機関９０のサーバ９２においては、データ処理部９２１が金融機関１７０から引落し不可の通知を受信し（Ｓ１３０３）、これを利用者１２の携帯電話番号とともに携帯電話会社１０に通知する（Ｓ１３０４）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０から引落し不可の通知を受信し（Ｓ２５６）、これを利用者１２の携帯電話機１３に通知する（Ｓ２３２）。
一方、ステップＳ１４０１において引落しが可能な場合、サーバ１７２のデータ処理部１７４は振替データを決済機関９０に送信し（Ｓ１４０３）、利用者１２の口座１６０から決済機関９０の口座に前払金額を振替える支払処理を実行する（Ｓ１４０４）。
決済機関９０のサーバ９２においては、データ処理部９２１が金融機関１７０から送信された振替データを受信し（Ｓ１３０５）、続いて前払金額の入金をデータベース９２２に記録することにより入出金履歴９１２を更新する（Ｓ１３０６）。未通知データが送信されて来ている場合は、ここで決済金額をデータベース９２２に記録することにより決済履歴９１４を更新する（Ｓ１３０７）。続いて、データ処理部９２１は仮想口座１１０の残高に前払金額を加算することにより仮想口座残高を更新する（Ｓ１３０８）。未通知データがあった場合はこれを「無」に変更する。続いて、データ処理部９２１は仮想口座１１０の残高を携帯電話番号とともに携帯電話会社１０に送信する（Ｓ１３０９）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０から送信された仮想口座残高を受信し（Ｓ２５７）、その仮想口座残高を送信データ１０２としてメモリ３０３に記憶する（Ｓ２５８）。続いて、データ処理部３０１は未通知データを「無」に変更する（Ｓ２５９）。続いて、データ処理部３０１は、メモリ３０３に記憶された送信データ１０２を利用者１２の携帯電話機１３に送信する（Ｓ２６０）。続いて、上記送信が正常に終了したか否かを判定し（Ｓ２６１）、正常に終了した場合は送信データ１０２をクリアし（Ｓ２６２）、利用者１２が電波圏外にいたり携帯電話機１３の電源を切っていた場合など、送信データを携帯電話機１３に送信できず、送信が正常に終了しなかった場合は再送信処理を行なう（Ｓ２６３）。具体的には、所定期間経過後に送信データ１０２を再び携帯電話機１３に送信する。
２−３．仮想店舗での決済
図５３は、図４３に示した仮想店舗２４での決済に用いられるパーソナルコンピュータ４０、携帯電話機１３、携帯電話会社１０のサーバ３０、決済機関９０のサーバ９２および仮想店舗２４のサーバ５０のハードウェア構成を示すブロック図である。図５３に示すように、決済機関９０に設置されたサーバ９２のデータ処理部９２１はインターネット６０に接続される。
図５４〜図５６は、図４３に示したように仮想店舗２４で決済する場合におけるパーソナルコンピュータ４０、携帯電話機１３、携帯電話会社１０のサーバ３０、決済機関９０のサーバ９２、および仮想店舗２４のサーバ５０の動作を示すフローチャートである。
ここでは、利用者１２のパーソナルコンピュータ４０または携帯電話機１３は注文内容とともに会員番号（顧客番号）を仮想店舗２４に送信する（Ｓ３０１）。仮想店舗２４のサーバはこれらを受信し（Ｓ６０１）、電子請求書を作成して会員番号とともに請求内容をインターネット６０を介して決済機関９０に送信する（Ｓ６０２）。
決済機関９０のサーバ９２においては、データ処理部９２１が仮想店舗２４から送信された電子請求書を受信し（Ｓ１３１０）、その受信した会員番号に基づいてデータベース９２２を検索して利用者情報９１０の中から利用者１２の携帯電話番号および携帯電話会社を特定する（Ｓ１３１１）。続いて、データ処理部９２１は受信した電子請求書を該当の携帯電話会社１０に携帯電話番号とともに送信する（Ｓ１３１２）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０から送信された電子請求書を携帯電話番号とともに受信する（Ｓ５０１）。データ処理部３０１は個人情報１１中の利用状況を確認し（Ｓ５０３）、利用状況が「利用不可」の場合はその旨を携帯電話番号とともに決済機関９０に通知する（Ｓ５０４）。
決済機関９０のサーバ９２においては、携帯電話会社１０から携帯電話番号とともに通知されたサービス利用不可の通知を受信し（Ｓ１３１３）、これをインターネット６０を介して仮想店舖２４に通知する（Ｓ１３１４）。
また、利用者１２は、携帯電話会社１０から送信され、携帯電話機１３で受信した電子請求書を開封し（Ｓ４１８）、携帯電話機１３のデータ処理部１３１は受信した電子請求書の請求内容および利用可能な仮想口座残高を表示装置１３７に表示する（Ｓ１５４）。
また、電子請求書の請求金額が利用可能残高を超えている場合、データ処理部１３１は表示装置１３７を通じて利用者１２に対して仮想口座１１０への追加振替を行なうか否かを問合せる（Ｓ１５５）。追加振替を行なう場合、データ処理部１３１は資金振替の処理を実行する（Ｓ１５６）。
また、決済を承認するか否かの判定（Ｓ４０２）は、利用可能残高の検証（Ｓ４０８）後に行なう。携帯電話会社１０のサーバ３０においては、データ処理部３０１が受信した決済の取消または拒否を携帯電話番号とともに決済機関９０に送信する（Ｓ５０７）。決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話会社１０から送信された決済の取消または拒否を受信し（Ｓ１３１５）、これをインターネット６０を介して仮想店舗２４に送信する（Ｓ１３１６）。決済の取消または拒否は上記実施の形態と同様に仮想店舗２４を介して利用者１２に返信される（Ｓ６０５，Ｓ６０６，Ｓ３０４）。利用者１２のパーソナルコンピュータ４０または携帯電話機１３においては、データ処理部４０１または１３１がその受信した決済の取消または拒否（受注取消）を表示装置４０６または１３７に表示する（Ｓ３０８）。
また、利用者１２の携帯電話機１３においては、パスワードの入力（Ｓ４１１）後に、データ処理部１３１がその入力されたパスワードの検証を行なう（Ｓ１５７）。パスワードが誤っている場合はデータ処理部１３１はその旨を表示装置１３７に表示し（Ｓ１５８）、パスワードが正しい場合は送受信部１３５は決済の承認を携帯電話会社１０に通知する（Ｓ４１２）。
また、携帯電話会社１０のサーバ３０においては、キーコードまたはパスワードが不一致の場合、データ処理部３０１は個人情報１１の利用状況を「利用可」から「認証異常」に変更し（Ｓ５２２）、その旨を利用者１２に通知し（Ｓ５２３）、さらに決済機関９０にも携帯電話番号とともに通知する（Ｓ５２４）。利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０から送信された認証異常の通知を受信し（Ｓ１５９）、データ処理部１３１は利用状況を「利用可」から「認証異常」に変更し、さらに本サービスの利用停止を表示装置１３７に表示する（Ｓ１６１）。一方、決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話会社１０から送信された認証異常の通知を受信し（Ｓ１３１７）、認証異常を理由に決済が不可能である旨をインターネット６０を介して仮想店舗２４に通知する（Ｓ１３１８）。仮想店舗２４のサーバ５０においては、モデム５０４が決済機関９０から送信された決済不可の通知を受信し（Ｓ６１３）、これに応じて受注の取消をインターネット６０を介して利用者１２のパーソナルコンピュータ４０または携帯電話機１３に送信する（Ｓ６１４）。利用者１２のパーソナルコンピュータ４０または携帯電話機１３においては、モデム４０４または送受信部１３５が仮想店舗２４から送信された受注の取消を受信し（Ｓ３０９）、データ処理部４０１または１３１がその旨を表示装置４０６または１３７に表示する（Ｓ３１０）。
ステップＳ５１１，Ｓ５１２においてキーコードおよびパスワードがともに一致した場合、データ処理部３０１は未通知が「有」か否かを判定し（Ｓ５２５）、未通知データがある場合は決済データおよび未通知データを携帯電話番号とともに決済機関９０に送信する（Ｓ５２６）。未通知データがない場合はデータ処理部３０１は決済データを携帯電話番号とともに決済機関９０に送信する（Ｓ５２７）。決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話会社１０から送信された決済データ（および未通知データがある場合は未通知データ）を受信し（Ｓ１３１９）、その受信した決済データ（および未通知データがある場合は未通知データ）に基づいて入出金履歴９１２を更新し（Ｓ１３２０）、決済履歴９１４を更新し（Ｓ１３２１）、さらに仮想口座１１０の残高を更新する（Ｓ１３２２）。ここで、データ処理部９２１は仮想口座１１０の未通知を「無」にする。
続いて、データ処理部９２１は更新した仮想口座１１０の残高を携帯電話番号とともに携帯電話会社１０に送信し（Ｓ１３２３）、決済の完了をインターネット６０を介して仮想店舗２４に通知し（Ｓ１３２４）、さらに仮想店舗２４への支払処理を行なう（Ｓ１３２５）。決済完了の通知は仮想店舗２４を介して利用者１２にも通知される（Ｓ６１２，Ｓ３０７）。利用者１２のパーソナルコンピュータ４０または携帯電話機１３においては、データ処理部４０１または１３１がその受信した決済の完了を表示装置４０６または１３７に表示する（Ｓ３１１）。
一方、携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０から送信された仮想口座残高を受信し（Ｓ５２８）、その残高を送信データ１０２としてメモリ３０３に記憶する（Ｓ５２９）。続いて、データ処理部３０１は個人情報１１の未通知を「無」にし（Ｓ５３０）、メモリ３０３に記憶された送信データ（仮想口座残高）１０２を利用者１２の携帯電話機１３に送信する（Ｓ５３１）。
続いて、データ処理部３０１は上記データの送信が正常に終了したか否かを判定し（Ｓ５３２）、正常に終了した場合はメモリ３０３に記憶された送信データ１０２をクリアし（Ｓ５３３）、正常に終了しなかった場合は再び送信処理を行なう（Ｓ５３４）。
利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０から送信された送信データ１０２を受信し（Ｓ１６２）、データ処理部１３１がその受信した送信データ１０２に基づいて仮想口座残高を更新する（Ｓ１６３）。続いて、データ処理部１３１は未通知データをクリアし（Ｓ１６４）、仮想口座残高とともに決済の完了を表示装置１３７に表示する（Ｓ１６５）。
２−４．実在店舗での決済
図５７は、図４４に示した実在店舗での決済に用いられる携帯電話機１３、ＰＯＳ端末２７、携帯電話会社１０のサーバ３０および決済機関９０のサーバ９２のハードウェア構成を示すブロック図である。ここでは図２０と異なり、決済機関９０のサーバ９２が実在店舗２６のＰＯＳ端末２７および携帯電話会社１０のサーバ３０に接続される。
図５８〜図６０は、図５７に示した携帯電話機１３、ＰＯＳ端末２７、携帯電話会社１０のサーバ３０および決済機関９０のサーバ９２の動作を示すフローチャートである。
ここでは、携帯電話会社１０のサーバ３０において、ステップＳ５２５の判定の結果、未通知データがある場合、データ処理部３０１はその未通知データを携帯電話番号とともに決済機関９０に送信する（Ｓ５３５）。決済機関９０のサーバ９２においては、未通知データがある場合、データ処理部９２１は入出金履歴９１２を更新する（Ｓ１３３０）。続いて、データ処理部９２１は決済履歴９１４を更新し、該当する決済の状態を「通知済」とする（Ｓ１３３１）。続いて、データ処理部９２１は未通知データがある場合に仮想口座１１０の残高を更新し、未通知を「無」にする（Ｓ１３３２）。
また、ここでは図２２と異なり、利用者１２の携帯電話機１３において、残高の検証（Ｓ７１８）後に、データ処理部１３１は未通知データに決済内容を記憶し（Ｓ７２２）、その後、携帯電話番号、キーコード、パスワードといった携帯電話機１３の端末情報をＰＯＳ端末２７に送信する（Ｓ７２０）。ステップＳ８０２〜Ｓ８０４，Ｓ７２１は図２２と同じである。ステップＳ７２１でＰＯＳ端末２７から決済完了の通知を受信した後、データ処理部１３１は決済モードをオフにし（Ｓ７２３）、決済の終了を表示装置１３７に表示する（Ｓ７３１）。
また、ＰＯＳ端末２７のデータ処理部２７１はステップＳ８０２で受信した携帯電話番号、キーコードおよびパスワードとともに、ステップＳ８０３で記録した決済内容を決済機関９０に送信する（Ｓ８０５）。決済機関９０のサーバ９２においては、データ処理部９２１がＰＯＳ端末２７から携帯電話番号などとともに送信された決済内容を受信し（Ｓ１３３３）、その受信した携帯電話番号に基づいてデータベース９２２に記憶された利用者情報９１０を検索する（Ｓ１３３４）。この検索結果に従って、データ処理部９２１は該当の携帯電話会社１０に認証を依頼するためにステップＳ１３３３で受信した携帯電話番号、キーコードおよびパスワードを携帯電話会社１０に送信する（Ｓ１３３５）。
携帯電話会社１０のサーバ３０においては、図５５と同様にデータ処理部３０１が認証を行なう（Ｓ５１１，Ｓ５１２）。ただしここでは、キーコードまたはパスワードが不一致の場合、データ処理部３０１は個人情報１の利用状況を「利用不可」に変更し（Ｓ５２２）、本サービスの利用停止を利用者１２に通知する（Ｓ５２３）。利用者１２の携帯電話機１３においては、データ処理部１３１は利用状況を「利用不可」に変更する（Ｓ１６０）。
一方、キーコードおよびパスワードが一致した場合、データ処理部３０１は個人情報１１の未通知を「有」に変更し（Ｓ９２５）、認証の成功を決済機関９０に通知し、さらに後述する未通知データの要求処理を行なう（Ｓ９２７）。
決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話会社１０から送信された認証成功の通知を受信し（Ｓ１３３０）、入出金履歴９１２、決済履歴９１４および仮想口座１１０の残高をそれぞれ更新する（Ｓ１３２０〜Ｓ１３２２）。ここでは、決済履歴９１４を更新したときその状態を「未通知」とする。続いて、データ処理部９２１は仮想口座１１０の未通知を「有」に変更する（Ｓ１３３１）。
また、データ処理部９２１が携帯電話会社１０から認証異常の通知を受信した場合も（Ｓ１３１７）、データ処理部９２１は実在店舗２６に対する決済金額の支払処理を行なう（Ｓ１３３２）。このような認証異常が起こる原因として利用者１２の不正が考えられるが、この場合も決済機関９０は実在店舗２６に対して支払を保証することになる。決済機関９０は不正使用による損害を負担することになるが、上記のように認証異常を検出した時点で本サービスの利用を停止しているので損害を最小限に抑えることができる。
２−５．未通知データの要求
図６１は、携帯電話会社１０が利用者１２に対して未通知データを要求する場合における携帯電話機１３、携帯電話会社１０のサーバ３０および決済機関９０のサーバ９２の動作を示すフローチャートである。なお、未通知データは図２４に示した第１の実施の形態と同様に携帯電話機１３のＲＡＭ１３２に記憶されている。また、未通知データの要求の際には図４７に示したハードウェア構成が用いられる。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が予め定められた時間間隔おきに利用者１２の携帯電話機１３に対して未通知データの送信を要求する（Ｓ５４０）。利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０から送信された未通知データの送信要求を受信し（Ｓ１７０）、これに応じてデータ処理部１３１がＲＡＭ１３２に記憶されている未通知データを携帯電話番号、キーコードおよびパスワードとともに携帯電話会社１０に送信する（Ｓ７０６）。以下、図５８および図５９と同様に携帯電話会社１０のサーバ３０は認証などを行ない、決済機関９０のサーバ９２は決済履歴９１４の更新などを行なう。
２−６．請求代行
図６２は、図４６に示した請求代行に用いられるパーソナルコンピュータ４０、携帯電話機１３、携帯電話会社１０のサーバ３０、仮想店舗２４のサーバ５０、決済機関９０のサーバ９２、金融機関１７０のサーバ９４のハードウェア構成を示すブロック図である。図６２に示すように、金融機関のサーバ９４は、データ処理部９４１と、データベース９４２とを備える。データ処理部９４１は、インターネット６０と、決済機関９０に設置されているサーバ９２のデータ処理部９２１とに接続される。データベース９４２には、利用者情報９４３、加盟店情報９４４および利用者履歴９４５が蓄積される。利用者情報９４３は、利用者の住所、氏名、電話番号などの他、銀行の場合は口座番号、信販会社の場合はクレジットカード番号および引落銀行口座などである。加盟店情報９４４は、デビットカードやクレジットカードによる決済を受付ける加盟店の住所、名称などである。利用者履歴９４５は、デビットカードやクレジットカードによる決済金額、決済日、利用加盟店の名称などである。
図６３および図６４は、図６２に示したパーソナルコンピュータ４０、携帯電話機１３、携帯電話会社１０のサーバ３０、決済機関９０のサーバ９２、金融機関のサーバ９４および仮想店舗２４のサーバ５０の動作を示すフローチャートである。
図６３および図６４に示した請求代行の処理は、図５４〜図５６に示した仮想店舗での決済の処理に類似している。ただし、請求代行の際には利用者１２の携帯電話機１３において、ステップＳ４１８で電子請求書を開封した後直ちに、決済の承認を行なう（Ｓ４０２）。また、ステップＳ１５７でパスワードが一致した場合に、デビットカードによる決済かクレジットカードによる決済かという決済方法の選択を利用者１２に対して促す（Ｓ１７１）。続いて、携帯電話機１３の送受信部１３５は、決済の承認を携帯電話会社１０に通知する（Ｓ４１２）。このとき、携帯電話番号、キーコード、パスワード、決済内容の他、決済方法も合わせて携帯電話会社１０に送信する。
また、携帯電話会社１０のサーバ３０においては、ステップＳ５１１，Ｓ５１２でキーコードおよびパスワードが一致した場合に、データ処理部３０１はステップＳ５１０で受信した決済の承認を携帯電話番号とともに決済機関９０に送信する。決済機関９０のサーバ９２においては、データ処理部９２１がこの決済の承認をインターネット６０を介して仮想店舗２４に通知し（Ｓ１３３５）、仮想店舗２４のサーバ５０においてはモデム５０４がこの通知を受信する（Ｓ６１５）。
続いて、データ処理部９２１は金融機関に決済内容を通知する（Ｓ１３３６）。金融機関のサーバ９４においては、データ処理部９４１が決済機関９０から送信された決済内容を受信し（Ｓ１５００）、所定の決済処理を行なう（Ｓ１５０１）。続いて、データ処理部９４１は決済の可否を仮想店舗２４に通知する（Ｓ１５０２）。仮想店舗２４のサーバ５０においては、モデム５０４が金融機関から送信された決済可否の通知を受信し（Ｓ６１６）、決済が可能か否かを判定し（Ｓ６１７）、決済が不可能な場合は受注の取消を利用者１２のパーソナルコンピュータ４０または携帯電話機１３に送信する（Ｓ６１８）。利用者１２のパーソナルコンピュータ４０または携帯電話機１３においては、モデム４０４または送受信部１３５が仮想店舗２４から送信された受注取消を受信し（Ｓ３１５）、その旨を表示装置４０６または１３７に表示する（Ｓ３１６）。
上記第３の実施の形態は仮想口座１１０を決済機関９０に設けている点で上記第１および第２の実施の形態と大きく相違するが、その他の点でも相違している。これらの相違点は上記第１および第２の実施の形態でも採用することは可能である。
［第４の実施の形態］
上記第３の実施の形態では携帯電話会社１０に設けた個人情報１１に基づいて利用者１２の認証を行なっているが、以下に述べる第４の実施の形態では決済機関９０に設けた利用者情報９１０に基づいて利用者１２の認証を行なう。この第４の実施の形態のためのハードウェア構成は、図４７、図４９、図５３、図５７および図６２に示したものと同じであるから、その説明は繰返さない。以下、第４の実施の形態を上記第３の実施の形態との相違点を中心に説明する。
１．前払い方法
まず、仮想口座に入金する前払い方法について説明する。図６５は、この発明の第４の実施の形態に従う前払い方法を示す概略図である。ここでは、携帯電話機１３のＲＡＭ１３２内に、後述するワンタイムＩＤ、小口口座残高および小口決済履歴を記憶するための領域が確保されている。また、決済機関９０の利用者情報９１０には、利用者１２を認証するためのキーコードおよびパスワードが含まれている。利用者情報９１０にはまた、携帯電話機１３のメールアドレス、利用状況および会員区分が含まれている。会員区分には個人利用者の「一般」と「加盟店」とがある。仮想口座１１０には、小口口座残高およびワンタイムＩＤが含まれている。図６６および図６７は、図６５に示した場合における、携帯電話機、携帯電話会社のサーバ、および決済機関のサーバの動作を示すフローチャートである。
まず、利用者１２は携帯電話機１３を用い、メニュー画面で「前払い」を選択する（Ｓ９８）。具体的には、図４７、図４９、図５３、図５７および図６２に示した携帯電話機１３において、利用者１２の操作に応じて入力装置１３６が「前払い」の選択信号をデータ処理部１３１に与える。以降、ステップＳ９９〜Ｓ１０３は図５０に示したものと同じであるから、その説明は繰返さない。
パスワードの検証（Ｓ１０２）後、利用者１２は携帯電話機１３を用い、予め付与されている顧客番号を入力する（Ｓ１７５）。具体的には、利用者１２の操作に応じて入力装置１３６が入力された顧客番号をデータ処理部１３１に与える。ここでは利用者１２が顧客番号を入力しているが、最初に入力された顧客番号をＲＡＭ１３２に記憶しておき、２回目以降はこの記憶された顧客番号を送信するようにしてもよい。また、上記実施の形態のように携帯電話機１３の電話番号を顧客番号として用いてもよい。
続いて、携帯電話機１３の送受信部１３５がステップＳ１７５で入力された顧客番号、ＲＯＭ１３３に予め登録されているキーコード、およびステップＳ１０１で入力されたパスワードを携帯電話会社１０に送信する（Ｓ１７６）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された顧客番号、キーコードおよびパスワードを受信し、これらをそのままインターネット６０を介して決済機関９０に送信する。すなわち、携帯電話会社１０は携帯電話機１３から送信された顧客番号、キーコードおよびパスワードを決済機関９０に転送する（Ｓ２６５）。
決済機関９０のサーバ９２においては、携帯電話機１３から携帯電話会社１０を介して送信された顧客番号、キーコードおよびパスワードをデータ処理部９２１が受信する（Ｓ２００）。以降、決済機関９０のサーバ９２は、図５０および図５１に示したステップＳ２０３〜Ｓ２０５，Ｓ２５０，Ｓ２５１と同じ処理を携帯電話会社１０のサーバ３０に代わって実行する。但しここでは、決済機関９０のサーバ９２は認証異常通知を携帯電話会社１０に送信し、携帯電話会社１０のサーバ３０はこれを携帯電話機１３に転送する（Ｓ２６６）。また、決済機関９０のサーバ９２は利用不可通知を携帯電話会社１０に送信し、携帯電話会社１０のサーバ３０はこれを携帯電話機１３に転送する（Ｓ２６７）。携帯電話機１３のステップＳ１５０〜Ｓ１５２，Ｓ１１０，Ｓ１１１は図５１に示したものと同じであるから、その説明は繰返さない。
利用状況の確認（Ｓ２０４）の結果、利用状況が「利用可」の場合、決済機関９０は利用者１２に対して前払金額の入力を要求する。具体的には、決済機関９０のサーバ９２において、データ処理部９２１が前払金額の要求を携帯電話機１３に送信する（Ｓ１３４０）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０からインターネット６０を介して送信された前払金額の要求を利用者１２の携帯電話機１３に転送する（Ｓ２６８）。
利用者１２の携帯電話機１３においては、送受信部１３５が決済機関９０から携帯電話会社１０を介して送信された前払金額の要求を受信する（Ｓ１７７）。
利用者１２はこの要求に応じて携帯電話機１３の入力装置１３６を操作し、所望の前払金額を入力するとともに前払金額の支払方法を選択する（Ｓ１７８）。この支払方法としては、上記と同様に銀行口座からの引落し、デビット決済、クレジット決済の他、振込み、電子マネーによる決済などがある。携帯電話機１３の送受信部１３５は、この入力された前払金額および選択された支払方法を決済機関９０に送信する。携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された前払金額および支払方法を決済機関９０に転送する（Ｓ２６９）。
決済機関９０のサーバ９２においては、携帯電話機１３から携帯電話会社１０を介して送信された前払金額および支払方法をデータ処理部９２１が受信する（Ｓ１３４１）。
続いて、データ処理部９２１は選択された支払方法で所望の前払金額の決済処理を実行する（Ｓ１３４２）。
続いて、データ処理部９２１は決済が可能か否かを判定する（Ｓ１３４３）。決済が不可能な場合、決済機関９０は利用者１２に前払不可を通知する。具体的には、決済機関９０のサーバ９２において、データ処理部９２１が前払不可の通知を携帯電話機１３に送信する（Ｓ１３４４）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０からインターネット６０を介して送信された前払不可の通知を携帯電話機１３に転送する（Ｓ２７０）。
利用者１２の携帯電話機１３においては、送受信部１３５が決済機関９０から携帯電話会社１０を介して送信された前払不可の通知を受信し（Ｓ１７９）、前払不可を表示装置１３７に表示する（Ｓ１８０）。
一方、ステップＳ１３４３で決済が可能な場合、決済機関９０は利用者１２に仮想口座の新しい残高とともに前払完了を通知する。具体的には、データ処理部９２１が仮想口座の残高とともに前払完了の通知を携帯電話機１３に送信する（Ｓ１３４５）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０からインターネット６０を介して送信された仮想口座の残高および前払完了の通知を利用者１２の携帯電話機１３に転送する（Ｓ２７１）。
利用者１２の携帯電話機１３においては、送受信部１３５が決済機関９０から携帯電話会社１０を介して送信された仮想口座の残高および前払完了の通知を受信し（Ｓ１８１）、データ処理部１３１が仮想口座の残高とともに前払完了を表示装置１３７に表示する（Ｓ１８２）。
前払完了の通知（Ｓ１３４５）後、データ処理部９２１は前払金額に基づいて入出金履歴９１２を更新し（Ｓ１３０６）、さらに仮想口座１１０の残高を更新する（Ｓ１３０８）。
上述したステップＳ２６５〜Ｓ２７１に係る通信は同一セッション内で行なわれる。したがって、入出金履歴や仮想口座残高を更新する前に通信が遮断された場合は入出金履歴や仮想口座残高は更新されない。
２．仮想店舗での決済
次に、仮想店舗での決済について説明する。以下に仮想口座から仮想店舗に請求金額を送金する２つの方法を挙げる。
２−１．第１の送金方法
図６８は、この発明の第４の実施の形態に従う第１の送金方法を示す概念図である。ここでは、決済機関９０のサーバ９２に設けられたデータベース９２２に、加盟店請求履歴９１８および加盟店入金履歴９２０が記録される。図６９および図７０は、図６８に示した場合における、パーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、決済機関のサーバ、および仮想店舗のサーバの動作を示すフローチャートである。
上記第３の実施の形態と同様に、利用者１２のパーソナルコンピュータ４０または携帯電話機１３は注文内容とともに顧客番号を仮想店舗２４に送信する（Ｓ３０１）。仮想店舗２４のサーバ５０はこれらを受信し（Ｓ６０１）、顧客番号とともに請求内容を決済機関９０に送信する（Ｓ６０２）。
決済機関９０のサーバ９２においては、データ処理部９２１が仮想店舗２４から送信された請求内容を受信する（Ｓ１３１０）。
続いて、決済機関９０のサーバ９２は、図５４に示したステップＳ５０２，Ｓ５０３，Ｓ５０５と同じ処理を携帯電話会社１０のサーバ３０に代わって実行する。但しここでは、携帯電話番号の代わりに顧客番号に基づいて決済機関９０のサーバ９２がデータベース９２２中の利用者情報９１０を検索する（Ｓ５０２）。
利用状況の確認（Ｓ５０３）の結果、利用状況が「利用可」の場合、決済機関９０のサーバ９２においては、データ処理部９２１が顧客番号に基づいてデータベース９２２を検索し、利用者情報９１０の中から携帯電話機１３の電子メールアドレスを読出し、その電子メールアドレスに従って電子請求書を電子メールで携帯電話機１３に送信する（Ｓ５０５）。この電子請求書には、請求番号、請求金額、送金先（加盟店番号）などが記録されている。
続いて、データ処理部９２１は加盟店請求履歴９１８を更新し、仮想店舗２４から送信された電子請求書に基づいて、請求番号、請求日、請求金額などを記録する（Ｓ１３４０）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０からインターネット６０を介して送信された電子メールを利用者１２の携帯電話機１３に転送する（Ｓ２７２）。
携帯電話機１３においては、送受信部１３５が決済機関９０から携帯電話会社１０を介して送信された電子メールを受信し（Ｓ４０１）、データ処理部１３１が利用者１２の操作に応じて電子メールを開封し、電子請求書を表示装置１３７に表示する（Ｓ４１８）。
続いて、利用者１２が電子請求書を確認し、そこに記録されている請求金額を仮想店舗２４に送金する場合は「送金」を選択する。このとき、利用者１２は入力装置１３６を操作して顧客番号およびパスワードも入力する。これにより携帯電話機１３は電子メールに埋込まれている送金ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）に従って決済機関９０のサーバ９２に接続され、送受信部１３５がキーコード、顧客番号およびパスワードとともに送金選択信号を決済機関９０に送信する（Ｓ４３０）。携帯電話会社１０のサーバ３０は、携帯電話機１３から送信された送金選択信号をインターネット６０を介して決済機関９０に転送する（Ｓ２７３）。
決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話機１３から携帯電話会社１０を介して送信されたキーコード、顧客番号、パスワードおよび送金選択信号を受信し（Ｓ１３４１）、その受信した顧客番号に基づいてデータベース９２２中の利用者情報９１０を検索する（Ｓ１３４２）。以降、決済機関９０のサーバ９２は図５５に示したステップＳ５１１，Ｓ５１２，Ｓ５２２〜Ｓ５２４と同じ処理を携帯電話会社１０のサーバ３０に代わって実行する。
データ処理部９２１がキーコードおよびパスワードを検証し（Ｓ５１１，Ｓ５１２）、両方共一致した場合は仮想口座１１０の新しい残高とともに送金完了の通知を携帯電話会社１０を介して利用者１２の携帯電話機１３に送信する（Ｓ１３４３）。携帯電話会社１０のサーバ３０は、決済機関９０からインターネット６０を介して送信された送金完了の通知を利用者１２の携帯電話機１３に転送する（Ｓ２７５）。携帯電話機１３においては、送受信部１３５が決済機関９０から携帯電話会社１０を介して送信された送金完了通知を受信し（Ｓ４３１）、さらにデータ処理部１３１が送金後の仮想口座残高とともに送金完了を表示装置１３７に表示する（Ｓ４３２）。
送金完了の通知（Ｓ１３４３）後、決済機関９０のサーバ９２は図５６に示したステップＳ１３２０〜Ｓ１３２２と同じ処理を実行する。
仮想口座残高の更新（Ｓ１３２２）後、データ処理部９２１はデータベース９２２中の加盟店請求履歴９１８を更新し、入金日を記録する（Ｓ１３４４）。
続いて、データ処理部９２１はデータベース９２２中の加盟店入金履歴９２０を更新し、請求番号、入金日、入金額、送金顧客番号などを記録する（Ｓ１３４５）。
続いて、データ処理部９２１は入金通知をインターネット６０を介して仮想店舗２４に送信する（Ｓ１３４６）。仮想店舗２４のサーバ５０においては、モデム５０４が決済機関９０から送信された入金通知を受信する（Ｓ６１９）。
ここでは、ステップＳ２７２〜Ｓ２７５に係る通信は同一セッション内で行なわれる。
２−２．第２の送金方法
図７１は、この発明の第４の実施の形態に従う第２の送金方法を示す概念図である。図７２および図７３は、図７１に示した場合における、パーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、決済機関のサーバ、および仮想店舗のサーバの動作を示すフローチャートである。
注文を受けた仮想店舗２４は、上記第１の送金方法のように支払内容を決済機関９０を介して利用者１２に通知するのではなく、ここでは支払内容を利用者１２に直接通知する。具体的には、仮想店舗２４のサーバ５０においては、注文の受信（Ｓ６０１）後、データ処理部５０１は仮想店舗２４の加盟店番号と請求金額などの請求内容をインターネット６０を介して利用者１２の携帯電話機１３またはパーソナルコンピュータ４０に送信する（Ｓ６２０）。利用者１２の携帯電話機１３またはパーソナルコンピュータ４０においては、送受信部１３５またはモデム４０４がこれらを受信する（Ｓ３１２）。
利用者１２は通知された請求内容を見て携帯電話機１３を操作し、メニュー画面から「送金」を選択する（Ｓ９７）。図６６に示したステップＳ９９〜１０３，Ｓ１７５，Ｓ１７６，Ｓ２６５，Ｓ２００と同様に、利用者１２はパスワードおよび顧客番号を入力し、携帯電話機１３はこれらをキーコードとともに決済機関９０に送信し、決済機関１２はこれらを受信する。
続いて、図６９に示したステップＳ５０２，Ｓ５０３，Ｓ１３１４，Ｓ６０３，Ｓ６０４，Ｓ３０２，Ｓ３０３，Ｓ５１１，Ｓ５１２，Ｓ５２２〜Ｓ５２４，Ｓ２７４，Ｓ１５９，Ｓ６１３と同様に、決済機関９０は認証を行ない、ステップＳ５１１，Ｓ５１２でキーコードおよびパスワードの両方が一致した場合、具体的な送金内容を入力するよう利用者１２に要求する。利用者１２はこの要求に応じて具体的な送金内容を入力して決済機関９０に送信する。
具体的には、決済機関９０のサーバ９２においては、データ処理部９２１が送金内容の要求を利用者１２の携帯電話機１３に送信する（Ｓ１３４７）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０からインターネット６０を介して送信された送金内容の要求を携帯電話機１３に転送する（Ｓ２７６）。
利用者１２の携帯電話機１３においては、送受信部１３５が決済機関９０から携帯電話会社１０を介して送信された送金内容の要求を受信する（Ｓ４３３）。
続いて、入力装置１３６は利用者１２の操作に応じて入力された送金内容をデータ処理部１３１に与え、送受信部１３５はその入力された送金内容を決済機関９０に送信する（Ｓ４３４）。送金内容としては、送金先の加盟店番号、送金金額などがある。携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された送金内容を決済機関９０に転送する（Ｓ２７７）。決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話機１３から携帯電話会社１０を介して送信された送金内容を受信する（Ｓ１３４８）。以降は、図７０に示したステップＳ１３４３，Ｓ２７５，Ｓ４３１，Ｓ４３２，Ｓ１３２０〜Ｓ１３２２，Ｓ１３４５，Ｓ１３４６，Ｓ６１９と同じであるから、その説明は繰返さない。ただしここでは、図６８に示した請求履歴９１８はないので請求履歴の更新（Ｓ１３４４）は行なわれない。
３．実在店舗での決済
次に、実在店舗での決済について説明する。ここでは、仮想口座からの振替えが可能な小口口座をさらに設け、その小口口座の使用を可能にするワンタイムＩＤ（識別子）を発行する。
３−１．ワンタイムＩＤの発行（小口口座への振替え）
図７４および図７５は、この発明の第４の実施の形態に従ってワンタイムＩＤの発行方法を示す概念図である。図７４は小口決済履歴がない場合を示し、図７５は小口決済履歴がある場合を示す。ここでは、決済機関９０のサーバ９２に設けられたデータベース９２２に、小口口座の入出金履歴９１５が記録される。図７６および図７７は、図７４および図７５に示した場合における、携帯電話機、携帯電話会社のサーバ、および決済機関のサーバの動作を示すフローチャートである。
実在店舗で決済をするために仮想口座から小口口座に所望の金額を振替えようとする場合、利用者１２は携帯電話機１３を操作し、メニュー画面で「ワンタイムＩＤ」を選択する（Ｓ９６）。具体的には、携帯電話機１３において、入力装置１３６が利用者１２の操作に応じて「ワンタイムＩＤ」の選択信号をデータ処理部１３１に与える。以降、ステップＳ９９〜Ｓ１０３，Ｓ１７５は図６６に示したものと同じであるから、その説明は繰返さない。
顧客番号の入力（Ｓ１７５）後、携帯電話機１３においては、送受信部１３５が顧客番号、キーコード、パスワードおよび小口口座情報を決済機関９０に送信する（Ｓ１８５）。小口口座情報には、ＲＡＭ１３２に記録されている小口口座残高および小口決済履歴が含まれる。但し、初めてワンタイムＩＤを要求する場合、小口決済履歴はまだ存在していない。以降、ステップＳ２６５〜Ｓ２６７，Ｓ２００，Ｓ２０２〜Ｓ２０５，Ｓ２５０，Ｓ２５１，Ｓ１５０〜Ｓ１５２，Ｓ１１０，Ｓ１１１は図６６に示したものと同じであるから、その説明は繰返さない。
利用者１２の認証（Ｓ２０３）の結果、キーコードおよびパスワードが共に一致し、かつ利用状況の確認（Ｓ２０４）の結果、利用状況が「利用可」の場合、決済機関９０は利用者１２に対して仮想口座から小口口座への振替金額を要求する。具体的には、決済機関９０のサーバ９２において、データ処理部９２１が小口口座への希望振替金額の要求を利用者１２の携帯電話機１３に送信する（Ｓ１３５０）。このとき、振替可能な限度額（通常は仮想口座の残高）も併せて送信する。携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０からインターネット６０を介して送信された振替金額の要求を携帯電話機１３に転送する（Ｓ２７８）。
利用者１２の携帯電話機１３においては、送受信部１３５が決済機関９０から携帯電話会社１０を介して送信された振替金額の要求を受信する（Ｓ１８６）。
この要求に応じ、利用者１２は携帯電話機１３の入力装置１３６を操作して所望の振替金額を指定する（Ｓ１８７）。入力装置１３６は利用者１２により指定された振替金額をデータ処理部１３１に与える。
データ処理部１３１はステップＳ１８７で指定された決済金額をステップＳ１８６で受信した限度額と比較し、指定された決済金額が限度額以内か否かを判定する（Ｓ１８８）。指定された振替金額が限度額を超えている場合、データ処理部１３１は振替不可を表示装置１３７に表示する（Ｓ１８９）。一方、指定された振替金額が限度額以内の場合、送受信部１３５はその指定された振替金額を決済機関９０に送信する（Ｓ１９０）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が利用者１２の携帯電話機１３から送信された振替金額をインターネット６０を介して決済機関９０に転送する（Ｓ２７９）。
決済機関９０のサーバ９２においては、データ処理部９２１が利用者１２の携帯電話機１３から携帯電話会社１０を介して送信された振替金額を受信し（Ｓ１３５１）、さらにランダムにワンタイムＩＤを生成する（Ｓ１３５２）。
続いて、データ処理部９２１はステップＳ１３５１で受信した振替金額に基づいて、仮想口座の入出金履歴９１２を更新し（Ｓ１３２０）、仮想口座の決済履歴９１４を更新し（Ｓ１３２１）、仮想口座１１０の残高を更新し（Ｓ１３２２）、さらに小口口座の入出金履歴９１５を更新する（Ｓ１３４５）。
たとえば図７４に示すように利用者１２が振替金額を１０００円に指定した場合、仮想口座の入出金履歴９１２には１０００円が小口口座に出金された旨が記録される。また、仮想口座１１０の残高は１０００円減額され、小口口座の残高は１０００円増額される。さらに、小口口座の入出力履歴９１５には１０００円が入金された旨が記録される。この場合、小口決済履歴は携帯電話機１３から送信されて来ないので、仮想口座の決済履歴９１４は更新されない。
次に、図７５に示すように携帯電話機１３の小口決済履歴に３００円を使用した旨が記録されている（つまり携帯電話機１３の小口口座残高が７００円になっている）場合において利用者１２が振替金額を１５００円に指定したときは、この振替金額（１５００円）と現在の小口口座残高（７００円）との差額（８００円）が計算され、仮想口座の入出力履歴９１２には８００円が出金された旨が記録される。また、携帯電話機１３の小口決済履歴に基づいて仮想口座の決済履歴９１４には３００円が決済に使用された旨が記録される。また、上記差額に基づいて仮想口座１１０の残高は８００円減額され、２００円になる。小口口座から３００円が決済に使用されたが、新たに８００円が小口口座に振替えられるので、小口口座の残高は上記振替金額に等しい１５００円になる。また、小口口座の入出金履歴９１５には携帯電話機１３の小口決済履歴に基づいて３００円が出金された旨が記録され、さらに上記差額に基づいて８００円が入金された旨が記録される。
最後に、データ処理部９２１はステップＳ１３５２で生成したワンタイムＩＤや小口口座残高などの振替内容を利用者１２の携帯電話機１３に送信する（Ｓ１３５３）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０からインターネット６０を介して送信された振替内容を携帯電話機１３に転送する（Ｓ２８０）。
利用者１２の携帯電話機１３においては、送受信部１３５が決済機関９０から携帯電話会社１０を介して送信された振替内容を受信する（Ｓ１１９）。
続いて、データ処理部１３１はＲＡＭ１３２に記録されている小口決済履歴をクリアする（Ｓ１９２）。続いて、データ処理部１３１は、ＲＡＭ１３２に記録されている小口口座残高を書替え（Ｓ１９３）、さらにＲＡＭ１３２に記録されているワンタイムＩＤを書替える（Ｓ１９４）。
たとえば図７４に示した場合、決済機関９０で生成された「９８７６５」のワンタイムＩＤが携帯電話機１３のＲＡＭ１３２に記録される。また、利用者１２が指定した振替金額に従って小口口座残高が「０円」から「１０００円」に更新される。また、図７５に示した場合、決済機関９０で生成された「３４５６７」の新しいワンタイムＩＤが携帯電話機１３のＲＡＭ１３２に記録される。また、決済機関９０で計算された「１５００円」の新しい小口口座残高が携帯電話機１３のＲＡＭ１３２に記録される。
最後に、データ処理部１３１は小口口座残高とともに小口口座への入金完了を表示装置１３７に表示する（Ｓ１９５）。
３−２．ワンタイムＩＤの使用（小口口座からの支払い）
図７８は、この発明の第４の実施の形態に従い、ワンタイムＩＤを使用して実在店舗で決済する方法を示す概念図である。図７９は、図７８に示した場合における、携帯電話機、実在店舗のＰＯＳ端末、および決済機関のサーバの動作を示すフローチャートである。
小口口座に所望の金額を振替えてワンタイムＩＤを獲得した後、実在店舗２６で決済を行なう場合、利用者１２は携帯電話機１３を操作し、メニュー画面で「支払い」を選択する（Ｓ９５）。具体的には、携帯電話機１３において、入力装置１３６が利用者１２の操作に応じて「支払い」の選択信号をデータ処理部１３１に与える。以降、ステップＳ９９〜Ｓ１０３は図６６に示したものと同じであるから、その説明は繰返さない。
パスワードの検証（Ｓ１０２）後、データ処理部１３１はＲＡＭ１３２に記録されているワンタイムＩＤが有効か否かを判定する（Ｓ７３５）。ワンタイムＩＤには有効日が付与されており、小口口座の残高はその有効日までしか実在店舗での決済に使用することができない。ワンタイムＩＤは実在店舗での決済に１回使用すれば無効になるようにしてもよい。
ワンタイムＩＤが無効な場合、データ処理部１３１はその旨を表示装置１３７に表示する（Ｓ７３６）。一方、ワンタイムＩＤが有効な場合、データ処理部１３１は小口口座からの支払いが可能である旨を表示装置１３７に表示する（Ｓ７３７）。以降、ステップＳ７１６〜Ｓ７１９，Ｓ８０１は図５９に示したものと同じであるから、その説明は繰返さない。
残高検証（Ｓ７１８）の結果、ＰＯＳ端末２７から送信された決済金額が小口口座の残高以内の場合、携帯電話機１３のインターフェイス部１３９はＰＯＳ端末２７にＲＡＭ１３２に記録されているワンタイムＩＤを送信する（Ｓ７３８）。
続いて、データ処理部１３１はＲＡＭ１３２に記録されている小口決済履歴を更新する（Ｓ７３９）。具体的には、データ処理部１３１は、ＰＯＳ端末２７から送信された決済金額、決済日、実在店舗２６の加盟店番号などを記憶する。
続いて、データ処理部１３１はＲＡＭ１３２に記録されている小口口座の残高を更新する（Ｓ７４０）。具体的には、データ処理部１３１は、小口口座の残高から決済金額を減算して新しい残高を記録する。この時点で、携帯電話機１３の小口口座の残高は決済機関９０の小口口座の残高とずれる。
最後に、データ処理部１３１は小口口座の新しい残高とともに決済の完了を表示装置１３７に表示する（Ｓ７４１）。
実在店舗２６のＰＯＳ端末２７においては、インターフェイス部２７６が携帯電話機１３から送信されたワンタイムＩＤを受信する（Ｓ８１０）。
続いて、データ処理部２７１はその決済金額に基づいて売上計上処理を実行する（Ｓ８１１）。
続いて、インターフェイス部２７６は、加盟店番号とともにワンタイムＩＤ、決済日、決済金額、顧客番号などの決済内容を決済機関９０に送信する（Ｓ８０５）。
決済機関９０のサーバ９２においては、データ処理部９２１がＰＯＳ端末２７から送信された決済内容を受信し（Ｓ１３３３）、その受信した決済内容に基づいて加盟店の入金履歴９２０を更新する（Ｓ１３５５）。
続いて、データ処理部９２１はその支払を承認した旨の通知を実在店舗２６に送信する（Ｓ１３２４）。実在店舗２６のＰＯＳ端末２７は、決済機関９０から送信された支払承認の通知を受信する（Ｓ８０６）。
最後に、データ処理部９２１はたとえば月末に１ヶ月間の総支払金額を計算し、実在店舗２６に対する支払処理を実行する（Ｓ１３２５）。
上述した第４の実施の形態では、携帯電話会社１０のサーバ３０が携帯電話機１３から送信されたキーコードをそのまま決済機関９０のサーバ９２に転送しているが、携帯電話機１３から送信されたキーコードをこれと１対１に対応する別のキーコードに変換して決済機関９０のサーバ９２に送信するようにしてもよい。
また、小口口座への振替えの際にワンタイムＩＤをダウンロードするようにしているが、利用者１２が携帯電話機１３で決済機関９０が提供するサービスサイトにアクセスする度に自動的に新しいワンタイムＩＤをダウンロードするようにしてもよい。この場合、ワンタイムＩＤの更新頻度が増すため、セキュリティがさらに高くなる。
また、ワンタイムＩＤを１次元または２次元バーコードのイメージとし、実在店舗での決済の際には携帯電話機１３に表示されたバーコードをＰＯＳ端末２７のリーダで光学的に読取るようにしてもよい。この場合、携帯電話機１３から情報を読取るための専用機器をＰＯＳ端末２７に取付ける必要はなく、既存のバーコードリーダを用いればよい。また、小口口座の残高をワンタイムＩＤのバーコードに付加してもよい。
この発明の第４の実施の形態によれば、決済機関９０が携帯電話機１３から出力されるキーコードを取得し、利用者１２の認証を行なっているため、認証を携帯電話会社１０に依存することはない。そのため、決済会社９０だけで本サービスを提供することができる。
また、仮想口座とは別に小口口座を設け、実在店舗で決済する際には予め仮想口座から小口口座に振替えを行なっておき、小口口座から代金を支払うようにしているため、上記第１〜第２の実施の形態のように仮想口座の残高が真の残高からずれることはない。また、決済機関が小口口座からの出金を可能にするためのワンタイムＩＤを発行し、ワンタイムＩＤが有効でかつ決済金額が小口口座の残高以内の場合だけ携帯電話機１３からＰＯＳ端末２７にワンタイムＩＤが出力され、ＰＯＳ端末２７はこのワンタイムＩＤに基づいて決済を完了するようにしているため、セキュリティが高くなる。
上記各コンピュータには所定のプログラムがインストールされている。この各プログラムは、フローチャートで示した各列に並ぶ一連のステップを対応のコンピュータに実行させるためのものである。各プログラムはＣＤ−ＲＯＭのようなコンピュータ読取可能な媒体に記録して配布可能である。
今回開示された実施の形態はすべての点で例示であって制限的なものではないと解釈されるものである。本発明の範囲は上述した実施の形態ではなく特許請求の範囲によって定められ、特許請求の範囲と均等の意味およびその範囲内でのすべての変更が含まれることを意図するものである。
産業上の利用可能性
この発明は、携帯電話機を用いた決済サービスに適用可能である。
【図面の簡単な説明】
図１は、この発明の第１の実施の形態に従って仮想口座に入金する前払金額を通話料と併せて支払う場合の資金移動を示す概略図である。
図２は、この発明の第１の実施の形態に従って仮想口座に入金する前払金額をクレジットカードで支払う場合の資金移動を示す概略図である。
図３は、この発明の第１の実施の形態に従って仮想口座に入金する前払金額をデビットカードで支払う場合の資金移動を示す概略図である。
図４は、この発明の第１の実施の形態に従って仮想口座に入金する前払金額を銀行口座から自動引落しする場合の資金移動を示す概略図である。
図５は、この発明の第１の実施の形態に従って携帯電話機を用いてインターネット上の仮想店舗で決済する方法を示す概略図である。
図６は、この発明の第１の実施の形態に従って携帯電話機を用いて実在店舗で決済する方法を示す概略図である。
図７は、図１〜図４に示したように仮想口座に前払金を入金するために用いられる、携帯電話機および携帯電話会社のサーバのハードウェア構成を示すブロック図である。
図８は、図１に示した場合における、図７に示した携帯電話機および携帯電話会社のサーバの動作を示すフローチャートである。
図９は、図８に示した携帯電話機の動作中に表示される画面の遷移図である。
図１０は、図２に示した場合における、図７に示した携帯電話機および携帯電話会社のサーバの動作を示すフローチャートである。
図１１は、図１０に示した携帯電話機の動作中に表示される画面の遷移図である。
図１２は、図３に示した場合における、図７に示した携帯電話機および携帯電話会社のサーバの動作を示すフローチャートである。
図１３は、図１２に示した携帯電話機の動作中に表示される画面の遷移図である。
図１４は、図４に示した場合における、図７に示した携帯電話機および携帯電話会社のサーバの動作を示すフローチャートである。
図１５は、図１４に示した携帯電話の動作中に表示される画面の遷移図である。
図１６は、この発明の第１の実施の形態に従ってインターネット上の仮想店舗で携帯電話機を用いて決済する場合に用いられる、携帯電話機、携帯電話会社のサーバ、パーソナルコンピュータ、および仮想店舗のサーバのハードウェア構成を示すブロック図である。
図１７は、図５に示した場合における図１６に示したパーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、および仮想店舗のサーバの動作を示すフローチャートである。
図１８は、図１７に続くフローチャートである。
図１９は、図１７および図１８に示した携帯電話機の動作中に表示される画面の遷移図である。
図２０は、図６に示した場合に用いられる、携帯電話機、携帯電話会社のサーバ、および実在店舗のＰＯＳ端末のハードウェア構成を示すブロック図である。
図２１は、図２０に示した携帯電話機、実在店舗のＰＯＳ端末、および携帯電話会社のサーバの動作を示すフローチャートである。
図２２は、図２１に続くフローチャートである。
図２３は、図２１および図２２に示した携帯電話機の動作中に表示される画面の遷移図である。
図２４は、携帯電話機のＲＡＭおよびＲＯＭに記憶される情報を示す図である。
図２５は、この発明の第２の実施の形態に従って実在口座から仮想口座に振替える場合の資金移動を示す概略図である。
図２６は、図２５に示したように実在口座から仮想口座への振替に用いられる携帯電話機、携帯電話会社のサーバおよび金融機関のサーバのハードウェア構成を示すブロック図である。
図２７は、図２５に示した場合における、図２６に示した携帯電話機、携帯電話会社のサーバ、および金融機関のサーバの動作を示すフローチャートである。
図２８は、図２７に続くフローチャートである。
図２９は、図２７および図２８に示した携帯電話機の動作中に表示される画面の遷移図である。
図３０は、この発明の第２の実施例に従って携帯電話機を用いてインターネット上の仮想店舗で決済する方法を示す概略図である。
図３１は、図３０に示した場合に用いられるパーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、金融機関のサーバ、決済機関のサーバ、および仮想店舗のサーバのハードウェア構成を示すブロック図である。
図３２は、図３０に示した場合における、図３１に示したパーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、仮想店舗のサーバ、および金融機関サーバの動作を示すフローチャートである。
図３３は、図３２に続くフローチャートである。
図３４は、図３３に続くフローチャートである。
図３５は、図３２〜図３４に示した携帯電話機の動作中に表示される画面の遷移図である。
図３６は、この発明の第２の実施の形態に従って携帯電話機を用いて実在店舗で決済する方法を示す概略図である。
図３７は、図３６に示した場合に用いられる、携帯電話機、実在店舗のＰＯＳ端末、携帯電話会社のサーバ、金融機関のサーバ、および決済機関のサーバのハードウェア構成を示すブロック図である。
図３８は、図３６に示した場合における、図３７に示した携帯電話機、ＰＯＳ端末、携帯電話会社のサーバ、金融機関のサーバの動作を示すフローチャートである。
図３９は、図３８に続くフローチャートである。
図４０は、図３９に続くフローチャートである。
図４１は、この発明の第３の実施の形態に従ってサービスの利用者情報を登録する方法を示す概略図である。
図４２は、この発明の第３の実施の形態に従って仮想口座に前払金額を入金する場合の資金移動を示す概略図である。
図４３は、この発明の第３の実施の形態に従って携帯電話機を用いてインターネット上の仮想店舗で決済する方法を示す概略図である。
図４４は、この発明の第３の実施の形態に従って携帯電話機を用いて実在店舗で決済する方法を示す概略図である。
図４５は、この発明の第３の実施の形態に従って決済機関が利用者に対して携帯電話機に蓄積されている未通知データを要求する方法を示す概略図である。
図４６は、この発明の第３の実施の形態に従って携帯電話機を用いてインターネット上の仮想店舖で決済する場合において決済機関が金融機関に対する請求を代行する方法を示す概略図である。
図４７は、図４１に示した利用登録に用いられる、携帯電話機、携帯電話会社のサーバおよび決済機関のサーバのハードウェア構成を示すブロック図である。
図４８は、図４１に示した場合における、図４７に示した携帯電話機、携帯電話会社のサーバおよび決済機関のサーバの動作を示すフローチャートである。
図４９は、図４２に示した仮想口座への資金移動に用いられる、携帯電話機、携帯電話会社のサーバ、決済機関のサーバおよび金融機関のサーバのハードウェア構成を示すブロック図である。
図５０は、図４２に示した場合における、図４９に示した携帯電話機、携帯電話会社のサーバおよび決済機関のサーバの動作を示すフローチャートである。
図５１は、図５０に続くフローチャートである。
図５２は、図５１に続くフローチャートである。
図５３は、図４３に示した仮想店舗での決済に用いられる、パーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、決済機関のサーバおよび仮想店舗のサーバのハードウェア構成を示すブロック図である。
図５４は、図４３に示した場合における、図５３に示したパーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、決済機関のサーバおよび仮想店舗のサーバの動作を示すフローチャートである。
図５５は、図５４に続くフローチャートである。
図５６は、図５５に続くフローチャートである。
図５７は、図４４に示した実在店舗での決済に用いられる、携帯電話機、ＰＯＳ端末、携帯電話会社のサーバおよび決済機関のサーバのハードウェア構成を示すブロック図である。
図５８は、図４４に示した場合における、図５７に示した携帯電話機、ＰＯＳ端末、携帯電話会社のサーバおよび決済機関のサーバの動作を示すフローチャートである。
図５９は、図５８に続くフローチャートである。
図６０は、図５９に続くフローチャートである。
図６１は、図４５に示した未通知データの要求の場合における、携帯電話機、携帯電話会社のサーバおよび決済機関のサーバの動作を示すフローチャートである。
図６２は、図４６に示した請求代行に用いられる、パーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、決済機関のサーバ、金融機関のサーバおよび仮想店舗のサーバのハードウェア構成を示すブロック図である。
図６３は、図４６に示した場合における、図６２に示したパーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、決済機関のサーバ、金融機関のサーバおよび仮想店舗のサーバの動作を示すフローチャートである。
図６４は、図６３に続くフローチャートである。
図６５は、この発明の第４の実施の形態に従う前払方法を示す概略図である。
図６６は、図６５に示した場合における、携帯電話機、携帯電話会社のサーバ、および決済機関のサーバの動作を示すフローチャートである。
図６７は、図６６に続くフローチャートである。
図６８は、この発明の第４の実施の形態に従う第１の送金方法を示す概念図である。
図６９は、図６８に示した場合における、パーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、決済機関のサーバ、および仮想店舗のサーバの動作を示すフローチャートである。
図７０は、図６９に続くフローチャートである。
図７１は、この発明の第４の実施の形態に従う第２の送金方法を示す概念図です。
図７２は、図７１に示した場合における、パーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、決済機関のサーバ、および仮想店舗のサーバの動作を示すフローチャートである。
図７３は、図７２に続くフローチャートである。
図７４は、この発明の第４の実施の形態に従って、小口決済履歴がない場合におけるワンタイムＩＤの発行方法を示す概念図である。
図７５は、この発明の第４の実施の形態に従って、小口決済履歴がある場合におけるワンタイムＩＤの発行方法を示す概念図である。
図７６は、図７４および図７５に示した場合における、携帯電話機、携帯電話会社のサーバ、および決済機関のサーバの動作を示すフローチャートである。
図７７は、図７６に続くフローチャートである。
図７８は、この発明の第４の実施の形態に従い、ワンタイムＩＤを使用して実在店舗で決済する方法を示す概念図である。
図７９は、図７８に示した場合における、携帯電話機、実在店舗のＰＯＳ端末、および決済機関のサーバの動作を示すフローチャートである。

Claims (33)

1. 売り主と携帯電話機の利用者たる買い主との間の決済を仲介する方法であって、前記利用者の金銭を蓄積するための第１の口座を有するコンピュータにおいて、
   前記携帯電話機から送信された所望の金額を受信するステップと、
   前記受信した所望の金額を前記利用者の第１の口座に入金してその口座の残高を更新するステップと、
   前記更新した第１の口座の残高を前記携帯電話機に送信するステップと、
   決済金額を受信するステップと、
   前記受信した決済金額を前記第１の口座の残高から減じるステップと、
   前記受信した決済金額を前記売り主に支払うステップとを含む、方法。
2. 前記受信した所望の金額を前記利用者に対して課金するステップをさらに含む、請求項１に記載の方法。
3. 前記携帯電話機から送信された識別情報を受信するステップと、
   前記受信した識別情報に基づいて前記利用者の認証を行なうステップとをさらに含む、請求項１に記載の方法。
4. 前記識別情報は前記利用者に固有の利用者固有情報を含む、請求項３に記載の方法。
5. 前記利用者固有情報は前記携帯電話機の電話番号を含む、請求項４に記載の方法。
6. 前記利用者固有情報はパスワードをさらに含む、請求項５に記載の方法。
7. 前記利用者固有情報は前記利用者に予め付与された利用者識別子を含む、請求項４に記載の方法。
8. 前記利用者固有情報はパスワードをさらに含む、請求項７に記載の方法。
9. 前記識別情報は前記携帯電話機に固有の電話機固有情報をさらに含む、請求項４に記載の方法。
10. 前記電話機固有情報は前記携帯電話機の製造番号を含む、請求項９に記載の方法。
11. 前記電話機固有情報は前記携帯電話機のサブスクライバ識別子を含む、請求項９に記載の方法。
12. 前記サブスクライバ識別子は携帯電話局を介して送信される、請求項１１に記載の方法。
13. 前記コンピュータは第２の口座をさらに有し、
    前記携帯電話機から送信された振替金額を受信するステップと、
    前記受信した振替金額を前記第１の口座から前記第２の口座に振替えるステップと、
    前記第２の口座の残高を使用可能にするためのワンタイム識別子を生成して前記携帯電話機に送信するステップとをさらに含む、請求項１に記載の方法。
14. 前記コンピュータは携帯電話会社に設けられる、請求項１に記載の方法。
15. 前記コンピュータは決済機関に設けられる、請求項１に記載の方法。
16. 前記コンピュータは金融機関に設けられる、請求項１に記載の方法。
17. 売り主と携帯電話機の利用者たる買い主との間の決済を仲介する方法であって、前記利用者の金銭を蓄積するための口座を有する金融機関のコンピュータにおいて、
    携帯電話局のコンピュータから決済金額を受信するステップと、
    前記受信した決済金額を前記口座の残高から減じるステップと、
    前記受信した決済金額を前記売り主に支払うステップとを含む、方法。
18. 前記携帯電話機から送信された金額を前記携帯電話局のコンピュータを介して受信するステップと、
    前記受信した金額を前記利用者の口座に振替えてその口座の残高を更新するステップと、
    前記更新した口座の残高を前記携帯電話局のコンピュータを介して前記携帯電話機に送信するステップとをさらに含む、請求項１７に記載の方法。
19. 売り主と携帯電話機の利用者たる買い主との間の決済に用いられ、前記利用者の金銭を蓄積するための第１の口座を有するコンピュータにアクセス可能な携帯電話機であって、
    前記利用者の操作に応じて前記第１の口座に入金されるべき所望の金額を入力する入力手段と、
    前記入力された金額を前記コンピュータに送信し、前記コンピュータから送信された前記第１の口座の残高を受信する送受信手段と、
    前記受信した第１の口座の残高を記憶する手段とを備える、携帯電話機。
20. 前記送受信手段はさらに前記利用者の認証に必要な識別情報を前記コンピュータに送信する、請求項１９に記載の携帯電話機。
21. 前記識別情報は前記利用者に固有の利用者固有情報を含む、請求項２０に記載の携帯電話機。
22. 前記利用者固有情報を記憶する手段をさらに備える、請求項２１に記載の携帯電話機。
23. 前記利用者固有情報は前記携帯電話機の電話番号を含む、請求項２１に記載の携帯電話機。
24. 前記利用者固有情報はパスワードをさらに含む、請求項２３に記載の携帯電話機。
25. 前記利用者固有情報は前記利用者に予め付与された利用者識別子を含む、請求項２１に記載の携帯電話機。
26. 前記利用者固有情報はパスワードをさらに含む、請求項２５に記載の携帯電話機。
27. 前記識別情報は前記携帯電話機に固有の電話機固有情報をさらに含む、請求項２１に記載の携帯電話機。
28. 前記電話機固有情報を記憶する手段をさらに備える、請求項２７に記載の携帯電話機。
29. 前記電話機固有情報は携帯電話機の製造番号を含む、請求項２８に記載の携帯電話機。
30. 前記電話機固有情報は前記携帯電話機のサブスクライバ識別子を含む、請求項２８に記載の携帯電話機。
31. 前記送受信手段はさらに決済金額を受信し、
    前記送受信手段により受信された決済金額を記憶する手段をさらに備え、
    前記送受信手段はさらに前記記憶された決済金額を読出して前記コンピュータに送信する、請求項１９に記載の携帯電話機。
32. 前記記憶された第１の口座の残高から前記記憶された決済金額を減算する手段をさらに備える、請求項３１に記載の携帯電話機。
33. 前記コンピュータは第２の口座をさらに有し、
    前記入力手段は前記利用者の操作に応じて前記第１の口座から前記第２の口座に振替えられるべき振替金額を入力し、
    前記送受信手段はさらに前記入力された振替金額を前記コンピュータに送信し、
    前記送受信手段はさらに前記第２の口座の残高を使用可能にするためのワンタイム識別子を受信し、
    前記ワンタイム識別子が有効か否かを判定する手段と、
    前記ワンタイム識別子の判定の結果、前記ワンタイム識別子が有効な場合、前記送受信手段により受信された決済金額が前記第２の口座の残高以内か否かを判定する手段と、
    前記決済金額の判定の結果、前記決済金額が前記第２の口座の残高以内の場合、前記受信したワンタイム識別子を出力する手段と、
    前記決済金額を前記第２の口座から減じる手段とをさらに備える、請求項３１記載の携帯電話機。

Images