ホーム > 特許ランキング > エヌ・エス・システム株式会社
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2024-10-09
(45)【発行日】2024-10-18
(54)【発明の名称】食堂における注文量予測システム
(51)【国際特許分類】
G06Q 50/12 20120101AFI20241010BHJP
【ＦＩ】
G06Q50/12
【請求項の数】
14
(21)【出願番号】P 2024123695
(22)【出願日】2024-07-30
【審査請求日】2024-07-30
【早期審査対象出願】
(73)【特許権者】
【識別番号】522491177
【氏名又は名称】エヌ・エス・システム株式会社
(74)【代理人】
【識別番号】100120031
【弁理士】
【氏名又は名称】宮嶋 学
(74)【代理人】
【識別番号】100120617
【弁理士】
【氏名又は名称】浅野 真理
(74)【代理人】
【識別番号】100126099
【弁理士】
【氏名又は名称】反町 洋
(74)【代理人】
【識別番号】100210675
【弁理士】
【氏名又は名称】下山 潤
(72)【発明者】
【氏名】西澤 泰夫
【審査官】岩橋 龍太郎
(56)【参考文献】
【文献】特開２０１８－１８５５９１（ＪＰ，Ａ）
【文献】特開２０２３－１１７４２３（ＪＰ，Ａ）
【文献】星野 智洋，“機械学習を用いた飲食店運営の効率化へのアプローチ”，２０１８年度 人工知能学会全国大会（第３２回），一般社団法人 人工知能学会，2018年06月05日，ｐｐ.１－３
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００－９９／００
(57)【特許請求の範囲】
【請求項1】
過去注文履歴データベースと、外部因子データベースと、注文パターンモデル生成部と、注文量予測演算部と、注文量更新演算部とを備える、食堂における注文量予測システムであって、前記過去注文履歴データベースは、ユーザ毎の前記食堂における過去の注文履歴を、前記ユーザの属性情報および時系列と関連づけて記憶し、
前記外部因子データベースは、前記注文履歴を除く任意の情報を時系列と関連付けて記憶し、
前記注文パターンモデル生成部は、前記過去注文履歴データベースに記憶された情報と前記外部因子データベースに記憶された情報とに基づき、時系列に沿った前記ユーザ毎の注文パターンモデル、時系列に沿った前記属性毎の注文パターンモデル、および／または時系列に沿った前記食堂全体の注文パターンモデルを生成し、
前記注文量予測演算部は、
（１）前記ユーザ毎の注文パターンモデルと、特定日のメニューと、前記外部因子データベースに記憶されている前記特定日に関連する情報とに基づき、前記特定日における時系列に沿った前記ユーザ毎の注文予測モデルを演算し、かつ前記ユーザ毎の注文予測モデルの総和に基づき、前記特定日における時系列に沿った前記食堂全体の注文予測モデルを演算する、
（２）前記属性毎の注文パターンモデルと、特定日のメニューと、前記外部因子データベースに記憶されている前記特定日に関連する情報とに基づき、前記特定日における時系列に沿った前記属性毎の注文予測モデルを演算し、かつ前記属性毎の注文予測モデルの総和に基づき、前記特定日における時系列に沿った前記食堂全体の注文予測モデルを演算する、および／または
（３）前記食堂全体の注文パターンモデルと、特定日のメニューと、前記外部因子データベースに記憶されている前記特定日に関連する情報とに基づき、前記特定日における時系列に沿った前記食堂全体の注文予測モデルを演算し、
前記注文量更新演算部は、
（１）前記ユーザ毎の注文予測モデルを前記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った前記ユーザ毎の更新後注文予測モデルを演算し、かつ前記ユーザ毎の更新後注文予測モデルに基づき、前記特定日における時系列に沿った前記食堂全体の更新後注文予測モデルを演算する、
（２）前記属性毎の注文予測モデルを前記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った前記属性毎の更新後注文予測モデルを演算し、かつ前記属性毎の更新後注文予測モデルに基づき、前記特定日における時系列に沿った前記食堂全体の更新後注文予測モデルを演算する、および／または
（３）前記食堂全体の注文予測モデルを前記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した前記特定日における時系列に沿った前記食堂全体の更新後注文予測モデルを演算する、
注文量予測システム。
【請求項2】
前記外部因子データベースが気象情報および組織におけるイベント情報からなる群より選択される少なくとも１つを記憶する、請求項１に記載の注文量予測システム。
【請求項3】
前記注文量予測演算部が、さらに前記特定日における前記ユーザ毎の注文予約情報に基づき前記ユーザ毎の注文予測モデル、前記属性毎の注文予測モデル、および／または前記食堂全体の注文予測モデルを演算する、請求項１に記載の注文量予測システム。
【請求項4】
前記ベイズ統計学の手法がベイズ推論である、請求項１に記載のシステム。
【請求項5】
前記ユーザ毎の注文予約情報を記憶する注文予約データベースをさらに備える、請求項３に記載の注文量予測システム。
【請求項6】
前記ユーザ毎の注文パターンモデル、前記属性毎の注文パターンモデル、および／または前記食堂全体の注文パターンモデルを記憶する注文パターンモデルデータベースをさらに備える、請求項１に記載の注文量予測システム。
【請求項7】
前記ユーザ毎の注文予測モデル、前記属性毎の注文予測モデル、および／または前記食堂全体の注文予測モデルを記憶する注文予測モデルデータベースをさらに備える、請求項１に記載の注文量予測システム。
【請求項8】
前記ユーザ毎の更新後注文予測モデル、前記属性毎の更新後注文予測モデル、および／または前記食堂全体の更新後注文予測モデルを記憶する更新後注文予測モデルデータベースをさらに備える、請求項１に記載の注文量予測システム。
【請求項9】
前記注文量予測システムが補正パラメータ演算部をさらに備え、前記補正パラメータ演算部は、前記食堂全体の更新後注文予測モデルと、前記特定日における前記食堂全体の実際の注文量とに基づき、前記ユーザ毎の注文パターンモデル、前記属性毎の注文パターンモデル、および／または前記食堂全体の注文パターンモデルの補正に使用される補正パラメータを演算する、
請求項１に記載の注文量予測システム。
【請求項10】
請求項１～９のいずれか一項に記載の注文量予測システムと、前記ユーザ毎の特定日における実際の注文履歴を前記注文量予測システムに送信する注文受付システムと、
前記食堂全体の注文予測モデルおよび／または前記食堂全体の更新後注文予測モデルを表示する表示システムと
を備える、食堂注文システム。
【請求項11】
食堂における注文量を予測する方法であって、コンピュータが、
過去注文履歴データベースに記憶された情報と外部因子データベースに記憶された情報とに基づき、時系列に沿ったユーザ毎の注文パターンモデルおよび／または時系列に沿った属性毎の注文パターンモデルを生成するステップと、
前記ユーザ毎の注文パターンモデルおよび／または前記属性毎の注文パターンモデルと、特定日のメニューと、前記外部因子データベースに記憶されている前記特定日に関連する情報とに基づき、前記特定日における時系列に沿った前記ユーザ毎の注文予測モデルおよび／または前記特定日における時系列に沿った前記属性毎の注文予測モデルを演算するステップと、
前記ユーザ毎の注文予測モデルおよび／または前記属性毎の注文予測モデルの総和に基づき、前記特定日における時系列に沿った前記食堂全体の注文予測モデルを演算するステップと、
前記ユーザ毎の注文予測モデルおよび／または前記属性毎の注文予測モデルを前記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った前記ユーザ毎の更新後注文予測モデルおよび／または時系列に沿った前記属性毎の更新後注文予測モデルを演算するステップと、
前記ユーザ毎の更新後注文予測モデルおよび／または前記属性毎の更新後注文予測モデルに基づき、前記特定日における時系列に沿った前記食堂全体の更新後注文予測モデルを演算するステップと、
を実行し、
前記過去注文履歴データベースは、前記ユーザ毎の前記食堂における過去の注文履歴を、前記ユーザの属性情報および時系列と関連づけて記憶し、
前記外部因子データベースは、前記注文履歴を除く任意の情報を時系列と関連付けて記憶する、方法。
【請求項12】
食堂における注文量を予測する方法であって、コンピュータが、
過去注文履歴データベースに記憶された情報と外部因子データベースに記憶された情報とに基づき、時系列に沿ったユーザ毎の注文パターンモデルおよび／または時系列に沿った属性毎の注文パターンモデルを生成するステップと、
前記ユーザ毎の注文パターンモデルおよび／または前記属性毎の注文パターンモデルと、特定日のメニューと、前記外部因子データベースに記憶されている前記特定日に関連する情報とに基づき、前記特定日における時系列に沿った前記ユーザ毎の注文予測モデルおよび／または前記特定日における時系列に沿った前記属性毎の注文予測モデルを演算するステップと、
前記ユーザ毎の注文予測モデルおよび／または前記属性毎の注文予測モデルの総和に基づき、前記特定日における時系列に沿った前記食堂全体の注文予測モデルを演算するステップと、
前記食堂全体の注文予測モデルを前記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した前記特定日における時系列に沿った前記食堂全体の更新後注文予測モデルを演算するステップと、
を実行し、
前記過去注文履歴データベースは、前記ユーザ毎の前記食堂における過去の注文履歴を、前記ユーザの属性情報および時系列と関連づけて記憶し、
前記外部因子データベースは、前記注文履歴を除く任意の情報を時系列と関連付けて記憶する、方法。
【請求項13】
食堂における注文量を予測する方法であって、コンピュータが、
過去注文履歴データベースに記憶された情報と外部因子データベースに記憶された情報とに基づき、時系列に沿った食堂全体の注文パターンモデルを生成するステップと、
前記食堂全体の注文パターンモデルと、特定日のメニューと、前記外部因子データベースに記憶されている前記特定日に関連する情報とに基づき、前記特定日における時系列に沿った食堂全体の注文予測モデルを演算するステップと、
前記食堂全体の注文予測モデルをユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した前記特定日における時系列に沿った前記食堂全体の更新後注文予測モデルを演算するステップと、
を実行し、
前記過去注文履歴データベースは、前記ユーザ毎の前記食堂における過去の注文履歴を、前記ユーザの属性情報および時系列と関連づけて記憶し、
前記外部因子データベースは、前記注文履歴を除く任意の情報を時系列と関連付けて記憶する、方法。
【請求項14】
前記食堂全体の更新後注文予測モデルと、前記特定日における前記食堂全体の実際の注文量とに基づき、前記ユーザ毎の注文パターンモデル、前記属性毎の注文パターンモデル、および／または前記食堂全体の注文パターンモデルの補正に使用される補正パラメータを演算するステップをさらに含む、請求項１１～１３のいずれか一項に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、食堂における注文量予測システムに関する。
【背景技術】
【0002】
近年、ＳＤＧｓを目的として、食堂やレストラン等の飲食物を提供する場所においては、日々の発注量の予測をいかに正確に事前に行うかが非常に重要になってきている。そのため、例えば食堂の運営を行う食堂運営会社は、大規模なデータベースを有していることが通例となっている。そうしたデータベースは、日々のメニューがどれだけ売れたのかを分析し、長年のデータを蓄えていることが一般的である。
【0003】
そこで、店舗への来客数、客単価、売れ筋、混雑する日、時間帯、昨年対比などの店舗データを分析して、翌日や一年後の来客数等について注文量を予測するシステムが近年検討されている。
【発明の概要】
【0004】
従来のシステムは、あくまでも不特定の来客を対象として来客数や来客時間を予測するモデルであるため、主に特定のユーザが繰り返し食堂を訪問し、飲食を行うという特有な条件下、すなわち、限られた時間の極めて多量の集中的な発注の需要を予測することが極めて困難である。
【0005】
本開示は、主に特定のユーザが繰り返し食堂を訪問し、飲食を行うという特有な条件下であっても、注文量を予測することが可能なシステムを提供することを一つの目的とする。
【0006】
本開示者は、鋭意検討したところ、意外にも、ユーザの属性情報と、当該ユーザの注文履歴とに基づき、ベイズ統計学の手法による演算を実施することで、食堂における注文量を予測することが可能になることを見出した。本開示は、かかる知見に基づくものである。
【0007】
本開示の一実施態様によれば、過去注文履歴データベースと、外部因子データベースと、注文パターンモデル生成部と、注文量予測演算部と、注文量更新演算部とを備える、食堂における注文量予測システムであって、
上記過去注文履歴データベースは、ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶し、
上記注文パターンモデル生成部は、上記過去注文履歴データベースに記憶された情報と上記外部因子データベースに記憶された情報とに基づき、時系列に沿った上記ユーザ毎の注文パターンモデル、時系列に沿った上記属性毎の注文パターンモデル、および／または時系列に沿った上記食堂全体の注文パターンモデルを生成し、
上記注文量予測演算部は、
（１）上記ユーザ毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記ユーザ毎の注文予測モデルを演算し、かつ上記ユーザ毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算する、
（２）上記属性毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記属性毎の注文予測モデルを演算し、かつ上記属性毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算する、および／または
（３）上記食堂全体の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算し、
上記注文量更新演算部は、
（１）上記ユーザ毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記ユーザ毎の更新後注文予測モデルを演算し、かつ上記ユーザ毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、
（２）上記属性毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記属性毎の更新後注文予測モデルを演算し、かつ上記属性毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、および／または
（３）上記食堂全体の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、
注文量予測システムが提供される。
上記過去注文履歴データベースは、ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶し、
上記注文パターンモデル生成部は、上記過去注文履歴データベースに記憶された情報と上記外部因子データベースに記憶された情報とに基づき、時系列に沿った上記ユーザ毎の注文パターンモデル、時系列に沿った上記属性毎の注文パターンモデル、および／または時系列に沿った上記食堂全体の注文パターンモデルを生成し、
上記注文量予測演算部は、
（１）上記ユーザ毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記ユーザ毎の注文予測モデルを演算し、かつ上記ユーザ毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算する、
（２）上記属性毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記属性毎の注文予測モデルを演算し、かつ上記属性毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算する、および／または
（３）上記食堂全体の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算し、
上記注文量更新演算部は、
（１）上記ユーザ毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記ユーザ毎の更新後注文予測モデルを演算し、かつ上記ユーザ毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、
（２）上記属性毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記属性毎の更新後注文予測モデルを演算し、かつ上記属性毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、および／または
（３）上記食堂全体の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、
注文量予測システムが提供される。
【0008】
本開示の一実施態様によれば、主に特定のユーザが繰り返し食堂を訪問し、飲食を行うという特有な条件下であっても、注文量を予測することが可能なシステムを提供することができる。
【図面の簡単な説明】
【0009】
【図1】本開示の注文量予測システムの機能ブロック図の一例を示す。
【図2】本開示の注文量予測システムの処理フローの一例を示す。
【図3】本開示の注文量予測システムにおける注文パターンモデル生成部の処理フローを示す。
【図4】本開示の注文量予測演算部の処理フローを示す。
【図5】本開示の注文量更新演算部の処理フローを示す。
【図6】本開示の補正パラメータ演算部を示す。
【図7】ベイズ推論の概念図の一例を示す。
【図8】本開示の食堂注文システムの概略図を示す。
【図9】本開示の注文受付システムの機能ブロック図の一例を示す。
【図10】本開示の表示システムの機能ブロック図の一例を示す。
【図11】本開示の注文量予測システムおよび食堂注文システムの一例を示す。
【図12】本開示の過去注文履歴データベースに記憶されている情報の一例を示す。
【図13】本開示の注文パターンモデル生成部における重回帰分析結果の一例（箱ひげ分析）を示す。
【図14】本開示の注文パターンモデル生成部における重回帰分析結果の一例（ピアソン相関関係分析）を示す。
【図15】本開示の注文パターンモデル生成部で生成された注文パターンモデルの一例を示す。
【図16】本開示の注文パターンモデル生成部で生成された注文パターンモデルの一例を示す。
【図17】本開示の注文予約データベースに記憶されている情報の一例を示す。
【図18】本開示の注文量予測演算部で演算されたユーザ毎の注文予測モデルの一例を示す。
【図19】本開示の注文量予測演算部で演算されたユーザ毎の注文予測モデルの一例を示す。
【図20】本開示の注文量予測演算部で演算された食堂全体の注文予測モデルの一例を示す。
【図21】本開示の注文量予測演算部で演算された食堂全体の注文予測モデルの一例を示す。
【図22】本開示の当日注文履歴データベースに記憶されている情報の一例を示す。
【図23】本開示の注文量更新演算部で演算された食堂全体の更新後注文予測モデルの一例を示す。
【発明の具体的説明】
【0010】
［従来システムと社会的背景］
社員食堂や学生食堂のように、多数の特定の所属員が訪れることがほぼ決まっていて、その対象となる所属員が常にほぼ同じ人間であるという性質を帯びたいわゆる「閉じた場所」での多量供給の食堂において、個々人に着目したデータ分析は、従来のシステムでは不可能であった。
社員食堂や学生食堂のように、多数の特定の所属員が訪れることがほぼ決まっていて、その対象となる所属員が常にほぼ同じ人間であるという性質を帯びたいわゆる「閉じた場所」での多量供給の食堂において、個々人に着目したデータ分析は、従来のシステムでは不可能であった。
【0011】
すなわち、従来のシステムでは、事前に来客数と売れ筋のメニュー数などを予測することは可能であるが、ユーザ毎の属性に関する情報はほとんどないしは全く考慮されていない。会社や学校といった「閉じた組織」ではその所属員はほとんどの場合ほぼ同じであると考えられ、従来のシステムは、そうした所属員が定期的に（例えば、ほぼ毎日）訪問するようなタイプの食堂特有の現象に対応するように構成されていなかった。したがって、従来のシステムでは、事前に来客数や注文されるメニュー数の予測を行うといういわば静的ともいうべき予測であるといえ、特定の所属員が日々喫食するような閉じた場所における食堂において、個々人に着目し、所属員個々人のこれまでの喫食データを基にしたような予測は実現できておらず、またそれら所属員がある限られた時間内に集中して訪問して飲食を行うような「閉じた場所」での多量供給の食堂における予測には適切なものではなかった。
【0012】
従来のシステムは、主に複数の一般的なレストランや観光地における特定のレストラン（食堂）の来客の予測には力を発揮するように作られている。つまり、過去来客のデータをもとに、季節、天気、曜日などの情報を重ね合わせて、来客数を正確に予測することが可能である。来客の時間の予測、売れ筋のメニューの飲食数（発注数）等の予測も比較的正確に行うことができる。しかしながら、こうした従来のシステムは、「閉じた組織」にある「閉じた場所」での多量供給の食堂では余り力を発揮できない。時間に応じた来客予測だけでは、「閉じた場所」での多量供給の食堂で必要とされる、限られた時間の極めて多量の集中的な発注の需要を予測しきれない欠点に加えて、「閉じた組織」の所属員が繰り返し食堂を訪問し飲食を行うという「閉じた場所」での食堂に特有な特定の所属員が日々喫食するという特徴に着目していないという欠点がある。
【0013】
「閉じた組織」にある「閉じた場所」での多量供給の食堂では、同じような人間、つまり当該組織の所属員が定期的に（例えば、ほぼ毎日）利用するという特徴がある。さらに、閉じた場所に常にいる当該所属員は、集中した時間に訪問することを常としていて、こうした「閉じた場所」での多量供給の食堂は、例えばお昼休憩時間が開始する１２時～１２時１５分に最も来客が多く、いわば来客が殺到することを習慣としており、そこで「閉じた場所」での多量供給の食堂はピークの混み具合となることを常態としているような特殊性を有している。従来の予測システムは、そうした極度の集中状態の来客数を的確に予測するシステムではなく、したがって、例えば毎日の１２時～１２時１５分といった時間にいわば殺到する人間の数を予測したり、そこで発注されるメニューの提供数を予測したりすることが可能なシステムではなく、さらに１２時１５分までの状態を基に、例えば１３時３０分の食堂閉店時間までの残り時間の来客数予測や各メニュー発注量の予測の修正のような機能はない。こうした「閉じた場所」での多量供給の食堂では、ほぼ同じ所属員が定期的に（例えば、ほぼ毎日）ごく限られた時間に非常に集中して来客し飲食することを常態としているが、そうした常態において、今後の発注量を時々刻々と予測し直すような動的な予測を可能とするシステムはなかった。ところが、まさにこうした動的な発注予測が「閉じた場所」での多量供給の食堂では必要とされているのであるが、従来のシステムはそうした必要性に応じて機能を有していなかった。
【0014】
そのため、当該「閉じた場所」での多量供給の食堂の責任者（例えば料理長）の勘と人間の判断のみで、この「閉じた場所」での多量供給の食堂における常態としての短期的集中型の来客および発注に対応しているのが現状である。例えば、食堂運営会社では、前日までに過去のデータや過去の記憶に基づいて、当該食堂運営会社が保有するシステムの支援を受けつつ、当該「閉じた場所」での多量供給の食堂の責任者が、過去の実績や人間の勘として、発注量を予測して、当該メニューの発注予測を行い、必要な材料の手当を行い、部下の調理人に命じて、材料の仕込みや実際に当該メニューを必要な予測量に応じて調理し始める。しかし、食堂開店の当日は、一旦食堂が開店した後は、上記責任者の最終決断としてのメニュー毎の予測量から実際の来客による発注数とどのくらい違うのかは、時々刻々と上記責任者がほぼ勘でとらえて、閉店までの最終状態までを人間の勘で予測しなおして、当該時刻以降の発注量を調整して運営している。つまり、ほぼ人間の勘にたよって運営しているのが実情である。
【0015】
また、会社や学校という特定の「閉じた組織」において、社員食堂や学生食堂という「閉じた場所で営む食堂」において、当該閉じた組織の所属員である社員や学生が、ほぼ毎日習慣的に食するという特徴を持っているが、そこでは喫食する人間がほぼ毎日同じ人間あるという特徴を持つ。一方、飲食業で普及しつつある従来の予測システムでは、これとは全く異なり同じ人間が二日連続で訪れることがほぼないようなレストラン等で利用されることが通例という特徴を持つ。つまり、従来のシステムは、ほぼ一回きりしか訪れない人間を対象としたものである。したがって、従来のシステムでは、喫食する所属員各々個々人の属性等のデータに注目して、個々人や属性毎の行動を予測するような機能もなく、個々人のデータに基づき個々人や属性毎の行動についての予測を積み上げる形で、食堂全体について予測する機能は全くない。
【0016】
また、従来のシステムは、パラメータや機能の設定によっては「閉じた場所」における食堂全体として来客数やメニュー毎の発注数を予測することができるかもしれないが、所属員個々人の行動や喫食データを記録していることもなく、また当該所属員個々人や属性毎について予測する機能もなく、かつ非常に限られた一定の時間に集中的に訪問することを毎日繰り返すような場所での食堂での問題を解決することはできない。
【0017】
以下のような形態が、会社の社員食堂や学生食堂のような特定の「閉じた組織」の所属員が日々喫食するような「閉じた場所での食堂」としての運用として、現在一般的である。例えば、料理長が１２時前の食堂オープン前に、メニューの発注予想をたてる。そして、この当初予測数量に基づいて初期調理（作成）量を準備する。１２時から来客が訪問しはじめて、１２時１５分では、かなりの人間が来訪する。その時点で、食堂が終了する１３：３０ごろまでの発注量を再度、人間の勘で見直して、最後の着地点までの調理数を食堂運営の途中時間に決定している。これらの動的な発注量の調整は過去の経験からくる完全に料理長、すなわち人間の勘に頼ることが多い。あるいは、食堂運営会社が保有する従来のシステムでは、食堂開店前に来客数をＡＩ予測し、さらに過去のデータからＡＩによって、ある特定のメニュー（献立）がどのくらい発注されるのかということを予測する機能を持つ場合はある。しかしながら、こうした従来のシステムでは、注文受付システム（例えば、食堂レジ）と連動していないだけでなく、個々人の行動を観察や記録する機能もない。したがって、例えば上記のように食堂が１２時に開店した場合、１２時１５分までの来客数やある特定メニューへの注文状況から、その後の発注状況や食堂閉鎖までの合計値としてのトータル発注数を、個々人の来客時間と発注メニューの状況をみながら、全体について予測し直すような機能はない。従来のシステムでは、当初予測した数量からずれが生じるかどうかの判断は人間が勘として修正していくしかなく、それを補正する技術はなかった。途中で補正する技術を備えるためには、従来とは異なる新規の技術がどうしても必要であるが、既存技術を用いて途中で補正することが可能であったとしても、注文受付システム（例えば、食堂レジ）と連動する機能が従来技術にはないため、特定の個人や特定の属性を持つ集団がどのような行動をしているのかというリアルタイムのデータを時々刻々と用いて、数学的、統計学的な分析を行うことはできない。つまり、ＡＩ機能の処理によって都度、発注量の予測を時々刻々と補正する必要があるが、従来のこうした技術にはこうした根拠となる技術や機能は見られない。
【0018】
本開示はまさにこの「閉じた組織」にある「閉じた場所」での多量供給の食堂という特殊性も考慮した上で、さらにそこで食堂開始前の予測値と、例えば１２時１５分というある一定の経過時間時点までの注文受付システムからあがる来客データ、発注データという所属員個々人および特定の属性の集団に関して食堂レジから時々刻々と得られるリアルタイムのデータを勘案して、その時点までの実績値と事前予測値とのずれを比較して認識することよって、その時点で改めて着地点の予測、および途中の発注カーブの予測を行うことの重要性について鑑みているのである。逆に言えば、こうしたことの「重要性」についての考察がなければ、本開示の必要性は少しも認識されることがないといえる。
【0019】
上記「重要性」についてより詳細に説明する。まず、「閉じた場所」での多量供給の食堂は、例えば１０００人、２０００人のような非常に多数の来客、しかも特定の閉じた組織における所属員が日々喫食する場所である。そして、当該所属員が例えば昼食時には、１２時～１３時に集中して来客する。さらに、１２時～１２時１５分くらいの非常に短い特定の時間にかけて集中して来客する。これだけ多数の人間が特定の時間に集中して訪問する場所ということが、本開示が最も考察している前提となっている。その集中度は、一般的な大型のレストランをはるかに上回る。通常の一般的なレストランと異なるのは、非常に短時間の来店訪問客はけた違いの集中度をもっており、圧倒的な密度で訪れることが常態となっており、本開示で考察しているような特殊性を持ち、この特殊性がゆえに事前予測だけではなく、当該食堂開店時から注文受付システム（例えば、食堂レジ）を通して時々刻々と変化する来客数、発注数さらには所属員個々人に関するデータを基に、閉店まで残り時間の来客数や発注数の予測を修正し直さなければならないという性質を持つのである。
【0020】
さらに、その来客の人間が、ある会社や工場などの職場や、大学のキャンパスにおける学生食堂のように、毎日同じ種類の所属員である人間が習慣的に訪れて飲食を行う場所という特徴を持つ。したがって、不特定多数が訪れて飲食を行うような一般的なレストランにおける予測よりも、特定の人間が繰り返し訪問し飲食する場所なので、過去の様々なデータに基づいて行う開店前の予測は、一般的な来客予想システムよりも正確な発注予測を創ることが可能となる。しかしながら、食堂運営業者の従来の予測システムでは、特定の個人や特定の集団についてのデータをもっておらず、そうした機能はない。
【0021】
圧倒的な密度で訪れる所属員に対して、開店前にこの時刻にはこのメニューはこのくらい事前準備しておくとか、このくらい事前に材料を用意しておく（野菜、お肉を切っておく等）、このくらいの時間にはこのくらい炒めはじめる、このくらいの時間には皿に盛り付けておく、という「事前準備プログラム」を通常は設計しておく。しかし、この事前準備の対象となる発注の合計としての個数が数百から数千まで莫大な数を想定しなければならないというところに「閉じた場所」での多量供給の食堂の特殊性がある。通常の一般的なレストランとはけた違いな時間密度で人が訪れ、かつけた違いな形で注文の発注がなされるという特徴がある。したがって、例えば事前予測と、結果としての発注数量がずれた場合は、食堂運営会社の経済的にも相当にダメージがある。このメニューごとの発注予想を賢明に行わなければ、極端にいうと数百という莫大な数のずれが生じる恐れがあるという点に、この「閉じた場所」での多量供給の食堂での需要予測と実際のずれの重要性がある。かつ、その事前予測量と実際の量との差が莫大であるがゆえに、食堂開店後、食堂の運営状況を見ながら時々刻々と状況に応じて発注予測の補正を行っていかなければならないという「閉じた場所」での多量供給の食堂に特有の事情がある。
【0022】
「閉じた組織」にある「閉じた場所」での多量供給の食堂というのは通常の場合は、その食堂のオーナーはまさに当該の「閉じた組織」、すなわち会社や大学などの学校法人であるが、食堂を運営する「食堂運営会社」は、そうした「閉じた組織」との契約によって、食事を業務として提供する義務があり、こうした「食堂運営会社」を「コントラクトフードサービス（Ｃｏｎｔｒａｃｔ Ｆｏｏｄ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）」という。すなわち、会社や学校法人が委託者となり、ある約束のもとで食事を提供するという業務委託契約にしたがって、受託者である食堂運営会社に対して委託する。この「業務委託契約」はある予算内の助成金の形で委託者から補助されているスキームが多く、所属員である会社員や学生に対して、できるだけ安価でリーゾナブルな価格の中で、できるだけ充実したメニューを提供し、委託者である会社や学校法人の利用者である社員や学生が日々満足できるような飲食を提供する義務を負っている。つまり、限られた予算の中で、できるだけ効率的に満足できる食事を提供し続ける義務を受託者である食堂運営業者は負っている。比較的厳しい経済性の中で、すなわち限られた予算の中でできるだけ利用者が満足できるようなメニューを提供しなければならない。したがって、「閉じた場所」での多量供給の食堂においては、上記のように莫大な人数の利用者が限られた時間に集中的に訪問して集中的に飲食するので、事前に準備すべき食事数を余裕もって多く用意すればより良いとか、準備を多くしておくほうが便利で良いのだというような「安全策」を中心に考えれば良いというものではなく、できるだけ無駄を省かないといけなく、事前予測と実態ができるだけ一致していることが望ましいという経済合理性も非常に重要なのである。
【0023】
「安全策」を取りすぎた場合、あるいは食堂開店前の予測量を多くしすぎて予測した場合、結果として用意した材料、もしくは、完成した料理が余るという無駄がでてしまう恐れがあり、できるだけ正確に予測しなければ、予測量と実際の発注量が大きく異なるような場合は、結果として「損失」が大きな数量の単位で起きてしまう。特に完成した料理、および調理直前で火を通したり煮たりする調理段階の最終段階直前の状態でそろえた材料については、食堂閉店時点で余っていた場合は、ほぼ廃棄しなければならない。この廃棄量が多い場合は、採算が悪くなり、委託者からもらうことが許されている金額（助成金や補助費）から受託者にかかるコストを差し引いて計算される受託者のこの業務委託契約における業務から創出する利益がこの廃棄に伴うコスト分だけ無駄になっているということができる。この業務委託契約は過去の歴史を振り返ると、受託業者である食堂運営業者にとっては、経済的にはかなり厳しい内容であるのが通例であり、この廃棄量が大きい場合、利益が大きく削減されることになる。実際のデータとして、廃棄量が１０％を超えた場合は、相当の赤字になると言われている。例えば、あるメニューで３００食を開店前に予測していて準備していた場合において、実際の発注量が２７０食だった場合は廃棄すべき量は３０食分となり、受託業者である食堂運営業者の利益は相当に削られてしまい、赤字となると言われている。したがって、事前予測量と実際の発注量の差ができるだけ小さいことが望ましく、あくまでも一般的な運営の話ではあるが、できれば５％以下であることが望ましいと言われている。すなわち、上記例では、３００食を予測するのであれば、実際の発注が２８５食前後あることが望ましい。
【0024】
一方、発注量のぎりぎりを調理すれば良いという考えもある。例えば発注があってから調理すれば良いという考え方も可能性としては有りうる。しかしながら、そこにも「閉じた組織」にある「閉じた場所」での多量供給の食堂に特有な危険性が大きくある。「閉じた組織」にある「閉じた場所」での多量供給の食堂においては、前述のとおり、特定の社員や学生が限られた時間帯に一気に多量に訪れる場である。ほぼ毎日定期的にこれだけ多数の人間が、いわば習慣的に訪れる場所は他にないとも言えるほど何度も何度も繰り返し利用する場所である。かつ、社員や学生にとって、昼食の時間というのは、重要な息抜きの時間であり、福利厚生的にも社員の休養と英気を養い、食事を通して従業員の肉体に対して栄養や水分やエネルギーを補給するという生物的にも重大な営みの時間であり、食堂はそのような飲食を行う重要な生命の営みの場である。かつ、最近はただ食事をすませれば良いという場所という認識をはるかに超えて、社員同士あるいは学生同士がコミュニケーションをとって話あってリラックスしたり、情報交換したり、和気藹々とした楽しい時間を過ごす一種のリクリエーションとしての意味も有する貴重な時間を提供する場所である。したがって、その時間は極めて有効に利用されなければならないし、快適であることが望ましい。したがって、発注があってから調理すれば良いということはあまり妥当ではない。待たせるという行為が許容される場合とそうではない場合があり、これは食堂の運用方針や食堂の運営思想に深く係わるところであるが、「閉じた組織」にある「閉じた場所」における多量供給する食堂においては、待たせる時間の許容範囲は狭いことが通例であり望ましいということである。
【0025】
一方で、「できるだけ作りたての食事を出した方が良い」という思想もある。「閉じた場所」での多量供給の食堂とはいえ、メニューの全部が既に事前に作られて皿などの食器に既に盛られたような状態で並んでいるのが理想とは言えない。これは、まさに食堂運営業者の重要なノウハウの一つであるが、「（あ）既にできているものを並べているもの、（い）調理時間の非常に短いもの、（う）調理時間が一定程度かかるもの、（え）調理時間の長いもの」という料理の組み合わせにある。この（あ）～（え）のバランスはまさに、委託者の会社や大学などの学校法人の食堂運営に対する考え方や哲学そのものと深く関係しており、委託者の食堂のあるべき姿についての考え方や哲学に寄り添う形で受託者である食堂運営業者がノウハウや技術そして独自の哲学や考え方をもとに独自性をある程度発揮するところでもあり、一概にこうした「閉じた場所」での多量供給の食堂で提供すべき料理は全部（あ）のように事前準備すべきものだと言い切ることもできない。しかしながら、上記のとおりこうした「閉じた場所」での多量供給の食堂における特殊性を考えた場合、できるだけ待たせないですぐに提供できる形、すなわち（あ）（い）が望ましいことは明白である。そして意図的もしくは戦略的に、（う）（え）のような料理を敢えて一部提供して、当該の閉じた食堂の運営をバラエティに富んだものにしたり、利用者である閉じた場所の所属員に通常ではないフレッシュな企画として提供したりする場合もありうる。ただし、待つ時間をできるだけ短くして、時間について不満なく食事を提供しなければならないというのは、「閉じた組織」にある「閉じた場所」での多量供給の食堂の運営に関する特殊性の重要な一つであり、一般的なレストランで許容される待ち時間、もしくは世間一般通念としての待ち時間との比較では、より一層短い時間での提供が一般的には望ましいし常識的であるといえる。例えばファストフードの代表であるハンバーガー店における発注、支払いから受け渡し場所での待機から注文した飲食物の手交に要する時間よりも、はるかに短い時間が通例の「閉じた場所」での多量供給の食堂では要求されるというのが、通例の常識だと言える。
【0026】
また、食堂運営業者の採算の問題以上に深刻にとらえられているのが、ＳＤＧｓによる「廃棄ゼロ」の要請である。廃棄が多いことは上述のとおり、食堂運営業者の利益を圧迫し採算を悪化させ、経済的に困難をもたらす。それでは、例えば事前予測値と実際の来客数、発注数に差があり、その差が大きくなった結果、実際の廃棄量が多かった場合でも、食堂運営業者が経済的に我慢をして低採算に甘んずればこの問題は済むのかというとそうではない。現在の世間一般常識および社会の要請としては「ＳＤＧｓ」を非常に重視する傾向にあり、「廃棄物が多い」ということは重大な問題を引き起こすととらえられており、以前よりもより一層深刻にとらえられている。「廃棄」は食堂運営業者だけにとどまらず、閉じた場所の食堂を保有しているまさに当該食堂自体のオーナーである「閉じた組織」の会社や学校自体に対して大きな影響を持ち始めている。つまり、会社や学校がその内部に包含している食堂において「廃棄が多い」ということ自体が、「ＳＤＧｓ」上の深刻な問題を内包している組織であるとみなされつつあるということが背景としてある。つまり、この問題は食堂運営業者だけではなく、まさに食堂のオーナーである会社や学校といった、運営主体である「閉じた組織」そのものが、「廃棄ゼロ」を極めて重視する傾向にあるということである。そして、このように運営主体である「閉じた組織」そのものが、ＳＤＧｓおよび「廃棄ゼロ」を重視すればするほど、食堂運営業者もそれに沿った形で自身が運営する食堂での「廃棄ゼロ」を推し進める必要がより一層強まっているのである。こうした中、すぐに食べられるようにと利便性だけを主目的として、予測量を多めに見すぎたり、余裕をもって事前準備をする方針をとって、各メニューについて事前調理しておく状態を多くしたり、材料を事前に準備しすぎている場合で、実際に注文者が予測量よりもはるかに少なかったりした場合、廃棄物が相当数でてしまう恐れがある。それを防ぎ、かつ利便性も高め、食堂のサービス面の質の向上を高めるためには、できるだけ事前予測が正確であることが望ましく、かつ開店後からの実際の来客状況、発注状況に応じて、時々刻々と当該時刻から閉店までの予測量の素早く正確な補正予測が重要であり、そうした目的を満たす機能を持つ予測システムが必要であると本開示者は考えた。
【0027】
事前予測だけのＡＩ予測システムでは、実際に食堂をオープンしてみて、実際の来客のデータを注文受付システム（例えば、食堂レジ）からリアルタイムで取りいれながら、閉店までの来客数予測、メニューの発注予測をリアルタイムで調整、補正して出力し続けるような機能はない。最初狙った事前予測だけにしたがって運用を開始し、予測量よりも来客数や発注数が少ないと料理長つまり人間の勘で判断することが常で、予測システムを用いて事前に予測した量を、人間が勘を働かせて再度修正しているケースが現時点の一般的な運用であり、やはりここでも人の勘に頼っているだけである。
【0028】
この「閉じた組織」にある喫食サービスを提供する食堂では、利用者は限られた場所の人間であり、同じ人間であれば、例えば昼休みの１時間のある特定の時間前後に来ることが習慣となっていることが多いため、個々人のデータをしっかり抑えて、特定の個人が１時間の昼休みのある特定の時間に食堂に来ることを確率として事前に知っておくならば、そうした社員の確率の総和として特定の集団である社員や学生といった「閉じた場所」の組織に所属する人間全体の来客数あるいは特定集団の来客数についても、食堂を訪問する時間がかなり正確に予測できるはずであると本開示者は考えた。現時点、世の中にあるような「閉じた場所での食堂」の来客数や、メニューの販売数の売れ行き予測には、こうした特定の人間個々人や特定集団の行動を長い期間記録し、そのデータを有効活用し、様々なモデルを作りそれを学習によって補正していくような機能はない。
【0029】
本開示は、このように、廃棄ゼロとサービスの向上を同時に目指すことも一つの目的としている。
【0030】
また、従来技術には、食堂レジと事前予測数を算出する演算部分とが連動して、この連動を基に個々人について記録されているデータを活用して、時々刻々と残り時間の来客数やメニュー発注数の予測を修正する機能はなく、あくまでも食堂開店前の予測だけであった。
【0031】
ある特定の日程、曜日、季節等で来客数や当該日の売れ筋を予測し、メニューの発注量を機械学習等により予測することは、他の従来のシステムでも可能である。しかしながら、かかる従来のシステムは、「閉じた組織」内にある「閉じた場所」での多量供給の食堂の需給予測を、注文受付システム（例えば、食堂レジ）からあがるリアルタイムのデータおよび、所属員個々人の行動予測を基に、時々刻々と変化する時間に応じて発注されるメニュー内容およびその発注量について予測する機能を有しておらず、食堂について時々刻々と多量な人数と多量の発注について予測することはできなかった。
【0032】
従来のシステムは、所属員一人一人の個々人に注目したものではなく、また、「例えば１２時１５分において残りの食堂運営時間における発注量を予測するように時々刻々とメニューの出荷数を予測判断するためのＡＩ機能を持つ」ものではなく、あくまでも過去のデータに基づいて、食堂全体について、特定の季節、年月日の特定日にこのくらい売れるだろうと予測することを支援するようなシステムであった。
【0033】
また、こうした食堂運営会社が現在使用しているような「メニュー毎の売上予想システム」では、上記のように所属員個々人や特定集団のデータを持っているものはなく、さらにこうした所属員が日々決済に利用する食堂レジと連動するような機能はなかった。したがって、事前に食堂全体について売上予測をしながらも、所属員個々人および特定集団がどういう確率でどのようなものを何時食べるのかというような個々人に注目して計測し、かつ予測するような機能もなく、かつ食堂レジと連動していないので、当該の所属員が何時に来店して何を発注するのかというデータを時々刻々と把握するような機能は全くなかった。したがって、このような食堂運営会社が現在使用しているシステムでは、食堂全体としてどのくらい来客がありどのくらいメニューへの発注があるのかということについて、あくまでも料理長等の人間の判断を基本としており、所属員個々人の行動が食堂レジから時々刻々と上がり、それに基づいてシステムが時々刻々と予測との差を補正し、食堂全体としてのメニュー毎の準備量などを時々刻々と修正したりするような機能はなかった。
【0034】
また近年、ＡＩ技術が発展しており、事前のデータがたとえ十分でなくても、時々刻々と将来起こり得ることを予測する仕組みが高度になってきている。従来の食堂運営業者が用いているメニューの出荷予想は、多くの食堂における過去の喫食データに基づくもので、天気や季節その他の因子と様々なメニューの発注予測との関係を、ピアソン相関係数等で予測するものであった。しかし、これは従来の確率論の考えに依拠したものが多く、様々に変化する人間の行動や、実際に起こっている現実に基づいて、その後の確率を算出する考えを基本とする「ベイズ推論」等に基づくものではなかった。近年発展しつつあるＡＩ演算処理の一つの中心が、時々刻々と変化する将来起こり得る確率を計算し直す「ベイズ推論」に基づくものである。従来、こうした「閉じた食堂」における「閉じた場所で多量供給する食堂」で、様々な因子を考慮し、かつ食堂レジ等と連動して時々刻々と来客し発注されるメニューに関するデータをリアルタイムで取り入れて、それに基づいて開店前に各種データからＡＩに基づいて事前作成した事前分布としての「事前予測」を、時々刻々とベイズ統計学の手法による処理を行って、都度「ベイズ更新」として新たに事後分布としての「発注予測」を作成していく機能は従来なかった。
【0035】
多くの来客に対して、多量の食事を限られた時間に供給することを使命とする営みを行う食堂、特に社員食堂や学生食堂などのように、会社や学校のように所謂「閉じた組織」における「閉じた場所」において、その「閉じた組織」の所属員である多量の人数が一気に来客して飲食する多種多様な食堂において、事前にメニューと各々の発注数を想定すること、さらにそのメニューの提供数を時間に応じて予測することは非常に重要となっている。既存の技術では、「閉じた場所」での多量供給の食堂における事前のメニューの総量としての予測を支援するＡＩ的な演算を行うシステム（仮説に基づいて予測する演算を行うコンピューターシステムを含み）は既に存在しているが、所属員個々人について分析することはできず、また、時間軸に沿って時々刻々と変化する来客数や飲食数に応じて、当該メニューの調理準備数および実際に調理作成すべき数量を時々刻々と適切な値を予測し表示する機能を持つようなシステムはなかった。食堂で提供されるメニュー全体についての数量および提供する時刻を関連付けて予測するシステムは現時点様々なシステムがあるが、時々刻々と実際に訪問し発注する来客状況を見ながら、時々刻々と適切な数量を補正し判断することは人間である料理長の勘に頼るところが大きかった。また、食堂全体で提供される各メニュー数量について分析するシステムは既存技術であったとしても、所属員一人一人の属性や嗜好や過去の行動に関するデータを元に、個々人について食堂への来客時間を予測することはできず、また、嗜好に基づいて発注するメニューの予測などを行う機能を持ったシステムではない。また食堂全体の来客や発注数量の予測を行うような現時点にあるシステムと言っても、それは食堂全体における予測であって、所属員個々人の行動予測を積みあげたものではなかった。
【0036】
［本開示の注文量予測システム等］
本開示の一実施態様によれば、過去注文履歴データベースと、外部因子データベースと、注文パターンモデル生成部と、注文量予測演算部と、注文量更新演算部とを備える、食堂における注文量予測システムであって、
上記過去注文履歴データベースは、ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶し、
上記注文パターンモデル生成部は、上記過去注文履歴データベースに記憶された情報と上記外部因子データベースに記憶された情報とに基づき、時系列に沿った上記ユーザ毎の注文パターンモデル、時系列に沿った上記属性毎の注文パターンモデル、および／または時系列に沿った上記食堂全体の注文パターンモデルを生成し、
上記注文量予測演算部は、
（１）上記ユーザ毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記ユーザ毎の注文予測モデルを演算し、かつ上記ユーザ毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算する、
（２）上記属性毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記属性毎の注文予測モデルを演算し、かつ上記属性毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算する、および／または
（３）上記食堂全体の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算し、
上記注文量更新演算部は、
（１）上記ユーザ毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記ユーザ毎の更新後注文予測モデルを演算し、かつ上記ユーザ毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、
（２）上記属性毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記属性毎の更新後注文予測モデルを演算し、かつ上記属性毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、および／または
（３）上記食堂全体の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、
注文量予測システムが提供される。
本開示の一実施態様によれば、過去注文履歴データベースと、外部因子データベースと、注文パターンモデル生成部と、注文量予測演算部と、注文量更新演算部とを備える、食堂における注文量予測システムであって、
上記過去注文履歴データベースは、ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶し、
上記注文パターンモデル生成部は、上記過去注文履歴データベースに記憶された情報と上記外部因子データベースに記憶された情報とに基づき、時系列に沿った上記ユーザ毎の注文パターンモデル、時系列に沿った上記属性毎の注文パターンモデル、および／または時系列に沿った上記食堂全体の注文パターンモデルを生成し、
上記注文量予測演算部は、
（１）上記ユーザ毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記ユーザ毎の注文予測モデルを演算し、かつ上記ユーザ毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算する、
（２）上記属性毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記属性毎の注文予測モデルを演算し、かつ上記属性毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算する、および／または
（３）上記食堂全体の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算し、
上記注文量更新演算部は、
（１）上記ユーザ毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記ユーザ毎の更新後注文予測モデルを演算し、かつ上記ユーザ毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、
（２）上記属性毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記属性毎の更新後注文予測モデルを演算し、かつ上記属性毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、および／または
（３）上記食堂全体の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、
注文量予測システムが提供される。
【0037】
本開示の別の実施態様によれば、上記注文量予測システムと、
上記ユーザ毎の特定日における実際の注文履歴を上記注文量予測システムに送信する注文受付システムと、
上記食堂全体の注文予測モデルおよび／または上記食堂全体の更新後注文予測モデルを表示する表示システムと
を備える、食堂注文システムが提供される。
上記ユーザ毎の特定日における実際の注文履歴を上記注文量予測システムに送信する注文受付システムと、
上記食堂全体の注文予測モデルおよび／または上記食堂全体の更新後注文予測モデルを表示する表示システムと
を備える、食堂注文システムが提供される。
【0038】
本開示の一実施態様によれば、「閉じた組織」にある「閉じた場所」での多量供給の食堂においても、所属員個々人のデータを基に予測を行う為、事前にたてる来客時間予測、時刻毎メニュー毎の注文予測、食堂全体の来客予測、注文予測の正確さを大きく向上することができ、事前発注予想推測量を大幅に向上させることができる点で有利である。本開示の一実施態様によれば、一定の所属員である多量の人間が習慣として定期的に（例えばほぼ毎日）飲食を行い、さらにある限られた時間に集中的に訪問し、集中的に喫食するという特殊な特徴を持つ食堂においても、注文量を予測することができる点で有利である。
【0039】
本開示の一実施態様によれば、食堂レジで把握できるリアルタイムの所属員個々人の来客状況と発注状況や天気等の外部因子のデータに基づいて時系列に応じて分析することによって、最適なメニュー選択およびその料理数および時間に応じた調理数および必要な材料準備数等を時々刻々と予測して、調理場全体および料理長を含む料理人やスタッフに提示することが可能になる。特に、本開示の一実施態様によれば、社員食堂や学生食堂のように、日々同じような所属員が習慣的に訪れることを特徴とする「閉じた場所」での食堂において、その閉じた場所に特有な所属員個々人の習慣や嗜好を勘案し、かつ、かかる閉じた場所での飲食に特有な限られた時間において一気に多量の人員が飲食を行うという非常に限定された食堂において、個々人の習慣やデータに基づき、当該個々人の当該日における実際の来客時間と発注メニューという個々人に紐づくデータに基づいて、食堂全体の最適な調理すべき数を時々刻々と予測し、無駄な料理を作ることがなくなる、作りすぎによる廃棄を防ぐことができる、タイムリーに料理を提供することができる、作り置きして料理が冷えてしまうことを避けることができる、および／または当該食堂に対する来客の満足度を高めることができる点で有利である。
【0040】
本開示の一実施態様によれば、所属員個々人が大体何時頃食堂に来るのか、過去データから予想することができ、かつ同様に過去の発注履歴からもどのような特徴や種類や属性をもったどのようなメニューを発注する確率が高いかも予測することができる点で有利である。さらに、本開示の一実施態様によれば、箱ひげ分析、ピアソン相関係数の算出を含む機能を用いると、事前に所属員個々人について行う予測の正確性を日々向上させることができうる点で有利である。本開示によれば、例えば外部因子（例えば、気象データ）に応じて、晴れの時は食物Ａを食べる傾向があるが、寒い日には食物Ｂを食べる傾向があるような個々人の過去履歴から、未来に対してこうした外部因子の影響下、実際に発注される料理とその発注時刻をある確率で予測することができるが、その確率の正確性をより一層向上することができる点で有利である。
【0041】
本開示の一実施態様によれば、発注を事前予測していた場合でも、実際に食堂が開店し、多くの来客が訪れ、各々好きなものを注文していく中で、実際の時間軸にそった来客数やメニュー毎の発注量が、事前予測と異なる状態となることは起こり得るが、その場合、事前の予測量と時々刻々と注文受付システム（例えば、食堂レジ）から取り入れられる時々刻々に変化するデータ、すなわち所属員の実際の来客と発注内容という食堂レジから都度取り入れられるデータを、時々刻々と比較することを行うことができる点で有利である。すなわち、本開示によれば、ベイズ統計学の手法に基づく処理を行い、当該時刻以降で起こる事象をベイズ統計学の手法によって改めて推測することができる点で有利である。よって、本開示によれば、食堂開店前に作った発注事前予想に開店時間の最後までずっと固執して、特定のメニューを作り続ける必要はなく、時々刻々と変わるベイズ更新等に基づく新たに補正された発注予測が表示されるディスプレイを料理長が見ながら、時々刻々と動く最終的数量、あるいは途中時間の必要推量に沿ってメニューを適確に用意していくことができる点で有利である。これによって、食堂の閉店時刻における最終的な着地点の発注数とのずれは極小にすることができ、これにより食堂の廃棄物の量を極小、もしくはゼロに近づけることができる点で特に有利である。
【0042】
本開示の一実施態様によれば、長期間観測し記録することで得られる個々人の意識的か無意識かに関わらずいわゆる「習慣」や「嗜好」に関するデータを基に、個々人について日々の来客時間や発注するメニュー等を予測し、かつ食堂レジと連動してリアルタイムで得られるデータを活用することを基本としているので、食堂全体についての予測も従来の予測システムより高い精度で予測できる点で有利である。つまり、多くの食堂運営会社が従来技術を活用しているような予測は、当該の食堂での全体としての来客数やメニューの予測であり、所属員個々人について予測を行う機能はないが、本開示によれば、連動している注文受付システム（例えば、食堂レジ）から、個々人のデータを取り入れることができるため、様々な角度から個々人の習慣のようなデータを生成、演算ないしは記録可能になる点で有利である。
【0043】
本開示の一実施態様によれば、所属員個々人について習慣としてのデータを基に、各々の所属員について極めて高い精度で当該食堂に関する行動について予測できうる点で有利である。本開示の一実施態様によれば、例えば、ある所属員は、１２時１５分前後に食堂に来ることを習慣としていることがわかり、かつこの人が寒い日に温かい麺ものを注文する確率が高いことが、本開示においては従前にわかっているとすると、ある日の天気や曜日などの外部因子とルールを適用することで、その日における各々所属員の当該食堂における喫食行動を予測することができる点で有利である。
【0044】
本開示の一実施態様によれば、各々の所属員の習慣や嗜好も考慮することができる上に、かつそうした所属員が１０時くらいの朝食時に食べるのか、食堂開店直前の１１時半ごろ来店することを習慣としているのか、または１１時４５分くらいに来店することが多いのか、あるいはピークがすぎる１２時半をすぎてから来ることを習慣としている人なのか、週に一回はラーメンを食べる癖（習慣）があるとか、毎日サラダを食べる習慣を持っているとか、炭水化物を多くとる人だとか、肉を食べるか決して魚を食べない人とかそうした嗜好や栄養における偏りも含めて、所属員の習慣として記録されているデータを大いに利用することが可能である点で有利である。また、本開示の一実施態様によれば、会社における様々な集団に応じた行動様式の違いに応じたデータの活用も可能である。すなわち、例えば同じ会社でＰ事業部は会社の規制上１１時半から１２時半まで、Ｑ事業部は１２時１５分から１３時１５分まで、Ｒ事業部は１２時半から１３時半までを、それぞれの事業部の昼食時間として規定いる場合もあり、そうした集団毎の行動様式の違いに応じたデータも活用することが可能になる点で有利である。
【0045】
本開示の一実施態様によれば、当該閉じた場所に所属している所属員全員について上記データがあり、かつ上記予測が可能であるため、その総和として時々刻々の食堂全体における来客、メニュー毎の発注数の予測についても精度を高めて予測できうる点で有利である。つまり、本開示の一実施態様によれば、個々人に注目せずに全体として計算予測しているような既存技術での予測よりもはるかに正確で実態と近い形で予測することができる点で有利である。つまり、本開示の一実施態様によれば、閉じた場所の組織の所属員に注目して、個々の長期間にわたるデータを基に、個々人について異種類のデータ間の相関関係や機械学習等を適用し、こうしたデータ間の関係を割り出すことが可能であるため、個々人についての予測値をさらに実態に近くすることができ、その総和としての食堂全体についての予測値も精度を高めることができる点で特に有利である。
【0046】
本開示の好ましい一実施態様によれば、上記注文量更新演算部は、下記（１）～（３）：
（１）上記ユーザ毎の注文予測モデルを前記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記ユーザ毎の更新後注文予測モデルを演算し、かつ前記ユーザ毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、
（２）上記属性毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記属性毎の更新後注文予測モデルを演算し、かつ上記属性毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、および／または
（３）上記食堂全体の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した前記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、
からなる群より選択される少なくとも２つ（好ましくは、３つ）の演算を実施する。このように、上記注文量更新演算部が２つ（好ましくは３つ）の演算を実施することで、各々について重みづけがなされたうえで、特定日における食堂全体の注文予測モデルが演算される。そのため、個々人に着目してベイズ統計学に基づく手法（例えば、ベイズ推論）により演算した場合と、属性（性別、年齢、所属する組織など）に着目してベイズ統計学に基づく手法により演算した場合と、食堂全体についてベイズ統計学に基づく手法により演算した場合とについて、それらの重みづけを変えていくことによって、食堂にとってより一層利便性のある注文予測モデルを算出可能になる点において特に有利である。
例えば、ある会社においてＰ工場だけが閉鎖になっている場合など、Ｐ工場に所属している社員の属性だけに注目して、当該（β）に対する重みづけを大きくすることで、食堂全体の注文予測モデルを、計算量を少なくして素早く的確に算出可能になりうることや、例えば個人や属性といった範囲をはるかに超えた巨大な天災や災害などが起きた場合、すなわち個人や属性に関係なく食堂全体の営業に極めて大きな影響を及ぼすような事態が起きた時には、（γ）について極めて大きな重みづけをすることが可能であり、これよって計算量を極めて少なくすることができ、食堂全体の注文予測モデルを素早く的確に算出できうる点で特に有利である。
（１）上記ユーザ毎の注文予測モデルを前記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記ユーザ毎の更新後注文予測モデルを演算し、かつ前記ユーザ毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、
（２）上記属性毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記属性毎の更新後注文予測モデルを演算し、かつ上記属性毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、および／または
（３）上記食堂全体の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した前記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、
からなる群より選択される少なくとも２つ（好ましくは、３つ）の演算を実施する。このように、上記注文量更新演算部が２つ（好ましくは３つ）の演算を実施することで、各々について重みづけがなされたうえで、特定日における食堂全体の注文予測モデルが演算される。そのため、個々人に着目してベイズ統計学に基づく手法（例えば、ベイズ推論）により演算した場合と、属性（性別、年齢、所属する組織など）に着目してベイズ統計学に基づく手法により演算した場合と、食堂全体についてベイズ統計学に基づく手法により演算した場合とについて、それらの重みづけを変えていくことによって、食堂にとってより一層利便性のある注文予測モデルを算出可能になる点において特に有利である。
例えば、ある会社においてＰ工場だけが閉鎖になっている場合など、Ｐ工場に所属している社員の属性だけに注目して、当該（β）に対する重みづけを大きくすることで、食堂全体の注文予測モデルを、計算量を少なくして素早く的確に算出可能になりうることや、例えば個人や属性といった範囲をはるかに超えた巨大な天災や災害などが起きた場合、すなわち個人や属性に関係なく食堂全体の営業に極めて大きな影響を及ぼすような事態が起きた時には、（γ）について極めて大きな重みづけをすることが可能であり、これよって計算量を極めて少なくすることができ、食堂全体の注文予測モデルを素早く的確に算出できうる点で特に有利である。
【0047】
本開示の一実施態様によれば、各種データとのピアソン相関係数の値も日々変化させることができる、および／または箱ひげ分析の精度も日々更新することができるため、この更新された新しい精度に基づく関数計算などを行う際の注文パターンモデルについても、機械学習等によって進化させることが可能になりうる点で有利である。また、本開示の一実施態様によれば、このように進化した注文パターンモデルは、例えば注文パターンモデルデータベースに記憶させることが可能な点で有利である。すなわち、本開示の一実施態様によれば、この閉じた食堂での予測精度は、時間がたてばたつほど、学習するデータが増えて進化していく為、予測精度を日々高めることができる点で特に有利である。
【0048】
本開示の一実施態様によれば、注文受付システム（例えば、食堂レジ）と連動している特徴をもっており、食堂レジを「閉じた組織」である会社や大学などの特定の所属員である会社員や学生が日々にこの食堂レジを実際に通過するたびに、当該日に食堂を訪問し実際に発注した時刻と、なにを喫食したのか（なにを発注したのか）に関するデータを日々に都度取り込むことができる機能を有する点で有利である。本開示の一実施態様によれば、その機能によって、食堂開店前に作成した時間毎の発注予測数量と、食堂開店後に食堂レジを通して実際の所属員たち各々の来店時刻（発注時刻）と何を発注したのかというメニュー内容という新たに時々刻々として取り込むデータを基に、ベイズ統計学の手法によって時々刻々と計算される補正値を算出することができる点で有利である。つまり、本開示の一実施態様によれば、「閉じた場所」において多量供給する食堂では、例えば１２時１５分において、当該時刻までに誰と誰が入店し、誰と誰が何を発注したのかというデータを得ることができ、そうした各所属員に関する具体的な時刻とメニュー発注内容のデータから、最終的な１３時半ごろまでの閉店までの各々メニューの総計としての着地点を時々刻々と予測し直すことができる点で有利である。このことにより、従来技術の開店前の予測値を食堂開業中に見直すことができるため、精度の高い予測値を都度出す形となり、したがって無駄な材料を用意する必要もなくなり、廃棄ゼロに近づけることができる点で有利である。
【0049】
以下、図面を参照しつつ、本開示の注文量予測システムの一実施態様について詳細に説明する。なお、本開示の注文量予測システムは、後述する図面の実施態様に限定されるものではない。
【0050】
まず、会社や大学等は、所属している所属員である社員や学生（ユーザ）は多くの場合、ほぼ固定されている。日々、月々、あるいは年々、去る者と新しく入る者がいるが、多くの場合は所属員の大多数は固定されたメンバーとなっているのが通例である。そうした場所はいわゆるユーザが固定されている、もしくは多少の入れ替わりがあるとはいえ、ある期間においては多くのユーザが固定されていると考えられ、その意味で「閉じた組織」であり、その組織にあって一定のユーザが食べることを中心としている食堂は「閉じた組織の食堂」ということができる。本開示の対象は主に、この「閉じた組織」にある「閉じた組織の食堂」を対象としており、いわゆる社員食堂や学生食堂のような場所を想定しているが、こうした食堂では当該組織のユーザが主に昼食時間というような限られた時間で、大勢が集まって喫食することを特徴としており、したがって、「閉じた組織で多量供給される食堂」であり、本開示は主にかかる食堂における注文量予測システムを想定している。
【0051】
いわゆる「閉じた組織」における所属員であるユーザは、「閉じた場所」において、日々主に昼食時などにおいて、昼食をはじめとする喫食を定期的に行う。「閉じた場所」においては、そうした所属員が働いたり学んだりする活動をする場所であるが、その場所においては活動を支援するために食堂があるのが通例であり、その食堂においては、厨房を有しており、調理師が働き、主に所属員が飲食をするために食事を提供しているのが通例である。この食事を提供しているのが、そうした閉じた場所の運営体である会社や大学等の「閉じた組織」との間で例えば業務委託契約を締結した食堂運営業者等である。すなわち、そうした会社や大学を委託者とし、選ばれた食堂運営業者を受託者として、受託者が委託者に対して食事を提供するという業務内容について、実際に当該「閉じた場所における食堂運営」は成り立っている。
【0052】
本開示における「閉じた組織」とは、特定の所属員（すなわちユーザ）が所属している組織を意味する。閉じた組織の典型的な例としては、企業、公的機関、高等学校、大学等が挙げられる。なお、閉じた組織には、会員証等のユーザの属性情報が記憶されたカード等を使用することが一般的な空間（例えば、ショッピングモール等）も包含することが意図される。本開示における「閉じた場所」とは、閉じた組織に所属するユーザが使用する場所を意味する。本開示における「閉じた食堂」とは、ユーザの多数が特定の者である食堂を意味する。閉じた食堂の典型的な例としては、例えば、企業内にある食堂、大学等にある食堂（例えば学生食堂）等が挙げられる。また、「閉じた食堂」には、会員証等のユーザの属性情報が記憶されたカード等を提示してメニューを注文することが通例な飲食店（例えば、ショッピングモール等に入っている飲食店（フードコート等も含む））も含まれるものとする。
【0053】
本開示における「ユーザ」は、「所属員」等と互換可能に使用される。
【0054】
本開示における「属性情報」とは、ユーザの任意の属性情報を意味する。かかる属性情報としては、これらに限定されるものではないが、例えば、性別、年齢、生年月日、出身地、所属組織名（例えば、会社名、学校名）、当該所属組織におけるユーザの識別情報（例えば、社員番号、学生番号等）、職位（例えば、役職名）、部署（例えば、所属する事業部や工場名、学部名等の組織におけるグループ名）、雇用形態（常勤、非常勤等）等が挙げられる。
【0055】
本開示における「属性毎」の注文パターンモデル、「属性毎」の注文予測モデル、「属性毎」の更新後注文予測モデル等は、ある属性毎に生成ないしは演算されたモデルを意味する。「属性毎」における「属性」は、上記属性情報と同義であるものとする。例えば、「属性」が性別の場合には、性別毎（男性、女性）の注文パターンモデル等が生成ないしは演算されてもよいし、「属性」が職位の場合には、職位毎（例えば、一般社員、管理職、役員等）の注文パターンモデル等が生成ないしは演算されてもよいし、「属性」が部署の場合には、部署毎（例えば、Ｐ事業部、Ｑ事業部等の部署等）の注文パターンモデル等が生成ないしは演算されてもよい。
【0056】
［食堂における注文量予測システムの構成］
本開示の注文量予測システムの一例を、図１を用いて説明する。
本開示の注文量予測システムの一例を、図１を用いて説明する。
【0057】
本開示の注文量予測システム１は、過去注文履歴データベース１０１、外部因子データベース１０２、注文パターンモデル生成部１０８、注文量予測演算部１０９および注文量更新演算部１１０を少なくとも備えている。上記注文量予測システム１は、さらに、注文予約データベース１０３、当日注文履歴データベース１０４、注文パターンモデルデータベース１０５、注文予測モデルデータベース１０６、更新後注文予測モデルデータベース１０７、および／または補正パラメータ演算部１１１を備えていてもよい。また、上記注文量予測システム１は、適宜、通信部１１２、入出力インターフェース部１１３等を備えていてもよい。
【0058】
（過去注文履歴データベース）
過去注文履歴データベース１０１は、閉じた組織内に所属するユーザの属性情報と関連づけて、当該組織の食堂における上記ユーザ毎の過去の注文履歴を時系列と関連づけて記憶するデータベースである。
過去注文履歴データベース１０１は、閉じた組織内に所属するユーザの属性情報と関連づけて、当該組織の食堂における上記ユーザ毎の過去の注文履歴を時系列と関連づけて記憶するデータベースである。
【0059】
過去注文履歴データベース１０１は、例えば、後述する図１２に示すデータを記憶していてもよい。図１２に示す例では、ユーザの属性（例えば、性別、年齢、役職、部署等）と、当該ユーザ毎における過去の注文情報（注文日時、注文したメニュー、当該メニューのカロリーや栄養情報等）が記憶されている。過去注文履歴データベース１０１は、「閉じた組織」の方針、考え方、哲学にしたがって、記憶すべき情報を自在に設定してもよい。なお、ユーザの属性に関する情報は、過去注文履歴データベースに記憶されていなくてもよく、他のデータベース等に記憶されていてもよい。その場合には、過去注文履歴データベースに記憶されている過去の注文履歴と、他のデータベース等に記憶されているユーザの属性に関する情報とが、識別コード等で紐付けられていてもよい。
【0060】
（外部因子データベース）
外部因子データベース１０２は、上記注文履歴を除く任意の情報を時系列と関連付けて記憶するデータベースである。外部因子データベースに記憶されている情報としては、例えば、気象情報、災害情報（例えば、地震、台風、河川氾濫、津波等）、経済情報（例えば、為替情報等）、交通情報（例えば、渋滞情報、遅延情報等）、パンデミックに関する情報、危機に関する情報（例えば、テロ、内乱、ミサイル襲撃、戦争等）、労働争議に関する情報（スト等）、国家または自治体イベント情報（例えば、地域のマラソン大会、国際的な競技大会等）、組織（好ましくは、上記閉じた組織）におけるイベント情報（例えば、Ｐ事業部だけの研修や、Ｑ工場の操業停止、新人研修、女性対象の研修、管理職研修、本部長会議、一般職のみ研修、株主総会当日、新入社員初出社日、入学式予定日等）等が挙げられ、これらは単独であってもよいし、２種以上の任意の組合せであってもよい。これら情報は、公開情報であってもよく、任意の頻度で（例えば、１時間毎、１日毎）外部因子データベース１０２に取り込まれるように設定されていてもよい。本開示の一実施態様によれば、上記外部因子データベースは、気象情報および組織におけるイベント情報からなる群より選択される少なくとも１つを記憶する。本開示のより好ましい一実施態様によれば、上記外部因子データベースは、気象情報を記憶する。
外部因子データベース１０２は、上記注文履歴を除く任意の情報を時系列と関連付けて記憶するデータベースである。外部因子データベースに記憶されている情報としては、例えば、気象情報、災害情報（例えば、地震、台風、河川氾濫、津波等）、経済情報（例えば、為替情報等）、交通情報（例えば、渋滞情報、遅延情報等）、パンデミックに関する情報、危機に関する情報（例えば、テロ、内乱、ミサイル襲撃、戦争等）、労働争議に関する情報（スト等）、国家または自治体イベント情報（例えば、地域のマラソン大会、国際的な競技大会等）、組織（好ましくは、上記閉じた組織）におけるイベント情報（例えば、Ｐ事業部だけの研修や、Ｑ工場の操業停止、新人研修、女性対象の研修、管理職研修、本部長会議、一般職のみ研修、株主総会当日、新入社員初出社日、入学式予定日等）等が挙げられ、これらは単独であってもよいし、２種以上の任意の組合せであってもよい。これら情報は、公開情報であってもよく、任意の頻度で（例えば、１時間毎、１日毎）外部因子データベース１０２に取り込まれるように設定されていてもよい。本開示の一実施態様によれば、上記外部因子データベースは、気象情報および組織におけるイベント情報からなる群より選択される少なくとも１つを記憶する。本開示のより好ましい一実施態様によれば、上記外部因子データベースは、気象情報を記憶する。
【0061】
（注文予約データベース）
注文予約データベース１０３は、ユーザ毎の特定日における注文の予約情報を記憶するデータベースである。注文予約データベース１０３は、ユーザの属性情報と特定日における当該ユーザの注文予約情報を紐付けて記憶することができる。注文予約データベース１０３は、例えばユーザが使用するユーザ端末から送信された特定日の注文予約情報を記憶することができる。注文予約データベース１０３は、単一の特定日の注文予約情報を記憶してもよいし、複数の特定日の注文予約情報を記憶してもよい。注文予約データベース１０３は、例えば、図１７に例示される情報を記憶していてもよい。
注文予約データベース１０３は、ユーザ毎の特定日における注文の予約情報を記憶するデータベースである。注文予約データベース１０３は、ユーザの属性情報と特定日における当該ユーザの注文予約情報を紐付けて記憶することができる。注文予約データベース１０３は、例えばユーザが使用するユーザ端末から送信された特定日の注文予約情報を記憶することができる。注文予約データベース１０３は、単一の特定日の注文予約情報を記憶してもよいし、複数の特定日の注文予約情報を記憶してもよい。注文予約データベース１０３は、例えば、図１７に例示される情報を記憶していてもよい。
【0062】
（当日注文履歴データベース）
当日注文履歴データベース１０４は、特定日の当日における実際の注文履歴をユーザの属性情報と紐付けて記憶するデータベースである。注文予約データベース１０４は、例えば、図２２に例示される情報を記憶していてもよい。
当日注文履歴データベース１０４は、特定日の当日における実際の注文履歴をユーザの属性情報と紐付けて記憶するデータベースである。注文予約データベース１０４は、例えば、図２２に例示される情報を記憶していてもよい。
【0063】
（注文パターンモデルデータベース）
注文パターンモデルデータベース１０５は、後述する注文パターンモデル生成部１０８により生成された、時系列に沿ったユーザ毎の注文パターンモデル、時系列に沿った属性毎の注文パターンモデル、および／または時系列に沿った食堂全体の注文パターンモデルを記憶するデータベースである。
注文パターンモデルデータベース１０５は、後述する注文パターンモデル生成部１０８により生成された、時系列に沿ったユーザ毎の注文パターンモデル、時系列に沿った属性毎の注文パターンモデル、および／または時系列に沿った食堂全体の注文パターンモデルを記憶するデータベースである。
【0064】
また、注文パターンモデルデータベース１０５は、後述する補正パラメータ演算部１１１で演算された補正パラメータを記憶していてもよい。
【0065】
（注文予測モデルデータベース）
注文予測モデルデータベース１０６は、後述する注文量予測演算部１０９によって演算された、特定日における時系列に沿ったユーザ毎の注文予測モデル、特定日における時系列に沿った属性毎の注文予測モデル、および／または特定日における時系列に沿った食堂全体の注文予測モデルを記憶するデータベースである。
注文予測モデルデータベース１０６は、後述する注文量予測演算部１０９によって演算された、特定日における時系列に沿ったユーザ毎の注文予測モデル、特定日における時系列に沿った属性毎の注文予測モデル、および／または特定日における時系列に沿った食堂全体の注文予測モデルを記憶するデータベースである。
【0066】
（更新後注文予測モデルデータベース）
更新後注文予測モデル１０７は、後述する注文量更新演算部１１０によって演算された、特定日における時系列に沿ったユーザ毎の更新後注文予測モデル、特定日における時系列に沿った属性毎の更新後注文予測モデル、および／または特定日における時系列に沿った食堂全体の更新後注文予測モデルを記憶するデータベースである。
更新後注文予測モデル１０７は、後述する注文量更新演算部１１０によって演算された、特定日における時系列に沿ったユーザ毎の更新後注文予測モデル、特定日における時系列に沿った属性毎の更新後注文予測モデル、および／または特定日における時系列に沿った食堂全体の更新後注文予測モデルを記憶するデータベースである。
【0067】
（注文パターンモデル生成部）
注文パターンモデル生成部１０８は、過去注文履歴データベース１０１に記憶された情報と外部因子データベース１０２に記憶された情報とに基づき、時系列に沿ったユーザ毎の注文パターンモデル、時系列に沿った属性毎の注文パターンモデル、および／または時系列に沿った食堂全体の注文パターンモデルを生成することができる。
注文パターンモデル生成部１０８は、過去注文履歴データベース１０１に記憶された情報と外部因子データベース１０２に記憶された情報とに基づき、時系列に沿ったユーザ毎の注文パターンモデル、時系列に沿った属性毎の注文パターンモデル、および／または時系列に沿った食堂全体の注文パターンモデルを生成することができる。
【0068】
注文パターンモデル生成部１０８は、例えば回帰分析（例えば、重回帰分析）等により、上記注文パターンモデルを生成することができる。上記注文パターンモデルの生成には、計算ソフトウェア等による計算や、機械学習（例えば、深層学習等）等を使用することができる。
【0069】
（注文量予測演算部）
注文量予測演算部１０９は、ユーザ毎の注文パターンモデルと、特定日のメニューと、外部因子データベース１０２に記憶されている特定日に関連する情報とに基づき、特定日における時系列に沿ったユーザ毎の注文予測モデルを演算することができる。さらに、注文量予測演算部１０９は、ユーザ毎の注文予測モデルの総和に基づき、特定日における時系列に沿った食堂全体の注文予測モデルを演算することができる。
注文量予測演算部１０９は、ユーザ毎の注文パターンモデルと、特定日のメニューと、外部因子データベース１０２に記憶されている特定日に関連する情報とに基づき、特定日における時系列に沿ったユーザ毎の注文予測モデルを演算することができる。さらに、注文量予測演算部１０９は、ユーザ毎の注文予測モデルの総和に基づき、特定日における時系列に沿った食堂全体の注文予測モデルを演算することができる。
【0070】
また、注文量予測演算部１０９は、属性毎の注文パターンモデルと、特定日のメニューと、外部因子データベース１０２に記憶されている特定日に関連する情報とに基づき、特定日における時系列に沿った属性毎の注文予測モデルを演算することができる。さらに、注文量予測演算部１０９は、属性毎の注文予測モデルの総和に基づき、特定日における時系列に沿った食堂全体の注文予測モデルを演算することができる。
【0071】
また、注文量予測演算部１０９は、食堂全体の注文パターンモデルと、特定日のメニューと、外部因子データベース１０２に記憶されている特定日に関連する情報とに基づき、特定日における時系列に沿った食堂全体の注文予測モデルを演算することができる。
【0072】
注文量予測演算部１０９は、必要に応じて、さらに注文予約データベース１０３に記憶されているユーザ毎の注文予約情報に基づき、上記各注文予測モデルを演算してもよい。
【0073】
注文量予測演算部１０９は、必要に応じて、さらに後述する補正パラメータ演算部１１１で演算された補正パラメータに基づき、上記各注文予測モデルを演算してもよい。
【0074】
注文量予測演算部１０９は、例えば、機械学習（例えば、深層学習）等により上記各注文予測モデルを演算することができる。
【0075】
（注文量更新演算部）
注文量更新演算部１１０は、ユーザ毎の注文予測モデルをユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿ったユーザ毎の更新後注文予測モデルを演算することができる。さらに、注文量更新演算部１１０は、ユーザ毎の更新後注文予測モデルに基づき、特定日における時系列に沿った食堂全体の更新後注文予測モデルを演算することができる。
注文量更新演算部１１０は、ユーザ毎の注文予測モデルをユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿ったユーザ毎の更新後注文予測モデルを演算することができる。さらに、注文量更新演算部１１０は、ユーザ毎の更新後注文予測モデルに基づき、特定日における時系列に沿った食堂全体の更新後注文予測モデルを演算することができる。
【0076】
また、注文量更新演算部１１０は、属性毎の注文予測モデルをユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った属性毎の更新後注文予測モデルを演算することができる。さらに、注文量更新演算部１１０は、属性毎の更新後注文予測モデルに基づき、特定日における時系列に沿った食堂全体の更新後注文予測モデルを演算することができる。
【0077】
また、注文量更新演算部１１０は、食堂全体の注文予測モデルをユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した特定日における時系列に沿った食堂全体の更新後注文予測モデルを演算することができる。
【0078】
本開示における「ベイズ統計学の手法」は、ベイズ統計学に基づく手法であれば特段限定されるものではない。ベイズ統計学の手法は、例えば、ベイズ推論；状態空間モデル（例えば、カルマンフィルタ、拡張カルマンフィルタ、非ガウス型フィルタ、粒子フィルタ、ベイズ構造時系列モデル）、時系列リカレントニューラルネットワーク（ＲＮＮ）系モデル（例えば、シンプルＲＮＮ、ＬＳＴＭ、ＧＲＵ、エンコーダデコーダモデル、双方向性再帰型モデル）、ＴＦＴ（Ｔｅｍｐｏｒａｌ Ｆｕｓｉｏｎ Ｔｒａｎｓｆｏｒｍｅｒ）モデル、Ｐｒｏｐｈｅｔモデル、ベイジアン動的線形モデル、Ｂａｓｓモデル、確率的ボラティリティモデル、マルコフ・スイッチングモデル、カオス解析（ロジスティック写像など）等のベイズ統計学に基づく他の時系列予測モデル；等が挙げられる。なお、ベイズ統計学の手法は、現在も世界中で日々研究され、日進月歩して急速なスピードで新たに開発されており、様々なものが日々発表されており、これらも本開示に包含されることが意図される。本開示の一実施態様によれば、ベイズ統計学の手法は、ベイズ推論である。
【0079】
注文量更新演算部１１０は、必要に応じて、さらに外部因子データベース１０２に記憶されている情報、注文パターンモデルデータベース１０５に記憶されている各注文パターンモデルに基づき、各更新後注文予測モデルを演算してもよい。
【0080】
注文量更新演算部１１０は、例えば、機械学習（例えば、深層学習）等により上記各更新後注文予測モデルを演算することができる。
【0081】
（補正パラメータ演算部）
補正パラメータ演算部１１１は、食堂全体の更新後注文予測モデルと、特定日における食堂全体の実際の注文量とに基づき、ユーザ毎の注文パターンモデル、属性毎の注文パターンモデル、および／または食堂全体の注文パターンモデルの補正に使用される補正パラメータを演算することができる。
補正パラメータ演算部１１１は、食堂全体の更新後注文予測モデルと、特定日における食堂全体の実際の注文量とに基づき、ユーザ毎の注文パターンモデル、属性毎の注文パターンモデル、および／または食堂全体の注文パターンモデルの補正に使用される補正パラメータを演算することができる。
【0082】
補正パラメータ演算部１１１は、例えば、機械学習（例えば、深層学習）等により上記補正パラメータを演算することができる。
【0083】
（通信部）
通信部１１２は、通信ネットワークＮＷを介した無線通信および／または有線通信により、データ等を相互に送受信することができる。
通信部１１２は、通信ネットワークＮＷを介した無線通信および／または有線通信により、データ等を相互に送受信することができる。
【0084】
（入出力インターフェース部）
入出力インターフェース部１１３は、内蔵されたおよび／または外部接続された入力部１１４および／または出力１１５に接続されるものであり、入力部１１４および／または出力部１１５の制御を行うことができる（なお、入力部１１４および出力部１１５は、図１では省略されている）。入力部１１４としては、例えば、キーボード、マウス、マイク等が挙げられる。出力部１１５としては、例えば、ディスプレイ、モニター、スピーカー等が挙げられる。
入出力インターフェース部１１３は、内蔵されたおよび／または外部接続された入力部１１４および／または出力１１５に接続されるものであり、入力部１１４および／または出力部１１５の制御を行うことができる（なお、入力部１１４および出力部１１５は、図１では省略されている）。入力部１１４としては、例えば、キーボード、マウス、マイク等が挙げられる。出力部１１５としては、例えば、ディスプレイ、モニター、スピーカー等が挙げられる。
【0085】
（その他）
注文量予測システム１は、必要に応じて、上記した各機能ブロック以外の他の機能ブロックを備えていてもよい。注文量予測システム１は、例えば、特定日のメニューを記憶するデータベース等を備えていてもよい。
注文量予測システム１は、必要に応じて、上記した各機能ブロック以外の他の機能ブロックを備えていてもよい。注文量予測システム１は、例えば、特定日のメニューを記憶するデータベース等を備えていてもよい。
【0086】
なお、図１は、１つの計算装置（コンピュータ）に上記した各機能ブロックが備えられている例を示した。この場合、上記各機能ブロックを備えた１つの計算装置が、本開示の一実施態様における注文量予測システム１を構成してもよい。また、上記した各機能ブロックは、２つ以上の計算装置に分かれて存在していてもよく、これら２つ以上の計算装置は、通信ネットワークＮＷ等を介して相互に通信可能に接続されていてもよい。この場合、上記２つ以上の計算装置が、本開示の一実施態様における注文量予測システム１を構成してもよい。
【0087】
注文量予測システム１は、スタンドアローンであってもよいし、クラウドシステムであってもよい。
【0088】
注文量予測システム１は、通信ネットワークＮＷを介した無線通信および／または有線通信により、注文受付システム２、表示システム３および／またはユーザ端末４とデータ等を相互に送受信できてもよい（図８）。
【0089】
［食堂における注文量予測システムの処理フロー］
上記注文量予測システムの処理フローの一例について、図２を用いて説明する。
上記注文量予測システムの処理フローの一例について、図２を用いて説明する。
【0090】
過去注文履歴データベースに記憶された情報（過去注文履歴）と、外部因子データベースに記憶された情報（外部因子情報）とが、注文パターンモデル生成部に入力される（Ｓ１０１、Ｓ１０２）。なお、図２の例では過去注文履歴に関する情報が入力された後に外部因子データが入力されているが、これらは任意の順番で注文パターンモデル生成部に入力されてもよいし、過去注文履歴に関する情報と外部因子データが同時に注文パターンモデル生成部に入力されてもよい。
【0091】
注文パターンモデル生成部では、時系列に沿ったユーザ毎の注文パターンモデル、時系列に沿った属性毎の注文パターンモデル、および／または時系列に沿った食堂全体の注文パターンモデルが生成される（Ｓ１０３）。
【0092】
注文量予測演算部に、上記で生成された時系列に沿ったユーザ毎の注文パターンモデル、時系列に沿った属性毎の注文パターンモデルおよび／または時系列に沿った食堂全体の注文パターンモデルと、特定日のメニュー情報と、注文予約情報とが入力される（Ｓ１０４、Ｓ１０５）。なお、これら情報の入力は、任意の順番であってもよいし、同時であってもよい。
【0093】
これら入力された情報に基づき、注文量予測演算部は、上記特定日における時系列に沿ったユーザ毎の注文予測モデル、上記特定日における時系列に沿った属性毎の注文予測モデル、および／または上記特定日における時系列に沿った食堂全体の注文予測モデルを演算する（Ｓ１０６）。
【0094】
特定日において、注文量更新演算部には、上記で演算された上記特定日における時系列に沿ったユーザ毎の注文予測モデル、上記特定日における時系列に沿った属性毎の注文予測モデルおよび／または上記特定日における時系列に沿った食堂全体の注文予測モデルと、ユーザ毎の特定日における実際の注文履歴と、必要に応じて上記時系列に沿ったユーザ毎の注文パターンモデル、時系列に沿った属性毎の注文パターンモデルおよび／または時系列に沿った食堂全体の注文パターンモデルが入力される（Ｓ１０７）。注文量更新演算部は、これら入力された情報に基づき、ベイズ統計学の手法により、時系列に沿った上記ユーザ毎の更新後注文予測モデル、時系列に沿った上記属性毎の更新後注文予測モデルおよび／または時系列に沿った上記食堂全体の更新後注文予測モデルを演算する（Ｓ１０８）。
【0095】
必要に応じて、上記食堂全体の更新後注文予測モデルと、特定日における食堂全体の実際の注文量とが補正パラメータ演算部に入力される。補正パラメータ演算部は、入力された情報に基づき、ユーザ毎の注文パターンモデル、属性毎の注文パターンモデルおよび／または食堂全体の注文パターンモデルの補正に使用される補正パラメータを演算してもよい（図示せず）。演算された上記補正パラメータは、例えば、注文パターンモデルデータベースに送信され、記憶されてもよい（図示せず）。
【0096】
（注文パターンモデル生成部の処理フロー）
図３を用いて、注文パターンモデル生成部の処理フローの一例について、より詳細に説明する。
図３を用いて、注文パターンモデル生成部の処理フローの一例について、より詳細に説明する。
【0097】
注文パターンモデル生成部１０８は、過去注文履歴データベースに記憶されている過去注文履歴に関する情報、および外部因子データベースに記憶されている情報（外部因子データ）を入力する（Ｓ２０１、Ｓ２０２）。なお、図３の例では過去注文履歴に関する情報が入力された後に外部因子データが入力されているが、これらは任意の順番で注文パターンモデル生成部１０８に入力されてもよいし、過去注文履歴に関する情報と外部因子データが同時に注文パターンモデル生成部１０８に入力されてもよい。
【0098】
注文パターンモデル生成部１０８は、入力された上記情報に基づき、重回帰分析処理を行い、時系列に沿ったユーザ毎の注文パターンモデル、時系列に沿った属性毎の注文パターンモデル、および／または時系列に沿った食堂全体の注文パターンモデルを生成する（Ｓ２０３、Ｓ２０４）。なお、上記で重回帰分析処理して得られた結果は、必要に応じて、上記注文量予測システムに備えられている任意の記憶部やデータベース等に送信され、記憶されてもよい。また、生成された上記各注文パターンモデルは、必要に応じて、上記注文量予測システムに備えられている注文パターンモデルデータベースに送信され、記憶されてもよい。
【0099】
（注文量予測演算部の処理フロー）
図４を用いて、注文量予測演算部の処理フローの一例について、より詳細に説明する。
図４を用いて、注文量予測演算部の処理フローの一例について、より詳細に説明する。
【0100】
注文量予測演算部１０９は、注文パターンモデル生成部１０８で生成されたかまたは注文パターンモデルデータベースに記憶された上記各注文パターンモデルと、特定日におけるメニューと、必要に応じて注文予約情報と、外部因子情報とを入力する（Ｓ３０１～Ｓ３０４）。なお、図４の例では注文パターンモデルが最初に入力されているが、これらは任意の順番で注文量予測演算部１０９に入力されてもよいし、これらが全て同時に注文量予測演算部１０９に入力されてもよい。
【0101】
注文量予測演算部１０９は、入力された上記情報に基づき、上記特定日における時系列に沿ったユーザ毎の注文予測モデル、上記特定日における時系列に沿った属性毎の注文予測モデル、および／または上記特定日における時系列に沿った食堂全体の注文予測モデルを演算する（Ｓ３０５）。すなわち、注文量予測演算部１０９は、上記特定日における時系列に沿ったユーザ毎の注文予測モデルを演算した場合には、演算されたユーザ毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った食堂全体の注文予測モデルを演算する（Ｓ３０５）。また、注文量予測演算部１０９は、上記特定日における時系列に沿った属性毎の注文予測モデルを演算した場合には、演算された属性毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った食堂全体の注文予測モデルを演算する（Ｓ３０５）。演算された上記各注文予測モデルは、必要に応じて、上記注文量予測システムに備えられている注文予測モデルデータベースに送信され、記憶されてもよい。
【0102】
注文量予測演算部１０９は、特定日が到来するまで、必要に応じて、任意の頻度で、上記各注文予測モデルの演算を繰り返し実施してもよい。
【0103】
（注文量更新演算部の処理フロー）
図５を用いて、注文量更新演算部の処理フローの一例について、より詳細に説明する。
図５を用いて、注文量更新演算部の処理フローの一例について、より詳細に説明する。
【0104】
注文量更新演算部１１０は、上記で演算された上記各注文予測モデルと、特定日の当日におけるユーザ毎の実際の注文履歴と、必要に応じて上記各注文パターンモデルを入力する（Ｓ４０１～Ｓ４０３）。なお、図５の例では当日の注文履歴の後に注文パターンモデルが入力されているが、これらは任意の順番で注文量更新演算部１１０に入力されてもよいし、これらが全て同時に注文量更新演算部１１０に入力されてもよい。
【0105】
注文量更新演算部１１０は、入力された情報に基づき、ベイズ統計学の手法により、時系列に沿った上記ユーザ毎の更新後注文予測モデル、時系列に沿った上記属性毎の更新後注文予測モデルおよび／または時系列に沿った上記食堂全体の更新後注文予測モデルを演算する（Ｓ４０４）。すなわち、注文量更新演算部１１０は、上記ユーザ毎の注文予測モデルが入力された場合には、上記ユーザ毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記ユーザ毎の更新後注文予測モデルを演算し、かつ上記ユーザ毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する（Ｓ４０４）。また、注文量更新演算部１１０は、上記属性毎の注文予測モデルが入力された場合には、上記属性毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記属性毎の更新後注文予測モデルを演算し、かつ上記属性毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する（Ｓ４０４）。また、注文量更新演算部１１０は、上記食堂全体の注文予測モデルが入力された場合には、上記食堂全体の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する（Ｓ４０４）。
【0106】
特定日においてはユーザが食堂で注文するたびに当日の注文履歴が刻々と更新されていくため、注文量更新演算部１１０は、任意の頻度で上記各更新後注文予測モデルを演算することができる。演算された上記各更新後注文予測モデルは、必要に応じて、上記注文量予測システムに備えられている更新後注文予測モデルデータベースに送信され、記憶されてもよい。
【0107】
（補正パラメータ演算部の処理フロー）
図６を用いて、補正パラメータ演算部の処理フローの一例について、より詳細に説明する。
図６を用いて、補正パラメータ演算部の処理フローの一例について、より詳細に説明する。
【0108】
補正パラメータ演算部１１０は、任意のタイミングで（例えば特定日における食堂の営業終了後）、特定日の更新後注文予測モデル（好ましくは、特定日の最新の更新後注文予測モデル）と、特定日のユーザ毎の当日の実際の注文履歴（好ましくは、食堂全体の特定日のユーザ毎の当日の実際の注文履歴）とを入力する（Ｓ５０１～Ｓ５０２）。なお、図６の例では上記更新ご注文予測モデルの後に上記注文履歴が入力されているが、これらは任意の順番で補正パラメータ演算部１１０に入力されてもよいし、これらが全て同時に補正パラメータ演算部１１０に入力されてもよい。
【0109】
補正パラメータ演算部１１０は、入力された情報に基づき、例えば機械学習（深層学習等）により、上記補正パラメータを演算することができる。演算された上記補正パラメータは、必要に応じて、上記注文量予測システムに備えられている任意の記憶部やデータベース（例えば、注文パターンモデルデータベース）に送信され、記憶されてもよい。
【0110】
［食堂注文システム］
本開示の一実施態様によれば、上記注文量予測システムと、
上記ユーザ毎の特定日における実際の注文履歴を上記注文量予測システムに送信する注文受付システムと、
上記食堂全体の注文予測モデルおよび／または上記食堂全体の更新後注文予測モデルを表示する表示システムと
を備える、食堂注文システムが提供される。
本開示の一実施態様によれば、上記注文量予測システムと、
上記ユーザ毎の特定日における実際の注文履歴を上記注文量予測システムに送信する注文受付システムと、
上記食堂全体の注文予測モデルおよび／または上記食堂全体の更新後注文予測モデルを表示する表示システムと
を備える、食堂注文システムが提供される。
【0111】
食堂注文システムの一例の概略を、図８を用いて説明する。食堂注文システム１１は、通信ネットワークＮＷを介した無線通信および／または有線通信により、注文量予測システム１、注文受付システム２、表示システム３および／またはユーザ端末４とデータ等を相互に送受信できてもよい。
【0112】
上記食堂注文システムは、スタンドアローンであってもよいし、クラウドシステムであってもよい。
【0113】
（注文受付システム）
注文受付システムの機能ブロックの一例について、図９を用いて説明する。注文受付システム２は、処理部２０１、決済部２０２、ユーザ情報識別部２０３、注文受付部２０４、表示部２０５、記憶部２０６、通信部２０７および／または入出力インターフェース部２０８を備えていてもよい。注文受付システム２は、必要に応じて、他の機能ブロックを備えていてもよい。
注文受付システムの機能ブロックの一例について、図９を用いて説明する。注文受付システム２は、処理部２０１、決済部２０２、ユーザ情報識別部２０３、注文受付部２０４、表示部２０５、記憶部２０６、通信部２０７および／または入出力インターフェース部２０８を備えていてもよい。注文受付システム２は、必要に応じて、他の機能ブロックを備えていてもよい。
【0114】
処理部２０１は、各種処理や演算等を行うことができる。
【0115】
決済部２０２は、決済が可能な構成である限り特段限定されるものではない。例えば、現金決済、クレジットカード決済、２次元コード決済が可能な公知の構成であってもよい。また、社員証や学生証や会員証等により決済が可能な構成であってもよい。
【0116】
ユーザ情報識別部２０３は、注文を実施したユーザ情報を識別することができる。例えば、ユーザやスタッフ等によって入力された識別番号（例えば、社員番号、学生番号等）によりユーザ情報を識別してもよいし、連動する任意の読み取り機（例えば、２次元コードリーダ、カメラ等）に読み込まれた情報によりユーザ情報を識別してもよい。例えば、社員証や学生証を上記読み取り機により読み込む方法が挙げられる。
【0117】
注文受付部２０４は、ユーザが注文した内容を受け付けることができる。スタッフが注文されたメニューを個別に手入力することもできるし、献立表等に貼付されたコード（例えば、バーコードや２次元コード等）をバーコードリーダやカメラで読み取って入力することもできる。なお、料理の皿や他の入れ物などにコードが貼付されうる。また、コードを読み取って注文内容を入力する場合、スタッフを配置せずに、注文者であるユーザ自身が、献立表等のコードを、バーコードリーダやカメラで読み取らせるようにしてもよい。
【0118】
表示部２０５は、例えば、ディスプレイ、モニター、スピーカー等であってもよい。
【0119】
記憶部２０６は、各種情報やデータを記憶することができる。
【0120】
通信部２０７は、通信ネットワークＮＷを介した無線通信および／または有線通信により、データ等を相互に送受信することができる。
【0121】
入出力インターフェース部２０８は、内蔵されたおよび／または外部接続された入力部２０９および／または出力２１０に接続されるものであり、入力部２０９および／または出力部２１０の制御を行うことができる（なお、入力部２０９および出力部２１０は、図９では省略されている）。入力部２０９としては、例えば、キーボード、マウス、マイク等が挙げられる。出力部２１０としては、例えば、ディスプレイ、モニター、スピーカー等が挙げられる。
【0122】
注文受付システム２の各機能ブロックは、１つの装置内に備えられていてもよいし、１以上の任意の機能ブロックが２以上の装置に備えられていてもよい。
【0123】
本開示の一実施態様によれば、上記注文受付システムは、食堂レジシステム（好ましくは食堂ＰＯＳレジシステム）である。
【0124】
上記注文受付システムは、スタンドアローンであってもよいし、クラウドシステムであってもよい。
【0125】
（表示システム）
表示システムの機能ブロックの一例について、図１０を用いて説明する。表示システム３は、処理部３０１、表示部３０２、記憶部３０３、通信部３０４および／または入出力インターフェース部３０５を備えていてもよい。表示システム３は、必要に応じて、他の機能ブロックを備えていてもよい。
表示システムの機能ブロックの一例について、図１０を用いて説明する。表示システム３は、処理部３０１、表示部３０２、記憶部３０３、通信部３０４および／または入出力インターフェース部３０５を備えていてもよい。表示システム３は、必要に応じて、他の機能ブロックを備えていてもよい。
【0126】
処理部３０１は、各種処理や演算等を行うことができる。
【0127】
表示部３０２は、例えば、ディスプレイ、モニター、スピーカー等であってもよい。
【0128】
記憶部３０３は、各種情報やデータを記憶することができる。
【0129】
通信部３０４は、通信ネットワークＮＷを介した無線通信および／または有線通信により、データ等を相互に送受信することができる。
【0130】
入出力インターフェース部３０５は、内蔵されたおよび／または外部接続された入力部３０６および／または出力３０７に接続されるものであり、入力部３０６および／または出力部３０７の制御を行うことができる（なお、入力部３０６および出力部３０７は、図１０では省略されている）。入力部３０６としては、例えば、キーボード、マウス、マイク等が挙げられる。出力部３０７としては、例えば、ディスプレイ、モニター、スピーカー等が挙げられる。
【0131】
上記注文受付システムは、スタンドアローンであってもよいし、クラウドシステムであってもよい。
【0132】
（ユーザ端末）
ユーザ端末は、特段限定されるものではなく、スマートフォン、パソコン、タブレット等であってもよい。
ユーザ端末は、特段限定されるものではなく、スマートフォン、パソコン、タブレット等であってもよい。
【0133】
［食堂における注文量を予測する方法］
本開示の別の実施態様によれば、食堂における注文量を予測する方法であって、
過去注文履歴データベースに記憶された情報と外部因子データベースに記憶された情報とに基づき、時系列に沿ったユーザ毎の注文パターンモデルおよび／または時系列に沿った属性毎の注文パターンモデルを生成するステップと、
上記ユーザ毎の注文パターンモデルおよび／または上記属性毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記ユーザ毎の注文予測モデルおよび／または上記特定日における時系列に沿った上記属性毎の注文予測モデルを演算するステップと、
上記ユーザ毎の注文予測モデルおよび／または上記属性毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算するステップと、
上記ユーザ毎の注文予測モデルおよび／または上記属性毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記ユーザ毎の更新後注文予測モデルおよび／または時系列に沿った上記属性毎の更新後注文予測モデルを演算するステップと、
上記ユーザ毎の更新後注文予測モデルおよび／または上記属性毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算するステップと、
を含み、
上記過去注文履歴データベースは、上記ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶する、方法が提供される。
本開示の別の実施態様によれば、食堂における注文量を予測する方法であって、
過去注文履歴データベースに記憶された情報と外部因子データベースに記憶された情報とに基づき、時系列に沿ったユーザ毎の注文パターンモデルおよび／または時系列に沿った属性毎の注文パターンモデルを生成するステップと、
上記ユーザ毎の注文パターンモデルおよび／または上記属性毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記ユーザ毎の注文予測モデルおよび／または上記特定日における時系列に沿った上記属性毎の注文予測モデルを演算するステップと、
上記ユーザ毎の注文予測モデルおよび／または上記属性毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算するステップと、
上記ユーザ毎の注文予測モデルおよび／または上記属性毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記ユーザ毎の更新後注文予測モデルおよび／または時系列に沿った上記属性毎の更新後注文予測モデルを演算するステップと、
上記ユーザ毎の更新後注文予測モデルおよび／または上記属性毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算するステップと、
を含み、
上記過去注文履歴データベースは、上記ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶する、方法が提供される。
【0134】
本開示の別の実施態様によれば、食堂における注文量を予測する方法であって、
過去注文履歴データベースに記憶された情報と外部因子データベースに記憶された情報とに基づき、時系列に沿ったユーザ毎の注文パターンモデルおよび／または時系列に沿った属性毎の注文パターンモデルを生成するステップと、
上記ユーザ毎の注文パターンモデルおよび／または上記属性毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記ユーザ毎の注文予測モデルおよび／または上記特定日における時系列に沿った上記属性毎の注文予測モデルを演算するステップと、
上記ユーザ毎の注文予測モデルおよび／または上記属性毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算するステップと、
上記食堂全体の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算するステップと、
を含み、
上記過去注文履歴データベースは、上記ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶する、方法が提供される。
過去注文履歴データベースに記憶された情報と外部因子データベースに記憶された情報とに基づき、時系列に沿ったユーザ毎の注文パターンモデルおよび／または時系列に沿った属性毎の注文パターンモデルを生成するステップと、
上記ユーザ毎の注文パターンモデルおよび／または上記属性毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記ユーザ毎の注文予測モデルおよび／または上記特定日における時系列に沿った上記属性毎の注文予測モデルを演算するステップと、
上記ユーザ毎の注文予測モデルおよび／または上記属性毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算するステップと、
上記食堂全体の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算するステップと、
を含み、
上記過去注文履歴データベースは、上記ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶する、方法が提供される。
【0135】
本開示の別の実施態様によれば、食堂における注文量を予測する方法であって、
過去注文履歴データベースに記憶された情報と外部因子データベースに記憶された情報とに基づき、時系列に沿った食堂全体の注文パターンモデルを生成するステップと、
上記食堂全体の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った食堂全体の注文予測モデルを演算するステップと、
上記食堂全体の注文予測モデルをユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算するステップと、
を含み、
上記過去注文履歴データベースは、上記ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶する、方法が提供される。
過去注文履歴データベースに記憶された情報と外部因子データベースに記憶された情報とに基づき、時系列に沿った食堂全体の注文パターンモデルを生成するステップと、
上記食堂全体の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った食堂全体の注文予測モデルを演算するステップと、
上記食堂全体の注文予測モデルをユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算するステップと、
を含み、
上記過去注文履歴データベースは、上記ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶する、方法が提供される。
【0136】
本開示の別の好ましい実施態様によれば、上記方法は、上記食堂全体の更新後注文予測モデルと、上記特定日における上記食堂全体の実際の注文量とに基づき、上記ユーザ毎の注文パターンモデル、上記属性毎の注文パターンモデル、および／または上記食堂全体の注文パターンモデルの補正に使用される補正パラメータを演算するステップ
をさらに含む。
をさらに含む。
【0137】
［食堂における注文量を予測するプログラム等］
本開示の別の実施態様によれば、上記方法を計算装置に実行させるためのプログラムが提供される。
本開示の別の実施態様によれば、上記方法を計算装置に実行させるためのプログラムが提供される。
【0138】
本開示の別の実施態様によれば、上記プログラムを記録した計算装置に読み取り可能な記録媒体が提供される。
【0139】
本開示の別の実施態様によれば、上記プログラムを内部記憶部に記録した計算装置が提供される。
【0140】
【0141】
注文量予測システム１Ａは、ネットワークＮＷ（図示せず）を介して、注文受付システム２Ａ、表示システム３Ａ、およびユーザＡが使用するユーザ端末４Ａ（図示せず）とデータ等を相互に送受信可能となっている。
【0142】
過去注文履歴データベース１０１Ａは、各ユーザが当該食堂で一体どのような行動をとったかを詳細に記憶したユーザ毎の当該食堂における過去の注文履歴を記憶している。過去注文履歴データベース１０１Ａは、当該注文履歴を、例えば、各ユーザが何時何分に注文を行ったか、何を注文したかという情報を連動している注文受付システム２Ａから入手して、それをユーザ毎の属性（例えば、性別、年齢、所属部署、職位等）と関連付けて記憶してもよい。つまり、過去注文履歴データベース１０１Ａには、全てのユーザが一定期間（例えば、１週間分、１箇月分、１年分またはそれ以上の期間）、当該食堂でどのような予約、注文を行い、どのような喫食行動を、どのような時刻に行ったか、という情報を時系列に沿って記憶することができる。過去注文履歴データベース１０１Ａは、例えば、図１２に例示する情報を記憶している。
【0143】
外部因子データベース１０２Ａは、気象庁などの気象情報保有機関から、気象情報等の外部因子情報を時系列に関連づけて入力し、記憶している。外部因子情報の入力は、任意の頻度であってもよい。
【0144】
注文パターンモデル生成部１０８Ａは、過去注文履歴データベース１０１Ａに記憶されているユーザ毎の時系列に沿った過去の注文履歴と、外部因子データベース１０２Ａに記憶されている時系列に沿った気象情報等の外部因子情報とに基づき重回帰分析を行い、時系列に沿ったユーザ毎の注文パターンモデル、時系列に沿った属性毎（例えば、男女別、年齢層別、所属部署別、職位別）の注文パターンモデル、および／または当該食堂全体の注文パターンモデルを生成する（Ｓ６０１～Ｓ６０３）。重回帰分析は、表計算ソフトウェア等による計算であってもよいし、機械学習（例えば、深層学習等）であってもよい。重回帰分析としては、例えば、箱ひげ分析、ピアソン相関関係分析等を行う。かかる重回帰分析結果は、注文量予約システム１Ａに備えられている任意のデータベースや記憶部等に記憶されていてもよい。
【0145】
注文パターンモデル生成部１０８Ａの重回帰分析結果の一例を図１３および１４に示す。図１３では、日替わり味噌汁は、１２時１０分頃によく売れている一方、かけうどん・そばは１２時４０分頃によく売れていることが分かる。また、図１３では、中華そばは、昼時であれば１２時４０分頃によく売れており、朝時であれば１０時１０分頃によく売れていることが分かる。このように、箱ひげ分析を通して、特定メニューの時間軸での売れ具合と、通常の営業時間におけるメニュー毎の発注量とを読み取ることが可能となる。
【0146】
天気、温度、湿度等の気象に係る情報を気象庁など外部機関から入手し、そうした外部因子情報とメニュー毎の注文量との関係を「ピアソン相関関係分析」により解析した一例を図１４に示す。図１４では、メニュー毎の注文量と天気等の気象に関する情報との相関関係を計算している。０は全く関係が見られない、１に近い正の値である場合は正の相関関係がある可能性が高い、１に近い負の値である場合は負の相関関係がある可能性が高い、と評価することができる。こうした組合せを種々解析することで、様々な外部因子とメニュー毎の注文量との関係を評価することができる。
【0147】
注文パターンモデル生成部１０８Ａにより生成されたユーザ毎の注文パターンモデルの一例を図１５および１６に示す。図１５の例は、管理職であるＡ氏の注文パターンモデルである。Ａ氏は、天気が良い日には１１時４５分頃に食堂に来て定食を注文する傾向があるが、天気が悪い日には遅めに来て（例えば１３時１５分頃）ラーメンやそば等の麺類を注文する傾向がある、ということが確率分布モデルとして算出されている。一方、図１６の例は、ＯＬであるＢ氏の注文パターンモデルである。Ｂ氏は、通常は１２時１５分頃に食堂に来てパスタを注文する傾向があり、遅めに食堂に来る場合（例えば１２時４５分頃）にはサラダを注文する傾向がある、ということが確率分布モデルとして算出されている。生成された注文パターンモデルは、注文パターンモデルデータベース１０５Ａに送信され、記憶される（Ｓ６０９）。
【0148】
過去注文履歴データベース１０１Ａには、特定日Ｘ以後の注文履歴も随時記憶される。また、外部因子データベース１０２Ａには、外部因子情報が随時記憶される。そのため、注文パターンモデル生成部１０８Ａは、これらデータベースから任意のタイミングでデータを取り出すとともに、注文パターンモデルデータベース１０５Ａに記憶されている注文パターンモデル（ユーザ毎、属性毎、および／または食堂全体）を取り出し、再度注文パターンモデルを生成してもよく、これを都度繰り返すことができる。そうすることにより、上記ユーザ毎の注文パターンモデル、上記属性毎の注文パターンモデルおよび／または上記食堂全体の注文パターンモデルの精度がより高まる。
【0149】
ユーザＡは、自らの端末（例えば、スマートフォン）やその他ＰＣなどのＩＴツールを使用し、食堂運営業者がＷＥＢ上で公開しているホームページに提示されているメニュー（献立）を日々見ることによって、特定日Ｘにおけるメニューを事前に予約することができる。ユーザＡの予約情報は、注文予約データベース１０３Ａに送信され、記憶される（Ｓ５０５）。注文予約データベース１０３Ａに記憶されている情報の一例を図１７に示す。
【0150】
注文予約データベース１０３Ａに記憶されている特定日Ｘにおけるユーザ毎の注文予約情報と、注文パターンモデルデータベース１０５Ａに記憶されているユーザ毎の注文パターンモデル、属性毎の注文パターンモデルおよび／または食堂全体の注文パターンモデルと、外部因子データベースに記憶されている特定日Ｘに関連する気象情報等（この場合、特定日Ｘにおける天気予報等）の外部因子情報とが注文量予測演算部１０９Ａに送信される（Ｓ６０６～Ｓ６０８）。注文量予測演算部１０９Ａは、これら送信された情報と特定日Ｘのメニューとに基づき、機械学習（例えば、深層学習）によりユーザ毎の特定日Ｘにおける注文予測モデルを演算する（Ｓ６０９）。かかる演算は、重回帰分析であってもよい。特定日Ｘのメニューは、都度入力して注文量予測システム１Ａの注文量予測演算部１０９Ａに送信してもよいし、注文量予測システム１Ａに備えられている任意のデータベースもしくは記憶部、または注文量予測システム１Ａには備えられていない外部データベース等に記憶され、注文量予測演算部１０９Ａに送信してもよい（図示せず）。演算されたユーザ毎の特定日Ｘにおける注文予測モデル、属性毎の特定日Ｘにおける注文予測モデルおよび／または食堂全体の特定日Ｘにおける注文予測モデルは、注文予測モデルデータベース１０６Ａに送信され、記憶される。注文量予測演算部１０９Ａは、任意のタイミングで（例えば、特定日Ｘの１日前、１週間前等）上記注文予測モデルを生成するように予め設定されていてもよい。注文量予測演算部１０９Ａは、複数の特定日（例えば、２日分、１週間分、１箇月分、３箇月分またはそれ以上）毎に上記注文予測モデルを演算してもよい。
【0151】
注文量予測演算部１０９Ａにより生成された注文予測モデルの一例（ユーザ毎の特定日Ｘにおける注文予測モデル）を図１８および１９に示す。例えば、上記Ａ氏の場合、注文量予測演算部１０９Ａは、特定日Ｘが管理職として本部長会議に出席する可能性が高いことから昼食を１３：３０頃に食べにくる確率が相当に高く、かつそばのように軽く食べられるものを注文する確率が高いと予想し、Ａ氏の特定日Ｘの事前分布として図１８の注文予測モデル（確率分布モデル）を演算する。一方、上記Ｂ氏の場合、注文量予測演算部１０９Ａは、Ｂ氏において特定日Ｘに特別な会議等が入っていないため、通常どおり１２時３０分頃に来る可能性が高いと予想し、Ｂ氏の特定日Ｘの事前分布として図１９の注文予測モデル（確率分布モデル）を演算する。
【0152】
注文量予測演算部１０９Ａは、演算されたユーザ毎の特定日Ｘにおける注文予測モデル、および／または属性毎の特定日Ｘにおける注文予測モデルに基づき、特定日Ｘにおける食堂全体の注文予測モデルを演算してもよい（Ｓ６０９）。すなわち、注文量予測演算部１０９Ａは、組織内に所属するユーザすべての特定日Ｘにおける注文予測モデルの総和および／または組織内に所属するユーザの属性毎の特定日Ｘにおける注文予測モデルの総和に基づいて、特定日Ｘにおける食堂全体の注文予測モデルを演算することができる。かかる演算は、表計算ソフトウェアや機械学習等で実施されてもよい。演算された特定日Ｘにおける食堂全体の注文予測モデルの一例を図２０に示す。演算された特定日Ｘにおける食堂全体の注文予測モデルは、注文予測モデルデータベース１０６Ａに送信され、記憶される（Ｓ６１０）。
【0153】
なお、ユーザ毎の特定日Ｘにおける注文予測モデルの総和に基づき演算された食堂全体の注文予測モデル（α）、属性毎の特定日Ｘにおける注文予測モデルの総和に基づき演算された食堂全体の注文予測モデル（β）、および食堂全体の注文パターンモデルに基づき演算された特定日Ｘにおける食堂全体の注文予測モデル（γ）のうちの２つ以上が存在する場合、各々について重みづけがなされたうえで、特定日Ｘにおける食堂全体の注文予測モデルが演算されてもよい。かかる重みづけを含めた演算も、注文量予測演算部１０９Ａで実施（例えば、深層学習等の機械学習により実施）されてもよい。重みづけに用いられるパラメータ等は、例えば、外部因子データベース１０２Ａに記憶されている特定日Ｘの外部因子情報と、各演算方法により演算された特定日Ｘにおける食堂全体の注文予測モデル（α、β、γ）と、特定日Ｘにおける食堂全体の実際の注文量とに基づいて機械学習（例えば、深層学習）することにより算出されてもよい。なお、上記重みづけに用いられるパラメータ等は、後述する補正パラメータ演算部１１１Ａで実施されてもよい。あるいは、上記重みづけに用いられるパラメータ等は、例えば食堂運営会社Ｃの過去の知見や経験に基づいて予め設定されていてもよい。
【0154】
特定日Ｘを迎えるまでの間、注文予約データベース１０３Ａ、外部因子データベース１０２Ａ等に記憶されている情報は随時更新されるため、注文量予測演算部１０９Ａは、任意のタイミングで（例えば、特定日Ｘを迎えるまで毎日特定の時刻で）特定日Ｘにおけるユーザ毎の注文予測モデル、特定日Ｘにおける属性毎の注文予測モデル、および／または特定日Ｘにおける食堂全体の注文予測モデルを演算してもよい。このようにして再度演算された各注文予測モデルは、注文予測モデルデータベース１０６Ａに送信され、記憶されてもよい。例えば、特定日Ｘの１週間前、特定日Ｘが晴天の予報であり、かかる情報に基づき特定日Ｘにおける各注文予測モデルが注文量予測演算部１０９Ａで演算され、注文予測モデルデータベース１０６Ａに記憶されていた。しかし、特定日Ｘの２日前、特定日Ｘが大雨の予報となり、かかる情報に基づき特定日Ｘにおける各注文予測モデルが注文量予測演算部１０９Ａで再度演算され、注文予測モデルデータベース１０６Ａに記憶されてもよい（図２１）。
【0155】
特定日Ｘの当日、注文予測モデルデータベース１０６Ａに記憶されている特定日Ｘの最新の食堂全体の注文予測モデルが、表示システム３Ａに送信され、表示されている（Ｓ６１１）。食堂運営会社Ｃのシェフ（例えば、料理長）は、特定日Ｘの開店時間前に、表示システム３Ａに表示されている注文予測モデルに基づき、食事の準備を進める。
【0156】
特定日Ｘの当日、ユーザＡは、例えば食堂に設置されている注文受付システム２Ａにて、予約済みのメニューを実際に注文することができる（Ｓ６１２）。一方、予約をしていないユーザＢは、特定日Ｘの当日に、当日のメニューを参照し（例えば、食堂のディスプレイや掲示板、場合によってはメニューの現物や模型などで提示されているメニュー表（献立表）を参照し）、注文受付システム２Ａを操作することで注文するメニューを選択することができる（Ｓ６１３）。ユーザＢは、ユーザＡとは異なり、食堂を訪問する前に特に予約などの行為を行っていない者であり、例えば昼食時間になって、ぶらりと食堂を訪問するようなユーザを想定している。ユーザＢは、食堂を訪問し、自分の食べたいメニューを選んだ後、決済をする必要があり、決済時に自らの端末（例えばスマートフォン）で注文受付システム２Ａに付属されている、あるいは内包されているカードリーダーにかざすことによって、決済を行うことができる。当該端末を用いない決済であってもよく、例えばＩＣカード（例えば、社員証等）を決済に用いてもよい。図１１では注文受付システム２Ａを一つのシステムとして図示しているが、注文受付システム２Ａは、例えば大きなディスプレイとレジシステムの組合せや、ディスプレイとカードリーダーやＰＣとの組み合わせなど複数のＩＴ機器により構成されていてもよい。なお、図１１における注文受付システム２Ａは、メニューの注文だけでなく、当該メニューについての支払いも併せて可能な食堂レジ決済システムであってもよい。
【0157】
この決済されたデータ、すなわち、ユーザＡおよびユーザＢそれぞれの属性、何時何分に、どのメニューをいくつ注文したかを含む特定日Ｘ当日における実際の注文履歴が、注文受付システム２Ａから注文量予約システム１Ａに送信され、当日注文履歴データベース１０４Ａに記憶される（Ｓ６１４）。このデータは、注文受付システム２Ａから過去注文履歴データベース１０１Ａに送信されて、記憶されてもよい（図示せず）。あるいは、当該データは、当日注文履歴データベース１０４Ａから、任意のタイミングで（例えば、特定日Ｘにおける営業時間終了後に）過去注文履歴データベース１０１Ａに送信され、記憶されてもよい（図示せず）。当日注文履歴データベース１０４Ａに記憶されている情報の一例を図２２に示す。
【0158】
当該実際の注文履歴（当日注文履歴）は、任意の頻度で（例えば任意の時刻で）、当日注文履歴データベース１０４Ａおよび／または過去注文履歴データベース１０１Ａに送信されてよく、注文量予測システム１Ａおよび／または注文受付システム２Ａの連携により適宜設定することができる。当該実際の注文履歴は、リアルタイムに近い時間に送信されることが好ましい。
【0159】
当日注文履歴データベース１０４Ａに記憶された当日注文履歴は、任意のタイミングで（例えば、１分毎、５分毎、１０毎、３０分毎）注文量更新演算部１１０Ａに送信される（Ｓ６１５）。また、注文予測モデルデータベース１０６Ａに記憶されている特定日Ｘの最新のユーザ毎、属性毎および／または食堂全体の注文予測モデルが、注文量更新演算部１１０Ａに送信される（Ｓ６１６）。当該注文予測モデルの送信頻度は、例えば、当日注文履歴の送信頻度と同じであってもよい。注文量更新演算部１１０Ａは、送信された注文予測モデル（事前分布）と送信された当日注文履歴とに基づき、ベイズ推論により更新したユーザ毎の更新後注文予測モデル（すなわち、事後分布）を演算する（Ｓ６１７）。注文量更新演算部１１０Ａは、必要に応じて、注文パターンモデルデータベース１０５Ａに記憶されているユーザ毎の注文パターンモデル、属性毎の注文パターンモデルおよび／または食堂全体の注文パターンモデルを参照しつつ（例えば、これらを尤度関数として用いて）、ベイズ推論により更新後注文予測モデルを演算してもよい。すなわち、注文量更新演算部１１０Ａは、注文予測モデルを事前分布として、当日注文履歴および必要に応じて注文パターンモデルによりベイズ更新を行い、事後分布として更新後注文予測モデルを演算することができる。かかる演算は、機械学習（例えば、深層学習）によって実施されてもよい。
【0160】
注文量更新演算部１１０Ａは、更新されたユーザ毎の更新後注文予測モデルに基づき、特定日Ｘにおける食堂全体の更新後注文予測モデルを演算することができる（Ｓ６１７）。例えば、注文量更新演算部１１０Ａは、演算を実施する前までに既に注文を終えたユーザ群については更新後注文予測モデルを、未だ食堂で注文をしていないユーザ群については注文予測モデルを適用し、これらの総和に基づいて、特定日Ｘ当日における食堂全体の更新後注文予測モデルを演算することができる。かかる演算は、表計算ソフトウェアや機械学習等で実施されてもよい。
【0161】
また、注文量更新演算部１１０Ａは、更新された属性毎の更新後注文予測モデルに基づき、特定日Ｘにおける食堂全体の更新後注文予測モデルを演算することができる（Ｓ６１７）。例えば、注文量更新演算部１１０Ａは、特定日Ｘにおける属性毎の注文予測モデルを事前分布とし、当日注文履歴データベース１０４Ａから送信された当日注文履歴に基づき、ベイズ推論により特定日Ｘ当日における属性毎の更新後注文予測モデルを演算し、演算された属性毎の更新後注文予測モデルに基づき、食堂全体の更新後注文予測モデルを演算することができる。かかる演算は、表計算ソフトウェアや機械学習等で実施されてもよい。
【0162】
また、注文量更新演算部１１０Ａは、特定日Ｘにおける食堂全体の注文予測モデルに基づき、特定日Ｘにおける食堂全体の更新後注文予測モデルを演算してもよい（Ｓ６１７）。例えば、注文量更新演算部１１０Ａは、特定日Ｘにおける食堂全体の注文予測モデルを事前分布とし、当日注文履歴データベース１０４Ａから送信された当日注文履歴に基づき、ベイズ推論により特定日Ｘ当日における食堂全体の更新後注文予測モデルを演算することができる。かかる演算は、機械学習等で実施されてもよい。演算された特定日Ｘ当日における食堂全体の更新後注文予測モデルの一例を図２３に示す。
【0163】
演算された特定日Ｘ当日におけるユーザ毎、属性毎および／または食堂全体の更新後注文予測モデルは、更新後注文予測モデルデータベース１０７Ａに送信され、記憶される（Ｓ６１８）。また、このようにして演算された食堂全体の更新後注文予測モデルは、表示システム３Ａに送信され、表示される（Ｓ６１９）。食堂運営会社Ｃのシェフ（例えば、料理長）は、表示システム３Ａに表示されている更新後注文予測モデルに基づき、調理する量を調整することができる。
【0164】
特定日Ｘ当日、ユーザが食堂に来るたびに当日注文履歴データベース１０４Ａは、更新されていくといえる。そのため、注文量更新演算部１１０Ａは、更新後注文予測モデルデータベース１０７Ａに記憶されている最新の更新後注文予測モデルを事前分布として（Ｓ６２０）、刻々と更新されていく当日注文履歴データベース１１０Ａの当日注文履歴の入力に基づき（Ｓ６１５）、再度、ユーザ毎、属性毎および／または食堂全体の更新後注文予測モデルを演算してもよい（Ｓ６１７）。そして、このようにして再度演算された更新後注文予測モデルは、更新後注文パターンモデルデータベース１０７Ａに送信され、記憶されるとともに（Ｓ６１８）、表示システム３Ａに送信され、表示される（Ｓ６１９）。例えば、ユーザＤが、いつもよりかなり早い時刻に食堂に来て（例えば、通常は１２：３０頃に食堂に来るが、特定日Ｘは１１：３０頃に食堂に来て）、普段注文しない「とんかつ」を注文した場合、このような当日注文履歴に基づき、ユーザＤの注文予測モデルおよび／またはユーザＤの属性の注文予測モデル（事前分布）がベイズ推論に基づき更新され、ユーザＤの更新後注文予測モデルおよび／またはユーザＤの属性の更新後注文予測モデル（事後分布）が演算されるとともに、食堂全体の更新後注文予測モデルも演算される。
【0165】
食堂運営会社Ｃのシェフ（例えば、料理長）は、表示システム３Ａに表示されている刻々と更新されていく更新後注文予測モデル（すなわち、時系列に沿った注文予測量）を参照しながら、準備すべき材料の量や調理すべき量を刻々と調整することが可能となる。
【0166】
特定日Ｘにおける食堂の営業時間終了後、更新後注文予測モデルデータベース１０７Ａに記憶されている最新のユーザ毎、属性毎および／または食堂全体の更新後注文予測モデルは、注文量予測システム１Ａに備えられている任意のデータベースまたは記憶部（例えば、注文パターンモデルデータベース１０５Ａ）に送信され、記憶されてもよい（図示せず）。そして、このように送信され、記憶された更新後注文予測モデルは、必要に応じて注文パターンモデルデータベース１０５Ａに記憶されている注文パターンモデルとともに、注文量予測演算部１０９Ａに送信され（Ｓ６０８）、再度注文予測モデルが演算されてもよい（Ｓ６０９）。あるいは、特定日Ｘにおける食堂の営業時間終了後、更新後注文予測モデルデータベース１０７Ａに記憶されている最新のユーザ毎、属性毎および／または食堂全体の更新後注文予測モデルは、必要に応じて注文パターンモデルデータベース１０５Ａに記憶されている注文パターンモデルとともに、注文量予測演算部１０９Ａに送信され（Ｓ６０８）、再度注文予測モデルが演算されてもよい（Ｓ６０９）。
【0167】
また、特定日Ｘにおける食堂の営業時間終了後、更新後注文予測モデルデータベース１０７Ａに記憶されている最新のユーザ毎、属性毎および／または食堂全体の更新後注文予測モデルと、特定日Ｘにおける食堂全体の実際の注文量の情報（かかる情報は、例えば、当日注文履歴データベース１０４Ａに記憶されていてもよい）とが、補正パラメータ演算部１１１Ａに送信され（Ｓ６２１）、これら送信された情報に基づいて機械学習（例えば、深層学習）により、補正パラメータが演算されてもよい（Ｓ６２２）。この補正パラメータは、特定日Ｘにおける上記ユーザ毎、属性毎および／または食堂全体の更新後注文予測モデルと、特定日Ｘにおける実際の注文量とのギャップをパラメータとして表したものである。演算された補正パラメータは、注文予測システム１Ａに備えられている任意の記憶部やデータベース（例えば、注文パターンモデルデータベース１０５Ａ）に送信され、記憶されてもよい（Ｓ６２３）。このように記憶された補正パラメータは、過去注文履歴データベース１０１Ａに記憶されている情報（Ｓ６０１）、および／または外部因子データベース１０２Ａに記憶されている情報（Ｓ６０２）とともに、注文パターンモデル生成部１０８Ａに送信され（図示せず）、ユーザ毎、属性毎および／または食堂全体の注文パターンモデルの生成に利用されてもよい（Ｓ６０３）。また、このように記憶された補正パラメータは、注文予約データベース１０３Ａに記憶されている情報（Ｓ６０６）、外部因子データベース１０２Ａに記憶されている情報（Ｓ６０７）および／または注文パターンモデルデータベースに記憶されている各注文パターンモデル（Ｓ６０８）とともに、注文量予測演算部１０９Ａに送信され（図示せず）、ユーザ毎、属性毎および／または食堂全体の注文予測モデルの生成に利用されてもよい（Ｓ６０９）。このように、補正パラメータ演算部で演算された補正パラメータにより、上記注文パターンモデルおよび／または上記注文予測モデルを生成ないしは演算することで、上記注文パターンモデルおよび／または上記注文予測モデルの精度がより高まる点で有利である。
【0168】
本開示は、以下を包含する。
［１］過去注文履歴データベースと、外部因子データベースと、注文パターンモデル生成部と、注文量予測演算部と、注文量更新演算部とを備える、食堂における注文量予測システムであって、
上記過去注文履歴データベースは、ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶し、
上記注文パターンモデル生成部は、上記過去注文履歴データベースに記憶された情報と上記外部因子データベースに記憶された情報とに基づき、時系列に沿った上記ユーザ毎の注文パターンモデル、時系列に沿った上記属性毎の注文パターンモデル、および／または時系列に沿った上記食堂全体の注文パターンモデルを生成し、
上記注文量予測演算部は、
（１）上記ユーザ毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記ユーザ毎の注文予測モデルを演算し、かつ上記ユーザ毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算する、
（２）上記属性毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記属性毎の注文予測モデルを演算し、かつ上記属性毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算する、および／または
（３）上記食堂全体の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算し、
上記注文量更新演算部は、
（１）上記ユーザ毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記ユーザ毎の更新後注文予測モデルを演算し、かつ上記ユーザ毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、
（２）上記属性毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記属性毎の更新後注文予測モデルを演算し、かつ上記属性毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、および／または
（３）上記食堂全体の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、
注文量予測システム。
［２］上記外部因子データベースが気象情報および組織におけるイベント情報からなる群より選択される少なくとも１つを記憶する、［１］に記載の注文量予測システム。
［３］上記注文量予測演算部が、さらに上記特定日における上記ユーザ毎の注文予約情報に基づき上記ユーザ毎の注文予測モデル、上記属性毎の注文パターンモデル、および／または上記食堂全体の注文パターンモデルを演算する、［１］または［２］に記載の注文量予測システム。
［４］上記ベイズ統計学の手法がベイズ推論である、［１］～［３］のいずれかに記載のシステム。
［５］上記ユーザ毎の注文予約情報を記憶する注文予約データベースをさらに備える、［３］に記載の注文量予測システム。
［６］上記ユーザ毎の注文パターンモデル、上記属性毎の注文パターンモデル、および／または上記食堂全体の注文パターンモデルを記憶する注文パターンモデルデータベースをさらに備える、［１］～［５］のいずれかに記載の注文量予測システム。
［７］上記ユーザ毎の注文予測モデル、上記属性毎の注文予測モデル、および／または上記食堂全体の注文予測モデルを記憶する注文予測モデルデータベースをさらに備える、［１］～［６］のいずれかに記載の注文量予測システム。
［８］上記ユーザ毎の更新後注文予測モデル、上記属性毎の更新後注文予測モデル、および／または上記食堂全体の更新後注文予測モデルを記憶する更新後注文予測モデルデータベースをさらに備える、［１］～［７］のいずれかに記載の注文量予測システム。
［９］上記注文量予測システムが補正パラメータ演算部をさらに備え、
上記補正パラメータ演算部は、上記食堂全体の更新後注文予測モデルと、上記特定日における上記食堂全体の実際の注文量とに基づき、上記ユーザ毎の注文パターンモデル、上記属性毎の注文パターンモデル、および／または上記食堂全体の注文パターンモデルの補正に使用される補正パラメータを演算する、
［１］～［８］のいずれかに記載の注文量予測システム。
［１０］［１］～［９］のいずれかに記載の注文量予測システムと、
上記ユーザ毎の特定日における実際の注文履歴を上記注文量予測システムに送信する注文受付システムと、
上記食堂全体の注文予測モデルおよび／または上記食堂全体の更新後注文予測モデルを表示する表示システムと
を備える、食堂注文システム。
［１１］食堂における注文量を予測する方法であって、
過去注文履歴データベースに記憶された情報と外部因子データベースに記憶された情報とに基づき、時系列に沿ったユーザ毎の注文パターンモデルおよび／または時系列に沿った属性毎の注文パターンモデルを生成するステップと、
上記ユーザ毎の注文パターンモデルおよび／または上記属性毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記ユーザ毎の注文予測モデルおよび／または上記特定日における時系列に沿った上記属性毎の注文予測モデルを演算するステップと、
上記ユーザ毎の注文予測モデルおよび／または上記属性毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算するステップと、
上記ユーザ毎の注文予測モデルおよび／または上記属性毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記ユーザ毎の更新後注文予測モデルおよび／または時系列に沿った上記属性毎の更新後注文予測モデルを演算するステップと、
上記ユーザ毎の更新後注文予測モデルおよび／または上記属性毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算するステップと、
を含み、
上記過去注文履歴データベースは、上記ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶する、方法。
［１２］食堂における注文量を予測する方法であって、
過去注文履歴データベースに記憶された情報と外部因子データベースに記憶された情報とに基づき、時系列に沿ったユーザ毎の注文パターンモデルおよび／または時系列に沿った属性毎の注文パターンモデルを生成するステップと、
上記ユーザ毎の注文パターンモデルおよび／または上記属性毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記ユーザ毎の注文予測モデルおよび／または上記特定日における時系列に沿った上記属性毎の注文予測モデルを演算するステップと、
上記ユーザ毎の注文予測モデルおよび／または上記属性毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算するステップと、
上記食堂全体の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算するステップと、
を含み、
上記過去注文履歴データベースは、上記ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶する、方法。
［１３］食堂における注文量を予測する方法であって、
過去注文履歴データベースに記憶された情報と外部因子データベースに記憶された情報とに基づき、時系列に沿った食堂全体の注文パターンモデルを生成するステップと、
上記食堂全体の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った食堂全体の注文予測モデルを演算するステップと、
上記食堂全体の注文予測モデルをユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算するステップと、
を含み、
上記過去注文履歴データベースは、上記ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶する、方法。
［１４］上記食堂全体の更新後注文予測モデルと、上記特定日における上記食堂全体の実際の注文量とに基づき、上記ユーザ毎の注文パターンモデル、上記属性毎の注文パターンモデル、および／または上記食堂全体の注文パターンモデルの補正に使用される補正パラメータを演算するステップ
をさらに含む、［１１］～［１３］のいずれかに記載の方法。
［１］過去注文履歴データベースと、外部因子データベースと、注文パターンモデル生成部と、注文量予測演算部と、注文量更新演算部とを備える、食堂における注文量予測システムであって、
上記過去注文履歴データベースは、ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶し、
上記注文パターンモデル生成部は、上記過去注文履歴データベースに記憶された情報と上記外部因子データベースに記憶された情報とに基づき、時系列に沿った上記ユーザ毎の注文パターンモデル、時系列に沿った上記属性毎の注文パターンモデル、および／または時系列に沿った上記食堂全体の注文パターンモデルを生成し、
上記注文量予測演算部は、
（１）上記ユーザ毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記ユーザ毎の注文予測モデルを演算し、かつ上記ユーザ毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算する、
（２）上記属性毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記属性毎の注文予測モデルを演算し、かつ上記属性毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算する、および／または
（３）上記食堂全体の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算し、
上記注文量更新演算部は、
（１）上記ユーザ毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記ユーザ毎の更新後注文予測モデルを演算し、かつ上記ユーザ毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、
（２）上記属性毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記属性毎の更新後注文予測モデルを演算し、かつ上記属性毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、および／または
（３）上記食堂全体の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、
注文量予測システム。
［２］上記外部因子データベースが気象情報および組織におけるイベント情報からなる群より選択される少なくとも１つを記憶する、［１］に記載の注文量予測システム。
［３］上記注文量予測演算部が、さらに上記特定日における上記ユーザ毎の注文予約情報に基づき上記ユーザ毎の注文予測モデル、上記属性毎の注文パターンモデル、および／または上記食堂全体の注文パターンモデルを演算する、［１］または［２］に記載の注文量予測システム。
［４］上記ベイズ統計学の手法がベイズ推論である、［１］～［３］のいずれかに記載のシステム。
［５］上記ユーザ毎の注文予約情報を記憶する注文予約データベースをさらに備える、［３］に記載の注文量予測システム。
［６］上記ユーザ毎の注文パターンモデル、上記属性毎の注文パターンモデル、および／または上記食堂全体の注文パターンモデルを記憶する注文パターンモデルデータベースをさらに備える、［１］～［５］のいずれかに記載の注文量予測システム。
［７］上記ユーザ毎の注文予測モデル、上記属性毎の注文予測モデル、および／または上記食堂全体の注文予測モデルを記憶する注文予測モデルデータベースをさらに備える、［１］～［６］のいずれかに記載の注文量予測システム。
［８］上記ユーザ毎の更新後注文予測モデル、上記属性毎の更新後注文予測モデル、および／または上記食堂全体の更新後注文予測モデルを記憶する更新後注文予測モデルデータベースをさらに備える、［１］～［７］のいずれかに記載の注文量予測システム。
［９］上記注文量予測システムが補正パラメータ演算部をさらに備え、
上記補正パラメータ演算部は、上記食堂全体の更新後注文予測モデルと、上記特定日における上記食堂全体の実際の注文量とに基づき、上記ユーザ毎の注文パターンモデル、上記属性毎の注文パターンモデル、および／または上記食堂全体の注文パターンモデルの補正に使用される補正パラメータを演算する、
［１］～［８］のいずれかに記載の注文量予測システム。
［１０］［１］～［９］のいずれかに記載の注文量予測システムと、
上記ユーザ毎の特定日における実際の注文履歴を上記注文量予測システムに送信する注文受付システムと、
上記食堂全体の注文予測モデルおよび／または上記食堂全体の更新後注文予測モデルを表示する表示システムと
を備える、食堂注文システム。
［１１］食堂における注文量を予測する方法であって、
過去注文履歴データベースに記憶された情報と外部因子データベースに記憶された情報とに基づき、時系列に沿ったユーザ毎の注文パターンモデルおよび／または時系列に沿った属性毎の注文パターンモデルを生成するステップと、
上記ユーザ毎の注文パターンモデルおよび／または上記属性毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記ユーザ毎の注文予測モデルおよび／または上記特定日における時系列に沿った上記属性毎の注文予測モデルを演算するステップと、
上記ユーザ毎の注文予測モデルおよび／または上記属性毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算するステップと、
上記ユーザ毎の注文予測モデルおよび／または上記属性毎の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した時系列に沿った上記ユーザ毎の更新後注文予測モデルおよび／または時系列に沿った上記属性毎の更新後注文予測モデルを演算するステップと、
上記ユーザ毎の更新後注文予測モデルおよび／または上記属性毎の更新後注文予測モデルに基づき、上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算するステップと、
を含み、
上記過去注文履歴データベースは、上記ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶する、方法。
［１２］食堂における注文量を予測する方法であって、
過去注文履歴データベースに記憶された情報と外部因子データベースに記憶された情報とに基づき、時系列に沿ったユーザ毎の注文パターンモデルおよび／または時系列に沿った属性毎の注文パターンモデルを生成するステップと、
上記ユーザ毎の注文パターンモデルおよび／または上記属性毎の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った上記ユーザ毎の注文予測モデルおよび／または上記特定日における時系列に沿った上記属性毎の注文予測モデルを演算するステップと、
上記ユーザ毎の注文予測モデルおよび／または上記属性毎の注文予測モデルの総和に基づき、上記特定日における時系列に沿った上記食堂全体の注文予測モデルを演算するステップと、
上記食堂全体の注文予測モデルを上記ユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算するステップと、
を含み、
上記過去注文履歴データベースは、上記ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶する、方法。
［１３］食堂における注文量を予測する方法であって、
過去注文履歴データベースに記憶された情報と外部因子データベースに記憶された情報とに基づき、時系列に沿った食堂全体の注文パターンモデルを生成するステップと、
上記食堂全体の注文パターンモデルと、特定日のメニューと、上記外部因子データベースに記憶されている上記特定日に関連する情報とに基づき、上記特定日における時系列に沿った食堂全体の注文予測モデルを演算するステップと、
上記食堂全体の注文予測モデルをユーザ毎の特定日における実際の注文履歴に基づいてベイズ統計学の手法により更新した上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算するステップと、
を含み、
上記過去注文履歴データベースは、上記ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、
上記外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶する、方法。
［１４］上記食堂全体の更新後注文予測モデルと、上記特定日における上記食堂全体の実際の注文量とに基づき、上記ユーザ毎の注文パターンモデル、上記属性毎の注文パターンモデル、および／または上記食堂全体の注文パターンモデルの補正に使用される補正パラメータを演算するステップ
をさらに含む、［１１］～［１３］のいずれかに記載の方法。
【符号の説明】
【0169】
１、１Ａ 注文量予測システム
１０１、１０１Ａ 過去注文履歴データベース
１０２、１０２Ａ 外部因子データベース
１０３、１０３Ａ 注文予約データベース
１０４、１０４Ａ 当日注文履歴データベース
１０５、１０５Ａ 注文パターンモデルデータベース
１０６、１０６Ａ 注文予測モデルデータベース
１０７、１０７Ａ 更新後注文予測モデルデータベース
１０８、１０８Ａ 注文パターンモデル生成部
１０９、１０９Ａ 注文量予測演算部
１１０、１１０Ａ 注文量更新演算部
１１１、１１１Ａ 補正パラメータ演算部
１１２ 通信部
１１３ 入出力インターフェース部
２、２Ａ 注文受付システム
２０１ 処理部
２０２ 決済部
２０３ ユーザ情報識別部
２０４ 注文受付部
２０５ 表示部
２０６ 記憶部
２０７ 通信部
２０８ 入出力インターフェース部
３、３Ａ 表示システム
３０１ 処理部
３０２ 表示部
３０３ 記憶部
３０４ 通信部
３０５ 入出力インターフェース部
４ ユーザ端末
１１ 食堂注文システム
ＮＷ 通信ネットワーク
１０１、１０１Ａ 過去注文履歴データベース
１０２、１０２Ａ 外部因子データベース
１０３、１０３Ａ 注文予約データベース
１０４、１０４Ａ 当日注文履歴データベース
１０５、１０５Ａ 注文パターンモデルデータベース
１０６、１０６Ａ 注文予測モデルデータベース
１０７、１０７Ａ 更新後注文予測モデルデータベース
１０８、１０８Ａ 注文パターンモデル生成部
１０９、１０９Ａ 注文量予測演算部
１１０、１１０Ａ 注文量更新演算部
１１１、１１１Ａ 補正パラメータ演算部
１１２ 通信部
１１３ 入出力インターフェース部
２、２Ａ 注文受付システム
２０１ 処理部
２０２ 決済部
２０３ ユーザ情報識別部
２０４ 注文受付部
２０５ 表示部
２０６ 記憶部
２０７ 通信部
２０８ 入出力インターフェース部
３、３Ａ 表示システム
３０１ 処理部
３０２ 表示部
３０３ 記憶部
３０４ 通信部
３０５ 入出力インターフェース部
４ ユーザ端末
１１ 食堂注文システム
ＮＷ 通信ネットワーク
【要約】
【課題】主に特定のユーザが繰り返し食堂を訪問し、飲食を行うという特有な条件下であっても、注文量を予測することが可能なシステムを提供すること。
【解決手段】食堂における注文量予測システムであって、過去注文履歴データベースは、ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶し、注文パターンモデル生成部は、上記過去注文履歴データベースに記憶された情報と上記外部因子データベースに記憶された情報とに基づき、時系列に沿った注文パターンモデルを生成し、注文量予測演算部は、特定日における時系列に沿った上記食堂全体の注文予測モデルを演算し、上記注文量更新演算部は上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、注文量予測システム。
【選択図】図１
【解決手段】食堂における注文量予測システムであって、過去注文履歴データベースは、ユーザ毎の上記食堂における過去の注文履歴を、上記ユーザの属性情報および時系列と関連づけて記憶し、外部因子データベースは、上記注文履歴を除く任意の情報を時系列と関連付けて記憶し、注文パターンモデル生成部は、上記過去注文履歴データベースに記憶された情報と上記外部因子データベースに記憶された情報とに基づき、時系列に沿った注文パターンモデルを生成し、注文量予測演算部は、特定日における時系列に沿った上記食堂全体の注文予測モデルを演算し、上記注文量更新演算部は上記特定日における時系列に沿った上記食堂全体の更新後注文予測モデルを演算する、注文量予測システム。
【選択図】図１
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
