(57)【要約】【課題】プリペイドタイプの電子マネーを用いた決済システムを提供する。【解決手段】電子マネー毎に、電子マネーＩＤおよびユーザの携帯電話１の機種固有情報と対応づけて残高が電子マネーデータベースに登録されている。ユーザは電子マネーＩＤを指定して決済することもできるが、携帯電話１を介して購入申込をするならば、電子マネーＩＤを指定しなくても自動送信される機種固有情報によってデータベースから残高が取り出されて決済可否が判定でき決済可能である。携帯電話１の機種固有情報を受信したときは、一の電子マネーの残高では不足でも、同一の機種固有情報と対応づけられた他の電子マネーが１以上あるならば、これら複数の電子マネーの残高を合算して決済可否を判定する。【選択図】図４
2013065360.tif 000002
【特許請求の範囲】
【請求項１】
プリペイドタイプの電子マネーの購入時に使用されたユーザ携帯端末の機種固有情報を、電子マネーＩＤおよび電子マネーの残高と対応付けて電子マネー毎に電子マネー残高記憶手段に格納しておいて、この電子マネーを決済に利用するシステムであって、
商品購入申込とともに電子マネーＩＤを受信したときは、前記電子マネー残高記憶手段から前記電子マネーＩＤに対応する残高を取り出し、電子マネーＩＤが不受信であっても商品購入申込とともに前記ユーザ携帯端末の機種固有情報を受信したときは、受信した機種固有情報に対応する残高を取り出し、取り出した残高が購入申込商品の取引金額以上であれば決済可能と判定する決済可否判定手段と、
決済可能の場合に、前記電子マネー残高記憶手段に記憶される残高を、これから前記取引金額を減じた値に更新する電子マネー残高更新手段と
を備え、
前記決済可否判定手段は、機種固有情報を受信したときは、一の電子マネーの残高が取引金額未満であっても、前記電子マネー残高記憶手段に同一の機種固有情報と対応づけられた他の１以上の電子マネーが記憶されている場合、決済の可否はこれら複数の電子マネーの残高の合算値と前記取引金額との比較によって判定する
ことを特徴とする決済システム。
【発明の詳細な説明】
【技術分野】
【０００１】
商品購入の支払いをプリペイドタイプの電子マネーを使用して簡便に行うことのできる決済システムに関する。
【背景技術】
【０００２】
インターネットの普及に伴い、有形無形の商品の売買がインターネット上で行われるようになってきた。支払いはクレジット払いによることが多いが、そのためには通信ネットワークを介して販売者側にクレジットカード番号などの個人情報を送信しなくてはならない。この結果引き起こされる個人情報の流出事故が世上を賑わし、金銭面の具体的なトラブルだけではなく、インターネット売買の普及そのものにブレーキをかけているという。
このような事態に鑑み、これまでにも安全な支払い手段が提案されてきた。
特許文献１に記載の発明もその一つであり、プリペイドタイプの電子マネーを支払い手段とするものである。
【０００３】
一方、携帯電話の機能が通話に限らず広範になってきていることから、この携帯電話は金銭的価値の交換手段としても用いられるようになってきている。特許文献２に記載の発明も、このような用途で携帯電話を活用することを意図しており、携帯電話からの電子マネーによる電子投票などを提案している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−３２７０５０号公報（〔００４２〕、〔００５８〕、図５）
【特許文献２】特開２００８−２５７４３０号公報（〔００１７〕、〔００１９〕、〔００３７〕）
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、一般に「電子マネー」には、（ａ）ＩＣカード型と、（ｂ）パソコンや携帯電話の内部メモリ内に設けられたタイプ（以下、「携帯内蔵型」という）と、（ｃ）ネットワークを経由して電子マネー管理会社のシステムと接続するデータベースなどに設けられたタイプ（以下、「ネットワーク型」という）とがある。
【０００６】
特許文献１に記載の発明は、上記の（ｃ）のタイプの電子マネーを念頭においているが、電子マネーの識別情報を入力しなくてはならない。
電子マネーは大量に発行されているため、個々の電子マネーを他と区別するための識別情報の桁数は当然多くなる。滅多に購入しない高額商品ならともかく、単価が安くしかも頻繁に購入するインターネット上の商品のために、桁数の多い識別情報を購入の都度入力することは煩雑である。普及すればするほど桁数は大きくなるのだから、利便性を欠き、インターネット売買の普及という基本的なテーマに応えきれていない。
【０００７】
特許文献２に記載の発明の電子マネーは、（ｂ）の携帯内蔵型と（ｃ）のネットワーク型のいずれも想定しており、インターネットを介して払戻システムへアクセスする際に、電子マネー会員であることの確認のために。顧客端末の固体情報が送信される。固体情報によって会員認証がなされるので、会員は特に識別情報などを入力しなくてもよい。このように、ユーザに高い利便性を提供してくれるのではあるが、こと「プリペイドタイプのネットワーク型電子マネー」の場合に限ると致命的な欠点を有する。このことについて説明する。１つの電子マネーの残高が乏しくなった場合でも同一人の持つ複数の電子マネーを合算すれば必要な金額を充たすことがある。ところで、金融機関の用語では、同一顧客の複数の口座を一元管理することを「名寄せ」という。これに倣って、同一顧客の複数の電子マネーを一括して管理することを電子マネー版の「名寄せ」と称するならば、特許文献２の発明にはこの名寄せの機能がない。ＩＣカード型あるいは携帯内蔵型の電子マネーならば簡単にチャージできるので何ら問題はないが、チャージができないプリペイドのネットワーク型電子マネーでは小額が頻繁に取引されるのであるから、この名寄せの機能は重要である。
【０００８】
以上の問題点に鑑み、本発明は（ｃ）のネットワーク型の電子マネーの使いやすさの向上を図ることを目的とした。具体的には、電子マネーの識別情報を入力不要とし、かつ、自分の持っている複数の電子マネーの残額を合算して支払いにあてることを可能とすることで、インターネット上での商品購入から決済までを電子マネーを用いて迅速かつ簡便に行えるようにすることである。
【課題を解決するための手段】
【０００９】
上記の目的を達成するために、本発明は、
プリペイドタイプの電子マネーの購入時に使用されたユーザ携帯端末の機種固有情報を、電子マネーＩＤおよび電子マネーの残高と対応付けて電子マネー毎に電子マネー残高記憶手段に格納しておいて、この電子マネーを決済に利用するシステムであって、
商品購入申込とともに電子マネーＩＤを受信したときは、前記電子マネー残高記憶手段から前記電子マネーＩＤに対応する残高を取り出し、電子マネーＩＤが不受信であっても商品購入申込とともに前記ユーザ携帯端末の機種固有情報を受信したときは、受信した機種固有情報に対応する残高を取り出し、取り出した残高が購入申込商品の取引金額以上であれば決済可能と判定する決済可否判定手段と、
決済可能の場合に、前記電子マネー残高記憶手段に記憶される残高を、これから前記取引金額を減じた値に更新する電子マネー残高更新手段と
を備え、
前記決済可否判定手段は、機種固有情報を受信したときは、一の電子マネーの残高が取引金額未満であっても、前記電子マネー残高記憶手段に同一の機種固有情報と対応づけられた他の１以上の電子マネーが記憶されている場合、決済の可否はこれら複数の電子マネーの残高の合算値と前記取引金額との比較によって判定する
ことを特徴とする。
「ユーザ」とは、本発明のシステムを利用して商品の購入と支払いを行おうとする者をいう。ユーザ携帯端末としては、下記の実施の形態では携帯電話を用いている。携帯電話は、普及が著しく、かつカメラ機能、ウェブページ閲覧機能などの通話以外の機能が豊富になっているからである。
「商品」は、本や各種チケットのような形の有るものに限らず、デジタルデータのような無形のものでもよい。
【００１０】
このように機種固有情報を受信した場合は残高を合算する機能が備わっているので、ひとつの電子マネーでは取引金額に足りず購入できなくても、複数の電子マネーを合算すると取引金額以上の残高があれば購入することができる。この残高の合算は、決済サーバが行うのでユーザによる操作を必要としない。また、残高がわずかの電子マネーが使われずに残るといったことも防げる。
【発明の効果】
【００１１】
ユーザは、電子マネーの購入時に使用した携帯電話を介して商品を購入するならば、電子マネーの識別情報を入力しなくても電子マネーを利用することができる。
一人で複数の電子マネーを持っている場合でも、データベースでは携帯電話の機種固有情報との対応づけで同一人の電子マネーと判断できるので、一つの電子マネーの残高では購入金額に満たないときでも、複数の電子マネーを合算すると購入金額以上であれば購入可能となる。
【図面の簡単な説明】
【００１２】
【図１】実施の形態のシステムの構成を示す図である。
【図２】実施の形態の携帯電話のブロック図である。
【図３】実施の形態の決済サーバのブロック図である。
【図４】実施の形態の電子マネーＤＢのテーブル構造を例示する図である。
【図５】実施の形態の販売サーバのブロック図である。
【図６】実施の形態のシステムの処理フローを示す図である。
【図７】実施の形態の商品購入申込の画面例を示す図である。
【図８】実施の形態の支払い方法選択の画面例を示す図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照しながら本発明の一実施の形態のシステム（以下、「本システム」）について説明する。
【００１４】
《本システムの概略》
まず、本システムの概略を説明する。
ユーザ（Ａ）は、コンビニなどで電子マネー管理会社（Ｂ）の電子マネー（Ｃ）を購入する。購入すると電子マネー（Ｃ）の識別情報である電子マネーＩＤ（Ｄ）およびこのＩＤ（Ｄ）をコード化したＱＲコード（登録商標）が印刷されたカードあるいはレシートが渡される。ユーザ（Ａ）は、自分の携帯電話（Ｅ）でＱＲコードを読み取ることにより、電子マネー管理会社（Ｂ）側に携帯電話（Ｅ）の機種固有情報（Ｆ）と電子マネーＩＤ（Ｄ）を送信すると、電子マネー残高を管理するデータベース（Ｇ）には、機種固有情報（Ｆ）と、電子マネーＩＤ（Ｄ）と、電子マネー（Ｃ）の購入金額とが対応づけて登録される。この購入金額は残高の初期値であって、残高が０円になるまでデータベース（Ｇ）に登録されている。
ユーザ（Ａ）は、テレビ画面や新聞・雑誌などに商品販売サイト（Ｈ）のＱＲコード（Ｉ）が表示されていると、これを携帯電話（Ｅ）のカメラ機能で撮影し、商品販売サイト（Ｈ）にアクセスする。ユーザ（Ａ）がこの商品販売サイト（Ｈ）にて気に入った商品（Ｊ）の購入申込をすると、商品（Ｊ）を特定する情報と携帯電話（Ｅ）の機種固有情報（Ｆ）とが、商品販売サイト（Ｈ）に送信される。商品販売サイト（Ｈ）が電子マネー管理会社（Ｂ）と提携しているならば、この電子マネー管理会社（Ｂ）と関連する決済サイト（Ｋ）にアクセスして、商品（Ｊ）の取引金額と機種固有情報（Ｆ）とを送信する。電子マネー管理会社（Ｂ）は、残高を管理するデータベース（Ｇ）から機種固有情報（Ｆ）に対応する電子マネー（Ｃ）の残高を抽出して、この残高が商品（Ｊ）の代金以上であれば、商品販売サイト（Ｈ）にユーザ（Ａ）への販売が可能である旨を通知する。
【００１５】
ここで、ユーザ（Ａ）が最少限することは、電子マネー（Ｃ）をデータベース（Ｇ）に登録する時に用いた携帯電話（Ｅ）で商品販売サイト（Ｈ）にアクセスし、購入を希望する商品（Ｊ）を選択することだけである。代金の決済は、商品販売サイト（Ｈ）が取得した携帯電話（Ｅ）の機種固有情報（Ｆ）を決済サイト（Ｋ）に送信することにより、商品販売サイト（Ｈ）と決済サイト（Ｋ）間だけで行われるので、ユーザ（Ａ）は電子マネーＩＤ（Ｄ）を入力したりするには及ばない。
このように、本システムはインターネットを介した商品の購入から決済までを迅速簡便に行える。特に商品が楽曲などデジタルデータであれば、再生あるいはダウンロードをもって売買が完了するので、商品の発送などのために個人情報の入力をするには及ばない。
以下、このシステムの構成と処理の流れについて詳しく説明する。
なお、本システムのユーザは従来どおりの電子マネーＩＤを入力することによる決済も可能であるが、この決済の仕方は周知のことなので説明を省略し、専ら携帯電話１の機種固有情報をキーとする一連の取引について説明する。
【００１６】
《本システムの構成》
本システムでは、図１に示すようにユーザの携帯電話１と、決済サーバ２と、販売サーバ３、とが通信ネットワーク４を介して接続可能である。
決済サーバ２は、電子マネー管理会社等が電子マネーの発行や代金の決済を行うために使用するコンピュータであり、販売サーバ３は、商品販売等を業とし、商品販売サイトを運営管理する者が使用するコンピュータである。
通信ネットワーク４には、インターネット、移動体通信網のほかに専用回線網も含まれる。
図１では、ユーザの携帯電話１、決済サーバ２、販売サーバ３のいずれも、それぞれ１台しか記載されていないが、台数に制限はない。
また、決済サーバ２、販売サーバ３のいずれも、１台のコンピュータによって構成されるとは限らず、その機能を複数のコンピュータに分散し、これらの複数台が連携して実現するものであってもよい。
【００１７】
携帯電話１は、本システムを利用してオンライン上で商品を購入しようとするユーザが用いる端末装置であり、請求項１にいう「ユーザ携帯端末」の一例である。
携帯電話１は、図２に示すように、画像取得部５と、コード読取部６と、機種固有情報部７と、ブラウジング部８と、キーやボタンなどの入力操作部９と、ディスプレイなどの画面表示部１０と、通信インターフェース部１１と、制御部１２とを備える。
【００１８】
画像取得部５は、撮像素子としてＣＣＤを用いたカメラによって撮影されたＱＲコードを取得する。
コード読取部６は、画像取得部５によって取得されたデータコード画像を解析し、その中に有している情報を抽出する。
機種固有情報部７には、携帯電話１に固有の情報が格納される。固有の情報としては、携帯電話の製造番号、あるいは契約者番号などがある。なお、携帯電話番号も固有の情報ではあるが、個人情報保護の観点から本発明では電子マネーの残高管理には使用しない。
ブラウジング部８は、ブラウザあるいはウェブブラウザなどと呼ばれるプログラムに従い、コード読取部６によって抽出されたＵＲＬ情報に基づいてウェブサイトへのアクセスを行うとともに、アクセス先からの情報を受取ると、その情報を画面表示部１０に表示させる。
制御部１２は、所定の制御プログラムに従って、上記の各部の動作を制御するものである。
【００１９】
決済サーバ２は、図３に示すように、処理部１３と、記憶部１４と、通信インターフェース部１５を備える。適宜、キーボードなどの入力手段、画面やプリンタなどの出力手段も備える。
【００２０】
記憶部１４は、電子マネー残高記憶手段１６を備える。
この電子マネー残高記憶手段１６には、電子マネーの購入時に使用された携帯電話１の機種固有情報を、電子マネーの残高および電子マネーＩＤと対応付けて記憶する電子マネー残高データベース（以下、「電子マネーＤＢ」）が格納されている。
また、記憶部１４には、決済サーバ２を利用する販売者についての個人情報、各種プログラムやワークデータ等を格納するその他の記憶手段も備える。
【００２１】
処理部１３は、電子マネー登録手段１７と、決済可否応答手段１８と、電子マネー残高更新手段１９を備える。
電子マネー登録手段１７は、携帯電話１を介して電子マネーの購入申込を受けると、電子マネーＩＤを生成し、申込時に支払われた金額を当初の残高とした上で、この残高と電子マネーＩＤを携帯電話１の機種固有情報と対応づけて電子マネーＤＢ１６に登録する。
決済可否応答手段１８は、販売サーバ３から携帯電話１の機種固有情報と取引金額を受信すると、電子マネーＤＢ１６から該機種固有情報に対応する残高を取り出して、この残高が取引金額以上であれば決済可能、取引金額未満であれば決済不可と判断する手段（請求項１の「決済可否判定手段」に相当）と、判断結果を回答する手段からなる。
電子マネー残高更新手段１９は、決済可能の場合に、電子マネーＤＢ１６に記憶されている残高を、これから取引金額を減じた値に更新する。
処理部１３の各手段の機能は、記憶部１４に格納されたプログラムをＣＰＵ（図示せず）が読み込んで実行することにより実現されるが、その機能の一部をハードウェアで実現してもよい。
【００２２】
さて、本システムを利用して商品の購入をしようとする者は、あらかじめネットワーク型の電子マネーを入手していることが前提である。念のため、その電子マネーの入手方法について説明をしておく。
ユーザが、電子マネーを販売するコンビニなどに行き、電子マネーの購入を申し込む。
たとえば、３０００円分の電子マネーを入手したときは、３０００円の現金を支払い、商品の電子マネーカードやレシートに記載された電子マネーＩＤを含む情報をもとに、自分の携帯電話１を決済サーバ２と接続させ、機種固有情報と電子マネーＩＤを送信し、３０００円分の電子マネーを登録する。
なお、電子マネーＩＤは、文字列に限らず、ＱＲコード化して印刷されてもよい。
決済サーバ２の電子マネー登録手段１７は、コンビニ等において支払われた購入金額を当初の残高とした上で、この残高と電子マネーＩＤを携帯電話１の機種固有情報と対応づけて電子マネーＤＢ１６に登録する。
【００２３】
電子マネーＤＢ１６のデータ構造の例を図４に示す。
機種固有情報（１６ａ）と現在残高（１６ｃ）は必須のデータである。
機種固有情報から、この機種固有情報を有する携帯電話１の利用者の電子マネーの現在残高、および複数の電子マネーの合計残高がわかる。したがって、本システムのような商品の購入から決済までが、ユーザを煩わすことなくシームレスに行われることになる。
しかし、電子マネーＩＤ（１６ｂ）もあわせて登録してあるので、従来どおりの電子マネーＩＤを入力することによる決済も可能である。
その他の情報（１６ｄ）としては、購入日時、残高からの引き落しの履歴などを適宜記録する。
なお、本システムの電子マネーはプリペイドタイプを想定しているので、金額の補充（チャージ）は行わない。チャージの代りに別途電子マネーを購入することになる。
【００２４】
販売サーバ３は、図５に示すように、処理部２０と、記憶部２１と、通信インターフェース部２２を備える。適宜、キーボードなどの入力手段、画面やプリンタなどの出力手段も備える。
記憶部２１は、商品情報記憶手段２３を備える。この商品情報記憶手段２３は、販売商品の商品特定情報と価格とを対応付けて記憶する商品情報データベース（以下、「商品情報ＤＢ」）を格納する。
また、記憶部２１には、ユーザへの商品紹介や購入申込を受け付けるためのウェブページを格納したＨＴＭＬ等のファイル、提携している決済サーバ２に関する情報、ワークデータや各種プログラム等も格納するその他の記憶手段も備える。
【００２５】
処理部２０は、商品情報提供手段２４と、購入申込受付手段２５と、決済可否照会手段２６と、商品提供可否通知手段２７を備える。
商品情報提供手段２４は、携帯電話１からの閲覧要求に応じて、商品紹介ウェブページを送信する。
購入申込受付手段２５は、携帯電話１から購入希望の商品を特定する商品特定情報とともに、携帯電話１の機種固有情報を受信する。
決済可否照会手段２６は、商品情報ＤＢ２３から商品特定情報に対応する商品の価格を取り出し、この価格と機種固有情報を決済サーバ２に送信する。
商品提供可否通知手段２７は、決済サーバ２から決済可能と回答があった場合に、購入希望の商品を提供する旨を携帯電話１に通知し、決済不可と回答があった場合に提供できない旨を携帯電話１に通知する。
処理部２０の各手段の機能は、記憶部２１に格納されたプログラムをＣＰＵ（図示せず）が読み込んで実行することにより実現されるが、その機能の一部をハードウェアで実現してもよい。
【００２６】
《本システムの動作》 
次に、本システムの動作について図６の処理フローを参照しながら説明する。
雑誌の広告などに販売サーバ３が開設している商品販売サイトのＵＲＬをコード化したＱＲコードが印刷されているものとする。
携帯電話１の画像取得部５（カメラ）でこのＱＲコードを撮影する（ステップＳ１。以下、「ステップＳ＊」を「Ｓ＊」のように記載する。）と、コード読取部６がＱＲコードからＵＲＬを読み取って当該サイトにアクセスする（ステップＳ２）。その際、機種固有情報部７に記憶されているこの携帯電話１の機種固有情報も送信される。
【００２７】
販売サーバ３の商品情報提供手段２４はアクセスしてきた携帯電話１に商品紹介ページを送信する（ステップＳ３）と、携帯電話１のブラウジング部８によって画面表示部１０にこのページが表示される。入力操作部９を介して、図７に例示するようなページから気に入った商品を指定し（Ｓ４）、購入希望の商品を特定する情報を販売サーバ３に送信する（Ｓ５）。販売サーバ３の購入申込受付手段２５は、購入希望の商品を特定する情報を取得すると、商品情報ＤＢ２３から商品特定情報に対応する商品の取引金額、その他の情報（例えば、在庫の有無）を取り出す（Ｓ６）。
なお、ユーザが複数種類の商品を異なる個数分指定することもあるが、この場合は、商品情報ＤＢ２３を参照して商品種類毎の単価を抽出して合計金額を算出する。
【００２８】
販売サーバ３が複数の支払い方法を持っているならば、支払い方法を選択する画面を携帯電話１に送信する（Ｓ７）。図８に例示するような支払い方法選択ページが携帯電話１の画面表示部１０に表示されるので、ユーザは、入力操作部９を介してこのページから電子マネー払いを選択し（Ｓ８），販売サーバ３に送信する（Ｓ９）。もし、販売サーバ３が代金の決済を電子マネー払いに限定しているならば、ステップＳ７〜Ｓ８の処理は省略される。また、販売サーバ３が複数の決済サーバと提携していれば、更にその中から選択することになるが、図６のフロー及び図８の画面例では提携している決済サーバが一つの場合を示す。
【００２９】
以上で、ユーザによる購入申込のための手続きは終了した。後は、販売サーバ３と決済サーバ２との間で決済が終了すれば、販売サーバ３を管理する販売者側から商品が提供されることになる。
以下、電子マネーを利用した決済の処理フローを説明する。
【００３０】
販売サーバ３は、ユーザからの支払方法を受信すると、決済可否照会手段２６は取引金額と機種固有情報を決済サーバ２に送信する（Ｓ１０）。
決済サーバ２の決済可否応答手段１８は、電子マネーＤＢ１６から機種固有情報に対応する現在残高を参照し、商品代金を決済可能か、判定する（Ｓ１１）。
【００３１】
ここで商品代金が１５００円であるとする。
図４のレコード（ａ）から、機種固有情報が「ＭＢＬ１１１１」のユーザであれば、電子マネー残高が２８００円あるので、決済可能である。
機種固有情報が「ＭＢＬ３３３３」のユーザは、レコード（ｂ）を参照すると電子マネー残高が５０円で決済に不足するが、レコード（ｃ）と（ｄ）の同一人の電子マネー残高を合算すると１８００円なので決済可能である。
機種固有情報が「ＭＢＬ７７７７」のユーザは、レコード（ｅ）と（ｆ）に登録されている２種類の電子マネーを持つが、これらの残高を合算しても３７０円なので決済不可である。
【００３２】
決済可能であれば（Ｓ１２でｙｅｓ）、決済可否応答手段１８は販売サーバ３に対して販売可能である旨のメッセージを返す（Ｓ１３）。
ここで、決済サーバ２側の口座を開設してある金融機関に対して、この口座から販売サーバ側の該当する口座への資金移動を依頼してもよい。例えば、既存のインターネットバンキングの仕組みを利用すれば、口座間の資金移動が簡便にできる。
電子マネー残高の更新は、販売可能である旨を販売サーバ３に送信したとき、あるいは銀行口座間の振込みを依頼あるいは完了したとき等に行えばよい。電子マネー残高更新手段１９による更新が複数の電子マネーについて行う必要があるときは、予め定めた方法で更新すればよい。たとえば、電子マネーの購入日付順、残高の多寡順などの方法が考えられる。
【００３３】
決済可能であれば、販売サーバ３は、ユーザに希望の商品を提供する（Ｓ１４）。この商品が電子データであればオンラインでの提供ができるので、携帯電話１に対してこの電子データのダウンロード用のウェブサイトのＵＲＬを通知すればよい。もし、有体物であれば、郵便などのオフラインの手段による発送の手配をすることになる。
当事者の口座間の資金移動や商品の提供の仕方については、本発明にとって本質的でないので、詳細は省略する。
【００３４】
もし、残高が商品代金に満たないときは（Ｓ１２でｎｏ）、決済不可の旨のメッセージを販売サーバ３に送信する（Ｓ１５）。販売サーバ３の商品提供可否通知手段２７は携帯電話１に対して残高不足のため販売できない旨のメッセージを送信する（Ｓ１６）。
【００３５】
以上の説明からわかるとおり、ユーザの携帯電話の操作は以下の３種類である。即ち、（１）販売サイトへアクセスするためのＱＲコード読み取り〔Ｓ１〕、（２）希望商品の指定〔Ｓ４〕、（３）支払い方法の選択〔Ｓ８〕である。利便性において大変優れている。
【００３６】
電子マネーが１つだけであればともかく、複数の電子マネーの残高の合算によって決済しようとする場合は、識別情報を使用する電子マネーごとに入力しなくてはならない。したがって本システムのように、電子マネー残高記憶手段１６に機種固有情報が登録されている携帯電話を介して購入するならば識別情報を入力しなくてすむということは非常に便利なことである。しかも、本システムでは、同一人のすべての電子マネーを携帯電話の機種固有情報によって取り出せるので、複数の電子マネーを合算して支払いに充当することができる。この合算をシステムが自動的に行う点も本システムの利点のひとつである。電子マネーの使用が個別にしかできないならば、残金がわずかになった電子マネーは利用しづらく、使われないままになってしまうこともある。しかし、本システムでは自動的に合算されるので、電子マネーを０円になるまで使い切ることができる。本システムは従来どおりの電子マネーＩＤを入力することによる決済も可能なので、同一のユーザが残高の少ない電子マネーを多数所持することもありうる。このようなユーザにとって自動的な合算機能はきわめて便利である。
また、チャージはできないが、そのかわりに購入済みの電子マネー残高が少なくなってきたならば、新たに購入すればよい。
【００３７】
さらに、本システムは個人情報保護の観点からも好ましい。電子マネーの購入時に、ユーザの氏名住所はもちろんのこと携帯電話番号も入力しなくてよい。電子マネーの使用時にも、機種固有情報さえわかれば決済ができるので、誰がどこで何をいくらで購入したのか、といった個人情報を知られることはない。電子マネー残高を管理する決済サーバ２には機種固有情報を通知しなくてはならないが、この機種固有情報からユーザの個人情報を取得することは殆んどできない。また、機種固有情報さえわかれば、個人情報を入力しなくても安全確実に電子マネーの合算ができる。
【００３８】
以上、一の実施の形態をもとに本発明の説明をしてきたが、この実施の形態は例示にすぎず、さまざまな変形が考えられる。いくつの変形例を下記に記す。
【００３９】
上記の実施の形態では、決済サーバが電子マネーの発行と登録を行っていたが、電子マネー発行専用のサーバなどが新規発行及び登録を行ってもかまわない。本発明にとって、決済サーバが電子マネーの残高を管理しているデータベースにアクセスできることが重要であって、決済サーバが電子マネーの新規発行・登録まで行うことは必須ではない。
上記の実施の形態では、決済サーバと販売サーバとは別の運営主体によって管理されるものと想定しているが、これらは同一の運営主体によって管理される同一のコンピュータによって実現されてもかまわない。この場合も、購入申込と決済の間での電子マネーＩＤの入力を省略できるのでユーザにとって便利なことに変わりはない。
上記の実施の形態では、ユーザは電子マネーをコンビニなどで購入していたが、携帯電話から所定のサイトにアクセスして購入を申し込み、代金は携帯電話料金との合算払いや、クレジットカード払いでもよい。
上記の実施の形態では、販売サイトへのアクセスのためにＵＲＬをコード化したＱＲコードを読み込んでいたが、ＵＲＬをキー入力してもよいことは言うまでもない。
上記の実施の形態では、ＱＲコードを使用していたが、これに限らず、ＱＲコード以外の２次元バーコードでも１次元のバーコードでも、ＵＲＬや電子マネーＩＤを表わす文字列でもかまわない。
上記の実施の形態では、販売サイトのＵＲＬを現すＱＲコードは雑誌広告などに印刷されていたが、例えばテレビのエンディングにおいて画面に表示されるようなものでもよい。テレビの場合、番組内容と連動したり、スポンサーが開設するウェブサイトへ誘導したりすれば、より一層の販売・広告効果が見込まれる。
上記の実施の形態では、電子マネーＤＢ１６には機種固有情報と対応づけられた電子マネーのみを登録していたが（図４）、このデータベースには対応付け前の未使用の電子マネーや旧来の機種固有情報を利用しない販売サーバとの決済の結果、対応付け無しで残高の更新された電子マネーが登録されていてもかまわない。
【産業上の利用可能性】
【００４０】
インターネット上で商品を購入する際、電子マネーの識別情報を入力しなくても携帯電話の機種固有情報をキーとして残高を参照でき簡便に決済ができる。また、個々の電子マネーの残高を携帯電話の機種固有情報をキーとして合算できるので、きわめて使い勝手のよい決済システムとして、電子マネーのさらなる普及に役立つと期待される。
【符号の説明】
【００４１】
１  携帯電話
２  決済サーバ
３  販売サーバ
４  通信ネットワーク
１６  電子マネー残高記憶手段
１８  決済可否応答手段
１９  電子マネー残高更新手段
２３  商品情報記憶手段
２４  商品情報提供手段
２５  購入申込受付手段
２６  決済可否照会手段
２７  商品提供可否通知手段
【図１】
2013065360.tif 000003
【図２】
2013065360.tif 000004
【図３】
2013065360.tif 000005
【図４】
2013065360.tif 000006
【図５】
2013065360.tif 000007
【図６】
2013065360.tif 000008
【図７】
2013065360.tif 000009
【図８】
2013065360.tif 000010