JP2008171202A - 取引システム、および、取引管理装置 - Google Patents

取引システム、および、取引管理装置 Download PDF

Info

Publication number
JP2008171202A
JP2008171202A JP2007003772A JP2007003772A JP2008171202A JP 2008171202 A JP2008171202 A JP 2008171202A JP 2007003772 A JP2007003772 A JP 2007003772A JP 2007003772 A JP2007003772 A JP 2007003772A JP 2008171202 A JP2008171202 A JP 2008171202A
Authority
JP
Japan
Prior art keywords
transaction
information
value
data processing
electronic money
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2007003772A
Other languages
English (en)
Other versions
JP5220318B2 (ja
Inventor
Kazutoshi Nakajima
和俊 中島
Yoshiteru Washio
芳輝 鷲尾
Katsuyuki Iwanabe
克行 岩邉
Tsutomu Murayama
勉 村山
Akihiro Tanaka
明弘 田中
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sankyo Co Ltd
Original Assignee
Sankyo Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sankyo Co Ltd filed Critical Sankyo Co Ltd
Priority to JP2007003772A priority Critical patent/JP5220318B2/ja
Publication of JP2008171202A publication Critical patent/JP2008171202A/ja
Application granted granted Critical
Publication of JP5220318B2 publication Critical patent/JP5220318B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

【課題】特定店舗における取引額に応じた特典付与によって、特定店舗への集客向上に寄与すること。
【解決手段】複数の店舗に設置され、携帯端末に記憶されている取引価値を用いて取引処理を実行する取引装置と、前記取引処理に用いられた前記取引価値の額である取引額を各携帯端末ごとに集計して管理する取引額管理手段を有する取引管理装置とを含む取引システムによって、各携帯端末の取引額が各店舗ごとに集計して管理され、複数の店舗のうちから、取引処理に対する特典付与の対象とする特典付与対象店舗が設定され、管理されている取引額のうち、設定された特典付与対象店舗における取引額に応じて特典を付与するための特典付与処理が実行される(S2192〜2198)。
【選択図】図27

Description

本発明は、取引システム、および、取引管理装置に関する。詳しくは、複数の店舗に設置され、携帯端末に記憶されている取引価値を用いて取引処理を実行する取引装置と、前記取引処理に用いられた前記取引価値の額である取引額を各携帯端末ごとに集計して管理する取引額管理手段を有する取引管理装置とを含む取引システム、および、取引管理装置に関する。
従来、サーバでカードIDに対応付けてポイントを管理し、各店舗での商品購入代金に応じてポイントを付与するシステムがあった(たとえば、特許文献1)。
特開2005−433号公報(第0025段落、第0026段落、第0030段落および第0038段落)
しかし、特許文献1に開示されている技術においては、いずれの店舗での商品購入に対しても一律に特典(たとえば、ポイント)が付与されるため、特典の付与を特定店舗の集客向上に利用することができないといった問題があった。
この発明はかかる事情に鑑み考え出されたものであり、その目的は、特定店舗への集客向上に寄与することが可能な取引システム、および、取引管理装置を提供することである。
課題を解決するための手段の具体例およびその効果
(1) 複数の店舗(たとえば、遊技場30)に設置され、携帯端末(たとえば、携帯電話100)に記憶されている取引価値(たとえば、バリュー)を用いて取引処理(たとえば、プリペイドカード371の発券処理、遊技球の球貸処理)を実行する取引装置(たとえば、券売機300、カードユニット600)と、前記取引処理に用いられた前記取引価値の額である取引額を各携帯端末ごとに集計して管理する取引額管理手段(たとえば、データ処理部210、記憶部220、通信部260、発行情報DB222、残高管理AP214)を有する取引管理装置(たとえば、電子マネー管理サーバ200)とを含む取引システム(たとえば、電子マネーシステム10)であって、
前記取引額管理手段は、前記各携帯端末の取引額を各店舗ごとに集計して管理し(たとえば、発行情報DB222で携帯端末情報と取引店舗と取引額とを対応付けて記憶)、
前記取引管理装置は、
前記複数の店舗のうちから、前記取引処理に対する特典付与の対象とする特典付与対象店舗を設定する対象店舗設定手段(たとえば、特典設定画面、特典付与店舗DB)と、
前記取引額管理手段によって管理されている取引額のうち、前記対象店舗設定手段によって設定された前記特典付与対象店舗における取引額に応じて前記特典を付与するための特典付与処理を実行する特典付与手段(たとえば、データ処理部210、特典付与AP217、ステップS2192〜S2198)を含む。
このような構成によれば、取引システムによって、各携帯端末の取引額が各店舗ごとに集計して管理され、複数の店舗のうちから、取引処理に対する特典付与の対象とする特典付与対象店舗が設定され、管理されている取引額のうち、設定された特典付与対象店舗における取引額に応じて特典を付与するための特典付与処理が実行される。
このため、取引管理装置で管理されている特典付与対象店舗における取引額に応じて特典が付与されるので、特典付与対象店舗での取引処理の動機付けを与えることができる。その結果、特定店舗における取引額に応じた特典付与によって、特定店舗への集客向上に寄与することができる。
(2) 前記取引管理装置は、さらに、
複数の店舗が属するグループを設定するグループ設定手段(たとえば、特典設定画面、特典付与店舗DB)を備え、
前記特典付与手段は、前記取引額管理手段によって管理されている取引額のうち、前記グループ設定手段によって設定された前記グループに含まれる前記店舗における取引額の合計額に応じて前記特典付与処理を実行する(たとえば、特典付与AP217、ステップS2192〜S2198)。
このような構成によれば、取引システムによって、複数の店舗が属するグループが設定され、管理されている取引額のうち、設定されたグループに含まれる店舗における取引額の合計額に応じて特典付与処理が実行される。
このため、設定されたグループに含まれる店舗における取引額の合計額に応じて特典が付与されるので、当該グループに含まれる店舗での取引処理の動機付けを与えることができる。その結果、チェーン店などの特定のグループに含まれる店舗における取引額に応じた特典付与によって、特定のグループに含まれる店舗への集客向上に寄与することができる。
(3) 前記特典付与手段は、前記取引額に応じた額の取引価値である付与取引価値を前記携帯端末に記憶させるための処理を、前記特典付与処理として実行する(たとえば、特典付与AP217、ステップS2194)。
このような構成によれば、取引システムによって、取引額に応じた額の取引価値である付与取引価値を携帯端末に記憶させるための処理が、特典付与処理として実行される。
このため、取引額に応じて付与された付与取引価値が携帯端末に記憶される。その結果、付与取引価値をユーザに提供するための媒体を別途用意する必要をなくすることができる。
(4) 前記取引管理装置は、さらに、
前記付与取引価値を使用可能とする使用可能店舗を設定する使用可能店舗設定手段(たとえば、特典設定画面)を備え、
前記特典付与手段は、ユーザによる対価の支払に応じた取引価値とは区別して前記付与取引価値を前記携帯端末(たとえば、携帯電話100の非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用記憶領域)に記憶させるための処理とともに、当該付与取引価値に対して前記使用可能店舗設定手段によって設定された前記使用可能店舗を示す使用可能店舗情報を当該付与取引価値に対応させて前記携帯端末(たとえば、携帯電話100の非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用記憶領域)に記憶させるための処理を、前記特典付与処理として実行し(たとえば、特典付与AP217、ステップS2194)、
前記取引装置は、前記携帯端末から取得した使用可能店舗情報が示す使用可能店舗が、当該取引装置が設置されている店舗であることを条件として、当該使用可能店舗情報に対応させて前記携帯端末に記憶されている付与取引価値を用いて前記取引処理を実行する(たとえば、データ処理部310、ステップS341、ステップS356、ステップS362、データ処理部610、ステップS641、ステップS656、ステップS662)。
このような構成によれば、取引管理装置によって、付与取引価値を使用可能とする使用可能店舗が設定され、ユーザによる対価の支払に応じた取引価値とは区別して付与取引価値を携帯端末に記憶させるための処理とともに、当該付与取引価値に対して設定された使用可能店舗を示す使用可能店舗情報を当該付与取引価値に対応させて携帯端末に記憶させるための処理が、特典付与処理として実行され、取引装置によって、携帯端末から取得した使用可能店舗情報が示す使用可能店舗が、当該取引装置が設置されている店舗であることを条件として、当該使用可能店舗情報に対応させて携帯端末に記憶されている付与取引価値が用いられて取引処理が実行される。
このため、付与取引価値を使用可能店舗でのみ使用可能とすることができるので、使用可能店舗での取引処理の動機付けを与えることができる。その結果、特定店舗で使用可能な特典付与によって、より確実に特定店舗への集客向上に寄与することができる。
(5) 前記取引システムは、さらに、
複数の店舗に設置され、前記携帯端末に対して前記特典を付与する処理を実行する特典付与装置を含み、
前記特典付与手段は、前記特典を示す情報と前記特典が付与される携帯端末を識別するための携帯端末識別情報とを前記特典付与装置に送信する処理を、前記特典付与処理として実行し、
前記特典付与装置は、
前記携帯端末を受付ける受付手段と、
前記受付手段によって受付けられた携帯端末の携帯端末識別情報が、前記特典付与手段から送信された携帯端末識別情報と一致するか否かを判定する携帯端末識別情報判定手段とを含み、
前記携帯端末識別情報判定手段によって携帯端末識別情報が一致すると判定されたことを条件として、当該携帯端末識別情報とともに前記特典付与手段から送信された情報で示される特典を前記受付手段により受付けた携帯端末に対して付与する。
このような構成によれば、取引管理装置によって、特典を示す情報と特典が付与される携帯端末を識別するための携帯端末識別情報とを特典付与装置に送信する処理が、特典付与処理として実行される。特典付与装置によって、携帯端末が受付けられ、受付けられた携帯端末の携帯端末識別情報が、取引管理装置から送信された携帯端末識別情報と一致するか否かが判定され、一致すると判定されたことを条件として、当該携帯端末識別情報とともに取引管理装置から送信された情報で示される特典が受付けられた携帯端末に対して付与される。
このため、店舗に設置された特典付与装置によって携帯端末に特典が付与される。その結果、特典付与が店舗において実施されるため、当該店舗への集客をより確実に向上できる。
(6) 取引管理装置(たとえば、電子マネー管理サーバ200)は、
携帯端末(たとえば、携帯電話100)に記憶されている取引価値(たとえば、バリュー)を用いて取引処理(たとえば、プリペイドカード371の発券処理、遊技球の球貸処理)を実行する複数の店舗(たとえば、遊技場30)に設置される取引装置(たとえば、券売機300、カードユニット600)で実行された前記取引処理に用いられた前記取引価値の額である取引額を各携帯端末および各店舗ごとに集計して管理する取引額管理手段(たとえば、データ処理部210、記憶部220、通信部260、発行情報DB222、残高管理AP214、発行情報DB222で携帯端末情報と取引店舗と取引額とを対応付けて記憶)と、
前記複数の店舗のうちから、前記取引処理に対する特典付与の対象とする特典付与対象店舗を設定する対象店舗設定手段(たとえば、特典設定画面、特典付与店舗DB)と、
前記取引額管理手段によって管理されている取引額のうち、前記対象店舗設定手段によって設定された前記特典付与対象店舗における取引額に応じて前記特典を付与するための特典付与処理を実行する特典付与手段(たとえば、データ処理部210、特典付与AP217、ステップS2192〜S2198)とを備える。
このような構成によれば、特定店舗における取引額に応じた特典付与によって、特定店舗への集客向上に寄与することができる。
[第1の実施の形態]
以下に、本発明を実施するための最良の形態を図面に基づいて詳細に説明する。なお、以下の最良の形態においては、遊技機の一例として、パチンコ遊技機を示すが、本発明は、これに限定されず、たとえば、コイン遊技機およびスロットマシン等のその他の遊技機であってもよい。
(電子マネーシステム10の各構成の説明)
図1は、本発明に係る電子マネーシステム10の構成の一例を示すブロック図である。図1を参照して、電子マネーシステム10は、携帯電話100と、電子マネー管理サーバ200と、決済サーバ280と、リモート発行サーバ400と、金融機関サーバ500,500Aと、遊技場30に設置される機器とを含む。
遊技場30に設置される機器には、券売機300、カードユニット600、パチンコ遊技機700、および、店舗サーバ800が含まれる。カードユニット600は、パチンコ遊技機700に対応して設けられる。
携帯電話100は、本実施の形態における主要な構成として、電子マネーアプリ111と、非接触型IC(Integrated Circuit)チップ190とを備える。携帯電話100は、携帯電話インターネット網910を介して、電子マネー管理サーバ200と通信することが可能である。
電子マネー管理サーバ200は、本発明におけるデータとしての電子マネー(バリュー)を携帯電話100に対して発行する発行処理を行なう発行処理サーバの一例であるとともに、本発明における発行書込処理サーバの一部を構成するものであり、また本発明の取引管理装置の一例であるとともに、電子マネーサーバの一例でもあって、本実施の形態における主要な構成として、初期登録時AP(Application Program)211と、バリュー購入時AP212と、バリュー発行時AP213と、残高管理AP214と、バリュー預かりAP215と、バリュー返却AP216と、特典付与AP217と、特典通知APと、利用者情報DB(DataBase)221と、発行情報DB222と、特典DB223とを備える。
電子マネーシステム10は、ユーザの携帯電話100にチャージされた特定の種類の電子マネーであるバリューを用いて、遊技場30に設置されたパチンコ遊技機700でのパチンコ遊技を可能にするための電子マネー遊技使用サービスを提供するシステムである。
携帯電話100は、通話機能、ウェブブラウザによるウェブページ閲覧機能、電子メール機能、アプリケーションソフト実行機能、および、非接触型ICチップ190による短距離通信機能を備える。なお、ウェブページ閲覧機能、電子メール機能、アプリケーションソフト実行機能、および、非接触型ICチップ190による短距離通信機能を備える装置であれば、携帯電話100に替えて、通話機能がない携帯情報端末(Personal Digital Assistance、以下「PDA」という)などの他の携帯端末であってもよい。
本実施の形態においては、携帯電話100に、電子マネー遊技使用サービスを実行するための携帯電話100側の処理手順を示すプログラムである電子マネーアプリ111が導入されることにより、後述するように、電子マネーシステム10で、この携帯電話100を用いることができるようになる。
電子マネーアプリ111は、携帯電話インターネット網910を介して、電子マネー管理サーバ200や金融機関サーバ500やリモート発行サーバ400と通信することが可能である。また、電子マネーアプリ111は、バリューに関する処理状況を記憶部120に記憶することによって管理する。
非接触型ICチップ190は、電子マネーアプリ111、および、外部のチップリーダライタと通信することが可能である。非接触型ICチップ190と外部のチップリーダライタとの通信は、非接触型ICチップ190がチップリーダライタから数センチメートルの距離に近接するように、携帯電話100がチップリーダライタにかざされることによって行なわれる。
非接触型ICチップ190と外部のチップリーダライタとの通信は、チップリーダライタからの電磁波である搬送波を、非接触型ICチップ190やチップリーダライタが変調させることによって行なわれる。また、非接触型ICチップ190には、チップリーダライタからの電磁波による電磁誘導によって、外部のチップリーダライタ側から電力が供給される。
このため、携帯電話100側から電力が供給されない場合であっても、非接触型ICチップ190がチップリーダライタに近づけられることによって、非接触型ICチップ190は動作可能となる。
電子マネー管理サーバ200は、初期登録時AP211、バリュー購入時AP212、バリュー発行時AP213、残高管理AP214、バリュー預かりAP215、バリュー返却AP216、特典付与AP217、特典通知AP、利用者情報DB221、発行情報DB222、および、特典DB223などの機能によって、携帯電話100および遊技場30に対して、後述するような電子マネー遊技使用サービスにおける様々なサービスを提供する。
決済サーバ280は、請求情報DB281を含み、電子マネー遊技使用サービスに対するユーザの決済を管理する。決済サーバ280は、専用線を介して、電子マネー管理サーバ200と通信することが可能である。
リモート発行サーバ400は、携帯電話100の非接触型ICチップ190に本発明におけるデータとしての電子マネー(バリュー)を書込むための書込処理を行なう書込処理サーバの一例であるとともに、本発明における発行書込処理サーバの一部を構成するものであって、複数のサービス提供機関により使用が可能とされた前記記憶部192に各サービス提供機関が提供するサービスに応じてサービス提供用領域の構築および削除のための処理を行なうとともに、該サービス提供用領域の構築に応じた対価を請求するために各サービス提供機関ごとに課金管理を行なうサービス提供用領域管理機関によって運営される。
リモート発行サーバ400は、電子マネー管理サーバ200および携帯電話100からの非接触型ICチップ190への記憶領域の確保および情報の書込みを管理する。具体的には、本実施例においては、リモート発行サーバ400は、非接触型ICチップ190の記憶部192にサービス提供機関である電子マネー管理サーバ200の運営機関が提供する電子マネー遊技使用サービスに応じて電子マネー遊技使用サービス用の記憶領域の構築および削除のための処理を行なうとともに、電子マネー遊技使用サービス用の記憶領域の構築に応じた対価を請求するために課金管理を行なう。ここで、非接触型ICチップ190の記憶部192は、複数のサービス提供機関により使用が可能とされた記憶媒体であって、携帯電話100に搭載された記憶媒体である。
また、リモート発行サーバ400は、携帯電話100の非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域へバリューを書込むための依頼を携帯電話100から受信する。次に、リモート発行サーバ400は、この依頼に応じて、その電子マネー遊技使用サービス用の記憶領域へバリューを書込むための書込処理を行なう。そして、リモート発行サーバ400は、書込処理の終了に基づいて、当該バリューを書込済であることを処理状況として記憶することによってバリューが書込済であるか否かの処理状況を管理する。また、リモート発行サーバ400は、バリューの書込以外のバリューに関する処理状況も管理する。
金融機関サーバ500,500Aは、電子マネー遊技使用サービスを利用するにあたって電子マネー遊技使用サービスの提供業者に対価を支払うためにユーザが利用する金融機関のサーバである。金融機関サーバ500は、各種収納機関および金融機関が専用線で閉域接続された金融機関専用ネットワーク920を運営する団体に加盟する金融機関に設置される。金融機関サーバ500は、金融機関専用ネットワーク920を介して、決済サーバ280と通信することが可能である。金融機関サーバ500は、携帯電話インターネット網910を介して、携帯電話100と通信することが可能である。金融機関サーバ500Aは、専用線または公衆回線を介して、電子マネー管理サーバ200と通信することが可能である。
つまり、金融機関サーバ500は、金融機関専用ネットワーク920に加盟している第1金融機関に設置される第1金融機関サーバであって、電子マネーのチャージ額の決済を要求する第1決済要求を前記携帯端末から受付けるとともに、当該第1決済要求に対する決済が完了したことを通知するための第1決済完了通知(消込速報)を前記金融機関専用ネットワーク920を介して電子マネー管理サーバ200に通知する。また、金融機関サーバ500Aは、電子マネーのチャージ額の決済を要求する第2決済要求(決済要求情報)を電子マネー管理サーバ200から受付けるとともに、当該第2決済要求に対する決済が完了したことを通知するための第2決済完了通知(決済完了通知)を、(金融機関専用ネットワーク920を介することなく)電子マネー管理サーバ200に通知するサーバであり、第2金融機関に設置される。
なお、図1においては、作図の都合上、金融機関サーバ500および金融機関サーバ500Aをそれぞれ1つのみ示しているが、実際には、電子マネー管理サーバ200の運営機関との間でチャージ額の決済に関し提携している多数の第1金融機関の各々および第2金融機関の各々に設置されている。
金融機関サーバ500は、金融機関専用ネットワーク920と決済サーバ280とを介して、間接的に、電子マネー管理サーバ200と決済のための情報をやり取りする。また、金融機関サーバ500Aは、直接的に、電子マネー管理サーバ200と決済のための情報をやり取りする。以下、金融機関サーバ500が設置された金融機関を、間接決済に対応する金融機関(第1金融機関)という。また、金融機関サーバ500Aが設置された金融機関を、直接決済に対応する金融機関(第2金融機関)という。
券売機300は、ユーザから現金やバリューを受けて、遊技を可能とする所定の遊技価値を有するプリペイドデータを記録したプリペイドカード371を発券する。券売機300は、後述するようにチップリーダライタを含み、前述したように、携帯電話100の非接触型ICチップ190と通信することが可能である。つまり、券売機300は、取引装置の一例であって、携帯電話100に記憶されたバリューを使用してプリペイドカード371を発券する処理を取引処理として行なう。
カードユニット600は、パチンコ遊技機700に対応して設けられる。カードユニット600は、遊技者からプリペイドカード371や現金やバリューを受付けて、パチンコ遊技機700に設けられた球貸ボタンの操作に応じて、プリペイドカード371に記録されたプリペイドデータで示される価値のうちから所定額相当(たとえば、500円相当)の価値を減算する。
カードユニット600は、減算した価値に見合った遊技球を払出すことを指示する球貸操作信号をパチンコ遊技機700に送信する。カードユニット600は、パチンコ遊技機700に設けられた返却ボタン632の操作に応じて、プリペイドカード371を排出する。カードユニット600は、後述するようにチップリーダライタを含み、前述したように、携帯電話100の非接触型ICチップ190と通信することが可能である。つまり、カードユニット600は、取引装置の一例であって、携帯電話100に記憶されたバリューを使用してパチンコ遊技機700から遊技球を払出す処理を取引処理として行なう。
パチンコ遊技機700は、パチンコ遊技をユーザである遊技者に提供する装置である。パチンコ遊技機700は、カードユニット600からの球貸操作信号を受けて、所定額相当の遊技球を払出す。そして、遊技者によるパチンコ遊技機700に設けられた発射ハンドルの操作に応じて、払出された遊技球が遊技領域に発射されることによって、パチンコ遊技が行なわれる。
店舗サーバ800は、遊技場30内のLAN(Local Area Network)を介して、券売機300およびカードユニット600と通信することが可能である。店舗サーバ800は、専用線または公衆回線を介して、電子マネー管理サーバ200と通信することが可能である。
店舗サーバ800は、券売機300におけるプリペイドカード371の販売に伴なう取引情報、および、カードユニット600におけるプリペイドカード371の使用に伴なう使用情報などの情報を、券売機300やカードユニット600から受けて、それらの情報を記憶する。
店舗サーバ800は、記憶した情報のうち、後述するバリューの使用に関する情報を電子マネー管理サーバ200に送信する。店舗サーバ800は、電子マネー管理サーバ200から電子マネー遊技使用サービスにおける不正に関する情報を受信する。
店舗サーバ800は、電子マネー管理サーバ200から受信した情報を、必要に応じて、券売機300やカードユニット600に送信する。
なお、決済サーバ280は、電子マネー管理サーバ200に含まれるように構成されてもよい。また、初期登録時AP211、バリュー購入時AP212、バリュー発行時AP213、残高管理AP214、バリュー預かりAP215、バリュー返却AP216、特典付与AP217、特典通知AP、利用者情報DB221、発行情報DB222、および、特典DB223の構成は、それぞれ、電子マネー管理サーバ200と異なるコンピュータに含まれるようにしてもよい。また、たとえば、携帯電話100のウェブ処理時に情報をやり取りするサーバと、携帯電話100の電子マネーアプリ111の処理時にやり取りするサーバとが、それぞれ別のコンピュータで構成されるようにしてもよい。
図2は、本発明に係る携帯電話100の構成の一例を示すブロック図である。図2を参照して、携帯電話100は、データ処理部110と、記憶部120と、データ入力部130と、表示部140と、音声入出力部150と、無線通信部160と、アンテナ161と、前述した非接触型ICチップ190とを含む。
非接触型ICチップ190は、制御部191と、記憶部192と、非接触通信部193と、アンテナ194とを含む。
記憶部120は、ROM(Read Only Memory)やフラッシュメモリなどの不揮発性メモリやRAM(Random Access Memory)などの揮発性メモリなどの半導体メモリで構成される。記憶部120は、携帯電話100の各種機能をデータ処理部110に実行させるためのプログラムやデータを記憶する。また、記憶部120は、携帯電話100を識別するための携帯端末情報である携帯IDを予め記憶する。また、記憶部120は、非接触型ICチップ190を利用する各種サービスにおけるアプリケーションプログラム、本実施の形態においては、電子マネー管理サーバ200から受信した本電子マネーサービスを享受するための処理手段が示された特定プログラムとしての電子マネーアプリ111を記憶する。また、記憶部120には、電子マネー(バリュー)の処理状況が記憶されて管理されるとともに、該処理状況は、電子マネーアプリ111の処理手順に従って、データ処理部110により更新される。
データ入力部130は、電話番号や各種データなどの数字やアルファベットやその他の文字などを入力するためのダイヤルキーや十字操作キーやその他のファンクションキーで構成される。データ入力部130は、ユーザからデータの入力を受付けて、入力されたデータをデータ処理部110に受渡す。
表示部140は、液晶表示装置(Liquid Crystal Display、以下「LCD」という)で構成される。なお、表示部140は、EL(ElectroLuminescence)ディスプレイなど他の表示装置で構成されてもよい。表示部140は、データ処理部110から受けた文字データおよび画像データを表示する。
音声入出力部150は、マイクおよびスピーカで構成される。音声入出力部150は、外部から入力された音声を電気信号に変えて、データ処理部110に受渡し、データ処理部110からの電気信号を音声に変換して、外部に出力する。
無線通信部160は、他の携帯電話またはサーバからアンテナ161で受信した信号をデータ処理部110に受渡し、データ処理部110から他の携帯電話またはサーバへ送信する信号をアンテナ161から出力させる。
データ処理部110は、マイクロプロセッサ(Micro Processing Unit、以下「MPU」という)で構成される。データ処理部110は、非接触型ICチップ190の制御部191と通信することが可能である。データ処理部110は、記憶部120に記憶されたプログラムに従って、記憶部120、データ入力部130、無線通信部160、音声入出力部150、または、非接触型ICチップ190の制御部191から入力されたデータを処理して、記憶部120、表示部140、無線通信部160、音声入出力部150、または、非接触型ICチップ190の制御部191に出力する。
非接触型ICチップ190の記憶部192は、非接触型ICチップ190を利用する各種サービスで用いられるバリューなどの電子マネーやサービスポイントなどのデータ、および、アプリケーションプログラムで用いられるデータを記憶する。つまり、記憶部192は、本発明におけるデータとしての電子マネー(バリュー)を記憶する記憶手段を構成する。
非接触型ICチップ190の非接触通信部193は、アンテナ194を介して外部のチップリーダライタと通信する。本実施の形態においては、非接触通信部193は、券売機300に備えられたチップリーダライタ390およびカードユニット600に備えられたチップリーダライタ690と通信する。また、前述したように、外部のチップリーダライタからの電磁波による電磁誘導によって、非接触通信部193は、アンテナ194から電力を受け、非接触型ICチップ190の各部に電力を供給する。
非接触型ICチップ190の制御部191は、記憶部192に記憶されたプログラムに従って、記憶部192、非接触通信部193、または、データ処理部110から入力されたデータを処理して、記憶部192、非接触通信部193、または、データ処理部110に出力する。
なお、本実施の形態においては、携帯電話100は、音声入出力部150を含んでも含まなくてもよい。
図3は、本発明に係る電子マネー管理サーバ200の構成の一例を示すブロック図である。図3を参照して、電子マネー管理サーバ200は、データ処理部210と、記憶部220と、データ入力部230と、表示部240と、通信部260とを含む。
記憶部220は、ROMやフラッシュメモリなどの不揮発性メモリやRAMなどの揮発性メモリなどの半導体メモリ、および、ハードディスクなどの外部記憶装置で構成される。記憶部220には、電子マネー管理サーバ200の各種機能をデータ処理部210に実行させるためのプログラムやデータが記憶される。
本実施の形態においては、初期登録時AP211、バリュー購入時AP212、バリュー発行時AP213、残高管理AP214、バリュー預かりAP215、バリュー返却AP216、特典付与AP217、および、特典通知APが記憶部220に記憶される。また、前述した利用者情報DB221、発行情報DB222および特典DB223も、記憶部220に記憶される。
データ入力部230は、キーボードおよびマウスなどの入力装置で構成される。データ入力部230は、電子マネー管理サーバの管理者などのユーザからデータの入力を受付けて、入力されたデータをデータ処理部110に受渡す。
表示部240は、LCDで構成される。なお、表示部240は、CRT(Cathode Ray Tube)ディスプレイやEL(ElectroLuminescence)ディスプレイなど他の表示装置で構成されてもよい。表示部240は、データ処理部210から受けた文字データおよび画像データを表示する。
通信部260は、携帯電話100または他のサーバから、携帯電話インターネット網910または他のネットワークを介して受信したデータをデータ処理部210に受渡し、データ処理部210から携帯電話インターネット網910または他のネットワークを介して携帯電話100または他のサーバに送信するデータを出力する。
データ処理部210は、MPUで構成される。データ処理部210は、記憶部220に記憶されたプログラムに従って、記憶部220、データ入力部230、または、通信部260から入力されたデータを処理して、記憶部220、表示部240、または、通信部260に出力する。
なお、決済サーバ280、リモート発行サーバ400、金融機関サーバ500,500A、および、店舗サーバ800の構成は、図3で説明した電子マネー管理サーバ200の構成と同様である。
図4は、本実施の形態における電子マネー管理サーバ200が電子マネー遊技使用サービスを提供する際に用いる利用者情報データベース221を説明するための図である。
図4を参照して、利用者情報DB221では、会員IDおよび携帯端末情報に対応付けて、携帯電話100の電子メールアドレス、金融機関指定情報、金融機関の口座番号、金融機関のパスワード、未チャージ削除カウンタのカウント値、通常用であるかテスト用であるかの携帯電話100の種別、携帯電話100の1日購入限度額、携帯電話100の携帯上保持限度額、および、バリューに関する処理状況が記憶される。
会員IDは、電子マネー遊技使用サービスの会員を一意に識別するためのIDである。携帯端末情報は、携帯電話100を一意に識別するための情報である。携帯電話100の電子マネーアドレスは、携帯電話100に対して一意に設定される電子メールに用いられるアドレスである。
金融機関指定情報は、会員がバリューのチャージ額の決済に用いる金融機関に対して予め一意に付与される番号である。口座番号は、会員がバリューのチャージ額の決済に用いる金融機関の口座番号である。パスワードは、会員がバリューのチャージ額の決済に用いる金融機関の口座のパスワードである。このように、利用者情報DB221は、本発明の金融機関記憶手段の一例であって、チャージ額の決済に使用する金融機関としてユーザ(携帯端末100)から指定された金融機関を特定可能な金融機関指定情報を記憶するとともに、ユーザが当該金融機関に開設した口座を特定可能な口座特定情報としての口座番号およびパスワードを記憶する。なお、口座番号およびパスワードについては、金融機関として前記直接決済に対応する金融機関(第2金融機関)が指定された場合にのみ記憶される。未チャージ削除カウンタは、電子マネー遊技使用サービスに登録され、初期登録手数料の決済が終了していない回数を携帯端末100ごとに計数するためのカウンタである。
テスト用の携帯電話は、電子マネーシステム10における電子マネー遊技使用サービスが適正に提供されるか否かをテストするために用いられる携帯電話である。通常用の携帯電話は、一般ユーザが電子マネー遊技使用サービスを享受するために用いる携帯電話である。
1日購入限度額は、1日に購入できるバリューの限度額である。携帯上保持限度額は、携帯電話100にチャージできるバリューの限度額である。ここで、1日購入限度額および携帯上保持限度額は、電子マネー管理サーバ200において、設定変更できるようされており、具体的には、通常用携帯電話に対する上限額よりも、テスト用携帯電話に対する上限額のほうが高く設定される。また、電子マネー管理サーバ200においては、ユーザがバリューのチャージ額を選択する際の選択肢(表示金額リスト:図41、図42参照)についても、通常用携帯電話およびテスト用携帯電話それぞれに対して、上記設定された上限額に対応して設定変更できるようになっており、かかる設定された通常用携帯電話に対するチャージ額の選択肢とテスト用携帯電話に対するチャージ額の選択肢を管理している。
バリューに関する処理状況は、図5で後述する処理状況であるバリューの発行ごとの処理状況(発行状況)以外の処理状況であり、具体的には、図8で後述する初期登録時APにおける電子マネー遊技使用サービス用の記憶領域が確保するための情報を送信済であることを示す領域確保済、図23で後述するバリュー預かりAPにおけるバリューを預けて電子マネー遊技使用サービス用の記憶領域を削除するための情報を送信済であることを示す削除応答済、および、図25のバリュー返却APにおけるバリューの返却を受けるための情報を送信済であることを示す返却済のいずれかの状況を示す。
このため、電子マネー管理サーバ200は、会員IDまたは携帯端末情報に基づき、当該会員IDまたは当該携帯端末情報に対応する、電子メールアドレス、金融機関指定情報、未チャージ削除カウンタのカウント値、種別、1日購入限度額、携帯上保持限度額、および、バリューに関する処理状況を容易に検索することができる。
図4では、たとえば、携帯端末情報として「MN7RE」,「NO8SF」のそれぞれ携帯電話のユーザに対して、会員IDとして「1101」,「9999」が発行され、これらの会員IDおよび携帯端末情報に対応付けて、それぞれ、電子メールアドレスとして「mailto@jp」,「testyo@jp」、金融機関指定情報として所定の銀行の指定口座を特定するための「2409329」,「3510430」、口座番号として「1234567」,口座番号が記憶されていないことを示す「−」、パスワードとして「****」,パスワードが記憶されていないことを示す「−」、未チャージ削除カウンタのカウント値として「2」,「0」、携帯電話の種別として「通常用」,「テスト用」、1日購入限度額として「30000」円,「500000」円、携帯上保持限度額として「30000」円,「1000000」円、および、バリューに関する処理状況として「領域確保済」,「削除応答済」が記録されている。
図5は、本実施の形態における電子マネー管理サーバ200が電子マネー遊技使用サービスを提供する際に用いる発行情報データベース222を説明するための図である。
図5を参照して、発行情報DB222では、前述した会員IDおよび携帯端末情報に対応付けて、携帯電話100のバリュー残高、購入番号、購入金額、手数料、タイムスタンプ、バリュー購入記録(未チャージバリューを含む)、バリュー購入回数、当日積算額、チャージ累計額、取引合計額、取引店舗、および、店舗別取引額が記憶される。
バリュー残高は、携帯電話100の非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域に記憶されるバリューの残額である。購入番号は、それぞれのバリューの購入を識別するための番号である。購入金額は、購入するバリューの対価である。手数料は、電子マネー遊技使用サービスの会員が電子マネー遊技使用サービスの提供業者に支払うべきバリューの購入の際の手数料である。タイムスタンプは、バリューの購入のための処理が行なわれた時刻を示す情報である。バリュー購入記録は、会員IDごとの未チャージバリューなどの購入に関する情報の記録である。バリュー購入回数は、その会員が会員となってからバリューを購入した回数である。当日積算額は、その当日にその会員によって購入されたバリューの積算額である。チャージ累計額は、その会員が現在までに購入したバリューの累計額である。取引合計額は、ユーザがバリューを用いて取引をした合計額である。取引店舗は、ユーザがバリューを用いた店舗である。店舗別取引額は、ユーザがバリューを用いて取引をした店舗別の取引額である。
このため、電子マネー管理サーバ200は、会員IDまたは携帯端末情報に基づき、当該会員IDまたは当該携帯端末情報に対応する、バリュー残高、購入番号、購入金額、手数料、タイムスタンプ、バリュー購入記録、バリュー購入回数、当日積算額、チャージ累計額、取引合計額、取引店舗、および、店舗別取引額を容易に検索することができる。なお、バリュー購入記録としては、バリューの額、および、バリューを発行済であるか未発行であるかを示す処理状況を含む。
図5では、たとえば、会員ID「1101」および携帯端末情報「MN7RE」に対応付けて、バリュー残高として「11000」円、バリュー購入回数として「28」回目、当日積算額として「6000」円、チャージ累計額として「24000」円、および、取引合計額として「23000」円が記憶されている。
また、前述した会員ID「1101」および携帯端末情報「MN7RE」に対応付けて、購入番号として「90010801」,「90005587」が記憶されている。本実施の形態においては、バリュー購入が行なわれるごとに、会員IDおよび携帯端末情報に対応付けて、購入番号が記憶される。
購入番号として「90010801」,「90005587」のそれぞれに対応して、購入金額として「1000」円,「5000」円、手数料として「200」円,「200」円、タイムスタンプとして「20050428153457」,「20050417071134」、バリューの額として「1000」円,「5000」円、および、処理状況として当該バリューが発行済である旨の「発行済」,当該バリューが発行済でない旨の「未発行」が記憶されている。つまり、未チャージバリューとは、処理状況が「未発行」であるバリューである。このように、発行情報DB222には、購入番号に対応する購入履歴が記憶される。
また、前述した会員ID「1101」および携帯端末情報「MN7RE」に対応付けて、取引店舗として、「A」,「B」,「C」が記憶されている。
取引店舗として「A」,「B」,「C」のそれぞれに対応して、その取引店舗における店舗別取引額として「21000」円,「1000」円,「1000」円が記憶されている。具体的には、本実施例においては、各店舗の店舗サーバ800から取引(球貸しやカード発行)に使用された携帯電話100の会員ID、携帯端末情報および取引額、ならびに、当該店舗を識別する店舗識別情報を含む取引情報を受信したことに基づいて、発行情報DB222において前記会員IDに対応付けて前記店舗識別情報の店舗が記憶されているか否かを判定し、記憶されていれば、それに対応する取引額に取引情報に含まれる取引額を加算する一方、前記店舗が記憶されていなければ、当該店舗を新たに記憶するとともに、取引情報に含まれる取引額を対応付けて記憶する。つまり、電子マネー管理サーバ200は、各携帯電話100ごとの取引額を各店舗ごとに集計して管理する。
以上、本実施の形態における電子マネー管理サーバ200のデータベースとして、利用者情報DB221と発行情報DB222とからなる構成について説明した。しかし、これに限らず、1つのデータベースで構成されるものであってもよい。たとえば、会員IDおよび携帯端末情報に対応付けて、当該会員IDまたは当該携帯端末情報に対応する各種情報を記憶するように構成するものであってもよい。
以上のように、電子マネー管理サーバ200は、利用者情報DB221において、各携帯電話100を個々に識別可能な(携帯端末)識別情報(会員ID、携帯端末情報)に対応付けて、当該携帯電話100の所有者が電子マネーのチャージの対価の決済用処理に利用する金融機関を特定するための金融機関指定情報と、該携帯電話100の記憶部192に本電子マネー遊技使用サービス用の記憶領域を構築した回数を示す未チャージ削除カウンタと、該携帯電話100が通常用携帯電話およびテスト用携帯電話のいずれであるかを示す種別と、該携帯電話100の種別に対応した1日購入限度額および携帯上保持限度額とを記憶・管理している。
また、電子マネー管理サーバ200は、図5の発行情報DB222において、各携帯電話100を個々に識別可能な(携帯端末)識別情報(会員ID、携帯端末情報)に対応付けて、該携帯電話100に対してチャージ可能となった電子マネーの額および当該電子マネーが発行済か否かを示す処理状況(発行状況)を含むバリュー購入記録と、当日(所定期間)においてチャージを許容された電子マネーの累計額である当日積算額とを記憶・管理している。
図6は、本発明に係る券売機300の構成の一例を示すブロック図である。図6を参照して、券売機300は、データ処理部310と、記憶部320と、操作部330と、表示部340と、通信部360と、カードリーダライタ370と、貨幣処理機380と、チップリーダライタ390とを含む。
チップリーダライタ390は、制御部391と、記憶部392と、非接触通信部393と、アンテナ394とを含む。
記憶部320は、ROMやフラッシュメモリなどの不揮発性メモリおよびRAMなどの揮発性メモリなどの半導体メモリで構成される。記憶部320には、券売機300の各種機能をデータ処理部310に実行させるためのプログラムおよびデータが記憶される。
操作部330は、購入するプリペイドカードの金額を選択するための金額ボタンを含む。また、金額ボタンは、選択されたときに、ランプが点灯するように構成される。操作部330は、ユーザからの操作を受付けて、受付けられた操作を示す信号をデータ処理部310に受渡す。
表示部340は、LCDで構成される。なお、表示部340は、ELディスプレイなど他の表示装置で構成されてもよい。表示部340は、データ処理部310から受けた文字データおよび画像データを表示する。
通信部360は、店舗サーバ800から、遊技場30のLANを介して受信したデータを、データ処理部310に受渡し、データ処理部310から遊技場30内のLANを介して店舗サーバ800に送信するデータを出力する。
カードリーダライタ370は、プリペイドカード371からデータを読出して、読出したデータをデータ処理部310へ受渡し、データ処理部310から受けたデータをプリペイドカード371に記録して、プリペイドカード371を発券する。
貨幣処理機380は、コインおよび紙幣の現金を受入れて、受入れられた現金の額を示すデータをデータ処理部310へ受渡す。また、貨幣処理機380は、データ処理部310から受けたデータで示される額の現金を外部へ返却する。
データ処理部310は、MPUで構成される。データ処理部310は、チップリーダライタ390の制御部391と通信することが可能である。データ処理部310は、記憶部320に記憶されたプログラムに従って、記憶部320、操作部330、通信部360、カードリーダライタ370、貨幣処理機380、または、チップリーダライタ390の制御部391から入力されたデータを処理して、記憶部320、表示部340、通信部360、カードリーダライタ370、貨幣処理機380、または、チップリーダライタ390の制御部391に出力する。
チップリーダライタ390の記憶部392は、非接触型ICチップ190を利用する各種サービスにおいて非接触型ICチップ190とやり取りするためのアプリケーションプログラム、および、それらのアプリケーションプログラムで用いられるデータを記憶する。
チップリーダライタ390の非接触通信部393は、アンテナ394を介して携帯電話100の非接触型ICチップ190と通信する。また、前述したように、非接触通信部393からの搬送波である電磁波による電磁誘導によって、非接触通信部393は、アンテナ394を介して、非接触型ICチップ190に電力を供給する。
チップリーダライタ390の制御部391は、記憶部392に記憶されたプログラムに従って、記憶部392、非接触通信部393、または、データ処理部310から入力されたデータを処理して、記憶部392、非接触通信部393、または、データ処理部310に出力する。
図7は、本発明に係るカードユニット600の構成の一例を示すブロック図である。図7を参照して、カードユニット600は、データ処理部610と、記憶部620と、表示部640と、通信部660と、カードリーダライタ670と、貨幣処理機680と、チップリーダライタ690とを含む。また、カードユニット600に信号を入力する操作部として、パチンコ遊技機700に設けられる球貸ボタン631および返却ボタン632がある。
チップリーダライタ690は、制御部691と、記憶部692と、非接触通信部693と、アンテナ694とを含む。
記憶部620は、ROMやフラッシュメモリなどの不揮発性メモリおよびRAMなどの揮発性メモリなどの半導体メモリで構成される。記憶部620には、カードユニット600の各種機能をデータ処理部610に実行させるためのプログラムおよびデータが記憶される。
球貸ボタン631は、遊技者により押下操作されることによって、遊技球の貸出を要求する球貸操作信号をデータ処理部610に出力する。返却ボタン632は、遊技者により押下操作されることによって、プリペイドカード371の返却を要求する返却操作信号をデータ処理部610に出力する。
表示部640は、LCDで構成される。なお、表示部640は、ELディスプレイなど他の表示装置で構成されてもよい。表示部640は、データ処理部610から受けた文字データおよび画像データを表示する。
通信部660は、店舗サーバ800から、遊技場30のLANを介して受信したデータを、データ処理部610に受渡し、データ処理部610から遊技場30内のLANを介して店舗サーバ800に送信するデータを出力する。
カードリーダライタ670は、プリペイドカード371からデータを読出して、読出したデータをデータ処理部610へ受渡し、データ処理部610から受けたデータをプリペイドカード371に記録する。また、カードリーダライタ670は、返却ボタン632からデータ処理部610を介して受けた返却操作信号に応じて、プリペイドカード371を外部へ排出する。
貨幣処理機680は、コインおよび紙幣の現金を受入れて、受入れられた現金の額を示すデータをデータ処理部610へ受渡す。また、貨幣処理機680は、データ処理部610から受けたデータで示される額の現金を外部へ返却する。
データ処理部610は、MPUで構成される。データ処理部610は、チップリーダライタ690の制御部691と通信することが可能である。データ処理部610は、記憶部620に記憶されたプログラムに従って、記憶部620、球貸ボタン631、返却ボタン632、通信部660、カードリーダライタ670、貨幣処理機680、または、チップリーダライタ690の制御部691から入力されたデータを処理して、記憶部620、表示部640、通信部660、カードリーダライタ670、貨幣処理機680、または、チップリーダライタ690の制御部691に出力する。
チップリーダライタ690の記憶部692は、非接触型ICチップ190を利用する各種サービスにおいて非接触型ICチップ190とやり取りするためのアプリケーションプログラム、および、それらのアプリケーションプログラムで用いられるデータを記憶する。
チップリーダライタ690の制御部691は、記憶部692に記憶されたプログラムに従って、記憶部692、非接触通信部693、または、データ処理部610から入力されたデータを処理して、記憶部692、非接触通信部693、または、データ処理部610に出力する。
(電子マネーシステム10への携帯電話100の初期登録の説明)
図32は、本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話100の表示部140に表示される第1の表示画面図である。図32(a)は、携帯電話100において、ウェブブラウザ機能が実行されるときに、携帯電話100の表示部140に、最初に表示されるウェブページの画面である。
図32(a)の画面は、「メニュー」画面である。図32(a)の画面には、他のウェブページへのリンクとして、「マイメニュー」「週間ガイド」「メニューリスト」「とくするメニュー」「エリア」「かんたん検索」が表示される。ここでは、「メニューリスト」が選択候補として反転表示されている。選択候補は、十字操作キーで切替えることができる。
また、図32(a)以降の画面でも共通する表示として、画面の下部の「戻る」「選択」「メニュー」の表示がある。データ入力部130の左、中、右のファンクションキーを操作することによって、それぞれ「戻る」「選択」「メニュー」の機能を実行することができる。
「戻る」の機能を実行させると、1つ前のウェブページの画面が表示される。「選択」の機能を実行させると、十字操作キーの操作によって反転表示された選択候補のリンク先のウェブページの画面が表示される。「メニュー」の機能を実行させると、図32(a)で説明した「メニュー」画面が表示される。
図32(a)の画面で、「メニューリスト」のリンクが選択されると、図32(b)の画面が表示される。
図32(b)の画面は、「メニューリスト」画面である。図32(b)の画面には、他のウェブページへのリンクとして、「天気/ニュース/情報」「モバイルバンキング」「趣味」その他のリンクが表示される。ここでは、「趣味」のリンクが選択候補として反転表示されている。
図32(b)の画面で、「趣味」のリンクが選択されると、図32(c)の画面が表示される。
図32(c)の画面には、他のウェブページへのリンクとして、「パチンコ/パチスロ」「電子マネー」「→全23サイト」その他のリンクが表示される。ここでは、「電子マネー」のリンクが選択候補として反転表示されている。
図32(c)の画面で、「→全23サイト」のリンクが選択されると、他のサイトへのリンクがさらに表示される。図32(c)の画面で、「電子マネー」のリンクが選択されると、携帯電話100から電子マネー管理サーバ200に、「電子マネー」のリンクにアクセスされた旨が送信される。
図8は、本実施の形態における電子マネー管理サーバ200により実行される初期登録時アプリケーションプログラム211の処理の流れを示すフローチャートである。図8を参照して、まず、ステップS201で、電子マネー管理サーバ200のデータ処理部210は、図32(c)の画面で、「電子マネー」のURL(Uniform Resource Locator)にアクセスがあったか否かを判断する。
アクセスがあったと判断した場合(ステップS201でYESの場合)、ステップS202で、データ処理部210は、携帯電話100に、電子マネー遊技使用サービスへの登録のためのトップページの画面を送信する。なお、本実施の形態において、「画面を送信する」とは、画面を表示するためのデータを送信することである。アクセスがないと判断した場合(ステップS201でNOの場合)、および、ステップS202の後、データ処理部210は、ステップS203に処理を進める。
図32に進んで、図32(d)の画面は、電子マネー遊技使用サービスへの携帯電話100の登録のためのトップページの画面である。図32(d)の画面には、電子マネー遊技使用サービスへの登録の案内の文章のほか、他のウェブページへのリンクとして、電子マネー遊技使用サービスの概要のウェブページへのリンクである「電子マネーとは?」、お気に入りのウェブページをユーザ専用のメニューに登録するためのリンクである「マイメニュー登録」、電子マネー遊技使用サービスの更新履歴のウェブページへのリンクである「What’sNew!」、電子マネー遊技使用サービスへの新規会員登録のウェブページへのリンクである「新規会員登録はこちら!」、その他のリンクが表示される。ここでは、「新規会員登録はこちら!」が選択候補として反転表示されている。
図10は、本実施の形態における携帯電話100のウェブブラウザ機能により実行されるウェブ処理の流れを示すフローチャートである。図10(a)はウェブ処理のうち初期登録時ウェブ処理の流れを示すフローチャートである。図10(a)を参照して、まず、ステップS101で、携帯電話100のデータ処理部110は、図32(d)の画面で、「新規会員登録はこちら!」のリンクが選択されたことによって、登録要求があったか否かを判断する。登録要求があったと判断すると(ステップS101でYESの場合)、ステップS102で、データ処理部110は、電子マネー管理サーバ200に、携帯電話100の機種情報を含む登録要求情報を送信する。
図8に戻って、ステップS203では、データ処理部210は、携帯電話100から機種情報を含む登録要求情報が送信されてきたか否かを判断する。登録要求情報が送信されてきていないと判断した場合(ステップS203でNOの場合)、データ処理部210は、実行する処理をステップS207に進める。一方、登録要求情報が送信されてきたと判断した場合(ステップS203でYESの場合)、ステップS204で、データ処理部210は、送信されてきた登録要求情報に含まれる機種情報が電子マネーシステム10に対応した機種を示すか否かを判断する。
携帯電話100が電子マネーシステム対応機種であると判断した場合(ステップS204でYESの場合)、ステップS205で、データ処理部210は、メール送信用画面を携帯電話100に送信する。その後、データ処理部210は、実行する処理をステップS207に進める。一方、携帯電話100が電子マネーシステム対応機種でないと判断した場合(ステップS204でNOの場合)、ステップS206で、データ処理部210は、非対応機種報知画面を携帯電話100に送信する。その後、データ処理部210は、実行する処理をステップS201に戻す。
図33は、本実施の形態における電子マネーシステム10に携帯電話100を初期登録するときに携帯電話100の表示部140に表示される第2の表示画面図である。図33(a)は、ステップS206で携帯電話100に送信される非対応機種報知画面である。
図33(a)の画面には、携帯電話100が電子マネーシステム10の対応機種でない旨の文章、電子マネー対応機種一覧へのリンクである「電子マネー対応携帯機種」、および、図32(d)で示したこのサイトのトップページへのリンクである「このサイトのトップへ」が表示される。
図33(b)は、ステップS205で携帯電話100に送信されるメール送信用画面である。図33(b)の画面には、電子マネー遊技使用サービスへの登録にあたっての注意書き、メール送信画面を表示するためのリンクである「ここをクリック!(空メール送信画面へ)」、および、図32(d)で示したこのサイトのトップページへのリンクである「このサイトのトップへ」が表示される。図33(b)の画面で、「ここをクリック!(空メール送信画面へ)」のリンクが選択されると、携帯電話100の電子メール機能が起動され、図33(c)のメール送信画面が表示される。
図33(c)のメール送信画面の宛先には、電子マネー遊技使用サービスへ登録するための電子メールアドレスが既に入力された状態でメール送信画面が表示される。また、メール送信画面の題名および本文には何も入力されていない。
図10(a)に戻って、ステップS103で、データ処理部110は、ユーザによって、図33(c)のメール送信画面のメールの送信操作が行なわれたか否かを判断する。メール送信操作が行なわれたと判断した場合(ステップS103でYESの場合)、ステップS104で、データ処理部110は、図33(c)のメール送信画面のメールを電子マネー管理サーバ200に送信する。つまり、空メールを送信する。
図8に戻って、ステップS207で、データ処理部210は、ユーザの携帯電話100から空メールを受信したか否かを判断する。空メールを受信することによって、データ処理部210は、ユーザの携帯電話100の電子メールアドレスを知ることができる。
空メールを受信したと判断した場合(ステップS207でYESの場合)、ステップS208で、データ処理部210は、登録手続を継続するための登録URLを記載した電子メールを、ユーザの携帯電話100の電子メールアドレス宛に送信する。その後、データ処理部210は、実行する処理をステップS210に進める。一方、電子メールアドレスを受信していないと判断した場合(ステップS207でNOの場合)、データ処理部210は、実行する処理をステップS210に進める。
図34は、本実施の形態における電子マネーシステム10に携帯電話100を初期登録するときに携帯電話100の表示部140に表示される第3の表示画面図である。
図34(a)は、携帯電話100の電子メール機能において、新着メッセージの件数を報知するための画面である。ここでは、「メール 未読001」の表示によって、新着の電子メールのうち、未読のものが1件であることが示されている。
図34(a)の画面で、「メール 未読001」が選択されると、図34(b)のように、ステップS208で、電子マネー管理サーバ200から携帯電話100に送信された新着メールの内容が表示される。
図34(b)の電子メールには、登録手続を継続するためのウェブページへの登録URLを選択して電子マネー遊技使用サービスへの登録手続を継続する旨の文章、および、登録URLが記載されたリンクが表示される。
図10(a)に戻って、ステップS105で、データ処理部110は、図34(b)の画面で、登録URLのリンクが選択されたか否かを判断する。登録URLのリンクが選択されたと判断すると(ステップS105でYESの場合)、ステップS106で、データ処理部110は、登録URLにアクセスするとともに、携帯電話100の機種情報を電子マネー管理サーバ200に送信する。
図8に戻って、ステップS210で、データ処理部210は、携帯電話100から登録URLにアクセスがあるとともに携帯電話100の機種情報を受信したか否かを判断する。登録URLにアクセスがあり機種情報を受信した場合(ステップS210でYESの場合)、ステップS211で、データ処理部210は、送信されてきた機種情報が電子マネーシステム10に対応した機種を示すか否かを判断する。
図34に進んで、図34(c)は、ステップS213で携帯電話100に送信される非対応機種報知画面である。図34(c)の画面は、図33(a)の画面と同様であるので、説明は繰返さない。
図34(d)は、ステップS212で携帯電話100に送信される利用同意画面である。図34(d)の画面には、電子マネー遊技使用サービスへの登録にあたっての注意書き、サービス規約のウェブページへのリンクである「サービス規約を読み(必須)」、および、サービス規約に同意し登録手続を先に進めるためのリンクである「同意して登録する」が表示される。ここでは、「同意して登録する」が選択候補として反転表示されている。
図10(a)に戻って、ステップS107で、データ処理部110は、ユーザによって、図34(d)の画面で、「同意して登録する」のリンクが選択されたか否かを判断する。「同意して登録する」のリンクが選択されたと判断した場合(ステップS107でYESの場合)、ステップS108で、データ処理部110は、携帯電話100を一意に識別するための携帯端末情報(以下「携帯ID」ともいう)を電子マネー管理サーバ200に送信する。
図8に戻って、ステップS214で、データ処理部210は、携帯電話100から携帯端末情報が送信されてきたか否かを判断する。携帯端末情報が送信されてきていないと判断した場合(ステップS214でNOの場合)、データ処理部210は、実行する処理をステップS221に進める。
一方、携帯端末情報が送信されてきたと判断した場合(ステップS214でYESの場合)、ステップS215で、データ処理部210は、図4の利用者情報DB221の携帯端末情報および会員IDを参照することによって、受信した携帯端末情報が利用者情報DB221に登録されたことがあるか否かを判断する。受信した携帯端末情報の登録履歴があると判断した場合(ステップS215でYESの場合)、ステップS216で、データ処理部210は、図4の利用者情報DB221の携帯端末情報および未チャージ削除カウンタを参照することによって、受信した携帯端末情報で示される携帯電話100に対応する未チャージ削除カウンタのカウント値が3以上であるか否かを判断する。
未チャージ削除カウンタのカウント値が3以上である場合(ステップS216でYESの場合)、ステップS217で、データ処理部210は、登録回数オーバ画面を携帯電話100に送信する。その後、データ処理部210は、実行する処理をステップS201に戻す。つまり、この場合には、携帯電話100の記憶部192に電子マネー遊技使用サービス用の記憶領域を構築するための領域確保情報(S236参照)の出力が禁止される。
図35は、本実施の形態における電子マネーシステム10に携帯電話100を初期登録するときに携帯電話100の表示部140に表示される第4の表示画面図である。図35(a)は、ステップS217で携帯電話100に送信される登録回数オーバ画面である。
図35(a)の画面には、登録回数が制限を越えている旨の文章、および、図32(d)で示したこのサイトのトップページへのリンクである「このサイトのトップへ」が表示される。
図8に戻って、受信した携帯端末情報の登録履歴がないと判断した場合(ステップS215でNOの場合)、または、未チャージ削除カウンタのカウント値が3未満である場合(ステップS216でNOの場合)、ステップS218で、データ処理部210は、受信した携帯端末情報を利用者情報DB221に登録する。次に、ステップS219で、データ処理部210は、金融機関を選択するウェブページの最初の画面である金融機関選択画面を携帯電話100に送信する。その後、データ処理部210は、実行する処理をステップS221に進める。
図35に進んで、図35(b)の画面は、ステップS219で携帯電話100に送信される金融機関登録トップ画面である。図35(b)の画面には、電子マネー遊技使用サービスにおけるバリューの利用の方法を示す文章、金融機関の登録を促がす旨の文章、金融機関の登録へ進むためのリンクである「ここから」、および、金融機関の登録をスキップするためのリンクである「金融機関登録をスキップする方はこちらを選択してください」が表示される。
図10(a)に戻って、ステップS109で、データ処理部110は、図35(b)の画面で、「ここから」の金融機関問合せリンクが選択されたか否か、図35(c)の画面で、いずれかの業態の金融機関問合せリンクが選択されたか否か、または、図35(d)の画面で、いずれかの金融機関問合せリンクが選択されたか否かを判断する。
金融機関問合せリンクが選択されたと判断すると(ステップS109でYESの場合)、ステップS110で、データ処理部110は、それぞれのリンクに対応する金融機関問合せ情報を電子マネー管理サーバ200に送信する。
図8に戻って、ステップS221で、データ処理部210は、携帯電話100から金融機関問合せ情報を受信したか否かを判断する。金融機関問合せ情報を受信したと判断した場合(ステップS221でYESの場合)、ステップS222で、データ処理部210は、金融機関問合せ情報に対応する画面を携帯電話100に送信する。
図35に進んで、図35(c)の画面は、図35(b)の画面の「ここから」のリンクの選択によって送信される金融機関問合せ情報に対応する第1の金融機関選択画面である。図35(c)の画面には、金融機関の業態の選択を促がす旨の文章、都市銀行を選択するためのリンクである「都市銀行」、地方銀行を選択するためのリンクである「地方銀行」、第2地方銀行を選択するためのリンクである「第2地銀」、労働金庫を選択するためのリンクである「労働金庫」、信用金庫を選択するためのリンクである「信用金庫」、信用組合を選択するためのリンクである「信用組合」、および、その他の金融機関を選択するためのリンクである「その他」が表示される。ここでは、図35(c)の画面で「都市銀行」のリンクが選択される場合について説明する。
図35(d)の画面は、図35(c)の画面の「都市銀行」のリンクの選択によって送信される金融機関問合せ情報に対応する第2の金融機関選択画面である。図35(d)の画面には、利用する金融機関の選択を促がす旨の文章、および、都市銀行のうちのいずれかを選択するためのリンクである「やまと銀行」「三友銀行」「ダイヤモンド銀行」「りえぞん銀行」が表示される。ここでは、図35(d)の画面で「やまと銀行」のリンクが選択される場合について説明する。
図9は、本実施の形態における電子マネー管理サーバ200で金融機関が直接決済対応か間接決済対応かを設定するための金融機関設定画面である。図9を参照して、金融機関設定画面には、直接決済および間接決済のいずれにも対応する金融機関の名称を入力するための「直接・間接決済対応」入力欄、間接決済に対応する金融機関の名称を入力するための「間接決済のみ対応」入力欄、直接決済に対応する金融機関の名称を入力するための「直接決済のみ対応」入力欄、各入力欄に入力されている金融機関の名称を他の入力欄に移動させるための移動ボタン、および、設定を終了するための「終了」ボタンが表示される。
図9の金融機関設定画面では、たとえば、「直接・間接決済対応」入力欄に「やまと銀行」、「間接決済のみに対応」入力欄に「ダイヤモンド銀行」,「りえぞん銀行」、「直接決済のみに対応」入力欄に「三友銀行」が入力されている。
そして、各入力欄に金融機関が入力された後に、終了ボタンが操作されると、各金融機関の金融機関名および金融機関指定情報に対応付けて、当該金融機関が直接決済および間接決済のいずれにも対応する金融機関であるか、直接決済のみに対応する金融機関であるか、間接決済にのみ対応する金融機関であるかを示す種別が記憶されて、設定される。つまり、図9に示す金融機関設定画面により、本発明の金融機関設定手段が構成されている。
電子マネー管理サーバ200のデータ処理部210は、携帯電話100から図35(d)の画面での金融機関の選択結果を示す情報を受信し、受信した情報で示される金融機関が、図9の金融機関設定画面で直接決済および間接決済のいずれにも対応する金融機関、直接決済のみに対応する金融機関、および、間接決済にのみ対応する金融機関のいずれと設定されたかを判断し、判断結果に応じて、それぞれ、後述の図36(a)、図36(b)および図37(a)のいずれかの画面を携帯電話100に送信する。
図36は、本実施の形態における電子マネーシステム10に携帯電話100を初期登録するときに携帯電話100の表示部140に表示される第5の表示画面図である。
図35(d)の画面で選択された金融機関が直接決済および間接決済のいずれにも対応している場合には、図36(a)の画面が表示される。図36(a)の画面は、図35(d)の画面の「やまと銀行」のリンクの選択によって送信される金融機関問合せ情報に対応する金融機関における決済方法を確認するための画面である。
図36(a)の画面には、選択された金融機関が直接決済と間接決済とを選択することが可能である旨の文章、「直接決済」または「間接決済」を選択するためのラジオボタン、および、ラジオボタンでの選択結果の送信を指示するためのリンクである「送信」が表示される。
図36(a)の画面で「直接決済」が選択された場合、および、図35(d)の画面で選択された金融機関が直接決済のみに対応する場合には、図36(b)の画面が表示される。
図36(b)の画面は、図35(d)および図36(a)で選択された直接決済に対応する金融機関を確認するための画面である。図36(b)の画面には、利用する金融機関としてやまと銀行、決済方法として直接決済を登録することを確認する旨の文章、登録することを確認して継続して手続を進めるためのリンクである「確認」、および、選択した金融機関を訂正するために前の画面に戻るためのリンクである「訂正する場合はこちらから」が表示される。
図36(b)の画面で「確認」のリンクが選択された場合、図36(c)の画面が表示される。図36(c)の画面は、図36(b)で確認された金融機関の口座番号およびその口座のパスワードの入力を求めるための画面である。図36(c)の画面には、口座番号およびパスワードの入力を促がす旨の文章、口座番号を入力するための口座番号入力欄、パスワードを入力するためのパスワード入力欄、および、入力した口座番号およびパスワードを電子マネー管理サーバ200に送信するためのリンクである「送信」が表示される。
図36(a)の画面で「間接決済」が選択された場合、および、図35(d)の画面で選択された金融機関が間接決済のみに対応する場合には、図37(a)の画面が表示される。
図37は、本実施の形態における電子マネーシステム10に携帯電話100を初期登録するときに携帯電話100の表示部140に表示される第6の表示画面図である。
図37(a)の画面は、図35(d)および図36(a)で選択された間接決済に対応する金融機関を確認するための画面である。図37(a)の画面には、利用する金融機関としてやまと銀行、決済方法として間接決済を登録することを確認する旨の文章、登録することを確認して継続して手続を進めるためのリンクである「確認」、および、選択した金融機関を訂正するために前の画面に戻るためのリンクである「訂正する場合はこちらから」が表示される。
図10(a)に戻って、ステップS111で、データ処理部110は、図36(c)の画面で「送信」のリンクが選択されたか否か、または、図37(a)の画面で「確認」のリンクが選択されたか否かを判断する。「送信」または「確認」のリンクが選択されたと判断すると(ステップS111でYESの場合)、ステップS112で、データ処理部110は、電子マネー管理サーバ200に、選択された金融機関を示す金融機関指定情報および前述した携帯端末情報を送信する。さらに、ステップS112で、データ処理部110は、選択された金融機関が直接決済に対応する金融機関であれば、図36(c)の画面で入力された口座番号およびパスワードを、電子マネー管理サーバ200に送信する。つまり、バリューのチャージに関する対価の決済のための決済用処理に利用する決済用処理機関としてユーザが指定した金融機関を特定するための金融機関指定情報、および、直接決済対応の金融機関の場合には口座番号およびパスワードが送信される。
図8に戻って、ステップS223で、データ処理部210は、携帯電話100から金融機関指定情報、および、直接決済対応の金融機関の場合には口座番号およびパスワードを受信したか否かを判断する。受信していないと判断した場合(ステップS223でNOの場合)、データ処理部210は、実行する処理をステップS226に進める。
一方、受信したと判断した場合(ステップS223でYESの場合)、データ処理部210は、ステップS224で、金融機関指定情報とともに受信した携帯端末情報と同一であって利用者情報DB221に仮登録された携帯端末情報に対応させて、受信した金融機関指定情報を利用者情報DB221に仮登録する。また、受信した口座番号およびパスワードを、ともに受信した携帯端末情報に対応させて利用者情報DB221に仮登録する。なお、当該金融機関指定情報から特定される金融機関に指定口座が存在するか否かを金融機関サーバ500,500Aに問合せ、存在する場合に仮登録するようにしてもよい。
以上のように、電子マネー管理サーバ200は、複数の金融機関のうちから、前記チャージ額の決済に使用する金融機関としてユーザから指定された金融機関を特定可能な金融機関指定情報をステップS223において受信することにより受付けており、当該ステップS223により、本発明の金融機関指定受付手段が構成されている。また、指定された金融機関が直接決済対応の金融機関(第2金融機関)である場合には、ユーザが当該金融機関に開設した口座を特定可能な口座特定情報としての口座番号およびパスワードを前記携帯電話100からステップS223において受信しており、当該ステップS223により、本発明の口座特定情報受付手段が構成されている。
そして、電子マネー管理サーバ200は、利用者情報DB221の登録内容に基づいて、各ユーザが指定した金融機関が間接決済対応の金融機関(第1金融機関)であるか直接決済対応の金融機関(第2金融機関)であるかを判定可能となっている。具体的には、利用者情報DB221において、金融機関指定情報のみが記憶されていれば、間接決済のみに対応する金融機関、または、直接決済および間接決済のいずれにも対応する金融機関であってユーザが間接決済を指定した金融機関であり、金融機関指定情報に加えて口座番号およびパスワードが記憶されていれば、直接決済のみに対応する金融機関、または、直接決済および間接決済のいずれにも対応する金融機関であってユーザが直接決済を指定した金融機関であると判定できる。
なお、直接決済および間接決済いずれにも対応する金融機関は存在せず、直接決済のみに対応する金融機関および間接決済のみに対応する金融機関のいずれかしか存在しない場合には、利用者情報DB221に記憶された金融機関指定情報に基づいて、各ユーザが指定した金融機関が間接決済対応の金融機関であるか直接決済対応の金融機関であるかを判定することも可能である。
具体的には、利用者情報DB221に記憶された金融機関指定情報と、図9の金融機関設定画面で設定され記憶された設定内容(金融機関指定情報と対応付けて間接決済対応の金融機関であるか直接決済対応の金融機関であるかが記憶されている)とに基づいて、各ユーザが指定した金融機関が、間接決済対応の金融機関であるか、直接決済対応の金融機関であるか、直接決済および間接決済のいずれにも対応する金融機関であるかを判定することも可能である。
次いで、ステップS225で、データ処理部210は、プロモーションメール受取可否設定画面を携帯電話100に送信する。その後、データ処理部210は、実行する処理をステップS226に進める。
図37に進んで、図37(b)は、ステップS225で携帯電話100に送信されるプロモーションメール受取可否設定画面である。図37(b)の画面には、電子マネーに関する最新情報等のお知らせメールであるプロモーションメールの受取を希望するか否かを確認する旨の文章、「希望する」または「希望しない」を選択するためのラジオボタン、ラジオボタンでの選択結果の送信を指示するためのリンクである「送信」、および、図32(d)で示したこのサイトのトップページへのリンクである「このサイトのトップへ」が表示される。
図10(a)に戻って、ステップS113で、データ処理部110は、図37(b)の画面で、「希望する」または「希望しない」のラジオボタンが選択され、「送信」のリンクが選択されることによって、プロモーションメールの受取可否が決定されたか否かを判断する。そして、ステップS114で、データ処理部110は、プロモーションメールの受取可否を示すプロモーション受取可否情報を電子マネー管理サーバ200に送信する。
図8に戻って、ステップS226で、データ処理部210は、携帯電話100からプロモーション受取可否情報を受信したか否かを判断する。プロモーション受取可否情報を受信していないと判断した場合(ステップS226でNOの場合)、データ処理部210は、実行する処理をステップS231に進める。一方、プロモーション受取可否情報を受信したと判断した場合(ステップS226でYESの場合)、ステップS227で、データ処理部210は、会員IDを発行し、その会員ID、ステップS207で受信したメールアドレス、ステップS224で仮登録された金融機関指定情報およびプロモーション受取可否情報を、プロモーション受取可否情報を送信した携帯電話100の携帯端末情報と対応させて仮登録する。なお、ステップS215でYESと判断された場合には、新たな会員IDを発行することなく、既に発行済みの会員IDを仮登録するようにしてもよい。次いで、ステップS228で、データ処理部210は、電子マネーアプリ111のダウンロードを確認する画面を携帯電話100に送信する。
図37に進んで、図37(c)は、ステップS228で携帯電話100に送信されるダウンロードを確認する画面である。図37(c)の画面には、バリューの利用方法の文章、電子マネーアプリ111のダウンロードを促がす旨の文章、ダウンロードの開始を指示するためのリンクである「ダウンロード開始」、および、電子マネーアプリ111のサイズを示す文章が表示される。
図10(a)に戻って、ステップS115で、データ処理部110は、図37(c)の画面で、「ダウンロード開始」が選択されることによって、電子マネーアプリ111のダウンロードが要求されたか否かを判断する。「ダウンロード開始」が選択されたと判断すると(ステップS115でYESの場合)、ステップS116で、データ処理部110は、電子マネーアプリ111のダウンロードを要求する旨の情報であるアプリダウンロード要求情報を電子マネー管理サーバ200に送信する。
図8に戻って、ステップS231で、データ処理部210は、携帯電話100からアプリダウンロード要求情報を受信したか否かを判断する。アプリダウンロード要求情報を受信したと判断した場合(ステップS231でYESの場合)、ステップS232で、電子マネーアプリ111を携帯電話100に送信する。
図37に進んで、携帯電話100で電子マネーアプリ111の受信が開始されると、図37(c)の画面は、図37(d)で示される状態になる。つまり、ダウンロード中である旨の表示が、図37(c)の画面上に表示される。
図10(a)に戻って、ステップS116aで、データ処理部110は、電子マネーアプリ111のダウンロードが終了したか否かを判断する。すなわち、電子マネーアプリ111が記憶部120に記憶されたか否かを判断する。ダウンロードが終了していないと判断した場合(ステップS116aでNOの場合)、データ処理部110は、ステップS116aの処理を繰返す。一方、ダウンロードが終了したと判断した場合(ステップS116aでYESの場合)、データ処理部110は、初期登録時ウェブ処理を終了する。
以上のように、本実施例においては、電子マネー遊技使用サービスを享受するための登録を要求する登録要求情報として、ステップS102の登録要求情報、ステップS108の携帯端末情報、ステップS116のアプリダウンロード要求情報等、複数の情報が送信されているが、初期登録に際して電子マネー管理サーバ200との間で送受信される情報は任意であり、少なくとも登録を要求する登録要求情報が1回送信されればよい。
電子マネーアプリ111のダウンロードが終了すると、携帯電話100のデータ処理部110は、記憶部120に記憶された電子マネーアプリ111を起動させる。
図38は、本実施の形態における電子マネーシステム10に携帯電話100を初期登録するときに携帯電話100の表示部140に表示される第7の表示画面図である。図38(a)は、電子マネーアプリ111の起動中に表示される画面である。図38(a)の画面には、起動中であるアプリの名称である「電子マネーアプリ」の文字、および、全起動プロセスのうちの経過したプロセスの割合の概略を示すグラフが表示される。
図11は、本実施の形態における携帯電話100で実行される電子マネーアプリ111の処理の流れを示すフローチャートである。図11を参照して、電子マネーアプリ111が起動されると、ステップS120で、データ処理部110は、電子マネーアプリ111がダウンロードされてから初回の起動であるか否かを判断する。初回起動でないと判断した場合(ステップS120でNOの場合)、データ処理部110は、実行する処理をステップS180に進める。一方、初回起動であると判断した場合(ステップS120でYESの場合)、ステップS1200で、データ処理部110は、初回起動処理を実行する。
図12は、本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンである初回起動処理の流れを示すフローチャートである。図12を参照して、まず、ステップS121で、データ処理部110は、携帯端末情報を電子マネー管理サーバ200に送信する。
図8に戻って、電子マネー管理サーバ200のデータ処理部210は、ステップS233で、携帯電話100から携帯端末情報を受信して、受信した携帯端末情報が仮登録されているか否かを判断する。携帯端末情報が仮登録されていないと判断した場合(ステップS233でNOの場合)、データ処理部210は、実行する処理をステップS201に戻す。
一方、携帯端末情報が仮登録されていると判断した場合(ステップS233でYESの場合)、データ処理部210は、ステップS234で、その携帯端末情報と対応させて仮登録された会員ID、メールアドレス、金融機関指定情報、口座番号、パスワードおよびプロモーション受取可否情報を、その携帯端末情報と対応させて、利用者情報DB221に本登録させる。そして、ステップS235で、データ処理部210は、本登録した携帯端末100に対応する未チャージ削除カウンタのカウント値を1加算する。なお、加算された未チャージ削除カウンタは、会員から脱退した場合(電子マネー遊技使用サービス用の記憶領域を削除した場合)であっても利用者情報DB221において保持される。
このようにステップS235において未チャージ削除カウンタが加算されることにより、ステップS236において送信される領域確保情報(領域構築情報)に対応する電子マネー遊技使用サービス用の記憶領域が携帯電話100の非接触型ICチップ190の記憶部192に構築された構築回数が管理される。
次に、ステップS236で、データ処理部210は、電子マネー遊技使用サービス用の記憶領域を携帯電話100の記憶部192に確保(構築)させるための情報である領域確保情報(領域構築情報)を携帯電話100に送信する。
なお、ステップS234で説明したように、本実施の形態においては、携帯電話100を他の携帯電話と識別可能にするための識別情報として、携帯端末情報である場合を一例に説明するが、これに限らず、識別情報としては、会員ID等、携帯電話100を他の携帯電話と識別可能な情報であればよい。たとえば、ステップS234においては、会員IDに対応付けて金融機関指定情報等を登録し、以後携帯電話から送信されてくる会員IDに基づき、当該携帯電話を識別し金融機関指定情報等を読出すようにしてもよい。この場合、会員IDは、ステップS234において本登録された後に、携帯電話100側に送信し記憶させるようにしてもよい。
図12に進んで、データ処理部110は、ステップS122で、電子マネー管理サーバ200から領域確保情報を受信したか否かを判断する。領域確保情報を受信していないと判断した場合(ステップS122でNOの場合)、データ処理部110は、ステップS122を繰返す。一方、領域確保情報を受信したと判断した場合(ステップS122でYESの場合)、ステップS122aで、データ処理部110は、記憶部120で記憶管理している携帯電話100におけるバリューに関する処理状況を、領域確保情報受信済に更新する。そして、ステップS122bで、データ処理部110は、領域確保情報を受信したことを電子マネー管理サーバ200に知らせるための受信応答情報を、電子マネー管理サーバ200に送信する。
図8に戻って、ステップS237で、データ処理部210は、携帯電話100から受信応答情報を受信したか否かを判断する。受信応答情報を受信していないと判断した場合(ステップS237においてNOの場合)、データ処理部210は、実行する処理をステップS201に戻す。一方、受信応答情報を受信したと判断した場合(ステップS237においてYESの場合)、ステップS238で、データ処理部210は、図4に示す利用者情報DB221の処理状況を領域確保済に更新する。その後、データ処理部210は、実行する処理をステップS201に戻す。
図12に進んで、次に、ステップS123で、データ処理部110は、電子マネー遊技使用サービス用の記憶領域を確保するための領域確保処理の開始を要求する領域確保処理開始要求(領域確保情報により示される電子マネー遊技使用サービス用の記憶領域の構築要求)を、リモート発行サーバ400に送信する。領域確保処理開始要求は、携帯端末情報を含む。
リモート発行サーバ400は、携帯電話100から領域確保処理開始要求を受けると、領域確保処理開始要求を送信してきた携帯電話100の非接触型ICチップ190に電子マネー遊技使用サービスに用いるための記憶部192の記憶領域を確保し、確保した記憶領域に会員IDを記憶させるための領域確保実行情報を、領域確保処理開始要求を送信してきた携帯電話100に送信する。
図12に戻って、携帯電話100のデータ処理部110は、ステップS124で、リモート発行サーバ400から領域確保実行情報を受信したか否かを判断する。領域確保実行情報を受信していないと判断した場合(ステップS124でNOの場合)、データ処理部110は、ステップS124を繰返す。
一方、領域確保実行情報を受信したと判断した場合(ステップS124でYESの場合)、データ処理部110は、ステップS125で、リモート発行サーバ400からの領域確保実行情報で示される領域確保処理を実行する。領域確保処理は、非接触型ICチップ190の記憶部192に電子マネー遊技使用サービス用の記憶領域を確保し、会員IDをリモート発行サーバ400に送信し、記憶部192の確保された記憶領域に0円相当のバリューを記憶させる処理である。
具体的には、この領域確保処理においては、リモート発行サーバ400は、電子マネーアプリ111を介して、非接触型ICチップ190の記憶部192に電子マネー遊技使用サービス用の記憶領域を確保する。携帯電話100は、電子マネーアプリ111によって、会員IDと書込みデータである0円相当のバリューとを、リモート発行サーバ400に送信する。リモート発行サーバ400は、電子マネーアプリ111を介さずに、非接触型ICチップ190と直接やり取りして、非接触型ICチップ190の記憶部192に、携帯電話100から受信した会員IDとバリューとを書込む。そして、記憶領域の確保および会員IDとバリューとの書込みが終了した場合、リモート発行サーバ400は、領域確保終了情報を携帯電話100に送信する。
なお、ここでは、リモート発行サーバ400は、電子マネーアプリ111を介して、記憶領域を確保するようにした。しかし、これに限定されず、リモート発行サーバ400は、電子マネーアプリ111を介さずに、直接、非接触型ICチップ190とやり取りして、記憶領域を確保するようにしてもよい。また、リモート発行サーバ400は、電子マネーアプリ111を介さずに、会員IDとバリューとを書込むようにした。しかし、これに限定されず、リモート発行サーバ400は、電子マネーアプリ111を介して、会員IDとバリューとを書込むようにしてもよい。
また、リモート発行サーバ400は、電子マネー遊技使用サービス用の記憶領域を確保して、その記憶領域に0円相当のバリューを書込んだことを条件として、ステップS123で携帯電話100から送信された領域確保処理開始要求に含まれる携帯端末情報と対応付けて、当該携帯端末情報の携帯電話100に対する処理状況を、領域確保処理が終了したことを示す領域確保終了済として記憶する。
次いで、データ処理部110は、ステップS126で、リモート発行サーバ400から領域確保終了情報を受信したことによって、領域確保処理が終了したか否かを判断する。領域確保処理が終了したと判断した場合(ステップS126でYESの場合)、ステップS127で、データ処理部110は、記憶部120で記憶している処理状況を、領域確保済に更新する。その後、データ処理部110は、実行する処理をこの処理の呼出元の処理である電子マネーアプリ111に戻す。
図11に戻って、ステップS1200の初回起動処理の実行後、データ処理部110は、実行する処理をステップS192に進める。
ステップS180では、データ処理部110は、電子マネーアプリ111の起動が非接触型ICチップ190からの起動であるか否かを判断する。図50で後述する券売機300による発券処理において券売機300の非接触型ICチップ390、または、図53で後述するカードユニット600による球貸処理においてカードユニット600の非接触型ICチップ690から、携帯電話100の非接触型ICチップ190へ、電子マネーアプリ111を起動させるためのアプリ起動信号が送信された場合、携帯電話100は、アプリ起動信号に応じて、電子マネーアプリ111を起動させる。アプリ起動信号については、図50で説明する。また、電子マネーアプリ111の起動が非接触型ICチップ190からの起動であると判断した場合(ステップS180でYESの場合)については、図50の説明とともに説明する。
一方、電子マネーアプリ111の起動が非接触型ICチップ190からの起動でないと判断した場合(ステップS180でNOの場合)、ステップS1100で、データ処理部110は、電子マネーアプリ111の起動が後述するエラー説明画面からの起動であるか否かを判断する。エラー説明画面からの起動であると判断した場合(ステップS1100でYESの場合)については後述する。
一方、電子マネーアプリ111の起動がエラー説明画面からの起動でないと判断した場合(ステップS1100でNOの場合)、ステップS1110で、データ処理部110は、電子マネーアプリ111の起動が後述するエラー対応完了メールからの起動であるか否かを判断する。エラー対応完了メールからの起動であると判断した場合(ステップS1110でYESの場合)については後述する。
一方、エラー対応完了メールからの起動でないと判断した場合(ステップS1110でNOの場合)、ステップS191で、データ処理部110は、後述する図17で説明する引継ぎ情報からの起動であるか否かを判断する。後述するように、バリューの購入後に引継ぎ情報が付された電子メールが携帯電話100に送信され、その引継ぎ情報によって、電子マネーアプリ111が起動され、購入されたバリューが携帯電話100にチャージされる。引継ぎ情報からの起動であると判断した場合(ステップS191でYESの場合)、データ処理部110は、実行する処理をステップS150に進める。
一方、引継ぎ情報からの起動でないと判断した場合(ステップS191でNOの場合)、ステップS191aで、データ処理部110は、後述する図27で説明する特典通知メールからの起動であるか否かを判断する。後述するように、特典を発行する基準に達した会員の携帯電話100に、特典発行要求情報を送信するためのリンクが付された特典通知メールが送信され、その特典発行要求情報が送信されることによって、特典としてのバリューである特典バリューが携帯電話100にチャージされる。特典通知メールからの起動であると判断した場合(ステップS191aでYESの場合)、データ処理部110は、実行する処理をステップS190に進める。
一方、特典通知メールからの起動でないと判断した場合(ステップS191aでNOの場合)、ステップS198で、データ処理部110は、処理状況確認処理を実行する。
図14は、本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンである処理状況確認処理の流れを示すフローチャートである。図14を参照して、ステップS1981で、データ処理部110は、記憶部120で管理されている処理状況が、図12の初回起動処理のステップS122aで更新される領域確保情報受信済であるか否かを判断する。
処理状況が領域確保情報受信済であると判断した場合(ステップS1981においてYESの場合)、データ処理部110は、実行する処理を図12の初回起動処理のステップS123に進める。これによって、データ処理部110は、ステップS122で領域確保情報を受信したが、ステップS123からステップS126までのリモート発行サーバ400とのやり取りにおいて、通信障害等により電子マネー遊技使用サービス用の記憶領域を確保できなかった場合、再度、ステップS121で携帯端末情報を電子マネー管理サーバ200に送信することなく、ステップS123で領域確保処理開始要求をリモート発行サーバ400に送信する。このため、電子マネー管理サーバ200ではステップS238で図4に示す利用者情報DB221の処理状況が領域確保済に更新されているにもかかわらず、再度、電子マネー遊技使用サービス用の記憶領域を確保するために携帯端末情報が携帯電話100から電子マネー管理サーバ200に送信され、電子マネー管理サーバ200側で管理している処理状況は領域確保済であるため、要求が受付けられずに領域の確保が行なえないという事態を防止することができる。
一方、処理状況が領域確保情報受信済でないと判断した場合(ステップS1981においてNOの場合)、データ処理部110は、実行する処理をステップS1982に進める。ステップS1982以降の処理については、後述する。
図11に戻って、ステップS198の処理状況確認処理の実行後、データ処理部110は、実行する処理をステップS192に進める。
ステップS192では、データ処理部110は、非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域からバリュー残高を取得して、電子マネーアプリ111の起動時初期画面を表示部140に表示させる。
図38に進んで、図38(b)は、ステップS192で表示される起動時初期画面である。図38(b)の画面には、非接触型ICチップ190の製造時から与えられているチップIDが00002000012398であること、ステップS192で取得された非接触型ICチップ190に記憶されているバリューの残高が0円であること、バリューを購入するためのリンクである「バリュー購入」、購入済みのバリューを非接触型ICチップ190にチャージするためのリンクである「ICチップへの購入バリューのチャージ」、機種変更時にバリューをサーバに預けるためのリンクである「バリュー預け」、機種変更後にサーバに預けたバリューの返却を受けるためのリンクである「預けバリュー返却」、および、特典バリューを非接触型ICチップ190にチャージするためのリンクである「ICチップへの特典バリューのチャージ」が表示される。
(電子マネーシステム10でのバリューの購入の説明)
図39は、本実施の形態における電子マネーシステム10において携帯電話100でバリューを購入するときに携帯電話100の表示部140に表示される第1の表示画面図である。
図39(a)は、携帯電話100において、アプリケーション実行機能が実行されるときに、携帯電話100の表示部140に、最初に表示されるソフト一覧画面である。図39(a)の画面には、携帯電話100に導入されているアプリケーションプログラムを実行させるためのリンクとして、「電子マネーアプリ」および「旅行ナビゲータ」が表示される。つまり、本実施の形態における携帯電話100には、電子マネーアプリ111、および、旅行ナビゲータという名称のアプリケーションプログラムが導入されていることが示される。
図11に戻って、図39(a)の画面で「電子マネーアプリ」のリンクが選択され、電子マネーアプリ111が起動されると、初回起動でなく(ステップS120でNOの場合)、ICチップからの起動でなく(ステップS180でNOの場合)、エラー説明画面からの起動でなく(ステップS1100でNOの場合)、エラー対応完了メールからの起動でなく(ステップS1110でNOの場合)、引継ぎ情報からの起動でない(ステップS191でNOの場合)ので、前述したステップS198の処理状況確認処理において処理状況が領域確保情報受信済でなく(ステップS1981においてNOの場合)、後述する処理状況確認処理のステップS1982からステップS1984においてもNOである場合、ステップS192で、データ処理部110は、非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の領域からバリュー残高を取得して、電子マネーアプリ111の起動時初期画面を表示させる。
図39に進んで、図39(b)の画面は、ステップS192で表示される起動時初期画面である。図39(b)の画面は、前述した図38(b)の画面と同様であるので、重複する説明は繰返さない。ただし、非接触型ICチップ190に記憶されているバリューの残高が、図38(b)の画面では、0円であるのに対して、図39(b)の画面では、1000円である。また、図39(b)の画面では、「バリュー購入」のリンクが選択候補として網掛け表示されている。
図11に戻って、ステップS193で、データ処理部110は、バリュー購入が選択されたか否かを判断する。図39(b)の画面で「バリュー購入」のリンクが選択されると、データ処理部110は、バリュー購入が選択されたと判断し(ステップS193でYES)、ステップS130で、バリュー購入時処理を実行する。
図15は、本実施の形態における携帯電話100により実行される電子マネーアプリ111のサブルーチンであるバリュー購入時処理の流れを示すフローチャートである。図15を参照して、まず、ステップS133で、データ処理部110は、会員IDと携帯端末情報とバリュー残高とを含むチャージ要求情報を電子マネー管理サーバ200に送信する。
図16は、本実施の形態における電子マネー管理サーバ200により実行されるバリュー購入時アプリケーションプログラム212の処理の流れを示すフローチャートである。図16を参照して、まず、ステップS241で、データ処理部210は、携帯電話100からチャージ要求情報を受信したか否かを判断する。チャージ要求情報を受信していないと判断した場合(ステップS241でNOの場合)、データ処理部210は、実行する処理をステップS257に進める。
一方、チャージ要求情報を受信したと判断した場合(ステップS241でYESの場合)、データ処理部210は、ステップS242で、チャージ要求情報に含まれる会員IDおよび携帯端末情報が利用者情報DB221に登録されたものであり、携帯電話100が電子マネー遊技使用サービスで利用可能なものであるか否かを判断する。利用可能なものでないと判断した場合(ステップS242でNOの場合)、ステップS243で、データ処理部210は、使用不可画面を携帯電話100に送信し、実行する処理をステップS241に戻す。
図39に進んで、図39(c)は、ステップS243で送信される使用不可画面である。図39(c)の画面には、携帯電話100が電子マネー管理サーバ200に登録されていない旨の文章、および、その旨を確認して電子マネーアプリ111を終了させるためのリンクである「OK」が表示される。
図16に戻って、一方、利用可能なものであると判断した場合(ステップS242でYESの場合)、ステップS244で、データ処理部210は、購入済みであるが携帯電話100にチャージされていない未チャージバリューがあるか否かを判断する。
未チャージバリューがあるか否かについては、ステップS241で受信したチャージ要求情報に含まれる会員IDおよび携帯端末情報に対応して、図5で説明した発行情報DB222において、処理状況として「未発行」が記憶されているバリューがあるか否かにより判断が行なわれる。本実施の形態においては、処理状況として「未発行」が記憶されているバリューがあると判断した場合には、データ処理部210は、未チャージバリューがあると判断する。
なお、未チャージバリューがあるか否かの判断については、このようなものに限るものではない。たとえば、チャージされ携帯電話100に書込まれたバリューは、発行情報DB222から消去するものであってもよい。そして、未チャージバリューがあるか否かについては、発行情報DB222に未チャージバリューが記憶されているか否かにより判断が行なわれるものであってもよい。
未チャージバリューがあると判断した場合(ステップS244でYESの場合)、データ処理部210は、ステップS245で、チャージ誘導画面を携帯電話100に送信し、実行する処理を後述する図19のステップS277に進める。
すなわち、チャージ受付情報としての残高情報を送信するステップである後述するステップS256に進むことなく、当該未チャージバリューを発行するために、図19に示すバリュー発行処理に移行する。
図39に進んで、図39(d)は、ステップS245で表示されるチャージ誘導画面である。図39(d)の画面には、チャージされていないバリューがあるので、チャージを促がす旨の文章が表示される。この画面が表示された後、後述する図19のバリュー発行時AP213のステップS277からの処理が実行され、チャージされていないバリューが携帯電話100にチャージされる。
なお、ここでは、チャージ誘導画面が表示された後、自動的に、ステップS277からの処理に移行するようにした。しかし、これに限定されず、チャージ誘導画面でユーザからの確認操作があった後に、ステップS277からの処理に移行するようにしてもよい。
一方、未チャージバリューがないと判断した場合(ステップS244でNOの場合)、データ処理部210は、実行する処理をステップS246に進める。
次に、ステップS246で、データ処理部210は、ステップS241で受信したチャージ要求情報を送信してきた携帯電話100の携帯端末情報に対応する金融機関指定情報を利用者情報DB221から検索して読出す。
また、ステップS246aで、データ処理部210は、受信したチャージ要求情報に含まれる携帯端末情報で示される携帯電話100の種別がテスト用であるか通常用であるかを特定する。次いで、ステップS247で、データ処理部210は、特定された携帯電話100の種別に応じた表示金額リスト情報を読出す。
なお、本実施の形態においては、携帯電話がテスト用であるか通常用であるかの判定は、チャージ要求情報に含まれる携帯端末情報が、利用者情報DB221にテスト用として記憶されているか通常用として記憶されているかによって行なわれる。しかし、これに限定されず、携帯端末情報ごとに利用者情報DB221に記憶された表示金額リスト情報が読出されるようにしてもよい。また、携帯電話100からテスト用であるか通常用であるかを示す種別識別情報を受信して、その種別識別情報によって示される種別に応じて、それぞれの種別に対応して予め記憶された表示金額リスト情報が読出されるようにしてもよい。
種別に応じた表示金額リスト情報は、電子マネー管理サーバ200の記憶部220に予め記憶される。表示金額リスト情報は、ユーザが携帯電話100で選択可能なバリューの金額のリストを示す情報であり、本実施の形態においては、通常用の種別に対応して「1000円」「5000円」「10000円」「20000円」「30000円」の5つの金額を示す情報あり、テスト用の種別に対応して「10000円」「50000円」「100000円」「300000円」「500000円」の5つの金額を示す情報である。選択可能なバリューの金額は、利用者の遊技へののめり込みを防止するために定められた携帯上保持限度額および1日購入限度額に基づいて、電子マネー遊技使用サービスの提供業者によって予め定められる。
ステップS250では、データ処理部210は、ステップS246aで特定された携帯電話100の種別に応じた携帯上保持限度額および1日購入限度額を読出す。
種別に応じた携帯上保持限度額および1日購入限度額は、電子マネー管理サーバ200の記憶部220に予め記憶される。具体的には、前述した図4で説明したように、携帯端末情報に対応させて記憶される。携帯上保持限度額および1日購入限度額は、それぞれ、本実施の形態においては、通常用の種別に対応して「30000円」「30000円」の金額を示す情報であり、テスト用の種別に対応して「1000000円」「500000円」の金額を示す情報である。
なお、本実施の形態においては、利用者情報DB221に、端末端末情報と対応付けて、テスト用か通常用かの種別、携帯上保持限度額および1日購入限度額を記憶するようにした。このため、ステップS241で受信したチャージ要求情報に含まれる携帯端末情報から、テスト用か通常用かの種別、携帯上保持限度額および1日購入限度額をそれぞれ一度に特定することができる。
しかし、これに限定されず、テスト用および通常用の種別に対応してそれぞれ携帯上保持限度額および1日購入限度額を第1のデータベースに記憶するとともに、携帯端末情報と対応付けてテスト用または通常用の種別を示す情報を第2のデータベースに記憶するようにしてもよい。これにより、まず、ステップS241で受信したチャージ要求情報に含まれる携帯端末情報から、第2のデータベースが参照されて、携帯電話の種別がテスト用であるか通常用であるかが特定され、次に、第1のデータベースが参照されて、特定された種別から携帯上保持限度額および1日購入限度額が特定される。
携帯端末情報の形式をテスト用と通常用とで異ならせ、携帯端末情報の各形式と携帯端末の種別とを対応付けて第1データベース(たとえば、K−***の携帯端末情報は通常用、T−***の携帯端末情報はテスト用)に記憶するとともに、テスト用および通常用の種別に対応してそれぞれの携帯上保持限度額および1日購入限度額を第2データベースに記憶するようにしてもよい。これにより、まず、ステップS241で受信したチャージ要求情報に含まれる携帯端末情報から第1データベースが参照されて携帯端末の種別が特定され、次に第2データベースが参照されて、特定された種別から携帯上保持限度額および1日購入限度額が特定されるようにしてもよい。
また、テスト用および通常用の種別に対応してそれぞれ携帯上保持限度額および1日購入限度額を第1のデータベースに記憶するとともに、テスト用の携帯電話の携帯端末情報を第2のデータベースに記憶するようにし、通常用の携帯電話の携帯端末情報を第3のデータベースに記憶するようにしてもよい。これにより、まず、ステップS241で受信したチャージ要求情報に含まれる携帯端末情報が第2のデータベースに含まれるか第3のデータベースに含まれるかによって携帯端末の種別が特定され、次に、第1のデータベースが参照されて、特定された種別から携帯上保持限度額および1日購入限度額が特定される。
また、表示金額リスト情報、携帯上保持限度額、および、1日購入限度額は、それぞれ、テスト用および通常用の2種類の種別に対応して記憶されることに限定されず、3種類以上の種別に対応して記憶されるようにしてもよいし、携帯電話ごとに記憶されるようにしてもよい。また、表示金額リスト情報に含まれる金額、携帯上保持限度額、および、1日購入限度額は、それぞれ、他の金額であってもよく、それぞれ任意に設定可能である。
次いで、ステップS251で、データ処理部210は、ステップS241で受信したチャージ要求情報に含まれる携帯電話100にチャージされているバリュー残高に、ステップS247で読出した表示金額リスト情報で示される金額のうちの最低購入金額(チャージ要求時に選択可能な最低金額であり、本実施例においては、図41(b)、図42に示す表示金額リストにおける最低の金額であり、図41(b)の通常用の表示金額リストの場合1000円、テスト用の表示金額リストの場合10000円)を加算した額が、ステップS250で読出した携帯上保持限度額以下であるか否かを判断する。つまり、バリュー残高と携帯上保持限度額とに基づいてチャージを許容するか否かを判定する。バリュー残高に最低購入金額を加算した額が携帯上保持限度額以下でない場合(ステップS251でNOの場合)、チャージを許容せず、ステップS252で、データ処理部210は、携帯上保持限度額購入不可画面を携帯電話100に送信した後、実行する処理をステップS241に戻す。
図40は、本実施の形態における電子マネーシステム10において携帯電話100でバリューを購入するときに携帯電話100の表示部140に表示される第2の表示画面図である。図40(a)は、ステップS252で携帯電話100に送信される携帯上保持限度額購入不可画面である。図40(a)の画面には、最低購入金額とバリュー残高との合計が携帯上保持限度額を超えるので、バリューを購入できない旨の文章、および、その旨を確認して電子マネーアプリ111を終了させるためのリンクである「OK」が表示される。
図16に戻って、一方、バリュー残高に最低購入金額を加算した額が携帯上保持限度額以下である場合(ステップS251でYESの場合)、ステップS253で、データ処理部210は、発行情報DB222に記憶されているその日に携帯電話100によって購入されたバリューの当日積算額に、最低購入金額を加算した額が1日購入限度額以下であるか否かを判断する。つまり、当日積算額と1日購入限度額とに基づいてチャージを許容するか否かを判定する。当日積算額に最低購入金額を加算した額が1日購入限度額以下でない場合(ステップS253でNOの場合)、チャージを許容せず、ステップS254で、データ処理部210は、1日購入限度額購入不可画面を携帯電話100に送信した後、実行する処理をステップS241に戻す。
図40に進んで、図40(b)は、ステップS254で携帯電話100に送信される1日購入限度額購入不可画面である。図40(b)の画面には、最低購入金額と当日積算額との合計が1日購入限度額を超えるので、バリューを購入できない旨の文章、および、その旨を確認して電子マネーアプリ111を終了させるためのリンクである「OK」が表示される。
図16に戻って、一方、当日積算額に最低購入金額を加算した額が1日購入限度額以下である場合(ステップS253でYESの場合)、ステップS255で、データ処理部210は、バリュー残高および当日積算額から購入可能金額を算出する。具体的には、データ処理部210は、携帯上保持限度額からバリュー残高を減算した額、および、1日購入限度額から当日積算額を減算した額のうち、低い方の額を購入可能金額として算出する。
なお、本実施の形態においては、バリュー残高および携帯上保持限度額、ならびに、当日積算額および1日購入限度額に基づいて、バリューを購入可能か否かを判断して、購入可能金額を算出するようにした。しかし、これに限定されず、バリュー残高および携帯上保持限度額、または、当日積算額および1日購入限度額に基づいて、バリューを購入可能か否かを判断して、購入可能金額を算出するようにしてもよい。
次に、ステップS256で、データ処理部210は、ステップS241で受信したチャージ要求情報に含まれる携帯端末情報に対応して利用者情報DB221に記憶されている電子メールアドレス、ステップS246で読出した金融機関指定情報(該金融機関が直接決済対応の金融機関および間接決済対応の金融機関のいずれであるかを示す情報も含む)、ステップS247で読出した携帯端末情報の携帯電話の種別に応じた表示金額リスト情報、ステップS250で読出した携帯上保持限度額、1日購入限度額、および、ステップS255で算出した購入可能金額情報を、残高情報(チャージ要求情報を受付けた旨を示すチャージ受付情報)として携帯電話100に送信する。
図15に戻って、ステップS134で、データ処理部110は、電子マネー管理サーバ200から残高情報を受信したか否かを判断する。残高情報を受信したと判断した場合(ステップS134でYESの場合)、ステップS135で、データ処理部110は、受信した残高情報に含まれる電子メールアドレスがバリューの購入に用いる電子メールアドレスとして正しいか否かを確認するためのアドレス確認画面を表示部140に表示させる。その後、データ処理部110は、実行する処理をステップS136に進める。
図40に進んで、図40(c)は、ステップS135で表示されるアドレス確認画面である。図40(c)の画面には、バリューのチャージの方法を説明するための文章、ステップS134で受信した残高情報に含まれる確認の対象である電子メールアドレス、表示されている電子メールアドレスが電子マネー遊技使用サービスで利用する携帯電話100の電子メールアドレスとして正しいと確認したことを入力するためのリンクである「確認」、および、表示されている電子メールアドレスが電子マネー遊技使用サービスで利用する携帯電話100の電子メールアドレスと異なる場合に選択するリンクである「→上記アドレスがご利用携帯のアドレスと異なる場合はこちら」が表示される。
図15に戻って、ステップS136で、データ処理部110は、図40(c)の画面で「確認」のリンクが選択されることによって、ユーザにより電子メールアドレスが確認されたか否かを判断する。アドレスが確認されたと判断した場合(ステップS136でYESの場合)、ステップS137で、データ処理部110は、金融機関確認画面を表示部140に表示させる。
図41は、本実施の形態における電子マネーシステム10において携帯電話100でバリューを購入するときに携帯電話100の表示部140に表示される第3の表示画面図である。
図41(a)は、ステップS137で携帯電話100に表示される金融機関確認画面である。図41(a)の画面には、利用する金融機関を確認する旨の文章、利用する金融機関の名称、利用する金融機関を確認して継続して手続を進めるためのリンクである「確認」、および、金融機関を変更するためのリンクである「金融機関変更の場合はこちらを選択してください。」が表示される。金融機関の名称は、受信した残高情報に含まれる金融機関指定情報は、金融機関の名称に対応して予め一意に定められている。このため、金融機関の名称は、残高情報を受信することにより、携帯電話100によって特定され得る。
図15に戻って、ステップS138で、データ処理部110は、図41(a)の画面で「確認」のリンクが選択されることによって、利用する金融機関がユーザにより確認されたか否かを判断する。
金融機関が確認されていないと判断した場合(ステップS138でNOの場合)、ステップS140aで、データ処理部110は、金融機関変更が選択されたか否かを判断する。金融機関変更が選択されていないと判断した場合(ステップS140aでNOの場合)、データ処理部110は、実行する処理をステップS138の処理に戻す。
一方、金融機関変更が選択されたと判断した場合(ステップS140aでYESの場合)、データ処理部110は、ステップS140bで金融機関変更問合せ情報を電子マネー管理サーバ200に送信し、ステップS140dで電子マネー管理サーバ200の利用者情報DB221に携帯端末情報と対応させて登録されている金融機関指定情報を他の金融機関指定情報に変更するための金融機関変更処理が行なわれ、実行する処理をステップS138の処理に戻す。金融機関変更処理においては、変更した金融機関の金融機関指定情報、ならびに、金融機関が直接決済対応の金融機関であれば口座番号およびその口座のパスワードが送信される。
電子マネー管理サーバ200のデータ処理部210は、携帯電話100から金融機関変更問合せ情報を受信した場合、金融機関変更問合せ情報に対応する画面(図35(c),(d),図36(a),(b),(c),図37(a)等参照)を携帯電話100に送信する。そして、電子マネー管理サーバ200のデータ処理部210は、携帯電話100から金融機関指定情報(ユーザから変更先として指定を受付けた金融機関を指定する情報)を受信したと判断した場合、変更した金融機関の金融機関指定情報を、携帯端末情報に対応させて、利用者情報DB221に登録する処理を行なう。また、口座番号およびパスワードを受信したと判断した場合、受信した口座番号およびパスワードを携帯端末情報に対応させて、利用者情報DB221に登録する処理を行なう。
なお、登録する処理としては、変更した金融機関のサーバが決済に利用される状態に更新するものであればよく、たとえば、変更前の金融機関の金融機関指定情報を消去して新たに変更後の金融機関の金融機関指定情報を登録する処理であってもよい。また、変更前の金融機関の金融機関指定情報を消去することなく変更後の金融機関の金融機関指定情報を決済に利用する金融機関として新たに登録する処理であってもよい。この場合、変更前の金融機関の金融機関指定情報を用いて、再度決済に利用する金融機関を変更前の金融機関に変更できるものであってもよい。
金融機関が確認されたと判断した場合(ステップS138でYESの場合)、データ処理部110は、ステップS139で、残高情報に含まれる表示金額リスト情報、携帯上保持限度額、1日購入限度額および購入可能金額情報でそれぞれ示される表示金額リストおよび購入可能金額に応じて、購入金額選択画面を表示部140に表示させる。
図41に進んで、図41(b)は、ステップS139で通常用の携帯電話100に表示される購入金額選択画面である。図41(b)の画面には、購入してチャージを希望するバリューの金額の選択を促がす旨の文章、1日購入限度額を示す文章、携帯上保持限度額に関する文章、購入希望金額の選択肢と対をなしたラジオボタン、および、選択されたバリューの購入希望金額の送信を指示するためのリンクである「送信」が表示される。
図41(b)の購入金額選択画面に表示される購入希望金額の選択肢、1日購入限度額、および、携帯上保持限度額は、それぞれ、電子マネー管理サーバ10によってこの携帯電話100が通常用の携帯電話であると判定されたことに応じて送信されてきた残高情報に含まれる表示金額リスト情報、1日購入限度額、および、携帯上保持限度額でそれぞれ示される「1000円,5000円,10000円,20000円,30000円」「30000円」および「30000円」である。
ここで、ステップS134で受信された残高情報に含まれる購入可能金額情報で示される購入可能金額を超える金額の選択肢と対をなすラジオボタンは、表示されるが、選択できない。また、購入希望金額の選択肢と対をなすラジオボタンのいずれかが選択されない限り、「送信」のリンクを選択することはできない。なお、本実施の形態においては、購入希望金額を超える金額の選択肢と対をなすラジオボタンも表示される例について説明したが、これに限らず、購入可能金額の範囲内の金額の選択肢と対をなすラジオボタンのみを表示させ、購入可能金額を超える金額の選択肢と対をなすラジオボタンを表示させないようにしてもよい。また、購入可能金額を超える金額の選択肢を表示させないようにしてもよい。つまり、購入可能金額以下のチャージ額の選択肢を指定可能な表示態様で表示させればよい。
図42は、本実施の形態における電子マネーシステム10において携帯電話100でバリューを購入するときに携帯電話100の表示部140に表示される第4の表示画面図である。図42(a)は、ステップS139でテスト用の携帯電話100に表示される購入金額選択画面である。図42(a)の画面は、図41(b)の画面と比較して、購入希望金額の選択肢、1日購入限度額、および、携帯上保持限度額が異なる。
図42(a)の購入金額選択画面に表示される購入希望金額の選択肢、1日購入限度額、および、携帯上保持限度額は、それぞれ、電子マネー管理サーバ10によりこの携帯電話100がテスト用の携帯電話であると判定されたことに応じて送信されてきた残高情報に含まれる表示金額リスト情報、1日購入限度額、および、携帯上保持限度額でそれぞれ示される「10000円,50000円,100000円,300000円,500000円」「500000円」および「1000000円」である。
図15に戻って、図41(b)の画面または図42(a)の画面で、購入希望金額と対をなすラジオボタンのいずれかが選択され、「送信」のリンクが選択されると、ステップS141で、携帯電話100のデータ処理部110は、購入希望金額のラジオボタンが選択されることによって、購入希望金額が選択されたか否かを判断する。
購入希望金額が選択されたと判断した場合(ステップS141でYESの場合)、データ処理部110は、ステップS142で、選択を受付けた購入希望金額および会員IDを示す情報を含む第1口座振替依頼情報を電子マネー管理サーバ200に送信する。
図16に進んで、ステップS257で、データ処理部210は、携帯電話100から第1口座振替依頼情報を受信したか否かを判断する。第1口座振替依頼情報を受信していないと判断した場合(ステップS257でNOの場合)、データ処理部210は、実行する処理をステップS265に進める。
一方、第1口座振替依頼情報を受信したと判断した場合(ステップS257でYESの場合)、ステップS258で、データ処理部210は、バリュー購入回数カウンタで携帯電話100ごとに計数されているバリュー購入回数が0回か否かを判断する。つまり、携帯電話100からチャージ要求が送信されステップS241においてYESと判断されたのが、ステップS236によって領域確保情報が携帯電話100に送信されてから初回であるか否かが判断される。
バリュー購入回数が0回であると判断した場合(ステップS258でYESの場合)、携帯電話100が電子マネー遊技使用サービスに登録されてから最初のバリューの購入であるので、初期登録手数料を徴収する必要がある。そこで、この場合、ステップS259で、データ処理部210は、初期登録手数料およびチャージ手数料を算出する。
一方、バリュー購入回数が0回でないと判断した場合(ステップS258でNOの場合)、すでに、初期登録手数料は徴収されているので、初期登録手数料を徴収しなくてもよい。そこで、この場合、ステップS260で、データ処理部210は、チャージ手数料を算出する。
なお、本実施の形態においては、ステップS259およびステップS260で、初期登録手数料およびチャージ手数料をそれぞれ算出するようにしたが、これに限定されず、初期登録手数料およびチャージ手数料を予め記憶部220に記憶させておき、それぞれ、ステップS259およびステップS260で読出すようにしてもよい。
次に、データ処理部210は、ステップS261で、今回のバリュー購入を他のバリュー購入と識別するための購入番号を発行し、ステップS262で、ステップS257で受信した第1口座振替依頼情報で示される購入希望金額と、ステップS259またはステップS260で算出された手数料との合計金額を算出する。
次いで、データ処理部210は、ステップS263で、ステップS262で算出した合計金額、ステップS261で発行した購入番号、および、現在の時刻であるタイムスタンプを、会員IDに対応させて発行情報DB222に登録する。そして、データ処理部210は、ステップS264で、合計金額をユーザに確認するための合計金額確認画面を表示させるための合計金額確認情報を携帯電話100に送信する。
図15に戻って、ステップS143で、データ処理部110は、電子マネー管理サーバ200から合計金額確認情報を受信したか否かを判断する。合計金額確認情報を受信したと判断した場合(ステップS143でYESの場合)、ステップS144で、データ処理部110は、合計金額確認情報に基づいて、合計金額確認画面を表示部140に表示させる。
図41に進んで、図41(c)は、ステップS144で表示される合計金額確認画面である。図41(c)の画面には、合計金額の確認を求める旨の文章、合計金額を確認した旨を示すために操作するリンクである「確認」、および、1つ前の図41(b)の購入金額選択画面に戻るためのリンクである「こちら。」とが表示される。
図15に戻って、ステップS145で、データ処理部110は、図41(c)の画面で「確認」のリンクが選択されることによって、ユーザにより合計金額が確認されたか否かを判断する。合計金額が確認されたと判断した場合(ステップS145でYESの場合)、ステップS147で、データ処理部110は、ステップS134で受信された残高情報に含まれる金融機関指定情報に含まれる情報が直接決済に対応する金融機関であることを示すか否かを判断することによって、金融機関が直接決済に対応する金融機関であるか否かを判断する。直接決済に対応する金融機関でないと判断された場合(ステップS147でNOの場合)、モバイルバンキング確認画面が表示される(ステップS145a)。
図41に進んで、図41(d)は、ステップS145aで表示されるモバイルバンキング確認画面である。図41(d)の画面には、手続がモバイルバンキングへ遷移される旨の文章、その旨の確認を入力するためのリンクである「確認」、および、図39(b)の起動時初期画面に戻るためのリンクである「手続を中止する(アプリのメニュー画面に戻る)」が表示される。
図15に戻って、ステップS145bでデータ処理部110は、図41(d)の画面で「確認」のリンクが選択されることによって、ユーザによりモバイルバンキングへの遷移が確認されたか否かを判断する。モバイルバンキングへの遷移が確認されたと判断した場合(ステップS145bでYESの場合)、ステップS146で、データ処理部110は、会員IDを示す情報を含む第2口座振替依頼情報を電子マネー管理サーバ200に送信し、バリュー購入時処理を終了する。以降、後述するように、電子マネー管理サーバ200から送信される引継画面情報の受信に応じて、引継時ウェブ処理が実行される。
図16に進んで、ステップS264aで、ステップS246で読出した金融機関指定情報で示される金融機関が、図9の金融機関設定画面で設定された直接決済に対応する金融機関であるか否かを、前述したように、利用者情報DB221の登録内容に基づいて判断する。直接決済に対応する金融機関でない、つまり間接決済に対応する金融機関であると判断した場合(ステップS264aでNOの場合)、ステップS265で、データ処理部210は、携帯電話100から第2口座振替依頼情報を受信したか否かを判断する。第2口座振替依頼情報を受信していないと判断した場合(ステップS265でNOの場合)、データ処理部210は、実行する処理をステップS269に進める。
一方、第2口座振替依頼情報を受信したと判断した場合(ステップS265でYESの場合)、ステップS266で、データ処理部210は、ステップS263で登録したタイムスタンプと現在の時刻とを比較するタイムスタンプチェックを実行し、異常があるか否かを判断する。たとえば、タイムスタンプと現在の時刻との差が規定時間以上である場合に異常があると判断する。
異常があると判断した場合(ステップS266でYESの場合)、ステップS267で、データ処理部210は、タイムスタンプチェックエラー画面を携帯電話100に送信する。
図41に進んで、図41(e)は、ステップS267で携帯電話100に送信されるタイムスタンプチェックエラー画面である。図41(e)の画面には、購入希望金額を選択してから一定時間が経過したので、手続のやり直しを促がす旨の文章、および、図39(b)の起動時初期画面に戻るためのリンクである「手続を中止する(アプリのメニュー画面に戻る)」が表示される。
図16に戻って、一方、異常がないと判断した場合(ステップS266でNOの場合)、データ処理部210は、ステップS268で、モバイルバンキングへ遷移させるための引継画面情報を携帯電話100に送信する。引継画面情報には、少なくとも、ステップS246において検索され読み出された当該携帯電話100の携帯端末情報に対応付けて登録されている金融機関情報から特定される金融機関の金融機関サーバ500のインターネットバンキングシステムにアクセスして、決済要求(第1決済要求)を送信するためのアクセス情報としてのURLが含まれる。
図10(b)は、ウェブ処理のうち引継時ウェブ処理の流れを示すフローチャートである。引継時ウェブ処理は、ステップS268で送信される引継画面情報の受信に応じて実行される。図10(b)を参照して、ステップS117で、データ処理部110は、電子マネー管理サーバ200から引継画面情報を受信したか否かを判断する。引継画面情報を受信したと判断した場合(ステップS117でYESの場合)、ステップS118で、データ処理部110は、引継画面情報に基づいて、モバイルバンキングへ遷移する旨を報知するためのモバイルバンキング遷移確認画面を表示部140に表示し、ステップS118aで、モバイルバンキングでのバリューの購入に対する決済の処理を行なうモバイルバンキング処理を実行する。モバイルバンキング処理では、操作に応じてバリューの購入に対する決済に関する情報を金融機関サーバ500に送信し、決済が完了すると引継時ウェブ処理が終了する。具体的には、引継画面情報に含まれるURLの示す金融機関サーバ500のインターネットバンキングシステムにアクセスし、予め登録されている自己のモバイルバンキング口座にログインして振込み処理を行なうことで、ステップS143で受信した合計金額確認情報から特定される合計金額の決済要求(第1決済要求)を金融機関サーバ500に送信することとなる。なお、この際、ステップS143で受信した合計金額確認情報から特定される合計金額についても、金融機関サーバ500に送信されるため、ログイン後の入力操作が軽減される。ここで、このモバイルバンキング処理は、現在、各金融機関が提供しているモバイルバンキングのシステムを利用するものであるから詳細な説明は省略する。
このように、本実施の形態においては、バリューのチャージに関する対価の決済のための決済用処理として、金融機関によるモバイルバンキングを利用することで、当該モバイルバンキングによる振込み処理の時点で決済が完了するものとしているが、決済用処理としては、このように処理の時点で決済が完了するものに限らず、たとえばクレジットカード提供機関のサーバに対してチャージに関する対価の決済を要求し、クレジットカード提供機関のサーバが与信による決済を行ない、実際の決済は後日に行なわれるような処理でもよい。
図1に戻って、バリュー購入に対する決済が完了すると、金融機関サーバ500から金融機関専用ネットワーク920を介して決済サーバ280に、バリュー購入に対する決済が完了した旨の消込電文が送信される。
決済サーバ280は、受信した消込電文を請求情報DB281に登録する。そして、決済サーバ280は、受信した消込電文に対応する消込速報(第1決済完了通知)を電子マネー管理サーバ200に送信する。
図16に進んで、ステップS269で、データ処理部210は、決済サーバ280から消込速報を受信したか否かを判断する。消込速報を受信したと判断した場合(ステップS269でYESの場合)、データ処理部210は、ステップS270で、バリュー対価決済後処理を実行する。バリュー対価決済後処理については、図17で説明する。一方、消込速報を受信していないと判断した場合(ステップS269でNOの場合)、または、ステップS270の後、データ処理部210は、実行する処理をステップS241に戻す。
図17は、本実施の形態における電子マネー管理サーバ200により実行されるバリュー購入時アプリケーションプログラム212のサブルーチンであるバリュー対価決済後処理の流れを示すフローチャートである。
図17を参照して、まず、電子マネー管理サーバ200のデータ処理部210は、ステップS2700で、ステップS269で決済サーバ280から受信した消込速報で示される購入番号が発行情報DB222に登録されているか否かを判断する。購入番号が登録されていないと判断した場合(ステップS2700でNOの場合)、ステップS2701で、データ処理部210は、エラー処理を行なう。たとえば、警報を発生して、電子マネー管理サーバ200の管理者が確認できるようにする。そして、確認操作後、データ処理部210は、実行する処理をこの処理の呼出元の処理であるバリュー購入時AP212に戻す。
一方、購入番号が登録されていると判断した場合(ステップS2700でYESの場合)、ステップS2702で、データ処理部210は、購入番号で示されるバリューの購入が、その購入番号と対応する携帯電話100での初回の購入であるか否かを判断する。具体的には、その携帯電話100に対応するバリュー購入回数カウンタのカウント値が0であるか否かを判断する。
初回の購入であると判断した場合(ステップS2702でYESの場合)、ステップS2703で、データ処理部210は、未チャージ削除カウンタのカウント値を0にする。なお、初回の購入であると判断した場合には、データ処理部210は、未チャージ削除カウンタのカウント値を1減算するものであってもよい。その後、データ処理部210は、実行する処理をステップS2704に進める。一方、初回の購入でないと判断した場合(ステップS2702でNOの場合)、データ処理部210は、実行する処理をステップS2704に進める。
次に、ステップS2704で、データ処理部210は、購入番号に対応する会員IDに対応するバリュー購入記録を更新する。ここでは、未チャージバリューが有りとなるように設定する処理が行なわれる。具体的には、図5の発行情報DB222に、バリューの額を特定するための情報(たとえば、購入額が1000円である場合は「1000」)と、その額が未チャージであることを示す処理状況(たとえば、「未発行」)とが対応付けられて記憶される。これにより、ステップS241における判断により受信したチャージ要求に対応するバリューであって、当該チャージ要求元の携帯電話100にチャージ可能となった未チャージバリューを特定するためのバリュー購入記録(特定用情報)を登録する手段が構成されている。
そして、データ処理部210は、ステップS2705で、バリュー購入回数カウンタのカウント値を1加算し、ステップS2706で、携帯電話100に対応する当日積算額に購入金額を加算して、当日積算額を更新し、ステップS2707で、携帯電話100に対応するチャージ累計額に購入金額を加算して、チャージ累計額を更新し記憶する。
次いで、ステップS2708で、データ処理部210は、ステップS2700で受信した消込速報を正常に処理した旨の応答情報を決済サーバ280に送信する。そして、ステップS2709で、データ処理部210は、引継ぎ情報を付した電子メールを、消込速報に対応する会員IDの電子メールアドレス宛に送信する。その後、データ処理部210は、バリュー対価決済後処理を終了し、実行する処理をこの処理の呼出元に戻す。
引継ぎ情報としては、リンク情報が含まれる。本実施の形態におけるリンク情報には、後述する電子マネーアプリ111を自動的に起動させるための情報が含まれている。電子マネーアプリ111が起動されると、引継ぎ情報からの起動である(ステップS191でYESである)ので、後述する図18で説明するバリュー発行時処理が実行される。
以上のように、電子マネー管理サーバ200は、携帯電話100から金融機関サーバ500に対して送信された第1決済要求に対する消込速報(第1決済完了通知)を金融機関専用ネットワーク920を介して受信したことを条件として、バリューを携帯電話100にチャージするための第1のチャージ処理として、電子マネーのチャージが可能になった旨を通知するとともに、電子マネーのチャージのために操作されるリンク情報を含む電子メールを携帯電話100に送信する処理を行なう。
(電子マネーシステム10でのバリューのチャージの説明)
図44は、本実施の形態における電子マネーシステム10において携帯電話100にバリューをチャージする(書込む)ときに携帯電話100の表示部140に表示される第1の表示画面図である。
図44(a)は、携帯電話100の電子メール機能において、新着メッセージの件数を示す画面である。ここでは、「メール 未読001」の表示によって、新着の電子メールのうち、未読のものが1件であることが示されている。
図44(a)の画面で、「メール 未読001」が選択されると、図44(b)のように、ステップS2709で、電子マネー管理サーバ200から携帯電話100に送信された新着メールの内容が表示される。
図44(b)の電子メールには、購入されたバリューが電子マネー管理サーバ200に登録された旨、および、購入されたバリューをチャージするための引継ぎ情報としてのリンクである「ここをクリックしてアプリを起動し、ICチップへのチャージを行なってください。」が表示される。図44(b)の画面で、このリンクが選択されると、電子マネーアプリ111が起動される。
図11に戻って、図44(b)の画面で、引継ぎ情報としてのリンクが選択され、電子マネーアプリ111が起動されると、ステップS191で、データ処理部110は、引継ぎ情報からの起動であると判断して、実行する処理をステップS150に進める。
また、ステップS194で、データ処理部110は、図39(b)で説明した起動時初期画面で「ICチップへの購入バリューのチャージ(最新残高更新)」のリンクが選択されることによって、バリュー発行が選択されたか否かを判断する。バリュー発行が選択された場合(ステップS194でYESの場合)、データ処理部110は、実行する処理をステップS150に進める。
ステップS150では、データ処理部110は、後述する図18で説明するバリュー発行時処理を実行する。
本実施の形態においては、電子メールに付された引継ぎ情報としてのリンクが選択されると、電子マネーアプリ111が自動的に起動され、ステップS150でバリュー発行時処理が実行されるようにした。しかし、これに限定されず、リンクが選択されると、電子マネーアプリ111が自動的に起動され、図39(b)で説明した起動時初期画面が表示され、ユーザによりバリューのチャージのリンクが選択されることによってバリュー発行時処理が実行されるようにしてもよい。また、リンクが選択されると、図39(a)で説明した画面が表示され、ユーザにより電子マネーアプリ111が起動され、バリューのチャージのリンクが選択されることによってバリュー発行時処理が実行されるようにしてもよい。
図18は、本実施の形態における携帯電話100により実行される電子マネーアプリ111のサブルーチンであるバリュー発行時処理の流れを示すフローチャートである。図18を参照して、まず、ステップS151で、データ処理部110は、記憶部120に記憶されている処理状況が発行情報受信済であるか否かを判断する。処理状況は、後述するように、ステップS153で、バリュー発行情報が電子マネー管理サーバ200から受信されることを条件として、ステップS153aで、発行情報受信済に更新される。
処理状況が発行情報受信済であると判断した場合(ステップS151においてYESの場合)、データ処理部110は、実行する処理をステップS154に進める。一方、処理状況が発行情報受信済でないと判断した場合(ステップS151においてNOの場合)、ステップS152で、データ処理部110は、バリューのチャージ(発行)を要求するための情報であって会員IDおよび携帯端末情報を含むバリュー発行要求情報を、電子マネー管理サーバ200に送信する。
つまり、本実施の形態においては、電子マネーの発行を要求するための発行操作として、図39(b)の起動時初期画面において「ICチップへの購入バリューのチャージ」のリンクの選択操作、または、電子メールに添付された引継ぎ情報としてのリンクの操作をユーザから受付けたことを条件として、具体的には、発行操作をユーザから受付け、さらに、記憶部120に記憶されている処理状況が発行情報受信済でないことを条件として、電子マネーの発行を要求するためのバリュー発行要求情報を電子マネー管理サーバ200に送信する。
図19は、本実施の形態における電子マネー管理サーバ200により実行されるバリュー発行時アプリケーションプログラム213の処理の流れを示すフローチャートである。
図19を参照して、まず、ステップS271で、データ処理部210は、携帯電話100からバリュー発行要求情報を受信したことによって、バリュー発行要求があったか否かを判断する。バリュー発行要求がないと判断した場合(ステップS271でNOの場合)、データ処理部210は、実行する処理をステップS271に戻す。
一方、バリュー発行要求があったと判断した場合(ステップS271でYESの場合)、ステップS272で、データ処理部210は、ステップS271で受信したバリュー発行要求情報に含まれる会員IDおよび携帯端末情報が利用者情報DB211に登録された利用可能なものであるか否かを判断する。利用可能なものでないと判断した場合(ステップS272でNOの場合)、ステップS273で、データ処理部210は、使用不可画面を携帯電話100に送信する。使用不可画面は、図39(c)で説明した画面と同様の画面である。
一方、利用可能なものであると判断した場合(ステップS272でYESの場合)、ステップS274で、データ処理部210は、会員IDおよび携帯端末情報に対応する未チャージバリューが発行情報DB222に記憶されているか否かを判断する。未チャージバリューがないと判断した場合(ステップS274でNOの場合)、ステップS275で、データ処理部210は、未チャージバリュー無画面を携帯電話100に送信する。なお、バリュー発行時AP213において、ステップS274およびステップS275の処理を実行する場合を説明したが、これに限らず、バリュー発行時AP213において、ステップS274およびステップS275の処理を実行しないものであってもよい。
図44に進んで、図44(c)は、ステップS275で携帯電話100に送信される未チャージバリュー無画面である。図44(c)の画面には、未受取のバリューが無い旨の文章、および、その旨を確認して電子マネーアプリ111を終了させるためのリンクである「OK」が表示される。
図19に戻って、未チャージバリューがあると判断した場合(ステップS274でYESの場合)、チャージ要求時に未チャージバリューがあると判断した場合(ステップS244でYESの場合)、および後述する残高移行依頼時に未チャージバリューがあると判断した場合(ステップS2064でYESの場合)、データ処理部210は、ステップS277で、未チャージバリューのバリュー購入記録から特定される額のバリューをリモート発行サーバ400から携帯電話100に書込ませるためのバリュー発行情報を携帯電話100に送信する。バリュー発行情報は、少なくとも書込み可能なバリューを含む。
これにより、ステップS271における判断によりバリュー発行要求を受信したことを条件として、さらには、バリュー発行要求情報に含まれる会員IDに対応付けて発行情報DBのバリュー購入記録にて管理されているバリューの処理状況(発行状況)が未発行であることを条件として、発行情報DB222に登録されている会員IDに対応するバリュー購入記録(特定用情報)から特定される未チャージバリューを、当該バリュー発行要求元の携帯電話100に送信するために出力する手段が構成されている。
図18に戻って、ステップS153で、データ処理部110は、電子マネー管理サーバ200からバリュー発行情報を受信したか否かを判断する。バリュー発行情報を受信したと判断した場合(ステップS153でYESの場合)、ステップS153aで、データ処理部110は、記憶部120で管理している処理状況を、発行情報受信済(データ受信済)に更新する。なお、発行情報受信済の処理状況は、後述するステップS157aで処理状況が書込済に更新される前であるので、バリューが未書込の処理状況に相当する。
そして、ステップS153bで、データ処理部110は、バリュー発行情報を受信したことを電子マネー管理サーバ200に知らせるための受信応答情報を、電子マネー管理サーバ200に送信する。
図19に進んで、ステップS278で、データ処理部210は、携帯電話100から受信応答情報を受信したか否かを判断する。受信応答情報を受信していないと判断した場合(ステップS278においてNOの場合)、データ処理部210は、ステップS278の処理を繰返す。一方、受信応答情報を受信したと判断した場合(ステップS278においてYESの場合)、ステップS279で、データ処理部210は、図5の発行情報DB222の処理状況を発行済に更新する。つまり、ステップS277でバリュー発行情報を送信したことを条件として、処理状況を発行済に更新する。その後、データ処理部210は、実行する処理をステップS271に戻す。
図18に戻って、次に、ステップS154で、データ処理部110は、非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域に、バリュー発行情報から特定される購入バリューを記憶させる書込処理を開始させるための情報であって、バリューの購入番号および携帯端末情報を含む書込処理開始要求情報(購入バリューの書込みを要求する書込要求情報)をリモート発行サーバ400へ送信する。
図1に戻って、リモート発行サーバ400は、バリュー書込実行情報を、書込処理開始要求情報に含まれる携帯端末情報で示される携帯電話100に送信する。バリュー書込実行情報は、携帯電話100の非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域に、書込み処理開始要求情報に含まれるバリュー発行額情報で示される額のバリューを記憶させるための情報である。
具体的には、リモート発行サーバ400は、バリューの書込状況を記憶する書込状況記憶部を備えており、当該書込状況記憶部には、書込処理開始要求に含まれる購入番号と携帯端末情報とが対応付けて記憶されるとともに、当該バリューを書込済か否かを示すフラグを記憶する領域が設けられている。
そして、リモート発行サーバ400は、携帯電話100から書込処理開始要求を受信すると、該書込処理開始要求に含まれる購入番号および携帯端末情報が書込状況記憶部に記憶されているか否かを判定するとともに、記憶されている場合にはさらに、対応するフラグが書込済か否かを判定する。
かかる判定において、購入番号および携帯端末情報が記憶されていないか、あるいは記憶されているが対応するフラグが書込済でないと判定された場合、つまり、書込状況記憶部(書込状況管理手段)における管理状況が未書込である場合には、バリュー書込実行情報を携帯電話100に送信する。
一方、購入番号および携帯端末情報が記憶されており、かつ対応するフラグが書込済であると判定された場合、つまり、書込状況記憶部(書込状況管理手段)における管理状況が書込済である場合には、バリュー書込実行情報を送信しない。また、購入番号および携帯端末情報が記憶されていないと判定された場合には、当該購入番号および携帯端末情報を書込状況記憶部に新たに記憶し、書込状況の管理を開始する。
図18に進んで、データ処理部110は、ステップS155で、リモート発行サーバ400からバリュー書込実行情報を受信したか否かを判断する。バリュー書込実行情報を受信したと判断した場合(ステップS155でYESの場合)、ステップS156で、データ処理部110は、リモート発行サーバ400から受信したバリュー書込実行情報で示される書込処理を実行する。書込処理は、バリュー発行情報から特定されるバリューの額を示すバリュー発行額情報で示されるバリューを非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域に書込むための処理である。
具体的には、この書込処理においては、携帯電話100は、電子マネーアプリ111によって、書込みデータであるバリュー発行額情報で示される額のバリューを、リモート発行サーバ400に送信する。リモート発行サーバ400は、電子マネーアプリ111を介さずに、非接触型ICチップ190と直接やり取りして、非接触型ICチップ190の記憶部192に、携帯電話100から受信したバリューを書込む。つまり、リモート発行サーバ400は、前記書込処理開始要求に対応するバリューの書込状況記憶部における書込状況が未書込を示すもの(購入番号等が記憶されていないか、フラグが書込済でない)であることを条件として、非接触型ICチップ190の制御部191に対して前記バリュー発行情報に示されたバリュー(発行バリュー)の書込みを指示し(書込指示情報を送信し)、これに応じて、制御部191が非接触型ICチップ190の記憶部192にバリューの書込みを行なう(つまり、制御部191がデータ書込実行手段を構成する)。この場合、記憶部192の電子マネー遊技使用サービス用の記憶領域に既にバリューが記憶されているときには、既に記憶されているバリューに発行バリューを加算した額のバリューを書込む処理が行なわれるが、かかる処理も発行バリューの書込みに該当する。そして、バリューの書込みが終了した場合、リモート発行サーバ400は、書込終了情報を携帯電話100に送信する。
以上のように、本実施の形態においては、電子マネーアプリ111を介することなく、リモート発行サーバ400の指示に応じて非接触型ICチップ190の制御部191が発行バリューの書込みを行なうように構成したが、これに限定されず、リモート発行サーバ400から書込指示情報を受信したことに応じて、電子マネーアプリ111が制御部191に発行バリューの書込みを指示するようにしてもよい。
また、リモート発行サーバ400は、電子マネー遊技使用サービス用の記憶領域にバリューを書込んだことを条件として、ステップS154で携帯電話100から送信された書込処理開始要求に含まれるバリューの購入番号と対応付けて、当該バリューの処理状況を、書込終了済として記憶する。
つまり、リモート発行サーバ400は、携帯電話100(非接触型ICチップ190の制御部191)に対して書込指示情報を送信したことを条件として、該書込指示情報で書込みが指示されたバリューの購入番号等に対応付けて書込状況記憶部に記憶されているフラグを書込済を示す状態に更新する。
なお、データ処理部110は、非接触型ICチップ190の制御部191に対して書込要求信号を送信し、制御部191が記憶部192の電子マネー遊技使用サービス用の記憶領域にバリューを書込むものであってもよい。この場合、データ処理部110から制御部191に書込要求信号を送信する処理が、バリューを加算するための処理に該当する。
また、リモート発行サーバ400と非接触型ICチップ190の制御部191とがアンテナ194を介して通信し、制御部191が記憶部192の電子マネー遊技使用サービス用の領域にバリューを書込むものであってもよい。この場合、ステップS154においてデータ処理部110からリモート発行サーバ400に書込処理開始要求情報を送信する処理が、バリューを加算するための処理に該当する。
次いで、データ処理部110は、ステップS157で、リモート発行サーバ400から書込終了情報を受信したことによって、書込処理が終了したか否かを判断する。書込処理が終了したと判断した場合(ステップS157でYESの場合)、ステップS157aで、データ処理部110は、記憶部120で管理している処理状況を、書込済に更新する。
なお、このようにリモート発行サーバ400から書込終了情報を受信して処理状況を更新するものに限らず、たとえば、データ処理部110は、制御部191から書込終了信号を受信して、これに基づいて処理状況を更新してもよい。つまり、電子マネー(データ)を非接触型ICチップ190の記憶部192に書込むための処理が実行されたことを条件として、処理状況をデータ書込済に更新すればよい。
次に、データ処理部110は、ステップS158で、非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域からバリュー残高を取得して、バリュー発行完了画面を表示部140に表示させる。
図44に進んで、図44(d)の画面は、ステップS158で表示されるバリュー発行完了画面である。図44(d)の画面には、図38(b)の画面と同様のチップID、バリューのチャージが完了した旨の文章、今回のチャージ金額が1000円であること、チャージ後のバリュー残高が11000円であること、および、バリュー使用時の注意事項が表示される。
図18に戻って、ステップS159aで、データ処理部110は、バリュー発行完了画面で確認操作がされたか否かを判断する。確認操作がされたと判断した場合(ステップS159aでYESの場合)、ステップS159bで、データ処理部110は、図39(b)で説明した起動時初期画面を表示部140に表示させる。その後、データ処理部110は、実行する処理をこの処理の呼出元の処理に戻す。
図14に戻って、ステップS1982で、データ処理部110は、記憶部120で管理されている処理状況が、図18のステップS153aで更新される発行情報受信済であるか否かを判断する。
処理状況が発行情報受信済であると判断した場合(ステップS1982においてYESの場合)、データ処理部110は、実行する処理を図18のバリュー発行時処理のステップS154に進める。これによって、データ処理部110は、ステップS153でバリュー発行情報を受信したが、ステップS154からステップS157までのリモート発行サーバ400とのやり取りにおいて、通信障害等によりバリューの書込みができなかった場合、再度、ステップS152でバリュー発行要求情報を電子マネー管理サーバ200に送信することなく、ステップS154で書込処理開始要求をリモート発行サーバ400に送信する。
具体的には、ステップS153aで記憶部120にて管理している処理状況を発行情報受信済に更新した後、バリューの書込みが完了する前にリモート発行サーバ400との通信が切断され、ユーザが図39(a)に示す画面から電子マネーアプリ111の起動操作を実施した場合に、図11に示す電子マネーアプリ111の処理において、ステップS120、ステップS180、ステップS1100、ステップS1110およびステップS191がすべてNOと判断され、ステップS198の処理状況確認処理が実行される。
そして、図14に示す処理状況確認処理のステップS1982において記憶部120で管理している処理状況が発行情報受信済であると判断され、図18のステップS152(バリュー発行要求情報の送信)を経由することなくステップS154に進み、リモート発行サーバ400に対して書込処理開始要求(書込要求情報)が送信される。すなわち、この場合には、ユーザから電子マネーアプリ111の起動操作を受付けることが、電子マネーの発行を要求するための発行操作を受付けることに該当する。
また、上記のようにリモート発行サーバ400との通信が切断された後、前記発行操作として、前記電子メールに添付された引継ぎ情報としてのリンクの操作をユーザから受付けた場合には、図11に示す電子マネーアプリ111の処理において、ステップS191でYESと判断されてステップS150のバリュー発行時処理が実行される。
そして、図18に示すバリュー発行時処理のステップS151において、記憶部120で管理している処理状況が発行情報受信済であると判断され、ステップS152(バリュー発行要求情報の送信)を経由することなくステップS154に進み、リモート発行サーバ400に対して書込処理開始要求(書込要求情報)が送信される。
これにより、電子マネー管理サーバ200では、ステップS279において発行情報DB222の処理状況(発行状況)が発行済に更新されているにもかかわらず、再度バリュー発行要求情報が送信され、電子マネー管理サーバ200における処理状況が発行済であるため、発行要求が受付けられずに、その後の書込処理に移行できず、バリューの書込みを受けられないという不都合を回避できる。
一方、処理状況が発行情報受信済でないと判断した場合(ステップS1982においてNOの場合)、データ処理部110は、実行する処理をステップS1983に進める。ステップS1983以降の処理については、後述する。
(決済金融機関が直接決済の場合のバリューの決済およびチャージの説明)
図15に戻って、携帯電話100においては、ステップS134で受信された残高情報に含まれる金融機関指定情報で示される金融機関が直接決済に対応する金融機関であると判断した場合(ステップS147でYESの場合)、ステップS148で、データ処理部110は、直接決済購入処理を実行する。
図20は、本実施の形態における携帯電話100により実行されるバリュー購入時処理のサブルーチンである直接決済購入処理の流れを示すフローチャートである。図20を参照して、図41(c)の画面でユーザにより合計金額が確認された旨を示す確認通知が、電子マネー管理サーバ200に送信される。
図16に戻って、電子マネー管理サーバ200においては、ステップS246で読出した金融機関指定情報で示される金融機関が直接決済に対応する金融機関であると判断した場合(ステップS264aでYESの場合)、ステップS264bで、データ処理部210は、直接決済発行処理を実行する。
図21は、本実施の形態における電子マネー管理サーバ200により実行されるバリュー購入時アプリケーションプログラム212のサブルーチンである直接決済発行処理の流れを示すフローチャートである。図21を参照して、まず、ステップS2641で、データ処理部210は、携帯電話100から合計金額の確認通知が受信されたか否かを判断する。確認通知が受信されていないと判断した場合(ステップS2641でNOの場合)、データ処理部210は、ステップS2641の処理を繰返す。
一方、確認通知が受信されたと判断した場合(ステップS2641でYESの場合)、ステップS2642で、データ処理部210は、ステップS246で読出した金融機関指定情報で示される金融機関の金融機関サーバ500Aに、購入バリューの決済を要求するための決済要求情報を送信する。決済要求情報には、ステップS262で算出した合計金額、ならびに、利用者情報DB221に登録されている口座番号およびパスワードが含まれる。
このように、電子マネー管理サーバ200は、図16のステップS264aにおいて、ユーザから指定され、利用者情報DB221に記憶されている金融機関指定情報から特定される金融機関が直接決済対応の金融機関(第2の金融機関)であると判定したことを条件として、ステップS2642においてチャージ額の決済を要求する決済要求情報(第2決済要求)を金融機関サーバ500Aに送信しており、当該ステップS2642により、本発明の決済要求送信手段が構成されている。具体的には、利用者情報DB221に前記携帯端末情報に対応付けて記憶されている口座番号およびパスワードを含み、当該口座番号の口座からの決済を要求する決済要求情報を送信する。
ステップS246で読出した金融機関指定情報で示される金融機関の金融機関サーバ500Aは、電子マネー管理サーバ200から受信した決済要求情報に含まれるパスワードが正しいか否かを判断する。パスワードが正しければ、金融機関サーバ500Aは、当該決済要求情報に含まれる口座番号で示される口座から、当該決済要求情報に含まれる合計金額を決済する。決済の完了後、金融機関サーバ500Aは、決済が完了したことを通知するための決済完了通知を電子マネー管理サーバ200に送信する。
電子マネー管理サーバ200においては、ステップS2643で、データ処理部210は、金融機関サーバ500Aから決済完了通知を受信したか否かを判断する。決済完了通知を受信していないと判断した場合(ステップS2643でNOの場合)、データ処理部210は、ステップS2643の処理を繰返す。
一方、決済完了通知を受信したと判断した場合(ステップS2643でYESの場合)、ステップS2651で、データ処理部210は、ステップS2641で確認通知を送信してきた携帯電話100でのバリューの初回購入であるか否かを判断する。このステップS2651からステップ2655までの処理は、前述の図17で説明したステップS2702からステップS2707までの処理と同様であるので、重複する説明は繰返さない。
ステップS2655の後、ステップS2656で、データ処理部210は、バリュー発行情報を携帯電話100に送信する。バリュー発行情報については、前述の図19のステップS277で説明したので、重複する説明は繰返さない。
図20に戻って、携帯電話100においては、ステップS1472で、データ処理部110は、電子マネー管理サーバ200からバリュー発行情報を受信したか否かを判断する。このステップS1472からステップS1474までの処理は、前述の図18のステップS153からステップS153bまでの処理と同様であるので、重複する説明は繰返さない。
図21に進んで、電子マネー管理サーバ200においては、ステップS2657で、データ処理部210は、携帯電話100から受信応答情報を受信したか否かを判断する。このステップS2657からステップS2658までの処理は、前述の図19のステップS278からステップS279までの処理と同様であるので、重複する説明は繰返さない。ステップS2658の後、データ処理部210は、実行する処理をこの直接決済発行処理の呼出元のバリュー購入時AP212に戻す。バリュー購入時AP212に処理を戻した後、データ処理部210は、実行する処理をステップS241の処理に戻す。
図20に戻って、次に、ステップS1481で、データ処理部110は、書込処理開始要求情報をリモート発行サーバ400へ送信する。このステップS1481からステップS1485までの処理は、前述の図18のステップS154からステップS157までの処理と同様であるので、重複する説明は繰返さない。
図43は、本実施の形態における電子マネーシステム10において直接決済対応の金融機関で決済が行なわれて携帯電話100にバリューをチャージするときに携帯電話100の表示部140に表示される第1の表示画面図である。
図43(a)は、ステップS1471からステップS1485までの処理が実行されている間、つまり、直接決済に対応する金融機関においてバリューの決済が行なわれ、そのバリューが携帯電話100にチャージされるまでの間に、携帯電話100の表示部140に表示される画面である。図43(a)の画面には、金融機関で決済中である旨の文章、および、全決済プロセスのうちの経過したプロセスの割合の概略を示すグラフが表示される。
図20に戻って、携帯電話100においては、ステップS1486で、データ処理部110は、非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域からバリュー残高を取得して、バリュー発行完了画面を表示部140に表示させる。
図43に進んで、図43(b)の画面は、前述した図44(d)のバリュー発行完了画面と同様であるので、重複する説明は繰返さない。
図20に戻って、ステップS1487で、データ処理部110は、バリュー発行完了画面で確認操作がされたか否かを判断する。確認操作がされたと判断した場合(ステップS1487でYESの場合)、ステップS1488で、データ処理部110は、図39(b)で説明した起動時初期画面を表示部140に表示させる。その後、データ処理部110は、実行する処理をこの処理の呼出元の処理に戻す。
以上のように、電子マネー管理サーバ200は、ステップS2642において送信した決済要求情報(第2決済要求)に対する決済完了を示す決済完了通知(第2決済完了通知)を、金融機関サーバ500Aから(金融機関専用ネットワーク920を介することなく)受信したことを条件として、携帯電話100に対してバリューをチャージするための第2チャージ処理として、ステップS2656においてバリュー発行情報を送信する処理、つまりは携帯電話100に電子マネーをチャージする処理を行なっており、当該ステップS2656により、本発明のチャージ処理手段が構成されている。
以上説明したように、本実施例においては、ユーザから指定された金融機関が間接決済対応金融機関か直接決済対応金融機関かによって、電子マネーをチャージするための処理が異なっている。
具体的には、間接決済対応金融機関が指定されている場合には、携帯電話100から金融機関サーバ500にアクセスして決済をする都合上、携帯電話100と電子マネー管理サーバ200との通信が一旦分断されてしまう。そのため、金融機関サーバ500における決済が終了し、電子マネー管理サーバ200に消込速報が通知されて、発行情報DB222にバリューが登録され発行可能な状態となった段階で、その旨をユーザに認識させるために、電子メールを送信し、その後ユーザが発行のための操作を行なうことにより、バリュー発行処理が行なわれ、バリューが携帯電話100にチャージされる。
一方、直接決済対応金融機関が指定されている場合には、電子マネー管理サーバ200と金融機関サーバ500Aとが、決済要求情報および決済完了通知の送受信を直接実施するので、携帯電話100と電子マネー管理サーバ200との通信が途中で分断されることがない。そのため、電子マネー管理サーバ200が金融機関サーバ500Aから決済完了通知を受信したことに応じて、引続きバリュー発行処理が行なわれ、バリューが携帯電話100にチャージされる。
(電子マネーシステム10でのバリュー預けの説明)
図45は、本実施の形態における電子マネーシステム10において携帯電話100から電子マネー管理サーバ200にバリューを預けるときに携帯電話の表示部に表示される第1の表示画面図である。図45(a)の画面は、図11のステップS192で表示される起動時初期画面である。図45(a)の画面は、前述した図39(a)の画面と同様であるので、重複する説明は繰返さない。ただし、図45(a)の画面では、「バリュー預け」のリンクが選択候補として網掛け表示されている。
図11に戻って、ステップS195で、データ処理部110は、バリュー預けが選択されたか否かを判断する。図45(a)の画面で「バリュー預け」のリンクが選択されると、データ処理部110は、バリュー預けが選択されたと判断し(ステップS195でYES)、ステップS160で、バリュー預け処理を実行する。
図22は、本実施の形態における携帯電話100により実行される電子マネーアプリ111のサブルーチンであるバリュー預け処理の流れを示すフローチャートである。図22を参照して、まず、ステップS1601で、データ処理部110は、非接触型ICチップ190の記憶部192からバリュー残高を取得する。
次に、ステップS1602で、データ処理部110は、ステップS1601で取得したバリュー残高を示すバリュー残高情報と会員IDと携帯端末情報とを含む残高移行依頼情報を電子マネー管理サーバ200に送信する。
図23は、本実施の形態における電子マネー管理サーバ200により実行されるバリュー預かりアプリケーションプログラム215の処理の流れを示すフローチャートである。図23を参照して、まず、ステップS2061で、データ処理部210は、携帯電話100から残高移行依頼情報を受信したか否かを判断する。残高移行依頼情報を受信していないと判断した場合(ステップS2061でNOの場合)、データ処理部210は、実行する処理をステップS2161に進める。
一方、残高移行依頼情報を受信したと判断した場合(ステップS2061でYESの場合)、データ処理部210は、ステップS2062で、残高移行依頼情報に含まれる会員IDおよび携帯端末情報が利用者情報DB221に登録されたものであり、携帯電話100が電子マネー遊技使用サービスで利用可能なものであるか否かを判断する。利用可能なものでないと判断した場合(ステップS2062でNOの場合)、ステップS2063で、データ処理部210は、使用不可画面を携帯電話100に送信し、実行する処理をステップS2161に進める。
図45に進んで、図45(b)は、ステップS2063で送信される使用不可画面である。図45(b)の画面は、図39(c)の画面と同様であるので、重複する説明は繰返さない。
図23に戻って、一方、利用可能なものであると判断した場合(ステップS2062でYESの場合)、ステップS2064aで、データ処理部210は、図4に示す利用者情報DB221の処理状況が削除応答済であるか否かを判断する。処理状況は、後述するように、ステップS2066で送信する残高移行応答情報に対する受信応答情報が携帯電話100から受信されることを条件として、ステップS2068で削除応答済に更新される。
処理状況が削除応答済であると判断した場合(ステップS2064aにおいてYESの場合)、データ処理部210は、実行する処理をステップS2061の処理に戻し、残高移行依頼(削除要求)を受付けない。一方、処理状況が削除応答済でないと判断した場合(ステップS2064aにおいてNOの場合)、ステップS2064で、データ処理部210は、購入済みであるが携帯電話100にチャージされていない未チャージバリューがあるか否かを判断する。ステップS2064の処理は、図16のステップS244の処理と同様であるので、重複する説明は繰返さない。
未チャージバリューがあると判断した場合(ステップS2064でYESの場合)、データ処理部210は、ステップS2065で、チャージ誘導画面を携帯電話100に送信し、実行する処理を前述した図19のステップS277に進めることで、当該未チャージバリューに対応するバリュー発行情報がステップS277において送信される。
図45に進んで、図45(c)は、ステップS2065で送信されるチャージ誘導画面である。図45(c)の画面は、図39(d)の画面と同様であるので、重複する説明は繰返さない。この画面が表示された後、前述した図19のバリュー発行時AP213のステップS277からの処理が実行され、チャージされていないバリューが携帯電話100にチャージされる。
一方、未チャージバリューがないと判断した場合(ステップS2064でNOの場合)、ステップS2066で、データ処理部210は、残高移行応答情報をステップS2061で受信した残高移行依頼情報に含まれる携帯端末情報で示される携帯電話100に送信する。残高移行応答情報には、ステップS2061で受信した残高移行依頼情報に含まれる会員IDと携帯端末情報とに対応して利用者情報DB221に記憶されている電子メールアドレス、および、処理開始情報が含まれる。処理開始情報は、携帯電話100の非接触型ICチップ190の記憶部192に確保されている電子マネー遊技使用サービス用の記憶領域を削除する領域削除処理を実行するためにリモート発行サーバ400に送信する情報である。なお、残高移行応答情報は、ステップS2064aでNOの場合、すなわち、処理状況(削除状況)が未実行であることを条件として送信される。
図22に戻って、ステップS1603で、データ処理部110は、電子マネー管理サーバ200から残高移行応答情報を受信したか否かを判断する。残高移行応答情報を受信したと判断した場合(ステップS1603でYESの場合)、ステップS1604で、データ処理部110は、アドレス確認画面を表示部140に表示させる。
図46は、本実施の形態における電子マネーシステム10において携帯電話100から電子マネー管理サーバ200にバリューを預けるときに携帯電話100の表示部140に表示される第2の表示画面図である。図46(a)は、ステップS1604で携帯電話100に表示されるアドレス確認画面である。図46(a)の画面には、バリューの預かりに関する説明の文章、ステップS1603で受信した残高移行応答情報に含まれる電子メールアドレス、表示されている電子メールアドレスが利用している携帯電話100の電子メールアドレスと異なる場合に電子メールアドレスを変更するためのリンクである「→上記アドレスがご利用携帯のアドレスと異なる場合はこちら。」、および、表示されている電子メールアドレスが正しいことを入力するためのリンクである「確認」が表示される。
図22に戻って、ステップS1605で、データ処理部110は、「確認」のリンクが選択されることによって、確認の入力があったか否かを判断する。確認の入力があったと判断した場合(ステップS1605でYESの場合)、ステップS1606で、データ処理部110は、パスワード入力画面を表示部140に表示させる。
図46に進んで、図46(b)は、ステップS1606で携帯電話100に表示されるパスワード入力画面である。図46(b)の画面には、預けたバリューの返却を受けるときに必要となるパスワードの入力を促がす旨の文章、ユーザが決めたパスワードを入力するためのパスワード入力欄、入力されたパスワードの確認の再入力をするためのパスワード確認用再入力欄、入力したパスワードを確認して決定するためのリンクである「確認」が表示される。
図22に戻って、ステップS1607で、データ処理部110は、「確認」のリンクが選択されることによって、確認の入力があったか否かを判断する。確認の入力があったと判断した場合(ステップS1607でYESの場合)、ステップS1607aで、データ処理部110は、記憶部120で管理している処理状況を、残高移行応答受信済に更新する。そして、ステップS1607bで、データ処理部110は、残高移行応答情報を受信したことを電子マネー管理サーバ200に知らせるための受信応答情報を、電子マネー管理サーバ200に送信する。
図23に進んで、ステップS2067で、データ処理部210は、携帯電話100から受信応答情報を受信したか否かを判断する。受信応答情報を受信していないと判断した場合(ステップS2067においてNOの場合)、データ処理部210は、ステップS2067の処理を繰返す。一方、受信応答情報を受信したと判断した場合(ステップS2067においてYESの場合)、ステップS2068で、データ処理部210は、図4に示す利用者情報DB221の処理状況を削除応答済に更新する。
図22に戻って、次に、ステップS1611で、データ処理部110は、領域削除処理開始要求をリモート発行サーバ400へ送信する。領域削除処理開始要求には、ステップS1603で受信した残高移行応答情報に含まれる処理開始情報に基づいて作成した領域削除処理を実行するための処理IDなどのパラメータ、および、携帯端末情報が含まれる。
図1に戻って、リモート発行サーバ400は、領域削除開始要求に含まれる携帯端末情報で示される携帯電話100の非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域を削除するための領域削除実行情報を、携帯端末情報で示される携帯電話100に送信する。
図22に進んで、データ処理部110は、ステップS1612で、リモート発行サーバ400から領域削除実行情報を受信したか否かを判断する。領域削除実行情報を受信したと判断した場合(ステップS1612でYESの場合)、ステップS1613で、データ処理部110は、リモート発行サーバ400から受信した領域削除実行情報で示される領域削除処理を実行する。領域削除処理は、領域削除実行情報で示される非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域を削除する処理である。
具体的には、この領域削除処理においては、リモート発行サーバ400は、電子マネーアプリ111を介して、非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域を削除する。そして、記憶領域の削除が終了した場合、リモート発行サーバ400は、領域削除終了情報を携帯電話100に送信する。
なお、ここでは、リモート発行サーバ400は、電子マネーアプリ111を介して、記憶領域を削除するようにした。しかし、これに限定されず、リモート発行サーバ400は、電子マネーアプリ111を介さずに、非接触型ICチップ190と直接やり取りして、記憶領域を削除するようにしてもよい。
また、リモート発行サーバ400は、非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域を削除したことを条件として、ステップS1611で携帯電話100から送信された領域削除処理開始要求に含まれる携帯端末情報と対応付けて、処理状況を削除終了済として記憶する。
なお、データ処理部110は、非接触型ICチップ190の制御部191に対して領域削除要求信号を送信し、制御部191が記憶部192の電子マネー遊技使用サービス用の記憶領域を削除するようにしてもよい。
次いで、データ処理部110は、ステップS1614で、リモート発行サーバ400から領域削除終了情報を受信したことによって、領域削除処理が終了したか否かを判断する。領域削除処理が終了したと判断した場合(ステップS1614でYESの場合)、ステップS1614aで、データ処理部110は、記憶部120で管理している処理状況を、削除済に更新する。次に、データ処理部110は、ステップS1615で、電子マネー遊技使用サービス用の記憶領域の削除が完了したことを通知するための通知であって、ステップS1607で入力されたパスワードと携帯端末情報とを含む移行完了通知を電子マネー管理サーバ200に送信する。
図23に進んで、ステップS2161で、データ処理部210は、携帯電話100から移行完了通知を受信したか否かを判断する。移行完了通知を受信していないと判断した場合(ステップS2161でNOの場合)、データ処理部210は、実行する処理をステップS2061に戻す。
一方、移行完了通知を受信したと判断した場合(ステップS2161でYESの場合)、データ処理部210は、ステップS2162で、携帯電話100からのバリューの預かりに対して割振られた番号であるお預かり番号を発行し、ステップS2163で、発行したお預かり番号と、ステップS2061で受信した残高移行依頼情報に含まれるバリュー残高情報で示されるバリュー残高である預かり残高と、ステップS2161で受信した移行完了通知に含まれるパスワードと、携帯端末情報とを対応させて記憶部220に記憶させる。つまり、携帯端末情報と対応して記憶されるお預かり番号、預かり残高、および、パスワードが、当該携帯端末情報と対応付けて利用者情報DB221に記憶されている処理状況と対応付けられて、記憶部220に登録されることとなる。
そして、ステップS2164で、データ処理部210は、ステップS2162で発行したお預かり番号を携帯電話100に送信する。また、ステップS2165で、データ処理部210は、ステップS2162で発行したお預かり番号を付した電子メールであるお預かり番号通知メールを携帯電話100の電子メールアドレス宛に送信する。その後、データ処理部210は、実行する処理をステップS2061に戻す。
図22に戻って、ステップS1616で、データ処理部110は、電子マネー管理サーバ200からお預かり番号を受信したか否かを判断する。お預かり番号を受信したと判断した場合(ステップS1616でYESの場合)、ステップS1617で、データ処理部110は、残高移行完了画面を表示部140に表示させる。
図46に進んで、図46(c)の画面は、ステップS1617で表示される残高移行完了画面である。図46(c)の画面には、バリューの預けが完了した旨の文章、ステップS1616で受信したお預かり番号、および、預けたバリューの返却に関する説明の文章が表示される。
図22に戻って、ステップS1618で、データ処理部110は、残高移行完了画面で確認操作がされたか否かを判断する。確認操作がされたと判断した場合(ステップS1618でYESの場合)、ステップS1619で、データ処理部110は、図39(b)で説明した起動時初期画面を表示部140に表示させる。その後、データ処理部110は、実行する処理をこの処理の呼出元の処理に戻す。
以上のように、バリュー預け処理においては、バリューの預けだけでなく、非接触型ICチップ190の記憶部192に構築された電子マネー遊技使用サービス用の記憶領域の削除処理が行なわれ、当該削除処理により記憶部192に記憶されたデータとしての電子マネー(バリュー)も削除される。
つまり、図45(a)に示す画面において、「バリュー預け」メニューが選択されたことに基づいて、記憶部192に記憶された電子マネーの削除が行なわれることから、同画面において「バリュー預け」メニューの選択操作を受付けることが、データとして電子マネーの削除を要求するための削除操作を受付けることに相当する。また、その選択操作に応じて図22のバリュー預け処理のステップS1602において電子マネー管理サーバ200に残高移行依頼情報を送信することが、データとして電子マネーの削除を要求するための削除要求情報を送信することに相当する。
また、電子マネー管理サーバ200は、図4に示す利用者情報DB221の処理状況において、携帯電話100の非接触型ICチップ190の記憶部192の電子マネーを削除するための削除用処理が実行済か否かを管理している。具体的には、電子マネー管理サーバ200は、削除用処理として、図23に示すステップS2066で残高移行応答情報(削除応答情報)を送信し、ステップS2067で受信応答情報を受信する処理を行ない、これに基づいて該処理状況の項目を削除応答済に更新するため、該処理状況の項目が削除応答済か否かにより削除用処理が実行済か否かが示される。
図14に戻って、ステップS1983で、データ処理部110は、記憶部120で管理されている処理状況が、図22のステップS1607aで更新される残高移行応答受信済であるか否かを判断する。
処理状況が残高移行応答受信済であると判断した場合(ステップS1983においてYESの場合)、データ処理部110は、実行する処理を図22のバリュー預け処理のステップS1611に進める。これによって、データ処理部110は、ステップS1603で残高移行応答情報を受信したが、ステップS1611からステップS1614までのリモート発行サーバ400とのやり取りにおいて、通信障害等により電子マネー遊技使用サービス用の記憶領域を削除できなかった場合、再度、ステップS1602で残高移行依頼情報を電子マネー管理サーバ200に送信することなく、ステップS1611で領域削除処理開始要求をリモート発行サーバ400に送信する。
つまり、ステップS1607aで記憶部120にて管理している処理状況を残高移行応答受信済(削除応答情報受信済)に更新した後、電子マネー遊技使用サービス用の記憶領域(バリュー)の削除が完了する前にリモート発行サーバ400との通信が切断され、ユーザが図39(a)に示す画面から電子マネーアプリ111の起動操作を実施した場合に、図11に示す電子マネーアプリ111の処理においてステップS120、ステップS180、ステップS1100、ステップS1110およびステップS191がすべてNOと判断され、ステップS198の処理状況確認処理が実行される。
そして、図14に示す処理情報確認処理のステップS1983において記憶部120で管理している処理状況が残高移行応答受信済であると判断され、図22のステップS1602(削除要求情報としての残高移行依頼情報の送信)を経由することなくステップS1611に進み、リモート発行サーバ400に対して削除処理開始要求(削除開始要求情報)が送信される。
これにより、電子マネー管理サーバ200ではステップS2068において図4に示す利用者情報DB221の処理状況(削除状況)が削除応答済(削除済)に更新されているにもかかわらず、再度残高移行依頼情報(削除要求情報)が送信され、電子マネー管理サーバ200における処理状況が削除済であるため、削除要求が受付けられずに、その後の削除処理に移行できず、バリュー(電子マネー遊技使用サービス用の記憶領域)の削除を行なえない(換言すればバリュー預けを行なえない)という不都合を回避できる。
一方、処理状況が残高移行応答受信済でないと判断した場合(ステップS1983においてNOの場合)、データ処理部110は、実行する処理をステップS1984に進める。ステップS1984以降の処理については、後述する。
(電子マネーシステム10でのバリューの返却の説明)
図47は、本実施の形態における電子マネーシステム10において電子マネー管理サーバ200に預けたバリューの返却を受けるときに携帯電話100の表示部140に表示される第1の表示画面図である。図47(a)の画面は、図11のステップS192で表示される起動時初期画面である。図47(a)の画面は、前述した図39(a)の画面と同様であるので、重複する説明は繰返さない。ただし、図47(a)の画面では、「預けバリュー返却」のリンクが選択候補として網掛け表示されている。
図11に戻って、ステップS196で、データ処理部110は、バリュー返却が選択されたか否かを判断する。図47(a)の画面で「預けバリュー返却」のリンクが選択されると、データ処理部110は、バリュー返却が選択されたと判断し(ステップS196でYES)、ステップS170で、バリュー返却処理を実行する。
図24は、本実施の形態における携帯電話100により実行される電子マネーアプリ111のサブルーチンであるバリュー返却処理の流れを示すフローチャートである。図24を参照して、まず、ステップS1701で、データ処理部110は、非接触型ICチップ190の記憶部192からバリュー残高を取得する。
次に、ステップS1702で、データ処理部110は、ステップS1701で取得したバリュー残高を示すバリュー残高情報と会員IDと携帯端末情報とを含む残高返却依頼情報を電子マネー管理サーバ200に送信する。
図25は、本実施の形態における電子マネー管理サーバ200により実行されるバリュー返却アプリケーションプログラム216の処理の流れを示すフローチャートである。図25を参照して、まず、ステップS2071で、データ処理部210は、携帯電話100から残高返却依頼情報を受信したか否かを判断する。残高返却依頼情報を受信していないと判断した場合(ステップS2071でNOの場合)、データ処理部210は、実行する処理をステップS2171に進める。
一方、残高返却依頼情報を受信したと判断した場合(ステップS2071でYESの場合)、データ処理部210は、ステップS2072で、残高返却依頼情報に含まれる会員IDおよび携帯端末情報が利用者情報DB221に登録されたものであり、携帯電話100が電子マネー遊技使用サービスで利用可能なものであるか否かを判断する。利用可能なものでないと判断した場合(ステップS2072でNOの場合)、ステップS2063で、データ処理部210は、使用不可画面を携帯電話100に送信し、実行する処理をステップS2171に進める。
図47に進んで、図47(b)は、ステップS2073で送信される使用不可画面である。図47(b)の画面は、図39(c)の画面と同様であるので、重複する説明は繰返さない。
図25に戻って、一方、利用可能なものであると判断した場合(ステップS2072でYESの場合)、ステップS2074aで、データ処理部210は、図4に示す利用者情報DB221の処理状況(返却状況)が返却済であるか否かを判断する。処理状況は、後述するように、ステップS2272で送信されるバリュー返却情報に対する受信応答情報が携帯電話100から受信されることを条件として、ステップS2274で返却済に更新される。
処理状況が返却済であると判断した場合(ステップS2074aにおいてYESの場合)、データ処理部210は、実行する処理をステップS2071の処理に戻す。一方、処理状況が返却済でないと判断した場合(ステップS2074aにおいてNOの場合)、ステップS2074で、データ処理部210は、購入済みであるが携帯電話100にチャージされていない未チャージバリューがあるか否かを判断する。ステップS2074の処理は、図16のステップS244の処理と同様であるので、重複する説明は繰返さない。
未チャージバリューがあると判断した場合(ステップS2074でYESの場合)、データ処理部210は、ステップS2075で、チャージ誘導画面を携帯電話100に送信し、実行する処理を前述した図19のステップS277に進める。
図47に進んで、図47(c)は、ステップS2075で送信されるチャージ誘導画面である。図47(c)の画面は、図39(d)の画面と同様であるので、重複する説明は繰返さない。この画面が表示された後、前述した図19のバリュー発行時AP213のステップS277からの処理が実行され、チャージされていないバリューが携帯電話100にチャージされる。
図25に戻って、一方、未チャージバリューがないと判断した場合(ステップS2074でNOの場合)、ステップS2076で、データ処理部210は、番号入力指示情報をステップS2071で受信した残高返却依頼情報に含まれる携帯端末情報で示される携帯電話100に送信する。番号入力指示情報は、携帯電話100で後述する番号入力画面を表示させる契機となる情報である。
図24に戻って、ステップS1703で、データ処理部110は、電子マネー管理サーバ200から番号入力指示情報を受信したか否かを判断する。番号入力指示情報を受信したと判断した場合(ステップS1703でYESの場合)、ステップS1704で、データ処理部110は、番号入力画面を表示部140に表示させる。
図48は、本実施の形態における電子マネーシステム10において電子マネー管理サーバ200に預けたバリューの返却を受けるときに携帯電話100の表示部140に表示される第2の表示画面図である。図48(a)は、ステップS1704で携帯電話100に表示される番号入力画面である。図48(a)の画面には、バリューを預けたときに発行されたお預かり番号とユーザによって定められたパスワードとの入力を求める旨の文章、お預かり番号を入力するためのお預かり番号入力欄、パスワードを入力するためのパスワード入力欄、および、入力したお預かり番号とパスワードとを確認して電子マネー管理サーバ200に送信するためのリンクである「確認」が表示される。
図24に戻って、ステップS1705で、データ処理部110は、「確認」のリンクが選択されることによって、確認の入力があったか否かを判断する。確認の入力があったと判断した場合(ステップS1705でYESの場合)、ステップS1706で、データ処理部110は、入力されたお預かり番号およびパスワード、ならびに、携帯端末情報を含む預かり番号情報(預かり残額返却要求情報)を電子マネー管理サーバ200に送信する。
図25に進んで、ステップS2171で、データ処理部210は、携帯電話100からお預かり番号、パスワードおよび携帯端末情報を含む預かり番号情報を受信したか否かを判断する。受信していないと判断した場合(ステップS2171でNOの場合)、データ処理部210は、実行する処理をステップS2271に進める。一方、受信したと判断した場合(ステップS2171でYESの場合)、ステップS2172で、データ処理部210は、ステップS2171で受信した預かり番号情報に含まれるお預かり番号およびパスワードが記憶部220に存在するか否かを判断する。
お預かり番号およびパスワードが存在しないと判断した場合(ステップS2172でNOの場合)、ステップS2173で、データ処理部210は、ステップS2171で受信した携帯端末情報で示される携帯電話100に番号エラー画面を送信し、実行する処理をステップS2271に進める。
図48に進んで、図48(b)は、ステップS2173で携帯電話100に送信される番号エラー画面である。図48(b)の画面には、受信したお預かり番号またはパスワードが記憶部220に存在しない旨の文章、および、再度、番号入力画面を表示させるためのリンクである「OK」が表示される。
図25に戻って、お預かり番号およびパスワードが存在すると判断した場合(ステップS2172でYESの場合)、ステップS2174で、データ処理部210は、ステップS2171で受信したお預かり番号およびパスワードに対応して記憶部220に記憶された携帯端末情報と、ステップS2171で受信した携帯端末情報とが一致するか否かを判断する。
携帯端末情報が一致すると判断した場合(ステップS2174でYESの場合)、本来機種変更されているので携帯端末情報が異なるはずであるのに携帯端末情報が一致していることとなり何らかの不正の疑いがあるので、バリューの返却処理を行なうことなく、ステップS2175で、データ処理部110は、携帯端末一致エラー画面を携帯電話100に送信し、実行する処理をステップS2271に進める。携帯端末一致エラー画面には、図48(b)で説明した番号エラー画面のお預かり番号またはパスワードが記憶部220に存在しない旨の文書に替えて、バリューを預ける前の携帯端末情報とバリューの返却を受けようとしている携帯端末情報とが一致する旨の文章が表示される。
一方、携帯端末情報が一致しないと判断した場合(ステップS2174でNOの場合)、ステップS2176で、データ処理部210は、ステップS2171で受信したお預かり番号とパスワードとに対応して記憶部220に記憶された預かり残高を読出す。
そして、ステップS2177で、データ処理部210は、ステップS2071で受信した残高返却依頼情報に含まれるバリュー残高情報で示されるバリュー残高と、ステップS2176で読出した預かり残高とを加算した金額が、携帯端末情報と対応して利用者情報DB221に記憶された携帯上保持限度額以下であるか否かを判断する。つまり、預かり残高とバリュー残高との合計額、および携帯上保持限度額に基づいて預かり残高の返却を許容するか否かを判定する。
携帯上保持限度額以下でないと判断した場合(ステップS2176でNOの場合)、ステップS2178で、データ処理部210は、バリューの返却処理を行なうことなく、携帯上保持限度額返却不可画面を携帯電話100に送信し、実行する処理をステップS2271に進める。携帯上保持限度額返却不可画面には、図48(b)で説明した番号エラー画面のお預かり番号またはパスワードが記憶部220に存在しない旨の文章に替えて、バリュー残高と預かり残高とを加算した額が携帯上保持限度額を超えるので預かり残高を返却することができない旨の文章が表示される。
一方、携帯上保持限度額以下であると判断した場合(ステップS2176でYESの場合)、ステップS2179で、データ処理部210は、ステップS2176で読出した預かり残高を示す預かり残高情報を、ステップS2171で受信した携帯端末情報で示される携帯電話100に送信する。
図24に戻って、ステップS1711で、データ処理部110は、電子マネー管理サーバ200から預かり残高情報を受信したか否かを判断する。預かり残高情報を受信していないと判断した場合(ステップS1711でNOの場合)、ステップS1711aで、データ処理部110は、電子マネー管理サーバ200から携帯上保持限度額返却不可画面を受信したか否かを判断する。携帯上保持限度額返却不可画面を受信していないと判断した場合(ステップS1711aでNOの場合)、データ処理部110は、実行する処理をステップS1711の処理に戻す。
一方、携帯上保持限度額返却不可画面を受信したと判断した場合(ステップS1711aでYESの場合)、ステップS1711bで、データ処理部110は、携帯上保持限度額返却不可画面を表示部140に表示させる。その後、データ処理部110は、実行する処理をステップS1726に進める。
一方、預かり残高情報を受信したと判断した場合(ステップS1711でYESの場合)、ステップS1712で、データ処理部110は、ステップS1711で受信した預かり残高情報で示される預かり残高を含む預かり残高返却確認画面を表示部140に表示させる。
図48に進んで、図48(c)は、ステップS1711で携帯電話100に表示される預かり残高返却確認画面である。図48の画面には、ステップS1711で受信した預かり残高情報で示される預かり残高、ステップS1701で取得されたバリュー残高、バリューの返却を実行するか否かを確認する旨の文章、および、バリューの返却を実行するためのリンクである「実行」が表示される。
図24に戻って、ステップS1713で、データ処理部110は、「実行」のリンクが選択されることによって、実行の入力があったか否かを判断する。実行の入力があったと判断した場合(ステップS1713でYESの場合)、ステップS1714で、データ処理部110は、返却実行情報を電子マネー管理サーバ200に送信する。返却実行情報は、返却されるバリューを非接触型ICチップ190の記憶部192に記憶させる処理を開始させる契機となるバリュー返却情報の送信を要求するための情報であり、携帯端末情報を含む。
図25に進んで、ステップS2271で、データ処理部210は、携帯電話100から返却実行情報を受信したか否かを判断する。返却実行情報を受信したと判断した場合(ステップS2271でYESの場合)、ステップS2272で、データ処理部210は、返却実行情報に含まれる携帯端末情報で示される携帯電話100に、バリュー返却情報を送信する。
図24に戻って、ステップS1715で、データ処理部110は、電子マネー管理サーバ200からバリュー返却情報を受信したか否かを判断する。バリュー返却情報を受信したと判断した場合(ステップS1715でYESの場合)、ステップS1716で、データ処理部110は、記憶部120で管理している処理状況を、返却情報受信済に更新する。そして、ステップS1717で、データ処理部110は、バリュー返却情報を受信したことを電子マネー管理サーバ200に知らせるための受信応答情報を、電子マネー管理サーバ200に送信する。
図25に進んで、ステップS2273で、データ処理部210は、携帯電話100から受信応答情報を受信したか否かを判断する。受信応答情報を受信していないと判断した場合(ステップS2273においてNOの場合)、データ処理部210は、ステップS2273の処理を繰返す。一方、受信応答情報を受信したと判断した場合(ステップS2273においてYESの場合)、ステップS2274で、データ処理部210は、図4の利用者情報DBの処理状況を返却済に更新する。
図24に戻って、次に、ステップS1721で、データ処理部110は、非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域にステップS1711で受信した預かり残高情報で示される預かり残高のバリューを記憶させる返却バリュー書込み処理を開始させるための情報であって、預かり残高情報および携帯端末情報を含むバリュー返却処理開始要求情報をリモート発行サーバ400に送信する。
図1に戻って、リモート発行サーバ400は、バリュー返却実行情報を、バリュー返却処理開始要求情報に含まれる携帯端末情報で示される携帯電話100に送信する。バリュー返却実行情報は、携帯電話100の非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域に、バリュー返却処理開始要求情報に含まれる預かり残高情報で示される額のバリューを記憶させるための情報である。
図24に進んで、データ処理部110は、ステップS1722で、リモート発行サーバ400からバリュー返却実行情報を受信したか否かを判断する。バリュー返却実行情報を受信したと判断した場合(ステップS1722でYESの場合)、ステップS1723で、データ処理部110は、リモート発行サーバ400から受信したバリュー返却実行情報で示される返却バリュー書込処理を実行する。返却バリュー書込処理は、バリュー返却実行情報で示されるバリューを非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域に書込むための処理である。
具体的には、この返却バリュー書込処理においては、携帯電話100は、電子マネーアプリ111によって、書込みデータである預かり残高情報で示される額のバリューを、リモート発行サーバ400に送信する。リモート発行サーバ400は、電子マネーアプリを介さず、非接触型ICチップ190と直接やり取りして、非接触型ICチップ190の記憶部192に、携帯電話100から受信したバリューを書込む。つまり、リモート発行サーバ400は、非接触型ICチップ190の制御部191に対して前記預かり残高情報で示される額のバリュー(返却バリュー)の書込みを指示し(返却指示情報を送信し)、これに応じて、制御部191が非接触型ICチップ190の記憶部192にバリューの書込みを行なう(つまり、制御部191がデータ返却実行手段を構成する)。この場合、記憶部192の電子マネー遊技使用サービス用の記憶領域に既にバリューが記憶されているときには、既に記憶されているバリューに返却バリューを加算した額のバリューを書込む処理が行なわれるが、かかる処理も返却バリューの書込みに該当する。そして、バリューの書込みが終了した場合、リモート発行サーバ400は、返却バリュー書込終了情報を携帯電話100に送信する。
以上のように、本実施の形態においては、電子マネーアプリ111を介することなく、リモート発行サーバ400の指示に応じて非接触型ICチップ190の制御部191が返却バリューの書込みを行なうように構成したが、これに限定されず、リモート発行サーバ400から返却指示情報を受信したことに応じて、電子マネーアプリ111が制御部191に返却バリューの書込みを指示するようにしてもよい。
また、リモート発行サーバ400は、電子マネー遊技使用サービス用の記憶領域にバリューを書込んだことを条件として、ステップS1721で携帯電話100から送信されたバリュー返却処理開始要求に含まれる携帯端末情報と対応付けて、当該バリューの処理状況を、返却終了済として記憶する。
なお、データ処理部110は、非接触型ICチップ190の制御部191に対して返却バリュー書込要求信号を送信し、制御部191が記憶部192の電子マネー遊技使用サービス用の記憶領域にバリューを書込むものであってもよい。この場合、データ処理部110から制御部191に返却バリュー書込要求信号を送信する処理が、バリューを加算するための処理に該当する。
次いで、データ処理部110は、ステップS1724で、リモート発行サーバ400から返却バリュー書込終了情報を受信したことによって、返却バリュー書込処理が終了したか否かを判断する。返却バリュー書込処理が終了したと判断した場合(ステップS1724でYESの場合)、ステップS1724aで、データ処理部110は、記憶部120で管理している処理状況を、返却済に更新する。次に、データ処理部110は、ステップS1725で、非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域からバリュー残高を取得して、返却完了画面を表示部140に表示させる。
図48に進んで、図48(d)の画面は、ステップS1725で表示される返却完了画面である。図48(d)の画面には、図38(b)の画面と同様のチップID、バリューの返却が完了した旨の文章、返却金額が1000円であること、および、返却後のバリューの残高が1000円であることが表示される。
図24に戻って、ステップS1726で、データ処理部110は、返却完了画面で確認操作がされたか否かを判断する。確認操作がされたと判断した場合(ステップS1726でYESの場合)、ステップS1727で、データ処理部110は、図39(b)で説明した起動時初期画面を表示部140に表示させる。その後、データ処理部110は、実行する処理をこの処理の呼出元の処理に戻す。
図14に戻って、ステップS1984で、データ処理部110は、記憶部120で管理されている処理状況が、図24のステップS1716で更新される返却情報受信済であるか否かを判断する。
処理状況が返却情報受信済であると判断した場合(ステップS1984においてYESの場合)、データ処理部110は、実行する処理を図24のバリュー返却処理のステップS1721に進める。これによって、データ処理部110は、ステップS1715でバリュー返却情報を受信したが、ステップS1721からステップS1724までのリモート発行サーバ400とのやり取りにおいて、通信障害等によりバリューの返却ができなかった場合、再度、ステップS1702で残高返却依頼情報を電子マネー管理サーバ200に送信することなく、ステップS1721でバリュー返却処理開始要求をリモート発行サーバ400に送信する。
具体的には、ステップS1716で記憶部120にて管理している処理状況を返却情報受信済に更新した後、バリューの返却が完了する前にリモート発行サーバ400との通信が切断され、ユーザが図39(a)に示す画面から電子マネーアプリ111の起動操作を実施した場合に、図11に示す電子マネーアプリ111の処理において、ステップS120、ステップS180、ステップS1100、ステップS1110およびステップS191がすべてNOと判断され、ステップS198の処理状況確認処理が実行される。
そして、図14に示す処理状況確認処理のステップS1984において記憶部120で管理している処理状況が返却情報受信済であると判断され、図24のステップS1714(返却実行情報の送信)を経由することなくステップS1721に進み、リモート発行サーバ400に対してバリュー返却処理開始要求(返却要求情報)が送信される。すなわち、この場合には、ユーザから電子マネーアプリ111の起動操作を受付けることが、電子マネーの返却を要求するための返却操作を受付けることに該当する。
これにより、電子マネー管理サーバ200では、ステップS2274において利用者情報DB221の処理状況(返却状況)が返却済に更新されているにもかかわらず、再度残高返却依頼情報が送信され、電子マネー管理サーバ200における処理状況が返却済であるため、残高返却依頼が受付けられずに、その後の返却バリュー書込処理に移行できず、バリューの返却を受けられないという不都合を回避できる。
一方、処理状況が返却情報受信済でないと判断した場合(ステップS1984においてNOの場合)、データ処理部110は、実行する処理をステップS1985に進める。ステップS1985以降の処理については、後述する。
なお、以上のバリュー預けおよび返却に関する処理においては、携帯電話100に通常のバリュー残高のみが存在する場合を説明したが、特典バリューが携帯電話100に記憶されていれば、同様にして、特典バリューの預けおよび返却を行なうようにしてもよい。
(電子マネーシステム10での特典バリューの発行の説明)
本実施の形態においては、バリューを用いてプリペイドカード371を購入したり、球貸を行なったりする取引処理による取引額に応じた特典として特典バリューがその取引処理を行なった携帯電話100に付与される。
図28は、本実施の形態における電子マネー管理サーバ200で特典の付与方法を設定するための特典設定画面である。図28を参照して、特典設定画面には、特典を付与する店舗の名称を入力するための特典付与店舗入力欄、特典を付与するグループの名称を入力するための特典付与グループ入力欄、特典付与店舗を設定するか特典付与グループを設定するかを選択するためのラジオボタン、特典付与グループを設定する場合に当該グループに所属する店舗の名称を入力するためのグループ所属店舗入力欄、特典を付与するための特典基準額を入力するための特典基準額入力欄、特典を付与する単位特典額を入力するための単位特典額入力欄、付与された特典を使用可能な特典使用可能店舗を入力するための特典使用可能店舗入力欄、次の設定に進むための「次設定」ボタン、および、設定を終了するための「終了」ボタンが表示される。
図28の特典設定画面では、たとえば、特典付与店舗入力欄に「D店」、特典付与グループ入力欄に「abcグループ」が入力されている。また、特典付与グループの設定を選択するラジオボタンが選択されている。また、グループ所属店舗入力欄に「A店」,「B店」が入力されている。また、特典基準額「10000」円ごとに単位特典額「500円」が付与される特典設定が入力されている。また、特典使用可能店舗として、全加盟店か、付与店舗・グループかを選択可能であることが示されている。
以上のように、電子マネー管理サーバ200が発行するバリューを使用可能な店舗のうちから選択した店舗の店舗名称を、図28に示す特典設定画面の特典付与店舗入力欄に入力し対応するラジオボタンを選択した後、次設定ボタンまたは終了ボタンを操作することにより、特典付与店舗入力欄に入力された店舗が取引処理に対する特典付与の対象とする特典付与対象店舗として設定され、当該特典付与設定画面により、本発明の対象店舗設定手段が構成されている。そして、該設定された特典付与対象店舗におけるバリューの使用額(取引額)が、同特典設定画面において設定された特典基準額に達するごとに、同特典設定画面において設定された単位特典額の特典バリューが付与されることとなる。
また、特典設定画面の特典付与グループ入力欄にグループ名を入力し対応するラジオボタンを選択しグループ所属店舗入力欄に複数の店舗名を入力した後、次設定ボタンまたは終了ボタンを操作することにより、該入力された複数の店舗が属するグループが設定され、当該特典付与設定画面により、本発明のグループ設定手段が構成されている。そして、該設定されたグループに属する店舗におけるバリューの使用額(取引額)の合計額が、同特典設定画面において設定された特典基準額に達するごとに、同特典設定画面において設定された単位特典額の特典バリューが付与されることとなる。
さらに、特典設定画面においては、特典バリューを使用可能とする店舗を選択可能とされており、具体的には特典使用可能店舗入力欄において、全加盟店で使用可能とするか、付与店舗・グループのみで使用可能とするかを選択可能となっており、当該特典付与設定画面により、本発明の使用可能店舗設定手段が構成されている。そして、全加盟店が選択設定された場合には、電子マネー管理サーバ200の発行したバリューを使用可能な全店舗で特典バリューを使用可能となる。一方、付与店舗・グループが選択設定された場合には、特典バリューの付与の元となった取引の行なわれた店舗またはグループ店舗において特典バリューを使用可能となる。たとえば、D店での取引額が特典基準額に達して付与された特典バリューであればD店でのみ使用可能となり、abcグループに属する店舗での取引額の合計額が特典基準額に達して付与された特典バリューであればabcグループに属するA店およびB店でのみ使用可能となる。
図29は、本実施の形態における電子マネー管理サーバ200が特典を付与する際に用いる特典付与店舗データベースを説明するための図である。図29を参照して、特典付与店舗DBでは、図28の特典設定画面で設定された、特典付与グループ、特典付与店舗、特典基準額、単位特典額、および、使用可能店舗が対応付けて記憶される。
なお、特典付与店舗の欄には、特典付与グループが入力されている場合は、特典付与グループに含まれるグループ所属店舗が記憶される。また、使用可能店舗が「1」である場合は使用可能店舗が特典の付与店舗・グループであることを示し、「0」である場合は使用可能店舗が全加盟店であることを示す。
図29では、たとえば、特典付与グループとして「abcグループ」、グループ所属店舗として「A」店,「B」店、特典基準額として「10000」円、単位特典額として「500」円、使用可能店舗として「1」が記録されている。また、特典付与店舗として「D」店、特典基準額として「5000」円、単位特典額として「300」円、使用可能店舗として「0」が記録されている。
図30は、本実施の形態における電子マネー管理サーバ200が特典を付与する際に用いる特典データベース223を説明するための図である。図30を参照して、特典DB223では、会員IDおよび携帯端末情報に対応付けて、取引店舗、前回特典付与後取引額、合計特典残高、店舗別特典残高、および、使用可能店舗が記憶される。
取引店舗は、ユーザがバリューを用いた店舗である。前回特典付与後取引額は、前回特典を付与した後に、ユーザがバリューを用いて取引店舗で取引した取引額である。前回特典付与後取引額は、後述する図56のS292で、店舗からの取引情報に含まれる取引額分加算され、後述する図27(b)のS2196で、特典付与の対象額分減算される。使用可能店舗は、特典を使用可能な店舗である。店舗別特典残高は、付与されたが未だ使用されていないその使用可能店舗で使用可能な特典の残高である。合計特典残高は、店舗別特典残高の合計である。
図30では、たとえば、会員ID「1101」および携帯端末情報「MN7RE」に対応付けて、合計特典残高として「500」円が記憶されている。
また、会員ID「1101」および携帯端末情報「MN7RE」に対応付けて、取引店舗として「abcグループ」,「D」店が記憶されている。本実施の形態においては、取引が行なわれたグループまたは店舗ごとに、会員IDおよび携帯端末情報に対応付けて、取引店舗が記憶される。取引店舗として「abcグループ」,「D」店のそれぞれに対応して、前回特典付与後取引額として「13000」円,「1000」円が記憶されている。
また、会員ID「1101」および携帯端末情報「MN7RE」に対応付けて、店舗別取引残高として「500」円が記憶されている。本実施の形態においては、使用可能店舗ごとに、会員IDおよび携帯端末情報に対応付けて、店舗別取引残高が記憶される。店舗別取引残高として「500」円に対応して、使用可能店舗として「abcグループ」が記憶されている。
図27は、本実施の形態における電子マネー管理サーバ200により実行される特典通知アプリケーションプログラムおよび特典付与アプリケーションプログラム217の処理の流れを示すフローチャートである。図27(a)は、本実施の形態における電子マネー管理サーバ200により実行される特典通知アプリケーションプログラムの処理の流れを示すフローチャートである。図27(a)を参照して、この特典通知APは、所定期間(たとえば、1ヶ月)ごとに実行される。
まず、ステップS2091で、データ処理部210は、図30の特典DB223から一の携帯電話100の携帯端末情報に対応する取引店舗と前回特典付与後取引額とを抽出する。そして、ステップS2092で、データ処理部210は、抽出された取引店舗に対応して図29の特典付与店舗DBに記憶されている特典基準額に達した前回特典付与後取引額があるか否かを判断する。
携帯端末情報「MN7RE」の携帯電話100の場合、図30の特典DB223から取引店舗として「abcグループ」および「D店」が抽出され、抽出された取引店舗に対応してそれぞれ図29の特典付与店舗DBに記憶されている特典基準額「10000」円および「5000」円に達した前回特典付与後取引額が図30の特典DB223に記憶されているか否かが判断される。ここでは、「D店」での前回特典付与後取引額が「1000」円であり、「D店」の特典基準額に達していないと判断される一方、「abcグループ」での前回特典付与後取引額が「13000」円であり、「abcグループ」の特典基準額「10000」円に達していると判断される。
特典基準額に達した前回特典付与後取引額があると判断した場合(ステップS2092でYESの場合)、ステップS2093で、データ処理部210は、電子マネーアプリ111を起動させるためのリンクが付された電子メールであって特典が付与可能となった旨を示す特典通知メールを、当該前回特典付与後取引額に対応して特典DB223に記憶されている携帯端末情報で示される携帯電話100に送信する。
特典基準額に達した前回特典付与後取引額がないと判断した場合(ステップS2092でNOの場合)、および、ステップS2093の後、ステップS2094で、データ処理部210は、すべての携帯電話100についてステップS2091からステップS2093までの処理が終了したか否かを判断する。
終了していない携帯電話100があると判断した場合(ステップS2094でNOの場合)、それらの携帯電話100についてステップS2091からステップS2093までの処理を実行する。一方、すべての携帯電話について処理が終了したと判断した場合(ステップS2094でYESの場合)、データ処理部210は、この特典通知APを終了する。
図49は、本実施の形態における電子マネーシステム10において携帯電話100に特典が付与されるときに携帯電話100の表示部140に表示される第1の表示画面図である。
図49(a)は、携帯電話100の電子メール機能において、新着メッセージの件数を示す画面である。ここでは、「メール 未読001」の表示によって、新着の電子メールのうち、未読のものが1件であることが示されている。
図49(a)の画面で、「メール 未読001」が選択されると、図49(b)のように、ステップS2093で、電子マネー管理サーバ200から携帯電話100に送信された特典通知メールの内容が表示される。
図49(b)の電子メールには、特典として付与される電子マネーがチャージ可能である旨、および、特典バリューをチャージするための引継ぎ情報としてのリンクである「ここをクリックしてアプリを起動し、ICチップへのチャージを行なってください。」が表示される。図49(b)の画面で、このリンクが選択されると、電子マネーアプリ111が起動される。
図11に戻って、図49(b)の画面で、引継ぎ情報としてのリンクが選択され、電子マネーアプリ111が起動されると、ステップS191aで、データ処理部110は、引継ぎ情報からの起動であると判断して、実行する処理をステップS190に進める。
また、ステップS197で、データ処理部110は、図39(b)で説明した起動時初期画面で「ICチップへの特典バリューのチャージ」のリンクが選択されることによって、特典バリュー発行が選択されたか否かを判断する。特典バリュー発行が選択された場合(ステップS194aでYESの場合)、データ処理部110は、実行する処理をステップS190に進める。
ステップS190では、データ処理部110は、図26で説明する特典発行時処理を実行する。
図26は、本実施の形態における携帯電話100により実行される電子マネーアプリ111のサブルーチンである特典発行時処理の流れを示すフローチャートである。図26を参照して、まず、ステップS1901で、データ処理部110は、記憶部120に記憶されている処理状況が特典発行情報受信済であるか否かを判断する。処理状況は、後述するように、ステップS1903で、特典発行情報が電子マネー管理サーバ200から受信されることを条件として、ステップS1904で、特典発行情報受信済に更新される。
処理状況が特典発行情報受信済であると判断した場合(ステップS1901においてYESの場合)、データ処理部110は、実行する処理をステップS1911に進める。一方、処理状況が特典発行情報受信済でないと判断した場合(ステップS1901においてNOの場合)、ステップS1902で、データ処理部110は、特典バリューの発行を要求するための情報であって会員IDおよび携帯端末情報を含む特典発行要求情報を、電子マネー管理サーバ200に送信する。
つまり、本実施の形態においては、特典バリューの発行を要求するための特典発行操作として、図39(b)の起動時初期画面において「ICチップへの特典バリューのチャージ」のリンクの選択操作、または、特典通知メールに添付されたリンクの操作をユーザから受付けたことを条件として、具体的には、特典発行操作をユーザから受付け、さらに、記憶部120に記憶されている処理状況が特典発行情報受信済でないことを条件として、特典バリューの発行を要求するための特典発行要求情報を電子マネー管理サーバ200に送信する。
図27(b)は、本実施の形態における電子マネー管理サーバ200により実行される特典付与アプリケーションプログラム217の処理の流れを示すフローチャートである。図27(b)を参照して、まず、ステップS2191で、データ処理部210は、携帯電話100から特典発行要求情報を受信したことによって、特典発行要求があったか否かを判断する。特典発行要求がないと判断した場合(ステップS2191でNOの場合)、データ処理部210は、ステップS2191の処理を繰返す。
一方、特典発行要求があったと判断した場合(ステップS2191でYESの場合)、ステップS2192で、データ処理部210は、ステップS2191で受信した特典発行要求情報に含まれる会員IDに対応して特典DB223に記憶されている取引店舗と前回特典付与後取引額とを特典DB223から抽出する。
次に、ステップS2193で、データ処理部210は、抽出した取引店舗に対応して特典付与店舗DBに記憶されている使用可能店舗に対応する店舗またはグループごとに付与する特典額を算出する。具体的には、今回の特典額は、前回特典付与後取引額を、特典付与店舗DBに記憶されている特典基準額で割った商の整数部分に、特典付与店舗DBに記憶されている単位特典額を掛けた額として算出することができる。
たとえば、取引店舗「abcグループ」に対応して特典付与店舗DBに記憶されている使用可能店舗は「1」、つまり付与店舗・グループであるので、対応する店舗またはグループは「abcグループ」である。そして、特典付与店舗DBに記憶されている「abcグループ」の特典基準額が「10000」円であり、単位特典額が「500」円である。また、特典DB223に記憶されている「abcグループ」の前回特典付与後取引額は、「13000」円である。したがって、使用可能店舗「abcグループ」で使用することができる今回の特典額は、前回特典付与後取引額「13000」円を特典基準額「10000」円で割った商の整数部分「1」に単位特典額「500」円を掛けた額「500」円として算出することができる。
また、取引店舗「D店」に対応して特典付与店舗DBに記憶されている使用可能店舗は「0」、つまり全加盟店である。そして、特典付与店舗DBに記憶されている「D店」の特典基準額が「5000」円であり、単位特典額が「300」円である。また、特典DB223に記憶されている「D店」の前回特典付与後取引額は、「1000」円である。したがって、使用可能店舗「全加盟店」で使用することができる今回の特典額は、前回特典付与後取引額「1000」円を特典基準額「5000」円で割った商の整数部分「0」に単位特典額「300」円を掛けた額「0」円として算出することができる。
さらに別の例として、たとえば、取引店舗「E店」,「F店」それぞれに対応する使用可能店舗が全加盟店であり、今回の特典額がそれぞれ「500」円,「1000」円と算出された場合、使用可能店舗「全加盟店」の店舗別特典残高にそれらの合算額である「1500」円が加算される。
なお、ステップS2193で算出された付与特典額が0円である場合は、携帯電話100に付与特典額が無い旨を報知する。
次のステップS2194では、データ処理部210は、算出した付与特典額と使用可能店舗を示す店舗識別情報とを含む特典発行情報を携帯電話100に送信する。特典発行情報は、付与特典額のバリューをリモート発行サーバ400から携帯電話100に書込ませるための情報である。
図26に戻って、ステップS1903で、データ処理部110は、電子マネー管理サーバ200から特典発行情報を受信したか否かを判断する。特典発行情報を受信したと判断した場合(ステップS1903でYESの場合)、ステップS1904で、データ処理部110は、記憶部120で管理している処理状況を、特典発行情報受信済に更新する。
そして、ステップS1905で、データ処理部110は、特典発行情報を受信したことを電子マネー管理サーバ200に知らせるための受信応答情報を、電子マネー管理サーバ200に送信する。
図27(b)に進んで、ステップS2195で、データ処理部210は、携帯電話100から受信応答情報を受信したか否かを判断する。受信応答情報を受信していないと判断した場合(ステップS2195においてNOの場合)、データ処理部210は、ステップS2195の処理を繰返す。一方、受信応答情報を受信したと判断した場合(ステップS2195においてYESの場合)、ステップS2196で、データ処理部210は、特典DB223の前回特典付与後取引額から今回の特典付与の対象額分を減算する。ステップS2193で前述した例では、前回特典付与後取引額「13000」円から今回の特典付与の対象額「10000」円分を減算して、前回特典付与後取引額を「3000」円に更新する。
そして、ステップS2197で、特典DB223の店舗別特典残高および合計特典残高に、算出した付与特典額を加算更新する。ステップS2193で前述した例では、abcグループで使用可能な店舗別特典残高を「500」円加算更新して、合計特典残高に「500」円加算更新する。
ステップS2198では、データ処理部210は、発行情報DB222のチャージ累計額に付与特典額を加算更新する。その後、データ処理部210は、実行する処理をステップS2191に戻す。
図26に戻って、次に、ステップS1911で、データ処理部110は、非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域に、特典発行情報から特定される特典バリューを記憶させる書込処理を開始させるための情報であって、携帯端末情報を含む書込処理開始要求情報(特典バリューの書込みを要求する書込要求情報)をリモート発行サーバ400へ送信する。このステップS1911からステップS1915までの処理は、前述した図18のステップS154からステップS157aまでの処理と同様であるので、重複する説明は繰返さない。
図31は、本実施の形態の携帯電話100の非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用記憶領域に記憶されるデータベースを説明するための図である。図31を参照して、電子マネー遊技使用サービス用の記憶領域には、会員ID、携帯端末情報およびバリュー残高が記憶される。また、電子マネー遊技使用サービス用の記憶領域には、店舗別特典残高およびそれを使用可能な使用可能店舗が対応付けて記憶される。なお、使用可能店舗および店舗別特典残高の組は複数記憶可能である。
図31では、会員IDとして「1101」、携帯端末情報として「MN7RE」、バリュー残高として「11000」円が記憶されている。また、使用可能店舗として「abcグループ」、店舗別特典残高として「500」円が対応付けて記憶されている。また、「abcグループ」で使用可能な店舗別特典残高に加えて、全加盟店で使用可能な店舗別特典残高があれば、使用可能店舗「全加盟店」と対応付けて全加盟店で使用可能な店舗別特典残高が記憶され、D店で使用可能な店舗別特典残高があれば、使用可能店舗「D店」と対応付けてD店で使用可能な店舗別特典残高が記憶される。
図26に戻って、データ処理部110は、ステップS1916で、非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域からバリュー残高を取得して、特典発行完了画面を表示部140に表示させる。
図49に進んで、図49(c)の画面は、ステップS1916で表示される特典発行完了画面である。図49(c)の画面には、図38(b)の画面と同様のチップID、特典バリューのチャージが完了した旨の文章、今回の特典バリューのチャージ金額が500円であること、特典バリューのチャージ後のバリュー残高が11500円であること、および、バリュー使用時の注意事項が表示される。なお、通常のバリュー残高と特典バリューの残高とを分けて表示するようにしてもよいし、使用可能店舗ごとに特典バリューの残高を表示するようにしてもよい。
図26に戻って、ステップS1917で、データ処理部110は、特典発行完了画面で確認操作がされたか否かを判断する。確認操作がされたと判断した場合(ステップS1917でYESの場合)、ステップS1918で、データ処理部110は、図39(b)で説明した起動時初期画面を表示部140に表示させる。その後、データ処理部110は、実行する処理をこの処理の呼出元の処理に戻す。
図14に戻って、ステップS1985で、データ処理部110は、記憶部120で管理されている処理状況が、図26のステップS1904で更新される特典発行情報受信済であるか否かを判断する。
処理状況が特典発行情報受信済であると判断した場合(ステップS1985においてYESの場合)、データ処理部110は、実行する処理を図26のバリュー発行時処理のステップS1911に進める。これによって、データ処理部110は、ステップS1903で特典発行情報を受信したが、ステップS1911からステップS1914までのリモート発行サーバ400とのやり取りにおいて、通信障害等により特典バリューの書込みができなかった場合、再度、ステップS1902で特典発行要求情報を電子マネー管理サーバ200に送信することなく、ステップS1911で書込処理開始要求をリモート発行サーバ400に送信する。
具体的には、ステップS1904で記憶部120にて管理している処理状況を特典発行情報受信済に更新した後、特典バリューの書込みが完了する前にリモート発行サーバ400との通信が切断され、ユーザが図39(a)に示す画面から電子マネーアプリ111の起動操作を実施した場合に、図11に示す電子マネーアプリ111の処理において、ステップS120、ステップS180、ステップS1100、ステップS1110およびステップS191がすべてNOと判断され、ステップS198の処理状況確認処理が実行される。
そして、図14に示す処理状況確認処理のステップS1985において記憶部120で管理している処理状況が特典発行情報受信済であると判断され、図26のステップS1902(特典発行要求情報の送信)を経由することなくステップS1911に進み、リモート発行サーバ400に対して書込処理開始要求(書込要求情報)が送信される。すなわち、この場合には、ユーザから電子マネーアプリ111の起動操作を受付けることが、特典バリューの発行を要求するための特典発行操作を受付けることに該当する。
また、上記のようにリモート発行サーバ400との通信が切断された後、前記特典発行操作として、前記特典通知メールに添付されたリンクの操作をユーザから受付けた場合には、図11に示す電子マネーアプリ111の処理において、ステップS191aでYESと判断されてステップS190の特典発行時処理が実行される。
そして、図26に示す特典発行時処理のステップS1901において、記憶部120で管理している処理状況が特典発行情報受信済であると判断され、ステップS1902(特典発行要求情報の送信)を経由することなくステップS1911に進み、リモート発行サーバ400に対して書込処理開始要求(書込要求情報)が送信される。
一方、処理状況が特典発行情報受信済でないと判断した場合(ステップS1985においてNOの場合)、データ処理部110は、実行する処理をこの処理の呼出元の処理である電子マネーアプリ111に戻す。
以上説明したように、電子マネー管理サーバ200においては、図5に示す発行情報DB222で、各携帯電話100ごとに各店舗におけるバリューを使用した取引額が集計・管理されるとともに、当該各店舗のうち図28に示す特典付与設定画面にて特典付与対象店舗として設定された店舗における取引額および特典付与対象グループに属する店舗における取引額の合計額が、特典DB223で携帯端末ごとに別途集計・管理されている。具体的には、特典DB223においては、各店舗やグループにおける取引額のうち、特典付与の対象となっていない前回特典付与後取引額が集計・管理されている。
そして、図27(b)に示す特典付与AP217のステップS2193において、特典DB223で各店舗ごとおよび各グループごとに管理されている前回特典付与後取引額に応じて特典バリュー額が算出され、ステップS2194で特典発行情報が携帯電話100に送信されることで、前記特典バリューが携帯電話100の記憶部120に記憶される。つまり、ステップS2193およびステップ2194により、特典付与対象店舗における取引額や特典付与対象グループに属する店舗における取引額の合計額に応じた特典を付与する特典付与処理として、特典バリューを携帯電話100に記憶させるための処理を行なう、本発明の特典付与手段が構成されている。
より具体的には、ステップS2193においては、特典バリューが使用可能店舗ごとに算出され、ステップS2194で各特典バリューと使用可能店舗を特定可能な特典発行情報が携帯電話100に送信されることで、前記特典バリューおよび当該特典バリューを使用可能な店舗を特定可能な使用可能店舗が、携帯電話100の非接触型ICチップ190の記憶部192に記憶される。
(電子マネーシステム10でのバリューの使用の説明)
図50は、本実施の形態における券売機300で実行される発券処理の流れを示すフローチャートである。図50を参照して、まず、ステップS310で、券売機300のデータ処理部310は、不正登録処理を実行する。
図51は、本実施の形態における券売機300で実行される不正登録処理の流れを示すフローチャートである。図51を参照して、データ処理部310は、ステップS311で、電子マネー管理サーバ200から店舗サーバ800を介して、携帯使用禁止情報を受信したか否かを判断する。
携帯使用禁止情報とは、遊技場30においてすべての携帯電話100でのバリューの使用を禁止させることを指示するための情報である。携帯使用禁止情報を送信する処理については、後述する図56および図57で説明する。
携帯使用禁止情報を受信したと判断した場合(ステップS311でYESの場合)、データ処理部310は、ステップS312で、携帯使用禁止情報を記憶部320に記憶させる。一方、携帯使用禁止情報を受信していないと判断した場合(ステップS311でNOの場合)、または、ステップS312の後、データ処理部310は、実行する処理をステップS313に進める。
ステップS313では、データ処理部310は、電子マネー管理サーバ200から店舗サーバ800を介して、不正端末情報を受信したか否かを判断する。
不正端末情報は、携帯IDを含み、携帯IDで示される携帯電話100でのバリューの使用を禁止させることを指示するための情報である。不正端末情報を送信する処理については、後述する図56および図57で説明する。
不正端末情報を受信したと判断した場合(ステップS313でYESの場合)、データ処理部310は、ステップS314で、不正端末情報を記憶部320に記憶させる。一方、不正端末情報を受信していないと判断した場合(ステップS313でNOの場合)、または、ステップS314の後、データ処理部310は、実行する処理をこの不正登録処理の呼出元の処理である図50の発券処理に戻す。
図50に戻って、ステップS320で、データ処理部310は、貨幣処理機380から現金が投入された旨の現金投入信号を受信したか否かを判断する。
現金投入信号を受信したと判断した場合(ステップS320でYESの場合)、ステップS323で、データ処理部310は、貨幣処理機380から現金カウント信号を受信して、現金カウント信号で示される現金の額を現金投入額にセットする。
そして、ステップS324で、データ処理部310は、現金カウント信号を再度受信したか否かを判断することによって、現金が追加投入されたか否かを判断する。現金が追加投入されたと判断した場合(ステップS324でYESの場合)、データ処理部310は、再度受信された現金カウント信号で示される現金の額を現金投入額に加算する。
現金が追加投入されていないと判断した場合(ステップS324でNOの場合)、または、ステップS325の後、データ処理部310は、現金投入額以下の金額ボタンを有効化制御する。有効化制御が実行されることにより、操作部330の金額ボタンへの操作が有効に受付可能にされるとともに、有効となった金額ボタンに設けられているランプが点灯される。
そして、ステップS327で、データ処理部310は、ステップS326で有効化された金額ボタンが操作されたことを示す操作信号を操作部330から受信したか否かを判断する。つまり、現金投入額以下の金額ボタンが操作されたか否かを判断する。現金投入額以下の金額ボタンが操作されていないと判断した場合(ステップS327でNOの場合)、データ処理部310は、実行する処理をステップS324に戻す。
一方、有効化された金額ボタンが操作されたと判断した場合(ステップS327でYESの場合)、データ処理部310は、ステップS328で、操作信号で示される金額ボタンの金額を購入金額にセットする。その後、データ処理部310は、実行する処理をステップS361に進める。
一方、現金投入信号を受信していないと判断した場合(ステップS320でNOの場合)、データ処理部310は、ステップS321で、操作部330の利用ボタンの操作が操作されたことを示す操作信号を操作部330から受信したか否かを判断することによって、利用ボタンが操作されたか否かを判断する。利用ボタンは、バリューを使用するときにユーザが操作するボタンである。利用ボタンが操作されていないと判断した場合(ステップS321でNOの場合)、データ処理部310は、実行する処理をステップS310に戻す。
一方、利用ボタンが操作されたと判断した場合(ステップS321でYESの場合)、データ処理部310は、ステップS322で、図51の不正登録処理で携帯使用禁止情報が記憶部320に記憶されたか否かを判断する。つまり、すべての携帯電話100でのバリューの使用が禁止されているか否かを判断する。
すべての携帯電話100でのバリューの使用が禁止されていないと判断した場合(ステップS322でNOの場合)、データ処理部310は、ステップS331で、全金額の金額ボタンを有効化制御する。そして、ステップS332で、データ処理部310は、ステップS331で有効化制御された金額ボタンが操作されたことを示す操作信号を操作部330から受信したか否かを判断する。つまり、いずれかの金額ボタンが操作されたか否かを判断する。いずれの金額ボタンも操作されていないと判断した場合(ステップS331でNOの場合)、データ処理部310は、ステップS331を繰返す。
一方、いずれかの金額ボタンが操作されたと判断した場合(ステップS331でYESの場合)、データ処理部310は、ステップS333で、操作信号で示される金額ボタンの金額を購入金額にセットする。
そして、データ処理部310は、ステップS341で、チップリーダライタ390によって携帯電話100の非接触型ICチップ190からバリュー残高、使用可能店舗および店舗別特典残高が読込まれたか否かを判断する。バリュー残高はバリュー残額として、店舗別特典残高は店舗別の特典残額として読込まれる。読込まれていないと判断した場合(ステップS341でNOの場合)、データ処理部310は、ステップS341の処理を繰返す。なお、一定時間(たとえば、30秒)、バリュー残高が読込まれないと判断した場合に、データ処理部310は、ステップS331で有効化された金額ボタンを無効化して、購入金額をリセットするようにしてもよい。
一方、携帯電話100からバリュー残高が読込まれたと判断した場合(ステップS341でYESの場合)、データ処理部310は、ステップS342で、バリュー残高とともに読込まれた携帯IDが図51の不正登録処理で記憶部320に記憶された不正端末情報により示される携帯IDであるか否かを判断する。つまり、不正な携帯電話100であるか否かを判断する。
不正携帯電話であると判断した場合(ステップS342でYESの場合)、データ処理部310は、ステップS343で、エラー報知する。エラー報知としては、たとえば、警報ランプを点滅させたり、警報ブザーを鳴動させたりする。そして、ステップS344で、データ処理部310は、遊技場30の係員によって不正携帯電話であるか否かが確認されて、確認操作がされたか否かを判断する。確認操作がされていない場合(ステップS344でNOの場合)、データ処理部310は、ステップS344を繰返す。一方、確認操作がされたと判断した場合(ステップS344でYESの場合)、データ処理部310は、実行する処理をステップS310に戻す。
不正携帯電話でないと判断した場合(ステップS342でNOの場合)、データ処理部310は、ステップS345で、バリュー残高とともに読込まれた携帯IDが、テスト用の携帯電話100の携帯IDであるか否かを判断する。つまり、バリュー残高が読込まれた携帯電話100がテスト用であるか否かを判断する。テスト用の携帯電話100の携帯IDは、電子マネー管理サーバ200から店舗サーバ800を介して、または、直接、券売機300に入力されることによって、券売機300の記憶部320に予め記憶される。
テスト用携帯電話であると判断した場合(ステップS345でYESの場合)、ステップS346で、データ処理部310は、テスト用の携帯電話の使用を許可する設定がされているか否かを判断する。テスト用の携帯電話の使用を許可するか否かは、券売機300に予め設定される。
なお、店舗サーバ800にテスト用の携帯電話の使用を許可するか否かの設定が予め記憶されるようにして、ステップS346で、データ処理部310が、店舗サーバ800に問合わせて、テスト用の携帯電話の使用を許可する設定がされているか否かを判断するようにしてもよい。
テスト用携帯電話の使用許可設定がされていないと判断した場合(ステップS346でNOの場合)、データ処理部310は、ステップS347で、ステップS343と同様に、エラー報知する。そして、ステップS348で、データ処理部310は、遊技場30の係員によって不正携帯電話であるか否かが確認されて、確認操作がされたか否かを判断する。確認操作がされていない場合(ステップS348でNOの場合)、データ処理部310は、ステップS348を繰返す。一方、確認操作がされたと判断した場合(ステップS348でYESの場合)、データ処理部310は、実行する処理をステップS310に戻す。
一方、テスト用携帯端末でないと判断した場合(ステップS345でNOの場合)、または、テスト用携帯電話の使用許可設定がされていると判断した場合(ステップS346でYESの場合)、データ処理部310は、実行する処理をステップS351に進める。
一方、すべての携帯電話100でのバリューの使用が禁止されていると判断した場合(ステップS322でYESの場合)、データ処理部310は、実行する処理をステップS310に戻す。
なお、ステップS342でYESの場合、および、ステップS346でNOの場合は、データ処理部310は、ステップS331で有効化された金額ボタンを無効化して、購入金額をリセットする。
ステップS351では、データ処理部310は、購入金額がバリュー残額に当該店舗で使用可能な特典残額を加算した額よりも大きな額であるか否かを判断する。購入金額がバリュー残額に当該店舗で使用可能な特典残額を加算した額よりも大きな額でないと判断した場合(ステップS351でNOの場合)、ステップS356において、データ処理部310は、購入金額分の購入バリューおよび特典バリューを携帯電話100の非接触型ICチップ190の記憶部192から減算させるための減算要求信号を携帯電話100に送信させるように、チップリーダライタ390を制御する。
具体的には、データ処理部310は、複数種類の電子マネーのうちバリューを引落対象として指定する電子マネー識別情報と、引落額相当を購入バリューおよび特典バリューから減算する旨を示す減算額情報と当該店舗を識別するための店舗識別情報とを含む減算要求信号を携帯電話100に送信するように非接触通信部393を制御する旨の減算制御コマンドをチップリーダライタ390の制御部391に送信する。チップリーダライタ390の制御部391は、減算制御コマンドに応じて、減算要求信号を携帯電話100に送信するよう非接触通信部393を制御する。
一方、減算要求信号を受信した携帯電話100では、非接触型ICチップ190の制御部191により、記憶部192の確保された領域に記憶されている引落対象として指定されている電子マネーである購入バリューおよび特典バリューから、引落額相当を減算し、バリューの減算が終了するとその旨を示す減算終了信号を券売機300のチップリーダライタ390に送信する処理が行なわれる。ここで、減算要求信号には、店舗識別情報が含まれるので、店舗識別情報で示される店舗に対応する店舗別特典残高があれば、店舗別特典残高から、優先的に、引落額相当が減算される。次いで、バリュー残高から、引落額相当の残り分が減算される。
そして、データ処理部310は、ステップS357で、携帯電話100から減算終了信号を受信したか否かを判断する。具体的には、チップリーダライタ390の制御部391は、携帯電話100からの減算終了信号の受信に応じて、減算が終了した旨の減算終了コマンドをデータ処理部310に送信する。データ処理部310は、減算終了コマンドを受信すると、引落額相当のバリューの減算が終了したと判断する。データ処理部310は、ステップS357において、減算終了コマンドが受信されるまで繰返し判断を行なう。なお、所定条件(判定回数、時間等)が成立するまでに、減算終了コマンドを受信しない場合には、減算が終了しない旨のエラーを表示部340において報知するようにしてもよい。
減算終了信号を受信したと判断した場合(ステップS357でYESの場合)、ステップS358で、データ処理部310は、バリュー残額に当該店舗で使用可能な特典残額を加算したものから購入金額を減算した額が所定額以下であるか否かを判断する。バリュー残額に当該店舗で使用可能な特典残額を加算したものから購入金額を減算した額が所定額以下であると判断した場合(ステップS358でYESの場合)、ステップS359で、データ処理部310は、携帯電話100の非接触型ICチップ190に、減算後残高僅少情報を含むアプリ起動信号を送信するように、チップリーダライタ390を制御する。
減算後残高僅少情報は、バリューの減算後に携帯電話100に記憶されているバリューの額が僅少である旨を携帯電話100に伝達するための情報である。アプリ起動信号は、携帯電話100の電子マネーアプリ111を外部から起動させるための信号である。所定額は、たとえば、最低額のプリペイドカード371を1回購入できる額であり、本実施の形態においては、1000円である。なお、所定額は、僅少な額であれば、他の額であってもよい。
一方、バリュー残額に当該店舗で使用可能な特典残額を加算したものから購入金額を減算した額が所定額以下でないと判断した場合(ステップS358でNOの場合)、または、ステップS359の後、データ処理部310は、実行する処理をステップS361に進める。
一方、購入金額がバリュー残額に当該店舗で使用可能な特典残額を加算した額よりも大きな額であると判断した場合(ステップS351でYESの場合)、ステップS352で、データ処理部310は、減算前残高不足情報を含むアプリ起動信号を携帯電話100の非接触型ICチップ190に送信するように、チップリーダライタ390を制御する。減算前残高不足情報は、バリューを減算する前に携帯電話100に記憶されているバリューの額が不足している旨を携帯電話100に伝達するための情報である。アプリ起動信号は、ステップS359で説明したものと同様である。その後、データ処理部310は、実行する処理をステップS310に戻す。
ステップS361では、データ処理部310は、発券するプリペイドカード371のカードID、購入に用いた現金額、購入に用いた携帯電話100の携帯ID、および、購入に用いた購入バリューおよび特典バリューの額(以下、取引額ともいう)をそれぞれ特定する情報を含む取引情報を店舗サーバ800に送信する。
次に、ステップS362で、データ処理部310は、購入金額のプリペイドカード371を発券するよう、カードリーダライタ370を制御する。なお、現金投入額が購入金額より多い場合は、データ処理部310は、現金投入額から購入金額を減算した釣銭を払出すよう、貨幣処理機380を制御する。そして、データ処理部310は、ステップS363で、購入金額、バリュー残額、特典残額、および、現金投入額をリセットして、実行する処理をステップS310に戻す。
ステップS359、または、ステップS352が実行されることによって券売機300から送信されたアプリ起動信号を非接触型ICチップ190で受信すると、非接触型ICチップ190の制御部191は、電子マネーアプリ111を起動させるコマンドをデータ処理部110に出力する。電子マネーアプリ111を起動させるコマンドを受けると、データ処理部110は、電子マネーアプリ111を起動させる。
図52は、本実施の形態における電子マネーシステム10において券売機300から携帯電話100の電子マネーアプリ111が起動されるときに携帯電話100の表示部140に表示される第1の表示画面図である。図52(a)の画面は、図38(a)の画面と同様であるので、重複する説明は繰返さない。
図11に戻って、電子マネーアプリ111のステップS180で、データ処理部110は、電子マネーアプリ111の起動が非接触型ICチップ190からの起動であるか否かを判断する。非接触型ICチップ190からの起動であると判断した場合(ステップS180でYESの場合)、ステップS1800で、データ処理部110は、ICチップ起動処理を実行する。
図13は、本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるICチップ起動処理の流れを示すフローチャートである。図13を参照して、まず、ステップS181では、データ処理部110は、減算前残高不足情報を受信したか否かを判断する。つまり、電子マネーアプリ111を起動させたアプリ起動信号に減算前残高不足情報が含まれているか否かを判断する。減算前残高不足情報を受信していないと判断した場合(ステップS181でNOの場合)、ステップS182で、データ処理部310は、減算後残高不足情報を受信したか否かを判断する。つまり、電子マネーアプリ111を起動させたアプリ起動信号に減算後残高不足情報が含まれているか否かを判断する。
減算後残高不足情報を受信していないと判断した場合(ステップS182でNOの場合)、ステップS184で、データ処理部310は、携帯電話100に記憶されているバリューの残高が僅少である旨を報知する。本実施の形態においては、残高が僅少である旨を表示部140に表示させることによって残高が僅少であることを報知する。しかし、これに限定されず、たとえば、データ処理部310は、残高が僅少である旨の音声を出力したり、残高が僅少である旨の振動を発生させたりすることによって、残高が僅少であることを報知するようにしてもよい。
図52に進んで、図52(b)は、残高が僅少である旨の表示画面図である。図52(b)の画面には、携帯電話100に記憶されているバリューの残高が僅少である旨、および、バリューの購入のための処理に移行する旨が表示される。
図13に戻って、減算前残高不足情報を受信したと判断した場合(ステップS181でYESの場合)、または、減算後残高不足情報を受信したと判断した場合(ステップS182でYESの場合)、ステップS185で、データ処理部310は、携帯電話100に記憶されているバリューの残高が不足している旨を報知する。本実施の形態においては、残高が不足している旨を表示部140に表示させることによって残高が不足していることを報知する。しかし、これに限定されず、たとえば、データ処理部310は、残高が不足している旨の音声を出力したり、残高が不足している旨の振動を発生させたりすることによって、残高が不足していることを報知するようにしてもよい。
図52に進んで、図52(c)は、残高が不足している旨の表示画面図である。図52(c)の画面には、携帯電話100に記憶されているバリューの残高が不足している旨、および、バリューの購入のための処理に移行する旨が表示される。
なお、本実施の形態においては、携帯電話100に記憶されているバリューの残高が僅少であること、および、不足していることを分けて、券売機300から携帯電話100にアプリ起動信号を送信するようにして携帯電話100で報知するようにした。しかし、これに限定されず、バリューの残高が僅少であること、および、不足していることを分けずに、携帯電話100で報知するようにしてもよい。つまり、バリューの残高が0円であるときを含めてバリューの残高が所定額以下のときにバリューの残高が不足している旨の残高不足情報を券売機300から携帯電話100に送信するようにして携帯電話100で残高が不足している旨を報知するようにしてもよい。
図13に戻って、ステップS184、または、ステップS185の後、データ処理部110は、実行する処理をこの処理の呼出元の処理である電子マネーアプリ111に戻す。
図11に戻って、ステップS1800のICチップ起動処理の後、ステップS130で、データ処理部310は、バリュー購入時処理を実行する。バリュー購入時処理が実行されることによって、図15で説明したように、ステップS139で、購入金額選択画面が表示される。このように、ユーザが電子マネーアプリ111を起動させなくても、自動的に購入金額選択画面を表示させることができる。
なお、ステップS1800のICチップ起動処理の後、ステップS130に遷移するようにしたが、これに限定されず、ステップS192に遷移するようにしてもよい。これによって、ユーザが起動時初期画面でバリュー購入を選択することによって、バリュー購入時処理を実行させることができる。
図53は、本実施の形態におけるカードユニット600で実行される球貸処理の流れを示すフローチャートである。図53を参照して、まず、ステップS610で、カードユニット600のデータ処理部610は、ユニット不正登録処理を実行する。
図55は、本実施の形態におけるカードユニット600で実行されるユニット不正登録処理の流れを示すフローチャートである。図55を参照して、ステップS601で、データ処理部610は、電子マネー管理サーバ200から店舗サーバ800を介して、携帯使用禁止情報を受信したか否かを判断する。携帯使用禁止情報は、図51のステップS311で説明したので重複する説明は繰返さない。
携帯使用禁止情報を受信したと判断した場合(ステップS601でYESの場合)、データ処理部610は、ステップS602で、携帯使用禁止情報を記憶部620に記憶させる。一方、携帯使用禁止情報を受信していないと判断した場合(ステップS601でNOの場合)、または、ステップS602の後、データ処理部610は、実行する処理をステップS603に進める。
ステップS603では、データ処理部610は、電子マネー管理サーバ200から店舗サーバ800を介して、不正端末情報を受信したか否かを判断する。不正端末情報は、図51のステップS313で説明したので重複する説明は繰返さない。
不正端末情報を受信したと判断した場合(ステップS603でYESの場合)、データ処理部610は、ステップS604で、不正端末情報を記憶部620に記憶させる。一方、不正端末情報を受信していないと判断した場合(ステップS603でNOの場合)、または、ステップS604の後、ステップS605で、データ処理部610は、電子マネー管理サーバ200から店舗サーバ800を介して、不正カードIDを受信したか否かを判断する。
不正カードIDは、不正な携帯電話100で購入されたプリペイドカード371を識別するためのIDである。不正カードIDを送信する処理については、後述する図56および図57で説明する。
不正カードIDを受信したと判断した場合(ステップS605でYESの場合)、データ処理部610は、ステップS606で、不正カードIDを記憶部620に記憶させる。不正カードIDを受信していないと判断した場合(ステップS605でNOの場合)、または、ステップS606の後、データ処理部610は、実行する処理をこのユニット不正登録処理の呼出元の処理である図53の球貸処理に戻す。一方、不正カードIDを受信していないと判断した場合(ステップS605でNOの場合)、データ処理部610は、実行する処理を図53の球貸処理に戻す。
図53に戻って、データ処理部610は、ステップS611で、カードリーダライタ670からプリペイドカード371が投入されたことを示す投入信号を受信したか否かを判断する。
投入信号を受信したと判断した場合(ステップS611でYESの場合)、データ処理部610は、ステップS612で、カードリーダライタ670から、投入されたプリペイドカード371のカードIDが、記憶部620に記憶された不正カードIDと同じであることを示す不正カード信号を受信したか否かを判断する。
不正カードでないと判断した場合(ステップS612でNOの場合)、データ処理部610は、実行する処理をステップS690に進める。一方、不正カードであると判断した場合(ステップS612でYESの場合)、データ処理部610は、ステップS671で、不正なプリペイドカードが投入された旨をエラー報知する。エラー報知は、たとえば、警報ランプを点滅させたり、警報ブザーを鳴動させたりすることによって行なう。そして、ステップS672で、データ処理部610は、遊技場30の係員によってエラー報知が確認されたことを示す確認操作があったか否かを判断する。確認操作がないと判断した場合(ステップS672でNOの場合)、データ処理部610は、ステップS672の処理を繰返す。一方、確認操作があったと判断した場合(ステップS672でYESの場合)、データ処理部610は、実行する処理をステップS610に戻す。
一方、投入信号を受信していないと判断した場合(ステップS611でNOの場合)、データ処理部610は、ステップS620で、貨幣処理機680から現金が投入された旨の現金投入信号を受信したか否かを判断する。
現金投入信号を受信したと判断した場合(ステップS620でYESの場合)、ステップS681で、データ処理部610は、発券するプリペイドカード371のカードID、および、購入に用いた現金額をそれぞれ特定する情報を含む取引情報を店舗サーバ800に送信する。
次に、ステップS682で、データ処理部610は、プリペイドカード371を発行し、貨幣処理機680からの現金カウント信号で示される現金投入額を、カードリーダライタ670の内部に予めストックされているプリペイドカード371に入金するよう、カードリーダライタ670を制御する。なお、ここでは、プリペイドカード371は、入金後、カードユニット600の中に保持されて、排出されない。その後、データ処理部610は、実行する処理をステップS690に進める。
ステップS690では、データ処理部610は、プリペイド球貸処理を実行する。プリペイド球貸処理については、後述する図54で説明する。
図54は、本実施の形態におけるカードユニット600で実行されるプリペイド球貸処理の流れを示すフローチャートである。
図54を参照して、ステップS691で、データ処理部610は、貨幣処理機680から現金が投入された旨の現金投入信号を受信したか否かを判断する。現金投入信号を受信したと判断した場合(ステップS691でYESの場合)、ステップS692で、データ処理部610は、貨幣処理機680から現金カウント信号を受信して、現金カウント信号で示される現金の額をプリペイドカード371に加算するよう、カードリーダライタ670を制御する。
一方、現金投入信号を受信していないと判断した場合(ステップS691でNOの場合)、または、ステップS692の後、データ処理部610は、ステップS613で、カードリーダライタ670によって読込まれたプリペイドカード371に記録されたプリペイドの残高を、カードリーダライタ670から受信する。
次に、ステップS614で、データ処理部610は、受信した残高が0より大きい値であるか、すなわち残高が0でないか否かを判断する。残高が0よりも大きい値でないと判断した場合(ステップS614でNOの場合)、データ処理部610は、実行する処理をステップS632に進める。
一方、残高が0より大きい値であると判断した場合(ステップS614でYESの場合)、データ処理部610は、ステップS615で、球貸ボタン631から球貸操作信号を受信したか否かを判断する。球貸操作信号を受信していないと判断した場合(ステップS615でNOの場合)、データ処理部610は、実行する処理をステップS631に進める。
一方、球貸操作信号を受信したと判断した場合(ステップS615でYESの場合)、データ処理部610は、ステップS616で、プリペイドカード371の残高から所定貸球相当の対価を減算する。次に、データ処理部610は、ステップS617で、減算した残高をプリペイドカード371に書込むよう、カードリーダライタ670を制御する。
次いで、ステップS618で、データ処理部610は、所定個数の遊技球の払出しを要求するための球貸信号をパチンコ遊技機700に送信する。この球貸信号に応じて、パチンコ遊技機700は、所定個数の遊技球を払出す。遊技者は、払出された遊技球を用いてパチンコ遊技を行なうことができる。なお、カードユニット600は、球貸信号を送信することによりパチンコ遊技機700に遊技球を払出させるものに限らず、自ら遊技球を払出すものであってもよい。すなわち、ステップS618において、遊技球を払出す処理を実行するものであってもよい。その後、データ処理部610は、実行する処理をステップS631に進める。
ステップS631では、データ処理部610は、返却ボタン632から返却操作信号を受信したか否かを判断する。返却操作信号を受信していないと判断した場合(ステップS631でNOの場合)、データ処理部610は、実行する処理をステップS691に戻す。
一方、返却操作信号を受信したと判断した場合(ステップS631でYESの場合)、データ処理部610は、実行する処理をステップS632に進める。
ステップS632では、データ処理部610は、プリペイドカード371から読込まれた残高をリセットする。次に、ステップS633で、データ処理部610は、プリペイドカード371を返却するように、カードリーダライタ670を制御する。その後、データ処理部610は、実行する処理をこのプリペイド球貸処理の呼出元の処理である図53の球貸処理に戻す。
図53に戻って、ステップS690でプリペイド球貸処理の実行後、データ処理部610は、実行する処理をステップS610に戻す。
一方、現金投入信号を受信していないと判断した場合(ステップS620でNOの場合)、データ処理部610は、ステップS622で、図55のユニット不正登録処理で携帯使用禁止情報が記憶部620に記憶されたか否かを判断する。つまり、すべての携帯電話100でのバリューの使用が禁止されているか否かを判断する。すべての携帯電話100でのバリューの使用が禁止されていると判断した場合(ステップS622でYESの場合)、データ処理部610は、実行する処理をステップS610に戻す。
一方、すべての携帯電話100でのバリューの使用が禁止されていないと判断した場合(ステップS622でNOの場合)、データ処理部610は、ステップS641からステップS648までの処理を実行する。ステップS641からステップS648までの処理は、図50で説明した発券処理のステップS341からステップS348と同様であるので、説明は繰返さない。
ステップS651では、データ処理部610は、バリュー残額に当該店舗で使用可能な特典残額を加算した額が0円であるか否かを判断する。バリュー残額に当該店舗で使用可能な特典残額を加算した額が0円であると判断した場合(ステップS651でYESの場合)、ステップS652で、データ処理部610は、図50の発券処理のステップS352と同様の減算前残高不足情報を含むアプリ起動信号を携帯電話100の非接触型ICチップ190に送信するように、チップリーダライタ690を制御する。その後、データ処理部610は、実行する処理をステップS610に戻す。
なお、本実施の形態においては、ステップS651で、バリュー残額に当該店舗で使用可能な特典残額を加算した額が0円であるか否かを判断した。これは、本実施の形態におけるバリューは、遊技のみに用いられ、球貸の単位である100円単位でバリューが引落とされるため、0円であるか否かを判断することによって、球貸可能なバリューが残っているか否かを判断できるためである。しかし、遊技場30以外でもバリューを用いることができるようにした場合、ステップS651で、バリュー残額が球貸に用いることができる最低額である100円未満であるか否かを判断するようにしてもよい。
一方、バリュー残額に当該店舗で使用可能な特典残額を加算した額が0円でないと判断した場合(ステップS651でNOの場合)、データ処理部610は、ステップS653で、バリュー残額に当該店舗で使用可能な特典残額を加算した額が1000円以上であるか否かを判断する。バリュー残額に当該店舗で使用可能な特典残額を加算した額が1000円以上であると判断した場合(ステップS653でYESの場合)、ステップS654で、データ処理部610は、1000円を購入金額にセットする。一方、バリュー残額に当該店舗で使用可能な特典残額を加算した額が1000円未満であると判断した場合(ステップS653でNOの場合)、ステップS655で、データ処理部610は、バリュー残額に当該店舗で使用可能な特典残額を加算した額を購入金額にセットする。
なお、ステップS653およびステップS654では、1000円としたので、後述するステップS662で、1000円に相当する貸球が払出される。しかし、これに限定されず、500円に相当する貸球が払出されるようにしてもよい。この場合、ステップS653で、バリュー残額が500円以上であるか否かを判断し、ステップS654で、データ処理部610は、500円を購入金額にセットする。
ステップS654またはステップS655の後、ステップS656で、データ処理部610は、図50の発券処理のステップS356と同様に、購入金額分の購入バリューおよび特典バリューを携帯電話100の非接触型ICチップ190の記憶部192から減算させるための減算要求信号を携帯電話100に送信させるように、チップリーダライタ690を制御する。
そして、データ処理部610は、ステップS657で、図50の発券処理のステップS357と同様に、携帯電話100から減算終了信号を受信したか否かを判断する。減算終了信号を受信していないと判断した場合(ステップS657でNOの場合)、データ処理部610は、ステップS657を繰返す。
一方、減算終了信号を受信したと判断した場合(ステップS657でYESの場合)、ステップS658で、データ処理部610は、バリュー残額に当該店舗で使用可能な特典残額を加算したものから購入金額を減算した額が0円であるか否かを判断する。バリュー残額に当該店舗で使用可能な特典残額を加算したものから購入金額を減算した額が0円であると判断した場合(ステップS658でYESの場合)、ステップS659で、データ処理部610は、携帯電話100の非接触型ICチップ190に、減算後残高不足情報を含むアプリ起動信号を送信するように、チップリーダライタ690を制御する。
減算後残高不足情報は、バリューの減算後に携帯電話100に記憶されているバリューの額が不足している旨を携帯電話100に伝達するための情報である。アプリ起動信号は、ステップS359で説明したものと同様である。
なお、ステップS651と同様、ステップS658で、バリュー残額から購入金額を減算した額が球貸に用いることができる最低額である100円未満であるか否かを判断するようにしてもよい。
さらに、ステップS658に加えて、図50の発券処理のステップS358と同様に、バリュー残額から購入金額を減算した額が所定額以下か否かを判断して、所定額以下である場合、ステップS359と同様に、減算後残額僅少情報を含むアプリ起動信号を携帯電話100に送信するようにしてもよい。
一方、バリュー残額に当該店舗で使用可能な特典残額を加算したものから購入金額を減算した額が0円でないと判断した場合(ステップS658でNOの場合)、または、ステップS659の後、データ処理部610は、ステップS661からステップS663までの処理を実行する。ステップS661からステップS663までの処理は、図50の発券処理のステップS361からステップS363までの処理と同様であるので、説明は繰返さない。ステップS663の後、データ処理部610は、実行する処理をステップS610に戻す。
ステップS659またはステップS652が実行されることによってカードユニット600から送信されたアプリ起動信号が非接触型ICチップ190で受信されることによって実行される電子マネーアプリ111のステップS181からステップS185までの処理については、図11で説明したので、説明は繰返さない。
以上説明したように、本発明の取引装置を構成する券売機300およびカードユニット600は、図50のステップS341または図53のステップS641において、携帯電話100から購入バリューおよび特典バリューとともに該特典バリューを使用可能な使用可能店舗を取得し、ステップS351またはステップS653に示すように、特典バリューのうち、該券売機300やカードユニット600が設置されている店舗が使用可能店舗として示される特典バリュー(具体的には、携帯電話100から取得した使用可能店舗情報が、当該店舗、当該店舗が属するグループ、および、全加盟店のいずれかである特典バリュー)についてのみ、カード発行や玉貸処理といった取引処理に使用するようにされている。
図56は、本実施の形態における電子マネー管理サーバ200により実行される残高管理アプリケーションプログラム214の処理の流れを示すフローチャートである。
図56を参照して、まず、ステップS291で、電子マネー管理サーバ200のデータ処理部210は、店舗サーバ800から取引情報を受信したか否かを判断する。この取引情報には、図57のステップS814で後述するように、店舗識別情報、ならびに、携帯端末情報ごとの購入バリューの取引額および特典バリューの取引額が含まれる。取引情報を受信した場合(ステップS291でYESの場合)、データ処理部210は、ステップS292で、取引情報に含まれる携帯端末情報に対応して発行情報DB222に記憶されているバリュー残高から、取引情報に含まれる購入バリューの取引額を減算する。取引情報に含まれる携帯端末情報に対応して発行情報DB222に記憶されている取引合計額に、取引情報に含まれる購入バリューの取引額および特典バリューの取引額を加算する。また、取引情報に含まれる携帯端末情報および店舗識別情報で示される店舗に対応して発行情報DB222に記憶されている店舗別取引額に、取引情報に含まれる購入バリューの取引額および特典バリューの取引額を加算する。また、取引情報に含まれる携帯端末情報および店舗識別情報で示される店舗に対応して特典DB223に記憶されている前回特典付与後取引額に、取引情報に含まれる購入バリューの取引額および特典バリューの取引額を加算する。また、取引情報に含まれる携帯端末情報に対応して特典DB223に記憶されている合計特典残高から、取引情報に含まれる特典バリューの取引額を減算する。また、取引情報に含まれる携帯端末情報および店舗識別情報で示される店舗に対応して特典DB223に記憶されている店舗別特典残高から、取引情報に含まれる特典バリューの取引額を減算する。また、特典DB223に記憶されている店舗別特典残高が0になったものがあれば、その店舗別特典残高および使用可能店舗のデータを削除する。
なお、発行情報DB222における店舗別取引額および特典DB223における前回特典付与後取引額については、特典バリューの取引額は加算せず、購入バリューの取引額のみを加算するようにしてもよい。この場合には、購入バリューを使用した取引の取引額については特典付与の対象となるが、特典バリューを使用した取引の取引額については特典付与の対象とならないこととなる。また、本実施例においては、特典バリューの付与額についても、図27(b)のステップS2198で発行情報DB222のチャージ累計額に加算されているため、後述するステップS281の判定における整合性を担保するため、取引情報に含まれる特典バリューの取引額を発行情報DB222の取引合計額に加算している。しかし、これに限定されるものではなく、特典バリューの付与額をチャージ累計額に加算しない場合には、特典バリューの取引額を取引合計額に加算しないようにすればよい。
ステップS292の後、または、取引情報を受信していないと判断した場合(ステップS291でNOの場合)、データ処理部210は、ステップS281で、チャージ累計額から取引合計額を減算した額がマイナスの会員IDがあるか否かを判断する。
チャージ累計額から取引合計額を減算した額がマイナスの会員IDがあると判断した場合(ステップS281でYESの場合)、ステップS282で、データ処理部210は、その会員IDの不正回数を1回加算する。
ステップS282の後、または、チャージ累計額から取引合計額を減算した額がマイナスの会員IDがないと判断した場合(ステップS281でNOの場合)、ステップS283で、データ処理部210は、不正回数が1回の会員IDがあるか否かを判断する。
不正回数1回の会員IDがあると判断した場合(ステップS283でYESの場合)、ステップS284で、データ処理部210は、その会員IDに対応する携帯IDの携帯電話のバリューを使用して購入されたプリペイドカードのカードIDをユニットに登録する旨および当該携帯IDを含む不正媒体情報を遊技場30側に送信する。
ステップS284の後、または、不正回数1回の会員IDがないと判断した場合(ステップS283でNOの場合)、ステップS285で、データ処理部210は、不正回数が2回の会員IDがあるか否かを判断する。
不正回数2回の会員IDがあると判断した場合(ステップS285でYESの場合)、ステップS286で、データ処理部210は、その会員IDに対応する携帯IDを券売機300に登録する旨、および、その会員IDに対応する携帯IDを含む不正端末情報を不正が発生した遊技場30側に送信する。また、ステップS287で、データ処理部210は、不正端末情報を不正が発生した遊技場30と同じ商圏の他の遊技場側にも送信する。なお、データ処理部210が不正端末情報を送信する遊技場は、不正が発生した遊技場30、または、不正が発生した遊技場30と同じ商圏の他の遊技場に限定されず、全国の遊技場であってもよいし、不正が発生した遊技場30の近隣の遊技場であってもよい。
ステップS287の後、または、不正回数2回の会員IDがないと判断した場合(ステップS285でNOの場合)、ステップS288で、データ処理部210は、全国の遊技場で発生した不正回数が3回以上であるか否かを判断する。
全国の遊技場で発生した不正回数が3回以上であると判断した場合(ステップS288でYESの場合)、ステップS289で、データ処理部210は、携帯使用禁止情報を遊技場30側に送信する。また、ステップS290で、データ処理部210は、携帯使用禁止情報を不正が発生した遊技場30と全国の遊技場側にも送信する。なお、データ処理部210が携帯使用禁止情報を、不正が発生した遊技場30以外にも、全国の遊技場に送信する場合について説明したが、これに限らず、不正が発生した遊技場30と同じ商圏の他の遊技場や、不正が発生した遊技場30と近隣の遊技場に送信するものであってもよい。この場合、ステップS288においては、携帯使用禁止情報の送信対象となる遊技場で発生した不正回数が3回以上であるか否かを判断するようにしてもよい。その後、データ処理部210は、実行する処理をステップS291に戻す。
図57は、本実施の形態における店舗サーバ800で実行される店舗サーバ処理の流れを示すフローチャートである。図57を参照して、店舗サーバ800のデータ処理部は、ステップS811で、券売機300またはカードユニット600から取引情報を受信したか否かを判断する。
取引情報を受信したと判断した場合(ステップS811でYESの場合)、店舗サーバ800のデータ処理部は、ステップS812で、取引情報に含まれる携帯IDごとに、発券したプリペイドカード371のカードID、発券、球貸に用いた現金額、および、発券、球貸に用いたバリューの額をそれぞれ特定する情報を対応させて記憶部に記憶させる。なお、発券、球貸に用いたバリューの額は、購入バリューでの取引額および特典バリューでの取引額に分けて集計、記憶される。
ステップS812の後、または、取引情報を受信していないと判断した場合(ステップS811でNOの場合)、店舗サーバ800のデータ処理部は、ステップS813で、電子マネー管理サーバ200へ取引情報を前回送信してから所定時間経過したか否かを判断する。本実施の形態では、所定時間は、3時間である。
取引情報の前回送信から所定時間経過したと判断した場合(ステップS813でYESの場合)、店舗サーバ800のデータ処理部は、ステップS814で、記憶部に記憶された前回送信後の携帯電話100での取引情報を電子マネー管理サーバ200に送信する。この取引情報には、携帯端末情報ごとの購入バリューの取引額および特典バリューの取引額、ならびに、店舗を識別するための店舗識別情報が含まれる。
ステップS814の後、または、取引情報の前回送信から所定時間経過していないと判断した場合(ステップS813でNOの場合)、店舗サーバ800のデータ処理部は、ステップS821で、携帯使用禁止情報を電子マネー管理サーバ200から受信したか否かを判断する。
携帯使用禁止情報を受信したと判断した場合(ステップS821でYESの場合)、店舗サーバ800のデータ処理部は、ステップS822で、携帯使用禁止情報を遊技場30内のすべての券売機300およびカードユニット600に送信する。
ステップS822の後、または、携帯使用禁止情報を受信していないと判断した場合(ステップS821でNOの場合)、店舗サーバ800のデータ処理部は、ステップS823で、不正端末情報を電子マネー管理サーバ200から受信したか否かを判断する。
不正端末情報を受信したと判断した場合(ステップS823でYESの場合)、店舗サーバ800のデータ処理部は、ステップS824で、不正端末情報を遊技場30内のすべての券売機300およびカードユニット600に送信する。
ステップS824の後、または、不正端末情報を受信していないと判断した場合(ステップS823でNOの場合)、店舗サーバ800のデータ処理部は、ステップS825で、不正媒体情報を電子マネー管理サーバ200から受信したか否かを判断する。
不正媒体情報を受信したと判断した場合(ステップS825でYESの場合)、店舗サーバ800のデータ処理部は、ステップS826で、不正媒体情報に含まれる携帯IDに対応して記憶部に記憶しているカードIDを、遊技場30内のすべてのカードユニット600に送信する。
ステップS826の後、または、不正媒体情報を受信していないと判断した場合(ステップS825でNOの場合)、店舗サーバ800のデータ処理部は、実行する処理をステップS811に戻す。
(電子マネーシステム10でのエラー対応の説明)
図18のステップS156や図26のステップS1913で説明したように、バリューの書込処理が終了すると、リモート発行サーバ400におけるバリューの処理状況(書込状況)は書込終了済とされる。また、ステップS157aや図26のステップS1915で説明したように、携帯電話100におけるバリューの処理状況は書込済に更新される。しかし、携帯電話100において、ステップS157aや図26のステップS1915で処理状況の更新に失敗すると、携帯電話100の処理状況は発行情報受信済のまま、つまり、書込済でない一方、リモート発行サーバ400の処理状況は書込終了済となる。このように、両者の処理状況に不一致が生じてしまい、その後の処理に不都合が発生する。
たとえば、本実施の形態の場合、携帯電話100において、不一致のまま電子マネーアプリ111が起動されると、ステップS198の処理状況確認処理のステップS1982で処理状況が発行情報受信済、または、ステップS1985で処理状況が特典発行情報受信済であると判断され、それぞれ、図18のステップS154または図26のステップS1911へ処理が進められ、バリューの購入番号を含むリモート発行サーバへ書込処理開始要求が送信される。しかし、リモート発行サーバ400では、携帯電話100から送信されてきた書込処理開始要求に含まれる購入番号のバリューはすでに書込終了済として管理されているので、この書込処理開始要求は受付けられない。
したがって、携帯電話100からは書込処理開始要求が電子マネーアプリ111を起動するごとに繰返し送信され続けられるが、リモート発行サーバ400では受付けられないため、携帯電話100で他の処理が実行できなくなってしまうといった問題が発生する。また、携帯電話100の記憶部120にて管理されている処理状況が書込済であることを条件として、次のチャージ要求を電子マネー管理サーバ200に送信可能となるような場合には、処理状況の書込済への更新に失敗すると、以降、一切チャージが不可能となるという問題が生じる。
このような処理状況の不一致のエラーが発生した場合、ユーザは、電話や電子メール等で、電子マネー遊技使用サービスの提供業者のオペレータに対して、上述したようなエラーが発生している旨を連絡する。
本実施の形態における電子マネー遊技使用サービスの提供業者のオペレータは、電話や電子メール等で、ユーザからのエラー問合せを受信した場合、ユーザに携帯電話100の電子メールのアドレスを問合せ、ユーザの携帯電話100の電子メールアドレスを取得する。
次に、オペレータは、取得したユーザの携帯電話100の電子メールアドレス宛に、エラー対応開始メールを送信する。エラー対応開始メールには、エラーについて説明するエラー説明ページのURLが添付される。
エラー対応開始メールに含まれるエラー説明ページへのリンクが操作されると、データ処理部110は、エラー説明ページへのリンク先のURLのエラー説明画面を取得し、表示部140に表示する。エラー説明画面には、エラーについての説明が記載されるとともに、電子マネーアプリ111を起動させるために操作されるリンク情報が含まれており、当該リンク情報が選択操作されることにより、データ処理部110は、電子マネーアプリ111を起動させる。
図11に戻って、ステップS1100で、データ処理部110は、エラー説明画面からの電子マネーアプリ111の起動であると判断し、ステップS1101で、データ処理部110は、非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域のバリュー残高などの記憶内容を取得して、該取得した記憶内容と、記憶部120で管理されている処理状況とを電子マネー管理サーバ200に送信する。その後、データ処理部110は、電子マネーアプリ111を終了する。
携帯電話100から記憶部192の記憶内容および処理状況を受信した電子マネー管理サーバ200は、受信した情報を表示部240に表示する。つまり、電子マネー管理サーバ200は、携帯電話100から取得した処理状況等に基づいた処理として、取得した処理状況等を表示部240に表示する処理を行なう。表示内容を確認したオペレータは、リモート発行サーバ400の管理者にリモート発行サーバ400における当該携帯電話100のバリューに関する処理状況(書込状況)を問合せる。
そして、たとえば、携帯電話100から取得した処理状況が発行情報受信済であり、リモート発行サーバ400の管理者からの回答が書込終了済であった場合、オペレータは携帯電話100において処理状況の更新失敗が生じたことを認識する。また、より慎重を期す場合には、取得したバリュー残高と電子マネー管理サーバ200において管理しているバリュー残高が一致するか否かをさらに確認してもよい。そして、両バリュー残高が一致すれば、携帯電話100においてバリューの書込みが行なわれていたことを確認できる。
かかる確認後、オペレータの操作に基づいて電子マネー管理サーバ200は、電子マネーアプリ111を起動し処理状況をクリアするために操作されるリンク情報が添付された電子メールを携帯電話100に送信する。
このように、本実施の形態においては、携帯電話100の記憶部120に記憶された処理状況を更新するための更新指示情報として、上記のようなリンク情報が添付された電子メールが送信される例を示したが、これに限定されるものではなく、電子マネー管理サーバ200が、携帯電話100のデータ処理部110に対して処理状況の更新を指示する更新指示情報を送信し、ユーザによるリンク操作等を介することなく、更新指示情報の受信に基づいて処理状況の更新が行なわれるようにしてもよい。
そして、かかる電子メールを受信した携帯電話100において、当該電子メールに添付されたリンク情報が選択操作されると、電子マネーアプリ111が起動され、図11に示す処理のステップS1110においてYESの判断がなされる。
ステップS1110においてYESの判断がなされると、ステップS1111で、データ処理部110は、このエラー対応完了メールのリンク情報の操作による電子マネーアプリ111の起動が初回であるか否かを判断する。具体的には、エラー対応完了メールのリンク情報が操作されたか否かを示す操作フラグの状態がオン状態であるかオフ状態であるかを判断することによって、初回であるか否かを判断する。
操作フラグがオン状態である、つまり、このエラー対応完了メールからの起動が初回でないと判断した場合(ステップS1111においてNOの場合)、データ処理部110は、電子マネーアプリ111を終了する。一方、操作フラグがオフ状態である、つまり、このエラー対応完了メールからの起動が初回であると判断した場合(ステップS1111においてYESの場合)、ステップS1112で、データ処理部110は、操作フラグをオン状態にする。
次に、ステップS1113で、データ処理部110は、記憶部120で管理されている処理状況をクリアする。なお、処理状況がクリアされることに限定されず、処理状況が書込済に更新されるものであってもよい。これにより、前述したような、携帯電話100から書込処理開始要求が送信され続けられるといった問題は解消する。
このように、データ処理部110は、本実施の形態における更新指示情報である前記電子メールを受信し、当該電子メールに添付されたリンク情報が操作されたことを条件として、さらには当該リンク情報の操作が初回であることを条件として、記憶部120にて管理している処理状況を強制的に更新する処理状況強制更新処理を実行する。また、図11に示して説明した通り、この処理状況強制更新処理(ステップS1113)は、更新指示情報としての電子メールに添付されたリンク情報が操作されたことを条件として実施され、電子マネーアプリ111の初期画面等からは実行できないため、ユーザの過誤等により処理状況の更新が実施されるおそれがない。さらに、この処理状況強制更新処理は、リンク操作が初回であることを条件として実行されるため、携帯電話100に保存されている電子メールのリンク情報をユーザの過誤等により複数回操作された場合にも、2回目以降の操作時には処理状況が更新されてしまうおそれがない。
次に、前述した第1の実施の形態により得られる主な効果を説明する。
(1−1) 従来、電子マネーで遊技に使用する遊技用記録媒体の発行や遊技用記録媒体に追加入金をするものがあった(たとえば、特開2002−224423号公報(たとえば、第0035段落))。この電子マネーは、利用者の取引金融機関からチャージすることができる。そして、ユーザは、チャージされた電子マネーを用いて遊技用記録媒体を購入したり、遊技用記録媒体に追加入金したりする。しかし、このような技術によれば、電子マネーのチャージは、遊技場内の所定の入金機に接続して行なう必要がある。このため、電子マネーのチャージのために、わざわざ、入金機に出向く手間が必要であった。また、入金機の台数が少ない場合は、電子マネーをチャージするためにユーザが並んで待つ状態が発生し、遊技に費やす時間が少なくなる。このため、入金機の台数を増やすことが考えられるが、設備投資費用が発生したり、入金機を設置するスペースにも限界がある。いずれにせよ、遊技者が遊技場にいる時間のうちの遊技に費やす時間をチャージに費やす必要が生じるため、遊技機の稼動に悪影響を与えるといった問題があった。
しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段と、ユーザが前記電子マネー情報のチャージに関する対価の決済に利用する金融機関を特定するための金融機関情報を前記サービス提供用サーバに送信するために出力する携帯端末側金融機関情報出力手段とを備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段と、前記携帯端末側金融機関情報出力手段から送信されてきた前記金融機関情報を受信したことを条件として、当該金融機関情報を、当該金融機関情報送信元の携帯端末を他の携帯端末と識別可能にするための識別情報と対応付けて記憶するサーバ側金融機関情報記憶手段とを備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報を受信したことを条件として、前記サーバ側金融機関情報記憶手段に記憶された金融機関情報から、当該チャージ要求情報送信元の携帯端末である要求元携帯端末を識別するための識別情報に対応付けて記憶された金融機関情報を検索する金融機関情報検索手段と、該金融機関情報検索手段により検索された金融機関情報から特定される金融機関のサーバを前記決済を行なうための通信先として指定する通信先指定情報を、前記要求元携帯端末に送信するために出力する通信先指定情報出力手段とを備え、前記携帯端末は、さらに、前記通信先指定情報出力手段から送信されてきた前記通信先指定情報により指定される金融機関のサーバに対し、前記決済を要求する決済要求情報を送信するために出力する決済要求情報出力手段を備え、前記サービス提供用サーバは、さらに、前記金融機関のサーバにおける前記決済の終了を条件として、前記電子マネー情報を前記要求元携帯端末に送信するために出力する電子マネー情報出力手段を備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備える。このように構成しているため、バリューチャージ時の手間を低減させることが可能である。
具体的には、図15のバリュー購入時処理に従って、ステップS133においてチャージ要求情報が携帯電話100から電子マネー管理サーバ200に送信されることにより、図16のバリュー購入時AP212に従って、ステップS268において引継画面情報が電子マネー管理サーバ200から携帯電話100に送信される。引継画面情報を受信した携帯電話100からは、図10のウェブ処理に従って、ステップS118aにおいてバリューの購入に対する決済に関する情報が金融機関サーバ500に送信され、当該金融機関において決済が行なわれ、その後図18のバリュー発行時処理に従って、未チャージバリューが記憶部192に書込まれる。これにより、携帯電話100から、チャージ要求情報を電子マネー管理サーバ200に送信することにより、いつでもどこでも事前にバリューをチャージあるいは遊技中であっても席を離れることなくバリューをチャージすることができるため、遊技場30に設置されているパチンコ遊技機700等の稼動に与える悪影響を減少させることができる。
(1−2) また、従来の技術においては、携帯電話100から電子マネー管理サーバ200にアクセスしてバリューを購入できるようにし、対価の決済についてはユーザの指定した金融機関サーバにアクセスすることによりモバイルバンキングサービスを利用する場合であっても、バリューを購入しようとするたびに入金に利用する金融機関を指定する必要があり、手間がかかる不都合が生じる。
しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージに関する対価の決済に利用する金融機関の指定をユーザから受付けるための処理を実行する金融機関指定処理手段と、該金融機関指定処理手段により指定を受付けた金融機関を特定するための金融機関情報を記憶する携帯端末側金融機関情報記憶手段と、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段と、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記チャージ要求情報出力手段が前記チャージ要求情報を出力したことを条件として、前記携帯端末側金融機関情報記憶手段に記憶されている前記金融機関情報から特定される金融機関のサーバに、前記決済を要求する決済要求情報を送信するために出力する決済要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記金融機関のサーバにおける前記決済の終了を条件として、前記電子マネー情報を、前記チャージ要求情報出力手段から送信されてきたチャージ要求情報の送信元の携帯端末である要求元携帯端末に送信するために出力する電子マネー情報出力手段を備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備える。このように構成しているため、バリューチャージ時の手間を低減させることが可能である。
具体的には、図8の初期登録時APに従って、ステップS219〜S224においてユーザに金融機関を選択させ、利用者情報DB221に登録する。そして、電子マネー管理サーバ200は、携帯電話100からのチャージ要求情報を受信することにより、図16のバリュー購入時AP212に従って、ステップS246において当該携帯電話100に対応付けて登録している金融機関を検索し、ステップS268において検索された金融機関の金融機関サーバ500のインターネットバンキングシステムにアクセス可能となる通信先指定情報を含む引継画面情報を当該携帯電話100に送信する。そして、携帯電話100は、図10のウェブ処理に従って、ステップS118aにおいて当該引継画面情報に基づき、指定される金融機関のサーバにバリューの購入に対する決済に関する情報を送信し決済を行なうことができる。このため、チャージを要求する度に、決済に利用する金融機関を指定する必要がないため、バリューのチャージ時の手間を低減させることができる。
(1−3) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記情報端末は、さらに、前記決済に利用する金融機関の変更をユーザから受付けるための処理を実行する金融機関変更受付手段と、該金融機関変更受付手段により受付けた金融機関を前記決済に利用する金融機関にする変更を要求するための金融機関変更要求情報を、前記サーバに送信するために出力する金融機関変更要求情報出力手段とを備え、前記サーバは、さらに、前記金融機関変更要求情報出力手段から送信されてきた前記金融機関変更要求情報を受信したことを条件として、前記サーバ側金融機関情報記憶手段において、金融機関変更要求情報送信元の情報端末の識別情報と対応付けて記憶されている金融機関情報を当該金融機関変更要求情報に従って変更される金融機関を特定するための金融機関情報に更新するサーバ側金融機関更新手段を備える。具体的には、図15のバリュー購入時処理に従って、ステップS140aにおいて金融機関変更が選択されたと判断した場合、金融機関変更問合せ情報が携帯電話100から電子マネー管理サーバ200に送信される。一方、電子マネー管理サーバ200は、金融機関変更問合せ情報に対応する画面(図35(c),(d),図37(a)等参照)を携帯電話100に送信し、携帯電話100から金融機関指定情報を受信したと判断した場合、変更した金融機関の金融機関指定情報を携帯端末情報に対応させて、利用者情報DB221に登録する処理を行なう。これにより、決済に利用する金融機関を変更することができるため、ユーザの利便性を向上させることができる。
(1−4) (1−1)で説明した課題を解消するために、たとえば、携帯電話100から電子マネー管理サーバ200にアクセスしてバリューを購入できるようにし、対価の決済についてはユーザの指定した金融機関サーバ500にアクセスすることによりモバイルバンキングサービスを利用してバリュー購入金額を決済することが考えられる。しかし、実際にバリュー購入の際には、金融機関サーバ500と接続するため携帯電話100と電子マネー管理サーバ200との接続が分断されるため、電子マネー管理サーバ200との通信を維持して一連の動作によりバリューをチャージすることができない。すなわち、電子マネー管理サーバ200との接続を一旦分断し、金融機関サーバ500に接続しバリュー購入金額の決済を済ませ、その後再度電子マネー管理サーバ200に接続し直し、バリューを携帯電話100にチャージする作業が必須となる。このため、バリューをチャージするための操作が複雑になり、ユーザの操作負担が増大する不都合が生じる。
しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段と、前記電子マネー情報のチャージに関する対価の決済を要求する決済要求情報を金融機関のサーバに送信するために出力する決済要求情報出力手段と、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記決済の終了した電子マネー情報の送信を要求する電子マネー情報送信要求を前記サービス提供用サーバに送信するために出力する電子マネー情報送信要求出力手段とを備え、前記サービス提供用サーバは、さらに、前記金融機関のサーバにおける前記決済が終了し、かつ前記電子マネー情報送信要求出力手段から送信されてきた前記電子マネー情報送信要求を受信したことを条件として、前記電子マネー情報を、当該電子マネー情報送信要求元の携帯端末に送信するために出力する電子マネー情報出力手段を備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備え、前記サービス提供用サーバは、さらに、前記金融機関のサーバにおける前記決済の終了を条件として、前記電子マネー情報送信要求出力手段により前記電子マネー情報送信要求を出力するために操作するリンク情報が添付された電子メールを、前記チャージ要求情報送信元の携帯端末である要求元携帯端末に送信するために出力する電子メール出力手段を備える。このように構成しているため、ユーザの操作負担を低減させることが可能である。
具体的には、金融機関サーバ500からの消込速報を電子マネー管理サーバ200が受信すると、図16のバリュー購入時APに従って、ステップS270においてバリュー対価決済後処理が行なわれ、図17のステップS2709において引継ぎ情報を付したメールが携帯電話100に送信される。そして、携帯電話100において、電子マネー管理サーバ200からのメールに付された引継ぎ情報が選択されると、図11のステップS191でYESと判断されて、図18のバリュー発行時処理に従って、未チャージバリューが記憶部192に書込まれる。このため、ユーザは、メールを受信したことによりバリューがチャージ可能になったことを認識することができる。また、バリューをチャージするための操作負担を軽減させることができる。
(1−5) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記携帯端末は、さらに、前記リンク情報が操作されることを条件として、前記特定プログラム記憶手段に記憶された前記特定プログラムを起動させる操作時起動手段を備え、前記電子マネー情報送信要求出力手段は、前記操作時起動手段により起動された前記特定プログラムが示す処理手順に従って、前記電子マネー情報送信要求を前記サービス提供用サーバに送信するために出力する。具体的には、メールに付された引継ぎ情報を操作することにより、図18のバリュー発行時処理が起動し、ステップS152においてバリュー発行要求情報が電子マネー管理サーバ200に送信されるため、バリューをチャージするための操作負担をより一層軽減させることができる。
(1−6) (1−4)で説明した課題に加えて、さらに、バリューが購入されてチャージ可能となっているか否かを確認することができないといった不都合が生じていた。このため、ユーザの過誤等により、未チャージバリューが電子マネー管理サーバに存在するにもかかわらず、重複してチャージを要求しバリューを購入してしまう不都合が生じる。
しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報を受信したことを条件として、当該チャージ要求情報を受付けた旨を示すチャージ受付情報を当該チャージ要求情報送信元の携帯端末である要求元携帯端末に送信するために出力するチャージ受付情報出力手段を備え、前記携帯端末は、さらに、前記チャージ受付情報出力手段から送信されてきた前記チャージ受付情報を受信したことを条件として、前記電子マネー情報のチャージに関する対価の決済を要求する決済要求情報を金融機関のサーバに送信するために出力する決済要求情報出力手段と、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記決済の終了した電子マネー情報の送信を要求する電子マネー情報送信要求を前記サービス提供用サーバに送信するために出力する電子マネー情報送信要求出力手段とを備え、前記サービス提供用サーバは、さらに、前記金融機関のサーバにおける前記決済の終了を条件として、前記要求元携帯端末に対してチャージ可能となった電子マネー情報を特定するための特定用情報を登録する特定用情報登録手段と、前記電子マネー情報送信要求出力手段から送信されてきた前記電子マネー情報送信要求を受信したことを条件として、前記特定用情報登録手段により登録された特定用情報から特定される電子マネー情報を、当該電子マネー情報送信要求元の携帯端末に送信するために出力する電子マネー情報出力手段と、該電子マネー情報出力手段によって前記電子マネー情報送信要求元の携帯端末に対して前記電子マネー情報が送信されたことを条件として、当該電子マネー情報を特定するための特定用情報の前記特定用情報登録手段における登録状態を送信済状態に更新する送信済状態更新手段とを備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から前記チャージ要求情報が送信されてきたことを条件として、前記送信済状態更新手段により登録状態が送信済状態に更新されていない前記特定用情報が前記要求元携帯端末について前記特定用情報登録手段に登録されているか否かを判定する登録判定手段を備え、前記チャージ受付情報出力手段は、前記送信済状態更新手段により登録状態が送信済状態に更新されていない前記特定用情報が前記特定用情報登録手段に登録されていると前記登録判定手段により判定されたことを条件として、前記チャージ受付情報を出力しない。このように構成しているため、ユーザの過誤等により発生する不都合を防止することが可能である。
具体的には、電子マネー管理サーバ200は、携帯電話100からのチャージ要求情報を受信した場合であっても、図16のバリュー購入時APに従って、ステップS244において図5の発行情報DB222の処理状況として「発行済」が記憶されている状態に更新されていないバリュー購入記録が登録されておりYESと判断された場合には、ステップS256における残高情報、ステップS264における合計金額確認情報、およびステップS268における引継画面情報が送信されないため、ステップS118aにおいてバリューの購入に対する決済に関する情報が金融機関サーバ500に送信されることを防止することができる。このため、図5の発行情報DB222の処理状況として「未発行」が記憶されている状態の未チャージバリューがあるにもかかわらず、ユーザの過誤等により、さらに決済の要求が行なわれ重複してバリューが購入される不都合の発生を防止することができる。
(1−7) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記サービス提供用サーバは、さらに、前記送信済状態更新手段により登録状態が送信済状態に更新されていない前記特定用情報が前記特定用情報登録手段に登録されていると前記登録判定手段により判定されたことを条件として、当該特定用情報から特定される電子マネー情報を、前記要求元携帯端末に送信するために出力するチャージ要求時電子マネー情報出力手段を備え、前記送信済状態更新手段は、前記チャージ要求時電子マネー情報出力手段によって前記要求元携帯端末に対して前記電子マネー情報が送信されたことを条件として、当該電子マネー情報を特定するための特定用情報の前記特定用情報登録手段における登録状態を送信済状態に更新する。具体的には、電子マネー管理サーバ200は、ステップS244において図5の発行情報DB222の処理状況として「発行済」が記憶されている状態に更新されていないバリュー購入記録が登録されておりYESと判断された場合に、ステップS245においてチャージ誘導画面が携帯電話100に送信された後に、図19のバリュー発行時処理APに従って、ステップ276〜S277において図5の発行情報DB222の処理状況として「未発行」が記憶されている状態のバリュー購入記録から特定される額のバリューを書込ませるためのバリュー発行情報が携帯電話100に送信される。このため、未チャージバリューをチャージするための操作を省略でき、ユーザの利便性を向上させることができる。
(1−8) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記電子マネー情報出力手段は、前記送信済状態更新手段により登録状態が送信済状態に更新されていない前記特定用情報が前記特定用情報登録手段に複数登録されていることを条件として、当該複数の特定用情報から特定される電子マネー情報を、前記電子マネー情報送信要求元の携帯端末に送信するために出力する。具体的には、電子マネー管理サーバ200が、ステップS269において金融機関サーバ500からの消込速報を受信するまでに、ステップS241において新たなチャージ要求情報を受付けた場合、図5の発行情報DB222において処理状況として「未発行」が記憶されている状態のバリュー購入記録が複数記憶されている状態になる。このような状態であるときに、ステップS241においてさらにチャージ要求情報を受付けたとき、およびステップS271においてバリュー発行要求情報を受付けたときに、ステップ276〜S277において発行情報DB222に複数記憶されている処理状況として「未発行」が記憶されている状態のバリュー購入記録から特定される額のバリューを書込ませるためのバリュー発行情報が携帯電話100に送信される。すなわち、一括してバリューをチャージすることができ、ユーザの利便性を向上させることができる。
(1−9) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報の送信を要求する電子マネー情報送信要求を前記サービス提供用サーバに送信するために出力する電子マネー情報送信要求出力手段を備え、前記サービス提供用サーバは、さらに、前記チャージ許容判定手段によりチャージを許容すると判定されたことを条件として、前記要求元携帯端末に対してチャージ可能となった電子マネー情報を特定するための特定用情報を登録する特定用情報登録手段を備え、前記電子マネー情報出力手段は、前記電子マネー情報送信要求出力手段から送信されてきた前記電子マネー情報送信要求を受信したことを条件として、前記特定用情報登録手段により登録された特定用情報から特定される電子マネー情報を、当該電子マネー情報送信要求元の携帯端末に送信するために出力し、前記サービス提供用サーバは、さらに、該電子マネー情報出力手段によって前記電子マネー情報送信要求元の携帯端末に対して前記電子マネー情報が送信されたことを条件として、当該電子マネー情報を特定するための特定用情報の前記特定用情報登録手段における登録状態を送信済状態に更新する送信済状態更新手段と、前記預かり要求情報出力手段から前記預かり要求情報が送信されてきたことを条件として、前記送信済状態更新手段により登録状態が送信済状態に更新されていない前記特定用情報が前記要求元携帯端末について前記特定用情報登録手段に登録されているか否かを判定する登録判定手段とを備え、前記預かり残額登録手段は、前記送信済状態更新手段により登録状態が送信済状態に更新されていない前記特定用情報が前記特定用情報登録手段に登録されていないと前記登録判定手段により判定されたことを条件として、前記預かり処理を行なう。具体的には、ステップS2061で携帯電話100からの残高移行依頼情報を受信したと判断した場合であっても、ステップS2064で未チャージバリューがあると判断した場合には、以降のバリュー預かり処理が行なわれないようにすることができる。このため、携帯電話100に加算可能なバリューが電子マネー管理サーバ200に存在するにもかかわらず、ユーザの過誤等により、携帯電話100の機種変更が行なわれてしまうことを防止することができる。
また、電子マネー管理サーバ200は、ステップS2061で携帯電話100からの残高移行依頼情報を受信した場合であっても、ステップS2064で発行済に設定されていない未チャージバリューがあると判断した場合には、ステップS2065,S277で説明したように、未チャージバリューを残高移行依頼情報の送信元の携帯電話100に出力することができる。このため、バリュー残高を電子マネー管理サーバ200に預けるときに、未チャージバリューを加算するための操作を省略することができる。その結果、ユーザの利便性を向上させることができる。
(1−10) ステップS259で説明した初期登録手数料を徴収するタイミングとしては、初期登録手数料の決済が済んでから、領域確保情報を携帯電話100に送信することが考えられる。しかし、このようにした場合、少額の初期登録手数料のためにわざわざ金融機関サーバ500,500Aに対して決済をしなければならず、手間が掛かるといった問題が生じる。また、この手間を省くために、初回のチャージ手数料とともに初期登録手数料を決済することが考えられる。しかし、一度もバリューがチャージされることなく、電子マネー遊技使用サービスを退会して、再度、電子マネー遊技使用サービスへ登録するようなことが悪意で繰返された場合、電子マネー遊技使用サービスを提供する提供機関は、サービス提供用領域管理機関に電子マネー遊技使用サービス用の記憶領域の確保に対する対価を支払うにもかかわらず、確保に対する初期登録手数料をユーザから決済できないといった問題が生じる。
しかし、本発明は次のような構成を含む。つまり、複数のサービス提供機関により使用が可能とされた記憶媒体を搭載する携帯端末と、前記記憶媒体に各サービス提供機関が提供するサービスに応じてサービス提供用領域の構築および削除のための処理を行なうとともに、該サービス提供用領域の構築に応じた対価を請求するために各サービス提供機関ごとに課金管理を行なうサービス提供用領域管理サーバを運営するサービス提供用領域管理機関に登録しているサービス提供機関であり、提供サービスとして電子マネーサービスを提供する電子マネーサービス提供機関に設けられるサービス提供用サーバと、前記記憶媒体に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段と、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネー情報を記憶するためのサービス提供用領域である電子マネーサービス提供用領域を前記携帯端末の前記記憶媒体に構築するための領域構築情報を当該携帯端末に送信するために出力する領域構築情報出力手段とを備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、前記領域構築情報出力手段から送信されてきた前記領域構築情報を受信したことを条件として、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記領域構築情報で示される電子マネーサービス提供用領域の構築要求を前記サービス提供用領域管理サーバに送信するために出力する構築要求出力手段と、該構築要求出力手段によって出力された構築要求に応じて前記サービス提供用領域管理サーバによって前記記憶媒体に前記電子マネーサービス提供用領域が構築されたことを条件として、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報に対応する前記電子マネー情報を当該チャージ要求情報送信元の携帯端末である要求元携帯端末に送信するために出力する電子マネー情報出力手段を備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネーサービス提供用領域に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネーサービス提供用領域に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から前記チャージ要求情報が送信されてきたのが、前記領域構築情報出力手段によって前記領域構築情報が当該要求元携帯端末に出力されてから初回であるか否かを判定する初回チャージ要求判定手段を備え、前記電子マネー情報出力手段は、前記初回チャージ要求判定手段によって初回でないと判定されたときは、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報に対応する前記電子マネー情報のチャージに関するチャージ対価の決済の終了を条件として、前記電子マネー情報を出力し、前記初回チャージ要求判定手段によって初回であると判定されたときは、前記チャージ対価と、前記領域構築情報出力手段によって出力された前記領域構築情報に対応する前記電子マネーサービス提供用領域の構築に関する領域構築対価との合計額の決済の終了を条件として、前記電子マネー情報を出力し、前記サービス提供用サーバは、さらに、前記領域構築情報出力手段によって出力された前記領域構築情報に対応する前記電子マネーサービス提供用領域の構築回数を少なくとも前記領域構築対価が未決済の携帯端末について管理する構築回数管理手段と、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したときに、前記構築回数管理手段によって管理されている前記登録要求情報送信元の前記携帯端末の前記構築回数が所定回数に達していることを条件として、前記領域構築情報出力手段による当該携帯端末への前記領域構築情報の出力を禁止する領域構築情報出力禁止手段とを備える。このように構成しているため、電子マネー遊技使用サービス用の記憶領域の確保に対する対価の決済のためのユーザの操作負担を軽減できる一方で、未決済の初期登録手数料を低減させることが可能である。
具体的には、電子マネー管理サーバ200は、携帯電話100からチャージ要求情報が送信されてきたのが、領域確保情報がチャージ要求情報の送信元の携帯電話100に送信されてから初回であるときは、チャージ手数料と初期登録手数料との合計額の決済の終了を条件として、バリュー発行情報をチャージ要求情報の送信元の携帯電話100に送信する。つまり、バリューの初回チャージのときに、チャージ手数料に併せて初期登録手数料が決済される。一方、電子マネー管理サーバ200は、携帯電話100からの登録要求に応じた未チャージ削除カウンタのカウント値が所定回数(本実施形態においては3回)に達していることを条件に領域確保情報の送信を禁止する。これにより、サービス用供用領域管理機関のリモート発行サーバ400に電子マネー遊技使用サービス用の記憶領域の領域確保情報が送信されないので、リモート発行サーバ400によって初期登録手数料の課金が行なわれない。このため、初期登録手数料の決済のためのユーザの操作負担を軽減させることができる一方で、バリューの購入をせずに電子マネー遊技使用サービス用の記憶領域の確保を繰返すことによって生じる未決済の初期登録手数料を低減させること、つまり電子マネー遊技使用サービスの提供機関に生じる損害を低減させることができる。
(1−11) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記サービス提供用サーバは、さらに、前記領域構築対価の決済が終了したことを条件として、前記構築回数管理手段に管理されている当該領域構築対価の決済が終了した携帯端末の前記構築回数を減算する構築回数減算手段を備える。具体的には、ステップS2703で説明したように、初期登録手数料が決済されたことを条件に、未チャージ削除カウンタのカウント値を減算する。このため、止むを得なく複数回登録をしなおした場合に、登録後の初回チャージ時に初期登録手数料を決済しているのに、未チャージ削除カウンタのカウント値が所定回数を超えてしまって、電子マネー遊技使用サービス用の記憶領域の確保ができなくなるといった不都合を防止できる。
(1−12) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記構築回数管理手段は、前記構築回数として前記領域構築対価の決済が終了しているか否かを示す情報を管理し、前記領域構築情報出力禁止手段は、前記構築回数管理手段によって管理されている情報によって前記登録要求情報送信元の前記携帯端末の前記領域構築対価が未決済であることが示されることを条件として、前記領域構築情報出力手段による当該携帯端末への前記領域構築情報の出力を禁止する。具体的には、前述したように(1−11)の所定回数は1回であってもよい。その場合、未チャージ削除カウンタのカウント値を管理しなくても、初期登録手数料の決済が終了しているか否かを示す情報を管理することによって、バリューの購入をせずに電子マネー遊技使用サービス用の記憶領域の確保を繰返すことによって生じる未決済の初期登録手数料を低減させることができる。
(1−13) 従来、携帯電話においてチャージ要求額を入力してサーバに送信し、電子マネー管理サーバは要求された額のバリューを携帯電話に送信してチャージするものがあった(たとえば、特開2004−272560号公報の第0125段落から第0129段落、第11図、および、第14図参照)。このようなシステムによれば、容易にバリューをチャージすることができる。この場合、ユーザのバリューの消費には特に制限が掛けられない。また、利便性が向上するが故に、遊技者が遊技にのめり込んでしまうといった問題が発生し得る。さらに、入金機に出向くことなくバリューをチャージすることができるようにした場合、さらに利便性が向上し、遊技者が遊技にのめり込むおそれが高くなる。
しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきたチャージ要求情報に対応する電子マネー情報のチャージに関する対価の決済が終了したことを条件として、前記電子マネー情報を当該チャージ要求情報送信元の携帯端末である要求元携帯端末に送信するために出力する電子マネー情報出力手段を備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備え、前記サービス提供用サーバは、さらに、所定期間内に前記対価の決済が終了した電子マネー情報の累積額または所定期間内に前記電子マネー情報出力手段により出力された電子マネー情報の累積額を各携帯端末ごとに管理する累積額管理手段と、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報を受信したときに、前記要求元携帯端末について前記累積額管理手段にて管理されている累積額と当該累積額に関して予め定められた上限額とに基づいて、電子マネー情報のチャージを許容するか否かを判定するチャージ許容判定手段とを備え、前記電子マネー情報出力手段は、該チャージ許容判定手段によりチャージを許容すると判定されたことをさらに条件として、前記電子マネー情報を前記要求元携帯端末に送信するために出力する。このように構成しているため、遊技への過度ののめり込みを防止することが可能である。
具体的には、電子マネー管理サーバ200は、ステップS253で説明したように、チャージ要求情報の送信元の携帯電話100について管理されている所定期間(本実施の形態においては当日)内の積算額である当日積算額と当該当日積算額に関して予め定められた1日購入限度額(本実施の形態においては30000円)とに基づいて、バリューの購入を許容するか否かを判定し、許容すると判定したことを条件として、ステップS277で説明したように、バリュー発行情報をチャージ要求情報の送信元の携帯電話100に送信する。このため、当日積算額と1日購入限度額とに基づいてバリューの購入を許容するか否かが判定されるので、所定期間内のチャージ額を制限することができる。その結果、チャージ要求情報の送信元の携帯電話100を使用する遊技者の遊技への過度ののめり込みを防止することができる。
(1−14) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記チャージ許容判定手段は、前記チャージ要求情報を受信したときに、前記要求元携帯端末の電子マネー情報記憶手段に記憶されている電子マネー情報の残額と当該残額に関して予め定められた上限額とに基づいて、電子マネー情報のチャージを許容するか否かを判定する。具体的には、電子マネー管理サーバ200は、ステップS251で説明したように、チャージ要求情報の送信元の携帯電話100に記憶されているバリューの残額であるバリュー残高とバリュー残高に関して予め定められた携帯上保持限度額とに基づいて、バリューの購入を許容するか否かを判定し、許容すると判定したことを条件として、ステップS277で説明したように、バリュー発行情報をチャージ要求情報の送信元の携帯電話100に送信する。このため、さらに、携帯電話100に記憶されているバリュー残高と携帯上保持限度額とに基づいてバリューの購入を許容するか否かが判定されるので、携帯電話100に記憶しておけるバリュー残高を制限することができる。その結果、遊技場30に出向かない日に1日購入限度額の範囲内で携帯電話100にバリューを溜め込んでおくことを防止することができるので、チャージ要求情報の送信元の携帯電話100を使用する遊技者の遊技への過度ののめり込みをさらに防止することができる。
(1−15) 従来、携帯電話の機種変更時にバリューを一旦、サーバに預け、機種変更後に返却を受けるシステムがあった(たとえば、特開2004−272717号公報の第0074段落から第0090段落、および、第10図から第12図参照)。このような携帯電話によれば、機種変更時にバリューを使い切ったり、放棄したりする必要がない。しかし、特開2004−272717号公報に開示されている技術のように、機種変更前にサーバにバリューを預けて、機種変更をしてバリューを購入および発行した後で、預けていたバリューの返却を受けた場合、携帯電話に記憶されるバリュー残高が携帯上保持限度額を超過してしまう。その結果、ユーザの過度の消費を助長してしまうといった問題が発生し得る。
しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報を受信したときに、当該チャージ要求情報送信元の携帯端末である要求元携帯端末の電子マネー情報記憶手段に記憶されている電子マネー情報の残額、および、電子マネー情報記憶手段に記憶可能な電子マネー情報の上限額に基づいて、電子マネー情報のチャージを許容するか否かを判定するチャージ許容判定手段と、前記チャージ許容判定手段によりチャージを許容すると判定されたことを条件として、前記電子マネー情報を前記要求元携帯端末に送信するために出力する電子マネー情報出力手段とを備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段と、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報記憶手段に記憶されている電子マネー情報の残額の預かりを要求するための預かり要求情報を前記サービス提供用サーバに送信するために出力する預かり要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記預かり要求情報出力手段から送信されてきた前記預かり要求情報から特定される電子マネー情報の残額を預かり残額として当該預かり残額を識別するための預かり残額識別情報と対応付けて登録する預かり処理を行なう預かり残額登録手段を備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記預かり残額識別情報を含む預かり残額の返却を要求するための預かり残額返却要求情報を前記サービス提供用サーバに送信するために出力する預かり残額返却要求情報出力手段を備え、前記サービス提供用サーバは、さらに、前記預かり残額返却要求情報出力手段から送信されてきた前記預かり残額返却要求情報に含まれる預かり残額識別情報に対応して前記預かり残額登録手段に登録されている前記預かり残額と前記預かり残額返却要求情報送信元の携帯端末の電子マネー情報記憶手段に記憶されている電子マネー情報の残額との合計額、および、前記上限額に基づいて前記預かり残額の返却を許容するか否かを判定する預かり残額返却許容判定手段と、該預かり残額返却許容判定手段によって返却を許容すると判定されたことを条件として、前記預かり残額の電子マネー情報を前記預かり残額返却要求情報送信元の携帯端末に送信するために出力する返却要求時電子マネー情報出力手段とを備え、前記電子マネー情報処理実行手段は、前記返却要求時電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する。このように構成しているため、ユーザが過度の消費をしてしまうことを防止することができる。
具体的には、電子マネー管理サーバ200は、ステップS2177で説明したように、預かり番号情報に含まれるお預かり番号に対応して登録されている預かり残高と預かり番号情報の送信元の携帯電話100に記憶されているバリュー残高との合計額と携帯電話100に記憶可能なバリューの上限額である携帯上保持限度額とに基づいて、預かり残高の返却を許容するか否かを判定し、許容すると判定したことを条件として、ステップS2179、S2272で説明したように、預かり残高を返却するための預かり残高情報およびバリュー返却情報を預かり番号情報の送信元の携帯電話に送信する。このため、預かり残高と携帯電話100に記憶されているバリュー残高との合計額と携帯上保持限度額とに基づいて預かり残高の返却を許容するか否かが判定されるので、預かり残高の返却時にも、携帯電話100に記憶しておけるバリュー残高を制限することができる。その結果、機種変更後の携帯電話100でバリューの購入および発行を行なった後に預かり残高の返却を受けることで携帯上保持限度額を超えたバリューが携帯電話100に記憶されることによって、ユーザが過度の消費をしてしまうことを防止することができる。
(1−16) (1−13)で説明したように、携帯電話にチャージされたバリューを遊技に使用させる場合、ユーザの過度の消費(のめり込み)を防止するために、携帯電話へのチャージ額(携帯電話に記憶できる額)や携帯電話に1日にチャージできる額に上限を設けるのが望ましい。しかし、このような上限額を設けると、バリューを使用して取引を行なう機器の試験を行なう場合に、携帯電話1台だけでは使用できるバリューの上限額をすぐに超過してしまうので、複数の携帯電話を用いる必要があり、不便であるといった問題があった。また、テスト用の携帯電話はサーバを経由せずにバリューをチャージすることができるようにすることが考えられる。しかし、このようにすると、テスト用の携帯電話になりすまされた場合、無償でバリューをチャージすることができることとなってしまい、セキュリティ上、問題となる。
しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、所定期間内に各携帯端末にチャージされた電子マネー情報の累積額を管理する累積額管理手段と、前記チャージ要求情報送信元の携帯端末である要求元携帯端末について前記累積額管理手段にて管理されている累積額である判定対象額と、前記所定期間内にチャージ可能な電子マネー情報の上限額とに基づいて、電子マネー情報のチャージを許容するか否かを判定するチャージ許容判定手段と、該チャージ許容判定手段によりチャージを許容すると判定されたことを条件として、前記電子マネー情報を前記要求元携帯端末に送信するために出力する電子マネー情報出力手段とを備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備え、前記サービス提供用サーバは、さらに、前記上限額として、一般ユーザが前記電子マネーサービスを享受するために用いる通常用携帯端末に対する通常用上限額と、前記電子マネーサービスが適正に提供されるか否かをテストするために用いるテスト用携帯端末に対する前記通常用上限額よりも高いテスト用上限額とを設定する上限額設定手段と、前記要求元携帯端末が前記通常用携帯端末であるか前記テスト用携帯端末であるかを特定する携帯端末特定手段とを備え、前記チャージ許容判定手段は、前記携帯端末特定手段によって前記通常用携帯端末であると特定された場合は、前記判定対象額と前記上限額設定手段によって設定された前記通常用上限額とに基づいて、前記チャージを許容するか否かを判定し、前記携帯端末特定手段によって前記テスト用携帯端末であると特定された場合は、前記判定対象額と前記上限額設定手段によって設定された前記テスト用上限額とに基づいて、前記チャージを許容するか否かを判定する。
また、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報送信元の携帯端末である要求元携帯端末の前記電子マネー情報記憶手段に記憶されている電子マネー情報の残額である判定対象額と、前記電子マネー記憶手段に記憶可能な電子マネー情報の上限額とに基づいて、電子マネー情報のチャージを許容するか否かを判定するチャージ許容判定手段と、該チャージ許容判定手段によりチャージを許容すると判定されたことを条件として、前記電子マネー情報を前記要求元携帯端末に送信するために出力する電子マネー情報出力手段とを備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備え、前記サービス提供用サーバは、さらに、前記上限額として、一般ユーザが前記電子マネーサービスを享受するために用いる通常用携帯端末に対する通常用上限額と、前記電子マネーサービスが適正に提供されるか否かをテストするために用いるテスト用携帯端末に対する前記通常用上限額よりも高いテスト用上限額とを設定する上限額設定手段と、前記要求元携帯端末が前記通常用携帯端末であるか前記テスト用携帯端末であるかを特定する携帯端末特定手段とを備え、前記チャージ許容判定手段は、前記携帯端末特定手段によって前記通常用携帯端末であると特定された場合は、前記判定対象額と前記上限額設定手段によって設定された前記通常用上限額とに基づいて、前記チャージを許容するか否かを判定し、前記携帯端末特定手段によって前記テスト用携帯端末であると特定された場合は、前記判定対象額と前記上限額設定手段によって設定された前記テスト用上限額とに基づいて、電子マネー情報のチャージを許容するか否かを判定する。このように構成しているため、ユーザの過度の消費を防止するとともに、電子マネーシステム10のテストを行なう際の不便さを解消しつつ、セキュリティを担保することができる。
具体的には、ステップS246a〜S253で説明したように、テスト用の携帯電話については、通常用の携帯上保持限度額および1日購入限度額よりも高いテスト用の携帯上保持限度額および1日購入限度額に基づいて、チャージを許容するか否かが判定される。このため、通常用の携帯電話を用いる場合と比較してテスト用の携帯電話を用いる場合には、通常時の額よりも多くチャージすることができ、システムの試験を行なう際の不便さを解消することができる。
また、ステップS246a〜S253で説明したように、通常用の携帯電話とテスト用の携帯電話とで、携帯上保持限度額および1日購入限度額を異ならせるだけで同様の方法でチャージを許容するか否かを判定する。このため、たとえば、テスト用の携帯電話については上限額に基づいて制限を排除するために、電子マネー管理サーバ200を経由せずにチャージを可能とするようなシステムと比較して、セキュリティホールが生じるおそれを低減できる。
(1−17) 従来、バリューをチャージする際、チャージ額を入力するための数値入力欄を携帯電話100に表示させて、ユーザに購入希望金額を入力させるものがあった。しかし、ユーザが自由に金額を入力できるため、入力金額が上限を超える場合にはユーザに再入力を促がす必要が生じ、ユーザに手間を掛けさせてしまうといった問題がある。このため、上限額の範囲内のバリューのチャージ額の選択肢を電子マネーアプリに予め組込んでおき、その選択肢から選択させることが考えられる。この場合、チャージ上限額の変更に伴なってチャージ額の選択肢を変更させるために、わざわざ、電子マネーアプリを導入し直す必要が生じる。
しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段と、前記特定プログラムが示す処理手順に従って、複数種類のチャージ額の選択肢を表示し、該選択肢のうちから、ユーザの所望するチャージ額の指定を受付けるチャージ額受付手段と、前記特定プログラムが示す処理手順に従って、該チャージ額受付手段により指定を受付けたチャージ額を示すチャージ額情報を前記サービス提供用サーバに送信するために出力するチャージ額情報出力手段とを備え、前記サービス提供サーバは、さらに、所定期間内に各携帯端末にチャージされた電子マネー情報の累積額を管理する累積額管理手段と、前記チャージ要求情報送信元の携帯端末である要求元携帯端末について前記累積額管理手段にて管理されている累積額と、予め定められた上限額とに基づいて、電子マネー情報のチャージを許容するか否かを判定するチャージ許容判定手段と、該チャージ許容判定手段によりチャージを許容すると判定され、かつ前記チャージ額情報出力手段から送信されてきたチャージ額情報が示すチャージ額の決済が終了したことを条件として、当該チャージ額の電子マネー情報を前記要求元携帯端末に送信するために出力する電子マネー情報出力手段とを備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報を受信したことを条件として、前記複数種類のチャージ額の選択肢を示す選択額情報を前記要求元携帯端末に送信するために出力する選択額情報出力手段を備え、前記チャージ額受付手段は、該選択額情報出力手段から送信されてきた選択額情報が示す複数種類のチャージ額の選択肢を表示する。
また、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段と、前記特定プログラムが示す処理手順に従って、複数種類のチャージ額の選択肢を表示し、該選択肢のうちから、ユーザの所望するチャージ額の指定を受付けるチャージ額受付手段と、前記特定プログラムが示す処理手順に従って、該チャージ額受付手段により指定を受付けたチャージ額を示すチャージ額情報を前記サービス提供用サーバに送信するために出力するチャージ額情報出力手段とを備え、前記サービス提供サーバは、さらに、前記チャージ要求情報送信元の携帯端末である要求元携帯端末の前記電子マネー情報記憶手段に記憶されている電子マネー情報の残額と、予め定められた上限額とに基づいて、電子マネー情報のチャージを許容するか否かを判定するチャージ許容判定手段と、該チャージ許容判定手段によりチャージを許容すると判定され、かつ前記チャージ額情報出力手段から送信されてきたチャージ額情報が示すチャージ額の決済が終了したことを条件として、当該チャージ額の電子マネー情報を前記要求元携帯端末に送信するために出力する電子マネー情報出力手段とを備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報を受信したことを条件として、前記複数種類のチャージ額の選択肢を示す選択額情報を前記要求元携帯端末に送信するために出力する選択額情報出力手段を備え、前記チャージ額受付手段は、該選択額情報出力手段から送信されてきた選択額情報が示す複数種類のチャージ額の選択肢を表示する。このように構成しているため、効率的にユーザに適切なチャージ額を選択させることが可能である。
具体的には、ステップS256で説明したように、ステップS247で読出された表示金額リスト情報を含む残高情報が携帯電話100に送信される。このため、電子マネー管理サーバ200において、携帯上保持限度額や1日購入限度額が変更された場合にも、電子マネーアプリを変更することなく、電子マネー管理サーバ200において表示金額リスト情報を変更することにより、携帯電話100に表示させるチャージ額の選択肢を変更することができる。
(1−18) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記サービス提供用サーバは、さらに、前記選択額情報出力手段によって前記選択額情報が出力されるときに、前記上限額から前記累積額を減算した額であるチャージ可能額を示すチャージ可能額情報を前記携帯端末に送信するために出力するチャージ可能額情報出力手段を備え、前記チャージ額受付手段は、前記選択額情報により示される複数種類のチャージ額のうち、前記チャージ可能額情報出力手段から送信されてきたチャージ可能額情報により示されるチャージ可能額以下のチャージ額を指定可能であることを示す態様で表示する。
また、前記サービス提供用サーバは、さらに、前記選択額情報出力手段によって前記選択額情報が出力されるときに、前記上限額から前記残額を減算した額であるチャージ可能額を示すチャージ可能額情報を前記携帯端末に送信するために出力するチャージ可能額情報出力手段を備え、前記チャージ額受付手段は、前記選択額情報により示される複数種類のチャージ額のうち、前記チャージ可能額情報出力手段から送信されてきたチャージ可能額情報により示されるチャージ可能額以下のチャージ額を指定可能であることを示す態様で表示する。具体的には、図41(b)で説明したように、表示金額リスト情報に含まれる複数種類の金額のうち、1日購入限度額から当日積算額を減算したステップS255で算出される購入可能金額以下であって、携帯上保持限度額からバリュー残高を減算したステップS255で算出される購入可能金額以下の金額の選択肢が指定可能であることをユーザに認識させることができる。すなわち、表示金額リスト情報に含まれる複数種類の金額のうち、1日購入限度額と当日積算額との差額および携帯上保持限度額とバリュー残高との差額の範囲内の金額の選択肢が指定可能であることをユーザに認識させることができる。その結果、ユーザに、購入できない選択肢を選択させてしまうような無駄な操作をさせることを防止することができる。
(1−19) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記携帯端末は、さらに、前記特定プログラムが示す処理手順に従って、複数種類のチャージ額の選択肢を表示し、該選択肢のうちから、ユーザの所望するチャージ額の指定を受付けるチャージ額受付手段と、前記特定プログラムが示す処理手順に従って、該チャージ額受付手段により指定を受付けたチャージ額を示すチャージ額情報を前記サービス提供用サーバに送信するために出力するチャージ額情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記複数種類のチャージ額の選択肢を示す選択額情報として、前記通常用携帯端末に対する通常用選択額情報と、前記テスト用携帯端末に対するテスト用選択額情報とを管理する選択額情報管理手段と、前記チャージ要求情報出力手段から送信されてきた前記チャージ要求情報を受信したことを条件として、前記携帯端末特定手段によって前記通常用携帯端末であると特定された場合は、前記選択額情報管理手段によって管理されている前記通常用選択額情報を前記要求元携帯端末に送信するために出力し、前記携帯端末特定手段によって前記テスト用携帯端末であると特定された場合は、前記選択額情報管理手段によって管理されている前記テスト用選択額情報を前記要求元携帯端末に送信するために出力する選択額情報出力手段とを備え、前記チャージ額受付手段は、該選択額情報出力手段から送信されてきた選択額情報が示す複数種類のチャージ額の選択肢を表示し、前記電子マネー情報出力手段は、前記チャージ額情報出力手段から送信されてきたチャージ額情報が示すチャージ額の電子マネー情報を送信する。具体的には、ステップS256で説明したように、チャージ要求情報の送信元の携帯電話が通常用の携帯電話であるかテスト用の携帯電話であるかに応じた複数種類の購入希望金額の選択肢である表示金額リストを示す表示金額リスト情報がチャージ要求情報の送信元の携帯電話に送信され、送信された表示金額リスト情報が示す複数種類の購入希望金額の選択肢が携帯電話の表示部に表示される。このため、携帯上保持限度額や1日購入限度額が変更された場合にも適切な購入希望金額の選択肢をユーザに提供できるとともに、チャージ要求情報の送信元の携帯電話が通常用であるかテスト用であるかに応じた適切な購入希望金額の選択肢を適用できる。
(1−20) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記預かり要求情報出力手段は、前記携帯端末を識別するための携帯端末識別情報を含む前記預かり要求情報を出力し、前記預かり残額登録手段は、前記預かり残額を、前記預かり要求情報に含まれる前記携帯端末識別情報とさらに対応付けて登録する前記預かり処理を行ない、前記預かり残額返却要求情報出力手段は、前記携帯端末識別情報をさらに含む前記預かり残額返却要求情報を出力し、前記サービス提供用サーバは、さらに、前記預かり残額返却要求情報出力手段から送信されてきた前記預かり残額返却要求情報に含まれる預かり残額識別情報に対応して前記預かり残額登録手段に登録されている前記携帯端末識別情報と、前記預かり残額返却要求情報出力手段から送信されてきた前記預かり残額返却要求情報に含まれる前記携帯端末識別情報とが一致するか否かを判定する携帯端末識別情報判定手段を備え、前記返却要求時電子マネー情報出力手段は、該携帯端末識別情報判定手段によって前記携帯端末識別情報が一致しないと判定されたことをさらに条件として、前記預かり残額の電子マネー情報を出力する。具体的には、ステップS2174で残高移行依頼情報に含まれる携帯端末情報と預かり番号情報に含まれる携帯端末情報とが一致しないと判断したことを条件として、ステップS2179,S2272で説明したように、預かり残高のバリューを返却するための預かり残高情報および返却実行情報が出力される。このため、残高移行依頼情報の送信元の携帯電話と預かり番号情報の送信元の携帯電話とが同一であるという機種変更が行なわれる場合には本来起こり得ない状況、つまり、不正等の疑いのある状況で、預かり残高のバリューの返却が行なわれてしまうことを防止できる。
(1−21) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記携帯端末は、さらに、当該携帯端末が前記通常用携帯端末であるか前記テスト用携帯端末であるかを特定可能な種別特定情報を前記遊技可能化処理手段に送信するために出力する種別特定情報出力手段を備え、前記遊技可能化処理手段は、前記テスト用携帯端末の使用を許可するか否かを予め設定するためのテスト用携帯端末使用可否設定手段を含み、前記種別特定情報出力手段から送信されてきた前記種別特定情報によって当該種別特定情報の送信元の携帯端末が前記テスト用携帯端末であることが特定される場合に、前記テスト用携帯端末使用可否設定手段によって前記テスト用携帯端末の使用を許可すると設定されていることを条件として、当該種別特定情報の送信元の携帯端末の電子マネー情報記憶手段に記憶されている電子マネー情報を用いた前記遊技可能化処理を実行する。具体的には、ステップS345およびステップS346で説明したように、テスト用の携帯電話の盗難などが発生した場合には、盗まれたテスト用の携帯電話の使用を許可しないように設定しておくことによって、盗まれた携帯電話に記憶されているバリューを用いたプリペイドカード371の発券が実行されないようにすることができる。このため、テスト用の携帯電話の盗難などが発生した場合に、盗まれたテスト用の携帯電話の使用を防止できる。
(1−22) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記遊技可能化処理手段は、前記電子マネー情報処理実行手段により実行される処理により加算される特定の種類の電子マネー情報を減算する対象として指定する種類指定情報を前記携帯端末に送信するために出力する種類指定情報出力手段を含み、前記電子マネー情報減算手段は、前記種類指定情報出力手段から送信されてきた前記種類指定情報に基づき、減算する対象として指定された前記特定の種類の電子マネー情報を減算する。具体的には、図50の発券処理および図53の球貸処理に従って、それぞれ、ステップS356およびS656において特定の種類の電子マネーであるバリューを引落対象として指定する電子マネー識別情報を含む減算要求信号が、券売機300またはカードユニット600から携帯電話100に送信され、当該電子マネー識別情報により指定されるバリューのみを用いてプリペイドカード371の購入または球貸を行なうことができるため、異なる種類のバリューを用いてプリペイドカード371の購入または球貸が行なわれることを防止することができる。
(1−23) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記遊技用電子マネーシステムは、さらに、前記遊技場において、前記遊技可能化処理手段によって前記遊技可能化処理に用いられた前記減算された電子マネー情報の額を特定可能な減算額特定情報と、該電子マネー情報が減算された携帯端末の識別情報とを対応付けて記憶する減算電子マネー情報記憶手段と、前記減算電子マネー情報記憶手段に記憶された前記減算額特定情報と該減算額特定情報に対応する前記識別情報とを含む取引情報を前記遊技場から前記サービス提供用サーバに所定時間ごとに送信するために出力する減算電子マネー情報出力手段とを含み、前記サービス提供用サーバは、さらに、前記電子マネー情報出力手段によって出力された前記電子マネー情報の額を特定可能な送信額特定情報と、前記要求元携帯端末の識別情報とを対応付けて記憶する送信電子マネー情報記憶手段と、前記減算電子マネー情報出力手段から送信されてきた前記取引情報と、前記送信電子マネー情報記憶手段に前記識別情報と対応して記憶された情報とに基づいて、識別情報ごとに電子マネー情報の残額を管理し、残額を超えた不正取引があったか否かを判定する不正取引判定手段と、該不正取引判定手段によって前記不正取引があると判定されたことを条件として、当該不正取引と判定された取引情報に対応する識別情報を、当該不正取引が発生した遊技場側に送信するために出力する不正取引識別情報出力手段とを備え、前記遊技用電子マネーシステムは、さらに、前記遊技場において、前記不正取引識別情報出力手段から送信されてきた前記識別情報を記憶する不正取引識別情報記憶手段と、前記遊技場において、前記遊技可能化処理手段により前記遊技可能化処理に用いられる携帯端末が、前記不正取引識別情報記憶手段に記憶された識別情報が示す不正携帯端末であるか否かを判定する不正携帯端末判定手段と、該不正携帯端末判定手段によって前記不正携帯端末であると判定されたことを条件として、該不正携帯端末に対して、前記遊技可能化処理手段による前記遊技可能化処理を停止する不正携帯端末使用停止手段とを含む。具体的には、ステップS812において、プリペイドカード371の購入または球貸処理に用いたバリューの額と当該購入または球貸に用いた携帯電話100の携帯IDとが各々対応付けて店舗サーバ800に記憶される。そして、ステップS813において所定時間経過したと判断された場合、ステップS814において店舗サーバ800に記憶されていた情報を取引情報として電子マネー管理サーバ200に送信される。一方、ステップS2707においては、チャージ累計額と携帯IDとが各々対応付けて発行情報DB222に記憶される。そして、ステップS292において、取引情報に含まれる携帯IDに対応する会員IDのチャージ累計額から取引情報に含まれる取引額が減算され、ステップS281において、チャージ累計額がマイナスの会員IDがあるか否かを判断することにより不正取引があったか否かが判断される。不正取引があった場合は、ステップS286において不正端末情報が、不正取引が発生した遊技場30に送信される。
不正端末情報を受信した遊技場30においては、ステップS314およびS604において、当該不正端末情報が記憶され、バリューでプリペイドカード371を購入する際および球貸処理に用いる際、携帯電話100の携帯IDが不正端末情報と一致するか否かが判断され、一致する場合、残高をバリュー残額にセットしない処理、すなわち使用停止処理が行なわれる。これにより、残額を超えた不正が行なわれたときの被害を最小限に抑えることができる。
(1−24) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記サービス提供用サーバは、さらに、前記不正取引判定手段によって前記不正取引があると判定された頻度を測定する不正取引頻度測定手段と、前記不正取引頻度測定手段によって測定された頻度に応じて、前記不正取引があった旨を示す不正取引発生情報を当該不正取引が発生した遊技場側に送信するために出力する不正取引発生情報出力手段とを備え、前記不正取引識別情報出力手段は、前記不正取引頻度測定手段によって測定された頻度に応じて前記識別情報を出力し、前記遊技用電子マネーシステムは、さらに、前記遊技場において、前記不正取引発生情報出力手段から前記不正取引発生情報が送信されてきたことを条件として、該遊技場内のすべての前記遊技可能化処理手段による前記遊技可能化処理を停止する電子マネー情報使用停止手段と、前記不正取引頻度測定手段によって測定された頻度に応じて、前記不正携帯端末使用停止手段または前記電子マネー情報使用停止手段を選択して、該選択された手段による停止処理を実行させる選択実行手段とを含む。具体的には、ステップS281において不正取引があった場合、ステップS282において不正回数が1加算され、不正取引の頻度が測定されている。そして、不正回数が1回の場合、ステップS284において不正媒体情報を不正取引が発生した遊技場30に送信され、不正取引に用いられたプリペイドカードによる球貸を禁止する。また、不正回数が2回の場合、ステップS286およびステップS287において不正端末情報を不正取引が発生した遊技場30および当該遊技場30と同じ商圏の他の遊技場に送信され、不正取引に用いられた携帯電話100によるプリペイドカード317の購入および球貸を禁止する。
さらに、不正回数が3回の場合、ステップS289およびステップS290において携帯使用禁止情報を不正取引が発生した遊技場30および全国の遊技場に送信される。そして、携帯使用禁止情報を受信した遊技場においては、ステップS312およびステップS602において、それぞれ、当該携帯使用禁止情報が記憶され、ステップS322およびステップS622により、それぞれ、すべての携帯電話についてバリューを用いてのプリペイドカード371購入および球貸を禁止する処理が行なわれる。このように、不正取引の頻度に応じて禁止する内容が選択され実行されるため、より効果的に不正が行なわれたときの被害を最小限に抑えることができる。
(1−25) 非接触型ICチップを内蔵した携帯電話により電子マネー端末またはサーバと通信して、バリューの加減算を行なうものがあった(たとえば、特開2005−38209号公報の第0016段落、第0017段落、第0049段落から第0055段落、第0111段落から第0114段落、第0136段落、および、第0138段落参照)。この携帯電話のアプリケーション部には、決済を行なう対象の電子マネー端末を特定する端末ID、事業者コード、動作パラメータ、および、動作ファイルが対応付けられて記憶される。
この携帯電話が用いられて電子マネー端末で決済される場合、電子マネー端末から端末IDおよび決済額分のバリューが減算された後、減算完了通知が送信されるとともに、この端末IDから事業者コード、動作パラメータ、および、動作ファイルが特定され、この動作ファイルが用いられて所定の動作が実行される。また、携帯電話にログ確認部が設けられて、アプリケーション部に予め確認金額が設定されることにより、ログ確認部が定期的にバリューの残額を確認し、確認金額を下回った場合、アプリケーション部が動作ファイルを用いて所定の動作として画像や音声でアラームを発することで電子マネーのチャージをユーザに促がすようにする。しかし、特開2005−38209号公報に開示されている技術によれば、携帯電話で実行できる動作ファイルは、端末IDに対応する各事業者コードに対して1ファイルであるため、実行される動作は、電子マネー端末との決済処理の都度実行される動作に限定される。また、携帯電話は能動的に動作ファイルを実行するため、バリューの残高の不足確認は、前述したように行なわれる。このため、バリューの残高が確認金額を上回っていても、決められた定期間隔で、バリューの残高を確認するという無駄な処理が発生してしまうといった問題がある。また、バリューの残高が確認金額を下回っていても、決められた定期間隔が長い間隔(たとえば、1時間)である場合は、バリューのチャージがユーザに促がされる前に、電子マネー端末またはサーバによりバリューの減算が行なわれる際に、ユーザが残高不足を認識してしまい、ユーザにチャージを促がす処理を実行するという特開2005−38209号公報に開示されている技術の本来の目的を達成できないこととなってしまう。このことから、ユーザが残高不足を認識してしまう前に、バリューのチャージを促がすために、バリューの残高を確認する定期間隔を短くする(たとえば、1分や30秒にする)必要がある。このため、バリューの残高を確認するという無駄な処理を頻繁に実行しなければならず非効率であるとともに、携帯電話のバッテリーの持続時間にも影響が生じるといった問題が発生する。
しかし、本発明は次のような構成を含む。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきたチャージ要求情報を受信したことを条件として、前記電子マネー情報を当該チャージ要求情報送信元の携帯端末である要求元携帯端末に送信するために出力する電子マネー情報出力手段を備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段と、前記電子マネー情報記憶手段に記憶された電子マネー情報の残額を特定可能な残額特定情報を前記遊技可能化処理手段に送信するために出力する残額特定情報出力手段とを備え、前記遊技可能化処理手段は、前記残額特定情報出力手段から送信されてきた残額特定情報で特定される電子マネー情報の残額が、前記遊技可能化処理が実行されるときに用いられる額に不足しているか否かを判定する残額不足判定手段と、前記残額不足判定手段によって不足していると判定されたことを条件として、前記残額が不足していることを示す残額不足情報を前記残額特定情報の送信元の携帯端末に送信するために出力する残額不足情報出力手段とを含み、前記携帯端末は、さらに、前記残額不足情報出力手段から前記残額不足情報を受信したことを条件として、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記残額が不足している旨を報知する残額不足報知手段を備える。このように構成しているため、バリューの残額が少ないことを効率的に的確にユーザに認識させることができる。
具体的には、携帯電話100の非接触型ICチップ190の機能によってバリュー残高が券売機300またはカードユニット600に送信される。また、ステップS351で説明したように、券売機300によって携帯電話100に記憶されているバリュー残高がプリペイドカード371の購入金額に不足していると判定され、ステップS352で説明したように、減算前残高不足情報が携帯電話100に送信される。また、ステップS651およびステップS658で説明したように、カードユニット600によって携帯電話100に記憶されているバリュー残高が球貸可能な最低額に不足していると判定され(本実施の形態においては、バリュー残高が0円であるか否かを判定、遊技場30以外でバリューを使用できる場合は、バリュー残高が球貸可能な最低額である100円未満であるか否かを判定)、ステップS652およびステップS659で説明したように、それぞれ、減算前残高不足情報または減算後残高不足情報が携帯電話100に送信される。そして、ステップS185で説明したように、携帯電話100によってバリュー残高が不足している旨が報知される。つまり、バリューが用いられるときに、携帯電話100によって、受動的に、バリュー残高が不足している旨が報知される。その結果、バリュー残高が少ないことを効率的に的確にユーザに認識させることができる。
(1−26) また、本発明は、次のような構成を含むようにしてもよい。つまり、電子マネーサービスを提供するサービス提供用サーバと、電子マネー情報を記憶する電子マネー情報記憶手段を備えた携帯端末と、前記電子マネー情報記憶手段に記憶された電子マネー情報を用いて遊技場に設置された遊技機での遊技を可能にするための遊技可能化処理を実行する遊技可能化処理手段とを含む遊技用電子マネーシステムであって、前記携帯端末は、前記電子マネーサービスを享受できるようにするための登録を要求する登録要求情報を前記サービス提供用サーバに送信するために出力する登録要求情報出力手段を備え、前記サービス提供用サーバは、前記登録要求情報出力手段から送信されてきた前記登録要求情報を受信したことを条件として、前記電子マネーサービスを享受するための処理手順を示す特定プログラムを、当該登録要求情報送信元の携帯端末に送信するために出力する特定プログラム出力手段を備え、前記携帯端末は、さらに、前記特定プログラム出力手段から送信されてきた前記特定プログラムを記憶する特定プログラム記憶手段と、該特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求情報を前記サービス提供用サーバに送信するために出力するチャージ要求情報出力手段とを備え、前記サービス提供用サーバは、さらに、前記チャージ要求情報出力手段から送信されてきたチャージ要求情報を受信したことを条件として、前記電子マネー情報を当該チャージ要求情報送信元の携帯端末である要求元携帯端末に送信するために出力する電子マネー情報出力手段を備え、前記携帯端末は、さらに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報出力手段から送信されてきた前記電子マネー情報を、前記電子マネー情報記憶手段に記憶された前記電子マネー情報に加算するための処理を実行する電子マネー情報処理実行手段と、前記電子マネー情報記憶手段に記憶された前記電子マネー情報から、前記遊技可能化処理手段により前記遊技可能化処理が実行されるときに用いられる額の電子マネー情報を減算する電子マネー情報減算手段と、前記電子マネー情報記憶手段に記憶された電子マネー情報の残額を特定可能な残額特定情報を前記遊技可能化処理手段に送信するために出力する残額特定情報出力手段とを備え、前記遊技可能化処理手段は、前記残額特定情報出力手段から送信されてきた残額特定情報で特定される電子マネー情報の残額から前記遊技可能化処理が実行されるときに用いられる額を減算した額が所定額以下となるか否かを判定する残額不足判定手段と、前記残額不足判定手段によって前記所定額以下となると判定されたことを条件として、前記残額が所定額以下となることを示す残額不足情報を前記残額特定情報の送信元の携帯端末に送信するために出力する残額不足情報出力手段とを含み、前記携帯端末は、さらに、前記残額不足情報出力手段から前記残額不足情報を受信したことを条件として、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記残額が前記所定額以下となる旨を報知する残額不足報知手段を備える。具体的には、携帯電話100の非接触型ICチップ190の機能によってバリュー残高が券売機300に送信され、ステップS358で説明したように、券売機300によって携帯電話100に記憶されているバリュー残高からプリペイドカード371の購入金額を減算した額が所定額以下となると判定され、ステップS359で説明したように、減算後残高僅少情報が携帯電話100に送信されて、ステップS184で説明したように、携帯電話100によってバリュー残高が所定額以下となる旨が報知される。カードユニット600についても同様である。つまり、バリューが用いられるときに、携帯電話100によって、受動的に、バリュー残高が所定額以下となる旨が報知される。その結果、バリュー残高が少ないことを効率的に的確にユーザに認識させることができる。
(1−27) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記携帯端末は、さらに、前記残額不足情報出力手段から前記残額不足情報を受信したときに、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、前記電子マネー情報のチャージを要求するためのチャージ要求処理を実行するチャージ要求処理実行手段を備え、前記チャージ要求情報出力手段は、該チャージ要求処理実行手段によって前記チャージ要求処理が実行された後に、前記チャージ要求情報を出力する。具体的には、ステップS181またはステップS182で減算前残高不足情報、減算後残高不足情報、または、減算後残高僅少情報が受信されたときにバリュー購入時処理が実行され、ステップS133で説明したように、バリュー購入時処理の実行開始後に自動的にチャージ要求情報が送信されるため、ユーザがバリュー購入時処理を能動的に実行させなくてもよい。このため、バリュー購入時処理を実行させる手間をユーザに掛けさせないようにできる。また、バリュー購入時処理が即座に実行されるので、バリュー購入に要する時間が短縮され、遊技場30におけるパチンコ遊技機700やスロットマシン等の遊技機の稼動率を向上させることができる。
(1−28) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記チャージ要求処理実行手段は、前記特定プログラム記憶手段に記憶された前記特定プログラムが示す処理手順に従って、複数種類のチャージ額の選択肢を表示し、該選択肢のうちから、ユーザの所望するチャージ額の指定を受付けるチャージ額受付手段を含む。具体的には、バリュー購入時処理として、ステップS139で購入希望金額の選択肢が表示され、ステップS141で購入希望金額の選択が受付けられるので、ユーザが能動的にバリュー購入時処理を実行させて購入希望金額の選択肢を表示させなくてもよい。このため、バリュー購入時処理を実行させ購入希望金額の選択肢を表示させる手間をユーザに掛けさせないようにできる。また、バリュー購入時処理が即座に実行され購入希望金額の選択肢が表示されるので、バリュー購入に要する時間が短縮され、遊技場30におけるパチンコ遊技機700やスロットマシン等の遊技機の稼動率を向上させることができる。
(2−1) 従来、電子マネーをネットチャージするものがあった。ネットチャージとは、携帯端末からサーバへのチャージの要求に対してサーバがインターネットなどのネットワークを介して携帯端末に電子マネーをチャージすることをいう。この場合に、携帯端末は、電子マネーの書込みに伴なってログを更新するとともに、電子マネーサーバに書込完了を送信する。また、電子マネーサーバも取引ログを更新する(たとえば、特開2004−272560号公報)。しかし、このような技術においては、携帯端末においてログの更新に失敗すると、携帯端末側の管理状況は未書込である一方、サーバ側の管理状況は書込済となる。このため、両者の管理状況に不一致が生じるために、その後の処理に不都合が発生するといった問題があった。
しかし、本発明は次のような構成を含む。つまり、ユーザが所望するデータが書込まれる記憶手段を備えた携帯端末と、該携帯端末に対して前記データを発行する発行処理と、該発行したデータを前記記憶手段に書込むための書込処理とを行なう発行書込処理サーバとを備えたデータ発行書込システムであって、前記携帯端末は、前記データの処理状況を管理する処理状況管理手段と、該処理状況管理手段によって管理されている処理状況が未書込であることを条件として、前記データの書込みを要求するための書込要求情報を前記発行書込処理サーバに送信するために出力する書込要求出力手段を備え、前記発行書込処理サーバは、前記携帯端末に対して書込むべきデータが書込済か否かを示す書込状況を管理する書込状況管理手段と、前記書込要求出力手段から送信されてきた前記書込要求情報に対応するデータの前記書込状況管理手段によって管理されている書込状況が未書込であることを条件として、当該データの前記記憶手段への書込みを指示する書込指示情報を、当該書込要求情報の送信元の携帯端末である要求元携帯端末に送信するために出力する書込指示出力手段と、該書込指示出力手段によって前記書込指示情報が出力されたことを条件として、当該書込指示情報で書込みが指示されたデータの前記書込状況管理手段によって管理されている書込状況を、書込済に更新する書込状況更新手段とを備え、前記携帯端末は、さらに、前記書込指示出力手段から前記書込指示情報を受信したことを条件として、当該書込指示情報で書込みが指示されたデータを前記記憶手段に書込むための処理を実行するデータ書込実行手段と、該書込処理実行手段によって前記データを書込むための処理が実行されたことを条件として、当該データの前記処理状況管理手段によって管理されている処理状況を、データ書込済に更新する処理状況更新手段とを備え、前記発行書込処理サーバは、さらに、前記処理状況管理手段によって管理されている処理状況を更新させるための更新指示情報を前記携帯端末に送信するために出力する更新指示出力手段を備え、前記携帯端末は、前記更新指示出力手段からの前記更新指示情報の受信に基づいて、前記処理状況管理手段によって管理されている処理状況を更新する処理状況強制更新処理を実行する処理状況強制更新手段を備える。このように構成しているため、データの書込みに関し携帯端末とサーバとで管理されている状況の不一致を解消し、その後の処理の不都合を解消することができる。
具体的には、データ発行書込システム(たとえば、電子マネーシステム10)は、ユーザが所望するデータ(たとえば、バリュー等の電子マネー情報)が書込まれる記憶手段(たとえば、非接触型ICチップ190の記憶部192)を備えた携帯端末(たとえば、携帯電話100)と、該携帯端末に対して前記データを発行する発行処理と、該発行したデータを前記記憶手段に書込むための書込処理とを行なう発行書込処理サーバ(たとえば、電子マネー管理サーバ200、決済サーバ280、リモート発行サーバ400)とを備える。ステップS122a,S127,S153a,S157a,S1607a,S1614a,S1716,S1724aで説明したように、携帯端末によって、データの処理状況(たとえば、処理状況)が管理される。ステップS154で説明したように、携帯端末によって、管理されている処理状況が未書込であること(たとえば、ステップS151においてYESの場合)を条件として、データの書込みを要求するための書込要求情報(たとえば、書込処理開始要求)が発行書込処理サーバに送信するために出力される。図5の発行情報DB222で説明したように、発行書込処理サーバによって、携帯端末に対して書込むべきデータが書込済(たとえば、発行済)か否かを示す書込状況(たとえば、処理状況)が管理される。送信されてきた書込要求情報に対応するデータの管理されている書込状況が未書込であること(たとえば、ステップS274においてYESの場合)を条件として、当該データの書込みを指示する書込指示情報(たとえば、書込実行情報)が、当該書込要求情報の送信元の携帯端末である要求元携帯端末に送信するために出力される(たとえば、リモート発行サーバ400による書込実行情報の送信)。書込指示情報が出力されたこと(たとえば、リモート発行サーバ400によって書込実行が送信されたこと)を条件として、当該書込指示情報で書込みが指示されたデータの管理されている書込状況が、書込済(たとえば、書込終了済)に更新される(たとえば、リモート発行サーバ400による処理状況の書込終了済への更新、または、ステップS2796)。ステップS156で説明したように、携帯端末によって、書込指示情報を受信したこと(たとえば、ステップS155においてYESの場合)を条件として、当該書込指示情報で書込みが指示されたデータを書込むための処理(たとえば、書込処理)が実行される。ステップS157aで説明したように、携帯端末によって、データを書込むための処理が実行されたこと(たとえば、ステップS157またはステップS157bにおいてYESの場合)を条件として、当該データの管理されている処理状況が、データ書込済(たとえば、書込済)に更新される。ステップS2918で説明したように、発行書込処理サーバによって、管理されている処理状況を更新させるための更新指示情報(たとえば、エラー対応完了メール)が携帯端末に送信するために出力される。S1113で説明したように、携帯端末によって、更新指示情報の受信に基づいて(たとえば、エラー対応完了メールから電子マネーアプリ111が起動されたことを条件として)、管理されている処理状況を更新する処理状況強制更新処理が実行される。これにより、通常は、発行書込処理サーバでは、書込指示情報の出力を条件として、書込状況が書込済に更新され、携帯端末では、書込指示情報で書込みが指示されたデータを書込むための処理の実行を条件として、処理状況がデータ書込済に更新される。しかし、データが書込まれたときに携帯端末側で処理状況のデータ書込済への更新に失敗した場合であっても、発行書込処理サーバからの指示で強制的に処理状況が更新される。その結果、データの書込みに関し携帯端末における処理状況と発行書込処理サーバにおける書込状況との不一致を解消し、その後の処理の不都合を解消することができる。
(2−2) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記発行書込処理サーバは、さらに、前記携帯端末から処理状況を取得する処理状況取得手段と、該処理状況取得手段によって取得された処理状況に基づいた処理を実行する取得状況処理実行手段とを備える。具体的には、ステップS2914で説明したように、発行書込処理サーバによって、携帯端末から処理状況が取得される。ステップS2916〜S2918で説明したように、発行書込処理サーバによって、取得された処理状況に基づいた処理が実行される。これにより、発行書込処理サーバによって取得された処理状況に基づいた処理が実行される。このため、処理状況が発行書込処理サーバで確認された上で必要な処理が実行されるようにすることができる。
(2−3) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記取得状況処理実行手段は、前記処理状況取得手段によって取得された処理状況と、前記書込状況管理手段によって管理されている書込状況とが一致するか否かを判断し、前記更新指示出力手段は、前記取得状況処理手段によって一致しないと判断されたことを条件として、前記更新指示情報を出力する。具体的には、ステップS2916およびステップS2917aで説明したように、発行書込処理サーバによって、取得された処理状況と、管理されている書込状況とが一致するか否かが判断される。ステップS2918で説明したように、発行書込処理サーバによって、一致しないと判断されたこと(たとえば、ステップS2917aにおいてYESの場合)を条件として、更新指示情報が出力される。これにより、オペレータによる確認作業等の手間を省くことができる。
(2−4) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記更新指示出力手段は、前記処理状況強制更新処理を実行させるために操作されるリンク情報が添付された電子メールを、前記更新指示情報として出力し、前記更新指示出力手段から送信されてきた前記電子メールに添付されたリンク情報が操作されることを条件として、前記処理状況強制更新手段は、前記処理状況強制更新処理を実行する。具体的には、ステップS2918で説明したように、発行書込処理サーバによって、処理状況強制更新処理を実行させるために操作されるリンク情報が添付された電子メール(たとえば、エラー対応完了メール)が、更新指示情報として出力される。ステップS1113で説明したように、携帯端末によって、送信されてきた電子メールに添付されたリンク情報が操作されること(たとえば、ステップS1110においてYESの場合)を条件として、処理状況強制更新処理が実行される。これにより、発行書込処理サーバ側での処理が終了し、処理状況の更新が可能となったことをユーザに確実に認識させることができるとともに、更新のためのユーザの操作負担も軽減させることができる。また、発行書込処理サーバから更新指示情報が出力されることなく処理状況強制更新処理が行なわれないようにすることができるので、ユーザの誤操作や悪用によって処理状況が強制的に更新されないようにすることができる。
(2−5) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記携帯端末は、さらに、前記リンク情報の操作が初回か否かを判定するリンク操作判定手段を備え、前記処理状況強制更新手段は、前記リンク操作判定手段によって前記リンク情報の操作が初回であると判定されたことをさらに条件として、前記処理状況強制更新処理を実行する。具体的には、ステップS1111で説明したように、携帯端末によって、リンク情報の操作が初回か否かが判定される。ステップS1113で説明したように、携帯端末によって、リンク情報の操作が初回であると判定されたこと(たとえば、ステップS1111においてYESの場合)をさらに条件として、処理状況強制更新処理が実行される。これにより、ユーザの過誤等によりリンク情報が複数回操作されても、その度に処理状況が更新されないようにすることができる。
(3−1) 従来、データを発行する発行処理サーバと、発行されたデータを携帯端末に書込むデータ書込処理を行なう書込処理サーバとが別個に設けられるシステムがあった(たとえば、株式会社エヌ・ティ・ティ・ドコモ東海、新しいケータイの活用例「iモード(登録商標)Felica(登録商標)」、[online]、[2005年12月9日]、インターネット〈URL:http://www.docomo-tokai.co.jp/businesshub/bh/felica/donyu.html〉)。しかし、このような技術によれば、発行処理サーバからデータの発行を受けた後に、当該データの書込処理において書込処理サーバとの通信が切断された場合に、再度データ発行のための処理をやり直し、発行処理サーバに発行要求を送信すると、発行処理サーバにおいてはデータを発行済であるため、発行要求が受付けられずデータを書込むことができなくなってしまうといった問題があった。
しかし、本発明は次のような構成を含む。つまり、ユーザが所望するデータの書込処理を行なう書込処理サーバからの指示に基づいて前記データが書込まれる記憶手段を備えた携帯端末と、該携帯端末に対して前記データを発行する発行処理サーバとを備えたデータ発行システムであって、前記携帯端末は、前記データの発行を要求するための発行操作をユーザから受付ける発行操作受付手段と、前記発行操作受付手段によって発行操作が受付けられたことを条件として、前記データの発行を要求するための発行要求情報を前記発行処理サーバに送信するために出力する発行要求出力手段とを備え、前記発行処理サーバは、前記携帯端末に対して発行すべきデータが発行済か否かを示す発行状況を管理する発行状況管理手段と、前記発行要求出力手段から送信されてきた前記発行要求情報に対応するデータの前記発行状況管理手段によって管理されている発行状況が、未発行であることを条件として、当該データを、当該発行要求情報の送信元の携帯端末である要求元携帯端末に送信するために出力するデータ出力手段と、該データ出力手段によって前記データが出力されたことを条件として、当該データの前記発行状況管理手段によって管理されている発行状況を、発行済に更新する発行状況更新手段とを備え、前記携帯端末は、さらに、前記データの処理状況を管理する処理状況管理手段と、前記データ出力手段から送信されてきた前記データを受信したことを条件として、当該データの前記処理状況管理手段によって管理されている処理状況を、データ受信済に更新する処理状況更新手段と、前記データ出力手段から送信されてきた前記データを受信したことを条件として、当該データの前記記憶手段への書込みを要求する書込要求情報を、前記書込処理サーバに送信するために出力する書込要求出力手段と、前記書込処理サーバから前記データの前記記憶手段への書込みを指示する書込指示情報を受信したことを条件として、前記データを前記記憶手段に書込むデータ書込実行手段とを備え、前記処理状況更新手段は、前記データ書込実行手段によって前記データが書込まれたことを条件として、当該データの前記処理状況管理手段によって管理されている処理状況を、データ書込済に更新し、前記携帯端末は、さらに、前記発行操作受付手段によって発行操作が受付けられたときに、前記処理状況管理手段によって管理されている処理状況がデータ受信済であることを条件として、前記発行要求出力手段による前記発行要求情報の出力を実行することなく、前記書込要求出力手段による前記書込要求情報の前記書込処理サーバへの出力を実行する要求出力実行制御手段を備える。このように構成しているため、書込処理サーバとの通信が切断された場合であっても、再度行なった発行操作に基づいて確実にデータを書込むことができる。
具体的には、データ発行システム(電子マネーシステム10)は、ユーザが所望するデータ(たとえば、バリュー等の電子マネー情報)の書込処理を行なう書込処理サーバ(たとえば、リモート発行サーバ400)からの指示に基づいてデータが書込まれる記憶手段(たとえば、非接触型ICチップ190の記憶部192)を備えた携帯端末(たとえば、携帯電話100)と、該携帯端末に対してデータを発行する発行処理サーバ(たとえば、電子マネー管理サーバ200、決済サーバ280)とを備える。ステップS194またはステップS191で説明したように、携帯端末によって、データの発行を要求するための発行操作(たとえば、図28(b)の画面で丸付き数字2の「ICチップへの購入バリューのチャージ」の選択肢を選択する操作、または、図33(b)の画面で引継ぎ情報を選択する操作)がユーザから受付けられる。ステップS152で説明したように、携帯端末によって、発行操作が受付けられたこと(たとえば、ステップS194またはステップS191においてYESの場合)を条件として、データの発行を要求するための発行要求情報(たとえば、バリュー発行要求情報)が発行処理サーバに送信するために出力される。図5の発行情報DB222で説明したように、発行処理サーバによって、携帯端末に対して発行すべきデータが発行済(たとえば、発行済)か否(たとえば、未発行)かを示す発行状況(たとえば、処理状況)が管理される。ステップS277で説明したように、発行処理サーバによって、送信されてきた発行要求情報に対応するデータの管理されている発行状況が、未発行であること(たとえば、ステップS274においてYESの場合)を条件として、当該データ(たとえば、バリュー発行情報)が、当該発行要求情報の送信元の携帯端末である要求元携帯端末に送信するために出力される。ステップS279で説明したように、データが出力されたこと(たとえば、ステップS278においてYESの場合)を条件として、当該データの管理されている発行状況が、発行済に更新される。ステップS122a,S127,S153a,S157a,S1607a,S1614a,S1716,S1724aで説明したように、携帯端末によって、データの処理状況が管理される。ステップS153aで説明したように、携帯端末によって、送信されてきたデータを受信したこと(たとえば、ステップS153においてYESの場合)を条件として、当該データの管理されている処理状況が、データ受信済(たとえば、発行情報受信済)に更新される。ステップS154で説明したように、携帯端末によって、送信されてきたデータを受信したこと(たとえば、ステップS153においてYESの場合)を条件として、当該データの書込みを要求する書込要求情報(たとえば、書込処理開始要求)が、書込処理サーバに送信するために出力される。ステップS156で説明したように、携帯端末によって、書込処理サーバからデータの書込みを指示する書込指示情報を受信したこと(たとえば、ステップS155においてYESの場合)を条件として、データが書込まれる。ステップS157aで説明したように、携帯端末によって、データが書込まれたこと(たとえば、ステップS157においてYESの場合)を条件として、当該データの管理されている処理状況が、データ書込済(たとえば、書込済)に更新される。ステップS154で説明したように、携帯端末によって、発行操作が受付けられたときに、管理されている処理状況がデータ受信済であること(たとえば、ステップS151においてYESの場合)を条件として、発行要求情報の出力が実行されることなく(たとえば、ステップS152においてバリュー発行要求情報を送信することなく)、書込要求情報の書込処理サーバへの出力が実行される。これにより、発行処理サーバによってデータが送信され発行状況が発行済に更新された後に、携帯端末によって受信されたデータの書込みのための携帯端末による書込処理サーバとの通信が切断された場合であっても、携帯端末によって処理状況がデータ受信済に更新されているため、発行操作が改めて受付けられたときに、再度、発行要求情報が発行処理サーバに送信されることなく、データの書込みの要求が書込処理サーバに送信される。このため、発行処理サーバが発行済のデータに対して再度、携帯端末から送信された発行要求情報が、発行処理サーバで受付けられなくなることを防止することができる。その結果、書込処理サーバとの通信が切断された場合であっても、再度行なった発行操作に基づいて確実にデータを書込むことができる。
(4−1) 従来、サーバでカードIDに対応付けてポイントを管理し、各店舗での商品購入代金に応じてポイントを付与するシステムがあった(たとえば、特開2005−433号公報(第0025段落、第0026段落、第0030段落および第0038段落))。しかし、このような技術においては、いずれの店舗での商品購入に対しても一律に特典(たとえば、ポイント)が付与されるため、特典の付与を特定店舗の集客向上に利用することができないといった問題があった。
しかし、本発明は次のような構成を含む。つまり、複数の店舗に設置され、携帯端末に記憶されている取引価値を用いて取引処理を実行する取引装置と、前記取引処理に用いられた前記取引価値の額である取引額を各携帯端末ごとに集計して管理する取引額管理手段を有する取引管理装置とを含む取引システムであって、前記取引額管理手段は、前記各携帯端末の取引額を各店舗ごとに集計して管理し、前記取引管理装置は、前記複数の店舗のうちから、前記取引処理に対する特典付与の対象とする特典付与対象店舗を設定する対象店舗設定手段と、前記取引額管理手段によって管理されている取引額のうち、前記対象店舗設定手段によって設定された前記特典付与対象店舗における取引額に応じて前記特典を付与するための特典付与処理を実行する特典付与手段を含む。このように構成しているため、特定店舗への集客向上に寄与することが可能である。
具体的には、取引システム(たとえば、電子マネーシステム10)は、複数の店舗(たとえば、遊技場30)に設置され、携帯端末(たとえば、携帯電話100)に記憶されている取引価値(たとえば、バリュー)を用いて取引処理(たとえば、プリペイドカード371の発券処理、遊技球の球貸処理)を実行する取引装置(たとえば、券売機300、カードユニット600)と、取引処理に用いられた取引価値の額である取引額を各携帯端末ごとに集計して管理する取引額管理手段(たとえば、データ処理部210、記憶部220、通信部260、発行情報DB222、残高管理AP214)を有する取引管理装置(たとえば、電子マネー管理サーバ200)とを含む。図5の発行情報DB222で説明したように、取引額管理手段によって、各携帯端末の取引額が各店舗ごとに集計して管理される。図28の特典設定画面および図29の特典付与店舗DBで説明したように、取引管理装置によって、複数の店舗のうちから、取引処理に対する特典付与の対象とする特典付与対象店舗が設定される。図27(b)の特典付与AP217のステップS2192〜ステップS2198で説明したように、取引管理装置によって、管理されている取引額のうち、設定された特典付与対象店舗における取引額に応じて特典を付与するための特典付与処理が実行される。これにより、取引管理装置で管理されている特典付与対象店舗における取引額に応じて特典が付与されるので、特典付与対象店舗での取引処理の動機付けを与えることができる。その結果、特定店舗における取引額に応じた特典付与によって、特定店舗への集客向上に寄与することができる。
(4−2) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記取引管理装置は、さらに、複数の店舗が属するグループを設定するグループ設定手段を備え、前記特典付与手段は、前記取引額管理手段によって管理されている取引額のうち、前記グループ設定手段によって設定された前記グループに含まれる前記店舗における取引額の合計額に応じて前記特典付与処理を実行する。具体的には、図28の特典設定画面および図29の特典付与店舗DBで説明したように、取引管理装置によって、複数の店舗が属するグループが設定される。図27(b)の特典付与AP217のステップS2192〜ステップS2198で説明したように、取引管理装置によって、管理されている取引額のうち、設定されたグループに含まれる店舗における取引額の合計額に応じて特典付与処理が実行される。これにより、設定されたグループに含まれる店舗における取引額の合計額に応じて特典が付与されるので、当該グループに含まれる店舗での取引処理の動機付けを与えることができる。その結果、チェーン店などの特定のグループに含まれる店舗における取引額に応じた特典付与によって、特定のグループに含まれる店舗への集客向上に寄与することができる。
(4−3) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記特典付与手段は、前記取引額に応じた額の取引価値である付与取引価値を前記携帯端末に記憶させるための処理を、前記特典付与処理として実行する。具体的には、図27(b)の特典付与AP217のステップS2194で説明したように、取引管理装置によって、取引額に応じた額の取引価値である付与取引価値を携帯端末に記憶させるための処理が、特典付与処理として実行される。このように、取引額に応じて付与された付与取引価値が携帯端末に記憶される。その結果、付与取引価値をユーザに提供するための媒体を別途用意する必要をなくすることができる。
(4−4) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記取引管理装置は、さらに、前記付与取引価値を使用可能とする使用可能店舗を設定する使用可能店舗設定手段を備え、前記特典付与手段は、ユーザによる対価の支払に応じた取引価値とは区別して前記付与取引価値を前記携帯端末に記憶させるための処理とともに、当該付与取引価値に対して前記使用可能店舗設定手段によって設定された前記使用可能店舗を示す使用可能店舗情報を当該付与取引価値に対応させて前記携帯端末に記憶させるための処理を、前記特典付与処理として実行し、前記取引装置は、前記携帯端末から取得した使用可能店舗情報が示す使用可能店舗が、当該取引装置が設置されている店舗であることを条件として、当該使用可能店舗情報に対応させて前記携帯端末に記憶されている付与取引価値を用いて前記取引処理を実行する。具体的には、図28の特典設定画面で説明したように、取引管理装置によって、付与取引価値を使用可能とする使用可能店舗が設定される。図27(b)の特典付与AP217のステップS2194で説明したように、ユーザによる対価の支払に応じた取引価値とは区別して付与取引価値を携帯端末(たとえば、携帯電話100の非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用記憶領域)に記憶させるための処理とともに、当該付与取引価値に対して設定された使用可能店舗を示す使用可能店舗情報を当該付与取引価値に対応させて携帯端末(たとえば、携帯電話100の非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用記憶領域)に記憶させるための処理が、特典付与処理として実行される。図50のステップS341、ステップS356およびステップS362、ならびに、図53のステップS641、ステップS656およびステップS662で説明したように、取引装置によって、携帯端末から取得した使用可能店舗情報が示す使用可能店舗が、当該取引装置が設置されている店舗であることを条件として、当該使用可能店舗情報に対応させて携帯端末に記憶されている付与取引価値が用いられて取引処理が実行される。このように、付与取引価値を使用可能店舗でのみ使用可能とすることができるので、使用可能店舗での取引処理の動機付けを与えることができる。その結果、特定店舗で使用可能な特典付与によって、より確実に特定店舗への集客向上に寄与することができる。
(5−1) 従来、電子マネーをネットチャージするときに、携帯端末から金融機関サーバにアクセスし、モバイルバンキングを利用してチャージ額の決済を実施し、決済が完了すると、金融機関サーバが、金融機関専用ネットワークを介して消込速報を電子マネーサーバに送信し、これにより電子マネーがチャージ可能な状態となる電子マネーシステムがあった(たとえば、特開2006−215747号公報(第0066段落、第0224段落から第0237段落まで))。しかし、特許文献1に開示されている技術によれば、金融機関専用ネットワークに加盟している金融機関しか決済に利用できないため、ユーザの利便性が低く、電子マネーの普及を促進できないといった問題があった。
しかし、本発明は次のような構成を含む。つまり、ユーザが金融機関に開設した口座の残高を使用してチャージ額の決済を行なうことにより、該チャージ額に対応する電子マネーをユーザの携帯端末にチャージするための処理を実行する電子マネーサーバであって、複数の金融機関のそれぞれが、専用ネットワークに加盟している金融機関であり、かつ、前記チャージ額の決済を要求する第1決済要求を前記携帯端末から受付けるとともに、当該第1決済要求に対する決済が完了したことを通知するための第1決済完了通知を前記専用ネットワークを介して前記電子マネーサーバに通知する第1金融機関サーバが設置された金融機関である第1金融機関、および、前記チャージ額の決済を要求する第2決済要求を前記電子マネーサーバから受付けるとともに、当該第2決済要求に対する決済が完了したことを通知するための第2決済完了通知を前記電子マネーサーバに通知する第2金融機関サーバが設置された金融機関である第2金融機関のいずれであるかを設定する金融機関設定手段と、前記複数の金融機関のうちから、前記チャージ額の決済に使用する金融機関の指定を前記携帯端末から受付ける金融機関指定受付手段と、電子マネーのチャージを要求するチャージ要求に応じて、前記金融機関指定受付手段によって指定された金融機関が前記第1金融機関であるか前記第2金融機関であるかを判定する金融機関判定手段と、該金融機関判定手段によって前記第1金融機関であると判定されたことを条件として、前記携帯端末から前記第1金融機関サーバにアクセスして前記第1決済要求を送信するためのアクセス情報を、当該携帯端末に送信するアクセス情報送信手段と、前記金融機関判定手段によって前記第2金融機関であると判定されたことを条件として、前記第2決済要求を前記第2金融機関サーバに送信する決済要求送信手段と、前記第1決済要求に対する前記第1決済完了通知を前記専用ネットワークを介して受信したことを条件として、前記携帯端末に電子マネーをチャージするための第1チャージ処理を実行する一方、前記第2決済要求に対する前記第2決済完了通知を前記第2金融機関サーバから受信したことを条件として、前記携帯端末に電子マネーをチャージするための第2チャージ処理を実行するチャージ処理手段とを備える。このように構成しているため、ユーザの利便性を向上させることができ、電子マネーの普及を促進することが可能である。
具体的には、電子マネーサーバ(たとえば、電子マネー管理サーバ200、決済サーバ280)は、ユーザが金融機関に開設した口座の残高を使用してチャージ額の決済を行なうことにより、該チャージ額に対応する電子マネー(たとえば、バリュー)をユーザの携帯端末(たとえば、携帯電話100)にチャージするための処理を実行する。
第1金融機関サーバ(たとえば、金融機関サーバ500)は、専用ネットワーク(たとえば、金融機関専用ネットワーク920)に加盟している金融機関に設置される。ステップS118aで説明したように、第1金融機関サーバによって、チャージ額の決済を要求する第1決済要求(たとえば、モバイルバンキングへの決済要求)が携帯端末から受付けられる。ステップS269で説明したように、第1金融機関サーバによって、当該第1決済要求に対する決済が完了したことを通知するための第1決済完了通知(たとえば、消込電文、消込速報)が専用ネットワークを介して電子マネーサーバに通知される。ステップS2642で説明したように、第2金融機関サーバ(たとえば、金融機関サーバ500A)によって、チャージ額の決済を要求する第2決済要求(たとえば、決済要求情報)が電子マネーサーバから受付けられる。ステップS2643で説明したように、第2金融機関サーバによって、当該第2決済要求に対する決済が完了したことを通知するための第2決済完了通知(たとえば、決済完了通知)が電子マネーサーバに通知される。
図9の金融機関設定画面で説明したように、電子マネーサーバによって、複数の金融機関のそれぞれが、第1金融機関サーバが設置された金融機関である第1金融機関(たとえば、間接決済対応の金融機関)、および、第2金融機関サーバが設置された金融機関である第2金融機関(たとえば、直接決済対応の金融機関)のいずれであるかが設定される。ステップS223で説明したように、電子マネーサーバによって、複数の金融機関のうちから、チャージ額の決済に使用する金融機関の指定が携帯端末から受付けられる。ステップS241およびステップS264aで説明したように、電子マネーサーバによって、電子マネーのチャージを要求するチャージ要求(たとえば、チャージ要求)に応じて、指定された金融機関が第1金融機関であるか第2金融機関であるかが判定される。ステップS268で説明したように、電子マネーサーバによって、第1金融機関であると判定されたこと(たとえば、ステップS264aでNOの場合)を条件として、携帯端末から第1金融機関サーバにアクセスして第1決済要求を送信するためのアクセス情報(たとえば、引継画面情報)が、当該携帯端末に送信される。ステップS2642で説明したように、電子マネーサーバによって、第2金融機関であると判定されたこと(たとえば、ステップS264aでYESの場合)を条件として、第2決済要求が第2金融機関サーバに送信される。ステップS270、ステップS2709およびステップS271からステップS279までで説明したように、電子マネーサーバによって、第1決済要求に対する第1決済完了通知が専用ネットワークを介して受信されたこと(たとえば、ステップS269でYESの場合)を条件として、携帯端末に電子マネーをチャージするための第1チャージ処理が実行される。一方、ステップS2651からステップS2658までで説明したように、電子マネーサーバによって、第2決済要求に対する第2決済完了通知が第2金融機関サーバから受信されたことを条件として、携帯端末に電子マネーをチャージするための第2チャージ処理が実行される。
このように、専用ネットワークに加盟している金融機関だけでなく専用ネットワークに加盟していない金融機関も電子マネーのチャージ額の決済に使用することができるようになる。その結果、ユーザの利便性を向上させることができ、電子マネーの普及を促進することができる。
なお、本実施の形態においては、第1決済要求は、携帯端末から直接、第1金融機関サーバに送信されることとしたが、これに限定されず、中継サーバで中継されるものであってもよい。また、中継サーバで、第1決済要求の形式が変更されるものであってもよい。また、本実施の形態においては、第1チャージ処理および第2チャージ処理は異なる処理としたが、これに限定されず、同じ処理であってもよい。
(5−2) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記金融機関指定受付手段によって指定された金融機関が前記第2金融機関である場合には、ユーザが当該金融機関に開設した口座を特定可能な口座特定情報を前記携帯端末から受付ける口座特定情報受付手段と、各携帯端末について、前記金融機関指定受付手段によって指定された前記金融機関を特定可能な情報を記憶するとともに、前記口座特定情報受付手段によって受付けられた前記口座特定情報を記憶する金融機関記憶手段とをさらに備え、前記アクセス情報送信手段は、前記金融機関記憶手段の記憶情報から特定される金融機関の第1金融機関サーバを前記第1決済要求の通信先として示す情報を前記アクセス情報として前記携帯端末に送信し、前記決済要求送信手段は、前記金融機関記憶手段に記憶されている前記口座特定情報から特定される口座からの決済を要求する前記第2決済要求を送信する。具体的には、ステップS223で説明したように、電子マネーサーバによって、指定された金融機関が第2金融機関である場合には、ユーザが当該金融機関に開設した口座を特定可能な口座特定情報(たとえば,口座番号)が携帯端末から受付けられる。図4の利用者情報DB221およびステップS224で説明したように、電子マネーサーバによって、各携帯端末について、指定された金融機関を特定可能な情報(たとえば、金融機関指定情報)が記憶されるとともに、受付けられた口座特定情報が記憶される。ステップS268で説明したように、電子マネーサーバによって、記憶情報から特定される金融機関の第1金融機関サーバを第1決済要求の通信先として示す情報(たとえば、金融機関サーバ500のインターネットバンキングシステムにアクセス可能となるURL)がアクセス情報として携帯端末に送信される。ステップS2642で説明したように、電子マネーサーバによって、記憶されている口座特定情報から特定される口座からの決済を要求する第2決済要求が送信される。このように、指定された金融機関が第1金融機関であっても第2金融機関であっても、予め記憶された金融機関を特定可能な情報や口座特定情報が用いられて決済が行なわれる。その結果、電子マネーのチャージ額の決済ごとに、決済のための情報を入力する手間を省くことができるので、ユーザの利便性を向上させることができる。
(5−3) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記チャージ処理手段は、前記第1チャージ処理として、電子マネーのチャージが可能になった旨を通知する電子メールである通知メールを前記携帯端末に送信し、前記第2チャージ処理として、前記携帯端末に電子マネーをチャージする処理を実行する。具体的には、ステップS2709で説明したように、電子マネーサーバによって、第1チャージ処理として、電子マネーのチャージが可能になった旨を通知する電子メールである通知メール(たとえば、引継ぎ情報を付した電子メール)が携帯端末に送信される。ステップS2656で説明したように、電子マネーサーバによって、第2チャージ処理として、携帯端末に電子マネーをチャージする処理が実行される(たとえば、ステップS2656でバリュー発行情報が携帯電話100に送信されることによって、即、ステップS1481〜ステップS1484でリモート発行サーバ400から携帯電話100にバリューが書込まれる)。このように、第1金融機関を指定したユーザに対しては、チャージが可能となったことを確実に認識させることができるとともに、第2金融機関を指定したユーザについては、迅速に携帯端末に電子マネーをチャージできる。
(5−4) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記チャージ処理手段は、前記第1チャージ処理として、電子マネーのチャージのために操作されるリンク情報を含む前記通知メールを送信し、該リンク情報が操作されたことに基づいて、前記携帯端末に電子マネーをチャージする処理を実行する。具体的には、ステップS2709で説明したように、電子マネーサーバによって、第1チャージ処理として、電子マネーのチャージのために操作されるリンク情報(たとえば、引継ぎ情報)を含む通知メールが送信される。ステップS271からステップS279までで説明したように、電子マネーサーバによって、該リンク情報が操作されたこと(たとえば、ステップS191でYESであること)に基づいて、携帯端末に電子マネーをチャージする処理が実行される。このように、第1金融機関を指定したユーザは通知メールに含まれるリンク情報を操作するだけで、携帯端末に電子マネーがチャージされる。その結果、第1金融機関を指定したユーザの電子マネーのチャージのための操作負担を軽減することができる。
(5−5) また、本発明は、次のような構成を含むようにしてもよい。つまり、前記第1決済完了通知を受信したが前記携帯端末に未だチャージされていない電子マネーである未チャージ電子マネーがあるか否かを判定する未チャージ電子マネー判定手段をさらに備え、前記アクセス情報送信手段は、該未チャージ電子マネー判定手段によって未チャージ電子マネーがあると判定されたことを条件として、前記アクセス情報を前記携帯端末に送信しない。具体的には、ステップS244で説明したように、電子マネーサーバによって、第1決済完了通知を受信したが携帯端末に未だチャージされていない電子マネーである未チャージ電子マネー(たとえば、未チャージバリュー)があるか否かが判定される。未チャージ電子マネーがあると判定されたこと(たとえば、ステップS244でYESの場合)を条件として、アクセス情報が携帯端末に送信されない(たとえば、ステップS270に進んで、ステップS2709で引継ぎ情報を付した電子メールが携帯電話100に送信されるのではなく、ステップS245からステップS277に進み、バリュー発行情報が携帯電話100に送信される)。このように、未チャージ電子マネーがある場合には、アクセス情報が携帯端末に送信されないので、未チャージ電子マネーがあるうちは、新たに、電子マネーのチャージ額を決済できないようにすることができる。その結果、ユーザによる過誤の電子マネーのチャージを防止できる。
[第2の実施の形態]
第1の実施の形態においては、電子マネー管理サーバ200およびリモート発行サーバ400が、別々の業者に備えられる場合について説明した。第2の実施の形態においては、電子マネー管理サーバ200およびリモート発行サーバ400が、同じ業者に備えられる場合について説明する。
なお、第2の実施の形態においては、リモート発行サーバ400が電子マネー管理サーバ200に含まれる、つまり、電子マネー管理サーバ200およびリモート発行サーバ400が1台のコンピュータで構成される場合について説明する(この場合には、該1台のコンピュータが、本発明の発行書込処理サーバを構成する)が、これに限定されず、電子マネー管理サーバ200の利用者情報DB221および発行情報DB222にリモート発行サーバ400が直接アクセスできるなど、電子マネー管理サーバ200およびリモート発行サーバ400が電子マネーに関するDBを共有できるのであれば、電子マネー管理サーバ200およびリモート発行サーバ400は、別々のコンピュータで構成されるようにしてもよい。
本第2の実施の形態のように、電子マネー管理サーバ200とリモート発行サーバ400とを一体に構成した場合には、第1の実施の形態の図12で示した初回起動処理、図18で示したバリュー発行時処理、図22で示したバリュー預け処理および図23で示したバリュー返却処理において、非接触型ICチップ190の記憶部192に電子マネー遊技使用サービス用の記憶領域を構築したり、バリューを書込んだり、電子マネー遊技使用サービス用の記憶領域を削除したりするために、携帯電話100とリモート発行サーバ400との間で行なわれていた処理が、すべて電子マネー管理サーバ200との間で行なわれることになる。以下においては、本発明に特に関連するバリュー発行時の処理と、携帯電話100の記憶部120にて管理される処理状況の更新に失敗した場合のエラー対応処理とを説明する。
図59は、第2の実施の形態における携帯電話100により実行される電子マネーアプリ111のサブルーチンであるバリュー発行時処理の流れを示すフローチャートである。
図59を参照して、ステップS152で、データ処理部110は、バリュー発行要求情報を、電子マネー管理サーバ200に送信する。ここで、バリュー発行要求情報は、図18と異なり、バリューのチャージ(発行)を要求するための情報であるとともに非接触型ICチップ190の記憶部192の電子マネー遊技使用サービス用の記憶領域にバリューを書込むための書込処理を開始させるための情報であって会員IDおよび携帯端末情報を含む情報である。つまり、図59のバリュー発行要求情報は、図18のバリュー発行要求情報(バリューの発行を要求するための発行要求情報)と書込処理開始要求情報(バリューの書込みを要求する書込要求情報)とを含む情報である。
図60は、第2の実施の形態における電子マネー管理サーバ200により実行されるバリュー発行時アプリケーションプログラムの処理の流れを示すフローチャートである。
図60を参照して、まず、ステップS271で、データ処理部210は、携帯電話100からバリュー発行要求情報を受信したことによって、バリュー発行要求があったか否かを判断する。バリュー発行要求がないと判断した場合(ステップS271でNOの場合)、データ処理部210は、実行する処理をステップS271に戻す。
一方、バリュー発行要求があったと判断した場合(ステップS271でYESの場合)、ステップS272で、データ処理部210は、ステップS271で受信したバリュー発行要求情報に含まれる会員IDおよび携帯端末情報が利用者情報DB211に登録された利用可能なものであるか否かを判断する。利用可能なものでないと判断した場合(ステップS272でNOの場合)、ステップS273で、データ処理部210は、使用不可画面を携帯電話100に送信する。使用不可画面は、図39(c)で説明した画面と同様の画面である。
一方、利用可能なものであると判断した場合(ステップS272でYESの場合)、ステップS274で、データ処理部210は、会員IDおよび携帯端末情報に対応する未チャージバリューが発行情報DB222に記憶されているか否かを判断する。未チャージバリューがないと判断した場合(ステップS274でNOの場合)、ステップS275で、データ処理部210は、未チャージバリュー無画面を携帯電話100に送信する。未チャージバリュー無画面は、図44(c)で説明したので重複する説明は繰返さない。
未チャージバリューがあると判断した場合(ステップS274でYESの場合)、チャージ要求時に未チャージバリューがあると判断した場合(ステップS274でYESの場合)、および、残高移行依頼時に未チャージバリューがあると判断した場合(ステップS2064でYESの場合)、ステップS2793で、データ処理部210は、書込処理を実行する。
具体的には、データ処理部210は、電子マネーアプリ111を介さずに、バリュー発行要求に含まれる携帯端末情報で示される携帯電話100の非接触型ICチップ190と直接やり取りして、非接触型ICチップ190の記憶部192に、発行情報DB222に記憶された未チャージバリューを書込む。
つまり、電子マネー管理サーバ200は、非接触型ICチップ190の制御部191に対して未チャージバリュー(発行バリュー)の書込みを指示し(書込指示情報を送信し)、これに応じて、制御部191が非接触型ICチップ190の記憶部192にバリューの書込みを行なう(つまり、制御部191がデータ書込実行手段を構成する)。この場合、記憶部192の電子マネー遊技使用サービス用の記憶領域に既にバリューが記憶されているときには、既に記憶されているバリューに発行バリューを加算した額のバリューを書込む処理が行なわれるが、かかる処理も発行バリューの書込みに該当する。
つまり、第2の実施の形態においては、図59のステップS152でバリューの発行を要求するバリュー発行要求情報とバリューの書込みを要求するバリュー書込要求情報とを兼ねるバリュー発行要求情報が携帯電話100から電子マネー管理サーバ200に対して送信されてくるため、電子マネー管理サーバ200は、図60のステップS2793で携帯電話100に対してバリューを発行する(送信する)処理を行なうとともに、当該発行したバリューを非接触型ICチップ190の記憶部192に書込むための書込指示情報を送信する処理とを併せて行なうものである。
以上のように、本実施の形態においては、電子マネーアプリ111を介することなく、電子マネー管理サーバ200の指示に応じて非接触型ICチップ190の制御部191が発行バリューの書込みを行なうように構成したが、これに限定されず、電子マネー管理サーバ200から書込指示情報を受信したことに応じて、電子マネーアプリ111が制御部191に発行バリューの書込みを指示するようにしてもよい。
そして、ステップS2794で、データ処理部210は、バリューの書込みが終了したか否かを判断する。終了していないと判断した場合(ステップS2794においてNOの場合)、データ処理部210は、ステップS2794の処理を繰返す。一方、終了したと判断した場合(ステップS2794においてYESの場合)、ステップS2795で、データ処理部210は、書込終了情報を携帯電話100に送信する。
また、ステップS2796で、データ処理部210は、書込みが終了したバリューと対応付けて図5に示す発行情報DB222に記憶されている当該バリューの処理状況(書込状況)を、書込終了済に更新する。その後、データ処理部210は、実行する処理をステップS271の処理に戻す。
図59に戻って、データ処理部110は、ステップS157bで、電子マネー管理サーバ200から書込終了情報を受信したことによって、書込処理が終了したか否かを判断する。書込処理が終了したと判断した場合(ステップS157bでYESの場合)、ステップS157aで、データ処理部110は、記憶部120で管理している処理状況を、書込済に更新する。ステップS157a以降の処理は、図18で説明したので重複する説明は繰返さない。
図61は、第2の実施の形態における携帯電話100により実行されるバリュー購入時処理のサブルーチンである直接決済購入処理の流れを示すフローチャートである。図61を参照して、図41(c)の画面でユーザにより合計金額が確認された旨を示す確認通知が、電子マネー管理サーバ200に送信される。
図16に戻って、電子マネー管理サーバ200においては、ステップS246で読出した金融機関指定情報で示される金融機関が直接決済に対応する金融機関であると判断した場合(ステップS264aでYESの場合)、ステップS264bで、データ処理部210は、直接決済発行処理を実行する。
図62は、第2の実施の形態における電子マネー管理サーバ200により実行されるバリュー購入時アプリケーションプログラム212のサブルーチンである直接決済発行処理の流れを示すフローチャートである。図62を参照して、まず、ステップS2641で、データ処理部210は、携帯電話100から合計金額の確認通知が受信されたか否かを判断する。確認通知が受信されていないと判断した場合(ステップS2641でNOの場合)、データ処理部210は、ステップS2641の処理を繰返す。
一方、確認通知が受信されたと判断した場合(ステップS2641でYESの場合)、ステップS2642で、データ処理部210は、ステップS246で読出した金融機関指定情報で示される金融機関の金融機関サーバ500Aに、購入バリューの決済を要求するための決済要求情報を送信する。決済要求情報には、ステップS262で算出した合計金額、ならびに、利用者情報DB221に登録されている口座番号およびパスワードが含まれる。
ステップS246で読出した金融機関指定情報で示される金融機関の金融機関サーバ500Aは、電子マネー管理サーバ200から受信した決済要求情報に含まれるパスワードが正しいか否かを判断する。パスワードが正しければ、金融機関サーバ500Aは、当該決済要求情報に含まれる口座番号で示される口座から、当該決済要求情報に含まれる合計金額を決済する。決済の完了後、金融機関サーバ500Aは、決済が完了したことを通知するための決済完了通知を電子マネー管理サーバ200に送信する。
電子マネー管理サーバ200においては、ステップS2643で、データ処理部210は、金融機関サーバ500Aから決済完了通知を受信したか否かを判断する。決済完了通知を受信していないと判断した場合(ステップS2643でNOの場合)、データ処理部210は、ステップS2643の処理を繰返す。
一方、決済完了通知を受信したと判断した場合(ステップS2643でYESの場合)、ステップS2651で、データ処理部210は、ステップS2641で確認通知を送信してきた携帯電話100でのバリューの初回購入であるか否かを判断する。このステップS2651からステップ2655までの処理は、前述の図17で説明したステップS2702からステップS2707までの処理と同様であるので、重複する説明は繰返さない。
ステップS2655の後、ステップS2646で、データ処理部210は、書込処理を実行する。ステップS2646からステップS2649までの処理は、図60のステップS2793からステップS2796までの処理と同様であるので、重複する説明は繰返さない。ステップS2649の後、データ処理部210は、実行する処理をこの処理の呼出元の処理に戻す。
図61に戻って、データ処理部110は、ステップS1484aで、電子マネー管理サーバ200から書込終了情報を受信したことによって、書込処理が終了したか否かを判断する。ステップS1484aからステップS1488までの処理は、図59のステップS157bからステップS159bまでの処理と同様であるので、重複する説明は繰返さない。
図63は、第2の実施の形態における携帯電話100により実行される電子マネーアプリ111のサブルーチンである特典発行時処理の流れを示すフローチャートである。図63を参照して、まず、ステップS1902で、データ処理部110は、特典バリューの発行を要求するための情報であって会員IDおよび携帯端末情報を含む特典発行要求情報を、電子マネー管理サーバ200に送信する。
図64は、第2の実施の形態における電子マネー管理サーバ200により実行される特典付与アプリケーションプログラム217の処理の流れを示すフローチャートである。図64を参照して、ステップS2191からステップS2193までの処理は、図27(b)で説明した処理と同様であるので重複する説明は繰返さない。
次に、ステップS2291で、データ処理部は、ステップS2193で算出された付与特典額とその付与特典額の使用可能店舗を示す店舗識別情報との書込処理を実行する。具体的には、前述した図60のステップS2793で説明した方法と同様の方法で非接触型ICチップ190の記憶部192に、付与特典額と店舗識別情報とを書込む。
ステップS2292からステップS2293までの処理は、図60のステップS2794からステップS2795までの処理と同様であるので重複する説明は繰返さない。ステップS2196からステップS2198までの処理は、図27(b)の処理と同様であるので重複する説明は繰返さない。
図63に戻って、ステップS1914aからステップS1918までの処理は、前述した図26の処理と同様であるので重複する説明は繰返さない。
図65は、第2の実施の形態における電子マネー管理サーバ200によって実行されるエラー対応処理の流れを示すフローチャートである。図65を参照して、第1の実施の形態においては、処理状況の不整合のエラーに対応する処理をオペレータが行なうようにした。第2の実施の形態のおいては、処理状況の不整合のエラーに対応する処理を、エラー対応処理として電子マネー管理サーバ200が行なう場合について説明する。なお、エラー対応処理は、電子マネー遊技使用サービスの提供機関のサーバで実行されるのであれば、電子マネー管理サーバ200で実行されることに限定されない。
図65を参照して、まず、電子マネー遊技使用サービスの提供業者のオペレータは、電話や電子メール等で、ユーザからのエラー問合せを受信した場合、ユーザに携帯電話100の電子メールアドレスを問合せ、ユーザの携帯電話100の電子メールアドレスを取得する。
次に、オペレータは、取得したユーザの携帯電話100の電子メールアドレス宛に、エラー対応開始メールを送信するように、電子マネー管理サーバ200を操作する。
この操作に応じて、電子マネー管理サーバ200のデータ処理部210は、ステップS2911で、ユーザの携帯電話100の電子メールアドレス宛に、エラー対応開始メールを送信する。エラー対応開始メールには、エラーについて説明するエラー説明ページのURLが添付される。
エラー対応開始メールに含まれるエラー説明ページへのリンクが操作されると、データ処理部110は、エラー説明ページへのリンク先のURLで示される電子マネー管理サーバ200に、エラー説明画面を取得するためのエラー説明画面取得要求を送信する。
電子マネー管理サーバ200のデータ処理部210は、ステップS2912で、携帯電話100からエラー説明画面取得要求があったか否かを判断する。エラー説明画面取得要求を受信していないと判断した場合(ステップS2912においてNOの場合)、データ処理部210は、ステップS2912の処理を繰返す。一方、エラー説明画面取得要求を受信したと判断した場合(ステップS2912においてYESの場合)、ステップS2913で、データ処理部210は、エラー説明画面をエラー説明画面取得要求元の携帯電話100に送信する。
携帯電話100のデータ処理部100は、電子マネー管理サーバ200からエラー説明画面を取得し、表示部140に表示する。エラー説明画面には、エラーについての説明が記載されるとともに、電子マネーアプリ111を起動させるために操作されるリンク情報が含まれており、当該リンク情報が選択操作されることにより、データ処理部110は、電子マネーアプリ111を起動させる。そして、図11で前述したステップS1101の処理が実行されることにより、バリュー残高などの非接触型ICチップ190の記憶部192の記憶内容および記憶部120で管理されている処理状況が電子マネー管理サーバ200に送信される。
電子マネー管理サーバ200のデータ処理部210は、ステップS2914で、ユーザの携帯電話100から非接触型ICチップ190の記憶内容および処理状況を受信したか否かを判断する。非接触型ICチップ190の記憶内容および処理状況を受信していないと判断した場合(ステップS2914においてNOの場合)、データ処理部210は、ステップS2914の処理を繰返す。
一方、非接触型ICチップ190の記憶内容を受信したと判断した場合(ステップS2914においてYESの場合)、ステップS2916で、データ処理部210は、ステップS2914で受信したユーザの携帯電話100の記憶部120で管理されていた処理状況および非接触型ICチップ190の記憶内容であるバリュー残高と、発行情報DB222に記憶された当該携帯電話100に書込んだバリューの処理状況および図5の発行情報DB222に記憶されたバリュー残高とを比較する。そして、処理状況が不一致でないと判断した場合(ステップS2917aにおいてNOの場合)、処理状況の不一致に対する処理を行なう必要がないので、データ処理部210は、実行する処理をステップS2911の処理に戻す。
処理状況が不一致であり(ステップS2917aにおいてYESであり)、かつ、バリュー残高が一致しないと判断した場合(ステップS2917bにおいてNOの場合)、バリューの書込みが行なわれていない可能性があり、オペレータによるエラーに対する対応が必要であるために、ステップS2917cで、データ処理部210は、処理状況およびバリュー残高が携帯電話100と電子マネー管理サーバ200とで不一致である旨を表示部240に表示させることによってオペレータに報知する。
そして、ステップS2917dで、データ処理部210は、オペレータによって確認操作がデータ入力部230から入力されたか否かを判断する。確認操作がないと判断した場合(ステップS2917dにおいてNOの場合)、データ処理部210は、ステップS2917dの処理を繰返す。一方、確認操作があったと判断した場合(ステップS2917dにおいてYESの場合)、データ処理部210は、実行する処理をステップS2911の処理に戻す。
処理状況が不一致であり(ステップS2917aにおいてYESであり)、かつ、バリュー残高が一致すると判断した場合(ステップS2917bにおいてYESの場合)、バリューは書込まれたが処理状況の書込済への更新には失敗したこととなるので、処理状況を強制的に更新させるために、ステップS2918で、データ処理部210は、ユーザの携帯電話100に、エラー対応完了メールを送信する。このエラー対応完了メールには、電子マネーアプリ111を起動させ処理状況をクリアさせるためのリンクが添付される。ステップS2918の後、データ処理部210は、実行する処理をステップS2911の処理に戻す。
なお、ここでは、バリューの処理状況およびバリュー残高を比較するようにしたが、これに限定されず、バリュー残高は比較せずにバリューの処理状況のみを比較するようにしてもよい。
そして、かかるエラー対応完了メールを受信した携帯電話100において、当該エラー対応完了メールに添付されたリンク情報が選択操作されると、電子マネーアプリ111が起動され、図11に示す処理のステップS1110においてYESの判断がなされ、ステップS1111以降の処理が実行され記憶部120の処理状況がクリアされる。ステップS111からの処理については前述した図11で説明したので重複する説明は繰返さない。
このように、データ処理部110は、本実施の形態における更新指示情報である前記エラー対応完了メールを受信し、当該エラー対応完了メールに添付されたリンク情報が操作されたことを条件として、さらには当該リンク情報の操作が初回であることを条件として、記憶部120にて管理している処理状況を強制的に更新する処理状況強制更新処理を実行する。また、図11に示して説明した通り、この処理状況強制更新処理(ステップS1113)は、更新指示情報としてのエラー対応完了メールに添付されたリンク情報が操作されたことを条件として実施され、電子マネーアプリ111の初期画面等からは実行できないため、ユーザの過誤等により処理状況の更新が実施されるおそれがない。さらに、この処理状況強制更新処理は、リンク操作が初回であることを条件として実行されるため、携帯電話100に保存されている電子メールのリンク情報をユーザの過誤等により複数回操作された場合にも、2回目以降の操作時には処理状況が更新されてしまうおそれがない。
また、電子マネー管理サーバ200では、ステップS2796で説明したように、書込処理の終了を条件として、処理状況が書込終了済に更新され、携帯電話100では、ステップS157aで説明したように、書込処理の実行を条件として、処理状況が書込済に更新される。しかし、バリューが書込まれたときに携帯電話100側で処理状況の書込済への更新に失敗した場合であっても、ステップS2918およびステップS1113で説明したように、電子マネー管理サーバ200からの指示で強制的に処理状況が更新される。その結果、バリューの書込みに関し携帯電話100と電子マネー管理サーバ200との処理状況の不一致を解消し、その後の処理の不都合を解消することができる。
また、ステップS2914からステップS2918までで説明したように、電子マネー管理サーバ200によって携帯電話100から取得された処理状況に基づいた処理が実行される。このため、処理状況が電子マネー管理サーバ200で確認された上で必要な処理が実行されるようにすることができる。
また、ステップS2916からステップS2918までで説明したように、電子マネー管理サーバ200によって、携帯電話100と電子マネー管理サーバ200との処理状況が一致するか否かが判断され、一致しないと判断されたことを条件として、携帯電話100の処理状況をクリアさせるためのエラー対応完了メールが送信される。このため、オペレータによる確認作業等の手間を省くことができる。
また、ステップS2918、ステップS1110およびステップS1113で説明したように、電子マネー管理サーバ200によって、エラー対応完了メールが送信され、エラー対応完了メールに添付されたリンク情報が操作されることを条件として、処理状況がクリアされるので、電子マネー管理サーバ200側での処理が終了し、処理状況の更新が可能となったことをユーザに確実に認識させることができるとともに、処理状況の更新のためのユーザの操作負担も軽減させることができる。また、電子マネー管理サーバ200からエラー対応完了メールが送信されることなく携帯電話100での処理状況の更新が行なわれないようにすることができるので、ユーザの誤操作や悪用によって処理状況が強制的に更新されないようにすることができる。
また、ステップS1111およびステップS1113で説明したように、携帯電話100によって、リンク情報の操作が初回か否かが判定され、初回であると判定されたことをさらに条件として、処理状況がクリアされるので、ユーザの過誤等によりリンク情報が複数回操作されても、その度に処理状況が更新されないようにすることができる。
次に前述した実施の形態の変形例を挙げる。
(1) 前述した実施の形態においては、ステップS269で決済サーバ280から消込速報を受信したことを条件として、電子マネー管理サーバ200は、バリューの購入に対する決済が終了したと判断して、ステップS277でバリュー発行情報を携帯電話100に送信するようにした。すなわち、決済用処理として、金融機関に対するバリューの購入に対する対価の決済を行なうための処理を例に説明した。
しかし、決済用処理としては、これに限定されるものではない。たとえば、決済用処理としては、クレジットカードの提供機関に対するバリューの購入に対する対価の決済のために与信の可否の判断において与信可との結果を得る処理であってもよい。具体的には、クレジットカードによる与信でバリューを購入できるようにして、実際の決済は済んでいなくても、バリュー発行情報を携帯電話100に送信するようにしてもよい。バリュー購入時処理において、電子マネー管理サーバ200または携帯電話100にクレジットカードの提供機関、カード番号等を記憶させておき、電子マネー管理サーバ200がクレジットカードの提供機関、カード番号等を読出してまたは携帯電話100から取得して、当該提供機関に与信の可否を問合せ、与信可の返信があれば図17に示すバリュー対価決済後処理を行ない、発行情報DB222への未チャージバリュー等の登録処理を行なうようにすればよい。
(2) 前述した実施の形態においては、所定時間ごとに券売機300から店舗サーバ800を介して電子マネー管理サーバ200に取引情報が送信されるようにした。このため、電子マネー管理サーバ200で管理されている携帯電話100のバリュー残高は常に正確である訳ではない。したがって、バリューが携帯電話100から電子マネー管理サーバ200に預けられるときには、ステップS1602で携帯電話100から電子マネー管理サーバ200にバリュー残高が送信されるようにした。そして、電子マネー管理サーバ200は、ステップS2163で携帯電話100から送信されたバリュー残高を預かり残高として記憶するようにした。
しかし、これに限定されず、リアルタイムで券売機300から電子マネー管理サーバ200に取引情報が送信されるようにして、バリューが携帯電話100から電子マネー管理サーバ200に預けられるときに、電子マネー管理サーバ200で管理されている携帯電話100のバリュー残高を預かり残高として記憶するようにしてもよい。この場合には、ステップS1702で送信する残高返却依頼情報にはバリュー残高を含めないようにしてもよい。また、同様に、ステップS251においては、ステップS133で送信するチャージ要求情報に含まれるバリュー残高に基づき携帯上保持限度額を判定しているが、リアルタイムで電子マネー管理サーバ200に取引情報が送信される場合、ステップS133においてバリュー残高を含まないチャージ要求情報に送信するようにしてもよい。
(3) 前述した実施の形態においては、ステップS1702で預かり番号を含まない残高返却依頼情報を送信するようにして、ステップS1706で預かり番号を送信するようにした。しかし、これに限定されず、ステップS1702で残高返却依頼情報を送信しないようにして、ステップS1706で預かり番号を含む残高依頼情報を送信するようにしてもよい。
(4) 前述した実施の形態においては、バリューが携帯電話100から電子マネー管理サーバ200に預けられるときに未チャージバリューがある場合(ステップS2064においてにYESの場合)は、一旦、未チャージバリューが携帯電話100にチャージされてから、携帯電話100のバリュー残高が預かり残高として記憶されるようにした。
しかし、これに限定されず、バリューが携帯電話100から電子マネー管理サーバ200に預けられるときに、電子マネー管理サーバ200が、携帯電話100から受取ったバリュー残高と未チャージバリューの額とを加算して、加算した額を預かり残高として記憶するようにしてもよい。
(5) 前述した実施の形態においては、ステップS2177でバリュー残高と預かり残高を加算した額が携帯上保持限度額より多いと判断された場合に、ステップS2178で携帯上保持限度額返却不可画面を送信して、預かり残高を返却しないようにした。しかし、これに限定されず、預かり残高のうち、バリュー残高と加算した額が携帯上保持限度額を超えない分を返却して、残りの分を未チャージバリューとするようにしてもよい。
(6) 本実施の形態においては、図8に示す初期登録時AP211のステップS236において領域確保情報が携帯電話100に送信されることで、携帯電話100の記憶部192に電子マネー遊技使用サービス用の記憶領域が構築(確保)されることから、当該領域確保情報の送信に先立ってステップS235において未チャージ削除カウンタを1加算することにより、携帯電話100の記憶部192に電子マネー遊技使用サービス用の記憶領域が構築された構築回数を加算・管理し、ステップS216で未チャージ削除カウンタの値が3に達しているか否かを判定し、達していれば領域構築情報の送信を禁止するようにしているが、これに限らず、たとえばステップS216での判定対象とする回数を1回とするような場合には、未チャージ削除カウンタにおいて回数を計数するのではなく、ステップS236で領域構築情報が送信されることに関連して領域構築済を示すフラグを立てて、図17に示すバリュー対価決済後処理のステップS2703において当該フラグを削除することで、領域構築対価の決済が終了しているか否かを管理し、ステップS216において当該フラグが立っているか否かを判定し、フラグが立っていれば領域構築対価の決済が未終了であるとして領域構築情報の送信を禁止するようにしてもよい。
また、本実施の形態においては、すべての携帯電話100について未チャージ削除カウンタを管理しているが、領域構築対価の決済用処理が未終了の携帯電話100の携帯端末情報のみを登録するデータベースを別途設け、当該データベースにおいて未チャージ削除カウンタを管理してもよい。
(7) 前述した実施の形態においては、サービス提供用サーバとして電子マネー管理サーバ200、および決済サーバ280を例にして説明した。しかし、サーバに限らず、ネットワークを介して複数のコンピュータを結ぶことで仮想的に構築されるコンピュータであるグリッドコンピューティングシステムであってもよい。
(8) 前述した第1の実施の形態においては、電子マネー管理サーバ200のデータ処理部によって、図16のステップS268で、モバイルバンキングへの引継をユーザに確認するためのモバイルバンキング遷移確認画面を表示させるための引継画面情報が携帯電話100に送信され、携帯電話100のデータ処理部110によって、図10(b)のステップS117で、電子マネー管理サーバ200から引継画面情報が受信されたことに応じて、ステップS118,S118aでモバイルバンキングに遷移しモバイルバンキング処理が行なわれ、決済が行なわれるようにした。つまり、携帯電話100と電子マネー管理サーバ200との接続が一旦分断され、決済のために携帯電話100から金融機関サーバ500にアクセスし、その後、再度、電子マネー管理サーバ200にアクセスして電子マネー情報の書込みを行なうようにした。
しかし、これに限定されず、電子マネー管理サーバ200によって、ステップS268で引継画面情報が送信されることに替えて、携帯電話100から電子マネー管理サーバ200を介して、金融機関サーバで決済が行なえるようにしてもよい。このようにすることで、携帯電話100と金融機関サーバとが決済のやり取りをする場合に分断してしまう携帯電話100と電子マネー管理サーバ200との接続を保ったまま、決済のやり取りを行なうことができるようになり、その後の電子マネー情報の携帯電話100への書込みまでの処理を一連の処理として行なうことができる。
(9) 前述した実施の形態においては、電子マネーシステム10は、遊技場30に設置される装置、携帯電話100、電子マネー管理サーバ200、決済サーバ280、リモート発行サーバ400、および、金融機関サーバ500,500Aで構成されるようにした。
しかし、これに限定されず、電子マネー管理サーバ200に、決済サーバ280、リモート発行サーバ400、および、金融機関サーバ500,500Aの全部または一部の機能が含まれるようにして、電子マネーシステム10が、遊技場30に設置される装置、携帯電話100、および、電子マネー管理サーバ200で構成されるようにしてもよい。
(10) 前述した実施の形態では、電子マネーシステム10の発明として説明した。しかし、これに限定されず、携帯電話100、電子マネー管理サーバ200、決済サーバ280、券売機300、カードユニット600、および、店舗サーバ800の装置の発明として捉えることができる。
また、電子マネーアプリ111、初期登録時AP211、バリュー購入時AP212、バリュー発行時AP213、残高管理AP214、バリュー預かりAP215、バリュー返却AP216、特典付与AP217、および、特典通知APのプログラムの発明として捉えることができる。
さらに、携帯電話100、電子マネー管理サーバ200、決済サーバ280、券売機300、カードユニット600、および、店舗サーバ800の装置でそれぞれ行なわれる処理を処理方法の発明として捉えることができる。
(11) 前述した実施の形態では、電子マネー遊技使用サービスの提供業者に対価を支払うためにユーザが利用する金融機関のサーバとして、金融機関ごとにそれぞれ金融機関サーバ500,500Aが設けられている例について説明した。しかし、これに限らず、ユーザが利用する金融機関のサーバとしては、複数の金融機関からなるグループ用に設けられた共通の金融機関サーバであってよい。この場合、同じグループに属する金融機関を利用する場合には、異なる金融機関を利用する場合であっても、当該グループ用に設けられた共通の金融機関サーバと通信し対価の支払いが行なわれる。また、対価を支払うために利用するためのサーバとしては、金融機関のサーバに限らず、ユーザが登録した金融機関サーバと通信し対価の支払いを代行する代行業者のサーバであってもよい。つまり、これらの場合にも、金融機関のサーバに含まれる。
(12) 前述した第1の実施の形態においては、携帯電話100のデータ処理部110によって図10のステップS112で金融機関指定情報が送信されたことに応じて、電子マネー管理サーバ200のデータ処理部210によって、図8のステップS224で、金融機関指定情報が利用者情報DB221に登録されるようにした。
しかし、金融機関指定情報は新規会員登録時に登録されることに限定されず、他のタイミングで登録されるようにしてもよい。たとえば、バリューの初回購入時に登録されるようにしてもよいし、電子マネーアプリのメインメニューに金融機関を登録するためのメニューを設けて、遊技者の携帯電話100からの金融機関指定情報の登録の要求があったときに登録されるようにしてもよい。
なお、金融機関変更処理が行なわれるタイミングについても同様である。前述した実施の形態においては、バリュー購入時処理において金融機関変更処理が行なわれる、すなわちバリュー購入時に金融機関を変更できる例について説明したが、これに限らず、金融機関変更処理が行なわれるタイミングは他のタイミングで変更されるようにしてもよいし、電子マネーアプリのメインメニューに金融機関を変更するためのメニューを設けて、遊技者の携帯電話100からの金融機関指定情報の変更の要求があったときに変更されるようにしてもよい。
(13) 前述した実施の形態においては、プリペイドカード371に残額を示す情報が記録されるようにした。しかし、これに限定されず、プリペイドカード371にはカードIDのみ記録しておき、店舗サーバ800などのサーバで、カードIDに対応させて残額を示す情報を管理しておき、プリペイドカード371を発行したり、プリペイドカード371に入金したり、プリペイドカード371から残額を減算したりする場合に、店舗サーバ800とやり取りするようにしてもよい。
(14) 前述した実施の形態では、情報端末の一例として携帯電話100について説明したが、これに限らず、ユーザが操作する情報端末であればどのようなものであってもよい。たとえば、情報端末として、PDA(Personal Digital Assistance)、パーソナルコンピュータ、テレビ受信機、カーナビ等であってもよい。また、取引の一例としてバリュー対価決済後処理によりステップS2704においてバリュー購入記録を更新するもの(すなわちバリューの購入)について説明したが、これに限らず、商品や株式等の引渡を受ける場合には、当該引渡に対する請求金額の一部または全部について支払済みにするもの等であってもよい。すなわち、売買の行為が成立する場合に、当該売買行為で発生する請求金額の一部または全部について支払済みにするものであればどのようなものであってもよい。この場合、たとえば、情報端末から出力する取引要求情報としては、商品や株式等の引渡を希望する旨の情報が該当する。情報端末は、当該情報をサーバに出力すると通信先指定情報を受信する。また、情報端末は、当該通信先指定情報により指定される金融機関のサーバに対し、商品や株式等の引渡を受けるために必要な金額分の決済を要求する旨の決済要求情報を送信する。そして、サーバは、当該決済要求情報を受信した金融機関のサーバにおいて決済の終了を条件として、商品や株式等の引渡に対する請求金額が支払われた旨を記録等する処理を取引処理として行なう。かかる取引処理が行なわれた後、係員等がサーバの記録内容を確認し、商品の発送等を行なうこととなる。
(15) 携帯電話100の非接触型ICチップ190にバリューがチャージされたとき、および、バリューの減算が完了したときに、非接触型ICチップ190の記憶部192に記憶されたバリュー残高のバックアップが記憶部120にされるようにしてもよい。
また、携帯電話100によってユーザからバックアップ操作の入力が受付けられたときに、バックアップがされるようにしてもよい。
また、携帯電話100によって前回バックアップがされてから所定期間(たとえば、3時間、1日など)経過するごとに、バックアップがされるようにしてもよい。
(16) 前述した実施の形態においては、当日に購入されたバリューの積算額を当日積算額として積算するようにした。しかし、これに限定されず、所定期間(たとえば、午前6時から翌日の午前6時までの期間)に購入されたバリューの積算額を積算するようにしてもよい。つまり、所定期間は、状況に応じて適宜設定変更可能とすればよい。
(17) 前述した実施の形態においては、図56の残高管理AP214によって、それぞれの会員IDごとに不正回数の頻度に応じて、不正に対する処理を行なうようにした。しかし、これに限定されず、すべての携帯電話での不正回数を合計した回数の頻度に応じて、不正に対する処理を行なうようにしてもよい。
(18) ステップS281で説明したように、取引額がチャージ累計額を超えているか否かにより不正取引の発生を判断して、チャージ累計額を超えた不正取引があった場合、ステップS284で説明したように、不正取引を行なった会員IDの携帯IDの不正な携帯電話100で購入されたプリペイドカード371の使用を禁止するような電子マネーシステムであってもよい。
また、ステップS281で説明したように、取引額がチャージ累計額を超えているか否かにより不正取引の発生を判断して、チャージ累計額を超えた不正取引があった場合、ステップS286で説明したように、不正取引を行なった会員IDの携帯IDの不正な携帯電話100のバリューの使用を禁止するような電子マネーシステムであってもよい。
また、ステップS281で説明したように、取引額がチャージ累計額を超えているか否かにより不正取引の発生を判断して、チャージ累計額を超えた不正取引があった場合、ステップS289で説明したように、不正取引が発生したホール(遊技場)でのすべての携帯電話でのバリューの使用を禁止するような電子マネーシステムであってもよい。
(19) 前述した実施の形態では、電子マネー管理サーバ200の残高管理AP214から店舗サーバ800を介して送信されてきた携帯使用禁止情報および不正端末記憶情報に基づき、券売機300のデータ処理部310は、記憶部320に携帯使用禁止情報および不正端末情報を記憶させる。そして、券売機300において、プリペイドカード371の購入に使用されている携帯電話100の携帯IDが記憶部310に記憶されている不正端末情報でないか、または記憶部310に携帯使用禁止情報が記憶されていないかが判断され、記憶されているときに取引不能にする。すなわち、前述した実施の形態では、券売機300において、不正取引であるか否か判断され、不正取引であると判断されたときに取引不能にする制御を行なう例について説明した。
しかし、これに限らず、店舗サーバ800において、不正取引であるか否か判断され、不正取引であると判断されたときに取引不能である旨を示す取引不能信号を券売機300に送信し、券売機300において取引不能信号を受信したときに取引不能にする制御が行なわれるようにしてもよい。たとえば、店舗サーバ800のデータ処理部は、電子マネー管理サーバ200の残高管理AP214からの携帯使用禁止情報および不正端末記憶情報を、店舗サーバ800の記憶部に記憶させる。一方、券売機300のデータ処理部310は、取引が行なわれる毎に、取引に用いられる携帯電話100の携帯IDを店舗サーバ800に送信する。店舗サーバ800のデータ処理部は、送信されてきた当該携帯IDが記憶部に記憶されている不正端末情報でないか、または記憶部に携帯使用禁止情報が記憶されていないかが判断され、記憶されているときに取引不能にする旨を示す取引不能信号を当該券売機300に送信する。券売機300のデータ処理部310は、取引不能信号に基づき、取引不能にする制御を行なう。
また、電子マネー管理サーバ200の残高管理AP214から店舗サーバ800に送信されてきた不正媒体情報に基づき、店舗サーバ800のデータ処理部は、当該不正媒体情報に含まれる携帯IDに対応して記憶部に記憶されているカードIDを不正カードIDとしてカードユニット600に送信し、カードユニット600の記憶部620に記憶させる。そして、カードユニット600において、球貸に使用されているプリペイドカードのカードIDが記憶部620に記憶されている不正カードIDでないかが判断され、不正カードIDであるときに球貸不能にする。すなわち、前述した実施の形態では、カードユニット600において、不正取引であるか否か判断され、不正取引であると判断されたときに球貸不能にする制御を行なう例について説明した。
しかし、これに限らず、店舗サーバ800において、不正取引であるか否か判断され、不正取引であると判断されたときに球貸不能である旨を示す球貸不能信号をカードユニット600に送信し、カードユニット600において球貸不能信号を受信したときに球貸不能にする制御が行なわれるようにしてもよい。たとえば、店舗サーバ800のデータ処理部は、電子マネー管理サーバ200の残高管理AP214から店舗サーバ800に送信されてきた不正媒体情報に基づき、当該不正媒体情報に含まれる携帯IDに対応して記憶部に記憶されているカードIDを不正カードIDとして店舗サーバ800の記憶部に記憶させる。一方、カードユニット600のデータ処理部610は、球貸しが行なわれる毎に、球貸しに用いられるプリペイドカードのカードIDを店舗サーバ800に送信する。店舗サーバ800のデータ処理部は、送信されてきた当該カードIDが記憶部に記憶されている不正カードIDでないかが判断され、記憶されているときに球貸不能にする旨を示す球貸不能信号を当該カードユニット600に送信する。カードユニット600のデータ処理部610は、球貸不能信号に基づき、球貸不能にする制御を行なう。
(20) 電子マネーのチャージに関する対価の決済のための決済用処理としては、金融機関サーバ500,500Aを利用した振込処理や、クレジットカード機関サーバが提供する与信による処理に限らず、本実施の形態における電子マネー管理サーバ200が提供するバリューとは異なる電子マネー等を使用して決済を行なう処理であってもよい。また、本実施の形態においては、携帯電話100と金融機関サーバ500が通信することにより決済用処理が行なわれたが、このように携帯電話100を使用するものに限らず、ユーザが電子マネー提供機関の口座に現金振込を行なうことにより決済が行なわれ、当該振込の行なわれた金融機関のサーバから電子マネー管理サーバ200に対して消込速報が通知されるようにしてもよい。
(21) 第1の実施の形態におけるバリュー購入に関する処理においては、ユーザから購入希望金額を受付ける前に、図16に示すバリュー購入時AP212のステップS251においてバリュー残高と最低購入金額との合計額が携帯上保持限度額以下か否かを判定するとともに、ステップS253において同日積算額と最低購入金額との合計金額が1日購入限度額以下か否かを判定し、両判定がYESの場合にさらに購入可能金額を算出して表示金額リスト情報とともに携帯電話100に対して送信することで、携帯電話100においては、表示金額リストのうち購入可能金額以下の選択肢のみが指定可能な態様で表示された。このようにすることは、ユーザに限度額を超過する無駄な選択操作をさせることがないことから好ましいが、これに限らず、ユーザに購入希望金額を先に選択させて、当該購入希望金額を電子マネー管理サーバ200に送信し、バリュー残高と購入希望金額との合計額が携帯上保持限度額以下か否かを判定するとともに、当日積算額と購入希望金額との合計額が1日購入限度額以下か否かを判定するようにしてもよい。
(22) 本実施の形態においては、図17に示すバリュー対価決済後処理において当日積算額を加算更新している、つまり図16に示すステップS251、S253において携帯上保持限度額あるいは1日購入限度額以下でありチャージを許容すると判定された電子マネーの額を当日積算額に加算して管理しているが、これに限らず、図19に示すバリュー発行時AP213におけるステップS277のバリュー発行情報送信に関連して、つまり携帯電話100に対してバリュー発行情報が送信されたバリューの額を当日積算額に加算して管理するようにしてもよい。
(23) 本実施の形態においては、預かり残額を識別するための預かり残額識別情報として、電子マネー管理サーバ200側において発行される預かり番号と遊技者から入力を受付けるパスワードの2種類の識別情報を使用しているが、これに限らず、いずれか一方のみでもよい。また、預かり番号やパスワードに限られず、預かり残額を識別可能な識別情報であればどのような形式のものであってもよい。
(24) 本実施の形態においては、携帯電話100に記憶されたバリューを使用して取引処理を行なう取引手段(取引装置)として、プリペイドカード371を発行する処理を行なう発券機300と球貸処理を行なうカードユニット600とを説明しているが、取引処理手段(取引装置)はこのような遊技場に設置される装置に限らず、たとえば携帯電話100に記憶されたバリューを使用して物品やチケット等を払出す取引処理を行なう自動販売装置であってもよいし、インターネットショッピング等でユーザが購入した商品の対価としてバリューを使用するような場合には、当該対価としてバリューを徴収するための処理を行なうショッピングサイト運営サーバが取引処理手段(取引装置)を構成する。
(25) 本実施の形態においては、初期登録処理、バリュー購入処理、バリュー発行処理、バリュー預け処理、およびバリュー返却処理において、種々の情報が複数回に分けて携帯電話100と電子マネー管理サーバ200との間で送受信されているが、各情報を処理のどの段階で何回に分けて送信するかといったことは、実施の形態に限られるものではなく、適宜変更可能である。
たとえば、バリュー購入処理において、携帯電話100から電子マネー管理サーバ200に対して、チャージ要求情報、第1口座振替依頼情報および第2口座振替依頼情報が送信されるが、予め購入希望金額の選択を受付けるような場合には、第1口座振替依頼情報を送信することなく、購入希望金額を含むチャージ要求情報を送信すればよいし、合計金額の確認を受付けない場合には、第2口座振替依頼情報を送信することなく、第1口座振替依頼情報に対して引継ぎ画面情報を返信するようにしてもよい。一方、電子マネー管理サーバ200から携帯電話100に対しては、表示金額リスト等を含む残高情報がチャージ受付情報として返信されるとともに、合計金額確認情報および引継ぎ画面情報が送信されるが、表示金額リスト等とは別個にチャージ受付情報を送信してもよいし、合計金額確認情報を送信することなく引継ぎ画面情報を送信してもよい。
(26) 本実施の形態においては、携帯電話100を個々に識別するための識別情報として予め携帯電話100に付与されている携帯端末情報(携帯ID)と電子マネー遊技使用サービスに会員登録することにより発行される会員IDとを使用しているが、これに限らず、いずれか一方のIDのみを使用してもよいし、種類によって使用するIDを使い分けてもよい。
(27) 本実施の形態の携帯電話100においては、初期登録処理、バリュー発行処理、バリュー預け処理およびバリュー返却処理における処理状況を、記憶部120に設けた1つの処理状況を各処理において共通に更新するようにした。しかし、これに限定されるものではなく、たとえば、バリューを重複して購入できるような場合には、図58に示す各バリューごとに処理状況(発行状況)を管理し、初期登録処理、バリュー預け処理およびバリュー返却処理における処理状況については、図示していないが発行状況とは別に記憶・管理するようにしてもよい。図58で示すDBは、バリューの購入番号、購入したバリューの額、および、処理状況を対応付けて記憶する。たとえば、購入番号が「90010801」および「90005587」であるバリューの額は、それぞれ「1000」円および「5000」円であり、処理状況は、それぞれ「発行情報受信済」および「書込済」である。
(28) 本実施の形態においては、データとして電子マネーを例にとり説明したが、データの種類は特に限定されるものではなく、たとえば、所定の会員登録を行なうことにより発行処理サーバから発行される会員IDをデータとして携帯端末の記憶部に書込むものであってもよいし、発行処理サーバから発行されるポイント情報をデータとして書込むものであってもよい。
(29) 本実施の形態においては、削除処理において、電子マネー(データ)とともに、電子マネー記憶領域も削除するものであったが、これに限定されるものではなく、電子マネー記憶領域を削除することなく、電子マネーのみを削除するものであってもよい。
(30) 本実施の形態においては、図11のステップS1113において処理状況をクリアして更新するようにしたが、これに限定されず、処理状況を書込済等、対応する処理が終了したことを示す状態に更新するものであってもよい。
(31) 本実施の形態においては、電子マネー(電子マネー記憶領域)の削除がバリュー預け処理において実施される例について説明したが、これに限定されず、たとえば、電子マネーアプリ初期画面に「領域削除」のメニューを設けておき、当該メニューが操作されることにより、領域(データ)を削除する処理のみが行なわれるようにしてもよい。
(32) 第1の実施の形態においては、携帯電話100における処理状況とリモート発行サーバ400における書込状況の比較をオペレータが実施したが、これに限定されず、電子マネー管理サーバ200がリモート発行サーバ400から書込状況を取得し、携帯電話100から取得した処理状況と比較を行なうようにしてもよい。
(33) 第1の実施の形態においては、図26および図27で説明したように、バリューの購入と同様に、特典バリューがネットチャージされるようにした。しかし、これに限定されず、携帯電話に特典を付与するための特典付与装置を店舗に設置して、その特典付与装置で特典を携帯電話100に付与するようにしてもよい。
具体的には、特典付与装置は、遊技場30の券売機300やカードユニット600で構成することもできるし、券売機300やカードユニット600とは別個の装置として設けてもよい。以下、本実施の形態において特典バリューが携帯電話100にチャージされるまでの処理について説明する。
本実施の形態においては、図66(a)の起動時初期画面で「ICチップへの特典バリューのチャージ」のリンクが選択されると、携帯電話100から電子マネー管理サーバ200に該携帯電話100の携帯端末情報を含む特典付与要求が送信される。該特典付与要求を受信した電子マネー管理サーバ200では、該特典付与要求に含まれる携帯端末情報に対応付けて特典DB223に記憶されている取引店舗および前回特典付与後取引額が抽出され、図27(b)のステップS2193と同様に使用可能店舗ごとに特典付与額を算出する。そして、特典基準額に達している前回特典付与後取引額が存在しない場合には、その旨を携帯電話100に返信する一方、付与特典額が算出された場合には、当該特典付与額の算出の元になった店舗、あるいは算出の元になったグループに属する店舗を示す受取可能店舗情報を携帯電話100に返信する。
受取可能店舗情報を受信した携帯電話100では、図66(b)の特典受取店舗選択画面が表示部140に表示される。特典受取店舗選択画面には、特典バリューを受取る店舗の選択を促がす旨の文章、前記受取可能店舗情報で示される各店舗、該各店舗のうちから特典を受取る店舗を選択するためのラジオボタン、および、選択した店舗を示す店舗識別情報を電子マネー管理サーバ200に送信するためのリンクである「送信」が表示される。
この特典受取店舗選択画面で、特典を受取る店舗が選択されて、「送信」のリンクが操作されることによって、図66(c)の特典受取店舗選択完了画面が携帯電話100の表示部140に表示される。特典受取店舗選択完了画面には、特典受取店舗が選択された旨の文章、選択された店舗を示す情報、および、遊技場30のカードユニット600に携帯電話100をかざすことによって特典バリューが受取れることを説明するための文章が表示される。また、選択された店舗を特定可能な店舗選択情報が電子マネー管理サーバ200に送信される。
店舗選択情報を受信した電子マネー管理サーバ200では、選択された遊技場30の店舗サーバ800に、前記算出された付与特典額の特典バリューと対象となる携帯電話100を識別するための携帯端末情報、さらには当該特典バリューを使用可能な使用可能店舗情報を送信する。
店舗サーバ800は、受信した特典バリュー、携帯端末情報および使用可能店舗情報を、遊技場30内の特典付与装置に送信する。そして、特典付与装置は、携帯電話100を受付けると、受付けた携帯電話100から携帯端末情報を取得し、前記店舗サーバ800から受信している携帯端末情報の中に、取得した携帯端末情報と一致するものが存在するか否か判定する。一致するものが存在する場合、その携帯端末情報に対応する特典バリューおよび使用可能店舗情報を携帯電話100の非接触型ICチップ190の記憶部192に書込むための書込コマンドを携帯電話100に送信することにより、特典バリューおよび使用可能店舗情報を携帯電話100の非接触型ICチップ190の記憶部192に記憶させる。
なお、特典を受取る店舗としては、特典バリューの算出の元になった店舗に限られず、全加盟店の中から選択できるようにしてもよい。また、ユーザから選択を受付けることなく、特典バリューの算出の元になった全ての店舗あるいは全加盟店の店舗サーバ800に送信するようにしてもよい。ただし、この場合には、ある店舗の特典付与装置で特典バリューの付与が行なわれた場合に、当該特典付与装置から携帯端末情報を含む付与完了通知を電子マネー管理サーバ200に通知し、電子マネー管理サーバ200から他の店舗の店舗サーバ800に携帯端末情報を含む削除指示を送信し、特典付与装置に記憶されている当該携帯端末情報および特典バリューを削除し、特典バリューが重複してチャージされるのを防止する必要がある。
つまり、電子マネーシステム10は、さらに、複数の店舗(たとえば、遊技場30)に設置され、携帯端末(たとえば、携帯電話100)に対して特典を付与する処理を実行する特典付与装置(たとえば、カードユニット600)を含む。取引管理装置(たとえば、電子マネー管理サーバ200)によって、特典を示す情報と特典が付与される携帯端末を識別するための携帯端末識別情報(たとえば、携帯端末情報)とを特典付与装置に送信する処理が、特典付与処理として実行される。特典付与装置によって、携帯端末が受付けられ、受付けられた携帯端末の携帯端末識別情報が、取引管理装置から送信された携帯端末識別情報と一致するか否かが判定され、一致すると判定されたことを条件として、当該携帯端末識別情報とともに取引管理装置から送信された情報で示される特典が受付けられた携帯端末に対して付与される。このように、店舗に設置された特典付与装置によって携帯端末に特典が付与される。その結果、特典付与が店舗において実施されるため、当該店舗への集客をより確実に向上できる。
(34) 本実施の形態においては、図27(a)の特典通知APのS2093で、前回特典付与後取引額が特典基準額に達していることを条件として、付与特典額を算出せずに、特典通知メールを携帯電話100に送信するようにした。そして、特典通知メールのリンクが操作されることによって、特典付与AP217のステップS2191で特典発行要求情報が受信されてから、ステップS2193で付与特典額を算出するようにした。
しかし、これに限定されるものではなく、図27(a)の特典通知APのステップS2092において、図27(b)のステップS2193と同様に使用可能店舗ごとに付与特典額を算出し、算出した付与特典額と使用可能店舗情報を特典DB223または発行情報DB222に登録し、携帯電話100からの特典発行要求情報の受信に応じて、該登録されている特典バリューを携帯電話100にチャージするための処理を行なうようにしてもよい。この場合には、図27(a)のステップS2093において送信する特典通知メールに使用可能店舗ごとの特典バリューの額を含めるようにすればよい。
実施例においては、携帯端末が携帯電話100とされているが、これに限定されるものではなく、ユーザが携帯可能であるとともに、取引価値である電子マネーを記憶可能であればよく、たとえばカードなどの記録媒体でもよい。
実施例においては、取引価値が電子マネーとされているが、これに限定されるものではなく、取引に使用される価値であればどのようなものでもよく、たとえば取引対象物の個数(遊技場であれば玉数)を示す情報でもよい。
実施例においては、取引額に応じて付与される特典が電子マネーとされているが、これに限定されるものではなく、ユーザにとって利益となるものであればどのようなものでもよく、たとえばポイントであったり、店舗で割引や粗品の提供を受けられるクーポンであってもよい。
実施例においては、各店舗における取引額の管理を発行情報DB222と特典DB223の両方で行なっているが、これに限定されるものではなく、いずれか一方のDBで行なうようにしてもよい。
実施例においては、ユーザが購入した購入バリューと特典バリューとを区別して電子マネー管理サーバ200で管理したり携帯電話100に記憶させたりしているが、これに限定されるものではなく、購入バリューと特典バリューを区別することなく、両者を合算して管理したり、記憶させたりしてもよい。また、特典バリューのうち、使用可能店舗が全加盟店のものについては、購入バリューと合算して管理したり、記憶させたりしてもよい。
実施例においては、図28に示す特典設定画面で使用可能店舗として全加盟店か付与店舗・グループかを選択可能とされていたが、これに限定されるものではなく、特典付与対象店舗として設定された全店舗を使用可能店舗として設定したり、あるいは任意に入力された店舗を使用可能店舗として設定したりするようにしてもよい。
実施例においては、初期登録時に金融機関の指定を受付けることとされているが、該指定を受付けるタイミングはこれに限定されるものではなく、たとえば図16に示すバリュー購入時AP212において金融機関の指定や口座番号およびパスワードの入力を受付けて、利用者情報DB221に登録するようにしてもよい。また、指定された金融機関や口座番号等を利用者情報DB221に登録することなく、バリュー購入の都度受付けるようにしてもよい。
実施例においては、図16に示すバリュー購入時AP212において、利用者情報DB221に登録されている金融機関が、間接決済対応の金融機関か直接決済対応の金融機関かにかかわらず、ステップS244で未チャージバリューの有無がチェックされたが、これに限定されるものではなく、直接決済対応の金融機関の場合には、未チャージバリューが電子マネー管理サーバ200に残存していることがありえないので、未チャージバリューの有無をチェックしなくてもよい。
実施例においては、図16に示すバリュー購入時AP212において、利用者情報DB221に登録されている金融機関が、間接決済対応の金融機関か直接決済対応の金融機関かにかかわらず、図40(c)に示す電子メールアドレス確認画面が表示されたが、これに限定されるものではなく、直接決済対応の金融機関の場合には、引継ぎ情報を含むメールが送信されないため、同画面を表示しないようにしてもよい。
(35) 今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
本発明に係る電子マネーシステムの構成の一例を示すブロック図である。 本発明に係る携帯電話の構成の一例を示すブロック図である。 本発明に係る電子マネー管理サーバの構成の一例を示すブロック図である。 本実施の形態における電子マネー管理サーバが電子マネー遊技使用サービスを提供する際に用いる利用者情報データベースを説明するための図である。 本実施の形態における電子マネー管理サーバが電子マネー遊技使用サービスを提供する際に用いる発行情報データベースを説明するための図である。 本発明に係る券売機の構成の一例を示すブロック図である。 本実施の形態におけるカードユニットの構成の一例を示すブロック図である。 本実施の形態における電子マネー管理サーバにより実行される初期登録時アプリケーションプログラムの処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバで金融機関が直接決済対応か間接決済対応かを設定するための金融機関設定画面である。 本実施の形態における携帯電話のウェブブラウザ機能により実行されるウェブ処理の流れを示すフローチャートである。 本実施の形態における携帯電話で実行される電子マネーアプリの処理の流れを示すフローチャートである。 本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンである初回起動処理の流れを示すフローチャートである。 本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるICチップ起動処理の流れを示すフローチャートである。 本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンである処理状況確認処理の流れを示すフローチャートである。 本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるバリュー購入時処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバにより実行されるバリュー購入時アプリケーションプログラムの処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバにより実行されるバリュー購入時アプリケーションプログラムのサブルーチンであるバリュー対価決済後処理の流れを示すフローチャートである。 本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるバリュー発行時処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバにより実行されるバリュー発行時アプリケーションプログラムの処理の流れを示すフローチャートである。 本実施の形態における携帯電話により実行されるバリュー購入時処理のサブルーチンである直接決済購入処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバにより実行されるバリュー購入時アプリケーションプログラムのサブルーチンである直接決済発行処理の流れを示すフローチャートである。 本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるバリュー預け処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバにより実行されるバリュー預かりアプリケーションプログラムの処理の流れを示すフローチャートである。 本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるバリュー返却処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバにより実行されるバリュー返却アプリケーションプログラムの処理の流れを示すフローチャートである。 本実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンである特典発行時処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバにより実行される特典通知アプリケーションプログラムおよび特典付与アプリケーションプログラムの処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバで特典の付与方法を設定するための特典設定画面である。 本実施の形態における電子マネー管理サーバが特典を付与する際に用いる特典付与店舗データベースを説明するための図である。 本実施の形態における電子マネー管理サーバが特典を付与する際に用いる特典データベースを説明するための図である。 本実施の形態の携帯電話の非接触型ICチップの記憶部の電子マネー遊技使用サービス用記憶領域に記憶されるデータベースを説明するための図である。 本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第1の表示画面図である。 本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第2の表示画面図である。 本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第3の表示画面図である。 本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第4の表示画面図である。 本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第5の表示画面図である。 本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第6の表示画面図である。 本実施の形態における電子マネーシステムに携帯電話を初期登録するときに携帯電話の表示部に表示される第7の表示画面図である。 本実施の形態における電子マネーシステムにおいて携帯電話でバリューを購入するときに携帯電話の表示部に表示される第1の表示画面図である。 本実施の形態における電子マネーシステムにおいて携帯電話でバリューを購入するときに携帯電話の表示部に表示される第2の表示画面図である。 本実施の形態における電子マネーシステムにおいて携帯電話でバリューを購入するときに携帯電話の表示部に表示される第3の表示画面図である。 本実施の形態における電子マネーシステムにおいて携帯電話でバリューを購入するときに携帯電話の表示部に表示される第4の表示画面図である。 本実施の形態における電子マネーシステムにおいて直接決済対応の金融機関で決済が行なわれて携帯電話にバリューをチャージするときに携帯電話の表示部に表示される第1の表示画面図である。 本実施の形態における電子マネーシステムにおいて携帯電話にバリューをチャージするときに携帯電話の表示部に表示される第1の表示画面図である。 本実施の形態における電子マネーシステムにおいて携帯電話から電子マネー管理サーバにバリューを預けるときに携帯電話の表示部に表示される第1の表示画面図である。 本実施の形態における電子マネーシステムにおいて携帯電話から電子マネー管理サーバにバリューを預けるときに携帯電話の表示部に表示される第2の表示画面図である。 本実施の形態における電子マネーシステムにおいて電子マネー管理サーバに預けたバリューの返却を受けるときに携帯電話の表示部に表示される第1の表示画面図である。 本実施の形態における電子マネーシステムにおいて電子マネー管理サーバに預けたバリューの返却を受けるときに携帯電話の表示部に表示される第2の表示画面図である。 本実施の形態における電子マネーシステムにおいて携帯電話に特典が付与されるときに携帯電話の表示部に表示される第1の表示画面図である。 本実施の形態における券売機で実行される発券処理の流れを示すフローチャートである。 本実施の形態における券売機で実行される不正登録処理の流れを示すフローチャートである。 本実施の形態における電子マネーシステムにおいて券売機から携帯電話の電子マネーアプリが起動されるときに携帯電話の表示部に表示される第1の表示画面図である。 本実施の形態におけるカードユニットで実行される球貸処理の流れを示すフローチャートである。 本実施の形態におけるカードユニットで実行されるプリペイド球貸処理の流れを示すフローチャートである。 本実施の形態におけるカードユニットで実行されるユニット不正登録処理の流れを示すフローチャートである。 本実施の形態における電子マネー管理サーバにより実行される残高管理アプリケーションプログラムの処理の流れを示すフローチャートである。 本実施の形態における店舗サーバで実行される店舗サーバ処理の流れを示すフローチャートである。 本実施の形態の変形例における携帯電話の記憶部に記憶されるデータベースを説明するための図である。 第2の実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンであるバリュー発行時処理の流れを示すフローチャートである。 第2の実施の形態における電子マネー管理サーバにより実行されるバリュー発行時アプリケーションプログラムの処理の流れを示すフローチャートである。 第2の実施の形態における携帯電話により実行されるバリュー購入時処理のサブルーチンである直接決済購入処理の流れを示すフローチャートである。 第2の実施の形態における電子マネー管理サーバにより実行されるバリュー購入時アプリケーションプログラムのサブルーチンである直接決済発行処理の流れを示すフローチャートである。 第2の実施の形態における携帯電話により実行される電子マネーアプリのサブルーチンである特典発行時処理の流れを示すフローチャートである。 第2の実施の形態における電子マネー管理サーバにより実行される特典付与アプリケーションプログラムの処理の流れを示すフローチャートである。 第2の実施の形態における電子マネー管理サーバによって実行されるエラー対応処理の流れを示すフローチャートである。 本実施の形態の変形例における電子マネーシステムにおいて携帯電話に特典が付与されるときに携帯電話の表示部に表示される第1の表示画面図である。
符号の説明
10 電子マネーシステム、30 遊技場、100 携帯電話、110 データ処理部、111 電子マネーアプリ、120 記憶部、130 データ入力部、140 表示部、150 音声入出力部、160 無線通信部、161 アンテナ、190 非接触型ICチップ、191 制御部、192 記憶部、193 非接触通信部、194 アンテナ、200 電子マネー管理サーバ、210 データ処理部、211 初期登録時AP、212 バリュー購入時AP、213 バリュー発行時AP、214 残高管理AP、215 バリュー預かりAP、216 バリュー返却AP、217 特典付与AP、220 記憶部、221 利用者情報DB、222 発行情報DB、223 特典DB、230 データ入力部、240 表示部、260 通信部、280 決済サーバ、300 券売機、310 データ処理部、320 記憶部、330 操作部、340 表示部、360 通信部、370 カードリーダライタ、371 プリペイドカード、380 貨幣処理機、390 チップリーダライタ、391 制御部、392 記憶部、393 非接触通信部、394 アンテナ、400 リモート発行サーバ、500,500A 金融機関サーバ、600 カードユニット、610 データ処理部、620 記憶部、631 球貸ボタン、632 返却ボタン、640 表示部、660 通信部、670 カードリーダライタ、680 貨幣処理機、690 チップリーダライタ、691 制御部、692 記憶部、693 非接触通信部、694 アンテナ、700 パチンコ遊技機、800 店舗サーバ。

Claims (6)

  1. 複数の店舗に設置され、携帯端末に記憶されている取引価値を用いて取引処理を実行する取引装置と、前記取引処理に用いられた前記取引価値の額である取引額を各携帯端末ごとに集計して管理する取引額管理手段を有する取引管理装置とを含む取引システムであって、
    前記取引額管理手段は、前記各携帯端末の取引額を各店舗ごとに集計して管理し、
    前記取引管理装置は、
    前記複数の店舗のうちから、前記取引処理に対する特典付与の対象とする特典付与対象店舗を設定する対象店舗設定手段と、
    前記取引額管理手段によって管理されている取引額のうち、前記対象店舗設定手段によって設定された前記特典付与対象店舗における取引額に応じて前記特典を付与するための特典付与処理を実行する特典付与手段を含むことを特徴とする、取引システム。
  2. 前記取引管理装置は、さらに、
    複数の店舗が属するグループを設定するグループ設定手段を備え、
    前記特典付与手段は、前記取引額管理手段によって管理されている取引額のうち、前記グループ設定手段によって設定された前記グループに含まれる前記店舗における取引額の合計額に応じて前記特典付与処理を実行することを特徴とする、請求項1に記載の取引システム。
  3. 前記特典付与手段は、前記取引額に応じた額の取引価値である付与取引価値を前記携帯端末に記憶させるための処理を、前記特典付与処理として実行することを特徴とする、請求項1または請求項2に記載の取引システム。
  4. 前記取引管理装置は、さらに、
    前記付与取引価値を使用可能とする使用可能店舗を設定する使用可能店舗設定手段を備え、
    前記特典付与手段は、ユーザによる対価の支払に応じた取引価値とは区別して前記付与取引価値を前記携帯端末に記憶させるための処理とともに、当該付与取引価値に対して前記使用可能店舗設定手段によって設定された前記使用可能店舗を示す使用可能店舗情報を当該付与取引価値に対応させて前記携帯端末に記憶させるための処理を、前記特典付与処理として実行し、
    前記取引装置は、前記携帯端末から取得した使用可能店舗情報が示す使用可能店舗が、当該取引装置が設置されている店舗であることを条件として、当該使用可能店舗情報に対応させて前記携帯端末に記憶されている付与取引価値を用いて前記取引処理を実行することを特徴とする、請求項3に記載の取引システム。
  5. 前記取引システムは、さらに、
    複数の店舗に設置され、前記携帯端末に対して前記特典を付与する処理を実行する特典付与装置を含み、
    前記特典付与手段は、前記特典を示す情報と前記特典が付与される携帯端末を識別するための携帯端末識別情報とを前記特典付与装置に送信する処理を、前記特典付与処理として実行し、
    前記特典付与装置は、
    前記携帯端末を受付ける受付手段と、
    前記受付手段によって受付けられた携帯端末の携帯端末識別情報が、前記特典付与手段から送信された携帯端末識別情報と一致するか否かを判定する携帯端末識別情報判定手段とを含み、
    前記携帯端末識別情報判定手段によって携帯端末識別情報が一致すると判定されたことを条件として、当該携帯端末識別情報とともに前記特典付与手段から送信された情報で示される特典を前記受付手段により受付けた携帯端末に対して付与することを特徴とする、請求項1から請求項4までのいずれかに記載の取引システム。
  6. 携帯端末に記憶されている取引価値を用いて取引処理を実行する複数の店舗に設置される取引装置で実行された前記取引処理に用いられた前記取引価値の額である取引額を各携帯端末および各店舗ごとに集計して管理する取引額管理手段と、
    前記複数の店舗のうちから、前記取引処理に対する特典付与の対象とする特典付与対象店舗を設定する対象店舗設定手段と、
    前記取引額管理手段によって管理されている取引額のうち、前記対象店舗設定手段によって設定された前記特典付与対象店舗における取引額に応じて前記特典を付与するための特典付与処理を実行する特典付与手段とを備えることを特徴とする、取引管理装置。
JP2007003772A 2007-01-11 2007-01-11 取引システム、および、取引管理装置 Expired - Fee Related JP5220318B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007003772A JP5220318B2 (ja) 2007-01-11 2007-01-11 取引システム、および、取引管理装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007003772A JP5220318B2 (ja) 2007-01-11 2007-01-11 取引システム、および、取引管理装置

Publications (2)

Publication Number Publication Date
JP2008171202A true JP2008171202A (ja) 2008-07-24
JP5220318B2 JP5220318B2 (ja) 2013-06-26

Family

ID=39699236

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007003772A Expired - Fee Related JP5220318B2 (ja) 2007-01-11 2007-01-11 取引システム、および、取引管理装置

Country Status (1)

Country Link
JP (1) JP5220318B2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021056624A (ja) * 2019-09-27 2021-04-08 株式会社日本総合研究所 電子マネーシステム

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1078989A (ja) * 1996-07-11 1998-03-24 Fujitsu Ltd 仮想商店街におけるポイントサービスシステム
JP2000306003A (ja) * 1999-02-18 2000-11-02 Matsushita Electric Ind Co Ltd 電子バリュー活用システム、電子バリュー活用方法およびサーバ装置並びに記録媒体
JP2004213106A (ja) * 2002-12-26 2004-07-29 Bitsuku Camera:Kk 電子的価値管理方法、電子的価値管理システム及び電子的価値管理プログラム
JP2005011116A (ja) * 2003-06-19 2005-01-13 Bitwallet Inc 金額還元装置、金額還元方法、及び金額還元プログラム
JP2005063126A (ja) * 2003-08-12 2005-03-10 Jcb:Kk ポイント還元システム
JP2006006398A (ja) * 2004-06-22 2006-01-12 Aruze Corp Icカード決済システム及びicカード
JP2006099692A (ja) * 2004-09-30 2006-04-13 Sankyo Kk 店舗用装置及び店舗用システム
JP2006235951A (ja) * 2005-02-24 2006-09-07 Japan Net Bank Ltd ポイント情報管理システム及びポイント情報管理方法

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1078989A (ja) * 1996-07-11 1998-03-24 Fujitsu Ltd 仮想商店街におけるポイントサービスシステム
JP2000306003A (ja) * 1999-02-18 2000-11-02 Matsushita Electric Ind Co Ltd 電子バリュー活用システム、電子バリュー活用方法およびサーバ装置並びに記録媒体
JP2004213106A (ja) * 2002-12-26 2004-07-29 Bitsuku Camera:Kk 電子的価値管理方法、電子的価値管理システム及び電子的価値管理プログラム
JP2005011116A (ja) * 2003-06-19 2005-01-13 Bitwallet Inc 金額還元装置、金額還元方法、及び金額還元プログラム
JP2005063126A (ja) * 2003-08-12 2005-03-10 Jcb:Kk ポイント還元システム
JP2006006398A (ja) * 2004-06-22 2006-01-12 Aruze Corp Icカード決済システム及びicカード
JP2006099692A (ja) * 2004-09-30 2006-04-13 Sankyo Kk 店舗用装置及び店舗用システム
JP2006235951A (ja) * 2005-02-24 2006-09-07 Japan Net Bank Ltd ポイント情報管理システム及びポイント情報管理方法

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
CSND200401776005; [無記名]: '「モバイルFeliCa登場でEdy決済増に期待 クラブ会員には"使う楽しみ"を提供」' モバイルRFマガジン 第94号, 200410, 37ページ. *
CSND200700215002; 白井 良: '「決済だけじゃない おサイフケータイの真の実力」' 日経コミュニケーション 第476号, 20061215, 96-101ページ. *
JPN6012017101; [無記名]: '「モバイルFeliCa登場でEdy決済増に期待 クラブ会員には"使う楽しみ"を提供」' モバイルRFマガジン 第94号, 200410, 37ページ. *
JPN6012017102; (株)am/pmジャパンほか: 「お客様とのコミュニケーションターミナル!「appoint's(アポインツ)」をam/pm店頭に設置 [検索日 2012年 3月27日], 20030819 *
JPN6013009091; 白井 良: '「決済だけじゃない おサイフケータイの真の実力」' 日経コミュニケーション 第476号, 20061215, 96-101ページ. *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021056624A (ja) * 2019-09-27 2021-04-08 株式会社日本総合研究所 電子マネーシステム
JP7368994B2 (ja) 2019-09-27 2023-10-25 株式会社日本総合研究所 電子マネーシステム

Also Published As

Publication number Publication date
JP5220318B2 (ja) 2013-06-26

Similar Documents

Publication Publication Date Title
JP4976141B2 (ja) 電子マネーサーバ、および、電子マネーシステム
JP4807980B2 (ja) 遊技用電子マネーシステム、携帯端末、および、電子マネーアプリケーションプログラム
JP4836610B2 (ja) 電子マネー管理サーバ、および、電子マネーシステム
JP4902224B2 (ja) 遊技用電子マネーシステム
JP2008287522A (ja) 電子マネーシステム
JP5220318B2 (ja) 取引システム、および、取引管理装置
JP4819435B2 (ja) 遊技用電子マネーシステム、および、サービス提供用サーバ
JP4808023B2 (ja) 電子マネーシステム、および、サービス提供用サーバ
JP5111879B2 (ja) 利用状況管理装置および電子マネーシステム
JP4808022B2 (ja) 電子マネーシステム、および、サービス提供用サーバ
JP4808021B2 (ja) 電子マネーシステム、および、サービス提供用サーバ
JP4799174B2 (ja) 電子マネーシステム、および、サービス提供用サーバ
JP5032861B2 (ja) 電子マネーサーバ
JP4822869B2 (ja) 電子マネー情報発行書込システム、発行書込処理サーバ、携帯端末、および、アプリケーションプログラム
JP4822870B2 (ja) 電子マネー情報発行書込システム、携帯端末、および、アプリケーションプログラム
JP5090003B2 (ja) 利用状況管理装置および電子マネーシステム
JP4822867B2 (ja) 電子マネー情報発行システム、携帯端末、および、アプリケーションプログラム
JP4808020B2 (ja) 電子マネーシステム、および、サービス提供用サーバ
JP4819497B2 (ja) 電子マネーシステム、および、サービス提供用サーバ
JP4819498B2 (ja) 電子マネーシステム、および、サービス提供用サーバ
JP4749151B2 (ja) 電子マネーシステム、および、サービス提供用サーバ
JP4819496B2 (ja) 電子マネーシステム、および、サービス提供用サーバ
JP4832892B2 (ja) 電子マネーシステム、および、サービス提供用サーバ
JP4689400B2 (ja) 遊技用電子マネーシステム、および、サービス提供用サーバ
JP2008276542A (ja) 電子マネーサーバ

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20091208

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120403

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120531

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20121106

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130201

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20130208

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130226

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130306

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160315

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5220318

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees