JP2002335349A

JP2002335349A - サービス運営システム

Info

Publication number: JP2002335349A
Application number: JP2001136791A
Authority: JP
Inventors: Yasuo Muramatsu; 靖夫村松; Masato Yokoi; 正人横井; Tomomitsu Miyake; 智充三宅
Original assignee: BIS KK
Current assignee: BIS KK
Priority date: 2001-05-08
Filing date: 2001-05-08
Publication date: 2002-11-22

Abstract

(57)【要約】【課題】安全で信頼性を確保することができるサービ
ス運営システムを提供すること。【解決手段】利用者が入金した入金情報を、サービス
運営サーバーにて受信する入金データ受信ステップと、
前記入金データ受信ステップで受信した入金情報を、利
用者にサービスを提供するサービス会社に対してサービ
ス運営サーバーから送信する入金データ送信ステップ
と、銀行に対して前記サービス会社への支払いデータを
送信する管理会社に、前記利用者の入金又は前記サービ
ス会社への支払いに関する売上データをサービス運営サ
ーバーから送信するステップとを有することを特徴とす
るサービス運営システム。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、利用者が例えば店
舗においてプリペイドカードを用いて入金することで各
種のサービス提供が受けられるサービス運営システムに
関する。

【０００２】

【従来の技術】従来から金券としての価値を有するプリ
ペイドカードがコンビニエンスストアなどで販売され、
例えばテレホンカードなどとして利用されている。

【０００３】

【発明が解決しようとする課題】しかし、金券としての
価値をカード自体に有するプリペイドカードは、盗難や
紛失に備えて管理を厳重にしなければならないという取
扱上の問題があった。従って、利用者がプリペイドカー
ドの購入時に入金を行い、この入金データをサーバー側
で管理することで、このような流通過程におけるプリペ
イドカードの取扱上の問題を解消するシステムが考えら
れる。しかし、かかるシステムでは、運営者の元に利用
者からの入金を集め、その後サービス提供者に分配する
必要が生じるため、サービス提供者から見ると、運営者
に対する取引の安全性と確実性が大きな問題となる。

【０００４】そこで本発明は、安全で信頼性を確保する
ことができるサービス運営システムを提供することを目
的とする。

【０００５】

【課題を解決するための手段】請求項１記載の本発明の
サービス運営システムは、利用者が入金した入情報を、
サービス運営サーバーにて受信する入金データ受信ステ
ップと、前記入金データ受信ステップで受信した入金情
報を、利用者にサービスを提供するサービス会社に対し
てサービス運営サーバーから送信する入金データ送信ス
テップと、金融機関に対して前記サービス会社への支払
いデータを送信する管理会社に、前記利用者の入金又は
前記サービス会社への支払いに関する売上データをサー
ビス運営サーバーから送信するステップとを有すること
を特徴とする。請求項２記載の本発明のサービス運営シ
ステムは、利用者が入金した入金情報を、サービス運営
サーバーにて受信する入金データ受信ステップと、サー
ビス会社のサービス利用に関する決済依頼に対して前記
サービス運営サーバーから決済完了情報を送信する決済
データ送信ステップと、金融機関に対して前記サービス
会社への支払いデータを送信する管理会社に、前記利用
者の前記サービス会社への支払いに関する売上データを
送信するステップとを有することを特徴とする。請求項
３記載の本発明は、請求項２に記載のサービス運営シス
テムにおいて、決済データ送信ステップ前に、前記サー
ビスに対する決済依頼データを受信する決済依頼受信ス
テップと、前記決済依頼受信ステップで受信した決済依
頼データによって当該利用者の入金情報から利用料金を
差し引くステップとを有することを特徴とする。請求項
４記載の本発明は、請求項１から請求項３のいずれかに
記載のサービス運営システムにおいて、サービス運営口
座に前記利用者からの入金を受ける入金ステップと、前
記入金ステップで受け付けた入金を前記金融機関の管理
口座に出金する出金ステップとを有することを特徴とす
る。請求項５記載の本発明は、請求項１から請求項３の
いずれかに記載のサービス運営システムにおいて、前記
入金データ受信ステップでは、前記利用者が店舗におい
てプリペイドカードを用いて入金し、前記入金データ受
信ステップで受信する入金情報を、前記プリペイドカー
ドに付与されている識別番号と、入金が行われた店舗識
別番号と、入金が行われた日時と、入金額に関する情報
と、カード種別情報とを含む情報としたことを特徴とす
る。

【０００６】

【発明の実施の形態】本発明の第１の実施の形態による
サービス運営システムは、利用者が入金した入金情報を
受信する入金データ受信ステップと、この入金情報をサ
ービス会社に対して送信する入金データ送信ステップ
と、管理会社に、利用者の入金又はサービス会社への支
払いに関する売上データを送信するステップとを有する
ものである。本実施の形態によれば、利用者が入金した
入金情報は、サービス運営サーバーを経由してサービス
会社に送信されるため、利用者はサービス会社の提供す
るサービスを入金後に受けることができる。また、サー
ビス会社への支払いデータは、サービス運営サーバーか
ら管理会社を経由して金融機関に送信される。従って、
金融機関からサービス会社への支払は、この支払いデー
タに基づいて行われるが、管理会社を経由することで、
安全で信頼性を確保することができる。

【０００７】本発明の第２の実施の形態によるサービス
運営システムは、利用者が入金した入金情報を受信する
入金データ受信ステップと、サービス会社に対して決済
完了情報を送信する決済データ送信ステップと、管理会
社に、サービス会社への支払いに関する売上データを送
信するステップとを有するものである。本実施の形態に
よれば、利用者が入金した入金情報は、サービス運営サ
ーバーに送信され、決済依頼に対する決済完了情報をサ
ービス運営サーバーから送信することで、利用者はサー
ビス会社の提供するサービスを入金後に受けることがで
きる。また、サービス会社への支払いデータは、サービ
ス運営サーバーから管理会社を経由して金融機関に送信
される。従って、金融機関からサービス会社への支払
は、この支払いデータに基づいて行われるが、管理会社
を経由することで、安全で信頼性を確保することができ
る。

【０００８】本発明の第３の実施の形態は、第２の実施
の形態によるサービス運営システムにおいて、サービス
会社にてサービスが行われる前に、サービスに対する決
済依頼データを受信する決済依頼受信ステップと、決済
依頼データによって当該利用者の入金情報から利用料金
を差し引くステップとを有するものである。本実施の形
態によれば、決済依頼に基づいて決済完了情報が送信さ
れ、また決済完了情報が送信される前に、入金情報から
サービス利用に伴う利用料金を差し引くため、利用者に
よる複数サービスの利用が同時期に行われた場合であっ
ても、残金内での決済を確実に行わせることができる。

【０００９】本発明の第４の実施の形態は、第１から第
３の実施の形態によるサービス運営システムにおいて、
サービス運営口座に利用者からの入金を受ける入金ステ
ップと、この入金を金融機関の管理口座に出金する出金
ステップとを有するものである。本実施の形態によれ
ば、サービス運営口座への入金は、そのまま金融機関の
管理口座に移されるため、サービス運営者に影響される
ことなく、本サービス運営システムの安全性と信頼性を
確保することができる。

【００１０】本発明の第５の実施の形態は、第１から第
３の実施の形態によるサービス運営システムにおいて、
利用者が店舗においてプリペイドカードを用いて入金し
た入金情報として、プリペイドカードに付与されている
識別番号と、入金が行われた店舗識別番号と、入金が行
われた日時と、入金額に関する情報と、カード種別情報
とを含む情報としたものである。本実施の形態によれ
ば、入金情報として、識別番号と、入金が行われた店舗
識別番号と、入金が行われた日時と、入金額に関する情
報と、カード種別情報とを含むことで取引の安全性を高
めることができる。

【００１１】

【実施例】以下本発明の一実施例によるサービス運営シ
ステムについて説明する。図１は、本実施例によるサー
ビス運営システムを説明するための概念図である。同図
に示すように、サービス提供を求める利用者１がサービ
ス提供を受けるために必要な利用料金をあらかじめ入金
する利用料金受付システム２と、本サービス運営を行う
サービス運営システム３と、サービス運営システムに集
められた利用者からの利用料金の分配サービスを行う管
理会社４と、銀行などの金融機関が管理する管理口座５
と、電話回線の接続サービスを行う電話会社６がある。
ここで銀行などの金融機関が管理する管理口座５は、例
えば金融機関名義の口座であり、サービス運営者と異な
る第三者名義の口座である。利用料金受付システム２
は、例えばコンビニエンスストアであり、各地域に有す
る店舗２Ａと、各店舗２Ａでの売り上げや支払いを統括
する本部２Ｂとから構成されている。ただし、必ずしも
同図に示すように、本部を備えた場合に限られるもので
はなく、店舗自体が独立形態として売り上げや支払いを
行う場合であってもよい。また、店舗が金融機関の支店
であってもよく、また各地域に配設されたＡＴＭでもよ
い。サービス運営システム３は、サービス運営サーバー
３Ａとサービス運営口座３Ｂとを有する。サービス運営
サーバー３Ａは、入金情報などのデータを送受信しサー
ビスの運営を管理する。一方、サービス運営口座３Ｂ
は、利用料金受付システム２から振り込まれたお金を一
時的に保管する。なお、同図においては、サービス会社
として電話会社６を示しているが、必ずしも電話会社に
限られることはなく、他のサービス提供を行う組織であ
ってもよい。

【００１２】利用者１は、電話会社６の通話サービスの
提供を希望する場合に店舗２Ａにて入金手続きを行う。
この入金手続きが行われると、店舗２Ａから入金情報が
サービス運営サーバー３Ａを介して電話会社６に送信さ
れる。電話会社６に入金情報が送信された後に、利用者
１は、電話会社６の通話サービスを受けることができ
る。従って、利用者１は、電話会社６に対して通話サー
ビスの提供を求めることで、通話サービスを受けること
ができる。

【００１３】図２は、本実施例によるサービス運営シス
テムのフロー図である。図１とともに図２を用いてデー
タとお金の流れを以下に説明する。利用者は、カードを
購入して入金を行う。既に利用者がカードを購入済みの
場合には、所有するカードを用いて入金を行う。すなわ
ち、このカードは再入金可能なリチャージャブルカード
であることが好ましい。このカードには、カードを識別
するために、カードごとに異なるユニークな番号が付与
されたシリアル番号が記憶されている。またこのカード
には、カード識別番号、カード発行会社コード、サービ
ス種別コード、製品種別コードが記憶されていることが
好ましい。ここでカード識別番号は、利用者がサービス
提供時に用いる番号であり、カード使用者を特定する番
号である。カード発行会社コードは、カードの発行会社
を識別し、サービス種別コードは、利用者が受けられる
サービスを識別するコードである。複数のカード発行会
社やサービス提供がある場合に、これらのコードで識別
される。カード発行会社コードは、サービス提供会社を
表すコードであってもよい。製品種別コードは、例えば
テレホンカードである場合には、額面金額によって区分
したコードである。

【００１４】入金に際しては、店舗２Ａに設置している
端末にカードを読み取らせる（Ｓ１）。端末がカードを
認識すると、サービス運営サーバー３に対して照会電文
を送信する（Ｓ２）。この照会電文では、額面金額、残
高、入金処理、及びキャンセル処理の許否の問い合わせ
が行われる。ここで入金処理の可否の問い合わせは、入
金可能上限額を越えないか否かを意味し、キャンセル処
理の可否の問い合わせは、入金キャンセル可能度数が残
度数としてあるか否かを意味する。なお、この入金に際
してのカード認識時に、端末ではカードの額面金額を表
示させることが好ましい。この照会電文は、サービス運
営サーバー３Ａで受信した後、認識したカードの発行会
社別に問い合わせを行う。電話会社６の発行するカード
である場合には、この照会電文は電話会社６に送信され
る（Ｓ３）。このとき電話会社に送信されるデータは、
「カード販売日時」「販売店分類コード」「販売店コー
ド」「製品種別コード」「カードシリアル番号」であ
る。ここで、「カード販売日時」は、店舗端末にて販売
した日時、「販売店分類コード」は、コンビニエンスス
トア本部コードとか、販売店をグループで捉える識別分
類コード、「販売店コード」は、コンビニエンスストア
店番号とか、販売店を個別に識別するコードである。

【００１５】この照会電文を受信した電話会社６のサー
バーでは、「カードシリアル番号有効」「カード売上想
定」「カードキャンセル想定」をチエックし、回答電文
のデータ領域を作成し、回答電文をサービス運営サーバ
ー３Ａに送信する（Ｓ４）。ここで「カードシリアル番
号有効」は、有効なカードシリアル番号か否かをチエッ
クする。「カード売上想定」は、受信したデータの販売
を想定した有効性をチエックする。具体的には、チャー
ジされるであろう度数を残高度数に加え、上限度数を越
えないか否かを判断する。「カードキャンセル想定」
は、受信したデータのキャンセルを想定した有効性をチ
エックする。具体的には、残高度数からチャージ度数を
引き、ゼロを下回らないか否かを判断する。回答電文で
は、「製品種別コード」「カードシリアル番号」「販売
価格」「チャージ度数」「現在残度数」「上限度数」及
び「取引許容コード」がデータとして含まれる。ここで
「販売価格」はカードの販売価格、「チャージ度数」は
販売価格に対応する度数、「現在残度数」は使用残度
数、「上限度数」は残高上限度数、「取引許容コード」
はチャージのみ了承か、キャンセルのみ了承か、チャー
ジ及びキャンセルすべて了承かを区分するコードであ
る。この回答電文を受信したサービス運営サーバー３Ａ
は、送信のあった店舗２Ａの端末に対して、この回答電
文を送信する（Ｓ５）。店舗２Ａの端末では、「製品種
別コード」「カードシリアル番号」「販売価格」「チャ
ージ度数」「現在残度数」「上限度数」及び「取引許容
コード」などの情報が表示され、入金（またはキャンセ
ル）が可能であれば入力が行われる。なお、入金、また
はキャンセルの入力にあたっては、カードの額面金額通
りで行う場合の他、カードの額面以下の金額でも入力を
可能とすることで、利用者の利便性は高まる。

【００１６】店舗２Ａの端末において入力が行われる
と、サービス運営サーバー３Ａでは、取引電文を受信す
る（Ｓ６）。この取引電文のデータは、「カード販売日
時」「販売店分類コード」「販売店コード」「製品種別
コード」「カードシリアル番号」「入金額（またはキャ
ンセル額）」及び「取引コード」である。ここで「取引
コード」は購入かキャンセルを区分するコードである。
サービス運営サーバー３Ａから送信されたこの取引電文
が電話会社６のサーバーで受信する（Ｓ７）と、取引は
成立する。なお、店舗２Ａにおいては、入力が行われ送
信が終了した時点で、利用者との間では取引が成立して
手続きは完了している。電話会社６のサーバーにて取引
が成立すると、電話会社６のサーバーからサービス運営
サーバー３Ａに対して受領電文が送信される（Ｓ８）。
なお、本実施例において、店舗２Ａで入力が行われ、送
信が終了した時点で利用者との間では取引が成立したも
のとし、電話会社６のサーバーから送信される受領電文
を店舗２Ａに送信した時点で取引を成立させていないの
は、サービス運営サーバー３Ａと店舗２Ａとの間の送信
の不確実性と、この送信によるタイムラグを考慮したた
めであるが、電話会社６のサーバーからサービス運営サ
ーバー３Ａに対して送信される受領電文（Ｓ８）を、店
舗２Ａに送信して利用者に確認させることがより好まし
い。また、この場合には、サービス運営サーバー３Ａか
ら店舗２Ａに対して送信される受領電文を確認した時点
をもって取引成立としてもよい。

【００１７】利用者は、電話会社６に対してカード識別
番号を送信する（Ｓ１０）ことで電話利用サービスを受
けることができる。利用者からカード識別番号が送信さ
れると、電話会社６のサーバーでは、「カードシリアル
番号」と照会し、入金データから残高照会を行う。電話
会社６のサーバーで残高が確認されると、残高の範囲内
でサービス提供が行われる。なお、必ずしも残高の範囲
内でサービスを提供する場合だけでなく、残高から所定
範囲内の限度額に限ってサービスを提供してもよい。な
お、上記実施例ではサービス提供者として電話会社を例
に説明したが、電話会社の場合には、回線利用による通
話サービスの他に、発信者番号通知サービスや転送サー
ビスの利用を受けることができる。特に転送サービスに
あっては、海外旅行者のための国際伝送サービスを利用
できることが好ましい。

【００１８】各店舗２Ａは、利用者から受け取った利用
料金を本部２Ｂに送金する。サービス運営サーバー３Ａ
は、店舗（本部２Ｂ）に対して請求情報を送信する（Ｓ
２０）。このサービス運営サーバー３Ａからの請求情報
を受信した本部２Ｂは、サービス運営口座３Ｂに入金を
行う（Ｓ２１）。この入金は、所定のタイミングで銀行
の管理口座５に振り込まれる（Ｓ２２）。一方、サービ
ス運営サーバー３Ａは、管理会社４に対して売上データ
を送信する（Ｓ２３）。管理会社４は、この売上データ
に基づいて管理口座５から支払うべき支払いデータを、
この管理口座５を管理する金融機関のサーバーに送信す
る（Ｓ２４）。金融機関は、この支払いデータに基づい
て電話会社６やサービスシステム３の運営者などに支払
いを行う（Ｓ２５）。また管理会社４は、電話会社６に
対して支払通知を送信する（Ｓ２６）。

【００１９】以下本発明の他の実施例によるサービス運
営システムについて説明する。図３は、本実施例による
サービス運営システムを説明するための概念図である。
同図に示すように、利用料金受付システム２、サービス
運営システム３、管理会社４、及び管理口座５について
は上記実施例と同様であるので一部説明を省略する。本
実施例では、利用者にサービスを提供するサービス会社
として、音楽配信サービス６Ａ、通販サービス６Ｂ、そ
の他サービス６Ｃがあり、共通のカードによって決済が
可能な場合を示している。利用者１は、各種のサービス
の提供を希望する場合に店舗２Ａにて入金手続きを行
う。この入金手続きが行われると、店舗２Ａから入金情
報がサービス運営サーバー３Ａに送信される。サービス
運営サーバー３Ａに入金情報が送信された後に、利用者
１は、音楽配信サービス６Ａ、通販サービス６Ｂ、その
他サービス６Ｃの提供を受けることができる。従って、
利用者１は、音楽配信サービス６Ａ、通販サービス６
Ｂ、その他サービス６Ｃに対してサービスの提供を求め
る場合に、サービス運営サーバー３Ａに対して決済依頼
を行い、サービス運営サーバー３Ａから決済完了通知を
受けることで各種のサービスを受けることができる。こ
れらのサービスは各種サービス会社の店舗において受け
ることができるとともに、例えばインターネットのよう
な通信回線を利用した電子決済にも利用することができ
る。

【００２０】図４は、本実施例によるサービス運営シス
テムのフロー図である。図３とともに図４を用いてデー
タとお金の流れを以下に説明する。なお上記実施例と共
通する内容については一部説明を省略する。入金に際
し、店舗２Ａに設置している端末がカードを認識する
（Ｓ３０）と、サービス運営サーバー３に対して照会電
文を送信する（Ｓ３１）。この照会電文では、上記実施
例と同様に、額面金額、残高、入金処理、及びキャンセ
ル処理の許否の問い合わせが行われる。この照会電文
は、サービス運営サーバー３Ａで受信した後、「カード
シリアル番号有効」「カード売上想定」「カードキャン
セル想定」をチエックし（Ｓ３２）、回答電文のデータ
領域を作成し、回答電文を端末に送信する（Ｓ３３）。
回答電文では、「製品種別コード」「カードシリアル番
号」「販売価格」「チャージ度数」「現在残度数」「上
限度数」及び「取引許容コード」がデータとして含まれ
る。店舗２Ａの端末では、「製品種別コード」「カード
シリアル番号」「販売価格」「チャージ度数」「現在残
度数」「上限度数」及び「取引許容コード」などの情報
が表示され、入金（またはキャンセル）が可能であれば
入力が行われる（Ｓ３４）。店舗２Ａの端末において入
力が行われると、サービス運営サーバー３Ａでは、取引
電文を受信する。この取引電文のデータも上記実施例と
同様に、「カード販売日時」「販売店分類コード」「販
売店コード」「製品種別コード」「カードシリアル番
号」「入金額（またはキャンセル額）」及び「取引コー
ド」である。サービス運営サーバー３Ａでこの取引電文
を受信すると取引は成立する（Ｓ３５）。取引が成立す
ると、サービス運営サーバー３Ａから端末に対して受領
電文が送信される（Ｓ３６）。なお、本実施例において
は、サービス運営サーバー３Ａでこの取引電文を受信す
ると利用者との間では取引が成立したものとしている
が、店舗２Ａにて受領した（Ｓ３６）受領電文を利用者
に確認させることが好ましく、この場合には、店舗２Ａ
に対して送信される受領電文を確認した時点をもって取
引成立としてもよい。

【００２１】利用者１は、サービス運営サーバー３Ａに
対して決済依頼のためにカード識別番号を送信する（Ｓ
４０）。サービス運営サーバー３Ａでは、利用者１から
カード識別番号が送信されると、カード識別番号を「カ
ードシリアル番号」と照会し、入金データから残高照会
を行う。残高が確認されると入金情報からサービス利用
に伴う利用料金が差し引かれて決済が行われ、残高の範
囲内でサービス提供が行われる。なお、必ずしも残高の
範囲内でサービスを提供する場合だけでなく、残高から
所定範囲内の限度額に限ってサービスを提供してもよ
い。なお、決済が行われた場合には、音楽配信サービス
６Ａ、通販サービス６Ｂ、その他サービス６Ｃに対して
決済完了通知が送信される（Ｓ４１）。

【００２２】

【発明の効果】本発明によれば、サービス会社への支払
いデータは、サービス運営サーバーから管理会社を経由
して銀行に送信されることで、安全で信頼性を確保する
ことができる。また、本発明によれば、決済依頼に基づ
いて決済完了情報が送信され、また決済完了情報が送信
される前に、入金情報からサービス利用に伴う利用料金
を差し引くため、利用者による複数サービスの利用が同
時期に行われた場合であっても、残金内での決済を確実
に行わせることができる。また、本発明によれば、サー
ビス運営口座への入金は、そのまま銀行の管理口座に移
されるため、サービス運営者に影響されることなく、本
サービス運営システムの安全性と信頼性を確保すること
ができる。また、本発明によれば、入金情報として、識
別番号と、入金が行われた店舗識別番号と、入金が行わ
れた日時と、入金額に関する情報と、カード種別情報と
を含むことで取引の安全性を高めることができる。

【図面の簡単な説明】

【図１】本発明の一実施例によるサービス運営システ
ムを説明するための概念図

【図２】本実施例によるサービス運営システムのフロ
ー図

【図３】本発明の他の実施例によるサービス運営シス
テムを説明するための概念図

【図４】本実施例によるサービス運営システムのフロ
ー図

【符号の説明】

１利用者２利用料金受付システム２Ａサービス運営サーバー２Ｂサービス運営口座３サービス運営システム４管理会社５管理口座６電話会社６Ａ音楽配信サービス６Ｂ通販サービス６Ｃその他サービス

───────────────────────────────────────────────────── フロントページの続き (72)発明者横井正人千葉県千葉市美浜区中瀬２−６ＷＢＧマリブイースト株式会社ビー・アイ・エス内 (72)発明者三宅智充千葉県千葉市美浜区中瀬２−６ＷＢＧマリブイースト株式会社ビー・アイ・エス内Ｆターム(参考） 3E044 AA03 BA06 DC01 DE01 5K025 AA01 BB10 EE25 KK06

Claims

【特許請求の範囲】

【請求項１】利用者が入金した入金情報を、サービス
運営サーバーにて受信する入金データ受信ステップと、
前記入金データ受信ステップで受信した入金情報を、利
用者にサービスを提供するサービス会社に対してサービ
ス運営サーバーから送信する入金データ送信ステップ
と、金融機関に対して前記サービス会社への支払いデー
タを送信する管理会社に、前記利用者の入金又は前記サ
ービス会社への支払いに関する売上データをサービス運
営サーバーから送信するステップとを有することを特徴
とするサービス運営システム。
【請求項２】利用者が入金した入金情報を、サービス
運営サーバーにて受信する入金データ受信ステップと、
サービス会社のサービス利用に関する決済依頼に対して
前記サービス運営サーバーから決済完了情報を送信する
決済データ送信ステップと、金融機関に対して前記サー
ビス会社への支払いデータを送信する管理会社に、前記
利用者の前記サービス会社への支払いに関する売上デー
タを送信するステップとを有することを特徴とするサー
ビス運営システム。
【請求項３】決済データ送信ステップ前に、前記サー
ビスに対する決済依頼データを受信する決済依頼受信ス
テップと、前記決済依頼受信ステップで受信した決済依
頼データによって当該利用者の入金情報から利用料金を
差し引くステップとを有することを特徴とする請求項２
に記載のサービス運営システム。
【請求項４】サービス運営口座に前記利用者からの入
金を受ける入金ステップと、前記入金ステップで受け付
けた入金を前記金融機関の管理口座に出金する出金ステ
ップとを有することを特徴とする請求項１から請求項３
のいずれかに記載のサービス運営システム。
【請求項５】前記入金データ受信ステップでは、前記
利用者が店舗においてプリペイドカードを用いて入金
し、前記入金データ受信ステップで受信する入金情報
を、前記プリペイドカードに付与されている識別番号
と、入金が行われた店舗識別番号と、入金が行われた日
時と、入金額に関する情報と、カード種別情報とを含む
情報としたことを特徴とする請求項１から請求項３のい
ずれかに記載のサービス運営システム。