JP2011209934A - 電子商取引サーバ及び電子商取引方法 - Google Patents
電子商取引サーバ及び電子商取引方法 Download PDFInfo
- Publication number
- JP2011209934A JP2011209934A JP2010075975A JP2010075975A JP2011209934A JP 2011209934 A JP2011209934 A JP 2011209934A JP 2010075975 A JP2010075975 A JP 2010075975A JP 2010075975 A JP2010075975 A JP 2010075975A JP 2011209934 A JP2011209934 A JP 2011209934A
- Authority
- JP
- Japan
- Prior art keywords
- order
- product
- information
- entry
- confirmed
- 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.)
- Granted
Links
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】消費者の共同購入への参加意欲を高める技術を提供する。
【解決手段】電子商取引サーバは、各共同購入商品についてその共同購入の終了時間を含む商品情報をそれぞれ格納する手段と、注文情報に含まれるその共同購入の注文方法としてエントリー状態及び注文確定状態のいずれか一方を選択可能な共同購入画面を消費者端末に表示させるための共同購入画面データを送信する手段と、共同購入の注文方法を含む注文情報を各消費者についてそれぞれ格納する手段と、エントリー状態を選択している消費者の消費者端末に対してのみ他の共同購入商品へ注文変更を受け付ける購入変更画面をその消費者端末に表示させるための購入変更画面データを送信する手段と、上記複数の注文情報のうち当該終了時間が経過した共同購入商品を対象にエントリー状態となっている注文情報を特定し、この注文情報を共同購入確定状態とする制御手段と、を備える。
【選択図】図１４
【解決手段】電子商取引サーバは、各共同購入商品についてその共同購入の終了時間を含む商品情報をそれぞれ格納する手段と、注文情報に含まれるその共同購入の注文方法としてエントリー状態及び注文確定状態のいずれか一方を選択可能な共同購入画面を消費者端末に表示させるための共同購入画面データを送信する手段と、共同購入の注文方法を含む注文情報を各消費者についてそれぞれ格納する手段と、エントリー状態を選択している消費者の消費者端末に対してのみ他の共同購入商品へ注文変更を受け付ける購入変更画面をその消費者端末に表示させるための購入変更画面データを送信する手段と、上記複数の注文情報のうち当該終了時間が経過した共同購入商品を対象にエントリー状態となっている注文情報を特定し、この注文情報を共同購入確定状態とする制御手段と、を備える。
【選択図】図１４
Description
本発明は、電子商取引における技術に関する。
現在、インターネット等のコンピュータネットワーク上で電子的な情報交換によって商取引を行う電子商取引（Ｅコマース）が盛んに行われている。この電子商取引は様々な形態で実施されているが、その一例としてサイバーモールと呼ばれるものがある。サイバーモールとは、インターネット上で複数の小売業者のウェブページを一つにまとめて、様々な商品を販売するウェブサイトのことである。サイバーモールでは、消費者は、消費者端末を用いてウェブサイトにアクセスし、購入を希望する商品を見つけ出し、商品を注文し、購入決済を行うことでその商品を購入することができる。
また、このようなウェブサイトの中には、商品を他の消費者と共同購入をすることができる電子商取引用のウェブサイト（以降、単に「共同購入サイト」とも表記する）もある。共同購入とは、同じ商品の消費者（この場合を特に「購入希望者」と表記する）が集まって共同で購入することで、商品１個あたりの購入価格（以降、単に「商品価格」と表記する）を安くしようとする購入方法のことである。
この共同購入サイトでは、商品の購入希望者が共同で購入する商品の総量で商品価格が決定するため、商品の購入希望者が共同で購入するその商品の総量（以降、単に「購入総量」と表記）が決定していない段階においては、商品価格を決定することができない。そのため、そのような段階では、購入希望者が商品を注文して、購入決済を行っても、購入希望者の支払金額が決定しないため、購入決済を完了することができない。
購入決済を完了するために、共同購入サイトでは、商品価格を決定するための条件、言い換えると、販売を終了するための条件が設定されている。販売終了条件は２つある。一つ目は、販売期間である。販売期間は、いつまでたっても購入希望者が集まらず販売を終了することが出来ない事態に陥ってしまわないように、購入希望者を集うための期間として設定されている。二つ目は、販売数である。販売数は、小売業者が販売できない事態に陥ってしまわないように、小売業者が販売を予定している商品の数量として設定されている。
どちらかの販売終了の条件が満たされると、その商品は販売終了になり、その商品の商品価格が決定される。そして、ようやく購入希望者の購入決済が完了し、購入希望者は商品を購入することができる。
しかしながら、上述の共同購入サイトでは、購入希望者は、一度商品の注文を行うと、購入決済が完了していなくても、その注文のキャンセルをすることは一般的に認められていない。なぜなら、注文のキャンセルが行われることで、購入総量が減り、商品価格が、一度商品価格として決定した、その他の購入希望者が購入を決めた価格よりも高い価格になってしまう可能性があるからである。
また、このような共同購入サイトにおいて、商品の注文を行った後に、他のより魅力的な共同購入対象の商品に乗り換えたいと思ったとしても、消費者は、その商品の注文をキャンセルできない。
そのため、消費者は、共同購入サイトにおいて商品を注文する際、商品の購入を後悔しないよう、その商品の関連情報や推奨商品の情報を調べるなど慎重になる必要があり、気軽に購入に参加できないという問題点がある。
本発明の課題は、このような問題点に鑑み、消費者の共同購入への参加意欲を高める技術を提供することにある。
本発明の各態様では、上述した課題を解決するために、それぞれ以下の構成を採用する。
本発明の第１態様は、共同購入サービスを提供する電子商取引サーバに関する。第１態様に係る電子商取引サーバは、共同購入対象となる各共同購入商品について、その共同購入の注文の受付を締め切る終了時間を含む商品情報をそれぞれ格納する商品情報格納手段と、共同購入の注文情報を消費者に入力させる共同購入画面であって、その注文情報に含まれるその共同購入の注文方法として、エントリー状態及び注文確定状態のいずれか一方を選択可能な共同購入画面を消費者端末に表示させるための共同購入画面データをその消費者端末へ送信する手段と、その共同購入画面で入力された共同購入の注文方法を含む注文情報を各消費者についてそれぞれ格納する注文情報格納手段と、共同購入の注文方法としてエントリー状態を選択している消費者の消費者端末に対してのみ、他の共同購入商品へ注文変更を受け付ける購入変更画面をその消費者端末に表示させるための購入変更画面データを送信する手段と、上記注文情報格納手段に格納される複数の注文情報のうち、上記商品情報格納手段に格納される複数の共同購入商品のうちの当該終了時間が経過した共同購入商品を対象にエントリー状態となっている注文情報を特定し、このエントリー状態となっている注文情報を同一の共同購入商品を対象に注文確定状態となっている注文情報と共に共同購入確定状態とする制御手段と、を備える。
なお、本発明の別態様としては、以上の何れかの構成を実現する方法であってもよいし、プログラムであってもよいし、このようなプログラムを記録したコンピュータが読み取り可能な記憶媒体であってもよい。
本発明によれば、消費者の共同購入への参加意欲を高める技術を提供することができる。
以下、本発明を実施するための形態としての共同購入の電子商取引システム（以下、単に「本システム」とも表記する）について具体例を挙げて説明する。以下に挙げる実施形態は例示であり、本発明は以下の実施形態の構成に限定されない。
§１システム構成
図１は、実施形態における電子商取引システムの全体構成を示す図である。本実施形態における電子商取引システムは、データサーバ１、ワークサーバ２、ＷＥＢサーバ５、ユーザ端末９等から構成される。データサーバ１、ワークサーバ２、ＷＥＢサーバ５はそれぞれシステム内ネットワーク７により相互に通信可能に接続される。これにより、複数のユーザ端末９の各々は、ネットワーク６を介してＷＥＢサーバ５へアクセスすることができ、電子商取引サービスの提供を受けることができる。例えば、ユーザ端末９とＷＥＢサーバ５との間のインタフェースとしてＷＥＢシステムが利用される。
図１は、実施形態における電子商取引システムの全体構成を示す図である。本実施形態における電子商取引システムは、データサーバ１、ワークサーバ２、ＷＥＢサーバ５、ユーザ端末９等から構成される。データサーバ１、ワークサーバ２、ＷＥＢサーバ５はそれぞれシステム内ネットワーク７により相互に通信可能に接続される。これにより、複数のユーザ端末９の各々は、ネットワーク６を介してＷＥＢサーバ５へアクセスすることができ、電子商取引サービスの提供を受けることができる。例えば、ユーザ端末９とＷＥＢサーバ５との間のインタフェースとしてＷＥＢシステムが利用される。
ネットワーク６及びシステム内ネットワーク７は、インターネット等の公衆ネットワークであってもよいし、LAN（Local Area Network）やWAN（Wide Area Network）等の社内
ネットワークであってもよい。本発明は、このようなネットワーク６及びシステム内ネットワーク７を限定するものではなく、ネットワーク６及びシステム内ネットワーク７上に規定されるプロトコル等を限定するものでもない。図１では、ネットワーク６とシステムネットワーク７とを区別したが、同一のネットワークであってもよい。
ネットワークであってもよい。本発明は、このようなネットワーク６及びシステム内ネットワーク７を限定するものではなく、ネットワーク６及びシステム内ネットワーク７上に規定されるプロトコル等を限定するものでもない。図１では、ネットワーク６とシステムネットワーク７とを区別したが、同一のネットワークであってもよい。
§２ 装置構成
以下、本システムを構成する各ノードの構成についてそれぞれ説明する。
以下、本システムを構成する各ノードの構成についてそれぞれ説明する。
§２−１ データサーバ１
図２は、本実施形態におけるデータサーバ１の構成を示す概念図である。
図２は、本実施形態におけるデータサーバ１の構成を示す概念図である。
データサーバ１は、ハードウェア構成として、図２に示されるように、バス１３で接続される、制御部１１、記憶部１２、通信部１４等既存のハードウェアを有する。記憶部１２は、例えばハードディスクであり、制御部１１で実行される処理で利用される各種情報を記憶する。制御部１１は、CPU（Central Processing Unit）等の１又は複数のプロセッサであり、このプロセッサの処理に利用される周辺回路（ROM（Read Only Memory）、RAM（Random Access Memory）、インタフェース回路等）を有する。通信部１４は、システム内ネットワーク７に接続され、ワークサーバ２とＷＥＢサーバ５等とIP（Internet Protocol）パケット等の送受信を行う。
データサーバ１は、PC（Personal Computer）等のような汎用コンピュータで構成され
てもよいし、ネットワーク接続ストレージ（NAS）のような専用コンピュータで構築され
てもよい。本発明は、データサーバ１のハードウェア構成を限定するものではない。
てもよいし、ネットワーク接続ストレージ（NAS）のような専用コンピュータで構築され
てもよい。本発明は、データサーバ１のハードウェア構成を限定するものではない。
図２では、データサーバ１は、電子商取引における情報の格納を行うために注文情報テーブル１６、割引ランクテーブル１７、商品情報テーブル１８を記憶部１２に有し、それらの情報を管理するための処理部としてデータ管理部１５を制御部１１に有している。
§２−１−１ 注文情報テーブル１６
注文情報テーブル１６には、ユーザの注文情報が格納される。以降、注文情報テーブル１６の行データのことを特に「注文情報」と表記する。図３は、本実施形態における注文情報テーブル１６である。本実施形態の注文情報テーブル１６は、注文ＩＤフィールド、商品ＩＤフィールド、ユーザＩＤフィールド、確定注文又はエントリー数フィールド、確定注文又はエントリー日時フィールド、レコメンド日時フィールド、状態フィールドを有する。
注文情報テーブル１６には、ユーザの注文情報が格納される。以降、注文情報テーブル１６の行データのことを特に「注文情報」と表記する。図３は、本実施形態における注文情報テーブル１６である。本実施形態の注文情報テーブル１６は、注文ＩＤフィールド、商品ＩＤフィールド、ユーザＩＤフィールド、確定注文又はエントリー数フィールド、確定注文又はエントリー日時フィールド、レコメンド日時フィールド、状態フィールドを有する。
注文ＩＤフィールドには、注文を識別するための識別子（注文ＩＤ）が格納される。商品ＩＤフィールドには、商品を識別するための識別子（商品ＩＤ）が格納される。ユーザＩＤフィールドには、注文を行ったユーザを識別するための識別子（ユーザＩＤ）が格納される。確定注文又はエントリー数フィールドには、ユーザが確定注文又はエントリーを行った商品の注文数の数値が格納される。
本実施形態では、商品の注文方法として、２つの注文方法が設けられている。１つは、「確定注文」であり、もう１つは「エントリー」である。「確定注文」とは、その商品を購入することを確定し、変更やキャンセル等できない状態になる注文方法である。「エントリー」とは、注文する意思を示すが注文を確定させていない状態になる注文方法である。
このエントリー状態では、ユーザは、商品の販売が終了するまで他の商品に乗り換えることができる。乗り換えとは、ある商品の注文をキャンセルし、別の商品を注文することである。以降、キャンセルした方の商品を「乗り換え前の商品」と、乗り換えた方の商品を「乗り換え先の商品」と表記する。
確定注文又はエントリー日時フィールドには、ユーザが確定注文又はエントリーを行った日時が格納される。レコメンド日時フィールドには、ワークサーバ２がユーザにレコメンドを行った日時が格納される。状態フィールドには、ユーザが行った注文が確定注文であるか又はエントリーであるかを示す識別子が格納される。
なお、図３には、各フィールドの具体的なデータが表現されているが、本発明はデータ表現を限定するものではない。注文情報テーブル１６の更新については、以下の§２−１−４で説明する。
§２−１−２ 割引ランクテーブル１７
割引ランクテーブル１７には、商品の割引情報が格納される。図４は、本実施形態における割引ランクテーブル１７である。本実施形態の割引ランクテーブル１７は、ランクフィールド、割引率フィールド、割引条件フィールドを有する。
ランクフィールドには、商品の割引のランクを示す識別子が格納される。割引率フィールドには、商品の割引のランクに応じた割引率が格納される。割引条件フィールドには、商品の割引のランクを定めるための条件が格納される。
割引ランクテーブル１７には、商品の割引情報が格納される。図４は、本実施形態における割引ランクテーブル１７である。本実施形態の割引ランクテーブル１７は、ランクフィールド、割引率フィールド、割引条件フィールドを有する。
ランクフィールドには、商品の割引のランクを示す識別子が格納される。割引率フィールドには、商品の割引のランクに応じた割引率が格納される。割引条件フィールドには、商品の割引のランクを定めるための条件が格納される。
なお、本発明は、割引ランクテーブル１７のデータ形式を限定するものではない。
§２−１−３ 商品情報テーブル１８
商品情報テーブル１８には、商品の商品情報が格納される。以降、商品情報テーブル１８の行データのことを特に「商品情報」と表記する。図５は、本実施形態における商品情報テーブル１８である。本実施形態の商品情報テーブル１８は、商品ＩＤフィールド、商品名フィールド、定価フィールド、賞味期限フィールド、販売期間フィールド、賞味期限の割引ランクフィールド、商品タグフィールド、販売数フィールド、現在の確定注文数フィールド、現在のエントリー数フィールド、確定注文可能数フィールド、エントリー可能数フィールド、残りの販売数フィールド、確定注文数による割引ランクフィールド、エントリー数を含む割引ランクフィールド、割引確定価格フィールド、割引見込み価格フィールド、最大割引価格フィールドを有する。
商品情報テーブル１８には、商品の商品情報が格納される。以降、商品情報テーブル１８の行データのことを特に「商品情報」と表記する。図５は、本実施形態における商品情報テーブル１８である。本実施形態の商品情報テーブル１８は、商品ＩＤフィールド、商品名フィールド、定価フィールド、賞味期限フィールド、販売期間フィールド、賞味期限の割引ランクフィールド、商品タグフィールド、販売数フィールド、現在の確定注文数フィールド、現在のエントリー数フィールド、確定注文可能数フィールド、エントリー可能数フィールド、残りの販売数フィールド、確定注文数による割引ランクフィールド、エントリー数を含む割引ランクフィールド、割引確定価格フィールド、割引見込み価格フィールド、最大割引価格フィールドを有する。
商品ＩＤフィールドには、注文情報テーブル１６の商品ＩＤフィールドと同様、商品ＩＤが格納される。商品名フィールドには、商品の名前が格納される。定価フィールドには、商品の定価が格納される。賞味期限フィールドには、商品の賞味期限が格納される。販売期間フィールドには、商品の販売数による販売終了条件の日時（販売終了日時）が格納される。
賞味期限の割引ランクフィールドには、商品の賞味期限による割引ランクが格納される。本実施形態では、商品の賞味期限による割引ランクは、販売期間フィールドに格納されている販売終了日時が割引ランクテーブル１７のどの割引ランクの割引条件を満たすか否かで決定されている。なお、本発明は賞味期限による割引ランクの定め方を限定するものではない。
商品タグフィールドには、その商品の類似商品・推奨商品を検索するためのデータ（以下、単に「商品タグ」と表記）が格納される。類似商品・推奨商品を検索するためのデータとは、例えば文字列データ等の検索キーワードである。図５では、商品Ａの類似商品・推奨商品を検索するためのデータとして、商品Ａのタグフィールドには「飲料、コーラ、炭酸」という３つの検索キーワードが格納されている。本実施形態では、この検索キーワードを使って、この検索キーワードと同一の検索キーワードをもつ他の商品が検索される。例えば、商品Ａの場合、商品Ｂと商品Ｃが類似商品・推奨商品に該当する。なお、本発明は商品の類似商品・推奨商品を検索するためのデータを限定するものではない。
販売数フィールドには、販売を予定している商品数量が格納される。現在の確定注文数フィールドには、商品の確定注文数が格納される。確定注文数とは、当該商品に対する確定注文による注文数の総量のことである。現在のエントリー数フィールドには、商品のエントリー数が格納される。エントリー数とは、当該商品に対するエントリーによる注文数の総量のことである。確定注文可能数フィールドには、ユーザが商品を確定注文することができる注文数の最大値が格納される。エントリー可能数フィールドには、ユーザが商品にエントリーすることができる注文数の最大値が格納される。残りの販売数フィールドには、ユーザが商品を注文することができる注文数の最大値が格納される。
これら確定注文可能数フィールド、エントリー可能数フィールド、残りの販売数フィールドは、販売数による販売終了条件やその他の条件によって格納される値が異なる。本実施形態では、販売数による販売終了条件は「確定注文数＋エントリー数＝販売数」とする。また、その他の条件は考慮しないことにする。その他の条件とは、例えば、販売数の８割については確定注文を可能とし、残り２割についてはエントリーの対象商品とする等である。これらを考慮すると、確定注文可能数フィールドには、「販売数−確定注文数」が入る。エントリー可能数フィールドには、「販売数−確定注文数−エントリー数」が入る。残りの販売数フィールドには、「販売数−確定注文数−エントリー数」が入る。なお、
販売数による販売終了条件は本実施形態以外にも考えることができる。その例は§４変形例で示す。
販売数による販売終了条件は本実施形態以外にも考えることができる。その例は§４変形例で示す。
確定注文数による割引ランクフィールドには、確定注文数が満たす割引ランクテーブル１７内の割引条件の割引ランクが格納される。
エントリー数を含む割引ランクフィールドには、確定注文数とエントリー数の合計が満たす割引ランクテーブル１７内の割引条件の割引ランクが格納される。割引確定価格フィールドには、確定した割引価格（以降、「割引確定価格」と表記）が格納される。確定した割引価格とは、購入総量が現在の確定注文数である場合の商品価格である。本実施形態において、割引確定価格は「定価×（１−賞味期限の割引ランクの割引率−確定注文数による割引ランクの割引率）」で計算される。図５において、例えば、商品Ｂの割引確定価格は、「２００×（１−０．３−０．２）＝１００」として計算されている。なお、本発明は割引確定価格の計算方法を限定するものではない。その他、どのような計算方法を用いてもよい。
割引見込み価格フィールドには、エントリー数を含んだ場合の割引価格（以降、「割引見込み価格」と表記）が格納される。割引見込み価格とは、購入総量が確定注文数とエントリー数の合計である場合の商品価格である。割引見込み価格の計算については、割引確定価格と同様である。割引見込み価格は、割引確定価格を求める計算式内の「確定注文数による割引ランクの割引率」を「エントリー数を含む割引ランクの割引率」に置き換えた計算式によって計算される。
最大割引価格フィールドには、その商品の最大割引価格が格納される。つまり、購入総量が販売数である場合の商品価格が格納される。
§２−１−４ 各テーブルの更新について
本実施形態において、ユーザがＷＥＢページ上で商品を確定注文した時、商品にエントリーした時、商品にエントリーした状態から他の商品に乗り換えを行った時、商品にエントリーした状態から確定注文に切り換えた時、注文情報テーブル１６と商品情報テーブル１８は、データ管理部１５によって更新される。
本実施形態において、ユーザがＷＥＢページ上で商品を確定注文した時、商品にエントリーした時、商品にエントリーした状態から他の商品に乗り換えを行った時、商品にエントリーした状態から確定注文に切り換えた時、注文情報テーブル１６と商品情報テーブル１８は、データ管理部１５によって更新される。
本実施形態において、ユーザがＷＥＢページ上で上記注文を行うと、ワークサーバ２からデータサーバ１に注文情報テーブル１６と商品情報テーブル１８を更新するためのデータ（以降、「更新用データ」と表記）が送信される。更新用データは、ユーザが注文した商品の商品ＩＤ、ユーザＩＤ、注文数、注文の日時等が含まれている。データ管理部１５は、更新用データに基づいて注文情報テーブル１６と商品情報テーブル１８の更新を行う。
（１）注文情報テーブル１６の更新
データ管理部１５は、注文情報テーブル１６の更新を行う。ユーザが商品を確定注文又はエントリーした時、データ管理部１５は、新たな注文情報を生成する。新たな注文情報は、更新用データに含まれる商品ＩＤ、ユーザＩＤ、注文数、注文の日時等によって生成される。ユーザが商品の乗り換え又は注文の切り替えを行った時、データ管理部１５は、その注文の注文情報により元の注文情報を更新する。この場合、データ管理部１５は、更新用データに含まれている注文ＩＤを用いて、注文情報テーブル１６を検索し、該当する注文情報を更新用データに含まれる商品ＩＤ、注文の日時等によって更新する。
データ管理部１５は、注文情報テーブル１６の更新を行う。ユーザが商品を確定注文又はエントリーした時、データ管理部１５は、新たな注文情報を生成する。新たな注文情報は、更新用データに含まれる商品ＩＤ、ユーザＩＤ、注文数、注文の日時等によって生成される。ユーザが商品の乗り換え又は注文の切り替えを行った時、データ管理部１５は、その注文の注文情報により元の注文情報を更新する。この場合、データ管理部１５は、更新用データに含まれている注文ＩＤを用いて、注文情報テーブル１６を検索し、該当する注文情報を更新用データに含まれる商品ＩＤ、注文の日時等によって更新する。
（２）商品情報テーブル１８の更新
データ管理部１５は、注文情報テーブル１６を更新した場合には、商品情報テーブル１
８の更新を行う。データ管理部１５は、更新用データに含まれる商品ＩＤを用いて、商品情報テーブル１８を検索し、該当する商品情報を更新用データに含まれる注文数等によって更新する。以下、ユーザが商品を確定注文した場合を例示する。
データ管理部１５は、注文情報テーブル１６を更新した場合には、商品情報テーブル１
８の更新を行う。データ管理部１５は、更新用データに含まれる商品ＩＤを用いて、商品情報テーブル１８を検索し、該当する商品情報を更新用データに含まれる注文数等によって更新する。以下、ユーザが商品を確定注文した場合を例示する。
ユーザが商品を確定注文した場合、データ管理部１５は、該当する商品の商品情報内の現在の確定注文数に、更新用データに含まれる注文数を加算して、上書きする。データ管理部１５は、該当する商品の商品情報内の確定注文可能数から、更新用データに含まれる注文数を減算して、上書きする。データ管理部１５は、同様の減算処理を該当する商品の商品情報内のエントリー可能数、残りの販売数についても行う。
これらの更新後、確定注文数が更新されたので、データ管理部１５は、該当する商品の商品情報内の確定注文数による割引ランク、エントリー数を含む割引ランクの更新を行う。この更新は、割引ランクテーブル１７を用いて行われる。また、該当する商品の商品情報内の確定注文数による割引ランク、エントリー数を含む割引ランクのどちらか一方でも更新された場合、データ管理部１５は、割引確定価格、割引見込み価格の更新を行う。割引確定価格、割引見込み価格は§２−１−３で説明したとおりである。データ管理部１５は、これらの計算を行い、上書きする。
上述のような更新処理の後、データ管理部１５は、更新後の商品情報及び更新後の注文情報を含む更新結果（以降、「更新結果データ」と表記）をワークサーバ２に返信する。
ユーザがエントリーによる注文を行った場合等も、上記確定注文した場合と同様に商品情報テーブル１８の更新が行われる。
§２−１−５ 時間経過監視時について
本実施形態において、一定期間が経過すると、ワークサーバ２からデータサーバ１へ、データ送信時の日時を含むデータ（以下、「時間監視データ」と表記）が送信される。詳細は§２−３−３で説明する。
本実施形態において、一定期間が経過すると、ワークサーバ２からデータサーバ１へ、データ送信時の日時を含むデータ（以下、「時間監視データ」と表記）が送信される。詳細は§２−３−３で説明する。
データサーバ１が時間監視データを受信すると、データ管理部１５は、販売期間の過ぎた商品情報及びその商品を対象とした注文情報の収集と、販売期間の過ぎていない商品を対象とした注文情報の中でレコメンドを行う対象の注文情報の収集を行う。
まず、データ管理部１５は、販売期間の過ぎた商品情報及びその商品を対象とした注文情報の収集を行う。具体的には、データ管理部１５は、商品情報テーブル１８から、時間監視データ内のデータ送信時の日時より小さい販売期間を有する商品情報を収集し、収集した商品情報を商品情報テーブル１８から削除する。
更に、データ管理部１５は、注文情報テーブル１６から、販売期間を過ぎた商品の商品情報内の商品ＩＤと同一の商品ＩＤを持つ注文情報（以降、「販売期間を過ぎた商品の注文情報」と表記）を収集する。データ管理部１５は、収集した注文情報を注文情報テーブル１６から削除する。なお、販売期間を過ぎた商品の商品情報及び販売期間を過ぎた商品の注文情報は販売中の商品情報及び注文情報と区別できればよいため、削除しなくてもよいが、本実施形態においては削除することにする。
次に、データ管理部１５は、販売期間の過ぎていない商品を対象とした注文情報の中でレコメンドを行う対象の注文情報の収集を行う。具体的には、データ管理部１５は、注文情報テーブル１６から状態フィールドに「エントリー」が格納されている注文情報のうちでレコメンド日時がデータ送信時の日時よりも所定期間以上前となっている注文情報（以降、「レコメンド対象の注文の注文情報」）を収集する。例えば、データ管理部１５は、
レコメンド日時が送信時の日時よりも１日以前である注文情報を収集する。以下、§３−２において、上記所定期間は１日であるとして説明するが、本発明はこの上記所定期間を限定するものではない。この所定期間は、ユーザによって定められてもよい。
レコメンド日時が送信時の日時よりも１日以前である注文情報を収集する。以下、§３−２において、上記所定期間は１日であるとして説明するが、本発明はこの上記所定期間を限定するものではない。この所定期間は、ユーザによって定められてもよい。
更に、データ管理部１５は、商品情報テーブル１８から、レコメンド対象の注文情報内の商品ＩＤと同一の商品ＩＤを持つ商品情報（以降、「レコメンド対象の注文の商品情報」と表記）を収集する。
その後、データ管理部１５は、収集した注文情報と収集した商品情報を含むデータ（以下、「時間監視検索データ」と表記）を返信する。そして、データ管理部１５は、レコメンド対象の注文の注文情報のレコメンド日時をデータ送信時の日時に上書きして、注文情報テーブル１６を更新する。
§２−１−６ ユーザの注文による販売終了時
本実施形態において、ユーザの注文により商品の販売が終了すると、ワークサーバ２からデータサーバ１へ、販売終了処理のためのデータ（以降、「販売終了用データ」と表記する）が送信される。詳細は、§２−３−２（２）で説明する。
本実施形態において、ユーザの注文により商品の販売が終了すると、ワークサーバ２からデータサーバ１へ、販売終了処理のためのデータ（以降、「販売終了用データ」と表記する）が送信される。詳細は、§２−３−２（２）で説明する。
販売終了用データには、販売が終了した商品の商品情報が含まれている。データサーバ１は、販売が終了した商品の商品情報及び販売が終了した商品に対する注文情報を検索し、検索結果をワークサーバ２へ返信した後に削除する。なお、販売が終了した商品の商品情報及び販売が終了した商品に対する注文情報は、販売中の商品情報及び注文情報と区別できればよいため、削除しなくてもよいが、本実施形態においては削除することにする。
まず、データ管理部１５は、商品情報テーブル１８から、販売終了用データ内の販売が終了した商品の商品ＩＤと同一の商品ＩＤを持つ商品情報を収集し、収集した商品情報を商品情報テーブル１８から削除する。
次に、データ管理部１５は、注文情報テーブル１６から、販売が終了した商品の商品ＩＤと同一の商品ＩＤを持つ注文情報を収集し、収集した注文情報を注文情報テーブル１６から削除する。この際、状態フィールドに格納されている識別子は考慮しない。
そして、データ管理部１５は、販売が終了した商品の商品情報と、販売が終了した商品の商品ＩＤと同一の商品ＩＤを持つ注文情報を含む処理結果をワークサーバ２へ返信する。
§２−１−７ その他
本実施形態において、データサーバ１の記憶部１２に格納されている注文情報テーブル１６、割引ランクテーブル１７、商品情報テーブル１８はテーブルの形式で表現されているが、本発明は情報の実現形式を限定するものではない。たとえば、XML（eXtensible Markup Language）で実現されていても良いし、SQL（Structured Query Language）で実現
されていても良い。
本実施形態において、データサーバ１の記憶部１２に格納されている注文情報テーブル１６、割引ランクテーブル１７、商品情報テーブル１８はテーブルの形式で表現されているが、本発明は情報の実現形式を限定するものではない。たとえば、XML（eXtensible Markup Language）で実現されていても良いし、SQL（Structured Query Language）で実現
されていても良い。
また、本実施形態において、データサーバ１の記憶部１２に格納されている注文情報テーブル１６、割引ランクテーブル１７、商品情報テーブル１８は別々のテーブルとして説明したが、本発明はテーブル数を限定するものではない。一つのテーブルであってもよいし、複数のテーブルであってもよい。
また、本実施形態において、データ管理部１５が各フィールドの更新を行う際の処理を説明したが、本発明はデータの更新処理を限定するものではない。例えば、全てのフィー
ルドの値や識別子をメモリ上で計算・判定してから一度に更新してもよい。
ルドの値や識別子をメモリ上で計算・判定してから一度に更新してもよい。
また、本実施形態においては、データ管理部１５は注文情報テーブル１６を更新した後に商品情報テーブル１８を更新しているが、本発明はデータの更新順を限定するものではない。
§２−２ ＷＥＢサーバ５
図６は、本実施形態におけるＷＥＢサーバ５の構成を示す概念図である。
図６は、本実施形態におけるＷＥＢサーバ５の構成を示す概念図である。
ＷＥＢサーバ５は、ハードウェア構成として、図６に示されるように、バス５３で接続される、制御部５１、記憶部５２、通信部５４等既存のハードウェアを有する。なお、本発明は、ＷＥＢサーバ５のハードウェア構成を限定するものではない。
本実施形態における電子商取引は、ＷＥＢサーバ５から送られてくるＷＥＢページをユーザがユーザ端末９上で操作することによって行われる。ＷＥＢページは例えばHTML（HyperText Markup Language）文書等であり、ユーザがユーザ端末９上で行える操作はキー
ボードによる文字入力や、マウスによるクリック操作等である。
ボードによる文字入力や、マウスによるクリック操作等である。
ユーザがＷＥＢページ上で行うことのできる操作は、商品を検索すること（商品検索操作）、商品を確定注文すること（確定注文操作）、商品にエントリーすること（エントリー操作）、ある商品にエントリーしている時に他の商品に乗り換えを行うこと（商品乗り換え操作）、ある商品にエントリーしている時に注文を確定注文に切り換えを行うこと（注文切り換え操作）等である。
ＷＥＢサーバ５は、ユーザのＷＥＢページ上での操作の情報（以降、単に「ユーザの操作情報」と表記する）を受け取って、そのユーザの操作情報に基づくリクエスト情報を後述のワークサーバ２へ送信する。図６では、ＷＥＢサーバ５をユーザ端末９と本システムとの間のインタフェースとして動作させるための処理部として操作処理部５５、リクエスト制御部５６、ＷＥＢページ処理部５７が示されている。
§２−２−１ 操作処理部５５
操作処理部５５は、ユーザの操作情報の判定を行う。電子商取引は、ユーザがＷＥＢページをユーザ端末９上で商品検索操作等の操作をすることによって行われるが、実際の操作は、例えば、マウスによるクリック操作やキーボードによる文字入力等である。これらの操作からユーザの操作情報は何であるかの判定を操作処理部５５は行う。
操作処理部５５は、ユーザの操作情報の判定を行う。電子商取引は、ユーザがＷＥＢページをユーザ端末９上で商品検索操作等の操作をすることによって行われるが、実際の操作は、例えば、マウスによるクリック操作やキーボードによる文字入力等である。これらの操作からユーザの操作情報は何であるかの判定を操作処理部５５は行う。
§２−２−２ リクエスト制御部５６
リクエスト制御部５６は、操作処理部５５の判定により明らかとなったユーザの操作情報に基づいてリクエスト情報を生成し、電子商取引の処理を行う後述のワークサーバ２へそのリクエスト情報を送信する。リクエスト情報は以下に示されるデータである。
リクエスト制御部５６は、操作処理部５５の判定により明らかとなったユーザの操作情報に基づいてリクエスト情報を生成し、電子商取引の処理を行う後述のワークサーバ２へそのリクエスト情報を送信する。リクエスト情報は以下に示されるデータである。
ユーザの操作情報が商品検索操作による情報であるならば、リクエスト情報はユーザが入力した商品の検索条件を含むデータである。ユーザが入力した商品の検索条件とは、例えば商品名等の文字列データである。
ユーザの操作情報が確定注文操作による情報であるならば、リクエスト情報は、ユーザ端末９でＷＥＢページを操作しているユーザのユーザＩＤ、ユーザがＷＥＢページ上で商品を確定注文した日時、ユーザが確定注文した商品の商品情報及び確定注文した注文数を含むデータである。
ユーザの操作情報がエントリー操作による情報であるならば、リクエスト情報は、ユーザ端末９でＷＥＢページを操作しているユーザのユーザＩＤ、ユーザがＷＥＢページ上で商品にエントリーした日時、ユーザがエントリーした商品の商品情報及びエントリーした注文数を含むデータである。
ユーザの操作情報が商品乗り換え操作による情報であるならば、リクエスト情報は、ユーザ端末９でＷＥＢページを操作しているユーザのユーザＩＤ、ユーザがＷＥＢページ上で商品の乗り換えをした日時、乗り換え前の商品情報と乗り換え先の商品情報、乗り換え前の商品に対するユーザの注文情報及び乗り換え先の商品の注文数を含むデータである。
ユーザの操作情報が注文切り換え操作による情報であるならば、リクエスト情報は、ユーザ端末９でＷＥＢページを操作しているユーザのユーザＩＤ及びユーザがエントリーから確定注文に切り換えた商品の商品情報と注文情報を含むデータである。
§２−２−３ ＷＥＢページ処理部５７
ＷＥＢページ処理部５７は、ユーザの操作情報、ワークサーバ２から返信されるＷＥＢサーバ５のリクエストに対する結果（以降、「リクエスト結果情報」と表記）、記憶部５２に格納されているＷＥＢページデータ５８等を基にして、ユーザ端末９に表示するためのＷＥＢページを生成し、ユーザ端末９に送信する。生成されるＷＥＢページは、商品の検索結果を表示するＷＥＢページ（商品検索結果ページ）、商品の情報を表示するＷＥＢページ（商品詳細ページ）、注文が完了したことを表示するＷＥＢページ（注文完了ページ）である。
ＷＥＢページ処理部５７は、ユーザの操作情報、ワークサーバ２から返信されるＷＥＢサーバ５のリクエストに対する結果（以降、「リクエスト結果情報」と表記）、記憶部５２に格納されているＷＥＢページデータ５８等を基にして、ユーザ端末９に表示するためのＷＥＢページを生成し、ユーザ端末９に送信する。生成されるＷＥＢページは、商品の検索結果を表示するＷＥＢページ（商品検索結果ページ）、商品の情報を表示するＷＥＢページ（商品詳細ページ）、注文が完了したことを表示するＷＥＢページ（注文完了ページ）である。
なお、以下のＷＥＢページは、本実施形態におけるＷＥＢページ処理部５７が生成するＷＥＢページであり、本発明のＷＥＢページのデザインを限定するものではない。例えば、フレーム等の画面効果を用いたＷＥＢページであってもよい。
（１） 商品検索結果ページ
図７は、本実施形態における商品検索結果ページである。商品検索結果ページは、ユーザが商品検索操作を行った時にユーザ端末９上に表示されるＷＥＢページである。
図７は、本実施形態における商品検索結果ページである。商品検索結果ページは、ユーザが商品検索操作を行った時にユーザ端末９上に表示されるＷＥＢページである。
ＷＥＢページ処理部５７は、ワークサーバ２から受け取ったリクエスト結果情報を基に、ＷＥＢページを作成する。リクエスト結果情報には、それぞれ該当する商品情報がデータサーバ１に存在すれば、ユーザが入力した商品の検索条件に合致する商品名の商品情報及び、類似商品・推奨商品の商品情報が含まれている。ＷＥＢページ処理部５７は、それぞれの商品情報を記載したＷＥＢページを作成する。
ＷＥＢページ処理部５７は、ＷＥＢページデータ５８を利用して、それぞれのデータを埋め込むことでＷＥＢページを生成してもよい。ＷＥＢページデータ５８は、例えば、CGI（Common Gateway Interface）、ＪＡＶＡＳＣＲＩＰＴ（登録商標）を含むHTML文書、
スタイルシートなど周知技術のデータである。生成された商品検索結果ページは、ＷＥＢページ処理部５７からユーザ端末９に送信され、ユーザ端末９に表示される。
スタイルシートなど周知技術のデータである。生成された商品検索結果ページは、ＷＥＢページ処理部５７からユーザ端末９に送信され、ユーザ端末９に表示される。
図７では、商品検索操作を行う部分（１３１）において、ユーザは商品Ａを商品の検索条件として入力し、商品検索操作を行っている。また、ユーザの商品検索操作の結果、商品の検索条件に該当する商品Ａの商品情報が表示されている（１３２）。そして、商品Ａの類似商品・推奨商品である商品Ｂと商品Ｃの商品情報も表示されている（１３３）（図５も合わせて参照）。
データサーバ１に該当商品の商品情報がない場合については不図示だが、商品の検索条
件に該当する商品情報を表示する部分（１３２）や検索条件に該当する商品の類似商品・推奨商品の商品情報を表示する部分（１３３）に、“該当商品なし”などと表示される。
件に該当する商品情報を表示する部分（１３２）や検索条件に該当する商品の類似商品・推奨商品の商品情報を表示する部分（１３３）に、“該当商品なし”などと表示される。
（２） 商品詳細ページ
図８は、本実施形態における商品Ａの商品詳細ページである。商品詳細ページは、ユーザが確定注文操作やエントリー操作を行うためのＷＥＢページである。図７において、商品の検索条件に該当する商品情報を表示する部分（１３２）内や検索条件に該当する商品の類似商品・推奨商品の商品情報を表示する部分（１３３）内にある「商品詳細ページへ」を、ユーザ端末９上でクリック操作等をユーザが行うことで、ＷＥＢページ処理部５７は、商品詳細ページを生成する。
図８は、本実施形態における商品Ａの商品詳細ページである。商品詳細ページは、ユーザが確定注文操作やエントリー操作を行うためのＷＥＢページである。図７において、商品の検索条件に該当する商品情報を表示する部分（１３２）内や検索条件に該当する商品の類似商品・推奨商品の商品情報を表示する部分（１３３）内にある「商品詳細ページへ」を、ユーザ端末９上でクリック操作等をユーザが行うことで、ＷＥＢページ処理部５７は、商品詳細ページを生成する。
生成される商品詳細ページは、§２−２−３（１）で説明したワークサーバ２からのリクエスト結果情報を基にして生成される。リクエスト結果情報には、ユーザが入力した商品の検索条件に合致する商品名の商品情報及び、類似商品・推奨商品の商品情報が含まれている。
なお、ユーザは、商品検索結果ページから商品詳細ページにアクセスしているが、URL
（Uniform Resource Locator）を指定する等して商品詳細ページに直接アクセスしてもよい。また、ＷＥＢページ処理部５７が生成した商品詳細ページを記憶部５２に格納しておき、ユーザ端末９からのアクセスに応じて、ＷＥＢページ処理部５７は記憶部５２に格納している商品詳細ページをユーザ端末９へ送信してもよい。
（Uniform Resource Locator）を指定する等して商品詳細ページに直接アクセスしてもよい。また、ＷＥＢページ処理部５７が生成した商品詳細ページを記憶部５２に格納しておき、ユーザ端末９からのアクセスに応じて、ＷＥＢページ処理部５７は記憶部５２に格納している商品詳細ページをユーザ端末９へ送信してもよい。
本実施形態において、商品詳細ページは、当該商品の商品情報を表示する部分（１４１）、当該商品に対してユーザが確定注文操作又はエントリー操作を行う部分（１４２）、ユーザが類似商品・推奨商品を並び替える操作を行う部分（１４３）、当該商品の類似商品・推奨商品の商品情報を表示する表示する部分（１４４）を有する。
当該商品の商品情報を表示する部分（１４１）には、「エントリー期間」「現在の購入確定数」「現在のエントリー数」「現在の割引確定価格」「現在の割引見込み価格」「最大割引価格」が表示される。「エントリー期間」は、商品情報内の販売期間であり、その商品の販売終了日時を示す。「現在の購入確定数」は、商品情報内の現在の確定注文数であり、その商品の確定注文されている注文数を示す。「現在のエントリー数」は、商品情報内の現在のエントリー数であり、その商品のエントリーされている注文数を示す。「現在の割引確定価格」は、商品情報内の割引確定価格であり、その商品の購入総量が現在の購入確定数であった場合の商品価格を示す。「現在の割引見込み価格」は、商品情報内の割引見込み価格であり、その商品の購入総量が現在の購入確定数と現在のエントリー数との合計であった場合の商品価格を示す。「最大割引価格」は、商品情報内の最大割引価格であり、その商品の購入総量が予定販売数である場合の商品価格を示す。
当該商品に対してユーザが確定注文操作又はエントリー操作を行う部分（１４２）は、ユーザがエントリー又は確定注文を行うための操作部分である。本実施形態では、注文数を記入する欄と、「確定注文」ボタン及び「エントリー」ボタンがある。
ユーザがユーザ端末９を操作し、記入欄に注文数を入力した上で、「確定注文」ボタンを押すと、操作処理部５５はユーザの操作情報が確定注文操作による情報であると判定する。その判定に従って、リクエスト制御部５６は、当該商品の商品情報を表示する部分（１４１）に表示している商品情報、記入欄に入力した値から上述したリクエスト情報を生成する。ここで、ユーザが記入欄に入力した値が、当該商品の商品情報を表示する部分（１４１）に表示している商品情報の残りの販売数を超えている場合、リクエスト制御部５６は、リクエスト情報を生成せず、ＷＥＢページ処理部５７にエラーを送る。エラー処理
については、周知の技術である。
については、周知の技術である。
また、ユーザがユーザ端末９を操作し、記入欄に注文数を入力した上で、「エントリー」ボタンを押すと、操作処理部５５はユーザの操作情報がエントリー操作による情報であると判定する。その判定に従って、リクエスト制御部５６は、当該商品の商品情報を表示する部分（１４１）に表示している商品情報、記入欄に入力した値からリクエスト情報を生成する。ここで、ユーザが記入欄に入力した値が、当該商品の商品情報を表示する部分（１４１）に表示している商品情報内の残りの販売数を超えている場合は、上記と同様、リクエスト制御部５６は、エラー処理を行う。
当該商品に対してユーザが確定注文操作又はエントリー操作を行う部分（１４２）は他の形態であってもよい。例えば、HTMLのチェックボックスやセレクト部品のようなフォーム形式が考えられる。
ユーザが類似商品・推奨商品を並び替える操作を行う部分（１４３）は、当該商品の類似商品・推奨商品の商品情報を表示する表示する部分（１４４）に表示されている当該商品の類似商品・推奨商品を、ユーザ操作によって並び替えるための操作部分である。この機能はＷＥＢサーバ５の機能として周知の機能である。
当該商品の類似商品・推奨商品の商品情報を表示する表示する部分（１４４）には、当該商品詳細ページの商品に関する類似商品・推奨商品が表示される。各部分の値は、当該商品の商品情報を表示する部分（１４１）で説明したものと同様である。
（３） 注文完了ページ
注文完了ページは、ユーザが確定注文操作、エントリー操作、商品乗り換え操作、注文切り換え操作を行った際、その際に必要な本システムの処理が完了したことを表示するＷＥＢページである。
注文完了ページは、ユーザが確定注文操作、エントリー操作、商品乗り換え操作、注文切り換え操作を行った際、その際に必要な本システムの処理が完了したことを表示するＷＥＢページである。
注文完了ページには、次の３つの種類がある。１つ目は、ユーザが商品を確定注文した際の本システムの処理が完了したことを表示するＷＥＢページ（以降、単に「確定注文完了ページ」と表記）である。２つ目は、ユーザが商品にエントリーした際の本システムの処理が完了したことを表示するＷＥＢページ（以降、単に「エントリー完了ページ」と表記）である。３つ目は、ユーザが商品を確定注文又は商品にエントリーした際に本システムの処理が完了した結果、その商品が販売終了になったことを表示するＷＥＢページ（以降、単に「販売終了ページ」と表記）である。
（３−１）確定注文完了ページ
図９は、本実施形態における商品Ａの確定注文完了ページである。確定注文完了ページは、ユーザが確定注文操作を行った時、乗り換え先の商品を確定注文した商品乗り換え操作を行った時、注文切り換え操作を行った時にＷＥＢページ処理部５７によって生成される。以下、ユーザが確定注文操作を行った場合を例にして、ＷＥＢページ処理部５７の処理を説明する。
図９は、本実施形態における商品Ａの確定注文完了ページである。確定注文完了ページは、ユーザが確定注文操作を行った時、乗り換え先の商品を確定注文した商品乗り換え操作を行った時、注文切り換え操作を行った時にＷＥＢページ処理部５７によって生成される。以下、ユーザが確定注文操作を行った場合を例にして、ＷＥＢページ処理部５７の処理を説明する。
ユーザはユーザ端末９に表示される商品詳細ページ（図８）上で確定注文操作を行う。ユーザが確定注文操作を行うと、ＷＥＢサーバ５からワークサーバ２へリクエスト情報が送信される。ＷＥＢサーバ５は、ワークサーバ２からリクエスト結果情報を受信する。ＷＥＢページ処理部５７は、このリクエスト結果情報に基づいて確定注文完了ページを生成する。リクエスト結果情報には、ユーザが確定注文した商品の更新後の商品情報が含まれており、ＷＥＢページ処理部５７は、この商品情報と、ユーザが商品を確定注文した注文数を用いて確定注文完了ページを生成する。
ＷＥＢページ処理部５７は、図９の確定注文完了ページを生成する。図９の確定注文完了ページには、ユーザが確定注文した商品の更新後の商品情報と、ユーザが商品を確定注文した注文数が表示されている。ユーザが乗り換え先の商品を確定注文した商品乗り換え操作を行った時、注文切り換え操作を行った時も同様にして、確定注文完了ページが生成される。
（３−２）エントリー完了ページ
図１０は、本実施形態における商品Ａのエントリー完了ページである。エントリー完了ページは、ユーザがエントリー操作を行った時、乗り換え先の商品にエントリーした商品乗り換え操作を行った時にＷＥＢページ処理部５７によって生成される。以下、ユーザがエントリー操作を行った場合を例にして、ＷＥＢページ処理部５７の処理を説明する。
図１０は、本実施形態における商品Ａのエントリー完了ページである。エントリー完了ページは、ユーザがエントリー操作を行った時、乗り換え先の商品にエントリーした商品乗り換え操作を行った時にＷＥＢページ処理部５７によって生成される。以下、ユーザがエントリー操作を行った場合を例にして、ＷＥＢページ処理部５７の処理を説明する。
ユーザはユーザ端末９に表示される商品詳細ページ（図８）上でエントリー操作を行う。ユーザがエントリー操作を行うと、ＷＥＢサーバ５からワークサーバ２へリクエスト情報が送信される。その後、ＷＥＢサーバ５は、ワークサーバ２からリクエスト結果情報を受信する。ＷＥＢページ処理部５７は、このリクエスト結果情報に基づいてエントリー完了ページを生成する。リクエスト結果情報には、ユーザがエントリーした商品の更新後の商品情報が含まれており、ＷＥＢページ処理部５７は、この商品情報と、ユーザが商品をエントリーした注文数を用いてエントリー完了ページを生成する。
ＷＥＢページ処理部５７は、図１０のエントリー完了ページを生成する。図１０のエントリー完了ページには、ユーザがエントリーした商品の更新後の商品情報と、ユーザが商品を確定注文した注文数が表示されている。ユーザが乗り換え先の商品をエントリーした商品乗り換え操作を行った時、注文切り換え操作を行った時も同様にして、エントリー完了ページが生成される。
図１０のエントリー完了ページには、その他に、当該商品に対してユーザが注文切り換え操作を行う部分（１５１）、当該商品に対してユーザが商品乗り換え操作を行う部分（１５２、１５３）が表示されている。
ユーザは、エントリー完了ページ上の当該商品に対してユーザが注文切り換え操作を行う部分（１５１）の「注文を確定する」ボタンをマウスによるクリック操作等の操作を行うことで、注文切り換え操作を行うことができる。なお、注文切り換え操作を行う際に注文数を変更できるようにしてもよい。
また、本実施形態において、ユーザはエントリー完了ページ上の当該商品に対してユーザが商品乗り換え操作を行う部分（１５２、１５３）を操作することで商品乗り換え操作を行うことができる。ユーザは、「この商品に乗り換える」ボタン（１５２）をマウスによるクリック操作等の操作を行う。そして、ユーザは、その操作により表示された乗り換え先の商品の注文数と注文方法をユーザに操作させる部分（１５３）の記入欄に値を記入し、「確定注文」ボタン又は「エントリー」ボタンをマウスによるクリック操作等の操作を行うことで、商品乗り換え操作を行うことができる。
（３−３）販売終了ページ
図１１は、本実施形態における商品Ａの販売終了ページである。販売終了ページは、ユーザが確定注文操作、エントリー操作、商品乗り換え操作を行った際に必要な本システムの処理が完了した結果、ユーザが確定注文又はエントリーした商品が販売終了となったことを表示するＷＥＢページである。以下、ユーザが確定注文操作を行った場合を例にして、ＷＥＢページ処理部５７の処理を説明する。
図１１は、本実施形態における商品Ａの販売終了ページである。販売終了ページは、ユーザが確定注文操作、エントリー操作、商品乗り換え操作を行った際に必要な本システムの処理が完了した結果、ユーザが確定注文又はエントリーした商品が販売終了となったことを表示するＷＥＢページである。以下、ユーザが確定注文操作を行った場合を例にして、ＷＥＢページ処理部５７の処理を説明する。
ユーザが確定注文操作を行った際、ＷＥＢサーバ５はワークサーバ２へリクエスト情報を送信する。その後、ＷＥＢサーバ５は、ワークサーバ２からリクエスト結果情報を受信する。ＷＥＢページ処理部５７は、ユーザの注文した商品が販売終了となったとワークサーバ２が判定した場合、このリクエスト結果情報に基づいて販売終了ページを生成する。リクエスト結果情報には、ユーザが確定注文した商品の更新後の商品情報が含まれており、ＷＥＢページ処理部５７は、この商品情報と、ユーザが商品を確定注文した注文数を用いて販売終了ページを生成する。
以上の処理の結果、図１１の販売終了ページが生成される。図１１の販売終了ページには、ユーザが確定注文した商品の更新後の商品情報と、ユーザが商品を確定注文した注文数表示されている。ユーザがその他の操作を行った時も同様にして、販売終了ページが生成される。
§２−３ ワークサーバ２
図１２は、本実施形態におけるワークサーバ２の構成を示す概念図である。
図１２は、本実施形態におけるワークサーバ２の構成を示す概念図である。
ワークサーバ２は、ハードウェア構成として、図３に示されるように、バス２３で接続される、制御部２１、記憶部２２、通信部２４等既存のハードウェアを有する。なお、本発明は、ワークサーバ２のハードウェア構成を限定するものではない。
ワークサーバ２は、記憶部２２に格納されるOS等のプログラムが制御部２１において実行されることにより、電子商取引における情報の処理を行うワークサーバとして動作する。図１２では、ワークサーバ２をワークサーバとして動作させるための処理部としてリクエスト振分部２５、リクエスト処理部２６、時間経過監視部２７、レコメンド処理部２８が示されている。
§２−３−１ リクエスト振分部２５
リクエスト振分部２５は、ＷＥＢサーバ５から送信されてくるリクエスト情報をユーザの操作情報に応じてリクエスト処理部２６内の各処理部に振り分ける。
リクエスト振分部２５は、ＷＥＢサーバ５から送信されてくるリクエスト情報をユーザの操作情報に応じてリクエスト処理部２６内の各処理部に振り分ける。
§２−３−２ リクエスト処理部２６
リクエスト処理部２６は、ＷＥＢサーバ５から送信されてくるリクエスト情報の処理を行うため、商品検索処理部３１、確定注文操作処理部３２、エントリー操作処理部３３、商品乗り換え操作処理部３４、注文切り換え操作処理部３５を有する。
リクエスト処理部２６は、ＷＥＢサーバ５から送信されてくるリクエスト情報の処理を行うため、商品検索処理部３１、確定注文操作処理部３２、エントリー操作処理部３３、商品乗り換え操作処理部３４、注文切り換え操作処理部３５を有する。
（１） 商品検索処理部３１
商品検索処理部３１は、ユーザの商品検索操作の処理を行う。検索処理自体は既存の技術を用いる。
商品検索処理部３１は、ユーザの商品検索操作の処理を行う。検索処理自体は既存の技術を用いる。
商品検索処理部３１は、ＷＥＢサーバ５からリクエスト情報が送信されてくると、ユーザが入力した商品の検索条件を含む商品検索用のデータを作成し、データサーバ１へ送信する。その後、ワークサーバ２は、上記商品検索用のデータの返信として、データサーバ１から検索結果を受信する。
検索結果にユーザが入力した商品の検索条件に合致する商品名の商品情報が含まれている場合、商品検索処理部３１は、更にその商品の類似商品・推奨商品の問い合わせをデータサーバ１に行う。具体的には、商品検索処理部３１は、検索結果に含まれている商品情報の商品タグを用い、類似商品・推奨商品検索用のデータを生成し、データサーバ１へ送信する。その後、ワークサーバ２は、上記類似商品・推奨商品検索用のデータの返信とし
て、データサーバ１から類似商品・推奨商品についての検索結果を受信する。
て、データサーバ１から類似商品・推奨商品についての検索結果を受信する。
そして、商品検索処理部３１は、それぞれ該当する商品の商品情報がデータサーバ１に存在すれば、ユーザが入力した商品の検索条件に合致する商品名の商品情報と類似商品・推奨商品の商品情報とを含むリクエスト結果情報を作成し、ＷＥＢサーバ５へ返信する。
（２） 確定注文操作処理部３２
確定注文操作処理部３２は、ユーザの確定注文操作の処理を行う。確定注文操作処理部３２は、理ウエスト振分部２５によって振り分けられたリクエスト情報から更新用データを作る。確定注文操作処理部３２に振り分けられるリクエスト情報には、ユーザ端末９でＷＥＢページを操作しているユーザのユーザＩＤ、ユーザがＷＥＢページ上で商品を確定注文した日時、ユーザが確定注文した商品の商品情報及び確定注文した注文数が含まれている。確定注文操作処理部３２は、このリクエスト情報から、更新用データを生成し、データサーバ１へ送信する。
確定注文操作処理部３２は、ユーザの確定注文操作の処理を行う。確定注文操作処理部３２は、理ウエスト振分部２５によって振り分けられたリクエスト情報から更新用データを作る。確定注文操作処理部３２に振り分けられるリクエスト情報には、ユーザ端末９でＷＥＢページを操作しているユーザのユーザＩＤ、ユーザがＷＥＢページ上で商品を確定注文した日時、ユーザが確定注文した商品の商品情報及び確定注文した注文数が含まれている。確定注文操作処理部３２は、このリクエスト情報から、更新用データを生成し、データサーバ１へ送信する。
ワークサーバ２は、データサーバ１での処理が完了すると、更新後の商品情報と、更新後の注文情報を含む更新結果データを受信する。確定注文操作処理部３２は、ユーザが確定注文した商品が販売終了したかどうかを判定するため、受信した更新結果データに含まれる更新後の商品情報内の残りの販売数が０か否か判定する。残りの販売数が０でなければ、確定注文操作処理部３２は、更新後の商品情報を含むリクエスト結果情報をＷＥＢサーバ５へ返信する。残りの販売数が０であれば、確定注文操作処理部３２は、ユーザが確定注文した商品の販売が終了したと判定した上で、更新後の商品情報を含むリクエスト結果情報をＷＥＢサーバ５へ返信する。
なお、残りの販売数が０であれば、当該商品の販売が終了しているため、確定注文操作処理部３２は、当該商品に対するエントリー注文及び確定注文に対して販売終了処理を行う。販売終了処理は、共同購入の注文を確定する処理であり、例えば、発注処理や決済処理等が含まれる。この販売終了処理を行う対象となる注文情報の検索は、データサーバ１に依頼される。すなわち、当該商品の販売が終了した時点において、当該商品に対するエントリーは、確定注文と同等に扱われる。
確定注文操作処理部３２は、販売終了処理として、当該商品の商品情報及び注文情報をデータサーバ１から検索および削除するため、データサーバ１に対して販売が終了した商品の商品情報を含む販売終了用データを送信する。販売終了用データに対する返信として、販売が終了した商品の商品情報と、販売が終了した商品の商品ＩＤと同一の商品ＩＤを持つ注文情報を含む処理結果がデータサーバ１からワークサーバ２へ返信される。確定注文操作処理部３２は、販売が終了した当該商品の発注処理、決済処理、当該商品の販売者等への通知処理等を行う。このような発注処理、決済処理等は周知の手法で行われればよい。
（３） エントリー操作処理部３３
エントリー操作処理部３３は、ユーザのエントリー操作の処理を行う。
エントリー操作処理部３３は、ユーザのエントリー操作の処理を行う。
エントリー操作処理部３３は、リクエスト振分部２５によって振り分けられたリクエスト情報から更新用データを作る。エントリー操作処理部３３に振り分けられるリクエスト情報には、ユーザ端末９でＷＥＢページを操作しているユーザのユーザＩＤ、ユーザがＷＥＢページ上で商品にエントリーした日時、ユーザがエントリーした商品の商品情報及びエントリーした注文数が含まれている。エントリー操作処理部３３は、このリクエスト情報から、更新用データを生成し、データサーバ１へ送信する。
ワークサーバ２は、データサーバ１での処理が完了すると、更新後の商品情報と、更新後の注文情報を含む更新結果データを受信する。エントリー操作処理部３３は、上記と同様に、更新結果データに含まれる更新後の商品情報内の残りの販売数が０か否か判定する。残りの販売数が０の場合、確定注文操作処理部３２と同様の処理が実行される。つまり、エントリー操作処理部３３は、ユーザがエントリーした商品は販売が終了したと判定した上で、当該商品の商品情報を含むリクエスト結果情報をＷＥＢサーバ５へ返信する。また、エントリー操作処理部３３は、販売が終了した商品に対して販売終了処理を行う。残りの販売数が０でなければ、エントリー操作処理部３３は、更新後の商品情報内の商品タグを利用して、類似商品・推奨商品検索用のデータを生成し、データサーバ１へ送信する。この処理については、商品検索処理部３１における類似商品・推奨商品の検索処理と同様である。
ワークサーバ２がデータサーバ１より類似商品・推奨商品の検索結果を受信すると、エントリー操作処理部３３はリクエスト結果情報をＷＥＢサーバ５へ返信する。リクエスト結果情報には、ユーザがエントリーした商品の更新後の商品情報及び注文情報と、類似商品・推奨商品の検索結果が含まれている。
（４） 商品乗り換え操作処理部３４
商品乗り換え操作処理部３４は、ユーザの商品乗り換え操作の処理を行う。商品乗り換え操作処理部３４は、リクエスト振分部２５によって振り分けられたリクエスト情報から更新用データを作る。商品乗り換え操作処理部３４に振り分けられたリクエスト情報には、ユーザ端末９でＷＥＢページを操作しているユーザのユーザＩＤ、ユーザがＷＥＢページ上で商品の乗り換えをした日時、乗り換え前の商品情報と乗り換え先の商品情報、乗り換え前の商品に対するユーザの注文情報及び乗り換え先の商品の注文数が含まれている。商品乗り換え操作処理部３４は、このリクエスト情報から、更新用データを生成し、データサーバ１へ送信する。
商品乗り換え操作処理部３４は、ユーザの商品乗り換え操作の処理を行う。商品乗り換え操作処理部３４は、リクエスト振分部２５によって振り分けられたリクエスト情報から更新用データを作る。商品乗り換え操作処理部３４に振り分けられたリクエスト情報には、ユーザ端末９でＷＥＢページを操作しているユーザのユーザＩＤ、ユーザがＷＥＢページ上で商品の乗り換えをした日時、乗り換え前の商品情報と乗り換え先の商品情報、乗り換え前の商品に対するユーザの注文情報及び乗り換え先の商品の注文数が含まれている。商品乗り換え操作処理部３４は、このリクエスト情報から、更新用データを生成し、データサーバ１へ送信する。
ワークサーバ２は、データサーバ１での処理が完了すると、更新後の商品情報と、更新後の注文情報を含む更新結果データを受信する。商品乗り換え操作処理部３４は、更新結果データ内の乗り換え後の商品についてのリクエスト結果情報をＷＥＢサーバ５へ返信する。この処理は、処理対象の商品情報が乗り換え先の商品の商品情報であるだけで、乗り換え先の注文の注文方法が確定注文であるならば、確定注文操作処理部３２の処理と、乗り換え先の注文の注文方法がエントリーであるならば、エントリー操作処理部３３と同様の処理である。
（５） 注文切り換え操作処理部３５
注文切り換え操作処理部３５は、ユーザの注文切り換え操作の処理を行う。注文切り換え操作処理部３５は、リクエスト振分部２５によって振り分けられたリクエスト情報から更新用データを作る。注文切り換え操作処理部３５に振り分けられたリクエスト情報には、ユーザ端末９でＷＥＢページを操作しているユーザのユーザＩＤ、ユーザがエントリーから確定注文に切り換えた商品の商品情報と注文情報、ユーザがエントリーから確定注文に切り換えた注文の注文数が含まれている。注文切り換え操作処理部３５は、このリクエスト情報から、更新用データを生成し、データサーバ１へ送信する。
注文切り換え操作処理部３５は、ユーザの注文切り換え操作の処理を行う。注文切り換え操作処理部３５は、リクエスト振分部２５によって振り分けられたリクエスト情報から更新用データを作る。注文切り換え操作処理部３５に振り分けられたリクエスト情報には、ユーザ端末９でＷＥＢページを操作しているユーザのユーザＩＤ、ユーザがエントリーから確定注文に切り換えた商品の商品情報と注文情報、ユーザがエントリーから確定注文に切り換えた注文の注文数が含まれている。注文切り換え操作処理部３５は、このリクエスト情報から、更新用データを生成し、データサーバ１へ送信する。
ワークサーバ２は、データサーバ１での処理が完了すると、更新後の商品情報と、更新後の注文情報を含む更新結果データを受信する。注文切り換え操作処理部３５は、更新結果データ内の更新後の商品情報についてのリクエスト結果情報をＷＥＢサーバ５へ返信する。この処理は、確定注文操作処理部３２の処理と同様である。
§２−３−３ 時間経過監視部２７
時間経過処理部２７は、データサーバ１において販売期間の過ぎた商品情報及びその商品を対象とした注文情報の収集と、販売期間の過ぎていない商品を対象とした注文情報の中でレコメンドを行う対象の注文情報の収集を行うために、時間監視データをデータサーバ１に送信する。時間経過監視部２７は、一定期間毎例えば１分おきに、データサーバ１に対して、データ送信時の日時を含む時間監視データを送信する。なお、以下、§３−２において、一定期間毎は１分おきであるとするが、本発明はこの一定期間を限定するものではない。
時間経過処理部２７は、データサーバ１において販売期間の過ぎた商品情報及びその商品を対象とした注文情報の収集と、販売期間の過ぎていない商品を対象とした注文情報の中でレコメンドを行う対象の注文情報の収集を行うために、時間監視データをデータサーバ１に送信する。時間経過監視部２７は、一定期間毎例えば１分おきに、データサーバ１に対して、データ送信時の日時を含む時間監視データを送信する。なお、以下、§３−２において、一定期間毎は１分おきであるとするが、本発明はこの一定期間を限定するものではない。
ワークサーバ２がデータサーバ１から時間監視検索データを受信すると、時間経過監視部２７は、時間監視検索データ内の販売期間を過ぎた商品の商品情報と販売期間を過ぎた商品の注文情報を当該商品の販売者等に通知する。この処理は、販売終了の処理として行われる処理で、§２−３−２（２）で説明した処理と同様である。
また、時間経過監視部２７は、時間監視検索データ内のレコメンド対象の注文の注文情報及びレコメンド対象の注文の注文情報に対応づけられたレコメンド対象の注文の商品情報をレコメンド処理部２８へ引き渡す。
§２−３−４ レコメンド処理部２８
レコメンド処理部２８は、時間経過監視部２７から引き受けた時間監視検索データ内のレコメンド対象の注文の注文情報内のユーザＩＤを持つユーザに対してレコメンド情報を提供する。なお、レコメンド情報の提供方法は、本実施形態では、メールによってユーザ端末９に直接送信する方法を採用するが、本発明は、レコメンド情報の提供方法を限定するものではない。レコメンド情報の提供方法は、周知のＷＥＢシステムによって提供される。そして、レコメンド情報を送信する先であるユーザ端末９のメールアドレス等は、データサーバ１内の記憶部１２から取得するようにしてもよい。
レコメンド処理部２８は、時間経過監視部２７から引き受けた時間監視検索データ内のレコメンド対象の注文の注文情報内のユーザＩＤを持つユーザに対してレコメンド情報を提供する。なお、レコメンド情報の提供方法は、本実施形態では、メールによってユーザ端末９に直接送信する方法を採用するが、本発明は、レコメンド情報の提供方法を限定するものではない。レコメンド情報の提供方法は、周知のＷＥＢシステムによって提供される。そして、レコメンド情報を送信する先であるユーザ端末９のメールアドレス等は、データサーバ１内の記憶部１２から取得するようにしてもよい。
レコメンド処理部２８は、時間監視検索データ内のレコメンド対象の注文の商品情報の商品に対する類似商品・推奨商品をデータサーバ１に問い合わせる。類似商品・推奨商品の検索については、商品検索処理部３１と同様、商品情報内の商品タグを用いて行われる。
レコメンド処理部２８は、レコメンド対象の注文の商品情報の商品に対する類似商品・推奨商品が見つかった場合、レコメンド対象の注文の商品情報と類似商品・推奨商品の商品情報とを比較してレコメンド情報を生成する。例えば、割引確定価格で比較し、レコメンド対象の注文の商品情報よりも割引確定価格の安い類似商品・推奨商品の商品情報を収集して、レコメンド情報を生成する。
図１３は、本実施形態における商品Ａに対するメールによるレコメンド情報である。図１３において、商品Ａの商品情報と、商品Ａの類似商品・推奨商品の商品情報とを、比較した結果、商品Ｂ及び商品Ｃの商品情報を含むレコメンド情報が生成されている。なお、商品情報については、図５に示す。
また、レコメンド処理部２８は、参照した商品情報の商品の類似商品・推奨商品が見つからなかった場合、参照した商品情報の商品についてのレコメンド情報を生成しない。
なお、本実施形態のレコメンド処理部２８は時間経過処理部２７から時間監視検索データを引き渡されることによってレコメンド情報の生成を始めているが、本発明のレコメンド情報の生成開始手段を制限するものではない。例えば、ワークサーバ２内の記憶部２２にユーザの注文方法がエントリーである注文情報をキューとして格納し、FIFO（First In
First Out）で処理することでレコメンド処理部２８はレコメンド情報の生成を始めても
よい。
First Out）で処理することでレコメンド処理部２８はレコメンド情報の生成を始めても
よい。
§２−４ ユーザ端末９
ユーザ端末９は、例えば、ＰＣ、携帯電話等である。ユーザ端末９は、ＷＥＢサーバ５にアクセスしデータを受け得る一般的な通信機能、提供されたデータに基づく画面を表示及び操作することができる一般的なユーザインタフェース機能等を有するものであればよい。本発明はこのユーザ端末９のハードウェア構成及び機能構成を限定するものではない。
ユーザ端末９は、例えば、ＰＣ、携帯電話等である。ユーザ端末９は、ＷＥＢサーバ５にアクセスしデータを受け得る一般的な通信機能、提供されたデータに基づく画面を表示及び操作することができる一般的なユーザインタフェース機能等を有するものであればよい。本発明はこのユーザ端末９のハードウェア構成及び機能構成を限定するものではない。
本実施形態では、ユーザ端末９とＷＥＢサーバ５との間のインタフェースとしてＷＥＢシステムが利用される例を挙げているため、ユーザ端末９を利用するユーザ（消費者）は、電子商取引サービスを受けるにあたり、ＷＥＢブラウザを用いてＷＥＢサーバ５にアクセスする。当該ユーザは、ＷＥＢサーバ５から提供される店舗情報（販売商品等）をＷＥＢブラウザにより閲覧する。ユーザは、当該ＷＥＢブラウザ上に表示される画面をユーザ端末９に接続されるユーザインタフェースを用いて操作することにより、所望の商品を検索し、商品を選択し、その選んだ商品を確定注文又はエントリーする。既知のシステムのとおりに、選んだ商品をカートに入れ、最終的に、カート内の商品について確定注文又はエントリーする方式であっても良い。その場合、当然、購入を取り止める商品を当該カートから出す操作を行うことも可能である。ユーザ端末９上での電子商取引に関する各操作に応じた内容がユーザ端末９からＷＥＢサーバ５へそれぞれ送られる。
§２−５ その他
上記装置構成はあくまで例示であり、その他の実施形態を妨げるものではない。
上記装置構成はあくまで例示であり、その他の実施形態を妨げるものではない。
例えば、本システムの構成はＷＥＢサーバ５、ワークサーバ２、データサーバ１の３つのサーバからなっているが、１つのサーバで実現しても良いし、２つ以上の複数のサーバで実現しても良い。
§３ 動作例
§３−１ 注文時
図１４は、本実施形態における注文時の本システムの動作例を示すフローチャートである。ユーザが本システムのＷＥＢページ上で「商品Ａ」を注文した場合を例として、図１４のフローチャートを説明する。注文情報の前提として、図３を用いる。また、商品情報の前提として、図５を用いる。
§３−１ 注文時
図１４は、本実施形態における注文時の本システムの動作例を示すフローチャートである。ユーザが本システムのＷＥＢページ上で「商品Ａ」を注文した場合を例として、図１４のフローチャートを説明する。注文情報の前提として、図３を用いる。また、商品情報の前提として、図５を用いる。
最初に、ユーザの操作が確定注文操作である場合の例として、商品Ａを注文数１個で確定注文した場合を説明する。また、商品Ａを確定注文した際に販売が終了となる場合についても、説明する。次に、ユーザの操作がエントリー操作である場合の例として、商品Ａを注文数１個でエントリーした場合について説明する。そして、ユーザの操作が商品乗り換え操作である場合の例として、商品Ａを注文数１個でエントリーしている状態から同じ注文数で商品Ｂに乗り換えた場合について説明する。ユーザは、乗り換え先の商品である商品Ｂを確定注文したとする。最後に、ユーザの操作が注文切り換え操作の場合の例として、商品Ａを注文数１個でエントリーしている状態から確定注文に注文を切り換えた場合について説明する。
§３−１−１ 確定注文操作時
本動作例において、ユーザは、ユーザ端末９に表示された商品Ａの商品詳細ページ（図８）の当該商品に対してユーザが確定注文操作又はエントリー操作を行う部分（１４２）の注文数を記入する欄に「１」と記入し、「確定注文」ボタンをカーソルでクリック操作等行うことで、商品Ａを注文数１個で確定注文操作を行う（Ｓ２０１）。
本動作例において、ユーザは、ユーザ端末９に表示された商品Ａの商品詳細ページ（図８）の当該商品に対してユーザが確定注文操作又はエントリー操作を行う部分（１４２）の注文数を記入する欄に「１」と記入し、「確定注文」ボタンをカーソルでクリック操作等行うことで、商品Ａを注文数１個で確定注文操作を行う（Ｓ２０１）。
ユーザが上記確定注文操作を行うと、操作処理部５５は、ユーザの操作が上記確定注文操作であると判定し、その判定に基づいてリクエスト制御部５６はＷＥＢページを操作しているユーザのユーザＩＤ、上記確定注文操作をした日時、商品Ａの商品情報、注文数「１」を含むリクエスト情報を生成し、ワークサーバ２に送信する（Ｓ２０２）。
ワークサーバ２がＷＥＢサーバ５からリクエスト情報を受信すると、リクエスト振分部２５は、当該リクエスト情報を確定注文操作処理部３２に振り分ける（Ｓ２０３）。
確定注文操作処理部３２は、当該リクエスト情報から、商品Ａの商品ＩＤ「１００１」、ユーザＩＤ、注文数「１」、上記確定注文操作を行った日時を含む更新用データを生成し、データサーバ１へ送信する（Ｓ２０４）。
データサーバ１が上記更新用データをワークサーバ２から受信すると、データ管理部１５は、注文情報テーブル１６及び商品情報テーブル１８の更新を行う（Ｓ２０５）。
データ管理部１５は、更新用データに含まれているデータから注文情報を生成し、注文情報テーブル１６に追加する。例えば、「注文ＩＤ：００４、商品ＩＤ：１００１、ユーザＩＤ：user004、エントリー／確定注文数：１本、エントリー／確定注文日時：２０１
０／０２／０３／ １５：１６：３２、レコメンド日時：２０１０／０２／０３／ １５：１６：３２、状態：確定」という注文情報を生成し、注文情報テーブル１６に追加する。
０／０２／０３／ １５：１６：３２、レコメンド日時：２０１０／０２／０３／ １５：１６：３２、状態：確定」という注文情報を生成し、注文情報テーブル１６に追加する。
また、データ管理部１５は、商品Ａの商品情報を更新する。データ管理部１５は、商品Ａの商品情報内の変更が必要なフィールドについて「現在の確定注文数：５０、確定注文可能数：１９０、エントリー可能数：１８０、残りの販売数：１８０」から「現在の確定注文数：５１、確定注文可能数：１８９、エントリー可能数：１７９、残りの販売数：１７９」へと更新する。
更新が終了すると、データ管理部１５は、更新後の商品Ａの商品情報と生成された注文情報を含む更新結果データをワークサーバ２に返信する。
ワークサーバ２がデータサーバ１から更新結果データを受信すると、確定注文操作処理部３２は、更新後の商品Ａの商品情報内の残りの販売数が０かどうか判定する（Ｓ２０６）。本動作例では、更新後の商品Ａの商品情報内の残りの販売数は「１７９」であるため、確定注文操作処理部３２は、商品Ａは販売終了していないと判定する。
次に、確定注文操作処理部３２は、更新後の商品Ａの商品情報を含むリクエスト結果情報をＷＥＢサーバ５へ返信する（Ｓ２０９）。
ＷＥＢサーバ５がワークサーバ２からリクエスト結果情報を受信すると、ＷＥＢページ処理部５７は、図９の確定注文完了ページを生成する（Ｓ２１０）。そして、確定注文完了ページはユーザ端末９に送信され、ユーザ端末９上に表示される（Ｓ２１１）。
また、Ｓ２０１において、ユーザが、当該商品に対してユーザが確定注文操作又はエントリー操作を行う部分（１４２）の注文数を記入する欄に「１８０」と記入し、「確定注文」ボタンをカーソルでクリック操作等行ったとする。そうすると、Ｓ２０６において、確定注文操作処理部３２は、更新後の商品Ａの商品情報内の残りの販売数は０であると判定する。したがって、確定注文操作処理部３２は、商品Ａの販売が終了したと判定し、更新後の商品Ａの商品情報を含むリクエスト結果情報をＷＥＢサーバ５へ返信する。また、
確定注文操作処理部３２は、§２−３−２（２）で述べたとおり、販売終了処理を行う。なお、この際、Ｓ２０２〜Ｓ２０５までの処理については、注文数が「１」から「１８０」に替わっただけで、上記と同様である。
確定注文操作処理部３２は、§２−３−２（２）で述べたとおり、販売終了処理を行う。なお、この際、Ｓ２０２〜Ｓ２０５までの処理については、注文数が「１」から「１８０」に替わっただけで、上記と同様である。
ＷＥＢサーバ５が上記リクエスト結果情報を受信すると、ＷＥＢページ処理部５７は、図１１の販売終了ページを生成する（Ｓ２０７）。そして、販売終了ページはユーザ端末９に送信され、ユーザ端末９上に表示される（Ｓ２０８）。
§３−１−２ エントリー操作時
本動作例において、ユーザ端末９に表示された商品Ａの商品詳細ページ（図８）の当該商品に対してユーザが確定注文操作又はエントリー操作を行う部分（１４２）の注文数を記入する欄に「１」と記入し、「エントリー」ボタンをカーソルでクリック操作等行うことで、ユーザは商品Ａを注文数１個でエントリー操作を行う（Ｓ２０１）。
本動作例において、ユーザ端末９に表示された商品Ａの商品詳細ページ（図８）の当該商品に対してユーザが確定注文操作又はエントリー操作を行う部分（１４２）の注文数を記入する欄に「１」と記入し、「エントリー」ボタンをカーソルでクリック操作等行うことで、ユーザは商品Ａを注文数１個でエントリー操作を行う（Ｓ２０１）。
ユーザが上記エントリー操作を行うと、操作処理部５５は、ユーザの操作が上記エントリー操作であると判定し、その判定に基づいてリクエスト制御部５６はリクエスト情報を生成し、ワークサーバ２に送信する（Ｓ２０２）。以降、エントリー操作処理部３３がデータサーバ１に更新用データを送信するまで、ワークサーバ２内の処理主体が異なるだけで、確定注文操作時と同様の処理である（Ｓ２０３〜Ｓ２０４）。
データサーバ１が更新用データをワークサーバ２から受信すると、データ管理部１５は、注文情報テーブル１６及び商品情報テーブル１８の更新を行う（Ｓ２０５）。
本動作例では、データ管理部１５は、更新用データに含まれているデータから注文情報を生成し、注文情報テーブル１６に追加する。例えば、データ管理部１５は、「注文ＩＤ：００４、商品ＩＤ：１００１、ユーザＩＤ：user004、エントリー／確定注文数：１本
、エントリー／確定注文日時：２０１０／０２／０３／ １５：１６：３２、レコメンド日時：２０１０／０２／０３／ １５：１６：３２、状態：エントリー」という注文情報を生成し、注文情報テーブル１６に追加する。
、エントリー／確定注文日時：２０１０／０２／０３／ １５：１６：３２、レコメンド日時：２０１０／０２／０３／ １５：１６：３２、状態：エントリー」という注文情報を生成し、注文情報テーブル１６に追加する。
また、データ管理部１５は、商品Ａの商品情報を更新する。本動作例では、データ管理部１５は、商品Ａの商品情報内の変更が必要なフィールドについて「現在のエントリー数：１０、エントリー可能数：１８０、残りの販売数：１８０」から「現在のエントリー数：１１、エントリー可能数：１７９、残りの販売数：１７９」へと更新する。
更新が終了すると、データ管理部１５は、更新後の商品Ａの商品情報と生成された注文情報を含む更新結果データをワークサーバ２に返信する。
ワークサーバ２がデータサーバ１から更新結果データを受信すると、エントリー操作処理部３３は、更新後の商品Ａの商品情報内の残りの販売数が０かどうか判定する（Ｓ２０６）。本動作例では、更新後の商品Ａの商品情報内の残りの販売数は「１７９」であるため、エントリー操作処理部３３は、商品Ａは販売終了していないと判定する。
エントリー操作処理部３３は、エントリーした商品Ａの商品タグ「飲料、コーラ、炭酸」を用いて、類似商品・推奨商品をデータサーバ１に問い合わせる（Ｓ２０９、Ｓ２１２）。データサーバ１は商品情報テーブル１８から、商品Ａの商品タグと同一の商品タグを持つ商品Ｂと商品Ｃの商品情報を収集する（Ｓ２１３）。データサーバ１は、商品Ｂと商品Ｃの商品情報を含む検索結果をワークサーバ２に返信する。
ワークサーバ２は商品Ｂと商品Ｃの商品情報を受信すると、エントリー操作処理部３３
は、ＷＥＢサーバ５にリクエスト結果情報を返信する（Ｓ２１４）。本動作例において、リクエスト結果情報には、更新した商品Ａの商品情報と、商品Ａの類似商品・推奨商品である商品Ｂ及び商品Ｃの商品情報と、本エントリー操作によって生成された注文情報が含まれている。
は、ＷＥＢサーバ５にリクエスト結果情報を返信する（Ｓ２１４）。本動作例において、リクエスト結果情報には、更新した商品Ａの商品情報と、商品Ａの類似商品・推奨商品である商品Ｂ及び商品Ｃの商品情報と、本エントリー操作によって生成された注文情報が含まれている。
ＷＥＢサーバ５が上記リクエスト結果情報を受信すると、ＷＥＢページ処理部５７は、図１０のエントリー完了ページを生成する（Ｓ２１５）。そして、エントリー完了ページはユーザ端末９に送信され、ユーザ端末９上に表示される（Ｓ２１６）。
§３−１−３ 商品乗り換え操作時
ユーザは、上記エントリー操作の後、ユーザ端末９に表示された商品Ａのエントリー完了ページ（図１０）を操作することで商品乗り換え操作を行ったとする。本動作例では、ユーザは、エントリー完了ページ内の当該商品に対してユーザが商品乗り換え操作を行う部分（１５２、１５３）の注文数を記入する欄に「１」と記入し、「確定注文」ボタンをクリック操作等行ったとする。つまり、ユーザは、商品Ａから商品Ｂに注文数１個の確定注文で商品乗り換え操作を行ったとする（Ｓ２０１）。
ユーザは、上記エントリー操作の後、ユーザ端末９に表示された商品Ａのエントリー完了ページ（図１０）を操作することで商品乗り換え操作を行ったとする。本動作例では、ユーザは、エントリー完了ページ内の当該商品に対してユーザが商品乗り換え操作を行う部分（１５２、１５３）の注文数を記入する欄に「１」と記入し、「確定注文」ボタンをクリック操作等行ったとする。つまり、ユーザは、商品Ａから商品Ｂに注文数１個の確定注文で商品乗り換え操作を行ったとする（Ｓ２０１）。
ユーザが上記商品乗り換え操作を行うと、操作処理部５５は、ユーザの操作が上記商品乗り換え操作であると判定し、その判定に基づいてリクエスト制御部５６はＷＥＢページを操作しているユーザのユーザＩＤ、上記確定注文操作をした日時、商品Ａの商品情報、商品Ａに対する注文情報、注文数「１」、商品Ｂの商品情報を含むリクエスト情報を生成し、ワークサーバ２に送信する（Ｓ２０２）。
ワークサーバ２がＷＥＢサーバ５からリクエスト情報を受信すると、リクエスト振分部２５は、当該リクエスト情報を商品乗り換え操作処理部３４に振り分ける（Ｓ２０３）。
商品乗り換え操作処理部３４は、当該リクエスト情報から、商品Ａに対する注文ＩＤ「００４」、商品Ａの商品ＩＤ「１００１」、商品Ｂの商品ＩＤ「１００２」、ユーザＩＤ、商品Ａに対する注文数「１」、商品Ｂに対する注文数「１」、上記商品乗り換え操作を行った日時を含む更新用データを生成し、データサーバ１へ送信する（Ｓ２０４）。
データサーバ１が更新用データをワークサーバ２から受信すると、データ管理部１５は、注文情報テーブル１６及び商品情報テーブル１８の更新を行う（Ｓ２０５）。
本動作例では、データ管理部１５は、注文情報テーブル１６から更新用データに含まれている商品Ａに対する注文ＩＤ「００４」の注文情報を検索し、該当する注文情報を更新する。例えば、データ管理部１５は、注文ＩＤ「００４」の注文情報内の変更が必要なフィールドについて、「商品ＩＤ：１００１、エントリー／確定注文日時：２０１０／０２／０３／ １５：１６：３２、レコメンド日時：２０１０／０２／０３／ １５：１６：３２、状態：エントリー」から「商品ＩＤ：１００２、エントリー／確定注文日時：２０１０／０２／０４／ １２：３１：４１、レコメンド日時：２０１０／０２／０４／ １２：３１：４１、状態：確定」へと注文情報を更新し、注文情報テーブル１６に上書きする。
また、データ管理部１５は、商品Ａの商品情報を更新する。本動作例では、データ管理部１５は、商品Ａの商品情報内の変更が必要なフィールドについて「現在のエントリー数：１１、エントリー可能数：１７９、残りの販売数：１７９」から「現在のエントリー数：１０、エントリー可能数：１８０、残りの販売数：１８０」へと更新する。そして、商品Ｂの商品情報内の変更が必要なフィールドについて「現在の確定注文数：１００、確定注文可能数：２０、エントリー可能数：５、残りの販売数：５、エントリー数を含む割引
ランク：Ｂ、割引見込み価格：９０」から「現在の確定注文数：１０１、確定注文可能数：１９、エントリー可能数：４、残りの販売数：４、エントリー数を含む割引ランク：Ａ、割引見込み価格：８０」へと更新する。
ランク：Ｂ、割引見込み価格：９０」から「現在の確定注文数：１０１、確定注文可能数：１９、エントリー可能数：４、残りの販売数：４、エントリー数を含む割引ランク：Ａ、割引見込み価格：８０」へと更新する。
更新が終了すると、データ管理部１５は、更新後の商品Ｂの商品情報と生成された注文情報を含む更新結果データをワークサーバ２に返信する。
Ｓ２０６以降の処理については、確定注文操作時と同様である。つまり、商品乗り換え操作処理部３４からＷＥＢサーバ５へリクエスト結果情報が返信され、確定注文完了ページがユーザ端末９上に表示される（Ｓ２０６〜Ｓ２１１）。
§３−１−４ 注文切り換え操作時
ユーザは、上記エントリー操作の後、ユーザ端末９に表示された商品Ａのエントリー完了ページ（図１０）を操作することで注文切り換え操作を行ったとする。本動作例では、ユーザは、エントリー完了ページ内の当該商品に対してユーザが注文切り換え操作を行う部分（１５１）の「注文を確定する」ボタンをクリック操作等行ったとする（Ｓ２０１）。
ユーザは、上記エントリー操作の後、ユーザ端末９に表示された商品Ａのエントリー完了ページ（図１０）を操作することで注文切り換え操作を行ったとする。本動作例では、ユーザは、エントリー完了ページ内の当該商品に対してユーザが注文切り換え操作を行う部分（１５１）の「注文を確定する」ボタンをクリック操作等行ったとする（Ｓ２０１）。
ユーザが上記注文切り換え操作を行うと、操作処理部５５は、ユーザの操作が上記注文切り換え操作であると判定する。そして、その判定に基づいてリクエスト制御部５６はＷＥＢページを操作しているユーザのユーザＩＤ、商品Ａの商品情報、商品Ａに対する注文情報、注文数「１」を含むリクエスト情報を生成し、ワークサーバ２に送信する（Ｓ２０２）。
ワークサーバ２がＷＥＢサーバ５からリクエスト情報を受信すると、リクエスト振分部２５は、当該リクエスト情報を注文切り換え操作処理部３５に振り分ける（Ｓ２０３）。注文切り換え操作処理部３５は、当該リクエスト情報から、商品Ａに対する注文ＩＤ「００４」、商品Ａの商品ＩＤ「１００１」、商品Ａに対する注文数「１」を含む更新用データを生成し、データサーバ１へ送信する（Ｓ２０４）。
データサーバ１が更新用データをワークサーバ２から受信すると、データ管理部１５は、注文情報テーブル１６及び商品情報テーブル１８の更新を行う（Ｓ２０５）。データ管理部１５は、上記更新用データに含まれている商品Ａに対する注文ＩＤ「００４」をもつ注文情報を注文情報テーブル１６から検索する。そして、データ管理部１５は、注文ＩＤ「００４」の注文情報内の状態フィールドに格納されている識別子を「エントリー」から「確定」に更新し、注文情報テーブル１６に上書きする。
また、データ管理部１５は、商品Ａの商品情報を更新する。データ管理部１５は、商品Ａの商品情報内の変更が必要なフィールドについて「現在の確定注文数：５０、現在のエントリー数：１１、確定注文可能数：１８０」から「現在の確定注文数：５１、現在のエントリー数：１０、確定注文可能数：１７９」と更新する。
更新終了後、データ管理部１５は、更新後の商品Ａ及び商品Ｂの商品情報と、更新後の注文情報を含む更新結果データをワークサーバ２に返信する。
Ｓ２０６以降の処理については、ワークサーバ２内の処理主体が確定注文操作処理部３２ではなく注文切り換え操作処理部３５であることを除いて、確定注文操作時と同様である（Ｓ２０６〜Ｓ２１１）。したがって、説明は省略する。
§３−２ レコメンド時
図１５は、本実施形態におけるメールによるレコメンド時の本システムの動作例を示すフローチャートである。ユーザが本システムのＷＥＢページ上で「商品Ａ」にエントリーした場合を例として、図１５のフローチャートを説明する。
図１５は、本実施形態におけるメールによるレコメンド時の本システムの動作例を示すフローチャートである。ユーザが本システムのＷＥＢページ上で「商品Ａ」にエントリーした場合を例として、図１５のフローチャートを説明する。
まず、ワークサーバ２のレコメンド処理部２７は、一定期間経過毎にデータサーバ２に対して時間監視データを送信する（Ｓ３０１）。本動作例においては、一定期間は１分おきであるとし、時間監視データは２０１０年２月３日１３時１６分に送信されたものとする。
データサーバ１が時間監視データを受信すると、データ管理部１５は、データ送信時の日時を用いて、販売期間を過ぎた商品の商品情報及び販売期間を過ぎた商品の注文情報の検索を行う。そして、注文情報テーブル１６から販売期間を過ぎた商品の注文情報を除いた上で、データ管理部１５は、レコメンド対象の注文の注文情報及びレコメンド対象の注文の商品情報の収集を行う（Ｓ３０２）。
本動作例では、まず、データ管理部１５は、商品情報テーブル１８から、販売期間が２０１０年２月３日１３時１６分より前の日時をもつ商品情報を検索する。該当する商品情報は見つからないので、次に、データ管理部１５は、注文情報テーブル１６から、２０１０年２月２日１３時１６分より前のレコメンド日時をもつ注文情報を検索する。図３において、データ管理部１５は、レコメンド対象の注文の注文情報として「注文ＩＤ：００２、商品ＩＤ：１００１、・・・」の注文情報を収集する。なお、本動作例では、§２−１−５で説明したとおり、レコメンド日時がデータ送信時の日時より１日前の場合にその注文情報をレコメンド対象とするとした。
最後に、データ管理部１５は、商品ＩＤ「１００１」の商品情報「注文ＩＤ：００２、商品ＩＤ：１００１、・・・」を注文情報に対応づけて商品情報テーブル１８から収集する。
その後、データ管理部１５は、商品Ａの商品情報、「注文ＩＤ：００２、商品ＩＤ：１００１、・・・」の注文情報を含む時間監視検索データを返信する。そして、データ管理部１５は、「注文ＩＤ：００２、商品ＩＤ：１００１、・・・」の注文情報内のレコメンド日時を、「2010/02/02 13:15:46」から「2010/02/03 13:16:00」へ上書きする。
ワークサーバ２がデータサーバ１から時間の経過を監視する処理に対する応答であることを示す識別子を含む時間監視検索データを受信すると、時間経過監視部２７は、時間監視検索データ内の販売期間を過ぎた商品の商品情報を参照し、販売終了の処理を行う。本動作例の場合、該当する商品情報はない。
時間経過監視部２７は、時間監視検索データ内の「注文ＩＤ：００２、商品ＩＤ：１００１、・・・」の注文情報及び商品Ａの商品情報をレコメンド処理部２８へ引き渡す。
レコメンド処理部２８は、「注文ＩＤ：００２、商品ＩＤ：１００１、・・・」の注文情報内の「ユーザＩＤ：user002」のユーザ情報をデータサーバ１に問い合わせる（Ｓ３
０３）。データサーバ１は、記憶部１２を検索し、メールアドレスを含むユーザ情報を検索結果としてワークサーバ２へ返信する（Ｓ３０４）。
０３）。データサーバ１は、記憶部１２を検索し、メールアドレスを含むユーザ情報を検索結果としてワークサーバ２へ返信する（Ｓ３０４）。
次に、レコメンド処理部２８は、商品Ａの商品情報内の商品タグ「飲料、コーラ、炭酸」を用いて、データサーバ１に商品Ａの類似商品・推奨商品を問い合わせる（Ｓ３０５）。このＳ３０５及びＳ３０６については、Ｓ２１２及びＳ２１３と同様である。データサーバ１では、Ｓ２１３と同様、商品Ｂ及び商品Ｃが商品Ａの類似商品・推奨商品として検
索される（Ｓ３０６）。
索される（Ｓ３０６）。
データサーバ１から商品Ａの類似商品・推奨商品の検索結果を受信すると、レコメンド処理部２８は、商品Ａの類似商品・推奨商品が見つかったかどうか確認する（Ｓ３０７）。
データサーバ１から受信した検索結果に類似商品・推奨商品が含まれていなければ、動作は終了となる（Ｓ３１１）。本動作例の場合、商品Ａの類似商品・推奨商品として商品Ｂ及び商品Ｃが見つかる。商品Ａの類似商品・推奨商品が見つかったので、レコメンド処理部２８は、商品Ａの商品情報と商品Ｂ及び商品Ｃの商品情報とを比較してレコメンド情報を生成する（Ｓ３０８）。
レコメンド処理部２８は、生成したレコメンド情報とユーザ情報からメールを生成し（図１３参照）、ユーザ端末９へ送信する（Ｓ３０９）。送信されたメールは、ユーザ端末９上に表示される（Ｓ３１０）。
§３−３ 作用及び効果
上述したように、本実施形態における電子商取引システムでは、データサーバ１の商品情報テーブル１８内に、共同購入対象となる各商品について、共同購入の注文の受付を許可する販売期間、共同購入の注文の受付を締め切る販売数等と共に、現在の確定注文数、現在のエントリー数等が格納される。このように格納される商品情報に基づいて、ＷＥＢサーバ５のＷＥＢページ処理部５７により、ユーザからの共同購入の受け付けを行うための商品詳細ページ（例えば、図８参照）が生成され、ユーザ端末９へ送られる。この商品詳細ページには、共同購入の注文方法として、確定注文かエントリー注文かの選択操作を可能とする表示部が表示される。
上述したように、本実施形態における電子商取引システムでは、データサーバ１の商品情報テーブル１８内に、共同購入対象となる各商品について、共同購入の注文の受付を許可する販売期間、共同購入の注文の受付を締め切る販売数等と共に、現在の確定注文数、現在のエントリー数等が格納される。このように格納される商品情報に基づいて、ＷＥＢサーバ５のＷＥＢページ処理部５７により、ユーザからの共同購入の受け付けを行うための商品詳細ページ（例えば、図８参照）が生成され、ユーザ端末９へ送られる。この商品詳細ページには、共同購入の注文方法として、確定注文かエントリー注文かの選択操作を可能とする表示部が表示される。
これにより、本実施形態によれば、ユーザは、共同購入をするにあたり確定注文かエントリー注文かを選ぶことができる。
ユーザにより共同購入の注文が行なわれると、注文数、注文方法（注文ＩＤフィールド）等を含む注文情報がデータサーバ１の注文情報テーブル１６に格納される。
ワークサーバ２では、確定注文操作処理部３２、エントリー操作処理部３３、商品乗り換え操作処理部３４、注文切り替え操作処理部３５により各共同購入商品について販売終了条件のうちの１つであるエントリー数及び確定注文数の合計が所定の販売数に到達しているか否か（残りの販売数が０となっているか否か）が判定される。この判定により、その商品について販売終了条件を未だ満たしていないと判定された場合には、ＷＥＢサーバ５のＷＥＢページ処理部５７によりエントリー注文を行ったユーザのためのエントリー完了ページ（図１０参照）が生成され、そのユーザのユーザ端末９へ送られる。このエントリー完了ページには、注文切り換え操作を行うための表示部、商品乗り換え操作を行うための表示部が含まれる。
これにより、エントリー注文を行なっているユーザは、他の商品への乗り換え、共同購入注文をエントリー注文から確定注文への変更を行うことができる。
更に、ワークサーバ２では、時間経過監視部２７により各共同購入商品について販売終了条件のうちのもう１つである販売期間が経過しているか否かが判定される。この判定により販売終了条件を未だ満たしてない商品に対してその商品に関連する商品、即ち、類似商品や推奨商品に関するデータが検索され、抽出されたデータがレコメンド処理部２８によりその商品についてエントリー注文を行なっているユーザに対して送信される。
これにより、エントリー注文を行なっているユーザは、対象商品についての関連商品の情報が提供されるため、その情報を他の商品への乗り換えのために参考にすることができる。
また、上記各販売終了条件が満たされた、即ち、その商品について販売終了したと判定されると、その商品に対するエントリー注文及び確定注文を対象に発注処理及び決済処理等を含む販売終了処理が実行される。つまり、商品の販売が終了した時点において、当該商品に対するエントリーは確定注文と同等に扱われる。
このように本実施形態によれば、共同購入を望むユーザは、エントリー注文を選択すれば、販売終了条件となるまで他の商品へ乗り替えることができるため、従来のように一度注文してしまうと変更できない形態に比較して共同購入に参加し易くなる。また、エントリー注文を選択したユーザには、関連商品情報がリコメンドされ、他の商品への乗り換えが促されるため、ユーザにとって利便性が向上する。結果、本実施形態によれば、消費者の共同購入への参加意欲を高めることができる。
§４ 変形例
以上の実施形態（以下、「実施形態１」と表記）では、販売数による販売終了条件を「確定注文数＋エントリー数＝販売数」とし、販売終了時には、エントリーも確定注文も同等であるとして処理する例について説明した。しかし、販売終了条件及び販売終了時の処理はこのような形態のみに限定されない。以下、他の形態として、販売数による販売終了条件を「確定注文数＝販売数」とする場合について説明する。
以上の実施形態（以下、「実施形態１」と表記）では、販売数による販売終了条件を「確定注文数＋エントリー数＝販売数」とし、販売終了時には、エントリーも確定注文も同等であるとして処理する例について説明した。しかし、販売終了条件及び販売終了時の処理はこのような形態のみに限定されない。以下、他の形態として、販売数による販売終了条件を「確定注文数＝販売数」とする場合について説明する。
販売数による販売終了条件が「確定注文数＝販売数」であるならば、確定注文数とエントリー数の合計が販売数を超える場合がある。時間による販売終了時点において、確定注文数とエントリー数の合計が販売数を超えている場合、販売数を超えた分について当該商品の販売者等は当該商品を用意し、発注処理や決済処理等を行うようにしてもよい。また、販売数を超えている分について当該商品の販売者等は、販売数を超えている分の確定していない注文についてキャンセルするようにしてもよい。以下、後者の形態、すなわち、キャンセルする形態を変形例として実施形態１とは異なる内容を中心に説明する。
なお、注文のキャンセルとは、注文が無効とされること、言い換えれば当該商品についての契約が解除されることを意味し、当該商品の販売者等は注文のキャンセル処理を行う。キャンセル処理では、例えば、当該商品を注文しているユーザにそのキャンセルの旨が通知される。
本変形例では、エントリーによる注文を対象に注文のキャンセルが行われる。そのため、エントリーによる注文方法を採用したユーザにとって、その注文を変更できるメリットがあると共に、その注文がキャンセルされるデメリットもある。注文をキャンセルされたくないユーザは、注文がキャンセルされる前に、エントリーによる注文から確定注文による注文に切り替える必要がある。そこで、本変形例では、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が販売数を超えた時点で、当該商品についてエントリーによる注文をしているユーザに対して、通知を行う。
更に、本変形例では、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が販売数を超えた場合であっても、確定注文数が販売数に到達しない限り、当該商品の販売が終了しない。そのため、本来ならば注文確定とできる状態であるにもかかわらず、確定注文しているユーザにとっては、その商品を早く受け取れないというデメリットもある。そこで、本変形例では、商品の確定注文数とエントリー数の合計が販売数を超えた時点
で、販売終了まで所定期間以上ある場合、販売期間を短縮する。例えば、その所定期間は１日と設定される。また、販売期間の短縮は残り１日とすることである。以下、所定期間は１日、販売期間の短縮は残り１日とすることとして説明するが、本発明はこれらを限定するものではない。
で、販売終了まで所定期間以上ある場合、販売期間を短縮する。例えば、その所定期間は１日と設定される。また、販売期間の短縮は残り１日とすることである。以下、所定期間は１日、販売期間の短縮は残り１日とすることとして説明するが、本発明はこれらを限定するものではない。
なお、以下に挙げる変形例は例示であり、本発明は以下の変形例の構成に限定されない。
§４−１ データサーバ１
§４−１−１ 注文情報テーブル１６
本変形例では、時間による販売終了時点において、確定注文数とエントリー数の合計が販売数を超えている場合、販売数を超えた分の注文についてエントリーによる注文がキャンセルされる。本変形例では、どのエントリーによる注文をキャンセルするかを決定するため、各エントリーによる注文に優先度が設けられる。
§４−１−１ 注文情報テーブル１６
本変形例では、時間による販売終了時点において、確定注文数とエントリー数の合計が販売数を超えている場合、販売数を超えた分の注文についてエントリーによる注文がキャンセルされる。本変形例では、どのエントリーによる注文をキャンセルするかを決定するため、各エントリーによる注文に優先度が設けられる。
この優先度は、時間による販売終了時点において、確定注文数とエントリー数の合計が販売数を超えている場合、「販売数−確定注文数」分を各エントリーによる注文にどのように振り分けるか定めるために用いられる。本変形例では、「販売数−確定注文数」分を各エントリーによる注文に振り分ける方法として、エントリーによる注文が早い者順に振り分ける方法を例に挙げる。なお、この「販売数−確定注文数」分を各エントリーによる注文に振り分ける方法は、各エントリーによる注文の注文数に比例して「販売数−確定注文数」分を相対的に振り分ける方法や、各エントリーによる注文の注文数の多い注文順に順次振り分ける方法等が採用されてもよい。
エントリーによる注文が早い者順に「販売数−確定注文数」分を振り分けるため、具体的には、注文情報テーブル１６に格納される注文情報に新たに注文順番フィールドを設ける。注文順番フィールドには、各エントリーによる注文の注文順番が格納される。
ユーザが確定注文操作を行った場合、本変形例では確定注文の注文順番は意味を持たないので、データ管理部１５は、適当に注文順番を定め、注文情報を生成する。また、ユーザがエントリー操作を行った場合、データ管理部１５は、更新用データ内のユーザが注文した商品ＩＤと同一の商品ＩＤをもち、状態フィールドに「エントリー」が格納されている注文情報を注文情報テーブル１６から収集する。データ管理部１５は、収集した注文情報から、本操作による注文の注文順番を計算し、注文情報を生成する。具体的には、該当する注文情報がなければ「１」を、該当する注文情報があれば、その注文情報内の注文順番の最大値に「１」を加算した値を注文順番として、データ管理部１５は注文情報を生成する。
§４−１−２ 商品情報テーブル１８
本変形例では、販売数による販売終了条件が「確定注文数＝販売数」であるため、実施形態１とは、エントリー可能数フィールド、残りの販売数フィールドが異なる。エントリー可能数フィールドは、ユーザが商品にエントリーすることができる商品数量の最大値が格納されるため、エントリー数に制限のない本変形例においては、不要である。残りの販売数フィールドには、販売数による販売終了条件が「確定注文数＝販売数」であるため、「販売数−確定注文数−エントリー数」ではなく、「販売数−確定注文数」が格納される。
本変形例では、販売数による販売終了条件が「確定注文数＝販売数」であるため、実施形態１とは、エントリー可能数フィールド、残りの販売数フィールドが異なる。エントリー可能数フィールドは、ユーザが商品にエントリーすることができる商品数量の最大値が格納されるため、エントリー数に制限のない本変形例においては、不要である。残りの販売数フィールドには、販売数による販売終了条件が「確定注文数＝販売数」であるため、「販売数−確定注文数−エントリー数」ではなく、「販売数−確定注文数」が格納される。
また、本変形例では、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が販売数を超えた時点で、販売終了までの期間が１日以上ある場合、販売期間を残り１日に短縮する。この場合、データサーバ１は、ワークサーバ２から販売期間を変更するため
のデータ（以降、「販売期間変更データ」と表記）を受信する。販売期間変更データには、商品ＩＤ、販売期間が含まれている。データ管理部１５は、販売期間変更データに含まれる商品ＩＤと同一の商品ＩＤをもつ商品情報を商品情報テーブル１８から検索し、該当する商品情報内の販売期間を販売期間変更データに含まれる販売期間に上書きする。
のデータ（以降、「販売期間変更データ」と表記）を受信する。販売期間変更データには、商品ＩＤ、販売期間が含まれている。データ管理部１５は、販売期間変更データに含まれる商品ＩＤと同一の商品ＩＤをもつ商品情報を商品情報テーブル１８から検索し、該当する商品情報内の販売期間を販売期間変更データに含まれる販売期間に上書きする。
§４−１−３ ワークサーバ２への返信について
実施形態１では、データ管理部１５は、ユーザの操作に応じて各データベースを更新した際、ワークサーバ２に更新した商品情報と、更新した注文情報を含む更新結果データを返信する。本変形例では、データ管理部１５は、更に、注文情報を更新する際に収集した、更新した注文情報と同一の商品ＩＤを持つ注文情報を含む更新結果データを返信する。
実施形態１では、データ管理部１５は、ユーザの操作に応じて各データベースを更新した際、ワークサーバ２に更新した商品情報と、更新した注文情報を含む更新結果データを返信する。本変形例では、データ管理部１５は、更に、注文情報を更新する際に収集した、更新した注文情報と同一の商品ＩＤを持つ注文情報を含む更新結果データを返信する。
また、実施形態１では、データ管理部１５は、ワークサーバ２から時間監視データを受信した際、レコメンド対象の注文の注文情報を含む時間監視検索データをワークサーバ２に返信する。本変形例では、更に、レコメンド対象の注文の注文情報と同一の商品ＩＤを持つ注文情報を含む時間監視検索データをワークサーバ２に返信する。
§４−２ ＷＥＢサーバ５
実施形態１では、ＷＥＢページ処理部５７は、ワークサーバ２から返信されるリクエスト結果情報に基づいてユーザ端末９に表示するためのＷＥＢページを生成する。本変形例では、ユーザがエントリーによる注文をすると、その商品の注文順番が決定される。したがって、本変形例では、この際に生成されるエントリー完了ページにおいて、この注文順番に関する情報を更に表示する。
実施形態１では、ＷＥＢページ処理部５７は、ワークサーバ２から返信されるリクエスト結果情報に基づいてユーザ端末９に表示するためのＷＥＢページを生成する。本変形例では、ユーザがエントリーによる注文をすると、その商品の注文順番が決定される。したがって、本変形例では、この際に生成されるエントリー完了ページにおいて、この注文順番に関する情報を更に表示する。
ユーザがＷＥＢページ上でエントリーした場合又は商品乗り換え操作において乗り換え先の商品の注文方法としてエントリーを選択した場合、実施形態１とは異なり、ワークサーバ２からＷＥＢサーバ５へ注文順番に関する情報を含むリクエスト結果情報が返信される。注文順番に関する情報とは、キャンセルまでの注文数又はキャンセルされることの情報を含む情報である。
キャンセルまでの注文数とは、ユーザが行ったエントリーによる注文について一部キャンセルが生じるまでの確定注文による注文数を示す。例えば、あるユーザが商品Ａに注文数「１０」でエントリーしたとする（図５参照）。当該ユーザが商品Ａについての注文順番は２番目で、エントリー数は「２０」となる。この状態で、誰かが商品Ａに「１７１」以上の注文数で確定注文したとすると、確定注文数とエントリー注文数の合計は「２４１」以上となり、販売数「２４０」を超える。この場合、当該ユーザの商品Ａについての注文からキャンセルが行われる。つまり、この場合におけるキャンセルまでの注文数とは、「１７１」である。
本変形例では、ＷＥＢページ処理部５７は、キャンセルまでの注文数又はキャンセルされること等を記載したエントリー完了ページを生成する。エントリーによる注文がキャンセルされるか否かはワークサーバ２において判定される。
なお、実施形態１において、ユーザが商品にエントリーする際、当該商品の残りの販売数を超える注文数で注文を行った場合、リクエスト制御部５６はリクエスト情報を生成せず、エラーをＷＥＢページ処理部５７に送ることを説明した。本変形例の場合、エントリーについては制限を設けていないため、ユーザが商品をエントリーする際、当該商品の残りの販売数を超える注文数でエントリーしたとしても、リクエスト制御部５６はエラーをＷＥＢページ処理部５７に送らず、リクエスト情報を生成してワークサーバ２へ送信する。
§４−３ ワークサーバ２
§４−３−１ 確定注文操作処理部３２
本変形例では、実施形態１とは異なり、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が販売数を超えた時点で、当該商品についてエントリーによる注文をしているユーザに対して通知が行われる。以下、この点における、確定注文操作処理部３２の変更点を説明する。なお、販売終了時の処理については、後述する。
§４−３−１ 確定注文操作処理部３２
本変形例では、実施形態１とは異なり、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が販売数を超えた時点で、当該商品についてエントリーによる注文をしているユーザに対して通知が行われる。以下、この点における、確定注文操作処理部３２の変更点を説明する。なお、販売終了時の処理については、後述する。
確定注文操作処理部３２は、データサーバ１からの更新結果データを受信後、更新後の商品情報の確定注文数とエントリー数の合計が販売数を超えたか否かの判定を行う。判定は、「確定注文数＋エントリー数≧販売数」を計算することで行われる。「確定注文数＋エントリー数≧販売数」でなければ、その後の処理は実施形態１と同様である。確定注文操作処理部３２は、リクエスト結果情報をＷＥＢサーバ５へ返信する。
他方、「確定注文数＋エントリー数≧販売数」であれば、確定注文操作処理部３２は、更新結果データに含まれる各注文情報に対してキャンセルまでの注文数を計算する。更新結果データには、ユーザが注文した商品に対するエントリーによる注文の注文情報がすべて含まれている。確定注文操作処理部３２は、各注文情報を注文順番の早い順に並び替える。そして、１番目の注文情報から順にキャンセルまでの注文数を計算していく。
１番目の注文情報のキャンセルまでの注文数は「販売数−確定注文数−注文数＋１」と計算され、それ以降、Ｎ番目の注文情報のキャンセルまでの注文数は「（Ｎ−１番目のキャンセルまでの注文数）−注文数」で計算される。キャンセルまでの注文数が初めて１以下となった時点で計算を終了し、その時点の注文情報の注文順番を超える注文情報にはキャンセルされることの情報を対応づける。
なお、キャンセルまでの注文数が初めて１以下となった時点における注文情報についての注文は、一部キャンセルが生じる可能性がある。具体的には、キャンセルまでの注文数が負の値になっている可能性を考慮して、「１−キャンセルまでの注文数」分について一部キャンセルが生じる。この「１−キャンセルまでの注文数」も注文順番に関する情報に含まれる。
その後、確定注文操作処理部３２は、それぞれの注文情報にキャンセルまでの注文数やキャンセルされることの情報を対応づけた上で、商品情報とともにレコメンド処理部２８に引き渡す。各ユーザへの通知はレコメンド処理部２８が行う。その他の処理は実施形態１と同様である。つまり、確定注文操作処理部３２は、リクエスト結果情報をＷＥＢサーバ５へ返信する。
また、本変形例では、実施形態１とは異なり、商品の確定注文数とエントリー数の合計が販売数を超えた時点で、販売終了までの期間が１日以上ある場合、販売期間を残り１日に短縮する。以下、この点における、確定注文操作処理部３２の変更点を説明する。
上記のとおり、確定注文操作処理部３２は、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が予定販売数を超えたか否かを「確定注文数＋エントリー数≧販売数」によって判定する。「確定注文数＋エントリー数≧販売数」でなければ、販売期間は変更しないので、その後の処理は実施形態１と同様である。つまり、確定注文操作処理部３２は、リクエスト結果情報をＷＥＢサーバ５へ返信する。
「確定注文数＋エントリー数≧販売数」であれば、確定注文操作処理部３２は、更新後の商品情報内の販売期間フィールドに格納されている日時とＷＥＢサーバ５から受信したリクエスト情報に含まれているユーザがＷＥＢページ上で商品を確定注文した日時を比較
する。更新後の商品情報内の販売期間フィールドに格納されている日時がリクエスト情報に含まれているユーザがＷＥＢページ上で商品を確定注文した日時よりも１日以上大きい場合、確定注文操作処理部３２は、販売期間変更データを生成する。確定注文操作処理部３２は、リクエスト情報に含まれているユーザがＷＥＢページ上で商品を確定注文した日時に１日加算した日時を含む販売期間変更データを生成し、その販売期間変更データをデータサーバ１へ送信する。その後の処理が実施形態１と同様であることは上記のとおりである。確定注文操作処理部３２は、リクエスト結果情報をＷＥＢサーバ５へ返信する。
する。更新後の商品情報内の販売期間フィールドに格納されている日時がリクエスト情報に含まれているユーザがＷＥＢページ上で商品を確定注文した日時よりも１日以上大きい場合、確定注文操作処理部３２は、販売期間変更データを生成する。確定注文操作処理部３２は、リクエスト情報に含まれているユーザがＷＥＢページ上で商品を確定注文した日時に１日加算した日時を含む販売期間変更データを生成し、その販売期間変更データをデータサーバ１へ送信する。その後の処理が実施形態１と同様であることは上記のとおりである。確定注文操作処理部３２は、リクエスト結果情報をＷＥＢサーバ５へ返信する。
更新後の商品情報内の販売期間とリクエスト情報に含まれているユーザがＷＥＢページ上で商品を確定注文した日時との間が１日以上開いていなければ、販売期間変更データに関する上記の処理は行われない。その後の処理が実施形態１と同様であることは上記のとおりである。確定注文操作処理部３２は、リクエスト結果情報をＷＥＢサーバ５へ返信する。
なお、販売終了処理については、実施形態１と同様に、確定注文操作処理部３２は販売終了用データをデータサーバ１へ送信する。そして、ワークサーバ２はその返信をデータサーバ１から受信する。データサーバ１からの返信には、販売が終了した商品の商品情報と、その商品に対する注文情報が含まれている。実施形態１とは異なり、本変形例では、確定注文とエントリーは同等の注文とは取り扱われない。そのため、確定注文操作処理部３２は、確定注文の注文情報とエントリーの注文情報を区別して取り扱う。
本変形例では、ユーザの注文によって販売が終了する場合、残りの販売数は「販売数−確定注文数」であることから、エントリーによる注文はすべてキャンセルされる。したがって、確定注文操作処理部３２は、販売が終了した当該商品の確定注文による注文について、発注処理、決済処理、当該商品の販売者への通知処理等を行う。そして、確定注文操作処理部３２は、販売が終了した当該商品のエントリーによる注文について、キャンセル処理、当該商品の販売者への通知処理、当該注文のユーザへの通知処理等を行う。このような発注処理、決済処理、キャンセル処理等は周知の手法で行われればよい。
§４−３−２ エントリー操作処理部３３
販売期間を過ぎていない商品の確定注文数とエントリー数の合計が販売数を超えた時点で、当該商品についてエントリーによる注文をしているユーザに対して通知が行われる点、及び、その時点で販売終了までの期間が１日以上ある場合、販売期間を残り１日に短縮する点についての変更点は、確定注文操作処理部３２と同様である。なお、残りの販売数は「販売数−確定注文数」であることから、エントリーによる注文によって販売が終了することはない。この点も、実施形態１とは異なる。
販売期間を過ぎていない商品の確定注文数とエントリー数の合計が販売数を超えた時点で、当該商品についてエントリーによる注文をしているユーザに対して通知が行われる点、及び、その時点で販売終了までの期間が１日以上ある場合、販売期間を残り１日に短縮する点についての変更点は、確定注文操作処理部３２と同様である。なお、残りの販売数は「販売数−確定注文数」であることから、エントリーによる注文によって販売が終了することはない。この点も、実施形態１とは異なる。
本変形例では、ユーザがＷＥＢページ上でエントリーによる注文を行った場合にユーザ端末９に表示されるエントリー完了ページにキャンセルまでの注文数等が含まれる点で実施形態１とは異なる。以下、この点における、エントリー操作処理部３３の変更点を説明する。
エントリー操作処理部３３は、データサーバ１から更新結果データを受信後、このエントリーによる注文がキャンセルされるかどうかについての判定を行う。エントリー操作処理部３３は、更新後の商品情報及び注文情報内のそれぞれの値から「販売数−確定注文数−エントリー数≧０」の判定を行う。
「販売数−確定注文数−エントリー数≧０」ならば、エントリー操作処理部３３は、「販売数−確定注文数−エントリー数＋１」をキャンセルまでの注文数として、このキャンセルまでの注文数を含むリクエスト結果情報をＷＥＢサーバ５へ返信する。「販売数−確
定注文数−エントリー数≧０」でなければ、エントリー操作処理部３３は、このエントリーによる注文がキャンセルされると判定し、注文がキャンセルされることの情報を含むリクエスト結果情報をＷＥＢサーバ５へ返信する。
定注文数−エントリー数≧０」でなければ、エントリー操作処理部３３は、このエントリーによる注文がキャンセルされると判定し、注文がキャンセルされることの情報を含むリクエスト結果情報をＷＥＢサーバ５へ返信する。
§４−３−３ 商品乗り換え操作処理部３４
本変形例では、実施形態１と３つの点で異なる。１つ目は、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が販売数を超えた時点で、当該商品についてエントリーによる注文をしているユーザに対して通知が行われる点である。２つ目は、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が販売数を超えた時点で販売終了までの期間が１日以上ある場合、販売期間を残り１日に短縮する点である。３つ目は、ユーザがＷＥＢページ上でエントリーによる注文を行った場合にユーザ端末９に表示されるエントリー完了ページにキャンセルまでの注文数等が含まれる点である。
本変形例では、実施形態１と３つの点で異なる。１つ目は、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が販売数を超えた時点で、当該商品についてエントリーによる注文をしているユーザに対して通知が行われる点である。２つ目は、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が販売数を超えた時点で販売終了までの期間が１日以上ある場合、販売期間を残り１日に短縮する点である。３つ目は、ユーザがＷＥＢページ上でエントリーによる注文を行った場合にユーザ端末９に表示されるエントリー完了ページにキャンセルまでの注文数等が含まれる点である。
乗り換え先の商品についてユーザが確定注文を選択して注文した場合、上記１つ目と２つ目の点で実施形態１とは異なる。この処理に関しては、処理の対象が乗り換え先の商品について行われるだけで、確定注文操作処理部３２と同様の処理である。乗り換え先の商品についてユーザがエントリーを選択して注文した場合、上記１つ目〜３つ目の点で実施形態１とは異なる。この処理に関しては、処理の対象が乗り換え先の商品について行われるだけで、エントリー操作処理部３３と同様の処理である。
§４−３−４ 注文切り換え操作処理部３５
本変形例において、注文をエントリーから確定注文に切り換えたとしても確定注文数とエントリー数の合計は変化しないため、この処理自体では、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が販売数を超えることはない。既に、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が予定販売数を超えていた場合にのみ、確定注文操作処理部３２と同様、注文切り換え操作処理部３５は、当該商品の商品情報と注文情報をレコメンド処理部２８に引き渡す。既に、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が予定販売数を超えているため、販売期間は変更されており、本変形例においては、この処理によって販売期間を変更することはない。
本変形例において、注文をエントリーから確定注文に切り換えたとしても確定注文数とエントリー数の合計は変化しないため、この処理自体では、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が販売数を超えることはない。既に、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が予定販売数を超えていた場合にのみ、確定注文操作処理部３２と同様、注文切り換え操作処理部３５は、当該商品の商品情報と注文情報をレコメンド処理部２８に引き渡す。既に、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が予定販売数を超えているため、販売期間は変更されており、本変形例においては、この処理によって販売期間を変更することはない。
なお、注文の切り替えによって対象の商品が販売終了となった場合についての処理も、注文切り換え操作処理部３５は、確定注文操作処理部３２と同様の処理を行う。
§４−３−５ 時間経過監視部２７
本変形例において、実施形態１とは異なり、販売終了時点において、確定注文数とエントリー数の合計が販売数を超えている場合、販売数を超えた分についてエントリーによる注文がキャンセルされる。以下、この点における、時間経過監視部２７の変更点を説明する。
本変形例において、実施形態１とは異なり、販売終了時点において、確定注文数とエントリー数の合計が販売数を超えている場合、販売数を超えた分についてエントリーによる注文がキャンセルされる。以下、この点における、時間経過監視部２７の変更点を説明する。
時間監視検索データには、販売期間の過ぎた商品の商品情報と販売期間を過ぎた商品の注文情報が含まれている。時間経過監視部２７は、販売期間の過ぎた商品の商品情報内のそれぞれの値から「確定注文数＋エントリー数＞販売数」となっているかどうかを判定する。
「確定注文数＋エントリー数＞販売数」であれば、時間経過監視部２７は、販売期間の過ぎた商品の注文情報を確定注文の注文情報とエントリーの注文情報に振り分ける。そして、時間経過監視部２７は、エントリーの注文情報について、確定注文操作処理部３２と同様に、キャンセルまでの注文数又はキャンセルされることを求める。その後、時間経過監視部２７は、キャンセルされない又は一部キャンセルされるエントリーによる注文と、確定注文による注文について、発注処理等行う。また、時間経過監視部２７は、キャンセ
ルされるエントリーによる注文について、キャンセル処理等行う。他方、「確定注文数＋エントリー数＞販売数」でなければ、実施形態１と同様に、全ての注文について、発注処理等を行う。これらの処理は周知の手法で行われればよい。
ルされるエントリーによる注文について、キャンセル処理等行う。他方、「確定注文数＋エントリー数＞販売数」でなければ、実施形態１と同様に、全ての注文について、発注処理等を行う。これらの処理は周知の手法で行われればよい。
§４−３−６ レコメンド処理部２８
本変形例では、レコメンド処理部２８は、実施形態１とは異なり、レコメンド対象の注文の注文情報と同一の商品ＩＤを持つ注文情報を更に含む時間監視検索データを引き受ける。レコメンド処理部２８は、レコメンド対象の注文の注文情報のキャンセルまでの注文数を計算する。各注文情報のキャンセルまでの注文数の計算については、§４−３−１で述べたとおりである。そして、レコメンド処理部２８は、計算したキャンセルまでの注文数を含んだレコメンド情報を生成する。
本変形例では、レコメンド処理部２８は、実施形態１とは異なり、レコメンド対象の注文の注文情報と同一の商品ＩＤを持つ注文情報を更に含む時間監視検索データを引き受ける。レコメンド処理部２８は、レコメンド対象の注文の注文情報のキャンセルまでの注文数を計算する。各注文情報のキャンセルまでの注文数の計算については、§４−３−１で述べたとおりである。そして、レコメンド処理部２８は、計算したキャンセルまでの注文数を含んだレコメンド情報を生成する。
また、本変形例では、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が販売数を超えた時点で、当該商品についてエントリーによる注文をしているユーザに対して通知が行われる。このために、実施形態１と異なり、レコメンド処理部２８は、確定注文操作処理部３２等から当該商品の商品情報と、当該商品についてのエントリーによる注文の注文情報引き渡される場合がある。
レコメンド処理部２８は、当該商品についてのエントリーによる注文の注文情報について、キャンセルまでの注文数を計算する。この処理は、§４−３−１に記述のとおりである。そして、レコメンド処理部２８は、キャンセルまでの注文数やキャンセルされることの情報を含むレコメンド情報を生成し、各ユーザのユーザ端末９へ送信する。
§４−４ 変形例の動作例
以下、本変形例の動作例について、実施形態１と異なる点を中心に図１６及び図１７を用いて説明する。図１６は、本変形例における注文時の本システムの動作例を示すフローチャートである。図１７は、本変形例における注文時に確定注文数とエントリー数の合計が販売数に到達した場合についての本システムの動作例の変更点を特に示すフローチャートである。なお、注文情報の前提として、図３を用いる。また、商品情報の前提として、図５を用いる。ただし、本変形例において、§４−１で説明したとおり、注文情報には優先度フィールドが新たに設けられており、商品情報からエントリー可能数フィールドが削除されている。また、商品情報内の残りの販売数が替わっている。例えば、商品Ａの残りの販売数フィールドは「１８０」から「１９０」に、商品Ｂの残りの販売数フィールドは「５」から「２０」に替わっている。
以下、本変形例の動作例について、実施形態１と異なる点を中心に図１６及び図１７を用いて説明する。図１６は、本変形例における注文時の本システムの動作例を示すフローチャートである。図１７は、本変形例における注文時に確定注文数とエントリー数の合計が販売数に到達した場合についての本システムの動作例の変更点を特に示すフローチャートである。なお、注文情報の前提として、図３を用いる。また、商品情報の前提として、図５を用いる。ただし、本変形例において、§４−１で説明したとおり、注文情報には優先度フィールドが新たに設けられており、商品情報からエントリー可能数フィールドが削除されている。また、商品情報内の残りの販売数が替わっている。例えば、商品Ａの残りの販売数フィールドは「１８０」から「１９０」に、商品Ｂの残りの販売数フィールドは「５」から「２０」に替わっている。
§４−４−１ 注文時
ユーザが本システムのＷＥＢページ上で「商品Ａ」を注文した場合を例として、図１６のフローチャートを説明する。
ユーザが本システムのＷＥＢページ上で「商品Ａ」を注文した場合を例として、図１６のフローチャートを説明する。
最初に、ユーザの操作が確定注文操作である場合の例として、商品Ａを注文数１個で確定注文した場合を説明する。また、商品Ａを確定注文した際に販売が終了となる場合についても、説明する。次に、ユーザの操作がエントリー操作である場合の例として、商品Ａを注文数１個でエントリーした場合について説明する。そして、ユーザの操作が商品乗り換え操作である場合の例として、商品Ａを注文数１個でエントリーしている状態から同じ注文数で商品Ｂに乗り換えた場合について説明する。ユーザは、乗り換え先の商品である商品Ｂを確定注文したとする。最後に、ユーザの操作が注文切り換え操作の場合の例として、商品Ａを注文数１個でエントリーしている状態から確定注文に注文を切り換えた場合について説明する。
（１） 確定注文操作時
本動作例において、§３−１−１と同様に、ユーザが注文し（Ｓ２０１、Ｓ４０１）、ＷＥＢサーバ５がワークサーバ２へリクエスト情報を送信し（Ｓ２０２、Ｓ４０２）、リクエスト振分部２５がリクエスト情報を振り分け（Ｓ２０３、Ｓ４０３）、確定注文操作処理部３２がデータサーバ１へ更新用データを送信する（Ｓ２０４、Ｓ４０４）処理が行われる。
本動作例において、§３−１−１と同様に、ユーザが注文し（Ｓ２０１、Ｓ４０１）、ＷＥＢサーバ５がワークサーバ２へリクエスト情報を送信し（Ｓ２０２、Ｓ４０２）、リクエスト振分部２５がリクエスト情報を振り分け（Ｓ２０３、Ｓ４０３）、確定注文操作処理部３２がデータサーバ１へ更新用データを送信する（Ｓ２０４、Ｓ４０４）処理が行われる。
データサーバ１が上記更新用データをワークサーバ２から受信すると、データ管理部１５は、注文情報テーブル１６及び商品情報テーブル１８の更新を行う（Ｓ４０５）。
本動作例では、データ管理部１５は、上記更新用データに含まれている商品ＩＤ「１００１」を有し、状態が「エントリー」である注文情報を注文情報テーブル１６から収集する。注文ＩＤ「００２」の注文情報が収集される。
次に、データ管理部１５は、本確定注文に対する注文情報を生成し、注文情報テーブル１６に追加する。例えば、「注文ＩＤ：００４、商品ＩＤ：１００１、ユーザＩＤ：user004、エントリー／確定注文数：１本、エントリー／確定注文日時：２０１０／０２／０
３／ １５：１６：３２、レコメンド日時：２０１０／０２／０３／ １５：１６：３２、状態：確定、注文順番：１」という注文情報を生成し、注文情報テーブル１６に追加する。なお、注文順番については、この注文は確定注文であるため、どのような値を格納してもよい。
３／ １５：１６：３２、レコメンド日時：２０１０／０２／０３／ １５：１６：３２、状態：確定、注文順番：１」という注文情報を生成し、注文情報テーブル１６に追加する。なお、注文順番については、この注文は確定注文であるため、どのような値を格納してもよい。
また、データ管理部１５は、商品Ａの商品情報を更新する。本動作例では、データ管理部１５は、商品Ａの商品情報内の変更が必要なフィールドについて「現在の確定注文数：５０、確定注文可能数：１９０、残りの販売数：１９０」から「現在の確定注文数：５１、確定注文可能数：１８９、残りの販売数：１８９」へと更新する。
更新が終了すると、データ管理部１５は、更新後の商品Ａの商品情報と生成された注文情報と注文ＩＤ「００２」の注文情報を含む更新結果データをワークサーバ２に返信する。
ワークサーバ２がデータサーバ１から上記更新結果データを受信すると、確定注文操作処理部３２は、更新後の商品Ａの商品情報内の残りの販売数が０かどうか判定する（Ｓ４０６）。本動作例では、更新後の商品Ａの商品情報内の残りの販売数は「１８９」であるため、確定注文操作処理部３２は、商品Ａは販売終了していないと判定する。
次に、確定注文操作処理部３２は、商品Ａの確定注文数とエントリー数の合計が販売数に到達したか否かを判定する（Ｓ４０９）。本動作例では、商品Ａの確定注文数「５１」とエントリー数「１０」の合計「６１」は販売数「２４０」を超えていない。
以降、§３−１−１と同様に、確定注文操作処理部３２がリクエスト結果情報をＷＥＢサーバ５へ返信し（Ｓ２０９、Ｓ４１０）、ＷＥＢページ処理部５７が確定注文完了ページをユーザ端末９へ送信し（Ｓ２１０、Ｓ４１１）、ユーザ端末９が確定注文完了ページを表示する（Ｓ２１１、Ｓ４１２）処理が行われる。
また、Ｓ４０１において、ユーザが、当該商品に対してユーザが確定注文操作又はエントリー操作を行う部分（１４２）の注文数を記入する欄に「１９０」と記入し、「確定注文」ボタンをカーソルでクリック操作等行ったとする。そうすると、Ｓ４０６において、確定注文操作処理部３２は、更新後の商品Ａの商品情報内の残りの販売数は０であると判定する。そして、確定注文操作処理部３２は、更新後の商品Ａの商品情報を含むリクエスト結果情報をＷＥＢサーバ５へ返信する。また、確定注文操作処理部３２は、§４−３−
１で述べたとおり、販売終了処理を行うため、データサーバ１に対して販売終了用データを送信する。本動作例の場合、注文ＩＤ「００２」の注文はキャンセルされる。なお、この際、Ｓ４０２〜Ｓ４０５までの処理については、注文数が「１」から「１９０」に替わっただけで、上記と同様である。
１で述べたとおり、販売終了処理を行うため、データサーバ１に対して販売終了用データを送信する。本動作例の場合、注文ＩＤ「００２」の注文はキャンセルされる。なお、この際、Ｓ４０２〜Ｓ４０５までの処理については、注文数が「１」から「１９０」に替わっただけで、上記と同様である。
ＷＥＢサーバ５が当該商品の販売が終了したことを示す識別子を含む上記リクエスト結果情報を受信すると、ＷＥＢページ処理部５７は、図１１の販売終了ページを生成する（Ｓ４０７）。そして、販売終了ページはユーザ端末９に送信され、ユーザ端末９上に表示される（Ｓ４０８）。
（２） エントリー操作時
本動作例において、§３−１−２と同様に、ユーザが注文し（Ｓ２０１、Ｓ４０１）、ＷＥＢサーバ５がワークサーバ２へリクエスト情報を送信し（Ｓ２０２、Ｓ４０２）、リクエスト振分部２５がリクエスト情報を振り分け（Ｓ２０３、Ｓ４０３）、エントリー操作処理部３３がデータサーバ１へ更新用データを送信する（Ｓ２０４、Ｓ４０４）処理が行われる。
本動作例において、§３−１−２と同様に、ユーザが注文し（Ｓ２０１、Ｓ４０１）、ＷＥＢサーバ５がワークサーバ２へリクエスト情報を送信し（Ｓ２０２、Ｓ４０２）、リクエスト振分部２５がリクエスト情報を振り分け（Ｓ２０３、Ｓ４０３）、エントリー操作処理部３３がデータサーバ１へ更新用データを送信する（Ｓ２０４、Ｓ４０４）処理が行われる。
データサーバ１が上記更新用データをワークサーバ２から受信すると、データ管理部１５は、注文情報テーブル１６及び商品情報テーブル１８の更新を行う（Ｓ４０５）。
本動作例では、データ管理部１５は、上記更新用データに含まれているデータから商品ＩＤ「１００１」を有し、状態が「エントリー」である注文情報を注文情報テーブル１６から収集する。注文ＩＤ「００２」の注文情報が収集される。なお、注文ＩＤ「００２」の注文情報内の優先度フィールドには「１」が格納されているとする。
次に、データ管理部１５は、本エントリー注文に対する注文情報を生成し、注文情報テーブル１６に追加する。例えば、「注文ＩＤ：００４、商品ＩＤ：１００１、ユーザＩＤ：user004、エントリー／確定注文数：１本、エントリー／確定注文日時：２０１０／０
２／０３／ １５：１６：３２、レコメンド日時：２０１０／０２／０３／ １５：１６：３２、状態：エントリー、注文順番：２」という注文情報を生成し、注文情報テーブル１６に追加する。
２／０３／ １５：１６：３２、レコメンド日時：２０１０／０２／０３／ １５：１６：３２、状態：エントリー、注文順番：２」という注文情報を生成し、注文情報テーブル１６に追加する。
また、データ管理部１５は、商品Ａの商品情報を更新する。本動作例では、データ管理部１５は、商品Ａの商品情報内の現在のエントリー数を「１０」から「１１」へと更新する。
更新が終了すると、データ管理部１５は、更新後の商品Ａの商品情報と生成された注文情報と注文ＩＤ「００２」の注文情報を含む更新結果データをワークサーバ２に返信する。
ワークサーバ２がデータサーバ１から上記更新結果データを受信すると、エントリー操作処理部３３は、更新後の商品Ａの商品情報内の残りの販売数が０かどうか判定する（Ｓ４０６）。本動作例では、更新後の商品Ａの商品情報内の残りの販売数は「１９０」であるため、エントリー操作処理部３３は、商品Ａは販売終了していないと判定する。
次に、エントリー操作処理部３３は、商品Ａの確定注文数とエントリー数の合計が販売数に到達したか否かを判定する（Ｓ４０９）。本動作例では、商品Ａの確定注文数「５０」とエントリー数「１１」の合計「６１」は販売数「２４０」を超えていない。
また、エントリー操作処理部３３は、本注文がキャンセルされるかどうかについての判
定を行う。本動作例では、販売数「２４０」、確定注文数「５０」、エントリー数「１１」であるから、「２４０−５０−１１＝１７９≧０」より、本注文はキャンセルされない（Ｓ４１３）。この場合、エントリー操作処理部３３は、キャンセルまでの注文数を計算する。キャンセルまでの注文数は「２４０−５０−１１＋１＝１８０」である。
定を行う。本動作例では、販売数「２４０」、確定注文数「５０」、エントリー数「１１」であるから、「２４０−５０−１１＝１７９≧０」より、本注文はキャンセルされない（Ｓ４１３）。この場合、エントリー操作処理部３３は、キャンセルまでの注文数を計算する。キャンセルまでの注文数は「２４０−５０−１１＋１＝１８０」である。
以降、Ｓ３−１−２と同様に、エントリー操作処理部３３は商品Ａの類似商品・推奨商品をデータサーバ１に問い合わせ（§２１２、Ｓ４１４）、データサーバ１は商品Ｂ及び商品Ｃの商品情報を返信し（Ｓ２１３、Ｓ４１５）、エントリー操作処理部３３は商品Ａ、商品Ｂ及び商品Ｃの商品情報をＷＥＢサーバ５へ返信し（Ｓ２１４、Ｓ４１６）、ＷＥＢページ処理部５７がエントリー完了ページをユーザ端末９へ送信し（Ｓ２１５、Ｓ４１７）、ユーザ端末９がエントリー完了ページを表示する（Ｓ２１６、Ｓ４１８）処理が行われる。Ｓ３−１−２の処理と異なる点は、エントリー操作処理部３３がＷＥＢサーバ５へ返信するリクエスト結果情報及びエントリー完了ページにキャンセルまでの注文数等が含まれる点のみである。
（３） 商品乗り換え操作時
ユーザは、上記エントリー操作の後、ユーザ端末９に表示された商品Ａのエントリー完了ページ（図１０）を操作することで商品乗り換え操作を行ったとする。本本動作例において、§３−１−３と同様に、ユーザが注文し（Ｓ２０１、Ｓ４０１）、ＷＥＢサーバ５がワークサーバ２へリクエスト情報を送信し（Ｓ２０２、Ｓ４０２）、リクエスト振分部２５がリクエスト情報を振り分け（Ｓ２０３、Ｓ４０３）、商品乗り換え操作処理部３４がデータサーバ１へ更新用データを送信する（Ｓ２０４、Ｓ４０４）処理が行われる。
ユーザは、上記エントリー操作の後、ユーザ端末９に表示された商品Ａのエントリー完了ページ（図１０）を操作することで商品乗り換え操作を行ったとする。本本動作例において、§３−１−３と同様に、ユーザが注文し（Ｓ２０１、Ｓ４０１）、ＷＥＢサーバ５がワークサーバ２へリクエスト情報を送信し（Ｓ２０２、Ｓ４０２）、リクエスト振分部２５がリクエスト情報を振り分け（Ｓ２０３、Ｓ４０３）、商品乗り換え操作処理部３４がデータサーバ１へ更新用データを送信する（Ｓ２０４、Ｓ４０４）処理が行われる。
データサーバ１が上記更新用データをワークサーバ２から受信すると、データ管理部１５は、注文情報テーブル１６及び商品情報テーブル１８の更新を行う（Ｓ４０５）。
本動作例では、データ管理部１５は、上記更新用データに含まれているデータから乗り換え先の商品の商品ＩＤ「１００２」を有し、状態が「エントリー」である注文情報を注文情報テーブル１６から収集する。図３において、該当する注文情報は存在しない。
次に、上記更新用データに含まれている商品Ａに対する注文ＩＤ「００４」を有する注文情報を注文情報テーブル１６から検索し、該当する注文情報を更新する。例えば、データ管理部１５は、注文ＩＤ「００４」の注文情報内の変更が必要なフィールドについて、「商品ＩＤ：１００１、エントリー／確定注文日時：２０１０／０２／０３／ １５：１６：３２、レコメンド日時：２０１０／０２／０３／ １５：１６：３２、状態：エントリー、注文順番：２」から「商品ＩＤ：１００２、エントリー／確定注文日時：２０１０／０２／０４／ １２：３１：４１、レコメンド日時：２０１０／０２／０４／ １２：３１：４１、状態：確定、注文順番：２」へと注文情報を更新し、注文情報テーブル１６に上書きする。なお、注文順番については、この注文は確定注文であるため、どのような値を格納してもよい。
また、データ管理部１５は、商品Ａの商品情報を更新する。本動作例では、データ管理部１５は、商品Ａの商品情報内の現在のエントリー数のフィールドに格納される値を「１１」から「１０」へと更新する。そして、商品Ｂの商品情報内の変更が必要なフィールドについて「現在の確定注文数：１００、確定注文可能数：２０、残りの販売数：２０、エントリー数を含む割引ランク：Ｂ、割引見込み価格：９０」から「現在の確定注文数：１０１、確定注文可能数：１９、残りの販売数：１９、エントリー数を含む割引ランク：Ａ、割引見込み価格：８０」へと更新する。
更新が終了すると、データ管理部１５は、更新後の商品Ｂの商品情報と生成された注文
情報を含む更新結果データをワークサーバ２に返信する。
情報を含む更新結果データをワークサーバ２に返信する。
Ｓ４０６以降の処理については、処理主体が、確定注文操作処理部３２から商品乗り換え操作処理部３４に替わるだけで、§４−４−１（１）確定注文時と同様である。つまり、商品乗り換え操作処理部３４からＷＥＢサーバ５へリクエスト結果情報が返信され、確定注文完了ページがユーザ端末９上に表示される（Ｓ４０６〜Ｓ４１２）。
（４） 注文切り換え操作時
ユーザは、上記エントリー操作の後、ユーザ端末９に表示された商品Ａのエントリー完了ページ（図１０）を操作することで注文切り換え操作を行ったとする。本動作例において、§３−１−４と同様に、ユーザが注文し（Ｓ２０１、Ｓ４０１）、ＷＥＢサーバ５がワークサーバ２へリクエスト情報を送信し（Ｓ２０２、Ｓ４０２）、リクエスト振分部２５がリクエスト情報を振り分け（Ｓ２０３、Ｓ４０３）、注文切り換え操作処理部３５がデータサーバ１へ更新用データを送信する（Ｓ２０４、Ｓ４０４）処理が行われる。
ユーザは、上記エントリー操作の後、ユーザ端末９に表示された商品Ａのエントリー完了ページ（図１０）を操作することで注文切り換え操作を行ったとする。本動作例において、§３−１−４と同様に、ユーザが注文し（Ｓ２０１、Ｓ４０１）、ＷＥＢサーバ５がワークサーバ２へリクエスト情報を送信し（Ｓ２０２、Ｓ４０２）、リクエスト振分部２５がリクエスト情報を振り分け（Ｓ２０３、Ｓ４０３）、注文切り換え操作処理部３５がデータサーバ１へ更新用データを送信する（Ｓ２０４、Ｓ４０４）処理が行われる。
データサーバ１が上記更新用データをワークサーバ２から受信すると、データ管理部１５は、注文情報テーブル１６及び商品情報テーブル１８の更新を行う（Ｓ４０５）。
本動作例では、データ管理部１５は、上記更新用データに含まれている商品Ａに対する注文ＩＤ「００４」を有する注文情報を注文情報テーブル１６から検索し、該当する注文情報を更新する。データ管理部１５は、注文ＩＤ「００４」の注文情報内の状態フィールドに格納されている識別子を「エントリー」から「確定」に更新し、注文情報テーブル１６に上書きする。
また、データ管理部１５は、商品Ａの商品情報を更新する。本動作例では、データ管理部１５は、商品Ａの商品情報内の変更が必要なフィールドについて「現在の確定注文数：５０、現在のエントリー数：１１、確定注文可能数：１９０」から「現在の確定注文数：５１、現在のエントリー数：１０、確定注文可能数：１８９」と更新する。
更新終了後、データ管理部１５は、更新後の商品Ａの商品情報と、更新後の注文情報を含む処理結果をワークサーバ２に返信する。
Ｓ４０６以降の処理については、処理主体が、確定注文操作処理部３２から注文切り換え操作処理部３５に替わるだけで、確定注文時と同様である。つまり、注文切り換え操作処理部３５からＷＥＢサーバ５へリクエスト結果情報が返信され、確定注文完了ページがユーザ端末９上に表示される（Ｓ４０６〜Ｓ４１２）。
§４−４−２ ユーザによる注文時に確定注文数とエントリー数の合計が予定販売数に到達した場合
最後に、本変形例における注文時に確定注文数とエントリー数の合計が予定販売数に到達した場合についての本システムの動作例の変更点を説明する。ユーザの操作が確定注文操作であり、商品Ａを注文数１８５個で確定注文した場合を例として、図１７のフローチャートを説明する。
最後に、本変形例における注文時に確定注文数とエントリー数の合計が予定販売数に到達した場合についての本システムの動作例の変更点を説明する。ユーザの操作が確定注文操作であり、商品Ａを注文数１８５個で確定注文した場合を例として、図１７のフローチャートを説明する。
ユーザが注文し、データサーバ１の各テーブルの更新が行われ、確定注文操作処理部３２が、商品Ａの確定注文数とエントリー数の合計が予定販売数に到達したか否かを判定するまでの処理については、§４−４−１（１）で説明したとおりである。（Ｓ４０１〜Ｓ４０６、Ｓ４０９）。本動作例では、商品Ａの確定注文数「２３５」とエントリー数「１０」の合計「２４５」は販売数「２４０」を超えている。
商品Ａの確定注文数とエントリー数の合計が販売数に到達しているため、確定注文操作処理部３２は、データサーバ１から受信した更新結果データに含まれている各注文情報に対応するキャンセルまでの注文数を計算する（Ｓ４１９）。本動作例の場合、データサーバ１から受信した処理結果には注文ＩＤ「００２」の注文情報のみが含まれているので、この注文情報のキャンセルまでの注文数を計算する。商品Ａについての確定注文数は「２３５」であり、販売数は「２４０」であるから、当該注文情報のキャンセルまでの注文数は「−４」であり、注文数「５」について注文のキャンセルが起きる。
その後、確定注文操作処理部３２は、§３−２で説明した処理（Ｓ３０３〜Ｓ３１０）と同様に、各注文を行ったユーザ情報の問い合わせをデータサーバ１に対して行い、メールを作成し、ユーザ端末９へ送信する（Ｓ４２０〜Ｓ４２６）。異なる点は、ユーザが注文した商品についての類似商品・推奨商品が発見されない場合であっても、キャンセルまでの注文数又はキャンセルされることの情報を通知するため、メールが送信される点である。
なお、ユーザの操作がエントリー操作、商品乗り換え操作、注文切り換え操作の場合、ワークサーバ２における処理主体が、エントリー操作処理部３３、商品乗り換え操作処理部３４、注文切り換え操作処理部３５に替わるだけで、処理は上記と同様である。
§４−４−３ 作用及び効果
上述するように、本変形例では、ＷＥＢサーバ５のＷＥＢページ処理部５７により提供される商品詳細ページ（図８参照）では、確定注文数が販売終了数に満たない場合にはその確定注文数とエントリー数との合計数が販売終了数を超える場合であってもエントリー注文が受け付けられる。このエントリー注文に対しては注文順に応じた優先度が付加され、データサーバ１の注文情報テーブル１６に格納される。
上述するように、本変形例では、ＷＥＢサーバ５のＷＥＢページ処理部５７により提供される商品詳細ページ（図８参照）では、確定注文数が販売終了数に満たない場合にはその確定注文数とエントリー数との合計数が販売終了数を超える場合であってもエントリー注文が受け付けられる。このエントリー注文に対しては注文順に応じた優先度が付加され、データサーバ１の注文情報テーブル１６に格納される。
ワークサーバ２では、時間経過監視部２７により、販売期間が経過した商品の存在が監視され、販売期間が経過した商品であって確定注文数とエントリー数の合計が販売数を超えている商品については、その販売数を超える数のエントリー注文がキャンセルされる。このとき、当該商品のエントリー注文に付された優先度の低いものが優先的にキャンセルさせる。
また、ワークサーバ２では、確定注文操作処理部３２、エントリー操作処理部３３、商品乗り換え操作処理部３４及び注文切り替え操作処理部３５により、確定注文数とエントリー数の合計が販売数を超えたか否かが判定される。確定注文数とエントリー数の合計が販売数を超えたと判定されると、その商品についてエントリーによる注文をしているユーザに対してリコメンド処理部２８により通知が行われる。この通知には、キャンセルまでの注文数やキャンセルされる旨の情報等が含まれる。
これにより、エントリー注文をしているユーザは、その通知により自身のエントリー注文のキャンセル可能性を知ることができるため、キャンセルされる可能性が高い場合等には、他の商品への乗り換えを検討することができる。
また、確定注文操作処理部３２、エントリー操作処理部３３、商品乗り換え操作処理部３４及び注文切り替え操作処理部３５により、販売期間を過ぎていない商品の確定注文数とエントリー数の合計が販売数を超えており、販売終了までの期間が１日以上あると判定された場合には、商品情報テーブル１８に格納される販売期間が短縮される。
これにより、確定注文しているユーザは、他の商品への乗り換えをすることができないものの、所定の販売数に注文数が達するとすぐにその商品の共同購入状態が確定されるた
め、早くその商品を手にすることができる。
め、早くその商品を手にすることができる。
このように本変形例によれば、エントリー注文をしたユーザは、実施形態で述べたような変更が許されるというメリットを享受できると共に、キャンセルの可能性が生じるというデメリットも受ける。しかしながら、販売終了数を超える場合であってもエントリー注文が受け付けられ、自身よりも先にエントリー注文をしているユーザが存在する場合であっても、それら先着ユーザが乗り換え等を行なえば、その商品を購入することができる可能性がある。従って、本変形例によれば、エントリー注文をしているユーザは、エントリー注文をしている他のユーザの動向を気にしながら、戦略的に乗り換え等を決めることができるため、共同購入に戦略性、ゲーム性を生じさせることができる。結果、消費者の共同購入への参加意欲を一層高めることができる。
１ データサーバ
１５ データ管理部
１６ 注文情報テーブル
１８ 商品情報テーブル
２ ワークサーバ
２５ リクエスト振分部
２６ リクエスト処理部
２７ 時間経過監視部
２８ レコメンド処理部
３１ 商品検索処理部
３２ 確定注文操作処理部
３３ エントリー操作処理部
３４ 商品乗り換え操作処理部
３５ 注文切り換え操作処理部
５ ＷＥＢサーバ
５５ 操作処理部
５６ リクエスト制御部
５７ ＷＥＢページ処理部
９ ユーザ端末
１５ データ管理部
１６ 注文情報テーブル
１８ 商品情報テーブル
２ ワークサーバ
２５ リクエスト振分部
２６ リクエスト処理部
２７ 時間経過監視部
２８ レコメンド処理部
３１ 商品検索処理部
３２ 確定注文操作処理部
３３ エントリー操作処理部
３４ 商品乗り換え操作処理部
３５ 注文切り換え操作処理部
５ ＷＥＢサーバ
５５ 操作処理部
５６ リクエスト制御部
５７ ＷＥＢページ処理部
９ ユーザ端末
Claims (7)
- 共同購入サービスを提供する電子商取引サーバにおいて、
共同購入対象となる各共同購入商品について、その共同購入の注文の受付を締め切る終了時間を含む商品情報をそれぞれ格納する商品情報格納手段と、
共同購入の注文情報を消費者に入力させる共同購入画面であって、その注文情報に含まれるその共同購入の注文方法として、エントリー状態及び注文確定状態のいずれか一方を選択可能な共同購入画面を消費者端末に表示させるための共同購入画面データをその消費者端末へ送信する手段と、
前記共同購入画面で入力された前記共同購入の注文方法を含む注文情報を各消費者についてそれぞれ格納する注文情報格納手段と、
前記共同購入の注文方法としてエントリー状態を選択している消費者の消費者端末に対してのみ、他の共同購入商品へ注文変更を受け付ける購入変更画面をその消費者端末に表示させるための購入変更画面データを送信する手段と、
前記注文情報格納手段に格納される複数の注文情報のうち、前記商品情報格納手段に格納される複数の共同購入商品のうちの前記終了時間が経過した共同購入商品を対象に前記エントリー状態となっている注文情報を特定し、このエントリー状態となっている注文情報を同一の共同購入商品を対象に前記注文確定状態となっている注文情報と共に共同購入確定状態とする制御手段と、
を備えたことを特徴とする電子商取引サーバ。 - 前記注文情報格納手段に格納された複数の注文情報のうち、共同購入確定状態になっていない共同購入商品を対象に前記エントリー状態となっている注文情報を特定し、このエントリー状態となっている共同購入商品に関連する商品の情報を含むデータを、その特定されたエントリー状態の注文を行なった消費者の消費者端末に送信する商品情報提供手段を更に備える、
ことを特徴とする請求項１に記載の電子商取引サーバ。 - 前記商品情報格納手段に格納されている商品情報には共同購入の注文の受付を締め切る締め切り販売数が含まれ、
前記制御手段は、前記注文情報格納手段に格納される複数の注文情報のうち、前記エントリー状態及び前記注文確定状態の注文数の合計が前記締め切り販売数に到達した共同購入商品を対象に前記エントリー状態となっている注文情報を特定し、このエントリー状態となっている注文情報を同一の共同購入商品を対象に前記注文確定状態となっている注文情報と共に共同購入確定状態とする、
ことを特徴とする請求項１または２に記載の電子商取引サーバ。 - 前記商品情報格納手段に格納されている商品情報には共同購入の注文の受付を締め切る締め切り販売数が含まれ、
前記注文情報格納手段に格納されている注文情報には優先度が含まれ、
前記制御手段は、前記注文情報格納手段に格納される複数の注文情報のうち、前記商品情報格納手段に格納される複数の共同購入商品のうちの終了時間が経過した、又は前記注文確定状態の注文数が前記締め切り販売数に到達した共同購入商品を対象に前記エントリー状態となっている注文情報を特定し、この特定されたエントリー状態の注文情報のうち、注文が無効とされる注文情報を各注文情報に含まれる優先度に基づいて決定する、
ことを特徴とする請求項１または２に記載の電子商取引サーバ。 - 前記エントリー状態及び前記注文確定状態の注文数の合計が前記締め切り販売数に到達した共同購入商品を対象に前記エントリー状態となっている注文情報を特定し、この特定されたエントリー状態の注文を行なった消費者の消費者端末に対してのみ、前記エントリ
ー状態から前記注文確定状態への注文方法の変更を受け付ける注文方法変更画面をその消費者端末に表示させるための注文方法変更画面データを送信する手段、
を更に備えることを特徴とする請求項４記載の電子商取引サーバ。 - 前記エントリー状態及び前記注文確定状態の注文数の合計が前記締め切り販売数に到達した共同購入商品を対象に、前記商品情報格納手段に格納されている商品情報に含まれている終了時間の値を変更する手段、
を更に備えることを特徴とする請求項４または５に記載の電子商取引サーバ。 - 共同購入サービスを提供する電子商取引方法において、
コンピュータが、
共同購入の注文情報を消費者に入力させる共同購入画面であって、その注文情報に含まれるその共同購入の注文方法として、エントリー状態及び注文確定状態のいずれか一方を選択可能な共同購入画面を消費者端末に表示させるための共同購入画面データをその消費者端末へ送信するステップと、
前記共同購入画面で入力された前記共同購入の注文方法を含む注文情報を各消費者についてそれぞれ注文情報格納部に格納するステップと、
前記共同購入の注文方法としてエントリー状態を選択している消費者の消費者端末に対してのみ、他の共同購入商品へ注文変更を受け付ける購入変更画面をその消費者端末に表示させるための購入変更画面データを送信するステップと、
前記注文情報格納部に格納される複数の注文情報のうち、商品情報格納部に共同購入の注文の受付を締め切る終了時間と共に格納される複数の共同購入商品のうちのその終了時間が経過した共同購入商品を対象に前記エントリー状態となっている注文情報を特定し、このエントリー状態となっている注文情報を同一の共同購入商品を対象に前記注文確定状態となっている注文情報と共に共同購入確定状態とするステップと、
を実行することを特徴とする電子商取引方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010075975A JP5452313B2 (ja) | 2010-03-29 | 2010-03-29 | 電子商取引サーバ及び電子商取引方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010075975A JP5452313B2 (ja) | 2010-03-29 | 2010-03-29 | 電子商取引サーバ及び電子商取引方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2011209934A true JP2011209934A (ja) | 2011-10-20 |
| JP5452313B2 JP5452313B2 (ja) | 2014-03-26 |
Family
ID=44940934
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2010075975A Expired - Fee Related JP5452313B2 (ja) | 2010-03-29 | 2010-03-29 | 電子商取引サーバ及び電子商取引方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5452313B2 (ja) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2017182810A (ja) * | 2011-10-27 | 2017-10-05 | イーベイ インク．Ｅｂａｙ Ｉｎｃ． | 拡張現実を使用した物品の視覚化 |
| US10210659B2 (en) | 2009-12-22 | 2019-02-19 | Ebay Inc. | Augmented reality system, method, and apparatus for displaying an item image in a contextual environment |
| US10614602B2 (en) | 2011-12-29 | 2020-04-07 | Ebay Inc. | Personal augmented reality |
| US10936650B2 (en) | 2008-03-05 | 2021-03-02 | Ebay Inc. | Method and apparatus for image recognition services |
| US10956775B2 (en) | 2008-03-05 | 2021-03-23 | Ebay Inc. | Identification of items depicted in images |
| JP2021149444A (ja) * | 2020-03-18 | 2021-09-27 | ヤフー株式会社 | 情報処理装置、関連商品の特定表示制御方法及びプログラム |
| US11651398B2 (en) | 2012-06-29 | 2023-05-16 | Ebay Inc. | Contextual menus based on image recognition |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001265955A (ja) * | 2000-03-15 | 2001-09-28 | Takashi Fuchigami | オンライン共同購買仲介システム |
| JP2002215998A (ja) * | 2000-11-15 | 2002-08-02 | Koen Azusa | 共同購入による価格割引方法及び価格割引プログラム |
| JP2003331022A (ja) * | 2002-05-13 | 2003-11-21 | I Business Center:Kk | 商品購入システムおよび方法 |
-
2010
- 2010-03-29 JP JP2010075975A patent/JP5452313B2/ja not_active Expired - Fee Related
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001265955A (ja) * | 2000-03-15 | 2001-09-28 | Takashi Fuchigami | オンライン共同購買仲介システム |
| JP2002215998A (ja) * | 2000-11-15 | 2002-08-02 | Koen Azusa | 共同購入による価格割引方法及び価格割引プログラム |
| JP2003331022A (ja) * | 2002-05-13 | 2003-11-21 | I Business Center:Kk | 商品購入システムおよび方法 |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10936650B2 (en) | 2008-03-05 | 2021-03-02 | Ebay Inc. | Method and apparatus for image recognition services |
| US11727054B2 (en) | 2008-03-05 | 2023-08-15 | Ebay Inc. | Method and apparatus for image recognition services |
| US11694427B2 (en) | 2008-03-05 | 2023-07-04 | Ebay Inc. | Identification of items depicted in images |
| US10956775B2 (en) | 2008-03-05 | 2021-03-23 | Ebay Inc. | Identification of items depicted in images |
| US10210659B2 (en) | 2009-12-22 | 2019-02-19 | Ebay Inc. | Augmented reality system, method, and apparatus for displaying an item image in a contextual environment |
| CN109934635A (zh) * | 2011-10-27 | 2019-06-25 | 电子湾股份有限公司 | 使用增强现实的物品的可视化 |
| US10628877B2 (en) | 2011-10-27 | 2020-04-21 | Ebay Inc. | System and method for visualization of items in an environment using augmented reality |
| US11113755B2 (en) | 2011-10-27 | 2021-09-07 | Ebay Inc. | System and method for visualization of items in an environment using augmented reality |
| US11475509B2 (en) | 2011-10-27 | 2022-10-18 | Ebay Inc. | System and method for visualization of items in an environment using augmented reality |
| JP2017182810A (ja) * | 2011-10-27 | 2017-10-05 | イーベイ インク．Ｅｂａｙ Ｉｎｃ． | 拡張現実を使用した物品の視覚化 |
| US10147134B2 (en) | 2011-10-27 | 2018-12-04 | Ebay Inc. | System and method for visualization of items in an environment using augmented reality |
| US10614602B2 (en) | 2011-12-29 | 2020-04-07 | Ebay Inc. | Personal augmented reality |
| US11651398B2 (en) | 2012-06-29 | 2023-05-16 | Ebay Inc. | Contextual menus based on image recognition |
| JP2021149444A (ja) * | 2020-03-18 | 2021-09-27 | ヤフー株式会社 | 情報処理装置、関連商品の特定表示制御方法及びプログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| JP5452313B2 (ja) | 2014-03-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5452313B2 (ja) | 電子商取引サーバ及び電子商取引方法 | |
| JP6061309B2 (ja) | 関連商品情報を表示する方法及びシステム | |
| JP5277224B2 (ja) | サーバ装置、レシピ情報提供方法及びレシピ情報提供プログラム | |
| JP6014515B2 (ja) | レコメンド情報提供システム、レコメンド情報生成装置、レコメンド情報提供方法、およびプログラム | |
| US20190065572A1 (en) | Synchronizing database data to a database cache | |
| JP6147401B1 (ja) | 譲渡仲介システム | |
| US10825078B2 (en) | System and method for routing order lookups from retail systems | |
| US10475109B2 (en) | Information processing device, information processing method, and information processing program | |
| TWI503768B (zh) | Information processing devices, information processing methods and information processing products | |
| JP5690393B2 (ja) | 情報処理装置、情報処理方法、情報処理プログラム及び記録媒体 | |
| TW202044173A (zh) | 電腦實施系統、於圖形使用者介面安排超連結的電腦實施方法及非暫時性電腦可讀儲存媒體 | |
| JP5688388B2 (ja) | 情報処理装置、情報処理方法、情報処理プログラム及び記録媒体 | |
| JP2014016970A (ja) | サーバシステム、プログラム及び通信システム | |
| JP5794881B2 (ja) | 情報処理装置、情報処理方法、及び情報処理プログラム | |
| JP7006031B2 (ja) | 管理装置、制御方法及びプログラム | |
| JP2010165048A (ja) | ネットワークを介した商取引を支援する方法、サーバ装置、プログラムおよび記録媒体 | |
| JP2010117749A (ja) | 販売装置、販売方法、及びプログラム | |
| JP2014182522A (ja) | 個人間商品取引システム | |
| JP6664580B2 (ja) | 算出装置、算出方法および算出プログラム | |
| JP2008310742A (ja) | レシピ登録・食材販売システム及びレシピ登録・食材販売サーバ | |
| JP6494170B2 (ja) | 流通管理システム | |
| JP2011165044A (ja) | 電子商取引サーバ及び電子商取引プログラム | |
| JP6007300B1 (ja) | 算出装置、算出方法および算出プログラム | |
| JP3984001B2 (ja) | アイテム注文処理方法 | |
| JP7303425B2 (ja) | 情報処理装置、情報処理方法及びプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20130301 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20131211 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20131217 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20131227 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| LAPS | Cancellation because of no payment of annual fees |