特許 7109027 需要予測システム、価格決定システム、情報処理システムおよびコンピュータプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-07-21

(45)【発行日】2022-07-29

(54)【発明の名称】需要予測システム、価格決定システム、情報処理システムおよびコンピュータプログラム

(51)【国際特許分類】

   G06Q 30/02 20120101AFI20220722BHJP

   G06Q 50/12 20120101ALI20220722BHJP

【ＦＩ】

G06Q30/02 310

G06Q50/12

【請求項の数】 13

(21)【出願番号】P 2019154153

(22)【出願日】2019-08-26

(65)【公開番号】P2021033718

(43)【公開日】2021-03-01

【審査請求日】2021-05-28

【新規性喪失の例外の表示】特許法第３０条第２項適用 ｈｔｔｐｓ：／／ａｎｎｕａｌ２０１９．ｊｓｉａｍ．ｏｒｇ／ （令和１年８月２３日） 〔刊行物等〕 ｈｔｔｐｓ：／／ａｎｎｕａｌ２０１９．ｊｓｉａｍ．ｏｒｇ／ｗｐ－ａｄｍｉｎ／ａｄｍｉｎ．ｐｈｐ？ｐａｇｅ＝ｃｏｎｔｒｏｌ＿ｐａｎｅｌ （令和１年８月２３日）

(73)【特許権者】

【識別番号】504132272

【氏名又は名称】国立大学法人京都大学

(73)【特許権者】

【識別番号】502133251

【氏名又は名称】フォルシア株式会社

(74)【代理人】

【識別番号】100105924

【弁理士】

【氏名又は名称】森下 賢樹

(72)【発明者】

【氏名】梅野 健

(72)【発明者】

【氏名】新谷 健

(72)【発明者】

【氏名】原 旅人

(72)【発明者】

【氏名】東川 翔

(72)【発明者】

【氏名】長峰 駿介

(72)【発明者】

【氏名】加藤 みちる

(72)【発明者】

【氏名】洲巻 圭介

【審査官】安田 勇太

(56)【参考文献】

【文献】特開２００３－２５６７０２（ＪＰ，Ａ）

【文献】国際公開第２０１６／１５１６４０（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００ －９９／００

(57)【特許請求の範囲】

【請求項1】

所定のサービスを提供する主体が受け付けた前記サービスの予約数について、前記サービスの提供日前の時点ｔ_１までの日ごとに生じた予約数の時系列での推移を取得する取得部と、
前記取得部により取得された前記時点ｔ_１までの日ごとに生じた予約数の時系列での推移に基づいて、前記サービスの提供日までの日ごとに生じる予約数の時系列での推移を示す第１の指数関数を導出し、前記第１の指数関数を用いて前記サービスの提供日までの予約数の合計を推定する推定部と、
前記推定部により推定された前記サービスの提供日までの予約数の合計に基づく予測情報を出力する出力部と、
を備えることを特徴とする需要予測システム。

【請求項2】

前記取得部は、前記サービスが予約後にキャンセルされた数について、前記サービスの提供日前の時点ｔ_２までの日ごとに生じたキャンセル数の時系列での推移をさらに取得し、
前記推定部は、前記時点ｔ_２までの日ごとに生じたキャンセル数の時系列での推移に基づいて、前記サービスの提供日までの日ごとに生じるキャンセル数の時系列での推移を示す第２の指数関数を導出し、前記第２の指数関数を用いて前記サービスの提供日までのキャンセル数の合計を推定し、
前記出力部は、前記サービスの提供日までの予約数の合計からキャンセル数の合計を減じた値に基づく予測情報を出力することを特徴とする請求項１に記載の需要予測システム。

【請求項3】

所定のサービスを提供する複数の主体をそれぞれ含む複数のグループであって、前記サービスが提供されるエリアを含む属性の少なくとも一部が異なる複数のグループのそれぞれに対応付けて、各グループにおける前記サービスの提供日までの日ごとに生じる予約数の時系列での推移を近似した指数関数に関する情報を記憶する第１記憶部と、
前記複数のグループのそれぞれに対応付けて、各グループにおいて複数の主体のそれぞれが予約される確率を記憶する第２記憶部と、
前記サービスを提供する予測対象となる主体である対象主体に関する情報を取得する取得部と、
前記複数のグループのうち前記対象主体を含むグループである対象グループについて前記第１記憶部に記憶された前記対象グループに対応する指数関数と、前記第２記憶部に記憶された前記対象主体が予約される確率とをもとに、前記対象主体が提供する前記サービスの提供日までの予約数の合計を推定する推定部と、
前記推定部により推定された予約数の合計に基づく予測情報を出力する出力部と、
を備えることを特徴とする需要予測システム。

【請求項4】

前記第１記憶部に記憶される指数関数に関する情報は、時定数を含み、
前記取得部は、前記サービスの提供日までの予約数の合計に関して前記対象主体が定める目標値と、前記サービスの提供日前の予測対象となる時点ｔとをさらに取得し、
前記推定部は、前記対象グループに対応する指数関数の時定数と、前記対象主体が定める目標値とをもとに、前記目標値を達成するための値として、前記時点ｔまでの予約数の合計の適正値をさらに推定することを特徴とする請求項３に記載の需要予測システム。

【請求項5】

前記第１記憶部は、前記複数のグループのそれぞれに対応付けて、各グループにおける前記サービスの提供日までの日ごとに生じるキャンセル数の時系列での推移を近似した指数関数に関する情報をさらに記憶し、
前記推定部は、前記対象グループに対応する前記キャンセル数の推移を近似した指数関数と、前記対象主体が予約される確率とをもとに、前記対象主体が提供する前記サービスの提供日までのキャンセル数の合計をさらに推定し、
前記出力部は、前記推定部により推定された予約数の合計からキャンセル数の合計を減じた値に基づく予測情報を出力することを特徴とする請求項３または４に記載の需要予測システム。

【請求項6】

請求項１から５のいずれかに記載の需要予測システムから出力された予測情報が示す前記サービスの提供日までの予約数の合計と、前記予約数の合計に関して定められた目標値との比較結果に応じて、前記サービスの価格の変更に関する情報を生成することを特徴とする価格決定システム。

【請求項7】

請求項２または請求項５に記載の需要予測システムから出力された予測情報が示す前記サービスの提供日までの予約数の合計から前記サービスの提供日までのキャンセル数の合計を減じた値と、前記予約数の合計からキャンセル数の合計を減じた値に関して定められた目標値との比較結果に応じて、前記サービスの価格の変更に関する情報を生成することを特徴とする価格決定システム。

【請求項8】

請求項２または請求項５に記載の需要予測システムから出力された予測情報が示す前記サービスの提供日までのキャンセル数の合計と、前記キャンセル数の合計に関して定められた目標値との比較結果に応じて、前記サービスの価格の変更に関する情報を生成することを特徴とする価格決定システム。

【請求項9】

所定のサービスを提供する主体が受け付けた前記サービスの予約数について、前記サービスの提供日前の時点ｔ_１までの日ごとに生じた予約数の時系列での推移を取得し、前記サービスが予約後にキャンセルされた数について、前記サービスの提供日前の時点ｔ_２までの日ごとに生じたキャンセル数の時系列での推移を取得する取得部と、
前記取得部により取得された前記時点ｔ_１までの日ごとに生じた予約数の時系列での推移に基づいて、前記サービスの提供日までの日ごとに生じる予約数の時系列での推移を示す第１の指数関数を導出し、前記取得部により取得された前記時点ｔ_２までの日ごとに生じたキャンセル数の時系列での推移に基づいて、前記サービスの提供日までの日ごとに生じるキャンセル数の時系列での推移を示す第２の指数関数を導出する導出部と、
前記導出部により導出された第１の指数関数のパラメータと第２の指数関数のパラメータとを比較した結果に関する情報を出力する出力部と、
を備えることを特徴とする情報処理システム。

【請求項10】

所定のサービスを提供する主体が受け付けた前記サービスの予約数について、前記サービスの提供日前の時点ｔ_１までの日ごとに生じた予約数の時系列での推移を取得する機能と、
前記取得する機能により取得された前記時点ｔ_１までの日ごとに生じた予約数の時系列での推移に基づいて、前記サービスの提供日までの日ごとに生じる予約数の時系列での推移を示す第１の指数関数を導出し、前記第１の指数関数を用いて前記サービスの提供日までの予約数の合計を推定する機能と、
前記推定する機能により推定された前記サービスの提供日までの予約数の合計に基づく予測情報を出力する機能と、
をコンピュータに実現させるためのコンピュータプログラム。

【請求項11】

所定のサービスを提供する複数の主体をそれぞれ含む複数のグループであって、前記サービスが提供されるエリアを含む属性の少なくとも一部が異なる複数のグループのそれぞれに対応付けて、各グループにおける前記サービスの提供日までの日ごとに生じる予約数の時系列での推移を近似した指数関数に関する情報を記憶する第１記憶部と、前記複数のグループのそれぞれに対応付けて、各グループにおいて複数の主体のそれぞれが予約される確率を記憶する第２記憶部と、にアクセス可能なコンピュータに、
前記サービスを提供する予測対象となる主体である対象主体に関する情報を取得する機能と、
前記複数のグループのうち前記対象主体を含むグループである対象グループについて前記第１記憶部に記憶された前記対象グループに対応する指数関数と、前記第２記憶部に記憶された前記対象主体が予約される確率とをもとに、前記対象主体が提供する前記サービスの提供日までの予約数の合計を推定する機能と、
前記推定する機能により推定された予約数の合計に基づく予測情報を出力する機能と、
を実現させるためのコンピュータプログラム。

【請求項12】

請求項１０または１１に記載のコンピュータプログラムから出力された予測情報が示す前記サービスの提供日までの予約数の合計と、前記予約数の合計に関して定められた目標値との比較結果に応じて、前記サービスの価格の変更に関する情報を生成することを特徴とするコンピュータプログラム。

【請求項13】

所定のサービスを提供する主体が受け付けた前記サービスの予約数について、前記サービスの提供日前の時点ｔ_１までの日ごとに生じた予約数の時系列での推移を取得し、前記サービスが予約後にキャンセルされた数について、前記サービスの提供日前の時点ｔ_２までの日ごとに生じたキャンセル数の時系列での推移を取得する機能と、
前記取得する機能により取得された前記時点ｔ_１までの日ごとに生じた予約数の時系列での推移に基づいて、前記サービスの提供日までの日ごとに生じる予約数の時系列での推移を示す第１の指数関数を導出し、前記取得する機能により取得された前記時点ｔ_２までの日ごとに生じたキャンセル数の時系列での推移に基づいて、前記サービスの提供日までの日ごとに生じるキャンセル数の時系列での推移を示す第２の指数関数を導出する機能と、
前記導出する機能により導出された第１の指数関数のパラメータと第２の指数関数のパラメータとを比較した結果に関する情報を出力する機能と、
をコンピュータに実現させるためのコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データ処理技術に関し、特に需要予測システム、価格決定システム、情報処理システムおよびコンピュータプログラムに関する。

【背景技術】

【0002】

機械学習モデルを利用して宿泊施設における適正な宿泊料金を設定する宿泊料金設定装置が提案されている（例えば特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１９－１６０３５号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

上記特許文献１に記載の技術では、多くの宿泊施設における過去の実績データ（例えば客室予約数の時系列変化の情報）が十分にない場合、精度のよい機械学習モデルの構築が困難である。

【0005】

本発明はこうした課題に鑑みてなされたものであり、１つの目的は、サービスの提供者にとって有用な情報を効率的に提供することにある。

【課題を解決するための手段】

【0006】

上記課題を解決するために、本発明のある態様の需要予測システムは、所定のサービスを提供する主体が受け付けたサービスの予約数について、サービスの提供日前の時点ｔ_１までの時系列での予約数の推移を取得する取得部と、取得部により取得された時点ｔ_１までの時系列での予約数の推移に基づいて、サービスの提供日までの時系列での予約数の推移を示す第１の指数関数を導出し、第１の指数関数を用いてサービスの提供日までの予約数の合計を推定する推定部と、推定部により推定されたサービスの提供日までの予約数の合計に基づく予測情報を出力する出力部と、を備える。

【0007】

本発明の別の態様もまた、需要予測システムである。この需要予測システムは、所定のサービスを提供する複数の主体をそれぞれ含む複数のグループであって、サービスが提供されるエリアを含む属性の少なくとも一部が異なる複数のグループのそれぞれに対応付けて、各グループにおけるサービスの提供日までの時系列での予約数の推移を近似した指数関数に関する情報を記憶する第１記憶部と、複数のグループのそれぞれに対応付けて、各グループにおいて複数の主体のそれぞれが予約される確率を記憶する第２記憶部と、サービスを提供する予測対象となる主体である対象主体に関する情報を取得する取得部と、複数のグループのうち対象主体を含むグループである対象グループについて第１記憶部に記憶された対象グループに対応する指数関数と、第２記憶部に記憶された対象主体が予約される確率とをもとに、対象主体が提供するサービスの提供日までの予約数の合計を推定する推定部と、推定部により推定された予約数の合計に基づく予測情報を出力する出力部と、を備える。

【0008】

本発明のさらに別の態様は、価格決定システムである。この価格決定システムは、上記いずれかの需要予測システムから出力された予測情報が示すサービスの提供日までの予約数の合計と、予約数の合計に関して定められた目標値との比較結果に応じて、サービスの価格の変更に関する情報を生成する。

【0009】

本発明のさらに別の態様は、情報処理システムである。この情報処理システムは、所定のサービスを提供する主体が受け付けたサービスの予約数について、サービスの提供日前の時点ｔ_１までの時系列での予約数の推移を取得し、サービスが予約後にキャンセルされた数について、サービスの提供日前の時点ｔ_２までの時系列でのキャンセル数の推移を取得する取得部と、取得部により取得された時点ｔ_１までの時系列での予約数の推移に基づいて、サービスの提供日までの時系列での予約数の推移を示す第１の指数関数を導出し、取得部により取得された時点ｔ_２までの時系列でのキャンセル数の推移に基づいて、サービスの提供日までの時系列でのキャンセル数の推移を示す第２の指数関数を導出する導出部と、導出部により導出された第１の指数関数のパラメータと第２の指数関数のパラメータとを比較した結果に関する情報を出力する出力部と、を備える。

【0010】

なお、以上の構成要素の任意の組合せ、本発明の表現を装置、コンピュータプログラム、コンピュータプログラムを読み取り可能に記録した記録媒体などの間で変換したものもまた、本発明の態様として有効である。

【発明の効果】

【0011】

本発明によれば、サービスの提供者にとって有用な情報を効率的に提供することができる。

【図面の簡単な説明】

【0012】

【図1】実データの曲線フィッティングの結果を示す図である。

【図2】第１実施例の通信システムの構成を示す図である。

【図3】第１実施例の需要予測装置の機能ブロックを示すブロック図である。

【図4】予約関数を模式的に示す図である。

【図5】予約関数とキャンセル関数を模式的に示す図である。

【図6】第３実施例の需要予測装置の機能ブロックを示すブロック図である。

【図7】第４実施例の情報処理装置の機能ブロックを示すブロック図である。

【図8】第５実施例の通信システムの構成を示す図である。

【図9】図８の価格決定装置の機能ブロックを示すブロック図である。

【発明を実施するための形態】

【0013】

実施例では、宿泊施設（ホテル等）の需要予測（予約数およびキャンセル数の予測）を例示するが、実施例に記載の技術は、宿泊施設に限られず、供給量が制限されたサービス全般の需要予測に適用可能である。例えば、旅客輸送、スポーツ、コンサート、リラクゼーション、映画、駐車場、アミューズメント、美容、浴場、レジャー等のサービスにおける需要予測にも適用可能である。

【0014】

実施例のシステムを説明する前に、実施例で使用する需要予測アルゴリズムについて説明する。
まず、予約数とキャンセル数に対する定義を与える。実施例では、宿泊施設における或る日の宿泊予約数Ｘ（ｔ）とキャンセル数Ｙ（ｔ）が、以下の関数にしたがって振る舞うものとする。

【数1】

【0015】

ただし、Ａ＞Ｂ＞０とする。また、ｔは、宿泊日（言い換えればサービス提供日）より何日前かを示す値（単位：日）である。また、φ_Ｘ（ｔ）とφ_Ｙ（ｔ）は、以下を満たすものとする。

【数2】

つまり、Ｘ（０）＝Ａ，Ｘ（∞）＝０，Ｙ（０）＝Ｂ，Ｙ（∞）＝０となる。
このとき、以下を仮説として置く。

【0016】

任意の０≦ｔ_１＜ｔ_２に対し、次の式が成立するとする。
φ（ｔ_２）＝φ（ｔ_１）φ（ｔ_２－ｔ_１） ・・・（式１）
式１に対する直感的な理解を与える。
ある区間εと日付αが与えられたとき、式１は以下の性質を持つ。
φ（α）＝φ（０）φ（α－０）＝φ（α）
φ（α＋ε）＝φ（α）φ（ε）
すなわち、ε日後（あるいはε日前）の値は、α日時点での値によらず、そこから一定の割合だけ減る（或いは増える）という性質を持つ。

【0017】

この性質は、自然界において原子の半減期の性質にも見られるような自己比例を意味し、すなわち観測数の変化が、その時点での観測数に比例することを意味している。すなわち、人の予約行動を自然現象と見なし、予約数は、期日（予約の対象となる日であって、言い換えればサービス提供日）から遠ざかるにつれて（例えばその距離に比例して）日々減少していくことを仮定したことになる。

【0018】

予約数とキャンセル数に対して上記の定義と仮説を置いた場合、φ_Ｘ（ｔ）とφ_Ｙ（ｔ）は、陽に表すことができる。

【数3】

ただし、τ_Ｘとτ_Ｙは、正の時定数であり、言い換えれば、予約数とキャンセル数の変化を司る定数パラメータである。サービス提供者が宿泊施設の場合、τ_Ｘとτ_Ｙは、リードタイムとも言え、予約数とキャンセル数の増加度合いが大きくなるタイミングに応じた定数である。

【0019】

図１は、実データの曲線フィッティングの結果を示す。図１の横軸は、上記のｔを示し、すなわち宿泊施設に対する予告が行われた日（宿泊日の何日前か）を示している。図１の縦軸は、予約数またはキャンセル数を対数スケールで示している。ポイント１００は、ある時点ｔにおける予約数を示す実データであり、ポイント１０２は、ある時点ｔにおけるキャンセル数を示す実データである。予約曲線１０４は、ポイント１００の推移を近似した曲線であり、キャンセル曲線１０６は、ポイント１０２の推移を近似した曲線である。

【0020】

既述したように、図１の縦軸は対数スケールであるため、予約曲線１０４とキャンセル曲線１０６はともに指数関数となる。本発明者は、実データを用いた検証により、宿泊施設における予約数Ｘ（ｔ）とキャンセル数Ｙ（ｔ）は、以下の関数系に相応しくフィッティングされることを発見した。

【数4】

なお、Ａは、サービス提供当日（宿泊日当日）の予約数であり、Ｂは、サービス提供当日（宿泊日当日）のキャンセル数である。

【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】

第３実施例の予約関数Ｘ_ｉ（ｔ）は、サービス提供日前の時点ｔにおける或るグループｉ（例えばエリア、価格帯、曜日、季節が一致する宿泊施設群）に対する予約数の時間推移を示すものであり、以下の式４で表される。式４は、式２にグループの概念を導入したものである。

【数5】

式４のＡ_ｉは、グループｉにおけるサービス提供当日（宿泊日当日）の予約数である。また、式４のτ_ｘｉは、グループｉにおける正の時定数である。

【0054】

また、導出部５２は、複数のグループそれぞれの予約情報に基づいて、各グループにおいて複数の主体のそれぞれが予約される確率（以下「選択確率」とも呼ぶ。）を導出する。導出部５２は、各グループにおける各主体の選択確率Ｐ_ｉ，ｊを選択確率記憶部４２に格納する。選択確率Ｐ_ｉ，ｊのｉはグループの識別子であり、ｊは主体の識別子である。

【0055】

選択確率導出の具体例を説明する。ここでは、東京の恵比寿エリアで宿泊料金１２０００円のホテルＡについて或る日の選択確率を求めることとする。Ａホテルは、宿泊料金１２０００円の部屋を１００部屋備え、年間平均稼働率が７５％とする。すなわち、Ａホテルの１日あたりの平均部屋予約数は７５部屋である。

【0056】

一方、恵比寿エリアには宿泊施設が３００施設（合計６０００部屋）あることとする。また、各施設の平均価格や年間平均稼働率について以下のような公開データが得られていることとする。
・８０００円未満 ２０００部屋、平均稼働室数１５００部屋（７５％）
・８０００円以上１５０００円未満 ２５００部屋、平均稼働室数２１００部屋（８４％）
・１５０００円以上３００００円未満 １３００部屋、平均稼働室数８００部屋（６１％）
・３００００円以上 ２００部屋、平均稼働室数１００部屋（５０％）

【0057】

この例では、導出部５２は、恵比寿エリア、かつ価格帯８０００円以上１５０００円未満のグループにおけるホテルＡの選択確率を７５／２１００（すなわち３．５２％）と導出する。導出部５２は、導出した選択確率を年間平均の選択率と見なし、曜日や季節等の条件の変化に応じて、宿泊需要量を変動させて（例えば平日は２１００より少なくし、休日は２１００より多くする等）、複数のグループにおけるホテルＡの選択確率を導出してもよい。

【0058】

要求取得部５４は、ユーザ装置１２からの要求に応じて、需要予測の対象となるサービス提供主体である対象主体（例えば特定の宿泊施設）に関する情報を取得する。要求取得部５４は、要求元のユーザ装置１２（またはそのユーザ）に応じて対象主体を特定してもよい。対象主体に関する情報は、少なくとも対象主体の識別情報を含み、また、需要予測の対象となるグループである対象グループを特定可能な情報を含む。また、対象主体に関する情報は、需要予測の対象となる日付（対象日）を含んでもよく、その対象日の属性（曜日や季節等）を含んでもよい。

【0059】

推定部５６は、第１実施例の推定部３２に対応する。推定部５６は、対象主体（エリアを含む）や対象日の属性の組み合わせと、対象グループとの対応関係を保持する。推定部５６は、予め分類された複数のグループの中から、対象主体を含む対象グループであって、対象日の属性に合致する対象グループを特定する。推定部５６は、指数関数記憶部４０に記憶された対象グループに対応する指数関数（式４）と、選択確率記憶部４２に記憶された対象主体の選択確率とをもとに、対象主体が提供するサービスのその提供日までの予約数の合計を推定する。

【0060】

対象グループｉにおいて、サービス提供日のｔ日前の時点で既に予約した合計人数Ｓ_ｉ（ｔ）は、式４を時点ｔから∞まで積分することにより以下の式で表される。

【数6】

【0061】

第３実施例では、グループＧ_ｉの中に宿泊施設がＭ_ｉ個あるとき、施設Ｆ_ｉ，ｊ（ｊ＝１，．．．，Ｍｉ）に対して、グループＧ_ｉの全宿泊者が一定の確率（選択確率）Ｐ_ｉ，ｊにて施設Ｆ_ｉ，ｊへの予約が入ることとする。このとき、サービス提供日前のｔ日目時点までの施設Ｆ_ｉ，ｊへの予約数合計Ｘ_ｉ，ｊ（ｔ）は、以下の式５で表される。

【数7】

また、サービス提供日（ｔ＝０）までの施設Ｆ_ｉ，ｊへの予約数合計Ｘ_ｉ，ｊ（０）は、以下の式６で表される。

【数8】

【0062】

式６のＰ_ｉ，ｊは、対象施設の選択確率であり、導出部５２により予め導出され、選択確率記憶部４２に記憶されている。また、式６のＡ_ｉおよびτ_Ｘｉは、対象グループに対応する予約関数のパラメータであり、導出部５２により予め導出され、指数関数記憶部４０に記憶されている。そのため、推定部５６は、指数関数記憶部４０に記憶された対象グループに対応する予約関数のＡ_ｉおよびτ_Ｘｉを取得し、また、選択確率記憶部４２に記憶された対象主体の選択確率Ｐ_ｉ，ｊを取得する。そして、それらの乗算結果を対象主体が提供するサービスのその提供日までの予約数の合計として導出する。

【0063】

予測情報出力部５８は、第１実施例の予測情報出力部３４に対応する。予測情報出力部５８は、推定部５６により推定された予約数の合計に基づく予測情報を出力する。例えば、予測情報出力部５８は、推定部５６により推定された予約数の合計を示す予測情報をユーザ装置１２へ送信して、ユーザ装置１２に予測情報を表示させる。

【0064】

第３実施例の通信システム１０の動作を説明する。需要予測装置１４の予約情報取得部５０は、宿泊施設予約ポータルサイトを提供するシステムから、そのシステムに記憶された複数の宿泊施設に対する予約実績に基づく複数の予約情報を取得する。導出部５２は、複数の宿泊施設に対応する複数の予約情報をもとに、予め定められた複数のグループのそれぞれについて予約数の推移を近似した予約関数を導出し、導出した予約関数に関する情報を指数関数記憶部４０に格納する。また、導出部は、予め定められた複数のグループのそれぞれについて、複数のサービス提供主体の選択確率を導出し、各サービス提供主体の選択確率に関する情報を選択確率記憶部４２に格納する。

【0065】

宿泊施設のレベニューマネージャは、ユーザ装置１２を操作して需要予測装置１４が提供するウェブサイトにアクセスする。レベニューマネージャは、ある未来日（「対象日」と呼ぶ。）における予約数の見込を得たい場合、その対象日と自施設の識別情報を含む予測要求をユーザ装置１２から需要予測装置１４へ送信させる。需要予測装置１４の要求取得部５４は、ユーザ装置１２から送信された予測要求を受け付け、推定部５６に渡す。

【0066】

需要予測装置１４の推定部５６は、予測要求に基づいて、需要予測の対象主体を識別する。また、推定部５６は、予測要求が示す対象日や、対象主体が存在するエリア等に基づいて需要予測の対象グループを識別する。推定部５６は、予め導出された対象グループに対応する予約関数と、予め導出された対象主体の選択確率とをもとに、対象日までに対象主体が獲得すると見込まれる予約数の合計を推定する。

【0067】

需要予測装置１４の予測情報出力部５８は、推定部５６により推定された対象日までの予約数の合計（予測値）を示す予測情報をユーザ装置１２へ送信して表示させる。宿泊施設のレベニューマネージャは、需要予測装置１４から提供された予測情報が示す対象日までの予約数の合計が、自施設の客室数や目標の稼働率により定まる目標値より低い場合、対象日の宿泊料金を下げるという意思決定が可能になる。一方、レベニューマネージャは、予測情報が示す対象日までの予約数の合計が上記目標値を上回る場合、対象日の宿泊料金を上げるという意思決定が可能になる。

【0068】

このように第３実施例の需要予測装置１４によると、需要予測の対象主体（サービス提供者）の予約情報が少ない（もしくは無い）場合でも、市場全体のデータと他のサービス提供者における予約情報を用いることで、対象主体に関する需要予測情報を提供することができる。これにより、サービス提供者におけるレベニューマネジメントやダイナミックプライシングを効率的に支援することができる。

【0069】

第３実施例の第１変形例を説明する。需要予測装置１４の要求取得部５４は、サービス提供日までの予約数の合計に関して予測対象となる対象主体が定める目標値と、サービス提供日前の予測対象となる時点ｔとをさらに取得する。

【0070】

例えば、要求取得部５４は、ユーザ装置１２から送信された、対象主体の室数と目標の稼働率とを含む予測要求を受け付け、その室数と稼働率とをもとにサービス提供日までの予約数の合計（言い換えればサービス提供日までに受け付ける予約総数）の目標値を導出してもよい。また、ユーザ装置１２から送信される予測要求では、未来のサービス提供日（目標を達成すべき日）が指定されてもよい。この場合、要求取得部５４は、現在からサービス提供日までの日数を上記の時点ｔとして取得してもよい。

【0071】

対象主体の室数をＣとし、目標の稼働率をαとすると、サービス提供日までの予約数の合計の目標値はＣαとなる。式６をもとに理想状態は、以下の式７で表される。

【数9】

式５と式７から、目標値を達成するために時点ｔで受け付けておくべき予約数（適正値）は、以下の式８で表される。

【数10】

【0072】

需要予測装置１４の推定部５６は、式８にしたがい、予測対象となる対象グループに対応する指数関数の時定数と、対象主体が定める目標値とをもとに、その目標値を達成するための値として、時点ｔまでの予約数の合計の適正値をさらに推定する。需要予測装置１４の予測情報出力部５８は、第３実施例に記載した推定部５６により推定された対象日までの予約数合計の予測値と、本変形例に記載した推定部５６により推定された目標値を達成するための時点ｔまでの予約数合計の適正値とを含む予測情報をユーザ装置１２へ送信して表示させてもよい。

【0073】

本変形例の需要予測装置１４によると、未来日における予約数の目標を達成するために、時点ｔ（例えば現時点）で受け付けておくべき予約数の適正値を提供できる。例えば、宿泊施設のレベニューマネージャは、時点ｔでの予約の実績値が適正値を下回る場合、未来日における目標値を達成するために宿泊料金を下げる意思決定が可能になる。一方、レベニューマネージャは、時点ｔでの予約の実績値が適正値を上回る場合、利益を大きくするために宿泊料金を上げる意思決定が可能になる。

【0074】

第３実施例の第２変形例を説明する。本変形例は、第２実施例に記載したキャンセルの考慮を第３実施例に適用したものである。指数関数記憶部４０は、複数のグループのそれぞれに対応付けて、各グループにおけるサービス提供日までの時系列でのキャンセル数の推移を近似した指数関数に関する情報をさらに記憶する。

【0075】

予約情報取得部５０は、所定のサービスを提供する主体が受け付けた上記サービスのキャンセル数に関する情報であって、サービス提供日までの時系列でのキャンセル数の推移を示すキャンセル情報を取得する。例えば、予約情報取得部５０は、旅行予約ポータルサイトを提供するシステムから、そのシステムが受け付けたキャンセル実績に基づく、複数の主体に対応する複数のキャンセル情報を取得してもよい。

【0076】

導出部５２は、複数の主体に対応する複数のキャンセル情報を、各主体が属するグループごとに分類する。導出部５２は、グループごとに複数のキャンセル情報が示すサービス提供日までの時系列でのキャンセル数の推移を上記の式３にフィッティングすることにより、グループごとにキャンセル数の推移を近似した指数関数であるキャンセル関数を導出する。すなわち、導出部５２は、グループごとに式３のＢおよびτ_Ｙを推定する。導出部５２は、導出したキャンセル関数に関する情報（Ｂおよびτ_Ｙを含む）を指数関数記憶部４０に格納する。

【0077】

キャンセル関数Ｙ_ｉ（ｔ）は、サービス提供日前の時点ｔにおける或るグループｉ（例えばエリア、価格帯、曜日、季節が一致する宿泊施設群）に対するキャンセル数の時間推移を示すものであり、以下の式９で表される。

【数11】

【0078】

推定部５６は、予め分類された複数のグループのうち対象主体を含む対象グループについて指数関数記憶部４０に記憶された対象グループに対応するキャンセル関数と、選択確率記憶部４２に記憶された対象主体の選択確率とをもとに、対象主体が提供するサービスのその提供日までのキャンセル数の合計をさらに推定する。

【0079】

具体的には、サービス提供日（ｔ＝０）までの施設Ｆ_ｉ，ｊへのキャンセル数合計Ｙ_ｉ，ｊ（０）は、予約数に関する式６と同様に、以下の式１０で表される。

【数12】

推定部５６は、指数関数記憶部４０に記憶された対象グループに対応するキャンセル関数のＢ_ｉおよびτ_Ｙｉを取得し、また、選択確率記憶部４２に記憶された対象主体の選択確率Ｐ_ｉ，ｊを取得する。そして、それらの乗算結果を対象主体が提供するサービスのその提供日までのキャンセル数の合計として導出する。

【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】

１０ 通信システム、 １４ 需要予測装置、 １８ 情報処理装置、 ３０ 予約情報取得部、 ３２ 推定部、 ３４ 予測情報出力部、 ４０ 指数関数記憶部、 ４２ 選択確率記憶部、 ５０ 予約情報取得部、 ５４ 要求取得部、 ５６ 推定部、 ５８ 予測情報出力部、 ６０ 予約情報取得部、 ６２ 導出部、 ６４ 出力部、 ７０ 価格決定装置。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】