JP2004341793A - Information processing method, program and system related to prepaid settlement system - Google Patents

Information processing method, program and system related to prepaid settlement system Download PDF

Info

Publication number
JP2004341793A
JP2004341793A JP2003137125A JP2003137125A JP2004341793A JP 2004341793 A JP2004341793 A JP 2004341793A JP 2003137125 A JP2003137125 A JP 2003137125A JP 2003137125 A JP2003137125 A JP 2003137125A JP 2004341793 A JP2004341793 A JP 2004341793A
Authority
JP
Japan
Prior art keywords
user
key
data
prepaid
page
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.)
Pending
Application number
JP2003137125A
Other languages
Japanese (ja)
Inventor
Naohiro Munechika
直広 棟近
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.)
Nifty Corp
Original Assignee
Nifty Corp
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 Nifty Corp filed Critical Nifty Corp
Priority to JP2003137125A priority Critical patent/JP2004341793A/en
Publication of JP2004341793A publication Critical patent/JP2004341793A/en
Pending legal-status Critical Current

Links

Images

Abstract

<P>PROBLEM TO BE SOLVED: To realize new service related to prepaid type settlement. <P>SOLUTION: The information processing method includes a prepaid key generation step for generating a key based on regular member ID setting rules when receiving a distribution request of a key to be used for prepaid type settlement and storing the generated key into a storage device and a member registration step for setting the key in the storage device so as to apply the key as the ID of a regular member when receiving a request for registering the regular member by using the key stored in the storage device. Consequently, the prepaid key is continuously used as the ID of the regular member, and labor for newly issuing ID for the regular member and the overlapped management of IDs are omitted. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

【０００１】
【発明が属する技術分野】
本発明は、プリペイド方式での決済に関連するサービスのための情報処理技術に関する。
【０００２】
【従来の技術】
プロバイダの会員サービスとして、特定のプロバイダの会員が、当該プロバイダの他の会員に対してプロバイダの利用料をギフトとしてオンラインで贈呈できるサービスが一般的に存在している。このようなギフト（以下、オンライン・ギフトと呼ぶ）を受け取った会員は、贈呈者である会員が指定した金額分については、無料でプロバイダを利用することができる。すなわち、贈呈者である会員が、プリペイド方式の利用権を購入し、他の会員に贈るような形態となっており、贈呈者である会員に対して利用権分の金額が課金される。また、このようなオンライン・ギフトを利用することができるユーザを、プロバイダの会員に限定しない場合もある。
【０００３】
例えば、プリペイド方式のメール・サービスを提供する技術が存在する（特許文献１参照）。すなわち、ユーザ情報を格納するユーザ情報ファイルと、アクセスしてきたユーザのメール・アカウントをユーザ情報に基づいて認証する認証サーバと、認証されたメール・アカウントに対してインターネット・メール処理を行うメール・サーバと、メール・サーバの使用に応じて該当メール・アカウントの限定使用条件をチェックするとともにこの限定使用条件から外れたメール・アカウントの使用を禁止するアカウント管理部とから構成され、ユーザからの申し込みに基づいて限定使用条件をもったインターネット・メール・アカウントを発行するプリペイド・メール・システムが存在する。
【０００４】
【特許文献１】
特開２００２−１５２２４５号公報
【０００５】
【発明が解決しようとする課題】
しかしながら以上の技術においては、オンライン・ギフト又は一時メール・アカウントを入手したユーザは、当該オンライン・ギフト又は一時メール・アカウントに設定された金額や時間を特定のプロバイダの利用権として使用することができるが、それ以外の例えばオンライン・ショッピング等に使用することはできない。そのため、ユーザにとって利用範囲が狭いものになっていた。また、オンライン・ギフト又は一時メール・アカウントを利用したユーザが、プロバイダの正会員として登録されていないが、続けてサービスを利用するために正会員として登録されることを欲する場合には、改めてＩＤの発行を受け、正会員として別途登録される必要がある。その際、プリペイド方式の利用に用いていたデータは基本的に引き継げず、新たに設定されるため、ユーザにとって管理が煩わしいものになっていた。
【０００６】
従って本発明の目的は、プリペイド形式の決済に関連する新規なサービスを実現するための技術を提供することである。
【０００７】
なお、本発明の他の目的は、入会勧誘のための新規な技術を提供することである。
【０００８】
【課題を解決するための手段】
本発明に係る情報処理方法は、プリペイド方式での決済に用いるためのキー（以下、プリペイド・キーと呼ぶ）の配布要求を受信した場合、正会員のＩＤ設定ルールに従ったキーを生成し、記憶装置に格納するプリペイド・キー生成ステップと、記憶装置に格納されたキーを用いた、正会員への登録要求を受信した場合、当該キーを正会員のＩＤとして利用可能なように記憶装置に設定する会員登録ステップとを含む。
【０００９】
これにより、プリペイド・キーをそのまま正会員のＩＤとして継続使用することができ、改めて正会員用のＩＤを発行する手間やＩＤの重複管理を省くことができる。
【００１０】
また、上で述べたプリペイド・キー生成ステップが、キーを特定のユーザに関連付けるステップを含むようにしてもよい。これにより、プリペイド・キーを利用するユーザを指定することができ、プリペイド・キーを例えばオンライン・ギフトとして特定のユーザに贈呈することが可能となる。例えば、プリペイド・キーと当該プリペイド・キーを利用するユーザのメール・アドレスとを含むレコードを記憶装置に格納しておく。
【００１１】
また、上記特定のユーザは、正会員として未登録のユーザであるものとしてもよい。これにより、プロバイダの正会員として未登録のユーザが、続けてサービスを利用するために正会員として登録されることを欲する場合には、改めてＩＤの発行を受けることなく、正会員として登録される。すなわち、ユーザはプリペイド・キーを正会員のユーザＩＤとしてそのまま利用できるようになる。
【００１２】
また、上で述べた会員登録ステップが、記憶装置に設定される、特定のユーザのステータスを表すデータを、正会員を表すデータに変更し、記憶装置に設定するステップを含むようにしてもよい。このように、ユーザのステータスを変更して正会員への移行処理を行うことにより、ＩＤの新規発行を不要とするスムーズな正会員登録が実現できる。また、システム側の管理が容易になる。
【００１３】
また、キーに対応付けられている金額を超える決済要求を受信した場合、当該決済要求を行ったユーザに正会員登録を促すステップをさらに含むようにしてもよい。ここで、キーに対応付けられている金額とは、当該キーを利用することによりプリペイド方式での決済が可能となるプリペイド残高を指し、ユーザが決済を行うことにより、決済金額分だけ少なくなっていくものである。そして、上で述べたように不足が発生した際に正会員登録を促すことにより、効果的なタイミングで入会の勧誘を行うことができる。
【００１４】
また、決済要求における決済金額とキーに対応付けられている金額との差額を、正会員として登録されたユーザへの課金データとして課金データ格納部に格納するステップをさらに含むようにしてもよい。これにより、ユーザは、正会員になることによってプリペイド残高の不足分を正会員に提供される手段で決済することができるようになる。例えば、足りない分をクレジット・カード等で決済するものである。
【００１５】
また、上で述べたプリペイド・キー生成ステップが、キーに特定のパスワードを関連付けるステップを含むようにしてもよい。これにより、プリペイド・キーを利用するユーザを、特定のパスワードを知るユーザに限定することができる。例えば、プリペイド・キーと当該プリペイド・キーを利用するユーザが設定したパスワードとを含むレコードを記憶装置に格納しておく。
【００１６】
また、上で述べた会員登録ステップにおいて、上記特定のパスワードを、正会員のＩＤに対応するパスワードとして設定するようにしてもよい。これにより、ユーザは、正会員になったとしても、それまでに使い慣れたパスワードをそのまま利用し続けることができる。
【００１７】
また、あるユーザから、プリペイド方式での決済に利用できる金額の指定と当該金額をプリペイド方式の決済に用いるためのキーを特定のユーザに配布する指示とを受け付けた場合、上記特定のユーザによるキーの使用開始が確認された時点において、あるユーザにより指定され且つキーに対応付けられている金額を、あるユーザへの課金データとして課金データ格納部に格納するステップをさらに含むようにしてもよい。
【００１８】
これにより、他のユーザにプリペイド・キーを贈呈したユーザには、自己の指定した贈呈金額が、贈呈されたユーザのプリペイド・キーの使用開始が確認された際に、課金される。従って、プリペイド・キーを贈呈しようとしても、贈呈されるユーザがプリペイド・キーの使用を拒否した場合等には課金が発生せず、ユーザにとって無駄な出費を抑えることができる。
【００１９】
なお、本発明に係る情報処理方法をコンピュータに実行させるプログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してデジタル信号として頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリに一時保管される。
【００２０】
【発明の実施の形態】
本発明の一実施の形態に係るシステム構成図を図１に示す。例えばインターネットであるネットワーク１には、管理サーバ５と、例えばパーソナル・コンピュータである１又は複数のユーザ端末３及びユーザ端末７とが、無線又は有線によって接続されている。ユーザ端末３及びユーザ端末７は、図示していないウェブ（Ｗｅｂ）ブラウザ機能とメーラ機能とを有し、Ｗｅｂページの閲覧とメールの送受信及び閲覧とを可能とさせている。なお、ユーザ端末３及びユーザ端末７は、Ｗｅｂブラウザ機能及びメーラ機能を有する携帯電話機やその他の携帯情報端末等であってもよい。
【００２１】
また、管理サーバ５には、Ｗｅｂページ管理部５００とＩＤ管理部５０２とメール処理部５０４と決済処理部５０６とが含まれている。これらの処理内容については処理フローの説明において述べるが、管理サーバ５は、この他に図示していないＷｅｂサーバ機能を有しており、Ｗｅｂページ・データの生成・送信処理を行えるようになっている。さらに、管理サーバ５は、Ｗｅｂページ・データ格納部５１０とユーザ管理ＤＢ５１２とプリペイド決済ＤＢ５１４と課金ＤＢ５１６と商品ＤＢ５１８とを管理している。Ｗｅｂページ・データ格納部５１０には、後に例示するＷｅｂページのデータや、管理サーバ５が提供するその他のＷｅｂページのデータが格納されている。
【００２２】
図２に、ユーザ管理ＤＢ５１２のテーブル構成及び格納されるデータの一例を示す。図２の例には、ＩＤの列２００とパスワードの列２０２とプリペイド会員フラグの列２０４と正会員フラグの列２０６とメール・アドレスの列２０８とプリペイド残高の列２１０と氏名の列２１２とクレジット・カード番号の列２１４とＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）の列２１６とが含まれている。この他、図示していないが、登録日時の列やユーザの住所の列等、ユーザ管理に必要なデータを格納するための列が含まれている。
【００２３】
このユーザ管理ＤＢ５１２のテーブルには、プリペイド・キーを利用する非会員ユーザ（以下、プリペイド会員と呼ぶ）と、会員として登録済みのユーザ（以下、正会員と呼ぶ）とに関するレコードが登録されている。なお、プリペイド会員については、プリペイド・キーを、そのままユーザＩＤとして扱うような仕組みになっている。
【００２４】
ＩＤの列２００には、プリペイド・キー、すなわちプリペイド会員のユーザＩＤと、正会員のユーザＩＤとが格納される。すなわち、プリペイド・キーと正会員のユーザＩＤとは同様のネーミング・ルールで生成され、区別なく管理される。但し、ＩＤのストリング構成により、プリペイド会員又はプリペイド会員経由で正会員になったことが分かるようにしてもよい。
【００２５】
そして、ユーザがプリペイド会員である場合、プリペイド会員フラグの列２０４に「０」又は「１」と設定され、ユーザが正会員である場合、正会員フラグの列２０６に「１」と設定される。なお、プリペイド・キーの利用にあたっては、使用開始登録が必要であり、プリペイド会員のうち、ユーザＩＤの発行、プリペイド・キーの贈呈がなされており、且つ未だ使用開始登録をしていないユーザについては、プリペイド会員フラグの列２０４に「０」と設定される。一方、プリペイド会員のうち、プリペイド・キーの使用開始登録を行ったユーザについては、プリペイド会員フラグの列２０４に「１」と設定される。
【００２６】
プリペイド残高の列２１０には、プリペイド方式での決済が可能な金額が格納される。この金額は、プリペイド・キーの生成時に設定された金額を初期値として、プリペイド方式での決済がなされることにより少なくなっていく。決済金額によっては、１回の決済で「０」になることもある。また、氏名の列２１２とクレジット・カード番号の列２１４とには、ユーザが正会員である場合に、値が格納される。
【００２７】
また、ＵＲＬの列２１６には、ユーザ固有のＵＲＬデータが格納される。例えばユーザがプリペイド会員であり、ユーザＩＤの発行、プリペイド・キーの贈呈がなされており、且つ未だ使用開始登録をしていない場合には、使用開始登録用のＷｅｂページのＵＲＬデータが格納される。なお、本実施の形態においては、使用開始登録には仮受領確認と本受領確認との２つのステップが存在し、使用開始登録がどこまで進んでいるかによってＵＲＬが異なるため、仮受領確認ＵＲＬと本受領確認ＵＲＬとの共通のパスが格納されるようになっている。例えば、「ｈｔｔｐ：／／ｗｗｗ．＊＊＊＊．ｃｏｍ／ｐｒｅｐａｉｄ／￣ＧＩＦ１２３４５／」というデータが格納される。これに、例えば「ｋａｒｉｊｕｒｙｏ．ｈｔｍｌ」や「ｈｏｎｊｕｒｙｏ．ｈｔｍｌ」というデータを追加することにより、ユーザ固有のＵＲＬを生成するようになっている。
【００２８】
図３に、プリペイド決済ＤＢ５１４のテーブル構成及び格納されるデータの一例を示す。図３の例には、決済番号の列３００と贈呈者ＩＤの列３０２と受領者ＩＤの列３０４と商品ＩＤの列３０６と購入金額の列３０８と課金フラグの列３１０とが含まれている。この他、図示していないが、決済日時の列等、プリペイド・キーの購入や贈呈に関するデータを格納するための列が含まれている。
【００２９】
このプリペイド決済ＤＢ５１４には、プリペイド・キーの贈呈処理が行われた際にレコードが登録される。図３の例では、１行目のレコードより、「ＡＡＡ０００００」というユーザＩＤを持つユーザが、特定のユーザに対して例えば５００円分のプリペイド・キーの贈呈処理がなされたことが分かる。１行目のレコードの受領者ＩＤの列３０４には「ＧＩＦ１２３４５」という値が格納されているが、この値はプリペイド・キーそのものでもあり、贈呈先となるプリペイド会員のユーザＩＤでもある。
【００３０】
課金フラグの列３１０には、贈呈者ＩＤの列３０２に示されるユーザに課金がなされた場合に「１」が設定される。この課金フラグの列３１０には、受領者ＩＤの列３０４に示されるユーザによってプリペイド・キーの使用開始登録がなされるまでは、初期値の「０」が設定されており、ユーザに課金されないようになっている。
【００３１】
図４に、課金ＤＢ５１６のテーブル構成及び格納されるデータの一例を示す。図４の例には、課金番号の列４００と購入者ＩＤの列４０２と購入商品ＩＤの列４０４と購入金額の列４０６と支払方法の列４０８とが含まれている。この他、図示していないが、購入日時の列等、商品の購入に関するデータを格納するための列が含まれている。
【００３２】
この課金ＤＢ５１６には、ユーザがオンラインで商品を購入した場合にレコードが登録される。図４の例では、３行目のレコードと４行目のレコードとでは、課金番号の列４００の値、購入者ＩＤ４０２の値及び購入商品ＩＤ４０４の値が同じになっているが、これは、例えば３００円の商品をプリペイド方式で１００円分決済し、残りの２００円分を例えばクレジット・カード等、会員が通常行う決済方法で決済するような場合におけるレコードであるためである。課金番号を別々に設定するようにしてもよい。
【００３３】
図５に、商品ＤＢ５１８のテーブル構成及び格納されるデータの一例を示す。図５の例には、商品ＩＤの列５５０と商品属性の列５５２と商品名の列５５４と単価の列５５６とが含まれている。この他、図示していないが、メーカ・コード等、商品に関するデータを格納するための列が含まれている。この商品ＤＢ５１８には、ユーザがオンラインで購入可能な商品に関するレコードが登録されている。
【００３４】
次に、図６乃至図２７を用いて図１に示したシステムの処理内容について説明する。図６には、ユーザが例えばユーザ端末３を操作して管理サーバ５にアクセスし、プリペイド・キーの贈呈を行う際の処理フローが示されている。以下、各処理ステップに基づき説明していく。なお、これより前にログイン処理が行われているものとする。
【００３５】
まず、ユーザ端末３は、ユーザの操作に従い、オンライン・ギフト購入ページのデータの要求を管理サーバ５に対して送信する（図６：ステップＳ１）。本実施の形態においては、ユーザ端末３が有するＷｅｂブラウザを介してサーバにアクセスすることを想定しているが、専用のクライアント・ソフトウェアを使用する場合もある。
【００３６】
図７に、メニュー・ページの一例を示す。図７の例には、会員入会ページへのリンク部７００とギフト券購入ページへのリンク部７１０とが含まれている。会員入会ページへのリンク部７００がクリックされると会員入会ページへの移行がなされ、ギフト券購入ページへのリンク部７１０がクリックされるとギフト券購入ページへの移行がなされる。ここで、「（オンライン）ギフト券」とは、プリペイド・キーを指しているが、各Ｗｅｂページにおいては、ユーザがイメージしやすいように仮想的な「（オンライン）ギフト券」という表現を用いている。
【００３７】
図６の処理フローに戻り、管理サーバ５のＷｅｂページ管理部５００は、オンライン・ギフト券購入ページのデータの要求をユーザ端末３から受信する（図６：ステップＳ３）。そして、Ｗｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いてオンライン・ギフト券購入ページのデータを生成し、ユーザ端末３に対して送信する（ステップＳ５）。ユーザ端末３は、オンライン・ギフト券購入ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ７）。
【００３８】
図８に、オンライン・ギフト券購入ページの一例を示す。図８の例には、受取人のメール・アドレス入力欄８００と金額設定用プルダウン・リスト８１０とコメント入力欄８２０と送信ボタン８３０とが含まれている。ユーザは、このオンライン・ギフト券購入ページに対して必要なデータを入力し、送信ボタン８３０をクリックする。
【００３９】
図６の処理フローに戻り、ユーザ端末３は、オンライン・ギフト券購入ページ（図８）に対するユーザからの入力を受け付け、受け付けたデータを管理サーバ５に対して送信する（図６：ステップＳ９）。管理サーバ５のＷｅｂページ管理部５００は、オンライン・ギフト券購入ページ（図８）に対するユーザからの入力データをユーザ端末３から受信し、一旦記憶装置に格納する（ステップＳ１１）。
【００４０】
そして、Ｗｅｂページ管理部５００は、入力内容確認ページのデータを生成し、ユーザ端末３に対して送信する（ステップＳ１３）。なお、入力内容をチェックし、エラーがあった場合には、エラー・メッセージを返すようにしてもよい。ユーザ端末３は、入力内容確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ１５）。
【００４１】
図９に、入力内容確認ページの一例を示す。図９の例には、受取人のメール・アドレス表示欄９００と金額表示欄９１０とコメント表示欄９２０と確認ボタン９３０とが含まれている。ユーザは、この入力内容確認ページに示されているデータに間違いがないか確認し、確認ボタン９３０をクリックする。各表示欄に対してユーザが修正入力可能なようにしてもよいし、図示しないキャンセル・ボタン等が含まれていてもよい。
【００４２】
図６の処理フローに戻り、ユーザ端末３は、入力内容確認ページ（図９）に対するユーザからの選択入力を受け付け、選択入力データを管理サーバ５に対して送信する（図６：ステップＳ１７）。管理サーバ５のＷｅｂページ管理部５００は、選択入力データをユーザ端末３から受信し、一旦記憶装置に格納する（ステップＳ１９）。
【００４３】
そして、Ｗｅｂページ管理部５００は、オンライン・ギフト券の購入処理を行ってもよい（ＯＫ）かどうか判定する（ステップＳ２１）。例えば、入力内容確認ページ（図９）において図示しないキャンセル・ボタンがクリックされた場合や、ユーザの入力内容をチェックしてエラーが発見された場合等には、オンライン・ギフト券の購入処理を行ってはいけない（ＯＫではない）と判断する。
【００４４】
ＯＫではないと判定された場合（ステップＳ２１：Ｎｏルート）、ステップＳ５の処理に戻る。一方、ＯＫであると判定された場合（ステップＳ２１：Ｙｅｓルート）、管理サーバ５のＩＤ管理部５０２は、プリペイド会員データを生成し、ユーザ管理ＤＢ５１２に格納する（ステップＳ２３）。すなわち、ユーザ管理ＤＢ５１２に新規のレコードが１件登録される。なお、登録されるレコードのプリペイド会員フラグの列２０４（図２）には「０」が格納される。また、ＵＲＬの列２１６に、上で述べたようなユーザ固有のＵＲＬデータ（パス）が格納される。なお、この時点では、登録されるレコードのパスワードの列２０２（図２）と正会員フラグの列２０６（図２）と氏名の列２１２（図２）とクレジット・カード番号の列２１４（図２）とには、値が格納されない。
【００４５】
そして、管理サーバ５の決済処理部５０６は、贈呈者ＩＤと受領者ＩＤと商品ＩＤと購入金額とを含むプリペイド決済データを生成し、プリペイド決済ＤＢ５１４に格納する（ステップＳ２５）。すなわち、プリペイド決済ＤＢ５１４に贈呈者ＩＤと受領者ＩＤと商品ＩＤと購入金額とを含む新規のレコードが１件登録される。なお、登録されるレコードの課金フラグの列３１０（図３）には「０」が格納される。
【００４６】
そして、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて処理完了確認ページのデータを生成し、ユーザ端末３に対して送信する（ステップＳ２７）。ユーザ端末３は処理完了確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ２９）。図示しないが、処理完了確認ページには、例えば「オンライン・ギフト券の購入を受け付けました。」等のメッセージが含まれる。
【００４７】
このようにして、オンライン・ギフト券の購入が受け付けられ、プリペイド・キーが生成される。ステップＳ２７の処理が終わると、処理は端子Ａを介して図１０の処理に移行する。
【００４８】
図１０には、プリペイド・キーの贈呈先であるユーザが、例えばユーザ端末７を操作して管理サーバ５にアクセスし、プリペイド・キーを仮受領する際の処理フローが示されている。以下、各処理ステップに基づき説明していく。
【００４９】
まず、管理サーバ５のメール処理部５０４は、Ｗｅｂページ・データ格納部５１０に格納されているデータとユーザ管理ＤＢ５１２に格納されているデータとを用いてギフト・メールのデータを生成し、プリペイド・キーの贈呈先であるユーザ宛てに送信する（ステップＳ４１）。ユーザ端末７は、ユーザの操作に従い、図示しないメール・サーバを介して管理サーバ５からのギフト・メールのデータを受信し、表示装置に表示する（ステップＳ４３）。
【００５０】
図１１に、ギフト・メールの表示画面の一例を示す。図１１の例には、贈呈元ユーザ表示部１１００とメッセージ表示部１１１０と仮受領確認用ＵＲＬ表示部１１２０とが含まれている。贈呈元ユーザ表示部１１００には、贈呈元であるユーザの氏名（ユーザ管理ＤＢ５１２の氏名の列２１２（図２）の値）が含まれており、誰からの贈呈か分かるようになっている。メッセージ表示部１１１０には、オンライン・ギフト券購入ページ（図８）においてコメント入力欄８２０に入力されたデータが示される。仮受領確認用ＵＲＬ表示部１１２０には、仮受領確認ページのＵＲＬが示されているが、メーラの機能及びその設定によっては、ＵＲＬがハイパー・リンクになっている場合もある。
【００５１】
図１０の処理フローに戻り、ユーザ端末７は、例えば仮受領確認用ＵＲＬ表示部１１２０（図１１）に示されているＵＲＬに基づきＷｅｂページにアクセスするというユーザの指示に従い、仮受領確認ページ・データの要求を管理サーバ５に対して送信する（図１０：ステップＳ４５）。管理サーバ５のＷｅｂページ管理部５００は、仮受領確認ページ・データの要求をユーザ端末７から受信する（ステップＳ４７）。そして、Ｗｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータとユーザ管理ＤＢ５１２に格納されているデータとプリペイド決済ＤＢ５１４に格納されているデータとを用いて仮受領確認ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ４９）。ユーザ端末７は、仮受領確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ５１）。
【００５２】
図１２に、仮受領確認ページの一例を示す。図１２の例には、差出人メール・アドレス表示部１２００と受領人メール・アドレス表示部１２１０と金額表示部１２２０と受領ボタン１２３０と受領拒否ボタン１２４０とが含まれている。差出人メール・アドレス表示部１２００には、贈呈元であるユーザのメール・アドレスが示されているが、図１１に示した贈呈元ユーザ表示部１１００と同様に、ユーザの氏名を示すようにしてもよい。
【００５３】
図１０の処理フローに戻り、ユーザ端末７は、ユーザからの仮受領確認ページ（図１２）に対する選択入力を受け付け、管理サーバ５に対して送信する（図１０：ステップＳ５３）。管理サーバ５のＷｅｂページ管理部５００は、選択入力データをユーザ端末７から受信し、一旦記憶装置に格納する（ステップＳ５５）。
【００５４】
そして、Ｗｅｂページ管理部５００は、ユーザからの選択入力が「受領」であったかどうか判定する（ステップＳ５７）。仮受領確認ページ（図１２）において、ユーザによって受領ボタン１２３０がクリックされた場合には「受領」と判定し、受領拒否ボタン１２４０がクリックされた場合には「受領」ではないと判定する。
【００５５】
「受領」ではないと判定された場合（ステップＳ５７：Ｎｏルート）、管理サーバ５のメール処理部５０４は、ユーザ管理ＤＢ５１２に格納されているデータを用いて受領拒否通知メールのデータを生成し、贈呈者（贈呈元のユーザ）宛てに送信する（ステップＳ５９）。受領拒否通知メールには、図示しないが、オンライン・ギフト券を受け取ってもらえなかった旨のメッセージが含まれる。なお、この場合、プリペイド・キーの贈呈に関する一連の処理は終了する。ユーザ管理ＤＢ５１２から該当するレコードを削除してもよい。
【００５６】
一方、「受領」であったと判定された場合（ステップＳ５７：Ｙｅｓルート）、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いてパスワード入力ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ６１）。ユーザ端末７は、パスワード入力ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ６３）。
【００５７】
図１３に、パスワード入力ページの一例を示す。図１３の例には、パスワード入力欄１３００と確定ボタン１３１０とが含まれている。ユーザは、パスワード入力欄１３００にパスワードを入力し、確定ボタン１３１０をクリックする。なお、パスワード入力欄１３００は、ユーザからの入力文字をそのまま表示せず、アスタリスクで示すようになっている。そこで、入力ミスをチェックするために、パスワード入力欄が複数設けられる場合もある。
【００５８】
図１０の処理フローに戻り、ユーザ端末７は、ユーザからのパスワード入力ページ（図１３）に対するパスワードの入力を受け付け、管理サーバ５に対して送信する（図１０：ステップＳ６５）。管理サーバ５のＩＤ管理部５０２は、パスワードをユーザ端末７から受信し、ユーザ管理ＤＢ５１２のパスワードの列２０２（図２）に格納する（ステップＳ６７）。なお、該当するレコードは、例えばメール・アドレスの列２０８（図２）の値に基づき特定する。
【００５９】
そして、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータとユーザ管理ＤＢ５１２に格納されているデータとを用いて仮受領完了ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ６９）。ユーザ端末７は、仮受領完了ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ７１）。
【００６０】
図１４に、仮受領完了ページの一例を示す。図１４の例には、プリペイド・キー表示部１４００とＯＫボタン１４１０とが含まれている。ユーザは、プリペイド・キー表示部１４００に示された自分のＩＤを確認し、ＯＫボタン１４１０をクリックする。
【００６１】
このようにして、プリペイド・キーの仮受領処理が行われる。ステップＳ６９の処理が終わると、処理は端子Ｂを介して図１５の処理に移行する。
【００６２】
図１５には、プリペイド・キーの贈呈先であり且つプリペイド・キーの仮受領を既に行ったユーザが、例えばユーザ端末７を操作して管理サーバ５にアクセスし、プリペイド・キーを本受領する際の処理フローが示されている。以下、各処理ステップに基づき説明していく。
【００６３】
まず、管理サーバ５のメール処理部５０４は、Ｗｅｂページ・データ格納部５１０に格納されているデータとユーザ管理ＤＢ５１２に格納されているデータとを用いて本受領メールのデータを生成し、プリペイド・キーの贈呈先であるユーザ宛てに送信する（ステップＳ８１）。ユーザ端末７は、ユーザの操作に従い、図示しないメール・サーバを介して管理サーバ５からの本受領メールのデータを受信し、表示装置に表示する（ステップＳ８３）。
【００６４】
図１６に、本受領メールの表示画面の一例を示す。図１６の例には、本受領確認用ＵＲＬ表示部１６００が含まれている。本受領確認用ＵＲＬ表示部１６００には、本受領確認ページのＵＲＬが示されているが、メーラの機能及びその設定によっては、ＵＲＬがハイパー・リンクになっている場合もある。
【００６５】
図１５の処理フローに戻り、ユーザ端末７は、例えば本受領確認用ＵＲＬ表示部１６００（図１６）に示されているＵＲＬに基づきＷｅｂページにアクセスするというユーザの指示に従い、本受領確認ページ・データの要求を管理サーバ５に対して送信する（図１５：ステップＳ８５）。管理サーバ５のＷｅｂページ管理部５００は、本受領確認ページ・データの要求をユーザ端末７から受信する（ステップＳ８７）。そして、Ｗｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータとユーザ管理ＤＢ５１２に格納されているデータとプリペイド決済ＤＢ５１４に格納されているデータとを用いて本受領確認ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ８９）。ユーザ端末７は、本受領確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ９１）。
【００６６】
図１７に、本受領確認ページの一例を示す。図１７の例には、差出人メール・アドレス表示部１７００と受領人メール・アドレス表示部１７１０と金額表示部１７２０と「受領する」ボタン１７３０とが含まれている。差出人メール・アドレス表示部１７００には、贈呈元であるユーザのメール・アドレスが示されているが、ユーザの氏名を示すようにしてもよい。ユーザは、各表示部の内容を確認し、「受領する」ボタン１７３０をクリックする。
【００６７】
図１５の処理フローに戻り、ユーザ端末７は、ユーザからの本受領確認ページ（図１７）に対する選択入力を受け付け、管理サーバ５に対して送信する（図１５：ステップＳ９３）。管理サーバ５のＷｅｂページ管理部５００は、選択入力データをユーザ端末７から受信し、一旦記憶装置に格納する（ステップＳ９５）。なお、ここでのユーザからの選択入力は「受領する」である。
【００６８】
そして、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて認証データ入力ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ９７）。ユーザ端末７は、認証データ入力ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ９９）。
【００６９】
図１８に、認証データ入力ページの一例を示す。図１８の例には、ＩＤ入力欄１８００とパスワード入力欄１８１０と確定ボタン１８２０とが含まれている。ユーザは、仮受領完了ページ（図１４）において確認したプリペイド・キーをＩＤ入力欄１８００に入力し、パスワード入力ページ（図１３）において設定したパスワードをパスワード入力欄１８１０に入力し、確定ボタン１８２０をクリックする。
【００７０】
図１５の処理フローに戻り、ユーザ端末７は、ユーザからの認証データ入力ページ（図１８）に対するＩＤ（プリペイド・キー）及びパスワードの入力を受け付け、管理サーバ５に対して送信する（図１５：ステップＳ１０１）。管理サーバ５のＷｅｂページ管理部５００は、ＩＤ及びパスワードをユーザ端末７から受信し、一旦記憶装置に格納する（ステップＳ１０３）。その際、管理サーバ５のＩＤ管理部５０２は、ＩＤ及びパスワードが正しく入力されたか、ユーザ管理ＤＢ５１２に格納されているデータを用いてチェックする。正しく入力されていればそのまま処理を続行するが、正しく入力されていなければエラーを返し、例えばユーザに再入力を促す。
【００７１】
そして、ＩＤ管理部５０２は、ユーザ管理ＤＢ５１２のプリペイド会員フラグ２０４（図２）の値を「０」から「１」に更新する（ステップＳ１０５）。さらに、管理サーバ５の決済処理部５０６は、プリペイド決済ＤＢ５１４の該当するレコードの課金フラグの列３１０（図３）の値を「０」から「１」に更新し、当該レコードのデータを用いて課金データを生成し、課金データＤＢ５１６に格納する（ステップＳ１０７）。すなわち、プリペイド・キーの贈呈先ユーザをプリペイド会員として本登録し、それに伴い、プリペイド・キーの贈呈元ユーザに課金する処理が行われる。
【００７２】
そして、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて本受領完了ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ１０９）。ユーザ端末７は、本受領完了ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ１１１）。
【００７３】
図１９に、本受領完了ページの一例を示す。図１９の例には、メッセージ入力欄１９００とバリュー移行用ハイパー・リンク１９１０とＯＫボタン１９２０とが含まれている。バリュー移行用ハイパー・リンク１９１０がクリックされると、ユーザが受領したプリペイド・キーのバリュー（残高）を、当該プリペイド・キーとは異なる既存のＩＤに移すためのページに移行する。なお、バリューの移行処理は銀行振替のような処理であり、本発明の要旨ではないため説明を割愛する。例えばユーザは、メッセージ入力欄１９００にメッセージを入力し、ＯＫボタン１９２０をクリックする。
【００７４】
図１５の処理フローに戻り、ユーザ端末７は、ユーザからの本受領完了ページ（図１９）に対する選択入力を受け付け、管理サーバ５に対して送信する（図１５：ステップＳ１１３）。管理サーバ５のＷｅｂページ管理部５００は、選択入力データをユーザ端末７から受信し、一旦記憶装置に格納する（ステップＳ１１５）。なお、ここでのユーザからの選択入力は「ＯＫ」とする。
【００７５】
そして、管理サーバ５のメール処理部５０４は、受領通知メールのデータを生成し、贈呈者（贈呈元のユーザ）宛てに送信する（ステップＳ１１７）。受領通知メールには、図示しないが、オンライン・ギフト券の受け取りがなされた旨のメッセージと本受領完了ページのメッセージ入力欄１９００（図１９）に入力されたメッセージとが含まれる。また、課金に関するデータ（金額や支払日等）が含まれる場合もある。
【００７６】
このようにして、プリペイド・キーの本受領処理が行われる。そして、本受領処理を行いプリペイド会員となったユーザは、受領したプリペイド・キーを用いて商品の購入や有償コンテンツの閲覧等を行うことが可能となる。
【００７７】
図２０には、プロバイダの会員（プリペイド会員を含む）であるユーザが例えばユーザ端末７を操作して管理サーバ５にアクセスし、オンライン・ショッピングを行う際の処理フローが示されている。本実施の形態においては、ユーザ端末７が有するＷｅｂブラウザを介してサーバにアクセスすることを想定しているが、専用のクライアント・ソフトウェアを使用する場合もある。以下、各処理ステップに基づき説明していく。
【００７８】
まず、ユーザ端末７は、表示しているＷｅｂページに対するユーザからの商品購入指示を受け付け、指示データを管理サーバ５に対して送信する（図２０：ステップＳ２０１）。
【００７９】
例えば、図２１に示すようなショッピング・ページに対するユーザからの商品購入指示を受け付ける。図２１の例には、商品データ表示部２０００と「購入する」ボタン２１００とが含まれている。「購入する」ボタン２１００がクリックされることにより、Ａ商品の購入指示を受け付ける。なお、図２１では簡略化した例を示しているが、一般的なオンライン・ショッピングにおける「買い物かご」や「ショッピング・カート」等、複数の購入候補商品についての会計内容を表示し、購入指示を受け付けるようなページであってもよい。
【００８０】
図２０の処理フローに戻り、管理サーバ５のＷｅｂページ管理部５００は、購入指示データをユーザ端末７から受信し、一旦記憶装置に格納する（図２０：ステップＳ２０３）。なお、購入指示データには、商品名、単価、数量、合計金額等の会計データが含まれているものとする。
【００８１】
そして、Ｗｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて購入ユーザ確認ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ２０５）。ユーザ端末７は、購入ユーザ確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ２０７）。
【００８２】
図２２に、購入ユーザ確認ページの一例を示す。図２２の例には、会計データ表示部２２００とＩＤ入力欄２２１０とパスワード入力欄２２２０と確定ボタン２２３０とが含まれている。ユーザは、この購入ユーザ確認ページに対して認証データを入力し、確定ボタン２２３０をクリックする。例えば複数のＩＤを保有しているユーザは、課金するＩＤを入力する。なお、ユーザが既にログイン済みである場合には、ログインしているユーザのＩＤを予めＩＤ入力欄２２１０に埋め込んでおくようにしてもよい。
【００８３】
図２０の処理フローに戻り、ユーザ端末７は、購入ユーザ確認ページ（図２２）に対するユーザからの認証データの入力を受け付け、購入データを管理サーバ５に対して送信する（図２０：ステップＳ２０９）。なお、購入データには、商品の会計データとユーザの認証データとが含まれているものとする。
【００８４】
管理サーバ５のＷｅｂページ管理部５００は、購入データをユーザ端末７から受信し、一旦記憶装置に格納する（ステップＳ２１１）。その際、管理サーバ５のＩＤ管理部５０２は、ＩＤ及びパスワードが正しく入力されたか、ユーザ管理ＤＢ５１２に格納されているデータを用いてチェックする。また、ＩＤ管理部５０２は、購入データに含まれるＩＤが課金可能なＩＤであるかチェックし、課金不可能なＩＤであればエラーを返す。具体的には、ユーザ管理ＤＢ５１２の該当するレコードの、プリペイド会員フラグの列２０４（図２）の値が「１」である又は正会員フラグの列２０６（図２）の値が「１」である場合には、課金可能である。
【００８５】
さらに、ＩＤ管理部５０２は、ユーザ管理ＤＢ５１２に格納されているデータを用いて、商品を購入するユーザ（課金されるＩＤ）がプリペイド会員であるかどうか判定する（ステップＳ２１３）。ユーザ管理ＤＢ５１２の該当するレコードのプリペイド会員フラグの列２０４（図２）の値が「１」であれば、プリペイド会員であると判定する。
【００８６】
プリペイド会員ではないと判定された場合（ステップＳ２１３：Ｎｏルート）、後に述べるステップＳ２１９の処理に移行する。
【００８７】
一方、プリペイド会員であると判定された場合（ステップＳ２１３：Ｙｅｓルート）、管理サーバ５の決済処理部５０６は、購入データとユーザ管理ＤＢ５１２に格納されているデータとを用いて、プリペイド残高が不足しているかどうか判定する（ステップＳ２１５）。具体的には、ユーザ管理ＤＢ５１２の該当するレコードのプリペイド残高の列２１０（図２）の値が、購入データに含まれる会計金額より少ない場合には、残高不足であると判定する。
【００８８】
残高不足であると判定された場合（ステップＳ２１５：Ｙｅｓルート）、処理は端子Ｃを介して図２３の処理に移行する。一方、残高不足ではないと判定された場合（ステップＳ２１５：Ｎｏルート）、管理サーバ５の決済処理部５０６は、ユーザ管理ＤＢ５１２の該当するレコードのプリペイド残高の列２１０（図２）の値を更新する（ステップＳ２１７）。すなわち、会計金額分だけ残高を減らす。そして、管理サーバ５の決済管理部５０６は、購入データを用いて課金データを生成し、課金ＤＢ５１６に格納する（ステップＳ２１９）。なお、プリペイド方式での課金データは、決済が既に済んでいるため、課金ＤＢ５１６に格納しないようにしてもよい。
【００８９】
そして、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて決済確認ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ２２１）。ユーザ端末７は、決済確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ２２３）。図示しないが、決済確認ページには、商品の購入（注文）処理が完了したことを通知するメッセージが含まれる。
【００９０】
このようにして、プリペイド会員を含むプロバイダの会員ユーザによるオンライン・ショッピングにおける処理が行われる。
【００９１】
図２３には、ステップＳ２１５（図２０）において残高不足であると判定された場合（ステップＳ２１５：Ｙｅｓルート）の処理フローが示されている。まず、管理サーバ５の決済処理部５０６は、プリペイド残高の不足分の金額を例えばワーク・メモリ領域等の記憶装置に一時格納する（ステップＳ２３１）。そして、管理サーバ５のＷｅｂページ管理部５００は、プリペイド残高データとＷｅｂページ・データ格納部５１０に格納されているデータとを用いて残高不足通知ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ２３３）。ユーザ端末７は、残高不足通知ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ２３５）。
【００９２】
図２４に、残高不足通知ページの一例を示す。図２４の例には、メッセージ表示部２４００と「入会手続きへ」ボタン２４１０とキャンセル・ボタン２４２０とが含まれている。ユーザは、メッセージ表示部２４００に示されているメッセージを確認し、直ちに入会手続きを実施することを希望する場合には、「入会手続きへ」ボタン２４１０をクリックする。
【００９３】
図２３の処理フローに戻り、ユーザ端末７は、残高不足通知ページ（図２４）に対するユーザからの選択入力を受け付け、管理サーバ５に対して送信する（図２３：ステップＳ２３７）。管理サーバ５のＷｅｂページ管理部５００は、選択入力データをユーザ端末７から受信し、一旦記憶装置に格納する（ステップＳ２３９）。
【００９４】
そして、Ｗｅｂページ管理部５００は、残高不足通知ページ（図２４）に対するユーザからの選択入力が「入会」であったかどうか判定する（ステップＳ２４１）。例えば「入会手続きへ」ボタン２４１０（図２４）がクリックされた場合には「入会」であったと判定し、キャンセル・ボタン２４２０（図２４）がクリックされた場合には「入会」ではなかったと判定する。
【００９５】
「入会」であったと判定された場合（ステップＳ２４１：Ｙｅｓルート）、処理は端子Ｄを介して図２５の処理に移行する。一方、「入会」ではなかったと判定された場合（ステップＳ２４１：Ｎｏルート）、Ｗｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて購入キャンセル確認ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ２４３）。またこの際、管理サーバ５の決済処理部５０６は、ステップＳ２３１においてワーク・メモリ領域等の記憶装置に一時格納しておいた不足金額に関するデータをクリアする。
【００９６】
ユーザ端末７は、購入キャンセル確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ２４５）。図示しないが、購入キャンセル確認ページには、商品の購入（注文）処理を取りやめた旨のメッセージが含まれる。
【００９７】
このようにして、プリペイド残高が不足した場合には、正会員としての登録を促すようになっている。
【００９８】
図２５には、ステップＳ２４１（図２３）において「入会」であると判定された場合（ステップＳ２４１：Ｙｅｓルート）の処理フローが示されている。まず、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて入会ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ２５１）。ユーザ端末７は、入会ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ２５３）。図示しないが、入会ページには、ユーザの氏名の入力欄や、決済に使用するクレジット・カードの番号入力欄等、正会員として登録するために必要なデータを入力するための、入会用データ入力欄が含まれる。
【００９９】
そして、ユーザ端末７は、入会ページに対するユーザからの入会用データの入力を受け付け、管理サーバ５に対して送信する（ステップＳ２５５）。管理サーバ５のＩＤ管理部５０２は、入力用データをユーザ端末７から受信し、ユーザ管理ＤＢ５１２の該当するレコード（図２）に格納する（ステップＳ２５７）。
【０１００】
さらに、ＩＤ管理部５０２は、ユーザ管理ＤＢ５１２の該当するレコードの、プリペイド会員フラグの列２０４（図２）の値をクリアし、正会員フラグの列２０６（図２）に「１」を格納する（ステップＳ２５９）。
【０１０１】
そして、管理サーバ５の決済処理部５０６は、ステップＳ２３１（図２３）においてワーク・メモリ領域等の記憶装置に一時格納しておいた不足金額データと、ユーザ管理ＤＢ５１２の該当するレコードのプリペイド残高の列２１０（図２）の値とを用いて課金データを生成し、課金ＤＢ５１６に格納する（ステップＳ２６１）。本実施の形態においては、図４に示した例の３行目及び４行目のように２レコード登録される。さらに、決済処理部５０６は、ユーザ管理ＤＢ５１２の該当するレコードのプリペイド残高の列２１０（図２）の値を「０」に更新する（ステップＳ２６３）。
【０１０２】
そして、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて入会完了確認ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ２６５）。ユーザ端末７は、入会完了確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ２６７）。図示しないが、入会完了確認ページには、商品の購入（注文）処理が完了したことを通知するメッセージと、ユーザが正会員として登録された旨のメッセージとが含まれる。なお、決済方式が複数になるため、課金データも併せて提示するようにしてもよい。
【０１０３】
このようにして、プリペイド会員にはＩＤの再発行をすることなく正会員としての入会手続きが行われる。なお、プリペイド会員が正会員として登録された場合には、インセンティブとして代金のいくらかを減額するようにしてもよい。また、プリペイド・キーの贈呈者に課金されている金額のいくらかを減額するようにしてもよい。
【０１０４】
図２６には、プリペイド会員であるユーザが例えばユーザ端末７を操作して管理サーバ５にアクセスし、正会員として登録する際の処理フローが示されている。本実施の形態においては、ユーザ端末７が有するＷｅｂブラウザを介してサーバにアクセスすることを想定しているが、専用のクライアント・ソフトウェアを使用する場合もある。以下、各処理ステップに基づき説明していく。
【０１０５】
まず、ユーザ端末７は、表示しているメニュー・ページに対するユーザからの「入会」の選択指示を受け付け、指示データを管理サーバ５に対して送信する（図２６：ステップＳ３０１）。メニュー・ページについては、図７に一例を示したが、例えば会員入会ページへのリンク部７００（図７）のクリックを受け付ける。
【０１０６】
図２６の処理フローに戻り、管理サーバ５のＷｅｂページ管理部５００は、指示データをユーザ端末７から受信し、一旦記憶装置に格納する（図２６：ステップＳ３０３）。そして、Ｗｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて入会ユーザ確認ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ３０５）。ユーザ端末７は、入会ユーザ確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ３０７）。
【０１０７】
入会ユーザ確認ページの一例を図２７に示す。図２７の例には、ＩＤ入力欄２７００とパスワード入力欄２７１０と確定ボタン２７２０とが含まれている。ユーザは、この入会ユーザ確認ページに対して認証データを入力し、確定ボタン２７２０をクリックする。なお、ユーザが既にログイン済みである場合には、ログインしているユーザのＩＤを予めＩＤ入力欄２７００に埋め込んでおくようにしてもよい。
【０１０８】
図２６の処理フローに戻り、ユーザ端末７は、入会ユーザ確認ページ（図２７）に対するユーザからの認証データの入力を受け付け、認証データを管理サーバ５に対して送信する（図２６：ステップＳ３０９）。
【０１０９】
管理サーバ５のＷｅｂページ管理部５００は、認証データをユーザ端末７から受信し、一旦記憶装置に格納する（ステップＳ３１１）。その際、管理サーバ５のＩＤ管理部５０２は、ＩＤ及びパスワードが正しく入力されたか、ユーザ管理ＤＢ５１２に格納されているデータを用いてチェックする。正しく入力されていればそのまま処理を続行するが、正しく入力されていなければエラーを返し、例えばユーザに再入力を促す。また、ＩＤ管理部５０２は、ユーザ管理ＤＢ５１２に格納されているデータを用いて、認証データに含まれるＩＤがプリペイド会員のＩＤであることを確認する。具体的には、ユーザ管理ＤＢ５１２の該当するレコードの、プリペイド会員フラグの列２０４（図２）の値が「１」であることを確認する。その他の属性のＩＤの場合には、図示していないが、例えば新規にＩＤを発行する処理に移行する。但し、エラーとしてもよい。
【０１１０】
そして、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて入会ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ３１３）。ユーザ端末７は、入会ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ３１５）。図示しないが、入会ページには、ユーザの氏名の入力欄や、決済に使用するクレジット・カードの番号入力欄等、正会員として登録するために必要なデータを入力するための、入会用データ入力欄が含まれる。
【０１１１】
そして、ユーザ端末７は、入会ページに対するユーザからの入会用データの入力を受け付け、管理サーバ５に対して送信する（ステップＳ３１７）。管理サーバ５のＩＤ管理部５０２は、入力用データをユーザ端末７から受信し、ユーザ管理ＤＢ５１２の該当するレコード（図２）に格納する（ステップＳ３１９）。
【０１１２】
さらに、ＩＤ管理部５０２は、ユーザ管理ＤＢ５１２の該当するレコードの、プリペイド会員フラグの列２０４（図２）の値をクリアし、正会員フラグの列２０６（図２）に「１」を格納する（ステップＳ３２１）。なお、プリペイド残高の列２１０（図２）の値は変更しないため、プリペイドの残高が残っているユーザは、正会員になっても残りの金額分を利用することが可能である。
【０１１３】
そして、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて入会完了確認ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ３２３）。ユーザ端末７は、入会完了確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ３２５）。図示しないが、入会完了確認ページには、ユーザが正会員として登録された旨のメッセージ等が含まれる。
【０１１４】
このようにして、プリペイド会員にはＩＤの再発行をすることなく正会員としての入会手続きが行われる。
【０１１５】
以上本発明の一実施の形態について説明したが、本発明はこれに限定されるものではない。例えば図２乃至図５に示したテーブル構成は一例であって、同様のデータを格納するためであれば、別の構成を採用するようにしてもよい。また、必要に応じて項目を追加又は削除するようにしてもよい。例えば、プリペイド会員フラグの列２０４（図２）と正会員フラグの列２０６（図２）とを１つの列にまとめて、会員のステータスを管理するようにしてもよい。
【０１１６】
また、図７、図８、図９、図１１、図１２、図１３、図１４、図１６、図１７、図１８、図１９、図２１、図２２、図２４及び図２７に示した画面構成は一例であって、同様の内容を別の態様にて表現することも可能である。また、管理サーバ５が複数のサーバによって構成されていてもよい。さらに、図１に示した管理サーバ５の機能ブロック構成は一例であって、実際のプログラム・モジュール構成とは異なる場合がある。また、例えば会員向けのオンライン・ショッピングを実現するためのサーバは、管理サーバ５に限らず別の専用サーバ等であってもよい。
【０１１７】
また、図６、図１０、図１５、図２０、図２３、図２５及び図２６に示した処理フローも一例であって、同様の処理結果が得られる範囲において処理の順序を入れ替えてもよいし、必要に応じてステップを追加又は削除してもよい。
【０１１８】
【発明の効果】
以上述べたように、本発明によれば、プリペイド形式の決済に関連する新規なサービスを実現することができる。また、効果的なタイミングで入会勧誘を行うことができる。
【図面の簡単な説明】
【図１】本発明の実施の形態におけるシステム概要図である。
【図２】ユーザ管理ＤＢのテーブル構成及び格納されるデータの一例を示す図である。
【図３】プリペイド決済ＤＢのテーブル構成及び格納されるデータの一例を示す図である。
【図４】課金ＤＢのテーブル構成及び格納されるデータの一例を示す図である。
【図５】商品ＤＢのテーブル構成及び格納されるデータの一例を示す図である。
【図６】本発明の実施の形態における処理フロー（その１）を示す図である。
【図７】メニュー・ページの一例を示す図である。
【図８】購入ページの一例を示す図である。
【図９】確認ページの一例を示す図である。
【図１０】本発明の実施の形態における処理フロー（その２）を示す図である。
【図１１】ギフト・メール表示画面の一例を示す図である。
【図１２】仮受領確認ページの一例を示す図である。
【図１３】パスワード入力ページの一例を示す図である。
【図１４】仮受領完了ページの一例を示す図である。
【図１５】本発明の実施の形態における処理フロー（その３）を示す図である。
【図１６】本受領メール表示画面の一例を示す図である。
【図１７】本受領確認ページの一例を示す図である。
【図１８】認証データ入力ページの一例を示す図である。
【図１９】本受領完了ページの一例を示す図である。
【図２０】本発明の実施の形態における処理フロー（その４）を示す図である。
【図２１】ショッピング・ページの一例を示す図である。
【図２２】購入ユーザ確認ページの一例を示す図である。
【図２３】本発明の実施の形態における処理フロー（その５）を示す図である。
【図２４】残高不足通知ページの一例を示す図である。
【図２５】本発明の実施の形態における処理フロー（その６）を示す図である。
【図２６】本発明の実施の形態における処理フロー（その７）を示す図である。
【図２７】入会ユーザ確認ページの一例を示す図である。
【符号の説明】
１ ネットワーク ３，７ ユーザ端末 ５ 管理サーバ
５００ Ｗｅｂページ管理部 ５０２ ＩＤ管理部
５０４ メール処理部 ５０６ 決済処理部
５１０ Ｗｅｂページ・データ格納部
５１２ ユーザ管理ＤＢ
５１４ プリペイド決済ＤＢ
５１６ 課金ＤＢ ５１８ 商品ＤＢ[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to an information processing technology for a service related to payment in a prepaid system.
[0002]
[Prior art]
As a provider member service, there is generally a service in which a member of a specific provider can present a usage fee of the provider as a gift online to other members of the provider. A member receiving such a gift (hereinafter referred to as an online gift) can use the provider free of charge for the amount specified by the presenting member. That is, the presenter purchases the right to use the prepaid system and gives it to another member, and the presenter is charged the amount of the right to use. In addition, users who can use such an online gift may not be limited to members of the provider.
[0003]
For example, there is a technology for providing a prepaid mail service (see Patent Document 1). That is, a user information file for storing user information, an authentication server for authenticating a mail account of an accessing user based on the user information, and a mail server for performing Internet mail processing on the authenticated mail account And an account management unit that checks the limited use conditions of the corresponding mail account according to the use of the mail server and prohibits the use of mail accounts that do not meet the limited use conditions. Prepaid mail systems exist that issue Internet mail accounts based on limited use conditions.
[0004]
[Patent Document 1]
JP 2002-152245 A
[0005]
[Problems to be solved by the invention]
However, in the above technology, a user who obtains an online gift or temporary mail account can use the amount and time set in the online gift or temporary mail account as a right to use a specific provider. However, it cannot be used for other purposes such as online shopping. Therefore, the range of use for the user has been narrow. In addition, if the user who used the online gift or temporary mail account is not registered as a regular member of the provider but wants to be registered as a regular member to continue using the service, issue an ID again You need to be registered separately as a regular member. At that time, the data used for the use of the prepaid method cannot be basically inherited and is newly set, so that the management is troublesome for the user.
[0006]
Therefore, an object of the present invention is to provide a technique for realizing a new service related to prepaid payment.
[0007]
It is another object of the present invention to provide a new technique for soliciting membership.
[0008]
[Means for Solving the Problems]
The information processing method according to the present invention, when receiving a distribution request for a key (hereinafter, referred to as a prepaid key) used for payment in a prepaid system, generates a key according to a regular member ID setting rule and stores the key. A step of generating a prepaid key to be stored in the device, and a member for setting the key in the storage device so that the key can be used as an ID of the regular member when a registration request for the regular member is received using the key stored in the storage device. Registration step.
[0009]
As a result, the prepaid key can be continuously used as the active member ID as it is, and the trouble of issuing the active member ID again and the duplication management of the ID can be omitted.
[0010]
Also, the prepaid key generation step described above may include the step of associating the key with a particular user. Thus, a user who uses the prepaid key can be designated, and the prepaid key can be presented to a specific user as, for example, an online gift. For example, a record including a prepaid key and a mail address of a user who uses the prepaid key is stored in a storage device.
[0011]
Further, the specific user may be a user who has not been registered as a regular member. Accordingly, when a user who has not been registered as a regular member of the provider wants to be registered as a regular member to use the service continuously, the user is registered as a regular member without receiving a new ID. That is, the user can directly use the prepaid key as the user ID of the regular member.
[0012]
Further, the above-described member registration step may include a step of changing data indicating a status of a specific user set in the storage device to data indicating a regular member and setting the data in the storage device. In this way, by performing the transition process to the active member by changing the status of the user, the active active member registration that does not require the issuance of a new ID can be realized. In addition, management on the system side becomes easy.
[0013]
Further, when a payment request exceeding the amount associated with the key is received, a step of prompting the user who made the payment request to register as a regular member may be further included. Here, the amount associated with the key refers to a prepaid balance that enables payment by the prepaid method by using the key, and is reduced by the payment amount by the user performing the payment. It goes. Then, as described above, when a shortage occurs, by encouraging regular member registration, it is possible to solicit a membership at an effective timing.
[0014]
The method may further include the step of storing the difference between the payment amount in the payment request and the amount associated with the key in the charging data storage unit as charging data for a user registered as a regular member. This allows the user to settle the shortage of the prepaid balance by becoming a regular member by means provided to the regular member. For example, the shortfall is settled with a credit card or the like.
[0015]
Further, the above-described prepaid key generation step may include a step of associating a specific password with the key. As a result, users who use the prepaid key can be limited to users who know a specific password. For example, a record including a prepaid key and a password set by a user using the prepaid key is stored in the storage device.
[0016]
In the above-described member registration step, the specific password may be set as a password corresponding to the ID of the regular member. As a result, even if the user becomes a regular member, the user can continue to use the password that has been used so far.
[0017]
Further, when a specification of an amount that can be used for payment in the prepaid method and an instruction to distribute a key for using the amount for payment in the prepaid method to a specific user are received from a certain user, the key by the specific user is accepted. The method may further include storing, in the charging data storage unit, the amount specified by the certain user and associated with the key as the charging data for the certain user at the point in time when the start of use is confirmed.
[0018]
As a result, the user who has presented the prepaid key to another user is charged the amount of his / her designated presentation when it is confirmed that the presented user has started using the prepaid key. Therefore, even if an attempt is made to present the prepaid key, no charge is generated when the presented user refuses to use the prepaid key, and wasteful expenses for the user can be suppressed.
[0019]
The program that causes a computer to execute the information processing method according to the present invention is stored in a storage medium or storage device such as a flexible disk, a CD-ROM, a magneto-optical disk, a semiconductor memory, and a hard disk. In addition, it may be distributed as a digital signal via a network. The data being processed is temporarily stored in the memory of the computer.
[0020]
BEST MODE FOR CARRYING OUT THE INVENTION
FIG. 1 shows a system configuration diagram according to an embodiment of the present invention. For example, a management server 5 and one or more user terminals 3 and user terminals 7 such as personal computers are connected to a network 1 such as the Internet by wireless or wired. The user terminal 3 and the user terminal 7 have a not-shown web (Web) browser function and a mailer function, and enable browsing of a web page and transmission / reception and browsing of mail. In addition, the user terminal 3 and the user terminal 7 may be a mobile phone having a Web browser function and a mailer function, another mobile information terminal, or the like.
[0021]
The management server 5 includes a Web page management unit 500, an ID management unit 502, a mail processing unit 504, and a payment processing unit 506. These processing contents will be described in the description of the processing flow. However, the management server 5 has a Web server function (not shown), and can generate and transmit Web page data. I have. Further, the management server 5 manages a Web page / data storage unit 510, a user management DB 512, a prepaid payment DB 514, a billing DB 516, and a product DB 518. The Web page data storage unit 510 stores Web page data exemplified later and data of other Web pages provided by the management server 5.
[0022]
FIG. 2 shows an example of a table configuration of the user management DB 512 and stored data. In the example of FIG. 2, an ID column 200, a password column 202, a prepaid member flag column 204, a regular member flag column 206, a mail address column 208, a prepaid balance column 210, a name column 212, and a credit A column 214 of a card number and a column 216 of a URL (Uniform Resource Locator) are included. In addition, although not shown, a column for storing data necessary for user management, such as a column for a registration date and time and a column for a user's address, is included.
[0023]
In the table of the user management DB 512, records regarding a non-member user using a prepaid key (hereinafter, referred to as a prepaid member) and a user who has been registered as a member (hereinafter, referred to as a regular member) are registered. For prepaid members, the prepaid key is handled as a user ID as it is.
[0024]
The ID column 200 stores a prepaid key, that is, a prepaid member user ID and a regular member user ID. That is, the prepaid key and the user ID of the regular member are generated according to the same naming rule, and are managed without distinction. However, the ID string structure may be used to indicate that the user has become a regular member via a prepaid member or a prepaid member.
[0025]
If the user is a prepaid member, “0” or “1” is set in the column 204 of the prepaid member flag, and if the user is a regular member, “1” is set in the column 206 of the regular member flag. In addition, in order to use the prepaid key, use start registration is required. For prepaid members, users who have issued a user ID and presented a prepaid key and have not yet registered use start , Is set to “0” in the prepaid member flag column 204. On the other hand, among the prepaid members, the user who has registered the use start of the prepaid key is set to “1” in the column 204 of the prepaid member flag.
[0026]
The prepaid balance column 210 stores the amount of money that can be settled by the prepaid method. This amount decreases as the amount set at the time of generation of the prepaid key is set as the initial value, and the payment is made in the prepaid system. Depending on the payment amount, it may be “0” in one payment. In the column 212 of the name and the column 214 of the credit card number, values are stored when the user is a regular member.
[0027]
The URL column 216 stores URL data unique to the user. For example, if the user is a prepaid member, a user ID has been issued, a prepaid key has been presented, and the use start registration has not been performed, the URL data of the use start registration Web page is stored. . In the present embodiment, the use start registration includes two steps of temporary receipt confirmation and main receipt confirmation, and the URL differs depending on how far the use start registration has progressed. A common path with the receipt confirmation URL is stored. For example, data "http: //www.****.com/prepaid/@GIF12345/" is stored. For example, a user-specific URL is generated by adding data such as “karijuryo.html” or “honjuryo.html” to this.
[0028]
FIG. 3 shows an example of a table configuration of the prepaid payment DB 514 and stored data. The example of FIG. 3 includes a payment number column 300, a presenter ID column 302, a recipient ID column 304, a product ID column 306, a purchase amount column 308, and a charging flag column 310. . In addition, although not shown, a column for storing data relating to the purchase and presentation of a prepaid key, such as a column of settlement date and time, is included.
[0029]
A record is registered in the prepaid payment DB 514 when a prepaid key presentation process is performed. In the example of FIG. 3, it can be seen from the record on the first line that the user having the user ID “AAA00000” has given a prepaid key worth 500 yen to a specific user. The value “GIF12345” is stored in the column 304 of the recipient ID of the record in the first row, and this value is also the prepaid key itself and the user ID of the prepaid member to be presented.
[0030]
In the charging flag column 310, “1” is set when the user indicated in the presenter ID column 302 is charged. In the charging flag column 310, the initial value “0” is set until the user indicated in the receiver ID column 304 registers the start of use of the prepaid key, so that the user is not charged. It has become.
[0031]
FIG. 4 shows an example of a table configuration of the charging DB 516 and stored data. The example of FIG. 4 includes a charging number column 400, a purchaser ID column 402, a purchased product ID column 404, a purchase amount column 406, and a payment method column 408. In addition, although not shown, a column for storing data related to the purchase of a product, such as a column of purchase date and time, is included.
[0032]
A record is registered in the charging DB 516 when a user purchases a product online. In the example of FIG. 4, the value of the charging number column 400, the value of the purchaser ID 402, and the value of the purchased product ID 404 are the same between the record on the third line and the record on the fourth line. For example, this is a record in a case where a product of 300 yen is settled for 100 yen by a prepaid system, and the remaining 200 yen is settled by a member's usual settlement method such as a credit card. The billing number may be set separately.
[0033]
FIG. 5 shows an example of a table configuration of the product DB 518 and stored data. The example of FIG. 5 includes a product ID column 550, a product attribute column 552, a product name column 554, and a unit price column 556. In addition, although not shown, a column for storing data on a product such as a maker code is included. In the product DB 518, records regarding products that can be purchased online by the user are registered.
[0034]
Next, processing contents of the system shown in FIG. 1 will be described with reference to FIGS. FIG. 6 shows a processing flow when the user operates the user terminal 3 to access the management server 5 and presents a prepaid key, for example. Hereinafter, description will be made based on each processing step. It is assumed that the login processing has been performed before this.
[0035]
First, the user terminal 3 transmits a request for data of an online gift purchase page to the management server 5 according to the operation of the user (FIG. 6: step S1). In the present embodiment, it is assumed that the server is accessed via the Web browser of the user terminal 3, but dedicated client software may be used in some cases.
[0036]
FIG. 7 shows an example of the menu page. The example of FIG. 7 includes a link 700 to a member enrollment page and a link 710 to a gift coupon purchase page. When the link 700 to the member enrollment page is clicked, a transition is made to the member enrollment page, and when the link 710 to the gift coupon purchase page is clicked, the transition is made to the gift coupon purchase page. Here, “(online) gift certificate” refers to a prepaid key, but on each web page, a virtual “(online) gift certificate” is used to make it easier for the user to imagine. I have.
[0037]
Returning to the processing flow of FIG. 6, the Web page management unit 500 of the management server 5 receives a request for data of an online gift certificate purchase page from the user terminal 3 (FIG. 6: step S3). Then, the Web page management unit 500 generates data of an online gift certificate purchase page using the data stored in the Web page data storage unit 510, and transmits the data to the user terminal 3 (Step S5). The user terminal 3 receives the data of the online gift certificate purchase page from the Web page management unit 500 and displays the data on the display device (step S7).
[0038]
FIG. 8 shows an example of an online gift voucher purchase page. The example of FIG. 8 includes a recipient's mail address input field 800, a price setting pull-down list 810, a comment input field 820, and a send button 830. The user inputs necessary data to the online gift certificate purchase page, and clicks a send button 830.
[0039]
Returning to the processing flow of FIG. 6, the user terminal 3 receives an input from the user on the online gift certificate purchase page (FIG. 8), and transmits the received data to the management server 5 (FIG. 6: step S9). . The Web page management unit 500 of the management server 5 receives input data from the user for the online gift certificate purchase page (FIG. 8) from the user terminal 3 and temporarily stores the data in the storage device (step S11).
[0040]
Then, the Web page management unit 500 generates data of the input content confirmation page and transmits the data to the user terminal 3 (Step S13). The input contents may be checked, and if an error occurs, an error message may be returned. The user terminal 3 receives the data of the input content confirmation page from the web page management unit 500 and displays the data on the display device (step S15).
[0041]
FIG. 9 shows an example of the input content confirmation page. The example of FIG. 9 includes a recipient's e-mail address display column 900, an amount display column 910, a comment display column 920, and a confirmation button 930. The user confirms that there is no mistake in the data shown on the input content confirmation page, and clicks the confirmation button 930. The user may be allowed to make correction input to each display column, or may include a cancel button (not shown) or the like.
[0042]
Returning to the processing flow of FIG. 6, the user terminal 3 receives a selection input from the user on the input content confirmation page (FIG. 9), and transmits the selection input data to the management server 5 (FIG. 6: step S17). The Web page management unit 500 of the management server 5 receives the selection input data from the user terminal 3 and temporarily stores the data in the storage device (Step S19).
[0043]
Then, the Web page management unit 500 determines whether or not the purchase processing of the online gift certificate may be performed (OK) (step S21). For example, when a cancel button (not shown) is clicked on the input content confirmation page (FIG. 9) or when an error is found by checking the input content of the user, the online gift coupon purchase processing is performed. It is determined that it is not allowed (it is not OK).
[0044]
If it is determined that it is not OK (step S21: No route), the process returns to step S5. On the other hand, when it is determined to be OK (step S21: Yes route), the ID management unit 502 of the management server 5 generates prepaid member data and stores it in the user management DB 512 (step S23). That is, one new record is registered in the user management DB 512. “0” is stored in the column 204 (FIG. 2) of the prepaid member flag of the record to be registered. The URL column 216 stores the user-specific URL data (path) as described above. At this time, the column 202 of the password of the record to be registered (FIG. 2), the column 206 of the regular member flag (FIG. 2), the column 212 of the name (FIG. 2), and the column 214 of the credit card number (FIG. 2) Does not store a value.
[0045]
Then, the payment processing unit 506 of the management server 5 generates prepaid payment data including the presenter ID, the recipient ID, the product ID, and the purchase price, and stores the data in the prepaid payment DB 514 (step S25). That is, one new record including the presenter ID, the recipient ID, the product ID, and the purchase price is registered in the prepaid payment DB 514. “0” is stored in the charging flag column 310 (FIG. 3) of the registered record.
[0046]
Then, the Web page management unit 500 of the management server 5 generates the data of the processing completion confirmation page using the data stored in the Web page data storage unit 510, and transmits the data to the user terminal 3 (Step S27). ). The user terminal 3 receives the data of the processing completion confirmation page from the Web page management unit 500 and displays it on the display device (step S29). Although not shown, the processing completion confirmation page includes, for example, a message such as "Purchase of online gift certificate accepted."
[0047]
Thus, the purchase of the online gift certificate is accepted, and the prepaid key is generated. When the processing in step S27 is completed, the processing shifts to a processing in FIG.
[0048]
FIG. 10 shows a processing flow when a user who is a recipient of the prepaid key accesses the management server 5 by operating the user terminal 7 and temporarily receives the prepaid key. Hereinafter, description will be made based on each processing step.
[0049]
First, the mail processing unit 504 of the management server 5 generates gift mail data using the data stored in the Web page data storage unit 510 and the data stored in the user management DB 512, and generates a prepaid mail. The key is transmitted to the user to whom the key is presented (step S41). The user terminal 7 receives the gift mail data from the management server 5 via the mail server (not shown) according to the user's operation, and displays the data on the display device (step S43).
[0050]
FIG. 11 shows an example of a display screen for a gift / mail. The example of FIG. 11 includes a presentation source user display unit 1100, a message display unit 1110, and a temporary receipt confirmation URL display unit 1120. The presentation source user display unit 1100 includes the name of the user who is the presentation source (the value in the name column 212 (FIG. 2) of the user management DB 512) so that it can be known from whom. The message display section 1110 shows the data entered in the comment input field 820 on the online gift certificate purchase page (FIG. 8). Although the URL of the temporary receipt confirmation page is shown in the temporary receipt confirmation URL display unit 1120, the URL may be a hyperlink depending on the function of the mailer and its setting.
[0051]
Returning to the processing flow of FIG. 10, the user terminal 7 follows the instruction of the user to access the Web page based on the URL shown in the temporary receipt confirmation URL display unit 1120 (FIG. 11), for example. A data request is transmitted to the management server 5 (FIG. 10: step S45). The Web page management unit 500 of the management server 5 receives a request for temporary receipt confirmation page data from the user terminal 7 (Step S47). Then, the Web page management unit 500 uses the data stored in the Web page data storage unit 510, the data stored in the user management DB 512, and the data stored in the prepaid payment DB 514 to generate a temporary receipt confirmation page. Is generated and transmitted to the user terminal 7 (step S49). The user terminal 7 receives the data of the temporary receipt confirmation page from the Web page management unit 500 and displays the data on the display device (step S51).
[0052]
FIG. 12 shows an example of the temporary receipt confirmation page. The example of FIG. 12 includes a sender mail address display unit 1200, a recipient mail address display unit 1210, an amount display unit 1220, a reception button 1230, and a reception rejection button 1240. The sender's e-mail address display unit 1200 shows the e-mail address of the user who is the presenter. However, the sender's e-mail address display unit 1200 may display the user's name in the same manner as the presenter's e-mail display unit 1100 shown in FIG. Good.
[0053]
Returning to the processing flow of FIG. 10, the user terminal 7 receives a selection input from the user for the temporary receipt confirmation page (FIG. 12) and transmits it to the management server 5 (FIG. 10: step S53). The Web page management unit 500 of the management server 5 receives the selection input data from the user terminal 7 and temporarily stores the data in the storage device (Step S55).
[0054]
Then, the web page management unit 500 determines whether the selection input from the user is “accept” (step S57). On the temporary receipt confirmation page (FIG. 12), if the user clicks on the receipt button 1230, it is determined to be "reception", and if the rejection button 1240 is clicked, it is determined that it is not "reception".
[0055]
If it is determined that the received mail is not “reception” (step S57: No route), the mail processing unit 504 of the management server 5 generates data of a rejection notification mail using the data stored in the user management DB 512, It is transmitted to the presenter (user of the presenter) (step S59). Although not shown, the rejection notification mail includes a message indicating that the online gift certificate was not received. In this case, a series of processes relating to the presentation of the prepaid key ends. The corresponding record may be deleted from the user management DB 512.
[0056]
On the other hand, if it is determined that the received data is “accepted” (step S57: Yes route), the Web page management unit 500 of the management server 5 uses the data stored in the Web page data storage unit 510 to input the password input page. Is generated and transmitted to the user terminal 7 (step S61). The user terminal 7 receives the data of the password input page from the Web page management unit 500 and displays the data on the display device (step S63).
[0057]
FIG. 13 shows an example of the password input page. The example of FIG. 13 includes a password input field 1300 and a confirm button 1310. The user inputs a password in the password input field 1300, and clicks the OK button 1310. Note that the password input field 1300 does not directly display the characters input by the user, but is indicated by an asterisk. Therefore, a plurality of password input fields may be provided to check for an input error.
[0058]
Returning to the processing flow of FIG. 10, the user terminal 7 accepts the input of the password to the password input page (FIG. 13) from the user and transmits the password to the management server 5 (FIG. 10: step S65). The ID management unit 502 of the management server 5 receives the password from the user terminal 7 and stores the password in the password column 202 (FIG. 2) of the user management DB 512 (Step S67). The corresponding record is specified based on, for example, the value of the mail address column 208 (FIG. 2).
[0059]
Then, the Web page management unit 500 of the management server 5 generates data of the temporary reception completion page using the data stored in the Web page data storage unit 510 and the data stored in the user management DB 512, The message is transmitted to the user terminal 7 (step S69). The user terminal 7 receives the data of the temporary reception completion page from the Web page management unit 500 and displays the data on the display device (step S71).
[0060]
FIG. 14 shows an example of the temporary receipt completion page. The example of FIG. 14 includes a prepaid key display section 1400 and an OK button 1410. The user confirms his / her ID indicated on prepaid key display section 1400 and clicks OK button 1410.
[0061]
In this way, the provisional receipt processing of the prepaid key is performed. When the processing in step S69 ends, the processing shifts to a processing in FIG.
[0062]
FIG. 15 shows a case where a user who is the recipient of the prepaid key and has already received the prepaid key temporarily accesses the management server 5 by operating the user terminal 7 and finally receives the prepaid key. Is shown. Hereinafter, description will be made based on each processing step.
[0063]
First, the mail processing unit 504 of the management server 5 generates data of the received mail using the data stored in the Web page data storage unit 510 and the data stored in the user management DB 512, and The key is sent to the destination user (step S81). The user terminal 7 receives the data of the received mail from the management server 5 via the mail server (not shown) according to the operation of the user, and displays the data on the display device (step S83).
[0064]
FIG. 16 shows an example of a display screen of the received mail. The example of FIG. 16 includes a URL display unit 1600 for confirming receipt. The URL of the actual receipt confirmation page is shown in the URL display section 1600 for the actual receipt confirmation, but the URL may be a hyperlink depending on the function of the mailer and its setting.
[0065]
Returning to the processing flow of FIG. 15, the user terminal 7 follows the user's instruction to access the Web page based on the URL shown in the URL display unit 1600 for confirmation of reception (FIG. 16), for example. The data request is transmitted to the management server 5 (FIG. 15: step S85). The Web page management unit 500 of the management server 5 receives the request for the final confirmation page data from the user terminal 7 (Step S87). Then, the web page management unit 500 uses the data stored in the web page data storage unit 510, the data stored in the user management DB 512, and the data stored in the prepaid payment DB 514 to store the final receipt confirmation page. Is generated and transmitted to the user terminal 7 (step S89). The user terminal 7 receives the data of the main reception confirmation page from the Web page management unit 500 and displays the data on the display device (step S91).
[0066]
FIG. 17 shows an example of the main receipt confirmation page. The example of FIG. 17 includes a sender mail address display section 1700, a recipient mail address display section 1710, a money amount display section 1720, and a “receive” button 1730. The sender's e-mail address display section 1700 shows the e-mail address of the user who is the presenter, but may show the user's name. The user checks the contents of each display unit and clicks a “receive” button 1730.
[0067]
Returning to the processing flow of FIG. 15, the user terminal 7 accepts a selection input from the user for the main reception confirmation page (FIG. 17) and transmits the selection input to the management server 5 (FIG. 15: step S93). The Web page management unit 500 of the management server 5 receives the selection input data from the user terminal 7 and temporarily stores the data in the storage device (Step S95). Here, the selection input from the user is “accept”.
[0068]
Then, the Web page management unit 500 of the management server 5 generates data of the authentication data input page using the data stored in the Web page data storage unit 510, and transmits the data to the user terminal 7 (Step S97). ). The user terminal 7 receives the data of the authentication data input page from the Web page management unit 500 and displays the data on the display device (step S99).
[0069]
FIG. 18 shows an example of the authentication data input page. The example of FIG. 18 includes an ID input field 1800, a password input field 1810, and a confirm button 1820. The user enters the prepaid key confirmed on the temporary receipt completion page (FIG. 14) into the ID entry field 1800, enters the password set on the password entry page (FIG. 13) into the password entry field 1810, and presses the confirm button 1820. click.
[0070]
Returning to the processing flow of FIG. 15, the user terminal 7 receives the input of the ID (prepaid key) and the password for the authentication data input page (FIG. 18) from the user, and transmits them to the management server 5 (FIG. 15: Step S101). The Web page management unit 500 of the management server 5 receives the ID and the password from the user terminal 7, and temporarily stores the ID and the password in the storage device (Step S103). At this time, the ID management unit 502 of the management server 5 checks whether the ID and the password have been correctly input using the data stored in the user management DB 512. If the input is correct, the process is continued, but if the input is not correct, an error is returned and the user is prompted to input again, for example.
[0071]
Then, the ID management unit 502 updates the value of the prepaid member flag 204 (FIG. 2) of the user management DB 512 from “0” to “1” (Step S105). Further, the payment processing unit 506 of the management server 5 updates the value of the charging flag column 310 (FIG. 3) of the corresponding record in the prepaid payment DB 514 from “0” to “1” and uses the data of the record. The accounting data is generated and stored in the accounting data DB 516 (step S107). That is, a process is performed in which the destination user of the prepaid key is officially registered as a prepaid member, and the prepaid key presenting user is charged accordingly.
[0072]
Then, the web page management unit 500 of the management server 5 generates data of the main reception completion page using the data stored in the web page data storage unit 510, and transmits the data to the user terminal 7 (step S109). ). The user terminal 7 receives the data of the reception completion page from the Web page management unit 500 and displays the data on the display device (step S111).
[0073]
FIG. 19 shows an example of the main reception completion page. The example in FIG. 19 includes a message input field 1900, a value transfer hyperlink 1910, and an OK button 1920. When the value transfer hyperlink 1910 is clicked, the page moves to a page for transferring the value (balance) of the prepaid key received by the user to an existing ID different from the prepaid key. Note that the value transfer process is a process like a bank transfer, and is not the gist of the present invention, so the description is omitted. For example, the user inputs a message in the message input field 1900 and clicks an OK button 1920.
[0074]
Returning to the processing flow of FIG. 15, the user terminal 7 receives a selection input from the user for the main reception completion page (FIG. 19) and transmits the selection input to the management server 5 (FIG. 15: step S113). The Web page management unit 500 of the management server 5 receives the selection input data from the user terminal 7 and temporarily stores the data in the storage device (Step S115). Here, the selection input from the user is “OK”.
[0075]
Then, the mail processing unit 504 of the management server 5 generates data of the receipt notification mail and transmits the data to the presenter (user of the presenter) (step S117). Although not shown, the receipt notification mail includes a message indicating that the online gift certificate has been received and a message input to the message input field 1900 (FIG. 19) of the reception completion page. Further, there may be a case where data related to charging (amount of money, payment date, etc.) is included.
[0076]
Thus, the main processing of the prepaid key is performed. Then, the user who has completed the receiving process and has become a prepaid member can use the received prepaid key to purchase a product, browse paid content, and the like.
[0077]
FIG. 20 shows a processing flow when a user who is a member of the provider (including a prepaid member) operates the user terminal 7 to access the management server 5 and performs online shopping. In the present embodiment, it is assumed that the server is accessed via the Web browser of the user terminal 7, but dedicated client software may be used in some cases. Hereinafter, description will be made based on each processing step.
[0078]
First, the user terminal 7 receives a product purchase instruction from the user for the displayed Web page, and transmits instruction data to the management server 5 (FIG. 20: step S201).
[0079]
For example, a product purchase instruction from a user on a shopping page as shown in FIG. 21 is received. The example of FIG. 21 includes a product data display unit 2000 and a “buy” button 2100. By clicking “buy” button 2100, a purchase instruction for product A is accepted. Although a simplified example is shown in FIG. 21, accounting contents of a plurality of purchase candidate products such as “shopping basket” and “shopping cart” in general online shopping are displayed, and a purchase instruction is issued. The page may be accepted.
[0080]
Returning to the processing flow of FIG. 20, the Web page management unit 500 of the management server 5 receives the purchase instruction data from the user terminal 7 and temporarily stores it in the storage device (FIG. 20: step S203). Note that the purchase instruction data includes accounting data such as a product name, a unit price, a quantity, and a total price.
[0081]
Then, the web page management unit 500 generates data of the purchase user confirmation page using the data stored in the web page data storage unit 510, and transmits the data to the user terminal 7 (step S205). The user terminal 7 receives the data of the purchase user confirmation page from the Web page management unit 500 and displays the data on the display device (step S207).
[0082]
FIG. 22 shows an example of the purchase user confirmation page. The example of FIG. 22 includes a transaction data display unit 2200, an ID input box 2210, a password input box 2220, and a confirm button 2230. The user inputs the authentication data on the purchase user confirmation page, and clicks the OK button 2230. For example, a user having a plurality of IDs inputs an ID to be charged. If the user has already logged in, the ID of the logged-in user may be embedded in the ID input field 2210 in advance.
[0083]
Returning to the processing flow of FIG. 20, the user terminal 7 receives the input of the authentication data from the user on the purchase user confirmation page (FIG. 22) and transmits the purchase data to the management server 5 (FIG. 20: step S209). . It is assumed that the purchase data includes the transaction data of the product and the authentication data of the user.
[0084]
The Web page management unit 500 of the management server 5 receives the purchase data from the user terminal 7 and temporarily stores the purchase data in the storage device (Step S211). At this time, the ID management unit 502 of the management server 5 checks whether the ID and the password have been correctly input using the data stored in the user management DB 512. Further, the ID management unit 502 checks whether the ID included in the purchase data is a chargeable ID, and returns an error if the chargeable ID is not available. Specifically, the value of the prepaid member flag column 204 (FIG. 2) is “1” or the value of the regular member flag column 206 (FIG. 2) of the corresponding record in the user management DB 512 is “1”. In that case, billing is possible.
[0085]
Further, the ID management unit 502 determines whether the user who purchases the product (the ID to be charged) is a prepaid member using the data stored in the user management DB 512 (step S213). If the value of the prepaid member flag column 204 (FIG. 2) of the corresponding record in the user management DB 512 is “1”, it is determined that the user is a prepaid member.
[0086]
If it is determined that the member is not a prepaid member (step S213: No route), the process proceeds to step S219 described later.
[0087]
On the other hand, when it is determined that the member is a prepaid member (step S213: Yes route), the settlement processing unit 506 of the management server 5 uses the purchase data and the data stored in the user management DB 512 to run out of the prepaid balance. It is determined whether or not it has been performed (step S215). Specifically, when the value of the column 210 (FIG. 2) of the prepaid balance of the corresponding record in the user management DB 512 is smaller than the transaction amount included in the purchase data, it is determined that the balance is insufficient.
[0088]
If it is determined that the balance is insufficient (step S215: Yes route), the processing shifts to a processing of FIG. On the other hand, when it is determined that the balance is not insufficient (step S215: No route), the settlement processing unit 506 of the management server 5 updates the value of the column 210 (FIG. 2) of the corresponding record of the corresponding record in the user management DB 512. (Step S217). That is, the balance is reduced by the accounting amount. Then, the settlement management unit 506 of the management server 5 generates billing data using the purchase data, and stores the billing data in the billing DB 516 (step S219). Note that billing data in the prepaid system may not be stored in the billing DB 516 because the payment has already been completed.
[0089]
Then, the Web page management unit 500 of the management server 5 generates data of the payment confirmation page using the data stored in the Web page data storage unit 510, and transmits the data to the user terminal 7 (Step S221). . The user terminal 7 receives the payment confirmation page data from the web page management unit 500 and displays the data on the display device (step S223). Although not shown, the payment confirmation page includes a message notifying that the purchase (order) processing of the product has been completed.
[0090]
In this way, processing in online shopping by a member user of a provider including a prepaid member is performed.
[0091]
FIG. 23 shows a processing flow when it is determined in step S215 (FIG. 20) that the balance is insufficient (step S215: Yes route). First, the settlement processing unit 506 of the management server 5 temporarily stores the shortfall amount of the prepaid balance in a storage device such as a work memory area (step S231). Then, the Web page management unit 500 of the management server 5 generates data of the balance shortage notification page using the prepaid balance data and the data stored in the Web page data storage unit 510, and sends the data to the user terminal 7. The data is transmitted (step S233). The user terminal 7 receives the data of the balance shortage notification page from the Web page management unit 500 and displays the data on the display device (step S235).
[0092]
FIG. 24 shows an example of the balance shortage notification page. The example of FIG. 24 includes a message display unit 2400, a “go to enrollment procedure” button 2410, and a cancel button 2420. The user checks the message displayed on the message display unit 2400, and clicks the “go to enrollment procedure” button 2410 if he / she wants to immediately execute the enrollment procedure.
[0093]
Returning to the processing flow of FIG. 23, the user terminal 7 accepts a selection input from the user for the balance shortage notification page (FIG. 24) and transmits it to the management server 5 (FIG. 23: step S237). The Web page management unit 500 of the management server 5 receives the selection input data from the user terminal 7 and temporarily stores the data in the storage device (Step S239).
[0094]
Then, the Web page management unit 500 determines whether or not the user's selection input to the balance shortage notification page (FIG. 24) is "enrollment" (step S241). For example, when the “go to enrollment” button 2410 (FIG. 24) is clicked, it is determined that “enrollment” has been performed, and when the cancel button 2420 (FIG. 24) is clicked, it is determined that it has not been “enrollment”. I do.
[0095]
If it is determined that it is “enrollment” (step S241: Yes route), the processing shifts to a processing of FIG. On the other hand, when it is determined that it is not “enrollment” (step S241: No route), the web page management unit 500 uses the data stored in the web page data storage unit 510 to change the data of the purchase cancellation confirmation page. It is generated and transmitted to the user terminal 7 (step S243). At this time, the settlement processing unit 506 of the management server 5 clears the data regarding the shortage amount temporarily stored in the storage device such as the work memory area in step S231.
[0096]
The user terminal 7 receives the data of the purchase cancellation confirmation page from the Web page management unit 500 and displays the data on the display device (step S245). Although not shown, the purchase cancellation confirmation page includes a message indicating that the purchase (order) processing of the product has been canceled.
[0097]
In this way, when the prepaid balance runs short, registration as a regular member is urged.
[0098]
FIG. 25 shows a processing flow in the case where it is determined to be “enrollment” in step S241 (FIG. 23) (step S241: Yes route). First, the Web page management unit 500 of the management server 5 generates data of an enrollment page using the data stored in the Web page data storage unit 510, and transmits the generated data to the user terminal 7 (Step S251). The user terminal 7 receives the data of the enrollment page from the Web page management unit 500 and displays the data on the display device (step S253). Although not shown, an enrollment page includes an entry data entry area for inputting data necessary for registering as a regular member, such as an input field for a user's name and a credit card number input field for payment. Is included.
[0099]
Then, the user terminal 7 receives the input of the enrollment data from the user to the enrollment page, and transmits the data to the management server 5 (step S255). The ID management unit 502 of the management server 5 receives the input data from the user terminal 7 and stores the data in the corresponding record (FIG. 2) of the user management DB 512 (Step S257).
[0100]
Further, the ID management unit 502 clears the value of the prepaid member flag column 204 (FIG. 2) of the corresponding record in the user management DB 512, and stores “1” in the regular member flag column 206 (FIG. 2) ( Step S259).
[0101]
Then, the settlement processing unit 506 of the management server 5 determines the shortage amount data temporarily stored in the storage device such as the work memory area in step S231 (FIG. 23) and the prepaid balance of the corresponding record in the user management DB 512. Charging data is generated using the values in column 210 (FIG. 2) and stored in charging DB 516 (step S261). In the present embodiment, two records are registered as in the third and fourth lines in the example shown in FIG. Further, the settlement processing unit 506 updates the value of the prepaid balance column 210 (FIG. 2) of the corresponding record in the user management DB 512 to “0” (step S263).
[0102]
Then, the Web page management unit 500 of the management server 5 generates data of the enrollment completion confirmation page using the data stored in the Web page data storage unit 510, and transmits the data to the user terminal 7 (Step S265). ). The user terminal 7 receives the data of the enrollment completion confirmation page from the Web page management unit 500 and displays the data on the display device (step S267). Although not shown, the enrollment completion confirmation page includes a message notifying that the purchase (order) processing of the product has been completed and a message indicating that the user has been registered as a regular member. Since there are a plurality of settlement methods, billing data may be presented together.
[0103]
In this way, the prepaid member is enrolled as a regular member without reissuing the ID. When a prepaid member is registered as a regular member, some of the price may be reduced as an incentive. Also, some of the amount charged to the presenter of the prepaid key may be reduced.
[0104]
FIG. 26 shows a processing flow when a user who is a prepaid member operates the user terminal 7 to access the management server 5 and registers as a regular member. In the present embodiment, it is assumed that the server is accessed via the Web browser of the user terminal 7, but dedicated client software may be used in some cases. Hereinafter, description will be made based on each processing step.
[0105]
First, the user terminal 7 receives an instruction to select “join” for the displayed menu page from the user, and transmits instruction data to the management server 5 (FIG. 26: step S301). FIG. 7 shows an example of the menu page. For example, a click on the link 700 (FIG. 7) to the member enrollment page is accepted.
[0106]
Returning to the processing flow of FIG. 26, the Web page management unit 500 of the management server 5 receives the instruction data from the user terminal 7 and temporarily stores it in the storage device (FIG. 26: Step S303). Then, the Web page management unit 500 generates data of an enrollment user confirmation page using the data stored in the Web page data storage unit 510, and transmits the data to the user terminal 7 (Step S305). The user terminal 7 receives the data of the joining user confirmation page from the Web page management unit 500 and displays the data on the display device (step S307).
[0107]
FIG. 27 shows an example of the joining user confirmation page. The example of FIG. 27 includes an ID input field 2700, a password input field 2710, and a confirm button 2720. The user inputs the authentication data on the joining user confirmation page, and clicks the OK button 2720. If the user has already logged in, the ID of the logged-in user may be embedded in the ID input field 2700 in advance.
[0108]
Returning to the processing flow of FIG. 26, the user terminal 7 receives the input of the authentication data from the user to the joining user confirmation page (FIG. 27) and transmits the authentication data to the management server 5 (FIG. 26: Step S309). .
[0109]
The Web page management unit 500 of the management server 5 receives the authentication data from the user terminal 7 and temporarily stores the authentication data in the storage device (Step S311). At this time, the ID management unit 502 of the management server 5 checks whether the ID and the password have been correctly input using the data stored in the user management DB 512. If the input is correct, the process is continued, but if the input is not correct, an error is returned and the user is prompted to input again, for example. In addition, the ID management unit 502 uses the data stored in the user management DB 512 to confirm that the ID included in the authentication data is a prepaid member ID. Specifically, it confirms that the value of column 204 (FIG. 2) of the prepaid member flag of the corresponding record in user management DB 512 is “1”. In the case of an ID having another attribute, the process proceeds to, for example, a process of newly issuing an ID, although not shown. However, it may be an error.
[0110]
Then, the Web page management unit 500 of the management server 5 generates data of the enrollment page using the data stored in the Web page data storage unit 510, and transmits the data to the user terminal 7 (Step S313). The user terminal 7 receives the data of the enrollment page from the Web page management unit 500 and displays the data on the display device (step S315). Although not shown, an enrollment page includes an entry data entry field for inputting data necessary for registering as a regular member, such as an entry field for a user's name and a credit card number used for settlement. Is included.
[0111]
Then, the user terminal 7 receives the input of the enrollment data from the user to the enrollment page, and transmits the data to the management server 5 (step S317). The ID management unit 502 of the management server 5 receives the input data from the user terminal 7 and stores it in the corresponding record (FIG. 2) of the user management DB 512 (Step S319).
[0112]
Further, the ID management unit 502 clears the value of the prepaid member flag column 204 (FIG. 2) of the corresponding record in the user management DB 512, and stores “1” in the regular member flag column 206 (FIG. 2) ( Step S321). It should be noted that the value of the prepaid balance column 210 (FIG. 2) is not changed, so that a user who has a remaining prepaid balance can use the remaining amount even if he becomes a regular member.
[0113]
Then, the Web page management unit 500 of the management server 5 generates data of the enrollment completion confirmation page using the data stored in the Web page data storage unit 510, and transmits the data to the user terminal 7 (Step S323). ). The user terminal 7 receives the data of the enrollment completion confirmation page from the Web page management unit 500 and displays the data on the display device (step S325). Although not shown, the enrollment completion confirmation page includes a message indicating that the user has been registered as a regular member.
[0114]
In this way, the prepaid member is enrolled as a regular member without reissuing the ID.
[0115]
Although the embodiment of the present invention has been described above, the present invention is not limited to this. For example, the table configurations shown in FIGS. 2 to 5 are merely examples, and another configuration may be adopted if similar data is stored. Moreover, you may make it add or delete an item as needed. For example, the column 204 of prepaid member flags (FIG. 2) and the column 206 of regular member flags (FIG. 2) may be combined into one column to manage the member status.
[0116]
In addition, the screens shown in FIGS. 7, 8, 9, 11, 12, 13, 13, 14, 16, 17, 18, 19, 21, 22, 24, and 27 are shown. The configuration is an example, and the same contents can be expressed in another mode. Further, the management server 5 may be constituted by a plurality of servers. Further, the functional block configuration of the management server 5 shown in FIG. 1 is an example, and may differ from an actual program / module configuration. Also, for example, a server for realizing online shopping for members is not limited to the management server 5 and may be another dedicated server or the like.
[0117]
Further, the processing flows shown in FIGS. 6, 10, 15, 20, 23, 25, and 26 are also examples, and the order of the processing may be changed within a range in which a similar processing result is obtained. However, steps may be added or deleted as needed.
[0118]
【The invention's effect】
As described above, according to the present invention, a new service related to prepaid payment can be realized. In addition, membership solicitation can be performed at an effective timing.
[Brief description of the drawings]
FIG. 1 is a schematic diagram of a system according to an embodiment of the present invention.
FIG. 2 is a diagram illustrating an example of a table configuration of a user management DB and stored data.
FIG. 3 is a diagram showing an example of a table configuration of a prepaid payment DB and stored data.
FIG. 4 is a diagram showing an example of a table configuration of a billing DB and stored data.
FIG. 5 is a diagram showing an example of a table configuration of a product DB and stored data.
FIG. 6 is a diagram showing a processing flow (part 1) in the embodiment of the present invention.
FIG. 7 is a diagram illustrating an example of a menu page.
FIG. 8 is a diagram illustrating an example of a purchase page.
FIG. 9 is a diagram illustrating an example of a confirmation page.
FIG. 10 is a diagram showing a processing flow (part 2) in the embodiment of the present invention.
FIG. 11 is a diagram showing an example of a gift / mail display screen.
FIG. 12 is a diagram illustrating an example of a temporary receipt confirmation page.
FIG. 13 is a diagram illustrating an example of a password input page.
FIG. 14 is a diagram illustrating an example of a temporary reception completion page.
FIG. 15 is a diagram showing a processing flow (part 3) in the embodiment of the present invention.
FIG. 16 is a diagram showing an example of a received mail display screen.
FIG. 17 is a diagram showing an example of a main reception confirmation page.
FIG. 18 is a diagram illustrating an example of an authentication data input page.
FIG. 19 is a diagram showing an example of a main reception completion page.
FIG. 20 is a diagram showing a processing flow (part 4) in the embodiment of the present invention.
FIG. 21 is a diagram illustrating an example of a shopping page.
FIG. 22 is a diagram illustrating an example of a purchase user confirmation page.
FIG. 23 is a diagram showing a processing flow (part 5) in the embodiment of the present invention.
FIG. 24 is a diagram illustrating an example of a balance shortage notification page.
FIG. 25 is a diagram showing a processing flow (part 6) in the embodiment of the present invention.
FIG. 26 is a diagram showing a processing flow (part 7) in the embodiment of the present invention.
FIG. 27 is a diagram illustrating an example of an enrollment user confirmation page.
[Explanation of symbols]
1 network 3, 7 user terminal 5 management server
500 Web page management unit 502 ID management unit
504 Mail processing unit 506 Payment processing unit
510 Web page data storage
512 User management DB
514 Prepaid Payment DB
516 Billing DB 518 Product DB

Claims (11)

プリペイド方式での決済に用いるためのキーの配布要求を受信した場合、正会員へのＩＤ設定ルールに従ったキーを生成し、記憶装置に格納するプリペイド・キー生成ステップと、
前記記憶装置に格納されたキーを用いた、正会員への登録要求を受信した場合、前記キーを正会員のＩＤとして利用可能なように前記記憶装置に設定する会員登録ステップと、
を含む、コンピュータにより実行される情報処理方法。A prepaid key generating step of generating a key in accordance with an ID setting rule for a regular member and storing the key in a storage device when receiving a key distribution request for use in payment in a prepaid method;
Using a key stored in the storage device, when a registration request to a regular member is received, a member registration step of setting the key in the storage device so that the key can be used as an ID of the regular member;
An information processing method executed by a computer, including: 前記プリペイド・キー生成ステップが、前記キーを特定のユーザに関連付けるステップ
を含む、請求項１記載のコンピュータにより実行される情報処理方法。The computer-implemented information processing method of claim 1, wherein the step of generating a prepaid key comprises the step of associating the key with a particular user. 前記特定のユーザは、正会員として未登録のユーザであることを特徴とする、
請求項２記載のコンピュータにより実行される情報処理方法。The specific user is a user who has not been registered as a regular member,
An information processing method executed by the computer according to claim 2. 前記会員登録ステップが、前記記憶装置に設定される、前記特定のユーザのステータスを表すデータを、正会員を表すデータに変更し、前記記憶装置に設定するステップ
を含む、請求項２記載のコンピュータにより実行される情報処理方法。The computer according to claim 2, wherein the member registration step includes a step of changing data indicating the status of the specific user, which is set in the storage device, to data indicating a regular member and setting the data in the storage device. Information processing method to be executed. 前記キーに対応付けられている金額を超える決済要求を受信した場合、当該決済要求を行ったユーザに正会員登録を促すステップ
をさらに含む、請求項１記載のコンピュータにより実行される情報処理方法。The computer-implemented information processing method according to claim 1, further comprising: when receiving a payment request exceeding an amount associated with the key, prompting a user who made the payment request to register as a regular member. 前記決済要求における決済金額と前記キーに対応付けられている金額との差額を、正会員登録された前記ユーザへの課金データとして課金データ格納部に格納するステップ
をさらに含む、請求項５記載のコンピュータにより実行される情報処理方法。The computer according to claim 5, further comprising: storing a difference between a payment amount in the payment request and an amount associated with the key as charging data for the user registered as a regular member in a charging data storage unit. Information processing method executed by the computer. 前記プリペイド・キー生成ステップが、前記キーに特定のパスワードを関連付けるステップ
を含む、請求項１記載のコンピュータにより実行される情報処理方法。The computer-implemented information processing method according to claim 1, wherein the step of generating a prepaid key includes a step of associating a specific password with the key. 前記会員登録ステップにおいて、前記特定のパスワードを、正会員のＩＤに対応するパスワードとして設定することを特徴とする
請求項７記載のコンピュータにより実行される情報処理方法。8. The computer-implemented information processing method according to claim 7, wherein in the member registration step, the specific password is set as a password corresponding to an ID of a regular member. あるユーザから、プリペイド方式での決済に利用できる金額の指定と当該金額をプリペイド方式の決済に用いるためのキーを特定のユーザに配布する指示とを受け付けた場合、
前記特定のユーザによる前記キーの使用開始が確認された時点において、前記あるユーザにより指定され且つ前記キーに対応付けられている金額を、前記あるユーザへの課金データとして課金データ格納部に格納するステップ
をさらに含む、請求項１記載のコンピュータにより実行される情報処理方法。When receiving from a user a designation of an amount that can be used for prepaid settlement and an instruction to distribute a key for using the amount for the prepaid settlement to a specific user,
When it is confirmed that the specific user has started using the key, an amount specified by the certain user and associated with the key is stored in the charging data storage unit as charging data for the certain user. The computer-implemented information processing method according to claim 1, further comprising a step. 請求項１乃至９のいずれか１つに記載の情報処理方法をコンピュータに実行させるためのプログラム。A program for causing a computer to execute the information processing method according to claim 1. プリペイド方式での決済に用いるためのキーの配布要求を受信した場合、正会員のＩＤ設定ルールに従ったキーを生成し、記憶装置に格納する手段と、
前記記憶装置に格納されたキーを用いた、正会員への登録要求を受信した場合、前記キーを正会員のＩＤとして利用可能なように前記記憶装置に設定する手段と、
を有する情報処理システム。Means for generating a key according to the ID setting rule of a regular member when receiving a key distribution request for use in payment in a prepaid method, and storing the key in a storage device;
Using a key stored in the storage device, when receiving a registration request for a regular member, means for setting the key in the storage device so that the key can be used as an ID of the regular member;
Information processing system having
JP2003137125A 2003-05-15 2003-05-15 Information processing method, program and system related to prepaid settlement system Pending JP2004341793A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2003137125A JP2004341793A (en) 2003-05-15 2003-05-15 Information processing method, program and system related to prepaid settlement system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2003137125A JP2004341793A (en) 2003-05-15 2003-05-15 Information processing method, program and system related to prepaid settlement system

Publications (1)

Publication Number Publication Date
JP2004341793A true JP2004341793A (en) 2004-12-02

Family

ID=33526866

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003137125A Pending JP2004341793A (en) 2003-05-15 2003-05-15 Information processing method, program and system related to prepaid settlement system

Country Status (1)

Country Link
JP (1) JP2004341793A (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007310744A (en) * 2006-05-19 2007-11-29 Rakuten Inc Service providing system, service processor, member information registration method, and member information registration processing program
WO2018185816A1 (en) * 2017-04-03 2018-10-11 株式会社Ｏｎｅ Ｔａｐ ＢＵＹ Purchase system, purchase processing method, purchase server, and computer program
JP2019519050A (en) * 2016-06-22 2019-07-04 アリババ グループ ホウルディング リミテッド Resource processing method and apparatus
JP2020144481A (en) * 2019-03-04 2020-09-10 株式会社ミクシィ Information processing apparatus and information processing program

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007310744A (en) * 2006-05-19 2007-11-29 Rakuten Inc Service providing system, service processor, member information registration method, and member information registration processing program
JP2019519050A (en) * 2016-06-22 2019-07-04 アリババ グループ ホウルディング リミテッド Resource processing method and apparatus
US10805410B2 (en) 2016-06-22 2020-10-13 Alibaba Group Holding Limited Resource processing method and apparatus
US10827016B2 (en) 2016-06-22 2020-11-03 Alibaba Group Holding Limited Resource processing method and apparatus
WO2018185816A1 (en) * 2017-04-03 2018-10-11 株式会社Ｏｎｅ Ｔａｐ ＢＵＹ Purchase system, purchase processing method, purchase server, and computer program
JPWO2018185816A1 (en) * 2017-04-03 2020-02-20 株式会社Ｏｎｅ Ｔａｐ ＢＵＹ Purchase system, purchase processing method, purchase target server, and computer program
JP2020144481A (en) * 2019-03-04 2020-09-10 株式会社ミクシィ Information processing apparatus and information processing program

Similar Documents

Publication Publication Date Title
US10360570B2 (en) System and method for conducting a gift value transaction
US7536351B2 (en) User-to-user payment service with payee-specific pay pages
US8612343B2 (en) Network based payment service capable of generating coding for adding payment objects to pages of external sites
JP5405704B2 (en) Method and apparatus for ordering goods, services and content over an internetwork using a virtual payment account
CN103797502B (en) E-commerce platform without cookie
JPH11296587A (en) Electronic mall server, electronic mall client, electronic mall system and storing medium
JP2003524240A (en) Method and apparatus for processing electronic commerce using an electronic token
JP2008123475A (en) Online coupon distribution method
JP2001216441A (en) Method for performing electronic commerce while using electronic token
JP2009507279A (en) Secure Internet e-commerce system
US20090307102A1 (en) System and method for providing donations
WO2014140688A1 (en) System for management and activation of conditional bid offers
WO2012106148A2 (en) Method and system for facilitating electronic commerce
JP5196730B2 (en) Electronic shopping mall system
JP2010165048A (en) Method for supporting commercial transaction via network, server apparatus, program, and recording medium
JP2002236834A (en) Electronic commerce method
JP2004062545A (en) Management method and management system for valuable value information and valuable value information management program
JP2004341793A (en) Information processing method, program and system related to prepaid settlement system
JP4679048B2 (en) Electronic ticket management / distribution system and electronic ticket distribution server
JP2002056207A (en) Method and system for transacting merchandise coupon
KR20110035571A (en) Apparatus and method for providing shopping service using widget
JP2002163528A (en) Benefit management device, chargeable service management device, point service providing system and point service providing method
KR102383017B1 (en) Method and system for blockchain-based mobile anonymous non-currency payment
JP2003006528A (en) Order information connecting method, order information connecting program, order information connecting device, order receiving method, order receiving program and order receiving device
JP3552098B2 (en) Information processing method and information processing apparatus

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060508

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090331

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090525

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090804