(57)【要約】【課題】プリペイド形式の決済に関連する新規なサービスを実現する。【解決手段】プリペイド方式での決済に用いるためのキーの配布要求を受信した場合、正会員のＩＤ設定ルールに従ったキーを生成し、記憶装置に格納するプリペイド・キー生成ステップと、記憶装置に格納されたキーを用いた、正会員への登録要求を受信した場合、当該キーを正会員のＩＤとして利用可能なように記憶装置に設定する会員登録ステップとを含む。これにより、プリペイド・キーをそのまま正会員のＩＤとして継続使用することができ、改めて正会員用のＩＤを発行する手間やＩＤの重複管理を省くことができる。【選択図】  図１
2004341793.tif 000002
【特許請求の範囲】
【請求項１】
プリペイド方式での決済に用いるためのキーの配布要求を受信した場合、正会員へのＩＤ設定ルールに従ったキーを生成し、記憶装置に格納するプリペイド・キー生成ステップと、
前記記憶装置に格納されたキーを用いた、正会員への登録要求を受信した場合、前記キーを正会員のＩＤとして利用可能なように前記記憶装置に設定する会員登録ステップと、
を含む、コンピュータにより実行される情報処理方法。
【請求項２】
前記プリペイド・キー生成ステップが、前記キーを特定のユーザに関連付けるステップ
を含む、請求項１記載のコンピュータにより実行される情報処理方法。
【請求項３】
前記特定のユーザは、正会員として未登録のユーザであることを特徴とする、
請求項２記載のコンピュータにより実行される情報処理方法。
【請求項４】
前記会員登録ステップが、前記記憶装置に設定される、前記特定のユーザのステータスを表すデータを、正会員を表すデータに変更し、前記記憶装置に設定するステップ
を含む、請求項２記載のコンピュータにより実行される情報処理方法。
【請求項５】
前記キーに対応付けられている金額を超える決済要求を受信した場合、当該決済要求を行ったユーザに正会員登録を促すステップ
をさらに含む、請求項１記載のコンピュータにより実行される情報処理方法。
【請求項６】
前記決済要求における決済金額と前記キーに対応付けられている金額との差額を、正会員登録された前記ユーザへの課金データとして課金データ格納部に格納するステップ
をさらに含む、請求項５記載のコンピュータにより実行される情報処理方法。
【請求項７】
前記プリペイド・キー生成ステップが、前記キーに特定のパスワードを関連付けるステップ
を含む、請求項１記載のコンピュータにより実行される情報処理方法。
【請求項８】
前記会員登録ステップにおいて、前記特定のパスワードを、正会員のＩＤに対応するパスワードとして設定することを特徴とする
請求項７記載のコンピュータにより実行される情報処理方法。
【請求項９】
あるユーザから、プリペイド方式での決済に利用できる金額の指定と当該金額をプリペイド方式の決済に用いるためのキーを特定のユーザに配布する指示とを受け付けた場合、
前記特定のユーザによる前記キーの使用開始が確認された時点において、前記あるユーザにより指定され且つ前記キーに対応付けられている金額を、前記あるユーザへの課金データとして課金データ格納部に格納するステップ
をさらに含む、請求項１記載のコンピュータにより実行される情報処理方法。
【請求項１０】
請求項１乃至９のいずれか１つに記載の情報処理方法をコンピュータに実行させるためのプログラム。
【請求項１１】
プリペイド方式での決済に用いるためのキーの配布要求を受信した場合、正会員のＩＤ設定ルールに従ったキーを生成し、記憶装置に格納する手段と、
前記記憶装置に格納されたキーを用いた、正会員への登録要求を受信した場合、前記キーを正会員のＩＤとして利用可能なように前記記憶装置に設定する手段と、
を有する情報処理システム。
【発明の詳細な説明】
【０００１】
【発明が属する技術分野】
本発明は、プリペイド方式での決済に関連するサービスのための情報処理技術に関する。
【０００２】
【従来の技術】
プロバイダの会員サービスとして、特定のプロバイダの会員が、当該プロバイダの他の会員に対してプロバイダの利用料をギフトとしてオンラインで贈呈できるサービスが一般的に存在している。このようなギフト（以下、オンライン・ギフトと呼ぶ）を受け取った会員は、贈呈者である会員が指定した金額分については、無料でプロバイダを利用することができる。すなわち、贈呈者である会員が、プリペイド方式の利用権を購入し、他の会員に贈るような形態となっており、贈呈者である会員に対して利用権分の金額が課金される。また、このようなオンライン・ギフトを利用することができるユーザを、プロバイダの会員に限定しない場合もある。
【０００３】
例えば、プリペイド方式のメール・サービスを提供する技術が存在する（特許文献１参照）。すなわち、ユーザ情報を格納するユーザ情報ファイルと、アクセスしてきたユーザのメール・アカウントをユーザ情報に基づいて認証する認証サーバと、認証されたメール・アカウントに対してインターネット・メール処理を行うメール・サーバと、メール・サーバの使用に応じて該当メール・アカウントの限定使用条件をチェックするとともにこの限定使用条件から外れたメール・アカウントの使用を禁止するアカウント管理部とから構成され、ユーザからの申し込みに基づいて限定使用条件をもったインターネット・メール・アカウントを発行するプリペイド・メール・システムが存在する。
【０００４】
【特許文献１】
特開２００２−１５２２４５号公報
【０００５】
【発明が解決しようとする課題】
しかしながら以上の技術においては、オンライン・ギフト又は一時メール・アカウントを入手したユーザは、当該オンライン・ギフト又は一時メール・アカウントに設定された金額や時間を特定のプロバイダの利用権として使用することができるが、それ以外の例えばオンライン・ショッピング等に使用することはできない。そのため、ユーザにとって利用範囲が狭いものになっていた。また、オンライン・ギフト又は一時メール・アカウントを利用したユーザが、プロバイダの正会員として登録されていないが、続けてサービスを利用するために正会員として登録されることを欲する場合には、改めてＩＤの発行を受け、正会員として別途登録される必要がある。その際、プリペイド方式の利用に用いていたデータは基本的に引き継げず、新たに設定されるため、ユーザにとって管理が煩わしいものになっていた。
【０００６】
従って本発明の目的は、プリペイド形式の決済に関連する新規なサービスを実現するための技術を提供することである。
【０００７】
なお、本発明の他の目的は、入会勧誘のための新規な技術を提供することである。
【０００８】
【課題を解決するための手段】
本発明に係る情報処理方法は、プリペイド方式での決済に用いるためのキー（以下、プリペイド・キーと呼ぶ）の配布要求を受信した場合、正会員のＩＤ設定ルールに従ったキーを生成し、記憶装置に格納するプリペイド・キー生成ステップと、記憶装置に格納されたキーを用いた、正会員への登録要求を受信した場合、当該キーを正会員のＩＤとして利用可能なように記憶装置に設定する会員登録ステップとを含む。
【０００９】
これにより、プリペイド・キーをそのまま正会員のＩＤとして継続使用することができ、改めて正会員用のＩＤを発行する手間やＩＤの重複管理を省くことができる。
【００１０】
また、上で述べたプリペイド・キー生成ステップが、キーを特定のユーザに関連付けるステップを含むようにしてもよい。これにより、プリペイド・キーを利用するユーザを指定することができ、プリペイド・キーを例えばオンライン・ギフトとして特定のユーザに贈呈することが可能となる。例えば、プリペイド・キーと当該プリペイド・キーを利用するユーザのメール・アドレスとを含むレコードを記憶装置に格納しておく。
【００１１】
また、上記特定のユーザは、正会員として未登録のユーザであるものとしてもよい。これにより、プロバイダの正会員として未登録のユーザが、続けてサービスを利用するために正会員として登録されることを欲する場合には、改めてＩＤの発行を受けることなく、正会員として登録される。すなわち、ユーザはプリペイド・キーを正会員のユーザＩＤとしてそのまま利用できるようになる。
【００１２】
また、上で述べた会員登録ステップが、記憶装置に設定される、特定のユーザのステータスを表すデータを、正会員を表すデータに変更し、記憶装置に設定するステップを含むようにしてもよい。このように、ユーザのステータスを変更して正会員への移行処理を行うことにより、ＩＤの新規発行を不要とするスムーズな正会員登録が実現できる。また、システム側の管理が容易になる。
【００１３】
また、キーに対応付けられている金額を超える決済要求を受信した場合、当該決済要求を行ったユーザに正会員登録を促すステップをさらに含むようにしてもよい。ここで、キーに対応付けられている金額とは、当該キーを利用することによりプリペイド方式での決済が可能となるプリペイド残高を指し、ユーザが決済を行うことにより、決済金額分だけ少なくなっていくものである。そして、上で述べたように不足が発生した際に正会員登録を促すことにより、効果的なタイミングで入会の勧誘を行うことができる。
【００１４】
また、決済要求における決済金額とキーに対応付けられている金額との差額を、正会員として登録されたユーザへの課金データとして課金データ格納部に格納するステップをさらに含むようにしてもよい。これにより、ユーザは、正会員になることによってプリペイド残高の不足分を正会員に提供される手段で決済することができるようになる。例えば、足りない分をクレジット・カード等で決済するものである。
【００１５】
また、上で述べたプリペイド・キー生成ステップが、キーに特定のパスワードを関連付けるステップを含むようにしてもよい。これにより、プリペイド・キーを利用するユーザを、特定のパスワードを知るユーザに限定することができる。例えば、プリペイド・キーと当該プリペイド・キーを利用するユーザが設定したパスワードとを含むレコードを記憶装置に格納しておく。
【００１６】
また、上で述べた会員登録ステップにおいて、上記特定のパスワードを、正会員のＩＤに対応するパスワードとして設定するようにしてもよい。これにより、ユーザは、正会員になったとしても、それまでに使い慣れたパスワードをそのまま利用し続けることができる。
【００１７】
また、あるユーザから、プリペイド方式での決済に利用できる金額の指定と当該金額をプリペイド方式の決済に用いるためのキーを特定のユーザに配布する指示とを受け付けた場合、上記特定のユーザによるキーの使用開始が確認された時点において、あるユーザにより指定され且つキーに対応付けられている金額を、あるユーザへの課金データとして課金データ格納部に格納するステップをさらに含むようにしてもよい。
【００１８】
これにより、他のユーザにプリペイド・キーを贈呈したユーザには、自己の指定した贈呈金額が、贈呈されたユーザのプリペイド・キーの使用開始が確認された際に、課金される。従って、プリペイド・キーを贈呈しようとしても、贈呈されるユーザがプリペイド・キーの使用を拒否した場合等には課金が発生せず、ユーザにとって無駄な出費を抑えることができる。
【００１９】
なお、本発明に係る情報処理方法をコンピュータに実行させるプログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してデジタル信号として頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリに一時保管される。
【００２０】
【発明の実施の形態】
本発明の一実施の形態に係るシステム構成図を図１に示す。例えばインターネットであるネットワーク１には、管理サーバ５と、例えばパーソナル・コンピュータである１又は複数のユーザ端末３及びユーザ端末７とが、無線又は有線によって接続されている。ユーザ端末３及びユーザ端末７は、図示していないウェブ（Ｗｅｂ）ブラウザ機能とメーラ機能とを有し、Ｗｅｂページの閲覧とメールの送受信及び閲覧とを可能とさせている。なお、ユーザ端末３及びユーザ端末７は、Ｗｅｂブラウザ機能及びメーラ機能を有する携帯電話機やその他の携帯情報端末等であってもよい。
【００２１】
また、管理サーバ５には、Ｗｅｂページ管理部５００とＩＤ管理部５０２とメール処理部５０４と決済処理部５０６とが含まれている。これらの処理内容については処理フローの説明において述べるが、管理サーバ５は、この他に図示していないＷｅｂサーバ機能を有しており、Ｗｅｂページ・データの生成・送信処理を行えるようになっている。さらに、管理サーバ５は、Ｗｅｂページ・データ格納部５１０とユーザ管理ＤＢ５１２とプリペイド決済ＤＢ５１４と課金ＤＢ５１６と商品ＤＢ５１８とを管理している。Ｗｅｂページ・データ格納部５１０には、後に例示するＷｅｂページのデータや、管理サーバ５が提供するその他のＷｅｂページのデータが格納されている。
【００２２】
図２に、ユーザ管理ＤＢ５１２のテーブル構成及び格納されるデータの一例を示す。図２の例には、ＩＤの列２００とパスワードの列２０２とプリペイド会員フラグの列２０４と正会員フラグの列２０６とメール・アドレスの列２０８とプリペイド残高の列２１０と氏名の列２１２とクレジット・カード番号の列２１４とＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）の列２１６とが含まれている。この他、図示していないが、登録日時の列やユーザの住所の列等、ユーザ管理に必要なデータを格納するための列が含まれている。
【００２３】
このユーザ管理ＤＢ５１２のテーブルには、プリペイド・キーを利用する非会員ユーザ（以下、プリペイド会員と呼ぶ）と、会員として登録済みのユーザ（以下、正会員と呼ぶ）とに関するレコードが登録されている。なお、プリペイド会員については、プリペイド・キーを、そのままユーザＩＤとして扱うような仕組みになっている。
【００２４】
ＩＤの列２００には、プリペイド・キー、すなわちプリペイド会員のユーザＩＤと、正会員のユーザＩＤとが格納される。すなわち、プリペイド・キーと正会員のユーザＩＤとは同様のネーミング・ルールで生成され、区別なく管理される。但し、ＩＤのストリング構成により、プリペイド会員又はプリペイド会員経由で正会員になったことが分かるようにしてもよい。
【００２５】
そして、ユーザがプリペイド会員である場合、プリペイド会員フラグの列２０４に「０」又は「１」と設定され、ユーザが正会員である場合、正会員フラグの列２０６に「１」と設定される。なお、プリペイド・キーの利用にあたっては、使用開始登録が必要であり、プリペイド会員のうち、ユーザＩＤの発行、プリペイド・キーの贈呈がなされており、且つ未だ使用開始登録をしていないユーザについては、プリペイド会員フラグの列２０４に「０」と設定される。一方、プリペイド会員のうち、プリペイド・キーの使用開始登録を行ったユーザについては、プリペイド会員フラグの列２０４に「１」と設定される。
【００２６】
プリペイド残高の列２１０には、プリペイド方式での決済が可能な金額が格納される。この金額は、プリペイド・キーの生成時に設定された金額を初期値として、プリペイド方式での決済がなされることにより少なくなっていく。決済金額によっては、１回の決済で「０」になることもある。また、氏名の列２１２とクレジット・カード番号の列２１４とには、ユーザが正会員である場合に、値が格納される。
【００２７】
また、ＵＲＬの列２１６には、ユーザ固有のＵＲＬデータが格納される。例えばユーザがプリペイド会員であり、ユーザＩＤの発行、プリペイド・キーの贈呈がなされており、且つ未だ使用開始登録をしていない場合には、使用開始登録用のＷｅｂページのＵＲＬデータが格納される。なお、本実施の形態においては、使用開始登録には仮受領確認と本受領確認との２つのステップが存在し、使用開始登録がどこまで進んでいるかによってＵＲＬが異なるため、仮受領確認ＵＲＬと本受領確認ＵＲＬとの共通のパスが格納されるようになっている。例えば、「ｈｔｔｐ：／／ｗｗｗ．＊＊＊＊．ｃｏｍ／ｐｒｅｐａｉｄ／￣ＧＩＦ１２３４５／」というデータが格納される。これに、例えば「ｋａｒｉｊｕｒｙｏ．ｈｔｍｌ」や「ｈｏｎｊｕｒｙｏ．ｈｔｍｌ」というデータを追加することにより、ユーザ固有のＵＲＬを生成するようになっている。
【００２８】
図３に、プリペイド決済ＤＢ５１４のテーブル構成及び格納されるデータの一例を示す。図３の例には、決済番号の列３００と贈呈者ＩＤの列３０２と受領者ＩＤの列３０４と商品ＩＤの列３０６と購入金額の列３０８と課金フラグの列３１０とが含まれている。この他、図示していないが、決済日時の列等、プリペイド・キーの購入や贈呈に関するデータを格納するための列が含まれている。
【００２９】
このプリペイド決済ＤＢ５１４には、プリペイド・キーの贈呈処理が行われた際にレコードが登録される。図３の例では、１行目のレコードより、「ＡＡＡ０００００」というユーザＩＤを持つユーザが、特定のユーザに対して例えば５００円分のプリペイド・キーの贈呈処理がなされたことが分かる。１行目のレコードの受領者ＩＤの列３０４には「ＧＩＦ１２３４５」という値が格納されているが、この値はプリペイド・キーそのものでもあり、贈呈先となるプリペイド会員のユーザＩＤでもある。
【００３０】
課金フラグの列３１０には、贈呈者ＩＤの列３０２に示されるユーザに課金がなされた場合に「１」が設定される。この課金フラグの列３１０には、受領者ＩＤの列３０４に示されるユーザによってプリペイド・キーの使用開始登録がなされるまでは、初期値の「０」が設定されており、ユーザに課金されないようになっている。
【００３１】
図４に、課金ＤＢ５１６のテーブル構成及び格納されるデータの一例を示す。図４の例には、課金番号の列４００と購入者ＩＤの列４０２と購入商品ＩＤの列４０４と購入金額の列４０６と支払方法の列４０８とが含まれている。この他、図示していないが、購入日時の列等、商品の購入に関するデータを格納するための列が含まれている。
【００３２】
この課金ＤＢ５１６には、ユーザがオンラインで商品を購入した場合にレコードが登録される。図４の例では、３行目のレコードと４行目のレコードとでは、課金番号の列４００の値、購入者ＩＤ４０２の値及び購入商品ＩＤ４０４の値が同じになっているが、これは、例えば３００円の商品をプリペイド方式で１００円分決済し、残りの２００円分を例えばクレジット・カード等、会員が通常行う決済方法で決済するような場合におけるレコードであるためである。課金番号を別々に設定するようにしてもよい。
【００３３】
図５に、商品ＤＢ５１８のテーブル構成及び格納されるデータの一例を示す。図５の例には、商品ＩＤの列５５０と商品属性の列５５２と商品名の列５５４と単価の列５５６とが含まれている。この他、図示していないが、メーカ・コード等、商品に関するデータを格納するための列が含まれている。この商品ＤＢ５１８には、ユーザがオンラインで購入可能な商品に関するレコードが登録されている。
【００３４】
次に、図６乃至図２７を用いて図１に示したシステムの処理内容について説明する。図６には、ユーザが例えばユーザ端末３を操作して管理サーバ５にアクセスし、プリペイド・キーの贈呈を行う際の処理フローが示されている。以下、各処理ステップに基づき説明していく。なお、これより前にログイン処理が行われているものとする。
【００３５】
まず、ユーザ端末３は、ユーザの操作に従い、オンライン・ギフト購入ページのデータの要求を管理サーバ５に対して送信する（図６：ステップＳ１）。本実施の形態においては、ユーザ端末３が有するＷｅｂブラウザを介してサーバにアクセスすることを想定しているが、専用のクライアント・ソフトウェアを使用する場合もある。
【００３６】
図７に、メニュー・ページの一例を示す。図７の例には、会員入会ページへのリンク部７００とギフト券購入ページへのリンク部７１０とが含まれている。会員入会ページへのリンク部７００がクリックされると会員入会ページへの移行がなされ、ギフト券購入ページへのリンク部７１０がクリックされるとギフト券購入ページへの移行がなされる。ここで、「（オンライン）ギフト券」とは、プリペイド・キーを指しているが、各Ｗｅｂページにおいては、ユーザがイメージしやすいように仮想的な「（オンライン）ギフト券」という表現を用いている。
【００３７】
図６の処理フローに戻り、管理サーバ５のＷｅｂページ管理部５００は、オンライン・ギフト券購入ページのデータの要求をユーザ端末３から受信する（図６：ステップＳ３）。そして、Ｗｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いてオンライン・ギフト券購入ページのデータを生成し、ユーザ端末３に対して送信する（ステップＳ５）。ユーザ端末３は、オンライン・ギフト券購入ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ７）。
【００３８】
図８に、オンライン・ギフト券購入ページの一例を示す。図８の例には、受取人のメール・アドレス入力欄８００と金額設定用プルダウン・リスト８１０とコメント入力欄８２０と送信ボタン８３０とが含まれている。ユーザは、このオンライン・ギフト券購入ページに対して必要なデータを入力し、送信ボタン８３０をクリックする。
【００３９】
図６の処理フローに戻り、ユーザ端末３は、オンライン・ギフト券購入ページ（図８）に対するユーザからの入力を受け付け、受け付けたデータを管理サーバ５に対して送信する（図６：ステップＳ９）。管理サーバ５のＷｅｂページ管理部５００は、オンライン・ギフト券購入ページ（図８）に対するユーザからの入力データをユーザ端末３から受信し、一旦記憶装置に格納する（ステップＳ１１）。
【００４０】
そして、Ｗｅｂページ管理部５００は、入力内容確認ページのデータを生成し、ユーザ端末３に対して送信する（ステップＳ１３）。なお、入力内容をチェックし、エラーがあった場合には、エラー・メッセージを返すようにしてもよい。ユーザ端末３は、入力内容確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ１５）。
【００４１】
図９に、入力内容確認ページの一例を示す。図９の例には、受取人のメール・アドレス表示欄９００と金額表示欄９１０とコメント表示欄９２０と確認ボタン９３０とが含まれている。ユーザは、この入力内容確認ページに示されているデータに間違いがないか確認し、確認ボタン９３０をクリックする。各表示欄に対してユーザが修正入力可能なようにしてもよいし、図示しないキャンセル・ボタン等が含まれていてもよい。
【００４２】
図６の処理フローに戻り、ユーザ端末３は、入力内容確認ページ（図９）に対するユーザからの選択入力を受け付け、選択入力データを管理サーバ５に対して送信する（図６：ステップＳ１７）。管理サーバ５のＷｅｂページ管理部５００は、選択入力データをユーザ端末３から受信し、一旦記憶装置に格納する（ステップＳ１９）。
【００４３】
そして、Ｗｅｂページ管理部５００は、オンライン・ギフト券の購入処理を行ってもよい（ＯＫ）かどうか判定する（ステップＳ２１）。例えば、入力内容確認ページ（図９）において図示しないキャンセル・ボタンがクリックされた場合や、ユーザの入力内容をチェックしてエラーが発見された場合等には、オンライン・ギフト券の購入処理を行ってはいけない（ＯＫではない）と判断する。
【００４４】
ＯＫではないと判定された場合（ステップＳ２１：Ｎｏルート）、ステップＳ５の処理に戻る。一方、ＯＫであると判定された場合（ステップＳ２１：Ｙｅｓルート）、管理サーバ５のＩＤ管理部５０２は、プリペイド会員データを生成し、ユーザ管理ＤＢ５１２に格納する（ステップＳ２３）。すなわち、ユーザ管理ＤＢ５１２に新規のレコードが１件登録される。なお、登録されるレコードのプリペイド会員フラグの列２０４（図２）には「０」が格納される。また、ＵＲＬの列２１６に、上で述べたようなユーザ固有のＵＲＬデータ（パス）が格納される。なお、この時点では、登録されるレコードのパスワードの列２０２（図２）と正会員フラグの列２０６（図２）と氏名の列２１２（図２）とクレジット・カード番号の列２１４（図２）とには、値が格納されない。
【００４５】
そして、管理サーバ５の決済処理部５０６は、贈呈者ＩＤと受領者ＩＤと商品ＩＤと購入金額とを含むプリペイド決済データを生成し、プリペイド決済ＤＢ５１４に格納する（ステップＳ２５）。すなわち、プリペイド決済ＤＢ５１４に贈呈者ＩＤと受領者ＩＤと商品ＩＤと購入金額とを含む新規のレコードが１件登録される。なお、登録されるレコードの課金フラグの列３１０（図３）には「０」が格納される。
【００４６】
そして、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて処理完了確認ページのデータを生成し、ユーザ端末３に対して送信する（ステップＳ２７）。ユーザ端末３は処理完了確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ２９）。図示しないが、処理完了確認ページには、例えば「オンライン・ギフト券の購入を受け付けました。」等のメッセージが含まれる。
【００４７】
このようにして、オンライン・ギフト券の購入が受け付けられ、プリペイド・キーが生成される。ステップＳ２７の処理が終わると、処理は端子Ａを介して図１０の処理に移行する。
【００４８】
図１０には、プリペイド・キーの贈呈先であるユーザが、例えばユーザ端末７を操作して管理サーバ５にアクセスし、プリペイド・キーを仮受領する際の処理フローが示されている。以下、各処理ステップに基づき説明していく。
【００４９】
まず、管理サーバ５のメール処理部５０４は、Ｗｅｂページ・データ格納部５１０に格納されているデータとユーザ管理ＤＢ５１２に格納されているデータとを用いてギフト・メールのデータを生成し、プリペイド・キーの贈呈先であるユーザ宛てに送信する（ステップＳ４１）。ユーザ端末７は、ユーザの操作に従い、図示しないメール・サーバを介して管理サーバ５からのギフト・メールのデータを受信し、表示装置に表示する（ステップＳ４３）。
【００５０】
図１１に、ギフト・メールの表示画面の一例を示す。図１１の例には、贈呈元ユーザ表示部１１００とメッセージ表示部１１１０と仮受領確認用ＵＲＬ表示部１１２０とが含まれている。贈呈元ユーザ表示部１１００には、贈呈元であるユーザの氏名（ユーザ管理ＤＢ５１２の氏名の列２１２（図２）の値）が含まれており、誰からの贈呈か分かるようになっている。メッセージ表示部１１１０には、オンライン・ギフト券購入ページ（図８）においてコメント入力欄８２０に入力されたデータが示される。仮受領確認用ＵＲＬ表示部１１２０には、仮受領確認ページのＵＲＬが示されているが、メーラの機能及びその設定によっては、ＵＲＬがハイパー・リンクになっている場合もある。
【００５１】
図１０の処理フローに戻り、ユーザ端末７は、例えば仮受領確認用ＵＲＬ表示部１１２０（図１１）に示されているＵＲＬに基づきＷｅｂページにアクセスするというユーザの指示に従い、仮受領確認ページ・データの要求を管理サーバ５に対して送信する（図１０：ステップＳ４５）。管理サーバ５のＷｅｂページ管理部５００は、仮受領確認ページ・データの要求をユーザ端末７から受信する（ステップＳ４７）。そして、Ｗｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータとユーザ管理ＤＢ５１２に格納されているデータとプリペイド決済ＤＢ５１４に格納されているデータとを用いて仮受領確認ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ４９）。ユーザ端末７は、仮受領確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ５１）。
【００５２】
図１２に、仮受領確認ページの一例を示す。図１２の例には、差出人メール・アドレス表示部１２００と受領人メール・アドレス表示部１２１０と金額表示部１２２０と受領ボタン１２３０と受領拒否ボタン１２４０とが含まれている。差出人メール・アドレス表示部１２００には、贈呈元であるユーザのメール・アドレスが示されているが、図１１に示した贈呈元ユーザ表示部１１００と同様に、ユーザの氏名を示すようにしてもよい。
【００５３】
図１０の処理フローに戻り、ユーザ端末７は、ユーザからの仮受領確認ページ（図１２）に対する選択入力を受け付け、管理サーバ５に対して送信する（図１０：ステップＳ５３）。管理サーバ５のＷｅｂページ管理部５００は、選択入力データをユーザ端末７から受信し、一旦記憶装置に格納する（ステップＳ５５）。
【００５４】
そして、Ｗｅｂページ管理部５００は、ユーザからの選択入力が「受領」であったかどうか判定する（ステップＳ５７）。仮受領確認ページ（図１２）において、ユーザによって受領ボタン１２３０がクリックされた場合には「受領」と判定し、受領拒否ボタン１２４０がクリックされた場合には「受領」ではないと判定する。
【００５５】
「受領」ではないと判定された場合（ステップＳ５７：Ｎｏルート）、管理サーバ５のメール処理部５０４は、ユーザ管理ＤＢ５１２に格納されているデータを用いて受領拒否通知メールのデータを生成し、贈呈者（贈呈元のユーザ）宛てに送信する（ステップＳ５９）。受領拒否通知メールには、図示しないが、オンライン・ギフト券を受け取ってもらえなかった旨のメッセージが含まれる。なお、この場合、プリペイド・キーの贈呈に関する一連の処理は終了する。ユーザ管理ＤＢ５１２から該当するレコードを削除してもよい。
【００５６】
一方、「受領」であったと判定された場合（ステップＳ５７：Ｙｅｓルート）、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いてパスワード入力ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ６１）。ユーザ端末７は、パスワード入力ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ６３）。
【００５７】
図１３に、パスワード入力ページの一例を示す。図１３の例には、パスワード入力欄１３００と確定ボタン１３１０とが含まれている。ユーザは、パスワード入力欄１３００にパスワードを入力し、確定ボタン１３１０をクリックする。なお、パスワード入力欄１３００は、ユーザからの入力文字をそのまま表示せず、アスタリスクで示すようになっている。そこで、入力ミスをチェックするために、パスワード入力欄が複数設けられる場合もある。
【００５８】
図１０の処理フローに戻り、ユーザ端末７は、ユーザからのパスワード入力ページ（図１３）に対するパスワードの入力を受け付け、管理サーバ５に対して送信する（図１０：ステップＳ６５）。管理サーバ５のＩＤ管理部５０２は、パスワードをユーザ端末７から受信し、ユーザ管理ＤＢ５１２のパスワードの列２０２（図２）に格納する（ステップＳ６７）。なお、該当するレコードは、例えばメール・アドレスの列２０８（図２）の値に基づき特定する。
【００５９】
そして、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータとユーザ管理ＤＢ５１２に格納されているデータとを用いて仮受領完了ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ６９）。ユーザ端末７は、仮受領完了ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ７１）。
【００６０】
図１４に、仮受領完了ページの一例を示す。図１４の例には、プリペイド・キー表示部１４００とＯＫボタン１４１０とが含まれている。ユーザは、プリペイド・キー表示部１４００に示された自分のＩＤを確認し、ＯＫボタン１４１０をクリックする。
【００６１】
このようにして、プリペイド・キーの仮受領処理が行われる。ステップＳ６９の処理が終わると、処理は端子Ｂを介して図１５の処理に移行する。
【００６２】
図１５には、プリペイド・キーの贈呈先であり且つプリペイド・キーの仮受領を既に行ったユーザが、例えばユーザ端末７を操作して管理サーバ５にアクセスし、プリペイド・キーを本受領する際の処理フローが示されている。以下、各処理ステップに基づき説明していく。
【００６３】
まず、管理サーバ５のメール処理部５０４は、Ｗｅｂページ・データ格納部５１０に格納されているデータとユーザ管理ＤＢ５１２に格納されているデータとを用いて本受領メールのデータを生成し、プリペイド・キーの贈呈先であるユーザ宛てに送信する（ステップＳ８１）。ユーザ端末７は、ユーザの操作に従い、図示しないメール・サーバを介して管理サーバ５からの本受領メールのデータを受信し、表示装置に表示する（ステップＳ８３）。
【００６４】
図１６に、本受領メールの表示画面の一例を示す。図１６の例には、本受領確認用ＵＲＬ表示部１６００が含まれている。本受領確認用ＵＲＬ表示部１６００には、本受領確認ページのＵＲＬが示されているが、メーラの機能及びその設定によっては、ＵＲＬがハイパー・リンクになっている場合もある。
【００６５】
図１５の処理フローに戻り、ユーザ端末７は、例えば本受領確認用ＵＲＬ表示部１６００（図１６）に示されているＵＲＬに基づきＷｅｂページにアクセスするというユーザの指示に従い、本受領確認ページ・データの要求を管理サーバ５に対して送信する（図１５：ステップＳ８５）。管理サーバ５のＷｅｂページ管理部５００は、本受領確認ページ・データの要求をユーザ端末７から受信する（ステップＳ８７）。そして、Ｗｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータとユーザ管理ＤＢ５１２に格納されているデータとプリペイド決済ＤＢ５１４に格納されているデータとを用いて本受領確認ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ８９）。ユーザ端末７は、本受領確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ９１）。
【００６６】
図１７に、本受領確認ページの一例を示す。図１７の例には、差出人メール・アドレス表示部１７００と受領人メール・アドレス表示部１７１０と金額表示部１７２０と「受領する」ボタン１７３０とが含まれている。差出人メール・アドレス表示部１７００には、贈呈元であるユーザのメール・アドレスが示されているが、ユーザの氏名を示すようにしてもよい。ユーザは、各表示部の内容を確認し、「受領する」ボタン１７３０をクリックする。
【００６７】
図１５の処理フローに戻り、ユーザ端末７は、ユーザからの本受領確認ページ（図１７）に対する選択入力を受け付け、管理サーバ５に対して送信する（図１５：ステップＳ９３）。管理サーバ５のＷｅｂページ管理部５００は、選択入力データをユーザ端末７から受信し、一旦記憶装置に格納する（ステップＳ９５）。なお、ここでのユーザからの選択入力は「受領する」である。
【００６８】
そして、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて認証データ入力ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ９７）。ユーザ端末７は、認証データ入力ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ９９）。
【００６９】
図１８に、認証データ入力ページの一例を示す。図１８の例には、ＩＤ入力欄１８００とパスワード入力欄１８１０と確定ボタン１８２０とが含まれている。ユーザは、仮受領完了ページ（図１４）において確認したプリペイド・キーをＩＤ入力欄１８００に入力し、パスワード入力ページ（図１３）において設定したパスワードをパスワード入力欄１８１０に入力し、確定ボタン１８２０をクリックする。
【００７０】
図１５の処理フローに戻り、ユーザ端末７は、ユーザからの認証データ入力ページ（図１８）に対するＩＤ（プリペイド・キー）及びパスワードの入力を受け付け、管理サーバ５に対して送信する（図１５：ステップＳ１０１）。管理サーバ５のＷｅｂページ管理部５００は、ＩＤ及びパスワードをユーザ端末７から受信し、一旦記憶装置に格納する（ステップＳ１０３）。その際、管理サーバ５のＩＤ管理部５０２は、ＩＤ及びパスワードが正しく入力されたか、ユーザ管理ＤＢ５１２に格納されているデータを用いてチェックする。正しく入力されていればそのまま処理を続行するが、正しく入力されていなければエラーを返し、例えばユーザに再入力を促す。
【００７１】
そして、ＩＤ管理部５０２は、ユーザ管理ＤＢ５１２のプリペイド会員フラグ２０４（図２）の値を「０」から「１」に更新する（ステップＳ１０５）。さらに、管理サーバ５の決済処理部５０６は、プリペイド決済ＤＢ５１４の該当するレコードの課金フラグの列３１０（図３）の値を「０」から「１」に更新し、当該レコードのデータを用いて課金データを生成し、課金データＤＢ５１６に格納する（ステップＳ１０７）。すなわち、プリペイド・キーの贈呈先ユーザをプリペイド会員として本登録し、それに伴い、プリペイド・キーの贈呈元ユーザに課金する処理が行われる。
【００７２】
そして、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて本受領完了ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ１０９）。ユーザ端末７は、本受領完了ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ１１１）。
【００７３】
図１９に、本受領完了ページの一例を示す。図１９の例には、メッセージ入力欄１９００とバリュー移行用ハイパー・リンク１９１０とＯＫボタン１９２０とが含まれている。バリュー移行用ハイパー・リンク１９１０がクリックされると、ユーザが受領したプリペイド・キーのバリュー（残高）を、当該プリペイド・キーとは異なる既存のＩＤに移すためのページに移行する。なお、バリューの移行処理は銀行振替のような処理であり、本発明の要旨ではないため説明を割愛する。例えばユーザは、メッセージ入力欄１９００にメッセージを入力し、ＯＫボタン１９２０をクリックする。
【００７４】
図１５の処理フローに戻り、ユーザ端末７は、ユーザからの本受領完了ページ（図１９）に対する選択入力を受け付け、管理サーバ５に対して送信する（図１５：ステップＳ１１３）。管理サーバ５のＷｅｂページ管理部５００は、選択入力データをユーザ端末７から受信し、一旦記憶装置に格納する（ステップＳ１１５）。なお、ここでのユーザからの選択入力は「ＯＫ」とする。
【００７５】
そして、管理サーバ５のメール処理部５０４は、受領通知メールのデータを生成し、贈呈者（贈呈元のユーザ）宛てに送信する（ステップＳ１１７）。受領通知メールには、図示しないが、オンライン・ギフト券の受け取りがなされた旨のメッセージと本受領完了ページのメッセージ入力欄１９００（図１９）に入力されたメッセージとが含まれる。また、課金に関するデータ（金額や支払日等）が含まれる場合もある。
【００７６】
このようにして、プリペイド・キーの本受領処理が行われる。そして、本受領処理を行いプリペイド会員となったユーザは、受領したプリペイド・キーを用いて商品の購入や有償コンテンツの閲覧等を行うことが可能となる。
【００７７】
図２０には、プロバイダの会員（プリペイド会員を含む）であるユーザが例えばユーザ端末７を操作して管理サーバ５にアクセスし、オンライン・ショッピングを行う際の処理フローが示されている。本実施の形態においては、ユーザ端末７が有するＷｅｂブラウザを介してサーバにアクセスすることを想定しているが、専用のクライアント・ソフトウェアを使用する場合もある。以下、各処理ステップに基づき説明していく。
【００７８】
まず、ユーザ端末７は、表示しているＷｅｂページに対するユーザからの商品購入指示を受け付け、指示データを管理サーバ５に対して送信する（図２０：ステップＳ２０１）。
【００７９】
例えば、図２１に示すようなショッピング・ページに対するユーザからの商品購入指示を受け付ける。図２１の例には、商品データ表示部２０００と「購入する」ボタン２１００とが含まれている。「購入する」ボタン２１００がクリックされることにより、Ａ商品の購入指示を受け付ける。なお、図２１では簡略化した例を示しているが、一般的なオンライン・ショッピングにおける「買い物かご」や「ショッピング・カート」等、複数の購入候補商品についての会計内容を表示し、購入指示を受け付けるようなページであってもよい。
【００８０】
図２０の処理フローに戻り、管理サーバ５のＷｅｂページ管理部５００は、購入指示データをユーザ端末７から受信し、一旦記憶装置に格納する（図２０：ステップＳ２０３）。なお、購入指示データには、商品名、単価、数量、合計金額等の会計データが含まれているものとする。
【００８１】
そして、Ｗｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて購入ユーザ確認ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ２０５）。ユーザ端末７は、購入ユーザ確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ２０７）。
【００８２】
図２２に、購入ユーザ確認ページの一例を示す。図２２の例には、会計データ表示部２２００とＩＤ入力欄２２１０とパスワード入力欄２２２０と確定ボタン２２３０とが含まれている。ユーザは、この購入ユーザ確認ページに対して認証データを入力し、確定ボタン２２３０をクリックする。例えば複数のＩＤを保有しているユーザは、課金するＩＤを入力する。なお、ユーザが既にログイン済みである場合には、ログインしているユーザのＩＤを予めＩＤ入力欄２２１０に埋め込んでおくようにしてもよい。
【００８３】
図２０の処理フローに戻り、ユーザ端末７は、購入ユーザ確認ページ（図２２）に対するユーザからの認証データの入力を受け付け、購入データを管理サーバ５に対して送信する（図２０：ステップＳ２０９）。なお、購入データには、商品の会計データとユーザの認証データとが含まれているものとする。
【００８４】
管理サーバ５のＷｅｂページ管理部５００は、購入データをユーザ端末７から受信し、一旦記憶装置に格納する（ステップＳ２１１）。その際、管理サーバ５のＩＤ管理部５０２は、ＩＤ及びパスワードが正しく入力されたか、ユーザ管理ＤＢ５１２に格納されているデータを用いてチェックする。また、ＩＤ管理部５０２は、購入データに含まれるＩＤが課金可能なＩＤであるかチェックし、課金不可能なＩＤであればエラーを返す。具体的には、ユーザ管理ＤＢ５１２の該当するレコードの、プリペイド会員フラグの列２０４（図２）の値が「１」である又は正会員フラグの列２０６（図２）の値が「１」である場合には、課金可能である。
【００８５】
さらに、ＩＤ管理部５０２は、ユーザ管理ＤＢ５１２に格納されているデータを用いて、商品を購入するユーザ（課金されるＩＤ）がプリペイド会員であるかどうか判定する（ステップＳ２１３）。ユーザ管理ＤＢ５１２の該当するレコードのプリペイド会員フラグの列２０４（図２）の値が「１」であれば、プリペイド会員であると判定する。
【００８６】
プリペイド会員ではないと判定された場合（ステップＳ２１３：Ｎｏルート）、後に述べるステップＳ２１９の処理に移行する。
【００８７】
一方、プリペイド会員であると判定された場合（ステップＳ２１３：Ｙｅｓルート）、管理サーバ５の決済処理部５０６は、購入データとユーザ管理ＤＢ５１２に格納されているデータとを用いて、プリペイド残高が不足しているかどうか判定する（ステップＳ２１５）。具体的には、ユーザ管理ＤＢ５１２の該当するレコードのプリペイド残高の列２１０（図２）の値が、購入データに含まれる会計金額より少ない場合には、残高不足であると判定する。
【００８８】
残高不足であると判定された場合（ステップＳ２１５：Ｙｅｓルート）、処理は端子Ｃを介して図２３の処理に移行する。一方、残高不足ではないと判定された場合（ステップＳ２１５：Ｎｏルート）、管理サーバ５の決済処理部５０６は、ユーザ管理ＤＢ５１２の該当するレコードのプリペイド残高の列２１０（図２）の値を更新する（ステップＳ２１７）。すなわち、会計金額分だけ残高を減らす。そして、管理サーバ５の決済管理部５０６は、購入データを用いて課金データを生成し、課金ＤＢ５１６に格納する（ステップＳ２１９）。なお、プリペイド方式での課金データは、決済が既に済んでいるため、課金ＤＢ５１６に格納しないようにしてもよい。
【００８９】
そして、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて決済確認ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ２２１）。ユーザ端末７は、決済確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ２２３）。図示しないが、決済確認ページには、商品の購入（注文）処理が完了したことを通知するメッセージが含まれる。
【００９０】
このようにして、プリペイド会員を含むプロバイダの会員ユーザによるオンライン・ショッピングにおける処理が行われる。
【００９１】
図２３には、ステップＳ２１５（図２０）において残高不足であると判定された場合（ステップＳ２１５：Ｙｅｓルート）の処理フローが示されている。まず、管理サーバ５の決済処理部５０６は、プリペイド残高の不足分の金額を例えばワーク・メモリ領域等の記憶装置に一時格納する（ステップＳ２３１）。そして、管理サーバ５のＷｅｂページ管理部５００は、プリペイド残高データとＷｅｂページ・データ格納部５１０に格納されているデータとを用いて残高不足通知ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ２３３）。ユーザ端末７は、残高不足通知ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ２３５）。
【００９２】
図２４に、残高不足通知ページの一例を示す。図２４の例には、メッセージ表示部２４００と「入会手続きへ」ボタン２４１０とキャンセル・ボタン２４２０とが含まれている。ユーザは、メッセージ表示部２４００に示されているメッセージを確認し、直ちに入会手続きを実施することを希望する場合には、「入会手続きへ」ボタン２４１０をクリックする。
【００９３】
図２３の処理フローに戻り、ユーザ端末７は、残高不足通知ページ（図２４）に対するユーザからの選択入力を受け付け、管理サーバ５に対して送信する（図２３：ステップＳ２３７）。管理サーバ５のＷｅｂページ管理部５００は、選択入力データをユーザ端末７から受信し、一旦記憶装置に格納する（ステップＳ２３９）。
【００９４】
そして、Ｗｅｂページ管理部５００は、残高不足通知ページ（図２４）に対するユーザからの選択入力が「入会」であったかどうか判定する（ステップＳ２４１）。例えば「入会手続きへ」ボタン２４１０（図２４）がクリックされた場合には「入会」であったと判定し、キャンセル・ボタン２４２０（図２４）がクリックされた場合には「入会」ではなかったと判定する。
【００９５】
「入会」であったと判定された場合（ステップＳ２４１：Ｙｅｓルート）、処理は端子Ｄを介して図２５の処理に移行する。一方、「入会」ではなかったと判定された場合（ステップＳ２４１：Ｎｏルート）、Ｗｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて購入キャンセル確認ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ２４３）。またこの際、管理サーバ５の決済処理部５０６は、ステップＳ２３１においてワーク・メモリ領域等の記憶装置に一時格納しておいた不足金額に関するデータをクリアする。
【００９６】
ユーザ端末７は、購入キャンセル確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ２４５）。図示しないが、購入キャンセル確認ページには、商品の購入（注文）処理を取りやめた旨のメッセージが含まれる。
【００９７】
このようにして、プリペイド残高が不足した場合には、正会員としての登録を促すようになっている。
【００９８】
図２５には、ステップＳ２４１（図２３）において「入会」であると判定された場合（ステップＳ２４１：Ｙｅｓルート）の処理フローが示されている。まず、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて入会ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ２５１）。ユーザ端末７は、入会ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ２５３）。図示しないが、入会ページには、ユーザの氏名の入力欄や、決済に使用するクレジット・カードの番号入力欄等、正会員として登録するために必要なデータを入力するための、入会用データ入力欄が含まれる。
【００９９】
そして、ユーザ端末７は、入会ページに対するユーザからの入会用データの入力を受け付け、管理サーバ５に対して送信する（ステップＳ２５５）。管理サーバ５のＩＤ管理部５０２は、入力用データをユーザ端末７から受信し、ユーザ管理ＤＢ５１２の該当するレコード（図２）に格納する（ステップＳ２５７）。
【０１００】
さらに、ＩＤ管理部５０２は、ユーザ管理ＤＢ５１２の該当するレコードの、プリペイド会員フラグの列２０４（図２）の値をクリアし、正会員フラグの列２０６（図２）に「１」を格納する（ステップＳ２５９）。
【０１０１】
そして、管理サーバ５の決済処理部５０６は、ステップＳ２３１（図２３）においてワーク・メモリ領域等の記憶装置に一時格納しておいた不足金額データと、ユーザ管理ＤＢ５１２の該当するレコードのプリペイド残高の列２１０（図２）の値とを用いて課金データを生成し、課金ＤＢ５１６に格納する（ステップＳ２６１）。本実施の形態においては、図４に示した例の３行目及び４行目のように２レコード登録される。さらに、決済処理部５０６は、ユーザ管理ＤＢ５１２の該当するレコードのプリペイド残高の列２１０（図２）の値を「０」に更新する（ステップＳ２６３）。
【０１０２】
そして、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて入会完了確認ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ２６５）。ユーザ端末７は、入会完了確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ２６７）。図示しないが、入会完了確認ページには、商品の購入（注文）処理が完了したことを通知するメッセージと、ユーザが正会員として登録された旨のメッセージとが含まれる。なお、決済方式が複数になるため、課金データも併せて提示するようにしてもよい。
【０１０３】
このようにして、プリペイド会員にはＩＤの再発行をすることなく正会員としての入会手続きが行われる。なお、プリペイド会員が正会員として登録された場合には、インセンティブとして代金のいくらかを減額するようにしてもよい。また、プリペイド・キーの贈呈者に課金されている金額のいくらかを減額するようにしてもよい。
【０１０４】
図２６には、プリペイド会員であるユーザが例えばユーザ端末７を操作して管理サーバ５にアクセスし、正会員として登録する際の処理フローが示されている。本実施の形態においては、ユーザ端末７が有するＷｅｂブラウザを介してサーバにアクセスすることを想定しているが、専用のクライアント・ソフトウェアを使用する場合もある。以下、各処理ステップに基づき説明していく。
【０１０５】
まず、ユーザ端末７は、表示しているメニュー・ページに対するユーザからの「入会」の選択指示を受け付け、指示データを管理サーバ５に対して送信する（図２６：ステップＳ３０１）。メニュー・ページについては、図７に一例を示したが、例えば会員入会ページへのリンク部７００（図７）のクリックを受け付ける。
【０１０６】
図２６の処理フローに戻り、管理サーバ５のＷｅｂページ管理部５００は、指示データをユーザ端末７から受信し、一旦記憶装置に格納する（図２６：ステップＳ３０３）。そして、Ｗｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて入会ユーザ確認ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ３０５）。ユーザ端末７は、入会ユーザ確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ３０７）。
【０１０７】
入会ユーザ確認ページの一例を図２７に示す。図２７の例には、ＩＤ入力欄２７００とパスワード入力欄２７１０と確定ボタン２７２０とが含まれている。ユーザは、この入会ユーザ確認ページに対して認証データを入力し、確定ボタン２７２０をクリックする。なお、ユーザが既にログイン済みである場合には、ログインしているユーザのＩＤを予めＩＤ入力欄２７００に埋め込んでおくようにしてもよい。
【０１０８】
図２６の処理フローに戻り、ユーザ端末７は、入会ユーザ確認ページ（図２７）に対するユーザからの認証データの入力を受け付け、認証データを管理サーバ５に対して送信する（図２６：ステップＳ３０９）。
【０１０９】
管理サーバ５のＷｅｂページ管理部５００は、認証データをユーザ端末７から受信し、一旦記憶装置に格納する（ステップＳ３１１）。その際、管理サーバ５のＩＤ管理部５０２は、ＩＤ及びパスワードが正しく入力されたか、ユーザ管理ＤＢ５１２に格納されているデータを用いてチェックする。正しく入力されていればそのまま処理を続行するが、正しく入力されていなければエラーを返し、例えばユーザに再入力を促す。また、ＩＤ管理部５０２は、ユーザ管理ＤＢ５１２に格納されているデータを用いて、認証データに含まれるＩＤがプリペイド会員のＩＤであることを確認する。具体的には、ユーザ管理ＤＢ５１２の該当するレコードの、プリペイド会員フラグの列２０４（図２）の値が「１」であることを確認する。その他の属性のＩＤの場合には、図示していないが、例えば新規にＩＤを発行する処理に移行する。但し、エラーとしてもよい。
【０１１０】
そして、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて入会ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ３１３）。ユーザ端末７は、入会ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ３１５）。図示しないが、入会ページには、ユーザの氏名の入力欄や、決済に使用するクレジット・カードの番号入力欄等、正会員として登録するために必要なデータを入力するための、入会用データ入力欄が含まれる。
【０１１１】
そして、ユーザ端末７は、入会ページに対するユーザからの入会用データの入力を受け付け、管理サーバ５に対して送信する（ステップＳ３１７）。管理サーバ５のＩＤ管理部５０２は、入力用データをユーザ端末７から受信し、ユーザ管理ＤＢ５１２の該当するレコード（図２）に格納する（ステップＳ３１９）。
【０１１２】
さらに、ＩＤ管理部５０２は、ユーザ管理ＤＢ５１２の該当するレコードの、プリペイド会員フラグの列２０４（図２）の値をクリアし、正会員フラグの列２０６（図２）に「１」を格納する（ステップＳ３２１）。なお、プリペイド残高の列２１０（図２）の値は変更しないため、プリペイドの残高が残っているユーザは、正会員になっても残りの金額分を利用することが可能である。
【０１１３】
そして、管理サーバ５のＷｅｂページ管理部５００は、Ｗｅｂページ・データ格納部５１０に格納されているデータを用いて入会完了確認ページのデータを生成し、ユーザ端末７に対して送信する（ステップＳ３２３）。ユーザ端末７は、入会完了確認ページのデータをＷｅｂページ管理部５００から受信し、表示装置に表示する（ステップＳ３２５）。図示しないが、入会完了確認ページには、ユーザが正会員として登録された旨のメッセージ等が含まれる。
【０１１４】
このようにして、プリペイド会員にはＩＤの再発行をすることなく正会員としての入会手続きが行われる。
【０１１５】
以上本発明の一実施の形態について説明したが、本発明はこれに限定されるものではない。例えば図２乃至図５に示したテーブル構成は一例であって、同様のデータを格納するためであれば、別の構成を採用するようにしてもよい。また、必要に応じて項目を追加又は削除するようにしてもよい。例えば、プリペイド会員フラグの列２０４（図２）と正会員フラグの列２０６（図２）とを１つの列にまとめて、会員のステータスを管理するようにしてもよい。
【０１１６】
また、図７、図８、図９、図１１、図１２、図１３、図１４、図１６、図１７、図１８、図１９、図２１、図２２、図２４及び図２７に示した画面構成は一例であって、同様の内容を別の態様にて表現することも可能である。また、管理サーバ５が複数のサーバによって構成されていてもよい。さらに、図１に示した管理サーバ５の機能ブロック構成は一例であって、実際のプログラム・モジュール構成とは異なる場合がある。また、例えば会員向けのオンライン・ショッピングを実現するためのサーバは、管理サーバ５に限らず別の専用サーバ等であってもよい。
【０１１７】
また、図６、図１０、図１５、図２０、図２３、図２５及び図２６に示した処理フローも一例であって、同様の処理結果が得られる範囲において処理の順序を入れ替えてもよいし、必要に応じてステップを追加又は削除してもよい。
【０１１８】
【発明の効果】
以上述べたように、本発明によれば、プリペイド形式の決済に関連する新規なサービスを実現することができる。また、効果的なタイミングで入会勧誘を行うことができる。
【図面の簡単な説明】
【図１】本発明の実施の形態におけるシステム概要図である。
【図２】ユーザ管理ＤＢのテーブル構成及び格納されるデータの一例を示す図である。
【図３】プリペイド決済ＤＢのテーブル構成及び格納されるデータの一例を示す図である。
【図４】課金ＤＢのテーブル構成及び格納されるデータの一例を示す図である。
【図５】商品ＤＢのテーブル構成及び格納されるデータの一例を示す図である。
【図６】本発明の実施の形態における処理フロー（その１）を示す図である。
【図７】メニュー・ページの一例を示す図である。
【図８】購入ページの一例を示す図である。
【図９】確認ページの一例を示す図である。
【図１０】本発明の実施の形態における処理フロー（その２）を示す図である。
【図１１】ギフト・メール表示画面の一例を示す図である。
【図１２】仮受領確認ページの一例を示す図である。
【図１３】パスワード入力ページの一例を示す図である。
【図１４】仮受領完了ページの一例を示す図である。
【図１５】本発明の実施の形態における処理フロー（その３）を示す図である。
【図１６】本受領メール表示画面の一例を示す図である。
【図１７】本受領確認ページの一例を示す図である。
【図１８】認証データ入力ページの一例を示す図である。
【図１９】本受領完了ページの一例を示す図である。
【図２０】本発明の実施の形態における処理フロー（その４）を示す図である。
【図２１】ショッピング・ページの一例を示す図である。
【図２２】購入ユーザ確認ページの一例を示す図である。
【図２３】本発明の実施の形態における処理フロー（その５）を示す図である。
【図２４】残高不足通知ページの一例を示す図である。
【図２５】本発明の実施の形態における処理フロー（その６）を示す図である。
【図２６】本発明の実施の形態における処理フロー（その７）を示す図である。
【図２７】入会ユーザ確認ページの一例を示す図である。
【符号の説明】
１  ネットワーク    ３，７  ユーザ端末    ５  管理サーバ
５００  Ｗｅｂページ管理部    ５０２  ＩＤ管理部
５０４  メール処理部    ５０６  決済処理部
５１０  Ｗｅｂページ・データ格納部
５１２  ユーザ管理ＤＢ
５１４  プリペイド決済ＤＢ
５１６  課金ＤＢ    ５１８  商品ＤＢ
【図１】
2004341793.tif 000003
【図２】
2004341793.tif 000004
【図３】
2004341793.tif 000005
【図４】
2004341793.tif 000006
【図５】
2004341793.tif 000007
【図６】
2004341793.tif 000008
【図７】
2004341793.tif 000009
【図８】
2004341793.tif 000010
【図９】
2004341793.tif 000011
【図１０】
2004341793.tif 000012
【図１１】
2004341793.tif 000013
【図１２】
2004341793.tif 000014
【図１３】
2004341793.tif 000015
【図１４】
2004341793.tif 000016
【図１５】
2004341793.tif 000017
【図１６】
2004341793.tif 000018
【図１７】
2004341793.tif 000019
【図１８】
2004341793.tif 000020
【図１９】
2004341793.tif 000021
【図２０】
2004341793.tif 000022
【図２１】
2004341793.tif 000023
【図２２】
2004341793.tif 000024
【図２３】
2004341793.tif 000025
【図２４】
2004341793.tif 000026
【図２５】
2004341793.tif 000027
【図２６】
2004341793.tif 000028
【図２７】
2004341793.tif 000029