(58)【調査した分野】(Int.Cl.,DB名)
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、過去の販売実績に基づく需要予測では、正確に需要を予測することができるとは限らない。販売数は、取引対象の価格や商品の在庫の有無等の要因に影響されるので、ユーザの需要を正確に反映していない場合があるからである。また、特許文献1に開示されているように、取引対象の情報へのアクセス数に基づく需要予測においても、正確に需要を予測することができるとはいえない。取引対象の情報へアクセスしたユーザがその取引対象の購入に興味を持っているとは必ずしもいえないからからである。
【0006】
本発明は、以上の点に鑑みてなされたものであり、取引対象の需要をより正確に予測することができる情報処理装置、情報処理方法、
及び情報処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【0011】
請求項
1に記載の発明は、取引対象に関する情報への参照を保持する参照リストにユーザにより登録され
且つ前記参照リストから削除されていない取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段に記憶された、需要の予測対象の取引対象を示す前記参照リスト情報を取得する取得手段と、前記取得手段により取得された前記参照リスト情報の数に基づいて、前記取引対象の需要を予測し、
予測された該需要
から、ユーザによる前記参照リストからの取引対象の削除履歴を記憶する削除履歴記憶手段に記憶された、前記需要の予測対象の取引対象の前記削除履歴の数に
応じた量を減ずる、前記予測された需要の補正
を行う予測手段と、
前記予測手段により需要が予測された取引対象の過去の販売数が、該需要に応じて定められる数以下である場合、販売数が少ないことを示す情報を出力する出力手段と、を備えることを特徴とする。
【0012】
ユーザにより参照リストに登録された取引対象はそのユーザから購入される蓋然性がある。この発明によれば、購入される蓋然性がある取引対象を示す参照リスト情報に基づいて需要が予測されるので、より正確に需要を予測することができる。
また、ユーザが参照リストから削除した取引対象はそのユーザが購入に興味を失った蓋然性がある。この発明によれば、参照リストからの取引対象の削除の履歴を更に考慮することにより、需要の予測精度を高めることができる。
【0013】
請求項
2に記載の発明は、取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段に記憶された、需要の予測対象の取引対象を示す前記参照リスト情報を取得する取得手段と、取引対象の複数の区分のうち前記需要の予測対象の取引対象が属する区分が1人のユーザから同時期に複数購入される取引対象の区分であるか否かを判定する判定手段と、前記予測対象の取引対象が属する区分の取引対象の前記参照リストの登録数をユーザごとに取得する登録数取得手段と、前記取得手段により取得された前記参照リスト情報の数に基づいて、前記取引対象の需要を予測する予測手段であり、前記予測対象の取引対象を前記参照リストに登録している各ユーザの該取引対象に対する需要の和を計算して該和に応じた需要を予測し、前記判定手段により複数購入される取引対象の区分であると判定された場合、予め設定された設定需要を各ユーザの需要に設定し、前記判定手段により複数購入される取引対象の区分ではないと判定された場合、前記登録数取得手段によりユーザごとに取得された前記登録数に基づいて各ユーザの需要の設定を行う予測手段と、を備えることを特徴とする。
【0014】
ユーザにより参照リストに登録された取引対象はそのユーザから購入される蓋然性がある。この発明によれば、購入される蓋然性がある取引対象を示す参照リスト情報に基づいて需要が予測されるので、より正確に需要を予測することができる。
また、この発明によれば、1人のユーザから同時期に1つのみ購入されるような区分に属する取引対象の需要の予測においては、その区分の取引対象がユーザによって参照リストに登録されている数に基づいてそのユーザの需要が予測される。そのため、このような区分の取引対象が1人のユーザの参照リストに複数登録されていても、その中からユーザが購入する取引対象は1つである蓋然性が高いことを考慮した需要の予測を行うことができるので、需要の予測精度を高めることができる。
【0015】
請求項
3に記載の発明は、請求項
2に記載の情報処理装置において、ユーザにより購入された取引対象の区分を示す情報と、購入したユーザを示す情報と、購入時期とを対応付けて購入履歴として記憶する購入履歴記憶手段に記憶された前記購入履歴に基づいて、前記予測対象の取引対象が属する区分の取引対象の同時期における購入数をユーザごとに取得する購入数取得手段と、前記購入数取得手段により取得された前記購入数が前記登録数取得手段により取得された前記登録数以上であるか否かをユーザごとに判定する数判定手段と、を更に備え、前記判定手段により複数購入される取引対象の区分であると判定された場合、前記予測手段は、前記数判定手段により前記購入数が前記登録数以上であると判定されたユーザの需要に前記設定需要を設定し、前記数判定手段により前記購入数が前記登録数以上ではないと判定されたユーザの需要に、前記購入数と前記登録数とに基づいて、前記設定需要未満となる需要を設定することを特徴とする。
【0016】
この発明によれば、1人のユーザから同時期に複数購入される可能性がある区分に属する取引対象の需要の予測においては、購入履歴に基づいてその区分の取引対象がユーザによる同時期における購入数が取得され、その購入数が、その区分の取引対象がユーザにより参照リストに登録されている数よりも少ない場合には、購入数と参照リストに登録されている数とに基づいて、そのユーザの需要が予め設定された需要よりも小さく予測される。そのため、このような区分の取引対象が1人のユーザの参照リストに複数登録されている場合、各ユーザの購入の傾向を考慮した需要の予測を行うことができるので、需要の予測精度を高めることができる。
【0017】
請求項
4に記載の発明は、取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段に記憶された、需要の予測対象の取引対象を示す前記参照リスト情報を取得する取得手段と、前記需要の予測対象の取引対象を販売する複数の販売者のうち需要の予測を要求した販売者による該取引対象の市場占有率を取得する占有率取得手段と、前記取得手段により取得された前記参照リスト情報の数と、前記占有率取得手段により取得された前記市場占有率とに基づいて、需要の予測を要求した販売者に対する前記取引対象の需要を予測する予測手段と、を備えることを特徴とする
。
【0018】
ユーザにより参照リストに登録された取引対象はそのユーザから購入される蓋然性がある。この発明によれば、購入される蓋然性がある取引対象を示す参照リスト情報に基づいて需要が予測されるので、より正確に需要を予測することができる。
また、この発明によれば、需要を知りたい販売者に対する需要を予測することができる。
請求項5に記載の発明は、請求項2乃至4の何れか1項に記載の情報処理装置において、前記予測手段により需要が予測された取引対象の過去の販売数が、該需要に応じて定められる数以下である場合、販売数が少ないことを示す情報を出力する出力手段を更に備えることを特徴とする。
【0019】
請求項6に記載の発明は、コンピュータにより実行される情報処理方法であって、取引対象に関する情報への参照を保持する参照リストにユーザにより登録され
且つ前記参照リストから削除されていない取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段に記憶された、需要の予測対象の取引対象を示す前記参照リスト情報を取得する取得ステップと、前記取得ステップにより取得された前記参照リスト情報の数に基づいて、前記取引対象の需要を予測し、
予測された該需要
から、ユーザによる前記参照リストからの取引対象の削除履歴を記憶する削除履歴記憶手段に記憶された、前記需要の予測対象の取引対象の前記削除履歴の数に
応じた量を減ずる、前記予測された需要の補正
を行う予測ステップと、
前記予測ステップにより需要が予測された取引対象の過去の販売数が、該需要に応じて定められる数以下である場合、販売数が少ないことを示す情報を出力する出力ステップと、を含むことを特徴とする。
請求項
7に記載の発明は、コンピュータにより実行される情報処理方法であって、取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段に記憶された、需要の予測対象の取引対象を示す前記参照リスト情報を取得する取得ステップと、取引対象の複数の区分のうち前記需要の予測対象の取引対象が属する区分が1人のユーザから同時期に複数購入される取引対象の区分であるか否かを判定する判定ステップと、前記予測対象の取引対象が属する区分の取引対象の前記参照リストの登録数をユーザごとに取得する登録数取得ステップと、前記取得ステップにより取得された前記参照リスト情報の数に基づいて、前記取引対象の需要を予測する予測ステップであり、前記予測対象の取引対象を前記参照リストに登録している各ユーザの該取引対象に対する需要の和を計算して該和に応じた需要を予測し、前記判定ステップにより複数購入される取引対象の区分であると判定された場合、予め設定された設定需要を各ユーザの需要に設定し、前記判定ステップにより複数購入される取引対象の区分ではないと判定された場合、前記登録数取得ステップによりユーザごとに取得された前記登録数に基づいて各ユーザの需要の設定を行う予測ステップと、を含むことを特徴とする。
請求項
8に記載の発明は、コンピュータにより実行される情報処理方法であって、取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段に記憶された、需要の予測対象の取引対象を示す前記参照リスト情報を取得する取得ステップと、前記需要の予測対象の取引対象を販売する複数の販売者のうち需要の予測を要求した販売者による該取引対象の市場占有率を取得する占有率取得ステップと、前記取得ステップにより取得された前記参照リスト情報の数と、前記占有率取得ステップにより取得された前記市場占有率とに基づいて、需要の予測を要求した販売者に対する前記取引対象の需要を予測する予測ステップと、を含むことを特徴とする。
【0020】
請求項9に記載の発明は、情報処理装置に含まれるコンピュータを、取引対象に関する情報への参照を保持する参照リストにユーザにより登録され
且つ前記参照リストから削除されていない取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段に記憶された、需要の予測対象の取引対象を示す前記参照リスト情報を取得する取得手段
、前記取得手段により取得された前記参照リスト情報の数に基づいて、前記取引対象の需要を予測し、
予測された該需要
から、ユーザによる前記参照リストからの取引対象の削除履歴を記憶する削除履歴記憶手段に記憶された、前記需要の予測対象の取引対象の前記削除履歴の数に
応じた量を減ずる、前記予測された需要の補正
を行う予測手段、
及び前記予測手段により需要が予測された取引対象の過去の販売数が、該需要に応じて定められる数以下である場合、販売数が少ないことを示す情報を出力する出力手段、として機能させることを特徴とする。
請求項
10に記載の発明は、情報処理装置に含まれるコンピュータを、取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段に記憶された、需要の予測対象の取引対象を示す前記参照リスト情報を取得する取得手段、取引対象の複数の区分のうち前記需要の予測対象の取引対象が属する区分が1人のユーザから同時期に複数購入される取引対象の区分であるか否かを判定する判定手段、前記予測対象の取引対象が属する区分の取引対象の前記参照リストの登録数をユーザごとに取得する登録数取得手段、及び、前記取得手段により取得された前記参照リスト情報の数に基づいて、前記取引対象の需要を予測する予測手段であり、前記予測対象の取引対象を前記参照リストに登録している各ユーザの該取引対象に対する需要の和を計算して該和に応じた需要を予測し、前記判定手段により複数購入される取引対象の区分であると判定された場合、予め設定された設定需要を各ユーザの需要に設定し、前記判定手段により複数購入される取引対象の区分ではないと判定された場合、前記登録数取得手段によりユーザごとに取得された前記登録数に基づいて各ユーザの需要の設定を行う予測手段、として機能させることを特徴とする。
請求項
11に記載の発明は、情報処理装置に含まれるコンピュータを、取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段に記憶された、需要の予測対象の取引対象を示す前記参照リスト情報を取得する取得手段、前記需要の予測対象の取引対象を販売する複数の販売者のうち需要の予測を要求した販売者による該取引対象の市場占有率を取得する占有率取得手段、及び、前記取得手段により取得された前記参照リスト情報の数と、前記占有率取得手段により取得された前記市場占有率とに基づいて、需要の予測を要求した販売者に対する前記取引対象の需要を予測する予測手段、として機能させることを特徴とする。
【発明の効果】
【0022】
本発明によれば、購入される蓋然性がある取引対象を示す参照リスト情報に基づいて需要が予測されるので、より正確に需要を予測することができる。
【発明を実施するための形態】
【0024】
以下、図面を参照して本発明の実施形態について詳細に説明する。なお、以下に説明する実施の形態は、電子商取引システムに対して本発明を適用した場合の実施形態である。
【0025】
[1.電子商取引システムの構成及び機能概要]
[1−1.電子商取引システムの構成]
先ず、本実施形態に係る電子商取引システムSの構成について、
図1を用いて説明する。
図1は、本実施形態に係る電子商取引システムSの概要構成の一例を示す図である。
【0026】
図1に示すように、電子商取引システムSは、電子商取引サーバ1と、複数の店舗端末2と、複数のユーザ端末3と、を含んで構成されている。そして、電子商取引サーバ1と各店舗端末2及び各ユーザ端末3とは、ネットワークNWを介して、例えば、通信プロトコルにTCP/IP等を用いて相互にデータの送受信が可能になっている。なお、ネットワークNWは、例えば、インターネット、専用通信回線(例えば、CATV(Community Antenna Television)回線)、移動体通信網(基地局等を含む)、及びゲートウェイ等により構築されている。
【0027】
電子商取引サーバ1(本発明における情報処理装置の一例)は、商品の購入が可能な電子商店街に関する各種処理を実行するサーバ装置である。ユーザは、電子商店街を利用することにより、所望の店舗から所望の商品を購入することができる。電子商取引サーバ1は、店舗端末2やユーザ端末3からのリクエストに応じて、例えば、電子商店街のWebページを送信したり、商品の検索、購入等に関する処理を行ったりする。
【0028】
店舗端末2は、電子商店街に出店している店舗の従業員等により利用される端末装置である。店舗端末2は、例えば、販売する商品の情報を電子商店街に登録したり、商品の注文内容を確認したりするために用いられる。また、店舗端末2は、従業員等からの操作に基づいて電子商取引サーバ1にアクセスすることにより、電子商取引サーバ1からWebページを受信して表示する。店舗端末2には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。店舗端末2としては、例えば、パーソナルコンピュータ等が用いられる。
【0029】
ユーザ端末3は、電子商店街を利用するユーザの端末装置である。ユーザ端末3は、ユーザからの操作に基づいて電子商取引サーバ1にアクセスすることにより、電子商取引サーバ1からWebページを受信して表示する。ユーザ端末3には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。ユーザ端末3としては、例えば、パーソナルコンピュータ、PDA(Personal Digital Assistant)、スマートフォン等の携帯情報端末、携帯電話機等が用いられる。
【0030】
[1−2.お気に入りに基づく需要の予測]
電子商取引システムSにおいては、お気に入り機能が提供されている。お気に入り機能とは、電子商店街で販売されている商品をユーザのお気に入りとして登録することにより、商品ページへの参照をユーザ専用のリストに保持しておき、お気に入りの商品の商品ページをユーザが容易に閲覧することができるようにする機能である。商品ページは、1つの商品に関する詳細な情報が表示されるWebページである。また、お気に入りの商品は、単にお気に入りともいう。電子商店街においては、商品ページに、「お気に入りに追加」と表示されたハイパーリンク(以下、「リンク」という)が表示されている。ユーザがこのリンクを選択すると、商品ページに情報が表示されている商品が、ユーザのお気に入りに登録される。ユーザは、お気に入りに登録されている商品を、お気に入りページで確認することができる。お気に入りページは、お気に入りに登録されている商品の一覧が表示されるWebページであり、ユーザごとに専用のWebページである。また、お気に入りページには、お気に入りに登録された商品の商品ページへのリンクが埋め込まれている。お気に入りページにおいて、ユーザは、任意の商品のリンクを選択すると、対応する商品ページを表示させることができる。また、お気に入りページにおいて、ユーザは、お気に入りに登録されている商品の中から登録しておく必要がない商品を指定してお気に入りから削除することができる。
【0031】
電子商取引サーバ1は、店舗端末2からの要求に応じて、電子商店街で販売されている商品の需要予測を行い、予測結果を示すWebページ(以下「商品需要予測結果ページ」という)を店舗端末2へ送信する。具体的に、電子商取引サーバ1は、お気に入りに基づいて、商品の需要を予測する処理を実行する。お気に入りには、例えば、ユーザが気になった商品、購入候補とした商品、ユーザが好きな商品等が登録される。従って、ユーザによりお気に入りに登録されている商品は、お気に入りに登録されていない商品よりも、そのユーザによって将来購入される蓋然性が高い商品であると考えられる。つまり、お気に入りは、将来の商品の需要を表しているといえる。そこで、電子商取引サーバ1は、基本的には、ある商品をお気に入り
に登録しているユーザの数(以下、「登録数」という)が多いほど、その商品の需要が大きいと予測する。
【0032】
従来の需要予測としては、過去の販売数に基づく需要予測がある。しかしながら、過去の販売数に基づく需要予測では、正確に需要を予測することができるとは限らない。販売数は、商品の価格や商品の在庫の有無等の要因に影響されるからである。また、過去の販売数は、これまでの需要の消費量を示している。つまり、過去の販売数が多いと、これまでの商品の販売で、本来あった需要の大部分が消費されてしまっている場合がある。その場合、将来の販売数が急激に落ちることもあり得る。これに対し、お気に入りに基づく需要予測では、商品の価格や商品の在庫の有無等に影響されない。また、上述したように、お気に入りには、ユーザが将来購入する可能性がある商品が登録される。そのため、お気に入りに基づく需要予測は、過去の販売数に基づく需要予測よりも、正確に需要を予測することができる。
【0033】
また、従来の需要予測として、商品ページ等の商品の情報に対するアクセス数に基づく需要予測がある。アクセス数に基づく需要予測も、ユーザの需要を正確に予測することができるとはいえない。商品ページを閲覧したユーザがその商品ページに情報が掲載されている商品の購入に興味を持っているとは限らないからである。例えば、ユーザは、購入するつもりはなく、単なる興味本位で商品ページを閲覧する場合がある。また、ユーザが、商品ページに掲載された情報を確認した結果、その商品ページに情報が掲載されている商品を購入対象から除外する場合もある。これに対し、お気に入りに商品を登録するというユーザの行為は、ユーザがその商品に興味を持っているという意思表示である蓋然性が高い。そのため、お気に入りに基づく需要予測は、商品ページのアクセス数に基づく需要予測よりも、正確に需要を予測することができる。
【0034】
次に、お気に入りに基づく具体的な需要の予測方法について説明する。電子商取引サーバ1は、ある商品について、お気に入りに登録しているユーザ1人につき、1人分に応じた需要があるとする。この1人分に応じた需要の大きさは、例えば、電子商取引ステムSの管理者により予め設定されている。例えば、1人分に応じた需要は、商品1個分の需要があるとしてもよいし、商品1個分よりも大きくても小さくてもよい。例えば、お気に入りに登録しているユーザ1人につき商品1個の需要があるとする。また、商品Aのお気に入りへの登録数が3000であり、商品Bのお気に入りへの登録数が2000であるとする。その場合、商品Aに対して3000個分の需要があり、商品Bに対して2000個分の需要があることになる。
【0035】
ところで、各商品はそれぞれジャンル分けされている。商品のジャンル(本発明における区分の一例)は、商品を、例えば種類、性質、用途等で区分したときに、同じような種類、性質、用途等の商品が属する範囲である。ここで、あるジャンルの商品をあるユーザが購入するとき、そのジャンルの商品を同時期に複数購入することが一般的にはないジャンルがある。そのようなジャンルの商品として、例えば、冷蔵庫がある。冷蔵庫は、一般的には1つの家庭で1台購入されると、その家庭ではその後数年の間購入されることがない。例えば、あるユーザが、冷蔵庫の商品C、D及びEをお気に入りに登録しているとする。この場合、そのユーザが商品C、D及びEの全てを購入するつもりでお気に入りに登録しているとは考えにくい。この場合、そのユーザは、商品C、D及びEを購入候補として、その中から何れかの商品を購入するつもりである蓋然性が高い。従って、商品C、D及びEのうち商品Cが購入される商品として選択される確率は、単純計算では1/3である。そして、実際に商品Cが購入された場合、商品Cに対しては現実に需要があったが、商品D及びEに対しては現実の需要はなかったことになる。このことから、1人のユーザが同時期に複数購入することが一般的にないジャンルの商品について、あるユーザがお気に入りに登録している数(以下、「同一ジャンル登録数」という)が多いほど、個々の商品に対する将来の需要は小さくなると考えられる。
【0036】
そこで、電子商取引サーバ1は、このようなジャンルの商品の需要を予測する場合、ユーザごとに同一ジャンル登録数を計算する。そして、電子商取引サーバ1は、同一ジャンル登録数に基づいて、ユーザごとの需要を設定する。具体的に、電子商取引サーバ1は、予め設定された1人分に応じた需要に対して同一ジャンル登録数分の1となる需要を計算することによりユーザごとに需要を計算する。つまり、電子商取引サーバ1は、
【0037】
あるユーザの需要=1人分に応じた需要/そのユーザの同一ジャンル登録数
【0038】
を計算する。そして、電子商取引サーバ1は、各ユーザについて計算した需要の和を計算することで、全ユーザの需要を予測する。
【0039】
一方、電子商取引サーバ1は、1人のユーザが同時期に複数購入する可能性があるジャンルの商品の需要を予測する場合、同一ジャンル登録数の大きさにかかわらず、1人のユーザにつき予め設定された1人分に応じた需要があるとしてもよい。例えば、洋服は、同時期に複数購入される可能性がある。
【0040】
あるいは、電子商取引サーバ1は、1人のユーザが同時期に複数購入する可能性があるジャンルの商品の需要を予測する場合、ユーザの過去の購入傾向に基づいてユーザごとの需要を計算し、計算した需要の和を計算することで、全ユーザの需要を予測してもよい。1人のユーザが同時期に複数購入する可能性があるジャンルであるとしても、そのジャンルの商品が複数お気に入りに登録されている場合、登録されている全ての商品が購入されるとは限らない。同時期に何個の商品が購入されるかは、一般的にはユーザごとに異なる。そこで、電子商取引サーバ1は、ユーザごとに、需要の予測対象の商品が属するジャンルの商品について、同時期における購入数(以下、「同時期購入数」という)を算出する。そして、電子商取引サーバ1は、同時期購入数が同一ジャンル登録数以上である場合には、予め設定された1人分に応じた需要があるとする。ユーザが同時期に購入する数が、お気に入りに登録されている商品の数以上であるため、登録されている全ての商品がそのユーザによって購入される蓋然性があるからである。つまり、登録されている全ての商品に対して需要があると考えられるからである。一方、電子商取引サーバ1は、同時期購入数が同一ジャンル登録数未満である場合には、同時期購入数と同一ジャンル登録数に基づいて、予め設定された1人分に応じた需要未満の範囲内でユーザごとに需要を設定する。具体的に電子商取引サーバ1は、予め設定された1人分に応じた需要を同時期購入数倍し、その結果に対して同一ジャンル登録数分の1を計算することにより、ユーザごとの需要を計算する。つまり、電子商取引サーバ1は、
【0041】
あるユーザの需要=1人分に応じた需要×そのユーザの同時期購入数/そのユーザの同一ジャンル登録数
【0042】
を計算する。お気に入りに登録されている商品のうち、ユーザが同時期に購入する数までの需要があると考えられるからである。
【0043】
また、電子商取引サーバ1は、お気に入りへの商品の登録の履歴やお気に入りからの商品の削除の履歴を記録しておき、この履歴とお気に入りとに基づいて、商品の需要を予測してもよい。例えば、電子商取引サーバ1は、予め設定された期間(例えば、現在から1週間前までの期間、1ヶ月前までの期間等)における需要の予測対象の商品のお気に入りの登録数の増減数に基づいて、商品の需要を補正してもよい。これまでお気に入りの登録数が減っている商品は、この後も登録数が減っていく蓋然性がある。従って、そのような商品は、これから需要が減っていく蓋然性がある。そこで、電子商取引サーバ1は、例えば、お気に入りの登録数が減少した商品については、減少した数が多いほど、その商品の需要を補正前よりも小さくなるように補正してもよい。また、電子商取引サーバ1は、例えば、お気に入りの登録数が増加した商品については、増加した数が多いほど、その商品の需要を補正前よりも大きくなるように補正してもよい。
【0044】
また、電子商取引サーバ1は、お気に入りからの商品の削除の履歴とお気に入りとに基づいて、商品の需要を予測してもよい。例えば、電子商取引サーバ1は、予め設定された期間におけるお気に入りからの需要の予測対象の商品が削除された数に基づいて、商品の需要を補正してもよい。具体的に、電子商取引サーバ1は、削除された数が多いほど、商品の需要を補正前よりも小さくなるように補正する。
【0045】
また、電子商取引サーバ1は、需要の予測を要求してきた店舗に対する需要(以下、「店舗需要」という)を予測してもよい。過去の販売実績により、需要の予測を要求してきた店舗の電子商店街における市場占有率を計算することができる。そこで、電子商取引サーバ1は、電子商店街全体における需要(以下、「総需要」という)に市場占有率を乗算することにより、需要の予測を要求してきた店舗の需要を予測することができる。
【0046】
次に、お気に入りに基づく需要の予測結果を示す情報の表示例について説明する。
図2(a)乃至(e)は、商品需要予測結果ページ内における需要の予測結果を示す情報の表示例である。
【0047】
商品需要予測結果ページ内に、複数の商品の需要の情報を同時に表示させる場合がある。この場合、電子商取引サーバ1は、需要の予測対象の商品のうち同じ商品のジャンルに属する複数の商品については、商品間における需要の大小関係を予測し、需要の大小関係を示す情報が商品需要予測結果ページに表示されるようにする。同じジャンルに属する複数の商品は、店舗によって需要が比較される商品同士となるからである。店舗は、需要を比較することにより、例えば、どの商品を仕入れるべきか、どの商品の販売に力を入れるか等を検討する。
【0048】
例えば、電子商取引サーバ1は、
図2(a)に示すように、商品Aは3000個分、商品Bは2000個分と、各商品のお気に入りへの登録数がそのまま表示されるようにしてもよい。また例えば、電子商取引サーバ1は、
図2(b)に示すように、商品A:商品B=3:2というように、需要の比率が表示されるようにしてもよい。また、電子商取引サーバ1は、
図2(c)に示すように、「商品Aの方が商品Bよりも需要があります」という情報が表示されるようにしてもよいし、「商品A>商品B」という情報が表示されてもよい。また、電子商取引サーバ1は、
図2(d)に示すように、需要の大小関係を示す情報とともに、予め設定された期間における各商品のお気に入りの登録数の増減数が表示されるようにしてもよい。また、電子商取引サーバ1は、
図2(e)に示すように、需要の大小関係を示す情報とともに、各商品のお気に入りの登録数の増減数の推移を示すグラフが表示されるようにしてもよい。
【0049】
また、需要の予測を要求してきた店舗における需要の予測対象の商品のこれまでの販売数が、お気に入りに基づいて予測された需要に対して相当に小さい場合には、潜在的な需要があるにもかかわらず、何らかの原因(例えば、価格が高い等)で売れ行きがよくないことが考えられる。そこで、電子商取引サーバ1は、このような場合に応じた情報も表示されるようにしてもよい。例えば、「商品Aの需要は3000ありますが、何らかの原因で売れ行きが伸びていません。」等の情報が表示されるようにしてもよい。電子商取引サーバ1は、例えば、販売数が予め設定された閾値以下である場合や、販売数が予測された需要の所定数分の1以下である場合等にこのような表示が行われるようにしてもよい。
【0050】
また、電子商取引サーバ1は、総需要または店舗需要の何れか一方のみが表示されるようにしてもよいし、両方が表示されるようにしてもよい。
【0051】
[2.電子商取引サーバの構成]
次に、電子商取引サーバ1の構成について、
図3及び
図4を用いて説明する。
【0052】
図3は、本実施形態に係る電子商取引サーバ1の概要構成の一例を示すブロック図である。
図3に示すように、電子商取引サーバ1は、通信部11と、記憶部12と、入出力インターフェース13と、システム制御部14と、を備えている。そして、システム制御部14と入出力インターフェース13とは、システムバス15を介して接続されている。
【0053】
通信部11は、ネットワークNWに接続して、店舗端末2やユーザ端末3等との通信状態を制御するようになっている。
【0054】
記憶部12(本発明における記憶手段、削除履歴記憶手段及び購入履歴記憶手段の一例)は、例えば、ハードディスクドライブ等により構成されている。この記憶部12には、会員情報DB(データベース)12a、ジャンル情報DB12b、店舗情報DB12c、商品情報DB12d、閲覧履歴DB12e、購入履歴DB12f、お気に入り情報DB12g、お気に入り登録削除履歴DB12h等のデータベースが構築されている。
【0055】
図4(a)は、会員情報DB12aに登録される内容の一例を示す図である。会員情報DB12aには、電子商取引システムSに会員登録しているユーザに関する会員情報が登録される。具体的に、会員情報DB12aには、ユーザID、パスワード、ニックネーム、氏名、生年月日、性別、郵便番号、住所、電話番号、電子メールアドレス等のユーザの属性が、ユーザごとに対応付けて登録される。ユーザIDは、ユーザの識別情報である。
【0056】
図4(b)は、ジャンル情報DB12bに登録される内容の一例を示す図である。ジャンル情報DB12bには、商品のジャンルに関するジャンル情報が登録されている。具体的に、ジャンル情報DB12bには、ジャンルID、ジャンル名、ジャンルのレベル、親ジャンルID、子ジャンルIDリスト、複数購入対象外フラグ等のジャンルの属性が、ジャンルごとに対応付けて登録される。ジャンル情報は、例えば、電子商店街の管理者等により設定される。
【0057】
商品のジャンルは、木構造で階層的に定義されている。具体的に、木構造の各ノードが、ジャンルに相当する。ノードの深さが、そのノードに相当するジャンルのレベル(階層)に相当する。ノードの深さは、根に位置するノード(以下、「根ノード」という)からの距離である。レベルの値が大きいほど、レベルとしての深さが深く、レベルの値が小さいほど、レベルとしての深さが浅い。根ノードが有する子ノードに相当するジャンルがレベル1のジャンルである。レベル1のジャンルが最上位のジャンルである。レベル1の各ジャンルに対しては、子ノードに相当するジャンルが、レベル2のジャンルとして定義されている。ここで、あるジャンルC1の子ノードに相当するジャンルC2を、ジャンルC1の「子ジャンル」という。子ジャンルを、サブジャンルともいう。また、このときのジャンルC1を、ジャンルC2の「親ジャンル」という。子ジャンルは、親ジャンルを更に複数に区分したときに、同じような商品が属する範囲である。従って、子ジャンルは親ジャンルに属する。また、あるジャンルに対して、子孫のノードに相当するジャンルを、「子孫ジャンル」という。例えば、ジャンルC3がジャンルC2の子ジャンルであるとする。この場合、ジャンルC2及びC3は、ジャンルC1の子孫ジャンルである。また、あるジャンルに対して、先祖のノードに相当するジャンルを、「先祖ジャンル」という。ジャンルC1及びC2は、ジャンルC3の先祖ジャンルである。なお、同じジャンルに属する複数の商品とは、それぞれの商品が属するレベル1のジャンルから最下位のレベルのジャンルまでの全てのジャンルが互いに一致する商品同士のみに限られるものではない。同じジャンルに属する複数の商品とは、レベル1のジャンルから最下位のレベルのジャンルのうち少なくとも1つのジャンルにおいて同じジャンルに属する商品同士も含まれる。具体的には、レベル1のジャンルから、最下位のレベルのジャンルよりも上位のレベルのジャンルのうちあるレベルのジャンルまでが互いに一致する複数の商品であってもよい。最下位のレベルで同じジャンルに属するか否かを判断すると、同じジャンルに属する商品の範囲が狭くなりすぎる場合があるからである。レベル1のジャンルからどのレベルのジャンルまでが一致する場合に、同じジャンルに属する複数の商品とするかは、例えば、管理者等により予め設定されてもよいし、ジャンルに応じて定められてもよい。
【0058】
ジャンルIDは、ジャンル情報によって定義されるジャンルの識別情報である。親ジャンルIDは、ジャンル情報によって定義されるジャンルの親ジャンルのジャンルIDである。子ジャンルIDリストは、ジャンル情報によって定義されるジャンルの子ジャンルのジャンルIDのリストである。子ジャンルIDリストは、ジャンル情報によって定義されるジャンルが子ジャンルを有する場合に設定される。複数購入対象外フラグは、ジャンル情報によって定義されるジャンルが一般的に1人のユーザにより同時期に複数購入される可能性がある商品のジャンルであるか否かを示す。複数購入対象外フラグがONに設定されている場合、複数購入されない商品のジャンルであることを示し、複数購入対象外フラグがOFFに設定されている場合、複数購入される可能性がある商品のジャンルであることを示す。
【0059】
図4(c)は、店舗情報DB12cに登録される内容の一例を示す図である。店舗情報DB12cには、電子商店街に出店している店舗に関する店舗情報が登録される。具体的に、店舗情報DB12cには、店舗ID、店舗名、郵便番号、住所、電話番号、電子メールアドレス、取扱ジャンル情報等の店舗の属性が、店舗ごとに対応付けて登録される。店舗IDは、店舗の識別情報である。取扱ジャンル情報は、店舗が取り扱っている商品(店舗が販売している商品)のジャンルを示す情報である。具体的に、取扱ジャンル情報には、店舗が取り扱っている商品のジャンルごとにジャンルIDが設定されている。
【0060】
図4(d)は、商品情報DB12dに登録される内容の一例を示す図である。商品情報DB12dには、電子商店街で販売されている商品に関する商品情報が登録される。具体的に、商品情報DB12dには、商品ID、店舗ID、商品コード、ジャンルID、商品名、商品画像のURL(Uniform Resource Locator)、商品説明、商品価格等の商品の属性が、店舗が販売する商品ごとに対応付けて登録される。商品ID(本発明における取引対象を示す情報の一例)は、店舗等が、販売する商品を管理するための商品の識別情報である。店舗IDは、商品の販売元の店舗を示す。商品コードは、商品を識別するコード番号である。商品コードとしては、例えば、JAN(Japanese Article Number Code)コード等がある。ジャンルIDは、商品が属するジャンルのジャンルIDである。商品情報に設定されるジャンルIDは、基本的に最下位のレベルに定義されているジャンル(木構造における葉ノードに相当するジャンル)のジャンルIDが設定される。つまり、各商品は、最も細分化されたジャンルでジャンル分けされている。
【0061】
図4(e)は、閲覧履歴DB12eに登録される内容の一例を示す図である。閲覧履歴DB12eには、電子商店街の商品ページの閲覧履歴が登録される。具体的に、閲覧履歴DB12eには、商品ID、閲覧日時及びユーザIDが、商品ページが閲覧されるごとに対応付けて登録される。商品IDは、商品ページが閲覧された商品を示す。閲覧日時は、商品ページが閲覧された日時を示す。具体的に、閲覧日時は、電子商取引サーバ1がユーザ端末3へ商品ページを送信した日時である。ユーザIDは、商品ページを閲覧したユーザを示す。
【0062】
図4(f)は、購入履歴DB12fに登録される内容の一例を示す図である。購入履歴DB12fには、ユーザによる商品の購入履歴が登録される。具体的に、購入履歴DB12fには、注文コード、購入日時、ユーザID、商品ID、店舗ID、商品コード、購入数等が、商品の購入ごとに対応付けて登録される。注文コードは、商品の注文が行われるたびに付与される注文の識別情報である。ユーザIDは、購入したユーザを示す。商品ID及び商品コードは、購入された商品を示す。店舗IDは、購入先の店舗を示す。購入数は、購入された商品の個数である。
【0063】
図4(g)は、お気に入り情報DB12gに登録される内容の一例を示す図である。お気に入り情報DB12gには、ユーザのお気に入りに関するお気に入り情報(本発明における参照リスト情報の一例)が登録される。具体的に、お気に入り情報DB12gには、ユーザID、商品ID、登録日時等が、お気に入りに商品が登録されるごとに対応付けて登録される。ユーザIDは、お気に入りへの登録を行ったユーザを示す。商品IDは、お気に入りに登録された商品を示す。また、商品IDは、お気に入りに登録された商品の商品ページへの参照に相当する情報である。商品ページへの実際の参照の情報はURLであるが、商品ページのURLは、商品IDから特定することが可能である。なお、商品ページのURLが、商品IDとともにまたは商品IDの代わりにお気に入り情報DB12gに登録されるようになっていてもよい。登録日時は、お気に入りへの登録が行われた日時を示す。
【0064】
図4(h)は、お気に入り登録削除履歴DB12hに登録される内容の一例を示す図である。お気に入り登録削除履歴DB12hには、お気に入りに対する商品の登録や削除の履歴であるお気に入り登録削除履歴が登録される。具体的に、お気に入り登録削除履歴DB12hには、ユーザID、操作種別、操作日時、商品ID等が、お気に入りに対して商品が登録されたり削除されたりするごとに対応付けて登録される。ユーザIDは、お気に入りに対して商品の登録または削除を行ったユーザを示す。操作種別は、お気に入りへの登録が行われたか、またはお気に入りからの削除が行われたかの何れかを示す。操作日時は、お気に入りに対して商品の登録または削除が行われた日時を示す。商品IDは、お気に入りに対して登録または削除された商品を示す。
【0065】
なお、記憶部12には、例えば、商品コード別に商品に関する情報(例えば、商品の正式名称、商品のジャンルのジャンルID、商品の仕様等)が登録されるカタログDB等のデータベースも構築されている。
【0066】
次に、記憶部12に記憶されるその他の情報について説明する。記憶部12には、Webページを表示するためのHTML(HyperText Markup Language)文書、XML(Extensible Markup Language)文書、画像データ、テキストデータ、電子文書等の各種データが記憶されている。また、記憶部12には、管理者等により設定された各種の設定値が記憶されている。
【0067】
また、記憶部12には、オペレーティングシステム、WWW(World Wide Web)サーバプログラム、DBMS(Database Management System)、電子商取引管理プログラム等の各種プログラムが記憶されている。電子商取引管理プログラムは、電子商取引に関する各種の処理を実行するためのプログラムである。なお、各種プログラムは、例えば、他のサーバ装置等からネットワークNWを介して取得されるようにしてもよいし、DVD(Digital Versatile Disc)等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。
【0068】
入出力インターフェース13は、通信部11及び記憶部12とシステム制御部14との間のインターフェース処理を行うようになっている。
【0069】
システム制御部14は、CPU14a、ROM(Read Only Memory)14b、RAM(Random Access Memory)14c等により構成されている。そして、システム制御部14は、CPU14aが、各種プログラムを読み出し実行することにより、本発明における取得手段、予測手段、判定手段、登録数取得手段、購入数取得手段、数判定手段及び占有率取得手段として機能するようになっている。
【0070】
なお、電子商取引サーバ1が、複数のサーバ装置で構成されてもよい。例えば、お気に入りに関する処理を行うサーバ装置、電子商店街において商品の検索や注文等の処理を行うサーバ装置、商品の需要の予測の処理を行うサーバ装置、ユーザ端末3からのリクエストに応じてWebページを送信するサーバ装置、及びデータベースを管理するサーバ装置等が、互いにLAN等で接続されてもよい。
【0071】
[3.電子商取引システムの動作]
次に、電子商取引システムSの動作について、
図5乃至
図7を用いて説明する。
【0072】
図5は、本実施形態に係る電子商取引サーバ1のシステム制御部14の需要予測リクエスト受信時処理における処理例を示すフローチャートである。
【0073】
店舗の従業員等は、商品の需要の予測を要求するため、店舗端末2を操作する。すると、店舗端末2は、需要予測リクエストを電子商取引サーバ1へ送信する。需要予測リクエストは、商品の需要の予測を要求する店舗の店舗IDが設定されている。需要予測リクエスト受信時処理は、電子商取引サーバ1が店舗端末2から需要予測リクエストを受信したときに開始される。
【0074】
先ず、システム制御部14は、需要の予測対象の商品の商品コードを取得する(ステップS1)。例えば、店舗の従業員等が需要の予測対象の商品の商品コードを指定し、システム制御部14が、指定された商品コードを店舗端末2から取得してもよい。また、システム制御部14は、需要予測リクエストに設定された店舗IDを含む店舗情報から取扱ジャンル情報を取得し、取扱ジャンル情報に基づいて、需要の予測を要求した店舗が取り扱っているジャンルの商品の商品コードを複数取得してもよい。また、システム制御部14は、需要予測リクエストに設定された店舗IDを含む各商品情報から、需要の予測を要求した店舗が取り扱っている商品の商品コードを取得してもよい。
【0075】
次いで、システム制御部14は、需要の予測対象の商品のインデックスiに1を設定する(ステップS2)。次いで、システム制御部14は、需要の予測対象の商品のうち1つを、商品iとして選択する(ステップS3)。次いで、システム制御部14は、1商品需要予測処理を実行する(ステップS4)。
【0076】
図6は、本実施形態に係る電子商取引サーバ1のシステム制御部14の1商品需要予測処理における処理例を示すフローチャートである。1商品需要予測処理において、システム制御部14は、予測手段として、商品iの需要を予測する。
【0077】
先ず、システム制御部14は、商品iの電子商店街全体における需要の値を示す総需要iに0を設定する(ステップS21)。次いで、システム制御部14は、商品iの商品コードに対応するジャンルIDを、カタログDBから取得する(ステップS22)。次いで、システム制御部14は、取得したジャンルIDを含むジャンル情報から、複数購入対象外フラグを取得する(ステップS23)。次いで、システム制御部14は、商品情報DB12dから商品iの商品コードを含む商品情報を検索し、検索された各商品情報から商品IDを取得する(ステップS24)。つまり、システム制御部14は、商品iを販売している各店舗において商品iに付与されている商品IDを取得する。次いで、システム制御部14は、取得手段として、ステップS24において取得した商品IDごとに、お気に入り情報DB12gから商品IDを含むお気に入り情報を検索して取得する(ステップS25)。つまり、システム制御部14は、商品iをお気に入りとして登録していることを示すお気に入り情報を全て取得する。
【0078】
次いで、システム制御部14は、取得したお気に入り情報のうち1つを選択する。そして、システム制御部14は、選択したお気に入り情報に設定されているユーザIDを、処理対象のユーザIDとして取得する(ステップS26)。次いで、システム制御部14は、1ユーザ需要予測処理を実行する(ステップS27)。
【0079】
図7は、本実施形態に係る電子商取引サーバ1のシステム制御部14の1ユーザ需要予測処理における処理例を示すフローチャートである。1ユーザ需要予測処理において、システム制御部14は、処理対象ユーザの商品iに対する需要を予測する。なお、
図7に示す処理例は、1人分に応じた需要は商品1個分であるとした場合の処理例である。
【0080】
先ず、システム制御部14は、商品情報DB12dから処理対象ユーザのユーザIDを含むお気に入り情報を検索する(ステップS51)。次いで、システム制御部14は、検索されたお気に入り情報から商品IDを取得する。そして、システム制御部14は、商品IDを含む商品情報からジャンルIDを取得する(ステップS52)。次いで、システム制御部14は、登録数取得手段として、ステップS52において取得したジャンルIDのうち、1商品需要予測処理のステップS22において取得した商品iのジャンルIDと一致する数を計算する。これにより、システム制御部14は、対象ユーザがお気に入りに登録している商品のうち商品iが属するジャンルの商品の数である同一ジャンル登録数を計算する(ステップS53)。
【0081】
次いで、システム制御部14は、判定手段として、1商品需要予測処理のステップS23において取得した複数購入対象外フラグがONに設定されているか否かを判定する(ステップS54)。このとき、システム制御部14は、複数購入対象外フラグがONに設定されていると判定した場合には(ステップS54:YES)、対象ユーザの需要の予測値として、1/同一ジャンル登録数を設定する(ステップS55)。
【0082】
一方、システム制御部14は、複数購入対象外フラグがOFFに設定されていると判定した場合には(ステップS54:NO)、処理対象ユーザのユーザIDを含む購入履歴を検索する(ステップS56)。次いで、システム制御部14は、検索された各購入履歴から商品IDを取得する。そして、システム制御部14は、取得した商品IDを含む商品情報からジャンルIDを取得する(ステップS57)。次いで、システム制御部14は、検索された購入履歴の中から、その購入履歴に含まれる商品IDが1商品需要予測処理のステップS22において取得した商品iのジャンルIDと一致する購入履歴を抽出する(ステップS58)。つまり、システム制御部14は、商品iが属するジャンルの商品を対象ユーザが購入したことを示す購入履歴を抽出する。
【0083】
次いで、システム制御部14は、購入数取得手段として、抽出した購入履歴に基づいて、同時期購入数を計算する(ステップS59)。具体的に、システム制御部14は、現在から遡って同時期とみなす期間(例えば、1時間、1日、1週間、1ヶ月等)ごとに、その期間に購入日時が含まれる購入履歴を特定する。次いで、システム制御部14は、各期間において特定した各購入履歴に含まれる購入数の和を計算して、期間ごとの購入数を計算する。例えば、同時期とみなす期間を1日とする。この場合、システム制御部14は、昨日の購入数、今日の2日前の購入数、3日前の購入数・・・を計算する。どこまで遡って計算するかは、例えば、予め設定されている。次いで、システム制御部14は、期間ごとに計算した購入数のうち、1以上を示す購入数の平均値を計算することにより、同時期購入数を計算する。同時期購入数は、あくまでもユーザがあるジャンルの商品を購入した時期において、そのジャンルの商品をその時期に購入した数であるので、購入がなかった期間(購入数が0である期間)は、同時期購入数の計算には含まれない。例えば、同時期とみなす期間を1日とし、昨日から1週間前まで1日ごとの購入数を計算したとする。このとき、それぞれの購入数が、0、0、3、0、0、1である場合、同時期購入数は、(1+3)/2=2である。なお、電子商取引サーバ1は、購入数の平均値を計算するのではなく、例えば、ユーザが現在から直近に購入を行った期間における購入数を、同時期購入数としてもよい。例えば、上述の例では、3日前の購入数である3が、同時期購入数とされる。また例えば、電子商取引サーバ1は、期間ごとに計算した購入数のうち最大の購入数を同時購入数としてもよい。また、商品iが属するジャンルの商品のうちユーザが同時に購入した商品の数を同時期購入数としてもよい。つまり、システム制御部14は、購入日時が同一である購入履歴ごとに、商品iが属するジャンルの商品の購入数を計算して、例えば、購入数の平均値を計算したり、最大の購入数を特定したりすることにより、同時期購入数を求めてもよい。
【0084】
システム制御部14は、同時期購入数を計算すると、数判定手段として、同時期購入数が同一ジャンル登録数以上であるか否かを判定する(ステップS60)。このとき、システム制御部14は、同時期購入数が同一ジャンル登録数以上であると判定した場合には(ステップS60:YES)、対象ユーザの需要の予測値として、1を設定する(ステップS61)。一方、システム制御部14は、同時期購入数が同一ジャンル登録数以上ではないと判定した場合には(ステップS60:NO)、対象ユーザの需要の予測値として、同時期購入数/同一ジャンル登録数を設定する(ステップS62)。システム制御部14は、対象ユーザの需要の予測値の設定を終えると(ステップS55、S61またはS62)、1ユーザ需要予測処理を終了させる。
【0085】
次いで、システム制御部14は、
図6に示すように、1ユーザ需要予測処理で設定された対象ユーザの需要の予測値を、総需要iに加算する(ステップS28)。次いで、システム制御部14は、ステップS25において取得したお気に入り情報のうちまだ選択していないお気に入り情報があるか否かを判定する(ステップS29)。このとき、システム制御部14は、まだ選択していないお気に入り情報があると判定した場合には(ステップS29:YES)、まだ選択していないお気に入り情報のうち1つを選択する。そして、システム制御部14は、選択したお気に入り情報に設定されているユーザIDを、処理対象のユーザIDとして取得する(ステップS30)。次いで、システム制御部14は、ステップS27に移行する。システム制御部14は、ステップS27〜S30の処理を繰り返すことにより、商品iをお気に入りに登録している各ユーザの需要の予測値の和を、総需要iとして計算する。
【0086】
そして、システム制御部14は、全てのお気に入り情報を選択したと判定した場合には(ステップS29:NO)、ステップS24において取得した商品iの商品IDごとに、お気に入り登録削除履歴DB12hから、取得した商品IDを含むお気に入り登録削除履歴を検索する(ステップS31)。つまり、システム制御部14は、お気に入りに対する商品iの登録及び削除の履歴を検索する。このとき、システム制御部14は、操作日時が予め設定された期間(例えば、現在から1週間前までの期間、現在から1ヶ月前までの期間等)に含まれるお気に入り登録削除履歴のみを検索する。次いで、システム制御部14は、検索されたお気に入り登録削除履歴に基づいて、商品iのお気に入りの登録数の増減数を計算する(ステップS32)。具体的に、システム制御部14は、操作種別が登録を示すお気に入り登録削除履歴の数から、操作種別が削除を示すお気に入り登録削除履歴の数を減算することにより、増減数を計算する。次いで、システム制御部14は、計算した増減数に基づいて、総需要iを補正する(ステップS33)。例えば、システム制御部14は、増減数がマイナスである場合には、増減数に予め設定された係数を乗算し、乗算した結果を総需要iに加算してもよい。
【0087】
次いで、システム制御部14は、購入履歴DB12fから商品iの商品コードを含む購入履歴を検索する。このとき、システム制御部14は、購入日時が予め設定された期間に含まれる購入履歴のみを検索する。そして、システム制御部14は、検索された各購入履歴に含まれる購入数の和を計算することにより、予め設定された期間における商品iの総販売数を計算する(ステップS34)。次いで、システム制御部14は、検索された購入履歴の中から、商品の需要の予測を要求した店舗の店舗IDを含む購入履歴を抽出する。そして、システム制御部14は、抽出された各購入履歴に含まれる購入数の和を計算することにより、商品の需要の予測を要求した店舗の予め設定された期間における商品iの販売数を計算する(ステップS35)。次いで、システム制御部14は、占有率取得手段として、商品の需要の予測を要求した店舗の販売数を総販売数で除算することにより、商品の需要の予測を要求した店舗の商品iの市場占有率を計算する(ステップS36)。次いで、システム制御部14は、総需要iに市場占有率を乗算することにより、商品の需要の予測を要求した店舗の需要の値を示す店舗需要iを計算する(ステップS37)。システム制御部14は、この処理を終えると、1商品需要予測処理を終了させる。
【0088】
次いで、システム制御部14は、
図5に示すように、需要の予測対象の商品のうちまだ選択していない商品があるか否かを判定する(ステップS5)。このとき、システム制御部14は、まだ選択していない商品があると判定した場合には(ステップS5:YES)、インデックスiに1を加算する(ステップS6)。次いで、システム制御部14は、まだ選択していない商品のうち1つを、商品iとして選択する(ステップS7)。次いで、システム制御部14は、ステップS4に移行する。システム制御部14は、ステップS4〜S7の処理を繰り返すことにより、需要の予測対象の各商品の店舗需要を計算する。
【0089】
そして、システム制御部14は、全ての商品を選択したと判定した場合には(ステップS5:NO)、各商品の店舗需要に基づいて、予測した需要を示す情報を生成する(ステップS8)。このとき、システム制御部14は、需要の予測対象の商品の中に同一のジャンルに属する商品が複数存在する場合には、同一のジャンルに属する商品間における大小関係を示す情報を生成する。例えば、システム制御部14は、
図2(a)に示すように、店舗需要の値をそのまま示す情報を生成してもよい。また例えば、システム制御部14は、店舗需要の比率を計算し、
図2(b)に示すように、比率を示す情報を生成してもよい。また例えば、システム制御部14は、店舗需要の比較を行うことにより、
図2(c)に示すような情報を生成してもよい。また、システム制御部14は、ある商品について、同一のジャンルに属する他の商品が存在しない場合には、店舗需要の値をそのまま示す情報を生成してもよい。また例えば、システム制御部14は、
図2(d)や
図2(e)に示すように、需要を示す情報に、お気に入りの登録数の増減数の情報を付加してもよい。
【0090】
次いで、システム制御部14は、需要を示す情報を含む商品需要予測結果ページを生成し、需要予測リクエストの送信元の店舗端末2へ、生成した商品需要予測結果ページを送信する(ステップS9)。システム制御部14は、この処理を終えると、需要予測リクエスト受信時処理を終了させる。
【0091】
なお、システム制御部14は、ステップS22、S53及びS57において、カタログDBや商品情報DB12dからジャンルIDを取得し、ステップS53及びS58において、取得したジャンルID同士が一致するか否かを判定していた。つまり、システム制御部14は、商品が分類されている最下位のジャンルを比較することにより、需要の予測対象の商品と同じジャンルに属する商品を特定していた。しかしながら、システム制御部14は、カタログDBや商品情報DB12dから取得したジャンルIDが示すジャンルの先祖のジャンルのジャンルIDが一致するか否かを判定してもよい。つまり、システム制御部14は、最下位のレベルのジャンルではなく、そのジャンルよりも上位のジャンルで、需要の予測対象の商品と同じジャンルに属する商品を特定してもよい。最下位のレベルで同じジャンルに属するか否かを判定すると、同じジャンルに属する商品の範囲が狭くなりすぎる場合があるからである。また、ステップS8において同じジャンルに属する複数の商品を特定する場合についても同様である。ジャンル情報DB12bに登録されているジャンル情報に含まれている親ジャンルIDにより、ジャンル情報により定義されているジャンルの親ジャンルを特定することができる。そのため、親ジャンルIDを手がかりとして、ジャンル情報DB12bから先祖のジャンルのジャンルIDを取得することができる。
【0092】
以上説明したように、本実施形態によれば、電子商取引サーバ1のシステム制御部14が、お気に入り情報DB12gから複数のお気に入り情報を取得し、取得されたお気に入り情報に基づいて、商品の需要を予測する。従って、例えば、過去の購入数に基づく需要の予測や商品ページへのアクセス数に基づく需要の予測よりも正確に需要を予測することができる。
【0093】
また、システム制御部14が、複数のジャンルのうち少なくとも1つのジャンルが同じジャンルに属する複数の商品間における需要の大小関係を予測する。従って、複数の商品間で需要を比較することができる。
【0094】
また、システム制御部14が、お気に入り情報DB12gから取得されたお気に入り情報と、お気に入り登録削除履歴DB12hに登録されたお気に入り登録削除履歴とに基づいて、商品の需要を予測する。従って、お気に入り登録削除履歴を更に考慮することにより、需要の予測精度を高めることができる。
【0095】
また、システム制御部14が、需要の予測対象の商品が属するジャンルの複数購入対象外フラグがONであるか否かを判定し、需要の予測対象の商品が属するジャンの商品の同一ジャンル登録数をユーザごとに計算し、複数購入対象外フラグがOFFであると判定された場合、1人分に対応する需要を各ユーザの需要に設定し、複数購入対象外フラグがONであると判定された場合、1人分に対応する需要に対して同一ジャンル登録数の1となる需要を各ユーザの需要に設定し、予測対象の商品をお気に入りに登録している各ユーザのその商品に対する需要の和を計算してその和に応じた需要を予測する。従って、1人のユーザから同時期に1つのみ購入されるようなジャンルの商品が1人のユーザのお気に入りに複数登録されていても、その中からユーザが購入する商品は1つである蓋然性が高いことを考慮した需要の予測を行うことができるので、需要の予測精度を高めることができる。
【0096】
また、システム制御部14が、購入履歴DB12fに登録された購入履歴に基づいて、予測対象の商品が属するジャンルの商品の同時期購入数をユーザごとに計算し、同時期購入数が同一ジャンル登録数以上であるか否かをユーザごとに判定し、需要の予測対象の商品が属するジャンルの複数購入対象外フラグがOFFである場合において、同時期購入数が同一ジャンル登録数以上であると判定されたユーザの需要に1人分に対応する需要を設定し、同時期購入数が同一ジャンル登録数以上ではないと判定されたユーザの需要に、1人分に対応する需要を同時期購入数倍し、その結果に対して同一ジャンル登録数分の1となる需要を設定する。従って、1人のユーザから同時期に複数購入される可能性があるジャンルの商品が1人のユーザのお気に入りに複数登録されている場合、各ユーザの購入の傾向を考慮した需要の予測を行うことができるので、需要の予測精度を高めることができる。
【0097】
また、システム制御部14が、需要の予測対象の商品を販売する複数の店舗のうち需要の予測を要求した店舗による需要の予測対象の商品の市場占有率を計算し、お気に入り情報DB12gから取得されたお気に入り情報と市場占有率とに基づいて、需要の予測を要求した店舗の需要を予測する。従って、需要を知りたい店舗に対する需要を予測することができる。
【0098】
なお、上記実施形態においては、本発明における取引対象が商品に適用されていた。しかしながら、取引対象がサービスに適用されてもよい。そして、電子商取引のシステムとして、サービスの予約が可能なシステムに本発明が適用されてもよい。サービスの予約としては、例えば、宿泊施設の宿泊予約、ゴルフ場等の競技施設の利用予約、交通機関の座席の予約等がある。