JP2004341793A - プリペイド決済方式に関連する情報処理方法及びプログラム並びにシステム - Google Patents
プリペイド決済方式に関連する情報処理方法及びプログラム並びにシステム Download PDFInfo
- 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
Links
- 230000010365 information processing Effects 0.000 title claims abstract description 16
- 238000003672 processing method Methods 0.000 title claims abstract description 14
- 238000000034 method Methods 0.000 claims description 30
- 238000013500 data storage Methods 0.000 claims description 26
- 238000007726 management method Methods 0.000 description 187
- 238000012545 processing Methods 0.000 description 78
- 238000012790 confirmation Methods 0.000 description 59
- 238000010586 diagram Methods 0.000 description 28
- 230000006870 function Effects 0.000 description 7
- 238000012546 transfer Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 230000007704 transition Effects 0.000 description 3
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 2
- 238000013479 data entry Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
【課題】プリペイド形式の決済に関連する新規なサービスを実現する。
【解決手段】プリペイド方式での決済に用いるためのキーの配布要求を受信した場合、正会員のID設定ルールに従ったキーを生成し、記憶装置に格納するプリペイド・キー生成ステップと、記憶装置に格納されたキーを用いた、正会員への登録要求を受信した場合、当該キーを正会員のIDとして利用可能なように記憶装置に設定する会員登録ステップとを含む。これにより、プリペイド・キーをそのまま正会員のIDとして継続使用することができ、改めて正会員用のIDを発行する手間やIDの重複管理を省くことができる。
【選択図】 図1
【解決手段】プリペイド方式での決済に用いるためのキーの配布要求を受信した場合、正会員のID設定ルールに従ったキーを生成し、記憶装置に格納するプリペイド・キー生成ステップと、記憶装置に格納されたキーを用いた、正会員への登録要求を受信した場合、当該キーを正会員のIDとして利用可能なように記憶装置に設定する会員登録ステップとを含む。これにより、プリペイド・キーをそのまま正会員のIDとして継続使用することができ、改めて正会員用のIDを発行する手間やIDの重複管理を省くことができる。
【選択図】 図1
Description
【0001】
【発明が属する技術分野】
本発明は、プリペイド方式での決済に関連するサービスのための情報処理技術に関する。
【0002】
【従来の技術】
プロバイダの会員サービスとして、特定のプロバイダの会員が、当該プロバイダの他の会員に対してプロバイダの利用料をギフトとしてオンラインで贈呈できるサービスが一般的に存在している。このようなギフト(以下、オンライン・ギフトと呼ぶ)を受け取った会員は、贈呈者である会員が指定した金額分については、無料でプロバイダを利用することができる。すなわち、贈呈者である会員が、プリペイド方式の利用権を購入し、他の会員に贈るような形態となっており、贈呈者である会員に対して利用権分の金額が課金される。また、このようなオンライン・ギフトを利用することができるユーザを、プロバイダの会員に限定しない場合もある。
【0003】
例えば、プリペイド方式のメール・サービスを提供する技術が存在する(特許文献1参照)。すなわち、ユーザ情報を格納するユーザ情報ファイルと、アクセスしてきたユーザのメール・アカウントをユーザ情報に基づいて認証する認証サーバと、認証されたメール・アカウントに対してインターネット・メール処理を行うメール・サーバと、メール・サーバの使用に応じて該当メール・アカウントの限定使用条件をチェックするとともにこの限定使用条件から外れたメール・アカウントの使用を禁止するアカウント管理部とから構成され、ユーザからの申し込みに基づいて限定使用条件をもったインターネット・メール・アカウントを発行するプリペイド・メール・システムが存在する。
【0004】
【特許文献1】
特開2002−152245号公報
【0005】
【発明が解決しようとする課題】
しかしながら以上の技術においては、オンライン・ギフト又は一時メール・アカウントを入手したユーザは、当該オンライン・ギフト又は一時メール・アカウントに設定された金額や時間を特定のプロバイダの利用権として使用することができるが、それ以外の例えばオンライン・ショッピング等に使用することはできない。そのため、ユーザにとって利用範囲が狭いものになっていた。また、オンライン・ギフト又は一時メール・アカウントを利用したユーザが、プロバイダの正会員として登録されていないが、続けてサービスを利用するために正会員として登録されることを欲する場合には、改めてIDの発行を受け、正会員として別途登録される必要がある。その際、プリペイド方式の利用に用いていたデータは基本的に引き継げず、新たに設定されるため、ユーザにとって管理が煩わしいものになっていた。
【0006】
従って本発明の目的は、プリペイド形式の決済に関連する新規なサービスを実現するための技術を提供することである。
【0007】
なお、本発明の他の目的は、入会勧誘のための新規な技術を提供することである。
【0008】
【課題を解決するための手段】
本発明に係る情報処理方法は、プリペイド方式での決済に用いるためのキー(以下、プリペイド・キーと呼ぶ)の配布要求を受信した場合、正会員のID設定ルールに従ったキーを生成し、記憶装置に格納するプリペイド・キー生成ステップと、記憶装置に格納されたキーを用いた、正会員への登録要求を受信した場合、当該キーを正会員のIDとして利用可能なように記憶装置に設定する会員登録ステップとを含む。
【0009】
これにより、プリペイド・キーをそのまま正会員のIDとして継続使用することができ、改めて正会員用のIDを発行する手間やIDの重複管理を省くことができる。
【0010】
また、上で述べたプリペイド・キー生成ステップが、キーを特定のユーザに関連付けるステップを含むようにしてもよい。これにより、プリペイド・キーを利用するユーザを指定することができ、プリペイド・キーを例えばオンライン・ギフトとして特定のユーザに贈呈することが可能となる。例えば、プリペイド・キーと当該プリペイド・キーを利用するユーザのメール・アドレスとを含むレコードを記憶装置に格納しておく。
【0011】
また、上記特定のユーザは、正会員として未登録のユーザであるものとしてもよい。これにより、プロバイダの正会員として未登録のユーザが、続けてサービスを利用するために正会員として登録されることを欲する場合には、改めてIDの発行を受けることなく、正会員として登録される。すなわち、ユーザはプリペイド・キーを正会員のユーザIDとしてそのまま利用できるようになる。
【0012】
また、上で述べた会員登録ステップが、記憶装置に設定される、特定のユーザのステータスを表すデータを、正会員を表すデータに変更し、記憶装置に設定するステップを含むようにしてもよい。このように、ユーザのステータスを変更して正会員への移行処理を行うことにより、IDの新規発行を不要とするスムーズな正会員登録が実現できる。また、システム側の管理が容易になる。
【0013】
また、キーに対応付けられている金額を超える決済要求を受信した場合、当該決済要求を行ったユーザに正会員登録を促すステップをさらに含むようにしてもよい。ここで、キーに対応付けられている金額とは、当該キーを利用することによりプリペイド方式での決済が可能となるプリペイド残高を指し、ユーザが決済を行うことにより、決済金額分だけ少なくなっていくものである。そして、上で述べたように不足が発生した際に正会員登録を促すことにより、効果的なタイミングで入会の勧誘を行うことができる。
【0014】
また、決済要求における決済金額とキーに対応付けられている金額との差額を、正会員として登録されたユーザへの課金データとして課金データ格納部に格納するステップをさらに含むようにしてもよい。これにより、ユーザは、正会員になることによってプリペイド残高の不足分を正会員に提供される手段で決済することができるようになる。例えば、足りない分をクレジット・カード等で決済するものである。
【0015】
また、上で述べたプリペイド・キー生成ステップが、キーに特定のパスワードを関連付けるステップを含むようにしてもよい。これにより、プリペイド・キーを利用するユーザを、特定のパスワードを知るユーザに限定することができる。例えば、プリペイド・キーと当該プリペイド・キーを利用するユーザが設定したパスワードとを含むレコードを記憶装置に格納しておく。
【0016】
また、上で述べた会員登録ステップにおいて、上記特定のパスワードを、正会員のIDに対応するパスワードとして設定するようにしてもよい。これにより、ユーザは、正会員になったとしても、それまでに使い慣れたパスワードをそのまま利用し続けることができる。
【0017】
また、あるユーザから、プリペイド方式での決済に利用できる金額の指定と当該金額をプリペイド方式の決済に用いるためのキーを特定のユーザに配布する指示とを受け付けた場合、上記特定のユーザによるキーの使用開始が確認された時点において、あるユーザにより指定され且つキーに対応付けられている金額を、あるユーザへの課金データとして課金データ格納部に格納するステップをさらに含むようにしてもよい。
【0018】
これにより、他のユーザにプリペイド・キーを贈呈したユーザには、自己の指定した贈呈金額が、贈呈されたユーザのプリペイド・キーの使用開始が確認された際に、課金される。従って、プリペイド・キーを贈呈しようとしても、贈呈されるユーザがプリペイド・キーの使用を拒否した場合等には課金が発生せず、ユーザにとって無駄な出費を抑えることができる。
【0019】
なお、本発明に係る情報処理方法をコンピュータに実行させるプログラムは、例えばフレキシブル・ディスク、CD−ROM、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してデジタル信号として頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリに一時保管される。
【0020】
【発明の実施の形態】
本発明の一実施の形態に係るシステム構成図を図1に示す。例えばインターネットであるネットワーク1には、管理サーバ5と、例えばパーソナル・コンピュータである1又は複数のユーザ端末3及びユーザ端末7とが、無線又は有線によって接続されている。ユーザ端末3及びユーザ端末7は、図示していないウェブ(Web)ブラウザ機能とメーラ機能とを有し、Webページの閲覧とメールの送受信及び閲覧とを可能とさせている。なお、ユーザ端末3及びユーザ端末7は、Webブラウザ機能及びメーラ機能を有する携帯電話機やその他の携帯情報端末等であってもよい。
【0021】
また、管理サーバ5には、Webページ管理部500とID管理部502とメール処理部504と決済処理部506とが含まれている。これらの処理内容については処理フローの説明において述べるが、管理サーバ5は、この他に図示していないWebサーバ機能を有しており、Webページ・データの生成・送信処理を行えるようになっている。さらに、管理サーバ5は、Webページ・データ格納部510とユーザ管理DB512とプリペイド決済DB514と課金DB516と商品DB518とを管理している。Webページ・データ格納部510には、後に例示するWebページのデータや、管理サーバ5が提供するその他のWebページのデータが格納されている。
【0022】
図2に、ユーザ管理DB512のテーブル構成及び格納されるデータの一例を示す。図2の例には、IDの列200とパスワードの列202とプリペイド会員フラグの列204と正会員フラグの列206とメール・アドレスの列208とプリペイド残高の列210と氏名の列212とクレジット・カード番号の列214とURL(Uniform Resource Locator)の列216とが含まれている。この他、図示していないが、登録日時の列やユーザの住所の列等、ユーザ管理に必要なデータを格納するための列が含まれている。
【0023】
このユーザ管理DB512のテーブルには、プリペイド・キーを利用する非会員ユーザ(以下、プリペイド会員と呼ぶ)と、会員として登録済みのユーザ(以下、正会員と呼ぶ)とに関するレコードが登録されている。なお、プリペイド会員については、プリペイド・キーを、そのままユーザIDとして扱うような仕組みになっている。
【0024】
IDの列200には、プリペイド・キー、すなわちプリペイド会員のユーザIDと、正会員のユーザIDとが格納される。すなわち、プリペイド・キーと正会員のユーザIDとは同様のネーミング・ルールで生成され、区別なく管理される。但し、IDのストリング構成により、プリペイド会員又はプリペイド会員経由で正会員になったことが分かるようにしてもよい。
【0025】
そして、ユーザがプリペイド会員である場合、プリペイド会員フラグの列204に「0」又は「1」と設定され、ユーザが正会員である場合、正会員フラグの列206に「1」と設定される。なお、プリペイド・キーの利用にあたっては、使用開始登録が必要であり、プリペイド会員のうち、ユーザIDの発行、プリペイド・キーの贈呈がなされており、且つ未だ使用開始登録をしていないユーザについては、プリペイド会員フラグの列204に「0」と設定される。一方、プリペイド会員のうち、プリペイド・キーの使用開始登録を行ったユーザについては、プリペイド会員フラグの列204に「1」と設定される。
【0026】
プリペイド残高の列210には、プリペイド方式での決済が可能な金額が格納される。この金額は、プリペイド・キーの生成時に設定された金額を初期値として、プリペイド方式での決済がなされることにより少なくなっていく。決済金額によっては、1回の決済で「0」になることもある。また、氏名の列212とクレジット・カード番号の列214とには、ユーザが正会員である場合に、値が格納される。
【0027】
また、URLの列216には、ユーザ固有のURLデータが格納される。例えばユーザがプリペイド会員であり、ユーザIDの発行、プリペイド・キーの贈呈がなされており、且つ未だ使用開始登録をしていない場合には、使用開始登録用のWebページのURLデータが格納される。なお、本実施の形態においては、使用開始登録には仮受領確認と本受領確認との2つのステップが存在し、使用開始登録がどこまで進んでいるかによってURLが異なるため、仮受領確認URLと本受領確認URLとの共通のパスが格納されるようになっている。例えば、「http://www.****.com/prepaid/ ̄GIF12345/」というデータが格納される。これに、例えば「karijuryo.html」や「honjuryo.html」というデータを追加することにより、ユーザ固有のURLを生成するようになっている。
【0028】
図3に、プリペイド決済DB514のテーブル構成及び格納されるデータの一例を示す。図3の例には、決済番号の列300と贈呈者IDの列302と受領者IDの列304と商品IDの列306と購入金額の列308と課金フラグの列310とが含まれている。この他、図示していないが、決済日時の列等、プリペイド・キーの購入や贈呈に関するデータを格納するための列が含まれている。
【0029】
このプリペイド決済DB514には、プリペイド・キーの贈呈処理が行われた際にレコードが登録される。図3の例では、1行目のレコードより、「AAA00000」というユーザIDを持つユーザが、特定のユーザに対して例えば500円分のプリペイド・キーの贈呈処理がなされたことが分かる。1行目のレコードの受領者IDの列304には「GIF12345」という値が格納されているが、この値はプリペイド・キーそのものでもあり、贈呈先となるプリペイド会員のユーザIDでもある。
【0030】
課金フラグの列310には、贈呈者IDの列302に示されるユーザに課金がなされた場合に「1」が設定される。この課金フラグの列310には、受領者IDの列304に示されるユーザによってプリペイド・キーの使用開始登録がなされるまでは、初期値の「0」が設定されており、ユーザに課金されないようになっている。
【0031】
図4に、課金DB516のテーブル構成及び格納されるデータの一例を示す。図4の例には、課金番号の列400と購入者IDの列402と購入商品IDの列404と購入金額の列406と支払方法の列408とが含まれている。この他、図示していないが、購入日時の列等、商品の購入に関するデータを格納するための列が含まれている。
【0032】
この課金DB516には、ユーザがオンラインで商品を購入した場合にレコードが登録される。図4の例では、3行目のレコードと4行目のレコードとでは、課金番号の列400の値、購入者ID402の値及び購入商品ID404の値が同じになっているが、これは、例えば300円の商品をプリペイド方式で100円分決済し、残りの200円分を例えばクレジット・カード等、会員が通常行う決済方法で決済するような場合におけるレコードであるためである。課金番号を別々に設定するようにしてもよい。
【0033】
図5に、商品DB518のテーブル構成及び格納されるデータの一例を示す。図5の例には、商品IDの列550と商品属性の列552と商品名の列554と単価の列556とが含まれている。この他、図示していないが、メーカ・コード等、商品に関するデータを格納するための列が含まれている。この商品DB518には、ユーザがオンラインで購入可能な商品に関するレコードが登録されている。
【0034】
次に、図6乃至図27を用いて図1に示したシステムの処理内容について説明する。図6には、ユーザが例えばユーザ端末3を操作して管理サーバ5にアクセスし、プリペイド・キーの贈呈を行う際の処理フローが示されている。以下、各処理ステップに基づき説明していく。なお、これより前にログイン処理が行われているものとする。
【0035】
まず、ユーザ端末3は、ユーザの操作に従い、オンライン・ギフト購入ページのデータの要求を管理サーバ5に対して送信する(図6:ステップS1)。本実施の形態においては、ユーザ端末3が有するWebブラウザを介してサーバにアクセスすることを想定しているが、専用のクライアント・ソフトウェアを使用する場合もある。
【0036】
図7に、メニュー・ページの一例を示す。図7の例には、会員入会ページへのリンク部700とギフト券購入ページへのリンク部710とが含まれている。会員入会ページへのリンク部700がクリックされると会員入会ページへの移行がなされ、ギフト券購入ページへのリンク部710がクリックされるとギフト券購入ページへの移行がなされる。ここで、「(オンライン)ギフト券」とは、プリペイド・キーを指しているが、各Webページにおいては、ユーザがイメージしやすいように仮想的な「(オンライン)ギフト券」という表現を用いている。
【0037】
図6の処理フローに戻り、管理サーバ5のWebページ管理部500は、オンライン・ギフト券購入ページのデータの要求をユーザ端末3から受信する(図6:ステップS3)。そして、Webページ管理部500は、Webページ・データ格納部510に格納されているデータを用いてオンライン・ギフト券購入ページのデータを生成し、ユーザ端末3に対して送信する(ステップS5)。ユーザ端末3は、オンライン・ギフト券購入ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS7)。
【0038】
図8に、オンライン・ギフト券購入ページの一例を示す。図8の例には、受取人のメール・アドレス入力欄800と金額設定用プルダウン・リスト810とコメント入力欄820と送信ボタン830とが含まれている。ユーザは、このオンライン・ギフト券購入ページに対して必要なデータを入力し、送信ボタン830をクリックする。
【0039】
図6の処理フローに戻り、ユーザ端末3は、オンライン・ギフト券購入ページ(図8)に対するユーザからの入力を受け付け、受け付けたデータを管理サーバ5に対して送信する(図6:ステップS9)。管理サーバ5のWebページ管理部500は、オンライン・ギフト券購入ページ(図8)に対するユーザからの入力データをユーザ端末3から受信し、一旦記憶装置に格納する(ステップS11)。
【0040】
そして、Webページ管理部500は、入力内容確認ページのデータを生成し、ユーザ端末3に対して送信する(ステップS13)。なお、入力内容をチェックし、エラーがあった場合には、エラー・メッセージを返すようにしてもよい。ユーザ端末3は、入力内容確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS15)。
【0041】
図9に、入力内容確認ページの一例を示す。図9の例には、受取人のメール・アドレス表示欄900と金額表示欄910とコメント表示欄920と確認ボタン930とが含まれている。ユーザは、この入力内容確認ページに示されているデータに間違いがないか確認し、確認ボタン930をクリックする。各表示欄に対してユーザが修正入力可能なようにしてもよいし、図示しないキャンセル・ボタン等が含まれていてもよい。
【0042】
図6の処理フローに戻り、ユーザ端末3は、入力内容確認ページ(図9)に対するユーザからの選択入力を受け付け、選択入力データを管理サーバ5に対して送信する(図6:ステップS17)。管理サーバ5のWebページ管理部500は、選択入力データをユーザ端末3から受信し、一旦記憶装置に格納する(ステップS19)。
【0043】
そして、Webページ管理部500は、オンライン・ギフト券の購入処理を行ってもよい(OK)かどうか判定する(ステップS21)。例えば、入力内容確認ページ(図9)において図示しないキャンセル・ボタンがクリックされた場合や、ユーザの入力内容をチェックしてエラーが発見された場合等には、オンライン・ギフト券の購入処理を行ってはいけない(OKではない)と判断する。
【0044】
OKではないと判定された場合(ステップS21:Noルート)、ステップS5の処理に戻る。一方、OKであると判定された場合(ステップS21:Yesルート)、管理サーバ5のID管理部502は、プリペイド会員データを生成し、ユーザ管理DB512に格納する(ステップS23)。すなわち、ユーザ管理DB512に新規のレコードが1件登録される。なお、登録されるレコードのプリペイド会員フラグの列204(図2)には「0」が格納される。また、URLの列216に、上で述べたようなユーザ固有のURLデータ(パス)が格納される。なお、この時点では、登録されるレコードのパスワードの列202(図2)と正会員フラグの列206(図2)と氏名の列212(図2)とクレジット・カード番号の列214(図2)とには、値が格納されない。
【0045】
そして、管理サーバ5の決済処理部506は、贈呈者IDと受領者IDと商品IDと購入金額とを含むプリペイド決済データを生成し、プリペイド決済DB514に格納する(ステップS25)。すなわち、プリペイド決済DB514に贈呈者IDと受領者IDと商品IDと購入金額とを含む新規のレコードが1件登録される。なお、登録されるレコードの課金フラグの列310(図3)には「0」が格納される。
【0046】
そして、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて処理完了確認ページのデータを生成し、ユーザ端末3に対して送信する(ステップS27)。ユーザ端末3は処理完了確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS29)。図示しないが、処理完了確認ページには、例えば「オンライン・ギフト券の購入を受け付けました。」等のメッセージが含まれる。
【0047】
このようにして、オンライン・ギフト券の購入が受け付けられ、プリペイド・キーが生成される。ステップS27の処理が終わると、処理は端子Aを介して図10の処理に移行する。
【0048】
図10には、プリペイド・キーの贈呈先であるユーザが、例えばユーザ端末7を操作して管理サーバ5にアクセスし、プリペイド・キーを仮受領する際の処理フローが示されている。以下、各処理ステップに基づき説明していく。
【0049】
まず、管理サーバ5のメール処理部504は、Webページ・データ格納部510に格納されているデータとユーザ管理DB512に格納されているデータとを用いてギフト・メールのデータを生成し、プリペイド・キーの贈呈先であるユーザ宛てに送信する(ステップS41)。ユーザ端末7は、ユーザの操作に従い、図示しないメール・サーバを介して管理サーバ5からのギフト・メールのデータを受信し、表示装置に表示する(ステップS43)。
【0050】
図11に、ギフト・メールの表示画面の一例を示す。図11の例には、贈呈元ユーザ表示部1100とメッセージ表示部1110と仮受領確認用URL表示部1120とが含まれている。贈呈元ユーザ表示部1100には、贈呈元であるユーザの氏名(ユーザ管理DB512の氏名の列212(図2)の値)が含まれており、誰からの贈呈か分かるようになっている。メッセージ表示部1110には、オンライン・ギフト券購入ページ(図8)においてコメント入力欄820に入力されたデータが示される。仮受領確認用URL表示部1120には、仮受領確認ページのURLが示されているが、メーラの機能及びその設定によっては、URLがハイパー・リンクになっている場合もある。
【0051】
図10の処理フローに戻り、ユーザ端末7は、例えば仮受領確認用URL表示部1120(図11)に示されているURLに基づきWebページにアクセスするというユーザの指示に従い、仮受領確認ページ・データの要求を管理サーバ5に対して送信する(図10:ステップS45)。管理サーバ5のWebページ管理部500は、仮受領確認ページ・データの要求をユーザ端末7から受信する(ステップS47)。そして、Webページ管理部500は、Webページ・データ格納部510に格納されているデータとユーザ管理DB512に格納されているデータとプリペイド決済DB514に格納されているデータとを用いて仮受領確認ページのデータを生成し、ユーザ端末7に対して送信する(ステップS49)。ユーザ端末7は、仮受領確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS51)。
【0052】
図12に、仮受領確認ページの一例を示す。図12の例には、差出人メール・アドレス表示部1200と受領人メール・アドレス表示部1210と金額表示部1220と受領ボタン1230と受領拒否ボタン1240とが含まれている。差出人メール・アドレス表示部1200には、贈呈元であるユーザのメール・アドレスが示されているが、図11に示した贈呈元ユーザ表示部1100と同様に、ユーザの氏名を示すようにしてもよい。
【0053】
図10の処理フローに戻り、ユーザ端末7は、ユーザからの仮受領確認ページ(図12)に対する選択入力を受け付け、管理サーバ5に対して送信する(図10:ステップS53)。管理サーバ5のWebページ管理部500は、選択入力データをユーザ端末7から受信し、一旦記憶装置に格納する(ステップS55)。
【0054】
そして、Webページ管理部500は、ユーザからの選択入力が「受領」であったかどうか判定する(ステップS57)。仮受領確認ページ(図12)において、ユーザによって受領ボタン1230がクリックされた場合には「受領」と判定し、受領拒否ボタン1240がクリックされた場合には「受領」ではないと判定する。
【0055】
「受領」ではないと判定された場合(ステップS57:Noルート)、管理サーバ5のメール処理部504は、ユーザ管理DB512に格納されているデータを用いて受領拒否通知メールのデータを生成し、贈呈者(贈呈元のユーザ)宛てに送信する(ステップS59)。受領拒否通知メールには、図示しないが、オンライン・ギフト券を受け取ってもらえなかった旨のメッセージが含まれる。なお、この場合、プリペイド・キーの贈呈に関する一連の処理は終了する。ユーザ管理DB512から該当するレコードを削除してもよい。
【0056】
一方、「受領」であったと判定された場合(ステップS57:Yesルート)、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いてパスワード入力ページのデータを生成し、ユーザ端末7に対して送信する(ステップS61)。ユーザ端末7は、パスワード入力ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS63)。
【0057】
図13に、パスワード入力ページの一例を示す。図13の例には、パスワード入力欄1300と確定ボタン1310とが含まれている。ユーザは、パスワード入力欄1300にパスワードを入力し、確定ボタン1310をクリックする。なお、パスワード入力欄1300は、ユーザからの入力文字をそのまま表示せず、アスタリスクで示すようになっている。そこで、入力ミスをチェックするために、パスワード入力欄が複数設けられる場合もある。
【0058】
図10の処理フローに戻り、ユーザ端末7は、ユーザからのパスワード入力ページ(図13)に対するパスワードの入力を受け付け、管理サーバ5に対して送信する(図10:ステップS65)。管理サーバ5のID管理部502は、パスワードをユーザ端末7から受信し、ユーザ管理DB512のパスワードの列202(図2)に格納する(ステップS67)。なお、該当するレコードは、例えばメール・アドレスの列208(図2)の値に基づき特定する。
【0059】
そして、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータとユーザ管理DB512に格納されているデータとを用いて仮受領完了ページのデータを生成し、ユーザ端末7に対して送信する(ステップS69)。ユーザ端末7は、仮受領完了ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS71)。
【0060】
図14に、仮受領完了ページの一例を示す。図14の例には、プリペイド・キー表示部1400とOKボタン1410とが含まれている。ユーザは、プリペイド・キー表示部1400に示された自分のIDを確認し、OKボタン1410をクリックする。
【0061】
このようにして、プリペイド・キーの仮受領処理が行われる。ステップS69の処理が終わると、処理は端子Bを介して図15の処理に移行する。
【0062】
図15には、プリペイド・キーの贈呈先であり且つプリペイド・キーの仮受領を既に行ったユーザが、例えばユーザ端末7を操作して管理サーバ5にアクセスし、プリペイド・キーを本受領する際の処理フローが示されている。以下、各処理ステップに基づき説明していく。
【0063】
まず、管理サーバ5のメール処理部504は、Webページ・データ格納部510に格納されているデータとユーザ管理DB512に格納されているデータとを用いて本受領メールのデータを生成し、プリペイド・キーの贈呈先であるユーザ宛てに送信する(ステップS81)。ユーザ端末7は、ユーザの操作に従い、図示しないメール・サーバを介して管理サーバ5からの本受領メールのデータを受信し、表示装置に表示する(ステップS83)。
【0064】
図16に、本受領メールの表示画面の一例を示す。図16の例には、本受領確認用URL表示部1600が含まれている。本受領確認用URL表示部1600には、本受領確認ページのURLが示されているが、メーラの機能及びその設定によっては、URLがハイパー・リンクになっている場合もある。
【0065】
図15の処理フローに戻り、ユーザ端末7は、例えば本受領確認用URL表示部1600(図16)に示されているURLに基づきWebページにアクセスするというユーザの指示に従い、本受領確認ページ・データの要求を管理サーバ5に対して送信する(図15:ステップS85)。管理サーバ5のWebページ管理部500は、本受領確認ページ・データの要求をユーザ端末7から受信する(ステップS87)。そして、Webページ管理部500は、Webページ・データ格納部510に格納されているデータとユーザ管理DB512に格納されているデータとプリペイド決済DB514に格納されているデータとを用いて本受領確認ページのデータを生成し、ユーザ端末7に対して送信する(ステップS89)。ユーザ端末7は、本受領確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS91)。
【0066】
図17に、本受領確認ページの一例を示す。図17の例には、差出人メール・アドレス表示部1700と受領人メール・アドレス表示部1710と金額表示部1720と「受領する」ボタン1730とが含まれている。差出人メール・アドレス表示部1700には、贈呈元であるユーザのメール・アドレスが示されているが、ユーザの氏名を示すようにしてもよい。ユーザは、各表示部の内容を確認し、「受領する」ボタン1730をクリックする。
【0067】
図15の処理フローに戻り、ユーザ端末7は、ユーザからの本受領確認ページ(図17)に対する選択入力を受け付け、管理サーバ5に対して送信する(図15:ステップS93)。管理サーバ5のWebページ管理部500は、選択入力データをユーザ端末7から受信し、一旦記憶装置に格納する(ステップS95)。なお、ここでのユーザからの選択入力は「受領する」である。
【0068】
そして、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて認証データ入力ページのデータを生成し、ユーザ端末7に対して送信する(ステップS97)。ユーザ端末7は、認証データ入力ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS99)。
【0069】
図18に、認証データ入力ページの一例を示す。図18の例には、ID入力欄1800とパスワード入力欄1810と確定ボタン1820とが含まれている。ユーザは、仮受領完了ページ(図14)において確認したプリペイド・キーをID入力欄1800に入力し、パスワード入力ページ(図13)において設定したパスワードをパスワード入力欄1810に入力し、確定ボタン1820をクリックする。
【0070】
図15の処理フローに戻り、ユーザ端末7は、ユーザからの認証データ入力ページ(図18)に対するID(プリペイド・キー)及びパスワードの入力を受け付け、管理サーバ5に対して送信する(図15:ステップS101)。管理サーバ5のWebページ管理部500は、ID及びパスワードをユーザ端末7から受信し、一旦記憶装置に格納する(ステップS103)。その際、管理サーバ5のID管理部502は、ID及びパスワードが正しく入力されたか、ユーザ管理DB512に格納されているデータを用いてチェックする。正しく入力されていればそのまま処理を続行するが、正しく入力されていなければエラーを返し、例えばユーザに再入力を促す。
【0071】
そして、ID管理部502は、ユーザ管理DB512のプリペイド会員フラグ204(図2)の値を「0」から「1」に更新する(ステップS105)。さらに、管理サーバ5の決済処理部506は、プリペイド決済DB514の該当するレコードの課金フラグの列310(図3)の値を「0」から「1」に更新し、当該レコードのデータを用いて課金データを生成し、課金データDB516に格納する(ステップS107)。すなわち、プリペイド・キーの贈呈先ユーザをプリペイド会員として本登録し、それに伴い、プリペイド・キーの贈呈元ユーザに課金する処理が行われる。
【0072】
そして、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて本受領完了ページのデータを生成し、ユーザ端末7に対して送信する(ステップS109)。ユーザ端末7は、本受領完了ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS111)。
【0073】
図19に、本受領完了ページの一例を示す。図19の例には、メッセージ入力欄1900とバリュー移行用ハイパー・リンク1910とOKボタン1920とが含まれている。バリュー移行用ハイパー・リンク1910がクリックされると、ユーザが受領したプリペイド・キーのバリュー(残高)を、当該プリペイド・キーとは異なる既存のIDに移すためのページに移行する。なお、バリューの移行処理は銀行振替のような処理であり、本発明の要旨ではないため説明を割愛する。例えばユーザは、メッセージ入力欄1900にメッセージを入力し、OKボタン1920をクリックする。
【0074】
図15の処理フローに戻り、ユーザ端末7は、ユーザからの本受領完了ページ(図19)に対する選択入力を受け付け、管理サーバ5に対して送信する(図15:ステップS113)。管理サーバ5のWebページ管理部500は、選択入力データをユーザ端末7から受信し、一旦記憶装置に格納する(ステップS115)。なお、ここでのユーザからの選択入力は「OK」とする。
【0075】
そして、管理サーバ5のメール処理部504は、受領通知メールのデータを生成し、贈呈者(贈呈元のユーザ)宛てに送信する(ステップS117)。受領通知メールには、図示しないが、オンライン・ギフト券の受け取りがなされた旨のメッセージと本受領完了ページのメッセージ入力欄1900(図19)に入力されたメッセージとが含まれる。また、課金に関するデータ(金額や支払日等)が含まれる場合もある。
【0076】
このようにして、プリペイド・キーの本受領処理が行われる。そして、本受領処理を行いプリペイド会員となったユーザは、受領したプリペイド・キーを用いて商品の購入や有償コンテンツの閲覧等を行うことが可能となる。
【0077】
図20には、プロバイダの会員(プリペイド会員を含む)であるユーザが例えばユーザ端末7を操作して管理サーバ5にアクセスし、オンライン・ショッピングを行う際の処理フローが示されている。本実施の形態においては、ユーザ端末7が有するWebブラウザを介してサーバにアクセスすることを想定しているが、専用のクライアント・ソフトウェアを使用する場合もある。以下、各処理ステップに基づき説明していく。
【0078】
まず、ユーザ端末7は、表示しているWebページに対するユーザからの商品購入指示を受け付け、指示データを管理サーバ5に対して送信する(図20:ステップS201)。
【0079】
例えば、図21に示すようなショッピング・ページに対するユーザからの商品購入指示を受け付ける。図21の例には、商品データ表示部2000と「購入する」ボタン2100とが含まれている。「購入する」ボタン2100がクリックされることにより、A商品の購入指示を受け付ける。なお、図21では簡略化した例を示しているが、一般的なオンライン・ショッピングにおける「買い物かご」や「ショッピング・カート」等、複数の購入候補商品についての会計内容を表示し、購入指示を受け付けるようなページであってもよい。
【0080】
図20の処理フローに戻り、管理サーバ5のWebページ管理部500は、購入指示データをユーザ端末7から受信し、一旦記憶装置に格納する(図20:ステップS203)。なお、購入指示データには、商品名、単価、数量、合計金額等の会計データが含まれているものとする。
【0081】
そして、Webページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて購入ユーザ確認ページのデータを生成し、ユーザ端末7に対して送信する(ステップS205)。ユーザ端末7は、購入ユーザ確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS207)。
【0082】
図22に、購入ユーザ確認ページの一例を示す。図22の例には、会計データ表示部2200とID入力欄2210とパスワード入力欄2220と確定ボタン2230とが含まれている。ユーザは、この購入ユーザ確認ページに対して認証データを入力し、確定ボタン2230をクリックする。例えば複数のIDを保有しているユーザは、課金するIDを入力する。なお、ユーザが既にログイン済みである場合には、ログインしているユーザのIDを予めID入力欄2210に埋め込んでおくようにしてもよい。
【0083】
図20の処理フローに戻り、ユーザ端末7は、購入ユーザ確認ページ(図22)に対するユーザからの認証データの入力を受け付け、購入データを管理サーバ5に対して送信する(図20:ステップS209)。なお、購入データには、商品の会計データとユーザの認証データとが含まれているものとする。
【0084】
管理サーバ5のWebページ管理部500は、購入データをユーザ端末7から受信し、一旦記憶装置に格納する(ステップS211)。その際、管理サーバ5のID管理部502は、ID及びパスワードが正しく入力されたか、ユーザ管理DB512に格納されているデータを用いてチェックする。また、ID管理部502は、購入データに含まれるIDが課金可能なIDであるかチェックし、課金不可能なIDであればエラーを返す。具体的には、ユーザ管理DB512の該当するレコードの、プリペイド会員フラグの列204(図2)の値が「1」である又は正会員フラグの列206(図2)の値が「1」である場合には、課金可能である。
【0085】
さらに、ID管理部502は、ユーザ管理DB512に格納されているデータを用いて、商品を購入するユーザ(課金されるID)がプリペイド会員であるかどうか判定する(ステップS213)。ユーザ管理DB512の該当するレコードのプリペイド会員フラグの列204(図2)の値が「1」であれば、プリペイド会員であると判定する。
【0086】
プリペイド会員ではないと判定された場合(ステップS213:Noルート)、後に述べるステップS219の処理に移行する。
【0087】
一方、プリペイド会員であると判定された場合(ステップS213:Yesルート)、管理サーバ5の決済処理部506は、購入データとユーザ管理DB512に格納されているデータとを用いて、プリペイド残高が不足しているかどうか判定する(ステップS215)。具体的には、ユーザ管理DB512の該当するレコードのプリペイド残高の列210(図2)の値が、購入データに含まれる会計金額より少ない場合には、残高不足であると判定する。
【0088】
残高不足であると判定された場合(ステップS215:Yesルート)、処理は端子Cを介して図23の処理に移行する。一方、残高不足ではないと判定された場合(ステップS215:Noルート)、管理サーバ5の決済処理部506は、ユーザ管理DB512の該当するレコードのプリペイド残高の列210(図2)の値を更新する(ステップS217)。すなわち、会計金額分だけ残高を減らす。そして、管理サーバ5の決済管理部506は、購入データを用いて課金データを生成し、課金DB516に格納する(ステップS219)。なお、プリペイド方式での課金データは、決済が既に済んでいるため、課金DB516に格納しないようにしてもよい。
【0089】
そして、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて決済確認ページのデータを生成し、ユーザ端末7に対して送信する(ステップS221)。ユーザ端末7は、決済確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS223)。図示しないが、決済確認ページには、商品の購入(注文)処理が完了したことを通知するメッセージが含まれる。
【0090】
このようにして、プリペイド会員を含むプロバイダの会員ユーザによるオンライン・ショッピングにおける処理が行われる。
【0091】
図23には、ステップS215(図20)において残高不足であると判定された場合(ステップS215:Yesルート)の処理フローが示されている。まず、管理サーバ5の決済処理部506は、プリペイド残高の不足分の金額を例えばワーク・メモリ領域等の記憶装置に一時格納する(ステップS231)。そして、管理サーバ5のWebページ管理部500は、プリペイド残高データとWebページ・データ格納部510に格納されているデータとを用いて残高不足通知ページのデータを生成し、ユーザ端末7に対して送信する(ステップS233)。ユーザ端末7は、残高不足通知ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS235)。
【0092】
図24に、残高不足通知ページの一例を示す。図24の例には、メッセージ表示部2400と「入会手続きへ」ボタン2410とキャンセル・ボタン2420とが含まれている。ユーザは、メッセージ表示部2400に示されているメッセージを確認し、直ちに入会手続きを実施することを希望する場合には、「入会手続きへ」ボタン2410をクリックする。
【0093】
図23の処理フローに戻り、ユーザ端末7は、残高不足通知ページ(図24)に対するユーザからの選択入力を受け付け、管理サーバ5に対して送信する(図23:ステップS237)。管理サーバ5のWebページ管理部500は、選択入力データをユーザ端末7から受信し、一旦記憶装置に格納する(ステップS239)。
【0094】
そして、Webページ管理部500は、残高不足通知ページ(図24)に対するユーザからの選択入力が「入会」であったかどうか判定する(ステップS241)。例えば「入会手続きへ」ボタン2410(図24)がクリックされた場合には「入会」であったと判定し、キャンセル・ボタン2420(図24)がクリックされた場合には「入会」ではなかったと判定する。
【0095】
「入会」であったと判定された場合(ステップS241:Yesルート)、処理は端子Dを介して図25の処理に移行する。一方、「入会」ではなかったと判定された場合(ステップS241:Noルート)、Webページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて購入キャンセル確認ページのデータを生成し、ユーザ端末7に対して送信する(ステップS243)。またこの際、管理サーバ5の決済処理部506は、ステップS231においてワーク・メモリ領域等の記憶装置に一時格納しておいた不足金額に関するデータをクリアする。
【0096】
ユーザ端末7は、購入キャンセル確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS245)。図示しないが、購入キャンセル確認ページには、商品の購入(注文)処理を取りやめた旨のメッセージが含まれる。
【0097】
このようにして、プリペイド残高が不足した場合には、正会員としての登録を促すようになっている。
【0098】
図25には、ステップS241(図23)において「入会」であると判定された場合(ステップS241:Yesルート)の処理フローが示されている。まず、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて入会ページのデータを生成し、ユーザ端末7に対して送信する(ステップS251)。ユーザ端末7は、入会ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS253)。図示しないが、入会ページには、ユーザの氏名の入力欄や、決済に使用するクレジット・カードの番号入力欄等、正会員として登録するために必要なデータを入力するための、入会用データ入力欄が含まれる。
【0099】
そして、ユーザ端末7は、入会ページに対するユーザからの入会用データの入力を受け付け、管理サーバ5に対して送信する(ステップS255)。管理サーバ5のID管理部502は、入力用データをユーザ端末7から受信し、ユーザ管理DB512の該当するレコード(図2)に格納する(ステップS257)。
【0100】
さらに、ID管理部502は、ユーザ管理DB512の該当するレコードの、プリペイド会員フラグの列204(図2)の値をクリアし、正会員フラグの列206(図2)に「1」を格納する(ステップS259)。
【0101】
そして、管理サーバ5の決済処理部506は、ステップS231(図23)においてワーク・メモリ領域等の記憶装置に一時格納しておいた不足金額データと、ユーザ管理DB512の該当するレコードのプリペイド残高の列210(図2)の値とを用いて課金データを生成し、課金DB516に格納する(ステップS261)。本実施の形態においては、図4に示した例の3行目及び4行目のように2レコード登録される。さらに、決済処理部506は、ユーザ管理DB512の該当するレコードのプリペイド残高の列210(図2)の値を「0」に更新する(ステップS263)。
【0102】
そして、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて入会完了確認ページのデータを生成し、ユーザ端末7に対して送信する(ステップS265)。ユーザ端末7は、入会完了確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS267)。図示しないが、入会完了確認ページには、商品の購入(注文)処理が完了したことを通知するメッセージと、ユーザが正会員として登録された旨のメッセージとが含まれる。なお、決済方式が複数になるため、課金データも併せて提示するようにしてもよい。
【0103】
このようにして、プリペイド会員にはIDの再発行をすることなく正会員としての入会手続きが行われる。なお、プリペイド会員が正会員として登録された場合には、インセンティブとして代金のいくらかを減額するようにしてもよい。また、プリペイド・キーの贈呈者に課金されている金額のいくらかを減額するようにしてもよい。
【0104】
図26には、プリペイド会員であるユーザが例えばユーザ端末7を操作して管理サーバ5にアクセスし、正会員として登録する際の処理フローが示されている。本実施の形態においては、ユーザ端末7が有するWebブラウザを介してサーバにアクセスすることを想定しているが、専用のクライアント・ソフトウェアを使用する場合もある。以下、各処理ステップに基づき説明していく。
【0105】
まず、ユーザ端末7は、表示しているメニュー・ページに対するユーザからの「入会」の選択指示を受け付け、指示データを管理サーバ5に対して送信する(図26:ステップS301)。メニュー・ページについては、図7に一例を示したが、例えば会員入会ページへのリンク部700(図7)のクリックを受け付ける。
【0106】
図26の処理フローに戻り、管理サーバ5のWebページ管理部500は、指示データをユーザ端末7から受信し、一旦記憶装置に格納する(図26:ステップS303)。そして、Webページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて入会ユーザ確認ページのデータを生成し、ユーザ端末7に対して送信する(ステップS305)。ユーザ端末7は、入会ユーザ確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS307)。
【0107】
入会ユーザ確認ページの一例を図27に示す。図27の例には、ID入力欄2700とパスワード入力欄2710と確定ボタン2720とが含まれている。ユーザは、この入会ユーザ確認ページに対して認証データを入力し、確定ボタン2720をクリックする。なお、ユーザが既にログイン済みである場合には、ログインしているユーザのIDを予めID入力欄2700に埋め込んでおくようにしてもよい。
【0108】
図26の処理フローに戻り、ユーザ端末7は、入会ユーザ確認ページ(図27)に対するユーザからの認証データの入力を受け付け、認証データを管理サーバ5に対して送信する(図26:ステップS309)。
【0109】
管理サーバ5のWebページ管理部500は、認証データをユーザ端末7から受信し、一旦記憶装置に格納する(ステップS311)。その際、管理サーバ5のID管理部502は、ID及びパスワードが正しく入力されたか、ユーザ管理DB512に格納されているデータを用いてチェックする。正しく入力されていればそのまま処理を続行するが、正しく入力されていなければエラーを返し、例えばユーザに再入力を促す。また、ID管理部502は、ユーザ管理DB512に格納されているデータを用いて、認証データに含まれるIDがプリペイド会員のIDであることを確認する。具体的には、ユーザ管理DB512の該当するレコードの、プリペイド会員フラグの列204(図2)の値が「1」であることを確認する。その他の属性のIDの場合には、図示していないが、例えば新規にIDを発行する処理に移行する。但し、エラーとしてもよい。
【0110】
そして、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて入会ページのデータを生成し、ユーザ端末7に対して送信する(ステップS313)。ユーザ端末7は、入会ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS315)。図示しないが、入会ページには、ユーザの氏名の入力欄や、決済に使用するクレジット・カードの番号入力欄等、正会員として登録するために必要なデータを入力するための、入会用データ入力欄が含まれる。
【0111】
そして、ユーザ端末7は、入会ページに対するユーザからの入会用データの入力を受け付け、管理サーバ5に対して送信する(ステップS317)。管理サーバ5のID管理部502は、入力用データをユーザ端末7から受信し、ユーザ管理DB512の該当するレコード(図2)に格納する(ステップS319)。
【0112】
さらに、ID管理部502は、ユーザ管理DB512の該当するレコードの、プリペイド会員フラグの列204(図2)の値をクリアし、正会員フラグの列206(図2)に「1」を格納する(ステップS321)。なお、プリペイド残高の列210(図2)の値は変更しないため、プリペイドの残高が残っているユーザは、正会員になっても残りの金額分を利用することが可能である。
【0113】
そして、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて入会完了確認ページのデータを生成し、ユーザ端末7に対して送信する(ステップS323)。ユーザ端末7は、入会完了確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS325)。図示しないが、入会完了確認ページには、ユーザが正会員として登録された旨のメッセージ等が含まれる。
【0114】
このようにして、プリペイド会員にはIDの再発行をすることなく正会員としての入会手続きが行われる。
【0115】
以上本発明の一実施の形態について説明したが、本発明はこれに限定されるものではない。例えば図2乃至図5に示したテーブル構成は一例であって、同様のデータを格納するためであれば、別の構成を採用するようにしてもよい。また、必要に応じて項目を追加又は削除するようにしてもよい。例えば、プリペイド会員フラグの列204(図2)と正会員フラグの列206(図2)とを1つの列にまとめて、会員のステータスを管理するようにしてもよい。
【0116】
また、図7、図8、図9、図11、図12、図13、図14、図16、図17、図18、図19、図21、図22、図24及び図27に示した画面構成は一例であって、同様の内容を別の態様にて表現することも可能である。また、管理サーバ5が複数のサーバによって構成されていてもよい。さらに、図1に示した管理サーバ5の機能ブロック構成は一例であって、実際のプログラム・モジュール構成とは異なる場合がある。また、例えば会員向けのオンライン・ショッピングを実現するためのサーバは、管理サーバ5に限らず別の専用サーバ等であってもよい。
【0117】
また、図6、図10、図15、図20、図23、図25及び図26に示した処理フローも一例であって、同様の処理結果が得られる範囲において処理の順序を入れ替えてもよいし、必要に応じてステップを追加又は削除してもよい。
【0118】
【発明の効果】
以上述べたように、本発明によれば、プリペイド形式の決済に関連する新規なサービスを実現することができる。また、効果的なタイミングで入会勧誘を行うことができる。
【図面の簡単な説明】
【図1】本発明の実施の形態におけるシステム概要図である。
【図2】ユーザ管理DBのテーブル構成及び格納されるデータの一例を示す図である。
【図3】プリペイド決済DBのテーブル構成及び格納されるデータの一例を示す図である。
【図4】課金DBのテーブル構成及び格納されるデータの一例を示す図である。
【図5】商品DBのテーブル構成及び格納されるデータの一例を示す図である。
【図6】本発明の実施の形態における処理フロー(その1)を示す図である。
【図7】メニュー・ページの一例を示す図である。
【図8】購入ページの一例を示す図である。
【図9】確認ページの一例を示す図である。
【図10】本発明の実施の形態における処理フロー(その2)を示す図である。
【図11】ギフト・メール表示画面の一例を示す図である。
【図12】仮受領確認ページの一例を示す図である。
【図13】パスワード入力ページの一例を示す図である。
【図14】仮受領完了ページの一例を示す図である。
【図15】本発明の実施の形態における処理フロー(その3)を示す図である。
【図16】本受領メール表示画面の一例を示す図である。
【図17】本受領確認ページの一例を示す図である。
【図18】認証データ入力ページの一例を示す図である。
【図19】本受領完了ページの一例を示す図である。
【図20】本発明の実施の形態における処理フロー(その4)を示す図である。
【図21】ショッピング・ページの一例を示す図である。
【図22】購入ユーザ確認ページの一例を示す図である。
【図23】本発明の実施の形態における処理フロー(その5)を示す図である。
【図24】残高不足通知ページの一例を示す図である。
【図25】本発明の実施の形態における処理フロー(その6)を示す図である。
【図26】本発明の実施の形態における処理フロー(その7)を示す図である。
【図27】入会ユーザ確認ページの一例を示す図である。
【符号の説明】
1 ネットワーク 3,7 ユーザ端末 5 管理サーバ
500 Webページ管理部 502 ID管理部
504 メール処理部 506 決済処理部
510 Webページ・データ格納部
512 ユーザ管理DB
514 プリペイド決済DB
516 課金DB 518 商品DB
【発明が属する技術分野】
本発明は、プリペイド方式での決済に関連するサービスのための情報処理技術に関する。
【0002】
【従来の技術】
プロバイダの会員サービスとして、特定のプロバイダの会員が、当該プロバイダの他の会員に対してプロバイダの利用料をギフトとしてオンラインで贈呈できるサービスが一般的に存在している。このようなギフト(以下、オンライン・ギフトと呼ぶ)を受け取った会員は、贈呈者である会員が指定した金額分については、無料でプロバイダを利用することができる。すなわち、贈呈者である会員が、プリペイド方式の利用権を購入し、他の会員に贈るような形態となっており、贈呈者である会員に対して利用権分の金額が課金される。また、このようなオンライン・ギフトを利用することができるユーザを、プロバイダの会員に限定しない場合もある。
【0003】
例えば、プリペイド方式のメール・サービスを提供する技術が存在する(特許文献1参照)。すなわち、ユーザ情報を格納するユーザ情報ファイルと、アクセスしてきたユーザのメール・アカウントをユーザ情報に基づいて認証する認証サーバと、認証されたメール・アカウントに対してインターネット・メール処理を行うメール・サーバと、メール・サーバの使用に応じて該当メール・アカウントの限定使用条件をチェックするとともにこの限定使用条件から外れたメール・アカウントの使用を禁止するアカウント管理部とから構成され、ユーザからの申し込みに基づいて限定使用条件をもったインターネット・メール・アカウントを発行するプリペイド・メール・システムが存在する。
【0004】
【特許文献1】
特開2002−152245号公報
【0005】
【発明が解決しようとする課題】
しかしながら以上の技術においては、オンライン・ギフト又は一時メール・アカウントを入手したユーザは、当該オンライン・ギフト又は一時メール・アカウントに設定された金額や時間を特定のプロバイダの利用権として使用することができるが、それ以外の例えばオンライン・ショッピング等に使用することはできない。そのため、ユーザにとって利用範囲が狭いものになっていた。また、オンライン・ギフト又は一時メール・アカウントを利用したユーザが、プロバイダの正会員として登録されていないが、続けてサービスを利用するために正会員として登録されることを欲する場合には、改めてIDの発行を受け、正会員として別途登録される必要がある。その際、プリペイド方式の利用に用いていたデータは基本的に引き継げず、新たに設定されるため、ユーザにとって管理が煩わしいものになっていた。
【0006】
従って本発明の目的は、プリペイド形式の決済に関連する新規なサービスを実現するための技術を提供することである。
【0007】
なお、本発明の他の目的は、入会勧誘のための新規な技術を提供することである。
【0008】
【課題を解決するための手段】
本発明に係る情報処理方法は、プリペイド方式での決済に用いるためのキー(以下、プリペイド・キーと呼ぶ)の配布要求を受信した場合、正会員のID設定ルールに従ったキーを生成し、記憶装置に格納するプリペイド・キー生成ステップと、記憶装置に格納されたキーを用いた、正会員への登録要求を受信した場合、当該キーを正会員のIDとして利用可能なように記憶装置に設定する会員登録ステップとを含む。
【0009】
これにより、プリペイド・キーをそのまま正会員のIDとして継続使用することができ、改めて正会員用のIDを発行する手間やIDの重複管理を省くことができる。
【0010】
また、上で述べたプリペイド・キー生成ステップが、キーを特定のユーザに関連付けるステップを含むようにしてもよい。これにより、プリペイド・キーを利用するユーザを指定することができ、プリペイド・キーを例えばオンライン・ギフトとして特定のユーザに贈呈することが可能となる。例えば、プリペイド・キーと当該プリペイド・キーを利用するユーザのメール・アドレスとを含むレコードを記憶装置に格納しておく。
【0011】
また、上記特定のユーザは、正会員として未登録のユーザであるものとしてもよい。これにより、プロバイダの正会員として未登録のユーザが、続けてサービスを利用するために正会員として登録されることを欲する場合には、改めてIDの発行を受けることなく、正会員として登録される。すなわち、ユーザはプリペイド・キーを正会員のユーザIDとしてそのまま利用できるようになる。
【0012】
また、上で述べた会員登録ステップが、記憶装置に設定される、特定のユーザのステータスを表すデータを、正会員を表すデータに変更し、記憶装置に設定するステップを含むようにしてもよい。このように、ユーザのステータスを変更して正会員への移行処理を行うことにより、IDの新規発行を不要とするスムーズな正会員登録が実現できる。また、システム側の管理が容易になる。
【0013】
また、キーに対応付けられている金額を超える決済要求を受信した場合、当該決済要求を行ったユーザに正会員登録を促すステップをさらに含むようにしてもよい。ここで、キーに対応付けられている金額とは、当該キーを利用することによりプリペイド方式での決済が可能となるプリペイド残高を指し、ユーザが決済を行うことにより、決済金額分だけ少なくなっていくものである。そして、上で述べたように不足が発生した際に正会員登録を促すことにより、効果的なタイミングで入会の勧誘を行うことができる。
【0014】
また、決済要求における決済金額とキーに対応付けられている金額との差額を、正会員として登録されたユーザへの課金データとして課金データ格納部に格納するステップをさらに含むようにしてもよい。これにより、ユーザは、正会員になることによってプリペイド残高の不足分を正会員に提供される手段で決済することができるようになる。例えば、足りない分をクレジット・カード等で決済するものである。
【0015】
また、上で述べたプリペイド・キー生成ステップが、キーに特定のパスワードを関連付けるステップを含むようにしてもよい。これにより、プリペイド・キーを利用するユーザを、特定のパスワードを知るユーザに限定することができる。例えば、プリペイド・キーと当該プリペイド・キーを利用するユーザが設定したパスワードとを含むレコードを記憶装置に格納しておく。
【0016】
また、上で述べた会員登録ステップにおいて、上記特定のパスワードを、正会員のIDに対応するパスワードとして設定するようにしてもよい。これにより、ユーザは、正会員になったとしても、それまでに使い慣れたパスワードをそのまま利用し続けることができる。
【0017】
また、あるユーザから、プリペイド方式での決済に利用できる金額の指定と当該金額をプリペイド方式の決済に用いるためのキーを特定のユーザに配布する指示とを受け付けた場合、上記特定のユーザによるキーの使用開始が確認された時点において、あるユーザにより指定され且つキーに対応付けられている金額を、あるユーザへの課金データとして課金データ格納部に格納するステップをさらに含むようにしてもよい。
【0018】
これにより、他のユーザにプリペイド・キーを贈呈したユーザには、自己の指定した贈呈金額が、贈呈されたユーザのプリペイド・キーの使用開始が確認された際に、課金される。従って、プリペイド・キーを贈呈しようとしても、贈呈されるユーザがプリペイド・キーの使用を拒否した場合等には課金が発生せず、ユーザにとって無駄な出費を抑えることができる。
【0019】
なお、本発明に係る情報処理方法をコンピュータに実行させるプログラムは、例えばフレキシブル・ディスク、CD−ROM、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してデジタル信号として頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリに一時保管される。
【0020】
【発明の実施の形態】
本発明の一実施の形態に係るシステム構成図を図1に示す。例えばインターネットであるネットワーク1には、管理サーバ5と、例えばパーソナル・コンピュータである1又は複数のユーザ端末3及びユーザ端末7とが、無線又は有線によって接続されている。ユーザ端末3及びユーザ端末7は、図示していないウェブ(Web)ブラウザ機能とメーラ機能とを有し、Webページの閲覧とメールの送受信及び閲覧とを可能とさせている。なお、ユーザ端末3及びユーザ端末7は、Webブラウザ機能及びメーラ機能を有する携帯電話機やその他の携帯情報端末等であってもよい。
【0021】
また、管理サーバ5には、Webページ管理部500とID管理部502とメール処理部504と決済処理部506とが含まれている。これらの処理内容については処理フローの説明において述べるが、管理サーバ5は、この他に図示していないWebサーバ機能を有しており、Webページ・データの生成・送信処理を行えるようになっている。さらに、管理サーバ5は、Webページ・データ格納部510とユーザ管理DB512とプリペイド決済DB514と課金DB516と商品DB518とを管理している。Webページ・データ格納部510には、後に例示するWebページのデータや、管理サーバ5が提供するその他のWebページのデータが格納されている。
【0022】
図2に、ユーザ管理DB512のテーブル構成及び格納されるデータの一例を示す。図2の例には、IDの列200とパスワードの列202とプリペイド会員フラグの列204と正会員フラグの列206とメール・アドレスの列208とプリペイド残高の列210と氏名の列212とクレジット・カード番号の列214とURL(Uniform Resource Locator)の列216とが含まれている。この他、図示していないが、登録日時の列やユーザの住所の列等、ユーザ管理に必要なデータを格納するための列が含まれている。
【0023】
このユーザ管理DB512のテーブルには、プリペイド・キーを利用する非会員ユーザ(以下、プリペイド会員と呼ぶ)と、会員として登録済みのユーザ(以下、正会員と呼ぶ)とに関するレコードが登録されている。なお、プリペイド会員については、プリペイド・キーを、そのままユーザIDとして扱うような仕組みになっている。
【0024】
IDの列200には、プリペイド・キー、すなわちプリペイド会員のユーザIDと、正会員のユーザIDとが格納される。すなわち、プリペイド・キーと正会員のユーザIDとは同様のネーミング・ルールで生成され、区別なく管理される。但し、IDのストリング構成により、プリペイド会員又はプリペイド会員経由で正会員になったことが分かるようにしてもよい。
【0025】
そして、ユーザがプリペイド会員である場合、プリペイド会員フラグの列204に「0」又は「1」と設定され、ユーザが正会員である場合、正会員フラグの列206に「1」と設定される。なお、プリペイド・キーの利用にあたっては、使用開始登録が必要であり、プリペイド会員のうち、ユーザIDの発行、プリペイド・キーの贈呈がなされており、且つ未だ使用開始登録をしていないユーザについては、プリペイド会員フラグの列204に「0」と設定される。一方、プリペイド会員のうち、プリペイド・キーの使用開始登録を行ったユーザについては、プリペイド会員フラグの列204に「1」と設定される。
【0026】
プリペイド残高の列210には、プリペイド方式での決済が可能な金額が格納される。この金額は、プリペイド・キーの生成時に設定された金額を初期値として、プリペイド方式での決済がなされることにより少なくなっていく。決済金額によっては、1回の決済で「0」になることもある。また、氏名の列212とクレジット・カード番号の列214とには、ユーザが正会員である場合に、値が格納される。
【0027】
また、URLの列216には、ユーザ固有のURLデータが格納される。例えばユーザがプリペイド会員であり、ユーザIDの発行、プリペイド・キーの贈呈がなされており、且つ未だ使用開始登録をしていない場合には、使用開始登録用のWebページのURLデータが格納される。なお、本実施の形態においては、使用開始登録には仮受領確認と本受領確認との2つのステップが存在し、使用開始登録がどこまで進んでいるかによってURLが異なるため、仮受領確認URLと本受領確認URLとの共通のパスが格納されるようになっている。例えば、「http://www.****.com/prepaid/ ̄GIF12345/」というデータが格納される。これに、例えば「karijuryo.html」や「honjuryo.html」というデータを追加することにより、ユーザ固有のURLを生成するようになっている。
【0028】
図3に、プリペイド決済DB514のテーブル構成及び格納されるデータの一例を示す。図3の例には、決済番号の列300と贈呈者IDの列302と受領者IDの列304と商品IDの列306と購入金額の列308と課金フラグの列310とが含まれている。この他、図示していないが、決済日時の列等、プリペイド・キーの購入や贈呈に関するデータを格納するための列が含まれている。
【0029】
このプリペイド決済DB514には、プリペイド・キーの贈呈処理が行われた際にレコードが登録される。図3の例では、1行目のレコードより、「AAA00000」というユーザIDを持つユーザが、特定のユーザに対して例えば500円分のプリペイド・キーの贈呈処理がなされたことが分かる。1行目のレコードの受領者IDの列304には「GIF12345」という値が格納されているが、この値はプリペイド・キーそのものでもあり、贈呈先となるプリペイド会員のユーザIDでもある。
【0030】
課金フラグの列310には、贈呈者IDの列302に示されるユーザに課金がなされた場合に「1」が設定される。この課金フラグの列310には、受領者IDの列304に示されるユーザによってプリペイド・キーの使用開始登録がなされるまでは、初期値の「0」が設定されており、ユーザに課金されないようになっている。
【0031】
図4に、課金DB516のテーブル構成及び格納されるデータの一例を示す。図4の例には、課金番号の列400と購入者IDの列402と購入商品IDの列404と購入金額の列406と支払方法の列408とが含まれている。この他、図示していないが、購入日時の列等、商品の購入に関するデータを格納するための列が含まれている。
【0032】
この課金DB516には、ユーザがオンラインで商品を購入した場合にレコードが登録される。図4の例では、3行目のレコードと4行目のレコードとでは、課金番号の列400の値、購入者ID402の値及び購入商品ID404の値が同じになっているが、これは、例えば300円の商品をプリペイド方式で100円分決済し、残りの200円分を例えばクレジット・カード等、会員が通常行う決済方法で決済するような場合におけるレコードであるためである。課金番号を別々に設定するようにしてもよい。
【0033】
図5に、商品DB518のテーブル構成及び格納されるデータの一例を示す。図5の例には、商品IDの列550と商品属性の列552と商品名の列554と単価の列556とが含まれている。この他、図示していないが、メーカ・コード等、商品に関するデータを格納するための列が含まれている。この商品DB518には、ユーザがオンラインで購入可能な商品に関するレコードが登録されている。
【0034】
次に、図6乃至図27を用いて図1に示したシステムの処理内容について説明する。図6には、ユーザが例えばユーザ端末3を操作して管理サーバ5にアクセスし、プリペイド・キーの贈呈を行う際の処理フローが示されている。以下、各処理ステップに基づき説明していく。なお、これより前にログイン処理が行われているものとする。
【0035】
まず、ユーザ端末3は、ユーザの操作に従い、オンライン・ギフト購入ページのデータの要求を管理サーバ5に対して送信する(図6:ステップS1)。本実施の形態においては、ユーザ端末3が有するWebブラウザを介してサーバにアクセスすることを想定しているが、専用のクライアント・ソフトウェアを使用する場合もある。
【0036】
図7に、メニュー・ページの一例を示す。図7の例には、会員入会ページへのリンク部700とギフト券購入ページへのリンク部710とが含まれている。会員入会ページへのリンク部700がクリックされると会員入会ページへの移行がなされ、ギフト券購入ページへのリンク部710がクリックされるとギフト券購入ページへの移行がなされる。ここで、「(オンライン)ギフト券」とは、プリペイド・キーを指しているが、各Webページにおいては、ユーザがイメージしやすいように仮想的な「(オンライン)ギフト券」という表現を用いている。
【0037】
図6の処理フローに戻り、管理サーバ5のWebページ管理部500は、オンライン・ギフト券購入ページのデータの要求をユーザ端末3から受信する(図6:ステップS3)。そして、Webページ管理部500は、Webページ・データ格納部510に格納されているデータを用いてオンライン・ギフト券購入ページのデータを生成し、ユーザ端末3に対して送信する(ステップS5)。ユーザ端末3は、オンライン・ギフト券購入ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS7)。
【0038】
図8に、オンライン・ギフト券購入ページの一例を示す。図8の例には、受取人のメール・アドレス入力欄800と金額設定用プルダウン・リスト810とコメント入力欄820と送信ボタン830とが含まれている。ユーザは、このオンライン・ギフト券購入ページに対して必要なデータを入力し、送信ボタン830をクリックする。
【0039】
図6の処理フローに戻り、ユーザ端末3は、オンライン・ギフト券購入ページ(図8)に対するユーザからの入力を受け付け、受け付けたデータを管理サーバ5に対して送信する(図6:ステップS9)。管理サーバ5のWebページ管理部500は、オンライン・ギフト券購入ページ(図8)に対するユーザからの入力データをユーザ端末3から受信し、一旦記憶装置に格納する(ステップS11)。
【0040】
そして、Webページ管理部500は、入力内容確認ページのデータを生成し、ユーザ端末3に対して送信する(ステップS13)。なお、入力内容をチェックし、エラーがあった場合には、エラー・メッセージを返すようにしてもよい。ユーザ端末3は、入力内容確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS15)。
【0041】
図9に、入力内容確認ページの一例を示す。図9の例には、受取人のメール・アドレス表示欄900と金額表示欄910とコメント表示欄920と確認ボタン930とが含まれている。ユーザは、この入力内容確認ページに示されているデータに間違いがないか確認し、確認ボタン930をクリックする。各表示欄に対してユーザが修正入力可能なようにしてもよいし、図示しないキャンセル・ボタン等が含まれていてもよい。
【0042】
図6の処理フローに戻り、ユーザ端末3は、入力内容確認ページ(図9)に対するユーザからの選択入力を受け付け、選択入力データを管理サーバ5に対して送信する(図6:ステップS17)。管理サーバ5のWebページ管理部500は、選択入力データをユーザ端末3から受信し、一旦記憶装置に格納する(ステップS19)。
【0043】
そして、Webページ管理部500は、オンライン・ギフト券の購入処理を行ってもよい(OK)かどうか判定する(ステップS21)。例えば、入力内容確認ページ(図9)において図示しないキャンセル・ボタンがクリックされた場合や、ユーザの入力内容をチェックしてエラーが発見された場合等には、オンライン・ギフト券の購入処理を行ってはいけない(OKではない)と判断する。
【0044】
OKではないと判定された場合(ステップS21:Noルート)、ステップS5の処理に戻る。一方、OKであると判定された場合(ステップS21:Yesルート)、管理サーバ5のID管理部502は、プリペイド会員データを生成し、ユーザ管理DB512に格納する(ステップS23)。すなわち、ユーザ管理DB512に新規のレコードが1件登録される。なお、登録されるレコードのプリペイド会員フラグの列204(図2)には「0」が格納される。また、URLの列216に、上で述べたようなユーザ固有のURLデータ(パス)が格納される。なお、この時点では、登録されるレコードのパスワードの列202(図2)と正会員フラグの列206(図2)と氏名の列212(図2)とクレジット・カード番号の列214(図2)とには、値が格納されない。
【0045】
そして、管理サーバ5の決済処理部506は、贈呈者IDと受領者IDと商品IDと購入金額とを含むプリペイド決済データを生成し、プリペイド決済DB514に格納する(ステップS25)。すなわち、プリペイド決済DB514に贈呈者IDと受領者IDと商品IDと購入金額とを含む新規のレコードが1件登録される。なお、登録されるレコードの課金フラグの列310(図3)には「0」が格納される。
【0046】
そして、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて処理完了確認ページのデータを生成し、ユーザ端末3に対して送信する(ステップS27)。ユーザ端末3は処理完了確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS29)。図示しないが、処理完了確認ページには、例えば「オンライン・ギフト券の購入を受け付けました。」等のメッセージが含まれる。
【0047】
このようにして、オンライン・ギフト券の購入が受け付けられ、プリペイド・キーが生成される。ステップS27の処理が終わると、処理は端子Aを介して図10の処理に移行する。
【0048】
図10には、プリペイド・キーの贈呈先であるユーザが、例えばユーザ端末7を操作して管理サーバ5にアクセスし、プリペイド・キーを仮受領する際の処理フローが示されている。以下、各処理ステップに基づき説明していく。
【0049】
まず、管理サーバ5のメール処理部504は、Webページ・データ格納部510に格納されているデータとユーザ管理DB512に格納されているデータとを用いてギフト・メールのデータを生成し、プリペイド・キーの贈呈先であるユーザ宛てに送信する(ステップS41)。ユーザ端末7は、ユーザの操作に従い、図示しないメール・サーバを介して管理サーバ5からのギフト・メールのデータを受信し、表示装置に表示する(ステップS43)。
【0050】
図11に、ギフト・メールの表示画面の一例を示す。図11の例には、贈呈元ユーザ表示部1100とメッセージ表示部1110と仮受領確認用URL表示部1120とが含まれている。贈呈元ユーザ表示部1100には、贈呈元であるユーザの氏名(ユーザ管理DB512の氏名の列212(図2)の値)が含まれており、誰からの贈呈か分かるようになっている。メッセージ表示部1110には、オンライン・ギフト券購入ページ(図8)においてコメント入力欄820に入力されたデータが示される。仮受領確認用URL表示部1120には、仮受領確認ページのURLが示されているが、メーラの機能及びその設定によっては、URLがハイパー・リンクになっている場合もある。
【0051】
図10の処理フローに戻り、ユーザ端末7は、例えば仮受領確認用URL表示部1120(図11)に示されているURLに基づきWebページにアクセスするというユーザの指示に従い、仮受領確認ページ・データの要求を管理サーバ5に対して送信する(図10:ステップS45)。管理サーバ5のWebページ管理部500は、仮受領確認ページ・データの要求をユーザ端末7から受信する(ステップS47)。そして、Webページ管理部500は、Webページ・データ格納部510に格納されているデータとユーザ管理DB512に格納されているデータとプリペイド決済DB514に格納されているデータとを用いて仮受領確認ページのデータを生成し、ユーザ端末7に対して送信する(ステップS49)。ユーザ端末7は、仮受領確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS51)。
【0052】
図12に、仮受領確認ページの一例を示す。図12の例には、差出人メール・アドレス表示部1200と受領人メール・アドレス表示部1210と金額表示部1220と受領ボタン1230と受領拒否ボタン1240とが含まれている。差出人メール・アドレス表示部1200には、贈呈元であるユーザのメール・アドレスが示されているが、図11に示した贈呈元ユーザ表示部1100と同様に、ユーザの氏名を示すようにしてもよい。
【0053】
図10の処理フローに戻り、ユーザ端末7は、ユーザからの仮受領確認ページ(図12)に対する選択入力を受け付け、管理サーバ5に対して送信する(図10:ステップS53)。管理サーバ5のWebページ管理部500は、選択入力データをユーザ端末7から受信し、一旦記憶装置に格納する(ステップS55)。
【0054】
そして、Webページ管理部500は、ユーザからの選択入力が「受領」であったかどうか判定する(ステップS57)。仮受領確認ページ(図12)において、ユーザによって受領ボタン1230がクリックされた場合には「受領」と判定し、受領拒否ボタン1240がクリックされた場合には「受領」ではないと判定する。
【0055】
「受領」ではないと判定された場合(ステップS57:Noルート)、管理サーバ5のメール処理部504は、ユーザ管理DB512に格納されているデータを用いて受領拒否通知メールのデータを生成し、贈呈者(贈呈元のユーザ)宛てに送信する(ステップS59)。受領拒否通知メールには、図示しないが、オンライン・ギフト券を受け取ってもらえなかった旨のメッセージが含まれる。なお、この場合、プリペイド・キーの贈呈に関する一連の処理は終了する。ユーザ管理DB512から該当するレコードを削除してもよい。
【0056】
一方、「受領」であったと判定された場合(ステップS57:Yesルート)、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いてパスワード入力ページのデータを生成し、ユーザ端末7に対して送信する(ステップS61)。ユーザ端末7は、パスワード入力ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS63)。
【0057】
図13に、パスワード入力ページの一例を示す。図13の例には、パスワード入力欄1300と確定ボタン1310とが含まれている。ユーザは、パスワード入力欄1300にパスワードを入力し、確定ボタン1310をクリックする。なお、パスワード入力欄1300は、ユーザからの入力文字をそのまま表示せず、アスタリスクで示すようになっている。そこで、入力ミスをチェックするために、パスワード入力欄が複数設けられる場合もある。
【0058】
図10の処理フローに戻り、ユーザ端末7は、ユーザからのパスワード入力ページ(図13)に対するパスワードの入力を受け付け、管理サーバ5に対して送信する(図10:ステップS65)。管理サーバ5のID管理部502は、パスワードをユーザ端末7から受信し、ユーザ管理DB512のパスワードの列202(図2)に格納する(ステップS67)。なお、該当するレコードは、例えばメール・アドレスの列208(図2)の値に基づき特定する。
【0059】
そして、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータとユーザ管理DB512に格納されているデータとを用いて仮受領完了ページのデータを生成し、ユーザ端末7に対して送信する(ステップS69)。ユーザ端末7は、仮受領完了ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS71)。
【0060】
図14に、仮受領完了ページの一例を示す。図14の例には、プリペイド・キー表示部1400とOKボタン1410とが含まれている。ユーザは、プリペイド・キー表示部1400に示された自分のIDを確認し、OKボタン1410をクリックする。
【0061】
このようにして、プリペイド・キーの仮受領処理が行われる。ステップS69の処理が終わると、処理は端子Bを介して図15の処理に移行する。
【0062】
図15には、プリペイド・キーの贈呈先であり且つプリペイド・キーの仮受領を既に行ったユーザが、例えばユーザ端末7を操作して管理サーバ5にアクセスし、プリペイド・キーを本受領する際の処理フローが示されている。以下、各処理ステップに基づき説明していく。
【0063】
まず、管理サーバ5のメール処理部504は、Webページ・データ格納部510に格納されているデータとユーザ管理DB512に格納されているデータとを用いて本受領メールのデータを生成し、プリペイド・キーの贈呈先であるユーザ宛てに送信する(ステップS81)。ユーザ端末7は、ユーザの操作に従い、図示しないメール・サーバを介して管理サーバ5からの本受領メールのデータを受信し、表示装置に表示する(ステップS83)。
【0064】
図16に、本受領メールの表示画面の一例を示す。図16の例には、本受領確認用URL表示部1600が含まれている。本受領確認用URL表示部1600には、本受領確認ページのURLが示されているが、メーラの機能及びその設定によっては、URLがハイパー・リンクになっている場合もある。
【0065】
図15の処理フローに戻り、ユーザ端末7は、例えば本受領確認用URL表示部1600(図16)に示されているURLに基づきWebページにアクセスするというユーザの指示に従い、本受領確認ページ・データの要求を管理サーバ5に対して送信する(図15:ステップS85)。管理サーバ5のWebページ管理部500は、本受領確認ページ・データの要求をユーザ端末7から受信する(ステップS87)。そして、Webページ管理部500は、Webページ・データ格納部510に格納されているデータとユーザ管理DB512に格納されているデータとプリペイド決済DB514に格納されているデータとを用いて本受領確認ページのデータを生成し、ユーザ端末7に対して送信する(ステップS89)。ユーザ端末7は、本受領確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS91)。
【0066】
図17に、本受領確認ページの一例を示す。図17の例には、差出人メール・アドレス表示部1700と受領人メール・アドレス表示部1710と金額表示部1720と「受領する」ボタン1730とが含まれている。差出人メール・アドレス表示部1700には、贈呈元であるユーザのメール・アドレスが示されているが、ユーザの氏名を示すようにしてもよい。ユーザは、各表示部の内容を確認し、「受領する」ボタン1730をクリックする。
【0067】
図15の処理フローに戻り、ユーザ端末7は、ユーザからの本受領確認ページ(図17)に対する選択入力を受け付け、管理サーバ5に対して送信する(図15:ステップS93)。管理サーバ5のWebページ管理部500は、選択入力データをユーザ端末7から受信し、一旦記憶装置に格納する(ステップS95)。なお、ここでのユーザからの選択入力は「受領する」である。
【0068】
そして、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて認証データ入力ページのデータを生成し、ユーザ端末7に対して送信する(ステップS97)。ユーザ端末7は、認証データ入力ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS99)。
【0069】
図18に、認証データ入力ページの一例を示す。図18の例には、ID入力欄1800とパスワード入力欄1810と確定ボタン1820とが含まれている。ユーザは、仮受領完了ページ(図14)において確認したプリペイド・キーをID入力欄1800に入力し、パスワード入力ページ(図13)において設定したパスワードをパスワード入力欄1810に入力し、確定ボタン1820をクリックする。
【0070】
図15の処理フローに戻り、ユーザ端末7は、ユーザからの認証データ入力ページ(図18)に対するID(プリペイド・キー)及びパスワードの入力を受け付け、管理サーバ5に対して送信する(図15:ステップS101)。管理サーバ5のWebページ管理部500は、ID及びパスワードをユーザ端末7から受信し、一旦記憶装置に格納する(ステップS103)。その際、管理サーバ5のID管理部502は、ID及びパスワードが正しく入力されたか、ユーザ管理DB512に格納されているデータを用いてチェックする。正しく入力されていればそのまま処理を続行するが、正しく入力されていなければエラーを返し、例えばユーザに再入力を促す。
【0071】
そして、ID管理部502は、ユーザ管理DB512のプリペイド会員フラグ204(図2)の値を「0」から「1」に更新する(ステップS105)。さらに、管理サーバ5の決済処理部506は、プリペイド決済DB514の該当するレコードの課金フラグの列310(図3)の値を「0」から「1」に更新し、当該レコードのデータを用いて課金データを生成し、課金データDB516に格納する(ステップS107)。すなわち、プリペイド・キーの贈呈先ユーザをプリペイド会員として本登録し、それに伴い、プリペイド・キーの贈呈元ユーザに課金する処理が行われる。
【0072】
そして、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて本受領完了ページのデータを生成し、ユーザ端末7に対して送信する(ステップS109)。ユーザ端末7は、本受領完了ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS111)。
【0073】
図19に、本受領完了ページの一例を示す。図19の例には、メッセージ入力欄1900とバリュー移行用ハイパー・リンク1910とOKボタン1920とが含まれている。バリュー移行用ハイパー・リンク1910がクリックされると、ユーザが受領したプリペイド・キーのバリュー(残高)を、当該プリペイド・キーとは異なる既存のIDに移すためのページに移行する。なお、バリューの移行処理は銀行振替のような処理であり、本発明の要旨ではないため説明を割愛する。例えばユーザは、メッセージ入力欄1900にメッセージを入力し、OKボタン1920をクリックする。
【0074】
図15の処理フローに戻り、ユーザ端末7は、ユーザからの本受領完了ページ(図19)に対する選択入力を受け付け、管理サーバ5に対して送信する(図15:ステップS113)。管理サーバ5のWebページ管理部500は、選択入力データをユーザ端末7から受信し、一旦記憶装置に格納する(ステップS115)。なお、ここでのユーザからの選択入力は「OK」とする。
【0075】
そして、管理サーバ5のメール処理部504は、受領通知メールのデータを生成し、贈呈者(贈呈元のユーザ)宛てに送信する(ステップS117)。受領通知メールには、図示しないが、オンライン・ギフト券の受け取りがなされた旨のメッセージと本受領完了ページのメッセージ入力欄1900(図19)に入力されたメッセージとが含まれる。また、課金に関するデータ(金額や支払日等)が含まれる場合もある。
【0076】
このようにして、プリペイド・キーの本受領処理が行われる。そして、本受領処理を行いプリペイド会員となったユーザは、受領したプリペイド・キーを用いて商品の購入や有償コンテンツの閲覧等を行うことが可能となる。
【0077】
図20には、プロバイダの会員(プリペイド会員を含む)であるユーザが例えばユーザ端末7を操作して管理サーバ5にアクセスし、オンライン・ショッピングを行う際の処理フローが示されている。本実施の形態においては、ユーザ端末7が有するWebブラウザを介してサーバにアクセスすることを想定しているが、専用のクライアント・ソフトウェアを使用する場合もある。以下、各処理ステップに基づき説明していく。
【0078】
まず、ユーザ端末7は、表示しているWebページに対するユーザからの商品購入指示を受け付け、指示データを管理サーバ5に対して送信する(図20:ステップS201)。
【0079】
例えば、図21に示すようなショッピング・ページに対するユーザからの商品購入指示を受け付ける。図21の例には、商品データ表示部2000と「購入する」ボタン2100とが含まれている。「購入する」ボタン2100がクリックされることにより、A商品の購入指示を受け付ける。なお、図21では簡略化した例を示しているが、一般的なオンライン・ショッピングにおける「買い物かご」や「ショッピング・カート」等、複数の購入候補商品についての会計内容を表示し、購入指示を受け付けるようなページであってもよい。
【0080】
図20の処理フローに戻り、管理サーバ5のWebページ管理部500は、購入指示データをユーザ端末7から受信し、一旦記憶装置に格納する(図20:ステップS203)。なお、購入指示データには、商品名、単価、数量、合計金額等の会計データが含まれているものとする。
【0081】
そして、Webページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて購入ユーザ確認ページのデータを生成し、ユーザ端末7に対して送信する(ステップS205)。ユーザ端末7は、購入ユーザ確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS207)。
【0082】
図22に、購入ユーザ確認ページの一例を示す。図22の例には、会計データ表示部2200とID入力欄2210とパスワード入力欄2220と確定ボタン2230とが含まれている。ユーザは、この購入ユーザ確認ページに対して認証データを入力し、確定ボタン2230をクリックする。例えば複数のIDを保有しているユーザは、課金するIDを入力する。なお、ユーザが既にログイン済みである場合には、ログインしているユーザのIDを予めID入力欄2210に埋め込んでおくようにしてもよい。
【0083】
図20の処理フローに戻り、ユーザ端末7は、購入ユーザ確認ページ(図22)に対するユーザからの認証データの入力を受け付け、購入データを管理サーバ5に対して送信する(図20:ステップS209)。なお、購入データには、商品の会計データとユーザの認証データとが含まれているものとする。
【0084】
管理サーバ5のWebページ管理部500は、購入データをユーザ端末7から受信し、一旦記憶装置に格納する(ステップS211)。その際、管理サーバ5のID管理部502は、ID及びパスワードが正しく入力されたか、ユーザ管理DB512に格納されているデータを用いてチェックする。また、ID管理部502は、購入データに含まれるIDが課金可能なIDであるかチェックし、課金不可能なIDであればエラーを返す。具体的には、ユーザ管理DB512の該当するレコードの、プリペイド会員フラグの列204(図2)の値が「1」である又は正会員フラグの列206(図2)の値が「1」である場合には、課金可能である。
【0085】
さらに、ID管理部502は、ユーザ管理DB512に格納されているデータを用いて、商品を購入するユーザ(課金されるID)がプリペイド会員であるかどうか判定する(ステップS213)。ユーザ管理DB512の該当するレコードのプリペイド会員フラグの列204(図2)の値が「1」であれば、プリペイド会員であると判定する。
【0086】
プリペイド会員ではないと判定された場合(ステップS213:Noルート)、後に述べるステップS219の処理に移行する。
【0087】
一方、プリペイド会員であると判定された場合(ステップS213:Yesルート)、管理サーバ5の決済処理部506は、購入データとユーザ管理DB512に格納されているデータとを用いて、プリペイド残高が不足しているかどうか判定する(ステップS215)。具体的には、ユーザ管理DB512の該当するレコードのプリペイド残高の列210(図2)の値が、購入データに含まれる会計金額より少ない場合には、残高不足であると判定する。
【0088】
残高不足であると判定された場合(ステップS215:Yesルート)、処理は端子Cを介して図23の処理に移行する。一方、残高不足ではないと判定された場合(ステップS215:Noルート)、管理サーバ5の決済処理部506は、ユーザ管理DB512の該当するレコードのプリペイド残高の列210(図2)の値を更新する(ステップS217)。すなわち、会計金額分だけ残高を減らす。そして、管理サーバ5の決済管理部506は、購入データを用いて課金データを生成し、課金DB516に格納する(ステップS219)。なお、プリペイド方式での課金データは、決済が既に済んでいるため、課金DB516に格納しないようにしてもよい。
【0089】
そして、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて決済確認ページのデータを生成し、ユーザ端末7に対して送信する(ステップS221)。ユーザ端末7は、決済確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS223)。図示しないが、決済確認ページには、商品の購入(注文)処理が完了したことを通知するメッセージが含まれる。
【0090】
このようにして、プリペイド会員を含むプロバイダの会員ユーザによるオンライン・ショッピングにおける処理が行われる。
【0091】
図23には、ステップS215(図20)において残高不足であると判定された場合(ステップS215:Yesルート)の処理フローが示されている。まず、管理サーバ5の決済処理部506は、プリペイド残高の不足分の金額を例えばワーク・メモリ領域等の記憶装置に一時格納する(ステップS231)。そして、管理サーバ5のWebページ管理部500は、プリペイド残高データとWebページ・データ格納部510に格納されているデータとを用いて残高不足通知ページのデータを生成し、ユーザ端末7に対して送信する(ステップS233)。ユーザ端末7は、残高不足通知ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS235)。
【0092】
図24に、残高不足通知ページの一例を示す。図24の例には、メッセージ表示部2400と「入会手続きへ」ボタン2410とキャンセル・ボタン2420とが含まれている。ユーザは、メッセージ表示部2400に示されているメッセージを確認し、直ちに入会手続きを実施することを希望する場合には、「入会手続きへ」ボタン2410をクリックする。
【0093】
図23の処理フローに戻り、ユーザ端末7は、残高不足通知ページ(図24)に対するユーザからの選択入力を受け付け、管理サーバ5に対して送信する(図23:ステップS237)。管理サーバ5のWebページ管理部500は、選択入力データをユーザ端末7から受信し、一旦記憶装置に格納する(ステップS239)。
【0094】
そして、Webページ管理部500は、残高不足通知ページ(図24)に対するユーザからの選択入力が「入会」であったかどうか判定する(ステップS241)。例えば「入会手続きへ」ボタン2410(図24)がクリックされた場合には「入会」であったと判定し、キャンセル・ボタン2420(図24)がクリックされた場合には「入会」ではなかったと判定する。
【0095】
「入会」であったと判定された場合(ステップS241:Yesルート)、処理は端子Dを介して図25の処理に移行する。一方、「入会」ではなかったと判定された場合(ステップS241:Noルート)、Webページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて購入キャンセル確認ページのデータを生成し、ユーザ端末7に対して送信する(ステップS243)。またこの際、管理サーバ5の決済処理部506は、ステップS231においてワーク・メモリ領域等の記憶装置に一時格納しておいた不足金額に関するデータをクリアする。
【0096】
ユーザ端末7は、購入キャンセル確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS245)。図示しないが、購入キャンセル確認ページには、商品の購入(注文)処理を取りやめた旨のメッセージが含まれる。
【0097】
このようにして、プリペイド残高が不足した場合には、正会員としての登録を促すようになっている。
【0098】
図25には、ステップS241(図23)において「入会」であると判定された場合(ステップS241:Yesルート)の処理フローが示されている。まず、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて入会ページのデータを生成し、ユーザ端末7に対して送信する(ステップS251)。ユーザ端末7は、入会ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS253)。図示しないが、入会ページには、ユーザの氏名の入力欄や、決済に使用するクレジット・カードの番号入力欄等、正会員として登録するために必要なデータを入力するための、入会用データ入力欄が含まれる。
【0099】
そして、ユーザ端末7は、入会ページに対するユーザからの入会用データの入力を受け付け、管理サーバ5に対して送信する(ステップS255)。管理サーバ5のID管理部502は、入力用データをユーザ端末7から受信し、ユーザ管理DB512の該当するレコード(図2)に格納する(ステップS257)。
【0100】
さらに、ID管理部502は、ユーザ管理DB512の該当するレコードの、プリペイド会員フラグの列204(図2)の値をクリアし、正会員フラグの列206(図2)に「1」を格納する(ステップS259)。
【0101】
そして、管理サーバ5の決済処理部506は、ステップS231(図23)においてワーク・メモリ領域等の記憶装置に一時格納しておいた不足金額データと、ユーザ管理DB512の該当するレコードのプリペイド残高の列210(図2)の値とを用いて課金データを生成し、課金DB516に格納する(ステップS261)。本実施の形態においては、図4に示した例の3行目及び4行目のように2レコード登録される。さらに、決済処理部506は、ユーザ管理DB512の該当するレコードのプリペイド残高の列210(図2)の値を「0」に更新する(ステップS263)。
【0102】
そして、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて入会完了確認ページのデータを生成し、ユーザ端末7に対して送信する(ステップS265)。ユーザ端末7は、入会完了確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS267)。図示しないが、入会完了確認ページには、商品の購入(注文)処理が完了したことを通知するメッセージと、ユーザが正会員として登録された旨のメッセージとが含まれる。なお、決済方式が複数になるため、課金データも併せて提示するようにしてもよい。
【0103】
このようにして、プリペイド会員にはIDの再発行をすることなく正会員としての入会手続きが行われる。なお、プリペイド会員が正会員として登録された場合には、インセンティブとして代金のいくらかを減額するようにしてもよい。また、プリペイド・キーの贈呈者に課金されている金額のいくらかを減額するようにしてもよい。
【0104】
図26には、プリペイド会員であるユーザが例えばユーザ端末7を操作して管理サーバ5にアクセスし、正会員として登録する際の処理フローが示されている。本実施の形態においては、ユーザ端末7が有するWebブラウザを介してサーバにアクセスすることを想定しているが、専用のクライアント・ソフトウェアを使用する場合もある。以下、各処理ステップに基づき説明していく。
【0105】
まず、ユーザ端末7は、表示しているメニュー・ページに対するユーザからの「入会」の選択指示を受け付け、指示データを管理サーバ5に対して送信する(図26:ステップS301)。メニュー・ページについては、図7に一例を示したが、例えば会員入会ページへのリンク部700(図7)のクリックを受け付ける。
【0106】
図26の処理フローに戻り、管理サーバ5のWebページ管理部500は、指示データをユーザ端末7から受信し、一旦記憶装置に格納する(図26:ステップS303)。そして、Webページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて入会ユーザ確認ページのデータを生成し、ユーザ端末7に対して送信する(ステップS305)。ユーザ端末7は、入会ユーザ確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS307)。
【0107】
入会ユーザ確認ページの一例を図27に示す。図27の例には、ID入力欄2700とパスワード入力欄2710と確定ボタン2720とが含まれている。ユーザは、この入会ユーザ確認ページに対して認証データを入力し、確定ボタン2720をクリックする。なお、ユーザが既にログイン済みである場合には、ログインしているユーザのIDを予めID入力欄2700に埋め込んでおくようにしてもよい。
【0108】
図26の処理フローに戻り、ユーザ端末7は、入会ユーザ確認ページ(図27)に対するユーザからの認証データの入力を受け付け、認証データを管理サーバ5に対して送信する(図26:ステップS309)。
【0109】
管理サーバ5のWebページ管理部500は、認証データをユーザ端末7から受信し、一旦記憶装置に格納する(ステップS311)。その際、管理サーバ5のID管理部502は、ID及びパスワードが正しく入力されたか、ユーザ管理DB512に格納されているデータを用いてチェックする。正しく入力されていればそのまま処理を続行するが、正しく入力されていなければエラーを返し、例えばユーザに再入力を促す。また、ID管理部502は、ユーザ管理DB512に格納されているデータを用いて、認証データに含まれるIDがプリペイド会員のIDであることを確認する。具体的には、ユーザ管理DB512の該当するレコードの、プリペイド会員フラグの列204(図2)の値が「1」であることを確認する。その他の属性のIDの場合には、図示していないが、例えば新規にIDを発行する処理に移行する。但し、エラーとしてもよい。
【0110】
そして、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて入会ページのデータを生成し、ユーザ端末7に対して送信する(ステップS313)。ユーザ端末7は、入会ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS315)。図示しないが、入会ページには、ユーザの氏名の入力欄や、決済に使用するクレジット・カードの番号入力欄等、正会員として登録するために必要なデータを入力するための、入会用データ入力欄が含まれる。
【0111】
そして、ユーザ端末7は、入会ページに対するユーザからの入会用データの入力を受け付け、管理サーバ5に対して送信する(ステップS317)。管理サーバ5のID管理部502は、入力用データをユーザ端末7から受信し、ユーザ管理DB512の該当するレコード(図2)に格納する(ステップS319)。
【0112】
さらに、ID管理部502は、ユーザ管理DB512の該当するレコードの、プリペイド会員フラグの列204(図2)の値をクリアし、正会員フラグの列206(図2)に「1」を格納する(ステップS321)。なお、プリペイド残高の列210(図2)の値は変更しないため、プリペイドの残高が残っているユーザは、正会員になっても残りの金額分を利用することが可能である。
【0113】
そして、管理サーバ5のWebページ管理部500は、Webページ・データ格納部510に格納されているデータを用いて入会完了確認ページのデータを生成し、ユーザ端末7に対して送信する(ステップS323)。ユーザ端末7は、入会完了確認ページのデータをWebページ管理部500から受信し、表示装置に表示する(ステップS325)。図示しないが、入会完了確認ページには、ユーザが正会員として登録された旨のメッセージ等が含まれる。
【0114】
このようにして、プリペイド会員にはIDの再発行をすることなく正会員としての入会手続きが行われる。
【0115】
以上本発明の一実施の形態について説明したが、本発明はこれに限定されるものではない。例えば図2乃至図5に示したテーブル構成は一例であって、同様のデータを格納するためであれば、別の構成を採用するようにしてもよい。また、必要に応じて項目を追加又は削除するようにしてもよい。例えば、プリペイド会員フラグの列204(図2)と正会員フラグの列206(図2)とを1つの列にまとめて、会員のステータスを管理するようにしてもよい。
【0116】
また、図7、図8、図9、図11、図12、図13、図14、図16、図17、図18、図19、図21、図22、図24及び図27に示した画面構成は一例であって、同様の内容を別の態様にて表現することも可能である。また、管理サーバ5が複数のサーバによって構成されていてもよい。さらに、図1に示した管理サーバ5の機能ブロック構成は一例であって、実際のプログラム・モジュール構成とは異なる場合がある。また、例えば会員向けのオンライン・ショッピングを実現するためのサーバは、管理サーバ5に限らず別の専用サーバ等であってもよい。
【0117】
また、図6、図10、図15、図20、図23、図25及び図26に示した処理フローも一例であって、同様の処理結果が得られる範囲において処理の順序を入れ替えてもよいし、必要に応じてステップを追加又は削除してもよい。
【0118】
【発明の効果】
以上述べたように、本発明によれば、プリペイド形式の決済に関連する新規なサービスを実現することができる。また、効果的なタイミングで入会勧誘を行うことができる。
【図面の簡単な説明】
【図1】本発明の実施の形態におけるシステム概要図である。
【図2】ユーザ管理DBのテーブル構成及び格納されるデータの一例を示す図である。
【図3】プリペイド決済DBのテーブル構成及び格納されるデータの一例を示す図である。
【図4】課金DBのテーブル構成及び格納されるデータの一例を示す図である。
【図5】商品DBのテーブル構成及び格納されるデータの一例を示す図である。
【図6】本発明の実施の形態における処理フロー(その1)を示す図である。
【図7】メニュー・ページの一例を示す図である。
【図8】購入ページの一例を示す図である。
【図9】確認ページの一例を示す図である。
【図10】本発明の実施の形態における処理フロー(その2)を示す図である。
【図11】ギフト・メール表示画面の一例を示す図である。
【図12】仮受領確認ページの一例を示す図である。
【図13】パスワード入力ページの一例を示す図である。
【図14】仮受領完了ページの一例を示す図である。
【図15】本発明の実施の形態における処理フロー(その3)を示す図である。
【図16】本受領メール表示画面の一例を示す図である。
【図17】本受領確認ページの一例を示す図である。
【図18】認証データ入力ページの一例を示す図である。
【図19】本受領完了ページの一例を示す図である。
【図20】本発明の実施の形態における処理フロー(その4)を示す図である。
【図21】ショッピング・ページの一例を示す図である。
【図22】購入ユーザ確認ページの一例を示す図である。
【図23】本発明の実施の形態における処理フロー(その5)を示す図である。
【図24】残高不足通知ページの一例を示す図である。
【図25】本発明の実施の形態における処理フロー(その6)を示す図である。
【図26】本発明の実施の形態における処理フロー(その7)を示す図である。
【図27】入会ユーザ確認ページの一例を示す図である。
【符号の説明】
1 ネットワーク 3,7 ユーザ端末 5 管理サーバ
500 Webページ管理部 502 ID管理部
504 メール処理部 506 決済処理部
510 Webページ・データ格納部
512 ユーザ管理DB
514 プリペイド決済DB
516 課金DB 518 商品DB
Claims (11)
- プリペイド方式での決済に用いるためのキーの配布要求を受信した場合、正会員へのID設定ルールに従ったキーを生成し、記憶装置に格納するプリペイド・キー生成ステップと、
前記記憶装置に格納されたキーを用いた、正会員への登録要求を受信した場合、前記キーを正会員のIDとして利用可能なように前記記憶装置に設定する会員登録ステップと、
を含む、コンピュータにより実行される情報処理方法。 - 前記プリペイド・キー生成ステップが、前記キーを特定のユーザに関連付けるステップ
を含む、請求項1記載のコンピュータにより実行される情報処理方法。 - 前記特定のユーザは、正会員として未登録のユーザであることを特徴とする、
請求項2記載のコンピュータにより実行される情報処理方法。 - 前記会員登録ステップが、前記記憶装置に設定される、前記特定のユーザのステータスを表すデータを、正会員を表すデータに変更し、前記記憶装置に設定するステップ
を含む、請求項2記載のコンピュータにより実行される情報処理方法。 - 前記キーに対応付けられている金額を超える決済要求を受信した場合、当該決済要求を行ったユーザに正会員登録を促すステップ
をさらに含む、請求項1記載のコンピュータにより実行される情報処理方法。 - 前記決済要求における決済金額と前記キーに対応付けられている金額との差額を、正会員登録された前記ユーザへの課金データとして課金データ格納部に格納するステップ
をさらに含む、請求項5記載のコンピュータにより実行される情報処理方法。 - 前記プリペイド・キー生成ステップが、前記キーに特定のパスワードを関連付けるステップ
を含む、請求項1記載のコンピュータにより実行される情報処理方法。 - 前記会員登録ステップにおいて、前記特定のパスワードを、正会員のIDに対応するパスワードとして設定することを特徴とする
請求項7記載のコンピュータにより実行される情報処理方法。 - あるユーザから、プリペイド方式での決済に利用できる金額の指定と当該金額をプリペイド方式の決済に用いるためのキーを特定のユーザに配布する指示とを受け付けた場合、
前記特定のユーザによる前記キーの使用開始が確認された時点において、前記あるユーザにより指定され且つ前記キーに対応付けられている金額を、前記あるユーザへの課金データとして課金データ格納部に格納するステップ
をさらに含む、請求項1記載のコンピュータにより実行される情報処理方法。 - 請求項1乃至9のいずれか1つに記載の情報処理方法をコンピュータに実行させるためのプログラム。
- プリペイド方式での決済に用いるためのキーの配布要求を受信した場合、正会員のID設定ルールに従ったキーを生成し、記憶装置に格納する手段と、
前記記憶装置に格納されたキーを用いた、正会員への登録要求を受信した場合、前記キーを正会員のIDとして利用可能なように前記記憶装置に設定する手段と、
を有する情報処理システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003137125A JP2004341793A (ja) | 2003-05-15 | 2003-05-15 | プリペイド決済方式に関連する情報処理方法及びプログラム並びにシステム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003137125A JP2004341793A (ja) | 2003-05-15 | 2003-05-15 | プリペイド決済方式に関連する情報処理方法及びプログラム並びにシステム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004341793A true JP2004341793A (ja) | 2004-12-02 |
Family
ID=33526866
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003137125A Pending JP2004341793A (ja) | 2003-05-15 | 2003-05-15 | プリペイド決済方式に関連する情報処理方法及びプログラム並びにシステム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004341793A (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007310744A (ja) * | 2006-05-19 | 2007-11-29 | Rakuten Inc | サービス提供システム、サービス処理装置、会員情報登録方法、及び、会員情報登録処理プログラム |
WO2018185816A1 (ja) * | 2017-04-03 | 2018-10-11 | 株式会社One Tap BUY | 購入システム、購入処理方法、購入対象サーバ、及びコンピュータプログラム |
JP2019519050A (ja) * | 2016-06-22 | 2019-07-04 | アリババ グループ ホウルディング リミテッド | リソース処理方法及び装置 |
JP2020144481A (ja) * | 2019-03-04 | 2020-09-10 | 株式会社ミクシィ | 情報処理装置及び情報処理プログラム |
-
2003
- 2003-05-15 JP JP2003137125A patent/JP2004341793A/ja active Pending
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007310744A (ja) * | 2006-05-19 | 2007-11-29 | Rakuten Inc | サービス提供システム、サービス処理装置、会員情報登録方法、及び、会員情報登録処理プログラム |
JP2019519050A (ja) * | 2016-06-22 | 2019-07-04 | アリババ グループ ホウルディング リミテッド | リソース処理方法及び装置 |
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 (ja) * | 2017-04-03 | 2018-10-11 | 株式会社One Tap BUY | 購入システム、購入処理方法、購入対象サーバ、及びコンピュータプログラム |
JPWO2018185816A1 (ja) * | 2017-04-03 | 2020-02-20 | 株式会社One Tap BUY | 購入システム、購入処理方法、購入対象サーバ、及びコンピュータプログラム |
JP2020144481A (ja) * | 2019-03-04 | 2020-09-10 | 株式会社ミクシィ | 情報処理装置及び情報処理プログラム |
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 (ja) | 仮想支払アカウントを用いてインターネットワークを介して商品、サービス及びコンテンツを注文する方法及び装置 | |
CN103797502B (zh) | 无cookie的电子商务平台 | |
JPH11296587A (ja) | 電子モールサーバ,電子モールクライアント,電子モールシステム及び記憶媒体 | |
JP2003524240A (ja) | 電子トークンを用いて電子商取引を処理するための方法及び装置 | |
JP2001216441A (ja) | 電子トークンを用いて電子商取引を実行する方法 | |
JP2009507279A (ja) | 安全なインターネット電子商取引方式 | |
WO2014140688A1 (en) | System for management and activation of conditional bid offers | |
US20090307102A1 (en) | System and method for providing donations | |
WO2012106148A2 (en) | Method and system for facilitating electronic commerce | |
JP5196730B2 (ja) | 電子ショッピングモールシステム | |
JP2010165048A (ja) | ネットワークを介した商取引を支援する方法、サーバ装置、プログラムおよび記録媒体 | |
JP2002236834A (ja) | 電子商取引方法 | |
JP2004062545A (ja) | 有価価値情報の管理方法及び管理システム並びに有価価値情報管理プログラム | |
JP2004341793A (ja) | プリペイド決済方式に関連する情報処理方法及びプログラム並びにシステム | |
JP4679048B2 (ja) | 電子チケット管理・流通システム及び電子チケット流通サーバ | |
JP2002056207A (ja) | 商品券取引方法及びシステム | |
KR20110035571A (ko) | 위젯을 이용한 쇼핑 서비스 제공 장치 및 방법 | |
KR20010091907A (ko) | 인증 대리 수단을 갖춘 인터넷 상에서의 정보 제공방법 및그 구현 시스템 | |
JP2002163528A (ja) | 特典管理装置、有料サービス管理装置、ポイントサービス提供システム及びポイントサービス提供方法 | |
KR102383017B1 (ko) | 블록체인 기반의 모바일 무기명 비화폐 결제를 위한 방법 및 시스템 | |
JP2003006528A (ja) | 注文情報結合方法、注文情報結合プログラム、注文情報結合装置、注文受付方法、注文受付プログラム、および注文受付装置 | |
JP3552098B2 (ja) | 情報処理方法および情報処理装置 |
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 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090525 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20090804 |