JPWO2015151199A1 - 需要予測システム、需要予測方法およびプログラム - Google Patents

Abstract

需要者の商品やサービスを入手するための事前活動に基づき、より精度の高い需要予測を行うこと。需要予測システムは、商品又はサービスに関する条件をそれぞれ含む、複数のユーザリクエストを受け付け、前記各ユーザリクエストに応じて、前記条件を満足する１以上の商品又はサービスに関する情報を返信し、需要予測の対象である商品又はサービスについて、該商品又はサービスが満足している条件を含む受付済みのユーザリクエストに基づいて需要予測値を算出する。

Description

本発明は需要予測システム、需要予測方法およびプログラムに関する。

過去の需要実績に基づいて、電力や商品などの将来の需要を予測する需要予測システムが知られている。また天候や気温などの将来の環境を予測するとともに、過去の同じ環境における需要実績に照らして、将来の需要を予測する需要予測システムも知られている。

現在ではインターネットなどの情報通信ネットワークが発達しており、商品やサービスの入手前に、需要者は情報通信ネットワーク上でそれら商品やサービスに関する情報を取得することが多い。

特許文献１には、キーワードに応じて商品等を検索する電子商店街サーバが記載されている。この電子商店街サーバは、商品検索などに用いられるキーワードの流行を判定する。

特開２０１３−２５０６７７号公報

本発明の目的は、需要者の商品やサービスを入手するための事前活動に基づき、より精度の高い需要予測を行うことができる需要予測システム、需要予測方法およびプログラムを提供することにある。

上記課題を解決するために、本発明にかかる需要予測システムは、商品又はサービスに関する条件をそれぞれ含む、複数のユーザリクエストを受け付けるリクエスト受付手段と、前記各ユーザリクエストに応じて、前記条件を満足する１以上の商品又はサービスに関する情報を返信する情報返信手段と、需要予測の対象である商品又はサービスについて、該商品又はサービスが満足している条件を含む受付済みのユーザリクエストに基づいて需要予測値を算出する需要予測値算出手段と、を含むことを特徴とする。

また本発明にかかる需要予測方法は、商品又はサービスに関する条件をそれぞれ含む、複数のユーザリクエストを受け付けるステップと、前記各ユーザリクエストに応じて、前記条件を満足する１以上の商品又はサービスに関する情報を返信するステップと、需要予測の対象である商品又はサービスについて、該商品又はサービスが満足している条件を含む受付済みのユーザリクエストに基づいて需要予測値を算出するステップと、を含むことを特徴とする。

また本発明にかかるプログラムは、商品又はサービスに関する条件をそれぞれ含む、複数のユーザリクエストを受け付け、前記各ユーザリクエストに応じて、前記条件を満足する１以上の商品又はサービスに関する情報を返信し、需要予測の対象である商品又はサービスについて、該商品又はサービスが満足している条件を含む受付済みのユーザリクエストに基づいて需要予測値を算出する、処理をコンピュータに実行させる。

本発明によれば、需要者の商品やサービスを入手するための事前活動に基づいて、より精度の高い需要予測を行うことができる。

本発明の一態様では、前記商品又はサービスに関する条件は、複数の前記商品又はサービスの属性として設定される情報に関する条件を含んでもよい。

本発明の一態様では、前記需要予測値算出手段は、前記需要予測の対象である商品又はサービスの属性として設定される情報に基づいて、該商品又はサービスが満足している条件を含む受付済みのユーザリクエストを抽出する手段を含んでもよい。

本発明の一態様では、前記需要予測値算出手段は、前記条件を含むユーザリクエストのそれぞれに応じた値を加算して積算変数を更新し、更新された積算変数に基づいて前記需要予測値を算出してもよい。

本発明の一態様では、前記需要予測値算出手段は、需要予測の対象である前記商品またはサービスが満足する条件を含む受付済みのユーザリクエストの数と当該ユーザリクエストに含まれる条件を満たす商品またはサービスの数とに基づいて需要予測値を算出してもよい。

本発明の一態様では、前記需要予測値算出手段は、前記ユーザリクエストを送信するユーザが送信したユーザリクエストの数にさらに基づいて需要予測値を算出してもよい。

本発明の一態様では、前記需要予測値算出手段は、前記ユーザリクエストを送信したユーザの位置にさらに基づいて需要予測値を算出してもよい。

本発明の一態様では、前記需要予測値算出手段は、所定の条件を充足する時刻になされた前記受付済のユーザリクエストに基づいて前記需要予測値を算出し、前記所定の条件は、前記需要予測の対象である商品又はサービスを得る位置と、前記ユーザリクエストを送信したユーザの位置と、に基づくものであってよい。

本発明の一態様では、前記商品又はサービスは飲食サービスであり、前記情報返信手段は、飲食サービスに関する情報を返信してもよい。

本発明の一態様では、前記需要予測値算出手段は、需要予測の対象である商品又はサービスについて、該商品又はサービスが満足している条件を含む受付済みのユーザリクエストに基づいて、該商品又はサービスである飲食サービスを利用する人数を予測してもよい。

本発明の一態様では、需要予測システムは、現時点で前記飲食サービスを利用する顧客が将来注文する追加金額を推定する追加利用額推定手段と、前記飲食サービスが利用される際の予想金額と、前記推定された追加金額とに基づいて、現時点で前記飲食サービスを利用する顧客に退店を促す情報を出力するか否かを決定する退店判定手段と、をさらに含んでもよい。

本発明の一態様では、前記需要予測値算出手段は、前記ユーザリクエストを送信したユーザの当日の所定時間以内の飲食サービスの利用金額の実績に基づいて、前記飲食サービスが利用される際の予想金額を算出してもよい。

本発明の一態様では、需要予測システムは、前記退店判定手段が現時点で前記飲食サービスを利用する顧客に向けて退店を促す情報を出力すると決定した場合に、前記顧客に対して所定の条件を満たして退店すると特典が与えられるクーポンに関する情報を出力するクーポン出力手段をさらに含んでもよい。

本発明の実施形態にかかる需要予測システムの構成の一例を示す図である。 検索サーバ、需要予測サーバ、店舗サーバのハードウェア構成の一例を示す図である。 需要予測システムが実現する機能を示すブロック図である。 需要予測システムの動作の概要を示すシーケンス図である。 検索条件入力画面の一例を示す図である。 リスト画面の一例を示す図である。 検索サーバの処理フローの一例を示す図である。 商品サービス情報格納部に格納される店舗情報の一例を示す図である。 ログ格納部に格納される検索ログの一例を示す図である。 検索サーバの処理フローの一例を示す図である。 ログ格納部に格納される詳細表示ログの一例を示す図である。 需要予測サーバの処理フローの一例を示す図である。 需要予測サーバの処理フローの一例を示す図である。 店舗サーバの処理フローの一例を示す図である。 出力されるクーポンの一例を示す図である。 要求取得部、情報返信部、需要予測算出部の処理の他の一例を示す図である。 需要予測値の格納の方式を説明する図である。

以下では、本発明の実施形態について図面に基づいて説明する。同じ符号を付された構成については、重複する説明を省略する。以下では特に断りのない部分では様々な店舗が提供する飲食サービスを紹介するグルメ情報システムの例に焦点をあてて説明する。

図１は、本発明の実施形態にかかる需要予測システムの構成の一例を示す図である。この需要予測システムは、検索サーバ１と、需要予測サーバ２と、ユーザ端末３と、店舗サーバ４と、注文端末５とを含む。これらは、ネットワーク６を介して接続されている。ネットワーク６は、例えばローカルエリアネットワークやインターネットといったものである。

検索サーバ１および需要予測サーバ２は、サーバコンピュータであり、データセンタなどに設置されている。検索サーバ１は、ユーザ端末３からの検索要求に応じてデータベース等から情報を検索し、検索された情報をユーザ端末３に向けて返信するとともにその検索に関するログをデータベースなどに格納させる。需要予測サーバ２は、そのログに基づいて、飲食サービスに関する需要を予測する。ユーザ端末３は、例えばスマートフォンなどの携帯情報端末やパーソナルコンピュータのようなコンピュータである。検索サーバ１はウェブサーバプログラム（ｈｔｔｐｄなど）を実行しており、検索サーバ１とユーザ端末３との間はｈｔｔｐプロトコルになどにより通信する。ブラウザプログラムを実行するユーザ端末３はユーザが入力した要求を検索サーバ１に送信し、ユーザ端末３は検索サーバ１から送信された情報に応じた画面を表示手段に出力させる。

店舗サーバ４はサーバコンピュータであり、飲食サービスを提供する店舗に設置されている。注文端末５は、店舗の客席に配置される、または従業員に携帯される携帯情報端末である。店舗サーバ４は、無線ネットワークなどを介して注文端末５と接続されており、注文端末５から料理やドリンクなどの注文情報を取得し、調理担当者などに料理やドリンクの提供を指示する。また店舗サーバ４は発注された料理などの情報を記憶し、精算金額の算定やレジと連携した顧客の支払管理なども行う。

図２は検索サーバ１、需要予測サーバ２、店舗サーバ４のハードウェア構成の一例を示す図である。検索サーバ１、需要予測サーバ２、店舗サーバ４のそれぞれは、プロセッサ１１、記憶部１２、通信部１３、入出力部１４を含む。

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

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

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

入出力部１４は、表示出力手段をコントロールするビデオコントローラや、入力デバイスからのデータを取得するコントローラなどにより構成される。入力デバイスとしては、キーボード、マウス、タッチパネルなどがある。入出力部１４は、プロセッサ１１の制御に基づいて、表示出力デバイスに表示データを出力し、入力デバイスをユーザが操作することにより入力されるデータを取得する。表示出力デバイスは例えば外部に接続されるディスプレイ装置である。なお、ユーザ端末３や注文端末５も検索サーバ１等と同様にプロセッサ１１、記憶部１２、通信部１３、入出力部１４を含む。ユーザ端末３や注文端末５に含まれる入出力部は例えば携帯情報端末に内蔵されるディスプレイに表示データを出力する。

図３は、需要予測システムが実現する機能を示すブロック図である。需要予測システムは、機能的に、要求取得部５１と、情報返信部５２と、需要予測算出部５３と、需要予測送信部５４と、需要予測受信部５５と、追加利用額推定部５６と、クーポン発行判定部５７と、クーポン出力部５８と、商品サービス情報格納部６１と、ログ格納部６２と、注文履歴格納部６３と、を含む。

要求取得部５１と、情報返信部５２とは、検索サーバ１に含まれるプロセッサ１１が、記憶部１２に格納されたプログラムを実行し通信部１３等を制御することにより実現される。需要予測算出部５３と需要予測送信部５４とは、需要予測サーバ２に含まれるプロセッサ１１が、記憶部１２に格納されたプログラムを実行し通信部１３等を制御することにより実現される。また、商品サービス情報格納部６１は、検索サーバ１が提示する商品やサービス（グルメ情報システムでは特に飲食サービス）に関する情報を格納するデータベースであり、ログ格納部６２は、ユーザからの検索要求に関する情報を格納する。商品サービス情報格納部６１およびログ格納部６２は検索サーバ１の記憶部１２を中心として実現されるが、検索サーバ１から独立しかつデータベースプログラムが実行される他のサーバコンピュータにより実現されてもよい。また需要予測算出部５３と需要予測送信部５４とが検索サーバ１に含まれるプロセッサ１１等により実現されてもよい。

需要予測受信部５５、追加利用額推定部５６、クーポン発行判定部５７、クーポン出力部５８は、店舗サーバ４に含まれるプロセッサ１１が、記憶部１２に格納されたプログラムを実行し通信部１３等を制御することにより実現される。また、注文履歴格納部６３は、注文端末５から送信される店舗顧客の注文の履歴情報を格納するデータベースである。注文履歴格納部６３は店舗サーバ４の記憶部１２を中心として実現されるが、店舗サーバ４から独立しかつデータベースプログラムが実行される他のサーバコンピュータにより実現されてもよい。

図４は、需要予測システムの動作の概要の一例を示すシーケンス図である。図４の例では、需要予測システムは、ユーザ端末３を操作するユーザからの検索要求データやサービスや商品の詳細を表示させる項目表示要求データなどのユーザリクエストに基づいてユーザ端末３にデータを返信する際にそのユーザリクエストに関するログデータを格納し、その格納されたログデータを用いて商品やサービスの需要を予測し、その予測データを用いて店舗側で処理を行う。なお後述するが、本実施形態において、店舗サーバ４は需要予測値と店舗内の空き席に応じて店内の顧客の退店を促すか否か判定する処理を行う。

図４について、機能ブロックと、やりとりされるデータと関連づけてより詳細に説明する。

要求取得部５１は、検索サーバ１のプロセッサ１１、記憶部１２および通信部１３を中心として実現される。要求取得部５１はユーザ端末３に向けて検索条件入力画面データを送信する。また要求取得部５１はユーザ端末３から送信される商品又はサービスに関する条件をそれぞれ含む複数のユーザリクエストを受け付ける。

要求取得部５１が送信する検索条件入力画面データは、商品やサービスを検索するための検索条件を入力させる画面の情報である。これにより、ユーザ端末３は検索条件入力画面をユーザが閲覧する表示出力デバイスに表示させ、ユーザが商品又はサービスに関する検索条件を入力することを可能にする。

図５は、検索条件入力画面の一例を示す図である。図５に示す画面は、特定のＵＲＬを入力することによりユーザ端末３側の画面に表示されるグルメ情報サイトのトップページであり、検索用のキーワードを入力する欄、検索したい店舗が存在する地域を入力する欄、および飲食サービスのジャンルを選択する欄を含む検索条件入力領域７０を有している。ユーザが検索条件入力領域７０にキーワード、地域、ジャンルといった検索条件を入力し「検索」ボタンを押下すると、ユーザ端末３はそれらの検索条件を含む検索要求データを検索サーバ１に向けて送信する。そして、要求取得部５１は検索条件を含む検索要求データを受信する。

情報返信部５２は、検索サーバ１のプロセッサ１１、記憶部１２および通信部１３を中心として実現される。情報返信部５２は、受け付けたユーザリクエストに応じて、ユーザリクエストに含まれる条件を満たす１以上の商品又はサービスに関する情報（リスト画面データや項目詳細画面データ）を返信する。

要求取得部５１が検索条件を含む検索要求データを受信すると、情報返信部５２はその検索条件を含む検索クエリを用いて商品サービス情報格納部６１に含まれる商品やサービスの情報を検索し、その検索条件を満たす商品やサービスを項目とするリストであるリストデータを取得する。そして、情報返信部５２はそのリストデータに基づいてリスト画面データを生成し、生成されたリスト画面データを検索要求を送信したユーザ端末３に送信する。ユーザ端末３はリスト画面データを受信し、リスト画面を表示出力デバイスに表示させる。また情報返信部５２はこの検索条件を含む検索ログのデータをログ格納部６２に格納する。

図６は、リスト画面の一例を示す図である。本図に示すリストは、検索条件として、エリアが「銀座」、ジャンルが「和食」で検索された場合に表示される店舗（飲食サービス）のリストである。以下では、このリストに含まれる飲食サービスの一つ一つをリストの「項目」と記載する。なお、ここでは店舗が検索され表示されているが、この店舗は飲食サービスを提供するものであり、言い換えれば店舗は飲食サービスを示すものである。実際には飲食サービスの選択は店舗の選択によって行われているからである。

図６の画面には、項目７１から７３の情報が表示されているが、実際にはより多くの項目の情報が表示されている。リスト画面では、各項目について、商品やサービスの概要を示す情報、例えば飲食サービス施設の店名や写真、サービスを受ける際の予算の目安、その施設へのアクセス方法といった情報が配置されている。ユーザがリンクのクリックなどにより、これらの項目のうちいずれかを選択すると、ユーザ端末３は、その選択された項目を特定する情報（ＩＤ）を含む詳細表示要求データを検索サーバ１に送信する。

要求取得部５１はユーザ端末３から送信された詳細表示要求データを受信する。そして、情報返信部５２はその詳細表示要求データに含まれるＩＤを含むクエリを用いて商品サービス情報格納部６１から前記ＩＤにより特定される商品やサービスの詳細な情報（項目詳細データ）を取得し、その情報をユーザに提示するための項目詳細画面を表示するための項目詳細画面データを生成し、ユーザ端末３に生成された項目詳細画面データを送信する。ユーザ端末３は項目詳細画面データを受信し、項目詳細画面を表示出力デバイスに表示させる。また情報返信部５２はこのＩＤを含む詳細表示ログのデータをログ格納部６２に格納する。

この詳細表示要求データ（閲覧要求データ）は、商品やサービスを特定する条件を含む。例えば、詳細表示要求データは、商品又はサービスの詳細を表示させる画面のＵＲＬであってもよい。このＵＲＬも商品やサービスを特定する情報を含むので、商品やサービスに関する条件の一種である。要求取得部５１がこのＵＲＬのｈｔｔｐ要求を受信した場合、情報返信部５２はそのＵＲＬにより特定される条件に基づいて商品又はサービスの項目詳細データを取得し、項目詳細画面データをユーザ端末３に送信するとともに詳細表示ログをログ格納部６２に格納してよい。

また、詳細表示要求データは、商品やサービスを特定するＩＤを指定する検索条件を含んでもよい。これは検索要求データと同じく商品又はサービスの検索条件を含むユーザリクエストであるといえる。また、図４の例では、ユーザリクエストとして検索要求データと詳細表示要求データとを示しているが、他の種類のユーザリクエストがあってもよい。

他にも、上述のユーザリクエストが、季節限定の商品紹介ページへのボタンを押下した場合に検索サーバ１に向けて送信されるｈｔｔｐ要求であってもよい。これは例えば、グルメ情報サイトのトップページに季節限定としてクリスマス限定のセールのページへ遷移するボタンを設け、そのボタンが押下されて送信されるｈｔｔｐ要求により、情報返信部５２がクリスマス限定のセールをする店舗の一覧を表示させるような場合である。この場合、情報返信部５２は例えば検索条件として商品サービス情報格納部６１に格納されている店舗のうち、「クリスマスセール属性」を有する条件を満たすもの、または、キーワードに「クリスマスセール」を含む条件を満たすものを抽出し、その抽出された店舗のリストの画面の情報をユーザ端末３に送信する。

需要予測算出部５３は、需要予測サーバ２のプロセッサ１１、記憶部１２、通信部１３を中心として実現される。需要予測算出部５３は、需要予測の対象である商品又はサービスについて、その商品又はサービスが満足している条件を含む受付済みのユーザリクエストに基づいて需要予測値を算出する需要予測算出処理を実行する。

より具体的には、需要予測算出部５３はログ格納部６２に格納される検索ログや詳細表示ログを取得し、その取得されたデータに基づいて、商品やサービスを購入する人数の予測値（人数予測値）や、その人が購入の際に支払う金額の予測値（金額予測値）を算出する。なお、需要予測値の算出には必ずしもログ格納部６２に格納されるデータを用いなくてもよい。この詳細については後述する。

需要予測送信部５４は、需要予測サーバ２のプロセッサ１１、記憶部１２、通信部１３を中心として実現される。需要予測送信部５４は、需要予測データを送信する。

次に、検索サーバ１が実行する処理についてさらに説明する。図７は、検索サーバ１の処理フローの一例を示す図である。この処理フローは、要求取得部５１が検索条件を含む検索要求データを受信するたびに実行され、検索要求データのそれぞれに対して実行される。以下では、本需要予測システムが取り扱う商品やサービスは、具体的には飲食サービスであり、またその飲食サービスの種類として店舗そのものを用いている場合の処理の詳細について説明する。以下の記載で特に断りのない場合、飲食サービスを示す「店舗」を、他の商品やサービスに置き換えた処理が実行されてもよい。

要求取得部５１が検索要求データを取得すると、はじめに、情報返信部５２は検索要求データに含まれる店舗の検索条件を取得する（ステップＳ１０１）。次に、情報返信部５２はその検索条件を用いて商品サービス情報格納部６１を検索し、検索条件を満たす店舗情報のリスト（リストデータ）を取得する（ステップＳ１０２）。

図８は、商品サービス情報格納部６１に格納される店舗情報の一例を示す図である。店舗情報は、店舗（飲食サービス）を一意に特定するサービスＩＤと、名称と、店舗（飲食サービス）のジャンルと、店舗が存在するエリアと、検索条件中の検索キーワードによる検索対象となるキーワードと、それぞれ時間帯ごとの平均的な予算の額を示す予算昼、予算夕および予算夜と、いった属性の情報を含む。また図８に示される属性は一部であり、店舗情報は他の属性も含んでいてよい。エリアはユーザが検索しやすいように、都道府県とさらに細分化された街との２種類の情報を含んでいる。ここで、店舗情報は飲食サービスの情報でもある。ジャンル、エリア、予算、キーワードといった情報はそれだけで商品やサービス（ここでは店舗）を一意に特定することができない属性の情報であり、また複数の商品やサービスについて同じ情報が設定されうる属性である。図８には、５つの店舗（飲食サービス）についての店舗情報しか記載されていないが、実際にはより多くの店舗情報が商品サービス情報格納部６１に格納されている。

情報返信部５２が店舗情報のリストを取得すると、情報返信部５２は各店舗の人気などに応じてリスト中の店舗情報の表示順を決定し（ステップＳ１０３）、表示順にソートされた店舗情報のリスト（以下ではリストに含まれる店舗情報を「項目」とも記載する）を含むリスト画面のリスト画面データを生成し、そのリスト画面データをユーザ端末３に向けて送信する（ステップＳ１０４）。ここで、情報返信部５２は検索条件を満たすすべての店舗の情報をリスト画面データで送らず、例えば表示順があらかじめ与えられた閾値以下である（例えば１０位）までの店舗の情報を含むリストを送信する。

そして、情報返信部５２は検索条件を示す情報やリストデータに含まれる店舗情報の件数（ヒット件数）などを含む検索ログをログ格納部６２に格納する（ステップＳ１０５）。図９は、ログ格納部６２に格納される検索ログの一例を示す図である。検索ログは、検索ＩＤと、検索時刻と、ユーザＩＤと、検索条件として与えられたエリア、ジャンルおよびキーワードと、ヒット件数と、表示項目リストと、ユーザ位置などの属性を含む。検索ＩＤは検索ログの対象となる検索要求などを一意に識別するものであり、検索時刻は要求取得部５１が検索要求を受信して情報返信部５２がリスト画面データを返信する処理を行った時刻であり、ユーザＩＤは検索要求データを送信したユーザを特定するＩＤであり、ヒット件数は検索要求に含まれる検索条件を満たした件数であり、商品サービス情報格納部６１からみつかった項目の件数である。表示項目リストはリスト画面データとしてユーザ端末３に情報が送られた項目のリストであり、ユーザ位置は検索要求データに含まれる情報でありユーザが検索する際にどの町に居たかなどを示す位置の情報である。

図１０は、検索サーバ１の処理フローの一例を示す図である。この処理フローは、要求取得部５１が詳細表示要求データ（閲覧要求データ）を受信するたびに実行され、詳細表示要求データのそれぞれに対して実行される。

要求取得部５１が詳細表示要求データを取得すると、はじめに、情報返信部５２は詳細表示要求データからサービスＩＤ（店舗を特定するＩＤ）を取得する（ステップＳ１２１）。詳細表示要求データがＧＥＴやＰＯＳＴを含まないＵＲＬである場合には、情報返信部５２はそのＵＲＬを解析してサービスＩＤを取得する。また詳細表示要求データが明示的にサービスＩＤを含む場合には、そのサービスＩＤを取得する。次に、情報返信部５２はそのサービスＩＤを検索条件として商品サービス情報格納部６１を検索し、その店舗情報を取得する（ステップＳ１２２）。そして、その取得された店舗情報を表示させる項目詳細画面のデータである項目詳細画面データを生成し、詳細表示要求データを送信したユーザ端末３に向けてその項目詳細画面データを送信する（ステップＳ１２３）。これにより、そのユーザ端末３は項目詳細画面を表示出力デバイスに表示させる。

また、情報返信部５２はその表示された店舗情報を特定する情報やこれらの処理を行った時刻などを含む詳細表示ログをログ格納部６２に格納する（ステップＳ１２４）。図１１は、ログ格納部６２に格納される詳細表示ログの一例を示す図である。詳細表示ログは、ログを識別するための表示ＩＤと、項目詳細画面データを送信した送信時刻と、ユーザＩＤ、店舗を特定するサービスＩＤ、ユーザ位置などの情報を含む。

ここで、項目詳細画面データは、店舗情報に基づいて予め生成され、ＵＲＬと紐付けられて記憶部１２に格納されていてもよい。この場合、情報返信部５２は、詳細表示要求データのＵＲＬを取得すると、そのＵＲＬが特定する店舗情報を有する項目詳細画面データを取得し、詳細表示要求データを送信したユーザ端末３に向けてその項目詳細画面データを送信する。また情報返信部５２はサービスＩＤ等の店舗を特定する情報などを含む詳細表示ログをログ格納部６２に格納する。

次に、店舗（飲食サービス）について需要予測値を算出する方法の詳細について説明する。図１２および図１３は、需要予測サーバ２の処理フローの一例を示す図である。

図１２や図１３に示す処理フローは、需要予測サーバ２がログ格納部６２に格納された情報を用いて需要を予測するための処理の例を示すものであり、この例では需要を予測する対象となる店舗ごとに一定時間ごと（例えば１５分ごと）に処理が実行される。なお、以下では予測対象となる店舗を「対象店舗」とも記載する。またこの例では、需要予測算出部５３は店舗に来店すると予測される人数である人数予測値と、その来店する人のそれぞれが支払うと予測される金額である金額予測値とを予測する。

はじめに、需要予測算出部５３は、商品サービス情報格納部６１から、対象店舗の店舗情報に含まれるエリア、ジャンル、キーワードなどの属性の情報を取得する（ステップＳ２０１）。これらの属性は、検索要求データに含まれる検索条件による検索対象となりうる属性である。例えば図８に示すサービスＩＤが「ｒ０００１」の店舗が需要予測の対象である場合、需要予測算出部５３はジャンル「和食」、エリア「東京都＞銀座」、キーワード「薬膳」、「座敷」、「居酒屋」といった情報を取得する。また需要予測算出部５３は、別途予算昼、予算夕、予算夜の属性の情報も取得する。

次に、需要予測算出部５３は取得されたエリア、ジャンル、キーワードなどを組み合わせて１または複数のログ検索条件を生成する（ステップＳ２０２）。１または複数のログ検索条件の組は、対象店舗が検索されうる検索条件を網羅するものである。なお、この例では、検索条件によって検索される場合、その検索条件と完全一致となる店舗の情報が検索されることを前提としている。対象店舗についての複数のログ検索条件の例は、１番目のログ検索条件：ジャンル＝「和食」 ＡＮＤ エリア＝「東京都」、２番目のログ検索条件：ジャンル＝「和食」 ＡＮＤ エリア＝「東京都＞銀座」、３番目のログ検索条件：ジャンル＝「和食」 ＡＮＤ エリア＝「東京都」 ＡＮＤ キーワード＝「薬膳」、４番目のログ検索条件：ジャンル＝「和食」 ＡＮＤ エリア＝「東京都」 ＡＮＤ キーワード＝「薬膳」 ＡＮＤ キーワード＝「座敷」・・・といったものである。仮にこれらのログ検索条件のいずれで店舗情報が検索されても、対象店舗は検索結果のリスト中に存在することになる。なお、実際に検索をする際には、例示したログ検索条件の内容に加えて、検索時刻が現在から一定の範囲（例えば６０分前から現在まで）にあるという条件も検索条件に付加される。

次に需要予測算出部５３は変数ｉに１を代入して初期化する（ステップＳ２０３）。変数ｉはログ検索条件の番号に相当する。需要予測算出部５３はｉ番目のログ検索条件を用いて、ログ格納部６２に格納される検索ログのリストを抽出する（ステップＳ２０４）。なお、この検索をすべてのログ検索条件について行うことで、需要予測算出部５３はこの対象店舗が満足している条件を含む受付済みのユーザリクエストを抽出する。

次に、需要予測算出部５３は変数ｊに１を代入して初期化する（ステップＳ２０５）。変数ｊは検索ログのリスト内の順位に相当する。そして需要予測算出部５３はｊ番目の検索ログを取得し（ステップＳ２０６）、その検索ログによる需要予測値への寄与を算出する。より具体的には、まず需要予測算出部５３はｊ番目の検索ログに含まれる表示項目リストの中に対象店舗が含まれるか否か確認する（ステップＳ２０７）。この結果は後述する人数増期待値の計算で用いられる。次に需要予測算出部５３はｊ番目の検索ログに含まれるユーザＩＤを検索条件として検索ログを検索し、その検索条件を満たす検索ログの件数を取得する（ステップＳ２０８）。

需要予測算出部５３は検索ログに応じた人数増期待値ｍを算出し、その人数増期待値ｍを人数予測値に加算する（ステップＳ２０９）。人数増期待値ｍは、例えば以下の計算式を用いて計算される。

ｃはヒット件数、ｕは同一ユーザの検索ログの件数、ｐ１ｘはユーザの位置の経度、ｐ１ｙはユーザの位置の緯度、ｐ２ｘは店舗の位置の経度、ｐ２ｙは店舗の位置の緯度である。関数ｇはユーザの位置と店舗の位置とが近くなるほど値が大きくなる関数であり、最大値は１以下となる関数である。ａはステップＳ２０７でリスト画面データにどの店舗の情報を含むかを示す表示項目リスト中に対象店舗が含まれているか否かに応じた値をとり、対象店舗が含まれていない場合の値は含まれている場合の値より小さい。なお、ここでいう人数予測値は計算途中の値を格納する積算変数であり、全ての検索ログや詳細表示ログについての処理が終わると、需要予測算出部５３により算出された本物の人数予測値となる。

人数予測値は、対象店舗が満たす検索条件を有するユーザリクエストの数が多いほど大きくなり、またそれぞれのユーザリクエストに含まれる検索条件を満たす店舗の数が多いほど小さくなる。また人数予測値は、それぞれのユーザリクエストを送信するユーザが送信する他のユーザリクエストの数が多いほど小さくなり、それぞれのユーザリクエストに含まれるユーザの位置が対象店舗の位置に近いほど大きくなる。こうすることで、あるユーザが複数の対象店舗を検索をすることによって当該検索の対象となった複数の対象店舗の予測値が不必要に上昇する現象を抑え、またリストに表示されたか、ライバルとなる他の商品やサービスが多いかなどの事情も考慮された予測値を算出することが可能となる。

人数予測値が加算されると、需要予測算出部５３は検索ログに含まれるユーザが対象店舗を利用する場合の利用金額を予測する（ステップＳ２１０）。金額を予測する際には、需要予測算出部５３は需要予測サーバ２に接続される図示しない決済システムから検索ログに含まれるユーザＩＤのユーザの飲食サービスに対する過去の支払履歴として店舗のサービスＩＤと支払額と支払時刻とを取得し、そのサービスＩＤで特定される店舗情報におけるその支払時刻に応じた予算と支払額との比を計算する。また支払履歴が複数ある場合には需要予測算出部５３はそれぞれについて計算した比の平均をとる。需要予測算出部５３は、このようにして計算された比の値を対象店舗の店舗情報における現在時刻に応じた予算の値にかけ、利用金額の仮の予測値を計算する。

そして需要予測算出部５３は、ユーザの当日の支払金額に応じて利用金額の予測値を修正する。より具体的には、需要予測算出部５３は決済システムからそのユーザの当日の所定時間内の支払履歴を取得し、その支払額が、対象店舗の店舗情報に含まれる現在時刻に応じた予算の額に予め定められた量を加えた値を超えていれば、その超えた額に一定の係数（１未満）をかけた金額を仮の予測値から減額し、修正された利用金額の予測値とする。この所定時間は、人が満腹になってから空腹にならない程度の時間であり、具体的には現在時刻から２時間から３時間前までの期間とするのが好適である。

また、決済システムからユーザの支払履歴が取得できない場合には、対象店舗の店舗情報のうち現在時刻に応じた時間帯の予算の値を利用金額の予測値とする。なお、利用金額の予測値として、ユーザが入力した値を用いてもよい、例えば、検索要求に予算の金額が含まれ、それが検索ログに記録される場合には、その金額を利用金額の予測値としてもよい。

利用金額の予測値が算出されると、需要予測算出部５３は、その利用金額の予測値に人数増期待値をかけた値を金額積算変数に加算する（ステップＳ２１１）。金額積算変数は計算途中の値であり、この値は店舗において来店者が利用する利用金額の総額の期待値に相当する。それぞれのユーザの利用金額の予測値である金額予測値は、最終的な金額積算変数の値を最終的な人数予測値で割ることによって取得される。なお、金額積算変数だけでなく、算出された利用金額の予測値の最大値と最小値も取得してよい。

ステップＳ２１１の処理を終えると、需要予測算出部５３は全ての検索ログを取得したか判定する（ステップＳ２１２）。まだ残りの検索ログがある場合には（ステップＳ２１２のＮ）、需要予測算出部５３は変数ｊの値を１だけ増加させ（ステップＳ２１３）、ステップＳ２０６から処理を繰り返す。全ての検索ログについて処理がされた場合には（ステップＳ２１２のＮ）、需要予測算出部５３は全てのログ検索条件を用いて検索ログを検索する処理を行ったか判定する（ステップＳ２１４）。残りのログ検索条件がある場合には（ステップＳ２１４のＮ）、変数ｉの値を１だけ増加させ（ステップＳ２１５）ステップＳ２０４の処理から繰り返す。

次に、需要予測算出部５３は項目詳細画面が表示されたか否かを需要予測値に反映させる処理を行う。まず、需要予測算出部５３は対象店舗のサービスＩＤを検索条件とし、ログ格納部６２に格納された詳細表示ログからその検索条件を満たす詳細表示ログのリストを抽出する（ステップＳ２１６）。需要予測算出部５３は変数ｊに１を代入して初期化する（ステップＳ２１７）。変数ｊはここでは詳細表示ログのリスト内の順位に相当する。そして需要予測算出部５３はｊ番目の詳細表示ログを取得し（ステップＳ２１８）、詳細表示ログに応じた人数増期待値を人数予測値に加算する（ステップＳ２１９）。より具体的には、需要予測算出部５３は同じユーザの他の詳細表示ログの件数を取得し、１未満の固定値をその件数で割った値を人数増期待値とし、人数予測値に加算する。需要予測算出部５３はステップＳ２１０と同様の方法でユーザの利用金額の予測値を算出し（ステップＳ２２０）、その利用金額の予測値に人数増期待値をかけた値を金額積算変数に加算する（ステップＳ２２１）。

そして、全ての詳細表示ログについて取得および処理していない場合には（ステップＳ２２２のＮ）、需要予測算出部５３は変数ｊの値を１つ増加し（ステップＳ２２３）、ステップＳ２１８の処理から繰り返す。全ての詳細表示ログについて取得および処理をした場合には（ステップＳ２２２のＹ）、ユーザが利用する際の利用金額の予測値である金額予測値を、金額積算変数を人数予測値で割ることで算出する（ステップＳ２２４）。

ここで、ステップＳ２０９にてユーザの位置と対象店舗の位置との近さに応じて人数予測値の元となる人数増期待値ｍを求めているが、代わりに、需要予測算出部５３は、ログ検索条件といった他の条件を満たす検索要求（ここでは検索ログ）のうち、時刻条件を充足する時刻になされた検索要求を需要予測値の算出に用いてもよい。時刻条件は、需要予測の対象である商品又はサービスを得る位置と、検索要求を送信したユーザの位置とに応じて定まるものである。商品又はサービスを得る位置は、飲食サービスの場合にはそのサービスを提供する対象店舗の位置であり、サービスであればそのサービスを提供する場所であり、商品であればその商品を引き渡す場所である。

より具体的には、需要予測算出部５３は、ステップＳ２０４で取得される検索ログのリストに属する検索ログのそれぞれについて、ユーザ位置と対象店舗の位置との距離を算出し、その距離に応じて時刻条件を決定する。例えば、需要予測算出部５３は、その距離が０より大きく第１距離閾値（例えば２ｋｍ）以下の場合に時刻条件を検索時刻から現在時刻までの経過時間が３０分以下であると決定し、距離が第１距離閾値より大きく第２距離閾値（例えば５ｋｍ）以下の場合に時刻条件を経過時間が３０分超かつ１時間以下であると決定し、距離が第２距離閾値より大きく第３距離閾値（例えば１０ｋｍ）以下の場合には時刻条件を経過時間が１時間超かつ２時間以下であると決定してもよい。また需要予測算出部５３は距離が第３距離閾値より大きいものは需要予測値の算出の対象から除外してよい。そしてステップＳ２０４で抽出された検索ログのリストからさらにこの時刻条件を満たすものを抽出し、その抽出された検索ログを以降の計算で用いればよい。このような処理により、時間と距離の関係により来店する蓋然性の低いユーザによる検索の影響を抑えることができる。

また、この時刻条件を、検索要求だけでなく閲覧要求などの他のユーザリクエストにも適用してよい。例えば、需要予測算出部５３は、ユーザ位置に応じた時刻条件を満たす閲覧要求を用いて需要予測値を算出してよい。閲覧要求に適用する場合、需要予測算出部５３はステップＳ２１６で抽出された詳細表示ログのリストにおいて、ユーザ位置と対象店舗の位置との距離に基づいて時刻条件を決定し、その時刻条件を満たす詳細表示ログをリストから抽出する。需要予測算出部５３は以降の処理では抽出された詳細表示ログを用いて処理を進めればよい。

なお、検索ログや詳細表示ログを他の条件で抽出されたリストからさらに抽出する代わりに、距離の範囲とその範囲に対応する時刻条件とを含む検索条件を用いてログ格納部６２から直接的に検索ログや詳細表示ログを抽出してもよい。

図１２および１３に示す処理では、需要予測算出部５３は検索ログと詳細表示ログの両方を用いて人数予測値や金額予測値を算出しているが、需要予測算出部５３は検索ログと詳細表示ログのうち一方のみを用いて人数予測値や金額予測値を算出してもよい。需要予測算出部５３は、例えば検索ログのみを用いて人数予測値や金額予測値を算出する場合はステップＳ２１６からステップＳ２２３の処理を行わず、詳細表示ログのみを用いて人数予測値や金額予測値を算出する場合はステップＳ２０１からステップＳ２１５の処理を行わなければよい。

そして、需要予測送信部５４は、算出された人数予測値や金額予測値を対象店舗の店舗サーバ４に向けて送信する（ステップＳ２２５）。

ここで、上述の処理では対象店舗が検索条件を完全に満たす場合に検索ログを需要予測値に反映させているが、検索条件と一部のみが一致する検索ログを需要予測値に反映させてもよい。例えば、検索結果として一つの店しかでない場合、その店が満席であるために周囲の店に流れる可能性があるので、その店と同じジャンル（かつ同じエリア）の店について需要予測値を増加させてもよい。例えば、ログ検索条件に、ヒット件数が閾値以下でキーワードの一致を必要としない検索条件を生成し、その検索条件を満たす検索ログについて人数増期待値などを計算し、人数予測値を加算するようにすればこの処理が実現される。なお、この場合、人数増期待値を計算する際に１より小さい係数をさらにかけ、人数増期待値が他の場合に比べて小さくなるようにしてもよい。

また需要予測値は、人数や金額には限られない。例えば需要予測算出部５３は商品に対する需要予測値を算出する場合には、注文される数量の総量の予測値を需要予測値として算出してもよい。

次に、店舗サーバ４が需要予測値である人数予測値や金額予測値を用いて行う処理について説明する。図１４は、店舗サーバ４の処理フローの一例を示す図である。図１４に示す処理を行う際には、需要予測受信部５５が需要予測値を受信した際など、一定時間ごとに実行される。図１４に示す処理をする前に、注文履歴格納部６３に店内で飲食サービスを受けている顧客からの飲食物などの注文の履歴（注文タイミング、種類および金額）が格納されているものとする。

需要予測受信部５５は、店舗サーバ４のプロセッサ１１、記憶部１２および通信部１３を中心として実現される。需要予測受信部５５は、需要予測送信部５４から送信された人数予測値と金額予測値とを受信し、記憶部１２に格納させる（ステップＳ３０１）。

追加利用額推定部５６は、店舗サーバ４のプロセッサ１１および記憶部１２を中心として実現される。追加利用額推定部５６は現時点で店内で前記飲食サービスを利用する顧客が将来注文する追加利用額を推定する（ステップＳ３０２）。この追加利用額の推定は、例えば顧客の来店からの時間と平均的な追加利用額とを関連づけるテーブルが予め作成されている場合は、顧客の来店時間とそのテーブルとを用いて計算してもよい。また予め顧客の注文累計額と来店時刻、最終注文時刻とから追加利用額を計算するような関数を準備し、その関数を用いて追加利用額を計算してもよい。

クーポン発行判定部５７は、プロセッサ１１および記憶部１２を中心として実現される。クーポン発行判定部５７は、金額予測値と、推定された追加利用額とに基づいて、現時点で店内で飲食サービスを利用する顧客に退店を促す情報を出力するか否かを決定する。詳細な処理については以下に説明する。

クーポン発行判定部５７は、空き席数を取得する（ステップＳ３０３）。クーポン発行判定部５７は未精算の注文を有さない席の数を空き席数として取得してもよいし、店舗サーバ４が顧客のいる席を直接管理している場合にはその情報を用いて空き席数を取得してもよい。

次にクーポン発行判定部５７は空き席を超える新規顧客の来店があるか否かを判定する（ステップＳ３０４）。ここでは例えば、クーポン発行判定部５７は人数期待値が現在の空き席数を超えるか否かに基づいて判定する。空き席を超える新規顧客の来店がないと判定された場合には（ステップＳ３０４のＮ）、処理を終了する。また空き席を超える新規顧客の来店があると判定された場合には、退店を促すことが有利であるかを判定する（ステップＳ３０５）。ここでは例えば、クーポン発行判定部５７は例えば以下の３つの条件が全て満たされている場合に退店を促すことが有利であると判定する。１つめの条件は、推定された追加利用額の平均値が金額予想値より小さいことである。ここで追加利用額の平均値の代わりに、追加利用額の最低値などを用いてもよい。２つめの条件は、当日の売上が予め設定された閾値より低いことである。３つめの条件は、閉店時間までの残り時間が予め設定された閾値より大きいことである。３つめの条件は閉店間際に新規顧客が来ることが少ないことを考慮する条件である。クーポン発行判定部５７は１つめの条件と、２つめおよび３つめの条件のうち一方とを満たす場合に退店を促すことが有利であると判定してよい。また、クーポン発行判定部５７が判定するための条件や閾値を店舗側の担当者が予め設定してよい。退店を促すことが有利でないと判定された場合には（ステップＳ３０５のＮ）、処理を終了する。

退店を促すことが有利であると判定された場合には（ステップＳ３０５のＹ）、クーポン発行判定部５７はクーポンを発行するために、退店を促す対象となる顧客を決定する（ステップＳ３０６）。この処理では、クーポン発行判定部５７は人数予測値から空き席数を引いた数を切り捨てた値をｋとして、追加利用額が下からｋ番目までの顧客を退店を促す対象となる顧客としてもよいし、来店からの経過時間がある閾値（２時間）より長く追加利用額が金額予測値を超えない顧客の全てを退店を促す対象としてもよい。

クーポン出力部５８は、店舗サーバ４のプロセッサ１１、記憶部１２、通信部１３を中心として実現される。クーポン出力部５８はクーポン発行判定部５７が退店を促すことが有利であると判定したか否かに基づいて、顧客に向けて所定の利用条件を満たして退店すると特典が与えられるクーポンに関する情報を出力する。より具体的には、クーポン発行判定部５７が退店を促すことが有利であると判定した場合に、クーポン出力部５８は退店を促す対象となる顧客に向けて利用条件付きクーポンの情報を出力する（ステップＳ３０７）。利用条件付きクーポンの出力の方法としては、その顧客のメールアドレスに向けて利用条件付きクーポンの情報を含むメールを送信してもよいし、注文端末５が顧客のいる席に設置されている場合には、その注文端末５に利用条件付きクーポンの情報を送信し、注文端末５にその利用条件付きクーポンを表示させてもよいし、店舗内にプリンタがある場合には、そのプリンタに席の位置を示す情報とともにその利用条件付きクーポンを印刷させる情報を送信してもよい。また、店舗の従業員が持っている端末や店舗サーバ４が接続される表示出力デバイスに、どのテーブルにクーポンを配るかを店舗従業員に示す情報を表示させてもよい。この場合、その端末や店舗サーバ４を操作しその情報を閲覧した従業員が店舗にいる顧客にクーポンを渡す。

図１５は、出力されるクーポンの一例を示す図である。図１５は、クーポンを注文端末５に表示させる場合の例である。この例では、利用条件として利用する時間が当日の近い時間に制限されているクーポンの情報を顧客に提示することで、顧客に退店を促している。利用条件としては、他にも予め特典を与える人数ｂを決めておき、先着ｂ名様に制限されるという条件であってもよい。

なお、図１４の例では、退店を促すことが有利であるとの判定はクーポンを発行する判定であり、クーポン発行判定部５７が退店を促すことが有利であると判定した場合にクーポン出力部５８はそのまま顧客の退店を促すための処理を行っている。代わりに、クーポン出力部５８が顧客の退店を促す前に、クーポン発行判定部５７は店舗の責任者に退店を促すか確認してもよい。例えば、クーポン発行判定部５７は店舗サーバ４に接続される表示出力デバイスに人数予測値、空き席数、金額予測値、退店を促す対象となる席などの情報とともに退店を促してよいか店舗責任者に確認するメッセージを表示させ、退店を促して良いか確認し、店舗責任者が「ＯＫ」ボタンを押下するなど退店を促してよい旨の指示をした場合に限り、ステップＳ３０７の処理を行うようにしてもよい。また、クーポン発行判定部５７はステップＳ３０５で追加利用額が金額予想値より小さい条件以外の条件を全て満たす場合には店舗責任者に退店を促してよいか確認せず、追加利用額が金額予想値より小さい条件以外の条件に満たさないものがある場合には退店を促してよいか店舗責任者に確認してもよい。

また、クーポン発行判定部５７やクーポン出力部５８の処理を行わず、代わりに需要予測受信部５５は、受信した人数予測値や金額予測値などの需要予測値を店舗サーバ４に接続されるディスプレイなどに出力してもよい。なお、需要予測送信部５４が人数予測値や金額予測値を送信するタイミングは、需要予測値が算出されてすぐなど需要予測サーバ２側の処理をトリガとするタイミングとし、需要予測送信部５４がプッシュ型で需要予測値を送信してもよい。また需要予測送信部５４は、単に店舗サーバ４側からのｈｔｔｐ要求等に対する応答として、プル型で需要予測値を送信してもよい。この場合は、店舗サーバ４側は単なるブラウザであってもよい。

なお、これまでに説明した実施形態では、需要予測算出部５３は、検索ログ等に基づいて人数予測値や金額予測値を計算しているが、必ずしも検索ログ等を用いなくてもよい。

図１６は、要求取得部５１、情報返信部５２、需要予測算出部５３の処理の他の一例を示す図である。この処理は、検索要求データを受信するたびに実行されるものであり、図７に対応するものである。ステップＳ４０１からＳ４０５は、ステップＳ１０１からＳ１０５と同様の処理であるので説明を省略する。図１６の例では、検索ログを格納するだけでなく、ステップＳ４０６において需要予測算出部５３が検索された全ての店舗について項目の件数に応じた人数増期待値を人数予測値に加算し、人数予測値を更新する処理を行っている。人数増期待値の計算は、ステップＳ２０９の処理と同様に、数式１に基づいて計算してよい。また数式１のａの値はリスト画面データに出力された店舗か否かに基づいて変わってよい。

図１７は、需要予測値の格納の方式を説明する図である。店舗と時間帯の組み合わせごとに１つの需要予測値が設けられている。ここでは、各店舗に対し、４つの時間帯の需要予測値が設けられている。４つの時間帯は１番目：ｘ時０分〜（ｘ＋１）時０分、２番目：ｘ時１５分〜（ｘ＋１）時１５分、３番目：ｘ時３０分〜（ｘ＋１）時３０分、４番目：ｘ時４５分〜（ｘ＋１）時４５分である。図１７の例は、１５分ごとに１時間の間に積算された人数予測値が算出されることを前提としたものである。この方式では、例えば需要予測送信部５４は毎時０分に１番目の時間帯の各店舗の人数予測値を取得し、１番目の人数予測値を０にクリアする。毎時１５分、毎時３０分、毎時４５分も同様の処理を行う。こうすることで店舗が満たす検索条件を満たす検索ログを探さなくても人数予測値などを算出することができる。

また需要予測算出部５３は、この検索要求と異なる検索ログが存在する場合には、その検索ログに含まれる検索条件を満たす店舗についてその検索ログの数の増加により人数予測値が減少すべき値を、その店舗の人数予測値から減算し更新する処理を行ってもよい。また人数予測値だけでなく、金額予測値もステップＳ４０６の後のタイミングで計算してもよいし、項目詳細画面データが送信された後のタイミング（例えば図１０のステップＳ１２４の後のタイミング）で項目詳細画面データの送信に基づいて人数予測値や金額予測値の値を加算してもよい。

ここまでは、商品またはサービスの例として特に飲食サービスを例とし、その飲食サービスの種類として店舗を用いる場合の例を中心に説明しているが、この発明を電子商店街システムの商品の受注数量の予測に用いてもよい。例えば電子商店街システムの商品検索で商品名などを検索条件として検索がされ、電子商店街の店舗がその検索される商品を販売している場合に、需要予測算出部５３がその検索条件の応じてその商品の受注数量の予測値を算出してもよい。

１ 検索サーバ、２ 需要予測サーバ、３ ユーザ端末、４ 店舗サーバ、５ 注文端末、６ ネットワーク、１１ プロセッサ、１２ 記憶部、１３ 通信部、１４ 入出力部、５１ 要求取得部、５２ 情報返信部、５３ 需要予測算出部、５４ 需要予測送信部、５５ 需要予測受信部、５６ 追加利用額推定部、５７ クーポン発行判定部、５８ クーポン出力部、６１ 商品サービス情報格納部、６２ ログ格納部、６３ 注文履歴格納部、７０ 検索条件入力領域、７１，７２，７３ 項目。

Claims (15)

1. 商品又はサービスに関する条件をそれぞれ含む、複数のユーザリクエストを受け付けるリクエスト受付手段と、
   前記各ユーザリクエストに応じて、前記条件を満足する１以上の商品又はサービスに関する情報を返信する情報返信手段と、
   需要予測の対象である商品又はサービスについて、該商品又はサービスが満足している条件を含む受付済みのユーザリクエストに基づいて需要予測値を算出する需要予測値算出手段と、
   を含むことを特徴とする需要予測システム。
2. 請求項１に記載の需要予測システムにおいて、
   前記商品又はサービスに関する条件は、複数の前記商品又はサービスの属性として設定される情報に関する条件を含む、
   ことを特徴とする需要予測システム。
3. 請求項１又は２に記載の需要予測システムにおいて、
   前記需要予測値算出手段は、前記需要予測の対象である商品又はサービスの属性として設定される情報に基づいて、該商品又はサービスが満足している条件を含む受付済みのユーザリクエストを抽出する手段を含む、
   ことを特徴とする需要予測システム。
4. 請求項１から３のいずれかに記載の需要予測システムにおいて、
   前記需要予測値算出手段は、前記条件を含むユーザリクエストのそれぞれに応じた値を加算して積算変数を更新し、更新された積算変数に基づいて前記需要予測値を算出する、
   ことを特徴とする需要予測システム。
5. 請求項１から４のいずれかに記載の需要予測システムにおいて、
   前記需要予測値算出手段は、需要予測の対象である前記商品またはサービスが満足する条件を含む受付済みのユーザリクエストの数と当該ユーザリクエストに含まれる条件を満たす商品またはサービスの数とに基づいて需要予測値を算出する、
   ことを特徴とする需要予測システム。
6. 請求項１から５のいずれかに記載の需要予測システムにおいて、
   前記需要予測値算出手段は、前記ユーザリクエストを送信するユーザが送信したユーザリクエストの数にさらに基づいて需要予測値を算出する、
   ことを特徴とする需要予測システム。
7. 請求項１から６のいずれかに記載の需要予測システムにおいて、
   前記需要予測値算出手段は、前記ユーザリクエストを送信したユーザの位置にさらに基づいて需要予測値を算出する、
   ことを特徴とする需要予測システム。
8. 請求項７に記載の需要予測システムにおいて、
   前記需要予測値算出手段は、所定の条件を充足する時刻になされた前記受付済のユーザリクエストに基づいて前記需要予測値を算出し、
   前記所定の条件は、前記需要予測の対象である商品又はサービスを得る位置と、前記ユーザリクエストを送信したユーザの位置と、に基づくものである、
   ことを特徴とする需要予測システム。
9. 請求項１から８のいずれかに記載の需要予測システムにおいて、
   前記商品又はサービスは飲食サービスであり、
   前記情報返信手段は、飲食サービスに関する情報を返信する、
   ことを特徴とする需要予測システム。
10. 請求項９に記載の需要予測システムにおいて、
    前記需要予測値算出手段は、需要予測の対象である商品又はサービスについて、該商品又はサービスが満足している条件を含む受付済みのユーザリクエストに基づいて、該商品又はサービスである飲食サービスを利用する人数を予測する、
    ことを特徴とする需要予測システム。
11. 請求項１０に記載の需要予測システムにおいて、
    現時点で前記飲食サービスを利用する顧客が将来注文する追加金額を推定する追加利用額推定手段と、
    前記飲食サービスが利用される際の予想金額と、前記推定された追加金額とに基づいて、現時点で前記飲食サービスを利用する顧客に退店を促す情報を出力するか否かを決定する退店判定手段と、
    をさらに含むことを特徴とする需要予測システム。
12. 請求項１１に記載の需要予測システムにおいて、
    前記需要予測値算出手段は、前記ユーザリクエストを送信したユーザの当日の所定時間以内の飲食サービスの利用金額の実績に基づいて、前記飲食サービスが利用される際の予想金額を算出する、
    ことを特徴とする需要予測システム。
13. 請求項１１または１２に記載の需要予測システムにおいて、
    前記退店判定手段が現時点で前記飲食サービスを利用する顧客に向けて退店を促す情報を出力すると決定した場合に、前記顧客に対して所定の条件を満たして退店すると特典が与えられるクーポンに関する情報を出力するクーポン出力手段、
    をさらに含むことを特徴とする需要予測システム。
14. 商品又はサービスに関する条件をそれぞれ含む、複数のユーザリクエストを受け付けるステップと、
    前記各ユーザリクエストに応じて、前記条件を満足する１以上の商品又はサービスに関する情報を返信するステップと、
    需要予測の対象である商品又はサービスについて、該商品又はサービスが満足している条件を含む受付済みのユーザリクエストに基づいて需要予測値を算出するステップと、
    を含むことを特徴とする需要予測方法。
15. 商品又はサービスに関する条件をそれぞれ含む、複数のユーザリクエストを受け付け、
    前記各ユーザリクエストに応じて、前記条件を満足する１以上の商品又はサービスに関する情報を返信し、
    需要予測の対象である商品又はサービスについて、該商品又はサービスが満足している条件を含む受付済みのユーザリクエストに基づいて需要予測値を算出する、
    処理をコンピュータに実行させるためのプログラム。

Images