WO2013179818A1

WO2013179818A1 - 購入管理装置、購入管理方法、プログラムおよびコンピュータ読み取り可能な記憶媒体

Info

Publication number: WO2013179818A1
Application number: PCT/JP2013/061884
Authority: WO
Inventors: 久範山原
Original assignee: 楽天株式会社
Priority date: 2012-05-31
Filing date: 2013-04-23
Publication date: 2013-12-05
Also published as: JP2013250822A; JP5668023B2; US20150149325A1

Abstract

　電子商取引において、より柔軟に支払限度額を運用することのできる技術を提供すること。　購入管理サーバは、ユーザが入力した所定の期間における支払限度額を記憶部に記憶させ、商品またはサービスの少なくとも一方からなる商材であって前記ユーザが購入する商材を含む今回の購入内容に従って購入処理を実行し、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、前記ユーザの今回および過去の少なくとも一方の購入内容に基づいて今回の前記購入処理を制限するか否かを決定する。

Description

購入管理装置、購入管理方法、プログラムおよびコンピュータ読み取り可能な記憶媒体

　本発明は購入管理装置、購入管理方法、プログラムおよびコンピュータ読み取り可能な記憶媒体に関する。

　商品を販売しているＷｅｂサイト等で、一定期間（例えば月）ごとにユーザが支払をすることができる支払限度額を設定する方法がある。また、ユーザはその支払限度額を任意に設定することもできる。

　特許文献１には、上述のようにユーザが取引限度額を設定し、所定期間内の取引金額合計と今回の注文金額との合算金額が取引限度額を超える場合に注文処理を停止する電子商取引システムが開示されている。

特開２００２－１０９４３７号公報

　上述のように取引限度額を設定する目的の１つは、無駄使いを減らすことであると考えられる。しかしながら、無駄遣いを減らすという目的を中心に考えた場合、これまでの支払金額と今回の注文における金額との合計が支払限度額を超えたものを一律に許可しないことが適切でない場合もある。

　本発明は上記課題を鑑みてなされたものであって、その目的は、支払限度額を用いてより柔軟にユーザの支出を管理することができる技術を提供することにある。

　上記課題を解決するために、本発明にかかる購入管理装置は、ユーザが入力した所定の期間における支払限度額を記憶部に記憶させる支払限度額入力手段と、商品またはサービスの少なくとも一方からなる商材であって前記ユーザが購入する商材を含む今回の購入内容に従って購入処理を実行する購入手段と、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、前記ユーザの今回および過去の少なくとも一方の購入内容に基づいて前記購入手段による今回の購入処理を制限するか否かを決定する制限手段と、を含むことを特徴とする。

　また、本発明にかかる購入管理方法は、ユーザが入力した所定の期間における支払限度額を記憶部に記憶させるステップと、商品またはサービスの少なくとも一方からなる商材であって前記ユーザが購入する商材を含む今回の購入内容に従って購入処理を実行するステップと、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、前記ユーザの今回および過去の少なくとも一方の購入内容に基づいて今回の前記購入処理を制限するか否かを決定するステップと、を含むことを特徴とする。

　また、本発明にかかるプログラムは、ユーザが入力した所定の期間における支払限度額を記憶部に記憶させる支払限度額入力手段、商品またはサービスの少なくとも一方からなる商材であって前記ユーザが購入する商材を含む今回の購入内容に従って購入処理を実行する購入手段、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、前記ユーザの今回および過去の少なくとも一方の購入内容に基づいて前記購入手段による今回の購入処理を制限するか否かを決定する制限手段、としてコンピュータを機能させることを特徴とする。

　また、本発明にかかるコンピュータ読取り可能な記憶媒体は、上記プログラムを格納することを特徴とする。

　本発明によれば、支払限度額を用いてより柔軟にユーザの支出を管理することができる。

　本発明の一態様では、前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、今回前記ユーザが購入する商材の属性に基づいて今回の購入処理を制限するか否かを決定してもよい。

　本発明の一態様では、前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、商材の属性と購入を制限する対象であるかを関連づける情報と、前記ユーザが購入を希望する商材の属性とに基づいて今回の購入処理を制限するか否かを決定してもよい。

　本発明の一態様では、前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、複数の商材のそれぞれの単価を記憶する手段から取得された前記ユーザが購入する商材の単価に基づいて今回の購入処理を制限するか否かを決定してもよい。

　本発明の一態様では、前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、前記ユーザが購入する商材の単価と当該商材に対し複数の商材のそれぞれと当該商材に関係する商材とを関連づける情報により関連づけられた商材の単価に基づく基準額とに基づいて今回の購入処理を制限するか否かを決定してもよい。

　本発明の一態様では、前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、当該ユーザの過去かつ前記所定の期間における購入内容に含まれる商材の属性に基づいて今回の購入処理を制限するか否かを決定してもよい。

　本発明の一態様では、前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、当該ユーザの過去かつ前記所定の期間における購入内容に含まれる商材のうち、商材の属性と購入を制限する対象であるかを関連づける情報が購入を制限する対象と関連づける属性を有する商材に対する支払金額の合計の、前記支払限度額に対する割合に基づいて、今回の購入処理を制限するか否かを決定してもよい。

　本発明の一態様では、前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、当該ユーザの過去かつ前記所定の期間における購入内容に含まれる商材のうち、商材の属性と購入を制限する対象であるかを関連づける情報が購入を制限する対象と関連づけない属性を有する商材に対する支払金額の合計の、前記支払限度額に対する割合に基づいて、今回の購入処理を制限するか否かを決定してもよい。

　本発明の一態様では、前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、前記合計が前記支払限度額を超える金額に基づいて今回の購入処理を制限するか否かを決定してもよい。

　本発明の一態様では、前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超え、かつ、前記合計が前記支払限度額を超える金額の今回の購入内容に含まれる商材の単価の最小値に対する割合が所定の割合を超えない場合に、今回の購入処理を制限しないと決定してもよい。

　本発明の一態様では、前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超え、かつ前記合計が前記支払限度額を超える金額が前記購入内容に含まれる手数料より小さい場合に、今回の購入処理を制限しないと決定してもよい。

　本発明の一態様では、前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、前記ユーザが商材を購入する時間が前記所定の期間内のどこであるかに基づいて今回の購入処理を制限すると決定してもよい。

　本発明の一態様では、前記支払金額は、前記ユーザが購入する商材の単価に数量を掛けた額と、その購入における手数料との和から前記ユーザにより定まる支払減少額を引いた金額であってもよい。

　本発明の一態様では、前記制限手段は、前記所定の期間における前記ユーザの支払金額の合計が前記支払限度額を超える場合に今回の購入処理を制限すると決定してもよい。

本発明の実施形態にかかる電子商取引システムの機器構成の一例を示す図である。本発明の実施形態にかかる仮想商店街サーバの構成の一例を示す図である。本発明の実施形態にかかる仮想商店街サーバが実現する機能を示す機能ブロック図である。支払限度額入力部の処理フローの一例を示す図である。支払限度額設定画面の一例を示す図である。ユーザ情報格納部に格納されるユーザ情報の一例を示す図である。購入処理部および購入制限部の処理フローの一例を示す図である。購入処理部および購入制限部の処理フローの一例を示す図である。商品選択画面の一例を示す図である。商品情報格納部に格納される商品情報の一例を示す図である。支払限度額についての警告画面の一例を示す図である。カートの内容を表示するカート表示画面の一例を示す図である。支払・配送方法設定画面の一例を示す図である。購入できない旨を表示するメッセージ面の一例を示す図である。注文履歴格納部に格納される注文内容の情報の一例を示す図である。購入制限部に含まれるカート確認部または注文決定確認部の処理フローの一例を示す図である。購入制限情報の一例を示す図である。

　以下では、本発明の実施形態について図面に基づいて説明する。同じ符号を付された構成については、その前に説明した内容と違いが無い場合はその構成の説明を省略する。

　図１は、本発明の実施形態にかかる電子商取引システムの機器構成の一例を示す図である。この電子商取引システムは、仮想商店街サーバ１と、仮想商店街サーバ１が提供する電子商取引サービスを利用するユーザのユーザＰＣ２とを含む。これらは、ネットワークの一種であるインターネット３を介して接続されている。

　仮想商店街サーバ１は、電子商取引を行う商店の機能を実現する。より具体的には、仮想商店街サーバ１は購入管理機能、顧客管理機能、商品管理機能などを実現する。購入管理機能は、より具体的には、商品検索機能、商品紹介機能、受注機能、決済機能などを含む。ユーザＰＣ２は、例えばパーソナルコンピュータである。また、仮想商店街サーバ１のうち購入管理機能のみを別のサーバやクライアント側のコンピュータで実現してもよい。以下では、仮想商店街サーバ１が商品を扱う場合について説明するが、仮想商店街サーバ１がサービスも同様に扱うことはもちろんである。ここでは、商品およびサービスをあわせて「商材」と呼ぶ。

　図２は、本発明の実施形態にかかる仮想商店街サーバ１のハードウェア構成の一例を示す図である。仮想商店街サーバ１は、プロセッサ１１、記憶部１２、通信部１３、入出力部１４を含む。仮想商店街サーバ１は、例えばデータセンタなどに設置されるサーバコンピュータであってよい。

　プロセッサ１１は、記憶部１２に格納されているプログラムに従って動作する。またプロセッサ１１は通信部１３、入出力部１４を制御する。なお、上記プログラムは、インターネット等のネットワークを介して提供されるものであってもよいし、ＤＶＤ－ＲＯＭ等のコンピュータで読み取り可能な記憶媒体に格納されて提供されるものであってもよい。

　記憶部１２は、ＲＡＭやフラッシュメモリ等のメモリ素子やハードディスクドライブ等によって構成されている。記憶部１２は、上記プログラムを格納する。また、記憶部１２は、各部から入力される情報や演算結果を格納する。

　通信部１３は、ユーザＰＣ２などの他の装置と通信する機能を実現するものであり、例えば有線ＬＡＮを構成する集積回路や通信端子を有するネットワークカードにより構成されている。通信部１３は、ＣＰＵ１１の制御に基づいて、他の装置から受信した情報をＣＰＵ１１や記憶部１２に入力し、他の装置に情報を送信する。

　入出力部１４は、表示出力デバイスや入力デバイスとのやりとりを行う回路であり、例えば表示出力デバイスに画像を出力させるグラフィックボードや、キーボードやマウスなどの入力デバイスからのデータを取得するＵＳＢコントローラなどにより構成される。入出力部１４は、プロセッサ１１の制御に基づいて、画像データ等を表示出力デバイスに対して出力し、入力デバイスより操作者（ユーザ）からの情報を取得する。

　図３は、本発明の実施形態にかかる仮想商店街サーバ１が実現する機能を示す機能ブロック図である。仮想商店街サーバ１は機能的に、支払限度額入力部５１と、購入処理部５２と、購入制限部５３と、を含む。機能的に、購入処理部５２は、商品選択部５４と注文決定部５５と注文実行部５６とを含み、購入制限部５３は、カート確認部５７と注文決定確認部５８とを含む。これらの機能は、仮想商店街サーバ１を構成するプロセッサ１１が記憶部１２に格納されたプログラムを実行し、通信部１３等を制御することで実現される。また、ユーザ情報格納部６１と、商品情報格納部６２と、注文履歴格納部６３とは、仮想商店街サーバ１の記憶部１２により実現される。なお、ユーザ情報格納部６１と、商品情報格納部６２と、注文履歴格納部６３とは他のサーバの記憶手段等により実現されてもよい。また、支払限度額入力部５１と、購入処理部５２と、購入制限部５３とは、仮想商店街サーバ１の代わりに決済機能を有する携帯端末などのクライアントに含まれるプロセッサ、記憶部等により実現されてもよい。携帯端末の場合に特有の処理については、随時説明する。

　図４は、支払限度額入力部５１の処理フローの一例を示す図である。支払限度額入力部５１は、プロセッサ１１、記憶部１２および通信部１３を中心として実現される。以下では、支払限度額入力部５１について、処理フローを用いながら説明する。支払限度額入力部５１は、ユーザがユーザＰＣ２に入力する所定の期間における支払限度額等の情報を通信部１３を介して取得し、記憶部１２に記憶させる。より具体的には、はじめに、支払限度額入力部５１は、集計期間（上述の所定の期間に相当する）、支払限度額、支払限度額判定の例外の有無および期間内の支払制限対象品に対する支払金額の割合の上限値（図中「期間内の贅沢品の割合の上限」）を入力する支払限度額設定画面を表示させる画像データ（例えばＨＴＭＬデータ）を生成し、通信部１３を介してユーザＰＣ２に向けて送信する（ステップＳ３０１）。ユーザＰＣ２は、この画像データに基づいて、ユーザＰＣ２に接続されたディスプレイに支払限度額設定画面を表示させる。集計期間は、支払限度額と比較するための支払金額の合計額を集計する期間（例えば月単位や週単位の期間）である。

　図５は、支払限度額設定画面の一例を示す図である。支払限度額設定画面はいわゆるブラウザに表示される画面であり、ユーザは、支払限度額や期間内の支払制限対象品に対する支払金額の割合の上限値は入力フィールドに入力し、集計期間や例外有無はラジオボタンで入力する。また、図５に示す支払限度額設定画面には「設定」ボタンや「キャンセル」ボタンが配置されている。ユーザが支払限度額等を支払限度額設定画面の入力項目に入力した上で、「設定」ボタンを押下すると、ユーザＰＣ２はこれらの情報を仮想商店街サーバ１に送信する。なお、支払限度額の解除については、例えば、ユーザが支払限度額の欄を空欄にした場合に支払限度額を解除するようにすればよい。

　次に、支払限度額入力部５１は、ユーザＰＣ２から送信される集計期間、支払限度額、上述の例外の有無、および期間内の購入制限対象品に対する支払金額の割合の上限値を取得する（ステップＳ３０２）。そして、支払限度額入力部５１は、操作しているユーザについて、これらの情報に基づいてユーザ情報格納部６１に格納されているユーザ情報を変更する（ステップＳ３０３）。

　図６は、ユーザ情報格納部６１に格納されるユーザ情報の一例を示す図である。ユーザ情報格納部６１には、ユーザにつき１つのユーザ情報が格納されている。１つのユーザ情報は、ユーザＩＤと、ユーザ名と、支払限度額と、集計期間と、例外と、購入制限対象品の割合上限と、期間内の支払金額合計と、期間内の購入制限対象品への支払金額合計と、の情報を含む。支払限度額入力部５１は、支払限度額設定画面により入力された支払限度額、集計期間、例外有無、支払制限対象品に対する支払金額の割合の上限値を、ユーザ情報のそれぞれ支払限度額、集計期間、例外、購入制限対象品の割合上限の欄に上書きする。なお、図６の例では、支払限度額の欄が支払限度額の設定の有無の情報を兼ねている。例えば支払限度額が設定されていない、あるいは以前設定されていた支払限度額の設定が解除された状態では、支払限度額の欄は空とすればよい。

　購入処理部５２は、主にプロセッサ１１と記憶部１２と通信部１３とを中心として実現され、ユーザからの入力に基づいて、ユーザが購入する商品を含む今回の注文内容を決定し、その決定された注文内容に従って購入処理を実行する。また、購入制限部５３は、主にプロセッサ１１と記憶部１２とを中心として実現され、集計期間におけるユーザの支払金額と今回の注文内容における支払金額との合計が支払限度額を超える場合に、ユーザの今回または過去の注文内容に基づいて購入処理部５２による今回の購入処理を制限する。

　図７および図８は、購入処理部５２および購入制限部５３の処理フローの一例を示す図である。以下では、これらが行う処理について、処理フローに従って説明する。

　購入処理部５２に含まれる商品選択部５４は、主にプロセッサ１１と記憶部１２と通信部１３とを中心として実現される。商品選択部５４は、ユーザが購入を希望する商品の情報を取得し、取得した商品を買い物かご（カート）に追加してその買い物かごの内容に基づく注文内容を注文決定部５５に渡す。

　より具体的には、はじめに、商品選択部５４は、対話的な処理に基づいて商品詳細画面の画像データを出力する（ステップＳ１０１）。ユーザＰＣ２はこの画像データに基づいて商品詳細画面を出力する。商品詳細画面は商品の説明や単価などを表示する画面であり、商品選択部５４は、ユーザＰＣ２に、商品検索画面や商品の一覧表示画面を表示させ、また、その画面においてユーザが入力する検索条件や商品の選択などから商品詳細画面に出力する商品を特定し、その商品の商品詳細画面をユーザＰＣ２に出力させる。

　図９は、商品詳細画面の一例を示す図である。商品詳細画面には、店舗名、商品名、商品の画像（図中の商品名の下の四角い枠）、単価等が配置され、また商品の数量を入力する欄と、この商品を買い物かごに入れるためのボタンとが配置される。ユーザが数量の欄に購入を希望する商品の数量を入力したうえで「買い物かごにいれる」ボタンを押下すると、商品や数量の情報が商品選択部５４に向けて送信される。

　次に、商品選択部５４は、ユーザが入力する商品および数量、言い換えればユーザが購入を希望する商品の情報および数量を取得する（ステップＳ１０２）。商品選択部５４が取得する商品の情報は、その商品の商品ＩＤと、その商品の数量と、その商品を販売する店舗の店舗ＩＤと、商品の単価とである。

　これらの商品の情報は、元々は商品選択部５４が商品情報格納部６２から取得した商品情報であり、これらの商品情報は商品詳細画面を出力させる際に商品選択部５４からユーザＰＣ２に送信された情報である。図１０は、商品情報格納部６２に格納される商品情報の一例を示す図である。商品選択画面に出力される情報や、商品選択部５４が取得する情報は、数量を除き商品情報格納部６２に格納されている。商品情報格納部６２は、店舗と商品との組合せにつき１つの商品情報を格納する。例えば商品情報は、店舗ＩＤ、商品ＩＤ、商品名、商品のカテゴリ、商品の単価、在庫数などの情報を含む。

　商品選択部５４は、ユーザが購入を希望する商品の情報や数量（現時点の注文内容）を取得すると、それらの情報を用いて購入制限部５３に含まれるカート確認部５７に購入制限するか否かを問い合わせ、またカート確認部５７は購入制限するか否かを判定する（ステップＳ１０３）。ここで、購入制限部５３に含まれるカート確認部５７および注文決定確認部５８は、支払限度額とこれまでの支払金額および今回の注文における支払金額（予測値も含む）の合計とに基づいて購入制限するか否かを判定する。ステップＳ１０３で用いる今回の支払金額は、正確には支払金額の予測値であり、ユーザが購入を希望する商品ごとに単価に数量をかけた金額である。カート確認部５７や注文決定確認部５８が行う購入制限の判定についての詳細は後述する。なお、予測値は、ユーザが購入を希望する商品ごとに単価に数量をかけた金額から支払減少可能な額を引いた金額であってもよい。この場合、支払減少可能な額は、例えばポイント残額や、使っていないギフト金額である。ポイント残額はユーザの商品購入などに応じて加算されるものである。ギフト金額は他のユーザなどから電子的に送られて加算されるものである。ポイント残額やギフト金額はユーザと関連づけて記憶部１２に記憶されている。

　次に、商品選択部５４は、カート確認部５７からの問い合わせの回答である判定結果が購入制限無しの場合には（ステップＳ１０４のＮ）、ステップＳ１０７のカートに商品を追加する処理に移る。また判定結果が購入制限有りの場合には（ステップＳ１０４のＹ）、ユーザに向けて警告画面を出力し、ユーザからユーザＰＣ２を介して購入を中止するか否かの選択結果を取得する（ステップＳ１０５）。

　図１１は、支払限度額についての警告画面の一例を示す図である。支払限度額を超過し、さらにカート確認部５７が用いる他の条件を満たす場合に、商品選択部５４は警告画面を出力する。ユーザは、この警告画面で、買い物かごに商品を入れる（「このまま買い物を続ける」ボタン）か、この商品について購入処理を中止する（「この商品をキャンセルする」ボタン）かを選択する。

　そして、ユーザから購入処理を中止する入力がない（図１１の例で「このまま買い物を続ける」ボタンが押下された）場合には（ステップＳ１０６のＮ）、カートに商品および数量の情報を追加する（ステップＳ１０７）。また、ユーザから購入中止の入力がある（図１１の例で「この商品をキャンセルする」ボタンが押下された）場合には（ステップＳ１０６のＮ）、この商品の情報をカートに追加せずに、ステップＳ１０１の処理に戻る。このようにして、購入処理部５２による購入処理の進行が制限される。なお、支払制限有りでもカートへの商品の追加を可能とするのは、カートに商品を置いたまま今回の集計期間が経過するのを待つことを可能にするためである。

　カートに商品の情報や数量が追加されると、商品選択部５４はそのカートの内容を示すカート画面の画像データをユーザＰＣ２に向けて出力する（ステップＳ１０８）。図１２は、カートの内容を表示するカート表示画面の一例を示す図である。ユーザは、カート表示画面を介して、「削除」ボタンの押下による商品の削除の指示、「購入」チェックボックスによる今回の購入対象商品の指定、「購入手続を進める」「さらに商品を探す」ボタンによる購入手続を進めるか否かの指示とを入力することができる。なお、「削除」ボタンの処理の詳細については説明を省略する。

　そして、商品選択部５４は、そのカート画面に対するユーザの入力を取得する（ステップＳ１０９）。商品選択部５４は、ユーザから購入手続を進める指示を取得した場合には（ステップＳ１１０のＹ）、ステップＳ１１１以降の注文決定部５５の処理に進む。一方、ユーザから商品選択を続ける指示を取得した場合には（ステップＳ１１０のＮ）、ステップＳ１０１の処理に戻る。

　購入処理部５２に含まれる注文決定部５５は、主にプロセッサ１１と記憶部１２とを中心として実現される。注文決定部５５は、商品選択部５４から取得した購入対象となる商品の情報や、ユーザが入力する支払方法や配送方法の設定に基づいて注文内容を決定する。

　はじめに、注文決定部５５は、注文内容のうち、カート画面で指定された購入対象商品の情報とその購入対象商品の数量とを取得する（ステップＳ１１１）。次に、注文決定部５５は、支払方法や配送方法を設定する画面を表示させるデータをユーザＰＣ２に向けて出力する（ステップＳ１１２）。

　図１３は、支払・配送方法設定画面の一例を示す図である。支払・配送方法設定画面にはポイント利用額を設定する欄や、支払に用いる決済手段を指定する項目、配送方法（配送先の住所やラッピング有無）を入力する欄が設けられている。ユーザは、支払・配送方法設定画面を用いて注文決定部５５にこれらの情報を送信する。

　次に、注文決定部５５は、ユーザから決済手段、配送方法、ポイント利用額の情報を取得する（ステップＳ１１３）。ここで、これらの情報は、注文内容に含まれる手数料や、今回の支払金額を決定するのに用いられる。例えば、配送方法により配送手数料が決定され、決済手段により決済手数料（例えば代引手数料）が決定され、ポイント利用額などの割引金額や、図示しないギフト利用額により、ユーザが支払う金額を減少させる額（ここでは支払減少額とする）が決定される。今回の注文内容における支払金額は、商品ごとにその単価と数量を掛けたものの合計に決済手数料や配送手数料などの手数料を足し、さらに上述の支払減少額を反映した金額である。

　次に、注文決定部５５は、決済手段、配送方法、ポイント利用額等の情報を用いて購入制限部５３に含まれる注文決定確認部５８に購入制限するか否かを問い合わせる。また注文決定確認部５８は購入制限するか否かを判定する（ステップＳ１１４）。注文決定確認部５８の詳細な処理については後述する。

　次に、注文決定部５５は、注文決定確認部５８からの問い合わせの回答である判定結果が購入制限有りの場合には（ステップＳ１１５のＹ）、購入できない旨を表示する画面の情報をユーザＰＣ２に向けて出力し（ステップＳ１１６）処理を終了する。判定結果が購入制限無しの場合には（ステップＳ１１５のＮ）、注文実行部５６がステップＳ１１７以降の処理を実行する。

　図１４は、購入制限有りとなった場合に購入できない旨を表示するメッセージ画面の一例を示す図である。ここで、「ＯＫ」ボタンを押下すると購入に関する処理が終了する。

　購入処理部５２に含まれる注文実行部５６は、主にプロセッサ１１と記憶部１２と通信部１３とを中心として実現される。注文実行部５６は、注文決定部５５が決定した注文内容に従って購入処理を実行する。より具体的には、注文実行部５６は、注文内容の情報を注文内容に含まれる商品を販売する店舗に送信する（ステップＳ１１７）。注文実行部５６は、店舗側からの事前の設定に応じ、ユーザが指定した決済手段を用いた決済や、発送作業を管理するコンピュータへのデータの送信を行ってもよい。次に、注文実行部５６は、今回の注文内容を注文履歴格納部６３に追加し（ステップＳ１１８）、今回の注文における支払金額をユーザ情報の支払金額合計に加算してその欄に書込む。また注文実行部５６は支払金額のうち購入制限対象品に対する金額を計算し、その金額をユーザ情報の購入制限対象品の額に加算してその欄に書込む。そして今回の購入処理を終了する。このようにしてユーザの注文内容に対する購入処理が制限される。なお、購入制限対象品については後述する。

　なお、携帯端末により実現される購入処理部５２は、店頭のＰＯＳ端末等からユーザが指示する購入内容（金額および購入日時を含み、商品も含んでよい）を取得し、その購入内容について購入制限部５３に購入制限するか否かを問い合わせ、その問い合わせに対して購入制限部５３から購入できる旨の回答を得た場合に決済処理を実行することでその購入処理を実行してもよい。ここで、購入内容は、単なる注文をする場合の注文内容だけでなく、店頭で購入する場合にその購入に関する内容も含む概念である。

　図１５は、注文履歴格納部６３に格納される注文内容の情報の一例を示す図である。図１５に示す注文履歴としての注文内容は、注文履歴格納部６３のうち特に、ユーザＩＤ，店舗ＩＤ、注文日時、および支払金額や購入制限対象品に支払った金額となっているが、商品の商品ＩＤや数量などの情報を含んでいてもよい。

　以下では、購入制限部５３の処理の詳細について説明する。購入制限部５３は、主にプロセッサ１１および記憶部１２を中心として実現される。購入制限部５３は、集計期間におけるユーザの支払金額と今回の注文内容における支払金額との合計が支払限度額を超える場合に、ユーザの今回または過去の注文内容に基づいて購入処理部５２が今回の購入処理を進めることを制限する。

　図１６は、購入制限部５３に含まれるカート確認部５７または注文決定確認部５８の処理フローの一例を示す図である。カート確認部５７および注文決定確認部５８のそれぞれは、図１６に示す処理フローで購入制限するか否かを判定することで、購入処理部５２が購入処理を進めることを制限する。ここで、カート確認部５７と注文決定確認部５８の処理の大きな違いは、今回の支払金額を計算する処理の計算内容である。以下では購入制限部５３の処理として説明するものは、特に断りのない限り、カート確認部５７と注文決定確認部５８のそれぞれが行う処理であるとする。また、以下の処理は支払限度額が設定されている場合の処理であり、支払限度額が解除されている場合には、購入制限部５３は常に購入制限なしと判定する。

　購入制限部５３は、はじめに、注文内容に含まれる商品の数量と単価とを取得する（ステップＳ２０１）。次に、購入制限部５３は、ポイント等の情報を取得し、今回の支払金額を計算する（ステップＳ２０２）。より具体的には、カート確認部５７はポイントの残額や所有しているギフト金額の情報を取得し、注文決定確認部５８はポイント利用額やギフト利用額、また手数料を取得する。そして、カート確認部５７や注文決定確認部５８はそれぞれ取得した情報に基づいて今回の支払金額を計算する。

　今回の支払金額について説明する。前述のように、カート確認部５７が計算する今回の支払金額は支払金額の予測値であり、ユーザが購入を希望する商品ごとに単価に数量をかけた金額である。具体的には、カート確認部５７は、注文内容（カート）に含まれる商品の単価に数量をかけた金額を支払金額として計算する。なお、支払金額として注文内容（カート）に含まれる商品の単価に数量をかけた金額からポイント残額やギフト金額を引いた金額を計算してもよい。また、注文決定確認部５８が計算する今回の支払金額はユーザが決済方法や配送方法、ポイント利用額等を入力したことにより決まった金額であり、商品ごとにその単価と数量を掛けたものの合計に決済手数料や配送手数料などの手数料を足し、さらにポイント利用額やギフト利用額等の支払減少額を引いた金額である。

　次に、購入制限部５３は、集計期間内における過去の注文における支払金額合計を取得する（ステップＳ２０３）。支払合計額は、このユーザのユーザ情報から取得してもよいし、集計期間内に処理された注文内容を注文履歴格納部６３から取得し、その支払金額の総計を計算することで取得してもよい。次に、過去の支払金額合計と今回の支払金額とを足し、集計期間内の支払金額と今回の支払金額の合計を取得する（ステップＳ２０４）。そして、この合計が支払限度額以下であれば（ステップＳ２０５のＮ）、購入制限なしと判定しその結果を問い合わせ元に返す（ステップＳ２１１）。一方、この合計が支払限度額を超えた場合は（ステップＳ２０５のＹ）、ユーザ情報に例外ありと設定されているかを確認する（ステップＳ２０６）。例外無しと設定されている場合には（ステップＳ２０６のＮ）、購入制限ありと判定し、例外有りと設定されている場合には（ステップＳ２０６のＹ）、無駄遣いを防ぐという目的において認めてよいケースに当てはまるかを確認する。

　ステップＳ２０７では、購入制限部５３は、注文内容に含まれる商品のカテゴリを取得する。そして、購入制限部５３はこのカテゴリに対する購入制限情報を取得する（ステップＳ２０８）。図１７は、購入制限情報の一例を示す図である。購入制限情報は、商品のカテゴリと購入制限の対象有無とを関連づける情報である。なお、購入制限情報は、カテゴリの代わりに、商品名などの商品の他の属性と関連づけたものであってもよい。その場合、ステップＳ２０７やステップＳ２０８でカテゴリの代わりにその属性を用いて処理をすればよい。ここで、購入制限情報が、注文内容に含まれる商品の属性が購入制限有りと関連づけられている場合には、その商品が購入制限対象であることを示し、そうでない場合には、購入制限対象でないことを示す。購入制限対象は、一般的には贅沢品となる商品と関連づけられる。

　そして、購入制限情報がその商品が購入制限対象であることを示す場合には（ステップＳ２０９のＮ）、購入制限部５３は購入制限有りと判定し、その判定結果を問い合わせ元に返す（ステップＳ２１２）。そして、購入制限情報がその商品が購入制限対象でないことを示す場合には（ステップＳ２０９のＹ）、過去の購入制限対象の商品に対する支払金額について確認する。

　より具体的には、過去の購入制限対象の商品に対する支払金額は、注文履歴格納部６３に格納され、集計期間内に処理された注文内容のうち、購入制限対象となる商品に対する支払金額の合計である。購入制限部５３は、（過去の購入制限対象の商品に対する支払金額）／支払限度額が、ユーザ情報に格納された購入制限対象品割合上限以下である場合には（ステップＳ２１０のＹ）、購入制限なしと判定して、その判定結果を問い合わせ元に返す（ステップＳ２１１）。そして、ユーザ情報に格納された購入制限対象品割合上限を超える場合には、購入制限部５３は購入制限有りと判定し、その判定結果を問い合わせ元に返す（ステップＳ２１２）。なお、購入制限対象ではない商品に対する支払金額の合計を用いてこの判断をしてもよい。この場合には、ユーザ情報に非購入制限対象品の割合の下限の情報を格納し、その下限以上であれば購入制限無し、下限未満であれば購入制限有りとしてよい。

　このようにすることで、仮に支払限度額を超える場合でも、無駄遣いでない可能性が高いと思われる購入制限対象品でない商品の購入を許すことが可能となる。さらに過去に購入処理をした注文内容における購入制限対象品の購入金額の割合をみることで、これまでに多く無駄遣いをしてきた場合とそうでない場合とで、購入を許可するか否かの扱いを変えることも可能となる。

　購入制限部５３は、購入制限情報以外を用いて購入制限の有無を判定してもよい。例えば、注文内容に含まれる商品の単価を、類似商品の平均単価と比較して判定してもよい。類似商品は注文内容に含まれる商品の属性などにより関連づけられた商品であり、例えば同じ商品名である他の商品を類似商品としてもよい。より具体的には、ステップＳ２０７からＳ２１０の処理の代わりに、同じ商品名の平均単価を計算し、その平均単価より単価が高い商品は購入制限あり、単価が低い商品は購入制限なしとしてもよい。

　また、購入制限部５３は、集計期間における支払金額と今回の支払金額との合計のうち、支払限度額を超える金額（超過額）に基づいて購入制限の有無を判定してもよい。例えば、ステップＳ２０７からＳ２１０の処理の代わりに、その超過額が注文内容に含まれる手数料より小さいか判定し、小さい場合には購入制限なしとしてもよい。予め想定することが困難な手数料を除外することで、ユーザが混乱することを防ぐことが可能となる。

　他には、単価に対する超過額の割合の上限を予め決めておき、購入制限の有無を判定してもよい。ステップＳ２０７からＳ２１０の処理の代わりに、注文内容が複数の商品を含む場合には、その単価の最小値をとり、最小値に対する超過額の割合がその上限を超えない場合には購入制限無しとする。こうすると、例えば超過額の割合を５０％に設定しかつ支払限度額まで残り１万円の場合に、１万円の商品と１０００円の商品を購入するような場合には購入を認めず、５０００円と６０００円の商品を購入するような場合には購入を認めることができる。前者のように１０００円の商品をあきらめればほぼ支払限度額に近い金額まで購入可能なケースで購入することを防ぎつつ、後者のように片方をあきらめると支払限度額がより多く余ってしまうような場合は購入を許すことになり、ユーザの事情に応じた柔軟な支払限度額の管理が可能となる。

　また、購入制限部５３は、ユーザが商品を購入する時期が集計期間のどこにあるかによって購入制限の有無を判定してもよい。例えば、ステップＳ２０７からＳ２１０の処理の代わりに、購入する時期が集計期間の終わりから一定の期間内（例えば３日以内）の場合には、それまで節約していたから購入制限なしとし、それ以外の場合には節約の意思が認められないから購入制限ありとしてよい。こちらでもユーザの事情に応じて柔軟に購入を許可することが可能となる。

　また、ステップＳ２０６のタイミングで、例外ありでも過去の支払額が支払限度額を超える場合には購入制限ありと判定してもよい。過去の支払において支払限度額を超えた場合には、ユーザがそのことを認識している蓋然性が高いため、今回の商品が本当に必要であるならば、この商品を注文する前に支払限度額を修正する可能性が高いからである。

　１　仮想商店街サーバ、２　ユーザＰＣ、３　インターネット、１１　プロセッサ、１２　記憶部、１３　通信部、１４　入出力部、５１　支払限度額入力部、５２　購入処理部、５３　購入制限部、５４　商品選択部、５５　注文決定部、５６　注文実行部、５７カート確認部、５８　注文決定確認部、６１　ユーザ情報格納部、６２　商品情報格納部、６３　注文履歴格納部。

Claims

　ユーザが入力した所定の期間における支払限度額を記憶部に記憶させる支払限度額入力手段と、
　商品またはサービスの少なくとも一方からなる商材であって前記ユーザが購入する商材を含む今回の購入内容に従って購入処理を実行する購入手段と、
　前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、前記ユーザの今回および過去の少なくとも一方の購入内容に基づいて前記購入手段による今回の購入処理を制限するか否かを決定する制限手段と、
　を含むことを特徴とする購入管理装置。
　前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、今回前記ユーザが購入する商材の属性に基づいて今回の購入処理を制限するか否かを決定する、
　ことを特徴とする請求項１に記載の購入管理装置。
　前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、商材の属性と購入を制限する対象であるかを関連づける情報と、前記ユーザが購入を希望する商材の属性とに基づいて今回の購入処理を制限するか否かを決定する、
　ことを特徴とする請求項２に記載の購入管理装置。
　前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、複数の商材のそれぞれの単価を記憶する手段から取得された前記ユーザが購入する商材の単価に基づいて今回の購入処理を制限するか否かを決定する、
　ことを特徴とする請求項２に記載の購入管理装置。
　前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、前記ユーザが購入する商材の単価と当該商材に対し複数の商材のそれぞれと当該商材に関係する商材とを関連づける情報により関連づけられた商材の単価に基づく基準額とに基づいて今回の購入処理を制限するか否かを決定する、
　ことを特徴とする請求項４に記載の購入管理装置。
　前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、当該ユーザの過去かつ前記所定の期間における購入内容に含まれる商材の属性に基づいて今回の購入処理を制限するか否かを決定する、
　ことを特徴とする請求項１に記載の購入管理装置。
　前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、当該ユーザの過去かつ前記所定の期間における購入内容に含まれる商材のうち、商材の属性と購入を制限する対象であるかを関連づける情報が購入を制限する対象と関連づける属性を有する商材に対する支払金額の合計の、前記支払限度額に対する割合に基づいて、今回の購入処理を制限するか否かを決定する、
　ことを特徴とする請求項６に記載の購入管理装置。
　前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、当該ユーザの過去かつ前記所定の期間における購入内容に含まれる商材のうち、商材の属性と購入を制限する対象であるかを関連づける情報が購入を制限する対象と関連づけない属性を有する商材に対する支払金額の合計の、前記支払限度額に対する割合に基づいて、今回の購入処理を制限するか否かを決定する、
　ことを特徴とする請求項６に記載の購入管理装置。
　前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、前記合計が前記支払限度額を超える金額に基づいて今回の購入処理を制限するか否かを決定する、
　ことを特徴とする請求項１に記載の購入管理装置。
　前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超え、かつ、前記合計が前記支払限度額を超える金額の今回の購入内容に含まれる商材の単価の最小値に対する割合が所定の割合を超えない場合に、今回の購入処理を制限しないと決定する、
　ことを特徴とする請求項９に記載の購入管理装置。
　前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超え、かつ前記合計が前記支払限度額を超える金額が前記購入内容に含まれる手数料より小さい場合に、今回の購入処理を制限しないと決定する、
　ことを特徴とする請求項９に記載の購入管理装置。
　前記制限手段は、前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、前記ユーザが商材を購入する時間が前記所定の期間内のどこであるかに基づいて今回の購入処理を制限するか否かを決定する、
　ことを特徴とする請求項１に記載の購入管理装置。
　前記支払金額は、前記ユーザが購入する商材の単価に数量を掛けた額と、その購入における手数料との和から前記ユーザにより定まる支払減少額を引いた金額である、
　ことを特徴とする請求項１から１２に記載の購入管理装置。
　前記制限手段は、前記所定の期間における前記ユーザの支払金額の合計が前記支払限度額を超える場合に今回の購入処理を制限すると決定する、
　ことを特徴とする請求項１から１３に記載の購入管理装置。
　ユーザが入力した所定の期間における支払限度額を記憶部に記憶させるステップと、
　商品またはサービスの少なくとも一方からなる商材であって前記ユーザが購入する商材を含む今回の購入内容に従って購入処理を実行するステップと、
　前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、前記ユーザの今回および過去の少なくとも一方の購入内容に基づいて今回の前記購入処理を制限するか否かを決定するステップと、
　を含むことを特徴とする購入管理方法。
　ユーザが入力した所定の期間における支払限度額を記憶部に記憶させ、
　商品またはサービスの少なくとも一方からなる商材であって前記ユーザが購入する商材を含む今回の購入内容に従って購入処理を実行し、
　前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、前記ユーザの今回および過去の少なくとも一方の購入内容に基づいて今回の前記購入処理を制限するか否かを決定する、
　処理をコンピュータに実行させるプログラム。
　ユーザが入力した所定の期間における支払限度額を記憶部に記憶させ、
　商品またはサービスの少なくとも一方からなる商材であって前記ユーザが購入する商材を含む今回の購入内容に従って購入処理を実行し、
　前記所定の期間における前記ユーザの支払金額と今回の購入内容における支払金額との合計が前記支払限度額を超える場合に、前記ユーザの今回および過去の少なくとも一方の購入内容に基づいて今回の前記購入処理を制限するか否かを決定する、
　処理をコンピュータに実行させるプログラムを格納するコンピュータ読み取り可能な情報記憶媒体。