特許 6961551 情報処理装置、情報処理方法および情報処理プログラム

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

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

(11)【特許番号】6961551

(24)【登録日】2021年10月15日

(45)【発行日】2021年11月5日

(54)【発明の名称】情報処理装置、情報処理方法および情報処理プログラム

(51)【国際特許分類】

   G06Q 30/02 20120101AFI20211025BHJP

   G06Q 50/10 20120101ALI20211025BHJP

   G06Q 50/12 20120101ALI20211025BHJP

   G06Q 40/08 20120101ALI20211025BHJP

   G06Q 10/02 20120101ALI20211025BHJP

【ＦＩ】

   G06Q30/02 398

   G06Q50/10

   G06Q50/12

   G06Q40/08

   G06Q10/02

【請求項の数】14

【全頁数】23

(21)【出願番号】特願2018-154184(P2018-154184)

(22)【出願日】2018年8月20日

(65)【公開番号】特開2020-30471(P2020-30471A)

(43)【公開日】2020年2月27日

【審査請求日】2020年8月19日

(73)【特許権者】

【識別番号】319013263

【氏名又は名称】ヤフー株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】特許業務法人酒井国際特許事務所

(72)【発明者】

【氏名】塚本 浩司

(72)【発明者】

【氏名】田島 玲

(72)【発明者】

【氏名】阿部 泰芳

【審査官】 塩田 徳彦

(56)【参考文献】

【文献】 特開２００２−３４２５７８（ＪＰ，Ａ）

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

【文献】 米国特許出願公開第２０１５／０２４２８１９（ＵＳ，Ａ１）

【文献】 特開平０９−０８１６２６（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１５／００４６２０１（ＵＳ，Ａ１）

【文献】 特開２００４−０６２８２２（ＪＰ，Ａ）

【文献】 特開平０４−１８２８６８（ＪＰ，Ａ）

【文献】 特開２０１７−１６７９４４（ＪＰ，Ａ）

【文献】 特開２００２−３３４２１５（ＪＰ，Ａ）

【文献】 特開２００５−３２２１２３（ＪＰ，Ａ）

【文献】 Gardia、「favy ノーショー保証サービス」の同業他社への横展開で、当日無断キャンセルの被害に悩む飲食店のリスク保証を拡大，[online]，2017年12月25日，［2021年6月30日検索］，インターネット，＜ＵＲＬ：https://gardia.jp/news/201712/favy/＞

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

Ｇ０６Ｑ １０／００−９９／００

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

【請求項1】

施設の予約に関する情報である予約情報を取得する取得部と、
前記取得部によって取得された前記予約情報に基づき、前記予約のキャンセルが発生するリスクを推定する推定部と、
前記推定部によって推定された前記リスクに基づき、前記キャンセルに対して補償を行う補償サービスへ前記施設を提供する事業者が支払う掛け金を決定する決定部と
を備え、
前記推定部は、
前記施設の利用日時までの期間を分割した分割期間毎の前記リスクを推定し、
前記決定部は、
前記分割期間毎の前記リスクに基づいて前記掛け金を決定する
ことを特徴とする情報処理装置。

【請求項2】

前記補償サービスは、
前記キャンセルが発生した場合に、前記施設に対して補填額を支払うサービスであって、
前記補填額の指定を前記事業者から受け付ける受付部
をさらに備え、
前記決定部は、
前記受付部によって受け付けられた前記補填額に基づいて前記掛け金を決定すること
を特徴とする請求項１に記載の情報処理装置。

【請求項3】

前記受付部は、
前記分割期間毎の前記補填額の指定を受け付け、
前記決定部は、
前記分割期間毎に指定された前記補填額に対してそれぞれ対応する前記分割期間毎の前記リスクに応じた料率を乗算した金額の和を前記掛け金として決定すること
を特徴とする請求項２に記載の情報処理装置。

【請求項4】

施設の予約に関する情報である予約情報を取得する取得部と、
前記取得部によって取得された前記予約情報に基づき、前記予約のキャンセルが発生するリスクを推定する推定部と、
前記推定部によって推定された前記リスクに基づき、前記キャンセルに対して補償を行う補償サービスへ前記施設を提供する事業者が支払う掛け金を決定する決定部と
を備え、
前記推定部は、
前記予約を行ったユーザのキャンセル率、前記施設におけるキャンセル率、前記施設が属する地域のキャンセル率、前記施設が属する業界のキャンセル率、および季節因子の少なくとも一つに基づき、前記リスクを推定する
ことを特徴とする情報処理装置。

【請求項5】

前記事業者から前記補償サービスへの加入申請を受け付けることで、前記補償サービスの加入状況を管理する管理部
を備えることを特徴とする請求項１〜４のいずれか一つに記載の情報処理装置。

【請求項6】

前記管理部は、
前記予約毎に前記加入申請を受け付けること
を特徴とする請求項５に記載の情報処理装置。

【請求項7】

前記管理部は、
複数の前記予約に対応する前記補償サービスへの前記加入申請である一括申請を受け付けること
を特徴とする請求項５または６に記載の情報処理装置。

【請求項8】

前記決定部は、
前記一括申請が受け付けられた場合に、前記予約毎に前記掛け金を決定し、
前記管理部は、
前記掛け金が予め設定された枠内に収まる場合、当該掛け金にて前記補償サービスへ加入させること
を特徴とする請求項７に記載の情報処理装置。

【請求項9】

前記管理部は、
前記掛け金が前記枠内から逸脱する場合に、前記事業者に対して通知すること
を特徴とする請求項８に記載の情報処理装置。

【請求項10】

前記管理部は、
前記加入申請を受け付けた場合に、前記補償サービスとして保険サービスを提供する保険業者の装置へ前記保険サービスへの加入申請を示す情報を提供すること
を特徴とする請求項５〜９のいずれか一つに記載の情報処理装置。

【請求項11】

コンピュータが実行する情報処理方法であって、
施設の予約に関する情報である予約情報を取得する取得工程と、
前記取得工程によって取得された前記予約情報に基づき、前記予約のキャンセルが発生するリスクを推定する推定工程と、
前記推定工程によって推定された前記リスクに基づき、前記キャンセルに対して補償を行う補償サービスへ前記施設を提供する事業者が支払う掛け金を決定する決定工程と
を含み、
前記推定工程は、
前記施設の利用日時までの期間を分割した分割期間毎の前記リスクを推定し、
前記決定工程は、
前記分割期間毎の前記リスクに基づいて前記掛け金を決定する
ことを特徴とする情報処理方法。

【請求項12】

施設の予約に関する情報である予約情報を取得する取得手順と、
前記取得手順によって取得された前記予約情報に基づき、前記予約のキャンセルが発生するリスクを推定する推定手順と、
前記推定手順によって推定された前記リスクに基づき、前記キャンセルに対して補償を行う補償サービスへ前記施設を提供する事業者が支払う掛け金を決定する決定手順と
をコンピュータに実行させ、
前記推定手順は、
前記施設の利用日時までの期間を分割した分割期間毎の前記リスクを推定し、
前記決定手順は、
前記分割期間毎の前記リスクに基づいて前記掛け金を決定する
ことを特徴とする情報処理プログラム。

【請求項13】

コンピュータが実行する情報処理方法であって、
施設の予約に関する情報である予約情報を取得する取得工程と、
前記取得工程によって取得された前記予約情報に基づき、前記予約のキャンセルが発生するリスクを推定する推定工程と、
前記推定工程によって推定された前記リスクに基づき、前記キャンセルに対して補償を行う補償サービスへ前記施設を提供する事業者が支払う掛け金を決定する決定工程と
を含み、
前記推定工程は、
前記予約を行ったユーザのキャンセル率、前記施設におけるキャンセル率、前記施設が属する地域のキャンセル率、前記施設が属する業界のキャンセル率、および季節因子の少なくとも一つに基づき、前記リスクを推定する
ことを特徴とする情報処理方法。

【請求項14】

施設の予約に関する情報である予約情報を取得する取得手順と、
前記取得手順によって取得された前記予約情報に基づき、前記予約のキャンセルが発生するリスクを推定する推定手順と、
前記推定手順によって推定された前記リスクに基づき、前記キャンセルに対して補償を行う補償サービスへ前記施設を提供する事業者が支払う掛け金を決定する決定手順と
をコンピュータに実行させ、
前記推定手順は、
前記予約を行ったユーザのキャンセル率、前記施設におけるキャンセル率、前記施設が属する地域のキャンセル率、前記施設が属する業界のキャンセル率、および季節因子の少なくとも一つに基づき、前記リスクを推定する
ことを特徴とする情報処理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理装置、情報処理方法および情報処理プログラムに関する。

【背景技術】

【0002】

従来、旅館、ホテル、飲食店などの施設を利用しようとするユーザは、一般にインターネットや電話などを通じて施設を予約することができる。施設事業者は、予約を行ったユーザに対して規約として前受金や解約料を要求する場合もあるが、ユーザが前受金や解約料を支払わずにキャンセルすることも多く、施設事業者側に損害が発生することがある。

【0003】

そこで、特許文献１には、施設利用予約システムへユーザから施設の予約があったときは、ユーザから前受金をカードによって徴収し、予約がキャンセルされたときは前受金を施設事業者側に解約料として支払う技術が提案されている。かかる施設利用予約システムでは、ユーザから前受金を徴収することから、予約がキャンセルされた場合において損害の発生を防止することができる。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００３−１９６４０６号公報

【発明の概要】

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

【0005】

しかしながら、一律に前受金や解約料を要求すると、キャンセルを行わないようなユーザであっても上記施設利用予約システムを利用した予約を躊躇し予約を控えるといった事態が発生する可能性がある。

【0006】

本願は、上記に鑑みてなされたものであって、予約のキャンセルに対する新たな仕組みの構築を可能とする情報処理装置、情報処理方法および情報処理プログラムを提供することを目的とする。

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

【0007】

本願に係る情報処理装置は、取得部と、推定部と、決定部とを備える。前記取得部は、施設の予約に関する情報である予約情報を取得する。前記推定部は、前記取得部によって取得された前記予約情報に基づき、前記予約のキャンセルが発生するリスクを推定する。前記決定部は、前記推定部によって推定された前記リスクに基づき、前記キャンセルに対して補償を行う補償サービスへ前記施設を提供する事業者が支払う掛け金を決定する。

【発明の効果】

【0008】

実施形態の一態様によれば、予約のキャンセルに対する新たな仕組みを構築することができる。

【図面の簡単な説明】

【0009】

【図1】図１は、実施形態に係る情報処理の説明図である。

【図2】図２は、実施形態に係る情報処理システムの構成の一例を示す図である。

【図3】図３は、実施形態に係る情報処理装置の構成の一例を示す図である。

【図4】図４は、実施形態に係るユーザ情報テーブルの一例を示す図である。

【図5】図５は、実施形態に係る予約情報テーブルの一例を示す図である。

【図6】図６は、実施形態に係る補償関連情報テーブルの一例を示す図である。

【図7A】図７Ａは、補填額の受け付け画面の一例を示す図（その１）である。

【図7B】図７Ｂは、補填額の受け付け画面の一例を示す図（その２）である。

【図8】図８は、決定部による処理の一例を示す図である。

【図9】図９は、補償サービスの申し込み画面の一例である。

【図10】図１０は、実施形態に係る情報処理装置が実行する処理手順を示すフローチャートである。

【図11】図１１は、実施形態に係るプログラムを実行するコンピュータのハードウェア構成の一例を示す図である。

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

【0010】

以下に、本願に係る情報処理装置、情報処理方法および情報処理プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報処理装置、情報処理方法および情報処理プログラムが限定されるものではない。

【0011】

〔１．情報処理〕
図１を用いて、実施形態に係る情報処理について説明する。図１は、実施形態に係る情報処理の説明図である。

【0012】

図１に示すように、ユーザが予約サーバに対し施設利用の予約を要求する予約要求を行うと（ステップＳ１）、予約サーバは、ユーザからの予約要求を受け付けて、予約要求に基づいて、予約要求にかかる予約を登録する（ステップＳ２）。また、予約サーバは、施設利用の予約に関する情報である予約情報を情報処理装置へ送信する（ステップＳ３）。

【0013】

情報処理装置は、予約サーバから予約情報を取得すると、取得された予約情報に基づいて、予約のキャンセルが発生するリスク（以下、キャンセルリスクと記載する）を推定するリスク推定処理を行う（ステップＳ４）。かかるリスク推定処理は、予約毎に行われる。

【0014】

情報処理装置は、リスク評価モデルを記憶している。情報処理装置は、かかるリスク評価モデルによってキャンセルリスクのスコア（以下、キャンセルスコアＳｃと記載する）を演算することができる。かかるキャンセルスコアＳｃがキャンセルリスクの推定値であり、例えば、キャンセルが発生するキャンセル確率である。

【0015】

リスク評価モデルは、例えば、過去の予約情報を説明変数とし、過去のキャンセルの有無を教師データ（目的変数）として生成される。予約情報には、例えば、予約された施設の地域、予約された施設の利用期間、利用価格、利用される部屋の数や広さの情報が含まれており、これらの情報を説明変数としてリスク評価モデルを生成することができる。

【0016】

さらに、予約情報から得られる特徴情報に加え、予約したユーザの情報から得られる特徴情報を説明変数としてリスク評価モデルを生成することができる。予約情報には、ユーザの識別情報が含まれており、情報処理装置は、ユーザの識別情報に基づいて、ユーザの属性や行動履歴の情報を取得し、取得したユーザの属性や行動履歴を説明変数とすることができる。なお、予約情報に含まれるユーザの情報に、ユーザの属性や行動履歴の情報が含まれていてもよい。

【0017】

さらに、リスク推定処理において、ユーザが実際に施設を利用する利用日時までの期間を分割した分割期間毎のキャンセルスコアＳｃを推定する。例えば、分割期間の期間が、１日である場合、１日ごとのキャンセルスコアＳｃが演算結果として得られる。

【0018】

続いて、情報処理装置は、予約のキャンセルが発生した場合に、施設側へ支払われる補填額の指定を施設を提供する事業者（以下、施設事業者と記載する）から受け付ける（ステップＳ５）。情報処理装置は、施設に対する予約の発注時に補填額を入力する入力画面を施設の端末装置に表示することで、施設事業者から補填額の指定を受け付けることができる。

【0019】

情報処理装置は、ステップＳ４で推定したキャンセルリスクと、ステップＳ５で施設事業者により指定された補填額に基づき、施設事業者が補償サービスへ支払う掛け金を決定する（ステップＳ６）。

【0020】

情報処理装置は、例えば、キャンセルリスクと、補填額および掛け金との関係を示す演算式またはテーブルを有しており、かかる演算式またはテーブルを用いて補償サービスにおける掛け金を決定する。

【0021】

情報処理装置は、補償サービスにおける補填額および掛け金の情報を含む補償情報を、予約サーバを介して施設事業者へ送信する（ステップＳ７）。施設事業者は、補填額および掛け金を確認し、補償サービスへの加入の可否の判断を行う。施設事業者は、補償サービスへの加入を決定すると、予約サーバを介して情報処理装置へ補償サービスへの加入申請を行う（ステップＳ８）。

【0022】

情報処理装置は、補償サービスへの加入申請を受け付けると、ステップＳ１の予約要求に対する補償サービスへの施設事業者の加入処理を行う（ステップＳ９）。これにより、施設事業者は、掛け金を支払った後、ユーザによって予約がキャンセルされた場合に、そのキャンセルで発生した損害の補償を受けることができる。

【0023】

このように、実施形態に係る情報処理装置は、予約に関する情報である予約情報を取得し、かかる予約情報に基づいて、個々の予約に対するキャンセルリスクを推定することができる。そのため、予約のキャンセルのための補償サービスなどの提供が可能となり、予約のキャンセルが発生するリスクに応じた新たなサービスを施設事業者に提供することができる。

【0024】

また、実施形態に係る情報処理装置は、ユーザが施設を予約した利用日時までの期間を分割した分割期間毎のキャンセルリスクを推定する。そのため、利用日時までのキャンセルリスクをまとめて推定する場合に比べて、精度よくキャンセルリスクを推定することが可能となる。これにより、適正な金額の掛け金を決定することが可能となる。

【0025】

なお、上記のステップＳ４のキャンセルリスクの推定処理において、分割期間毎に分割せずに、利用日時までのキャンセルリスクを推定する事も可能である。この場合、ステップＳ６の掛け金の決定処理において、かかるキャンセルリスクに基づいて掛け金を決定することも可能である。

【0026】

〔２．情報処理システム〕
図２は、実施形態に係る情報処理システムの構成の一例を示す図である。図２に示すように、実施形態に係る情報処理システム１００は、情報処理装置１と、複数の端末装置２_１〜２_ｎ（ｎは２以上の整数）と、予約サーバ３と、複数の施設装置４_１〜４_ｍ（ｍは２以上の整数）と、保険業者サーバ５とを備える。保険業者サーバ５は、保険業者の装置である。

【0027】

これら情報処理装置１、複数の端末装置２_１〜２_ｎ、予約サーバ３、複数の施設装置４_１〜４_ｍ、および保険業者サーバ５は、ネットワーク６を介して有線または無線により互いに通信可能に接続される。ネットワーク６は、例えば、ＬＡＮ（Local Area Network）や、インターネットなどのＷＡＮ（Wide Area Network）である。端末装置２_１〜２_ｎは、ユーザＵ_１〜Ｕ_ｎによって操作される。

【0028】

以下においては、端末装置２_１〜２_ｎの各々を区別せずに示す場合、端末装置２と記載する。また、施設装置４_１〜４_ｍの各々を区別せずに示す場合、施設装置４と記載し、ユーザＵ_１〜Ｕ_ｎの各々を区別せずに示す場合、ユーザＵと記載する。

【0029】

端末装置２は、ユーザＵの端末装置であり、スマートフォン、タブレット型端末、ＰＤＡ（Personal Digital Assistant）、パーソナルコンピュータなどのスマートデバイス（通信端末）である。端末装置２は、ブラウザ、施設予約アプリケーションなどの各種のアプリケーションが実行可能である。端末装置２は、ブラウザ、施設予約アプリケーションなどのアプリケーションから、予約サーバ３にネットワーク６を介してアクセスし、各施設事業者が提供する施設を予約することができる。

【0030】

施設装置４は、施設事業者の装置であり、図２に示す例では、施設事業者毎に設けられる。施設事業者は、例えば、旅館、ホテル、ペンション、飲食店、マッサージ店、歯科医院、美容院などの施設を運営する事業者である。

【0031】

〔３．予約サーバ〕
図２に示すように、予約サーバ３は、通信部５０と、記憶部５１と、制御部５２とを備える。通信部５０は、ネットワーク６との間で情報の送受信を行う通信インターフェイスである。制御部５２は、通信部５０およびネットワーク６を介して、情報処理装置１、端末装置２、および施設装置４の各々との間で各種の情報を送受信することができる。

【0032】

記憶部５１は、施設予約サービスに必要な各種の情報を記憶する。記憶部５１は、例えば、フラッシュメモリ等の半導体メモリ素子、または、ＨＤＤ（Hard Disk Drive）、光ディスク等の記憶装置である。

【0033】

制御部５２は、施設装置４から施設情報を取得し、記憶部５１に記憶する。施設装置４の施設情報には、予約可能な施設の情報が含まれる。予約可能な施設の情報は、例えば、施設が宿泊施設である場合、予約可能な部屋の数、各部屋の広さ、各部屋の利用可能人数、各部屋の利用価格などの情報が含まれる。

【0034】

制御部５２は、端末装置２からアクセスがあった場合、施設の予約をするための施設情報画面の情報を端末装置２へ提供する。端末装置２は、施設情報画面の情報を不図示の表示部に表示する。施設情報画面には、例えば、上述した予約可能な施設の情報が含まれる。ユーザＵは、表示部に表示される施設情報画面を見ながら不図示の入力部への入力によって、施設の予約申請を予約サーバ３へ送信することができる。

【0035】

制御部５２は、予約申請があった場合、予約申請の対象となる施設の施設装置４へ予約申請の情報を送信する。施設装置４は、予約サーバ３から送信された予約申請の情報に基づいて、予約の可否を判定し、予約が可能であると判定した場合、予約が可能であることを示す情報を予約サーバ３へ送信する。制御部５２は、施設装置４から予約が可能であることを示す情報を取得すると、予約を確定するか否かを問い合わせる情報を端末装置２へ送信する。これにより、端末装置２の表示部には、予約確定ボタンが表示される。

【0036】

端末装置２のユーザＵが予約確定ボタンを操作すると、端末装置２から予約要求が予約サーバ３へ送信される。制御部５２は、予約要求を受け付けると、施設装置４へ予約要求があったことを示す情報を送信する。施設装置４は、予約要求があったことを示す情報を予約サーバ３から取得すると、予約を確定する。

【0037】

また、制御部５２は、予約要求を受け付けると、予約情報を情報処理装置１へ送信する。情報処理装置１へ送信される予約情報には、例えば、予約を行ったユーザＵのユーザＩＤ（identifier）、予約ＩＤ、予約の受付日時、および予約内容の情報が含まれる。予約内容の情報には、例えば、利用期間、施設名、施設の地域、利用人数、利用価格、利用部屋数、および利用する部屋の広さなどの情報が含まれる。

【0038】

また、制御部５２は、情報処理装置１から補償情報を取得すると、取得した補償情報を施設装置４へ送信する。また、制御部５２は、施設装置４から補償の申請があった場合に補償申請情報を情報処理装置１へ送信する。

【0039】

また、制御部５２は、端末装置２から予約のキャンセルがあった場合、キャンセル要求を施設装置４へ送信し、その後、予約がキャンセル済であることを示すキャンセル済情報を取得すると、情報処理装置１へキャンセル情報を送信する。

【0040】

〔４．情報処理装置〕
図３は、実施形態に係る情報処理装置の構成の一例を示す図である。図３に示すように、情報処理装置１は、通信部１０と、記憶部１１と、制御部１２（コントローラ）とを備える。以下、通信部１０、記憶部１１および制御部１２を具体的に説明する。

【0041】

〔４．１．通信部〕
通信部１０は、ネットワーク６との間で情報の送受信を行う通信インターフェイスである。制御部１２は、通信部１０およびネットワーク６を介して、端末装置２、予約サーバ３、および保険業者サーバ５の各々との間で各種の情報を送受信することができる。

【0042】

〔４．２．記憶部〕
記憶部１１は、ユーザ情報ＤＢ２０と、予約情報ＤＢ２１と、補償情報ＤＢ２２とを有する。記憶部１１は、例えば、フラッシュメモリ等の半導体メモリ素子、または、ＨＤＤ、光ディスク等の記憶装置である。

【0043】

〔４．２．１．ユーザ情報ＤＢ〕
ユーザ情報ＤＢ２０は、ユーザＵの情報であるユーザ情報を複数含むユーザ情報テーブルを有する。ユーザＵは、情報処理装置１の運営および管理を行う事業者が提供するサービスのユーザである。かかる事業者が提供するサービスは、ユーザＵに対してオンラインでサービスを提供するオンラインサービスであり、例えば、予約サーバ３の施設予約サイトで提供される施設予約サービス、電子商取引サイトで提供される電子商取引サービス、オークションサイトで提供されるオークションサービス、動画配信サイトで提供される動画配信サービス、ニュースサイトで提供されるニュース配信サービスなどが含まれる。

【0044】

図４は、実施形態に係るユーザ情報テーブルの一例を示す図である。図４に示すユーザ情報テーブル４１は、「ユーザＩＤ」、「デモグラフィック属性」、「サイコグラフィック属性」、および「行動履歴」などの情報が互いに関連付けられた情報である。

【0045】

「ユーザＩＤ」は、ユーザＵの識別情報であり、図４に示す例では、ユーザＵ_１、Ｕ_２、Ｕ_３のユーザＩＤとして「Ｕ１」、「Ｕ２」、「Ｕ３」が設定される。かかるユーザＩＤは、上述したオンラインサービスに対するユーザＵのアカウントである。なお、ユーザＩＤは、ユーザＵを識別する情報であればよく、ユーザＵが使用する端末装置２の識別情報をユーザＩＤとしてもよい。例えば、ユーザＩＤは、ＨＴＴＰ（Hypertext Transfer Protocol）クッキーで特定される識別情報であってもよい。

【0046】

「デモグラフィック属性」は、ユーザＵの人口統計学的な属性の情報である。かかる「デモグラフィック属性」は、例えば、ユーザＵの「性別」、「年齢」などの情報である。「性別」には、ユーザＵが女性である場合には「１」が設定され、ユーザＵが男性である場合には「２」が設定される。また、「年齢」には、ユーザＵの年齢が設定される。なお、「デモグラフィック属性」は、図４に示した属性の例に限られず、ユーザＵの職業、家族構成、年収、住所、出身地、学歴など様々な属性を含んでいてもよい。

【0047】

「サイコグラフィック属性」は、ユーザＵの心理学的な属性の情報であり、例えば、ユーザＵの価値観、ライフスタイル、性格、嗜好などの情報である。図４に示す例では、属性要素毎に、ユーザＵの嗜好が相対的に高い場合に「１」が設定され、それ以外の場合には「０」が設定される。また、「サイコグラフィック属性」は、図４に示した属性の例に限られず、経済、政治、野球、サッカー、その他スポーツ、スイーツ、パソコン、白物家電、家具など様々な属性を含んでいてもよい。なお、属性の情報は、０と１の２段階に限定されず、３段階以上の値であってもよい。

【0048】

「行動履歴」は、上述した各種サイトでのユーザＵの行動履歴の情報である。「行動履歴」は、例えば、施設予約サイトでの施設の予約の履歴、電子商取引サイトやオークションサイトでの商品またはサービスの購入履歴、動画配信サイトでの動画の視聴履歴、ニュースサイトで閲覧したニュースの履歴などである。また、「行動履歴」には、各サイトで提供される広告に対するアクション（例えば、クリック）などの情報が含まれる。

【0049】

〔４．２．２．予約情報ＤＢ〕
予約情報ＤＢ２１は、施設事業者の施設の予約に関する情報である予約情報を複数含む予約情報テーブルを有する。図５は、実施形態に係る予約情報テーブルの一例を示す図である。図５に示す予約情報テーブル４２は、「予約ＩＤ」、「ユーザＩＤ」、「受付日時」、「予約内容」、および「キャンセル情報」などの情報が互いに関連付けられた情報である。

【0050】

「予約ＩＤ」は、予約毎に割り当てられる固有の識別情報である。「ユーザＩＤ」は、ユーザＵ毎に割り当てられる固有の識別情報である。「受付日時」は、予約サーバ３によってユーザＵから予約を受け付けた日時を示す情報である。

【0051】

「予約内容」は、予約サーバ３によってユーザＵから受け付けられた予約の内容を示す情報である。「予約内容」には、利用期間、施設名、利用人数、施設の地域、利用価格、利用部屋数、利用する部屋の広さなどの情報が含まれる。

【0052】

利用期間は、ユーザＵが施設を利用する期間である。施設名は、ユーザＵが予約した施設の名称である。利用人数は、施設を利用する人数である。施設の地域は、ユーザＵが予約した施設が位置する地域である。

【0053】

利用価格は、予約内容に従って施設を利用した場合にユーザＵが施設事業者に支払う額である。例えば、予約された施設が宿泊施設である場合、予約の内容に飲食やマッサージなどが含まれる場合には、利用価格には、宿泊料に加え、食事やマッサージなどの料金が含まれる。また、予約された施設が飲食店の場合、利用価格は、施設内での飲食に必要な価格である。

【0054】

利用部屋数は、ユーザＵが予約した部屋の数である。利用する部屋の広さは、ユーザＵが予約した部屋の広さである。なお、予約された施設が飲食店の場合、利用部屋数に代えて、利用場所の種別（テーブル席、カウンター席、座敷など）の情報や、利用場所の広さなどが含まれる。

【0055】

「キャンセル情報」は、予約のキャンセルに関する情報であり、予約のキャンセルの有無を示す情報、および予約のキャンセルが受け付けられた日時であるキャンセル日時の情報を含む。

【0056】

〔４．２．３．補償情報ＤＢ〕
補償情報ＤＢ２２は、予約に対する補償サービスに関する情報である補償関連情報を複数含む補償関連情報テーブルを有する。図６は、実施形態に係る補償関連情報テーブルの一例を示す図である。図６に示す補償関連情報テーブル４３は、「予約ＩＤ」、「補償サービスの加入の有無」、「キャンセルスコア」、「掛け金」、および「補填額」などの情報が互いに関連付けられた情報である。

【0057】

「予約ＩＤ」は、予約毎に割り当てられる固有の識別情報である。「キャンセルスコア」は、制御部１２によって演算されるキャンセルスコアＳｃの情報である。図６に示す例では、キャンセルスコアＳｃを便宜上「Ｓｃ１」、「Ｓｃ２」、「Ｓｃ３」などと表しているが、キャンセルスコアＳｃは分割期間毎に数値化されたスコアである。

【0058】

「補償サービスの加入の有無」は、予約に対して施設事業者が補償サービスに加入しているか否かを示す情報である。図６に示す例では、予約ＩＤ「Ｃ１」の予約および予約ＩＤ「Ｃ３」の予約に対して各々施設事業者が補償サービスに加入しており、予約ＩＤ「Ｃ２」の予約に対して施設事業者が補償サービスに加入していないことを示している。「掛け金」は、補償サービスの掛け金の情報である。また、「補填額」は、補償サービスの補填額の情報である。

【0059】

また、図６の「補填額」に示すように、補填額には、「期間１」や「期間２」のように、それぞれ期間が設けられる。施設事業者は、「期間１」および「期間２」の範囲や、期間毎の補填額を指定することが可能である。期間１や期間２の範囲や、期間毎の補填額に応じて掛け金が更新される。

【0060】

〔４．３．制御部〕
制御部１２は、例えば、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、入出力ポートなどを有するマイクロコンピュータや各種の回路を含む。

【0061】

図３に示すように、制御部１２は、取得部３０と、生成部３１と、推定部３２と、受付部３３と、決定部３４と、管理部３５と、補償処理部３６とを備える。取得部３０、生成部３１、推定部３２、受付部３３、決定部３４、管理部３５および補償処理部３６の機能は、例えば、制御部１２のＣＰＵが制御部１２のＲＡＭ、ＲＯＭ、または記憶部１１に記憶されているプログラムを読み出して実行することにより実現される。

【0062】

なお、取得部３０、生成部３１、推定部３２、受付部３３、決定部３４、管理部３５および補償処理部３６は、それぞれ一部または全部がＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等のハードウェアで構成されてもよい。

【0063】

制御部１２は、第１補償モードおよび第２補償モードのうち設定された補償モードで動作することができる。制御部１２は、第１補償モードでは、情報処理装置１の運営者側によって補償を行う処理を行い、第２補償モードでは、保険業者が提供する保険サービスによる補償を仲介する処理を行う。なお、保険サービスは、補償サービスの一例である。補償モードは、情報処理装置１の管理者によって設定されてもよく、また、施設事業者が予約サーバ３を介して情報処理装置１に施設事業者毎に設定してもよい。

【0064】

〔４．３．１．取得部〕
取得部３０は、予約サーバ３から予約情報、補償申請情報、保険申請情報、およびキャンセル情報などを取得する。また、取得部３０は、保険業者サーバ５から保険情報および保険金支払情報などを取得する。

【0065】

取得部３０は、予約サーバ３から予約情報を取得すると、取得した予約情報を予約情報テーブル４２に追加する。予約情報には、予約ＩＤ、ユーザＩＤ、受付日時、および予約内容の情報が含まれており、これらの情報が予約情報テーブル４２に追加される。

【0066】

また、取得部３０は、予約サーバ３からキャンセル情報を取得すると、取得したキャンセル情報を予約情報テーブル４２に追加する。キャンセル情報には、予約ＩＤ、およびキャンセル日時の情報が含まれており、これらの情報に基づいて、予約のキャンセルが有りを示す情報、およびキャンセル日時の情報が予約情報テーブル４２に追加される。

【0067】

また、取得部３０は、不図示のサーバからユーザＵのユーザ情報を取得することができる。取得部３０は、ユーザ情報を取得すると、取得したユーザ情報をユーザ情報テーブル４１へ追加する。なお、取得部３０は、端末装置２からユーザ情報を取得することもでき、この場合も、取得したユーザ情報をユーザ情報テーブル４１へ追加することができる。

【0068】

〔４．３．２．生成部〕
生成部３１は、記憶部１１に記憶されたユーザ情報および予約情報を用いた機械学習を実行し、予約に対するキャンセルのリスクを評価する学習モデルであるリスク評価モデルを生成する。生成部３１は、生成したリスク評価モデルの情報を記憶部１１に記憶する。

【0069】

例えば、生成部３１は、予約に対するキャンセルの有無を目的変数（正解データ）とし、予約情報およびユーザ情報から抽出される各特徴情報を説明変数（素性）とする回帰モデルを学習モデルとして求めることができる。予約情報から抽出される特徴情報には、例えば、施設の利用期間、施設名、施設の地域、利用人数、利用価格、利用部屋数、利用する部屋の広さなどがある。

【0070】

また、ユーザ情報から抽出される特徴情報には、例えば、予約者であるユーザＵの各属性、予約者であるユーザＵの行動履歴などがある。ユーザＵの属性は、上述したデモグラフィック属性やサイコグラフィック属性である。ユーザＵの行動履歴は、サイトへのアクセス履歴、サイトでのサービスや商品の購入履歴などである。

【0071】

また、生成部３１は、記憶部１１に記憶した予約情報に基づいて、ユーザＵの予約履歴やユーザＵの他の施設の予約状況を説明変数とすることもできる。例えば、ユーザＵによる過去の施設予約のキャンセル率、ユーザＵが同じ期間に複数の施設を重複予約しているか否かの情報などである。

【0072】

生成部３１は、例えば、予約に対するキャンセルの有無を目的変数（正解データ）とし、予約情報およびユーザ情報から抽出される各特徴情報を説明変数（素性）とする回帰モデルをリスク評価モデルとして求める。例えば、生成部３１は、下記式（１）に示すような回帰モデルをリスク評価モデルとして求める。
ｙ＝ω_１・ｘ_１＋ω_２・ｘ_２＋・・・＋ω_ｎ・ｘ_ｎ ・・・（１）

【0073】

上記式（１）において、「ｘ」は、予約情報およびユーザ情報から抽出される各特徴情報に対応する説明変数である。「ｙ」は、予約に対するキャンセルの有無であり、予約に対するキャンセルがある場合には、「ｙ」＝「１」になり、予約に対するキャンセルがない場合には、「ｙ」＝「−１」または「０」になる。

【0074】

また、上記式（１）において、「ω」は、「ｘ」の係数であり、所定の重み値を示す。具体的には、「ω_１」は、「ｘ_１」の重み値であり、「ω_２」は、「ｘ_２」の重み値であり、「ω_ｎ」は、「ｘ_ｎ」の重み値である。このように、上記式（１）は、予約情報およびユーザ情報から抽出された特徴情報に対応する説明変数「ｘ」と、所定の重み値「ω」とを含む変数（例えば、「ω_１・ｘ_１」）を組合せることにより作成される。

【0075】

なお、生成部３１は、説明変数として扱う情報は、上述した例に限定されない。例えば、生成部３１は、施設の利用日の予測される天候、および施設の利用日の曜日といった情報も説明変数として扱うことができる。例えば、施設の利用日で予測される天候が悪い（例えば、暴風、台風、寒波など）とキャンセルの可能性が高くなるため、施設の利用日で予測される天候を説明変数とすることで、キャンセルリスクの推定精度を高めることができる。

【0076】

また、生成部３１は、過去の予約に対してキャンセルが発生したキャンセル日時を説明変数とすることもできる。すなわち、施設の利用日時までの期間を分割し、分割した分割期間毎のキャンセルリスクを求めることが可能となる。すなわち、キャンセルが発生する確率について時系列的な分布を求めることが可能となる。

【0077】

また、生成部３１は、施設におけるキャンセル率や、施設が属する地域（市町村、区など）のキャンセル率、施設の業界全体（ホテル業、レストラン業など）のキャンセル率を説明変数として扱うことも可能である。例えば、風評被害や災害等によって地域におけるキャンセル率が上昇する場合や、業界全体でキャンセル率が上昇した場合等に、即座にキャンセルリスクへ反映させることが可能である。したがって、キャンセルリスクの推定精度を高めることができる。

【0078】

また、生成部３１は、例えば、地域において同じ業界の予約状況を説明変数することも可能である。すなわち、地域における施設への需要が高い場合、キャンセルの発生後に、キャンセルされた予約枠が新たな予約で埋まる可能性が高く、キャンセルが発生したとしても、キャンセルに伴う損害を抑えることができる。すなわち、実際にキャンセルが発生した後のリカバリー率を考慮してキャンセルリスクを求めることも可能である。

【0079】

また、生成部３１は、季節要因や、ユーザ層を説明変数として扱うことも可能である。例えば、季節要因として、四季毎のキャンセル履歴に関するデータや、夏休みや冬休み等の長期休暇と、それ以外におけるキャンセル履歴に関するデータを説明変数とする。これにより、季節要因に基づくキャンセルリスクを反映することが可能となり、キャンセルリスクの推定精度を高めることができる。

【0080】

また、生成部３１は、周辺の施設の予約状況（例えば、予約率）、利用日時におけるイベント（音楽イベント、スポーツイベント、コミックマーケットなど）の種類毎の開催の有無などをそれぞれ説明変数とすることもできる。

【0081】

なお、生成部３１は、全ての施設に共通のリスク評価モデルを生成することもでき、ｎ（ｎは自然数）以上の施設毎や施設の種別（例えば、ホテル、旅館、ペンションなどの宿泊施設の種別、中華、和食、イタリアンなどの飲食店の種別）毎にリスク評価モデルを生成することもできる。また、生成部３１は、季節毎にリスク評価モデルを生成することもできる。また、生成部３１は、ユーザ情報を用いずにリスク評価モデルを生成することもできる。

【0082】

また、生成部３１は、ＳＶＭ（Support Vector Machine）やその他の機械学習法を用いて、リスク評価モデルを生成することもできる。また、生成部３１は、深層学習（ディープラーニング）の技術を用いてリスク評価モデルを生成することもできる。例えば、生成部３１は、ＤＮＮ（Deep Neural Network）やＲＮＮ（Recurrent Neural Network）やＣＮＮ（Convolutional Neural Network）等の種々のディープラーニングの技術を適宜用いてリスク評価モデルを生成することができる。

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

メディアインターフェイス２０７は、記録媒体２０８に格納されたプログラムまたはデータを読み取り、ＲＡＭ２０２を介してＣＰＵ２０１に提供する。ＣＰＵ２０１は、当該プログラムを、メディアインターフェイス２０７を介して記録媒体２０８からＲＡＭ２０２上にロードし、ロードしたプログラムを実行する。記録媒体２０８は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

【0128】

コンピュータ２００のＣＰＵ２０１は、ＲＡＭ２０２上にロードされたプログラムを実行することにより、上述した取得部３０、生成部３１、推定部３２、受付部３３、決定部３４、管理部３５および補償処理部３６の機能を実現することができる。また、かかる取得部３０、生成部３１、推定部３２、受付部３３、決定部３４、管理部３５および補償処理部３６は、それぞれ一部または全部がハードウェアのみで構成されてもよい。

【0129】

コンピュータ２００のＣＰＵ２０１は、プログラムを、記録媒体２０８から読み取って実行するが、他の例として、他の装置から、ネットワーク６を介してこれらのプログラムを取得してもよい。なお、ＨＤＤ２０４は、記憶部１１に対応し、記憶部１１と同様のデータを記憶する。また、ＨＤＤ２０４に代えて、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子、または、光ディスク等の記憶装置を用いてもよい。

【0130】

〔７．効果〕
実施形態に係る情報処理装置１は、施設の予約に関する情報である予約情報を取得する取得部３０と、取得部３０によって取得された予約情報に基づき、予約のキャンセルが発生するリスクを推定する推定部３２と、推定部３２によって推定された分割期間毎のリスクに基づき、キャンセルに対して補償を行う補償サービスへ施設を提供する事業者が支払う掛け金を決定する決定部３４を備える。したがって、実施形態に係る情報処理装置１によれば、予約のキャンセルに対する新たな仕組みの構築することができる。

【0131】

また、推定部３２は、施設の利用日時までの期間を分割した分割期間毎のリスクを推定し、決定部３４は、分割期間毎の前記リスクに基づいて前記掛け金を決定する。したがって、実施形態に係る情報処理装置１によれば、分割期間毎のリスクを推定することで、リスクを精度よく推定することが可能となる。

【0132】

また、補償サービスは、キャンセルが発生した場合に、施設に対して補填額を支払うサービスであって、情報処理装置１は、補填額の指定を事業者から受け付ける受付部３３をさらに備え、決定部３４は、受付部３３によって受け付けられた補填額に基づいて掛け金を決定する。したがって、実施形態に係る情報処理装置１によれば、施設事業者が望む範囲の補償サービスを提供することが可能となる。

【0133】

また、受付部３３は、分割期間毎の補填額の指定を受け付け、決定部３４は、分割期間毎に指定された補填額にそれぞれ対応する分割期間毎のリスクに応じた料率を乗算した金額の和を掛け金として決定する。したがって、実施形態に係る情報処理装置１によれば、施設事業者が希望する補償に対して最小減の掛け金を支払えばよいので、安価な掛け金で補償サービスを提供することが可能となる。

【0134】

また、推定部３２は、予約を行ったユーザのキャンセル履歴、施設のキャンセル履歴、施設が属する地域のキャンセル履歴、施設が属する業界のキャンセル履歴、および季節要因の少なくとも一つに基づき、リスクを推定する。したがって、実施形態に係る情報処理装置１によれば、キャンセルが発生するリスクを精度よく推定することが可能となる。

【0135】

また、情報処理装置１は、事業者から補償サービスへの加入申請を受け付けることで、補償サービスへの加入状況を管理する管理部３５を備える。したがって、実施形態に係る情報処理装置１によれば、施設のキャンセルに対する補償を行う補償サービスを施設事業者に提供することができる。

【0136】

また、管理部３５は、予約毎に加入申請を受け付ける。したがって、実施形態に係る情報処理装置１によれば、施設事業者に対する利便性を向上させることができる。

【0137】

また、管理部３５は、複数の予約に対応する補償サービスへの加入申請である一括申請を受け付ける。したがって、実施形態に係る情報処理装置１によれば、施設事業者に対する利便性を向上させることができる。

【0138】

また、決定部３４は、管理部３５によって一括申請が受け付けられた場合に、予約毎に掛け金を決定し、管理部３５は、掛け金が予め指定された所定範囲内に収まる場合、当該掛け金にて補償サービスへ加入させる。したがって、実施形態に係る情報処理装置１によれば、施設事業者に対する利便性を向上させることができる。

【0139】

また、管理部３５は、掛け金が所定範囲から逸脱する場合に、事業者に対して通知する。したがって、実施形態に係る情報処理装置１によれば、施設事業者に対する利便性を向上させることができる。

【0140】

また、管理部３５は、加入申請を受け付けた場合に、補償サービスとして保険サービスを提供する保険業者へ保険サービスへの加入申請を示す情報を提供する。したがって、実施形態に係る情報処理装置１によれば、保険業者と連携した補償サービスを施設事業者に提供することができる。

【0141】

また、上述した情報処理装置１は、それぞれ複数のサーバコンピュータで実現してもよく、また、機能によっては外部のプラットフォーム等をＡＰＩ（Application Programming Interface）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。

【0142】

また、上記してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。

【0143】

以上、上記実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されない。上記実施形態に多様な変更または改良を加えることが可能であることが当業者には明らかである。また、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

【符号の説明】

【0144】

１ 情報処理装置
２，２_１〜２_ｎ 端末装置
３ 予約サーバ
４，４_１〜４_ｍ 施設装置
５ 保険業者サーバ
６ ネットワーク
１０，５０ 通信部
１１，５１ 記憶部
１２，５２ 制御部
２０ ユーザ情報ＤＢ
２１ 予約情報ＤＢ
２２ 補償情報ＤＢ
３０ 取得部
３１ 生成部
３２ 推定部
３３ 受付部
３４ 決定部
３５ 管理部
３６ 補償処理部
４１ ユーザ情報テーブル
４２ 予約情報テーブル
４３ 補償関連情報テーブル
１００ 情報処理システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図8】

【図9】

【図10】

【図11】