(57)【要約】  【課題】  電子マネーの決済サーバに決済の代行を依頼することのできる販売サーバなどを提供すること。  【解決手段】  販売サーバ３は、販売サイトでチケットの販売を行っている。リーダライタ８を介して電子マネーカード９を顧客端末２に接続し、ネットワークからアクセス可能となっている。顧客は、顧客端末２から販売サイトにアクセスし、チケットの購入を申し込む。販売サーバ３は、電子マネーカード９からカードＩＤを取得する。販売サーバ３は、決済代金とカードＩＤを決済サーバ４に送信し、決済の代行を依頼する。顧客は、決済のための顧客端末２から決済サーバ４の決済サイトにアクセスする。決済サーバ４は、電子マネーカード９からカードＩＤを読み取って、販売サーバ３から受信した情報と照合し、決済金額を特定する。そして、減算命令を生成して電子マネーカード９に送信し、電子マネーカード９が記憶しているバリューを決済金額分だけ減算させる。  【選択図】  図１
2005071081.tif 000002
【特許請求の範囲】
【請求項１】
貨幣価値を電子情報として記憶する貨幣価値記憶手段と減算命令を受信して実行し、前記記憶した貨幣価値を減算する減算手段とを具備した貨幣端末と、前記貨幣端末に記憶した貨幣価値を用いた決済により商品の販売を行う販売サーバと、前記販売サーバからの依頼を受けて前記貨幣端末に減算命令を送信する決済実行サーバと、がネットワークで接続可能に配設された商品販売システムで使用される販売サーバであって、
前記貨幣端末に固有の端末ＩＤと、決済対象である商品を特定する商品特定情報と、を受信する決済情報受信手段と、
前記決済実行サーバに、前記受信した端末ＩＤと、前記受信した商品特定情報で特定される商品の代金情報と、を送信する決済情報送信手段と、
前記送信した端末ＩＤで特定される貨幣端末が記憶している貨幣価値が、前記送信した代金情報で特定される金額分だけ減算されたことを示す決済完了通知を、前記決済実行サーバから受信する決済完了通知受信手段と、
を具備したことを特徴とする販売サーバ。
【請求項２】
複数存在する決済処理サーバのうち、決済処理を依頼する決済実行サーバを指定する指定手段を備え、
前記決済情報送信手段は、前記指定した決済実行サーバに前記端末ＩＤと前記決済金額を送信することを特徴とする請求項１に記載の販売サーバ。
【請求項３】
決済の対象となる商品を選択可能に提示する提示手段を具備し、
前記決済情報受信手段は、前記提示した商品からユーザが選択した商品を特定する商品特定情報を受信することを特徴とする請求項１、又は請求項２に記載の販売サーバ。
【請求項４】
前記決済完了通知受信手段で決済完了通知を受信した場合に、決済の対象となった商品を提供する提供手段を具備したことを特徴とする請求項１、請求項２、又は請求項３に記載の販売サーバ。
【請求項５】
貨幣価値を電子情報として記憶する貨幣価値記憶手段と減算命令を受信して実行し、前記記憶した貨幣価値を減算する減算手段とを具備した貨幣端末と、前記貨幣端末に記憶した貨幣価値を用いた決済により商品の販売を行う販売サーバと、前記販売サーバからの依頼を受けて前記貨幣端末に減算命令を送信する決済実行サーバと、がネットワークで接続可能に配設された商品販売システムで使用される販売サーバが行う販売方法であって、
前記販売サーバは、決済情報受信手段と、決済情報送信手段と、決済完了通知受信手段と、を備えたコンピュータから構成され、
前記決済情報受信手段で、前記貨幣端末に固有の端末ＩＤと、決済対象である商品を特定する商品特定情報と、を受信する決済情報受信ステップと、
前記決済実行サーバに、前記決済情報送信手段で、前記受信した端末ＩＤと、前記受信した商品特定情報で特定される商品の代金情報と、を送信する決済情報送信ステップと、
前記送信した端末ＩＤで特定される貨幣端末が記憶している貨幣価値が、前記送信した代金情報で特定される金額分だけ減算されたことを示す決済完了通知を、前記決済完了通知受信手段で、前記決済実行サーバから受信する決済完了通知受信ステップと、
から構成されたことを特徴とする販売方法。
【請求項６】
貨幣価値を電子情報として記憶する貨幣価値記憶手段と減算命令を受信して実行し、前記記憶した貨幣価値を減算する減算手段とを具備した貨幣端末と、前記貨幣端末に記憶した貨幣価値を用いた決済により商品の販売を行う販売サーバと、前記販売サーバからの依頼を受けて前記貨幣端末に減算命令を送信する決済実行サーバと、がネットワークで接続可能に配設された商品販売システムで使用される販売サーバが実行する販売プログラムであって、
前記貨幣端末に固有の端末ＩＤと、決済対象である商品を特定する商品特定情報と、を受信する決済情報受信機能と、
前記決済実行サーバに、前記受信した端末ＩＤと、前記受信した商品特定情報で特定される商品の代金情報と、を送信する決済情報送信機能と、
前記送信した端末ＩＤで特定される貨幣端末が記憶している貨幣価値が、前記送信した代金情報で特定される金額分だけ減算されたことを示す決済完了通知を、前記決済実行サーバから受信する決済完了通知受信機能と、
をコンピュータで実現する販売プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、販売サーバなどに関し、例えば、電子マネーカードを用いた決済システムで用いるものに関する。
【背景技術】
【０００２】
近年の電子マネーの普及に伴い、電子マネーを用いた商取引が盛んに行われるようになってきた。
電子マネーによる商取引は、バリューと呼ばれる金銭と同等の交換価値を持つ電子情報を操作して価値の移動を行うことにより行われる。
【０００３】
一般に、バリューは、ＩＣチップを内蔵した電子マネーカードに書き込まれており、このバリューの表す金額はリーダライタと呼ばれる装置を介して書き換えることができる。
このようなバリューの書き換えによる商品・サービスの購入は、バリューによる商取引を行う契約を結んでいる加盟店で行うことができる。加盟店は、店頭にリーダライタを備えており、ユーザの電子マネーカードに記憶されているバリューを代金分だけ減算して決済する。
【０００４】
また、ユーザは、加盟店に金銭を支払い、その金額分のバリューを、加盟店の店頭に設置したリーダライタで電子マネーカードに書き込んでもらうこともできる。電子マネーカードにバリューを書き込む処理をチャージと呼ぶ。
あるいは、銀行口座からの引き落としや、クレジットカードによる決済を用いて、ネットワーク上に設置されたサーバ装置から行うことも可能である。
この場合、ユーザは、リーダライタを備えた端末に電子マネーカードを設置し、チャージ用のサイトにアクセスしてチャージを行う。
【０００５】
電子マネーカードを用いた決済は、加盟店が運営する実際の店頭のほかに、加盟店がインターネット上に開設した仮想店舗においても行うことができる。
この場合、ユーザは、パーソナルコンピュータなどの端末にリーダライタを接続してこれに電子マネーカードをセットし、決済は、サーバ装置が電子マネーカードからバリューを減算することにより行われる。
【０００６】
このような電子マネーを用いた販売システムは、バリューに関する情報を管理する電子マネー管理センタや、電子マネーによる決済を行う加盟店などをネットワーク接続することにより構成されている。
そして、新たに加盟店として加入を希望する事業者は、既に導入しているコンピュータシステムを販売システムに適合させてこれに接続するか、あるいは、販売システムに適合するコンピュータシステムを新たに導入することになる。
【０００７】
なお、電子マネーカードに記憶されているバリューを用いて決済を行う発明としては、例えば、次のサービス提供方法がある。
【特許文献１】特開２０００−２５０９９４公報
【０００８】
この発明は、ＩＣカードに予め記憶したバリューを用いてサービスの対価を支払うものである。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかし、加盟店として加入を希望する事業者のコンピュータシステムを、例えば、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）の違いなどにより、販売システムに組み込むことが困難な場合がある。その場合、事業者は、既に構築したコンピュータシステムを販売システムに適合するように再構築しなくてはならず、多額の投資が必要となる。
【００１０】
また、チケット業者によるチケットのインターネット販売などにおいては、決済がチケット販売開始時などの一定時間に集中することがあり、アクセス集中によるシステムダウンが発生する可能性があった。これを回避するためにはアクセス集中に耐えるシステムを構築する必要があり、設備投資の増大が問題となっていた。
更に、一般に、電子マネーによる決済を行うためには、電子マネーシステムの加盟店となって、電子マネー管理サーバと接続するための決済システムを導入する必要があり、設備投資が増大するという問題もある。
【００１１】
そこで、本発明の目的は、電子マネーの決済サーバに決済の代行を依頼することのできる販売サーバなどを提供することである。
【課題を解決するための手段】
【００１２】
本発明は、前記目的を達成するために、請求項１に記載の発明では、貨幣価値を電子情報として記憶する貨幣価値記憶手段と減算命令を受信して実行し、前記記憶した貨幣価値を減算する減算手段とを具備した貨幣端末と、前記貨幣端末に記憶した貨幣価値を用いた決済により商品の販売を行う販売サーバと、前記販売サーバからの依頼を受けて前記貨幣端末に減算命令を送信する決済実行サーバと、がネットワークで接続可能に配設された商品販売システムで使用される販売サーバであって、前記貨幣端末に固有の端末ＩＤと、決済対象である商品を特定する商品特定情報と、を受信する決済情報受信手段と、前記決済実行サーバに、前記受信した端末ＩＤと、前記受信した商品特定情報で特定される商品の代金情報と、を送信する決済情報送信手段と、前記送信した端末ＩＤで特定される貨幣端末が記憶している貨幣価値が、前記送信した代金情報で特定される金額分だけ減算されたことを示す決済完了通知を、前記決済実行サーバから受信する決済完了通知受信手段と、を具備したことを特徴とする販売サーバを提供する。
請求項２に記載の発明では、複数存在する決済処理サーバの内、決済処理を依頼する決済実行サーバを指定する指定手段を備え、前記決済情報送信手段は、前記指定した決済実行サーバに前記端末ＩＤと前記決済金額を送信することを特徴とする請求項１に記載の販売サーバを提供する。
請求項３に記載の発明では、決済の対象となる商品を選択可能に提示する提示手段を具備し、前記決済情報受信手段は、前記提示した商品からユーザが選択した商品を特定する商品特定情報を受信することを特徴とする請求項１、又は請求項２に記載の販売サーバを提供する。
請求項４に記載の発明では、前記決済完了通知受信手段で決済完了通知を受信した場合に、決済の対象となった商品を提供する提供手段を具備したことを特徴とする請求項１、請求項２、又は請求項３に記載の販売サーバを提供する。
請求項５に記載の発明では、貨幣価値を電子情報として記憶する貨幣価値記憶手段と減算命令を受信して実行し、前記記憶した貨幣価値を減算する減算手段とを具備した貨幣端末と、前記貨幣端末に記憶した貨幣価値を用いた決済により商品の販売を行う販売サーバと、前記販売サーバからの依頼を受けて前記貨幣端末に減算命令を送信する決済実行サーバと、がネットワークで接続可能に配設された商品販売システムで使用される販売サーバが行う販売方法であって、前記販売サーバは、決済情報受信手段と、決済情報送信手段と、決済完了通知受信手段と、を備えたコンピュータから構成され、前記決済情報受信手段で、前記貨幣端末に固有の端末ＩＤと、決済対象である商品を特定する商品特定情報と、を受信する決済情報受信ステップと、前記決済実行サーバに、前記決済情報送信手段で、前記受信した端末ＩＤと、前記受信した商品特定情報で特定される商品の代金情報と、を送信する決済情報送信ステップと、前記送信した端末ＩＤで特定される貨幣端末が記憶している貨幣価値が、前記送信した代金情報で特定される金額分だけ減算されたことを示す決済完了通知を、前記決済完了通知受信手段で、前記決済実行サーバから受信する決済完了通知受信ステップと、から構成されたことを特徴とする販売方法を提供する。
請求項６に記載の発明では、貨幣価値を電子情報として記憶する貨幣価値記憶手段と減算命令を受信して実行し、前記記憶した貨幣価値を減算する減算手段とを具備した貨幣端末と、前記貨幣端末に記憶した貨幣価値を用いた決済により商品の販売を行う販売サーバと、前記販売サーバからの依頼を受けて前記貨幣端末に減算命令を送信する決済実行サーバと、がネットワークで接続可能に配設された商品販売システムで使用される販売サーバが実行する販売プログラムであって、前記貨幣端末に固有の端末ＩＤと、決済対象である商品を特定する商品特定情報と、を受信する決済情報受信機能と、前記決済実行サーバに、前記受信した端末ＩＤと、前記受信した商品特定情報で特定される商品の代金情報と、を送信する決済情報送信機能と、前記送信した端末ＩＤで特定される貨幣端末が記憶している貨幣価値が、前記送信した代金情報で特定される金額分だけ減算されたことを示す決済完了通知を、前記決済実行サーバから受信する決済完了通知受信機能と、をコンピュータで実現する販売プログラムを提供する。
【発明の効果】
【００１３】
事業者の既存のコンピュータシステムの仕様によらず、電子マネーカードによる決済を可能とすることができる。
【発明を実施するための最良の形態】
【００１４】
（実施の形態の概要）
販売システム１（図１）は、ネットワークを介して公演チケット（以下、チケット）を販売するシステムである。
販売システム１では、販売サーバ３は、チケットを顧客に販売し、その代金決済の代行を決済サーバ４に依頼する。
【００１５】
顧客は、顧客端末２から販売サーバ３の販売サイトにアクセスし、チケットの購入を申し込む。この際に、顧客は、電子マネーカード９を顧客端末２にリーダライタ８を介して接続し、電子マネーカード９がネットワークを介してアクセス可能な状態としておく。
販売サーバ３は、電子マネーカード９にアクセスしてカードＩＤを受信し、顧客が申し込んだチケットに関する情報と共に記憶する。
後ほど、この電子マネーカード９のバリューにより、チケット代金の決済が行われる。
【００１６】
販売サーバ３は、複数台存在する決済サーバ４、４、…のうち、決済の代行を依頼する１台を選択する。そして、この選択した決済サーバ４にチケット代金とカードＩＤなどを含む決済情報を送信し、決済サーバ４にチケット代金の決済の代行を依頼する。
顧客は、チケットの購入を申し込んだ後、顧客端末２と販売サーバ３との接続を切断し、顧客端末２を販売サーバ３が選択した決済サーバ４の決済サイトに接続する。その際に、顧客は電子マネーカード９をリーダライタ８にセットし、決済サーバ４から電子マネーカード９にアクセスできるようにしておく。
【００１７】
決済サーバ４は、電子マネーカード９のカードＩＤを読み取って、販売サーバ３から受信したカードＩＤと照合し、決済情報を特定する。
そして、決済代金分のバリューを減算する減算命令を生成して電子マネーカード９に送信する。
電子マネーカード９は、この減算命令を実行し、記憶しているバリューから代金分のバリューを減算する。
決済サーバ４は、決済が完了した後、決済完了通知を販売サーバ３に送信する。
【００１８】
販売サーバ３は、決済サーバ４から決済完了通知を受信して、決済が完了したことを確認し、申込情報に決済済みであること記録する。
以後、電子マネーカード９はチケットとして使用することができ、顧客は公演会場で電子マネーカード９を提示する。
公演会場では、電子マネーカード９からカードＩＤを読み取り、そのカードＩＤが決済が完了した電子マネーカード９のカードＩＤであるか否かを確認する。そして、確認できた場合は、顧客の入場を認める。
【００１９】
電子マネー管理サーバ５は、決済サーバ４が決済した代金から手数料を引いた金額を販売サーバ３を運営する販売者の売り上げとし、また、手数料を決済サーバ４を運営する加盟店の売り上げとして、決済したバリューを精算する。
電子マネー管理センタは、精算結果に基づき、バリュー原資を配分する。
【００２０】
販売システム１では、販売サーバ３はチケット代金の決済を決済サーバ４に依頼するため、販売サーバ３自体は、電子マネーカード９での決済機能を備える必要がなく、電子マネーカード９を用いた決済に伴う新たな設備の導入を行う必要がない。
また、チケット発売開始時のように、商品購入の申込が一時に殺到した場合でも申込だけ受け付けておき、その決済を後ほど決済サーバ４で分散して行うことができる。
【００２１】
（実施の形態の詳細）
図１は、本実施の形態の販売システム１の構成を概念的に示した図である。
販売システム１では、バリューを記憶した電子マネーカード９、電子マネーカード９を顧客端末２に接続するリーダライタ８、リーダライタ８を介して電子マネーカード９をネットワークに接続する顧客端末２、商品の販売を行う販売サーバ３、販売した商品代金の決済を電子マネーカード９で行う決済サーバ４、４、４、…（以下、決済サーバ４）、商業活動に伴うバリューの移動に関する情報を管理する電子マネー管理サーバ５が、インターネットなどのネットワークを介して接続可能に配設されている。
【００２２】
顧客端末２は、例えば、パーソナルコンピュータなどで構成されたネットワーク接続可能な端末装置である。
顧客端末２は、ブラウザを備えており、ブラウザ上でＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒｓ）を指定することにより、顧客端末２を販売サーバ３の販売サイト、決済サーバ４の決済サイトに接続することができる。
【００２３】
顧客端末２は、キーボード、マウスなどの入力装置や、ディスプレイなどの表示装置を備えており、販売サーバ３や決済サーバ４が提供する各種画面を表示するほか、ユーザが入力した情報を、販売サーバ３や決済サーバ４に送信することができる。
これにより、販売サイトが提供する販売サービス、決済サイトが提供する決済サービスをネットワーク上で利用することができる。
【００２４】
リーダライタ８は、電子マネーカード９にアクセスするための装置であり、顧客端末２に配設してある。
リーダライタ８には、電子マネーカード９と短距離の無線通信を行うためのアンテナが内蔵されており、このアンテナから電波を放射して電子マネーカード９に駆動電力を供給すると共に、電子マネーカード９と通信を行うことができる。
【００２５】
電子マネーカード９は、通信用のアンテナと演算機能及び記憶機能を備えたＩＣチップが内蔵された携帯可能なプラスチックカードである。
電子マネーカード９は、リーダライタ８と近距離の無線通信が行えるようになっており、使用時には、リーダライタ８上に置いたり、あるいはリーダライタ８にかざすなどして、顧客端末２に接続する。
【００２６】
ＩＣチップは、バリュー処理を行うためのバリュー処理プログラムを記憶しており、リーダライタ８から送信された電力により駆動し、これを実行する。
ＩＣチップは、バリュー処理プログラムに従って動作し、加算命令や減算命令などの入力を受け付けて実行し、各種のバリュー処理（チャージ、決済、残高照会など）を行うことができる。
【００２７】
また、このＩＣチップは、固有のＩＤ情報を記憶しており、このＩＤ情報により、電子マネーカード９を特定できるようになっている。
より詳細に述べると、電子マネーカード９は、ＩＣチップに固有のＩＤ情報と、電子マネー管理サーバ５がバリュー情報の管理を行うためのＩＤ情報など複数のＩＤ情報を備えている。
【００２８】
何れのＩＤ情報を用いても販売システム１を構成することができるが、本実施の形態では、バリュー情報管理用のＩＤ情報を電子マネーカード９を特定するためのカードＩＤとして使用することにする。
【００２９】
販売サーバ３は、ネットワーク上で商品販売用の販売サイトを開設しており、この販売サイトを介して商品の販売を行うＷｅｂサーバ装置である。
本実施の形態では、販売サイトでチケットを販売する場合について説明する。
【００３０】
なお、販売対象は、これに限定するものではなく、例えば、コンテンツをダウンロード販売したり、あるいは、ソフトウェアを時間貸しするＡＳＰ業務を行ったり、あるいは、販売した商品を宅配する通信販売など、ネットワーク上で売買取引を行えるものであれば適用することができる。
【００３１】
販売サイトは、所定のＵＲＬで特定可能となっており、顧客端末２からこのＵＲＬを入力することによりアクセス可能となっている。
販売サイトでは、公演の一覧が表示され、ユーザが購入を希望するチケットを選択できるようになっている。
【００３２】
また、販売サイトでは、顧客が選択したチケットを購入するための購入画面が用意されており、顧客は、この画面から、希望する日時のチケット、枚数などの注文内容を入力することができる。更に、氏名、住所、電子メールアドレスなどの連絡先を入力するように構成することもできる。
販売サーバ３は、購入画面で顧客が入力した情報を申込情報として記憶する。
【００３３】
更に、販売サーバ３は、ネットワーク、電子マネーカード９にカードＩＤ出力命令を送信することができるようになっている。
この命令は、ネットワーク、顧客端末２、リーダライタ８を介して電子マネーカード９に入力される。電子マネーカード９は、この命令を実行してカードＩＤを出力し、出力されたカードＩＤは、販売サーバ３に送信される。
【００３４】
販売サーバ３は、電子マネーカード９から送信されてきたカードＩＤを受信し、これも申込情報として記憶する。
このカードＩＤにより、顧客が申し込んだチケットの代金を決済するための電子マネーカード９を特定することができる。
以上のようにして、販売サーバ３は、顧客からチケットの申込を受け付け、決済が完了した時点でチケットの所有権を顧客に渡す。
【００３５】
このように、電子マネーカード９は貨幣価値を記憶した貨幣端末を構成しており、カードＩＤは、端末ＩＤを構成している。
また、販売サーバ３は、チケットの販売に必要な情報（チケット（商品）を特定する商品特定情報は顧客端末２から、カードＩＤを電子マネーカード９から）を受信する決済情報受信手段を備えている。
更に、販売サイトで販売するチケットを選択可能に表示する提示手段を備えている。
【００３６】
販売サーバ３は、電子マネーカード９のバリューを減算して決済する機能を備えていないため、顧客からチケットの申込を受け付けた後、既に電子マネーカード９のバリュー減算機能を備えた決済サーバ４に決済の代行を依頼する。
この依頼は、決済情報を決済サーバ４に送信することにより行われる。決済情報は、チケット受付番号、チケット代金、カードＩＤなど、決済の対象と決済内容を特定するのに必要な情報から構成されている。
このように、販売サーバ３は、決済情報を送信する決済情報送信手段を備えている。
【００３７】
販売サーバ３は、決済の代行を依頼する際に、複数存在する決済サーバ４から決済を依頼する決済サーバ４を所定の手順で選択し、決済処理の実行負荷を分散させる。
決済サーバ４を選択する手順としては、例えば、チケットの申込を受け付けるごとに、決済サーバ４を順に選択したり、あるいは、乱数を発生させて、決済サーバ４をランダムに選択したり、更には、決済サーバ４の決済処理の実行負荷を監視し、実行負荷の小さい決済サーバ４を選択するなどの方法がある。
このように、販売サーバ３は、決済サーバ４を指定する指定手段を備えている。
【００３８】
チケットは、販売と同時に注文が殺到する場合があり、短時間に数万人分程度のチケットを決済処理する必要が生じることもある。
一方、決済サーバ４の処理能力は一度に１００人分程度であり、そのため、決済処理の負荷を分散することにより、決済処理を滞りなく行うことができる。
なお、チケットの申込の受付に関しては、決済処理を行わずにとりあえず受け付け処理だけ行うため、一度に多数の顧客からの申込を処理することができる。
【００３９】
販売サーバ３は、決済サーバ４から決済完了通知を受信し、決済サーバ４が電子マネーカード９での決済を行ったことを確認することができる。
決済完了通知には、決済の対象となった電子マネーカード９のカードＩＤ、決済案件を特定するための受付番号、決済を行った日時など、販売サーバ３が、決済が完了した案件を特定するのに必要な情報から構成されている。
【００４０】
販売サーバ３は、決済を確認した後、顧客が申し込んだチケットの所有権を顧客に設定する。これは後述するように、チケットの販売ステータスを「未決済」から「既決済」に変更することにより行う。販
このように、販売サーバ３は、決済完了通知受信手段と、チケットの所有権を顧客に移転する提供手段を備えている。
【００４１】
後日、顧客は電子マネーカード９をチケットとして公演会場に持参する。公演会場の入口では係員がカードＩＤをリーダライタで読み取って、このカードＩＤが決済されたものか否かを確認し、決済されている場合は顧客の入場を認める。
【００４２】
本実施の形態では、決済サーバ４を複数台用いたが、これに限定するものではなく、１台の決済サーバ４を用意し、これに決済の代行を依頼するように構成することもできる。
この場合も、販売サーバ３は、電子マネーカード９で決済する機能を備える必要がないため、販売サーバ３の設置コストが低減される。
【００４３】
決済サーバ４は、電子マネーカード９で決済を行う機能を備えたサーバ装置である。
決済サーバ４は、ネットワーク上で、所定のＵＲＬで特定される決済サイトを開設している。
この決済サイトは、販売サイトで申し込んだチケットの代金を決済を行うためのサイトであり、顧客は、販売サイトでチケットを申し込んだ後、決済サイトにアクセスして、チケット代金の決済を行う。
【００４４】
決済サーバ４は、決済サイトにアクセスしてきた顧客端末２にセットされた電子マネーカード９からカードＩＤを読み取る。
このカードＩＤをキーとして、販売サーバ３から受信したカードＩＤを検索し、この顧客の決済情報を特定する。
【００４５】
決済サーバ４は、顧客に決済内容を確認した後、減算命令を生成し、ネットワーク、顧客端末２、及びリーダライタ８を経由して電子マネーカード９に送信する。
この減算命令には、チケット代金がパラメータとして付属しており、電子マネーカード９は、自身が記憶しているバリューの金額からチケット代金分を減算した後、減算が完了したことを示す減算完了通知を決済サーバ４に送信する。
【００４６】
決済サーバ４は、電子マネーカード９から減算完了通知を受信することにより、決済が完了したことを確認し、決済が完了したことを通知するための決済完了通知を販売サーバ３に送信する。
【００４７】
決済サーバ４は、販売サーバ３の決済処理を支援する目的で新たに設置することもできるが、本実施の形態では、既に加盟店が事業で使用している決済サーバ４を利用することにした。
即ち、決済サーバ４は、加盟店が扱う商品の販売も行っており、その決済を行うため、電子マネーカード９での決済機能を備えている。そして、販売サーバ３は、この決済機能を借用するのである。
【００４８】
販売サーバ３は、決済サーバ４の決済機能を借用することにより新たに決済機能を備える必要がなく、また、決済サーバ４の事業者も、特に設備投資することなく決済業務代行に伴う手数料収入を得ることができる。
販売サーバ３と決済サーバ４の間で送受信する情報（決済情報と決済完了通知など）は、通常のサーバ間の通信で行えるもであるので、特に新規の通信設備を導入する必要もない。
【００４９】
電子マネー管理サーバ５は、商取引に伴うバリュー移動に関する情報を管理するサーバ装置である。
バリューは、電子マネー管理サーバ５において貨幣価値と対応させられている。そして、この対応関係により、バリューの移動による価値の移動と、通貨の移動による価値の移動を対応付けている。
【００５０】
電子マネーカード９に記憶するバリューは、イシュアと呼ばれる事業者が発行する。
イシュアは、バリューを発行する際に、顧客から発行するバリュー金額分の料金を徴収する。この徴収した料金（以下、バリュー原資）はプール（蓄積）され、顧客のバリュー使用に応じて使用先の加盟店に配分される。
電子マネー管理サーバ５は、このようなバリューの発行や移動に関する情報を加盟店などから収集して整理管理する。
【００５１】
電子マネー管理サーバ５は、このような決済したバリューとバリュー原資との対応付けを行うほか、決済サーバ４が販売サーバ３から依頼を受けて代行した決済に関する精算処理も行う。
この精算処理は、決済サーバ４が販売サーバ３からの依頼を受けて代行した決済金額のうち、代行手数料を決済サーバ４を運営する加盟店の売り上げとし、決済金額から代行手数料を引いた金額を販売サーバ３を運営する販売店の売り上げとすることにより行われる。
【００５２】
以上のように、構成された販売システム１が行う、チケット販売から決済までの情報処理手順を図に示した番号に対応させて説明する。
（１）まず、顧客は、顧客端末２から販売サーバ３の販売サイトにアクセスし、購入するチケットを選択する。
そして、チケットを特定する情報とカードＩＤを販売サーバ３に送信してチケットを申し込む。
（２）販売サーバ３は、これらの申込情報を受信して記憶し、チケットの申込を受け付ける。そして、決済の代行を依頼する決済サーバ４を選択し、顧客端末２に対して決済サーバ４の決済サイトへの接続を促す。
【００５３】
（３）販売サーバ３は、カードＩＤ、決済金額など、決済に必要な決済情報を生成し、決済の代行を依頼した決済サーバ４に送信する。
（４）決済サーバ４は、販売サーバ３から送信されてきた決済情報を受信して記憶し、顧客端末２からのアクセスを待つ。そして、顧客端末２からアクセスがあった場合、電子マネーカード９のカードＩＤを取得して、決済情報に含まれるカードＩＤと照合し、決済情報を特定する。そして、決済金額分のバリューを減算する減算命令を生成し、電子マネーカード９に送信する。電子マネーカード９は、この減算命令を実行し、チケット代金分のバリューを減算する。
【００５４】
（５）電子マネーカード９での減算処理が終了すると、決済サーバ４は決済完了通知を販売サーバ３に送信し、販売サーバ３から依頼された決済処理が完了したことを通知する。
（６）販売サーバ３は、決済サーバ４から完了通知を受信し、顧客から申し込まれたチケットを販売済みのチケットとして登録する。
【００５５】
（７）電子マネー管理サーバ５は、決済サーバ４から、販売サーバ３からの依頼により代行した決済金額を受信する。そして、この決済金額のうち代行手数料を決済サーバ４を運営する加盟店の売り上げとし、イシュアに蓄積されているバリュー原資をこの加盟店に配分して加盟店に対する資金決済を行う。
（８）電子マネー管理サーバ５は、決済サーバ４が代行した決済金額から代行手数料を減算した金額を販売サーバ３を運営する販売店の売り上げとし、イシュアに蓄積されているバリュー原資をこの販売店に配分して販売店に対する資金決済を行う。
【００５６】
以上の手順の（４）で、顧客端末２は、接続先を販売サーバ３から決済サーバ４に切り替えるが、これは、顧客に接続先の決済サイトのＵＲＬを通知し、顧客に手動で切り替えてもらっても良いし、あるいは、販売サイトから決済サイトへリンクを張って、販売サイトから決済サイトへ遷移したり、あるいは他の方法で切り替えるように構成することができる。
【００５７】
次に、電子マネーカード９の機能的な構成について、図２の機能ブロック図を用いて説明する。
電子マネーカード９は、アンテナ１４、通信制御部１８、情報処理部１５、バリュー記憶部１６、カードＩＤ記憶部１７などの機能的な構成要素を備えている。
【００５８】
アンテナ１４は、リーダライタ８に内蔵されたアンテナと電波の送受信を行う。アンテナ１４は、リーダライタ８から送信されてきた電波を受信して、各構成要素を動作させるのに要する電力を発電するほか、無線通信を行い、各種の情報の送受信を行う。
【００５９】
通信制御部１８は、リーダライタ８との通信を制御する機能部であり、情報処理部１５が出力した信号をアンテナ１４を励起して電波として放射させたり、あるいは、アンテナ１４が受信した電波から電気信号を取り出して情報処理部１５に入力したりする。
【００６０】
情報処理部１５は、通信制御部１８から命令の入力を受け付けてこれを実行し、実行結果を通信制御部１８に出力する。
情報処理部１５が実行する命令としては、例えば加算命令、減算命令、カードＩＤ出力命令などがある。
【００６１】
加算命令は、バリュー記憶部１６に記憶されているバリューを加算する命令であって、チャージを行う際に入力される。
減算命令は、バリュー記憶部１６に記憶されているバリューを減算する命令であり、決済を行う際に入力される。
これら加減算命令には、加減算する金額、チャージを行う電子マネー端末の端末ＩＤ、チャージを行う日時、このバリューを発行しているイシュアを特定するイシュア情報、その他の情報がパラメータとして付属している。
【００６２】
カードＩＤ記憶部１７は、電子マネーカード９のカードＩＤを記憶する機能部である。
情報処理部１５は、通信制御部１８からカードＩＤ出力命令を受信すると、カードＩＤ記憶部１７からカードＩＤを読み出し、通信制御部１８に出力する。
バリュー記憶部１６は、バリューに関する情報を記憶する機能部であり、バリューの現在残高、過去のチャージ・決済に関するログデータなどを記憶している。ログデータの内容としては、例えば、チャージ、又は決済した金額、日付、電子マネー端末のＩＤ情報などがある。
【００６３】
図３は、電子マネーカード９のハードウェア的な構成の一例を示した図である。
電子マネーカード９は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２１、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２２、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  ａｎｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）２３、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２４、インターフェース２５などがバスラインを介して接続されて構成されている。これらの構成要素は、ＩＣチップ上に形成されている。
【００６４】
ＣＰＵ２１は、所定のプログラムに従って情報処理を行ったり、他の構成要素の動作を制御したりする。
ＲＯＭ２２は、読み出し専用の記憶装置であり、電子マネーカード９を動作させるための基本的なプログラムやデータが記憶されている。
このようなプログラムとしては、例えば、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）や、リーダライタ８との通信を制御する通信制御プログラムなどがある。
【００６５】
ＥＥＰＲＯＭ２３は、読み出し、及び書き込み可能な記憶装置であり、バリュー処理プログラム、バリューの現在残高、バリューに関するログデータ、カードＩＤなどが記憶されている。
ＥＥＰＲＯＭ２３は、不揮発性メモリであり、電力が供給されなくても記憶を保持することができる。
バリュー処理プログラムがＣＰＵ２１により実行されると図２に示した機能的な構成要素がソフトウェア的に実現される。
【００６６】
ＲＡＭ２４は、ＣＰＵ２１が情報処理を行う際のワーキングエリアを提供する読み出し、及び書き込み可能な記憶装置である。
ＲＡＭ２４は揮発性メモリであり、電力の供給が停止されると記憶している内容が消去される。
インターフェース２５は、リーダライタ８との通信の仲介を行う。インターフェース２５は、図示しない通信用のアンテナを備えている。
【００６７】
図４（ａ）は、販売サーバ３の機能的な構成の一例を示した機能ブロック図である。
販売サーバ３は、通信制御部３１、販売処理部３２、販売データベース３３、商品データベース３４、…などから構成されている。
通信制御部３１は、販売サーバ３をネットワークに接続する機能部であり、販売サーバ３は、通信制御部３１を介して電子マネーカード９、決済サーバ４、電子マネー管理サーバ５に接続する。
【００６８】
販売処理部３２は、チケットの販売に関する情報処理を行う機能部である。
販売処理部３２は、販売データベース３３や商品データベース３４を用いて、顧客端末２で購入画面を表示するための購入画面データを生成したり、顧客からのチケットの申込を受け付けたり、更に、決済サーバ４に決済の代行を依頼したりなどする。
【００６９】
ここで、図５を用いて販売データベース３３と商品データベース３４の構成について説明する。
図５（ａ）は、販売データベース３３の論理的な構成の一例を示した図である。
販売データベース３３は、「受付番号」、「カードＩＤ」、「決済金額」、「チケット情報」、「決済ステータス」、…などの項目から構成されている。
これらの項目は、申込案件ごとに生成されており、新たな申込を受け付けると販売処理部３２により追加される。
【００７０】
「受付番号」は、チケットの購入の申込を受け付けた場合に販売処理部３２が付与する番号であり、この番号により申込に係る案件を特定することができる。
「カードＩＤ」は、決済の対象となる電子マネーカード９のカードＩＤであり、申込時に電子マネーカード９から送信されてきたものを販売処理部３２が書き込んだものである。
【００７１】
「決済金額」は、チケットの代金であり、決済の対象となる金額である。
後述するように、商品データベース３４では、チケットとチケット代金が対応付けられており、販売処理部３２は、ユーザが申し込むチケットの代金を商品データベース３４から取得し、販売データベース３３に記憶する。
なお、顧客がチケットを複数枚申し込んだ場合は、それらの合計額となる。
【００７２】
「チケット情報」は、チケットに関する情報を記憶する項目である。チケット情報として記憶される情報としては、例えば、アーチスト名、公演日、公演時間、会場、座席番号などがある。
「決済ステータス」は、当該申込案件が決済されたか否かを識別するための情報を記憶する項目である。
「決済ステータス」は、顧客から申込を受け付けた時点では「未決済」に設定され、決済サーバ４から決済完了通知を受信した時点で「既決済」に設定される。
【００７３】
後述するように、「決済ステータス」が「既決済」に設定された申込案件のカードＩＤはチケット番号として使用し、電子マネーカード９をチケットとして用いることが可能となる。
このほかに販売データベース３３には、顧客の氏名、年齢、住所、電話番号、電子メール番号などを記憶することができる。
【００７４】
図５（ｂ）は、商品データベース３４の論理的な構成の一例を示した図である。
商品データベース３４は、「アーチスト名」、「公演日時」、「チケット価格」、「座席情報」、…などの項目から構成されている。
【００７５】
「アーチスト名」は、公演を行うアーチストの名称である。「公演日時」は、公演が行われる日時である。「チケット価格」は、チケットの価格である。
これらの情報は、購入画面で表示され、顧客が選択したものが販売データベース３３に記憶される。
【００７６】
「座席情報」は、公演で提供される座席番号などが記憶されており、顧客からの申込により、顧客に割り当てられる。割り当てられた座席番号に関しては消し込みが行われる。
【００７７】
次に、決済サーバ４について説明する。
図４（ｂ）は、決済サーバ４の機能的な構成の一例を示した機能ブロック図である。
この決済サーバ４は、ネットワークを介して顧客にコンテンツをダウンロード販売し、その代金を電子マネーカード９で決済するサーバ装置であって、コンテンツ販売サイトからコンテンツの販売業務を行うかたわら販売サーバ３の決済の代行も請け負っているものとする。
【００７８】
決済サーバ４は、通信制御部４１、販売処理部４２、決済処理部４３、商品データベース４５、決済ログデータ一時記憶部４６…などから構成されている。
通信制御部４１は、決済サーバ４をネットワークに接続する機能部であり、決済サーバ４は、通信制御部４１を介して、顧客端末２、販売サーバ３、電子マネー管理サーバ５に接続する。
【００７９】
販売処理部４２は、商品データベース４５に記憶されているコンテンツを顧客に販売する機能部である。
販売処理部４２は、顧客端末２からのアクセスを受け付け、コンテンツ販売画面データを顧客端末２に送信する。そして、顧客が購入を希望するコンテンツを商品データベース４５から読み出し、顧客端末２に端末に送信する。
【００８０】
決済処理部４３は、電子マネーカード９による決済を行う機能部であり、コンテンツ販売の代金を決済するほか、販売サーバ３からの依頼を受けてチケット代金の決済も行う。
なお、本実施の形態では、一例として、決済サーバ４は決済を行い、チャージは電子マネー管理サーバ５が行うことにするが、これに限定せず、決済サーバ４にチャージ機能を持たせることも可能である。
【００８１】
決済処理部４３は、決済金額分のバリューを減算する減算命令を生成し、電子マネーカード９に送信する。そして、電子マネーカード９が送信した減算処理完了通知を受信して、電子マネーカード９での決済が完了したことを確認する。
決済が販売サーバ３から依頼されたものである場合は、決済完了通知を販売サーバ３に送信する。
【００８２】
商品データベース４５は、決済サーバ４が販売するコンテンツを記憶したデータベースである。
コンテンツとしては、例えば、音楽コンテンツ、動画コンテンツ、ゲームコンテンツなどのソフトウェアがある。
【００８３】
決済ログデータ一時記憶部４６は、決済処理部４３が行った決済に関するログデータを一時的に保存する記憶部である。
決済ログデータ一時記憶部４６に記憶されたログデータは、例えば、１日に１回程度バッチ処理にて電子マネー管理サーバ５に送信される。
【００８４】
ここで、図６を用いて決済ログデータ一時記憶部４６が記憶したログデータの論理的な構成の一例について説明する。
図６に示したように、ログデータは、「カードＩＤ」、「金額」、「依頼販売店」、「受付番号」、「チケット情報」…などの項目から構成されている。
これら項目は、決済のトランザクション（取引処理）ごとに生成されており、新たなトランザクションが発生すると、決済処理部４３により更新される。
【００８５】
「カードＩＤ」は、決済を行った電子マネーカード９のカードＩＤであり、決済実行時に、電子マネーカード９から読み取ったものである。
「金額」は、トランザクションによって決済処理部４３が決済した金額である。
「依頼販売店」は、決済が販売サーバ３を運営する販売店から依頼されたものである場合、その販売店を識別する情報が記憶される。
本実施の形態では、販売店を単数として説明するが、複数存在することもでき、その場合、決済を依頼した販売店を識別する必要がある。
【００８６】
また、決済が決済サーバ４のコンテンツを販売した代金に対して行われたものである場合、「依頼販売店」に、販売店名は記憶されない。
このように「依頼販売店」を参照することにより、その決済が販売店から依頼されたものであるのか、あるいは、自身が取り扱う商品の代金を決済したものかを識別することができる。
【００８７】
「受付番号」、及び「チケット情報」は、それぞれ販売サーバ３から受信したチケットの申込の受付番号と、チケット情報である。
これらの情報は、決済を実行する際に顧客に決済内容を確認してもらうのに使用する。
【００８８】
次に電子マネー管理サーバ５について説明する。
図４（ｃ）は、電子マネー管理サーバ５の機能的な構成の一例を示した機能ブロック図である。
電子マネー管理サーバ５は、通信制御部５１、集計処理部５２、決済ログデータ記憶部５３、…などを備えている。
【００８９】
通信制御部５１は、販売サーバ３、決済サーバ４などと通信を行う機能部である。電子マネー管理サーバ５は、通信制御部５１を介してバリュー決済に関する情報を販売サーバ３、決済サーバ４などと送受信することかできる。
集計処理部５２は、決済サーバ４からバリューに関するログデータを受信してこれを集計する機能部である。
集計結果により、イシュアが蓄積しているバリュー原資の配分先と配分額が決定される。
【００９０】
また、決済サーバ４が決済した金額のうち、決済サーバ４からの依頼により決済したものがあった場合、集計処理部５２は、決済金額のうち、代行手数料を決済サーバ４を運営する加盟店の売り上げとし、決済金額から代行手数料を減算した金額を販売サーバ３を運営する販売店の売り上げとする。
このように、集計処理部５２は、決済代行に伴う資金の授受を精算する精算処理機能を有している。
【００９１】
決済ログデータ記憶部５３は、決済サーバ４からバッチ処理にて送信されてきたログデータを記憶する機能部である。
決済ログデータ記憶部５３に蓄積されたログデータは、商取引に伴うバリューの移動を解析するのに用いられる。
【００９２】
図７（ａ）は、決済ログデータ記憶部５３に蓄積されたログデータの論理的な構成の一例を示した図である。
このログデータは、「加盟店」、「カードＩＤ」、「金額」、「依頼販売店」、「受付番号」、「チケット情報」、…などの項目から構成されている。
【００９３】
なお、本実施の形態では、加盟店が通常業務を行うシステムに販売サーバ３を組み込み、決済サーバ４が通常業務で行った決済ログデータに、販売サーバ３が行った販売に関するデータも含めているが、この他に、顧客から受領した金額情報と電子マネーＩＤだけを保持し、決済完了後に顧客に通知するだけの簡易な仕組みを導入することも可能である。
【００９４】
「加盟店」には、ログデータの送信元の決済サーバ４を運営する加盟店を識別する情報が記憶されている。
他の項目は、決済ログデータ一時記憶部４６に記憶されているものと同じであるので説明を省略する。
【００９５】
図７（ｂ）は、集計処理部５２が行った集計結果の一例を示した図である。この集計は、決済ログデータ記憶部５３に蓄積されたログデータを用いて行われたものである。
決済サーバ４を運営する加盟店に関しては、決済した金額の合計が加盟店ごとに算出される。
決済した金額のうち、販売サーバ３から決済の代行を依頼された分に関しては、予め取り決めてある代行手数料が合計される。
【００９６】
販売サーバ３を運営する販売店に関しては、販売代金から決済の代行手数料を減算した金額が販売店ごとに合計される。
集計処理部５２は、以上のような、決済の代行に伴う代行手数料の精算を含めた各加盟店、各販売店ごとのバリューの移動を、所定期間ごと（例えば、１日１回）に集計する。
【００９７】
加盟店に関しては、決済合計額分だけバリュー原資を配分し、販売店には、販売代金合計額から手数料合計額を引いた金額分だけバリュー原資を配分する。
即ち、販売サーバ３の販売店は、チケットの販売代金（代行手数料を引いたもの）をバリュー原資から得ることができ、一方、決済サーバ４の加盟店は、決済代行による代行手数料をバリュー原資から得ることができる。
【００９８】
なお、図示しないが、電子マネー管理サーバ５は、顧客からの要求により電子マネーカード９へのチャージを行う機能を有している。この場合、機器認証サーバ５は、顧客から要求があったチャージ金額分のバリューを加算する加算命令を生成し、電子マネーカード９に送信する。
チャージした金額分の料金は、顧客が予め決済サーバ４に登録した銀行口座やクレジットカードを用いて顧客から徴収する。徴収した資金は、イシュアのバリュー原資となる。
また、図示しないが、機器認証サーバ５は、各電子マネーカードごとにチャージした金額を記憶したデータベースも備えている。
【００９９】
図８は、販売サーバ３のハードウェア的な構成の一例を示した図である。
ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１２１は、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１２２に記憶されているプログラムや、記憶部１２８からＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１２３にロードされたプログラムに従って各種の処理を実行する中央処理装置である。
このような処理としては、例えば、顧客端末２から申込情報の受信、決済サーバ４への決済情報の送信、決済サーバ４からの決済完了通知の受信、販売データの管理などがある。
【０１００】
ＲＯＭ１２２は、販売サーバ３を機能させる上で必要な基本的なプログラムやパラメータなどが記憶されている。
ＲＡＭ１２３は、ＣＰＵ１２１が各種の処理を実行する上で必要なワーキングエリアを提供する。
【０１０１】
記憶部１２８は、販売サーバ３が機能するために必要な各プログラムやデータを記憶しており、例えば、ハードディスクや半導体メモリなどの記憶装置により構成されている。
【０１０２】
記憶部１２８に記憶されている情報としては、例えば、通信制御部３１を構成するための通信制御プログラム、販売処理部３２を構成するための販売処理プログラム、販売データベース３３、商品データベース３４、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）などがある。ＯＳは、ファイルの入出力を行ったり、販売サーバ３の各部を制御したりなど、基本的な機能を実現するためのプログラムである。
【０１０３】
ＣＰＵ１２１、ＲＯＭ１２２、ＲＡＭ１２３は、バス１２４を介して相互に接続されている。このバス１２４には、入出力インターフェース１２５も接続されている。
入出力インターフェース１２５には、キーボード、マウスなどよりなる入力部１２６、ＣＲＴ（Ｃａｔｈｏｄｅ−ｒａｙ  Ｔｕｂｅ）、ＬＣＤ（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）などよりなるディスプレイ、並びにスピーカなどによりなる出力部１２７、ハードディスクなどにより構成される記憶部１２８、モデム、ターミナルアダプタなどにより構成される通信部１２９が接続されている。
【０１０４】
通信部１２９は、ネットワークを介しての通信処理を行う機能部であり、例えば、決済サーバ４に接続して決済情報を送信したり、決済完了通知を受信したりなどする。
また、入出力インターフェース１２５には、必要に応じてドライブ１３０が接続され、磁気ディスク１４１、光ディスク１４２、光磁気ディスク１４３、又はメモリカード１４４などが適宜装着され、それから読み出されたコンピュータプログラムが、必要に応じて記憶部１２８にインストールされる。
なお、決済サーバ４、電子マネー管理サーバ５、顧客端末２の構成は基本的に販売サーバ３と同様であるので説明は省略する。
【０１０５】
図９は、チケット購入に際し、顧客端末２で表示される画面の一例を説明するための図である。
以下、図９（ａ）〜図９（ｄ）は、販売サーバ３が送信した画面データにより表示されたものである。
【０１０６】
図９（ａ）は、顧客が購入を申し込むチケットを選択した後に表示される画面であって、講演名、公演日時、会場が表示されるほか、会員ＩＤ入力欄とパスワード入力欄が表示される。
顧客は、表示内容を確認した後、自己の会員ＩＤとパスワードを入力し、「ログイン」ボタンをクリックする。
また、「ログイン」ボタンをクリックする際に、電子マネーカード９をリーダライタ８にセットしておく。
「ログイン」ボタンをクリックすると販売サーバ３は、電子マネーカード９のカードＩＤを読み出す。
【０１０７】
本実施の形態では、電子マネーカード９を用いて販売サーバ３からチケットを購入する場合、予め販売サーバ３に会員登録するものとしたが、会員登録しないでチケットを購入できるようにシステムを構成しても良い。
会員制を用いた場合、顧客の氏名、住所、電話番号などを登録しておき、チケットを購入するたびにこれらの情報を入力する手間を省略することができる。また、顧客にポイントを発行するなどの会員サービスを提供することもできる。
なお、従来のチケットサービスのように、チケットの郵送を必要としないため、また、バリューによる決済が可能となるため、住所などの個人情報を取得しなくてもチケットサービスの実現が可能である。
【０１０８】
図９（ｂ）は、図９（ａ）の画面で「ログイン」ボタンをクリックした場合に表示される画面である。
この画面には、購入を申し込むチケットに関する情報のほか、カードＩＤが表示され、顧客が確認するようになっている。
「確定」ボタンをクリックすると申込内容が確定し、販売サーバ３が受付番号を付与すると共に、電子マネーカード９からカードＩＤを読み取る。
「キャンセル」ボタンをクリックすると、チケットの申込をやり直すようになっている。
【０１０９】
図９（ｃ）は、図９（ｂ）の画面で「確定」ボタンをクリックした場合に表示される画面である。この画面では、受付番号と決済金額が表示される。
また、今決済するか否かの問い合わせが表示され、顧客は、「はい」ボタン、「後日にします」ボタンを選択することにより、今決済するか、又は後日決済するかを選択することができる。
「はい」ボタンをクリックすると、図９（ｅ）の画面に遷移し、直ちに決済処理に移行する。
「後日にします」ボタンをクリックすると、図９（ｄ）に示した画面に遷移する。
【０１１０】
図９（ｄ）の画面では、決済を受け付ける期間と、決済サーバ４が開設している決済サイトのＵＲＬが表示される。
この決済サイトは、販売サーバ３が複数ある決済サーバ４から選択したものが開設しているものである。
顧客は表示された期間内に指定されたＵＲＬを用いて決済サイトにアクセスし、決済を行う。
【０１１１】
図９（ｅ）は、顧客端末２が、販売サーバ３が指定した決済サイトにアクセスした際に表示される画面である。
この画面では、顧客に電子マネーカード９をリーダライタ８にセットするように促す表示がなされる。
電子マネーカード９をリーダライタ８にセットした後、「次へ」ボタンをクリックすると、決済サーバ４は、電子マネーカード９からカードＩＤを読み取る。
決済サーバ４は、電子マネーカード９から読み取ったカードＩＤと、販売サーバ３から受信したカードＩＤを照合することにより、決済情報を特定する。
【０１１２】
図９（ｆ）は、図９（ｅ）で「次へ」ボタンをクリックした場合に表示される画面である。
この画面では、決済の対象となるチケットに関する情報が表示される。
これらの情報は、決済サーバ４が、カードＩＤから特定した決済情報を用いて生成したものである。
顧客は、これらの情報を確認し、「決済」ボタンか「キャンセル」ボタンを選択してクリックする。
【０１１３】
顧客が「決済ボタン」をクリックした場合、決済サーバ４は、減算命令を電子マネーカード９に送信して決済を行う。
顧客が「キャンセル」ボタンをクリックした場合、決済サーバ４は決済を行わない。そして、指定した期間内に顧客が決済しない場合は、チケットの申込は取り消しになる。
【０１１４】
図９（ｇ）は、図９（ｆ）の画面で「決済」ボタンをクリックした場合に表示される画面である。
この画面の画面データは、決済サーバ４が生成して顧客端末２に送信しても良いし、あるいは販売サーバ３が決済完了通知を受信した後に生成して顧客端末２に送信しても良い。
この画面では、チケットの代金の決済が完了した旨の通知と、決済に使用した電子マネーカード９がそのままチケットとして使用されるので当日公演会場に持参するようにとの指示が表示される。また、質問などの問い合わせ先も表示される。
【０１１５】
図１０は、販売システム１でチケットを販売する手順を説明するためのフローチャートである。
まず、顧客は、チケットを購入するために顧客端末２から販売サーバ３の販売サイトにアクセスする（ステップ５）。
これに対し販売サーバ３は、購入画面データを顧客端末２に送信する（ステップ４０）。
【０１１６】
顧客は、販売サイトでチケットを選択する。この際に、顧客は電子マネーカード９をリーダライタ８にセットしておき、販売サーバ３が電子マネーカード９のカードＩＤを読み出せるようにしておく。
顧客端末２は、販売サーバ３に顧客が選択したチケットを特定する情報を送信する（ステップ１０）。
販売サーバ３は、これを受信し、一時記憶する。そして、電子マネーカード９に対してカードＩＤ出力命令を送信する（ステップ４５）。
【０１１７】
電子マネーカード９は、カードＩＤ出力命令を受信して実行し、販売サーバ３にカードＩＤを送信する（ステップ１５）。
販売サーバ３は、カードＩＤを受信し、また、受付番号を採番し、これらを先に記憶したチケットを特定する情報と共に、申込情報として販売データベース３３に記憶する（ステップ５０）。
【０１１８】
次に、販売サーバ３は、決済の代行を依頼する決済サーバ４を選択する。そして、申込情報から決済情報を生成し、これを選択した決済サーバ４に送信する（ステップ５５）。
決済サーバ４は、販売サーバ３から決済情報を受信して記憶し、顧客からのアクセスに備える（ステップ７０）。
【０１１９】
一方、販売サーバ３は、選択した決済サーバ４の決済サイトのＵＲＬを顧客端末２に送信し、この決済サーバ４に接続するように指示する（ステップ６０）。
顧客は、販売サーバ３との接続を一端切断し、販売サーバ３から指示された決済サイトにアクセスする（ステップ２０）。その際に、電子マネーカード９をリーダライタ８にセットしておく。
【０１２０】
決済サーバ４は、顧客端末２からアクセスを受け付け、電子マネーカード９に対してカードＩＤ出力命令を送信する（ステップ７３）。
電子マネーカード９は、このカードＩＤ出力命令を受信して実行し、決済サーバ４に対してカードＩＤを送信する（ステップ２５）。
【０１２１】
決済サーバ４は、電子マネーカード９からカードＩＤを受信してこれを販売サーバ３から受信した決済情報と照合し、該当する決済情報を特定する。そして、決済情報から決済する金額を取得して、この金額分だけバリューを減算処理するための減算命令を生成し、電子マネーカード９に送信する（ステップ７５）。
【０１２２】
電子マネーカード９は、決済サーバ４から減算命令を受信して実行し、決済金額分だけバリューを減算処理する（ステップ１５）。
電子マネーカード９は、減算処理を実行後、減算処理完了通知を決済サーバ４に送信する（ステップ３０）。
【０１２３】
決済サーバ４は、電子マネーカード９から減算完了通知を受信し、決済が完了したことを表示するための決済完了画面データを生成し、顧客端末２に送信する（ステップ８０）。
顧客端末２は、この画面データを受信して、この決済完了画面を表示装置に表示する（ステップ３５）。
【０１２４】
更に、決済サーバ４は、販売サーバ３に対して、決済完了通知を送信する（ステップ８５）。
販売サーバ３は、この決済完了通知を受信して、決済が行われた申込情報を特定し、決済ステータスを「未決済」から「既決済」に更新する。これにより、決済に使用した電子マネーカード９のカードＩＤがチケット番号として登録される（ステップ６５）。
【０１２５】
次に、チケットとして登録された電子マネーカード９の使用方法について説明する。
図１１は、公演会場の入場システムを模式的に示した図である。
この入場システムは、入場管理サーバ６１、公演会場の入口に設置され、入場管理サーバ６１と接続された入口端末６２、入口端末６２に配設されたリーダライタ６３などから構成されている。
【０１２６】
リーダライタ６３は、リーダライタ８と同様に、電子マネーカード９と近距離の無線通信を行う。
入口端末６２は、リーダライタ８を駆動すると共に、入場管理サーバ６１と通信する。
このように、入口端末６２、リーダライタ６３は、入場管理サーバ６１と電子マネーカード９の通信を仲介する。
【０１２７】
入場管理サーバ６１は、図１２に示したような項目から構成される登録チケットデータを備えている。
登録チケットデータは、「カードＩＤ」、「入場ステータス」、「チケット情報」、…などの項目から構成されている。
【０１２８】
これらの項目は、販売サーバ３の販売データベース３３で、「決済ステータス」が「既決済」となり、チケット登録されたものを集計したものであり、販売サーバ３から取得したものである。
また、「入場ステータス」は、デフォルトでは「未入場」に設定されており、顧客が入場すると「入場済み」に設定される。
【０１２９】
顧客は、公演会場に入場する際に、入口で電子マネーカード９をリーダライタ６３にセットする。
入場管理サーバ６１は、この電子マネーカード９からカードＩＤを取得して、登録チケットデータに登録されているカードＩＤのうち「入場ステータス」が「未入場」となっているものと照合する。
【０１３０】
入場管理サーバ６１は、照合の結果、電子マネーカード９のカードＩＤが登録チケットデータベースで検索されたか否かの結果を入口端末６２に送信する。入口端末６２は、これを係員に提示する。
電子マネーカード９のカードＩＤが、登録チケットデータベースで検索された場合、顧客は公演会場への入場を許可される。
【０１３１】
入場管理サーバ６１は、カードＩＤを検索した後、このカードＩＤに係る「入場ステータス」を「入場済み」に設定する。
また、入場管理サーバ６１は、「チケット情報」を用いて顧客の座席番号などを入口端末６２に提示するなどして、顧客の利便性を高めることもできる。
【０１３２】
なお、本実施の形態では、電子マネーカード９をチケットとして使用したが、これに限定するものではなく、例えば、従来行われているように、顧客にチケットを郵送するように構成することもできる。
また、登録チケットデータベースは、決済サーバ４が商品データベース３４を用いて生成し、入場管理サーバ６１に提供したものである。
この提供は、登録チケットデータベースを記憶媒体に記憶して公演会場に送付したり、あるいは、所定期間ごとに販売サーバ３がバッチ処理して入場管理サーバ６１に送信したり、あるいは、ＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）などで送信することができる。
また、開演直前など、即時性が要求される場合は、販売サーバ３が決済完了通知を受信すると共にネットワークで入場管理サーバ６１にカードＩＤなどを送信するように構成することができる。
【０１３３】
以上に説明した本実施の形態により以下のような効果を得ることができる。
（１）電子マネーカード９による決済機能を持たない販売システムを利用している販売店であっても、電子マネーカード９による決済機能を持つ加盟店に決済の代行を依頼することにより、商品を販売することができる。
（２）販売店は、複数の決済サーバ４に決済代行の依頼を行うことにより、複数の決済サーバ４から決済を依頼するものを選択することができる。
【０１３４】
（３）複数台の決済サーバ４に決済処理を分散させるため、一時期にチケット購入の申込が殺到しても、とりあえずチケット購入の申込だけ受け付けることができる。そのため、決済の待ち時間が長いため顧客を逃すといったことを防ぐことができる。
（４）複数台の決済サーバ４に決済処理を分散させるため、決済処理の集中により特定の決済サーバ４に過度の負荷がかかることを防ぐことができる。
【０１３５】
（５）チケットの申込は、販売サイトで行い、チケット代金の支払いは後ほど決済サイトで行うというように申込と決済を分離したため、チケット購入時に電子マネーカード９にチケット代金分のバリューがチャージされている必要はない。そのため、顧客は、バリュー残高の不足が原因でチケット購入の機会を逃すことがなく、販売サイト側は、訪れてきた顧客に確実にチケット販売することができる。
【０１３６】
以上、本実施の形態について説明したが、販売システム１を用いた様々なビジネス上の応用が可能である。
例えば、販売サーバ３の販売サイトは、集客力が高いため、ここに広告を掲載することにより、広告宣伝効果を高めることができる。特に、チケットの公演に関する広告を掲載すると効果的である。
【０１３７】
また、本実施の形態では、一例として、チケットを販売する場合について説明したが、これに限定するものではなく、ネットワークを介した商取引全般に適用することができる。
例えば、販売サーバ３がコンテンツを販売するサーバ装置であった場合、決済サーバ４での決済処理が終了した後、顧客端末２から再度販売サイトに接続してもらい、顧客端末２に対して決済が完了したコンテンツをダウンロードすることができる。
【０１３８】
また、顧客は、決済サイトにアクセスする必要があるため、ここに広告を掲載することにより、広告宣伝効果を高めることができる。
決済サーバ４を提供する加盟店が自社の商品を宣伝することにより、加盟店側もメリットを享受することができる。
【０１３９】
特に、チケットの公演に関する商品を取り扱っている加盟店に決済代行を依頼すると広告宣伝効果が高くなる。
例えば、サッカーチケットの決済代行をサッカー用品を販売している加盟店が行うことにより、加盟店は、決済サイトにアクセスした顧客にサッカー用品を宣伝・販売することができる。
【０１４０】
（変形例）
近年、携帯電話が広く普及してきた。そこで、携帯電話に電子マネーカード９と同様なＩＣチップを埋め込み、携帯電話で電子マネーを使用できるようにするビジネスモデルが提案されている。
ここでは、このような電子マネー機能を備えた携帯電話を販売システム１に適用する場合について説明する。
【０１４１】
図１３に示した携帯電話２０７は、電話機能部２１０、電子マネー機能部２１２、及び電話機能部２１０と電子マネー機能部２１２の通信を仲介するインターフェース部２１１から構成されている。
電話機能部２１０は、公衆回線網に接続して他の電話機と通話を行う通話モードと、インターネットに接続し、Ｗｅｂサイトが提供するサービスを利用するインターネットモードを有している。
以下では、携帯電話２０７をインターネットモードで使用するものとする。
【０１４２】
電話機能部２１０は、ディスプレイや数字・文字キー、機能キーなどを備えており、Ｗｅｂサイトが提供する情報の提示や、情報の入力・送信が行えるようになっている。
顧客は、電話機能部２１０から、ＵＲＬを入力することにより販売サイトや決済サイトにアクセスし、これらのサイトが提供するサービスを利用することができる。
【０１４３】
電子マネー機能部２１２は、電子マネーカード９に内蔵されているＩＣチップと同様のＩＣチップにより構成され、情報処理部２２８、バリュー記憶部２２９、通信制御部２３１、ＩＤ記憶部２３３、…などから構成されている。
これらの機能部は、それぞれ電子マネーカード９（図２）の情報処理部１５、バリュー記憶部１６、通信制御部１８、カードＩＤ記憶部１７に対応する。
【０１４４】
インターフェース部２１１は、リーダライタ８に対応する機能を有しており、電話機能部２１０と電子マネー機能部２１２の間の通信を仲介する。
販売サイト、決済サイトは、電話機能部２１０、インターフェース部２１１を介して、電子マネー機能部２１２に各種命令を入力すると共に、電子マネー機能部２１２が出力した情報を受信することができる。
【０１４５】
通信制御部２３１は、図示しない内蔵アンテナに接続されており、このアンテナを介して、リーダライタを備えた外部の端末装置と通信することができる。
このように、電子マネー機能部２１２には、インターネット経由でアクセスすることができると共に、電子マネーカード９と同様にリーダライタ経由でアクセスすることもできる。
【０１４６】
以上のように構成された携帯電話２０７は、販売システム１において以下のように利用される。
まず、顧客は、電話機能部２１０から販売サイトにアクセスし、チケットの購入を申し込む。この際に、販売サーバ３は、ＩＤ出力命令を電子マネー機能部２１２に送信し、電子マネー機能部２１２からＩＤを取得する。
【０１４７】
販売サーバ３は、決済情報を生成する。そして、決済サーバ４を選択し、選択した決済サーバ４に決済情報を送信して決済の代行を依頼する。
顧客は、電話機能部２１０からこの決済サーバ４の決済サイトにアクセスし、決済処理を申し出る。
【０１４８】
これに対し、決済サーバ４は、ＩＤ記憶部２３３からＩＤを取得して申込案件を特定し、決済金額分の減算命令を生成して電子マネー機能部２１２に送信する。
電子マネー機能部２１２では、情報処理部２２８がこの減算命令を実行し、バリュー記憶部２２９に記憶されているバリューを減算処理する。
決済サーバ４は、減算処理終了後、決済完了通知を販売サーバ３に送信し、決済サーバ４は、電子マネー機能部２１２のＩＤをチケット登録する。
【０１４９】
顧客は、公演当日に公演会場に携帯電話２０７を持参し、入口に設置されたリーダライタ６３に携帯電話２０７をセットする。
入場管理サーバ６１は、入口端末６２、リーダライタ６３を経由して電子マネー機能部２１２にアクセスし、電子マネー機能部２１２のＩＤを取得する。
そして、このＩＤを登録チケットデータベースと照合して、その結果を入口端末６２に送信する。
以上の手順により、顧客は、携帯電話２０７をチケットとして使用することができる。
【産業上の利用可能性】
【０１５０】
電子マネーカードでの決済機能を持たない販売サーバであっても、電子マネーカードでの決済機能を有する決済サーバに販売代金の決済の代行を依頼することにより、電子マネーを用いた商品販売を行うことができる。
【図面の簡単な説明】
【０１５１】
【図１】販売システムの構成を説明するための図である。
【図２】電子マネーカードの機能的な構成を説明するための機能ブロック図である。
【図３】電子マネーカードのハードウェア的な構成を示した図である。
【図４】各サーバの機能的な構成を示した図である。
【図５】販売データベースなどの論理的な構成を示した図である。
【図６】決済ログデータ一時記憶部のログデータの倫理的な構成を示した図である。
【図７】決済ログデータ記憶部のログデータの論理的な構成などを示した図である。
【図８】販売サーバのハードウェア的な構成を示した図である。
【図９】顧客端末での画面遷移を示した図である。
【図１０】チケットを販売する手順を説明するためのフローチャートである。
【図１１】公演会場の入場システムを模式的に示した図である。
【図１２】登録チケットデータの論理的な構成を示した図である。
【図１３】変形例を説明するための図である。
【符号の説明】
【０１５２】
１  販売システム
２  顧客端末
３  販売サーバ
４  決済サーバ
５  電子マネー管理サーバ
８  リーダライタ
９  電子マネーカード
【図１】
2005071081.tif 000003
【図２】
2005071081.tif 000004
【図３】
2005071081.tif 000005
【図４】
2005071081.tif 000006
【図５】
2005071081.tif 000007
【図６】
2005071081.tif 000008
【図７】
2005071081.tif 000009
【図８】
2005071081.tif 000010
【図９】
2005071081.tif 000011
【図１０】
2005071081.tif 000012
【図１１】
2005071081.tif 000013
【図１２】
2005071081.tif 000014
【図１３】
2005071081.tif 000015