JP4901053B2

JP4901053B2 - Settlement method using mobile phone and mobile phone

Info

Publication number: JP4901053B2
Application number: JP2002511243A
Authority: JP
Inventors: 貴子浄弘; 貞行與
Original assignee: 貴子浄弘
Priority date: 2000-06-14
Filing date: 2001-06-13
Publication date: 2012-03-21
Anticipated expiration: 2021-06-13
Also published as: AU2001264274A1; JPWO2001097118A1; WO2001097118A1

Description

技術分野
この発明は、携帯電話機およびその携帯電話機を用いた決済方法に関し、さらに詳しくは、インターネット上の仮想店舗や実在店舗における決済を仲介するサービスに関する。
背景技術
現在、携帯電話機を用いた種々の決済方法が提案されている。日経エレクトロニクス「携帯で決済」第７６９号，日経ＢＰ社（２０００年５月８日）発行，１０９〜１２９頁には、ＩＣカードを搭載した携帯電話機が記載されている。この携帯電話機では、ＩＣカードにクレジットカード番号をセキュアな状態で予め記録しておき、決済時にクレジットカード番号を暗号化して送信するようにしている。また、非接触型ＩＣカード用のリーダ／ライタを搭載した携帯電話機も記載されている。この携帯電話機では、プリペイドカードの度数のような電子バリューをダウンロードし、これをリーダ／ライタにより非接触型ＩＣカードに無線経由で転送するようにしている。利用者はこの非接触型ＩＣカードを使って決済を行なう。
上記ＩＣカードを搭載した携帯電話機ではクレジットカード番号を暗号化しているが、クレジットカード番号を送信していることに変わりはないので、インターネット上の電子商取引では十分なセキュリティとは言えない。
一方、上記リーダ／ライタを搭載した携帯電話機では、利用者は携帯電話機とともに非接触型ＩＣカードを持ち歩かなければならない。また、リーダ／ライタはサイズが大きく、コストも高いなど、問題も多い。
この他、携帯電話機を用いた種々の決済方法が提案されているが、いずれも決済時に与信照会が必要であったり、決済データの送信が必要なため、決済時に電波を飛ばす必要があり、電波圏外では使用することができず、また、決済に時間がかかるという問題がある。
発明の開示
この発明は、上記のような問題を解決するためになされたもので、セキュリティが高く使い勝手のよい携帯電話機およびその携帯電話機を用いた決済方法を提供することを目的とする。
この発明による携帯電話機を用いた決済方法は、売り主と携帯電話機の利用者たる買い主との間の決済を仲介する方法であって、利用者の金銭を蓄積するための口座を利用者ごとに設けたサーバコンピュータにおいて、携帯電話機から送信された金額を受信するステップと、受信した金額を利用者の口座に入金してその口座の残高を更新するステップと、更新した口座の残高を携帯電話機に送信するステップと、決済金額を受信するステップと、受信した決済金額を口座の残高から減じるステップと、受信した決済金額を売り主に支払うステップとを含む。ここでのサーバコンピュータは、携帯電話局（会社）、金融機関（会社）、決済機関（会社）などに設置され得るが、その位置は特に限定されない。
一方、この発明による携帯電話機は、売り主と携帯電話機の利用者たる買い主との間の決済に用いられる携帯電話機であって、利用者の金銭を蓄積するための口座がサーバコンピュータに利用者ごとに設けられ、利用者の操作に応じて口座に入金される所望の金額を入力する手段と、入力された金額を携帯電話局のコンピュータに送信し、サーバコンピュータから送信された仮想口座の残高を受信する送受信手段と、受信した口座の残高を記憶する手段とを備える。
この決済方法または携帯電話機によれば、利用者は携帯電話機を用いて所望の金額を携帯電話局または携帯電話局を通じて金融機関もしくは決済機関に送信する。携帯電話局、金融機関または決済機関は、携帯電話機から送信された金額を受信し、その金額を利用者の口座に入金してその口座の残高を更新して携帯電話機に送信する。携帯電話機は、携帯電話局から送信された口座の残高を受信して記憶する。したがって、利用者は携帯電話機を財布のように使って決済を行なうことができる。ここでは、クレジット番号などを送信する必要がないので、セキュリティが高い。また、ＩＣカードなどを持ち歩く必要もないので、使い勝手がよい。
発明を実施するための最良の形態
以下、この発明の実施の形態を図面を参照して詳しく説明する。図中同一または相当部分には同一符号を付してその説明は繰返さない。
［第１の実施の形態］
１．サービスの概要
この発明の実施の形態は、携帯電話会社が提供する新規サービス（「お財布サービス」と呼び、以下単に「本サービス」という）を実現するためのコンピュータシステムに関するものである。本サービスは、携帯電話機を財布のように使用できるようにするものである。以下、本サービスの概要を説明する。
携帯電話機購入の際、通話料金を引落す銀行口座以外に、クレジットカード番号やキャッシュカード番号などを携帯電話会社に登録する。携帯電話会社は、携帯電話機の利用者ごとに仮想口座を設ける。利用者は、決済の前に、仮想口座に前払金を入金するように、携帯電話機を用いて携帯電話会社に要請する。携帯電話会社は、予め登録されている銀行口座、クレジットカード番号、キャッシュカード番号などを用い、利用者に対して前払金の請求を行なう。前払金の支払方法は、利用者が選択することができる。前払金の請求後、携帯電話会社は、仮想口座に前払金を入金したうえで仮想口座の残高を携帯電話機に送信する。携帯電話機は、送信された仮想口座の残高を記憶する。利用者は、この携帯電話機を財布代わりに使ってインターネット上の仮想店舗や実在店舗で決済を行なう。店舗は、携帯電話会社に対して請求を行なう。
２．前払金の支払方法
次に、４通りの前払金の支払方法について説明する。
２−１．通話料と併せて支払う場合
図１は、前払金を通話料と併せて支払う場合の資金移動を示す概略図である。図１に示すように、携帯電話会社（携帯電話局）１０には、個人情報データベース１１が設けられている。個人情報データベース１１には、各利用者１２の個人情報が登録されている。具体的には、前払金（携帯電話会社にとっては前受金）を蓄積するための仮想口座１１０が設けられ、携帯電話機１３の電話番号の他、電子メールアドレス、パスワード、利用状況、キーコード、口座番号、クレジットカード番号、デビットカード番号などが予め登録されている。
まず、利用者１２は携帯電話機１３を用いて所望の前払金額とその支払方法（ここでは「通話料に加算」）とを携帯電話会社１０に送信する。このとき、携帯電話機１３の電話番号も併せて送信する。
携帯電話会社１０は、送信された携帯電話番号に基づいて個人情報データベース１１を検索し、利用者１２の仮想口座１１０の利用状況を照会する。利用者１２に問題がなければ（利用状況が「ＯＫ」であれば）、携帯電話会社１０は送信された前払金額を仮想口座１１０の前受残高に加算し、更新した最新の前受残高を送信する。一方、利用者１２の支払いが滞っていたり、本サービスの利用が停止されている場合、利用状況は「ＮＧ」となっている。この場合、携帯電話会社１０は携帯電話機１３を通じて本サービスを利用できない旨を利用者１２に通知する。
上記のように利用者１２が支払方法として「通話料に加算」を選択した場合、携帯電話会社１０は、基本料金と通話料金の請求書１４と併せて本サービスの利用明細書１５を利用者１２に送付する。
携帯電話会社１０は、個人情報データベース１１に登録されている口座番号に基づいて利用者１２の取引銀行１７に利用料金の引落しを依頼する。これに応じて銀行１７は、利用者１２の口座１６から、銀行１８に開設されている携帯電話会社１０の口座１９に資金を振替える。
２−２．クレジットカードで支払う場合
図２は、前払金をクレジットカードで支払う場合の資金移動を示す概略図である。この場合、図２に示すように、利用者１２は携帯電話機１３を用いて前払金額とその支払方法（ここでは「クレジットカード」）とを携帯電話会社１０に送信する。
携帯電話会社１０は、利用者１２の利用状況に問題がなければ、予め登録されているクレジットカード番号に基づいて信販会社２０に承認を依頼する。信販会社２０は、承認できる場合はその旨を携帯電話会社１０に通知する。これに応じて、携帯電話会社１０は仮想口座１１０の前受残高を更新し、その最新の前受残高を携帯電話機１３に送信する。一方、承認できない場合は、信販会社２０はその旨を携帯電話会社１０に通知する。これに応じて、携帯電話会社１０は前受残高を更新することなく、クレジットカードによる支払いができない旨を利用者１２に通知する。
支払いを承認した場合、信販会社２０は、利用者１２が所望した前払金額を携帯電話会社１０の口座１９に振込む。次いで信販会社２０は、銀行１７に対して利用者１２の口座１６から前払金額を引落すように依頼する。これに応じて銀行１７は、利用者１２の口座１６から信販会社２０に資金を振替える。
２−３．デビットカードで支払う場合
図３は、前払金をデビットカードで支払う場合の資金移動を示す概略図である。この場合、図３に示すように、利用者１２は携帯電話機１３を用いて前払金額とその決済方法（ここでは「デビットカード」）とを携帯電話会社１０に送信する。
携帯電話会社１０は、利用者１２の利用状況に問題がなければ、予め登録されているデビットカード番号に基づいてそのデビットカードを発行した銀行１７に資金の振替えを依頼する。振替え依頼を承認した場合、銀行１７はその振替えデータをクリアリングセンター２１に送信するとともに、振替えの完了を携帯電話会社１０に通知する。これに応じて携帯電話会社１０は、前受残高を更新し、その最新の前受残高を携帯電話機１３に送信する。一方、銀行１７が振替え依頼を承認しない場合、振替えできない旨を携帯電話会社１０に通知する。これに応じて携帯電話会社１０は、前受残高を更新することなく、デビットカードで支払いできない旨を利用者１２に通知する。
クリアリングセンター２１は、銀行１７の他、多数の銀行から送信された振替えデータに基づいて振替えの相殺および集計を行ない、銀行間の決済尻データを決済銀行２２に送信する。これに応じて決済銀行２２は、銀行１７から加盟店銀行２３に資金を振替える。これに応じて加盟店銀行２３は、その資金を携帯電話会社１０の口座１９に入金する。
２−４．自動引落しで支払う場合
図４は、前受金を銀行口座から自動引落しで支払う場合の資金移動を示す概略図である。この場合、図４に示すように、利用者１２は携帯電話機１３を用いて前払金額とその支払方法（ここでは「自動引落」）とを携帯電話会社１０に送信する。携帯電話会社１０は、利用者１２の利用状況に問題がなければ、予め登録されている口座番号に基づいて銀行１７に資金の引落しを依頼する。引落しが可能な場合、銀行１７はその旨を携帯電話会社１０に通知する。これに応じて携帯電話会社１０は、前受残高を更新し、最新の前受残高を携帯電話機１３に送信する。引落しが不可能な場合、銀行１７はその旨を携帯電話会社１０に通知する。これに応じて携帯電話会社１０は、支払いできない旨を利用者１２に通知する。携帯電話会社１０から引落し依頼を受けた銀行１７は直ちに、利用者１２の口座１６から携帯電話会社１０の口座１９に資金を振替える。これとは別に、利用明細書１５は請求書１４と併せて利用者１２に送付される。
３．決済
次に、携帯電話機１３を使って上述した前払金で決済を行なう方法について説明する。
３−１．インターネット上の仮想店舗での決済
図５は、インターネット上の仮想店舗で携帯電話機を使って決済する方法を示す概略図である。図５に示すように、まず、利用者１２は携帯電話機１３またはパーソナルコンピュータ４０でインターネット上の仮想店舗２４に商品やサービスを注文し、その決済方法（ここでは「携帯電話決済」）を選択する。パーソナルコンピュータ４０を用いる場合、利用者１２は携帯電話機１３の電話番号をパーソナルコンピュータ４０に手で入力し、インターネット６０を通じて仮想店舗２４に送信する。
注文を受けた仮想店舗２４は、送信された携帯電話番号に基づいて携帯電話会社１０に決済金額の請求を依頼する。
請求依頼を受けた携帯電話会社１０は、利用者１２の利用状況に問題があれば本サービスが利用できない旨を仮想店舗２４に通知する。これに応じて仮想店舗２４は、本サービスが利用できない旨を利用者１２に通知する。利用者１２の利用状況に問題がなければ、携帯電話会社１０は予め登録されている利用者１２の電子メールアドレスに基づいて利用者１２の携帯電話機１３に電子メールで電子請求書を送信する。電子請求書は、仮想口座１１０からの支払いを利用者１２に確認するためのものである。
また、電子請求書を受取った利用者１２は、その決済を承認するか否かを選択する。利用者１２が決済を承認した場合、電子請求書を受信した携帯電話機１３は、前払残高を検証し、前払残高が決済金額を下回っている場合、携帯電話機１３は残高不足として決済ができない旨を携帯電話会社１０に通知する。これに応じて携帯電話会社１０は、残高が不足しているから決済できない旨を仮想店舖２４を通じて利用者１２に通知する。利用者１２が決済を取消しまたは拒否した場合、決済取消しまたは決済拒否を携帯電話会社１０に通知する。これに応じて携帯電話会社１０は、決済が取消しまたは拒否されたから決済できない旨を仮想店舗２４に通知する。これに応じて仮想店舗２４は、決済できない旨を利用者１２に通知する。
また、利用者１２が決済を承認した場合において、前払残高の検証の結果、決済金額が前払残高以内のとき、その決済を了承する旨を携帯電話会社１０に通知する。このとき、予め携帯電話会社１０に登録されているパスワード、携帯電話番号、キーコードなどを併せて送信する。携帯電話会社１０は、送信された携帯電話番号に基づいて個人情報データベース１１を検索し、送信されたパスワードおよびキーコードが予め登録されているパスワードおよびキーコードとそれぞれ一致するか否かを判別する。キーコードが一致しない場合、携帯電話会社１０はキーコードが異常であるから本サービスを利用できない旨を利用者１２に通知するとともに、決済できない旨を仮想店舗２４を通じて利用者１２に通知する。両者とも一致する場合、携帯電話会社１０は仮想口座１１０の前受残高から決済金額を減算して前受残高を更新するとともに、その更新した前受残高を携帯電話機１３に送信する。これに応じて携帯電話機１３は内部の前受残高を更新する。また、携帯電話会社１０は決済完了を仮想店舗２４に通知する。これに応じて仮想店舗２４は決済完了を利用者１２に通知する。
その後、仮想店舗２４は注文を受けた商品を利用者１２に届けたり、注文を受けたサービスを利用者１２に提供する。携帯電話会社１０は、上記決済金額を仮想店舗２４に入金する。仮想店舗２４は、本サービスを利用した手数料を携帯電話会社１０に支払う。
３−２．実在店舗での決済
図６は、実在店舗で携帯電話機を使って決済する方法を示す概略図である。図６に示すように、実在店舗において、利用者１２は携帯電話機１３をＰＯＳ端末２７に接続された読取装置２７０にセットする。店員は商品の金額をＰＯＳ端末２７に打ち込み、決済金額を計算する。この決済金額はＰＯＳ端末２７から読取装置２７０を通じて携帯電話機１３に送信される。携帯電話機１３は、内部に記憶されている残高と決済金額とを比較し、決済が不可能であればエラーをＰＯＳ端末２７に送信する。一方、決済が可能であれば、携帯電話機１３は携帯電話番号とキーコードとをＰＯＳ端末２７に送信する。携帯電話番号は、ＰＯＳ端末２７に手で直接入力することはできない。
携帯電話番号とキーコードとを受信したＰＯＳ端末２７は決済を完了して、その旨を携帯電話機１３に通知する。決済完了を受けて、携帯電話機１３はその決済金額を内部メモリに記憶し、決済モードがオフになる。その後、利用者１２は携帯電話機１３を読取装置２７０から取り除く。
次に、決済金額とともに携帯電話番号およびキーコードを携帯電話会社１０に送信する。これに応じて携帯電話会社１０は、仮想口座１１０の前受残高から決済金額を減算して前受残高を更新するとともに、決済完了をＰＯＳ端末２７に通知する。
４．ハードウェア構成
図７は、携帯電話機１３、および携帯電話会社１０に設置されるサーバコンピュータ（以下、単にサーバという）３０のハードウェア構成を示すブロック図である。
図７に示すように、携帯電話機１３は、ＣＰＵからなるデータ処理部１３１と、ＲＡＭ１３２と、ＥＥＰＲＯＭのようなＲＯＭ１３３と、アンテナ１３４と、送受信部１３５と、テンキーやカーソルキーのような入力装置１３６と、液晶ディスプレイのような表示装置１３７と、バッテリ１３８と、インターフェイス（Ｉ／Ｆ）部１３９とを備える。この携帯電話機１３は電源アダプタ１４０に装着され、電源アダプタ１４０からＩ／Ｆ部１３９を通じてバッテリ１３８に電流が供給され、バッテリ１３８が充電される。データ処理部１３１は、ＲＡＭ１３２、ＲＯＭ１３３、送受信部１３５、入力装置１３６、表示装置１３７およびＩ／Ｆ部１３９を用いて通常の携帯電話機能を実行する他、後述する決済機能を実行する。
携帯電話会社１０に設置されているサーバ３０は、ＣＰＵからなるデータ処理部３０１と、データベース３０２とを備える。データベース３０２は、個人情報データベース１１と、利用履歴データベース２８と、決済履歴データベース２９とを含む。データ処理部３０１はデータベース３０２を用いて後述する決済機能を実行する。データ処理部３０１は無線基地局３０３に接続されている。無線基地局３０３のアンテナ３０４と携帯電話機１３のアンテナ１３４との間で電波が送受信される。利用履歴データベース２８は、携帯電話機１３とのデータの取引内容を記録するためのログファイルである。具体的には、仮想口座１１０の入出金日時、入出金額、残高などが記録される。決済履歴データベース２９は、店舗とのデータの取引内容を記録するためのログファイルである。具体的には、決済日時、決済金額などが記録される。
５．前払い時の処理動作
５−１．通話料と併せて支払う場合
図８は、図１に示した前払金を通話料と併せて支払う場合における携帯電話機１３およびサーバ３０の動作を示すフローチャートである。図９は、この場合に携帯電話機１３の表示装置１３７に表示される表示画面の遷移図である。
まず、携帯電話機１３のデータ処理部１３１は、表示装置１３７上に図９に示した画面Ｄ１を表示し、利用者１２に対してパスワードの入力を促す。利用者１２が入力装置１３６を操作してパスワードを入力すると、入力装置１３６はその入力されたパスワードをデータ処理部１３１に与える（Ｓ１０１）。
続いて、データ処理部１３１はその入力されたパスワードをＲＡＭ１３２またはＲＯＭ１３３に予め登録されているパスワードと比較することにより入力されたパスワードの検証を行なう（Ｓ１０２）。入力されたパスワードが誤っている場合、データ処理部１３１は表示装置１３７上に図９に示した画面Ｄ２を表示する（Ｓ１０３）。一方、入力されたパスワードが正しい場合、データ処理部１３１は表示装置１３７上に図９にした画面Ｄ３を表示し、利用者１２に対し、「▲１▼お金を払う」、「▲２▼お財布の中を見る」、「▲３▼お財布にお金を入れる」の中から１つを選択するよう促す。利用者１２が入力装置１３６を操作し、「▲３▼お財布にお金を入れる」を選択すると、データ処理部１３１は表示装置１３７上に画面Ｄ４を表示し、利用者１２に対して前払金額の入力を促す。このとき、未通知データ（詳細は後述する）がない場合はＲＡＭ１３２に記憶されている前払残高を現在の残高として表示し、未通知データがある場合はＲＡＭ１３２に記憶されている前払残高から未通知の決済金額を減算して真の前払残高を計算し、それを現在の残高として表示する。利用者１２が入力装置１３６を操作して所望の前払金額を入力すると、入力装置１３６がその入力された前払金額をデータ処理部１３１に与える（Ｓ１０４）。
続いて、データ処理部１３１は表示装置１３７上に画面Ｄ５を表示し、利用者１２に対して前払金額の支払方法を選択するよう促す。利用者１２が入力装置１３６を操作すると、「通話料に加算」という支払方法の他、「クレジット」、「デビットカード」、「自動引落」といういくつかの支払方法が表示される。ここでは利用者１２が「通話料に加算」という支払方法を選択するものとする。これに応じて、入力装置１３６は「通話料に加算」という支払方法の選択をデータ処理部１３１に与える（Ｓ１０５）。
続いて、データ処理部１３１は選択された支払方法および入力された前払金額を送受信部１３５に与え、送受信部１３５はこれらを携帯電話会社１０に送信する（Ｓ１０６）。このとき、ＲＯＭ１３３に予め記憶されている利用者１２に固有の携帯電話番号と、ＲＯＭ１３３に予め記憶されている携帯電話機１３に固有のキーコードと、ＲＡＭ１３２に記憶されている未通知データとを併せて送信する。携帯電話番号は、携帯電話会社１０が携帯電話機１３を販売する際にＥＥＰＲＯＭのようなＲＯＭ１３３に予めプログラムする。キーコードは、携帯電話機メーカが携帯電話機を製造する際に製造番号や各携帯電話機固有の管理番号（サブスクライバＩＤ（識別子）、機体ＩＤ、端末ＩＤなどと呼ばれる）などをＥＥＰＲＯＭのようなＲＯＭ１３３に予めプログラムする。したがって、携帯電話番号は利用者１２に固有のもので、携帯電話機１３を買い換えた場合でも同じ携帯電話番号を登録することができる。ただし、利用者１２自身は携帯電話番号を書き換えることはできず、利用者１２の依頼に応じて携帯電話会社１０が書き換えることになる。これに対し、キーコードは携帯電話機１３に固有のものである。キーコードに製造番号を用いた場合、利用者１２はもちろん、携帯電話会社１０さえも書き換えることができない。キーコードに上述したサブスクライバＩＤのような管理番号を用いた場合、携帯電話会社１０は書き換えることができるが、利用者１２は書き換えることができない。
続いて、データ処理部１３１はこれまでの処理が正常に終了したか否かを判別し（Ｓ１０７）、正常に終了していない場合はその旨を表示装置１３７に表示し（Ｓ１０８）、接続を切断する（Ｓ１０９）。一方、正常に終了した場合は異常終了の表示をすることなく接続を一旦切断する（Ｓ１０９）。
一方、携帯電話会社１０に設置されているサーバ３０において、データ処理部３０１は、携帯電話機１３から送信された前払金額、支払方法、携帯電話番号およびキーコードを無線基地局３０３を通じて受信する（Ｓ２０１）。
続いて、データ処理部３０１は受信した携帯電話番号に基づいて個人情報データベース１１を検索する（Ｓ２０２）。
続いて、データ処理部３０１は受信したキーコードを検索した個人情報データベース１１のキーコードと比較し、キーコードが一致するか否か確認する（Ｓ２０３）。キーコードが一致した場合、データ処理部３０１は個人情報データベース１１の利用状況を確認し、問題があるか否か判別する（Ｓ２０４）。上記ステップＳ２０２でキーコードが一致しない場合、またはこのステップＳ２０４で利用状況に問題がある場合、データ処理部３０１は本サービス利用不可の情報を携帯電話機１３に送信する（Ｓ２０５）。
携帯電話機１３においては、送受信部１３５が携帯電話機１３から送信された本サービス利用不可能の情報を受信する（Ｓ１１０）
続いて、データ処理部１３１は図９に示した画面Ｄ６を表示装置１３７上に表示し、本サービスを利用できない旨を利用者１２に通知する（Ｓ１１１）。そして、データ処理部１３１は表示装置１３７上に異常に終了した旨を表示する（Ｓ１１２）。
一方、上記ステップＳ２０４で利用状況に問題がなければ、利用履歴データベース２８を更新する（Ｓ２０６）。具体的には、現在の日時と、今回の前受金額（利用者１２にとっては前払金額）と、現在の前受残高と、未通知データ（未通知の決済金額）とを利用履歴データベース２８に記録する。
続いて、データ処理部３０１は現在の前受残高を携帯電話機１３に送信する（Ｓ２０７）。
続いて、データ処理部３０１はこの前受金額について請求データを作成する（Ｓ２０８）。
続いて、データ処理部３０１は作成した請求データを毎月一括して通話料に加算し、図１に示すように請求書１４とともに本サービスの利用明細書１５を発行する。
以降の処理は既存の処理と同じで、利用者１２の個人情報データベース１１に登録されている口座番号に基づき利用者１２の取引銀行１７に対して料金の引落しを依頼する（Ｓ２０９）。これに応じて、本サービスの利用料金が通話料と併せて利用者の口座１６から携帯電話会社の口座１９に振替えられる。
携帯電話機１３においては、上記ステップＳ２０７でサーバ３０から送信された前受残高を送受信部１３５が受信する（Ｓ１１３）。
続いて、データ処理部１３１は受信した前受残高を前払残高としてＲＡＭ１３２に格納し、これにより前受残高を更新する（Ｓ１１６）。
続いて、データ処理部１３１は図９に示した画面Ｄ７を表示装置１３７に表示する（Ｓ１１７）。具体的には、これまでの前払処理が完了した旨と現在の前払残高とを表示する。
５−２．クレジットカードで支払う場合
図１０は、図２に示した前払金額をクレジットカードで支払う場合における携帯電話機１３およびサーバ３０の動作を示すフローチャートである。図１１は、この場合に携帯電話機１３の表示装置１３７に表示される画面の遷移図である。
上記と異なり前払金額をクレジットカードで支払う場合は、図１１に示した画面Ｄ５で利用者１２は「クレジット（一括）」を選択する。これに応じて、入力装置１３６はクレジットカードによる支払いという支払方法の選択をデータ処理部１３１に与える（図１０，Ｓ１０５）。
また、携帯電話会社１０のサーバ３０においては、利用状況に問題がない場合、個人情報データベース１１に予め登録されているクレジットカード番号に基づいて信販会社２０に利用者１２の与信照会を行なう（Ｓ２１０）。
続いて、データ処理部３０１は信販会社２０からの返信に基づいて信販会社２０がクレジットカードによる支払いを承認したか否かを判別する（Ｓ２１１）。
非承認の場合、データ処理部３０１は支払できない旨を携帯電話機１３に送信する（Ｓ２１２）。承認の場合は、利用履歴データベース２８を更新する（Ｓ２０５）。
一方、携帯電話機１３においては、送受信部１３５がサーバ３０からクレジットカードによる支払いは不可能な旨を受信した場合、図１２に示した画面Ｄ８を表示装置１３７に表示し、クレジットカードによる支払いが不可能な旨を利用者１２に通知する（Ｓ１２０）。
５−３．デビットカードで支払う場合
図１２は、前払金額をデビットカードで支払う場合の携帯電話機１３およびサーバ３０の動作を示すフローチャートである。図１３は、この場合に携帯電話機１３の表示装置１３７に表示される画面の遷移図である。
上記と異なり前払金額をデビットカードで支払う場合、図１３に示した表示画面Ｄ５において利用者１２は「デビットカード」を選択する。これに応じて、入力装置１３６はその選択情報をデータ処理部１３１に与える（Ｓ１０５）。
一方、携帯電話会社１０のサーバ３０においては、利用状況に問題がない場合、データ処理部３０１は個人情報データベース１１に予め登録されているデビットカード番号に基づいてそのデビットカードの発行銀行１７に引落し（承認）依頼を送信する（Ｓ２２０）。これに応じて、既存のデビットカード処理が実行される（Ｓ２２１）。
続いて、データ処理部３０１はデビットカードの発行銀行１７から送信された振替え結果に基づいて振替えが完了したか否かを判別する（Ｓ２２２）。振替えができなかった場合、データ処理部３０１はその旨を携帯電話機１３に送信する（Ｓ２１２）。
これに応じて携帯電話機１３のデータ処理部１３１は、図１３に示した画面Ｄ９を表示装置１３７に表示し（Ｓ１２０）、デビットカードによる支払いができない旨を利用者１２に通知する。
５−４．自動引落で即時支払う場合
図１４は、図４に示した前払金額を利用者の口座１６から自動的に引落す場合における携帯電話機１３およびサーバ３０の動作を示すフローチャートである。図１５は、この場合に携帯電話機１３の表示装置１３７に表示される画面の遷移図である。
上記と異なり自動引落しの場合、図１５に示した画面Ｄ５で利用者１２は「自動引落」を選択し、この利用者１２の操作に応じて入力装置１３６はデータ処理部１３１にその選択情報を与える（Ｓ１０５）。
一方、サーバ３０においては、利用状況に問題がない場合、データ処理部３０１は受信した前払金額が引落し可能か否かを利用者１２の取引銀行１７に照会する（Ｓ２３０）。
続いて、データ処理部３０１は銀行１７から返信された照会結果に基づいて引落しが可能か否かを判別する（Ｓ２３１）。引落しが不可能な場合、データ処理部３０１はその旨を携帯電話機１３に送信する（Ｓ２３２）。
これに応じて携帯電話機１３のデータ処理部１３１は、図１５に示した画面Ｄ１０を表示し（Ｓ１２０）、利用者の口座１６からは所望の前払金額を引落すことができない旨を利用者１２に通知する。
一方、引落しが可能な場合、携帯電話会社１０は既存の方法で銀行１７に引落しを依頼する（Ｓ２２３）。
６．決済時の処理動作
次に、携帯電話機１３を用いてインターネット上の仮想店舗および実在店舗で決済を行なう場合の動作について説明する。
６−１．仮想店舗で決済する場合
図１６は、仮想店舗で決済を行なう場合に用いられる利用者のパーソナルコンピュータ（ＰＣ）４０および携帯電話機１３、携帯電話会社のサーバ３０、ならびに仮想店舗のサーバコンピュータ（以下、単にサーバという）５０のハードウェア構成を示すブロック図である。
図１６に示すように、利用者１２のパーソナルコンピュータ４０は、ＣＰＵのようなデータ処理部４０１と、ＲＯＭやＲＡＭのようなメモリ４０２と、ハードディスク（ＨＤ）４０３と、モデム４０４と、キーボードやマウスのような入力装置４０５と、ＣＲＴディスプレイや液晶ディスプレイのような表示装置４０６とを備える。仮想店舗２４のサーバ５０も同様に、データ処理部５０１と、メモリ５０２と、ハードディスク５０３と、モデム５０４と、入力装置５０５と、表示装置５０６とを備える。パーソナルコンピュータ４０はモデム４０４を通じてインターネット６０に接続される。サーバ５０もモデム５０４を通じてインターネット６０に接続される。携帯電話会社１０のサーバ３０もモデム３０３を通じてインターネット６０に接続される。
図１７および図１８は、図１６に示したパーソナルコンピュータ４０、携帯電話機１３、サーバ３０および５０の動作を示すフローチャートである。
利用者１２はパーソナルコンピュータ４０の入力装置４０５を操作して仮想店舗２４に商品やサービスの注文を行ない、その決済方法として携帯電話決済を選択する。これに応じて、パーソナルコンピュータ４０のデータ処理部４０１は入力された注文情報および携帯電話番号をインターネット６０を通じて仮想店舗２４のサーバ５０に送信する（Ｓ３０１）。
サーバ５０のデータ処理部５０１は、送信された注文情報および携帯電話番号を受信する（Ｓ６０１）。
続いて、データ処理部５０１は、店舗名、決済金額、携帯電話番号などの請求情報をインターネット６０を通じて携帯電話会社１０のサーバ３０に送信することにより、携帯電話会社１０に利用者１２の決済金額を請求する（Ｓ６０２）。
サーバ３０のデータ処理部３０１は、送信された請求情報を受信する（Ｓ５０１）。
続いて、データ処理部３０１は受信した携帯電話番号に基づいて個人情報データベース１１を検索する（Ｓ５０２）。
続いて、データ処理部３０１は検索した利用者１２の個人情報の中から利用状況を照会し、問題がないか否か確認する（Ｓ５０３）。問題がある場合、データ処理部３０１は本サービス利用不可の情報をサーバ５０に送信する。これにより、本サービスを利用できない旨を仮想店舖２４に通知する（Ｓ５０４）。一方、利用状況に問題がない場合、データ処理部３０１は検索した個人情報の中から利用者１２の電子メールアドレスを特定し、電子メールで請求データを携帯電話機１３に送信する（Ｓ５０５）。これは、携帯電話会社１０が仮想店舗２４に代わって利用者１２に請求書を発行することを意味する。利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０のサーバ３０から送信された請求データを受信する（Ｓ４０１）。
利用者１２が携帯電話機１３の入力装置１３６を操作して「受信メール一覧」を選択すると、携帯電話機１３のデータ処理部１３１は図１９に示した画面Ｄ１１を表示装置１３７上に表示する。利用者１２が入力装置１３６を操作して請求データの電子メールを選択すると、データ処理部１３１は画面Ｄ１２を表示装置１３７上に表示する。これは電子請求書であり、注文日、注文者（通常は利用者１２と同じ）、請求者（通常は仮想店舗２４と同じ）、請求額（通常は決済金額と同じ）が表示されている。
利用者１２が請求内容を確認し、同意できれば「支払」を選択し、同意できなければ「拒否」を選択する。携帯電話機１３の入力装置１３６はこのような利用者１２の操作に応じて選択情報をデータ処理部１３１に入力する。データ処理部１３１は入力された選択情報に基づいて決済が承認されたか否かを判別する（Ｓ４０２）。決済が承認されなかった場合、送受信部１３５は決済取消・拒否の情報を携帯電話機１０のサーバ３０に送信する（Ｓ４０３）。この場合、データ処理部１３１は、図１９に示した画面Ｄ１３を表示装置１３７上に表示する（Ｓ４０４）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された決済取消・拒否の情報を受信し（Ｓ５０６）、さらにその情報を仮想店舗２４のサーバ５０に送信する（Ｓ５０７）。
仮想店舗２４のサーバ５０においては、データ処理部５０１が携帯電話会社１０のサーバ３０から送信された決済取消・拒否の情報を受信する（Ｓ６０５）。
続いて、データ処理部５０１は受信した決済取消・拒否の情報をインターネット６０を通じて利用者１２のパーソナルコンピュータ４０に送信し、これにより仮想店舗２４は利用者１２に決済が取消しまたは拒否された旨を利用者１２に通知する（Ｓ６０６）。
利用者１２のパーソナルコンピュータ４０においては、データ処理部４０１が仮想店舗２４のサーバ５０から送信された決済取消・拒否の情報を受信し（Ｓ３０４）、決済が取消しまたは拒否された旨を表示装置４０６上に表示する。
上記ステップＳ４０２で決済が承認された場合、携帯電話機１３のデータ処理部１３１は、ＲＡＭ１３２内に未通知データ（電波圏外の店舗で決済したために携帯電話会社１０に未だ通知できていない決済日時、決済金額などで、その詳細は後述する。）が存在しないか否かを判別する（Ｓ４０５）。未通知データがある場合、データ処理部１３１は未通知の決済金額を合計して累計未通知金額を計算し（Ｓ４０６）、続いてＲＡＭ１３２に記憶されている前払残高から累計未通知金額を減算して現時点における真の前払金額を計算する（Ｓ４０７）。
上記ステップＳ４０５で未通知データがない場合、または上記ステップＳ４０７の後、データ処理部１３１は前払残高を検証し、決済金額が前受残高以内か否かを判別する（Ｓ４０８）。決済金額が前受残高を超えている場合、データ処理部１３１は図１９に示した画面Ｄ１４を表示装置１３７上に表示して残高不足を利用者１２に通知し（Ｓ４０９）、続いて残高不足の情報を電波で携帯電話会社１０のサーバ３０に送信する（Ｓ４１０）。
これに応じて携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された残高不足の情報を受信し（Ｓ５０８）、続いてこの残高不足の情報をインターネット６０を通じて仮想店舗２４のサーバ５０に送信する（Ｓ５０９）。
仮想店舗２４のサーバ５０においては、データ処理部５０１が携帯電話会社１０のサーバ３０から送信された残高不足の情報を受信し（Ｓ６０７）、続いてこの残高不足の情報をインターネット６０を通じて利用者１２のパーソナルコンピュータ４０に送信する（Ｓ６０８）。利用者１２のパーソナルコンピュータ４０はこの残高不足の情報を受信し、その旨を表示装置４０６上に表示する（Ｓ３０５）。
一方、携帯電話機１３において、上記ステップＳ４０８で決済金額が前払残高以内の場合、データ処理部１３１は図１９に示した画面Ｄ１を表示し、利用者１２にパスワードの入力を促す。利用者１２がパスワードを入力すると、入力装置１３６は入力されたパスワードをデータ処理部１３１に与える（Ｓ４１１）。
続いて、送受信部１３５は、決済承認の情報および未通知データを携帯電話会社１０のサーバ３０に電波で送信する（Ｓ４１２）。具体的には、携帯電話機１３の電話番号、ＲＯＭ１３３に予めハード的に登録されているキーコード、上記ステップＳ４１１で入力されたパスワード、未通知の決済金額を送信する。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された決済承認の情報を受信する（Ｓ５１０）。
続いて、データ処理部３０１は個人情報データベース１１を検索し、受信した携帯電話番号に基づいて利用者１２の個人情報を特定する。データ処理部３０１はさらに、受信したキーコードを利用者１２の個人情報として予め登録されているキーコードと比較し、キーコードが一致するか否かを判別する（Ｓ５１１）。キーコードが一致した場合、データ処理部３０１は、受信したパスワードを利用者１２の個人情報として予め登録されているパスワードと比較し、パスワードが一致するか否かを判別する（Ｓ５１２）。
キーコードが一致しない場合、またはパスワードが一致しない場合、データ処理部３０１は本サービス利用不可の情報を携帯電話機１３に電波で送信し、これにより携帯電話会社１０は利用者１２に本サービスが利用できない旨を通知する（Ｓ５１３）。
利用者の携帯電話機１３においては、送受信部１３５が携帯電話会社１０のサーバ３０から送信された本サービス利用不可の情報を受信する（Ｓ４１３）。
続いて、データ処理部１３１は本サービスが利用できない旨を表示装置１３７上に表示する（Ｓ４１４）。
続いて、データ処理部１３１は本サービス手続が異常に終了した旨を表示装置１３７上に表示する（Ｓ４１５）。
一方、携帯電話会社１０の携帯電話機１３において、データ処理部３０１は決済不可の情報をインターネット６０を通じて仮想店舗２４のサーバ５０に送信する（Ｓ５１４）。
仮想店舗２４のサーバ５０においては、データ処理部５０１が携帯電話会社１０のサーバ３０から送信された決済不可の情報を受信する（Ｓ６０９）。
これに応じて、データ処理部５０１は決済不可の情報をインターネット６０を通じて利用者１２のパーソナルコンピュータ４０に送信し、これにより仮想店舗２４は利用者１２に決済ができない旨を通知する（Ｓ６１０）。
利用者１２のパーソナルコンピュータ４０においては、データ処理部４０１が仮想店舗２１のサーバ５０から送信された決済不可の情報を受信し（Ｓ３０６）、決済ができない旨を表示装置４０６上に表示する。
一方、携帯電話会社１０のサーバ３０においては、上記ステップＳ５１２でパスワードが一致した場合、データ処理部３０１は利用履歴データベース２８を更新し、利用者１２の仮想口座１１０の前受残高を更新する（Ｓ５１５）。利用履歴データベース２８には具体的には、決済日時、決済金額などを記録する。
続いて、データ処理部３０１は更新した前受残高を電波で携帯電話機１３に送信する（Ｓ５１６）。
携帯電話機１３においては、データ処理部１３１が携帯電話会社１０のサーバ３０から送信された仮想口座１１０の前受残高を受信する（Ｓ４１６）。
続いて、データ処理部１３１は受信した仮想口座の前受残高と同じになるようにＲＡＭ１３２に記憶されている前払残高を更新し、さらにＲＡＭ１３２に記憶されている未通知データをクリアする（Ｓ４１７）。これにより、携帯電話機１３内の前払残高と携帯電話会社内の仮想口座１１０の前受残高とが同期する。
そして、データ処理部１３１は図１９に示した画面Ｄ１５を表示装置１３７上に表示し、決済が完了した旨を利用者１２に通知する。
携帯電話会社１０のサーバ３０においては、上記ステップＳ５１６の後、決済完了の情報をインターネット６０を通じて仮想店舗２４のサーバ５０に送信し、これにより携帯電話会社１０は決済が完了した旨を仮想店舗２４に通知する（Ｓ５１７）。そして、携帯電話会社１０は既存の方法で仮想店舗２４に決済金額を支払う（Ｓ５１８）。
一方、仮想店舗２４のサーバ５０においては、データ処理部５０１は携帯電話会社１０のサーバ３０から送信された決済完了の情報を受信する（Ｓ６１１）。
続いて、データ処理部５０１は受注明細および決済完了の情報をインターネット６０を通じて利用者１２のパーソナルコンピュータ４０に送信する（Ｓ６１２）。
利用者１２のパーソナルコンピュータ４０においては、データ処理部４０１が仮想店舗２４のサーバ５０から送信された受注明細および決済完了の情報を受信する（Ｓ３０７）。
６−２．実在店舗で決済する場合
図２０は、実在店舖で決済する場合に用いられる携帯電話機１３、ＰＯＳ端末３７およびサーバ３０のハードウェア構成を示すブロック図である。
図２０に示すように、ＰＯＳ端末２７も同様に、データ処理部２７１と、ＲＡＭ２７２と、ハードディスク２７３と、入力装置２７４と、表示装置２７５と、インターフェイス（Ｉ／Ｆ）部２７６とを備える。決済時に携帯電話機１３がセットされる読取装置２７０はインターフェイス２７６に接続される。商品バーコードを読取るためのスキャナもインターフェイス部２７６に接続される。現金引出し部２７８もインターフェイス部２７６に接続される。
図２１および図２２は、図６に示したように実在店舗で決済する場合における携帯電話機１３、ＰＯＳ端末２７およびサーバ３０の動作を示すフローチャートである。
まず利用者１２は実在店舗２６で買物する前に、図２３に示した画面Ｄ１で携帯電話機１３の入力装置１３６を操作してパスワードを入力し、これに応じて入力装置１３６は入力されたパスワードをデータ処理部１３１に与える（Ｓ７０１）。
続いて、データ処理部１３１は入力されたパスワードを、図２４に示すようにＲＡＭ１３２に予め登録されているパスワードと比較し、パスワードの検証を行なう（Ｓ７０２）。パスワードが一致しない場合、データ処理部１３１は図２３に示した画面Ｄ２を表示装置１３７上に表示する（Ｓ７０３）。
一方、パスワードが一致した場合、データ処理部１３１は図２３に示したメニュー画面Ｄ３を表示する。利用者１２が「▲１▼お金を払う」を選択すると、データ処理部１３１は未通知データがあるか否かを判別する（Ｓ７０４）。未通知データは、電波圏外の店舗で決済した場合に、その決済金額、決済日時、決済店舗なｄが図２４に示すようにＲＡＭ１３２に累積的に格納されたものである。未通知データがある場合、データ処理部１３１は電波圏内か否かを判別し（Ｓ７０５）、電波圏内の場合、送受信部１３５は電波で携帯電話会社１０のサーバ３０に未通知データを図２４に示すようにＲＯＭ１３３に予め登録されたキーコードとともに送信する（Ｓ７０６）。電波圏外の場合、ＲＡＭ１３２に記憶されている未通知の決済金額を合計して累計未通知金額を計算し（Ｓ７０７）、続いてＲＡＭ１３２に記憶されている前払残高からその累計未通知金額を減算し、現在の真の前払残高を計算する（Ｓ７０８）。携帯電話機１３内の前払残高は、携帯電話会社１０から仮想口座１１０の前受残高が送信されて来ない限り更新されない。したがって、電波圏外の実在店舗で連続して携帯電話機１３で決済を行なった場合などは、その各決済金額を未通知データとしてＲＡＭ１３２に記憶しておく。
一方、携帯電話会社１０のサーバ３０においては、上記ステップＳ７０６で利用者１２の携帯電話機１３から送信された未通知データをデータ処理部３０１が受信する（Ｓ９０１）。
続いて、データ処理部３０１は、携帯電話機１３から送信されたキーコードを、個人情報データベース１１に予め登録されているキーコードと比較し、キーコードが一致するか否かを確認する（Ｓ９０２）。キーコードが一致しない場合、データ処理部３０１は本サービス利用不可の情報を携帯電話機１３に電波で送信し、これにより携帯電話会社１０は利用者１２に本サービスが利用できない旨を通知する（Ｓ９０３）。キーコードが一致する場合、データ処理部３０１は受信した未通知データに基づいて利用履歴データベース２８を更新し、仮想口座１１０の前受残高を更新する（Ｓ９０４）。続いて、データ処理部３０１は更新した最新の前受残高を携帯端末機１３に送信する（Ｓ９０５）。
携帯電話機１３においては、上記ステップＳ９０３で携帯電話会社１０のサーバ３０から送信された本サービス利用不可の情報を送受信部１３５が受信する（Ｓ７０９）。続いて、データ処理部１３１は本サービスが利用できない旨を表示装置１３７上に表示し（Ｓ７１０）、さらに本サービス手続が異常に終了した旨を表示装置１３７上に表示する（Ｓ７１１）。
また、上記ステップＳ９０５で携帯電話会社１０のサーバ３０から送信された前受残高を送受信部１３５が受信する（Ｓ７１２）。続いて、データ処理部１３１は受信した前受残高と同じになるようにＲＡＭ１３２に記憶されている前払残高を更新し、さらに未通知データをクリアする（Ｓ７１３）。
上記ステップＳ７０４で未通知データがない場合、または上記ステップＳ７０８もしくはＳ７１３の後、データ処理部１０３は図２３に示した画面Ｄ１６のように現在利用可能な残高を表示する（Ｓ７１４）。
続いて、携帯電話機１３の決済モードがオンになり、データ処理部１３１は図２３に示した画面Ｄ１７を表示装置１３７上に表示する（Ｓ７１５）。
続いて、利用者１２は携帯電話機１３を読取装置２７０にセットする（Ｓ７１６）。これにより、データ処理部１３１は図２３に示した画面Ｄ１８を表示装置１３７上に表示する。このとき、実在店舗のＰＯＳ端末２７においては、データ処理部２７１が読取装置２８を通じて携帯電話機１３に決済金額を送信する（Ｓ８０１）。
携帯電話機１３においては、データ処理部１３１はＰＯＳ端末２７から送信された決済金額を受信する（Ｓ７１７）。
続いて、データ処理部１３１は受信した決済金額が現在の残高内か否かを判別する（Ｓ７１８）。決済金額が残高を超えている場合、データ処理部１３１は図２３に示した画面Ｄ１９を表示装置１３７上に表示し、残高不足を利用者１２に通知する（Ｓ７１９）。
決済金額が残高内の場合、データ処理部１３１は携帯電話機１３の電話番号およびＲＯＭ１３３に予めハード的に登録されているキーコードを読取装置２８を通じてＰＯＳ端末２７に送信する（Ｓ７２０）。
ＰＯＳ端末２７においては、データ処理部２７１が携帯端末機１３から送信された携帯電話番号およびキーコードを受信する（Ｓ８０２）。
続いて、データ処理部２７１は受信した携帯電話番号およびキーコードならびに決済内容をハードディスク２７３に記録する（Ｓ８０３）。
続いて、データ処理部２７１は決済完了の情報を読取装置２７０を通じて携帯電話機１３に送信する（Ｓ８０４）。
携帯電話機１３においては、データ処理部１３１がＰＯＳ端末２７から送信された決済完了の情報を受信し、取引完了を確認する（Ｓ７２１）。
続いて、データ処理部１３１はこのときの決済金額などを含む決済内容を未通知データとしてＲＡＭ１３２に記憶する（Ｓ７２２）。
上記ステップＳ７１６〜Ｓ７２２の間、データ処理部１３１は図２３に示した画面Ｄ１８を表示装置１３７上に表示する。また、携帯電話機１３が途中で読取装置２７０から取外された場合は異常終了となる。上記ステップＳ７２２で決済内容をＲＡＭ１３２に記憶した後、データ処理部１３１は図２３に示した画面Ｄ２０を表示装置１３７上に表示する。そして、上記決済モードはオフになる（Ｓ７２３）。
続いて、データ処理部１３１は電波圏内か否かを判別し（Ｓ７２４）、電波圏内の場合、ＲＡＭ１３２に蓄積されている未通知データをＲＯＭ１３３にプログラムされているキーコードとともに携帯電話会社１０のサーバ３０に送信する（Ｓ７２５）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された未通知データをキーコードとともに受信する（Ｓ９０９）。
続いて、データ処理部３０１は、携帯電話機１３から送信されたキーコードを、個人情報データベース１１に予め登録されているキーコードと比較し、キーコードが一致するか否かを確認する（Ｓ９１０）。キーコードが一致しない場合、データ処理部３０１は本サービス利用不可の情報を携帯電話機１３に電波で送信する（Ｓ９１１）。携帯電話機１３は、この情報を受信し（Ｓ７２６）、続いて本サービスが利用できない旨を表示装置１３７上に表示し（Ｓ７２７）、そして本サービス手続が異常に終了した旨を表示装置１３７上に表示する（Ｓ７２８）。
上記ステップＳ９１０でキーコードが一致する場合、データ処理部３０１は受信した未通知データに基づいて利用履歴データベース２８を更新し、仮想口座１１０の前受残高を更新する（Ｓ９１２）。
続いて、データ処理部３０１は最新の前受残高を携帯電話機１３に送信する（Ｓ９１３）。
携帯電話機１３においては、携帯電話会社１０のサーバ３０から送信された前受残高を受信し、この受信した前受残高と同じになるようにＲＡＭ１３２に記憶されている前払残高を更新し、さらに未通知データをクリアする（Ｓ７２９）。
一方、実在店舗２６のＰＯＳ端末２７においては、データ処理部２７１が上記決済内容を携帯電話会社１０のサーバ３０に送信する（Ｓ８０５）。決済内容の送信は取引ごと、つまりリアルタイムで行なうのが望ましいが、営業終了後に一括してバッチ処理で行なってもよい。
携帯電話会社１０のサーバ３０においては、データ処理部３０１はＰＯＳ端末２７から送信された決済内容を受信する（Ｓ９０６）。
続いて、データ処理部３０１は決済完了の情報をＰＯＳ端末２７に送信する（Ｓ９０７）。そして、携帯電話会社１０は決済内容に基づいて実在店舗２６に対して支払処理を行なう（Ｓ９０８）。
ＰＯＳ端末２７においては、データ処理部２７１が携帯電話会社１０のサーバ３０から送信された決済完了の情報を受信する（Ｓ８０６）。
上記第１の実施の形態ではＰＯＳ端末２７から決済金額を携帯電話機１３に送信し、携帯電話機１３が決済の可否を判定しているが、携帯電話機１３から仮想口座の残高をＰＯＳ端末２７に送信し、ＰＯＳ端末２７が決済の可否を判定するようにしてもよい。また、上記第１の実施の形態では携帯電話機１３を読取装置２７０を用いてＰＯＳ端末２７に電気的に接続しているが、近距離無線（たとえばブルートゥース（Ｂｌｕｅｔｏｏｔｈ））、無線ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）またはＩｒＤＡ（ＩｎｆｒａｒｅｄＤａｔａＡｓｓｏｃｉａｔｉｏｎ）で接続したり、あるいはバーコードリーダを用いて光学的に接続してもよい。バーコードリーダを用いる場合、携帯電話機１３からＰＯＳ端末２７に送信するデータをバーコードで表示装置１３７に表示し、これをバーコードリーダで読取るようにすればよい。これらの変更は後述する実施の形態でも適用可能である。
７．本サービスの利点
７−１．クレジットカード番号、キャッシュカード番号、口座番号がインターネット上に流れない。
クレジットによる決済の場合、クレジットカード番号さえあれば決済可能な場合があり、特にインターネット上の決済においては、利用者はクレジットカード番号を入力することに強い不安と抵抗を感じることになり、事実、第三者にクレジットカード番号を知られると決済されてしまう危険性や、店頭においてもカード番号が盗まれる危険性は否定できない。しかしながら、この実施の形態ではインターネット上に流れる決済取引データにクレジットカード番号は含まれておらず、携帯電話番号がその役目を果たすものである。また、携帯電話番号はその利用目的上、広く第三者に知られているが、第三者が他人の携帯電話番号のみを知っていても携帯電話機そのものを持っていないと、実在店舗でもインターネット上の仮想店舗でも決済を完了できないうえ、決済限度額が仮想口座内の残高に限定されるため、安全性は高い。
７−２．決済の際に信用照会および承認が不要である。
利用者が携帯電話会社の仮想口座に資金を預ける（前払）する際に、その支払方法ごとに必要とされる信用照会および承認が行なわれるので、利用者がインターネット上の仮想店舗や実在店頭で決済するときには、決済金額が前払残高以内であるか否かを確認するだけでよい。現在、店頭決済時に必要とされている承認番号の取得や本人の署名などの手続が不要となる。
７−３．店頭決済時に電波を飛ばす必要がない（電波圏外でもよい）。
この実施の形態では、店頭決済時に携帯電話機から必ずしも電波を飛ばす必要はない。したがって、店頭決済を行なう場所が電波圏内であるかどうかを意識する必要がない。よって、電波圏外の多い都市圏の地下街やビル内部、地下鉄構内、地下に設置されている自動販売機や券売機などでも決済することが可能である。携帯電話機が電波圏外にあり、決済金額が携帯電話会社に未通知状態になっていても、携帯電話機の内部メモリに未通知金額が記憶された状態で残り、次回取引発生時には未通知データが必ず送信され、仮想口座の残高が携帯電話機と携帯電話会社との間で同期がとれている状態になってから次の決済処理に入る。
７−４．２４時間仮想口座への振替が可能である。
インターネット上の仮想店舖または実在店舗での決済時に仮想口座の残高が不足しても、原則としてその場で２４時間いつでも仮想口座への資金の振替（前払）をすることが可能であるので、時間を問わず買物ができる。
７−５．決済の際に与信枠や残高を意識する必要がない。
従来、店頭でクレジットカードによる決済をする際に利用限度額を超過するため、クレジットカードによる決済を拒否されることがあり、現金の持ち合せが十分でないときには決済そのものが不可能になることもある。そのため、複数のクレジットカードを使い分けている利用者も多く、かといって利用者が各社クレジットカードごとにその限度額を認識しておくことは現実的には困難である。これに対し、この実施の形態では利用者がいつでも携帯電話会社内の仮想口座に振替済である金額、つまり前払残高を携帯電話機で確認することが可能であり、その上その残高内であれば常に決済可能であることが保証されている。
７−６．利用者は、クレジットカードやデビットカードなどの既存決済手段を提供している売り手から提供されている各サービスプログラムを継続して利用可能である。
利用者は、クレジットカードなどの既存決済手段等を利用して携帯電話会社の仮想口座に資金を振込むことで、信販会社などが提供しているサービスを継続して受けることができる。
７−７．クレジットカードを持てない世代でも後払が可能である。
利用者が携帯電話会社内の仮想口座に「通話料に加算」という支払方法で資金の振替を指定する場合、実際に利用者の口座から資金が引落されるのは通話料金の引落し時点である。よって、クレジットカードを持てない世代でも通話料の引落し時に口座に資金があればよいことになり、クレジットカードのような「擬似翌月一括払」が可能となる。
７−８．宅配業者が提供する「代金引換え」において利用可能となれば、利用者は予め現金を準備しておく必要がなくなる。
宅配業者は、商品配達時に代金を回収する手段として、携帯電話機による決済を導入することにより、利用者は現金を予め用意する必要がなくなり、宅配業者は配達員に釣銭を持たせる必要が軽減する。店頭のＰＯＳ端末のように携帯電話会社のサーバと決済ごとにデータの送受信を行なわず、一括してその日の業務終了後に送信する方法や、その都度無線で送受信する方法等が考えられる。また、こういった移動先での決済を可能とする端末は、小規模店舗等でも流用可能であるうえ、導入が容易である。
７−９．銀行振込やコンビニエンスストアでの決済と比較して手数料が割安である。
携帯電話会社内の仮想口座への資金の振替を「通話料に加算」という支払方法で行なう場合、利用者は１００円〜２００円程度の月額使用料を支払う。少額決済を同じ月内に繰返し行なう場合等は、銀行振込みやコンビニエンスストアでの決済を利用する場合よりも利用者が負担する手数料が安く済むことになる。
７−１０．手数料負担が公平である。
現行のクレジットカードやデビットカードによる決済では、手数料を加盟店が負担しており、その課金方法では少額決済では売上利益を圧迫するため、クレジットカードやデビットカードによる決済を採用していない（加盟していない）店舗がある。一方、この実施の形態では携帯電話会社への資金振込みの際にクレジットカードやデビットカードを利用する場合、極端な少額を振替える例は少ないと想定され、必要に応じて携帯電話会社が資金振替の際の最低金額やその単位を予め設定することにより、携帯電話会社が負担する信販会社等に支払う手数料と収入金額のバランスを取ることが可能である。一方、携帯電話会社から加盟店へ資金を振替える際には、その振替金額の一定期間中の合計に対して手数料が計算され、課金される。つまり、利用者が決済するごとに、その決済金額に対して手数料が加盟店に課金される現状のクレジットカードやデビットカードによる決済方法とは違い、加盟店は携帯電話会社からその合計金額に対する手数料を課金されることになり、少額決済の多い店舗（企業）であっても導入しやすく、個々の取引決済金額の大小にかかわらず、手数料負担が公平である。つまり、従来の決済システムでは、少額決済が大半を占める店舗、企業（たとえばコンビニエンスストア）でも、利益率を圧迫されることがない。
７−１１．少額取引に適した決済システムである。
上記７−１０のとおり、手数料負担が公平であることから、少額決済が大半を占める店舗や企業（たとえばコンビニエンスストア）でも、売上利益を圧迫されることはない。また、クレジットカードやデビットカードによる決済方法を導入している店舗や企業でも、負担する手数料の売上金額に対する割合を考慮し、利用可能な最低決済金額（たとえば３０００円以上）が設けられていることが多いが、この実施の形態では手数料は一定期間中の合計決済金額に対して課金されるので、限度額設定の必要がない。
７−１２．携帯電話機に金銭的な価値を付加するものではない。
現在、進行中の電子マネー計画では携帯電話機に金銭情報そのものをダウンロードして利用することを目的としているが、この実施の形態では仮想口座から振込を実現するための道具として携帯電話機を使用するものであり、電子マネーを仮想口座に振込む資金として利用することも可能である。商取引に携帯電話会社および決済サイトを介在させることにより、その安全性と利便性を高めることが目的であり、携帯電話機に金銭価値を付加するものではない。したがって、電子マネーは紛失したら現金を紛失することと同じであるが、この実施の形態では携帯電話機を落としても金銭的価値が消失するものではない。
７−１３．端末の不正使用に対する安全性
紛失や盗難の際も携帯電話会社にサービス停止を依頼することが可能であり、サービス停止になるまでに店頭で悪用されたとしても、利用できる金額は仮想口座内の残高内である。また、本人が携帯電話機を所有しているにもかかわらず、その携帯電話番号がインターネット上で第三者に悪用された場合でも、他の決済手段では決済が完了するまでまたは利用明細書が届くまで本人が認識することが困難であるのに対し、この実施の形態では決済確認がすべて携帯電話機に送信されることから、決済が完了する前に本人が認識し、未然に防ぐことが可能である。なお、携帯電話機の利用契約者が本サービスの停止を携帯電話会社に申告している場合は、インターネット上での決済の場合は携帯電話機の利用状況の確認の際に、実在店舗での決済の場合は決済モードをオンにする際にサービスの利用不可として通知される。
７−１４．携帯電話機と携帯電話会社のサーバ間での取引の安全性が高い。
携帯電話機から携帯電話会社のサーバには携帯電話番号とキーコードとがペアで送信され、携帯電話会社はこの両者を用いて認証を行なっている。携帯電話番号は利用者に固有で、キーコードは携帯電話機に固有であるから、利用者１２の携帯電話番号を知っている第三者であっても、利用者１２自身の携帯電話機１３以外の携帯電話機を使って上述した取引を行なうことはできない。
７−１５．短時間で決済が完了する。
上記７−２のとおり、与信照会は前払い時に行ない、決済時には行なう必要がないので、決済にかかる時間は短い。この時間は、現在実在店舗で行なわれているクレジットカードやデビッドカードによる決済にかかる時間よりも短い。
［第２の実施の形態］
以上、本発明の実施の形態を説明したが、本発明はその他の形態でも実施可能なものである。たとえば上記実施の形態では携帯電話会社に仮想口座を設けているが、銀行のような金融機関に仮想口座を設けでもよく、要するに携帯電話機と直接または間接的に通信可能なサーバに仮想口座を設ければよい。以下、本発明の第２の実施の形態を上記第１の実施の形態との相違点を中心に説明する。
１．資金移動
図２５は、この発明の第２の実施の形態における資金移動を示す概略図である。図１に示した第１の実施の形態と異なり、この第２の実施の形態では図２５に示すように、利用者１２の仮想口座１１０が銀行などの金融機関７０のサーバコンピュータに設けられる。この仮想口座１１０には残高の他、実在口座番号、仮想口座番号、携帯電話会社、および携帯電話番号が記憶される。実在口座番号としては、利用者１２が金融機関７０に実際に開設している口座の番号が登録される。仮想口座番号としては、この仮想口座１１０を特定するための番号が登録される。携帯電話会社としては、利用者１２が契約している携帯電話会社１０の名称が登録される。携帯電話番号としては、利用者１２の携帯電話機１３の携帯電話番号が登録される。
金融機関７０には仮想口座１１０の他、利用者１２の実在口座７１０、仮想口座１１０の入出金履歴データベース７１２、および仮想口座１１０の決済履歴データベース７１４が設けられる。利用者１２の実在口座７１０には、実在口座番号および口座残高が記憶される。入出金履歴データベース７１２には、仮想口座１１０の口座番号と、仮想口座１１０の入出金の日付と、その入出金額とが記憶される。決済履歴データベース７１４には、仮想口座１１０の口座番号と、仮想口座１１０の入出金の日付と、決済金額と、携帯電話機１３にその時点での仮想口座残高を携帯電話機１３に通知したか否かを示す状態とが記憶される。一方、携帯電話会社１０のサーバコンピュータにおける個人情報データベース１１には利用者１２が取引している金融機関７０の名称が記憶される。
図２６は、資金移動に用いられる携帯電話機、携帯電話会社のサーバ、および金融機関のサーバのハードウェア構成を示すブロック図である。上記図７に示した第１の実施の形態と異なり、この第２の実施の形態では図２６に示すように携帯電話会社１０のサーバ３０のデータベース３０２には前受け履歴や決済履歴は記録されない。また、この個人情報データベース１１には仮想口座情報は記録されない。その代わり、金融機関７０のサーバ７２にはデータベース７０２が設けられ、このデータベース７０２に仮想口座情報１１０、仮想口座入出金履歴７１２、および仮想口座決済履歴７１４が記録される。サーバ７２のデータ処理部７０１はサーバ３０のデータ処理部３０１と通信し、データベース７０２を用いて決済処理を行なう。
図２７および図２８は、金融機関７０の仮想口座１１０に資金を振替える場合における携帯電話機１３、携帯電話会社のサーバ３０、および金融機関のサーバ７２の動作を示すフローチャートである。図２９は、この場合に携帯電話機１３に表示される画面の遷移図である。
図２７に示すようにこの第２の実施の形態では、ステップＳ１０４において、利用者１２は携帯電話機１３の入力装置１３６を操作して所望の振替金額を入力する。これにより、入力装置１３６はその入力された振替金額をデータ処理部１３１に与える。
続いて、携帯電話機１３の送受信部１３５は、携帯電話番号、キーコードおよび未通知データとともに、その入力された振替金額を携帯電話会社１０のサーバ３０に送信する。
携帯電話会社１０のサーバ３０においては、上記第１の実施の形態と同様に、受信した携帯電話番号およびキーコードを用いて認証を行なった後（Ｓ２０２，Ｓ２０３）、図２８に示すように利用者１２の取引銀行へ振替依頼を送信する（Ｓ２４０）。具体的には、利用者１２の個人情報データベース１１から利用者１２の取引銀行の名称（ここではＢ銀行）を読出し、Ｂ銀行のサーバ７２に利用者１２の携帯電話番号および振替金額を送信し、これにより利用者１２の実在口座７１０から仮想口座１１０にその送信した金額を振替えるよう依頼する。
金融機関７０のサーバ７２においては、データ処理部７０１が携帯電話会社１０から送信された上記振替依頼を受信する（Ｓ１０００）。
続いて、データ処理部７０１は利用者１２の実在口座７１０を参照して振替が可能か否かを判定する（Ｓ１００１）。依頼のあった振替金額が実在口座７１０の残高を超えている場合、データ処理部７０１は振替不可の情報を携帯電話会社１０のサーバ３０に送信する（Ｓ１００２）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が金融機関７０から送信された振替不可の情報を受信し（Ｓ２４１）、引続きこれを利用者１２の携帯電話機１３に送信する（Ｓ２４２）。
利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０から送信された振替不可の情報を受信する（Ｓ１４０）。
続いて、データ処理部１３１は表示装置１３７上に図２９に示した画面Ｄ２１を表示し（Ｓ１４１）、残高不足のために振替ができない旨を利用者１２に通知する。
続いて、データ処理部１３１は表示装置１３７上に異常終了を表示する（Ｓ１４２）。
上記ステップＳ１００１において依頼のあった振替金額が実在口座７１０の残高以内の場合、データ処理部７０１はその依頼のあった金額を実在口座７１０から仮想口座１１０に振替える（Ｓ１００４）。
続いて、データ処理部７０１は上記振替金額に基づいて入出金履歴データベース７１２を更新する（Ｓ１００５）。
続いて、上記ステップＳ１０００で受信した情報の中に未通知データがあるか否かをデータ処理部７０１が判別する（Ｓ１００５）。上記ステップＳ７０４で未通知データが存在し、上記ステップＳ１０６で携帯電話機１３から携帯電話会社１０に未通知データを送信し、さらに上記ステップＳ２４０で携帯電話会社１０から金融機関７０に未通知データを送信している場合、データ処理部７０１はその未通知データに基づいて決済履歴データベース７１４を更新する（Ｓ１００６）。未通知データが存在しない場合、データ処理部７０１は仮想口座１１０の残高を携帯電話会社１０に送信する（Ｓ１００７）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が金融機関７０から送信された仮想口座１１０の残高を受信し（Ｓ２４３）、引続きこれを利用者１２の携帯電話機１３に送信する（Ｓ２０７）。
携帯電話機１３においては、上記第１の実施の形態と同様に送受信部１３５が携帯電話会社１０から送信された仮想口座１１０の残高を受信し（Ｓ１１３）、データ処理部１３１がＲＡＭ１３２に記録されている仮想口座の残高を更新し（Ｓ１１４）、最後に表示装置１３７上に振替が完了した旨を表示する（Ｓ１１５）。ここで、未通知データが存在する場合はその未通知データをクリアする（Ｓ１４３）。
２．仮想店舗での決済
図３０は、この発明の第２の実施の形態による仮想店舗での決済を示す概略図である。図３０に示すように、ここではインターネット上の仮想店舗２４と金融機関７０との間に決済機関８０が設けられる。決済機関８０は本サービスが利用される度に決済情報８１０を蓄積し、蓄積した多数の決済情報８１０に基づいて仮想店舗２４に対して利用代金を一括して支払う。決済情報８１０には、銀行名として金融機関７０の名称、支払者名として利用者１２の氏名または名称、振替金額、仮想口座１１０の仮想口座番号、および支払先としてインターネット上の仮想店舗２４の名称が含まれている。
図３１は、仮想店舗での決済に用いられるパーソナルコンピュータ４０、携帯電話機１３、携帯電話会社１０のサーバ３０、金融機関７０のサーバ７２、決済機関８０のサーバ８２、および仮想店舗２４のサーバ５０のハードウェア構成を示すブロック図である。図３１に示すように、決済機関８０のサーバ８２には、データ処理部８０１と、データベース８０２とが設けられる。データベース８０２には決済情報８１０が蓄積される。データ処理部８０１はサーバ７２のデータ処理部７０１と通信し、データベース８０２に蓄積した決済情報８１０に従って仮想店舗２４に対して支払処理を行なう。
図３２〜図３４は、仮想店舗２４で決済を行なう場合におけるパーソナルコンピュータ４０、携帯電話機１３、携帯電話会社１０のサーバ３０、仮想店舗２４のサーバ５０、および金融機関７０のサーバ７２の動作を示すフローチャートである。ここでは説明を簡単にするために、決済機関８０のサーバ８２の動作を省略する。
図１７に示した第１の実施の形態と同様に、携帯電話会社１０のサーバ３０は仮想店舗２４からの請求データを携帯電話機１３に送信する（Ｓ５０５）。
携帯電話機１３においては、送受信部１３５がその請求データを受信する（Ｓ４０１）。
続いて、その電子メールで送られてきた電子請求書を開封する（Ｓ４２０）。
続いて、上記第１の実施の形態と同様に未通知データを処理した後（Ｓ４０５〜Ｓ４０７）、データ処理部１３１が表示装置１３７上に請求内容および利用可能残高（たとえば図３５に示した画面Ｄ２２またはＤ２３）を表示する（Ｓ４２１）。
続いて、データ処理部１３１は請求額が利用可能残高以内か否かを検証する（Ｓ４２２）。請求額が利用可能残高以内の場合、図３５の画面Ｄ２２のように「支払」のボタンが表示される。請求額が利用可能残高を超えている場合、図３５の画面Ｄ２３のように「お財布にお金を入れる」のボタンが表示される。
請求額が利用可能残高を超えている場合、データ処理部１３１は利用者１２の操作に応じて追加資金を振替えるか否かを判別する（Ｓ４２３）。追加資金を振替える場合は上述した資金振替を行ない（Ｓ４２４）、追加資金を振替えない場合はステップＳ４０３に移る。
上記ステップＳ４２２で請求額が利用可能残高以内の場合、上記第１の実施の形態と同様に利用者１２が決済を承認したか否かを判別する（Ｓ４０２）。
また、携帯電話会社１０のサーバ３０において、パスワードを確認した後（Ｓ５１２）、データ処理部３０１は金融機関７０に対して決済依頼の情報を送信するとともに、未通知データが存在する場合はその未通知データを送信する（Ｓ５２０）。
金融機関７０のサーバ７２においては、データ処理部７０１が携帯電話会社１０から送信された決済依頼の情報を受信する（Ｓ１１００）。
続いて、データ処理部７０１は受信した決済金額を利用者１２の仮想口座１１０から振替える（Ｓ１１０１）。未通知データを受信している場合、その未通知の決済金額も利用者１２の仮想口座１１０から振替える。ここでは、仮想店舗２４への決済金額の振替を決済機関８０に依頼する。決済機関８０は依頼のたびにその決済金額を仮想店舗２４に支払うのではなく、たとえば所定の月度単位で複数の決済金額をまとめて仮想店舗２４に支払う。このような決済機関８０は必ずしも必要なく、金融機関７０が決済金額を直接仮想店舖２４に支払うようにしてもよい。ただし、決済機関８０を設けた方が振替の度に発生する手数料を抑えることができる。
続いて、データ処理部７０１はその決済金額に基づいて入出金履歴データベース７１２を更新する。（Ｓ１１０２）。
続いて、データ処理部７０１はその決済金額に基づいて決済履歴データベース７１４を更新する。（Ｓ１１０３）。
続いて、データ処理部７０１は仮想口座１１０の残高を読出して携帯電話会社１０に送信する（Ｓ１１０４）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が金融機関７０から送信された仮想口座残高を受信し（Ｓ５２１）、引続きこれを利用者１２の携帯電話機１３に送信する（Ｓ５１６）。
３．実在店舗での決済
図３６は、この発明の第２の実施の形態による実在店舗での決済を示す概略図である。図３６に示すように、実在店舖で決済する場合も決済機関８０が金融機関７０からの振替依頼を一括して実在店舗２６に対して支払を行なう。
図３７は、実在店舗での決済に設けられる携帯電話機１３、ＰＯＳ端末２７、携帯電話会社１０のサーバ３０、金融機関７０のサーバ７２、および決済機関８０のサーバ８２のハードウェア構成を示すブロック図である。
図３７に示すように、決済機関８０のサーバ８２におけるデータ処理部８０１はサーバ７２のデータ処理部７０１と通信し、決済情報８１０に従って実在店舗２６に対する支払を行なう。
図３８〜図４０は、実在店舗で決済する場合における携帯電話機１３、ＰＯＳ端末２７、携帯電話会社１０のサーバ３０、および金融機関７０のサーバ７２の動作を示すフローチャートである。
上記図２１に示した第１の実施の形態と異なり、この第２の実施の形態では図３８に示したステップＳ７０７において、携帯電話機１３のデータ処理部１３１はＲＡＭ１３２に記録されている仮想口座残高からステップＳ７０７で計算した累計未通知金額を減算する。
また、携帯電話会社１０のサーバ３０において、ステップＳ９０２でキーコードの一致を確認した場合、データ処理部３０１は未通知データを金融機関７０のサーバ７２に送信する（Ｓ９２０）。
金融機関７０のサーバ７２においては、データ処理部７０１が携帯電話会社１０から送信された未通知データを受信する（Ｓ１２００）。
続いて、データ処理部７０１は受信した未通知データに基づいて決済履歴データベース７１４を更新する（Ｓ１２０１）。
続いて、データ処理部７０１は仮想口座１１０の仮想口座残高を携帯電話会社１０のサーバ３０に送信する（Ｓ１２０２）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が金融機関７０から送信された仮想口座残高を受信し（Ｓ９２１）、引続きこれを利用者１２の携帯電話機１３に送信する（Ｓ１０５）。
携帯電話機１３においては、送受信部１３５が携帯電話会社１０から送信された仮想口座残高を受信し（Ｓ７１２）、さらにデータ処理部１３１はその受信した仮想口座残高に基づいてＲＡＭ１３２に記録されている仮想口座残高を更新しかつ未通知データをクリアする（Ｓ７１３）。
また、携帯電話会社１０のサーバ３０においては、ステップＳ９０６で実在店舗２６から送信された決済内容を受信した後、データ処理部３０１がその受信した決済内容を金融機関７０のサーバ７２に送信する（Ｓ９２２）。金融機関７０のサーバ７２においては、データ処理部７０１が携帯電話会社１０から送信された決済内容を受信する（Ｓ１２０３）。
続いて、データ処理部７０１はその受信した決済内容に基づいて決済履歴データベース７１４を更新する（Ｓ１２０４）。
続いて、データ処理部７０１は決済完了の情報を携帯電話会社１０のサーバ３０に送信する（Ｓ１２０５）。そして、金融機関７０は上記仮想店舗の場合と同様に決済機関８０を通じて実在店舗２６に対する支払処理を行なう（Ｓ１２０６）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が金融機関７０から送信された決済完了の情報を受信し（Ｓ９２３）、引続きこれを実在店舗２６のＰＯＳ端末２７に送信する（Ｓ９０７）。
また、携帯電話会社１０のサーバ３０においては、ステップＳ９０９でキーコードの一致を確認した場合、データ処理部３０１はステップＳ９０９で受信した未通知データを金融機関７０のサーバ７２に送信する（Ｓ９２４）。
金融機関７０のサーバ７２においては、データ処理部７０１が携帯電話会社１０から送信された未通知データを受信しする（Ｓ１２０７）。
続いて、データ処理部７０１はその受信した未通知データに基づいて決済履歴データベース７１４を更新する（Ｓ１２０８）
続いて、データ処理部７０１は仮想口座１１０の仮想口座残高を読出して携帯電話会社１０のサーバ３０に送信する（Ｓ１２０９）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が金融機関７０から送信された仮想口座残高を受信し（Ｓ９２５）、引続きこれを利用者１２の携帯電話機１３に送信する（Ｓ９１３）。
利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０から送信された仮想口座残高を受信し（Ｓ７３０）、さらにその受信した仮想口座残高に基づいてＲＡＭ１３２に記録されている仮想口座残高を更新しかつ未通知データをクリアする（Ｓ７２９）。
以上のようにこの発明の第２の実施の形態によれば、仮想口座１１０を金融機関７０に設けているため、仮想口座１１０への資金移動が上記第１の実施の形態に比べて簡単になる。
上記第２の実施の形態では金融機関７０に実在口座７１０とは別に仮想口座１１０を設けているが、実在口座７１０をそのまま仮想口座１１０として取扱うようにしてもよい。この場合、実在口座７１０から仮想口座１１０への資金移動が不要となるため、処理手続はさらに簡単になる。
上記実施の形態のインターネット上の仮想店舗での決済では利用者はパーソナルコンピュータを用いて注文をしているが、携帯電話機を用いて注文をする場合もある。この場合、携帯電話機がパーソナルコンピュータの代わりの機能を果たす。
［第３の実施の形態］
仮想口座を上記第１の実施の形態では携帯電話会社に設け、上記第２の実施の形態では金融機関に設けているが、以下に述べる第３の実施の形態では携帯電話会社や金融機関とは別個の決済機関に仮想口座を設ける。
１．サービスの概要
この第３の実施の形態によるサービスの利用を希望する利用者は、仮想口座に前払金を入金するために必要な銀行の口座番号や信販会社のクレジットカード番号などを決済機関に予め登録しておく。利用者は、決済の前に、仮想口座に前払金を入金するように、携帯電話機を用いて携帯電話会社を通じて決済機関に要請する。決済機関は、予め登録されている銀行の口座番号や信販会社のクレジットカード番号などを用い、利用者に対して前払金の請求を行なう。決済機関は、前払金の請求後、前払金を仮想口座に入金した上で仮想口座の残高を携帯電話会社を介して携帯電話機に送信する。仮想店舗や実在店舗は、上記第１および第２の実施の形態のように携帯電話会社や金融機関ではなく、決済機関に対して請求を行なう。
１−１．利用登録
図４１は、携帯電話機１３の利用者１２が本サービスの利用を希望する場合に最初に行なう利用登録の方法を示す概略図である。図４１に示すように、本サービスの利用を希望する利用者１２は、加入している携帯電話会社、携帯電話番号、および前払金を引落すための銀行の口座番号や信販会社のクレジットカード番号といった決済情報を所定の引落口座登録用紙２５に記入して決済機関９０に郵送する。決済機関９０は、引落口座登録用紙２５に基づいて利用者情報９１０をデータベースに登録する。
続いて、決済機関９０は、利用者１２に付与した会員番号（利用者情報９１０中の顧客番号）を携帯電話会社１０を通じて利用者１２に通知する。利用者１２はその通知内容を確認し、問題がなければ携帯電話会社１０を通じて決済機関９０に対して本サービスの申込を承認する。これに応じて決済機関９０は、仮想口座１１０を開設するとともに、仮想口座の入出金履歴９１２や決済履歴９１４を記録するための領域をデータベース内に開設する。
なお、決済機関９０のデータベースには、本サービスの利用が可能な加盟店（仮想店舗および実在店舗を含む）とその加盟店における利用金額を振込むための振込口座などの加盟店情報９１６が登録されている。
続いて、決済機関９０は、本サービスの開始を携帯電話会社１０を通じて利用者１２の携帯電話機１３に通知する。このとき、携帯電話会社１０は個人情報１１の利用状況を「未登録」から「利用可」に変更する。利用者１２の携帯電話機１３が携帯電話会社１０から本サービス開始の通知を受けると、携帯電話機１３の利用状況を「利用不可」から「利用可」に変更する。
上記手続により、利用者１２は本サービスの利用が可能となる。
１−２．仮想口座への資金移動
図４２は、決済機関９０に設けた仮想口座１１０に入金する前払金を金融機関の口座から引落しする場合の資金移動を示す概略図である。図４２に示すように、利用者１２は携帯電話機１３を用い、携帯電話会社１０を通じて決済機関９０に対して所望の前払金を仮想口座１１０に入金するよう要請する。ここでは仮想口座１１０に５０００円を入金する場合を例示している。決済機関９０は仮想口座１１０への前払の要請を受けると、利用者情報９１０に基づき、利用者１２の口座１６０が開設されている銀行や信販会社のような金融機関１７０に対して前払金の引落しを依頼する。引落し依頼を受けた金融機関１７０は引落しが可能か否かを確認し、可能な場合は振替データを決済機関９０に送り、前払金を決済機関９０に支払う。引落しが不可能な場合はその旨決済機関９０に通知する。決済機関９０は金融機関１７０から振替データを受けると、入出金履歴９１２を更新し、さらに仮想口座１１０を更新する。続いて、決済機関９０はその更新した仮想口座１１０の残高を携帯電話会社１０に通知する。携帯電話会社１０では、携帯電話番号や仮想口座残高などの送信データ１０２が作成される。携帯電話会社１０はこの送信データ１０２に基づいて利用者１２に仮想口座残高を通知する。この通知に応じて利用者１２の携帯電話機１３は仮想口座残高を更新する。携帯電話会社１０から利用者１２の携帯電話機１３への送信データ１０２の送信が完了すると、送信データ１０２はクリアされる。利用者１２が電波圏外にいる場合など、送信データ１０２の送信が不可能な場合、送信データ１０２はクリアされずにそのまま保持される。
１−３．仮想店舗での決済
図４３は、携帯電話機１３を用いてインターネット上の仮想店舗２４で決済する方法を示す概略図である。図４３に示すように、利用者１２は携帯電話機１３またはパーソナルコンピュータ４０を用いて仮想店舗２４に対して注文を出す。注文を受けた仮想店舗２４は、利用者１２の顧客番号や請求内容などを記載した電子請求書を決済機関９０および携帯電話会社１０を通じて利用者１２の携帯電話機１３に送信する。利用者１２はその送信された電子請求書を携帯電話機１３で確認し、その請求内容が自らの注文内容と一致する場合は決済の承認を携帯電話会社１０を通じて決済機関９０に通知する。決済機関９０は決済の承認を得ると、その請求内容に応じて入出金履歴９１２および決済履歴９１４を更新するとともに、仮想口座１１０の残高も更新する。ここではＢ店という仮想店舗２４で３０００円の商品を購入した場合を例示している。
続いて、決済機関９０はその更新した仮想口座残高を携帯電話会社１０に通知する。携帯電話会社１０はその仮想口座残高を送信データ１０２とし、さらに利用者１２の携帯電話機１３に送信する。これに応じて携帯電話機１３の仮想口座残高が更新される。携帯電話会社１０から利用者１２への仮想口座残高の送信が完了すると、送信データ１０２はクリアされる。
一方、決済機関９０は仮想口座残高の更新を終えると、決済の完了を仮想店舗２４を通じて利用者１２に通知する。また、決済機関９０は加盟店情報９１６に基づいてその決済金額を加盟店の振込口座に入金する。
１−４．実在店舗での決済
図４４は、携帯電話機１３を用いて実在店舗２６で決済する方法を示す概略図である。図４４に示すように、実在店舗２６に設置されているＰＯＳ端末２７に携帯電話機１３が装着されると、ＰＯＳ端末２７は決済金額を携帯電話機１３に送信する。決済金額が仮想口座残高以内の場合、携帯電話機１３は決済内容を未通知データに記録するとともに、携帯雷話番号、キーコードおよびパスワードをＰＯＳ端末２７に送信する。これに応じて、ＰＯＳ端末２７は決済の完了を携帯電話機１３に通知する。
その後、ＰＯＳ端末２７は、携帯電話番号、キーコードおよびパスワードとともに決済内容を決済機関９０に通知する。決済機関９０は、受信した携帯電話番号、キーコードおよびパスワードを携帯電話会社１０に送信することにより認証を依頼する。認証依頼を受けた携帯電話会社１０は、個人情報１１の未通知を「無」から「有」に変更する。受信した携帯電話番号、キーコードおよびパスワードが個人情報１１として登録されている携帯電話番号、キーコードおよびパスワードと一致しない場合、携帯電話会社１０は個人情報１１の利用状況を「認証異常」に変更し、その旨を利用者１２および決済機関９０に通知する。この通知に応じて、携帯電話機１３は利用状況を「認証異常」に変更する。
一方、受信した携帯電話番号、キーコードおよびパスワードが個人情報１１として登録されている携帯電話番号、キーコードおよびパスワードと一致した場合、携帯電話会社１０は認証が正常に完了した旨を決済機関９０に通知する。この通知に応じて、決済機関９０は入出金履歴９１２および決済履歴９１４を更新する。決済機関９０はさらに、仮想口座１１０の残高を更新するとともに、未通知を「無」から「有」に変更する。ここでは、Ｄ店という実在店舗２６で１０００円の商品を購入した場合を例示している。
続いて、決済機関９０は決済が完了した旨を実在店舗２６に通知する。また、決済機関９０は加盟店情報９１６に基づいて加盟店の振込口座にその決済金額を入金する。
１−５．未通知データの要求
図４５は、利用者１２が実在店舗２６で決済をしたために携帯電話機１３内に未通知データが発生して携帯電話機１３の仮想口座残高が決済機関９０の仮想口座残高と一致しなくなった場合に決済機関９０が仮想口座残高の同期をとるために携帯電話機１３に対して未通知データの送信を要求する方法を示す概略図である。図４５に示すように、決済機関９０は携帯電話会社１０を通じて利用者１２の携帯電話機１３に未通知データを要求する。これに応じて、携帯電話機１３は携帯電話会社１０を通じて未通知データを決済機関９０に送信する。決済機関９０は、受信した未通知データに基づいて決済履歴９１４のうち該当の決済の状態を「未通知」から「通知済」に変更する。
続いて、決済機関９０は仮想口座１１０の残高を携帯電話会社１０に送信する。携帯電話会社１０は受信した仮想口座残高を送信データ１０２とするとともに、個人情報１１中の未通知を「有」から「無」に変更する。携帯電話会社１０は仮想口座残高を携帯電話機１３に送信する。これに応じて、携帯電話機１３は仮想口座残高を更新するとともに、未通知データをクリアする。携帯電話会社１０は仮想口座残高の送信を完了すると、送信データ１０２をクリアする。
１−６．請求代行
図４６は、仮想店舗２４に代わって決済機関９０が利用者１２による仮想店舗２４での決済金額を信販会社２０に請求する方法を示す概略図である。この請求代行は、決済機関９０に設けた仮想口座１１０を利用するものではなく、利用者情報９１０として登録されている銀行の口座番号や信販会社のクレジットカード番号を利用してデビット決済やカード決済を行なうものである。
図４６に示すように、利用者１２が携帯電話機１３またはパーソナルコンピュータ４０を用いて仮想店舗２４に対して注文をすると、仮想店舗２４は顧客番号や請求内容などからなる電子請求書を決済機関９０および携帯電話会社１０を通じて利用者１２に発行する。利用者１２は携帯電話機１３に送信された電子請求書を確認し、決済を承認する場合はその旨を携帯電話会社１０を通じて決済機関９０に通知する。その際に、予め登録している決済方法の中から１つを選択する。ここでは、信販会社Ｅ社のクレジットカードによる決済を選択した場合を例示している。
決済機関９０は決済の承認を仮想店舗２４に通知するとともに、利用者情報９１０を用いてクレジットカード番号や決済金額などの決済内容を信販会社２０に通知する。これに応じて信販会社２０は仮想店舗２４に対して決済金額の支払処理を行ない、決済が完了した旨を仮想店舗２４に通知する。
利用者１２が決済方法としてデビットカードによる決済を選択した場合、決済機関９０は利用者情報９１０を用いて口座番号や決済金額などの決済内容を銀行１７に通知する。銀行１７はその決済金額を利用者１２の口座から引落し、さらに仮想店舗２４に対してその決済金額の支払処理を行なう。
上記請求代行サービスでは、銀行の口座番号や信販会社のクレジットカード番号といった重要な決済情報は予め決済機関９０に登録されており、携帯電話機１３やパーソナルコンピュータ４０から送信されることはない。認証は携帯電話番号、キーコードおよびパスワードを用いて携帯電話会社１０で行なわれ、認証が得られた場合だけ予め登録されている口座番号やクレジットカード番号が決済機関９０から金融機関１７０や信販会社２０に通知される。したがって、高い安全性を確保することができる。
２．システム構成およびその動作
次に、上記サービスを実現するためのシステム構成およびその動作について説明する。
２−１．利用登録
図４７は、図４１に示した利用登録のためのハードウェア構成を示すブロック図である。上記第１および第２の実施の形態と異なり、この第３の実施の形態では、携帯電話会社１０のサーバ３０には、送信データ１０２を記憶するためのメモリ３０３が設けられる。また、決済機関９０のサーバ９２には、データ処理部９２１と、データベース９２２とが設けられる。データベース９２２には、利用者情報９１０、仮想口座の入出金履歴９１２、仮想口座の決済履歴９１４および加盟店情報９１６が蓄積される。データ処理部９２１は、携帯電話会社１０に設置されているサーバ３０のデータ処理部３０１と接続され、データベース９２２に対して所定のデータ処理を行なう。
図４８は、利用登録を行なう場合における利用者１２の携帯電話機１３、携帯電話会社１０のサーバ３０および決済機関９０のサーバ９２の動作を示すフローチャートである。
まず、利用者１２は携帯電話機１３の入力装置１３６を操作して本サービスの利用申込を携帯電話機１３から携帯電話会社１０に送信する（Ｓ１１）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された利用申込を受信し（Ｓ２１）、これを決済機関９０に送信する（Ｓ２２）。決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話会社１０から送信された利用申込を受信する（Ｓ１３０１）。これに応じて、決済会社９２は所定の申込用紙を利用者１２に発送する（Ｓ１３０２）。利用者１２は申込用紙に引落しを希望する銀行の口座番号や信販会社のクレジットカード番号などを記入した後、決済機関９０に返送する。決済機関９０は利用者１２から返送された申込用紙を受取る（Ｓ１３０２）。この申込用紙に記入された事項に基づいて、データ処理部３０１は利用者情報９１０をデータベース９２２に登録する（Ｓ１３０３）。具体的には、利用者１２の会員番号、携帯電話番号、携帯電話会社、銀行の口座番号、信販会社のクレジットカード番号などを登録する。続いて、データ処理部９２１は会員番号を携帯電話会社１０に通知する（Ｓ１３０４）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０から送信された会員番号を受信し（Ｓ２３）、これを利用者１２に通知する（Ｓ２４）。利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０から送信された会員番号を受信し（Ｓ１２）、利用者１２がその申込を承認した場合はその旨を携帯電話会社１０に通知する（Ｓ１３）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された申込承認の通知を受信し（Ｓ２５）、これを決済機関９０に通知する（Ｓ２６）。
決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話会社１０から送信された申込承認の通知を受信し（Ｓ１３０５）、仮想口座１１０を開設し（Ｓ１３０６）、本サービスの開始を携帯電話会社１０に通知する（Ｓ１３０７）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０から送信されたサービス開始の通知を受信し（Ｓ２７）、個人情報１１の利用状況を「未登録」から「利用可」に更新する（Ｓ２８）。続いて、データ処理部３０１は本サービスの開始を利用者１２に通知する（Ｓ２９）。利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０から送信されたサービス開始の通知を受信し（Ｓ１４）、利用状況を「利用不可」から「利用可」に更新する（Ｓ１５）。
２−２．仮想口座への資金移動
図４９は、図４２に示した資金移動に用いられる利用者１２の携帯電話機１３、携帯電話会社１０のサーバ３０、決済機関９０のサーバ９２、金融機関１７０のサーバ１７２のハードウェア構成を示すブロック図である。図４９に示すように、金融機関１７０に設置されるサーバ１７２は、データ処理部１７４と、データベース１７６とを備える。データ処理部１７４はデータベース１７６のデータを処理するとともに、携帯電話会社１０に設置されているサーバ３０のデータ処理部３０１に接続される。データベース１７６には、利用者の住所や氏名などの利用者情報１７７と、金融機関１７０に開設されている実在口座に関する実在口座情報１７８と、実在口座における入出金などの実在口座履歴１７９とが登録される。
図５０〜図５２は、図４２に示したように金融機関１７０から決済機関９０の仮想口座１１０に資金を移動する場合における携帯電話機１３、携帯電話会社１０のサーバ３０および決済機関９０のサーバ９２の動作を示すフローチャートである。
ここでは、パスワードの入力（Ｓ１０１）前に、携帯電話機１３が利用状況を確認し、利用不可の場合はその旨を表示装置１３７に表示する（Ｓ１００）。利用可の場合は利用者１２に対してパスワードの入力を促す（Ｓ１０１）。また、パスワードの検証（Ｓ１０２）後、前払金額の入力（Ｓ１０４）前に、図２１と同様に未通知データを確認して利用可能残高を表示する（Ｓ７１４）。
続いて、携帯電話機１３の送受信部１３５はステップＳ１０４で入力された前払金額などを携帯電話会社１０に送信するが（Ｓ１０６）、ここではステップＳ１０１で入力されたパスワードも携帯電話会社１０に送信する。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が受信した携帯電話番号に基づいて個人情報１１を検索した後（Ｓ２０２）、受信したキーコードおよびパスワードを検証する（Ｓ２０３）。キーコードまたはパスワードが一致しない場合、個人情報１１の利用状況を「利用可」から「利用不可」に変更し（Ｓ２５０）、認証の異常を利用者１２に通知する（Ｓ２５１）。
利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０から認証異常の通知を受信し（Ｓ１５０）、これに応じてデータ処理部１３１は携帯電話機１３の利用状況を「利用可」から「認証異常」に変更し（Ｓ１５１）、本サービスの利用停止を表示装置１３７に表示する（Ｓ１５２）。
一方、ステップＳ２０３でキーコードおよびパスワードの両方が一致した場合、データ処理部３０１は個人情報１１の利用状況を確認し（Ｓ２０４）、利用状況が「利用可」の場合は未通知データがあるか否かを判定する（Ｓ２５３）。未通知データがある場合、データ処理部３０１はステップＳ２０１で受信した前払金額とともに未通知データを決済機関９０に送信する（Ｓ２５４）。一方、未通知データがない場合、データ処理部３０１は前払金額のみを決済機関９０に送信する（Ｓ２５５）。このように携帯電話会社１０から決済機関９０に前払金額を送信する際には、利用者１２の携帯電話番号も送信する。
決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話会社１０から送信された携帯電話番号や前払金額などを受信し（Ｓ１３００）、その受信した情報およびデータベース９２２に登録されている利用者情報９１０に基づいて利用者１２が口座を開設している金融機関１７０に対する請求データを作成する（Ｓ１３０１）。決済機関９０はその請求データに従って金融機関１７０に前払金額の引落しを依頼する（Ｓ１３０２）。
金融機関１７０は、決済機関９０からの引落し依頼に応じて利用者１２の口座１６０から前払金額を引落す（Ｓ１４００）。続いて、データ処理部１７４は引落しが可能か否か、すなわち前払金額が口座残高以内か否かを判定する（Ｓ１４０１）。引落しが不可能な場合、データ処理部１７４は決済機関９０にその旨を通知する（Ｓ１４０２）。決済機関９０のサーバ９２においては、データ処理部９２１が金融機関１７０から引落し不可の通知を受信し（Ｓ１３０３）、これを利用者１２の携帯電話番号とともに携帯電話会社１０に通知する（Ｓ１３０４）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０から引落し不可の通知を受信し（Ｓ２５６）、これを利用者１２の携帯電話機１３に通知する（Ｓ２３２）。
一方、ステップＳ１４０１において引落しが可能な場合、サーバ１７２のデータ処理部１７４は振替データを決済機関９０に送信し（Ｓ１４０３）、利用者１２の口座１６０から決済機関９０の口座に前払金額を振替える支払処理を実行する（Ｓ１４０４）。
決済機関９０のサーバ９２においては、データ処理部９２１が金融機関１７０から送信された振替データを受信し（Ｓ１３０５）、続いて前払金額の入金をデータベース９２２に記録することにより入出金履歴９１２を更新する（Ｓ１３０６）。未通知データが送信されて来ている場合は、ここで決済金額をデータベース９２２に記録することにより決済履歴９１４を更新する（Ｓ１３０７）。続いて、データ処理部９２１は仮想口座１１０の残高に前払金額を加算することにより仮想口座残高を更新する（Ｓ１３０８）。未通知データがあった場合はこれを「無」に変更する。続いて、データ処理部９２１は仮想口座１１０の残高を携帯電話番号とともに携帯電話会社１０に送信する（Ｓ１３０９）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０から送信された仮想口座残高を受信し（Ｓ２５７）、その仮想口座残高を送信データ１０２としてメモリ３０３に記憶する（Ｓ２５８）。続いて、データ処理部３０１は未通知データを「無」に変更する（Ｓ２５９）。続いて、データ処理部３０１は、メモリ３０３に記憶された送信データ１０２を利用者１２の携帯電話機１３に送信する（Ｓ２６０）。続いて、上記送信が正常に終了したか否かを判定し（Ｓ２６１）、正常に終了した場合は送信データ１０２をクリアし（Ｓ２６２）、利用者１２が電波圏外にいたり携帯電話機１３の電源を切っていた場合など、送信データを携帯電話機１３に送信できず、送信が正常に終了しなかった場合は再送信処理を行なう（Ｓ２６３）。具体的には、所定期間経過後に送信データ１０２を再び携帯電話機１３に送信する。
２−３．仮想店舗での決済
図５３は、図４３に示した仮想店舗２４での決済に用いられるパーソナルコンピュータ４０、携帯電話機１３、携帯電話会社１０のサーバ３０、決済機関９０のサーバ９２および仮想店舗２４のサーバ５０のハードウェア構成を示すブロック図である。図５３に示すように、決済機関９０に設置されたサーバ９２のデータ処理部９２１はインターネット６０に接続される。
図５４〜図５６は、図４３に示したように仮想店舗２４で決済する場合におけるパーソナルコンピュータ４０、携帯電話機１３、携帯電話会社１０のサーバ３０、決済機関９０のサーバ９２、および仮想店舗２４のサーバ５０の動作を示すフローチャートである。
ここでは、利用者１２のパーソナルコンピュータ４０または携帯電話機１３は注文内容とともに会員番号（顧客番号）を仮想店舗２４に送信する（Ｓ３０１）。仮想店舗２４のサーバはこれらを受信し（Ｓ６０１）、電子請求書を作成して会員番号とともに請求内容をインターネット６０を介して決済機関９０に送信する（Ｓ６０２）。
決済機関９０のサーバ９２においては、データ処理部９２１が仮想店舗２４から送信された電子請求書を受信し（Ｓ１３１０）、その受信した会員番号に基づいてデータベース９２２を検索して利用者情報９１０の中から利用者１２の携帯電話番号および携帯電話会社を特定する（Ｓ１３１１）。続いて、データ処理部９２１は受信した電子請求書を該当の携帯電話会社１０に携帯電話番号とともに送信する（Ｓ１３１２）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０から送信された電子請求書を携帯電話番号とともに受信する（Ｓ５０１）。データ処理部３０１は個人情報１１中の利用状況を確認し（Ｓ５０３）、利用状況が「利用不可」の場合はその旨を携帯電話番号とともに決済機関９０に通知する（Ｓ５０４）。
決済機関９０のサーバ９２においては、携帯電話会社１０から携帯電話番号とともに通知されたサービス利用不可の通知を受信し（Ｓ１３１３）、これをインターネット６０を介して仮想店舖２４に通知する（Ｓ１３１４）。
また、利用者１２は、携帯電話会社１０から送信され、携帯電話機１３で受信した電子請求書を開封し（Ｓ４１８）、携帯電話機１３のデータ処理部１３１は受信した電子請求書の請求内容および利用可能な仮想口座残高を表示装置１３７に表示する（Ｓ１５４）。
また、電子請求書の請求金額が利用可能残高を超えている場合、データ処理部１３１は表示装置１３７を通じて利用者１２に対して仮想口座１１０への追加振替を行なうか否かを問合せる（Ｓ１５５）。追加振替を行なう場合、データ処理部１３１は資金振替の処理を実行する（Ｓ１５６）。
また、決済を承認するか否かの判定（Ｓ４０２）は、利用可能残高の検証（Ｓ４０８）後に行なう。携帯電話会社１０のサーバ３０においては、データ処理部３０１が受信した決済の取消または拒否を携帯電話番号とともに決済機関９０に送信する（Ｓ５０７）。決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話会社１０から送信された決済の取消または拒否を受信し（Ｓ１３１５）、これをインターネット６０を介して仮想店舗２４に送信する（Ｓ１３１６）。決済の取消または拒否は上記実施の形態と同様に仮想店舗２４を介して利用者１２に返信される（Ｓ６０５，Ｓ６０６，Ｓ３０４）。利用者１２のパーソナルコンピュータ４０または携帯電話機１３においては、データ処理部４０１または１３１がその受信した決済の取消または拒否（受注取消）を表示装置４０６または１３７に表示する（Ｓ３０８）。
また、利用者１２の携帯電話機１３においては、パスワードの入力（Ｓ４１１）後に、データ処理部１３１がその入力されたパスワードの検証を行なう（Ｓ１５７）。パスワードが誤っている場合はデータ処理部１３１はその旨を表示装置１３７に表示し（Ｓ１５８）、パスワードが正しい場合は送受信部１３５は決済の承認を携帯電話会社１０に通知する（Ｓ４１２）。
また、携帯電話会社１０のサーバ３０においては、キーコードまたはパスワードが不一致の場合、データ処理部３０１は個人情報１１の利用状況を「利用可」から「認証異常」に変更し（Ｓ５２２）、その旨を利用者１２に通知し（Ｓ５２３）、さらに決済機関９０にも携帯電話番号とともに通知する（Ｓ５２４）。利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０から送信された認証異常の通知を受信し（Ｓ１５９）、データ処理部１３１は利用状況を「利用可」から「認証異常」に変更し、さらに本サービスの利用停止を表示装置１３７に表示する（Ｓ１６１）。一方、決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話会社１０から送信された認証異常の通知を受信し（Ｓ１３１７）、認証異常を理由に決済が不可能である旨をインターネット６０を介して仮想店舗２４に通知する（Ｓ１３１８）。仮想店舗２４のサーバ５０においては、モデム５０４が決済機関９０から送信された決済不可の通知を受信し（Ｓ６１３）、これに応じて受注の取消をインターネット６０を介して利用者１２のパーソナルコンピュータ４０または携帯電話機１３に送信する（Ｓ６１４）。利用者１２のパーソナルコンピュータ４０または携帯電話機１３においては、モデム４０４または送受信部１３５が仮想店舗２４から送信された受注の取消を受信し（Ｓ３０９）、データ処理部４０１または１３１がその旨を表示装置４０６または１３７に表示する（Ｓ３１０）。
ステップＳ５１１，Ｓ５１２においてキーコードおよびパスワードがともに一致した場合、データ処理部３０１は未通知が「有」か否かを判定し（Ｓ５２５）、未通知データがある場合は決済データおよび未通知データを携帯電話番号とともに決済機関９０に送信する（Ｓ５２６）。未通知データがない場合はデータ処理部３０１は決済データを携帯電話番号とともに決済機関９０に送信する（Ｓ５２７）。決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話会社１０から送信された決済データ（および未通知データがある場合は未通知データ）を受信し（Ｓ１３１９）、その受信した決済データ（および未通知データがある場合は未通知データ）に基づいて入出金履歴９１２を更新し（Ｓ１３２０）、決済履歴９１４を更新し（Ｓ１３２１）、さらに仮想口座１１０の残高を更新する（Ｓ１３２２）。ここで、データ処理部９２１は仮想口座１１０の未通知を「無」にする。
続いて、データ処理部９２１は更新した仮想口座１１０の残高を携帯電話番号とともに携帯電話会社１０に送信し（Ｓ１３２３）、決済の完了をインターネット６０を介して仮想店舗２４に通知し（Ｓ１３２４）、さらに仮想店舗２４への支払処理を行なう（Ｓ１３２５）。決済完了の通知は仮想店舗２４を介して利用者１２にも通知される（Ｓ６１２，Ｓ３０７）。利用者１２のパーソナルコンピュータ４０または携帯電話機１３においては、データ処理部４０１または１３１がその受信した決済の完了を表示装置４０６または１３７に表示する（Ｓ３１１）。
一方、携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０から送信された仮想口座残高を受信し（Ｓ５２８）、その残高を送信データ１０２としてメモリ３０３に記憶する（Ｓ５２９）。続いて、データ処理部３０１は個人情報１１の未通知を「無」にし（Ｓ５３０）、メモリ３０３に記憶された送信データ（仮想口座残高）１０２を利用者１２の携帯電話機１３に送信する（Ｓ５３１）。
続いて、データ処理部３０１は上記データの送信が正常に終了したか否かを判定し（Ｓ５３２）、正常に終了した場合はメモリ３０３に記憶された送信データ１０２をクリアし（Ｓ５３３）、正常に終了しなかった場合は再び送信処理を行なう（Ｓ５３４）。
利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０から送信された送信データ１０２を受信し（Ｓ１６２）、データ処理部１３１がその受信した送信データ１０２に基づいて仮想口座残高を更新する（Ｓ１６３）。続いて、データ処理部１３１は未通知データをクリアし（Ｓ１６４）、仮想口座残高とともに決済の完了を表示装置１３７に表示する（Ｓ１６５）。
２−４．実在店舗での決済
図５７は、図４４に示した実在店舗での決済に用いられる携帯電話機１３、ＰＯＳ端末２７、携帯電話会社１０のサーバ３０および決済機関９０のサーバ９２のハードウェア構成を示すブロック図である。ここでは図２０と異なり、決済機関９０のサーバ９２が実在店舗２６のＰＯＳ端末２７および携帯電話会社１０のサーバ３０に接続される。
図５８〜図６０は、図５７に示した携帯電話機１３、ＰＯＳ端末２７、携帯電話会社１０のサーバ３０および決済機関９０のサーバ９２の動作を示すフローチャートである。
ここでは、携帯電話会社１０のサーバ３０において、ステップＳ５２５の判定の結果、未通知データがある場合、データ処理部３０１はその未通知データを携帯電話番号とともに決済機関９０に送信する（Ｓ５３５）。決済機関９０のサーバ９２においては、未通知データがある場合、データ処理部９２１は入出金履歴９１２を更新する（Ｓ１３３０）。続いて、データ処理部９２１は決済履歴９１４を更新し、該当する決済の状態を「通知済」とする（Ｓ１３３１）。続いて、データ処理部９２１は未通知データがある場合に仮想口座１１０の残高を更新し、未通知を「無」にする（Ｓ１３３２）。
また、ここでは図２２と異なり、利用者１２の携帯電話機１３において、残高の検証（Ｓ７１８）後に、データ処理部１３１は未通知データに決済内容を記憶し（Ｓ７２２）、その後、携帯電話番号、キーコード、パスワードといった携帯電話機１３の端末情報をＰＯＳ端末２７に送信する（Ｓ７２０）。ステップＳ８０２〜Ｓ８０４，Ｓ７２１は図２２と同じである。ステップＳ７２１でＰＯＳ端末２７から決済完了の通知を受信した後、データ処理部１３１は決済モードをオフにし（Ｓ７２３）、決済の終了を表示装置１３７に表示する（Ｓ７３１）。
また、ＰＯＳ端末２７のデータ処理部２７１はステップＳ８０２で受信した携帯電話番号、キーコードおよびパスワードとともに、ステップＳ８０３で記録した決済内容を決済機関９０に送信する（Ｓ８０５）。決済機関９０のサーバ９２においては、データ処理部９２１がＰＯＳ端末２７から携帯電話番号などとともに送信された決済内容を受信し（Ｓ１３３３）、その受信した携帯電話番号に基づいてデータベース９２２に記憶された利用者情報９１０を検索する（Ｓ１３３４）。この検索結果に従って、データ処理部９２１は該当の携帯電話会社１０に認証を依頼するためにステップＳ１３３３で受信した携帯電話番号、キーコードおよびパスワードを携帯電話会社１０に送信する（Ｓ１３３５）。
携帯電話会社１０のサーバ３０においては、図５５と同様にデータ処理部３０１が認証を行なう（Ｓ５１１，Ｓ５１２）。ただしここでは、キーコードまたはパスワードが不一致の場合、データ処理部３０１は個人情報１の利用状況を「利用不可」に変更し（Ｓ５２２）、本サービスの利用停止を利用者１２に通知する（Ｓ５２３）。利用者１２の携帯電話機１３においては、データ処理部１３１は利用状況を「利用不可」に変更する（Ｓ１６０）。
一方、キーコードおよびパスワードが一致した場合、データ処理部３０１は個人情報１１の未通知を「有」に変更し（Ｓ９２５）、認証の成功を決済機関９０に通知し、さらに後述する未通知データの要求処理を行なう（Ｓ９２７）。
決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話会社１０から送信された認証成功の通知を受信し（Ｓ１３３０）、入出金履歴９１２、決済履歴９１４および仮想口座１１０の残高をそれぞれ更新する（Ｓ１３２０〜Ｓ１３２２）。ここでは、決済履歴９１４を更新したときその状態を「未通知」とする。続いて、データ処理部９２１は仮想口座１１０の未通知を「有」に変更する（Ｓ１３３１）。
また、データ処理部９２１が携帯電話会社１０から認証異常の通知を受信した場合も（Ｓ１３１７）、データ処理部９２１は実在店舗２６に対する決済金額の支払処理を行なう（Ｓ１３３２）。このような認証異常が起こる原因として利用者１２の不正が考えられるが、この場合も決済機関９０は実在店舗２６に対して支払を保証することになる。決済機関９０は不正使用による損害を負担することになるが、上記のように認証異常を検出した時点で本サービスの利用を停止しているので損害を最小限に抑えることができる。
２−５．未通知データの要求
図６１は、携帯電話会社１０が利用者１２に対して未通知データを要求する場合における携帯電話機１３、携帯電話会社１０のサーバ３０および決済機関９０のサーバ９２の動作を示すフローチャートである。なお、未通知データは図２４に示した第１の実施の形態と同様に携帯電話機１３のＲＡＭ１３２に記憶されている。また、未通知データの要求の際には図４７に示したハードウェア構成が用いられる。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が予め定められた時間間隔おきに利用者１２の携帯電話機１３に対して未通知データの送信を要求する（Ｓ５４０）。利用者１２の携帯電話機１３においては、送受信部１３５が携帯電話会社１０から送信された未通知データの送信要求を受信し（Ｓ１７０）、これに応じてデータ処理部１３１がＲＡＭ１３２に記憶されている未通知データを携帯電話番号、キーコードおよびパスワードとともに携帯電話会社１０に送信する（Ｓ７０６）。以下、図５８および図５９と同様に携帯電話会社１０のサーバ３０は認証などを行ない、決済機関９０のサーバ９２は決済履歴９１４の更新などを行なう。
２−６．請求代行
図６２は、図４６に示した請求代行に用いられるパーソナルコンピュータ４０、携帯電話機１３、携帯電話会社１０のサーバ３０、仮想店舗２４のサーバ５０、決済機関９０のサーバ９２、金融機関１７０のサーバ９４のハードウェア構成を示すブロック図である。図６２に示すように、金融機関のサーバ９４は、データ処理部９４１と、データベース９４２とを備える。データ処理部９４１は、インターネット６０と、決済機関９０に設置されているサーバ９２のデータ処理部９２１とに接続される。データベース９４２には、利用者情報９４３、加盟店情報９４４および利用者履歴９４５が蓄積される。利用者情報９４３は、利用者の住所、氏名、電話番号などの他、銀行の場合は口座番号、信販会社の場合はクレジットカード番号および引落銀行口座などである。加盟店情報９４４は、デビットカードやクレジットカードによる決済を受付ける加盟店の住所、名称などである。利用者履歴９４５は、デビットカードやクレジットカードによる決済金額、決済日、利用加盟店の名称などである。
図６３および図６４は、図６２に示したパーソナルコンピュータ４０、携帯電話機１３、携帯電話会社１０のサーバ３０、決済機関９０のサーバ９２、金融機関のサーバ９４および仮想店舗２４のサーバ５０の動作を示すフローチャートである。
図６３および図６４に示した請求代行の処理は、図５４〜図５６に示した仮想店舗での決済の処理に類似している。ただし、請求代行の際には利用者１２の携帯電話機１３において、ステップＳ４１８で電子請求書を開封した後直ちに、決済の承認を行なう（Ｓ４０２）。また、ステップＳ１５７でパスワードが一致した場合に、デビットカードによる決済かクレジットカードによる決済かという決済方法の選択を利用者１２に対して促す（Ｓ１７１）。続いて、携帯電話機１３の送受信部１３５は、決済の承認を携帯電話会社１０に通知する（Ｓ４１２）。このとき、携帯電話番号、キーコード、パスワード、決済内容の他、決済方法も合わせて携帯電話会社１０に送信する。
また、携帯電話会社１０のサーバ３０においては、ステップＳ５１１，Ｓ５１２でキーコードおよびパスワードが一致した場合に、データ処理部３０１はステップＳ５１０で受信した決済の承認を携帯電話番号とともに決済機関９０に送信する。決済機関９０のサーバ９２においては、データ処理部９２１がこの決済の承認をインターネット６０を介して仮想店舗２４に通知し（Ｓ１３３５）、仮想店舗２４のサーバ５０においてはモデム５０４がこの通知を受信する（Ｓ６１５）。
続いて、データ処理部９２１は金融機関に決済内容を通知する（Ｓ１３３６）。金融機関のサーバ９４においては、データ処理部９４１が決済機関９０から送信された決済内容を受信し（Ｓ１５００）、所定の決済処理を行なう（Ｓ１５０１）。続いて、データ処理部９４１は決済の可否を仮想店舗２４に通知する（Ｓ１５０２）。仮想店舗２４のサーバ５０においては、モデム５０４が金融機関から送信された決済可否の通知を受信し（Ｓ６１６）、決済が可能か否かを判定し（Ｓ６１７）、決済が不可能な場合は受注の取消を利用者１２のパーソナルコンピュータ４０または携帯電話機１３に送信する（Ｓ６１８）。利用者１２のパーソナルコンピュータ４０または携帯電話機１３においては、モデム４０４または送受信部１３５が仮想店舗２４から送信された受注取消を受信し（Ｓ３１５）、その旨を表示装置４０６または１３７に表示する（Ｓ３１６）。
上記第３の実施の形態は仮想口座１１０を決済機関９０に設けている点で上記第１および第２の実施の形態と大きく相違するが、その他の点でも相違している。これらの相違点は上記第１および第２の実施の形態でも採用することは可能である。
［第４の実施の形態］
上記第３の実施の形態では携帯電話会社１０に設けた個人情報１１に基づいて利用者１２の認証を行なっているが、以下に述べる第４の実施の形態では決済機関９０に設けた利用者情報９１０に基づいて利用者１２の認証を行なう。この第４の実施の形態のためのハードウェア構成は、図４７、図４９、図５３、図５７および図６２に示したものと同じであるから、その説明は繰返さない。以下、第４の実施の形態を上記第３の実施の形態との相違点を中心に説明する。
１．前払い方法
まず、仮想口座に入金する前払い方法について説明する。図６５は、この発明の第４の実施の形態に従う前払い方法を示す概略図である。ここでは、携帯電話機１３のＲＡＭ１３２内に、後述するワンタイムＩＤ、小口口座残高および小口決済履歴を記憶するための領域が確保されている。また、決済機関９０の利用者情報９１０には、利用者１２を認証するためのキーコードおよびパスワードが含まれている。利用者情報９１０にはまた、携帯電話機１３のメールアドレス、利用状況および会員区分が含まれている。会員区分には個人利用者の「一般」と「加盟店」とがある。仮想口座１１０には、小口口座残高およびワンタイムＩＤが含まれている。図６６および図６７は、図６５に示した場合における、携帯電話機、携帯電話会社のサーバ、および決済機関のサーバの動作を示すフローチャートである。
まず、利用者１２は携帯電話機１３を用い、メニュー画面で「前払い」を選択する（Ｓ９８）。具体的には、図４７、図４９、図５３、図５７および図６２に示した携帯電話機１３において、利用者１２の操作に応じて入力装置１３６が「前払い」の選択信号をデータ処理部１３１に与える。以降、ステップＳ９９〜Ｓ１０３は図５０に示したものと同じであるから、その説明は繰返さない。
パスワードの検証（Ｓ１０２）後、利用者１２は携帯電話機１３を用い、予め付与されている顧客番号を入力する（Ｓ１７５）。具体的には、利用者１２の操作に応じて入力装置１３６が入力された顧客番号をデータ処理部１３１に与える。ここでは利用者１２が顧客番号を入力しているが、最初に入力された顧客番号をＲＡＭ１３２に記憶しておき、２回目以降はこの記憶された顧客番号を送信するようにしてもよい。また、上記実施の形態のように携帯電話機１３の電話番号を顧客番号として用いてもよい。
続いて、携帯電話機１３の送受信部１３５がステップＳ１７５で入力された顧客番号、ＲＯＭ１３３に予め登録されているキーコード、およびステップＳ１０１で入力されたパスワードを携帯電話会社１０に送信する（Ｓ１７６）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された顧客番号、キーコードおよびパスワードを受信し、これらをそのままインターネット６０を介して決済機関９０に送信する。すなわち、携帯電話会社１０は携帯電話機１３から送信された顧客番号、キーコードおよびパスワードを決済機関９０に転送する（Ｓ２６５）。
決済機関９０のサーバ９２においては、携帯電話機１３から携帯電話会社１０を介して送信された顧客番号、キーコードおよびパスワードをデータ処理部９２１が受信する（Ｓ２００）。以降、決済機関９０のサーバ９２は、図５０および図５１に示したステップＳ２０３〜Ｓ２０５，Ｓ２５０，Ｓ２５１と同じ処理を携帯電話会社１０のサーバ３０に代わって実行する。但しここでは、決済機関９０のサーバ９２は認証異常通知を携帯電話会社１０に送信し、携帯電話会社１０のサーバ３０はこれを携帯電話機１３に転送する（Ｓ２６６）。また、決済機関９０のサーバ９２は利用不可通知を携帯電話会社１０に送信し、携帯電話会社１０のサーバ３０はこれを携帯電話機１３に転送する（Ｓ２６７）。携帯電話機１３のステップＳ１５０〜Ｓ１５２，Ｓ１１０，Ｓ１１１は図５１に示したものと同じであるから、その説明は繰返さない。
利用状況の確認（Ｓ２０４）の結果、利用状況が「利用可」の場合、決済機関９０は利用者１２に対して前払金額の入力を要求する。具体的には、決済機関９０のサーバ９２において、データ処理部９２１が前払金額の要求を携帯電話機１３に送信する（Ｓ１３４０）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０からインターネット６０を介して送信された前払金額の要求を利用者１２の携帯電話機１３に転送する（Ｓ２６８）。
利用者１２の携帯電話機１３においては、送受信部１３５が決済機関９０から携帯電話会社１０を介して送信された前払金額の要求を受信する（Ｓ１７７）。
利用者１２はこの要求に応じて携帯電話機１３の入力装置１３６を操作し、所望の前払金額を入力するとともに前払金額の支払方法を選択する（Ｓ１７８）。この支払方法としては、上記と同様に銀行口座からの引落し、デビット決済、クレジット決済の他、振込み、電子マネーによる決済などがある。携帯電話機１３の送受信部１３５は、この入力された前払金額および選択された支払方法を決済機関９０に送信する。携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された前払金額および支払方法を決済機関９０に転送する（Ｓ２６９）。
決済機関９０のサーバ９２においては、携帯電話機１３から携帯電話会社１０を介して送信された前払金額および支払方法をデータ処理部９２１が受信する（Ｓ１３４１）。
続いて、データ処理部９２１は選択された支払方法で所望の前払金額の決済処理を実行する（Ｓ１３４２）。
続いて、データ処理部９２１は決済が可能か否かを判定する（Ｓ１３４３）。決済が不可能な場合、決済機関９０は利用者１２に前払不可を通知する。具体的には、決済機関９０のサーバ９２において、データ処理部９２１が前払不可の通知を携帯電話機１３に送信する（Ｓ１３４４）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０からインターネット６０を介して送信された前払不可の通知を携帯電話機１３に転送する（Ｓ２７０）。
利用者１２の携帯電話機１３においては、送受信部１３５が決済機関９０から携帯電話会社１０を介して送信された前払不可の通知を受信し（Ｓ１７９）、前払不可を表示装置１３７に表示する（Ｓ１８０）。
一方、ステップＳ１３４３で決済が可能な場合、決済機関９０は利用者１２に仮想口座の新しい残高とともに前払完了を通知する。具体的には、データ処理部９２１が仮想口座の残高とともに前払完了の通知を携帯電話機１３に送信する（Ｓ１３４５）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０からインターネット６０を介して送信された仮想口座の残高および前払完了の通知を利用者１２の携帯電話機１３に転送する（Ｓ２７１）。
利用者１２の携帯電話機１３においては、送受信部１３５が決済機関９０から携帯電話会社１０を介して送信された仮想口座の残高および前払完了の通知を受信し（Ｓ１８１）、データ処理部１３１が仮想口座の残高とともに前払完了を表示装置１３７に表示する（Ｓ１８２）。
前払完了の通知（Ｓ１３４５）後、データ処理部９２１は前払金額に基づいて入出金履歴９１２を更新し（Ｓ１３０６）、さらに仮想口座１１０の残高を更新する（Ｓ１３０８）。
上述したステップＳ２６５〜Ｓ２７１に係る通信は同一セッション内で行なわれる。したがって、入出金履歴や仮想口座残高を更新する前に通信が遮断された場合は入出金履歴や仮想口座残高は更新されない。
２．仮想店舗での決済
次に、仮想店舗での決済について説明する。以下に仮想口座から仮想店舗に請求金額を送金する２つの方法を挙げる。
２−１．第１の送金方法
図６８は、この発明の第４の実施の形態に従う第１の送金方法を示す概念図である。ここでは、決済機関９０のサーバ９２に設けられたデータベース９２２に、加盟店請求履歴９１８および加盟店入金履歴９２０が記録される。図６９および図７０は、図６８に示した場合における、パーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、決済機関のサーバ、および仮想店舗のサーバの動作を示すフローチャートである。
上記第３の実施の形態と同様に、利用者１２のパーソナルコンピュータ４０または携帯電話機１３は注文内容とともに顧客番号を仮想店舗２４に送信する（Ｓ３０１）。仮想店舗２４のサーバ５０はこれらを受信し（Ｓ６０１）、顧客番号とともに請求内容を決済機関９０に送信する（Ｓ６０２）。
決済機関９０のサーバ９２においては、データ処理部９２１が仮想店舗２４から送信された請求内容を受信する（Ｓ１３１０）。
続いて、決済機関９０のサーバ９２は、図５４に示したステップＳ５０２，Ｓ５０３，Ｓ５０５と同じ処理を携帯電話会社１０のサーバ３０に代わって実行する。但しここでは、携帯電話番号の代わりに顧客番号に基づいて決済機関９０のサーバ９２がデータベース９２２中の利用者情報９１０を検索する（Ｓ５０２）。
利用状況の確認（Ｓ５０３）の結果、利用状況が「利用可」の場合、決済機関９０のサーバ９２においては、データ処理部９２１が顧客番号に基づいてデータベース９２２を検索し、利用者情報９１０の中から携帯電話機１３の電子メールアドレスを読出し、その電子メールアドレスに従って電子請求書を電子メールで携帯電話機１３に送信する（Ｓ５０５）。この電子請求書には、請求番号、請求金額、送金先（加盟店番号）などが記録されている。
続いて、データ処理部９２１は加盟店請求履歴９１８を更新し、仮想店舗２４から送信された電子請求書に基づいて、請求番号、請求日、請求金額などを記録する（Ｓ１３４０）。
携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０からインターネット６０を介して送信された電子メールを利用者１２の携帯電話機１３に転送する（Ｓ２７２）。
携帯電話機１３においては、送受信部１３５が決済機関９０から携帯電話会社１０を介して送信された電子メールを受信し（Ｓ４０１）、データ処理部１３１が利用者１２の操作に応じて電子メールを開封し、電子請求書を表示装置１３７に表示する（Ｓ４１８）。
続いて、利用者１２が電子請求書を確認し、そこに記録されている請求金額を仮想店舗２４に送金する場合は「送金」を選択する。このとき、利用者１２は入力装置１３６を操作して顧客番号およびパスワードも入力する。これにより携帯電話機１３は電子メールに埋込まれている送金ＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）に従って決済機関９０のサーバ９２に接続され、送受信部１３５がキーコード、顧客番号およびパスワードとともに送金選択信号を決済機関９０に送信する（Ｓ４３０）。携帯電話会社１０のサーバ３０は、携帯電話機１３から送信された送金選択信号をインターネット６０を介して決済機関９０に転送する（Ｓ２７３）。
決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話機１３から携帯電話会社１０を介して送信されたキーコード、顧客番号、パスワードおよび送金選択信号を受信し（Ｓ１３４１）、その受信した顧客番号に基づいてデータベース９２２中の利用者情報９１０を検索する（Ｓ１３４２）。以降、決済機関９０のサーバ９２は図５５に示したステップＳ５１１，Ｓ５１２，Ｓ５２２〜Ｓ５２４と同じ処理を携帯電話会社１０のサーバ３０に代わって実行する。
データ処理部９２１がキーコードおよびパスワードを検証し（Ｓ５１１，Ｓ５１２）、両方共一致した場合は仮想口座１１０の新しい残高とともに送金完了の通知を携帯電話会社１０を介して利用者１２の携帯電話機１３に送信する（Ｓ１３４３）。携帯電話会社１０のサーバ３０は、決済機関９０からインターネット６０を介して送信された送金完了の通知を利用者１２の携帯電話機１３に転送する（Ｓ２７５）。携帯電話機１３においては、送受信部１３５が決済機関９０から携帯電話会社１０を介して送信された送金完了通知を受信し（Ｓ４３１）、さらにデータ処理部１３１が送金後の仮想口座残高とともに送金完了を表示装置１３７に表示する（Ｓ４３２）。
送金完了の通知（Ｓ１３４３）後、決済機関９０のサーバ９２は図５６に示したステップＳ１３２０〜Ｓ１３２２と同じ処理を実行する。
仮想口座残高の更新（Ｓ１３２２）後、データ処理部９２１はデータベース９２２中の加盟店請求履歴９１８を更新し、入金日を記録する（Ｓ１３４４）。
続いて、データ処理部９２１はデータベース９２２中の加盟店入金履歴９２０を更新し、請求番号、入金日、入金額、送金顧客番号などを記録する（Ｓ１３４５）。
続いて、データ処理部９２１は入金通知をインターネット６０を介して仮想店舗２４に送信する（Ｓ１３４６）。仮想店舗２４のサーバ５０においては、モデム５０４が決済機関９０から送信された入金通知を受信する（Ｓ６１９）。
ここでは、ステップＳ２７２〜Ｓ２７５に係る通信は同一セッション内で行なわれる。
２−２．第２の送金方法
図７１は、この発明の第４の実施の形態に従う第２の送金方法を示す概念図である。図７２および図７３は、図７１に示した場合における、パーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、決済機関のサーバ、および仮想店舗のサーバの動作を示すフローチャートである。
注文を受けた仮想店舗２４は、上記第１の送金方法のように支払内容を決済機関９０を介して利用者１２に通知するのではなく、ここでは支払内容を利用者１２に直接通知する。具体的には、仮想店舗２４のサーバ５０においては、注文の受信（Ｓ６０１）後、データ処理部５０１は仮想店舗２４の加盟店番号と請求金額などの請求内容をインターネット６０を介して利用者１２の携帯電話機１３またはパーソナルコンピュータ４０に送信する（Ｓ６２０）。利用者１２の携帯電話機１３またはパーソナルコンピュータ４０においては、送受信部１３５またはモデム４０４がこれらを受信する（Ｓ３１２）。
利用者１２は通知された請求内容を見て携帯電話機１３を操作し、メニュー画面から「送金」を選択する（Ｓ９７）。図６６に示したステップＳ９９〜１０３，Ｓ１７５，Ｓ１７６，Ｓ２６５，Ｓ２００と同様に、利用者１２はパスワードおよび顧客番号を入力し、携帯電話機１３はこれらをキーコードとともに決済機関９０に送信し、決済機関１２はこれらを受信する。
続いて、図６９に示したステップＳ５０２，Ｓ５０３，Ｓ１３１４，Ｓ６０３，Ｓ６０４，Ｓ３０２，Ｓ３０３，Ｓ５１１，Ｓ５１２，Ｓ５２２〜Ｓ５２４，Ｓ２７４，Ｓ１５９，Ｓ６１３と同様に、決済機関９０は認証を行ない、ステップＳ５１１，Ｓ５１２でキーコードおよびパスワードの両方が一致した場合、具体的な送金内容を入力するよう利用者１２に要求する。利用者１２はこの要求に応じて具体的な送金内容を入力して決済機関９０に送信する。
具体的には、決済機関９０のサーバ９２においては、データ処理部９２１が送金内容の要求を利用者１２の携帯電話機１３に送信する（Ｓ１３４７）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０からインターネット６０を介して送信された送金内容の要求を携帯電話機１３に転送する（Ｓ２７６）。
利用者１２の携帯電話機１３においては、送受信部１３５が決済機関９０から携帯電話会社１０を介して送信された送金内容の要求を受信する（Ｓ４３３）。
続いて、入力装置１３６は利用者１２の操作に応じて入力された送金内容をデータ処理部１３１に与え、送受信部１３５はその入力された送金内容を決済機関９０に送信する（Ｓ４３４）。送金内容としては、送金先の加盟店番号、送金金額などがある。携帯電話会社１０のサーバ３０においては、データ処理部３０１が携帯電話機１３から送信された送金内容を決済機関９０に転送する（Ｓ２７７）。決済機関９０のサーバ９２においては、データ処理部９２１が携帯電話機１３から携帯電話会社１０を介して送信された送金内容を受信する（Ｓ１３４８）。以降は、図７０に示したステップＳ１３４３，Ｓ２７５，Ｓ４３１，Ｓ４３２，Ｓ１３２０〜Ｓ１３２２，Ｓ１３４５，Ｓ１３４６，Ｓ６１９と同じであるから、その説明は繰返さない。ただしここでは、図６８に示した請求履歴９１８はないので請求履歴の更新（Ｓ１３４４）は行なわれない。
３．実在店舗での決済
次に、実在店舗での決済について説明する。ここでは、仮想口座からの振替えが可能な小口口座をさらに設け、その小口口座の使用を可能にするワンタイムＩＤ（識別子）を発行する。
３−１．ワンタイムＩＤの発行（小口口座への振替え）
図７４および図７５は、この発明の第４の実施の形態に従ってワンタイムＩＤの発行方法を示す概念図である。図７４は小口決済履歴がない場合を示し、図７５は小口決済履歴がある場合を示す。ここでは、決済機関９０のサーバ９２に設けられたデータベース９２２に、小口口座の入出金履歴９１５が記録される。図７６および図７７は、図７４および図７５に示した場合における、携帯電話機、携帯電話会社のサーバ、および決済機関のサーバの動作を示すフローチャートである。
実在店舗で決済をするために仮想口座から小口口座に所望の金額を振替えようとする場合、利用者１２は携帯電話機１３を操作し、メニュー画面で「ワンタイムＩＤ」を選択する（Ｓ９６）。具体的には、携帯電話機１３において、入力装置１３６が利用者１２の操作に応じて「ワンタイムＩＤ」の選択信号をデータ処理部１３１に与える。以降、ステップＳ９９〜Ｓ１０３，Ｓ１７５は図６６に示したものと同じであるから、その説明は繰返さない。
顧客番号の入力（Ｓ１７５）後、携帯電話機１３においては、送受信部１３５が顧客番号、キーコード、パスワードおよび小口口座情報を決済機関９０に送信する（Ｓ１８５）。小口口座情報には、ＲＡＭ１３２に記録されている小口口座残高および小口決済履歴が含まれる。但し、初めてワンタイムＩＤを要求する場合、小口決済履歴はまだ存在していない。以降、ステップＳ２６５〜Ｓ２６７，Ｓ２００，Ｓ２０２〜Ｓ２０５，Ｓ２５０，Ｓ２５１，Ｓ１５０〜Ｓ１５２，Ｓ１１０，Ｓ１１１は図６６に示したものと同じであるから、その説明は繰返さない。
利用者１２の認証（Ｓ２０３）の結果、キーコードおよびパスワードが共に一致し、かつ利用状況の確認（Ｓ２０４）の結果、利用状況が「利用可」の場合、決済機関９０は利用者１２に対して仮想口座から小口口座への振替金額を要求する。具体的には、決済機関９０のサーバ９２において、データ処理部９２１が小口口座への希望振替金額の要求を利用者１２の携帯電話機１３に送信する（Ｓ１３５０）。このとき、振替可能な限度額（通常は仮想口座の残高）も併せて送信する。携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０からインターネット６０を介して送信された振替金額の要求を携帯電話機１３に転送する（Ｓ２７８）。
利用者１２の携帯電話機１３においては、送受信部１３５が決済機関９０から携帯電話会社１０を介して送信された振替金額の要求を受信する（Ｓ１８６）。
この要求に応じ、利用者１２は携帯電話機１３の入力装置１３６を操作して所望の振替金額を指定する（Ｓ１８７）。入力装置１３６は利用者１２により指定された振替金額をデータ処理部１３１に与える。
データ処理部１３１はステップＳ１８７で指定された決済金額をステップＳ１８６で受信した限度額と比較し、指定された決済金額が限度額以内か否かを判定する（Ｓ１８８）。指定された振替金額が限度額を超えている場合、データ処理部１３１は振替不可を表示装置１３７に表示する（Ｓ１８９）。一方、指定された振替金額が限度額以内の場合、送受信部１３５はその指定された振替金額を決済機関９０に送信する（Ｓ１９０）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が利用者１２の携帯電話機１３から送信された振替金額をインターネット６０を介して決済機関９０に転送する（Ｓ２７９）。
決済機関９０のサーバ９２においては、データ処理部９２１が利用者１２の携帯電話機１３から携帯電話会社１０を介して送信された振替金額を受信し（Ｓ１３５１）、さらにランダムにワンタイムＩＤを生成する（Ｓ１３５２）。
続いて、データ処理部９２１はステップＳ１３５１で受信した振替金額に基づいて、仮想口座の入出金履歴９１２を更新し（Ｓ１３２０）、仮想口座の決済履歴９１４を更新し（Ｓ１３２１）、仮想口座１１０の残高を更新し（Ｓ１３２２）、さらに小口口座の入出金履歴９１５を更新する（Ｓ１３４５）。
たとえば図７４に示すように利用者１２が振替金額を１０００円に指定した場合、仮想口座の入出金履歴９１２には１０００円が小口口座に出金された旨が記録される。また、仮想口座１１０の残高は１０００円減額され、小口口座の残高は１０００円増額される。さらに、小口口座の入出力履歴９１５には１０００円が入金された旨が記録される。この場合、小口決済履歴は携帯電話機１３から送信されて来ないので、仮想口座の決済履歴９１４は更新されない。
次に、図７５に示すように携帯電話機１３の小口決済履歴に３００円を使用した旨が記録されている（つまり携帯電話機１３の小口口座残高が７００円になっている）場合において利用者１２が振替金額を１５００円に指定したときは、この振替金額（１５００円）と現在の小口口座残高（７００円）との差額（８００円）が計算され、仮想口座の入出力履歴９１２には８００円が出金された旨が記録される。また、携帯電話機１３の小口決済履歴に基づいて仮想口座の決済履歴９１４には３００円が決済に使用された旨が記録される。また、上記差額に基づいて仮想口座１１０の残高は８００円減額され、２００円になる。小口口座から３００円が決済に使用されたが、新たに８００円が小口口座に振替えられるので、小口口座の残高は上記振替金額に等しい１５００円になる。また、小口口座の入出金履歴９１５には携帯電話機１３の小口決済履歴に基づいて３００円が出金された旨が記録され、さらに上記差額に基づいて８００円が入金された旨が記録される。
最後に、データ処理部９２１はステップＳ１３５２で生成したワンタイムＩＤや小口口座残高などの振替内容を利用者１２の携帯電話機１３に送信する（Ｓ１３５３）。携帯電話会社１０のサーバ３０においては、データ処理部３０１が決済機関９０からインターネット６０を介して送信された振替内容を携帯電話機１３に転送する（Ｓ２８０）。
利用者１２の携帯電話機１３においては、送受信部１３５が決済機関９０から携帯電話会社１０を介して送信された振替内容を受信する（Ｓ１１９）。
続いて、データ処理部１３１はＲＡＭ１３２に記録されている小口決済履歴をクリアする（Ｓ１９２）。続いて、データ処理部１３１は、ＲＡＭ１３２に記録されている小口口座残高を書替え（Ｓ１９３）、さらにＲＡＭ１３２に記録されているワンタイムＩＤを書替える（Ｓ１９４）。
たとえば図７４に示した場合、決済機関９０で生成された「９８７６５」のワンタイムＩＤが携帯電話機１３のＲＡＭ１３２に記録される。また、利用者１２が指定した振替金額に従って小口口座残高が「０円」から「１０００円」に更新される。また、図７５に示した場合、決済機関９０で生成された「３４５６７」の新しいワンタイムＩＤが携帯電話機１３のＲＡＭ１３２に記録される。また、決済機関９０で計算された「１５００円」の新しい小口口座残高が携帯電話機１３のＲＡＭ１３２に記録される。
最後に、データ処理部１３１は小口口座残高とともに小口口座への入金完了を表示装置１３７に表示する（Ｓ１９５）。
３−２．ワンタイムＩＤの使用（小口口座からの支払い）
図７８は、この発明の第４の実施の形態に従い、ワンタイムＩＤを使用して実在店舗で決済する方法を示す概念図である。図７９は、図７８に示した場合における、携帯電話機、実在店舗のＰＯＳ端末、および決済機関のサーバの動作を示すフローチャートである。
小口口座に所望の金額を振替えてワンタイムＩＤを獲得した後、実在店舗２６で決済を行なう場合、利用者１２は携帯電話機１３を操作し、メニュー画面で「支払い」を選択する（Ｓ９５）。具体的には、携帯電話機１３において、入力装置１３６が利用者１２の操作に応じて「支払い」の選択信号をデータ処理部１３１に与える。以降、ステップＳ９９〜Ｓ１０３は図６６に示したものと同じであるから、その説明は繰返さない。
パスワードの検証（Ｓ１０２）後、データ処理部１３１はＲＡＭ１３２に記録されているワンタイムＩＤが有効か否かを判定する（Ｓ７３５）。ワンタイムＩＤには有効日が付与されており、小口口座の残高はその有効日までしか実在店舗での決済に使用することができない。ワンタイムＩＤは実在店舗での決済に１回使用すれば無効になるようにしてもよい。
ワンタイムＩＤが無効な場合、データ処理部１３１はその旨を表示装置１３７に表示する（Ｓ７３６）。一方、ワンタイムＩＤが有効な場合、データ処理部１３１は小口口座からの支払いが可能である旨を表示装置１３７に表示する（Ｓ７３７）。以降、ステップＳ７１６〜Ｓ７１９，Ｓ８０１は図５９に示したものと同じであるから、その説明は繰返さない。
残高検証（Ｓ７１８）の結果、ＰＯＳ端末２７から送信された決済金額が小口口座の残高以内の場合、携帯電話機１３のインターフェイス部１３９はＰＯＳ端末２７にＲＡＭ１３２に記録されているワンタイムＩＤを送信する（Ｓ７３８）。
続いて、データ処理部１３１はＲＡＭ１３２に記録されている小口決済履歴を更新する（Ｓ７３９）。具体的には、データ処理部１３１は、ＰＯＳ端末２７から送信された決済金額、決済日、実在店舗２６の加盟店番号などを記憶する。
続いて、データ処理部１３１はＲＡＭ１３２に記録されている小口口座の残高を更新する（Ｓ７４０）。具体的には、データ処理部１３１は、小口口座の残高から決済金額を減算して新しい残高を記録する。この時点で、携帯電話機１３の小口口座の残高は決済機関９０の小口口座の残高とずれる。
最後に、データ処理部１３１は小口口座の新しい残高とともに決済の完了を表示装置１３７に表示する（Ｓ７４１）。
実在店舗２６のＰＯＳ端末２７においては、インターフェイス部２７６が携帯電話機１３から送信されたワンタイムＩＤを受信する（Ｓ８１０）。
続いて、データ処理部２７１はその決済金額に基づいて売上計上処理を実行する（Ｓ８１１）。
続いて、インターフェイス部２７６は、加盟店番号とともにワンタイムＩＤ、決済日、決済金額、顧客番号などの決済内容を決済機関９０に送信する（Ｓ８０５）。
決済機関９０のサーバ９２においては、データ処理部９２１がＰＯＳ端末２７から送信された決済内容を受信し（Ｓ１３３３）、その受信した決済内容に基づいて加盟店の入金履歴９２０を更新する（Ｓ１３５５）。
続いて、データ処理部９２１はその支払を承認した旨の通知を実在店舗２６に送信する（Ｓ１３２４）。実在店舗２６のＰＯＳ端末２７は、決済機関９０から送信された支払承認の通知を受信する（Ｓ８０６）。
最後に、データ処理部９２１はたとえば月末に１ヶ月間の総支払金額を計算し、実在店舗２６に対する支払処理を実行する（Ｓ１３２５）。
上述した第４の実施の形態では、携帯電話会社１０のサーバ３０が携帯電話機１３から送信されたキーコードをそのまま決済機関９０のサーバ９２に転送しているが、携帯電話機１３から送信されたキーコードをこれと１対１に対応する別のキーコードに変換して決済機関９０のサーバ９２に送信するようにしてもよい。
また、小口口座への振替えの際にワンタイムＩＤをダウンロードするようにしているが、利用者１２が携帯電話機１３で決済機関９０が提供するサービスサイトにアクセスする度に自動的に新しいワンタイムＩＤをダウンロードするようにしてもよい。この場合、ワンタイムＩＤの更新頻度が増すため、セキュリティがさらに高くなる。
また、ワンタイムＩＤを１次元または２次元バーコードのイメージとし、実在店舗での決済の際には携帯電話機１３に表示されたバーコードをＰＯＳ端末２７のリーダで光学的に読取るようにしてもよい。この場合、携帯電話機１３から情報を読取るための専用機器をＰＯＳ端末２７に取付ける必要はなく、既存のバーコードリーダを用いればよい。また、小口口座の残高をワンタイムＩＤのバーコードに付加してもよい。
この発明の第４の実施の形態によれば、決済機関９０が携帯電話機１３から出力されるキーコードを取得し、利用者１２の認証を行なっているため、認証を携帯電話会社１０に依存することはない。そのため、決済会社９０だけで本サービスを提供することができる。
また、仮想口座とは別に小口口座を設け、実在店舗で決済する際には予め仮想口座から小口口座に振替えを行なっておき、小口口座から代金を支払うようにしているため、上記第１〜第２の実施の形態のように仮想口座の残高が真の残高からずれることはない。また、決済機関が小口口座からの出金を可能にするためのワンタイムＩＤを発行し、ワンタイムＩＤが有効でかつ決済金額が小口口座の残高以内の場合だけ携帯電話機１３からＰＯＳ端末２７にワンタイムＩＤが出力され、ＰＯＳ端末２７はこのワンタイムＩＤに基づいて決済を完了するようにしているため、セキュリティが高くなる。
上記各コンピュータには所定のプログラムがインストールされている。この各プログラムは、フローチャートで示した各列に並ぶ一連のステップを対応のコンピュータに実行させるためのものである。各プログラムはＣＤ−ＲＯＭのようなコンピュータ読取可能な媒体に記録して配布可能である。
今回開示された実施の形態はすべての点で例示であって制限的なものではないと解釈されるものである。本発明の範囲は上述した実施の形態ではなく特許請求の範囲によって定められ、特許請求の範囲と均等の意味およびその範囲内でのすべての変更が含まれることを意図するものである。
産業上の利用可能性
この発明は、携帯電話機を用いた決済サービスに適用可能である。
【図面の簡単な説明】
図１は、この発明の第１の実施の形態に従って仮想口座に入金する前払金額を通話料と併せて支払う場合の資金移動を示す概略図である。
図２は、この発明の第１の実施の形態に従って仮想口座に入金する前払金額をクレジットカードで支払う場合の資金移動を示す概略図である。
図３は、この発明の第１の実施の形態に従って仮想口座に入金する前払金額をデビットカードで支払う場合の資金移動を示す概略図である。
図４は、この発明の第１の実施の形態に従って仮想口座に入金する前払金額を銀行口座から自動引落しする場合の資金移動を示す概略図である。
図５は、この発明の第１の実施の形態に従って携帯電話機を用いてインターネット上の仮想店舗で決済する方法を示す概略図である。
図６は、この発明の第１の実施の形態に従って携帯電話機を用いて実在店舗で決済する方法を示す概略図である。
図７は、図１〜図４に示したように仮想口座に前払金を入金するために用いられる、携帯電話機および携帯電話会社のサーバのハードウェア構成を示すブロック図である。
図８は、図１に示した場合における、図７に示した携帯電話機および携帯電話会社のサーバの動作を示すフローチャートである。
図９は、図８に示した携帯電話機の動作中に表示される画面の遷移図である。
図１０は、図２に示した場合における、図７に示した携帯電話機および携帯電話会社のサーバの動作を示すフローチャートである。
図１１は、図１０に示した携帯電話機の動作中に表示される画面の遷移図である。
図１２は、図３に示した場合における、図７に示した携帯電話機および携帯電話会社のサーバの動作を示すフローチャートである。
図１３は、図１２に示した携帯電話機の動作中に表示される画面の遷移図である。
図１４は、図４に示した場合における、図７に示した携帯電話機および携帯電話会社のサーバの動作を示すフローチャートである。
図１５は、図１４に示した携帯電話の動作中に表示される画面の遷移図である。
図１６は、この発明の第１の実施の形態に従ってインターネット上の仮想店舗で携帯電話機を用いて決済する場合に用いられる、携帯電話機、携帯電話会社のサーバ、パーソナルコンピュータ、および仮想店舗のサーバのハードウェア構成を示すブロック図である。
図１７は、図５に示した場合における図１６に示したパーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、および仮想店舗のサーバの動作を示すフローチャートである。
図１８は、図１７に続くフローチャートである。
図１９は、図１７および図１８に示した携帯電話機の動作中に表示される画面の遷移図である。
図２０は、図６に示した場合に用いられる、携帯電話機、携帯電話会社のサーバ、および実在店舗のＰＯＳ端末のハードウェア構成を示すブロック図である。
図２１は、図２０に示した携帯電話機、実在店舗のＰＯＳ端末、および携帯電話会社のサーバの動作を示すフローチャートである。
図２２は、図２１に続くフローチャートである。
図２３は、図２１および図２２に示した携帯電話機の動作中に表示される画面の遷移図である。
図２４は、携帯電話機のＲＡＭおよびＲＯＭに記憶される情報を示す図である。
図２５は、この発明の第２の実施の形態に従って実在口座から仮想口座に振替える場合の資金移動を示す概略図である。
図２６は、図２５に示したように実在口座から仮想口座への振替に用いられる携帯電話機、携帯電話会社のサーバおよび金融機関のサーバのハードウェア構成を示すブロック図である。
図２７は、図２５に示した場合における、図２６に示した携帯電話機、携帯電話会社のサーバ、および金融機関のサーバの動作を示すフローチャートである。
図２８は、図２７に続くフローチャートである。
図２９は、図２７および図２８に示した携帯電話機の動作中に表示される画面の遷移図である。
図３０は、この発明の第２の実施例に従って携帯電話機を用いてインターネット上の仮想店舗で決済する方法を示す概略図である。
図３１は、図３０に示した場合に用いられるパーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、金融機関のサーバ、決済機関のサーバ、および仮想店舗のサーバのハードウェア構成を示すブロック図である。
図３２は、図３０に示した場合における、図３１に示したパーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、仮想店舗のサーバ、および金融機関サーバの動作を示すフローチャートである。
図３３は、図３２に続くフローチャートである。
図３４は、図３３に続くフローチャートである。
図３５は、図３２〜図３４に示した携帯電話機の動作中に表示される画面の遷移図である。
図３６は、この発明の第２の実施の形態に従って携帯電話機を用いて実在店舗で決済する方法を示す概略図である。
図３７は、図３６に示した場合に用いられる、携帯電話機、実在店舗のＰＯＳ端末、携帯電話会社のサーバ、金融機関のサーバ、および決済機関のサーバのハードウェア構成を示すブロック図である。
図３８は、図３６に示した場合における、図３７に示した携帯電話機、ＰＯＳ端末、携帯電話会社のサーバ、金融機関のサーバの動作を示すフローチャートである。
図３９は、図３８に続くフローチャートである。
図４０は、図３９に続くフローチャートである。
図４１は、この発明の第３の実施の形態に従ってサービスの利用者情報を登録する方法を示す概略図である。
図４２は、この発明の第３の実施の形態に従って仮想口座に前払金額を入金する場合の資金移動を示す概略図である。
図４３は、この発明の第３の実施の形態に従って携帯電話機を用いてインターネット上の仮想店舗で決済する方法を示す概略図である。
図４４は、この発明の第３の実施の形態に従って携帯電話機を用いて実在店舗で決済する方法を示す概略図である。
図４５は、この発明の第３の実施の形態に従って決済機関が利用者に対して携帯電話機に蓄積されている未通知データを要求する方法を示す概略図である。
図４６は、この発明の第３の実施の形態に従って携帯電話機を用いてインターネット上の仮想店舖で決済する場合において決済機関が金融機関に対する請求を代行する方法を示す概略図である。
図４７は、図４１に示した利用登録に用いられる、携帯電話機、携帯電話会社のサーバおよび決済機関のサーバのハードウェア構成を示すブロック図である。
図４８は、図４１に示した場合における、図４７に示した携帯電話機、携帯電話会社のサーバおよび決済機関のサーバの動作を示すフローチャートである。
図４９は、図４２に示した仮想口座への資金移動に用いられる、携帯電話機、携帯電話会社のサーバ、決済機関のサーバおよび金融機関のサーバのハードウェア構成を示すブロック図である。
図５０は、図４２に示した場合における、図４９に示した携帯電話機、携帯電話会社のサーバおよび決済機関のサーバの動作を示すフローチャートである。
図５１は、図５０に続くフローチャートである。
図５２は、図５１に続くフローチャートである。
図５３は、図４３に示した仮想店舗での決済に用いられる、パーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、決済機関のサーバおよび仮想店舗のサーバのハードウェア構成を示すブロック図である。
図５４は、図４３に示した場合における、図５３に示したパーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、決済機関のサーバおよび仮想店舗のサーバの動作を示すフローチャートである。
図５５は、図５４に続くフローチャートである。
図５６は、図５５に続くフローチャートである。
図５７は、図４４に示した実在店舗での決済に用いられる、携帯電話機、ＰＯＳ端末、携帯電話会社のサーバおよび決済機関のサーバのハードウェア構成を示すブロック図である。
図５８は、図４４に示した場合における、図５７に示した携帯電話機、ＰＯＳ端末、携帯電話会社のサーバおよび決済機関のサーバの動作を示すフローチャートである。
図５９は、図５８に続くフローチャートである。
図６０は、図５９に続くフローチャートである。
図６１は、図４５に示した未通知データの要求の場合における、携帯電話機、携帯電話会社のサーバおよび決済機関のサーバの動作を示すフローチャートである。
図６２は、図４６に示した請求代行に用いられる、パーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、決済機関のサーバ、金融機関のサーバおよび仮想店舗のサーバのハードウェア構成を示すブロック図である。
図６３は、図４６に示した場合における、図６２に示したパーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、決済機関のサーバ、金融機関のサーバおよび仮想店舗のサーバの動作を示すフローチャートである。
図６４は、図６３に続くフローチャートである。
図６５は、この発明の第４の実施の形態に従う前払方法を示す概略図である。
図６６は、図６５に示した場合における、携帯電話機、携帯電話会社のサーバ、および決済機関のサーバの動作を示すフローチャートである。
図６７は、図６６に続くフローチャートである。
図６８は、この発明の第４の実施の形態に従う第１の送金方法を示す概念図である。
図６９は、図６８に示した場合における、パーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、決済機関のサーバ、および仮想店舗のサーバの動作を示すフローチャートである。
図７０は、図６９に続くフローチャートである。
図７１は、この発明の第４の実施の形態に従う第２の送金方法を示す概念図です。
図７２は、図７１に示した場合における、パーソナルコンピュータ、携帯電話機、携帯電話会社のサーバ、決済機関のサーバ、および仮想店舗のサーバの動作を示すフローチャートである。
図７３は、図７２に続くフローチャートである。
図７４は、この発明の第４の実施の形態に従って、小口決済履歴がない場合におけるワンタイムＩＤの発行方法を示す概念図である。
図７５は、この発明の第４の実施の形態に従って、小口決済履歴がある場合におけるワンタイムＩＤの発行方法を示す概念図である。
図７６は、図７４および図７５に示した場合における、携帯電話機、携帯電話会社のサーバ、および決済機関のサーバの動作を示すフローチャートである。
図７７は、図７６に続くフローチャートである。
図７８は、この発明の第４の実施の形態に従い、ワンタイムＩＤを使用して実在店舗で決済する方法を示す概念図である。
図７９は、図７８に示した場合における、携帯電話機、実在店舗のＰＯＳ端末、および決済機関のサーバの動作を示すフローチャートである。Technical field
The present invention relates to a mobile phone and a payment method using the mobile phone, and more particularly to a service that mediates payment in a virtual store or a real store on the Internet.
Background art
Currently, various settlement methods using a mobile phone have been proposed. Nikkei Electronics "Settlement with mobile phone" No. 769, issued by Nikkei BP (May 8, 2000), pages 109 to 129, describes a mobile phone equipped with an IC card. In this mobile phone, a credit card number is recorded in advance in a secure state on an IC card, and the credit card number is encrypted and transmitted at the time of settlement. A mobile phone equipped with a reader / writer for a non-contact type IC card is also described. In this cellular phone, an electronic value such as the frequency of a prepaid card is downloaded and transferred to a non-contact type IC card by a reader / writer via wireless. The user uses this contactless IC card to make a payment.
The mobile phone equipped with the IC card encrypts the credit card number. However, since the credit card number is still transmitted, it cannot be said that the electronic commerce on the Internet provides sufficient security.
On the other hand, in a mobile phone equipped with the reader / writer, the user must carry a non-contact IC card with the mobile phone. Also, the reader / writer has many problems such as large size and high cost.
In addition, various payment methods using a mobile phone have been proposed, but all require credit reference at the time of payment or transmission of payment data, so it is necessary to skip the radio wave at the time of payment. There is a problem that it cannot be used outside the service area and it takes time to settle.
Disclosure of the invention
The present invention has been made to solve the above-described problems, and an object of the present invention is to provide a mobile phone with high security and ease of use and a settlement method using the mobile phone.
A settlement method using a mobile phone according to the present invention is a method of mediating settlement between a seller and a buyer who is a user of a mobile phone, and an account for accumulating user money is provided for each user. The server computer receives the amount transmitted from the mobile phone, deposits the received amount into the user's account and updates the balance of the account, and transmits the updated account balance to the mobile phone. A step of receiving the payment amount, subtracting the received payment amount from the account balance, and paying the received payment amount to the seller. The server computer here can be installed in a mobile phone station (company), a financial institution (company), a settlement institution (company), or the like, but its position is not particularly limited.
On the other hand, the mobile phone according to the present invention is a mobile phone used for settlement between the seller and the buyer who is the user of the mobile phone, and an account for storing the money of the user is stored in the server computer for each user. A means for inputting a desired amount to be deposited into an account in response to a user operation, and transmitting the entered amount to a mobile phone station computer and receiving a balance of a virtual account transmitted from a server computer Transmitting and receiving means, and means for storing the balance of the received account.
According to this settlement method or mobile phone, the user transmits a desired amount to the financial institution or the settlement organization through the mobile phone station or the mobile phone station using the mobile phone. The mobile phone station, financial institution or settlement organization receives the amount transmitted from the mobile phone, deposits the amount into the user's account, updates the account balance, and transmits it to the mobile phone. The mobile phone receives and stores the account balance transmitted from the mobile phone station. Therefore, the user can make a payment by using the mobile phone like a wallet. Here, since there is no need to transmit a credit number or the like, the security is high. In addition, since it is not necessary to carry an IC card or the like, it is easy to use.
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference numerals, and description thereof will not be repeated.
[First Embodiment]
1. Service overview
The embodiment of the present invention relates to a computer system for realizing a new service provided by a mobile phone company (referred to as “wallet service”, hereinafter simply referred to as “this service”). This service allows mobile phones to be used like a wallet. The outline of this service will be described below.
When purchasing a mobile phone, a credit card number or cash card number is registered with the mobile phone company in addition to the bank account from which the call charge is deducted. A mobile phone company establishes a virtual account for each mobile phone user. A user requests a mobile phone company using a mobile phone to deposit a prepayment into a virtual account before settlement. The mobile phone company uses a bank account, a credit card number, a cash card number, and the like registered in advance to request a prepayment from the user. The user can select the payment method of the prepayment. After requesting the advance payment, the mobile phone company deposits the advance payment into the virtual account and transmits the balance of the virtual account to the mobile phone. The mobile phone stores the balance of the transmitted virtual account. The user uses this mobile phone as a wallet to make a payment at a virtual store or a real store on the Internet. The store charges the mobile phone company.
2. Prepayment payment method
Next, four types of advance payment methods will be described.
2-1. When paying along with call charges
FIG. 1 is a schematic diagram showing fund transfer when a prepayment is paid together with a call charge. As shown in FIG. 1, a mobile phone company (mobile phone station) 10 is provided with a personal information database 11. In the personal information database 11, personal information of each user 12 is registered. Specifically, a virtual account 110 is provided for accumulating advance payments (advance payments for mobile phone companies). In addition to the telephone number of the mobile phone 13, an e-mail address, password, usage status, key code, account number Credit card numbers, debit card numbers, etc. are registered in advance.
First, the user 12 uses the mobile phone 13 to transmit a desired prepaid amount and a payment method (here, “add to call charge”) to the mobile phone company 10. At this time, the telephone number of the mobile phone 13 is also transmitted.
The mobile phone company 10 searches the personal information database 11 based on the transmitted mobile phone number and inquires about the usage status of the virtual account 110 of the user 12. If there is no problem with the user 12 (if the usage status is “OK”), the mobile phone company 10 adds the transmitted prepaid amount to the prepaid balance of the virtual account 110 and updates the updated prepaid balance. Send. On the other hand, when the payment of the user 12 is delayed or the use of this service is stopped, the usage status is “NG”. In this case, the mobile phone company 10 notifies the user 12 through the mobile phone 13 that this service cannot be used.
When the user 12 selects “add to call charge” as the payment method as described above, the mobile phone company 10 uses the service usage statement 15 together with the bill 14 of the basic charge and the call charge for the user. 12 to send.
The mobile phone company 10 requests the transaction bank 17 of the user 12 to withdraw the usage fee based on the account number registered in the personal information database 11. In response to this, the bank 17 transfers funds from the account 16 of the user 12 to the account 19 of the mobile phone company 10 established in the bank 18.
2-2. When paying by credit card
FIG. 2 is a schematic diagram showing the transfer of funds when the advance payment is made with a credit card. In this case, as shown in FIG. 2, the user 12 uses the mobile phone 13 to transmit the prepaid amount and its payment method (here, “credit card”) to the mobile phone company 10.
If there is no problem in the usage status of the user 12, the mobile phone company 10 requests approval from the credit sales company 20 based on a pre-registered credit card number. If the credit sales company 20 can approve, the credit card company 20 notifies the mobile phone company 10 to that effect. In response to this, the mobile phone company 10 updates the advance balance of the virtual account 110 and transmits the latest advance balance to the mobile phone 13. On the other hand, if approval is not possible, the credit sales company 20 notifies the mobile phone company 10 to that effect. In response to this, the mobile phone company 10 notifies the user 12 that payment by credit card cannot be made without updating the advance balance.
When the payment is approved, the credit sales company 20 transfers the prepayment amount desired by the user 12 to the account 19 of the mobile phone company 10. Next, the credit sales company 20 requests the bank 17 to withdraw the prepayment amount from the account 16 of the user 12. In response to this, the bank 17 transfers funds from the account 16 of the user 12 to the credit sales company 20.
2-3. When paying with a debit card
FIG. 3 is a schematic diagram showing the transfer of funds when the advance payment is made with a debit card. In this case, as shown in FIG. 3, the user 12 uses the mobile phone 13 to transmit the prepaid amount and its settlement method (here, “debit card”) to the mobile phone company 10.
If there is no problem in the usage status of the user 12, the mobile phone company 10 requests the bank 17 that issued the debit card to transfer funds based on a pre-registered debit card number. When the transfer request is approved, the bank 17 transmits the transfer data to the clearing center 21 and notifies the mobile phone company 10 of the completion of the transfer. In response to this, the cellular phone company 10 updates the receipt balance and transmits the latest receipt balance to the cellular phone 13. On the other hand, if the bank 17 does not approve the transfer request, the mobile phone company 10 is notified that the transfer cannot be made. In response to this, the mobile phone company 10 notifies the user 12 that the debit card cannot be paid without updating the prepaid balance.
The clearing center 21 performs transfer offsetting and aggregation based on transfer data transmitted from a number of banks in addition to the bank 17, and transmits settlement data between banks to the settlement bank 22. In response to this, the settlement bank 22 transfers funds from the bank 17 to the member store bank 23. In response to this, the member store bank 23 deposits the funds into the account 19 of the mobile phone company 10.
2-4. When paying by automatic withdrawal
FIG. 4 is a schematic diagram showing the transfer of funds when the advance payment is made by automatic debit from a bank account. In this case, as shown in FIG. 4, the user 12 uses the mobile phone 13 to transmit the prepaid amount and the payment method (here, “automatic withdrawal”) to the mobile phone company 10. If there is no problem in the usage status of the user 12, the cellular phone company 10 requests the bank 17 to withdraw funds based on the account number registered in advance. If the withdrawal is possible, the bank 17 notifies the mobile phone company 10 to that effect. In response to this, the cellular phone company 10 updates the receipt balance and transmits the latest receipt balance to the cellular phone 13. If the withdrawal is impossible, the bank 17 notifies the mobile phone company 10 to that effect. In response to this, the mobile phone company 10 notifies the user 12 that payment cannot be made. Upon receipt of the withdrawal request from the mobile phone company 10, the bank 17 immediately transfers funds from the account 16 of the user 12 to the account 19 of the mobile phone company 10. Apart from this, the usage statement 15 is sent to the user 12 together with the bill 14.
3. settlement
Next, a method for making a settlement with the above-described advance payment using the mobile phone 13 will be described.
3-1. Settlement at a virtual store on the Internet
FIG. 5 is a schematic diagram illustrating a method of making a payment using a mobile phone in a virtual store on the Internet. As shown in FIG. 5, first, the user 12 orders a product or service from the virtual store 24 on the Internet using the mobile phone 13 or the personal computer 40, and selects a settlement method (here, “mobile phone settlement”). . When using the personal computer 40, the user 12 manually inputs the telephone number of the mobile phone 13 into the personal computer 40 and transmits it to the virtual store 24 through the Internet 60.
The virtual store 24 that has received the order requests the mobile phone company 10 to charge the settlement amount based on the transmitted mobile phone number.
Upon receipt of the request, the mobile phone company 10 notifies the virtual store 24 that the service cannot be used if there is a problem with the usage status of the user 12. In response to this, the virtual store 24 notifies the user 12 that the service cannot be used. If there is no problem in the usage status of the user 12, the mobile phone company 10 transmits an electronic invoice by email to the mobile phone 13 of the user 12 based on the email address of the user 12 registered in advance. The electronic bill is for confirming payment from the virtual account 110 to the user 12.
Further, the user 12 who has received the electronic bill selects whether or not to approve the settlement. When the user 12 approves the settlement, the mobile phone 13 that has received the electronic invoice verifies the prepaid balance. If the prepaid balance is less than the settlement amount, the mobile phone 13 is unable to settle due to insufficient balance. The mobile phone company 10 is notified. In response to this, the mobile phone company 10 notifies the user 12 through the virtual store 24 that the payment cannot be made because the balance is insufficient. When the user 12 cancels or rejects the settlement, the mobile phone company 10 is notified of the cancellation of the settlement or the rejection of the settlement. In response to this, the mobile phone company 10 notifies the virtual store 24 that the payment cannot be made because the payment is canceled or rejected. In response to this, the virtual store 24 notifies the user 12 that payment cannot be made.
Further, when the user 12 approves the settlement, if the settlement amount is within the prepaid balance as a result of the verification of the prepaid balance, the mobile phone company 10 is notified that the settlement is accepted. At this time, a password, a mobile phone number, a key code and the like registered in advance with the mobile phone company 10 are also transmitted. The cellular phone company 10 searches the personal information database 11 based on the transmitted cellular phone number, and determines whether or not the transmitted password and key code respectively match the previously registered password and key code. . When the key codes do not match, the mobile phone company 10 notifies the user 12 that the service cannot be used because the key code is abnormal, and notifies the user 12 through the virtual store 24 that the payment cannot be made. If both match, the mobile phone company 10 subtracts the settlement amount from the prepaid balance of the virtual account 110 to update the prepaid balance, and transmits the updated prepaid balance to the mobile phone 13. In response to this, the mobile phone 13 updates the internal advance balance. In addition, the mobile phone company 10 notifies the virtual store 24 of the completion of payment. In response to this, the virtual store 24 notifies the user 12 of the completion of payment.
Thereafter, the virtual store 24 delivers the ordered product to the user 12 or provides the ordered service to the user 12. The mobile phone company 10 deposits the payment amount into the virtual store 24. The virtual store 24 pays the mobile phone company 10 a fee for using this service.
3-2. Settlement at a real store
FIG. 6 is a schematic diagram showing a method of making a payment using a mobile phone in an actual store. As shown in FIG. 6, in the actual store, the user 12 sets the mobile phone 13 in the reading device 270 connected to the POS terminal 27. The store clerk inputs the product amount into the POS terminal 27 and calculates the settlement amount. This settlement amount is transmitted from the POS terminal 27 to the mobile phone 13 through the reading device 270. The mobile phone 13 compares the balance stored inside with the settlement amount, and transmits an error to the POS terminal 27 if settlement is impossible. On the other hand, if payment is possible, the mobile phone 13 transmits the mobile phone number and the key code to the POS terminal 27. The mobile phone number cannot be directly input to the POS terminal 27 by hand.
The POS terminal 27 that has received the mobile phone number and the key code completes the settlement and notifies the mobile phone 13 to that effect. Upon completion of the settlement, the mobile phone 13 stores the settlement amount in the internal memory and the settlement mode is turned off. Thereafter, the user 12 removes the mobile phone 13 from the reading device 270.
Next, the mobile phone number and the key code are transmitted to the mobile phone company 10 together with the settlement amount. In response to this, the mobile phone company 10 subtracts the payment amount from the prepaid balance of the virtual account 110 to update the prepaid balance and notifies the POS terminal 27 of the completion of payment.
4). Hardware configuration
FIG. 7 is a block diagram showing a hardware configuration of the mobile phone 13 and a server computer (hereinafter simply referred to as a server) 30 installed in the mobile phone company 10.
As shown in FIG. 7, the mobile phone 13 includes a data processing unit 131 including a CPU, a RAM 132, a ROM 133 such as an EEPROM, an antenna 134, a transmission / reception unit 135, and an input device 136 such as a numeric keypad or a cursor key. A display device 137 such as a liquid crystal display, a battery 138, and an interface (I / F) unit 139. The mobile phone 13 is attached to the power adapter 140, current is supplied from the power adapter 140 to the battery 138 through the I / F unit 139, and the battery 138 is charged. The data processing unit 131 uses the RAM 132, the ROM 133, the transmission / reception unit 135, the input device 136, the display device 137, and the I / F unit 139 to perform a normal mobile phone function, and also executes a settlement function described later.
The server 30 installed in the mobile phone company 10 includes a data processing unit 301 composed of a CPU and a database 302. The database 302 includes a personal information database 11, a usage history database 28, and a payment history database 29. The data processing unit 301 uses the database 302 to execute a settlement function described later. The data processing unit 301 is connected to the radio base station 303. Radio waves are transmitted and received between the antenna 304 of the radio base station 303 and the antenna 134 of the mobile phone 13. The usage history database 28 is a log file for recording transaction details of data with the mobile phone 13. Specifically, the deposit / withdrawal date / time, deposit / withdrawal amount, balance, etc. of the virtual account 110 are recorded. The settlement history database 29 is a log file for recording transaction details of data with stores. Specifically, payment date and time, payment amount, etc. are recorded.
5. Processing action at the time of prepayment
5-1. When paying along with call charges
FIG. 8 is a flowchart showing the operations of the mobile phone 13 and the server 30 when the advance payment shown in FIG. 1 is paid together with the call charge. FIG. 9 is a transition diagram of a display screen displayed on the display device 137 of the mobile phone 13 in this case.
First, the data processing unit 131 of the mobile phone 13 displays the screen D1 shown in FIG. 9 on the display device 137 and prompts the user 12 to input a password. When the user 12 operates the input device 136 to input a password, the input device 136 gives the input password to the data processing unit 131 (S101).
Subsequently, the data processing unit 131 verifies the input password by comparing the input password with a password registered in advance in the RAM 132 or the ROM 133 (S102). If the input password is incorrect, the data processing unit 131 displays the screen D2 shown in FIG. 9 on the display device 137 (S103). On the other hand, if the input password is correct, the data processing unit 131 displays the screen D3 shown in FIG. 9 on the display device 137 and gives the user 12 “▲ 1 pay money”, “▲ 2 ▼ The user is prompted to select one from “Look inside wallet” and “(3) Put money into wallet”. When the user 12 operates the input device 136 and selects “(3) Put money in wallet”, the data processing unit 131 displays a screen D4 on the display device 137, and the user 12 makes a prepayment amount. Prompt for At this time, if there is no unnotified data (details will be described later), the prepaid balance stored in the RAM 132 is displayed as the current balance, and if there is unnotified data, the prepaid balance stored in the RAM 132 is not notified. The true prepaid balance is calculated by subtracting the settlement amount and displayed as the current balance. When the user 12 operates the input device 136 to input a desired advance payment amount, the input device 136 gives the input advance payment amount to the data processing unit 131 (S104).
Subsequently, the data processing unit 131 displays a screen D5 on the display device 137 and prompts the user 12 to select a payment method for the prepayment amount. When the user 12 operates the input device 136, in addition to the payment method “add to call charge”, several payment methods “credit”, “debit card”, and “automatic withdrawal” are displayed. Here, it is assumed that the user 12 selects the payment method “add to call charge”. In response to this, the input device 136 gives the data processing unit 131 a payment method selection of “add to call charge” (S105).
Subsequently, the data processing unit 131 gives the selected payment method and the input prepaid amount to the transmission / reception unit 135, and the transmission / reception unit 135 transmits them to the mobile phone company 10 (S106). At this time, the mobile phone number unique to the user 12 stored in advance in the ROM 133, the key code unique to the mobile phone 13 prestored in the ROM 133, and unreported data stored in the RAM 132 are combined. To send. The mobile phone number is programmed in advance in a ROM 133 such as an EEPROM when the mobile phone company 10 sells the mobile phone 13. When a mobile phone manufacturer manufactures a mobile phone, the key code is stored in advance in a ROM 133 such as an EEPROM such as a manufacturing number or a management number unique to each mobile phone (referred to as a subscriber ID (identifier), machine ID, terminal ID, etc.). To program. Accordingly, the mobile phone number is unique to the user 12, and the same mobile phone number can be registered even when the mobile phone 13 is replaced. However, the user 12 itself cannot rewrite the mobile phone number, and the mobile phone company 10 rewrites it at the request of the user 12. On the other hand, the key code is unique to the mobile phone 13. When the serial number is used as the key code, not only the user 12 but also the cellular phone company 10 cannot be rewritten. When the management number such as the above-mentioned subscriber ID is used for the key code, the cellular phone company 10 can rewrite it, but the user 12 cannot rewrite it.
Subsequently, the data processing unit 131 determines whether or not the processing so far has ended normally (S107). If the processing has not ended normally, the data processing unit 131 displays that fact on the display device 137 (S108) and establishes the connection. Disconnect (S109). On the other hand, if the process ends normally, the connection is temporarily disconnected without displaying the abnormal end (S109).
On the other hand, in the server 30 installed in the mobile phone company 10, the data processing unit 301 receives the prepaid amount, payment method, mobile phone number and key code transmitted from the mobile phone 13 through the radio base station 303 (S201). ).
Subsequently, the data processing unit 301 searches the personal information database 11 based on the received mobile phone number (S202).
Subsequently, the data processing unit 301 compares the received key code with the searched key code of the personal information database 11 and checks whether or not the key codes match (S203). If the key codes match, the data processing unit 301 checks the usage status of the personal information database 11 and determines whether there is a problem (S204). If the key codes do not match in step S202, or if there is a problem in the usage status in step S204, the data processing unit 301 transmits information indicating that the service cannot be used to the mobile phone 13 (S205).
In the mobile phone 13, the transmission / reception unit 135 receives the information indicating that the service cannot be used, transmitted from the mobile phone 13 (S110).
Subsequently, the data processing unit 131 displays the screen D6 shown in FIG. 9 on the display device 137 and notifies the user 12 that the service cannot be used (S111). Then, the data processing unit 131 displays on the display device 137 that the processing has ended abnormally (S112).
On the other hand, if there is no problem in the usage status in step S204, the usage history database 28 is updated (S206). Specifically, the current date and time, the current advance payment amount (prepaid amount for the user 12), the current advance receipt balance, and unnotified data (unnotified settlement amount) are recorded in the usage history database 28. To do.
Subsequently, the data processing unit 301 transmits the current advance balance to the mobile phone 13 (S207).
Subsequently, the data processing unit 301 creates billing data for the advance payment (S208).
Subsequently, the data processing unit 301 collectively adds the created billing data to the call charge every month, and issues the usage statement 15 of this service together with the bill 14 as shown in FIG.
The subsequent processing is the same as the existing processing, and requests the bank 12 of the user 12 to withdraw the fee based on the account number registered in the personal information database 11 of the user 12 (S209). In response to this, the usage fee for this service is transferred from the user's account 16 to the mobile phone company's account 19 together with the call fee.
In the mobile phone 13, the transmission / reception unit 135 receives the advance balance transmitted from the server 30 in step S207 (S113).
Subsequently, the data processing unit 131 stores the received advance balance as a prepaid balance in the RAM 132, thereby updating the advance balance (S116).
Subsequently, the data processing unit 131 displays the screen D7 shown in FIG. 9 on the display device 137 (S117). Specifically, the fact that the prepaid processing so far is completed and the current prepaid balance are displayed.
5-2. When paying by credit card
FIG. 10 is a flowchart showing the operations of the mobile phone 13 and the server 30 when paying the prepaid amount shown in FIG. 2 with a credit card. FIG. 11 is a transition diagram of screens displayed on the display device 137 of the mobile phone 13 in this case.
Unlike the above, when paying the prepayment amount with a credit card, the user 12 selects “credit (collective)” on the screen D5 shown in FIG. In response to this, the input device 136 gives the data processor 131 a payment method selection of payment by credit card (FIG. 10, S105).
Further, in the server 30 of the mobile phone company 10, if there is no problem in the usage situation, the credit sales company 20 is referred to the credit sales company 20 based on the credit card number registered in advance in the personal information database 11 (S210). ).
Subsequently, the data processing unit 301 determines whether or not the credit sales company 20 has approved the payment by the credit card based on the reply from the credit sales company 20 (S211).
In the case of non-approval, the data processing unit 301 transmits to the mobile phone 13 that payment cannot be made (S212). In the case of approval, the usage history database 28 is updated (S205).
On the other hand, in the mobile phone 13, when the transmission / reception unit 135 receives from the server 30 that credit card payment is not possible, the screen D8 shown in FIG. 12 is displayed on the display device 137, and credit card payment is not possible. The user 12 is notified that it is possible (S120).
5-3. When paying with a debit card
FIG. 12 is a flowchart showing the operations of the mobile phone 13 and the server 30 when paying the prepaid amount with a debit card. FIG. 13 is a transition diagram of screens displayed on the display device 137 of the mobile phone 13 in this case.
When the prepaid amount is paid with a debit card unlike the above, the user 12 selects “debit card” on the display screen D5 shown in FIG. In response to this, the input device 136 provides the selection information to the data processing unit 131 (S105).
On the other hand, in the server 30 of the mobile phone company 10, if there is no problem in the usage situation, the data processing unit 301 withdraws to the debit card issuing bank 17 based on the debit card number registered in the personal information database 11 in advance. (Approval) request is transmitted (S220). In response to this, the existing debit card process is executed (S221).
Subsequently, the data processing unit 301 determines whether or not the transfer is completed based on the transfer result transmitted from the debit card issuing bank 17 (S222). If the transfer cannot be made, the data processing unit 301 transmits the fact to the mobile phone 13 (S212).
In response to this, the data processing unit 131 of the mobile phone 13 displays the screen D9 shown in FIG. 13 on the display device 137 (S120), and notifies the user 12 that payment by the debit card cannot be performed.
5-4. When paying immediately with automatic withdrawal
FIG. 14 is a flowchart showing operations of the mobile phone 13 and the server 30 when the prepayment amount shown in FIG. 4 is automatically withdrawn from the user's account 16. FIG. 15 is a transition diagram of screens displayed on the display device 137 of the mobile phone 13 in this case.
Unlike the above, in the case of automatic withdrawal, the user 12 selects “automatic withdrawal” on the screen D5 shown in FIG. (S105).
On the other hand, in the server 30, when there is no problem in the usage situation, the data processing unit 301 inquires of the bank 12 of the user 12 whether or not the received prepaid amount can be withdrawn (S230).
Subsequently, the data processing unit 301 determines whether or not withdrawal is possible based on the inquiry result returned from the bank 17 (S231). If the withdrawal is impossible, the data processing unit 301 transmits that fact to the mobile phone 13 (S232).
In response to this, the data processing unit 131 of the mobile phone 13 displays the screen D10 shown in FIG. 15 (S120), and the user 12 indicates that the desired prepaid amount cannot be withdrawn from the user's account 16. Notify
On the other hand, if the withdrawal is possible, the cellular phone company 10 requests the bank 17 to withdraw using an existing method (S223).
6). Processing action at the time of settlement
Next, an operation in the case where payment is made at a virtual store and a real store on the Internet using the mobile phone 13 will be described.
6-1. When paying at a virtual store
FIG. 16 shows a user's personal computer (PC) 40 and mobile phone 13, a mobile phone company server 30, and a virtual store server computer (hereinafter simply referred to as a server) 50 used when making a payment at a virtual store. It is a block diagram which shows a hardware configuration.
As shown in FIG. 16, the personal computer 40 of the user 12 includes a data processing unit 401 such as a CPU, a memory 402 such as ROM and RAM, a hard disk (HD) 403, a modem 404, a keyboard and a mouse. Input device 405 and a display device 406 such as a CRT display or a liquid crystal display. Similarly, the server 50 of the virtual store 24 includes a data processing unit 501, a memory 502, a hard disk 503, a modem 504, an input device 505, and a display device 506. The personal computer 40 is connected to the Internet 60 through a modem 404. Server 50 is also connected to Internet 60 through modem 504. The server 30 of the mobile phone company 10 is also connected to the Internet 60 through the modem 303.
17 and 18 are flowcharts showing operations of the personal computer 40, the mobile phone 13, and the servers 30 and 50 shown in FIG.
The user 12 operates the input device 405 of the personal computer 40 to place an order for goods and services in the virtual store 24, and selects mobile phone payment as the payment method. In response to this, the data processing unit 401 of the personal computer 40 transmits the input order information and mobile phone number to the server 50 of the virtual store 24 via the Internet 60 (S301).
The data processing unit 501 of the server 50 receives the transmitted order information and mobile phone number (S601).
Subsequently, the data processing unit 501 transmits the billing information such as the store name, the payment amount, and the mobile phone number to the server 30 of the mobile phone company 10 via the Internet 60, thereby allowing the mobile phone company 10 to pay the payment amount of the user 12. Is charged (S602).
The data processing unit 301 of the server 30 receives the transmitted billing information (S501).
Subsequently, the data processing unit 301 searches the personal information database 11 based on the received mobile phone number (S502).
Subsequently, the data processing unit 301 inquires the usage status from the searched personal information of the user 12 and confirms whether there is any problem (S503). If there is a problem, the data processing unit 301 transmits information indicating that the service cannot be used to the server 50. This notifies the virtual store 24 that the service cannot be used (S504). On the other hand, if there is no problem in the usage status, the data processing unit 301 specifies the email address of the user 12 from the retrieved personal information, and transmits the billing data to the mobile phone 13 by email (S505). This means that the mobile phone company 10 issues a bill to the user 12 on behalf of the virtual store 24. In the mobile phone 13 of the user 12, the transmission / reception unit 135 receives the billing data transmitted from the server 30 of the mobile phone company 10 (S401).
When the user 12 operates the input device 136 of the mobile phone 13 to select “received mail list”, the data processing unit 131 of the mobile phone 13 displays the screen D11 shown in FIG. 19 on the display device 137. When the user 12 operates the input device 136 to select an e-mail for billing data, the data processing unit 131 displays the screen D12 on the display device 137. This is an electronic invoice that displays the order date, the orderer (usually the same as the user 12), the invoicer (usually the same as the virtual store 24), and the invoice amount (usually the same as the settlement amount). .
The user 12 confirms the contents of the bill and selects “pay” if the user can agree, and selects “reject” if the user cannot agree. The input device 136 of the mobile phone 13 inputs selection information to the data processing unit 131 in accordance with such an operation of the user 12. The data processing unit 131 determines whether the payment is approved based on the input selection information (S402). If the payment is not approved, the transmission / reception unit 135 transmits payment cancellation / rejection information to the server 30 of the mobile phone 10 (S403). In this case, the data processing unit 131 displays the screen D13 shown in FIG. 19 on the display device 137 (S404).
In the server 30 of the mobile phone company 10, the data processing unit 301 receives the information on settlement cancellation / rejection transmitted from the mobile phone 13 (S506), and further transmits the information to the server 50 of the virtual store 24 (S507). ).
In the server 50 of the virtual store 24, the data processing unit 501 receives the payment cancellation / rejection information transmitted from the server 30 of the mobile phone company 10 (S605).
Subsequently, the data processing unit 501 transmits the received payment cancellation / rejection information to the personal computer 40 of the user 12 via the Internet 60, whereby the virtual store 24 informs the user 12 that the payment has been canceled or rejected. The user 12 is notified (S606).
In the personal computer 40 of the user 12, the data processing unit 401 receives the payment cancellation / rejection information transmitted from the server 50 of the virtual store 24 (S304), and the display device 406 indicates that the payment has been canceled or rejected. Display above.
When the payment is approved in step S402, the data processing unit 131 of the mobile phone 13 stores unnotified data in the RAM 132 (the date and time of payment that has not been notified to the mobile phone company 10 because payment was made at a store outside the radio wave range, payment) It is determined whether or not there is an amount etc. (details will be described later) (S405). When there is unnotified data, the data processing unit 131 calculates the accumulated unnotified amount by summing the unnotified settlement amounts (S406), and then subtracts the accumulated unnotified amount from the prepaid balance stored in the RAM 132. The true prepaid amount at the present time is calculated (S407).
If there is no unreported data in step S405 or after step S407, the data processing unit 131 verifies the prepaid balance and determines whether the settlement amount is within the prepaid balance (S408). If the settlement amount exceeds the prepaid balance, the data processing unit 131 displays the screen D14 shown in FIG. 19 on the display device 137 to notify the user 12 that the balance is insufficient (S409), and then the balance is insufficient. Is transmitted to the server 30 of the mobile phone company 10 by radio waves (S410).
In response to this, in the server 30 of the mobile phone company 10, the data processing unit 301 receives the shortage information transmitted from the mobile phone 13 (S 508). 24 to the server 50 (S509).
In the server 50 of the virtual store 24, the data processing unit 501 receives the shortage information transmitted from the server 30 of the mobile phone company 10 (S 607). To the personal computer 40 (S608). The personal computer 40 of the user 12 receives this balance shortage information and displays that fact on the display device 406 (S305).
On the other hand, if the payment amount is within the prepaid balance in step S408 on the mobile phone 13, the data processing unit 131 displays the screen D1 shown in FIG. 19 and prompts the user 12 to enter a password. When the user 12 inputs a password, the input device 136 gives the input password to the data processing unit 131 (S411).
Subsequently, the transmission / reception unit 135 transmits the payment approval information and the unnotified data to the server 30 of the mobile phone company 10 by radio waves (S412). Specifically, the telephone number of the cellular phone 13, the key code registered in advance in the ROM 133, the password input in step S411, and the unpaid payment amount are transmitted.
In the server 30 of the mobile phone company 10, the data processing unit 301 receives the payment approval information transmitted from the mobile phone 13 (S510).
Subsequently, the data processing unit 301 searches the personal information database 11 and specifies the personal information of the user 12 based on the received mobile phone number. The data processing unit 301 further compares the received key code with a key code registered in advance as personal information of the user 12, and determines whether or not the key codes match (S511). If the key codes match, the data processing unit 301 compares the received password with a password registered in advance as personal information of the user 12, and determines whether the passwords match (S512).
If the key code does not match or the password does not match, the data processing unit 301 transmits information indicating that the service cannot be used to the mobile phone 13 by radio waves, so that the mobile phone company 10 uses the service for the user 12. The fact that it is not possible is notified (S513).
In the mobile phone 13 of the user, the transmission / reception unit 135 receives the information indicating that the service cannot be used transmitted from the server 30 of the mobile phone company 10 (S413).
Subsequently, the data processing unit 131 displays on the display device 137 that the service cannot be used (S414).
Subsequently, the data processing unit 131 displays on the display device 137 that the service procedure has ended abnormally (S415).
On the other hand, in the mobile phone 13 of the mobile phone company 10, the data processing unit 301 transmits information indicating that payment is not possible to the server 50 of the virtual store 24 via the Internet 60 (S514).
In the server 50 of the virtual store 24, the data processing unit 501 receives the information indicating that payment is not possible transmitted from the server 30 of the mobile phone company 10 (S609).
In response to this, the data processing unit 501 transmits information indicating that payment is not possible to the personal computer 40 of the user 12 via the Internet 60, whereby the virtual store 24 notifies the user 12 that payment cannot be made (S610).
In the personal computer 40 of the user 12, the data processing unit 401 receives the non-settlement information transmitted from the server 50 of the virtual store 21 (S 306), and displays on the display device 406 that settlement is not possible.
On the other hand, in the server 30 of the mobile phone company 10, when the passwords match in step S512, the data processing unit 301 updates the usage history database 28 and updates the advance balance of the virtual account 110 of the user 12 ( S515). Specifically, the use history database 28 records the payment date and time, the payment amount, and the like.
Subsequently, the data processing unit 301 transmits the updated advance balance to the mobile phone 13 by radio waves (S516).
In the mobile phone 13, the data processing unit 131 receives the advance balance of the virtual account 110 transmitted from the server 30 of the mobile phone company 10 (S 416).
Subsequently, the data processing unit 131 updates the prepaid balance stored in the RAM 132 so as to be the same as the received balance of the received virtual account, and further clears unnotified data stored in the RAM 132 (S417). . As a result, the prepaid balance in the mobile phone 13 and the prepaid balance of the virtual account 110 in the mobile phone company are synchronized.
Then, the data processing unit 131 displays the screen D15 shown in FIG. 19 on the display device 137 and notifies the user 12 that the settlement has been completed.
The server 30 of the mobile phone company 10 transmits the payment completion information to the server 50 of the virtual store 24 via the Internet 60 after the above step S516, whereby the mobile phone company 10 notifies the virtual store 24 that the payment has been completed. (S517). Then, the mobile phone company 10 pays the settlement amount to the virtual store 24 by an existing method (S518).
On the other hand, in the server 50 of the virtual store 24, the data processing unit 501 receives the payment completion information transmitted from the server 30 of the mobile phone company 10 (S611).
Subsequently, the data processing unit 501 transmits the order details and payment completion information to the personal computer 40 of the user 12 through the Internet 60 (S612).
In the personal computer 40 of the user 12, the data processing unit 401 receives the order details and payment completion information transmitted from the server 50 of the virtual store 24 (S307).
6-2. When paying at an actual store
FIG. 20 is a block diagram showing the hardware configuration of the mobile phone 13, the POS terminal 37 and the server 30 used when making a payment at an actual store.
As shown in FIG. 20, the POS terminal 27 similarly includes a data processing unit 271, a RAM 272, a hard disk 273, an input device 274, a display device 275, and an interface (I / F) unit 276. The reading device 270 on which the mobile phone 13 is set at the time of settlement is connected to the interface 276. A scanner for reading the product barcode is also connected to the interface unit 276. A cash withdrawal unit 278 is also connected to the interface unit 276.
FIGS. 21 and 22 are flowcharts showing the operations of the mobile phone 13, the POS terminal 27, and the server 30 when making a payment at an actual store as shown in FIG.
First, before shopping at the actual store 26, the user 12 operates the input device 136 of the mobile phone 13 on the screen D1 shown in FIG. 23 to input the password, and the input device 136 inputs the password accordingly. Is provided to the data processing unit 131 (S701).
Subsequently, the data processing unit 131 compares the input password with a password registered in advance in the RAM 132 as shown in FIG. 24, and verifies the password (S702). If the passwords do not match, the data processing unit 131 displays the screen D2 shown in FIG. 23 on the display device 137 (S703).
On the other hand, if the passwords match, the data processing unit 131 displays the menu screen D3 shown in FIG. When the user 12 selects “(1) pay”, the data processing unit 131 determines whether there is unreported data (S704). The unnotified data is data in which the settlement amount, settlement date and time, and settlement store d are accumulated in the RAM 132 as shown in FIG. 24 when settlement is made at a store outside the radio wave range. If there is unnotified data, the data processing unit 131 determines whether or not it is in the radio wave range (S705), and if it is in the radio wave range, the transmitting / receiving unit 135 sends the unnotified data to the server 30 of the mobile phone company 10 by radio wave in FIG. As shown, it is transmitted together with a key code registered in advance in the ROM 133 (S706). If out of the radio wave range, the unnotified settlement amount stored in the RAM 132 is summed to calculate the accumulated unnotified amount (S707), and then the accumulated unnotified amount is subtracted from the prepaid balance stored in the RAM 132. The current true prepaid balance is calculated (S708). The prepaid balance in the mobile phone 13 is not updated unless the prepaid balance of the virtual account 110 is transmitted from the mobile phone company 10. Therefore, when payment is continuously made with the mobile phone 13 at an actual store outside the radio wave range, the payment amount is stored in the RAM 132 as unreported data.
On the other hand, in the server 30 of the mobile phone company 10, the data processing unit 301 receives the unnotified data transmitted from the mobile phone 13 of the user 12 in step S706 (S901).
Subsequently, the data processing unit 301 compares the key code transmitted from the mobile phone 13 with a key code registered in advance in the personal information database 11 to confirm whether or not the key codes match (S902). . If the key codes do not match, the data processing unit 301 transmits information indicating that the service cannot be used to the mobile phone 13 by radio waves, whereby the mobile phone company 10 notifies the user 12 that the service cannot be used (S903). ). If the key codes match, the data processing unit 301 updates the usage history database 28 based on the received non-notified data, and updates the advance balance of the virtual account 110 (S904). Subsequently, the data processing unit 301 transmits the updated latest advance balance to the mobile terminal 13 (S905).
In the mobile phone 13, the transmission / reception unit 135 receives the information indicating that the service cannot be used transmitted from the server 30 of the mobile phone company 10 in step S <b> 903 (S <b> 709). Subsequently, the data processing unit 131 displays on the display device 137 that the service cannot be used (S710), and further displays on the display device 137 that the service procedure has ended abnormally (S711).
Further, the transmission / reception unit 135 receives the advance balance transmitted from the server 30 of the mobile phone company 10 in step S905 (S712). Subsequently, the data processing unit 131 updates the prepaid balance stored in the RAM 132 so as to be the same as the received prepaid balance, and further clears unnotified data (S713).
If there is no unreported data in step S704, or after step S708 or S713, the data processing unit 103 displays the balance currently available as shown in the screen D16 shown in FIG. 23 (S714).
Subsequently, the payment mode of the mobile phone 13 is turned on, and the data processing unit 131 displays the screen D17 shown in FIG. 23 on the display device 137 (S715).
Subsequently, the user 12 sets the mobile phone 13 in the reading device 270 (S716). Thereby, the data processing unit 131 displays the screen D18 shown in FIG. 23 on the display device 137. At this time, in the POS terminal 27 of the actual store, the data processing unit 271 transmits the payment amount to the mobile phone 13 through the reading device 28 (S801).
In the mobile phone 13, the data processing unit 131 receives the payment amount transmitted from the POS terminal 27 (S717).
Subsequently, the data processing unit 131 determines whether or not the received settlement amount is within the current balance (S718). If the payment amount exceeds the balance, the data processing unit 131 displays the screen D19 shown in FIG. 23 on the display device 137 and notifies the user 12 that the balance is insufficient (S719).
When the settlement amount is within the balance, the data processing unit 131 transmits the telephone number of the mobile phone 13 and the key code registered in advance in the ROM 133 to the POS terminal 27 through the reading device 28 (S720).
In the POS terminal 27, the data processing unit 271 receives the mobile phone number and the key code transmitted from the mobile terminal 13 (S802).
Subsequently, the data processing unit 271 records the received mobile phone number, key code, and settlement content on the hard disk 273 (S803).
Subsequently, the data processing unit 271 transmits payment completion information to the mobile phone 13 through the reading device 270 (S804).
In the mobile phone 13, the data processing unit 131 receives the payment completion information transmitted from the POS terminal 27 and confirms the completion of the transaction (S721).
Subsequently, the data processing unit 131 stores the settlement content including the settlement amount at this time in the RAM 132 as unnotified data (S722).
During the steps S716 to S722, the data processing unit 131 displays the screen D18 shown in FIG. 23 on the display device 137. If the mobile phone 13 is removed from the reading device 270 in the middle, the process ends abnormally. After the payment details are stored in the RAM 132 in step S722, the data processing unit 131 displays the screen D20 shown in FIG. Then, the settlement mode is turned off (S723).
Subsequently, the data processing unit 131 determines whether or not it is in the radio wave range (S724). If it is in the radio wave range, the unreported data stored in the RAM 132 is stored in the server of the mobile phone company 10 together with the key code programmed in the ROM 133. 30 (S725).
In the server 30 of the cellular phone company 10, the data processing unit 301 receives the unnotified data transmitted from the cellular phone 13 together with the key code (S909).
Subsequently, the data processing unit 301 compares the key code transmitted from the mobile phone 13 with a key code registered in advance in the personal information database 11 to confirm whether or not the key codes match (S910). . If the key codes do not match, the data processing unit 301 transmits information indicating that the service cannot be used to the mobile phone 13 by radio waves (S911). The mobile phone 13 receives this information (S726), then displays on the display device 137 that the service cannot be used (S727), and displays on the display device 137 that the service procedure has ended abnormally. It is displayed (S728).
If the key codes match in step S910, the data processing unit 301 updates the usage history database 28 based on the received unreported data, and updates the prepaid balance of the virtual account 110 (S912).
Subsequently, the data processing unit 301 transmits the latest advance balance to the mobile phone 13 (S913).
The mobile phone 13 receives the prepaid balance transmitted from the server 30 of the mobile phone company 10, updates the prepaid balance stored in the RAM 132 to be the same as the received prepaid balance, The notification data is cleared (S729).
On the other hand, in the POS terminal 27 of the actual store 26, the data processing unit 271 transmits the payment contents to the server 30 of the mobile phone company 10 (S805). The settlement contents are preferably transmitted for each transaction, that is, in real time, but may be batch processed after the end of business.
In the server 30 of the mobile phone company 10, the data processing unit 301 receives the payment content transmitted from the POS terminal 27 (S906).
Subsequently, the data processing unit 301 transmits payment completion information to the POS terminal 27 (S907). Then, the mobile phone company 10 performs a payment process for the actual store 26 based on the payment contents (S908).
In the POS terminal 27, the data processing unit 271 receives the payment completion information transmitted from the server 30 of the mobile phone company 10 (S806).
In the first embodiment, the payment amount is transmitted from the POS terminal 27 to the mobile phone 13, and the mobile phone 13 determines whether payment is possible, but the balance of the virtual account is transmitted from the mobile phone 13 to the POS terminal 27. Then, the POS terminal 27 may determine whether payment is possible. In the first embodiment, the mobile phone 13 is electrically connected to the POS terminal 27 using the reading device 270. However, short-range wireless (for example, Bluetooth), wireless LAN (Local Area Network), etc. ) Or IrDA (Infrared Data Association), or may be optically connected using a barcode reader. When a bar code reader is used, the data transmitted from the mobile phone 13 to the POS terminal 27 may be displayed on the display device 137 as a bar code and read by the bar code reader. These changes can also be applied to the embodiments described later.
7). Advantages of this service
7-1. Credit card number, cash card number, account number does not flow on the Internet.
In the case of payment by credit card, payment may be possible if there is only a credit card number, especially in the case of payment on the Internet, the user will feel strong anxiety and resistance to entering the credit card number, There is no denying the risk of being settled if a third party knows the credit card number, or the risk of the card number being stolen at the store. However, in this embodiment, the credit card number is not included in the settlement transaction data flowing on the Internet, and the mobile phone number plays the role. In addition, mobile phone numbers are widely known to third parties for their purpose of use, but even if a third party knows only the mobile phone number of another person and does not have a mobile phone itself, it can also be used on the internet at a real store. Since the above virtual store cannot complete the payment, and the payment limit is limited to the balance in the virtual account, the safety is high.
7-2. No credit inquiry and approval is required for settlement.
When a user deposits funds in a mobile phone company's virtual account (prepayment), the credit inquiry and approval required for each payment method is performed, so that the user can visit a virtual store or a real storefront on the Internet. When making a settlement, it is only necessary to confirm whether or not the settlement amount is within the prepaid balance. Currently, procedures such as obtaining an approval number and signature of the person, which are required for over-the-counter payments, are no longer necessary.
7-3. There is no need to send out radio waves at the time of over-the-counter payments (may be outside the radio range).
In this embodiment, it is not always necessary to emit radio waves from the mobile phone at the time of over-the-counter payment. Therefore, it is not necessary to be aware of whether or not the place for over-the-counter payment is in the radio wave range. Therefore, it is possible to make payments by using vending machines or ticket machines installed in underground shopping malls, buildings, subway premises, and underground in metropolitan areas where there are many radio waves. Even if the mobile phone is out of the radio wave range and the payment amount has not been notified to the mobile phone company, the unreported amount remains stored in the internal memory of the mobile phone, and the unreported data is always available when the next transaction occurs. Then, after the balance of the virtual account is synchronized between the mobile phone and the mobile phone company, the next settlement process is started.
7-4. Transfer to a virtual account for 24 hours is possible.
Even if the balance of the virtual account is insufficient at the time of settlement at a virtual store or a real store on the Internet, in principle, it is possible to transfer funds (pay in advance) to the virtual account 24 hours a day on the spot. You can shop regardless.
7-5. There is no need to be aware of credit lines and balances when making payments.
Conventionally, when using a credit card for payment at a storefront, the credit card payment may be rejected because the limit of use is exceeded, and payment may not be possible when the cash balance is insufficient. . Therefore, there are many users who use a plurality of credit cards properly, but it is actually difficult for the user to recognize the limit amount for each company credit card. On the other hand, in this embodiment, the user can always check the amount that has been transferred to the virtual account in the mobile phone company, that is, the prepaid balance on the mobile phone, and if within that balance, It is guaranteed that payment is always possible.
7-6. The user can continue to use each service program provided by the seller who provides the existing settlement means such as a credit card or a debit card.
A user can continue to receive services provided by a credit sales company or the like by transferring funds to a virtual account of a mobile phone company using an existing settlement means such as a credit card.
7-7. Post-payment is possible even for generations who cannot have a credit card.
When a user designates a transfer of funds to a virtual account in a mobile phone company with a payment method of “add to call charge”, the funds are actually withdrawn from the user's account at the time of call charge withdrawal. is there. Therefore, even generations who do not have a credit card need only have funds in the account when the call charge is withdrawn, and “pseudo next month lump sum payment” like a credit card becomes possible.
7-8. If the service can be used in “price exchange” provided by the delivery company, the user does not need to prepare cash in advance.
By introducing payment by mobile phone as a means of collecting the price at the time of product delivery, the courier eliminates the need for the user to prepare cash in advance and reduces the need for the courier to give the delivery member change . There may be a method of transmitting data at the end of the business day without transmitting / receiving data to / from the mobile phone company server like a POS terminal at a store, and a method of transmitting / receiving wirelessly each time. In addition, such a terminal that enables settlement at a destination can be used in a small store or the like and can be easily introduced.
7-9. Fees are cheaper compared to bank transfer and convenience store payments.
When transferring funds to a virtual account in a mobile phone company by a payment method of “add to call charge”, the user pays a monthly usage fee of about 100 to 200 yen. When small payments are repeatedly made within the same month, the fee charged by the user is lower than when using bank transfer or payment at a convenience store.
7-10. The fee burden is fair.
With current credit card and debit card payments, the merchant bears a fee, and the billing method does not adopt credit card or debit card payments because the small amount payments press on sales profits. Not) there are stores. On the other hand, in this embodiment, when using a credit card or debit card when transferring funds to a mobile phone company, it is assumed that there are few examples of transferring an extremely small amount, and the mobile phone company transfers funds as necessary. By setting the minimum amount and unit in advance, it is possible to balance the fee paid to the credit sales company borne by the mobile phone company and the amount of income. On the other hand, when funds are transferred from a mobile phone company to a member store, a fee is calculated and charged for the total of the transfer amount during a certain period. In other words, each time a user makes a payment, unlike the current credit card or debit card payment method where the fee is charged to the merchant for the payment amount, the merchant will charge the total amount from the mobile phone company. Therefore, it is easy to introduce even a store (company) with a small amount of settlement, and the fee burden is fair regardless of the amount of settlement for each transaction. In other words, in the conventional settlement system, the profit rate is not squeezed even in stores and companies (for example, convenience stores) where the small amount payment is the majority.
7-11. It is a payment system suitable for small transactions.
As described in 7-10 above, since the fee burden is fair, even in stores and companies (for example, convenience stores) where the small amount payment is the majority, sales profits are not squeezed. In addition, even at stores and companies that have introduced a payment method using a credit card or debit card, the minimum available payment amount (for example, 3000 yen or more) must be provided, taking into account the proportion of commissions paid to the sales amount. However, in this embodiment, the fee is charged for the total settlement amount during a certain period, so there is no need to set a limit amount.
7-12. It does not add monetary value to mobile phones.
The current electronic money plan aims to download and use money information itself on a mobile phone. In this embodiment, the mobile phone is used as a tool for transferring money from a virtual account. It is also possible to use electronic money as funds to be transferred to a virtual account. The purpose is to increase the safety and convenience by interposing a mobile phone company and a settlement site in the business transaction, and it does not add monetary value to the mobile phone. Therefore, if electronic money is lost, it is the same as losing cash. However, in this embodiment, even if the mobile phone is dropped, the monetary value is not lost.
7-13. Safety against unauthorized use of devices
Even when lost or stolen, it is possible to request the mobile phone company to stop the service, and even if it is misused at the store before the service is stopped, the amount that can be used is within the balance in the virtual account. Even if the person owns the mobile phone, even if the mobile phone number is abused by a third party on the Internet, other payment means will receive the usage statement until payment is completed In this embodiment, all payment confirmations are sent to the mobile phone, so the person can recognize them before payment is completed and prevent them from occurring. is there. If the mobile phone user contractor has notified the mobile phone company of suspension of this service, in the case of payment on the Internet, when confirming the usage status of the mobile phone, In this case, the service is not available when the payment mode is turned on.
7-14. The safety of transactions between mobile phones and mobile phone company servers is high.
A mobile phone number and a key code are transmitted as a pair from a mobile phone to a mobile phone company server, and the mobile phone company performs authentication using both. Since the mobile phone number is specific to the user and the key code is specific to the mobile phone, even a third party who knows the mobile phone number of the user 12 is not a user's own mobile phone 13. The above transaction cannot be performed using a mobile phone.
7-15. Settlement is completed in a short time.
As described in 7-2 above, since the credit inquiry is performed at the time of advance payment and does not need to be performed at the time of settlement, the time required for settlement is short. This time is shorter than the time taken for settlement by credit card or debit card currently performed at a real store.
[Second Embodiment]
As mentioned above, although embodiment of this invention was described, this invention can be implemented also with another form. For example, in the above embodiment, a virtual account is provided in a mobile phone company, but a virtual account may be provided in a financial institution such as a bank. In short, a virtual account is provided in a server that can communicate directly or indirectly with a mobile phone. Just do it. Hereinafter, a second embodiment of the present invention will be described focusing on differences from the first embodiment.
1. Transfer of funds
FIG. 25 is a schematic diagram showing funds transfer in the second embodiment of the present invention. Unlike the first embodiment shown in FIG. 1, in this second embodiment, as shown in FIG. 25, the virtual account 110 of the user 12 is provided in a server computer of a financial institution 70 such as a bank. In addition to the balance, the virtual account 110 stores a real account number, a virtual account number, a mobile phone company, and a mobile phone number. As the real account number, the account number actually opened by the user 12 in the financial institution 70 is registered. As the virtual account number, a number for specifying the virtual account 110 is registered. As the mobile phone company, the name of the mobile phone company 10 with which the user 12 has a contract is registered. As the mobile phone number, the mobile phone number of the mobile phone 13 of the user 12 is registered.
In addition to the virtual account 110, the financial institution 70 is provided with a real account 710 of the user 12, a deposit / withdrawal history database 712 of the virtual account 110, and a settlement history database 714 of the virtual account 110. A real account number and an account balance are stored in the real account 710 of the user 12. The deposit / withdrawal history database 712 stores the account number of the virtual account 110, the date of deposit / withdrawal of the virtual account 110, and the deposit / withdrawal amount. In the settlement history database 714, the mobile phone 13 is notified of the account number of the virtual account 110, the deposit / withdrawal date of the virtual account 110, the settlement amount, and the virtual account balance at that time to the mobile phone 13. Is stored. On the other hand, the personal information database 11 in the server computer of the mobile phone company 10 stores the name of the financial institution 70 with which the user 12 is dealing.
FIG. 26 is a block diagram showing a hardware configuration of a mobile phone, a mobile phone company server, and a financial institution server used for transferring funds. Unlike the first embodiment shown in FIG. 7, in this second embodiment, as shown in FIG. 26, the reception history and settlement history are not recorded in the database 302 of the server 30 of the mobile phone company 10. . Further, virtual account information is not recorded in the personal information database 11. Instead, a database 702 is provided in the server 72 of the financial institution 70, and virtual account information 110, a virtual account deposit / withdrawal history 712, and a virtual account settlement history 714 are recorded in the database 702. The data processing unit 701 of the server 72 communicates with the data processing unit 301 of the server 30 and performs settlement processing using the database 702.
27 and 28 are flowcharts showing operations of the mobile phone 13, the mobile phone company server 30, and the financial institution server 72 when funds are transferred to the virtual account 110 of the financial institution 70. FIG. FIG. 29 is a transition diagram of screens displayed on the mobile phone 13 in this case.
As shown in FIG. 27, in the second embodiment, in step S104, the user 12 operates the input device 136 of the mobile phone 13 to input a desired transfer amount. As a result, the input device 136 gives the input transfer amount to the data processing unit 131.
Subsequently, the transmitting / receiving unit 135 of the mobile phone 13 transmits the input transfer amount to the server 30 of the mobile phone company 10 together with the mobile phone number, the key code, and the unnotified data.
The server 30 of the mobile phone company 10 uses the received mobile phone number and key code (S202, S203) and uses them as shown in FIG. 28, as in the first embodiment. The transfer request is transmitted to the bank of the person 12 (S240). Specifically, the name of the bank of the user 12 (B bank in this case) is read from the personal information database 11 of the user 12, and the mobile phone number and transfer amount of the user 12 are transmitted to the server 72 of the B bank. Thus, the user 12 is requested to transfer the transmitted amount from the real account 710 of the user 12 to the virtual account 110.
In the server 72 of the financial institution 70, the data processing unit 701 receives the transfer request transmitted from the mobile phone company 10 (S1000).
Subsequently, the data processing unit 701 refers to the real account 710 of the user 12 and determines whether transfer is possible (S1001). When the requested transfer amount exceeds the balance of the real account 710, the data processing unit 701 transmits information indicating that transfer is not possible to the server 30 of the mobile phone company 10 (S1002).
In the server 30 of the cellular phone company 10, the data processing unit 301 receives the non-transferable information transmitted from the financial institution 70 (S241), and subsequently transmits this information to the cellular phone 13 of the user 12 (S242).
In the mobile phone 13 of the user 12, the transmission / reception unit 135 receives the non-transferable information transmitted from the mobile phone company 10 (S140).
Subsequently, the data processing unit 131 displays the screen D21 shown in FIG. 29 on the display device 137 (S141), and notifies the user 12 that transfer cannot be performed due to a shortage of balance.
Subsequently, the data processing unit 131 displays an abnormal end on the display device 137 (S142).
If the transfer amount requested in step S1001 is within the balance of the real account 710, the data processing unit 701 transfers the requested amount from the real account 710 to the virtual account 110 (S1004).
Subsequently, the data processing unit 701 updates the deposit / withdrawal history database 712 based on the transfer amount (S1005).
Subsequently, the data processing unit 701 determines whether there is unreported data in the information received in step S1000 (S1005). In step S704, unnotified data exists. In step S106, unnotified data is transmitted from the mobile phone 13 to the mobile phone company 10. Further, in step S240, unnotified data is transmitted from the mobile phone company 10 to the financial institution 70. If so, the data processing unit 701 updates the settlement history database 714 based on the unnotified data (S1006). When there is no unreported data, the data processing unit 701 transmits the balance of the virtual account 110 to the mobile phone company 10 (S1007).
In the server 30 of the cellular phone company 10, the data processing unit 301 receives the balance of the virtual account 110 transmitted from the financial institution 70 (S243), and subsequently transmits this to the cellular phone 13 of the user 12 (S207). .
In the mobile phone 13, as in the first embodiment, the transmission / reception unit 135 receives the balance of the virtual account 110 transmitted from the mobile phone company 10 (S 113), and the data processing unit 131 is recorded in the RAM 132. The balance of the existing virtual account is updated (S114), and finally the fact that the transfer is completed is displayed on the display device 137 (S115). If unnotified data exists, the unnotified data is cleared (S143).
2. Settlement at virtual store
FIG. 30 is a schematic diagram showing settlement at a virtual store according to the second embodiment of the present invention. As shown in FIG. 30, here, a settlement institution 80 is provided between the virtual store 24 on the Internet and the financial institution 70. The settlement organization 80 accumulates the settlement information 810 every time this service is used, and pays the usage fee to the virtual store 24 based on the accumulated settlement information 810. The settlement information 810 includes the name of the financial institution 70 as the bank name, the name or name of the user 12 as the payer name, the transfer amount, the virtual account number of the virtual account 110, and the name of the virtual store 24 on the Internet as the payment destination. It is included.
FIG. 31 shows the personal computer 40, the mobile phone 13, the server 30 of the mobile phone company 10, the server 72 of the financial institution 70, the server 82 of the payment institution 80, and the server 50 of the virtual store 24 used for payment in the virtual store. It is a block diagram which shows a hardware configuration. As shown in FIG. 31, the data processing unit 801 and the database 802 are provided in the server 82 of the clearing house 80. Payment information 810 is stored in the database 802. The data processing unit 801 communicates with the data processing unit 701 of the server 72 and performs payment processing for the virtual store 24 according to the settlement information 810 stored in the database 802.
32 to 34 show operations of the personal computer 40, the mobile phone 13, the server 30 of the mobile phone company 10, the server 50 of the virtual store 24, and the server 72 of the financial institution 70 when making a payment at the virtual store 24. It is a flowchart. Here, in order to simplify the description, the operation of the server 82 of the clearing house 80 is omitted.
Similarly to the first embodiment shown in FIG. 17, the server 30 of the mobile phone company 10 transmits the billing data from the virtual store 24 to the mobile phone 13 (S505).
In the mobile phone 13, the transmission / reception unit 135 receives the billing data (S401).
Subsequently, the electronic invoice sent by the electronic mail is opened (S420).
Subsequently, after processing unnotified data in the same manner as in the first embodiment (S405 to S407), the data processing unit 131 displays the billing contents and the available balance (for example, the screen shown in FIG. 35) on the display device 137. D22 or D23) is displayed (S421).
Subsequently, the data processing unit 131 verifies whether the billed amount is within the available balance (S422). When the billing amount is within the available balance, a “payment” button is displayed as shown in the screen D22 of FIG. If the billing amount exceeds the available balance, a “Pay Money in Wallet” button is displayed as shown in screen D23 of FIG.
If the amount charged exceeds the available balance, the data processing unit 131 determines whether or not to transfer additional funds in accordance with the operation of the user 12 (S423). If the additional funds are to be transferred, the above-described funds are transferred (S424), and if the additional funds are not to be transferred, the process proceeds to step S403.
If the charged amount is within the available balance in step S422, it is determined whether or not the user 12 has approved the settlement (S402) as in the first embodiment.
In addition, after confirming the password in the server 30 of the mobile phone company 10 (S512), the data processing unit 301 transmits the settlement request information to the financial institution 70. Notification data is transmitted (S520).
In the server 72 of the financial institution 70, the data processing unit 701 receives the settlement request information transmitted from the mobile phone company 10 (S1100).
Subsequently, the data processing unit 701 transfers the received payment amount from the virtual account 110 of the user 12 (S1101). If unnotified data has been received, the unnotified settlement amount is also transferred from the virtual account 110 of the user 12. Here, the settlement organization 80 is requested to transfer the settlement amount to the virtual store 24. The settlement organization 80 does not pay the settlement amount to the virtual store 24 at each request, but pays the virtual store 24 a plurality of settlement amounts in a predetermined monthly unit, for example. Such a settlement institution 80 is not necessarily required, and the financial institution 70 may pay the settlement amount directly to the virtual store 24. However, it is possible to reduce the fee generated each time a transfer is made by providing the settlement organization 80.
Subsequently, the data processing unit 701 updates the deposit / withdrawal history database 712 based on the settlement amount. (S1102).
Subsequently, the data processing unit 701 updates the settlement history database 714 based on the settlement amount. (S1103).
Subsequently, the data processing unit 701 reads the balance of the virtual account 110 and transmits it to the mobile phone company 10 (S1104).
In the server 30 of the cellular phone company 10, the data processing unit 301 receives the virtual account balance transmitted from the financial institution 70 (S521), and subsequently transmits this to the cellular phone 13 of the user 12 (S516).
3. Settlement at a real store
FIG. 36 is a schematic diagram showing settlement at an actual store according to the second embodiment of the present invention. As shown in FIG. 36, even when the settlement is made at the actual store, the settlement institution 80 makes a payment request from the financial institution 70 in a lump sum to the actual store 26.
FIG. 37 is a block diagram showing a hardware configuration of the mobile phone 13, the POS terminal 27, the server 30 of the mobile phone company 10, the server 72 of the financial institution 70, and the server 82 of the settlement institution 80 that are provided for settlement at an actual store. It is.
As shown in FIG. 37, the data processing unit 801 in the server 82 of the settlement institution 80 communicates with the data processing unit 701 of the server 72 and pays the actual store 26 according to the settlement information 810.
38 to 40 are flowcharts showing operations of the mobile phone 13, the POS terminal 27, the server 30 of the mobile phone company 10, and the server 72 of the financial institution 70 when making a payment at a real store.
Unlike the first embodiment shown in FIG. 21, in the second embodiment, the data processing unit 131 of the mobile phone 13 stores the virtual account balance recorded in the RAM 132 in step S707 shown in FIG. From the accumulated unreported amount calculated in step S707.
When the server 30 of the mobile phone company 10 confirms that the key code matches in step S902, the data processing unit 301 transmits unnotified data to the server 72 of the financial institution 70 (S920).
In the server 72 of the financial institution 70, the data processing unit 701 receives unnotified data transmitted from the mobile phone company 10 (S1200).
Subsequently, the data processing unit 701 updates the settlement history database 714 based on the received unreported data (S1201).
Subsequently, the data processing unit 701 transmits the virtual account balance of the virtual account 110 to the server 30 of the mobile phone company 10 (S1202).
In the server 30 of the cellular phone company 10, the data processing unit 301 receives the virtual account balance transmitted from the financial institution 70 (S921), and subsequently transmits it to the cellular phone 13 of the user 12 (S105).
In the mobile phone 13, the transmission / reception unit 135 receives the virtual account balance transmitted from the mobile phone company 10 (S 712), and the data processing unit 131 further stores the virtual account recorded in the RAM 132 based on the received virtual account balance. The account balance is updated and unnotified data is cleared (S713).
In the server 30 of the mobile phone company 10, after receiving the payment details transmitted from the actual store 26 in step S <b> 906, the data processing unit 301 transmits the received payment details to the server 72 of the financial institution 70 ( S922). In the server 72 of the financial institution 70, the data processing unit 701 receives the settlement content transmitted from the mobile phone company 10 (S1203).
Subsequently, the data processing unit 701 updates the payment history database 714 based on the received payment content (S1204).
Subsequently, the data processing unit 701 transmits payment completion information to the server 30 of the mobile phone company 10 (S1205). Then, the financial institution 70 performs a payment process for the actual store 26 through the settlement institution 80 as in the case of the virtual store (S1206).
In the server 30 of the mobile phone company 10, the data processing unit 301 receives the payment completion information transmitted from the financial institution 70 (S923), and subsequently transmits this information to the POS terminal 27 of the actual store 26 (S907).
In addition, in the server 30 of the mobile phone company 10, when the key code match is confirmed in step S909, the data processing unit 301 transmits the unnotified data received in step S909 to the server 72 of the financial institution 70 (S924). .
In the server 72 of the financial institution 70, the data processing unit 701 receives unnotified data transmitted from the mobile phone company 10 (S1207).
Subsequently, the data processing unit 701 updates the settlement history database 714 based on the received unreported data (S1208).
Subsequently, the data processing unit 701 reads the virtual account balance of the virtual account 110 and transmits it to the server 30 of the mobile phone company 10 (S1209).
In the server 30 of the cellular phone company 10, the data processing unit 301 receives the virtual account balance transmitted from the financial institution 70 (S925), and subsequently transmits it to the cellular phone 13 of the user 12 (S913).
In the mobile phone 13 of the user 12, the transmission / reception unit 135 receives the virtual account balance transmitted from the mobile phone company 10 (S730), and the virtual account recorded in the RAM 132 based on the received virtual account balance. The balance is updated and unnotified data is cleared (S729).
As described above, according to the second embodiment of the present invention, since the virtual account 110 is provided in the financial institution 70, it is easier to transfer funds to the virtual account 110 than in the first embodiment. Become.
Although the virtual account 110 is provided in the financial institution 70 separately from the real account 710 in the second embodiment, the real account 710 may be handled as the virtual account 110 as it is. In this case, since it is not necessary to transfer funds from the real account 710 to the virtual account 110, the processing procedure is further simplified.
In payment at a virtual store on the Internet according to the above-described embodiment, a user places an order using a personal computer. However, the user may place an order using a mobile phone. In this case, the mobile phone functions as a substitute for a personal computer.
[Third Embodiment]
In the first embodiment, the virtual account is provided in the mobile phone company, and in the second embodiment, the virtual account is provided in the financial institution. In the third embodiment described below, Establishes a virtual account in a separate clearing house.
1. Service overview
A user who wishes to use the service according to the third embodiment registers in advance a bank account number, a credit card company credit card number, etc. necessary for depositing a prepayment into a virtual account in a settlement organization. deep. Prior to the settlement, the user requests the settlement organization through the cellular phone company using the cellular phone to deposit the prepayment into the virtual account. The clearing house uses a bank account number registered in advance, a credit card number of a credit sales company, etc., and bills the user for a prepayment. After requesting the prepayment, the settlement organization deposits the prepayment into the virtual account and transmits the balance of the virtual account to the mobile phone via the mobile phone company. The virtual store or the actual store charges the settlement organization, not the mobile phone company or the financial institution as in the first and second embodiments.
1-1. Registration
FIG. 41 is a schematic diagram illustrating a method of use registration that is first performed when the user 12 of the mobile phone 13 desires to use this service. As shown in FIG. 41, the user 12 who wishes to use this service can subscribe to a mobile phone company, a mobile phone number, a bank account number for withdrawing prepayments, and a credit card number of a credit sales company. Such settlement information is entered in a predetermined withdrawal account registration form 25 and mailed to the settlement organization 90. The clearing house 90 registers the user information 910 in the database based on the withdrawal account registration form 25.
Subsequently, the clearing house 90 notifies the user 12 through the mobile phone company 10 of the member number (customer number in the user information 910) given to the user 12. The user 12 confirms the contents of the notification, and if there is no problem, the user 12 approves the application for this service to the settlement organization 90 through the mobile phone company 10. In response to this, the settlement institution 90 opens a virtual account 110 and opens an area for recording the virtual account deposit / withdrawal history 912 and settlement history 914 in the database.
In the database of the payment institution 90, member store information 916 such as a transfer account for transferring the amount of money used in the member store (including virtual stores and real stores) and the member store that can use the service is registered. Yes.
Subsequently, the settlement organization 90 notifies the start of the service to the mobile phone 13 of the user 12 through the mobile phone company 10. At this time, the mobile phone company 10 changes the usage status of the personal information 11 from “unregistered” to “available”. When the mobile phone 13 of the user 12 receives a notification of the start of the service from the mobile phone company 10, the usage status of the mobile phone 13 is changed from “unusable” to “usable”.
Through the above procedure, the user 12 can use this service.
1-2. Transfer funds to virtual account
FIG. 42 is a schematic diagram showing the transfer of funds when the advance payment to be deposited into the virtual account 110 provided in the settlement institution 90 is withdrawn from the account of the financial institution. As shown in FIG. 42, the user 12 uses the mobile phone 13 to request the settlement organization 90 to deposit a desired advance payment into the virtual account 110 through the mobile phone company 10. Here, the case where 5000 yen is deposited in the virtual account 110 is illustrated. When the settlement organization 90 receives a request for advance payment to the virtual account 110, based on the user information 910, the settlement organization 90 sends the advance payment to the financial institution 170 such as a bank or a credit sales company where the account 160 of the user 12 is established. Request a withdrawal. The financial institution 170 that has received the withdrawal request confirms whether or not the withdrawal is possible, and if possible, sends the transfer data to the settlement institution 90 and pays the prepayment to the settlement institution 90. When the withdrawal is impossible, the settlement organization 90 is notified to that effect. When the settlement organization 90 receives the transfer data from the financial institution 170, it updates the deposit / withdrawal history 912 and further updates the virtual account 110. Subsequently, the clearing house 90 notifies the mobile phone company 10 of the updated balance of the virtual account 110. In the mobile phone company 10, transmission data 102 such as a mobile phone number and a virtual account balance is created. The mobile phone company 10 notifies the user 12 of the virtual account balance based on the transmission data 102. In response to this notification, the mobile phone 13 of the user 12 updates the virtual account balance. When the transmission of the transmission data 102 from the mobile phone company 10 to the mobile phone 13 of the user 12 is completed, the transmission data 102 is cleared. When transmission of the transmission data 102 is impossible, such as when the user 12 is outside the radio wave range, the transmission data 102 is not cleared but is held as it is.
1-3. Settlement at virtual store
FIG. 43 is a schematic diagram showing a method of making a payment at the virtual store 24 on the Internet using the mobile phone 13. As shown in FIG. 43, the user 12 places an order to the virtual store 24 using the mobile phone 13 or the personal computer 40. The virtual store 24 that has received the order transmits an electronic invoice describing the customer number of the user 12 and the contents of the charge to the mobile phone 13 of the user 12 through the settlement organization 90 and the mobile phone company 10. The user 12 confirms the transmitted electronic bill on the mobile phone 13, and if the charged content matches the order content, the user 12 notifies the payment organization 90 through the mobile phone company 10 of the approval of payment. When the settlement organization 90 obtains the approval of the settlement, it updates the deposit / withdrawal history 912 and the settlement history 914 according to the contents of the bill, and also updates the balance of the virtual account 110. Here, a case where a product of 3000 yen is purchased at a virtual store 24 called a store B is illustrated.
Subsequently, the clearing house 90 notifies the mobile phone company 10 of the updated virtual account balance. The mobile phone company 10 uses the virtual account balance as transmission data 102 and further transmits it to the mobile phone 13 of the user 12. In response to this, the virtual account balance of the mobile phone 13 is updated. When the transmission of the virtual account balance from the mobile phone company 10 to the user 12 is completed, the transmission data 102 is cleared.
On the other hand, upon completion of the update of the virtual account balance, the settlement organization 90 notifies the user 12 through the virtual store 24 of the completion of settlement. Further, the settlement organization 90 deposits the settlement amount into the transfer account of the member store based on the member store information 916.
1-4. Settlement at a real store
FIG. 44 is a schematic diagram showing a method of making a payment at the actual store 26 using the mobile phone 13. As shown in FIG. 44, when the mobile phone 13 is attached to the POS terminal 27 installed in the actual store 26, the POS terminal 27 transmits the payment amount to the mobile phone 13. When the payment amount is within the virtual account balance, the mobile phone 13 records the payment contents in the unreported data and transmits the mobile thunder story number, key code, and password to the POS terminal 27. In response to this, the POS terminal 27 notifies the mobile phone 13 of completion of the settlement.
Thereafter, the POS terminal 27 notifies the settlement organization 90 of the settlement contents together with the mobile phone number, the key code, and the password. The settlement institution 90 requests authentication by transmitting the received mobile phone number, key code, and password to the mobile phone company 10. The cellular phone company 10 that has received the authentication request changes the unnotification of the personal information 11 from “none” to “present”. If the received mobile phone number, key code, and password do not match the mobile phone number, key code, and password registered as personal information 11, the mobile phone company 10 changes the usage status of the personal information 11 to "authentication error". Then, this is notified to the user 12 and the settlement organization 90. In response to this notification, the mobile phone 13 changes the usage status to “authentication error”.
On the other hand, when the received mobile phone number, key code, and password match the mobile phone number, key code, and password registered as the personal information 11, the mobile phone company 10 indicates that the authentication has been successfully completed. Notify In response to this notification, the settlement organization 90 updates the deposit / withdrawal history 912 and the settlement history 914. The settlement institution 90 further updates the balance of the virtual account 110 and changes the unnotified from “none” to “present”. Here, a case where a product of 1000 yen is purchased at a real store 26 called D store is illustrated.
Subsequently, the settlement organization 90 notifies the actual store 26 that the settlement has been completed. Further, the settlement organization 90 deposits the settlement amount into the transfer account of the member store based on the member store information 916.
1-5. Request for unreported data
FIG. 45 shows a case where unnotified data is generated in the mobile phone 13 because the user 12 has made a payment at the actual store 26 and the virtual account balance of the mobile phone 13 no longer matches the virtual account balance of the settlement organization 90. It is the schematic which shows the method the settlement organization 90 requests | requires transmission of unnotified data with respect to the mobile telephone set 13 in order to synchronize a virtual account balance. As shown in FIG. 45, the clearing house 90 requests unnotified data from the mobile phone 13 of the user 12 through the mobile phone company 10. In response to this, the mobile phone 13 transmits unnotified data to the clearing house 90 through the mobile phone company 10. The settlement organization 90 changes the status of the corresponding settlement in the settlement history 914 from “unnotified” to “notified” based on the received unnotified data.
Subsequently, the settlement institution 90 transmits the balance of the virtual account 110 to the mobile phone company 10. The mobile phone company 10 uses the received virtual account balance as the transmission data 102 and changes the unnotification in the personal information 11 from “present” to “none”. The mobile phone company 10 transmits the virtual account balance to the mobile phone 13. In response to this, the mobile phone 13 updates the virtual account balance and clears the unreported data. When the mobile phone company 10 completes the transmission of the virtual account balance, the transmission data 102 is cleared.
1-6. Billing agency
FIG. 46 is a schematic diagram illustrating a method in which the payment agency 90 charges the credit sales company 20 for the payment amount of the user 12 at the virtual store 24 instead of the virtual store 24. This billing agency does not use the virtual account 110 provided in the settlement institution 90, but uses a bank account number registered as the user information 910 or a credit card number of a credit sales company to make a debit settlement or a card settlement. Is to do.
As shown in FIG. 46, when the user 12 places an order with respect to the virtual store 24 using the mobile phone 13 or the personal computer 40, the virtual store 24 sends an electronic invoice consisting of a customer number, billing details, etc. to the settlement organization 90. And issued to the user 12 through the mobile phone company 10. The user 12 confirms the electronic bill transmitted to the mobile phone 13, and if the payment is approved, notifies the payment organization 90 through the mobile phone company 10. At that time, one of the pre-registered payment methods is selected. Here, a case where payment by credit card of credit sales company E is selected is illustrated.
The settlement organization 90 notifies the virtual store 24 of the approval of the settlement, and notifies the credit sales company 20 of the settlement contents such as a credit card number and a settlement amount using the user information 910. In response to this, the credit sales company 20 performs payment processing of the settlement amount to the virtual store 24 and notifies the virtual store 24 that the settlement has been completed.
When the user 12 selects payment by debit card as the payment method, the payment organization 90 notifies the bank 17 of the payment details such as the account number and the payment amount using the user information 910. The bank 17 withdraws the settlement amount from the account of the user 12 and further performs payment processing of the settlement amount to the virtual store 24.
In the billing agency service, important settlement information such as a bank account number and a credit card company credit card number is registered in advance in the settlement organization 90 and is not transmitted from the mobile phone 13 or the personal computer 40. Authentication is performed by the mobile phone company 10 using a mobile phone number, a key code and a password. Only when the authentication is obtained, an account number and a credit card number registered in advance are changed from the settlement institution 90 to the financial institution 170 or the credit sales company. 20 is notified. Therefore, high safety can be ensured.
2. System configuration and operation
Next, a system configuration and operation for realizing the above service will be described.
2-1. Registration
FIG. 47 is a block diagram showing a hardware configuration for use registration shown in FIG. Unlike the first and second embodiments, in the third embodiment, the server 30 of the mobile phone company 10 is provided with a memory 303 for storing transmission data 102. Further, the server 92 of the settlement institution 90 is provided with a data processing unit 921 and a database 922. The database 922 stores user information 910, virtual account deposit / withdrawal history 912, virtual account settlement history 914, and member store information 916. The data processing unit 921 is connected to the data processing unit 301 of the server 30 installed in the mobile phone company 10 and performs predetermined data processing on the database 922.
FIG. 48 is a flowchart showing the operations of the cellular phone 13 of the user 12, the server 30 of the cellular phone company 10, and the server 92 of the clearing house 90 when performing usage registration.
First, the user 12 operates the input device 136 of the mobile phone 13 to transmit a use application for this service from the mobile phone 13 to the mobile phone company 10 (S11). In the server 30 of the mobile phone company 10, the data processing unit 301 receives the use application transmitted from the mobile phone 13 (S21), and transmits it to the settlement organization 90 (S22). In the server 92 of the clearing house 90, the data processing unit 921 receives the use application transmitted from the mobile phone company 10 (S1301). In response to this, the settlement company 92 sends a predetermined application form to the user 12 (S1302). The user 12 fills in the application form with the account number of the bank he / she wishes to withdraw, the credit card number of the credit sales company, etc., and returns it to the settlement organization 90. The clearing house 90 receives the application form returned from the user 12 (S1302). Based on the items entered on the application form, the data processing unit 301 registers the user information 910 in the database 922 (S1303). Specifically, the membership number of the user 12, the mobile phone number, the mobile phone company, the bank account number, the credit card number of the credit sales company, etc. are registered. Subsequently, the data processing unit 921 notifies the mobile phone company 10 of the membership number (S1304).
In the server 30 of the cellular phone company 10, the data processing unit 301 receives the membership number transmitted from the settlement organization 90 (S23) and notifies the user 12 of this (S24). In the mobile phone 13 of the user 12, the transmission / reception unit 135 receives the membership number transmitted from the mobile phone company 10 (S12), and if the user 12 approves the application, the mobile phone company 10 informs the mobile phone company 10 of that. Notification is made (S13). In the server 30 of the mobile phone company 10, the data processing unit 301 receives the notification of application approval transmitted from the mobile phone 13 (S25), and notifies the settlement organization 90 of this (S26).
In the server 92 of the clearing house 90, the data processing unit 921 receives the notification of application approval transmitted from the mobile phone company 10 (S1305), opens the virtual account 110 (S1306), and starts the service. The company 10 is notified (S1307). In the server 30 of the mobile phone company 10, the data processing unit 301 receives the service start notification transmitted from the settlement organization 90 (S 27), and changes the usage status of the personal information 11 from “unregistered” to “available”. Update (S28). Subsequently, the data processing unit 301 notifies the user 12 of the start of this service (S29). In the cellular phone 13 of the user 12, the transmission / reception unit 135 receives the service start notification transmitted from the cellular phone company 10 (S14), and updates the usage status from “unusable” to “usable” (S15). ).
2-2. Transfer funds to virtual account
FIG. 49 is a block diagram showing a hardware configuration of the mobile phone 13 of the user 12, the server 30 of the mobile phone company 10, the server 92 of the settlement institution 90, and the server 172 of the financial institution 170 used for transferring funds shown in FIG. FIG. As shown in FIG. 49, the server 172 installed in the financial institution 170 includes a data processing unit 174 and a database 176. The data processing unit 174 processes data in the database 176 and is connected to the data processing unit 301 of the server 30 installed in the mobile phone company 10. Registered in the database 176 are user information 177 such as a user's address and name, real account information 178 regarding a real account opened in the financial institution 170, and real account history 179 such as deposits and withdrawals in the real account. Is done.
50 to 52 show the mobile phone 13, the mobile phone company 10 server 30 and the payment institution 90 server 92 when transferring funds from the financial institution 170 to the virtual account 110 of the payment institution 90 as shown in FIG. It is a flowchart which shows this operation | movement.
Here, before the password is entered (S101), the mobile phone 13 confirms the usage status, and if it is not available, displays that fact on the display device 137 (S100). If it is available, the user 12 is prompted to enter a password (S101). Further, after the password is verified (S102) and before the advance payment amount is input (S104), the unnotified data is confirmed and the available balance is displayed (S714) as in FIG.
Subsequently, the transmission / reception unit 135 of the mobile phone 13 transmits the advance payment amount or the like input in step S104 to the mobile phone company 10 (S106). Here, the password input in step S101 is also transmitted to the mobile phone company 10. .
In the server 30 of the mobile phone company 10, after the personal information 11 is searched based on the mobile phone number received by the data processing unit 301 (S202), the received key code and password are verified (S203). If the key code or password does not match, the usage status of the personal information 11 is changed from “usable” to “unusable” (S250), and an abnormal authentication is notified to the user 12 (S251).
In the mobile phone 13 of the user 12, the transmission / reception unit 135 receives a notification of authentication abnormality from the mobile phone company 10 (S 150), and in response to this, the data processing unit 131 sets the usage status of the mobile phone 13 to “available”. Is changed to “authentication error” (S151), and the suspension of use of this service is displayed on the display device 137 (S152).
On the other hand, if both the key code and the password match in step S203, the data processing unit 301 checks the usage status of the personal information 11 (S204). If the usage status is “available”, is there any unreported data? It is determined whether or not (S253). If there is unnotified data, the data processing unit 301 transmits unnotified data to the clearing house 90 together with the advance payment received in step S201 (S254). On the other hand, when there is no unreported data, the data processing unit 301 transmits only the prepayment amount to the clearing house 90 (S255). In this way, when the advance payment amount is transmitted from the mobile phone company 10 to the settlement institution 90, the mobile phone number of the user 12 is also transmitted.
In the server 92 of the clearing house 90, the data processing unit 921 receives the mobile phone number and the advance payment amount transmitted from the mobile phone company 10 (S1300), the received information and the user registered in the database 922. Based on the information 910, billing data is created for the financial institution 170 in which the user 12 has opened an account (S1301). The settlement institution 90 requests the financial institution 170 to withdraw the prepayment amount according to the billing data (S1302).
The financial institution 170 withdraws the prepayment amount from the account 160 of the user 12 in response to the withdrawal request from the settlement institution 90 (S1400). Subsequently, the data processing unit 174 determines whether or not the withdrawal is possible, that is, whether or not the prepayment amount is within the account balance (S1401). If the withdrawal is impossible, the data processing unit 174 notifies the settlement organization 90 of the fact (S1402). In the server 92 of the settlement institution 90, the data processing unit 921 receives a notice that it cannot be withdrawn from the financial institution 170 (S1303), and notifies this to the cellular phone company 10 together with the cellular phone number of the user 12 (S1304). . In the server 30 of the mobile phone company 10, the data processing unit 301 receives a notification that it cannot be withdrawn from the settlement organization 90 (S256), and notifies the mobile phone 13 of the user 12 of this (S232).
On the other hand, if the withdrawal can be made in step S1401, the data processing unit 174 of the server 172 transmits the transfer data to the clearing house 90 (S1403), and transfers the prepaid amount from the account 160 of the user 12 to the account of the clearing house 90. A payment process to be replaced is executed (S1404).
In the server 92 of the settlement institution 90, the data processing unit 921 receives the transfer data transmitted from the financial institution 170 (S1305), and subsequently updates the deposit / withdrawal history 912 by recording the deposit of the prepayment amount in the database 922. (S1306). If unnotified data has been transmitted, the settlement history 914 is updated by recording the settlement amount in the database 922 (S1307). Subsequently, the data processing unit 921 updates the virtual account balance by adding the prepaid amount to the balance of the virtual account 110 (S1308). If there is unreported data, change it to “None”. Subsequently, the data processing unit 921 transmits the balance of the virtual account 110 together with the mobile phone number to the mobile phone company 10 (S1309).
In the server 30 of the mobile phone company 10, the data processing unit 301 receives the virtual account balance transmitted from the settlement organization 90 (S257), and stores the virtual account balance in the memory 303 as the transmission data 102 (S258). Subsequently, the data processing unit 301 changes the unnotified data to “none” (S259). Subsequently, the data processing unit 301 transmits the transmission data 102 stored in the memory 303 to the mobile phone 13 of the user 12 (S260). Subsequently, it is determined whether or not the transmission is normally completed (S261). If the transmission is normally completed, the transmission data 102 is cleared (S262), and the user 12 is out of the radio wave range or the power of the mobile phone 13 is turned on. If the transmission data cannot be transmitted to the mobile phone 13 and the transmission is not completed normally, such as when it is disconnected, a retransmission process is performed (S263). Specifically, the transmission data 102 is transmitted to the mobile phone 13 again after a predetermined period.
2-3. Settlement at virtual store
53 shows the hardware of the personal computer 40, the mobile phone 13, the server 30 of the mobile phone company 10, the server 92 of the payment institution 90, and the server 50 of the virtual store 24 used for the payment at the virtual store 24 shown in FIG. It is a block diagram which shows a structure. As shown in FIG. 53, the data processing unit 921 of the server 92 installed in the settlement institution 90 is connected to the Internet 60.
54 to 56 show the personal computer 40, the mobile phone 13, the server 30 of the mobile phone company 10, the server 92 of the payment institution 90, and the virtual store 24 when making a payment at the virtual store 24 as shown in FIG. 3 is a flowchart showing the operation of a server 50.
Here, the personal computer 40 or the mobile phone 13 of the user 12 transmits the member number (customer number) together with the order contents to the virtual store 24 (S301). The server of the virtual store 24 receives these (S601), creates an electronic bill, and transmits the billing contents together with the membership number to the settlement institution 90 via the Internet 60 (S602).
In the server 92 of the clearing house 90, the data processing unit 921 receives the electronic bill transmitted from the virtual store 24 (S1310), searches the database 922 based on the received membership number, and stores the user information 910. The mobile phone number of the user 12 and the mobile phone company are specified from among them (S1311). Subsequently, the data processing unit 921 transmits the received electronic bill together with the mobile phone number to the corresponding mobile phone company 10 (S1312).
In the server 30 of the mobile phone company 10, the data processing unit 301 receives the electronic bill transmitted from the settlement organization 90 together with the mobile phone number (S501). The data processing unit 301 confirms the usage status in the personal information 11 (S503), and if the usage status is “unusable”, notifies the settlement organization 90 together with the mobile phone number (S504).
The server 92 of the clearing house 90 receives the service unavailable notification notified from the mobile phone company 10 together with the mobile phone number (S1313), and notifies the virtual store 24 via the Internet 60 (S1314).
Further, the user 12 opens the electronic bill transmitted from the mobile phone company 10 and received by the mobile phone 13 (S418), and the data processing unit 131 of the mobile phone 13 charges and uses the received electronic bill. The possible virtual account balance is displayed on the display device 137 (S154).
If the billing amount of the electronic bill exceeds the available balance, the data processing unit 131 inquires of the user 12 whether or not to perform additional transfer to the virtual account 110 through the display device 137 (S155). . When performing an additional transfer, the data processing unit 131 executes a fund transfer process (S156).
Further, the determination as to whether or not to approve the payment (S402) is made after the available balance is verified (S408). In the server 30 of the cellular phone company 10, the cancellation or rejection of the settlement received by the data processing unit 301 is transmitted to the settlement organization 90 together with the cellular phone number (S507). In the server 92 of the settlement institution 90, the data processing unit 921 receives the cancellation or rejection of the settlement transmitted from the mobile phone company 10 (S1315), and transmits this to the virtual store 24 via the Internet 60 (S1316). . The cancellation or rejection of the settlement is returned to the user 12 via the virtual store 24 as in the above embodiment (S605, S606, S304). In the personal computer 40 or the mobile phone 13 of the user 12, the data processing unit 401 or 131 displays on the display device 406 or 137 whether or not the received settlement is canceled or rejected (order cancellation) (S308).
In the cellular phone 13 of the user 12, after the password is input (S411), the data processing unit 131 verifies the input password (S157). If the password is incorrect, the data processing unit 131 displays that fact on the display device 137 (S158), and if the password is correct, the transmission / reception unit 135 notifies the mobile phone company 10 of the approval of payment (S412).
In the server 30 of the mobile phone company 10, if the key code or the password does not match, the data processing unit 301 changes the usage status of the personal information 11 from “available” to “authentication abnormal” (S522). The user 12 is notified (S523), and further, the settlement organization 90 is notified together with the mobile phone number (S524). In the mobile phone 13 of the user 12, the transmission / reception unit 135 receives the notification of the authentication abnormality transmitted from the mobile phone company 10 (S 159), and the data processing unit 131 changes the usage status from “available” to “authentication abnormal”. In addition, the suspension of use of the service is displayed on the display device 137 (S161). On the other hand, in the server 92 of the settlement organization 90, the data processing unit 921 receives the notification of the authentication abnormality transmitted from the mobile phone company 10 (S1317), and indicates that the settlement is impossible due to the authentication abnormality. Is notified to the virtual store 24 (S1318). In the server 50 of the virtual store 24, the modem 504 receives a notification indicating that payment is not possible transmitted from the payment agency 90 (S 613), and in response to this, the cancellation of the order is received via the Internet 60 and the personal computer 40 of the user 12. Or it transmits to the mobile telephone 13 (S614). In the personal computer 40 or the mobile phone 13 of the user 12, the modem 404 or the transmission / reception unit 135 receives the cancellation of the order received from the virtual store 24 (S309), and the data processing unit 401 or 131 displays that effect. It is displayed on 406 or 137 (S310).
If the key code and the password match in steps S511 and S512, the data processing unit 301 determines whether or not unnotified is “present” (S525). If there is unnotified data, the settlement data and unnotified data are stored. It is transmitted to the settlement institution 90 together with the mobile phone number (S526). If there is no unreported data, the data processing unit 301 transmits the settlement data together with the mobile phone number to the settlement organization 90 (S527). In the server 92 of the settlement institution 90, the data processing unit 921 receives the settlement data transmitted from the mobile phone company 10 (and unnotified data if there is unreported data) (S1319), and the received settlement data ( If there is unreported data, the deposit / withdrawal history 912 is updated (S1320), the settlement history 914 is updated (S1321), and the balance of the virtual account 110 is further updated (S1322). Here, the data processing unit 921 sets unnotified virtual account 110 to “no”.
Subsequently, the data processing unit 921 transmits the updated balance of the virtual account 110 together with the mobile phone number to the mobile phone company 10 (S1323), and notifies the virtual store 24 of the completion of the settlement via the Internet 60 (S1324). Further, payment processing to the virtual store 24 is performed (S1325). The notification of the completion of settlement is also notified to the user 12 via the virtual store 24 (S612, S307). In the personal computer 40 or the mobile phone 13 of the user 12, the data processing unit 401 or 131 displays the completion of the received payment on the display device 406 or 137 (S311).
On the other hand, in the server 30 of the mobile phone company 10, the data processing unit 301 receives the virtual account balance transmitted from the settlement organization 90 (S528), and stores the balance as transmission data 102 in the memory 303 (S529). Subsequently, the data processing unit 301 sets “not notified” of the personal information 11 to “no” (S530), and transmits the transmission data (virtual account balance) 102 stored in the memory 303 to the mobile phone 13 of the user 12 (S531). ).
Subsequently, the data processing unit 301 determines whether or not the transmission of the data has been completed normally (S532). If the transmission is completed normally, the transmission data 102 stored in the memory 303 is cleared (S533). If not completed, the transmission process is performed again (S534).
In the mobile phone 13 of the user 12, the transmission / reception unit 135 receives the transmission data 102 transmitted from the mobile phone company 10 (S162), and the data processing unit 131 calculates the virtual account balance based on the received transmission data 102. Update (S163). Subsequently, the data processing unit 131 clears the unreported data (S164), and displays the completion of settlement on the display device 137 together with the virtual account balance (S165).
2-4. Settlement at a real store
FIG. 57 is a block diagram showing a hardware configuration of the mobile phone 13, the POS terminal 27, the server 30 of the mobile phone company 10 and the server 92 of the payment institution 90 used for the payment at the actual store shown in FIG. 44. Here, unlike FIG. 20, the server 92 of the settlement institution 90 is connected to the POS terminal 27 of the actual store 26 and the server 30 of the mobile phone company 10.
58 to 60 are flowcharts showing the operations of the mobile phone 13, the POS terminal 27, the server 30 of the mobile phone company 10, and the server 92 of the clearing house 90 shown in FIG.
Here, in the server 30 of the mobile phone company 10, when there is unnotified data as a result of the determination in step S525, the data processing unit 301 transmits the unnotified data to the settlement organization 90 together with the mobile phone number (S535). In the server 92 of the clearing house 90, if there is unreported data, the data processing unit 921 updates the deposit / withdrawal history 912 (S1330). Subsequently, the data processing unit 921 updates the settlement history 914 and sets the state of the corresponding settlement to “notified” (S1331). Subsequently, when there is unreported data, the data processing unit 921 updates the balance of the virtual account 110 and sets unnotified to “None” (S1332).
Further, here, unlike FIG. 22, in the mobile phone 13 of the user 12, after the balance is verified (S718), the data processing unit 131 stores the settlement content in the unreported data (S722), and then the mobile phone number, The terminal information of the mobile phone 13 such as the key code and the password is transmitted to the POS terminal 27 (S720). Steps S802 to S804 and S721 are the same as those in FIG. After receiving the payment completion notification from the POS terminal 27 in step S721, the data processing unit 131 turns off the payment mode (S723) and displays the end of payment on the display device 137 (S731).
In addition, the data processing unit 271 of the POS terminal 27 transmits the settlement content recorded in step S803 to the settlement organization 90 together with the mobile phone number, key code, and password received in step S802 (S805). In the server 92 of the payment institution 90, the data processing unit 921 receives the payment contents transmitted together with the mobile phone number from the POS terminal 27 (S1333), and is stored in the database 922 based on the received mobile phone number. User information 910 is searched (S1334). According to the search result, the data processing unit 921 transmits the mobile phone number, key code and password received in step S1333 to the mobile phone company 10 in order to request the mobile phone company 10 to authenticate (S1335).
In the server 30 of the cellular phone company 10, the data processing unit 301 performs authentication in the same manner as in FIG. 55 (S511, S512). However, here, if the key code or password does not match, the data processing unit 301 changes the usage status of the personal information 1 to “unusable” (S522), and notifies the user 12 of the suspension of the use of this service (S523). ). In the mobile phone 13 of the user 12, the data processing unit 131 changes the usage status to “unusable” (S160).
On the other hand, if the key code and the password match, the data processing unit 301 changes the unnotification of the personal information 11 to “present” (S925), notifies the settlement organization 90 of the successful authentication, and further includes unnotified data described later. Request processing is performed (S927).
In the server 92 of the payment institution 90, the data processing unit 921 receives the notification of the successful authentication transmitted from the mobile phone company 10 (S1330), and updates the balance of the deposit / withdrawal history 912, the payment history 914, and the virtual account 110, respectively. (S1320 to S1322). Here, when the settlement history 914 is updated, the state is “not notified”. Subsequently, the data processing unit 921 changes the non-notification of the virtual account 110 to “present” (S1331).
Also, when the data processing unit 921 receives a notification of authentication abnormality from the mobile phone company 10 (S1317), the data processing unit 921 performs payment processing of the settlement amount to the actual store 26 (S1332). The cause of such an authentication abnormality is considered to be fraud of the user 12. In this case as well, the settlement institution 90 guarantees payment to the actual store 26. The clearing house 90 bears damage due to unauthorized use, but since the use of this service is stopped when the authentication abnormality is detected as described above, the damage can be minimized.
2-5. Request for unreported data
FIG. 61 is a flowchart showing the operations of the mobile phone 13, the server 30 of the mobile phone company 10, and the server 92 of the clearing house 90 when the mobile phone company 10 requests unreported data from the user 12. The unnotified data is stored in the RAM 132 of the mobile phone 13 as in the first embodiment shown in FIG. Further, when requesting unreported data, the hardware configuration shown in FIG. 47 is used.
In the server 30 of the mobile phone company 10, the data processing unit 301 requests the mobile phone 13 of the user 12 to transmit unreported data at predetermined time intervals (S540). In the mobile phone 13 of the user 12, the transmission / reception unit 135 receives a transmission request for unnotified data transmitted from the mobile phone company 10 (S170), and the data processing unit 131 is stored in the RAM 132 accordingly. The unnotified data is transmitted to the mobile phone company 10 together with the mobile phone number, key code and password (S706). 58 and 59, the server 30 of the mobile phone company 10 performs authentication and the like, and the server 92 of the settlement organization 90 updates the settlement history 914 and the like.
2-6. Billing agency
62 shows the personal computer 40, the mobile phone 13, the server 30 of the mobile phone company 10, the server 50 of the virtual store 24, the server 92 of the settlement institution 90, and the server 94 of the financial institution 170 used for the billing agency shown in FIG. It is a block diagram which shows the hardware constitutions. As shown in FIG. 62, the financial institution server 94 includes a data processing unit 941 and a database 942. The data processing unit 941 is connected to the Internet 60 and the data processing unit 921 of the server 92 installed in the settlement organization 90. The database 942 stores user information 943, member store information 944, and user history 945. The user information 943 includes an account number in the case of a bank, a credit card number and a withdrawal bank account in the case of a credit sales company, in addition to the user's address, name, and telephone number. The member store information 944 is the address, name, etc. of the member store that accepts payment by debit card or credit card. The user history 945 includes a payment amount by a debit card or a credit card, a payment date, a name of a member store used, and the like.
63 and 64 show operations of the personal computer 40, the mobile phone 13, the server 30 of the mobile phone company 10, the server 92 of the settlement institution 90, the server 94 of the financial institution, and the server 50 of the virtual store 24 shown in FIG. It is a flowchart to show.
The billing agency process shown in FIGS. 63 and 64 is similar to the settlement process in the virtual store shown in FIGS. 54 to 56. However, at the time of billing, the mobile phone 13 of the user 12 approves the payment immediately after opening the electronic bill in step S418 (S402). Further, when the passwords match in step S157, the user 12 is prompted to select a settlement method to be settled using a debit card or a credit card (S171). Subsequently, the transmission / reception unit 135 of the mobile phone 13 notifies the mobile phone company 10 of the approval of the settlement (S412). At this time, in addition to the mobile phone number, key code, password, and payment contents, the payment method is also transmitted to the mobile phone company 10.
In addition, in the server 30 of the mobile phone company 10, when the key code and the password match in steps S511 and S512, the data processing unit 301 transmits the payment approval received in step S510 to the payment organization 90 together with the mobile phone number. To do. In the server 92 of the payment institution 90, the data processing unit 921 notifies the approval of the payment to the virtual store 24 via the Internet 60 (S1335), and the modem 504 receives this notification in the server 50 of the virtual store 24. (S615).
Subsequently, the data processing unit 921 notifies the financial institution of the contents of payment (S1336). In the server 94 of the financial institution, the data processing unit 941 receives the payment content transmitted from the payment institution 90 (S1500), and performs a predetermined payment process (S1501). Subsequently, the data processing unit 941 notifies the virtual store 24 of whether payment is possible (S1502). In the server 50 of the virtual store 24, the modem 504 receives the settlement permission notification transmitted from the financial institution (S616), determines whether the settlement is possible (S617), and receives an order if the settlement is impossible. Is sent to the personal computer 40 or the mobile phone 13 of the user 12 (S618). In the personal computer 40 or the mobile phone 13 of the user 12, the modem 404 or the transmission / reception unit 135 receives the order cancellation transmitted from the virtual store 24 (S315), and displays that on the display device 406 or 137 (S316). ).
The third embodiment is greatly different from the first and second embodiments in that the virtual account 110 is provided in the settlement organization 90, but is also different in other points. These differences can also be adopted in the first and second embodiments.
[Fourth Embodiment]
In the third embodiment, the user 12 is authenticated based on the personal information 11 provided in the mobile phone company 10, but in the fourth embodiment described below, the user provided in the clearing house 90 is used. Based on the information 910, the user 12 is authenticated. Since the hardware configuration for the fourth embodiment is the same as that shown in FIGS. 47, 49, 53, 57 and 62, description thereof will not be repeated. Hereinafter, the fourth embodiment will be described focusing on the differences from the third embodiment.
1. Prepayment method
First, a prepayment method for depositing into a virtual account will be described. FIG. 65 is a schematic diagram showing a prepayment method according to the fourth embodiment of the present invention. Here, an area for storing a one-time ID, a retail account balance and a retail settlement history, which will be described later, is secured in the RAM 132 of the mobile phone 13. Further, the user information 910 of the settlement institution 90 includes a key code and a password for authenticating the user 12. The user information 910 also includes the e-mail address, usage status, and member classification of the mobile phone 13. The membership classification includes “general” and “member store” of individual users. The virtual account 110 includes a small account balance and a one-time ID. 66 and 67 are flowcharts showing the operations of the mobile phone, the mobile phone company server, and the settlement institution server in the case shown in FIG.
First, the user 12 uses the mobile phone 13 and selects “Prepay” on the menu screen (S98). Specifically, in the mobile phone 13 shown in FIGS. 47, 49, 53, 57, and 62, the input device 136 sends a “prepaid” selection signal in response to the operation of the user 12. To give. Since steps S99 to S103 are the same as those shown in FIG. 50, the description thereof will not be repeated.
After the password verification (S102), the user 12 uses the mobile phone 13 to input a customer number assigned in advance (S175). Specifically, the customer number input by the input device 136 is given to the data processing unit 131 according to the operation of the user 12. Here, the user 12 inputs the customer number. However, the customer number input first may be stored in the RAM 132, and the stored customer number may be transmitted after the second time. Moreover, you may use the telephone number of the mobile telephone 13 as a customer number like the said embodiment.
Subsequently, the transmission / reception unit 135 of the mobile phone 13 transmits the customer number input in step S175, the key code registered in advance in the ROM 133, and the password input in step S101 to the mobile phone company 10 (S176).
In the server 30 of the cellular phone company 10, the data processing unit 301 receives the customer number, key code, and password transmitted from the cellular phone 13, and transmits them to the clearing house 90 via the Internet 60 as they are. That is, the mobile phone company 10 transfers the customer number, key code, and password transmitted from the mobile phone 13 to the settlement organization 90 (S265).
In the server 92 of the clearing house 90, the data processing unit 921 receives the customer number, key code, and password transmitted from the mobile phone 13 through the mobile phone company 10 (S200). Thereafter, the server 92 of the clearing house 90 executes the same processing as steps S203 to S205, S250, and S251 shown in FIGS. 50 and 51 in place of the server 30 of the mobile phone company 10. However, here, the server 92 of the clearing house 90 transmits an authentication abnormality notification to the mobile phone company 10, and the server 30 of the mobile phone company 10 transfers it to the mobile phone 13 (S266). In addition, the server 92 of the settlement institution 90 transmits an unavailable notification to the mobile phone company 10, and the server 30 of the mobile phone company 10 transfers it to the mobile phone 13 (S267). Since steps S150 to S152, S110, and S111 of mobile phone 13 are the same as those shown in FIG. 51, the description thereof will not be repeated.
If the usage status is “available” as a result of the usage status confirmation (S204), the settlement institution 90 requests the user 12 to input a prepaid amount. Specifically, in the server 92 of the clearing house 90, the data processing unit 921 transmits a request for a prepaid amount to the mobile phone 13 (S1340). In the server 30 of the cellular phone company 10, the data processing unit 301 transfers the request for the prepayment amount transmitted from the settlement organization 90 via the Internet 60 to the cellular phone 13 of the user 12 (S268).
In the mobile phone 13 of the user 12, the transmission / reception unit 135 receives the request for the prepayment amount transmitted from the settlement organization 90 via the mobile phone company 10 (S177).
In response to this request, the user 12 operates the input device 136 of the mobile phone 13 to input a desired advance payment amount and select a payment method for the advance payment amount (S178). As this payment method, there are withdrawal from a bank account, debit settlement, credit settlement, transfer, settlement by electronic money, etc. as described above. The transmitting / receiving unit 135 of the mobile phone 13 transmits the input prepaid amount and the selected payment method to the clearing house 90. In the server 30 of the cellular phone company 10, the data processing unit 301 transfers the prepayment amount and payment method transmitted from the cellular phone 13 to the settlement organization 90 (S269).
In the server 92 of the clearing house 90, the data processing unit 921 receives the prepayment amount and the payment method transmitted from the mobile phone 13 via the mobile phone company 10 (S1341).
Subsequently, the data processing unit 921 executes a settlement process for a desired prepaid amount using the selected payment method (S1342).
Subsequently, the data processing unit 921 determines whether payment is possible (S1343). If settlement is impossible, the settlement organization 90 notifies the user 12 that advance payment is not possible. Specifically, in the server 92 of the clearing house 90, the data processing unit 921 transmits a notification that pre-payment is not possible to the mobile phone 13 (S1344). In the server 30 of the mobile phone company 10, the data processing unit 301 transfers the prepayment impossible notice transmitted from the settlement organization 90 via the Internet 60 to the mobile phone 13 (S270).
In the mobile phone 13 of the user 12, the transmission / reception unit 135 receives a notice of non-prepayment sent from the settlement organization 90 via the mobile phone company 10 (S 179), and displays the pre-payment impossible on the display device 137 (S 180). ).
On the other hand, if payment can be made in step S1343, the payment institution 90 notifies the user 12 of the completion of prepaid together with the new balance of the virtual account. Specifically, the data processing unit 921 transmits a prepaid completion notification to the mobile phone 13 together with the balance of the virtual account (S1345). In the server 30 of the mobile phone company 10, the data processing unit 301 transfers the balance of the virtual account and the notice of completion of the prepaid sent from the settlement organization 90 via the Internet 60 to the mobile phone 13 of the user 12 (S271). .
In the mobile phone 13 of the user 12, the transmission / reception unit 135 receives the balance of the virtual account and the advance payment completion transmitted from the settlement organization 90 via the mobile phone company 10 (S 181), and the data processing unit 131 performs the virtual processing. The advance payment completion is displayed on the display device 137 together with the balance of the account (S182).
After the advance payment completion notification (S1345), the data processing unit 921 updates the deposit / withdrawal history 912 based on the advance payment amount (S1306), and further updates the balance of the virtual account 110 (S1308).
Communication according to steps S265 to S271 described above is performed within the same session. Therefore, when communication is interrupted before updating the deposit / withdrawal history and virtual account balance, the deposit / withdrawal history and virtual account balance are not updated.
2. Settlement at virtual store
Next, settlement at a virtual store will be described. The following are two methods for transferring the billing amount from the virtual account to the virtual store.
2-1. First remittance method
FIG. 68 is a conceptual diagram showing a first remittance method according to the fourth embodiment of the present invention. Here, the member store billing history 918 and the member store payment history 920 are recorded in the database 922 provided in the server 92 of the clearing house 90. 69 and 70 are flowcharts showing operations of the personal computer, the mobile phone, the mobile phone company server, the settlement institution server, and the virtual store server in the case shown in FIG.
Similar to the third embodiment, the personal computer 40 or the mobile phone 13 of the user 12 transmits the customer number together with the order contents to the virtual store 24 (S301). The server 50 of the virtual store 24 receives these (S601), and transmits the contents of the bill together with the customer number to the settlement organization 90 (S602).
In the server 92 of the clearing house 90, the data processing unit 921 receives the billing content transmitted from the virtual store 24 (S1310).
Subsequently, the server 92 of the settlement institution 90 executes the same processing as steps S502, S503, and S505 shown in FIG. 54 instead of the server 30 of the mobile phone company 10. However, here, the server 92 of the settlement institution 90 searches the user information 910 in the database 922 based on the customer number instead of the mobile phone number (S502).
When the usage status is “available” as a result of the usage status confirmation (S503), in the server 92 of the settlement institution 90, the data processing unit 921 searches the database 922 based on the customer number, and the user information 910 The e-mail address of the mobile phone 13 is read from the inside, and the electronic bill is transmitted to the mobile phone 13 by e-mail according to the e-mail address (S505). In this electronic bill, a billing number, a billing amount, a remittance destination (member store number), and the like are recorded.
Subsequently, the data processing unit 921 updates the member store billing history 918 and records a billing number, a billing date, a billing amount, and the like based on the electronic bill transmitted from the virtual store 24 (S1340).
In the server 30 of the cellular phone company 10, the data processing unit 301 transfers the electronic mail transmitted from the settlement organization 90 via the Internet 60 to the cellular phone 13 of the user 12 (S272).
In the mobile phone 13, the transmission / reception unit 135 receives an e-mail transmitted from the settlement organization 90 via the mobile phone company 10 (S 401), and the data processing unit 131 opens the e-mail according to the operation of the user 12. Then, the electronic bill is displayed on the display device 137 (S418).
Subsequently, the user 12 confirms the electronic bill, and selects “send money” when sending the billing amount recorded therein to the virtual store 24. At this time, the user 12 operates the input device 136 to input the customer number and password. Accordingly, the mobile phone 13 is connected to the server 92 of the settlement institution 90 according to a remittance URL (Uniform Resource Locator) embedded in the e-mail, and the transmission / reception unit 135 sends a remittance selection signal together with the key code, customer number and password to the settlement institution. 90 (S430). The server 30 of the mobile phone company 10 transfers the remittance selection signal transmitted from the mobile phone 13 to the clearing house 90 via the Internet 60 (S273).
In the server 92 of the clearing house 90, the data processing unit 921 receives the key code, customer number, password, and remittance selection signal transmitted from the mobile phone 13 via the mobile phone company 10 (S1341). The user information 910 in the database 922 is searched based on the number (S1342). Thereafter, the server 92 of the settlement institution 90 executes the same processing as steps S511, S512, S522 to S524 shown in FIG. 55 instead of the server 30 of the mobile phone company 10.
The data processing unit 921 verifies the key code and the password (S511, S512). If both match, the remittance completion notification is sent together with the new balance of the virtual account 110 via the mobile phone company 10 to the mobile phone 13 of the user 12. (S1343). The server 30 of the mobile phone company 10 transfers the remittance completion notification transmitted from the settlement organization 90 via the Internet 60 to the mobile phone 13 of the user 12 (S275). In the mobile phone 13, the transmission / reception unit 135 receives the remittance completion notification transmitted from the settlement organization 90 via the mobile phone company 10 (S 431), and the data processing unit 131 completes the remittance with the virtual account balance after remittance. The information is displayed on the display device 137 (S432).
After the remittance completion notification (S1343), the server 92 of the clearing house 90 executes the same processing as steps S1320 to S1322 shown in FIG.
After updating the virtual account balance (S1322), the data processing unit 921 updates the member store billing history 918 in the database 922 and records the payment date (S1344).
Subsequently, the data processing unit 921 updates the member store deposit history 920 in the database 922, and records the bill number, deposit date, deposit amount, remittance customer number, etc. (S1345).
Subsequently, the data processing unit 921 transmits a payment notice to the virtual store 24 via the Internet 60 (S1346). In the server 50 of the virtual store 24, the modem 504 receives the payment notification transmitted from the settlement organization 90 (S619).
Here, communication according to steps S272 to S275 is performed within the same session.
2-2. Second remittance method
FIG. 71 is a conceptual diagram showing a second remittance method according to the fourth embodiment of the present invention. 72 and 73 are flowcharts showing operations of the personal computer, the mobile phone, the mobile phone company server, the settlement institution server, and the virtual store server in the case shown in FIG.
The virtual store 24 that has received the order does not notify the user 12 of the payment content via the settlement organization 90 as in the first remittance method, but directly notifies the user 12 of the payment content here. Specifically, in the server 50 of the virtual store 24, after receiving the order (S <b> 601), the data processing unit 501 sends the billing contents such as the member store number of the virtual store 24 and the billing amount via the Internet 60 to the user 12. To the mobile phone 13 or the personal computer 40 (S620). In the cellular phone 13 or the personal computer 40 of the user 12, the transmission / reception unit 135 or the modem 404 receives them (S312).
The user 12 operates the cellular phone 13 while seeing the notified billing contents, and selects “Send Money” from the menu screen (S97). As in steps S99 to 103, S175, S176, S265, and S200 shown in FIG. 66, the user 12 inputs a password and a customer number, and the mobile phone 13 transmits these together with a key code to the settlement organization 90 for settlement. The engine 12 receives these.
Subsequently, in the same manner as steps S502, S503, S1314, S603, S604, S302, S303, S511, S512, S522, S524, S274, S159, and S613 shown in FIG. , S512, if both the key code and the password match, the user 12 is requested to input specific remittance details. In response to this request, the user 12 inputs specific remittance content and transmits it to the clearing house 90.
Specifically, in the server 92 of the clearing house 90, the data processing unit 921 transmits a request for remittance content to the mobile phone 13 of the user 12 (S1347). In the server 30 of the cellular phone company 10, the data processing unit 301 transfers the request for the remittance content transmitted from the settlement organization 90 via the Internet 60 to the cellular phone 13 (S276).
In the mobile phone 13 of the user 12, the transmission / reception unit 135 receives the request for the remittance content transmitted from the settlement organization 90 via the mobile phone company 10 (S433).
Subsequently, the input device 136 gives the remittance content input in accordance with the operation of the user 12 to the data processing unit 131, and the transmitting / receiving unit 135 transmits the input remittance content to the settlement organization 90 (S434). The details of the remittance include the merchant number of the remittance destination and the amount of remittance. In the server 30 of the cellular phone company 10, the data processing unit 301 transfers the remittance content transmitted from the cellular phone 13 to the settlement organization 90 (S277). In the server 92 of the clearing house 90, the data processing unit 921 receives the remittance content transmitted from the mobile phone 13 via the mobile phone company 10 (S1348). The subsequent steps are the same as steps S 1343, S 275, S 431, S 432, S 1320 to S 1322, S 1345, S 1346, and S 619 shown in FIG. 70, and therefore description thereof will not be repeated. However, here, since there is no billing history 918 shown in FIG. 68, the billing history is not updated (S1344).
3. Settlement at a real store
Next, settlement at an actual store will be described. Here, a small account that can be transferred from the virtual account is further provided, and a one-time ID (identifier) that enables the use of the small account is issued.
3-1. Issuing a one-time ID (transfer to a small account)
74 and 75 are conceptual diagrams showing a one-time ID issuing method according to the fourth embodiment of the present invention. 74 shows a case where there is no retail payment history, and FIG. 75 shows a case where there is a retail payment history. Here, the deposit / withdrawal history 915 of the small account is recorded in the database 922 provided in the server 92 of the clearing house 90. FIGS. 76 and 77 are flowcharts showing the operations of the mobile phone, the mobile phone company server, and the settlement institution server in the case shown in FIGS. 74 and 75.
When a desired amount is to be transferred from a virtual account to a small account in order to make a payment at a real store, the user 12 operates the mobile phone 13 and selects “One Time ID” on the menu screen (S96). Specifically, in the mobile phone 13, the input device 136 gives a selection signal of “one time ID” to the data processing unit 131 in accordance with the operation of the user 12. Thereafter, steps S99 to S103, S175 are the same as those shown in FIG. 66, and therefore description thereof will not be repeated.
After inputting the customer number (S175), in the mobile phone 13, the transmission / reception unit 135 transmits the customer number, the key code, the password, and the personal account information to the settlement organization 90 (S185). The personal account information includes the personal account balance and the personal payment history recorded in the RAM 132. However, when a one-time ID is requested for the first time, the retail payment history does not exist yet. Thereafter, steps S265 to S267, S200, S202 to S205, S250, S251, S150 to S152, S110, and S111 are the same as those shown in FIG. 66, and therefore, description thereof will not be repeated.
As a result of the authentication of the user 12 (S203), if both the key code and the password match and the usage status is “usable” as a result of the usage status confirmation (S204), the clearing house 90 And request the transfer amount from the virtual account to the small account. Specifically, in the server 92 of the clearing house 90, the data processing unit 921 transmits a request for the desired transfer amount to the personal account to the mobile phone 13 of the user 12 (S1350). At this time, the limit amount that can be transferred (usually the balance of the virtual account) is also transmitted. In the server 30 of the mobile phone company 10, the data processing unit 301 transfers the transfer amount request transmitted from the settlement organization 90 via the Internet 60 to the mobile phone 13 (S278).
In the mobile phone 13 of the user 12, the transmission / reception unit 135 receives the request for the transfer amount transmitted from the settlement organization 90 via the mobile phone company 10 (S186).
In response to this request, the user 12 operates the input device 136 of the mobile phone 13 to designate a desired transfer amount (S187). The input device 136 gives the transfer amount designated by the user 12 to the data processing unit 131.
The data processing unit 131 compares the settlement amount specified in step S187 with the limit amount received in step S186, and determines whether or not the specified settlement amount is within the limit amount (S188). When the designated transfer amount exceeds the limit amount, the data processing unit 131 displays that transfer is not possible on the display device 137 (S189). On the other hand, when the designated transfer amount is within the limit amount, the transmission / reception unit 135 transmits the designated transfer amount to the clearing house 90 (S190). In the server 30 of the mobile phone company 10, the data processing unit 301 transfers the transfer amount transmitted from the mobile phone 13 of the user 12 to the clearing house 90 via the Internet 60 (S279).
In the server 92 of the clearing house 90, the data processing unit 921 receives the transfer amount transmitted from the mobile phone 13 of the user 12 via the mobile phone company 10 (S1351), and further randomly generates a one-time ID. (S1352).
Subsequently, the data processing unit 921 updates the virtual account deposit / withdrawal history 912 based on the transfer amount received in step S1351 (S1320), updates the virtual account settlement history 914 (S1321), and updates the virtual account 110. The balance is updated (S1322), and the deposit / withdrawal history 915 of the retail account is updated (S1345).
For example, as shown in FIG. 74, when the user 12 designates the transfer amount as 1000 yen, the virtual account deposit / withdrawal history 912 records that 1000 yen has been withdrawn into the small account. Further, the balance of the virtual account 110 is reduced by 1000 yen, and the balance of the personal account is increased by 1000 yen. Further, the fact that 1000 yen has been deposited is recorded in the input / output history 915 of the personal account. In this case, since the retail payment history is not transmitted from the mobile phone 13, the payment history 914 of the virtual account is not updated.
Next, as shown in FIG. 75, when the fact that 300 yen has been used is recorded in the retail payment history of the mobile phone 13 (that is, the retail account balance of the mobile phone 13 is 700 yen), the user 12 When the transfer amount is designated as 1500 yen, the difference (800 yen) between this transfer amount (1500 yen) and the current account balance (700 yen) is calculated, and the input / output history 912 of the virtual account contains 800 The fact that the yen has been withdrawn is recorded. Further, based on the small payment history of the mobile phone 13, the virtual account payment history 914 records that 300 yen has been used for payment. Based on the difference, the balance of the virtual account 110 is reduced by 800 yen to 200 yen. 300 yen was used for settlement from the small account, but since 800 yen is newly transferred to the small account, the balance of the small account becomes 1500 yen, which is equal to the above transfer amount. Further, in the deposit / withdrawal history 915 of the retail account, it is recorded that 300 yen has been withdrawn based on the retail settlement history of the mobile phone 13, and further, that 800 yen has been deposited based on the above difference. .
Finally, the data processing unit 921 transmits the transfer contents such as the one-time ID and the small account balance generated in step S1352 to the mobile phone 13 of the user 12 (S1353). In the server 30 of the mobile phone company 10, the data processing unit 301 transfers the transfer contents transmitted from the settlement organization 90 via the Internet 60 to the mobile phone 13 (S280).
In the mobile phone 13 of the user 12, the transmission / reception unit 135 receives the transfer content transmitted from the settlement organization 90 via the mobile phone company 10 (S119).
Subsequently, the data processing unit 131 clears the retail payment history recorded in the RAM 132 (S192). Subsequently, the data processing unit 131 rewrites the personal account balance recorded in the RAM 132 (S193), and further rewrites the one-time ID recorded in the RAM 132 (S194).
For example, in the case shown in FIG. 74, the one-time ID “98765” generated by the clearing house 90 is recorded in the RAM 132 of the mobile phone 13. Further, the account balance is updated from “0 yen” to “1000 yen” in accordance with the transfer amount designated by the user 12. 75, the new one-time ID “34567” generated by the clearing house 90 is recorded in the RAM 132 of the mobile phone 13. In addition, the new retail account balance of “1500 yen” calculated by the settlement organization 90 is recorded in the RAM 132 of the mobile phone 13.
Finally, the data processing unit 131 displays the payment completion to the personal account together with the personal account balance on the display device 137 (S195).
3-2. Use of one-time ID (payment from a small account)
FIG. 78 is a conceptual diagram showing a method of making a payment at an actual store using a one-time ID according to the fourth embodiment of the present invention. FIG. 79 is a flowchart showing the operations of the mobile phone, the POS terminal at the actual store, and the server of the payment institution in the case shown in FIG.
When a desired amount is transferred to the personal account and the one-time ID is acquired, and then payment is made at the actual store 26, the user 12 operates the mobile phone 13 and selects “payment” on the menu screen (S95). Specifically, in the mobile phone 13, the input device 136 gives a “payment” selection signal to the data processing unit 131 in accordance with the operation of the user 12. Since steps S99 to S103 are the same as those shown in FIG. 66, the description thereof will not be repeated.
After the password verification (S102), the data processing unit 131 determines whether or not the one-time ID recorded in the RAM 132 is valid (S735). The effective date is given to the one-time ID, and the balance of the personal account can only be used for settlement at the actual store until the effective date. The one-time ID may be invalidated once it is used for settlement at a real store.
If the one-time ID is invalid, the data processing unit 131 displays the fact on the display device 137 (S736). On the other hand, if the one-time ID is valid, the data processing unit 131 displays on the display device 137 that payment from the personal account is possible (S737). Hereinafter, steps S716 to S719 and S801 are the same as those shown in FIG. 59, and therefore description thereof will not be repeated.
As a result of the balance verification (S718), when the settlement amount transmitted from the POS terminal 27 is within the balance of the small account, the interface unit 139 of the mobile phone 13 transmits the one-time ID recorded in the RAM 132 to the POS terminal 27. (S738).
Subsequently, the data processing unit 131 updates the retail payment history recorded in the RAM 132 (S739). Specifically, the data processing unit 131 stores the payment amount, the payment date, the member store number of the real store 26, and the like transmitted from the POS terminal 27.
Subsequently, the data processing unit 131 updates the balance of the personal account recorded in the RAM 132 (S740). Specifically, the data processing unit 131 subtracts the settlement amount from the balance of the personal account and records a new balance. At this time, the balance of the small account of the mobile phone 13 is shifted from the balance of the small account of the settlement organization 90.
Finally, the data processing unit 131 displays the completion of settlement on the display device 137 together with the new balance of the retail account (S741).
In the POS terminal 27 of the actual store 26, the interface unit 276 receives the one-time ID transmitted from the mobile phone 13 (S810).
Subsequently, the data processing unit 271 executes sales recording processing based on the settlement amount (S811).
Subsequently, the interface unit 276 transmits the payment contents such as the one-time ID, the payment date, the payment amount, and the customer number together with the member store number to the payment organization 90 (S805).
In the server 92 of the payment institution 90, the data processing unit 921 receives the payment contents transmitted from the POS terminal 27 (S1333), and updates the payment history 920 of the member store based on the received payment contents (S1355). .
Subsequently, the data processing unit 921 transmits a notification that the payment has been approved to the real store 26 (S1324). The POS terminal 27 of the actual store 26 receives the notification of payment approval transmitted from the settlement organization 90 (S806).
Finally, the data processing unit 921 calculates the total payment amount for one month at the end of the month, for example, and executes the payment process for the actual store 26 (S1325).
In the above-described fourth embodiment, the server 30 of the mobile phone company 10 transfers the key code transmitted from the mobile phone 13 to the server 92 of the clearing house 90 as it is, but the key transmitted from the mobile phone 13 The code may be converted into another key code corresponding to the code and transmitted to the server 92 of the settlement institution 90.
In addition, a one-time ID is downloaded when transferring to a small account, but each time the user 12 accesses the service site provided by the settlement organization 90 with the mobile phone 13, a new one-time ID is automatically obtained. May be downloaded. In this case, since the update frequency of the one-time ID is increased, the security is further increased.
Further, the one-time ID may be an image of a one-dimensional or two-dimensional barcode, and the barcode displayed on the mobile phone 13 may be optically read by the reader of the POS terminal 27 at the time of settlement at an actual store. Good. In this case, it is not necessary to attach a dedicated device for reading information from the mobile phone 13 to the POS terminal 27, and an existing bar code reader may be used. Further, the balance of the personal account may be added to the barcode of the one-time ID.
According to the fourth embodiment of the present invention, since the payment institution 90 acquires the key code output from the mobile phone 13 and authenticates the user 12, the authentication depends on the mobile phone company 10. There is nothing. Therefore, this service can be provided only by the settlement company 90.
In addition, a small account is provided separately from the virtual account, and when making a payment at a real store, the virtual account is transferred to the small account in advance, and the payment is made from the small account. As in the second embodiment, the balance of the virtual account does not deviate from the true balance. In addition, the settlement institution issues a one-time ID for enabling withdrawal from the small account, and the mobile phone 13 transfers to the POS terminal 27 only when the one-time ID is valid and the settlement amount is within the balance of the small account. Since the one-time ID is output and the POS terminal 27 completes the settlement based on the one-time ID, security is increased.
A predetermined program is installed in each of the computers. Each program is for causing a corresponding computer to execute a series of steps arranged in each column shown in the flowchart. Each program can be distributed by being recorded on a computer-readable medium such as a CD-ROM.
The embodiments disclosed herein are illustrative and non-restrictive in every respect. The scope of the present invention is defined by the scope of the claims, not the embodiment described above, and is intended to include meanings equivalent to the scope of the claims and all modifications within the scope.
Industrial applicability
The present invention is applicable to a payment service using a mobile phone.
[Brief description of the drawings]
FIG. 1 is a schematic diagram showing fund transfer in the case where a prepaid amount to be deposited into a virtual account is paid together with a call charge according to the first embodiment of the present invention.
FIG. 2 is a schematic diagram showing the transfer of funds when a prepaid amount to be deposited into the virtual account is paid by a credit card according to the first embodiment of the present invention.
FIG. 3 is a schematic diagram showing the transfer of funds when the prepaid amount to be deposited into the virtual account is paid by the debit card according to the first embodiment of the present invention.
FIG. 4 is a schematic diagram showing the transfer of funds when the prepayment amount deposited into the virtual account is automatically withdrawn from the bank account according to the first embodiment of the present invention.
FIG. 5 is a schematic diagram showing a method of making a payment at a virtual store on the Internet using a mobile phone according to the first embodiment of the present invention.
FIG. 6 is a schematic diagram showing a method of making a payment at an actual store using a mobile phone according to the first embodiment of the present invention.
FIG. 7 is a block diagram showing a hardware configuration of a cellular phone and a cellular phone company server used for depositing a prepayment into a virtual account as shown in FIGS.
FIG. 8 is a flowchart showing the operations of the cellular phone and cellular phone company server shown in FIG. 7 in the case shown in FIG.
FIG. 9 is a transition diagram of screens displayed during the operation of the mobile phone shown in FIG.
FIG. 10 is a flowchart showing the operations of the cellular phone and cellular phone company server shown in FIG. 7 in the case shown in FIG.
FIG. 11 is a transition diagram of screens displayed during the operation of the mobile phone shown in FIG.
FIG. 12 is a flowchart showing the operation of the cellular phone shown in FIG. 7 and the server of the cellular phone company in the case shown in FIG.
FIG. 13 is a transition diagram of screens displayed during operation of the mobile phone shown in FIG.
FIG. 14 is a flowchart showing the operations of the cellular phone and cellular phone company server shown in FIG. 7 in the case shown in FIG.
FIG. 15 is a transition diagram of screens displayed during the operation of the mobile phone shown in FIG.
FIG. 16 shows a mobile phone, a mobile phone company server, a personal computer, and a virtual store server used when making a payment using a mobile phone at a virtual store on the Internet according to the first embodiment of the present invention. It is a block diagram which shows a hardware configuration.
FIG. 17 is a flowchart showing operations of the personal computer, the mobile phone, the mobile phone company server, and the virtual store server shown in FIG. 16 in the case shown in FIG.
FIG. 18 is a flowchart following FIG.
FIG. 19 is a transition diagram of screens displayed during the operation of the mobile phone shown in FIGS. 17 and 18.
FIG. 20 is a block diagram showing a hardware configuration of the mobile phone, the mobile phone company server, and the POS terminal of the actual store used in the case shown in FIG.
FIG. 21 is a flowchart showing operations of the mobile phone, the POS terminal at the actual store, and the server of the mobile phone company shown in FIG.
FIG. 22 is a flowchart following FIG.
FIG. 23 is a transition diagram of screens displayed during operation of the mobile phone shown in FIGS. 21 and 22.
FIG. 24 is a diagram showing information stored in the RAM and ROM of the mobile phone.
FIG. 25 is a schematic diagram showing the transfer of funds when transferring from a real account to a virtual account according to the second embodiment of the present invention.
FIG. 26 is a block diagram showing a hardware configuration of a mobile phone, a mobile phone company server, and a financial institution server used for transfer from a real account to a virtual account as shown in FIG.
27 is a flowchart showing operations of the mobile phone, the mobile phone company server, and the financial institution server shown in FIG. 26 in the case shown in FIG.
FIG. 28 is a flowchart following FIG.
FIG. 29 is a transition diagram of screens displayed during the operation of the mobile phone shown in FIGS. 27 and 28.
FIG. 30 is a schematic diagram showing a method of making a payment at a virtual store on the Internet using a mobile phone according to the second embodiment of the present invention.
FIG. 31 is a block diagram showing a hardware configuration of a personal computer, a mobile phone, a mobile phone company server, a financial institution server, a settlement institution server, and a virtual store server used in the case shown in FIG. .
32 is a flowchart showing operations of the personal computer, the mobile phone, the mobile phone company server, the virtual store server, and the financial institution server shown in FIG. 31 in the case shown in FIG.
FIG. 33 is a flowchart following FIG.
FIG. 34 is a flowchart following FIG.
FIG. 35 is a transition diagram of screens displayed during operation of the mobile phone shown in FIGS.
FIG. 36 is a schematic diagram showing a method of making a payment at an actual store using a mobile phone according to the second embodiment of the present invention.
FIG. 37 is a block diagram showing a hardware configuration of a mobile phone, a POS terminal at a real store, a mobile phone company server, a financial institution server, and a settlement institution server used in the case shown in FIG.
FIG. 38 is a flowchart showing the operations of the mobile phone, the POS terminal, the mobile phone company server, and the financial institution server shown in FIG. 37 in the case shown in FIG.
FIG. 39 is a flowchart following FIG.
FIG. 40 is a flowchart following FIG.
FIG. 41 is a schematic diagram showing a method for registering service user information according to the third embodiment of the present invention.
FIG. 42 is a schematic diagram showing fund transfer when depositing a prepaid amount into a virtual account according to the third embodiment of the present invention.
FIG. 43 is a schematic diagram showing a method for making a payment at a virtual store on the Internet using a mobile phone according to the third embodiment of the present invention.
FIG. 44 is a schematic diagram showing a method of making a payment at an actual store using a mobile phone according to the third embodiment of the present invention.
FIG. 45 is a schematic diagram showing a method by which a clearing house requests unnotified data stored in a mobile phone from a user according to the third embodiment of the present invention.
FIG. 46 is a schematic diagram showing a method in which a settlement institution makes a charge to a financial institution when making a settlement at a virtual store on the Internet using a mobile phone according to the third embodiment of the present invention.
FIG. 47 is a block diagram showing a hardware configuration of the cellular phone, the cellular phone company server, and the settlement institution server used for the usage registration shown in FIG.
48 is a flowchart showing operations of the mobile phone, the mobile phone company server, and the settlement institution server shown in FIG. 47 in the case shown in FIG.
FIG. 49 is a block diagram showing a hardware configuration of a mobile phone, a mobile phone company server, a settlement institution server, and a financial institution server used for transferring funds to the virtual account shown in FIG.
FIG. 50 is a flowchart showing operations of the mobile phone, the mobile phone company server, and the settlement institution server shown in FIG. 49 in the case shown in FIG.
FIG. 51 is a flowchart following FIG.
FIG. 52 is a flowchart subsequent to FIG.
53 is a block diagram showing a hardware configuration of a personal computer, a mobile phone, a mobile phone company server, a settlement institution server, and a virtual store server used for settlement at the virtual store shown in FIG.
FIG. 54 is a flowchart showing operations of the personal computer, the mobile phone, the mobile phone company server, the settlement institution server, and the virtual store server shown in FIG. 53 in the case shown in FIG.
FIG. 55 is a flowchart following FIG.
FIG. 56 is a flowchart following FIG.
FIG. 57 is a block diagram showing a hardware configuration of a mobile phone, a POS terminal, a mobile phone company server, and a payment institution server used for payment at the actual store shown in FIG.
FIG. 58 is a flowchart showing operations of the mobile phone, the POS terminal, the mobile phone company server, and the settlement institution server shown in FIG. 57 in the case shown in FIG.
FIG. 59 is a flowchart subsequent to FIG.
FIG. 60 is a flowchart following FIG.
FIG. 61 is a flowchart showing operations of the cellular phone, the cellular phone company server, and the clearing house server in the case of the unnotified data request shown in FIG.
FIG. 62 is a block diagram showing the hardware configuration of a personal computer, a mobile phone, a mobile phone company server, a settlement institution server, a financial institution server, and a virtual store server used for the billing agency shown in FIG. is there.
FIG. 63 is a flowchart showing the operations of the personal computer, mobile phone, mobile phone company server, settlement institution server, financial institution server, and virtual store server shown in FIG. 62 in the case shown in FIG. .
FIG. 64 is a flowchart subsequent to FIG.
FIG. 65 is a schematic diagram showing a prepayment method according to the fourth embodiment of the present invention.
FIG. 66 is a flowchart showing operations of the cellular phone, the cellular phone company server, and the settlement institution server in the case shown in FIG.
FIG. 67 is a flowchart subsequent to FIG.
FIG. 68 is a conceptual diagram showing a first remittance method according to the fourth embodiment of the present invention.
FIG. 69 is a flowchart showing operations of the personal computer, the mobile phone, the mobile phone company server, the settlement institution server, and the virtual store server in the case shown in FIG.
FIG. 70 is a flowchart following FIG.
FIG. 71 is a conceptual diagram showing a second remittance method according to the fourth embodiment of the present invention.
72 is a flowchart showing operations of the personal computer, the mobile phone, the mobile phone company server, the settlement institution server, and the virtual store server in the case shown in FIG.
FIG. 73 is a flowchart following FIG.
FIG. 74 is a conceptual diagram showing a one-time ID issuance method when there is no retail payment history according to the fourth embodiment of the present invention.
FIG. 75 is a conceptual diagram showing a one-time ID issuance method when there is a retail payment history according to the fourth embodiment of the present invention.
FIG. 76 is a flowchart showing operations of the cellular phone, the cellular phone company server, and the settlement institution server in the case shown in FIG. 74 and FIG.
FIG. 77 is a flowchart following FIG.
FIG. 78 is a conceptual diagram showing a method of making a payment at an actual store using a one-time ID according to the fourth embodiment of the present invention.
FIG. 79 is a flowchart showing the operations of the mobile phone, the POS terminal at the actual store, and the server of the payment institution in the case shown in FIG.

Claims

A payment system comprising: a mobile phone; a terminal that accepts payment using the mobile phone; and a computer that manages payment by the mobile phone and the terminal ,
The mobile phone is
Means for requesting the computer to generate a one-time identifier for enabling a balance of a retail account;
A means for entering the desired transfer amount to be transferred from the original account to the retail account;
Means for transmitting the input transfer amount to the computer ;
Means for receiving a one-time identifier and a balance of a personal account transmitted from the computer;
Means for storing the received one-time identifier;
Means for storing the balance of the received retail account;
Means for determining whether the one-time identifier stored in the mobile phone is valid;
As a result of the determination of the one-time identifier, if the one-time identifier is valid, means for receiving a settlement amount transmitted from the terminal ;
Means for determining whether the received payment amount is within a balance of a personal account stored in the mobile phone ;
As a result of the determination of the payment amount, if the payment amount is within the balance of the retail account, means for transmitting the received one-time identifier to the terminal ;
Means for updating the balance of the retail account by subtracting the settlement amount from the balance of the retail account ;
The terminal
Means for transmitting a settlement amount to the mobile phone;
Means for receiving a one-time identifier transmitted from the mobile phone;
Means for transmitting the payment amount and the received one-time identifier to the computer,
The computer
Means for storing the balance of the retail account;
Means for receiving the transfer amount transmitted from the mobile phone;
Means for generating a one-time identifier in response to a request from the mobile phone;
Means for updating the balance of the personal account stored in the computer by transferring the received transfer amount from the original account to the personal account;
Means for transmitting the generated one-time identifier and the updated balance account balance to the mobile phone;
Means for receiving a settlement amount and a one-time identifier transmitted from the terminal;
Means for recording the received payment amount and one-time identifier.

The mobile phone further includes
The settlement system according to claim 1, further comprising means for transmitting identification information necessary for user authentication to the computer.

The payment system according to claim 2, wherein the identification information includes user-specific information unique to the user.

The mobile phone further includes
4. The settlement system according to claim 3, further comprising means for storing the user specific information.

The payment system according to claim 3, wherein the user-specific information includes a telephone number of the mobile phone.

The payment system according to claim 5, wherein the user-specific information further includes a password.

The payment system according to claim 3, wherein the user-specific information includes a user identifier assigned in advance to the user.

The payment system according to claim 7, wherein the user-specific information further includes a password.

The payment system according to claim 3, wherein the identification information further includes telephone-specific information specific to the mobile phone.

The mobile phone further includes
The payment system according to claim 9, comprising means for storing the telephone-specific information.

The payment system according to claim 10, wherein the telephone-specific information includes a manufacturing number of a mobile phone.

The payment system according to claim 10, wherein the telephone-specific information includes a subscriber identifier of the mobile phone.