情報処理装置、情報処理方法、情報処理プログラム、及び記録媒体
【課題】取引対象の需要をより正確に予測する。
【解決手段】情報処理装置は、取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の参照リスト情報を取得する取得手段と、取得手段により取得された参照リスト情報に基づいて、取引対象の需要を予測する予測手段と、を備える。
【解決手段】情報処理装置は、取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の参照リスト情報を取得する取得手段と、取得手段により取得された参照リスト情報に基づいて、取引対象の需要を予測する予測手段と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、取引対象の需要を予測する情報処理装置の技術分野に関する。
【背景技術】
【０００２】
従来、商品やサービス等の取引対象の販売にあたって、取引対象の需要の予測が行われることがある。このような予測は、例えば、過去の取引対象の販売実績に基づいて行われている。具体的には、過去の販売数が多いほど、需要があると予測されたり、過去の販売数の変化の態様に応じて、需要が予測されたりする。
【０００３】
また、特許文献１には、商品の記事が掲載されたサイトへのアクセス数に基づいて、商品の需要を予測する技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７ー０３４９６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、過去の販売実績に基づく需要予測では、正確に需要を予測することができるとは限らない。販売数は、取引対象の価格や商品の在庫の有無等の要因に影響されるので、ユーザの需要を正確に反映していない場合があるからである。また、特許文献１に開示されているように、取引対象の情報へのアクセス数に基づく需要予測においても、正確に需要を予測することができるとはいえない。取引対象の情報へアクセスしたユーザがその取引対象の購入に興味を持っているとは必ずしもいえないからからである。
【０００６】
本発明は、以上の点に鑑みてなされたものであり、取引対象の需要をより正確に予測することができる情報処理装置、情報処理方法、情報処理プログラム、及び記録媒体を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、請求項１に記載の発明は、取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の前記参照リスト情報を取得する取得手段と、前記取得手段により取得された前記参照リスト情報に基づいて、取引対象の需要を予測する予測手段と、を備えることを特徴とする。
【０００８】
ユーザにより参照リストに登録された取引対象はそのユーザから購入される蓋然性がある。この発明によれば、購入される蓋然性がある取引対象を示す参照リスト情報に基づいて需要が予測されるので、より正確に需要を予測することができる。
【０００９】
請求項２に記載の発明は、請求項１に記載の情報処理装置において、前記予測手段は、取引対象の複数の区分のうち少なくとも１つの区分が同じ区分に属する複数の取引対象間における需要の大小関係を予測することを特徴とする。
【００１０】
この発明によれば、複数の取引対象間で需要を比較することができる。
【００１１】
請求項３に記載の発明は、請求項１または請求項２に記載の情報処理装置において、前記予測手段は、前記取得手段により取得された前記参照リスト情報と、ユーザによる前記参照リストからの取引対象の削除履歴を記憶する削除履歴記憶手段に記憶された前記削除履歴とに基づいて、該取引対象の需要を予測することを特徴とする。
【００１２】
ユーザが参照リストから削除した取引対象はそのユーザが購入に興味を失った蓋然性がある。この発明によれば、参照リストからの取引対象の削除の履歴を更に考慮することにより、需要の予測精度を高めることができる。
【００１３】
請求項４に記載の発明は、請求項１乃至３の何れか１項に記載の情報処理装置において、取引対象の複数の区分のうち需要の予測対象の取引対象が属する区分が１人のユーザから同時期に複数購入される取引対象の区分であるか否かを判定する判定手段と、前記予測対象の取引対象が属する区分の取引対象の前記参照リストの登録数をユーザごとに取得する登録数取得手段と、を更に備え、前記特定手段は、前記予測対象の取引対象を前記参照リストに登録している各ユーザの該取引対象に対する需要の和を計算して該和に応じた需要を予測し、前記判定手段により複数購入される取引対象の区分であると判定された場合、予め設定された設定需要を各ユーザの需要に設定し、前記判定手段により複数購入される取引対象の区分ではないと判定された場合、前記登録数取得手段によりユーザごとに取得された前記登録数に基づいて各ユーザの需要の設定を行うことを特徴とする。
【００１４】
この発明によれば、１人のユーザから同時期に１つのみ購入されるような区分に属する取引対象の需要の予測においては、その区分の取引対象がユーザによって参照リストに登録されている数に基づいてそのユーザの需要が予測される。そのため、このような区分の取引対象が１人のユーザの参照リストに複数登録されていても、その中からユーザが購入する取引対象は１つである蓋然性が高いことを考慮した需要の予測を行うことができるので、需要の予測精度を高めることができる。
【００１５】
請求項５に記載の発明は、請求項４に記載の情報処理装置において、ユーザにより購入された取引対象の区分を示す情報と、購入したユーザを示す情報と、購入時期とを対応付けて購入履歴として記憶する購入履歴記憶手段に記憶された前記購入履歴に基づいて、前記予測対象の取引対象が属する区分の取引対象の同時期における購入数をユーザごとに取得する購入数取得手段と、前記購入数取得手段により取得された前記購入数が前記登録数取得手段により取得された前記登録数以上であるか否かをユーザごとに判定する数判定手段と、を更に備え、前記判定手段により複数購入される取引対象の区分であると判定された場合、前記特定手段は、前記数判定手段により前記購入数が前記登録数以上であると判定されたユーザの需要に前記設定需要を設定し、前記数判定手段により前記購入数が前記登録数以上ではないと判定されたユーザの需要に、前記購入数と前記登録数とに基づいて、前記設定需要未満となる需要を設定することを特徴とする。
【００１６】
この発明によれば、１人のユーザから同時期に複数購入される可能性がある区分に属する取引対象の需要の予測においては、購入履歴に基づいてその区分の取引対象がユーザによる同時期における購入数が取得され、その購入数が、その区分の取引対象がユーザにより参照リストに登録されている数よりも少ない場合には、購入数と参照リストに登録されている数とに基づいて、そのユーザの需要が予め設定された需要よりも小さく予測される。そのため、このような区分の取引対象が１人のユーザの参照リストに複数登録されている場合、各ユーザの購入の傾向を考慮した需要の予測を行うことができるので、需要の予測精度を高めることができる。
【００１７】
請求項６に記載の発明は、請求項１乃至５の何れか１項に記載の情報処理装置において、需要の予測対象の取引対象を販売する複数の販売者のうち需要の予測を要求した販売者による該取引対象の市場占有率を取得する占有率取得手段を更に備え、前記予測手段は、前記取得手段により取得された前記参照リスト情報と、前記占有率取得手段により取得された前記市場占有率とに基づいて、需要の予測を要求した販売者の需要を予測することを特徴とする。
【００１８】
この発明によれば、需要を知りたい販売者に対する需要を予測することができる。
【００１９】
請求項７に記載の発明は、コンピュータにより実行される情報処理方法であって、取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の前記参照リスト情報を取得する取得ステップと、前記取得ステップにおいてり取得された前記参照リスト情報に基づいて、取引対象の需要を予測する予測ステップと、を含むことを特徴とする。
【００２０】
請求項８に記載の発明は、情報処理装置に含まれるコンピュータを、取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の前記参照リスト情報を取得する取得手段、及び、前記取得手段により取得された前記参照リスト情報に基づいて、取引対象の需要を予測する予測手段、として機能させることを特徴とする。
【００２１】
請求項９に記載の発明は、情報処理装置に含まれるコンピュータを、取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の前記参照リスト情報を取得する取得手段、及び、前記取得手段により取得された前記参照リスト情報に基づいて、取引対象の需要を予測する予測手段、として機能させる情報処理プログラムがコンピュータ読み取り可能に記憶されていることを特徴とする。
【発明の効果】
【００２２】
本発明によれば、購入される蓋然性がある取引対象を示す参照リスト情報に基づいて需要が予測されるので、より正確に需要を予測することができる。
【図面の簡単な説明】
【００２３】
【図１】本実施形態に係る電子商取引システムＳの概要構成の一例を示す図である。
【図２】（ａ）乃至（ｅ）は、商品需要予測結果ページ内における需要の予測結果を示す情報の表示例である。
【図３】本実施形態に係る電子商取引サーバ１の概要構成の一例を示すブロック図である。
【図４】（ａ）は、会員情報ＤＢ１２ａに登録される内容の一例を示す図であり、（ｂ）は、ジャンル情報ＤＢ１２ｂに登録される内容の一例を示す図であり、（ｃ）は、店舗情報ＤＢ１２ｃに登録される内容の一例を示す図であり、（ｄ）は、商品情報ＤＢ１２ｄに登録される内容の一例を示す図であり、（ｅ）は、閲覧履歴ＤＢ１２ｅに登録される内容の一例を示す図であり、（ｆ）は、購入履歴ＤＢ１２ｆに登録される内容の一例を示す図であり、（ｇ）は、お気に入り情報ＤＢ１２ｇに登録される内容の一例を示す図であり、（ｈ）は、お気に入り登録削除履歴ＤＢ１２ｈに登録される内容の一例を示す図である。
【図５】本実施形態に係る電子商取引サーバ１のシステム制御部１４の需要予測リクエスト受信時処理における処理例を示すフローチャートである。
【図６】本実施形態に係る電子商取引サーバ１のシステム制御部１４の１商品需要予測処理における処理例を示すフローチャートである。
【図７】本実施形態に係る電子商取引サーバ１のシステム制御部１４の１ユーザ需要予測処理における処理例を示すフローチャートである。
【発明を実施するための形態】
【００２４】
以下、図面を参照して本発明の実施形態について詳細に説明する。なお、以下に説明する実施の形態は、電子商取引システムに対して本発明を適用した場合の実施形態である。
【００２５】
［１．電子商取引システムの構成及び機能概要］
［１−１．電子商取引システムの構成］
先ず、本実施形態に係る電子商取引システムＳの構成について、図１を用いて説明する。図１は、本実施形態に係る電子商取引システムＳの概要構成の一例を示す図である。
【００２６】
図１に示すように、電子商取引システムＳは、電子商取引サーバ１と、複数の店舗端末２と、複数のユーザ端末３と、を含んで構成されている。そして、電子商取引サーバ１と各店舗端末２及び各ユーザ端末３とは、ネットワークＮＷを介して、例えば、通信プロトコルにＴＣＰ／ＩＰ等を用いて相互にデータの送受信が可能になっている。なお、ネットワークＮＷは、例えば、インターネット、専用通信回線（例えば、ＣＡＴＶ（Community Antenna Television）回線）、移動体通信網（基地局等を含む）、及びゲートウェイ等により構築されている。
【００２７】
電子商取引サーバ１（本発明における情報処理装置の一例）は、商品の購入が可能な電子商店街に関する各種処理を実行するサーバ装置である。ユーザは、電子商店街を利用することにより、所望の店舗から所望の商品を購入することができる。電子商取引サーバ１は、店舗端末２やユーザ端末３からのリクエストに応じて、例えば、電子商店街のＷｅｂページを送信したり、商品の検索、購入等に関する処理を行ったりする。
【００２８】
店舗端末２は、電子商店街に出店している店舗の従業員等により利用される端末装置である。店舗端末２は、例えば、販売する商品の情報を電子商店街に登録したり、商品の注文内容を確認したりするために用いられる。また、店舗端末２は、従業員等からの操作に基づいて電子商取引サーバ１にアクセスすることにより、電子商取引サーバ１からＷｅｂページを受信して表示する。店舗端末２には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。店舗端末２としては、例えば、パーソナルコンピュータ等が用いられる。
【００２９】
ユーザ端末３は、電子商店街を利用するユーザの端末装置である。ユーザ端末３は、ユーザからの操作に基づいて電子商取引サーバ１にアクセスすることにより、電子商取引サーバ１からＷｅｂページを受信して表示する。ユーザ端末３には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。ユーザ端末３としては、例えば、パーソナルコンピュータ、ＰＤＡ（Personal Digital Assistant）、スマートフォン等の携帯情報端末、携帯電話機等が用いられる。
【００３０】
［１−２．お気に入りに基づく需要の予測］
電子商取引システムＳにおいては、お気に入り機能が提供されている。お気に入り機能とは、電子商店街で販売されている商品をユーザのお気に入りとして登録することにより、商品ページへの参照をユーザ専用のリストに保持しておき、お気に入りの商品の商品ページをユーザが容易に閲覧することができるようにする機能である。商品ページは、１つの商品に関する詳細な情報が表示されるＷｅｂページである。また、お気に入りの商品は、単にお気に入りともいう。電子商店街においては、商品ページに、「お気に入りに追加」と表示されたハイパーリンク（以下、「リンク」という）が表示されている。ユーザがこのリンクを選択すると、商品ページに情報が表示されている商品が、ユーザのお気に入りに登録される。ユーザは、お気に入りに登録されている商品を、お気に入りページで確認することができる。お気に入りページは、お気に入りに登録されている商品の一覧が表示されるＷｅｂページであり、ユーザごとに専用のＷｅｂページである。また、お気に入りページには、お気に入りに登録された商品の商品ページへのリンクが埋め込まれている。お気に入りページにおいて、ユーザは、任意の商品のリンクを選択すると、対応する商品ページを表示させることができる。また、お気に入りページにおいて、ユーザは、お気に入りに登録されている商品の中から登録しておく必要がない商品を指定してお気に入りから削除することができる。
【００３１】
電子商取引サーバ１は、店舗端末２からの要求に応じて、電子商店街で販売されている商品の需要予測を行い、予測結果を示すＷｅｂページ（以下「商品需要予測結果ページ」という）を店舗端末２へ送信する。具体的に、電子商取引サーバ１は、お気に入りに基づいて、商品の需要を予測する処理を実行する。お気に入りには、例えば、ユーザが気になった商品、購入候補とした商品、ユーザが好きな商品等が登録される。従って、ユーザによりお気に入りに登録されている商品は、お気に入りに登録されていない商品よりも、そのユーザによって将来購入される蓋然性が高い商品であると考えられる。つまり、お気に入りは、将来の商品の需要を表しているといえる。そこで、電子商取引サーバ１は、基本的には、ある商品をお気に入りの登録しているユーザの数（以下、「登録数」という）が多いほど、その商品の需要が大きいと予測する。
【００３２】
従来の需要予測としては、過去の販売数に基づく需要予測がある。しかしながら、過去の販売数に基づく需要予測では、正確に需要を予測することができるとは限らない。販売数は、商品の価格や商品の在庫の有無等の要因に影響されるからである。また、過去の販売数は、これまでの需要の消費量を示している。つまり、過去の販売数が多いと、これまでの商品の販売で、本来あった需要の大部分が消費されてしまっている場合がある。その場合、将来の販売数が急激に落ちることもあり得る。これに対し、お気に入りに基づく需要予測では、商品の価格や商品の在庫の有無等に影響されない。また、上述したように、お気に入りには、ユーザが将来購入する可能性がある商品が登録される。そのため、お気に入りに基づく需要予測は、過去の販売数に基づく需要予測よりも、正確に需要を予測することができる。
【００３３】
また、従来の需要予測として、商品ページ等の商品の情報に対するアクセス数に基づく需要予測がある。アクセス数に基づく需要予測も、ユーザの需要を正確に予測することができるとはいえない。商品ページを閲覧したユーザがその商品ページに情報が掲載されている商品の購入に興味を持っているとは限らないからである。例えば、ユーザは、購入するつもりはなく、単なる興味本位で商品ページを閲覧する場合がある。また、ユーザが、商品ページに掲載された情報を確認した結果、その商品ページに情報が掲載されている商品を購入対象から除外する場合もある。これに対し、お気に入りに商品を登録するというユーザの行為は、ユーザがその商品に興味を持っているという意思表示である蓋然性が高い。そのため、お気に入りに基づく需要予測は、商品ページのアクセス数に基づく需要予測よりも、正確に需要を予測することができる。
【００３４】
次に、お気に入りに基づく具体的な需要の予測方法について説明する。電子商取引サーバ１は、ある商品について、お気に入りに登録しているユーザ１人につき、１人分に応じた需要があるとする。この１人分に応じた需要の大きさは、例えば、電子商取引ステムＳの管理者により予め設定されている。例えば、１人分に応じた需要は、商品１個分の需要があるとしてもよいし、商品１個分よりも大きくても小さくてもよい。例えば、お気に入りに登録しているユーザ１人につき商品１個の需要があるとする。また、商品Ａのお気に入りへの登録数が３０００であり、商品Ｂのお気に入りへの登録数が２０００であるとする。その場合、商品Ａに対して３０００個分の需要があり、商品Ｂに対して２０００個分の需要があることになる。
【００３５】
ところで、各商品はそれぞれジャンル分けされている。商品のジャンル（本発明における区分の一例）は、商品を、例えば種類、性質、用途等で区分したときに、同じような種類、性質、用途等の商品が属する範囲である。ここで、あるジャンルの商品をあるユーザが購入するとき、そのジャンルの商品を同時期に複数購入することが一般的にはないジャンルがある。そのようなジャンルの商品として、例えば、冷蔵庫がある。冷蔵庫は、一般的には１つの家庭で１台購入されると、その家庭ではその後数年の間購入されることがない。例えば、あるユーザが、冷蔵庫の商品Ｃ、Ｄ及びＥをお気に入りに登録しているとする。この場合、そのユーザが商品Ｃ、Ｄ及びＥの全てを購入するつもりでお気に入りに登録しているとは考えにくい。この場合、そのユーザは、商品Ｃ、Ｄ及びＥを購入候補として、その中から何れかの商品を購入するつもりである蓋然性が高い。従って、商品Ｃ、Ｄ及びＥのうち商品Ｃが購入される商品として選択される確率は、単純計算では１／３である。そして、実際に商品Ｃが購入された場合、商品Ｃに対しては現実に需要があったが、商品Ｄ及びＥに対しては現実の需要はなかったことになる。このことから、１人のユーザが同時期に複数購入することが一般的にないジャンルの商品について、あるユーザがお気に入りに登録している数（以下、「同一ジャンル登録数」という）が多いほど、個々の商品に対する将来の需要は小さくなると考えられる。
【００３６】
そこで、電子商取引サーバ１は、このようなジャンルの商品の需要を予測する場合、ユーザごとに同一ジャンル登録数を計算する。そして、電子商取引サーバ１は、同一ジャンル登録数に基づいて、ユーザごとの需要を設定する。具体的に、電子商取引サーバ１は、予め設定された１人分に応じた需要に対して同一ジャンル登録数分の１となる需要を計算することによりユーザごとに需要を計算する。つまり、電子商取引サーバ１は、
【００３７】
あるユーザの需要＝１人分に応じた需要／そのユーザの同一ジャンル登録数
【００３８】
を計算する。そして、電子商取引サーバ１は、各ユーザについて計算した需要の和を計算することで、全ユーザの需要を予測する。
【００３９】
一方、電子商取引サーバ１は、１人のユーザが同時期に複数購入する可能性があるジャンルの商品の需要を予測する場合、同一ジャンル登録数の大きさにかかわらず、１人のユーザにつき予め設定された１人分に応じた需要があるとしてもよい。例えば、洋服は、同時期に複数購入される可能性がある。
【００４０】
あるいは、電子商取引サーバ１は、１人のユーザが同時期に複数購入する可能性があるジャンルの商品の需要を予測する場合、ユーザの過去の購入傾向に基づいてユーザごとの需要を計算し、計算した需要の和を計算することで、全ユーザの需要を予測してもよい。１人のユーザが同時期に複数購入する可能性があるジャンルであるとしても、そのジャンルの商品が複数お気に入りに登録されている場合、登録されている全ての商品が購入されるとは限らない。同時期に何個の商品が購入されるかは、一般的にはユーザごとに異なる。そこで、電子商取引サーバ１は、ユーザごとに、需要の予測対象の商品が属するジャンルの商品について、同時期における購入数（以下、「同時期購入数」という）を算出する。そして、電子商取引サーバ１は、同時期購入数が同一ジャンル登録数以上である場合には、予め設定された１人分に応じた需要があるとする。ユーザが同時期に購入する数が、お気に入りに登録されている商品の数以上であるため、登録されている全ての商品がそのユーザによって購入される蓋然性があるからである。つまり、登録されている全ての商品に対して需要があると考えられるからである。一方、電子商取引サーバ１は、同時期購入数が同一ジャンル登録数未満である場合には、同時期購入数と同一ジャンル登録数に基づいて、予め設定された１人分に応じた需要未満の範囲内でユーザごとに需要を設定する。具体的に電子商取引サーバ１は、予め設定された１人分に応じた需要を同時期購入数倍し、その結果に対して同一ジャンル登録数分の１を計算することにより、ユーザごとの需要を計算する。つまり、電子商取引サーバ１は、
【００４１】
あるユーザの需要＝１人分に応じた需要×そのユーザの同時期購入数／そのユーザの同一ジャンル登録数
【００４２】
を計算する。お気に入りに登録されている商品のうち、ユーザが同時期に購入する数までの需要があると考えられるからである。
【００４３】
また、電子商取引サーバ１は、お気に入りへの商品の登録の履歴やお気に入りからの商品の削除の履歴を記録しておき、この履歴とお気に入りとに基づいて、商品の需要を予測してもよい。例えば、電子商取引サーバ１は、予め設定された期間（例えば、現在から１週間前までの期間、１ヶ月前までの期間等）における需要の予測対象の商品のお気に入りの登録数の増減数に基づいて、商品の需要を補正してもよい。これまでお気に入りの登録数が減っている商品は、この後も登録数が減っていく蓋然性がある。従って、そのような商品は、これから需要が減っていく蓋然性がある。そこで、電子商取引サーバ１は、例えば、お気に入りの登録数が減少した商品については、減少した数が多いほど、その商品の需要を補正前よりも小さくなるように補正してもよい。また、電子商取引サーバ１は、例えば、お気に入りの登録数が増加した商品については、増加した数が多いほど、その商品の需要を補正前よりも大きくなるように補正してもよい。
【００４４】
また、電子商取引サーバ１は、お気に入りからの商品の削除の履歴とお気に入りとに基づいて、商品の需要を予測してもよい。例えば、電子商取引サーバ１は、予め設定された期間におけるお気に入りからの需要の予測対象の商品が削除された数に基づいて、商品の需要を補正してもよい。具体的に、電子商取引サーバ１は、削除された数が多いほど、商品の需要を補正前よりも小さくなるように補正する。
【００４５】
また、電子商取引サーバ１は、需要の予測を要求してきた店舗に対する需要（以下、「店舗需要」という）を予測してもよい。過去の販売実績により、需要の予測を要求してきた店舗の電子商店街における市場占有率を計算することができる。そこで、電子商取引サーバ１は、電子商店街全体における需要（以下、「総需要」という）に市場占有率を乗算することにより、需要の予測を要求してきた店舗の需要を予測することができる。
【００４６】
次に、お気に入りに基づく需要の予測結果を示す情報の表示例について説明する。図２（ａ）乃至（ｅ）は、商品需要予測結果ページ内における需要の予測結果を示す情報の表示例である。
【００４７】
商品需要予測結果ページ内に、複数の商品の需要の情報を同時に表示させる場合がある。この場合、電子商取引サーバ１は、需要の予測対象の商品のうち同じ商品のジャンルに属する複数の商品については、商品間における需要の大小関係を予測し、需要の大小関係を示す情報が商品需要予測結果ページに表示されるようにする。同じジャンルに属する複数の商品は、店舗によって需要が比較される商品同士となるからである。店舗は、需要を比較することにより、例えば、どの商品を仕入れるべきか、どの商品の販売に力を入れるか等を検討する。
【００４８】
例えば、電子商取引サーバ１は、図２（ａ）に示すように、商品Ａは３０００個分、商品Ｂは２０００個分と、各商品のお気に入りへの登録数がそのまま表示されるようにしてもよい。また例えば、電子商取引サーバ１は、図２（ｂ）に示すように、商品Ａ：商品Ｂ＝３：２というように、需要の比率が表示されるようにしてもよい。また、電子商取引サーバ１は、図２（ｃ）に示すように、「商品Ａの方が商品Ｂよりも需要があります」という情報が表示されるようにしてもよいし、「商品Ａ＞商品Ｂ」という情報が表示されてもよい。また、電子商取引サーバ１は、図２（ｄ）に示すように、需要の大小関係を示す情報とともに、予め設定された期間における各商品のお気に入りの登録数の増減数が表示されるようにしてもよい。また、電子商取引サーバ１は、図２（ｅ）に示すように、需要の大小関係を示す情報とともに、各商品のお気に入りの登録数の増減数の推移を示すグラフが表示されるようにしてもよい。
【００４９】
また、需要の予測を要求してきた店舗における需要の予測対象の商品のこれまでの販売数が、お気に入りに基づいて予測された需要に対して相当に小さい場合には、潜在的な需要があるにもかかわらず、何らかの原因（例えば、価格が高い等）で売れ行きがよくないことが考えられる。そこで、電子商取引サーバ１は、このような場合に応じた情報も表示されるようにしてもよい。例えば、「商品Ａの需要は３０００ありますが、何らかの原因で売れ行きが伸びていません。」等の情報が表示されるようにしてもよい。電子商取引サーバ１は、例えば、販売数が予め設定された閾値以下である場合や、販売数が予測された需要の所定数分の１以下である場合等にこのような表示が行われるようにしてもよい。
【００５０】
また、電子商取引サーバ１は、総需要または店舗需要の何れか一方のみが表示されるようにしてもよいし、両方が表示されるようにしてもよい。
【００５１】
［２．電子商取引サーバの構成］
次に、電子商取引サーバ１の構成について、図３及び図４を用いて説明する。
【００５２】
図３は、本実施形態に係る電子商取引サーバ１の概要構成の一例を示すブロック図である。図３に示すように、電子商取引サーバ１は、通信部１１と、記憶部１２と、入出力インターフェース１３と、システム制御部１４と、を備えている。そして、システム制御部１４と入出力インターフェース１３とは、システムバス１５を介して接続されている。
【００５３】
通信部１１は、ネットワークＮＷに接続して、店舗端末２やユーザ端末３等との通信状態を制御するようになっている。
【００５４】
記憶部１２（本発明における記憶手段、削除履歴記憶手段及び購入履歴記憶手段の一例）は、例えば、ハードディスクドライブ等により構成されている。この記憶部１２には、会員情報ＤＢ（データベース）１２ａ、ジャンル情報ＤＢ１２ｂ、店舗情報ＤＢ１２ｃ、商品情報ＤＢ１２ｄ、閲覧履歴ＤＢ１２ｅ、購入履歴ＤＢ１２ｆ、お気に入り情報ＤＢ１２ｇ、お気に入り登録削除履歴ＤＢ１２ｈ等のデータベースが構築されている。
【００５５】
図４（ａ）は、会員情報ＤＢ１２ａに登録される内容の一例を示す図である。会員情報ＤＢ１２ａには、電子商取引システムＳに会員登録しているユーザに関する会員情報が登録される。具体的に、会員情報ＤＢ１２ａには、ユーザＩＤ、パスワード、ニックネーム、氏名、生年月日、性別、郵便番号、住所、電話番号、電子メールアドレス等のユーザの属性が、ユーザごとに対応付けて登録される。ユーザＩＤは、ユーザの識別情報である。
【００５６】
図４（ｂ）は、ジャンル情報ＤＢ１２ｂに登録される内容の一例を示す図である。ジャンル情報ＤＢ１２ｂには、商品のジャンルに関するジャンル情報が登録されている。具体的に、ジャンル情報ＤＢ１２ｂには、ジャンルＩＤ、ジャンル名、ジャンルのレベル、親ジャンルＩＤ、子ジャンルＩＤリスト、複数購入対象外フラグ等のジャンルの属性が、ジャンルごとに対応付けて登録される。ジャンル情報は、例えば、電子商店街の管理者等により設定される。
【００５７】
商品のジャンルは、木構造で階層的に定義されている。具体的に、木構造の各ノードが、ジャンルに相当する。ノードの深さが、そのノードに相当するジャンルのレベル（階層）に相当する。ノードの深さは、根に位置するノード（以下、「根ノード」という）からの距離である。レベルの値が大きいほど、レベルとしての深さが深く、レベルの値が小さいほど、レベルとしての深さが浅い。根ノードが有する子ノードに相当するジャンルがレベル１のジャンルである。レベル１のジャンルが最上位のジャンルである。レベル１の各ジャンルに対しては、子ノードに相当するジャンルが、レベル２のジャンルとして定義されている。ここで、あるジャンルＣ１の子ノードに相当するジャンルＣ２を、ジャンルＣ１の「子ジャンル」という。子ジャンルを、サブジャンルともいう。また、このときのジャンルＣ１を、ジャンルＣ２の「親ジャンル」という。子ジャンルは、親ジャンルを更に複数に区分したときに、同じような商品が属する範囲である。従って、子ジャンルは親ジャンルに属する。また、あるジャンルに対して、子孫のノードに相当するジャンルを、「子孫ジャンル」という。例えば、ジャンルＣ３がジャンルＣ２の子ジャンルであるとする。この場合、ジャンルＣ２及びＣ３は、ジャンルＣ１の子孫ジャンルである。また、あるジャンルに対して、先祖のノードに相当するジャンルを、「先祖ジャンル」という。ジャンルＣ１及びＣ２は、ジャンルＣ３の先祖ジャンルである。なお、同じジャンルに属する複数の商品とは、それぞれの商品が属するレベル１のジャンルから最下位のレベルのジャンルまでの全てのジャンルが互いに一致する商品同士のみに限られるものではない。同じジャンルに属する複数の商品とは、レベル１のジャンルから最下位のレベルのジャンルのうち少なくとも１つのジャンルにおいて同じジャンルに属する商品同士も含まれる。具体的には、レベル１のジャンルから、最下位のレベルのジャンルよりも上位のレベルのジャンルのうちあるレベルのジャンルまでが互いに一致する複数の商品であってもよい。最下位のレベルで同じジャンルに属するか否かを判断すると、同じジャンルに属する商品の範囲が狭くなりすぎる場合があるからである。レベル１のジャンルからどのレベルのジャンルまでが一致する場合に、同じジャンルに属する複数の商品とするかは、例えば、管理者等により予め設定されてもよいし、ジャンルに応じて定められてもよい。
【００５８】
ジャンルＩＤは、ジャンル情報によって定義されるジャンルの識別情報である。親ジャンルＩＤは、ジャンル情報によって定義されるジャンルの親ジャンルのジャンルＩＤである。子ジャンルＩＤリストは、ジャンル情報によって定義されるジャンルの子ジャンルのジャンルＩＤのリストである。子ジャンルＩＤリストは、ジャンル情報によって定義されるジャンルが子ジャンルを有する場合に設定される。複数購入対象外フラグは、ジャンル情報によって定義されるジャンルが一般的に１人のユーザにより同時期に複数購入される可能性がある商品のジャンルであるか否かを示す。複数購入対象外フラグがＯＮに設定されている場合、複数購入されない商品のジャンルであることを示し、複数購入対象外フラグがＯＦＦに設定されている場合、複数購入される可能性がある商品のジャンルであることを示す。
【００５９】
図４（ｃ）は、店舗情報ＤＢ１２ｃに登録される内容の一例を示す図である。店舗情報ＤＢ１２ｃには、電子商店街に出店している店舗に関する店舗情報が登録される。具体的に、店舗情報ＤＢ１２ｃには、店舗ＩＤ、店舗名、郵便番号、住所、電話番号、電子メールアドレス、取扱ジャンル情報等の店舗の属性が、店舗ごとに対応付けて登録される。店舗ＩＤは、店舗の識別情報である。取扱ジャンル情報は、店舗が取り扱っている商品（店舗が販売している商品）のジャンルを示す情報である。具体的に、取扱ジャンル情報には、店舗が取り扱っている商品のジャンルごとにジャンルＩＤが設定されている。
【００６０】
図４（ｄ）は、商品情報ＤＢ１２ｄに登録される内容の一例を示す図である。商品情報ＤＢ１２ｄには、電子商店街で販売されている商品に関する商品情報が登録される。具体的に、商品情報ＤＢ１２ｄには、商品ＩＤ、店舗ＩＤ、商品コード、ジャンルＩＤ、商品名、商品画像のＵＲＬ（Uniform Resource Locator）、商品説明、商品価格等の商品の属性が、店舗が販売する商品ごとに対応付けて登録される。商品ＩＤ（本発明における取引対象を示す情報の一例）は、店舗等が、販売する商品を管理するための商品の識別情報である。店舗ＩＤは、商品の販売元の店舗を示す。商品コードは、商品を識別するコード番号である。商品コードとしては、例えば、ＪＡＮ（Japanese Article Number Code）コード等がある。ジャンルＩＤは、商品が属するジャンルのジャンルＩＤである。商品情報に設定されるジャンルＩＤは、基本的に最下位のレベルに定義されているジャンル（木構造における葉ノードに相当するジャンル）のジャンルＩＤが設定される。つまり、各商品は、最も細分化されたジャンルでジャンル分けされている。
【００６１】
図４（ｅ）は、閲覧履歴ＤＢ１２ｅに登録される内容の一例を示す図である。閲覧履歴ＤＢ１２ｅには、電子商店街の商品ページの閲覧履歴が登録される。具体的に、閲覧履歴ＤＢ１２ｅには、商品ＩＤ、閲覧日時及びユーザＩＤが、商品ページが閲覧されるごとに対応付けて登録される。商品ＩＤは、商品ページが閲覧された商品を示す。閲覧日時は、商品ページが閲覧された日時を示す。具体的に、閲覧日時は、電子商取引サーバ１がユーザ端末３へ商品ページを送信した日時である。ユーザＩＤは、商品ページを閲覧したユーザを示す。
【００６２】
図４（ｆ）は、購入履歴ＤＢ１２ｆに登録される内容の一例を示す図である。購入履歴ＤＢ１２ｆには、ユーザによる商品の購入履歴が登録される。具体的に、購入履歴ＤＢ１２ｆには、注文コード、購入日時、ユーザＩＤ、商品ＩＤ、店舗ＩＤ、商品コード、購入数等が、商品の購入ごとに対応付けて登録される。注文コードは、商品の注文が行われるたびに付与される注文の識別情報である。ユーザＩＤは、購入したユーザを示す。商品ＩＤ及び商品コードは、購入された商品を示す。店舗ＩＤは、購入先の店舗を示す。購入数は、購入された商品の個数である。
【００６３】
図４（ｇ）は、お気に入り情報ＤＢ１２ｇに登録される内容の一例を示す図である。お気に入り情報ＤＢ１２ｇには、ユーザのお気に入りに関するお気に入り情報（本発明における参照リスト情報の一例）が登録される。具体的に、お気に入り情報ＤＢ１２ｇには、ユーザＩＤ、商品ＩＤ、登録日時等が、お気に入りに商品が登録されるごとに対応付けて登録される。ユーザＩＤは、お気に入りへの登録を行ったユーザを示す。商品ＩＤは、お気に入りに登録された商品を示す。また、商品ＩＤは、お気に入りに登録された商品の商品ページへの参照に相当する情報である。商品ページへの実際の参照の情報はＵＲＬであるが、商品ページのＵＲＬは、商品ＩＤから特定することが可能である。なお、商品ページのＵＲＬが、商品ＩＤとともにまたは商品ＩＤの代わりにお気に入り情報ＤＢ１２ｇに登録されるようになっていてもよい。登録日時は、お気に入りへの登録が行われた日時を示す。
【００６４】
図４（ｈ）は、お気に入り登録削除履歴ＤＢ１２ｈに登録される内容の一例を示す図である。お気に入り登録削除履歴ＤＢ１２ｈには、お気に入りに対する商品の登録や削除の履歴であるお気に入り登録削除履歴が登録される。具体的に、お気に入り登録削除履歴ＤＢ１２ｈには、ユーザＩＤ、操作種別、操作日時、商品ＩＤ等が、お気に入りに対して商品が登録されたり削除されたりするごとに対応付けて登録される。ユーザＩＤは、お気に入りに対して商品の登録または削除を行ったユーザを示す。操作種別は、お気に入りへの登録が行われたか、またはお気に入りからの削除が行われたかの何れかを示す。操作日時は、お気に入りに対して商品の登録または削除が行われた日時を示す。商品ＩＤは、お気に入りに対して登録または削除された商品を示す。
【００６５】
なお、記憶部１２には、例えば、商品コード別に商品に関する情報（例えば、商品の正式名称、商品のジャンルのジャンルＩＤ、商品の仕様等）が登録されるカタログＤＢ等のデータベースも構築されている。
【００６６】
次に、記憶部１２に記憶されるその他の情報について説明する。記憶部１２には、Ｗｅｂページを表示するためのＨＴＭＬ（HyperText Markup Language）文書、ＸＭＬ（Extensible Markup Language）文書、画像データ、テキストデータ、電子文書等の各種データが記憶されている。また、記憶部１２には、管理者等により設定された各種の設定値が記憶されている。
【００６７】
また、記憶部１２には、オペレーティングシステム、ＷＷＷ（World Wide Web）サーバプログラム、ＤＢＭＳ（Database Management System）、電子商取引管理プログラム等の各種プログラムが記憶されている。電子商取引管理プログラムは、電子商取引に関する各種の処理を実行するためのプログラムである。なお、各種プログラムは、例えば、他のサーバ装置等からネットワークＮＷを介して取得されるようにしてもよいし、ＤＶＤ（Digital Versatile Disc）等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。
【００６８】
入出力インターフェース１３は、通信部１１及び記憶部１２とシステム制御部１４との間のインターフェース処理を行うようになっている。
【００６９】
システム制御部１４は、ＣＰＵ１４ａ、ＲＯＭ（Read Only Memory）１４ｂ、ＲＡＭ（Random Access Memory）１４ｃ等により構成されている。そして、システム制御部１４は、ＣＰＵ１４ａが、各種プログラムを読み出し実行することにより、本発明における取得手段、予測手段、判定手段、登録数取得手段、購入数取得手段、数判定手段及び占有率取得手段として機能するようになっている。
【００７０】
なお、電子商取引サーバ１が、複数のサーバ装置で構成されてもよい。例えば、お気に入りに関する処理を行うサーバ装置、電子商店街において商品の検索や注文等の処理を行うサーバ装置、商品の需要の予測の処理を行うサーバ装置、ユーザ端末３からのリクエストに応じてＷｅｂページを送信するサーバ装置、及びデータベースを管理するサーバ装置等が、互いにＬＡＮ等で接続されてもよい。
【００７１】
［３．電子商取引システムの動作］
次に、電子商取引システムＳの動作について、図５乃至図７を用いて説明する。
【００７２】
図５は、本実施形態に係る電子商取引サーバ１のシステム制御部１４の需要予測リクエスト受信時処理における処理例を示すフローチャートである。
【００７３】
店舗の従業員等は、商品の需要の予測を要求するため、店舗端末２を操作する。すると、店舗端末２は、需要予測リクエストを電子商取引サーバ１へ送信する。需要予測リクエストは、商品の需要の予測を要求する店舗の店舗ＩＤが設定されている。需要予測リクエスト受信時処理は、電子商取引サーバ１が店舗端末２から需要予測リクエストを受信したときに開始される。
【００７４】
先ず、システム制御部１４は、需要の予測対象の商品の商品コードを取得する（ステップＳ１）。例えば、店舗の従業員等が需要の予測対象の商品の商品コードを指定し、システム制御部１４が、指定された商品コードを店舗端末２から取得してもよい。また、システム制御部１４は、需要予測リクエストに設定された店舗ＩＤを含む店舗情報から取扱ジャンル情報を取得し、取扱ジャンル情報に基づいて、需要の予測を要求した店舗が取り扱っているジャンルの商品の商品コードを複数取得してもよい。また、システム制御部１４は、需要予測リクエストに設定された店舗ＩＤを含む各商品情報から、需要の予測を要求した店舗が取り扱っている商品の商品コードを取得してもよい。
【００７５】
次いで、システム制御部１４は、需要の予測対象の商品のインデックスｉに１を設定する（ステップＳ２）。次いで、システム制御部１４は、需要の予測対象の商品のうち１つを、商品ｉとして選択する（ステップＳ３）。次いで、システム制御部１４は、１商品需要予測処理を実行する（ステップＳ４）。
【００７６】
図６は、本実施形態に係る電子商取引サーバ１のシステム制御部１４の１商品需要予測処理における処理例を示すフローチャートである。１商品需要予測処理において、システム制御部１４は、予測手段として、商品ｉの需要を予測する。
【００７７】
先ず、システム制御部１４は、商品ｉの電子商店街全体における需要の値を示す総需要ｉに０を設定する（ステップＳ２１）。次いで、システム制御部１４は、商品ｉの商品コードに対応するジャンルＩＤを、カタログＤＢから取得する（ステップＳ２２）。次いで、システム制御部１４は、取得したジャンルＩＤを含むジャンル情報から、複数購入対象外フラグを取得する（ステップＳ２３）。次いで、システム制御部１４は、商品情報ＤＢ１２ｄから商品ｉの商品コードを含む商品情報を検索し、検索された各商品情報から商品ＩＤを取得する（ステップＳ２４）。つまり、システム制御部１４は、商品ｉを販売している各店舗において商品ｉに付与されている商品ＩＤを取得する。次いで、システム制御部１４は、取得手段として、ステップＳ２４において取得した商品ＩＤごとに、お気に入り情報ＤＢ１２ｇから商品ＩＤを含むお気に入り情報を検索して取得する（ステップＳ２５）。つまり、システム制御部１４は、商品ｉをお気に入りとして登録していることを示すお気に入り情報を全て取得する。
【００７８】
次いで、システム制御部１４は、取得したお気に入り情報のうち１つを選択する。そして、システム制御部１４は、選択したお気に入り情報に設定されているユーザＩＤを、処理対象のユーザＩＤとして取得する（ステップＳ２６）。次いで、システム制御部１４は、１ユーザ需要予測処理を実行する（ステップＳ２７）。
【００７９】
図７は、本実施形態に係る電子商取引サーバ１のシステム制御部１４の１ユーザ需要予測処理における処理例を示すフローチャートである。１ユーザ需要予測処理において、システム制御部１４は、処理対象ユーザの商品ｉに対する需要を予測する。なお、図７に示す処理例は、１人分に応じた需要は商品１個分であるとした場合の処理例である。
【００８０】
先ず、システム制御部１４は、商品情報ＤＢ１２ｄから処理対象ユーザのユーザＩＤを含むお気に入り情報を検索する（ステップＳ５１）。次いで、システム制御部１４は、検索されたお気に入り情報から商品ＩＤを取得する。そして、システム制御部１４は、商品ＩＤを含む商品情報からジャンルＩＤを取得する（ステップＳ５２）。次いで、システム制御部１４は、登録数取得手段として、ステップＳ５２において取得したジャンルＩＤのうち、１商品需要予測処理のステップＳ２２において取得した商品ｉのジャンルＩＤと一致する数を計算する。これにより、システム制御部１４は、対象ユーザがお気に入りに登録している商品のうち商品ｉが属するジャンルの商品の数である同一ジャンル登録数を計算する（ステップＳ５３）。
【００８１】
次いで、システム制御部１４は、判定手段として、１商品需要予測処理のステップＳ２３において取得した複数購入対象外フラグがＯＮに設定されているか否かを判定する（ステップＳ５４）。このとき、システム制御部１４は、複数購入対象外フラグがＯＮに設定されていると判定した場合には（ステップＳ５４：ＹＥＳ）、対象ユーザの需要の予測値として、１／同一ジャンル登録数を設定する（ステップＳ５５）。
【００８２】
一方、システム制御部１４は、複数購入対象外フラグがＯＦＦに設定されていると判定した場合には（ステップＳ５４：ＮＯ）、処理対象ユーザのユーザＩＤを含む購入履歴を検索する（ステップＳ５６）。次いで、システム制御部１４は、検索された各購入履歴から商品ＩＤを取得する。そして、システム制御部１４は、取得した商品ＩＤを含む商品情報からジャンルＩＤを取得する（ステップＳ５７）。次いで、システム制御部１４は、検索された購入履歴の中から、その購入履歴に含まれる商品ＩＤが１商品需要予測処理のステップＳ２２において取得した商品ｉのジャンルＩＤと一致する購入履歴を抽出する（ステップＳ５８）。つまり、システム制御部１４は、商品ｉが属するジャンルの商品を対象ユーザが購入したことを示す購入履歴を抽出する。
【００８３】
次いで、システム制御部１４は、購入数取得手段として、抽出した購入履歴に基づいて、同時期購入数を計算する（ステップＳ５９）。具体的に、システム制御部１４は、現在から遡って同時期とみなす期間（例えば、１時間、１日、１週間、１ヶ月等）ごとに、その期間に購入日時が含まれる購入履歴を特定する。次いで、システム制御部１４は、各期間において特定した各購入履歴に含まれる購入数の和を計算して、期間ごとの購入数を計算する。例えば、同時期とみなす期間を１日とする。この場合、システム制御部１４は、昨日の購入数、今日の２日前の購入数、３日前の購入数・・・を計算する。どこまで遡って計算するかは、例えば、予め設定されている。次いで、システム制御部１４は、期間ごとに計算した購入数のうち、１以上を示す購入数の平均値を計算することにより、同時期購入数を計算する。同時期購入数は、あくまでもユーザがあるジャンルの商品を購入した時期において、そのジャンルの商品をその時期に購入した数であるので、購入がなかった期間（購入数が０である期間）は、同時期購入数の計算には含まれない。例えば、同時期とみなす期間を１日とし、昨日から１週間前まで１日ごとの購入数を計算したとする。このとき、それぞれの購入数が、０、０、３、０、０、１である場合、同時期購入数は、（１＋３）／２＝２である。なお、電子商取引サーバ１は、購入数の平均値を計算するのではなく、例えば、ユーザが現在から直近に購入を行った期間における購入数を、同時期購入数としてもよい。例えば、上述の例では、３日前の購入数である３が、同時期購入数とされる。また例えば、電子商取引サーバ１は、期間ごとに計算した購入数のうち最大の購入数を同時購入数としてもよい。また、商品ｉが属するジャンルの商品のうちユーザが同時に購入した商品の数を同時期購入数としてもよい。つまり、システム制御部１４は、購入日時が同一である購入履歴ごとに、商品ｉが属するジャンルの商品の購入数を計算して、例えば、購入数の平均値を計算したり、最大の購入数を特定したりすることにより、同時期購入数を求めてもよい。
【００８４】
システム制御部１４は、同時期購入数を計算すると、数判定手段として、同時期購入数が同一ジャンル登録数以上であるか否かを判定する（ステップＳ６０）。このとき、システム制御部１４は、同時期購入数が同一ジャンル登録数以上であると判定した場合には（ステップＳ６０：ＹＥＳ）、対象ユーザの需要の予測値として、１を設定する（ステップＳ６１）。一方、システム制御部１４は、同時期購入数が同一ジャンル登録数以上ではないと判定した場合には（ステップＳ６０：ＮＯ）、対象ユーザの需要の予測値として、同時期購入数／同一ジャンル登録数を設定する（ステップＳ６２）。システム制御部１４は、対象ユーザの需要の予測値の設定を終えると（ステップＳ５５、Ｓ６１またはＳ６２）、１ユーザ需要予測処理を終了させる。
【００８５】
次いで、システム制御部１４は、図６に示すように、１ユーザ需要予測処理で設定された対象ユーザの需要の予測値を、総需要ｉに加算する（ステップＳ２８）。次いで、システム制御部１４は、ステップＳ２５において取得したお気に入り情報のうちまだ選択していないお気に入り情報があるか否かを判定する（ステップＳ２９）。このとき、システム制御部１４は、まだ選択していないお気に入り情報があると判定した場合には（ステップＳ２９：ＹＥＳ）、まだ選択していないお気に入り情報のうち１つを選択する。そして、システム制御部１４は、選択したお気に入り情報に設定されているユーザＩＤを、処理対象のユーザＩＤとして取得する（ステップＳ３０）。次いで、システム制御部１４は、ステップＳ２７に移行する。システム制御部１４は、ステップＳ２７〜Ｓ３０の処理を繰り返すことにより、商品ｉをお気に入りに登録している各ユーザの需要の予測値の和を、総需要ｉとして計算する。
【００８６】
そして、システム制御部１４は、全てのお気に入り情報を選択したと判定した場合には（ステップＳ２９：ＮＯ）、ステップＳ２４において取得した商品ｉの商品ＩＤごとに、お気に入り登録削除履歴ＤＢ１２ｈから、取得した商品ＩＤを含むお気に入り登録削除履歴を検索する（ステップＳ３１）。つまり、システム制御部１４は、お気に入りに対する商品ｉの登録及び削除の履歴を検索する。このとき、システム制御部１４は、操作日時が予め設定された期間（例えば、現在から１週間前までの期間、現在から１ヶ月前までの期間等）に含まれるお気に入り登録削除履歴のみを検索する。次いで、システム制御部１４は、検索されたお気に入り登録削除履歴に基づいて、商品ｉのお気に入りの登録数の増減数を計算する（ステップＳ３２）。具体的に、システム制御部１４は、操作種別が登録を示すお気に入り登録削除履歴の数から、操作種別が削除を示すお気に入り登録削除履歴の数を減算することにより、増減数を計算する。次いで、システム制御部１４は、計算した増減数に基づいて、総需要ｉを補正する（ステップＳ３３）。例えば、システム制御部１４は、増減数がマイナスである場合には、増減数に予め設定された係数を乗算し、乗算した結果を総需要ｉに加算してもよい。
【００８７】
次いで、システム制御部１４は、購入履歴ＤＢ１２ｆから商品ｉの商品コードを含む購入履歴を検索する。このとき、システム制御部１４は、購入日時が予め設定された期間に含まれる購入履歴のみを検索する。そして、システム制御部１４は、検索された各購入履歴に含まれる購入数の和を計算することにより、予め設定された期間における商品ｉの総販売数を計算する（ステップＳ３４）。次いで、システム制御部１４は、検索された購入履歴の中から、商品の需要の予測を要求した店舗の店舗ＩＤを含む購入履歴を抽出する。そして、システム制御部１４は、抽出された各購入履歴に含まれる購入数の和を計算することにより、商品の需要の予測を要求した店舗の予め設定された期間における商品ｉの販売数を計算する（ステップＳ３５）。次いで、システム制御部１４は、占有率取得手段として、商品の需要の予測を要求した店舗の販売数を総販売数で除算することにより、商品の需要の予測を要求した店舗の商品ｉの市場占有率を計算する（ステップＳ３６）。次いで、システム制御部１４は、総需要ｉに市場占有率を乗算することにより、商品の需要の予測を要求した店舗の需要の値を示す店舗需要ｉを計算する（ステップＳ３７）。システム制御部１４は、この処理を終えると、１商品需要予測処理を終了させる。
【００８８】
次いで、システム制御部１４は、図５に示すように、需要の予測対象の商品のうちまだ選択していない商品があるか否かを判定する（ステップＳ５）。このとき、システム制御部１４は、まだ選択していない商品があると判定した場合には（ステップＳ５：ＹＥＳ）、インデックスｉに１を加算する（ステップＳ６）。次いで、システム制御部１４は、まだ選択していない商品のうち１つを、商品ｉとして選択する（ステップＳ７）。次いで、システム制御部１４は、ステップＳ４に移行する。システム制御部１４は、ステップＳ４〜Ｓ７の処理を繰り返すことにより、需要の予測対象の各商品の店舗需要を計算する。
【００８９】
そして、システム制御部１４は、全ての商品を選択したと判定した場合には（ステップＳ５：ＮＯ）、各商品の店舗需要に基づいて、予測した需要を示す情報を生成する（ステップＳ８）。このとき、システム制御部１４は、需要の予測対象の商品の中に同一のジャンルに属する商品が複数存在する場合には、同一のジャンルに属する商品間における大小関係を示す情報を生成する。例えば、システム制御部１４は、図２（ａ）に示すように、店舗需要の値をそのまま示す情報を生成してもよい。また例えば、システム制御部１４は、店舗需要の比率を計算し、図２（ｂ）に示すように、比率を示す情報を生成してもよい。また例えば、システム制御部１４は、店舗需要の比較を行うことにより、図２（ｃ）に示すような情報を生成してもよい。また、システム制御部１４は、ある商品について、同一のジャンルに属する他の商品が存在しない場合には、店舗需要の値をそのまま示す情報を生成してもよい。また例えば、システム制御部１４は、図２（ｄ）や図２（ｅ）に示すように、需要を示す情報に、お気に入りの登録数の増減数の情報を付加してもよい。
【００９０】
次いで、システム制御部１４は、需要を示す情報を含む商品需要予測結果ページを生成し、需要予測リクエストの送信元の店舗端末２へ、生成した商品需要予測結果ページを送信する（ステップＳ９）。システム制御部１４は、この処理を終えると、需要予測リクエスト受信時処理を終了させる。
【００９１】
なお、システム制御部１４は、ステップＳ２２、Ｓ５３及びＳ５７において、カタログＤＢや商品情報ＤＢ１２ｄからジャンルＩＤを取得し、ステップＳ５３及びＳ５８において、取得したジャンルＩＤ同士が一致するか否かを判定していた。つまり、システム制御部１４は、商品が分類されている最下位のジャンルを比較することにより、需要の予測対象の商品と同じジャンルに属する商品を特定していた。しかしながら、システム制御部１４は、カタログＤＢや商品情報ＤＢ１２ｄから取得したジャンルＩＤが示すジャンルの先祖のジャンルのジャンルＩＤが一致するか否かを判定してもよい。つまり、システム制御部１４は、最下位のレベルのジャンルではなく、そのジャンルよりも上位のジャンルで、需要の予測対象の商品と同じジャンルに属する商品を特定してもよい。最下位のレベルで同じジャンルに属するか否かを判定すると、同じジャンルに属する商品の範囲が狭くなりすぎる場合があるからである。また、ステップＳ８において同じジャンルに属する複数の商品を特定する場合についても同様である。ジャンル情報ＤＢ１２ｂに登録されているジャンル情報に含まれている親ジャンルＩＤにより、ジャンル情報により定義されているジャンルの親ジャンルを特定することができる。そのため、親ジャンルＩＤを手がかりとして、ジャンル情報ＤＢ１２ｂから先祖のジャンルのジャンルＩＤを取得することができる。
【００９２】
以上説明したように、本実施形態によれば、電子商取引サーバ１のシステム制御部１４が、お気に入り情報ＤＢ１２ｇから複数のお気に入り情報を取得し、取得されたお気に入り情報に基づいて、商品の需要を予測する。従って、例えば、過去の購入数に基づく需要の予測や商品ページへのアクセス数に基づく需要の予測よりも正確に需要を予測することができる。
【００９３】
また、システム制御部１４が、複数のジャンルのうち少なくとも１つのジャンルが同じジャンルに属する複数の商品間における需要の大小関係を予測する。従って、複数の商品間で需要を比較することができる。
【００９４】
また、システム制御部１４が、お気に入り情報ＤＢ１２ｇから取得されたお気に入り情報と、お気に入り登録削除履歴ＤＢ１２ｈに登録されたお気に入り登録削除履歴とに基づいて、商品の需要を予測する。従って、お気に入り登録削除履歴を更に考慮することにより、需要の予測精度を高めることができる。
【００９５】
また、システム制御部１４が、需要の予測対象の商品が属するジャンルの複数購入対象外フラグがＯＮであるか否かを判定し、需要の予測対象の商品が属するジャンの商品の同一ジャンル登録数をユーザごとに計算し、複数購入対象外フラグがＯＦＦであると判定された場合、１人分に対応する需要を各ユーザの需要に設定し、複数購入対象外フラグがＯＮであると判定された場合、１人分に対応する需要に対して同一ジャンル登録数の１となる需要を各ユーザの需要に設定し、予測対象の商品をお気に入りに登録している各ユーザのその商品に対する需要の和を計算してその和に応じた需要を予測する。従って、１人のユーザから同時期に１つのみ購入されるようなジャンルの商品が１人のユーザのお気に入りに複数登録されていても、その中からユーザが購入する商品は１つである蓋然性が高いことを考慮した需要の予測を行うことができるので、需要の予測精度を高めることができる。
【００９６】
また、システム制御部１４が、購入履歴ＤＢ１２ｆに登録された購入履歴に基づいて、予測対象の商品が属するジャンルの商品の同時期購入数をユーザごとに計算し、同時期購入数が同一ジャンル登録数以上であるか否かをユーザごとに判定し、需要の予測対象の商品が属するジャンルの複数購入対象外フラグがＯＦＦである場合において、同時期購入数が同一ジャンル登録数以上であると判定されたユーザの需要に１人分に対応する需要を設定し、同時期購入数が同一ジャンル登録数以上ではないと判定されたユーザの需要に、１人分に対応する需要を同時期購入数倍し、その結果に対して同一ジャンル登録数分の１となる需要を設定する。従って、１人のユーザから同時期に複数購入される可能性があるジャンルの商品が１人のユーザのお気に入りに複数登録されている場合、各ユーザの購入の傾向を考慮した需要の予測を行うことができるので、需要の予測精度を高めることができる。
【００９７】
また、システム制御部１４が、需要の予測対象の商品を販売する複数の店舗のうち需要の予測を要求した店舗による需要の予測対象の商品の市場占有率を計算し、お気に入り情報ＤＢ１２ｇから取得されたお気に入り情報と市場占有率とに基づいて、需要の予測を要求した店舗の需要を予測する。従って、需要を知りたい店舗に対する需要を予測することができる。
【００９８】
なお、上記実施形態においては、本発明における取引対象が商品に適用されていた。しかしながら、取引対象がサービスに適用されてもよい。そして、電子商取引のシステムとして、サービスの予約が可能なシステムに本発明が適用されてもよい。サービスの予約としては、例えば、宿泊施設の宿泊予約、ゴルフ場等の競技施設の利用予約、交通機関の座席の予約等がある。
【符号の説明】
【００９９】
１ 電子商取引サーバ
２ 店舗端末
３ ユーザ端末
１１ 通信部
１２ 記憶部
１２ａ 会員情報ＤＢ
１２ｂ ジャンル情報ＤＢ
１２ｃ 店舗情報ＤＢ
１２ｄ 商品情報ＤＢ
１２ｅ 閲覧履歴ＤＢ
１２ｆ 購入履歴ＤＢ
１２ｇ お気に入り情報ＤＢ
１２ｈ お気に入り登録削除履歴ＤＢ
１３ 入出力インターフェース
１４ システム制御部
１４ａ ＣＰＵ
１４ｂ ＲＯＭ
１４ｃ ＲＡＭ
１５ システムバス
ＮＷ ネットワーク
Ｓ 電子商取引システム
【技術分野】
【０００１】
本発明は、取引対象の需要を予測する情報処理装置の技術分野に関する。
【背景技術】
【０００２】
従来、商品やサービス等の取引対象の販売にあたって、取引対象の需要の予測が行われることがある。このような予測は、例えば、過去の取引対象の販売実績に基づいて行われている。具体的には、過去の販売数が多いほど、需要があると予測されたり、過去の販売数の変化の態様に応じて、需要が予測されたりする。
【０００３】
また、特許文献１には、商品の記事が掲載されたサイトへのアクセス数に基づいて、商品の需要を予測する技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７ー０３４９６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、過去の販売実績に基づく需要予測では、正確に需要を予測することができるとは限らない。販売数は、取引対象の価格や商品の在庫の有無等の要因に影響されるので、ユーザの需要を正確に反映していない場合があるからである。また、特許文献１に開示されているように、取引対象の情報へのアクセス数に基づく需要予測においても、正確に需要を予測することができるとはいえない。取引対象の情報へアクセスしたユーザがその取引対象の購入に興味を持っているとは必ずしもいえないからからである。
【０００６】
本発明は、以上の点に鑑みてなされたものであり、取引対象の需要をより正確に予測することができる情報処理装置、情報処理方法、情報処理プログラム、及び記録媒体を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、請求項１に記載の発明は、取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の前記参照リスト情報を取得する取得手段と、前記取得手段により取得された前記参照リスト情報に基づいて、取引対象の需要を予測する予測手段と、を備えることを特徴とする。
【０００８】
ユーザにより参照リストに登録された取引対象はそのユーザから購入される蓋然性がある。この発明によれば、購入される蓋然性がある取引対象を示す参照リスト情報に基づいて需要が予測されるので、より正確に需要を予測することができる。
【０００９】
請求項２に記載の発明は、請求項１に記載の情報処理装置において、前記予測手段は、取引対象の複数の区分のうち少なくとも１つの区分が同じ区分に属する複数の取引対象間における需要の大小関係を予測することを特徴とする。
【００１０】
この発明によれば、複数の取引対象間で需要を比較することができる。
【００１１】
請求項３に記載の発明は、請求項１または請求項２に記載の情報処理装置において、前記予測手段は、前記取得手段により取得された前記参照リスト情報と、ユーザによる前記参照リストからの取引対象の削除履歴を記憶する削除履歴記憶手段に記憶された前記削除履歴とに基づいて、該取引対象の需要を予測することを特徴とする。
【００１２】
ユーザが参照リストから削除した取引対象はそのユーザが購入に興味を失った蓋然性がある。この発明によれば、参照リストからの取引対象の削除の履歴を更に考慮することにより、需要の予測精度を高めることができる。
【００１３】
請求項４に記載の発明は、請求項１乃至３の何れか１項に記載の情報処理装置において、取引対象の複数の区分のうち需要の予測対象の取引対象が属する区分が１人のユーザから同時期に複数購入される取引対象の区分であるか否かを判定する判定手段と、前記予測対象の取引対象が属する区分の取引対象の前記参照リストの登録数をユーザごとに取得する登録数取得手段と、を更に備え、前記特定手段は、前記予測対象の取引対象を前記参照リストに登録している各ユーザの該取引対象に対する需要の和を計算して該和に応じた需要を予測し、前記判定手段により複数購入される取引対象の区分であると判定された場合、予め設定された設定需要を各ユーザの需要に設定し、前記判定手段により複数購入される取引対象の区分ではないと判定された場合、前記登録数取得手段によりユーザごとに取得された前記登録数に基づいて各ユーザの需要の設定を行うことを特徴とする。
【００１４】
この発明によれば、１人のユーザから同時期に１つのみ購入されるような区分に属する取引対象の需要の予測においては、その区分の取引対象がユーザによって参照リストに登録されている数に基づいてそのユーザの需要が予測される。そのため、このような区分の取引対象が１人のユーザの参照リストに複数登録されていても、その中からユーザが購入する取引対象は１つである蓋然性が高いことを考慮した需要の予測を行うことができるので、需要の予測精度を高めることができる。
【００１５】
請求項５に記載の発明は、請求項４に記載の情報処理装置において、ユーザにより購入された取引対象の区分を示す情報と、購入したユーザを示す情報と、購入時期とを対応付けて購入履歴として記憶する購入履歴記憶手段に記憶された前記購入履歴に基づいて、前記予測対象の取引対象が属する区分の取引対象の同時期における購入数をユーザごとに取得する購入数取得手段と、前記購入数取得手段により取得された前記購入数が前記登録数取得手段により取得された前記登録数以上であるか否かをユーザごとに判定する数判定手段と、を更に備え、前記判定手段により複数購入される取引対象の区分であると判定された場合、前記特定手段は、前記数判定手段により前記購入数が前記登録数以上であると判定されたユーザの需要に前記設定需要を設定し、前記数判定手段により前記購入数が前記登録数以上ではないと判定されたユーザの需要に、前記購入数と前記登録数とに基づいて、前記設定需要未満となる需要を設定することを特徴とする。
【００１６】
この発明によれば、１人のユーザから同時期に複数購入される可能性がある区分に属する取引対象の需要の予測においては、購入履歴に基づいてその区分の取引対象がユーザによる同時期における購入数が取得され、その購入数が、その区分の取引対象がユーザにより参照リストに登録されている数よりも少ない場合には、購入数と参照リストに登録されている数とに基づいて、そのユーザの需要が予め設定された需要よりも小さく予測される。そのため、このような区分の取引対象が１人のユーザの参照リストに複数登録されている場合、各ユーザの購入の傾向を考慮した需要の予測を行うことができるので、需要の予測精度を高めることができる。
【００１７】
請求項６に記載の発明は、請求項１乃至５の何れか１項に記載の情報処理装置において、需要の予測対象の取引対象を販売する複数の販売者のうち需要の予測を要求した販売者による該取引対象の市場占有率を取得する占有率取得手段を更に備え、前記予測手段は、前記取得手段により取得された前記参照リスト情報と、前記占有率取得手段により取得された前記市場占有率とに基づいて、需要の予測を要求した販売者の需要を予測することを特徴とする。
【００１８】
この発明によれば、需要を知りたい販売者に対する需要を予測することができる。
【００１９】
請求項７に記載の発明は、コンピュータにより実行される情報処理方法であって、取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の前記参照リスト情報を取得する取得ステップと、前記取得ステップにおいてり取得された前記参照リスト情報に基づいて、取引対象の需要を予測する予測ステップと、を含むことを特徴とする。
【００２０】
請求項８に記載の発明は、情報処理装置に含まれるコンピュータを、取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の前記参照リスト情報を取得する取得手段、及び、前記取得手段により取得された前記参照リスト情報に基づいて、取引対象の需要を予測する予測手段、として機能させることを特徴とする。
【００２１】
請求項９に記載の発明は、情報処理装置に含まれるコンピュータを、取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の前記参照リスト情報を取得する取得手段、及び、前記取得手段により取得された前記参照リスト情報に基づいて、取引対象の需要を予測する予測手段、として機能させる情報処理プログラムがコンピュータ読み取り可能に記憶されていることを特徴とする。
【発明の効果】
【００２２】
本発明によれば、購入される蓋然性がある取引対象を示す参照リスト情報に基づいて需要が予測されるので、より正確に需要を予測することができる。
【図面の簡単な説明】
【００２３】
【図１】本実施形態に係る電子商取引システムＳの概要構成の一例を示す図である。
【図２】（ａ）乃至（ｅ）は、商品需要予測結果ページ内における需要の予測結果を示す情報の表示例である。
【図３】本実施形態に係る電子商取引サーバ１の概要構成の一例を示すブロック図である。
【図４】（ａ）は、会員情報ＤＢ１２ａに登録される内容の一例を示す図であり、（ｂ）は、ジャンル情報ＤＢ１２ｂに登録される内容の一例を示す図であり、（ｃ）は、店舗情報ＤＢ１２ｃに登録される内容の一例を示す図であり、（ｄ）は、商品情報ＤＢ１２ｄに登録される内容の一例を示す図であり、（ｅ）は、閲覧履歴ＤＢ１２ｅに登録される内容の一例を示す図であり、（ｆ）は、購入履歴ＤＢ１２ｆに登録される内容の一例を示す図であり、（ｇ）は、お気に入り情報ＤＢ１２ｇに登録される内容の一例を示す図であり、（ｈ）は、お気に入り登録削除履歴ＤＢ１２ｈに登録される内容の一例を示す図である。
【図５】本実施形態に係る電子商取引サーバ１のシステム制御部１４の需要予測リクエスト受信時処理における処理例を示すフローチャートである。
【図６】本実施形態に係る電子商取引サーバ１のシステム制御部１４の１商品需要予測処理における処理例を示すフローチャートである。
【図７】本実施形態に係る電子商取引サーバ１のシステム制御部１４の１ユーザ需要予測処理における処理例を示すフローチャートである。
【発明を実施するための形態】
【００２４】
以下、図面を参照して本発明の実施形態について詳細に説明する。なお、以下に説明する実施の形態は、電子商取引システムに対して本発明を適用した場合の実施形態である。
【００２５】
［１．電子商取引システムの構成及び機能概要］
［１−１．電子商取引システムの構成］
先ず、本実施形態に係る電子商取引システムＳの構成について、図１を用いて説明する。図１は、本実施形態に係る電子商取引システムＳの概要構成の一例を示す図である。
【００２６】
図１に示すように、電子商取引システムＳは、電子商取引サーバ１と、複数の店舗端末２と、複数のユーザ端末３と、を含んで構成されている。そして、電子商取引サーバ１と各店舗端末２及び各ユーザ端末３とは、ネットワークＮＷを介して、例えば、通信プロトコルにＴＣＰ／ＩＰ等を用いて相互にデータの送受信が可能になっている。なお、ネットワークＮＷは、例えば、インターネット、専用通信回線（例えば、ＣＡＴＶ（Community Antenna Television）回線）、移動体通信網（基地局等を含む）、及びゲートウェイ等により構築されている。
【００２７】
電子商取引サーバ１（本発明における情報処理装置の一例）は、商品の購入が可能な電子商店街に関する各種処理を実行するサーバ装置である。ユーザは、電子商店街を利用することにより、所望の店舗から所望の商品を購入することができる。電子商取引サーバ１は、店舗端末２やユーザ端末３からのリクエストに応じて、例えば、電子商店街のＷｅｂページを送信したり、商品の検索、購入等に関する処理を行ったりする。
【００２８】
店舗端末２は、電子商店街に出店している店舗の従業員等により利用される端末装置である。店舗端末２は、例えば、販売する商品の情報を電子商店街に登録したり、商品の注文内容を確認したりするために用いられる。また、店舗端末２は、従業員等からの操作に基づいて電子商取引サーバ１にアクセスすることにより、電子商取引サーバ１からＷｅｂページを受信して表示する。店舗端末２には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。店舗端末２としては、例えば、パーソナルコンピュータ等が用いられる。
【００２９】
ユーザ端末３は、電子商店街を利用するユーザの端末装置である。ユーザ端末３は、ユーザからの操作に基づいて電子商取引サーバ１にアクセスすることにより、電子商取引サーバ１からＷｅｂページを受信して表示する。ユーザ端末３には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。ユーザ端末３としては、例えば、パーソナルコンピュータ、ＰＤＡ（Personal Digital Assistant）、スマートフォン等の携帯情報端末、携帯電話機等が用いられる。
【００３０】
［１−２．お気に入りに基づく需要の予測］
電子商取引システムＳにおいては、お気に入り機能が提供されている。お気に入り機能とは、電子商店街で販売されている商品をユーザのお気に入りとして登録することにより、商品ページへの参照をユーザ専用のリストに保持しておき、お気に入りの商品の商品ページをユーザが容易に閲覧することができるようにする機能である。商品ページは、１つの商品に関する詳細な情報が表示されるＷｅｂページである。また、お気に入りの商品は、単にお気に入りともいう。電子商店街においては、商品ページに、「お気に入りに追加」と表示されたハイパーリンク（以下、「リンク」という）が表示されている。ユーザがこのリンクを選択すると、商品ページに情報が表示されている商品が、ユーザのお気に入りに登録される。ユーザは、お気に入りに登録されている商品を、お気に入りページで確認することができる。お気に入りページは、お気に入りに登録されている商品の一覧が表示されるＷｅｂページであり、ユーザごとに専用のＷｅｂページである。また、お気に入りページには、お気に入りに登録された商品の商品ページへのリンクが埋め込まれている。お気に入りページにおいて、ユーザは、任意の商品のリンクを選択すると、対応する商品ページを表示させることができる。また、お気に入りページにおいて、ユーザは、お気に入りに登録されている商品の中から登録しておく必要がない商品を指定してお気に入りから削除することができる。
【００３１】
電子商取引サーバ１は、店舗端末２からの要求に応じて、電子商店街で販売されている商品の需要予測を行い、予測結果を示すＷｅｂページ（以下「商品需要予測結果ページ」という）を店舗端末２へ送信する。具体的に、電子商取引サーバ１は、お気に入りに基づいて、商品の需要を予測する処理を実行する。お気に入りには、例えば、ユーザが気になった商品、購入候補とした商品、ユーザが好きな商品等が登録される。従って、ユーザによりお気に入りに登録されている商品は、お気に入りに登録されていない商品よりも、そのユーザによって将来購入される蓋然性が高い商品であると考えられる。つまり、お気に入りは、将来の商品の需要を表しているといえる。そこで、電子商取引サーバ１は、基本的には、ある商品をお気に入りの登録しているユーザの数（以下、「登録数」という）が多いほど、その商品の需要が大きいと予測する。
【００３２】
従来の需要予測としては、過去の販売数に基づく需要予測がある。しかしながら、過去の販売数に基づく需要予測では、正確に需要を予測することができるとは限らない。販売数は、商品の価格や商品の在庫の有無等の要因に影響されるからである。また、過去の販売数は、これまでの需要の消費量を示している。つまり、過去の販売数が多いと、これまでの商品の販売で、本来あった需要の大部分が消費されてしまっている場合がある。その場合、将来の販売数が急激に落ちることもあり得る。これに対し、お気に入りに基づく需要予測では、商品の価格や商品の在庫の有無等に影響されない。また、上述したように、お気に入りには、ユーザが将来購入する可能性がある商品が登録される。そのため、お気に入りに基づく需要予測は、過去の販売数に基づく需要予測よりも、正確に需要を予測することができる。
【００３３】
また、従来の需要予測として、商品ページ等の商品の情報に対するアクセス数に基づく需要予測がある。アクセス数に基づく需要予測も、ユーザの需要を正確に予測することができるとはいえない。商品ページを閲覧したユーザがその商品ページに情報が掲載されている商品の購入に興味を持っているとは限らないからである。例えば、ユーザは、購入するつもりはなく、単なる興味本位で商品ページを閲覧する場合がある。また、ユーザが、商品ページに掲載された情報を確認した結果、その商品ページに情報が掲載されている商品を購入対象から除外する場合もある。これに対し、お気に入りに商品を登録するというユーザの行為は、ユーザがその商品に興味を持っているという意思表示である蓋然性が高い。そのため、お気に入りに基づく需要予測は、商品ページのアクセス数に基づく需要予測よりも、正確に需要を予測することができる。
【００３４】
次に、お気に入りに基づく具体的な需要の予測方法について説明する。電子商取引サーバ１は、ある商品について、お気に入りに登録しているユーザ１人につき、１人分に応じた需要があるとする。この１人分に応じた需要の大きさは、例えば、電子商取引ステムＳの管理者により予め設定されている。例えば、１人分に応じた需要は、商品１個分の需要があるとしてもよいし、商品１個分よりも大きくても小さくてもよい。例えば、お気に入りに登録しているユーザ１人につき商品１個の需要があるとする。また、商品Ａのお気に入りへの登録数が３０００であり、商品Ｂのお気に入りへの登録数が２０００であるとする。その場合、商品Ａに対して３０００個分の需要があり、商品Ｂに対して２０００個分の需要があることになる。
【００３５】
ところで、各商品はそれぞれジャンル分けされている。商品のジャンル（本発明における区分の一例）は、商品を、例えば種類、性質、用途等で区分したときに、同じような種類、性質、用途等の商品が属する範囲である。ここで、あるジャンルの商品をあるユーザが購入するとき、そのジャンルの商品を同時期に複数購入することが一般的にはないジャンルがある。そのようなジャンルの商品として、例えば、冷蔵庫がある。冷蔵庫は、一般的には１つの家庭で１台購入されると、その家庭ではその後数年の間購入されることがない。例えば、あるユーザが、冷蔵庫の商品Ｃ、Ｄ及びＥをお気に入りに登録しているとする。この場合、そのユーザが商品Ｃ、Ｄ及びＥの全てを購入するつもりでお気に入りに登録しているとは考えにくい。この場合、そのユーザは、商品Ｃ、Ｄ及びＥを購入候補として、その中から何れかの商品を購入するつもりである蓋然性が高い。従って、商品Ｃ、Ｄ及びＥのうち商品Ｃが購入される商品として選択される確率は、単純計算では１／３である。そして、実際に商品Ｃが購入された場合、商品Ｃに対しては現実に需要があったが、商品Ｄ及びＥに対しては現実の需要はなかったことになる。このことから、１人のユーザが同時期に複数購入することが一般的にないジャンルの商品について、あるユーザがお気に入りに登録している数（以下、「同一ジャンル登録数」という）が多いほど、個々の商品に対する将来の需要は小さくなると考えられる。
【００３６】
そこで、電子商取引サーバ１は、このようなジャンルの商品の需要を予測する場合、ユーザごとに同一ジャンル登録数を計算する。そして、電子商取引サーバ１は、同一ジャンル登録数に基づいて、ユーザごとの需要を設定する。具体的に、電子商取引サーバ１は、予め設定された１人分に応じた需要に対して同一ジャンル登録数分の１となる需要を計算することによりユーザごとに需要を計算する。つまり、電子商取引サーバ１は、
【００３７】
あるユーザの需要＝１人分に応じた需要／そのユーザの同一ジャンル登録数
【００３８】
を計算する。そして、電子商取引サーバ１は、各ユーザについて計算した需要の和を計算することで、全ユーザの需要を予測する。
【００３９】
一方、電子商取引サーバ１は、１人のユーザが同時期に複数購入する可能性があるジャンルの商品の需要を予測する場合、同一ジャンル登録数の大きさにかかわらず、１人のユーザにつき予め設定された１人分に応じた需要があるとしてもよい。例えば、洋服は、同時期に複数購入される可能性がある。
【００４０】
あるいは、電子商取引サーバ１は、１人のユーザが同時期に複数購入する可能性があるジャンルの商品の需要を予測する場合、ユーザの過去の購入傾向に基づいてユーザごとの需要を計算し、計算した需要の和を計算することで、全ユーザの需要を予測してもよい。１人のユーザが同時期に複数購入する可能性があるジャンルであるとしても、そのジャンルの商品が複数お気に入りに登録されている場合、登録されている全ての商品が購入されるとは限らない。同時期に何個の商品が購入されるかは、一般的にはユーザごとに異なる。そこで、電子商取引サーバ１は、ユーザごとに、需要の予測対象の商品が属するジャンルの商品について、同時期における購入数（以下、「同時期購入数」という）を算出する。そして、電子商取引サーバ１は、同時期購入数が同一ジャンル登録数以上である場合には、予め設定された１人分に応じた需要があるとする。ユーザが同時期に購入する数が、お気に入りに登録されている商品の数以上であるため、登録されている全ての商品がそのユーザによって購入される蓋然性があるからである。つまり、登録されている全ての商品に対して需要があると考えられるからである。一方、電子商取引サーバ１は、同時期購入数が同一ジャンル登録数未満である場合には、同時期購入数と同一ジャンル登録数に基づいて、予め設定された１人分に応じた需要未満の範囲内でユーザごとに需要を設定する。具体的に電子商取引サーバ１は、予め設定された１人分に応じた需要を同時期購入数倍し、その結果に対して同一ジャンル登録数分の１を計算することにより、ユーザごとの需要を計算する。つまり、電子商取引サーバ１は、
【００４１】
あるユーザの需要＝１人分に応じた需要×そのユーザの同時期購入数／そのユーザの同一ジャンル登録数
【００４２】
を計算する。お気に入りに登録されている商品のうち、ユーザが同時期に購入する数までの需要があると考えられるからである。
【００４３】
また、電子商取引サーバ１は、お気に入りへの商品の登録の履歴やお気に入りからの商品の削除の履歴を記録しておき、この履歴とお気に入りとに基づいて、商品の需要を予測してもよい。例えば、電子商取引サーバ１は、予め設定された期間（例えば、現在から１週間前までの期間、１ヶ月前までの期間等）における需要の予測対象の商品のお気に入りの登録数の増減数に基づいて、商品の需要を補正してもよい。これまでお気に入りの登録数が減っている商品は、この後も登録数が減っていく蓋然性がある。従って、そのような商品は、これから需要が減っていく蓋然性がある。そこで、電子商取引サーバ１は、例えば、お気に入りの登録数が減少した商品については、減少した数が多いほど、その商品の需要を補正前よりも小さくなるように補正してもよい。また、電子商取引サーバ１は、例えば、お気に入りの登録数が増加した商品については、増加した数が多いほど、その商品の需要を補正前よりも大きくなるように補正してもよい。
【００４４】
また、電子商取引サーバ１は、お気に入りからの商品の削除の履歴とお気に入りとに基づいて、商品の需要を予測してもよい。例えば、電子商取引サーバ１は、予め設定された期間におけるお気に入りからの需要の予測対象の商品が削除された数に基づいて、商品の需要を補正してもよい。具体的に、電子商取引サーバ１は、削除された数が多いほど、商品の需要を補正前よりも小さくなるように補正する。
【００４５】
また、電子商取引サーバ１は、需要の予測を要求してきた店舗に対する需要（以下、「店舗需要」という）を予測してもよい。過去の販売実績により、需要の予測を要求してきた店舗の電子商店街における市場占有率を計算することができる。そこで、電子商取引サーバ１は、電子商店街全体における需要（以下、「総需要」という）に市場占有率を乗算することにより、需要の予測を要求してきた店舗の需要を予測することができる。
【００４６】
次に、お気に入りに基づく需要の予測結果を示す情報の表示例について説明する。図２（ａ）乃至（ｅ）は、商品需要予測結果ページ内における需要の予測結果を示す情報の表示例である。
【００４７】
商品需要予測結果ページ内に、複数の商品の需要の情報を同時に表示させる場合がある。この場合、電子商取引サーバ１は、需要の予測対象の商品のうち同じ商品のジャンルに属する複数の商品については、商品間における需要の大小関係を予測し、需要の大小関係を示す情報が商品需要予測結果ページに表示されるようにする。同じジャンルに属する複数の商品は、店舗によって需要が比較される商品同士となるからである。店舗は、需要を比較することにより、例えば、どの商品を仕入れるべきか、どの商品の販売に力を入れるか等を検討する。
【００４８】
例えば、電子商取引サーバ１は、図２（ａ）に示すように、商品Ａは３０００個分、商品Ｂは２０００個分と、各商品のお気に入りへの登録数がそのまま表示されるようにしてもよい。また例えば、電子商取引サーバ１は、図２（ｂ）に示すように、商品Ａ：商品Ｂ＝３：２というように、需要の比率が表示されるようにしてもよい。また、電子商取引サーバ１は、図２（ｃ）に示すように、「商品Ａの方が商品Ｂよりも需要があります」という情報が表示されるようにしてもよいし、「商品Ａ＞商品Ｂ」という情報が表示されてもよい。また、電子商取引サーバ１は、図２（ｄ）に示すように、需要の大小関係を示す情報とともに、予め設定された期間における各商品のお気に入りの登録数の増減数が表示されるようにしてもよい。また、電子商取引サーバ１は、図２（ｅ）に示すように、需要の大小関係を示す情報とともに、各商品のお気に入りの登録数の増減数の推移を示すグラフが表示されるようにしてもよい。
【００４９】
また、需要の予測を要求してきた店舗における需要の予測対象の商品のこれまでの販売数が、お気に入りに基づいて予測された需要に対して相当に小さい場合には、潜在的な需要があるにもかかわらず、何らかの原因（例えば、価格が高い等）で売れ行きがよくないことが考えられる。そこで、電子商取引サーバ１は、このような場合に応じた情報も表示されるようにしてもよい。例えば、「商品Ａの需要は３０００ありますが、何らかの原因で売れ行きが伸びていません。」等の情報が表示されるようにしてもよい。電子商取引サーバ１は、例えば、販売数が予め設定された閾値以下である場合や、販売数が予測された需要の所定数分の１以下である場合等にこのような表示が行われるようにしてもよい。
【００５０】
また、電子商取引サーバ１は、総需要または店舗需要の何れか一方のみが表示されるようにしてもよいし、両方が表示されるようにしてもよい。
【００５１】
［２．電子商取引サーバの構成］
次に、電子商取引サーバ１の構成について、図３及び図４を用いて説明する。
【００５２】
図３は、本実施形態に係る電子商取引サーバ１の概要構成の一例を示すブロック図である。図３に示すように、電子商取引サーバ１は、通信部１１と、記憶部１２と、入出力インターフェース１３と、システム制御部１４と、を備えている。そして、システム制御部１４と入出力インターフェース１３とは、システムバス１５を介して接続されている。
【００５３】
通信部１１は、ネットワークＮＷに接続して、店舗端末２やユーザ端末３等との通信状態を制御するようになっている。
【００５４】
記憶部１２（本発明における記憶手段、削除履歴記憶手段及び購入履歴記憶手段の一例）は、例えば、ハードディスクドライブ等により構成されている。この記憶部１２には、会員情報ＤＢ（データベース）１２ａ、ジャンル情報ＤＢ１２ｂ、店舗情報ＤＢ１２ｃ、商品情報ＤＢ１２ｄ、閲覧履歴ＤＢ１２ｅ、購入履歴ＤＢ１２ｆ、お気に入り情報ＤＢ１２ｇ、お気に入り登録削除履歴ＤＢ１２ｈ等のデータベースが構築されている。
【００５５】
図４（ａ）は、会員情報ＤＢ１２ａに登録される内容の一例を示す図である。会員情報ＤＢ１２ａには、電子商取引システムＳに会員登録しているユーザに関する会員情報が登録される。具体的に、会員情報ＤＢ１２ａには、ユーザＩＤ、パスワード、ニックネーム、氏名、生年月日、性別、郵便番号、住所、電話番号、電子メールアドレス等のユーザの属性が、ユーザごとに対応付けて登録される。ユーザＩＤは、ユーザの識別情報である。
【００５６】
図４（ｂ）は、ジャンル情報ＤＢ１２ｂに登録される内容の一例を示す図である。ジャンル情報ＤＢ１２ｂには、商品のジャンルに関するジャンル情報が登録されている。具体的に、ジャンル情報ＤＢ１２ｂには、ジャンルＩＤ、ジャンル名、ジャンルのレベル、親ジャンルＩＤ、子ジャンルＩＤリスト、複数購入対象外フラグ等のジャンルの属性が、ジャンルごとに対応付けて登録される。ジャンル情報は、例えば、電子商店街の管理者等により設定される。
【００５７】
商品のジャンルは、木構造で階層的に定義されている。具体的に、木構造の各ノードが、ジャンルに相当する。ノードの深さが、そのノードに相当するジャンルのレベル（階層）に相当する。ノードの深さは、根に位置するノード（以下、「根ノード」という）からの距離である。レベルの値が大きいほど、レベルとしての深さが深く、レベルの値が小さいほど、レベルとしての深さが浅い。根ノードが有する子ノードに相当するジャンルがレベル１のジャンルである。レベル１のジャンルが最上位のジャンルである。レベル１の各ジャンルに対しては、子ノードに相当するジャンルが、レベル２のジャンルとして定義されている。ここで、あるジャンルＣ１の子ノードに相当するジャンルＣ２を、ジャンルＣ１の「子ジャンル」という。子ジャンルを、サブジャンルともいう。また、このときのジャンルＣ１を、ジャンルＣ２の「親ジャンル」という。子ジャンルは、親ジャンルを更に複数に区分したときに、同じような商品が属する範囲である。従って、子ジャンルは親ジャンルに属する。また、あるジャンルに対して、子孫のノードに相当するジャンルを、「子孫ジャンル」という。例えば、ジャンルＣ３がジャンルＣ２の子ジャンルであるとする。この場合、ジャンルＣ２及びＣ３は、ジャンルＣ１の子孫ジャンルである。また、あるジャンルに対して、先祖のノードに相当するジャンルを、「先祖ジャンル」という。ジャンルＣ１及びＣ２は、ジャンルＣ３の先祖ジャンルである。なお、同じジャンルに属する複数の商品とは、それぞれの商品が属するレベル１のジャンルから最下位のレベルのジャンルまでの全てのジャンルが互いに一致する商品同士のみに限られるものではない。同じジャンルに属する複数の商品とは、レベル１のジャンルから最下位のレベルのジャンルのうち少なくとも１つのジャンルにおいて同じジャンルに属する商品同士も含まれる。具体的には、レベル１のジャンルから、最下位のレベルのジャンルよりも上位のレベルのジャンルのうちあるレベルのジャンルまでが互いに一致する複数の商品であってもよい。最下位のレベルで同じジャンルに属するか否かを判断すると、同じジャンルに属する商品の範囲が狭くなりすぎる場合があるからである。レベル１のジャンルからどのレベルのジャンルまでが一致する場合に、同じジャンルに属する複数の商品とするかは、例えば、管理者等により予め設定されてもよいし、ジャンルに応じて定められてもよい。
【００５８】
ジャンルＩＤは、ジャンル情報によって定義されるジャンルの識別情報である。親ジャンルＩＤは、ジャンル情報によって定義されるジャンルの親ジャンルのジャンルＩＤである。子ジャンルＩＤリストは、ジャンル情報によって定義されるジャンルの子ジャンルのジャンルＩＤのリストである。子ジャンルＩＤリストは、ジャンル情報によって定義されるジャンルが子ジャンルを有する場合に設定される。複数購入対象外フラグは、ジャンル情報によって定義されるジャンルが一般的に１人のユーザにより同時期に複数購入される可能性がある商品のジャンルであるか否かを示す。複数購入対象外フラグがＯＮに設定されている場合、複数購入されない商品のジャンルであることを示し、複数購入対象外フラグがＯＦＦに設定されている場合、複数購入される可能性がある商品のジャンルであることを示す。
【００５９】
図４（ｃ）は、店舗情報ＤＢ１２ｃに登録される内容の一例を示す図である。店舗情報ＤＢ１２ｃには、電子商店街に出店している店舗に関する店舗情報が登録される。具体的に、店舗情報ＤＢ１２ｃには、店舗ＩＤ、店舗名、郵便番号、住所、電話番号、電子メールアドレス、取扱ジャンル情報等の店舗の属性が、店舗ごとに対応付けて登録される。店舗ＩＤは、店舗の識別情報である。取扱ジャンル情報は、店舗が取り扱っている商品（店舗が販売している商品）のジャンルを示す情報である。具体的に、取扱ジャンル情報には、店舗が取り扱っている商品のジャンルごとにジャンルＩＤが設定されている。
【００６０】
図４（ｄ）は、商品情報ＤＢ１２ｄに登録される内容の一例を示す図である。商品情報ＤＢ１２ｄには、電子商店街で販売されている商品に関する商品情報が登録される。具体的に、商品情報ＤＢ１２ｄには、商品ＩＤ、店舗ＩＤ、商品コード、ジャンルＩＤ、商品名、商品画像のＵＲＬ（Uniform Resource Locator）、商品説明、商品価格等の商品の属性が、店舗が販売する商品ごとに対応付けて登録される。商品ＩＤ（本発明における取引対象を示す情報の一例）は、店舗等が、販売する商品を管理するための商品の識別情報である。店舗ＩＤは、商品の販売元の店舗を示す。商品コードは、商品を識別するコード番号である。商品コードとしては、例えば、ＪＡＮ（Japanese Article Number Code）コード等がある。ジャンルＩＤは、商品が属するジャンルのジャンルＩＤである。商品情報に設定されるジャンルＩＤは、基本的に最下位のレベルに定義されているジャンル（木構造における葉ノードに相当するジャンル）のジャンルＩＤが設定される。つまり、各商品は、最も細分化されたジャンルでジャンル分けされている。
【００６１】
図４（ｅ）は、閲覧履歴ＤＢ１２ｅに登録される内容の一例を示す図である。閲覧履歴ＤＢ１２ｅには、電子商店街の商品ページの閲覧履歴が登録される。具体的に、閲覧履歴ＤＢ１２ｅには、商品ＩＤ、閲覧日時及びユーザＩＤが、商品ページが閲覧されるごとに対応付けて登録される。商品ＩＤは、商品ページが閲覧された商品を示す。閲覧日時は、商品ページが閲覧された日時を示す。具体的に、閲覧日時は、電子商取引サーバ１がユーザ端末３へ商品ページを送信した日時である。ユーザＩＤは、商品ページを閲覧したユーザを示す。
【００６２】
図４（ｆ）は、購入履歴ＤＢ１２ｆに登録される内容の一例を示す図である。購入履歴ＤＢ１２ｆには、ユーザによる商品の購入履歴が登録される。具体的に、購入履歴ＤＢ１２ｆには、注文コード、購入日時、ユーザＩＤ、商品ＩＤ、店舗ＩＤ、商品コード、購入数等が、商品の購入ごとに対応付けて登録される。注文コードは、商品の注文が行われるたびに付与される注文の識別情報である。ユーザＩＤは、購入したユーザを示す。商品ＩＤ及び商品コードは、購入された商品を示す。店舗ＩＤは、購入先の店舗を示す。購入数は、購入された商品の個数である。
【００６３】
図４（ｇ）は、お気に入り情報ＤＢ１２ｇに登録される内容の一例を示す図である。お気に入り情報ＤＢ１２ｇには、ユーザのお気に入りに関するお気に入り情報（本発明における参照リスト情報の一例）が登録される。具体的に、お気に入り情報ＤＢ１２ｇには、ユーザＩＤ、商品ＩＤ、登録日時等が、お気に入りに商品が登録されるごとに対応付けて登録される。ユーザＩＤは、お気に入りへの登録を行ったユーザを示す。商品ＩＤは、お気に入りに登録された商品を示す。また、商品ＩＤは、お気に入りに登録された商品の商品ページへの参照に相当する情報である。商品ページへの実際の参照の情報はＵＲＬであるが、商品ページのＵＲＬは、商品ＩＤから特定することが可能である。なお、商品ページのＵＲＬが、商品ＩＤとともにまたは商品ＩＤの代わりにお気に入り情報ＤＢ１２ｇに登録されるようになっていてもよい。登録日時は、お気に入りへの登録が行われた日時を示す。
【００６４】
図４（ｈ）は、お気に入り登録削除履歴ＤＢ１２ｈに登録される内容の一例を示す図である。お気に入り登録削除履歴ＤＢ１２ｈには、お気に入りに対する商品の登録や削除の履歴であるお気に入り登録削除履歴が登録される。具体的に、お気に入り登録削除履歴ＤＢ１２ｈには、ユーザＩＤ、操作種別、操作日時、商品ＩＤ等が、お気に入りに対して商品が登録されたり削除されたりするごとに対応付けて登録される。ユーザＩＤは、お気に入りに対して商品の登録または削除を行ったユーザを示す。操作種別は、お気に入りへの登録が行われたか、またはお気に入りからの削除が行われたかの何れかを示す。操作日時は、お気に入りに対して商品の登録または削除が行われた日時を示す。商品ＩＤは、お気に入りに対して登録または削除された商品を示す。
【００６５】
なお、記憶部１２には、例えば、商品コード別に商品に関する情報（例えば、商品の正式名称、商品のジャンルのジャンルＩＤ、商品の仕様等）が登録されるカタログＤＢ等のデータベースも構築されている。
【００６６】
次に、記憶部１２に記憶されるその他の情報について説明する。記憶部１２には、Ｗｅｂページを表示するためのＨＴＭＬ（HyperText Markup Language）文書、ＸＭＬ（Extensible Markup Language）文書、画像データ、テキストデータ、電子文書等の各種データが記憶されている。また、記憶部１２には、管理者等により設定された各種の設定値が記憶されている。
【００６７】
また、記憶部１２には、オペレーティングシステム、ＷＷＷ（World Wide Web）サーバプログラム、ＤＢＭＳ（Database Management System）、電子商取引管理プログラム等の各種プログラムが記憶されている。電子商取引管理プログラムは、電子商取引に関する各種の処理を実行するためのプログラムである。なお、各種プログラムは、例えば、他のサーバ装置等からネットワークＮＷを介して取得されるようにしてもよいし、ＤＶＤ（Digital Versatile Disc）等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。
【００６８】
入出力インターフェース１３は、通信部１１及び記憶部１２とシステム制御部１４との間のインターフェース処理を行うようになっている。
【００６９】
システム制御部１４は、ＣＰＵ１４ａ、ＲＯＭ（Read Only Memory）１４ｂ、ＲＡＭ（Random Access Memory）１４ｃ等により構成されている。そして、システム制御部１４は、ＣＰＵ１４ａが、各種プログラムを読み出し実行することにより、本発明における取得手段、予測手段、判定手段、登録数取得手段、購入数取得手段、数判定手段及び占有率取得手段として機能するようになっている。
【００７０】
なお、電子商取引サーバ１が、複数のサーバ装置で構成されてもよい。例えば、お気に入りに関する処理を行うサーバ装置、電子商店街において商品の検索や注文等の処理を行うサーバ装置、商品の需要の予測の処理を行うサーバ装置、ユーザ端末３からのリクエストに応じてＷｅｂページを送信するサーバ装置、及びデータベースを管理するサーバ装置等が、互いにＬＡＮ等で接続されてもよい。
【００７１】
［３．電子商取引システムの動作］
次に、電子商取引システムＳの動作について、図５乃至図７を用いて説明する。
【００７２】
図５は、本実施形態に係る電子商取引サーバ１のシステム制御部１４の需要予測リクエスト受信時処理における処理例を示すフローチャートである。
【００７３】
店舗の従業員等は、商品の需要の予測を要求するため、店舗端末２を操作する。すると、店舗端末２は、需要予測リクエストを電子商取引サーバ１へ送信する。需要予測リクエストは、商品の需要の予測を要求する店舗の店舗ＩＤが設定されている。需要予測リクエスト受信時処理は、電子商取引サーバ１が店舗端末２から需要予測リクエストを受信したときに開始される。
【００７４】
先ず、システム制御部１４は、需要の予測対象の商品の商品コードを取得する（ステップＳ１）。例えば、店舗の従業員等が需要の予測対象の商品の商品コードを指定し、システム制御部１４が、指定された商品コードを店舗端末２から取得してもよい。また、システム制御部１４は、需要予測リクエストに設定された店舗ＩＤを含む店舗情報から取扱ジャンル情報を取得し、取扱ジャンル情報に基づいて、需要の予測を要求した店舗が取り扱っているジャンルの商品の商品コードを複数取得してもよい。また、システム制御部１４は、需要予測リクエストに設定された店舗ＩＤを含む各商品情報から、需要の予測を要求した店舗が取り扱っている商品の商品コードを取得してもよい。
【００７５】
次いで、システム制御部１４は、需要の予測対象の商品のインデックスｉに１を設定する（ステップＳ２）。次いで、システム制御部１４は、需要の予測対象の商品のうち１つを、商品ｉとして選択する（ステップＳ３）。次いで、システム制御部１４は、１商品需要予測処理を実行する（ステップＳ４）。
【００７６】
図６は、本実施形態に係る電子商取引サーバ１のシステム制御部１４の１商品需要予測処理における処理例を示すフローチャートである。１商品需要予測処理において、システム制御部１４は、予測手段として、商品ｉの需要を予測する。
【００７７】
先ず、システム制御部１４は、商品ｉの電子商店街全体における需要の値を示す総需要ｉに０を設定する（ステップＳ２１）。次いで、システム制御部１４は、商品ｉの商品コードに対応するジャンルＩＤを、カタログＤＢから取得する（ステップＳ２２）。次いで、システム制御部１４は、取得したジャンルＩＤを含むジャンル情報から、複数購入対象外フラグを取得する（ステップＳ２３）。次いで、システム制御部１４は、商品情報ＤＢ１２ｄから商品ｉの商品コードを含む商品情報を検索し、検索された各商品情報から商品ＩＤを取得する（ステップＳ２４）。つまり、システム制御部１４は、商品ｉを販売している各店舗において商品ｉに付与されている商品ＩＤを取得する。次いで、システム制御部１４は、取得手段として、ステップＳ２４において取得した商品ＩＤごとに、お気に入り情報ＤＢ１２ｇから商品ＩＤを含むお気に入り情報を検索して取得する（ステップＳ２５）。つまり、システム制御部１４は、商品ｉをお気に入りとして登録していることを示すお気に入り情報を全て取得する。
【００７８】
次いで、システム制御部１４は、取得したお気に入り情報のうち１つを選択する。そして、システム制御部１４は、選択したお気に入り情報に設定されているユーザＩＤを、処理対象のユーザＩＤとして取得する（ステップＳ２６）。次いで、システム制御部１４は、１ユーザ需要予測処理を実行する（ステップＳ２７）。
【００７９】
図７は、本実施形態に係る電子商取引サーバ１のシステム制御部１４の１ユーザ需要予測処理における処理例を示すフローチャートである。１ユーザ需要予測処理において、システム制御部１４は、処理対象ユーザの商品ｉに対する需要を予測する。なお、図７に示す処理例は、１人分に応じた需要は商品１個分であるとした場合の処理例である。
【００８０】
先ず、システム制御部１４は、商品情報ＤＢ１２ｄから処理対象ユーザのユーザＩＤを含むお気に入り情報を検索する（ステップＳ５１）。次いで、システム制御部１４は、検索されたお気に入り情報から商品ＩＤを取得する。そして、システム制御部１４は、商品ＩＤを含む商品情報からジャンルＩＤを取得する（ステップＳ５２）。次いで、システム制御部１４は、登録数取得手段として、ステップＳ５２において取得したジャンルＩＤのうち、１商品需要予測処理のステップＳ２２において取得した商品ｉのジャンルＩＤと一致する数を計算する。これにより、システム制御部１４は、対象ユーザがお気に入りに登録している商品のうち商品ｉが属するジャンルの商品の数である同一ジャンル登録数を計算する（ステップＳ５３）。
【００８１】
次いで、システム制御部１４は、判定手段として、１商品需要予測処理のステップＳ２３において取得した複数購入対象外フラグがＯＮに設定されているか否かを判定する（ステップＳ５４）。このとき、システム制御部１４は、複数購入対象外フラグがＯＮに設定されていると判定した場合には（ステップＳ５４：ＹＥＳ）、対象ユーザの需要の予測値として、１／同一ジャンル登録数を設定する（ステップＳ５５）。
【００８２】
一方、システム制御部１４は、複数購入対象外フラグがＯＦＦに設定されていると判定した場合には（ステップＳ５４：ＮＯ）、処理対象ユーザのユーザＩＤを含む購入履歴を検索する（ステップＳ５６）。次いで、システム制御部１４は、検索された各購入履歴から商品ＩＤを取得する。そして、システム制御部１４は、取得した商品ＩＤを含む商品情報からジャンルＩＤを取得する（ステップＳ５７）。次いで、システム制御部１４は、検索された購入履歴の中から、その購入履歴に含まれる商品ＩＤが１商品需要予測処理のステップＳ２２において取得した商品ｉのジャンルＩＤと一致する購入履歴を抽出する（ステップＳ５８）。つまり、システム制御部１４は、商品ｉが属するジャンルの商品を対象ユーザが購入したことを示す購入履歴を抽出する。
【００８３】
次いで、システム制御部１４は、購入数取得手段として、抽出した購入履歴に基づいて、同時期購入数を計算する（ステップＳ５９）。具体的に、システム制御部１４は、現在から遡って同時期とみなす期間（例えば、１時間、１日、１週間、１ヶ月等）ごとに、その期間に購入日時が含まれる購入履歴を特定する。次いで、システム制御部１４は、各期間において特定した各購入履歴に含まれる購入数の和を計算して、期間ごとの購入数を計算する。例えば、同時期とみなす期間を１日とする。この場合、システム制御部１４は、昨日の購入数、今日の２日前の購入数、３日前の購入数・・・を計算する。どこまで遡って計算するかは、例えば、予め設定されている。次いで、システム制御部１４は、期間ごとに計算した購入数のうち、１以上を示す購入数の平均値を計算することにより、同時期購入数を計算する。同時期購入数は、あくまでもユーザがあるジャンルの商品を購入した時期において、そのジャンルの商品をその時期に購入した数であるので、購入がなかった期間（購入数が０である期間）は、同時期購入数の計算には含まれない。例えば、同時期とみなす期間を１日とし、昨日から１週間前まで１日ごとの購入数を計算したとする。このとき、それぞれの購入数が、０、０、３、０、０、１である場合、同時期購入数は、（１＋３）／２＝２である。なお、電子商取引サーバ１は、購入数の平均値を計算するのではなく、例えば、ユーザが現在から直近に購入を行った期間における購入数を、同時期購入数としてもよい。例えば、上述の例では、３日前の購入数である３が、同時期購入数とされる。また例えば、電子商取引サーバ１は、期間ごとに計算した購入数のうち最大の購入数を同時購入数としてもよい。また、商品ｉが属するジャンルの商品のうちユーザが同時に購入した商品の数を同時期購入数としてもよい。つまり、システム制御部１４は、購入日時が同一である購入履歴ごとに、商品ｉが属するジャンルの商品の購入数を計算して、例えば、購入数の平均値を計算したり、最大の購入数を特定したりすることにより、同時期購入数を求めてもよい。
【００８４】
システム制御部１４は、同時期購入数を計算すると、数判定手段として、同時期購入数が同一ジャンル登録数以上であるか否かを判定する（ステップＳ６０）。このとき、システム制御部１４は、同時期購入数が同一ジャンル登録数以上であると判定した場合には（ステップＳ６０：ＹＥＳ）、対象ユーザの需要の予測値として、１を設定する（ステップＳ６１）。一方、システム制御部１４は、同時期購入数が同一ジャンル登録数以上ではないと判定した場合には（ステップＳ６０：ＮＯ）、対象ユーザの需要の予測値として、同時期購入数／同一ジャンル登録数を設定する（ステップＳ６２）。システム制御部１４は、対象ユーザの需要の予測値の設定を終えると（ステップＳ５５、Ｓ６１またはＳ６２）、１ユーザ需要予測処理を終了させる。
【００８５】
次いで、システム制御部１４は、図６に示すように、１ユーザ需要予測処理で設定された対象ユーザの需要の予測値を、総需要ｉに加算する（ステップＳ２８）。次いで、システム制御部１４は、ステップＳ２５において取得したお気に入り情報のうちまだ選択していないお気に入り情報があるか否かを判定する（ステップＳ２９）。このとき、システム制御部１４は、まだ選択していないお気に入り情報があると判定した場合には（ステップＳ２９：ＹＥＳ）、まだ選択していないお気に入り情報のうち１つを選択する。そして、システム制御部１４は、選択したお気に入り情報に設定されているユーザＩＤを、処理対象のユーザＩＤとして取得する（ステップＳ３０）。次いで、システム制御部１４は、ステップＳ２７に移行する。システム制御部１４は、ステップＳ２７〜Ｓ３０の処理を繰り返すことにより、商品ｉをお気に入りに登録している各ユーザの需要の予測値の和を、総需要ｉとして計算する。
【００８６】
そして、システム制御部１４は、全てのお気に入り情報を選択したと判定した場合には（ステップＳ２９：ＮＯ）、ステップＳ２４において取得した商品ｉの商品ＩＤごとに、お気に入り登録削除履歴ＤＢ１２ｈから、取得した商品ＩＤを含むお気に入り登録削除履歴を検索する（ステップＳ３１）。つまり、システム制御部１４は、お気に入りに対する商品ｉの登録及び削除の履歴を検索する。このとき、システム制御部１４は、操作日時が予め設定された期間（例えば、現在から１週間前までの期間、現在から１ヶ月前までの期間等）に含まれるお気に入り登録削除履歴のみを検索する。次いで、システム制御部１４は、検索されたお気に入り登録削除履歴に基づいて、商品ｉのお気に入りの登録数の増減数を計算する（ステップＳ３２）。具体的に、システム制御部１４は、操作種別が登録を示すお気に入り登録削除履歴の数から、操作種別が削除を示すお気に入り登録削除履歴の数を減算することにより、増減数を計算する。次いで、システム制御部１４は、計算した増減数に基づいて、総需要ｉを補正する（ステップＳ３３）。例えば、システム制御部１４は、増減数がマイナスである場合には、増減数に予め設定された係数を乗算し、乗算した結果を総需要ｉに加算してもよい。
【００８７】
次いで、システム制御部１４は、購入履歴ＤＢ１２ｆから商品ｉの商品コードを含む購入履歴を検索する。このとき、システム制御部１４は、購入日時が予め設定された期間に含まれる購入履歴のみを検索する。そして、システム制御部１４は、検索された各購入履歴に含まれる購入数の和を計算することにより、予め設定された期間における商品ｉの総販売数を計算する（ステップＳ３４）。次いで、システム制御部１４は、検索された購入履歴の中から、商品の需要の予測を要求した店舗の店舗ＩＤを含む購入履歴を抽出する。そして、システム制御部１４は、抽出された各購入履歴に含まれる購入数の和を計算することにより、商品の需要の予測を要求した店舗の予め設定された期間における商品ｉの販売数を計算する（ステップＳ３５）。次いで、システム制御部１４は、占有率取得手段として、商品の需要の予測を要求した店舗の販売数を総販売数で除算することにより、商品の需要の予測を要求した店舗の商品ｉの市場占有率を計算する（ステップＳ３６）。次いで、システム制御部１４は、総需要ｉに市場占有率を乗算することにより、商品の需要の予測を要求した店舗の需要の値を示す店舗需要ｉを計算する（ステップＳ３７）。システム制御部１４は、この処理を終えると、１商品需要予測処理を終了させる。
【００８８】
次いで、システム制御部１４は、図５に示すように、需要の予測対象の商品のうちまだ選択していない商品があるか否かを判定する（ステップＳ５）。このとき、システム制御部１４は、まだ選択していない商品があると判定した場合には（ステップＳ５：ＹＥＳ）、インデックスｉに１を加算する（ステップＳ６）。次いで、システム制御部１４は、まだ選択していない商品のうち１つを、商品ｉとして選択する（ステップＳ７）。次いで、システム制御部１４は、ステップＳ４に移行する。システム制御部１４は、ステップＳ４〜Ｓ７の処理を繰り返すことにより、需要の予測対象の各商品の店舗需要を計算する。
【００８９】
そして、システム制御部１４は、全ての商品を選択したと判定した場合には（ステップＳ５：ＮＯ）、各商品の店舗需要に基づいて、予測した需要を示す情報を生成する（ステップＳ８）。このとき、システム制御部１４は、需要の予測対象の商品の中に同一のジャンルに属する商品が複数存在する場合には、同一のジャンルに属する商品間における大小関係を示す情報を生成する。例えば、システム制御部１４は、図２（ａ）に示すように、店舗需要の値をそのまま示す情報を生成してもよい。また例えば、システム制御部１４は、店舗需要の比率を計算し、図２（ｂ）に示すように、比率を示す情報を生成してもよい。また例えば、システム制御部１４は、店舗需要の比較を行うことにより、図２（ｃ）に示すような情報を生成してもよい。また、システム制御部１４は、ある商品について、同一のジャンルに属する他の商品が存在しない場合には、店舗需要の値をそのまま示す情報を生成してもよい。また例えば、システム制御部１４は、図２（ｄ）や図２（ｅ）に示すように、需要を示す情報に、お気に入りの登録数の増減数の情報を付加してもよい。
【００９０】
次いで、システム制御部１４は、需要を示す情報を含む商品需要予測結果ページを生成し、需要予測リクエストの送信元の店舗端末２へ、生成した商品需要予測結果ページを送信する（ステップＳ９）。システム制御部１４は、この処理を終えると、需要予測リクエスト受信時処理を終了させる。
【００９１】
なお、システム制御部１４は、ステップＳ２２、Ｓ５３及びＳ５７において、カタログＤＢや商品情報ＤＢ１２ｄからジャンルＩＤを取得し、ステップＳ５３及びＳ５８において、取得したジャンルＩＤ同士が一致するか否かを判定していた。つまり、システム制御部１４は、商品が分類されている最下位のジャンルを比較することにより、需要の予測対象の商品と同じジャンルに属する商品を特定していた。しかしながら、システム制御部１４は、カタログＤＢや商品情報ＤＢ１２ｄから取得したジャンルＩＤが示すジャンルの先祖のジャンルのジャンルＩＤが一致するか否かを判定してもよい。つまり、システム制御部１４は、最下位のレベルのジャンルではなく、そのジャンルよりも上位のジャンルで、需要の予測対象の商品と同じジャンルに属する商品を特定してもよい。最下位のレベルで同じジャンルに属するか否かを判定すると、同じジャンルに属する商品の範囲が狭くなりすぎる場合があるからである。また、ステップＳ８において同じジャンルに属する複数の商品を特定する場合についても同様である。ジャンル情報ＤＢ１２ｂに登録されているジャンル情報に含まれている親ジャンルＩＤにより、ジャンル情報により定義されているジャンルの親ジャンルを特定することができる。そのため、親ジャンルＩＤを手がかりとして、ジャンル情報ＤＢ１２ｂから先祖のジャンルのジャンルＩＤを取得することができる。
【００９２】
以上説明したように、本実施形態によれば、電子商取引サーバ１のシステム制御部１４が、お気に入り情報ＤＢ１２ｇから複数のお気に入り情報を取得し、取得されたお気に入り情報に基づいて、商品の需要を予測する。従って、例えば、過去の購入数に基づく需要の予測や商品ページへのアクセス数に基づく需要の予測よりも正確に需要を予測することができる。
【００９３】
また、システム制御部１４が、複数のジャンルのうち少なくとも１つのジャンルが同じジャンルに属する複数の商品間における需要の大小関係を予測する。従って、複数の商品間で需要を比較することができる。
【００９４】
また、システム制御部１４が、お気に入り情報ＤＢ１２ｇから取得されたお気に入り情報と、お気に入り登録削除履歴ＤＢ１２ｈに登録されたお気に入り登録削除履歴とに基づいて、商品の需要を予測する。従って、お気に入り登録削除履歴を更に考慮することにより、需要の予測精度を高めることができる。
【００９５】
また、システム制御部１４が、需要の予測対象の商品が属するジャンルの複数購入対象外フラグがＯＮであるか否かを判定し、需要の予測対象の商品が属するジャンの商品の同一ジャンル登録数をユーザごとに計算し、複数購入対象外フラグがＯＦＦであると判定された場合、１人分に対応する需要を各ユーザの需要に設定し、複数購入対象外フラグがＯＮであると判定された場合、１人分に対応する需要に対して同一ジャンル登録数の１となる需要を各ユーザの需要に設定し、予測対象の商品をお気に入りに登録している各ユーザのその商品に対する需要の和を計算してその和に応じた需要を予測する。従って、１人のユーザから同時期に１つのみ購入されるようなジャンルの商品が１人のユーザのお気に入りに複数登録されていても、その中からユーザが購入する商品は１つである蓋然性が高いことを考慮した需要の予測を行うことができるので、需要の予測精度を高めることができる。
【００９６】
また、システム制御部１４が、購入履歴ＤＢ１２ｆに登録された購入履歴に基づいて、予測対象の商品が属するジャンルの商品の同時期購入数をユーザごとに計算し、同時期購入数が同一ジャンル登録数以上であるか否かをユーザごとに判定し、需要の予測対象の商品が属するジャンルの複数購入対象外フラグがＯＦＦである場合において、同時期購入数が同一ジャンル登録数以上であると判定されたユーザの需要に１人分に対応する需要を設定し、同時期購入数が同一ジャンル登録数以上ではないと判定されたユーザの需要に、１人分に対応する需要を同時期購入数倍し、その結果に対して同一ジャンル登録数分の１となる需要を設定する。従って、１人のユーザから同時期に複数購入される可能性があるジャンルの商品が１人のユーザのお気に入りに複数登録されている場合、各ユーザの購入の傾向を考慮した需要の予測を行うことができるので、需要の予測精度を高めることができる。
【００９７】
また、システム制御部１４が、需要の予測対象の商品を販売する複数の店舗のうち需要の予測を要求した店舗による需要の予測対象の商品の市場占有率を計算し、お気に入り情報ＤＢ１２ｇから取得されたお気に入り情報と市場占有率とに基づいて、需要の予測を要求した店舗の需要を予測する。従って、需要を知りたい店舗に対する需要を予測することができる。
【００９８】
なお、上記実施形態においては、本発明における取引対象が商品に適用されていた。しかしながら、取引対象がサービスに適用されてもよい。そして、電子商取引のシステムとして、サービスの予約が可能なシステムに本発明が適用されてもよい。サービスの予約としては、例えば、宿泊施設の宿泊予約、ゴルフ場等の競技施設の利用予約、交通機関の座席の予約等がある。
【符号の説明】
【００９９】
１ 電子商取引サーバ
２ 店舗端末
３ ユーザ端末
１１ 通信部
１２ 記憶部
１２ａ 会員情報ＤＢ
１２ｂ ジャンル情報ＤＢ
１２ｃ 店舗情報ＤＢ
１２ｄ 商品情報ＤＢ
１２ｅ 閲覧履歴ＤＢ
１２ｆ 購入履歴ＤＢ
１２ｇ お気に入り情報ＤＢ
１２ｈ お気に入り登録削除履歴ＤＢ
１３ 入出力インターフェース
１４ システム制御部
１４ａ ＣＰＵ
１４ｂ ＲＯＭ
１４ｃ ＲＡＭ
１５ システムバス
ＮＷ ネットワーク
Ｓ 電子商取引システム
【特許請求の範囲】
【請求項１】
取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の前記参照リスト情報を取得する取得手段と、
前記取得手段により取得された前記参照リスト情報に基づいて、取引対象の需要を予測する予測手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
請求項１に記載の情報処理装置において、
前記予測手段は、取引対象の複数の区分のうち少なくとも１つの区分が同じ区分に属する複数の取引対象間における需要の大小関係を予測することを特徴とする情報処理装置。
【請求項３】
請求項１または請求項２に記載の情報処理装置において、
前記予測手段は、前記取得手段により取得された前記参照リスト情報と、ユーザによる前記参照リストからの取引対象の削除履歴を記憶する削除履歴記憶手段に記憶された前記削除履歴とに基づいて、該取引対象の需要を予測することを特徴とする情報処理装置。
【請求項４】
請求項１乃至３の何れか１項に記載の情報処理装置において、
取引対象の複数の区分のうち需要の予測対象の取引対象が属する区分が１人のユーザから同時期に複数購入される取引対象の区分であるか否かを判定する判定手段と、
前記予測対象の取引対象が属する区分の取引対象の前記参照リストの登録数をユーザごとに取得する登録数取得手段と、
を更に備え、
前記特定手段は、前記予測対象の取引対象を前記参照リストに登録している各ユーザの該取引対象に対する需要の和を計算して該和に応じた需要を予測し、前記判定手段により複数購入される取引対象の区分であると判定された場合、予め設定された設定需要を各ユーザの需要に設定し、前記判定手段により複数購入される取引対象の区分ではないと判定された場合、前記登録数取得手段によりユーザごとに取得された前記登録数に基づいて各ユーザの需要の設定を行うことを特徴とする情報処理装置。
【請求項５】
請求項４に記載の情報処理装置において、
ユーザにより購入された取引対象の区分を示す情報と、購入したユーザを示す情報と、購入時期とを対応付けて購入履歴として記憶する購入履歴記憶手段に記憶された前記購入履歴に基づいて、前記予測対象の取引対象が属する区分の取引対象の同時期における購入数をユーザごとに取得する購入数取得手段と、
前記購入数取得手段により取得された前記購入数が前記登録数取得手段により取得された前記登録数以上であるか否かをユーザごとに判定する数判定手段と、
を更に備え、
前記判定手段により複数購入される取引対象の区分であると判定された場合、前記特定手段は、前記数判定手段により前記購入数が前記登録数以上であると判定されたユーザの需要に前記設定需要を設定し、前記数判定手段により前記購入数が前記登録数以上ではないと判定されたユーザの需要に、前記購入数と前記登録数とに基づいて、前記設定需要未満となる需要を設定することを特徴とする情報処理装置。
【請求項６】
請求項１乃至５の何れか１項に記載の情報処理装置において、
需要の予測対象の取引対象を販売する複数の販売者のうち需要の予測を要求した販売者による該取引対象の市場占有率を取得する占有率取得手段を更に備え、
前記予測手段は、前記取得手段により取得された前記参照リスト情報と、前記占有率取得手段により取得された前記市場占有率とに基づいて、需要の予測を要求した販売者の需要を予測することを特徴とする情報処理装置。
【請求項７】
コンピュータにより実行される情報処理方法であって、
取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の前記参照リスト情報を取得する取得ステップと、
前記取得ステップにおいてり取得された前記参照リスト情報に基づいて、取引対象の需要を予測する予測ステップと、
を含むことを特徴とする情報処理方法。
【請求項８】
情報処理装置に含まれるコンピュータを、
取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の前記参照リスト情報を取得する取得手段、及び、
前記取得手段により取得された前記参照リスト情報に基づいて、取引対象の需要を予測する予測手段、
として機能させることを特徴とする情報処理プログラム。
【請求項９】
情報処理装置に含まれるコンピュータを、
取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の前記参照リスト情報を取得する取得手段、及び、
前記取得手段により取得された前記参照リスト情報に基づいて、取引対象の需要を予測する予測手段、
として機能させる情報処理プログラムがコンピュータ読み取り可能に記憶されていることを特徴とする記録媒体。
【請求項１】
取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の前記参照リスト情報を取得する取得手段と、
前記取得手段により取得された前記参照リスト情報に基づいて、取引対象の需要を予測する予測手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
請求項１に記載の情報処理装置において、
前記予測手段は、取引対象の複数の区分のうち少なくとも１つの区分が同じ区分に属する複数の取引対象間における需要の大小関係を予測することを特徴とする情報処理装置。
【請求項３】
請求項１または請求項２に記載の情報処理装置において、
前記予測手段は、前記取得手段により取得された前記参照リスト情報と、ユーザによる前記参照リストからの取引対象の削除履歴を記憶する削除履歴記憶手段に記憶された前記削除履歴とに基づいて、該取引対象の需要を予測することを特徴とする情報処理装置。
【請求項４】
請求項１乃至３の何れか１項に記載の情報処理装置において、
取引対象の複数の区分のうち需要の予測対象の取引対象が属する区分が１人のユーザから同時期に複数購入される取引対象の区分であるか否かを判定する判定手段と、
前記予測対象の取引対象が属する区分の取引対象の前記参照リストの登録数をユーザごとに取得する登録数取得手段と、
を更に備え、
前記特定手段は、前記予測対象の取引対象を前記参照リストに登録している各ユーザの該取引対象に対する需要の和を計算して該和に応じた需要を予測し、前記判定手段により複数購入される取引対象の区分であると判定された場合、予め設定された設定需要を各ユーザの需要に設定し、前記判定手段により複数購入される取引対象の区分ではないと判定された場合、前記登録数取得手段によりユーザごとに取得された前記登録数に基づいて各ユーザの需要の設定を行うことを特徴とする情報処理装置。
【請求項５】
請求項４に記載の情報処理装置において、
ユーザにより購入された取引対象の区分を示す情報と、購入したユーザを示す情報と、購入時期とを対応付けて購入履歴として記憶する購入履歴記憶手段に記憶された前記購入履歴に基づいて、前記予測対象の取引対象が属する区分の取引対象の同時期における購入数をユーザごとに取得する購入数取得手段と、
前記購入数取得手段により取得された前記購入数が前記登録数取得手段により取得された前記登録数以上であるか否かをユーザごとに判定する数判定手段と、
を更に備え、
前記判定手段により複数購入される取引対象の区分であると判定された場合、前記特定手段は、前記数判定手段により前記購入数が前記登録数以上であると判定されたユーザの需要に前記設定需要を設定し、前記数判定手段により前記購入数が前記登録数以上ではないと判定されたユーザの需要に、前記購入数と前記登録数とに基づいて、前記設定需要未満となる需要を設定することを特徴とする情報処理装置。
【請求項６】
請求項１乃至５の何れか１項に記載の情報処理装置において、
需要の予測対象の取引対象を販売する複数の販売者のうち需要の予測を要求した販売者による該取引対象の市場占有率を取得する占有率取得手段を更に備え、
前記予測手段は、前記取得手段により取得された前記参照リスト情報と、前記占有率取得手段により取得された前記市場占有率とに基づいて、需要の予測を要求した販売者の需要を予測することを特徴とする情報処理装置。
【請求項７】
コンピュータにより実行される情報処理方法であって、
取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の前記参照リスト情報を取得する取得ステップと、
前記取得ステップにおいてり取得された前記参照リスト情報に基づいて、取引対象の需要を予測する予測ステップと、
を含むことを特徴とする情報処理方法。
【請求項８】
情報処理装置に含まれるコンピュータを、
取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の前記参照リスト情報を取得する取得手段、及び、
前記取得手段により取得された前記参照リスト情報に基づいて、取引対象の需要を予測する予測手段、
として機能させることを特徴とする情報処理プログラム。
【請求項９】
情報処理装置に含まれるコンピュータを、
取引対象に関する情報への参照を保持する参照リストにユーザにより登録された取引対象を示す参照リスト情報をユーザごとに記憶する記憶手段から複数の前記参照リスト情報を取得する取得手段、及び、
前記取得手段により取得された前記参照リスト情報に基づいて、取引対象の需要を予測する予測手段、
として機能させる情報処理プログラムがコンピュータ読み取り可能に記憶されていることを特徴とする記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１３−７７１０９（Ｐ２０１３−７７１０９Ａ）
【公開日】平成２５年４月２５日（２０１３．４．２５）
【国際特許分類】
【出願番号】特願２０１１−２１５９７５（Ｐ２０１１−２１５９７５）
【出願日】平成２３年９月３０日（２０１１．９．３０）
【出願人】（３９９０３７４０５）楽天株式会社 (416)
【公開日】平成２５年４月２５日（２０１３．４．２５）
【国際特許分類】
【出願日】平成２３年９月３０日（２０１１．９．３０）
【出願人】（３９９０３７４０５）楽天株式会社 (416)
[ Back to top ]