JP5785350B1 - 情報処理装置、情報処理方法、プログラム、記憶媒体 - Google Patents

Abstract

予定購入について使用するポイント数の上限である使用上限ポイント数を操作に基づき設定するポイント数設定部、通常ポイントと期間限定ポイントとを管理するポイント管理情報に基づいて予定購入に係る決済がポイント数設定部により設定された使用上限ポイント数に応じた割引額で行われるように制御する割引決済制御部、使用上限ポイント数が設定された予定購入について当該予定購入で使用される予定の期間限定ポイントの数である使用予定期間限定ポイント数をポイント管理情報と使用上限ポイント数とに基づいて求め、当該予定購入が行われる前にユーザに通知する期間限定ポイント数通知部、シリーズ購入における予定購入が行われたことに応じて、当該予定購入の時点でのユーザの保有ポイント数を取得し、取得した保有ポイント数と使用上限ポイント数との差の発生態様に基づき、使用上限ポイント数の変更をユーザに提言するための通知を行う変更提言通知部を備える。

Description

本発明は、例えばネットショッピングなどの電子商取引に用いられる情報処理装置とその情報処理方法、情報処理装置を実現するプログラム、及びプログラムを記憶した記憶媒体に関するものであり、特には、購入の申し込みタイミングから時間差を有して行われる購入である予定購入について、購入時に使用可能なポイントに係る処理を行うための技術分野に関する。

特開２００８−０２６９３５号公報

電子商取引の一形態として、いわゆるネットショッピングのようなインターネット等の通信ネットワークを介した商品又はサービスの購入が一般的に行われている。
ネットショッピングにおいては、例えば商品又はサービスの購入額に応じたポイントが付与され、当該ポイントを商品又はサービスの購入に使用できる場合がある。すなわち、ポイント数に応じた額の割引を受けることができる（例えば、上記特許文献１を参照）。

一方で、ネットショッピングにおける商品又はサービスの購入形態としては、複数回の商品又はサービスの購入が１セットとされたシリーズ購入や、発売前の商品を予約して購入する予約購入の形態などが存在する。シリーズ購入としては、例えば、トイレットペーパーや毛髪洗浄剤（いわゆるシャンプー）等の日常消耗品としての商品の購入が１度の申し込みに応じて定められた周期で複数回行われるものを挙げることができる。
また、予約購入については、発売前の書籍や音楽ＣＤ等を予約して購入する例を挙げることができる。

ここで、ネットショッピングにおいては、これらシリーズ購入における各購入や予約購入など、申し込みタイミングから時間差を有して行われる購入（以下「予定購入」と表記）についても、ポイントの使用を可能とすることがサービス向上等の面で望ましい。

しかしながら、通常、購入申し込みタイミングから予定購入が実行されるまでの時間差は比較的大きく、その間に保有ポイント数の変動が生じる可能性が高い。このため、仮に購入の申し込み時にユーザに使用ポイント数を入力させたとしても、予定購入の実行時には「入力ポイント数＞保有ポイント数」となってしまう虞があり、その場合はユーザの意図した割引決済ができなくなってしまう。
この対策として、購入申し込みから予定購入が行われるまでの間に保有ポイント数に変動があった場合に、ユーザに使用ポイント数の変更入力を求めることも考えられるが、それではユーザに負担を強いることになる。

そこで、本発明は上記した問題点を克服し、予定購入についてユーザの意図したポイント数による割引が行われるようにしつつ、ユーザの負担軽減を図ることを目的とする。

本発明に係る情報処理装置は、商品又はサービスの購入時に使用可能なポイントとして、使用期限が定められた期間限定ポイントと使用期限の無い又は前記期間限定ポイントよりも長期の使用期限が定められた通常ポイントとに分けて管理するポイント管理情報にアクセス可能とされた情報処理装置であって、購入の申し込みタイミングから時間差を有して行われる購入である予定購入について、使用するポイント数の上限である使用上限ポイント数を操作に基づき設定するポイント数設定部と、前記ポイント管理情報に基づいて、前記予定購入に係る決済が前記ポイント数設定部により設定された前記使用上限ポイント数に応じた割引額で行われるように制御する割引決済制御部と、前記使用上限ポイント数が設定された前記予定購入について、当該予定購入で使用される予定の前記期間限定ポイントの数である使用予定期間限定ポイント数、又は当該予定購入では使用されない予定の前記期間限定ポイントの数である非使用予定期間限定ポイント数を前記ポイント管理情報と前記使用上限ポイント数とに基づいて求め、当該予定購入が行われる前にユーザに通知する期間限定ポイント数通知部と、前記予定購入として、複数回の商品又はサービスの購入が１セットとされたシリーズ購入における予定購入が行われたことに応じて、当該予定購入の時点でのユーザの保有ポイント数を取得し、取得した保有ポイント数と前記使用上限ポイント数との差の発生態様に基づき、前記使用上限ポイント数の変更をユーザに提言するための通知を行う変更提言通知部とを備えるものである。

使用上限ポイント数に基づくポイント使用としたことで、予定購入でのポイント使用が使用上限ポイント数までを範囲内として行われることが予めユーザにより把握される。また、ユーザによる使用ポイント数の設定は少なくとも申し込み時のみで済む。
また、使用予定期間限定ポイント数又は非使用予定期間限定ポイント数の通知が行われることで、使用又は非使用予定の期間限定ポイント数を計算するという比較的重い負担をユーザに強いることがなく、さらに、変更提言通知が行われることで、ユーザにポイント使用状況の監視負担を強いることなくユーザのポイント獲得・使用状況に応じた適切な使用上限ポイント数への変更が可能とされる。

上記した本発明に係る情報処理装置においては、前記期間限定ポイント数通知部は、対象とする前記予定購入よりも前に実行予定の他の予定購入が存在するか否かを判定し、当該他の予定購入が存在する場合には、当該他の予定購入での前記使用予定期間限定ポイント数に基づき、対象とする前記予定購入での前記使用予定期間限定ポイント数、又は前記非使用予定期間限定ポイント数を求めることが望ましい。
これにより、使用又は非使用予定の期間限定ポイント数の通知にあたり、複数の予定購入がオーバーラップして存在することが許容される。

上記した本発明に係る情報処理装置においては、前記期間限定ポイント数通知部は、対象とする前記予定購入において使用可能な期間限定ポイント数である購入時使用可能期間限定ポイント数が当該予定購入の対象商品又はサービスの価格以上であり、且つ当該予定購入に対して設定された前記使用上限ポイント数が前記商品又はサービスの価格以上であるか否かを判定し、肯定結果が得られた場合は前記商品又はサービスの価格を前記使用予定期間限定ポイント数とし、当該予定購入に対して設定された前記使用上限ポイント数が前記商品又はサービスの価格未満であり、且つ前記購入時使用可能期間限定ポイント数が当該予定購入に対して設定された前記使用上限ポイント数以上であるか否かを判定し、肯定結果が得られた場合は当該予定購入に対して設定された前記使用上限ポイント数を前記使用予定期間限定ポイント数とし、双方の前記判定で否定結果が得られた場合は、前記購入時使用可能期間限定ポイント数を前記使用予定期間限定ポイント数とすることが望ましい。
これにより、使用可能期間限定ポイント数を求めるのに要する場合分けの数が最小となる。

また、上記した本発明に係る情報処理装置においては、前記変更提言通知部は、前記シリーズ購入における予定購入が行われるごとに前記保有ポイント数と前記使用上限ポイント数とに差が生じているか否かを判定し、当該差の発生頻度に基づいて前記通知を行うことが望ましい。
これにより、購入ごとに取得される保有ポイント数と使用上限ポイント数との差の発生頻度に応じて適切に変更提言を行うことが可能とされる。

上記した本発明に係る情報処理装置においては、前記変更提言通知部は、前記取得した保有ポイント数と前記使用上限ポイント数との差の大きさに基づいて前記通知を行うことが望ましい。
これにより、購入ごとに取得される保有ポイント数と使用上限ポイント数との差の大きさに応じて適切に変更提言を行うことが可能とされる。

また、本発明に係る情報処理方法は、商品又はサービスの購入時に使用可能なポイントとして、使用期限が定められた期間限定ポイントと使用期限の無い又は前記期間限定ポイントよりも長期の使用期限が定められた通常ポイントとに分けて管理するポイント管理情報にアクセス可能とされた情報処理装置における情報処理方法であって、購入の申し込みタイミングから時間差を有して行われる購入である予定購入について、使用するポイント数の上限である使用上限ポイント数を操作に基づき設定するポイント数設定ステップと、前記ポイント管理情報に基づいて、前記予定購入に係る決済が前記ポイント数設定ステップにより設定された前記使用上限ポイント数に応じた割引額で行われるように制御する割引決済制御ステップと、前記使用上限ポイント数が設定された前記予定購入について、当該予定購入で使用される予定の前記期間限定ポイントの数である使用予定期間限定ポイント数、又は当該予定購入では使用されない予定の前記期間限定ポイントの数である非使用予定期間限定ポイント数を前記ポイント管理情報と前記使用上限ポイント数とに基づいて求め、当該予定購入が行われる前にユーザに通知する期間限定ポイント数通知ステップと、前記予定購入として、複数回の商品又はサービスの購入が１セットとされたシリーズ購入における予定購入が行われたことに応じて、当該予定購入の時点でのユーザの保有ポイント数を取得し、取得した保有ポイント数と前記使用上限ポイント数との差の発生態様に基づき、前記使用上限ポイント数の変更をユーザに提言するための通知を行う変更提言通知ステップと、を実行する情報処理方法である。
このような情報処理方法によっても、上記した本発明に係る情報処理装置と同様の作用が得られる。

さらに、本発明に係るプログラムは、上記情報処理方法として実行する処理を情報処理装置に実行させるプログラムである。
さらにまた、本発明に係る記憶媒体は、上記プログラムを記憶したプログラムである。これらのプログラムや記憶媒体により上記の情報処理装置を実現する。

本発明によれば、予定購入についてユーザの意図したポイント数による割引が行われるようにしつつ、ユーザの負担軽減を図ることができる。

実施の形態のネットワークシステムの例を示した図である。 ユーザデータベースの格納情報を例示した図である。 ポイントデータベースの格納情報を例示した図である。 実施の形態のネットワークシステムを構成するコンピュータ装置のハードウェア構成を示したブロック図である。 実施の形態に係る機能をブロック化して示した機能ブロック図である。 シリーズ購入（定期購入）の対象商品についての商品ページの例を示した図である。 商品お届けのサイクル設定ページの例を示し図である。 支払い方法等選択ページの例を示した図である。 購入申込受付処理部に対応した処理を示したフローチャートである。 期間限定ポイント数通知処理部に対応した処理を示したフローチャートである。 各他の予定購入での使用予定期間限定ポイント数の総和の計算処理を示したフローチャートである。 対象とする予定購入での使用予定期間限定ポイント数を求めるための処理を示したフローチャートである。 割引決済制御処理部に対応した処理を示したフローチャートである。 変更提言通知処理部に対応した処理を示したフローチャートである。

以下、実施の形態を次の順序で説明する。
＜１．ネットワークシステムの概要＞
＜２．コンピュータ装置のハードウェア構成＞
＜３．予定購入に係るポイント関連処理＞
＜４．処理手順＞
＜５．実施の形態のまとめ＞
＜６．プログラム及び記憶媒体＞
＜７．変形例＞

＜１．ネットワークシステムの概要＞

図１に、本実施の形態で前提とするネットワークシステム１の例を示す。ネットワークシステム１は、ＥＣ（ＥＣ：electronic commerce（電子商取引））システムとして機能する。
ネットワークシステム１は、例えばインターネットとしてのネットワーク２を介して、ショッピングサイト管理システム３、複数のユーザ端末４，４…、複数の店舗端末５，５…、及びカード会社サーバ６が互いに通信可能に構成されている。

ユーザ端末４は、ウェブブラウザを備えたコンピュータ装置である。ユーザ端末４としては、例えば高機能携帯電話機（スマートフォン）や携帯電話機、携帯情報端末（ＰＤＡ）、携帯型又は据置型のパーソナルコンピュータ（ＰＣ）などが挙げられるが、ユーザ端末４の種類はこれらに限定されない。
ユーザ端末４は、ＨＴＴＰ（Hypertext Transfer Protocol）リクエストをショッピングサイト運営システム３におけるショッピングサーバ３ａやカード会社システム７におけるガード会社サーバ７ａ等に送信することでウェブページや所定の処理を要求する。またユーザ端末４は、ＨＴＴＰリクエストに応じて送られてきたウェブページを受信してウェブブラウザ上に表示する。これにより、ユーザは所望のウェブページを閲覧したり操作したりすることができる。

ショッピングサイト運営システム３は、それぞれコンピュータ装置で構成されたショッピングサーバ３ａ、商品ＤＢ（データベース）３ｂ、ユーザＤＢ３ｃ、及びポイントＤＢ３ｄを備えている。これらの各装置は、例えばＬＡＮ（Local Area Network）等のネットワークを介して互いに通信可能とされている。

ショッピングサーバ３ａは、ユーザ端末４から送られてきたＨＴＴＰリクエストに基づいて様々な処理を行う。例えば、各種ウェブページ（例えば商品ウェブページ、買い物かごウェブページ、注文ウェブページなど）の生成及び送信や、ユーザによる注文確定操作に応じた購入処理等を実行する。

ネットワークシステム１では、ショッピングサーバ３ａにより仮想商店街のウェブサイト（ＥＣサイト：ショッピングサイト）がユーザ（ユーザ端末４のユーザ）に提供される。ＥＣサイト内には複数の店舗（仮想商店街の加盟店）が存在する。各店舗のスタッフが自店舗の商品を店舗端末５としてのコンピュータ装置を介して登録することで、様々な店舗の様々な商品がＥＣサイト上にアップロードされる。ユーザはユーザ端末４によりＥＣサイトにアクセスして所望の商品を購入することができる。

なお、本例では、ネットワークシステム１における商取引の対象が商品である場合を例示するが、当該商取引の対象はサービスであってもよい。

ショッピングサイト運営システム３において、商品ＤＢ３ｂには、店舗端末５を介して登録された商品に係る情報が記憶されている。具体的には、商品を識別するための識別子である商品ＩＤに対応づけられて、商品名、商品のジャンル、商品の画像、スペック、商品紹介の要約文等の商品情報や、広告情報等が記憶されている。また、商品ＤＢ３ｂには、ＨＴＭＬ（HyperText Markup Language）、ＸＭＬ（Extensible Markup Language）等のマークアップ言語等により記述された商品ウェブページのファイル等も記憶されている。
このような商品ＤＢ３ｂにより、例えば入力キーワード等に基づいた商品検索等を行うことが可能とされている。

ここで、ユーザは、ＥＣサイトを利用するにあたり、ショッピングサイト管理システム３に会員登録を行うことができる。会員登録の際にユーザは、ユーザＩＤ（ユーザ識別情報）、パスワード、氏名、メールアドレス、商品の送付先情報（住所情報）、クレジットカード番号等の必要情報を登録する。ユーザは、登録したユーザＩＤによりＥＣサイトにログインすることで、ＥＣサイトでの商品の購入の際に必要情報を再度入力する手間が省かれる。

ユーザＤＢ３ｃには、上記のように会員としてのユーザにより登録されたユーザ情報が記憶されている。
図２は、ユーザＤＢ３ｃの格納情報を例示した図である。
図示するようにユーザＤＢ３ｃにおいては、ユーザＩＤごとに、パスワード、氏名、メールアドレス、住所の各情報、及びクレジットカード情報が紐付けられて（対応づけられて）記憶されている。クレジットカード情報としては、カード番号、名義人（カード名義人の氏名）、及び有効期限の各情報が記憶されている。

また、ＥＣサイトにおいては、商品を購入する等、ユーザが所定の行動を行うことに応じて、当該ユーザにポイントの付与が行われる。ここで言うポイントとは、購入時に使用可能なポイントであり、ユーザは使用ポイント数に応じて購入代金の割引を受けることができる。

ポイントには、通常ポイントと期間限定ポイントの二種が存在する。期間限定ポイントとは、使用期限が定められたポイントであり、通常ポイントとは、使用期限の無い又は期間限定ポイントよりも長期の使用期限が定められたポイントである。本例の場合、通常ポイントは使用期限の定められていないポイントとされているとする。

ショッピングサイト運営システム３においては、これら通常ポイントや期間限定ポイントによるユーザごとの保有ポイントの情報がポイントＤＢ３ｄによって管理されている。
図３は、ポイントＤＢ３ｄの格納情報を例示した図であり、図３Ａはユーザごとのポイントの獲得履歴情報の例、図３Ｂはユーザごとのポイントの使用履歴情報の例をそれぞれ示している。
図３Ａに示す獲得履歴情報においては、ユーザＩＤごとに、当該ユーザＩＤで特定されるユーザが獲得したポイントに係る各種の情報としてそれぞれポイントの獲得日、有効化日、有効期限、及び獲得したポイント数が対応付けられている。なお、有効化日は、獲得したポイントが使用可能となる予定日を表すものである。
このような獲得履歴情報によれば、有効期限が設定されているか否かにより、獲得ポイントが通常ポイント、期間限定ポイントの何れであるかが区別可能とされる。

また、図３Ｂに示す使用履歴情報においては、ユーザＩＤごとに、当該ユーザＩＤで特定されるユーザが使用したポイントに係る各種の情報としてそれぞれポイントの使用日と使用ポイント数の情報が対応付けられている。

ショッピングサーバ３ａは、ポイントＤＢ３ｄに格納されたこれら獲得履歴情報と使用履歴情報とに基づいて、ユーザごとの保有ポイント数の計算を行うことが可能とされている。

本例では、ポイントの獲得、使用に応じて、ショッピングサーバ３ａがポイントＤＢ３ｄにおける獲得履歴情報、使用履歴情報の更新を行う。
この際、ポイントの使用に関しては、ショッピングサーバ３ａは、通常ポイントよりも期間限定ポイントの方が優先的に使用されるように処理を行う。具体的には、ユーザにより設定されたポイント数を購入処理において使用する際、その時点で有効な保有ポイントに通常ポイントと期間限定ポイントとが混在している場合には、期間限定ポイントの方を優先的に使用する。この際、期間限定ポイントとして有効期限の異なるポイントが混在している場合には、有効期限の早い（つまりより早く失効する）方のポイントを優先的に使用する。

ここで、本例におけるショッピングサーバ３ａは、ユーザからの申し込みに応じた予定購入のための処理を行う。予定購入とは、購入の申し込みタイミングから時間差を有して行われる購入である。
本例で行われる予定購入は、複数回の商品購入が１セットとされたシリーズ購入における各購入、又は発売前の商品についてユーザからの購入予約を受けて行われる予約購入の何れかとされている。前述もしたが、シリーズ購入としては、例えば、トイレットペーパーや毛髪洗浄剤（いわゆるシャンプー）等の日常消耗品としての商品の購入が１度の申し込みに応じて定められた周期で複数回行われるもの（いわゆる定期購入）等を挙げることができる。また、予約購入の対象商品としては、例えば書籍や音楽ＣＤ等が挙げらる。

ショッピングサーバ３ａは、或るユーザによりシリーズ購入の申し込みがあった場合は、当該申し込みに応じて定められた周期で対象商品についての購入処理を実行する。また、或るユーザにより予約購入の申し込みがあった場合には、対象商品の入荷等に応じた所定のタイミングで当該商品についての購入処理を実行する。
購入処理において、ショッピングサーバ３ａは、対象商品の価格やユーザにより設定された使用ポイント数の情報等に基づいて対象商品の購入価格（決済金額）を計算すると共に、当該購入価格による決済（カード決済）が行われるように制御する処理を行う。具体的に、本例においては、計算した購入価格による注文情報（購入価格や購入ユーザのクレジットカード番号などの情報を含む）を対象商品の販売元店舗の店舗端末５に対して送信する。
注文情報を受信した店舗端末５は、当該注文情報をカード会社サーバ６に送信して決済を要求する。

なお、ショッピングサーバ３ａは、上記のようなシリーズ購入や予約購入に関して、ユーザからの使用ポイント数の設定受け付けや使用される予定の期間限定ポイント数の通知、及び設定された使用ポイント数の変更提言通知に係る処理も行うが、これら本実施の形態としての処理については後に改めて説明する。

カード会社サーバ６は、カード情報の管理、及びカード番号を指定した与信照会や売上請求等に対する処理を行う。
具体的に、カード会社サーバ６は、店舗端末５から上記した注文情報を受信すると、当該注文情報に含まれるカード番号に基づき与信照会を行い、与信ＯＫであれば、与信承認番号を含む与信承認通知を店舗端末５に送信すると共に、クレジットカードのカード番号に係る売り上げの速報情報（利用日、利用金額等）をユーザのメールアドレスに宛てて通知する。

店舗端末５は、所定の売り上げ請求タイミングで、カード会社サーバ７ａにクレジットカードのカード番号と与信承認番号に基づく売り上げ請求を送信する。
カード会社サーバ７ａは、当該売り上げ請求に基づき、該当するカード番号に対して該当する与信承認番号に紐付く決済金額を売り上げとして登録する。このような売り上げ登録が行われることで、その後の所定のタイミングで、当該カード番号に紐付く口座より決済金額の引き落とし処理が実行される。

なお、図１において、ネットワーク２の構成は多様な例が想定される。例えば、インターネットを始めとして、イントラネット、エキストラネット、ＬＡＮ（Local Area Network）、ＣＡＴＶ（Community Antenna TeleVision）通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網等が想定される。
またネットワーク２の全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４、ＵＳＢ（Universal Serial Bus）、電力線搬送、電話線等の有線でも、ＩｒＤＡ（Infrared Data Association）のような赤外線、ブルートゥース（登録商標）、８０２．１１無線、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。

＜２．コンピュータ装置のハードウェア構成＞

図４に、図１で示したショッピングサーバ３ａをはじめとした各装置（商品ＤＢ３ｂ、ユーザＤＢ３ｃ、ポイントＤＢ３ｄ、ユーザ端末４、店舗端末５、カード会社サーバ６）を構成するコンピュータ装置のハードウェア構成を示す。
図４において、コンピュータ装置のＣＰＵ（Central Processing Unit）１０１は、ＲＯＭ( Read Only Memory)１０２に記憶されているプログラム、または記憶部１０８からＲＡＭ( Random Access Memory )１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
ＣＰＵ１０１、ＲＯＭ１０２、及びＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インターフェース１０５も接続されている。
入出力インターフェース１０５には、キーボード、マウス、タッチパネルなどよりなる入力装置１０６、ＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ（表示装置）、並びにスピーカなどよりなる出力装置１０７、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ装置などより構成される記憶部１０８、外部装置との間で相互通信を行うための通信部１０９が接続されている。
入出力インターフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。

このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われたり、リムーバブルメディア１１１を介したデータやプログラムの受け渡しが可能である。
ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、特にショッピングサーバ３ａとしてのコンピュータ装置においては以降で説明する情報処理や通信が実行される。

＜３．予定購入に係るポイント関連処理＞

ここで、上述したシリーズ購入における各購入や予約購入など、申し込みタイミングから時間差を有して行われる予定購入に関しては、申し込みタイミングから予定購入が実行されるまでの時間差が比較的大きく、その間に保有ポイント数の変動が生じる可能性が高い。このため、仮に購入の申し込み時にユーザに使用ポイント数を入力させたとしても、予定購入の実行時には「入力ポイント数＞保有ポイント数」となってしまう虞があり、その場合はユーザの意図した割引決済ができなくなってしまう。

そこで、本実施の形態では、予定購入については、ユーザに使用するポイント数そのものを設定させるのではなく、使用するポイント数の上限である「使用上限ポイント数」を設定させる。

図５は、ショッピングサーバ３ａのＣＰＵ１０１が実現する機能のうち、このような使用上限ポイント数の設定のための処理を含んだ予定購入に係るポイント関連処理の機能をブロック化して示した機能ブロック図である。
図５に示すように、ショッピングサーバ３ａのＣＰＵ１０１には、機能ブロックとして、購入申込受付処理部Ｆ１、割引決済制御処理部Ｆ２、期間限定ポイント数通知処理部Ｆ３、及び変更提言通知処理部Ｆ４が備えられている。

購入申込受付処理部Ｆ１は、ユーザからの予定購入に係る購入申し込みを受け付けるための処理を行う。具体的には、シリーズ購入や予約購入の購入申し込みを受け付けるための処理である。

図６〜図８を参照して、シリーズ購入の申し込みを例に、購入申し込みの完了までの流れを説明する。
図６は、シリーズ購入（定期購入）の対象商品についての商品ページの例を示している。
当該商品ページには、商品画像ｐ１や商品名ｐ２、商品の価格ｐ３の情報が提示されていると共に、例えば「定期購入する」などの文字情報が表記されたシリーズ購入の購入申し込みを行うための申し込みボタンｐ４が提示されている。
なお、ここでの説明では、シリーズ購入における購入回数は予め定められた回数（例えば５回など）で固定とされ、ユーザが任意の購入回数を選択できない場合を例示しているが、もちろん、任意の購入回数を選択可能としてもよい。

図７は、購入申し込みボタンｐ４を選択する操作（マウスクリック又はタッチ操作）が行われたことに応じて提示される商品お届けのサイクル設定ページの例を示している。
当該設定ページには、商品お届けサイクルを選択するためのサイクル選択領域ａ１と、購入申し込みの段階を次段階へ進めるための次へボタンｐ７とが提示されている。本例の場合、サイクル選択領域ａ１には１回目の商品お届け日としてのサイクル起点日を指定するための起点日指定ボックスｐ５と、起点日以降の各商品お届け日の間隔（本例では日数単位）を指定するための間隔指定ボックスｐ６とが設けられている。
ユーザにより起点日指定ボックスｐ５を選択する操作が行われると、起点日指定ボックスｐ５にはプルダウンによりサイクル起点日の候補日が一覧表示され、ユーザは当該一覧から所望の候補日をサイクル起点日として指定できる。また、間隔指定ボックスｐ６も同様に、ユーザによる選択操作に応じてプルダウンにより間隔の候補が一覧表示（本例では５日〜９０日の範囲内）され、ユーザは当該一覧から所望の間隔を指定できる。これらの指定により、当該シリーズ購入における各購入のサイクル（本例では５回分の各購入のサイクル）が選択されたことになる。
ユーザは、サイクル選択領域ａ１において所望のサイクルを選択した上で、次へボタンｐ７を選択する操作を行う。

図８は、次へボタンｐ７を選択する操作が行われたことに応じて提示される支払い方法等選択ページの例を示している。
支払い方法等選択ページには、例えばクレジットカード払い、銀行振込、代金引換のうちから支払い方法を選択するための支払い方法選択領域ａ２と、配送方法の選択を行うための配送方法選択領域ａ３と、使用上限ポイント数を指定するための使用上限ポイント数指定領域ａ４と、購入申し込みの段階を次段階へ進めるための次へボタンｐ９とが提示されている。

ユーザは、支払い方法選択領域ａ２、配送方法選択領域ａ３においてそれぞれ所望の支払い方法、配送方法を選択すると共に、使用上限ポイント数指定領域ａ４において所望の使用上限ポイント数を指定する。
使用上限ポイント数指定領域ａ４には、ポイント数の入力ボックスｐ８が設けられており、ユーザは当該入力ボックスｐ８に任意の数値を入力することで使用上限ポイント数を指定することができる。
ユーザは、支払い方法、配送方法、使用上限ポイント数の指定を行った上で、次へボタンｐ９を選択する操作を行う。

図示は省略したが、次へボタンｐ９を選択する操作が行われたことに応じては、申し込み内容の確認ページが提示される。当該確認ページには、申し込み内容を確定するための確定ボタンが提示され、ユーザは当該確定ボタンを選択する操作を行うことで当該シリーズ購入についての申し込みを確定させることができる。
このように申し込みが確定されたことに伴い、ユーザにより選択、指定された商品お届けサイクルや支払い方法、配送方法、使用上限ポイント数の設定が完了する。

説明を図５に戻す。
購入申込受付処理部Ｆ１は、図６〜図８に示した各ウェブページに対するユーザ操作に基づき、商品お届けサイクルや支払い方法、配送方法、使用上限ポイント数の設定を行う。

なお、上記ではシリーズ購入を例に説明を行ったが、書籍や音楽ＣＤ等の予約購入の申し込み時にも、同様に使用上限ポイント数の設定が行われる。具体的に、予約購入の申し込み時においても、同様に支払方法選択画面において使用上限ポイント数指定領域ａ４が提示され、該使用上限ポイント数指定領域ａ４に設けられた入力ボックスｐ８への入力数値に基づいて使用上限ポイント数の設定が行われる。

続いて、割引決済制御処理部Ｆ２は、前述のように通常ポイントと期間限定ポイントとが管理されたポイントＤＢ３ｄにおける格納情報（ポイント管理情報）に基づいて、予定購入に係る決済が、上記した購入申込受付処理部Ｆ１により設定された使用上限ポイント数に応じた割引額で行われるように制御を行う。
すなわち、前述した獲得履歴情報と使用履歴情報とから計算されるユーザの保有ポイント数に基づき、シリーズ購入における各購入或いは予約購入についての決済が、設定された使用上限ポイント数に応じた割引額で行われるように制御を行う。
この際、「保有ポイント数」≧「使用上限ポイント数」であれば、割引決済制御処理部Ｆ２は、購入価格から使用上限ポイント数を減じた額による決済が行われるように制御を行う（本例では前述のように注文情報を該当する店舗端末５に送信する）。
一方、「保有ポイント数」＜「使用上限ポイント数」であれば、割引決済制御処理部Ｆ２は、購入価格から保有ポイント数を減じた額による決済が行われるように制御を行う。
なお、保有ポイントの使用にあたっては、前述した通り、通常ポイントよりも期間限定ポイントの方を優先的に使用する。また、期間限定ポイントの使用にあたっては、有効期限の早い方のポイントを優先的に使用する。

期間限定ポイント数通知処理部Ｆ３は、使用上限ポイント数が設定された予定購入について、当該予定購入で使用される予定の使用予定期間限定ポイント数をポイントＤＢ３ｄにおける格納情報と設定された使用上限ポイント数とに基づいて求め、当該予定購入が行われる前にユーザに通知する。

ここで、期間限定ポイントは比較的短期の有効期限が設定されているため、失効させずに効率的に使用するためには、逐次獲得される期間限定ポイントについて継続的な期限管理を行うことを要し、ユーザの負担が比較的大きい。
また、期限が迫った期間限定ポイントについては、これを無駄にしまいとの意図から焦って使用する（購入商品を半ば無理に探し出して使用する）ケースも見受けられる。

そこで、本実施の形態では、期間限定ポイント数通知処理部Ｆ３により、予定購入における使用予定期間限定ポイント数を求め、ユーザに対して事前通知する。これにより、ユーザの期間限定ポイントについての期限管理負担の緩和が図られ、また当該予定購入で使用される期間限定ポイントがある場合においては、ポイントを焦って使用する必要が無いことをユーザに事前に把握させることができる。
使用予定期間限定ポイント数の通知は、例えば、ユーザの登録メールアドレス宛に電子メールを送信することで行う。

ここで、使用予定期間限定ポイント数は、対象とする予定購入の実行時点で使用可能な期間限定ポイント数（以下「購入時使用可能期間限定ポイント数」と表記）と、購入対象の商品価格と、設定された使用上限ポイント数とに基づいて求めることができる。
これら購入時使用可能期間限定ポイント数、商品価格、及び使用上限ポイント数に基づき使用予定期間限定ポイント数を求める手法としては、例えば、以下の二つを挙げることができる。

一つ目の手法は、「使用上限ポイント数≧商品価格」であるか否かの場合分けを基準に行う例である。具体的には、
●使用上限ポイント数≧商品価格のとき
１）購入時使用可能期間限定ポイント数≧商品価格であれば
→使用予定期間限定ポイント数＝商品価格とする。
２）購入時使用可能期間限定ポイント数＜商品価格であれば
→使用予定期間限定ポイント数＝購入時使用可能期間限定ポイント数とする。
●使用上限ポイント数＜商品価格のとき
３）購入時使用可能期間限定ポイント数≧使用上限ポイント数であれば
→使用予定期間限定ポイント数＝使用上限ポイント数とする。
４）購入時使用可能期間限定ポイント数＜使用上限ポイント数であれば
→使用予定期間限定ポイント数＝購入時使用可能期間限定ポイント数とする。
これにより、対象とする予定購入での使用予定期間限定ポイント数を求めることができる。

二つ目の手法は、使用予定期間限定ポイント数が採り得る値を基準とした手法である。
使用予定期間限定ポイント数として採り得る値は、商品価格、使用上限ポイント数、購入時使用可能期間限定ポイント数の何れかである。
使用予定期間限定ポイント数＝商品価格となるのは、購入時使用可能期間限定ポイント数≧商品価格、且つ使用上限ポイント数≧商品価格の場合（条件ｉ）である。
また、使用予定期間限定ポイント数＝使用上限ポイント数となるのは、使用上限ポイント数＜商品価格、且つ購入時使用可能期間限定ポイント数≧使用上限ポイント数の場合（条件ii）である。
さらに、使用予定期間限定ポイント数＝購入時使用可能期間限定ポイント数となるのは、購入時使用可能期間限定ポイント数＜商品価格、且つ購入時使用可能期間限定ポイント数＜使用上限ポイント数の場合であり、上記の条件ｉ、条件iiの何れの場合にも該当しないときである。
よって、上記の条件ｉ又は条件iiの場合に該当するか否かの判定を行って、条件ｉの場合に該当すれば使用予定期間限定ポイント数＝商品価格とし、条件iiの場合に該当すれば使用予定期間限定ポイント数＝使用上限ポイント数とし、条件ｉ及び条件iiの何れの場合にも該当しなければ使用予定期間限定ポイント数＝購入時使用可能期間限定ポイント数とする。

上記二つ目の手法は、使用可能期間限定ポイント数を求めるのに要する場合分けの数が一つ目の手法よりも少なく、最小とすることができる。従って、使用可能期間限定ポイント数を求めるための場合分けに要する処理負担の軽減を図ることができる。
本例においては、当該二つ目の手法を採用する。

ここで、本例においては、或る予定購入について使用予定期間限定ポイント数を求めるにあたっては、当該使用予定期間限定ポイント数を求める処理の実行時点から当該予定購入の実行予定日までの間に他の予定購入が存在し得ることも考慮する。すなわち、期間限定ポイント数通知処理部Ｆ３は、対象とする予定購入での使用予定期間限定ポイント数を求めるにあたり、当該予定購入よりも前に実行予定の他の予定購入が存在するか否かを判定し、当該他の予定購入が存在する場合には、当該他の予定購入についての使用予定期間限定ポイント数に基づき、対象とする予定購入での「購入時使用可能期間限定ポイント数」を求め、該「購入時使用可能期間限定ポイント数」と商品価格と使用上限ポイント数とに基づいて上記の手法により使用予定期間限定ポイント数を求める。
このとき、対象とする予定購入での「購入時使用可能期間限定ポイント数」は、現時点（処理時点）で保有されている期間限定ポイント数のうち当該予定購入の実行予定日より後に期限を迎える期間限定ポイント数から、他の予定購入での使用予定期間限定ポイント数を減じた値として算出する。

なお、このような他の予定購入での使用予定期間限定ポイント数を考慮した使用予定期間限定ポイント数の具体的な計算例については後に改めて説明する。

変更提言通知処理部Ｆ４は、予定購入として、シリーズ購入における購入が行われたことに応じて、当該購入の時点でのユーザの保有ポイント数を取得し、取得した保有ポイント数と使用上限ポイント数との差の発生態様に基づき、使用上限ポイント数の変更をユーザに提言するための通知を行う。
予定購入についてユーザが設定した使用上限ポイント数に対し、予定購入実行時点での保有ポイント数に差が生じている場合には、設定された使用上限ポイント数は当該ユーザのポイント獲得・使用の態様に合致しない不適切なものであると言うことができる。このため、当該差の発生態様に基づいて使用上限ポイント数の変更をユーザに提言する。

本例では、使用上限ポイント数の変更提言通知は、保有ポイント数と使用上限ポイント数との差の発生頻度、及び差の大きさに基づいて行う。具体的に、変更提言通知処理部Ｆ４は、予定購入が行われるごとに、保有ポイント数と使用上限ポイント数との差を計算し、当該差が所定値α以上である予定購入が所定回数（Ｘ回）以上連続しているか否かを判定し、連続している場合に使用上限ポイント数の変更提言通知を行う。

この場合の変更提言通知としては、例えば「使用上限ポイント数が低く設定されているようです。使用上限ポイント数を引き上げますか？」などのメッセージを記した電子メールをユーザの登録メールアドレス宛に送信することで行う。この際、過去Ｘ回分の保有ポイント数と使用上限ポイント数との差に応じて適切とされる引き上げポイント数を求め、当該引き上げポイント数の情報を変更提言通知に含めるようにしてもよい。また、変更提言通知には、対象のシリーズ購入における各購入ごとの保有ポイント数、使用ポイント数の履歴情報を含めるようにしてもよい。

＜４．処理手順＞

続いて、上記により説明した実施の形態としての各機能を実現するために実行すべき具体的な処理の手順を図９〜図１４のフローチャートを参照して説明する。なお、これらのフローチャートに示す処理は、ショッピングサーバ３ａのＣＰＵ１０１が例えば記憶部１０８等の記憶装置に記憶されたプログラムに従って実行する。

図９は、購入申込受付処理部Ｆ１に対応した処理を示している。
図９において、ショッピングサーバ３ａのＣＰＵ１０１は、ステップＳ１０１の申込情報入力受付処理として、ユーザによる予定購入に係る申込情報の入力受付のための処理を行う。具体的には、先の図６〜図８に示したウェブページにおけるユーザの入力情報の受付を行う。先の説明から理解されるように、ここでの入力情報としては、図８に示したウェブページ上の入力ボックスｐ８に対する使用上限ポイント数の入力情報が含まれる。

続くステップＳ１０２でＣＰＵ１０１は、申込完了操作が行われるまで待機する。すなわち、前述した申し込み内容の確認ページにおける確定ボタンを選択する操作が検出されるまで待機する。

申込完了操作が行われた場合、ＣＰＵ１０１は、ステップＳ１０３で購入情報、設定された使用上限ポイント数の情報を購入ＩＤに紐付けて保存する。購入情報とは、購入商品の商品ＩＤ、販売店舗の店舗ＩＤ、及び商品価格の情報を含むと共に、シリーズ購入であればさらに各購入のサイクルの情報を含み、予約購入であれば商品の入荷予定日（購入の実行予定日）の情報をさらに含む。
購入ＩＤは、ユーザにより申し込まれたシリーズ購入又は予約購入を識別するための情報としてショッピングサーバ３ａのＣＰＵ１０１が生成するものである。

ＣＰＵ１０１は、ステップＳ１０３の紐付け処理を実行したことに応じてこの図に示す処理を終了する。

図１０は、期間限定ポイント数通知処理部Ｆ３に対応した処理を示している。
先ず、ＣＰＵ１０１はステップＳ２０１で、現時点から対象の予定購入の実行予定日までの間に実行予定日が存在する他の予定購入があるか否かを判定する。当該他の予定購入が存在しなければ、ＣＰＵ１０１はステップＳ２０２に進み、「購入時使用可能期間限定ポイント数」として、「現時点で保有されている購入実行予定日より後に期限を迎える期間限定ポイント数」（現時点で保有されている期間限定ポイント数のうち対象とする予定購入の実行予定日より後に期限を迎える期間限定ポイント数）を割り当てた上で、ステップＳ２０８に進む。

一方、ステップＳ２０１において、他の予定購入があると判定した場合には、ＣＰＵ１０１はステップＳ２０３に進み、他の予定購入は複数であるか否かを判定する。
他の予定購入が複数でなければ、ＣＰＵ１０１はステップＳ２０４に進み、他の予定購入での「使用予定期間限定ポイント数」を計算する（以下「ポイント数ｄ１」と表記）。
ここで、他の予定購入での「使用予定期間限定ポイント数」は、当該他の予定購入を「対象とする予定購入」と置き換えて図１０に示す処理と同じ処理を行って求める。この点は、後述する図１１のステップＳ３０３及びステップＳ３０５の処理についても同様である。

ＣＰＵ１０１は、続くステップＳ２０５で、「購入時使用可能期間限定ポイント数」として、「現時点で保有されている購入実行予定日より後に期限を迎える期間限定ポイント数」から上記のポイント数ｄ１を減じた値を割り当てた上で、ステップＳ２０８に進む。

一方、他の予定購入が複数であれば、ＣＰＵ１０１はステップＳ２０６に進み、各他の予定購入での使用予定期間限定ポイント数の総和Ｗを計算する。

図１１は、ステップＳ２０６の総和Ｗの計算処理を示している。
ＣＰＵ１０１は、ステップＳ３０１で他の予定購入を識別するためのカウント値ｎを「１」にセットし、続くステップＳ３０２で存在する他の予定購入の総数をＮとしてセットした上で、ステップＳ３０３に進む。
ステップＳ３０３でＣＰＵ１０１は、実行予定日を１番目に迎える（１番早く迎える）他の予定購入での使用予定期間限定ポイント数を計算する。

続くステップＳ３０４でＣＰＵ１０１は、カウント値ｎをインクリメント（＋１）した上で、ステップＳ３０５で実行予定日をｎ番目に迎える他の予定購入での使用予定期間限定ポイント数を計算し、ステップＳ３０６でカウント値ｎが他の予定購入の総数Ｎ以上であるか否かを判定する。
カウント値ｎが総数Ｎ以上でなければ、ＣＰＵ１０１はステップＳ３０４に戻る。すなわち、存在する他の予定購入の全てについて使用予定期間限定ポイント数を計算するまでステップＳ３０４〜Ｓ３０６の処理が繰り返される。

カウント値ｎが総数Ｎ以上であれば、ＣＰＵ１０１はステップＳ３０７に進み、１〜Ｎ番目それぞれの他の予定購入について計算した使用予定期間限定ポイント数の総和を総和Ｗとして計算し、ステップＳ２０６の総和Ｗの計算処理を終える。

図１０に戻り、ＣＰＵ１０１は、ステップＳ２０６に続くステップＳ２０７で、「購入時使用可能期間限定ポイント数」として「現時点で保有されている購入実行予定日より後に期限を迎える期間限定ポイント数」から総和Ｗを減じた値を割り当てた上で、ステップＳ２０８に進む。

ステップＳ２０８でＣＰＵ１０１は、対象とする予定購入について設定された使用上限ポイント数、商品価格、及びステップＳ２０２又はＳ２０５又はＳ２０７で割り当てた「購入時使用可能期間限定ポイント数」に基づき、使用予定期間限定ポイント数を求める。

図１２は、ステップＳ２０８で実行する具体的な処理を示している。
本例では、前述した条件ｉの場合に該当するか否か、条件iiの場合に該当するか否かを判定した結果に基づき、使用予定期間限定ポイント数を商品価格、使用上限ポイント数、購入時使用可能期間限定ポイント数の何れかとして求める。
具体的に、ＣＰＵ１０１は、ステップＳ４０１で購入時使用可能期間限定ポイント数≧商品価格、且つ使用上限ポイント数≧商品価格である（条件ｉ）か否かを判定し、肯定結果が得られた場合は、ステップＳ４０２に進んで使用予定期間限定ポイント数として商品価格を割り当て、ステップＳ２０８の処理を終える。

一方、ステップＳ４０１の判定処理で否定結果が得られた場合、ＣＰＵ１０１はステップＳ４０３に進み、使用上限ポイント数＜商品価格、且つ購入時使用可能期間限定ポイント数≧使用上限ポイント数である（条件ii）か否かを判定し、肯定結果が得られた場合はステップＳ４０４に進んで使用予定期間限定ポイント数として使用上限ポイント数を割り当て、ステップＳ２０８の処理を終える。

また、ステップＳ４０３の判定処理で否定結果が得られた場合（つまり条件ｉ、条件iiの何れの場合にも該当しない場合）、ＣＰＵ１０１はステップＳ４０５に進み、使用予定期間限定ポイント数として購入時使用可能期間限定ポイント数を割り当て、ステップＳ２０８の処理を終える。

ＣＰＵ１０１は、上記ステップＳ２０８の処理により使用予定期間限定ポイント数を求めたことに応じ、図１０に示すステップＳ２０９に進んで使用予定期間限定ポイント数の通知処理を行う。すなわち、少なくとも使用予定期間限定ポイント数の情報を含んだ電子メールをユーザの登録メールアドレス宛に送信するための処理を行う。
なお、この際の通知は、ＥＣサイトにおける所定のウェブページ上で行うなどしてもよく、電子メールによる通知に限定されるものではない。

ここで、上記では、予定購入で使用される予定の期間限定ポイント数を通知する例を挙げたが、これに代えて、又はこれと共に、予定購入では使用されない予定の期間限定ポイントの数(以下「非使用予定期間限定ポイント数」と表記）を通知してもよい。当該「非使用予定期間限定ポイント数」については、例えば、上記の手法により求めた「使用予定期間限定ポイント数」を現時点（図１０の処理の実行時点）で保有されている期間限定ポイント数から減じたポイント数として算出すればよい。或いは、「非使用予定期間限定ポイント数」は、特に他の予定購入が存在しないケースにおいては、現時点（図１０の処理の実行時点）で保有されている期間限定ポイント数のうち対象とする予定購入の実行予定日以前に期限を迎えるポイント数と、「購入時使用可能期間限定ポイント数」のうち当該予定購入では使用されない期間限定ポイント数との和として求めることもできる。

また、上記では、対象とする予定購入についての「購入時使用可能期間限定ポイント数」を計算するために要する「他の予定購入での使用予定期間限定ポイント数」の値を、ステップＳ２０４やＳ２０６において都度計算する例を示したが、当該「他の予定購入での使用予定期間限定ポイント数」が既に計算され保存されている場合には、当該保存されたポイント数を流用することができる。

図１３は、割引決済制御処理部Ｆ２に対応した処理を示している。
なお、図１３に示す処理は、シリーズ購入における各購入、又は予約購入の何れかとしての予定購入についての購入処理を実行すべき条件が成立したことに応じて開始されるものである。

先ず、ＣＰＵ１０１はステップＳ５０１で、当該予定購入は購入予定回数がＸ回を超えるシリーズ購入における購入であるか否かを判定する。
購入予定回数がＸ回を超えるシリーズ購入における購入であるとして肯定結果が得られた場合、ＣＰＵ１０１はステップＳ５０２に進み、現時点での保有ポイント数（当該予定購入の申込ユーザの保有ポイント数）を例えば記憶部１０８に保存した上でステップＳ５０３に進む。
このステップＳ５０２の保存処理は、シリーズ購入を対象とした変更提言通知を行うべきか否かの判定（図１４で後述）において用いる、各購入時の保有ポイント数の情報を保存する処理である。

一方、ステップＳ１０１の判定処理で否定結果が得られた場合（つまり対象の予定購入が購入予定回数≦Ｘ回のシリーズ購入における購入、又は予約購入である場合）、ＣＰＵ１０１はステップＳ５０２の保存処理をパスしてステップＳ５０３に進む。

ステップＳ５０３でＣＰＵ１０１は、保有ポイント数≧使用上限ポイント数であるか否かを判定する。保有ポイント数≧使用上限ポイント数であれば、ＣＰＵ１０１はステップＳ５０４に進んで「使用可能ポイント数」として使用上限ポイント数を割り当て、ステップＳ５０６に進む。
一方、保有ポイント数≧使用上限ポイント数でなければ、ＣＰＵ１０１はステップＳ５０５に進んで「使用可能ポイント数」として保有ポイント数を割り当て、ステップＳ５０６に進む。
なお、「使用可能ポイント数」は、以下の説明から理解されるように、当該購入で使用するポイント数（以下「使用ポイント数」と表記）の候補値である。

ステップＳ５０６でＣＰＵ１０１は、確認値として「商品価格」−「使用可能ポイント数」を計算し、続くステップＳ５０７で確認値が０未満であるか（つまり使用可能ポイント数が商品価格より大か否か）を判定する。
確認値が０未満でなければ、ＣＰＵ１０１はステップＳ５０８に進んで「使用ポイント数」として「使用可能ポイント数」を割り当てた上で、ステップＳ５０９で確認値を決済額とした注文情報を該当する店舗端末５に対して送信し、この図に示す処理を終える。

一方、確認値が０未満であれば、ＣＰＵ１０１はステップＳ５１０に進んで「使用ポイント数」として商品価格を割り当てた上で、ステップＳ５１１で決済額＝０とした注文情報を該当する店舗端末５に対して送信し、この図に示す処理を終える。

図１４は、変更提言通知処理部Ｆ４に対応した処理を示している。
なお、図１４に示す処理は、例えば、図１３に示した処理が実行されるごとなど、対象とするシリーズ購入における各購入の実行ごとに行われる。
先ず、ＣＰＵ１０１はステップＳ６０１で、対象のシリーズ購入について、購入時に先のステップＳ５０２で保存された保有ポイント数の情報、及び設定された使用上限ポイント数の情報を取得し、ステップＳ６０２で「保有ポイント数」−「使用上限ポイント数」を計算し、例えば記憶部１０８に保存する。

続くステップＳ６０３でＣＰＵ１０１は、Ｘ回連続して「保有ポイント数」−「使用上限ポイント数」が所定値α以上であるか否かを判定する。
Ｘ回連続して「保有ポイント数」−「使用上限ポイント数」が所定値α以上であれば、ＣＰＵ１０１はステップＳ６０４に進み、上限ポイント数変更提言通知処理として、例えば設定中の使用上限ポイント数の引き上げを提言するための情報を含んだ電子メールをユーザの登録メールアドレス宛に送信するための処理を行い、この図に示す処理を終える。
なお、この際の通知としても、ＥＣサイトにおける所定のウェブページ上で行うなど、電子メールによる通知に限定されるものではない。

一方、Ｘ回連続して「保有ポイント数」−「使用上限ポイント数」が所定値α以上でなければ、ＣＰＵ１０１はステップＳ６０４の通知処理をパスしてこの図に示す処理を終える。

なお、上記では、使用上限ポイント数の引き上げ側の提言通知を行う例を挙げたが、引き下げ側の提言通知を行うこともできる。その場合は、例えばステップＳ６０４においてＸ回連続して「保有ポイント数」−「使用上限ポイント数」≦−αか否かを判定し、肯定結果が得られた場合に使用上限ポイント数の引き下げを提言する通知を行えばよい。

＜５．実施の形態のまとめ＞

上記のように実施の形態の情報処理装置（ショッピングサーバ３ａ）は、購入の申し込みタイミングから時間差を有して行われる購入である予定購入について、使用するポイント数の上限である使用上限ポイント数を操作に基づき設定するポイント数設定部（購入申込受付処理部Ｆ１）と、ポイント管理情報に基づいて、予定購入に係る決済がポイント数設定部により設定された使用上限ポイント数に応じた割引額で行われるように制御する割引決済制御部（割引決済制御処理部Ｆ２）とを備える。
また、使用上限ポイント数が設定された予定購入について、当該予定購入で使用される予定の期間限定ポイントの数である使用予定期間限定ポイント数、又は当該予定購入では使用されない予定の期間限定ポイントの数である非使用予定期間限定ポイント数をポイント管理情報と使用上限ポイント数とに基づいて求め、当該予定購入が行われる前にユーザに通知する期間限定ポイント数通知部（期間限定ポイント数通知処理部Ｆ３）と、予定購入として、複数回の商品又はサービスの購入が１セットとされたシリーズ購入における予定購入が行われたことに応じて、当該予定購入の時点でのユーザの保有ポイント数を取得し、取得した保有ポイント数と使用上限ポイント数との差の発生態様に基づき、使用上限ポイント数の変更をユーザに提言するための通知を行う変更提言通知部（変更提言通知処理部Ｆ４）とを備えている。

使用上限ポイント数に基づくポイント使用としたことで、予定購入でのポイント使用が使用上限ポイント数までを範囲内として行われることが予めユーザにより把握される。また、ユーザによる使用ポイント数の設定は少なくとも申し込み時のみで済む。
また、使用予定期間限定ポイント数又は非使用予定期間限定ポイント数の通知が行われることで、使用又は非使用予定の期間限定ポイント数を計算するという比較的重い負担をユーザに強いることがなく、さらに、変更提言通知が行われることで、ユーザにポイント使用状況の監視負担を強いることなくユーザのポイント獲得・使用状況に応じた適切な使用上限ポイント数への変更が可能とされる。
以上より、実施の形態の情報処理装置によれば、予定購入についてユーザの意図したポイント数による割引が行われるようにしつつ、ユーザの負担軽減を図ることができる。
また、予定購入で使用又は非使用予定の期間限定ポイント数が通知されることで、ユーザの期間限定ポイントについての期限管理負担の緩和が図られ、さらに当該予定購入で使用される期間限定ポイントがある場合においては、期間限定ポイントを焦って使用する必要が無いことをユーザに事前に把握させることができる。

また、実施の形態の情報処理装置においては、期間限定ポイント数通知部は、対象とする予定購入よりも前に実行予定の他の予定購入が存在するか否かを判定し、当該他の予定購入が存在する場合には、当該他の予定購入での使用予定期間限定ポイント数に基づき、対象とする予定購入での使用予定期間限定ポイント数、又は非使用予定期間限定ポイント数を求めている。

これにより、使用又は非使用予定の期間限定ポイント数の通知にあたり、複数の予定購入がオーバーラップして存在することが許容される。
従って、他の予定購入が存在する場合に使用又は非使用予定の期間限定ポイント数の通知ができないという不便さを解消でき、利便性の向上を図ることができる。

さらに、実施の形態の情報処理装置においては、期間限定ポイント数通知部は、対象とする予定購入において使用可能な期間限定ポイント数である購入時使用可能期間限定ポイント数が当該予定購入の対象商品又はサービスの価格以上であり、且つ当該予定購入に対して設定された使用上限ポイント数が商品又はサービスの価格以上であるか否かを判定し、肯定結果が得られた場合は商品又はサービスの価格を使用予定期間限定ポイント数とし、当該予定購入に対して設定された使用上限ポイント数が商品又はサービスの価格未満であり、且つ購入時使用可能期間限定ポイント数が当該予定購入に対して設定された使用上限ポイント数以上であるか否かを判定し、肯定結果が得られた場合は当該予定購入に対して設定された使用上限ポイント数を使用予定期間限定ポイント数とし、双方の前記判定で否定結果が得られた場合は、購入時使用可能期間限定ポイント数を使用予定期間限定ポイント数としている。

これにより、使用可能期間限定ポイント数を求めるのに要する場合分けの数が最小となる。
従って、使用可能期間限定ポイント数を求めるための場合分けに要する処理負担の軽減を図ることができる。

さらにまた、実施の形態の情報処理装置においては、変更提言通知部は、シリーズ購入における予定購入が行われるごとに保有ポイント数と使用上限ポイント数とに差が生じているか否かを判定し、当該差の発生頻度に基づいて前記通知を行っている。

これにより、購入ごとに取得される保有ポイント数と使用上限ポイント数との差の発生頻度に応じて適切に変更提言を行うことができ、変更提言の有効性を高めることができる。

また、実施の形態の情報処理装置においては、変更提言通知部は、取得した保有ポイント数と使用上限ポイント数との差の大きさに基づいて前記通知を行っている。

これにより、購入ごとに取得される保有ポイント数と使用上限ポイント数との差の大きさに応じて適切に変更提言を行うことができ、変更提言の有効性を高めることができる。

＜６．プログラム及び記憶媒体＞

以上、本発明に係る情報処理装置の実施の形態としてのショッピングサーバ３ａを説明してきたが、実施の形態のプログラムは、ショッピングサーバ３ａの処理を情報処理装置（ＣＰＵ等）に実行させるプログラムである。

実施の形態のプログラムは、商品又はサービスの購入時に使用可能なポイントとして、使用期限が定められた期間限定ポイントと使用期限の無い又は前記期間限定ポイントよりも長期の使用期限が定められた通常ポイントとに分けて管理するポイント管理情報にアクセス可能とされた情報処理装置に処理を実行させるプログラムであって、購入の申し込みタイミングから時間差を有して行われる購入である予定購入について、使用するポイント数の上限である使用上限ポイント数を操作に基づき設定するポイント数設定機能と、前記ポイント管理情報に基づいて、前記予定購入に係る決済が前記ポイント数設定機能により設定された前記使用上限ポイント数に応じた割引額で行われるように制御する割引決済制御機能と、前記使用上限ポイント数が設定された前記予定購入について、当該予定購入で使用される予定の前記期間限定ポイントの数である使用予定期間限定ポイント数、又は当該予定購入では使用されない予定の前記期間限定ポイントの数である非使用予定期間限定ポイント数を前記ポイント管理情報と前記使用上限ポイント数とに基づいて求め、当該予定購入が行われる前にユーザに通知する期間限定ポイント数通知機能と、前記予定購入として、複数回の商品又はサービスの購入が１セットとされたシリーズ購入における予定購入が行われたことに応じて、当該予定購入の時点でのユーザの保有ポイント数を取得し、取得した保有ポイント数と前記使用上限ポイント数との差の発生態様に基づき、前記使用上限ポイント数の変更をユーザに提言するための通知を行う変更提言通知機能と、を情報処理装置に実現させる。
すなわち、このプログラムは、例えばショッピングサーバ３ａ等の情報処理装置に図９〜図１４等により説明した処理を実行させるプログラムに相当する。

このようなプログラムにより、上述したショッピングサーバ３ａとしての情報処理装置を実現できる。
そして、このようなプログラムはコンピュータ装置等の機器に内蔵されている記憶媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭ等に予め記憶しておくことができる。或いはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記憶媒体に、一時的あるいは永続的に格納（記憶）しておくことができる。またこのようなリムーバブル記憶媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記憶媒体からパーソナルコンピュータ等にインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークを介してダウンロードすることもできる。

＜７．変形例＞

本発明は上記により説明した具体例に限定されず、各種の変形例が考えられる。
例えば、上記では、シリーズ購入の例として商品の定期購入を挙げたが、シリーズ購入としては電気、ガス、水道、通信／通話サービス等の公共サービスの周期的な購入を挙げることもできる。

１ ネットワークシステム、２ ネットワーク、３ ショッピングサイト運営システム、３ａ ショッピングサーバ、３ｄ ポイントＤＢ（データベース）、４ ユーザ端末、５ 店舗端末、６ カード会社サーバ、１０１ ＣＰＵ、Ｆ１ 購入申込受付処理部、Ｆ２ 割引決済制御処理部、Ｆ３ 期間限定ポイント数通知処理部、Ｆ４ 変更提言通知処理部

Claims (8)

1. 商品又はサービスの購入時に使用可能なポイントとして、使用期限が定められた期間限定ポイントと使用期限の無い又は前記期間限定ポイントよりも長期の使用期限が定められた通常ポイントとに分けて管理するポイント管理情報にアクセス可能とされた情報処理装置であって、
   購入の申し込みタイミングから時間差を有して行われる購入である予定購入について、使用するポイント数の上限である使用上限ポイント数を操作に基づき設定するポイント数設定部と、
   前記ポイント管理情報に基づいて、前記予定購入に係る決済が前記ポイント数設定部により設定された前記使用上限ポイント数に応じた割引額で行われるように制御する割引決済制御部と、
   前記使用上限ポイント数が設定された前記予定購入について、当該予定購入で使用される予定の前記期間限定ポイントの数である使用予定期間限定ポイント数、又は当該予定購入では使用されない予定の前記期間限定ポイントの数である非使用予定期間限定ポイント数を前記ポイント管理情報と前記使用上限ポイント数とに基づいて求め、当該予定購入が行われる前にユーザに通知する期間限定ポイント数通知部と、
   前記予定購入として、複数回の商品又はサービスの購入が１セットとされたシリーズ購入における予定購入が行われたことに応じて、当該予定購入の時点でのユーザの保有ポイント数を取得し、取得した保有ポイント数と前記使用上限ポイント数との差の発生態様に基づき、前記使用上限ポイント数の変更をユーザに提言するための通知を行う変更提言通知部と、を備える
   情報処理装置。
2. 前記期間限定ポイント数通知部は、
   対象とする前記予定購入よりも前に実行予定の他の予定購入が存在するか否かを判定し、当該他の予定購入が存在する場合には、当該他の予定購入での前記使用予定期間限定ポイント数に基づき、対象とする前記予定購入での前記使用予定期間限定ポイント数、又は前記非使用予定期間限定ポイント数を求める
   請求項１に記載の情報処理装置。
3. 前記期間限定ポイント数通知部は、
   対象とする前記予定購入において使用可能な期間限定ポイント数である購入時使用可能期間限定ポイント数が当該予定購入の対象商品又はサービスの価格以上であり、且つ当該予定購入に対して設定された前記使用上限ポイント数が前記商品又はサービスの価格以上であるか否かを判定し、肯定結果が得られた場合は前記商品又はサービスの価格を前記使用予定期間限定ポイント数とし、
   当該予定購入に対して設定された前記使用上限ポイント数が前記商品又はサービスの価格未満であり、且つ前記購入時使用可能期間限定ポイント数が当該予定購入に対して設定された前記使用上限ポイント数以上であるか否かを判定し、肯定結果が得られた場合は当該予定購入に対して設定された前記使用上限ポイント数を前記使用予定期間限定ポイント数とし、
   双方の前記判定で否定結果が得られた場合は、前記購入時使用可能期間限定ポイント数を前記使用予定期間限定ポイント数とする
   請求項１に記載の情報処理装置。
4. 前記変更提言通知部は、
   前記シリーズ購入における予定購入が行われるごとに前記保有ポイント数と前記使用上限ポイント数とに差が生じているか否かを判定し、当該差の発生頻度に基づいて前記通知を行う
   請求項１に記載の情報処理装置。
5. 前記変更提言通知部は、
   前記取得した保有ポイント数と前記使用上限ポイント数との差の大きさに基づいて前記通知を行う
   請求項１に記載の情報処理装置。
6. 商品又はサービスの購入時に使用可能なポイントとして、使用期限が定められた期間限定ポイントと使用期限の無い又は前記期間限定ポイントよりも長期の使用期限が定められた通常ポイントとに分けて管理するポイント管理情報にアクセス可能とされた情報処理装置における情報処理方法であって、
   購入の申し込みタイミングから時間差を有して行われる購入である予定購入について、使用するポイント数の上限である使用上限ポイント数を操作に基づき設定するポイント数設定ステップと、
   前記ポイント管理情報に基づいて、前記予定購入に係る決済が前記ポイント数設定ステップにより設定された前記使用上限ポイント数に応じた割引額で行われるように制御する割引決済制御ステップと、
   前記使用上限ポイント数が設定された前記予定購入について、当該予定購入で使用される予定の前記期間限定ポイントの数である使用予定期間限定ポイント数、又は当該予定購入では使用されない予定の前記期間限定ポイントの数である非使用予定期間限定ポイント数を前記ポイント管理情報と前記使用上限ポイント数とに基づいて求め、当該予定購入が行われる前にユーザに通知する期間限定ポイント数通知ステップと、
   前記予定購入として、複数回の商品又はサービスの購入が１セットとされたシリーズ購入における予定購入が行われたことに応じて、当該予定購入の時点でのユーザの保有ポイント数を取得し、取得した保有ポイント数と前記使用上限ポイント数との差の発生態様に基づき、前記使用上限ポイント数の変更をユーザに提言するための通知を行う変更提言通知ステップと、を実行する
   情報処理方法。
7. 商品又はサービスの購入時に使用可能なポイントとして、使用期限が定められた期間限定ポイントと使用期限の無い又は前記期間限定ポイントよりも長期の使用期限が定められた通常ポイントとに分けて管理するポイント管理情報にアクセス可能とされた情報処理装置に処理を実行させるプログラムであって、
   購入の申し込みタイミングから時間差を有して行われる購入である予定購入について、使用するポイント数の上限である使用上限ポイント数を操作に基づき設定するポイント数設定機能と、
   前記ポイント管理情報に基づいて、前記予定購入に係る決済が前記ポイント数設定機能により設定された前記使用上限ポイント数に応じた割引額で行われるように制御する割引決済制御機能と、
   前記使用上限ポイント数が設定された前記予定購入について、当該予定購入で使用される予定の前記期間限定ポイントの数である使用予定期間限定ポイント数、又は当該予定購入では使用されない予定の前記期間限定ポイントの数である非使用予定期間限定ポイント数を前記ポイント管理情報と前記使用上限ポイント数とに基づいて求め、当該予定購入が行われる前にユーザに通知する期間限定ポイント数通知機能と、
   前記予定購入として、複数回の商品又はサービスの購入が１セットとされたシリーズ購入における予定購入が行われたことに応じて、当該予定購入の時点でのユーザの保有ポイント数を取得し、取得した保有ポイント数と前記使用上限ポイント数との差の発生態様に基づき、前記使用上限ポイント数の変更をユーザに提言するための通知を行う変更提言通知機能と、
   を前記情報処理装置に実現させる
   プログラム。
8. 商品又はサービスの購入時に使用可能なポイントとして、使用期限が定められた期間限定ポイントと使用期限の無い又は前記期間限定ポイントよりも長期の使用期限が定められた通常ポイントとに分けて管理するポイント管理情報にアクセス可能とされた情報処理装置に処理を実行させるプログラムを記憶した記憶媒体であって、
   購入の申し込みタイミングから時間差を有して行われる購入である予定購入について、使用するポイント数の上限である使用上限ポイント数を操作に基づき設定するポイント数設定機能と、
   前記ポイント管理情報に基づいて、前記予定購入に係る決済が前記ポイント数設定機能により設定された前記使用上限ポイント数に応じた割引額で行われるように制御する割引決済制御機能と、
   前記使用上限ポイント数が設定された前記予定購入について、当該予定購入で使用される予定の前記期間限定ポイントの数である使用予定期間限定ポイント数、又は当該予定購入では使用されない予定の前記期間限定ポイントの数である非使用予定期間限定ポイント数を前記ポイント管理情報と前記使用上限ポイント数とに基づいて求め、当該予定購入が行われる前にユーザに通知する期間限定ポイント数通知機能と、
   前記予定購入として、複数回の商品又はサービスの購入が１セットとされたシリーズ購入における予定購入が行われたことに応じて、当該予定購入の時点でのユーザの保有ポイント数を取得し、取得した保有ポイント数と前記使用上限ポイント数との差の発生態様に基づき、前記使用上限ポイント数の変更をユーザに提言するための通知を行う変更提言通知機能と、
   を前記情報処理装置に実現させるプログラムを記憶した
   記憶媒体。

Images