(57)【要約】【課題】予約のキャンセルに対する新たな仕組みを構築すること。【解決手段】本願に係る情報処理装置は、取得部と、推定部と、通知部とを備える。取得部は、施設の予約に関する予約情報を取得する。推定部は、取得部によって取得された予約情報に基づいて予約のキャンセルが発生するリスクを推定する。通知部は、推定部によって推定されたリスクの推移に基づき、キャンセルに対して補償を行う補償サービスへの加入を推奨する推奨情報を施設を提供する事業者へ通知する。【選択図】図３
2020030472.tif 000002
【特許請求の範囲】
【請求項１】
施設の予約に関する予約情報を取得する取得部と、
前記取得部によって取得された前記予約情報に基づいて前記予約のキャンセルが発生するリスクを推定する推定部と、
前記推定部によって推定された前記リスクの推移に基づき、前記キャンセルに対して補償を行う補償サービスへの加入を推奨する推奨情報を前記施設を提供する事業者へ通知する通知部と
を備えることを特徴とする情報処理装置。
【請求項２】
前記通知部は、
前記推奨情報をプッシュ通知すること
を特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記通知部は、
前記予約の発注時に前記補償サービスへの新規加入に関する情報を通知し、前記発注時の前記リスクを基準として、現在の前記リスクが変動した場合に、前記推奨情報を通知すること
を特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記通知部は、
前記予約について前記リスクが上方修正された場合に、前記推奨情報を通知すること
を特徴とする請求項１、２または３に記載の情報処理装置。
【請求項５】
前記通知部は、
前記補償サービスへ加入していない前記予約について前記リスクが下方修正された場合に、前記推奨情報を通知すること
を特徴とする請求項１〜４のいずれか一つに記載の情報処理装置。
【請求項６】
前記施設を提供する事業者から前記補償サービスへの加入申請を受け付けることで、前記補償サービスの加入状況を管理する管理部
を備えることを特徴とする請求項１〜５のいずれか一つに記載の情報処理装置。
【請求項７】
前記管理部は、
前記補償サービスへの加入申請へ受け付けた場合に、前記補償サービスとして保険サービスを提供する保険業者の装置へ前記保険サービスへの加入申請を示す情報を提供する
ことを特徴とする請求項６に記載の情報処理装置。
【請求項８】
コンピュータが実行する情報処理方法であって、
施設の予約に関する予約情報を取得する取得工程と、
前記取得工程によって取得された前記予約情報に基づいて前記予約のキャンセルが発生するリスクを推定する推定工程と、
前記推定工程によって推定された前記リスクの推移に基づき、前記キャンセルに対して補償を行う補償サービスへの加入を推奨する推奨情報を前記施設を提供する事業者へ通知する通知工程と
を含むことを特徴とする情報処理方法。
【請求項９】
施設の予約に関する予約情報を取得する取得手順と、
前記取得手順によって取得された前記予約情報に基づく前記予約のキャンセルが発生するリスクを推定する推定手順と、
前記推定手順によって推定された前記リスクの推移に基づき、前記キャンセルに対して補償を行う補償サービスへの加入を推奨する推奨情報を前記施設を提供する事業者へ通知する通知手順と
をコンピュータに実行させることを特徴とする情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法および情報処理プログラムに関する。
【背景技術】
【０００２】
従来、旅館、ホテル、飲食店などの施設を利用しようとするユーザは、一般にインターネットや電話などを通じて施設を予約することができる。施設事業者は、予約を行ったユーザに対して規約として前受金や解約料を要求する場合もあるが、ユーザが前受金や解約料を支払わずにキャンセルすることも多く、施設事業者側に損害が発生することがある。
【０００３】
そこで、特許文献１には、施設利用予約システムへユーザから施設の予約があったときは、ユーザから前受金をカードによって徴収し、予約がキャンセルされたときは前受金を施設事業者側に解約料として支払う技術が提案されている。かかる施設利用予約システムでは、ユーザから前受金を徴収することから、予約がキャンセルされた場合において損害の発生を防止することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−１９６４０６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、一律に前受金や解約料を要求すると、キャンセルを行わないようなユーザであっても上記施設利用予約システムを利用した予約を躊躇し予約を控えるといった事態が発生する可能性がある。
【０００６】
本願は、上記に鑑みてなされたものであって、予約のキャンセルに対する新たな仕組みの構築を可能とする情報処理装置、情報処理方法および情報処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本願に係る情報処理装置は、取得部と、推定部と、通知部とを備える。前記取得部は、施設の予約に関する予約情報を取得する。前記推定部は、前記取得部によって取得された前記予約情報に基づく前記予約のキャンセルが発生するリスクを推定する。前記通知部は、前記推定部によって推定された前記リスクの推移に基づき、前記キャンセルに対して補償を行う補償サービスへの加入を推奨する推奨情報を前記施設を提供する事業者へ通知する。
【発明の効果】
【０００８】
実施形態の一態様によれば、予約のキャンセルに対する新たな仕組みを構築することができる。
【図面の簡単な説明】
【０００９】
【図１】図１は、実施形態に係る情報処理の説明図である。
【図２】図２は、実施形態に係る情報処理システムの構成の一例を示す図である。
【図３】図３は、実施形態に係る情報処理装置の構成の一例を示す図である。
【図４】図４は、実施形態に係るユーザ情報テーブルの一例を示す図である。
【図５】図５は、実施形態に係る予約情報テーブルの一例を示す図である。
【図６】図６は、実施形態に係る補償関連情報テーブルの一例を示す図である。
【図７Ａ】図７Ａは、通知部による処理の一例を示す図（その１）である。
【図７Ｂ】図７Ｂは、通知部による処理の一例を示す図（その２）である。
【図７Ｃ】図７Ｃは、通知部による処理の一例を示す図（その３）である。
【図７Ｄ】図７Ｄは、通知部による処理の一例を示す図（その４）である。
【図８】図８は、実施形態に係る情報処理装置が実行する処理手順を示すフローチャートである。
【図９】図９は、実施形態に係るプログラムを実行するコンピュータのハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００１０】
以下に、本願に係る情報処理装置、情報処理方法および情報処理プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報処理装置、情報処理方法および情報処理プログラムが限定されるものではない。
【００１１】
〔１．情報処理〕
図１を用いて、実施形態に係る情報処理について説明する。図１は、実施形態に係る情報処理の説明図である。
【００１２】
図１に示すように、ユーザが予約サーバに対し施設利用の予約を要求する予約要求を行うと（ステップＳ１）、予約サーバは、ユーザからの予約要求を受け付けて、予約要求に基づいて、予約要求にかかる予約を登録する（ステップＳ２）。また、予約サーバは、施設利用の予約に関する情報である予約情報を情報処理装置へ送信する（ステップＳ３）。
【００１３】
情報処理装置は、予約サーバから予約情報を取得すると、取得された予約情報に基づいて、予約のキャンセルが発生するリスク（以下、キャンセルリスクと記載する）を推定するリスク推定処理を行う（ステップＳ４）。かかるリスク推定処理は、予約毎に行われる。
【００１４】
情報処理装置は、リスク評価モデルを記憶している。情報処理装置は、かかるリスク評価モデルによってキャンセルリスクのスコア（以下、キャンセルスコアＳｃと記載する）を演算することができる。かかるキャンセルスコアＳｃがキャンセルリスクの推定値であり、例えば、キャンセルが発生するキャンセル確率である。
【００１５】
リスク評価モデルは、例えば、過去の予約情報を説明変数とし、過去のキャンセルの有無を教師データ（目的変数）として生成される。予約情報には、例えば、予約された施設の地域、予約された施設の利用期間、利用価格、利用される部屋の数や広さの情報が含まれており、これらの情報を説明変数としてリスク評価モデルを生成することができる。
【００１６】
さらに、予約情報から得られる特徴情報に加え、予約したユーザの情報から得られる特徴情報を説明変数としてリスク評価モデルを生成することができる。予約情報には、ユーザの識別情報が含まれており、情報処理装置は、ユーザの識別情報に基づいて、ユーザの属性や行動履歴の情報を取得し、取得したユーザの属性や行動履歴を説明変数とすることができる。なお、予約情報に含まれるユーザの情報に、ユーザの属性や行動履歴の情報が含まれていてもよい。
【００１７】
続いて、情報処理装置は、補償情報を予約サーバを介して施設を提供する事業者（以下、施設事業者と記載する）へ通知する（ステップＳ５）。補償情報は、予約のキャンセルが発生した場合に、キャンセルに対して補償を行う補償サービスの加入に関する情報である。
【００１８】
例えば、補償情報は、キャンセルが発生した場合に、施設へ支払われる補填額や、施設側が補償サービスへ予め支払う掛け金に関する情報が含まれる。また、補填額や掛け金は、キャンセルリスクに基づいて設定される。
【００１９】
情報処理装置は、キャンセルリスクの推移に基づき、施設事業者へ補償サービスへの加入を推奨する推奨情報を通知する（ステップＳ６）。これは、キャンセルリスクが、刻一刻と変化し、予約の発注時からキャンセルリスクが上昇したり、あるいは、下降したりする場合があるためである。
【００２０】
つまり、情報処理装置は、予約を発注後のキャンセルリスクの変化に応じて、補償サービスへの新規加入や、追加加入を推奨する推奨情報を施設事業者へ通知することができる。
【００２１】
施設事業者は、推奨情報の内容を確認し、補償サービスへの加入の可否の判断を行う。施設事業者は、補償サービスへの加入を決定すると、予約サーバを介して情報処理装置へ補償サービスへの加入申請を行う（ステップＳ７）。
【００２２】
情報処理装置は、補償サービスへの加入申請を受け付けると、ステップＳ１の予約要求に対する補償サービスへの施設事業者の加入処理を行う（ステップＳ８）。これにより、施設事業者は、掛け金を支払った後、ユーザによって予約がキャンセルされた場合に、かかるキャンセルで発生した損害の補償を受けることができる。
【００２３】
このように、実施形態に係る情報処理装置は、予約に関する情報である予約情報を取得し、かかる予約情報に基づいて、個々の予約に対するキャンセルリスクを推定することができる。そのため、予約のキャンセルのための補償サービスなどの提供が可能となり、予約のキャンセルが発生するリスクに応じた新たなサービスを施設事業者に提供することができる。
【００２４】
また、実施形態に係る情報処理装置は、予約発注後のキャンセルリスクの推移に応じて、補償サービスへの加入を推奨する推奨情報を施設事業者へ通知する。そのため、キャンセルリスクの変化に応じて、最適な補償サービスへの加入を提案することが可能となり、より良い補償サービスを提供することが可能となる。
【００２５】
〔２．情報処理システム〕
図２は、実施形態に係る情報処理システムの構成の一例を示す図である。図２に示すように、実施形態に係る情報処理システム１００は、情報処理装置１と、複数の端末装置２１〜２ｎ（ｎは２以上の整数）と、予約サーバ３と、複数の施設装置４１〜４ｍ（ｍは２以上の整数）と、保険業者サーバ５とを備える。保険業者サーバ５は、保険業者の装置である。
【００２６】
これら情報処理装置１、複数の端末装置２１〜２ｎ、予約サーバ３、複数の施設装置４１〜４ｍ、および保険業者サーバ５は、ネットワーク６を介して有線または無線により互いに通信可能に接続される。ネットワーク６は、例えば、ＬＡＮ（Local  Area  Network）や、インターネットなどのＷＡＮ（Wide  Area  Network）である。端末装置２１〜２ｎは、ユーザＵ１〜Ｕｎによって操作される。
【００２７】
以下においては、端末装置２１〜２ｎの各々を区別せずに示す場合、端末装置２と記載する。また、施設装置４１〜４ｍの各々を区別せずに示す場合、施設装置４と記載し、ユーザＵ１〜Ｕｎの各々を区別せずに示す場合、ユーザＵと記載する。
【００２８】
端末装置２は、ユーザＵの端末装置であり、スマートフォン、タブレット型端末、ＰＤＡ（Personal  Digital  Assistant）、パーソナルコンピュータなどのスマートデバイス（通信端末）である。端末装置２は、ブラウザ、施設予約アプリケーションなどの各種のアプリケーションが実行可能である。端末装置２は、ブラウザ、施設予約アプリケーションなどのアプリケーションから、予約サーバ３にネットワーク６を介してアクセスし、各施設事業者が提供する施設を予約することができる。
【００２９】
施設装置４は、施設事業者の装置であり、図２に示す例では、施設事業者毎に設けられる。施設事業者は、例えば、旅館、ホテル、ペンション、飲食店、マッサージ店、歯科医院、美容院などの施設を運営する事業者である。
【００３０】
〔３．予約サーバ〕
図２に示すように、予約サーバ３は、通信部５０と、記憶部５１と、制御部５２とを備える。通信部５０は、ネットワーク６との間で情報の送受信を行う通信インターフェイスである。制御部５２は、通信部５０およびネットワーク６を介して、情報処理装置１、端末装置２、および施設装置４の各々との間で各種の情報を送受信することができる。
【００３１】
記憶部５１は、施設予約サービスに必要な各種の情報を記憶する。記憶部５１は、例えば、フラッシュメモリ等の半導体メモリ素子、または、ＨＤＤ（Hard  Disk  Drive）、光ディスク等の記憶装置である。
【００３２】
制御部５２は、施設装置４から施設情報を取得し、記憶部５１に記憶する。施設装置４の施設情報には、予約可能な施設の情報が含まれる。予約可能な施設の情報は、例えば、施設が宿泊施設である場合、予約可能な部屋の数、各部屋の広さ、各部屋の利用可能人数、各部屋の利用価格などの情報が含まれる。
【００３３】
制御部５２は、端末装置２からアクセスがあった場合、施設の予約をするための施設情報画面の情報を端末装置２へ提供する。端末装置２は、施設情報画面の情報を不図示の表示部に表示する。施設情報画面には、例えば、上述した予約可能な施設の情報が含まれる。ユーザＵは、表示部に表示される施設情報画面を見ながら不図示の入力部への入力によって、施設の予約申請を予約サーバ３へ送信することができる。
【００３４】
制御部５２は、予約申請があった場合、予約申請の対象となる施設の施設装置４へ予約申請の情報を送信する。施設装置４は、予約サーバ３から送信された予約申請の情報に基づいて、予約の可否を判定し、予約が可能であると判定した場合、予約が可能であることを示す情報を予約サーバ３へ送信する。制御部５２は、施設装置４から予約が可能であることを示す情報を取得すると、予約を確定するか否かを問い合わせる情報を端末装置２へ送信する。これにより、端末装置２の表示部には、予約確定ボタンが表示される。
【００３５】
端末装置２のユーザＵが予約確定ボタンを操作すると、端末装置２から予約要求が予約サーバ３へ送信される。制御部５２は、予約要求を受け付けると、施設装置４へ予約要求があったことを示す情報を送信する。施設装置４は、予約要求があったことを示す情報を予約サーバ３から取得すると、予約を確定する。
【００３６】
また、制御部５２は、予約要求を受け付けると、予約情報を情報処理装置１へ送信する。情報処理装置１へ送信される予約情報には、例えば、予約を行ったユーザＵのユーザＩＤ（identifier）、予約ＩＤ、予約の受付日時、および予約内容の情報が含まれる。予約内容の情報には、例えば、利用期間、施設名、施設の地域、利用人数、利用価格、利用部屋数、および利用する部屋の広さなどの情報が含まれる。
【００３７】
また、制御部５２は、情報処理装置１から補償情報を取得すると、取得した補償情報を施設装置４へ送信する。また、制御部５２は、施設装置４から補償の申請があった場合に補償申請情報を情報処理装置１へ送信する。
【００３８】
また、制御部５２は、端末装置２から予約のキャンセルがあった場合、キャンセル要求を施設装置４へ送信し、その後、予約がキャンセル済であることを示すキャンセル済情報を取得すると、情報処理装置１へキャンセル情報を送信する。
【００３９】
〔４．情報処理装置〕
図３は、実施形態に係る情報処理装置の構成の一例を示す図である。図３に示すように、情報処理装置１は、通信部１０と、記憶部１１と、制御部１２（コントローラ）とを備える。以下、通信部１０、記憶部１１および制御部１２を具体的に説明する。
【００４０】
〔４．１．通信部〕
通信部１０は、ネットワーク６との間で情報の送受信を行う通信インターフェイスである。制御部１２は、通信部１０およびネットワーク６を介して、端末装置２、予約サーバ３、および保険業者サーバ５の各々との間で各種の情報を送受信することができる。
【００４１】
〔４．２．記憶部〕
記憶部１１は、ユーザ情報ＤＢ２０と、予約情報ＤＢ２１と、補償情報ＤＢ２２とを有する。記憶部１１は、例えば、フラッシュメモリ等の半導体メモリ素子、または、ＨＤＤ、光ディスク等の記憶装置である。
【００４２】
〔４．２．１．ユーザ情報ＤＢ〕
ユーザ情報ＤＢ２０は、ユーザＵの情報であるユーザ情報を複数含むユーザ情報テーブルを有する。ユーザＵは、情報処理装置１の運営および管理を行う事業者が提供するサービスのユーザである。かかる事業者が提供するサービスは、ユーザＵに対してオンラインでサービスを提供するオンラインサービスであり、例えば、予約サーバ３の施設予約サイトで提供される施設予約サービス、電子商取引サイトで提供される電子商取引サービス、オークションサイトで提供されるオークションサービス、動画配信サイトで提供される動画配信サービス、ニュースサイトで提供されるニュース配信サービスなどが含まれる。
【００４３】
図４は、実施形態に係るユーザ情報テーブルの一例を示す図である。図４に示すユーザ情報テーブル４１は、「ユーザＩＤ」、「デモグラフィック属性」、「サイコグラフィック属性」、および「行動履歴」などの情報が互いに関連付けられた情報である。
【００４４】
「ユーザＩＤ」は、ユーザＵの識別情報であり、図４に示す例では、ユーザＵ１、Ｕ２、Ｕ３のユーザＩＤとして「Ｕ１」、「Ｕ２」、「Ｕ３」が設定される。かかるユーザＩＤは、上述したオンラインサービスに対するユーザＵのアカウントである。なお、ユーザＩＤは、ユーザＵを識別する情報であればよく、ユーザＵが使用する端末装置２の識別情報をユーザＩＤとしてもよい。例えば、ユーザＩＤは、ＨＴＴＰ（Hypertext  Transfer  Protocol）クッキーで特定される識別情報であってもよい。
【００４５】
「デモグラフィック属性」は、ユーザＵの人口統計学的な属性の情報である。かかる「デモグラフィック属性」は、例えば、ユーザＵの「性別」、「年齢」などの情報である。「性別」には、ユーザＵが女性である場合には「１」が設定され、ユーザＵが男性である場合には「２」が設定される。また、「年齢」には、ユーザＵの年齢が設定される。なお、「デモグラフィック属性」は、図４に示した属性の例に限られず、ユーザＵの職業、家族構成、年収、住所、出身地、学歴など様々な属性を含んでいてもよい。
【００４６】
「サイコグラフィック属性」は、ユーザＵの心理学的な属性の情報であり、例えば、ユーザＵの価値観、ライフスタイル、性格、嗜好などの情報である。図４に示す例では、属性要素毎に、ユーザＵの嗜好が相対的に高い場合に「１」が設定され、それ以外の場合には「０」が設定される。また、「サイコグラフィック属性」は、図４に示した属性の例に限られず、経済、政治、野球、サッカー、その他スポーツ、スイーツ、パソコン、白物家電、家具など様々な属性を含んでいてもよい。なお、属性の情報は、０と１の２段階に限定されず、３段階以上の値であってもよい。
【００４７】
「行動履歴」は、上述した各種サイトでのユーザＵの行動履歴の情報である。「行動履歴」は、例えば、施設予約サイトでの施設の予約の履歴、電子商取引サイトやオークションサイトでの商品またはサービスの購入履歴、動画配信サイトでの動画の視聴履歴、ニュースサイトで閲覧したニュースの履歴などである。また、「行動履歴」には、各サイトで提供される広告に対するアクション（例えば、クリック）などの情報が含まれる。
【００４８】
〔４．２．２．予約情報ＤＢ〕
予約情報ＤＢ２１は、施設事業者の施設の予約に関する情報である予約情報を複数含む予約情報テーブルを有する。図５は、実施形態に係る予約情報テーブルの一例を示す図である。図５に示す予約情報テーブル４２は、「予約ＩＤ」、「ユーザＩＤ」、「受付日時」、「予約内容」、および「キャンセル情報」などの情報が互いに関連付けられた情報である。
【００４９】
「予約ＩＤ」は、予約毎に割り当てられる固有の識別情報である。「ユーザＩＤ」は、ユーザＵ毎に割り当てられる固有の識別情報である。「受付日時」は、予約サーバ３によってユーザＵから予約を受け付けた日時を示す情報である。
【００５０】
「予約内容」は、予約サーバ３によってユーザＵから受け付けられた予約の内容を示す情報である。「予約内容」には、利用期間、施設名、利用人数、施設の地域、利用価格、利用部屋数、利用する部屋の広さなどの情報が含まれる。
【００５１】
利用期間は、ユーザＵが施設を利用する期間である。施設名は、ユーザＵが予約した施設の名称である。利用人数は、施設を利用する人数である。施設の地域は、ユーザＵが予約した施設が位置する地域である。
【００５２】
利用価格は、予約内容に従って施設を利用した場合にユーザＵが施設事業者に支払う額である。例えば、予約された施設が宿泊施設である場合、予約の内容に飲食やマッサージなどが含まれる場合には、利用価格には、宿泊料に加え、食事やマッサージなどの料金が含まれる。また、予約された施設が飲食店の場合、利用価格は、施設内での飲食に必要な価格である。
【００５３】
利用部屋数は、ユーザＵが予約した部屋の数である。利用する部屋の広さは、ユーザＵが予約した部屋の広さである。なお、予約された施設が飲食店の場合、利用部屋数に代えて、利用場所の種別（テーブル席、カウンター席、座敷など）の情報や、利用場所の広さなどが含まれる。
【００５４】
「キャンセル情報」は、予約のキャンセルに関する情報であり、予約のキャンセルの有無を示す情報、および予約のキャンセルが受け付けられた日時であるキャンセル日時の情報を含む。
【００５５】
〔４．２．３．補償情報ＤＢ〕
補償情報ＤＢ２２は、予約に対する補償サービスに関する情報である補償関連情報を複数含む補償関連情報テーブルを有する。図６は、実施形態に係る補償関連情報テーブルの一例を示す図である。図６に示す補償関連情報テーブル４３は、「予約ＩＤ」、「補償サービスの加入の有無」、「キャンセルスコア」、「掛け金」、および「補填額」などの情報が互いに関連付けられた情報である。
【００５６】
「予約ＩＤ」は、予約毎に割り当てられる固有の識別情報である。「キャンセルスコア」は、制御部１２によって演算されるキャンセルスコアＳｃの情報である。図６に示す例では、キャンセルスコアＳｃを便宜上「Ｓｃ１」、「Ｓｃ２」、「Ｓｃ３」などと表しているが、キャンセルスコアＳｃは数値化されたスコアである。
【００５７】
「補償サービスの加入の有無」は、予約に対して施設事業者が補償サービスに加入しているか否かを示す情報である。図６に示す例では、予約ＩＤ「Ｃ１」の予約および予約ＩＤ「Ｃ３」の予約に対して各々施設事業者が補償サービスに加入しており、予約ＩＤ「Ｃ２」の予約に対して施設事業者が補償サービスに加入していないことを示している。「掛け金」は、補償サービスの掛け金の情報である。また、「補填額」は、補償サービスの補填額の情報である。
【００５８】
また、図６に示すように、キャンセルスコアＳｃや、掛け金には、「発注時」および「現在」に対応する項目があり、「発注時」は、施設に対する予約の発注時におけるキャンセルスコアＳｃまたは掛け金をそれぞれ示す。また、「現在」は、現在におけるキャンセルスコアＳｃまたは掛け金を示す。「現在」に対応するキャンセルスコアＳｃまたは掛け金は、随時更新される。なお、補填額がキャンセルスコアＳｃに応じて変動する場合、補填額についても「発注時」と「現在」との項目をそれぞれ記録することにしてもよい。
【００５９】
〔４．３．制御部〕
制御部１２は、例えば、ＣＰＵ（Central  Processing  Unit）、ＲＯＭ（Read  Only  Memory）、ＲＡＭ（Random  Access  Memory）、入出力ポートなどを有するマイクロコンピュータや各種の回路を含む。
【００６０】
図３に示すように、制御部１２は、取得部３０と、生成部３１と、推定部３２と、決定部３３と、通知部３４と、管理部３５と、補償処理部３６とを備える。取得部３０、生成部３１、推定部３２、決定部３３、通知部３４、管理部３５および補償処理部３６の機能は、例えば、制御部１２のＣＰＵが制御部１２のＲＡＭ、ＲＯＭ、または記憶部１１に記憶されているプログラムを読み出して実行することにより実現される。
【００６１】
なお、取得部３０、生成部３１、推定部３２、決定部３３、通知部３４、管理部３５および補償処理部３６は、それぞれ一部または全部がＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）等のハードウェアで構成されてもよい。
【００６２】
制御部１２は、第１補償モードおよび第２補償モードのうち設定された補償モードで動作することができる。制御部１２は、第１補償モードでは、情報処理装置１の運営者側によって補償を行う処理を行い、第２補償モードでは、保険業者の保険による補償を仲介する処理を行う。補償モードは、情報処理装置１の管理者によって設定されてもよく、また、施設事業者が予約サーバ３を介して情報処理装置１に施設事業者毎に設定してもよい。
【００６３】
〔４．３．１．取得部〕
取得部３０は、予約サーバ３から予約情報、補償申請情報、保険申請情報、およびキャンセル情報などを取得する。また、取得部３０は、保険業者サーバ５から保険情報および保険金支払情報などを取得する。
【００６４】
取得部３０は、予約サーバ３から予約情報を取得すると、取得した予約情報を予約情報テーブル４２に追加する。予約情報には、予約ＩＤ、ユーザＩＤ、受付日時、および予約内容の情報が含まれており、これらの情報が予約情報テーブル４２に追加される。
【００６５】
また、取得部３０は、予約サーバ３からキャンセル情報を取得すると、取得したキャンセル情報を予約情報テーブル４２に追加する。キャンセル情報には、予約ＩＤ、およびキャンセル日時の情報が含まれており、これらの情報に基づいて、予約のキャンセルが有りを示す情報、およびキャンセル日時の情報が予約情報テーブル４２に追加される。
【００６６】
また、取得部３０は、不図示のサーバからユーザＵのユーザ情報を取得することができる。取得部３０は、ユーザ情報を取得すると、取得したユーザ情報をユーザ情報テーブル４１へ追加する。なお、取得部３０は、端末装置２からユーザ情報を取得することもでき、この場合も、取得したユーザ情報をユーザ情報テーブル４１へ追加することができる。
【００６７】
〔４．３．２．生成部〕
生成部３１は、記憶部１１に記憶されたユーザ情報および予約情報を用いた機械学習を実行し、予約に対するキャンセルのリスクを評価する学習モデルであるリスク評価モデルを生成する。生成部３１は、生成したリスク評価モデルの情報を記憶部１１に記憶する。
【００６８】
例えば、生成部３１は、予約に対するキャンセルの有無を目的変数（正解データ）とし、予約情報およびユーザ情報から抽出される各特徴情報を説明変数（素性）とする回帰モデルを学習モデルとして求めることができる。予約情報から抽出される特徴情報には、例えば、施設の利用期間、施設名、施設の地域、利用人数、利用価格、利用部屋数、利用する部屋の広さなどがある。
【００６９】
また、ユーザ情報から抽出される特徴情報には、例えば、予約者であるユーザＵの各属性、予約者であるユーザＵの行動履歴などがある。ユーザＵの属性は、上述したデモグラフィック属性やサイコグラフィック属性である。ユーザＵの行動履歴は、サイトへのアクセス履歴、サイトでのサービスや商品の購入履歴などである。
【００７０】
また、生成部３１は、記憶部１１に記憶した予約情報に基づいて、ユーザＵの予約履歴やユーザＵの他の施設の予約状況を説明変数とすることもできる。例えば、ユーザＵによる過去の施設予約のキャンセル率、ユーザＵが同じ期間に複数の施設を重複予約しているか否かの情報などである。
【００７１】
生成部３１は、例えば、予約に対するキャンセルの有無を目的変数（正解データ）とし、予約情報およびユーザ情報から抽出される各特徴情報を説明変数（素性）とする回帰モデルをリスク評価モデルとして求める。例えば、生成部３１は、下記式（１）に示すような回帰モデルをリスク評価モデルとして求める。
ｙ＝ω１・ｘ１＋ω２・ｘ２＋・・・＋ωｎ・ｘｎ      ・・・（１）
【００７２】
上記式（１）において、「ｘ」は、予約情報およびユーザ情報から抽出される各特徴情報に対応する説明変数である。「ｙ」は、予約に対するキャンセルの有無であり、予約に対するキャンセルがある場合には、「ｙ」＝「１」になり、予約に対するキャンセルがない場合には、「ｙ」＝「−１」または「０」になる。
【００７３】
また、上記式（１）において、「ω」は、「ｘ」の係数であり、所定の重み値を示す。具体的には、「ω１」は、「ｘ１」の重み値であり、「ω２」は、「ｘ２」の重み値であり、「ωｎ」は、「ｘｎ」の重み値である。このように、上記式（１）は、予約情報およびユーザ情報から抽出された特徴情報に対応する説明変数「ｘ」と、所定の重み値「ω」とを含む変数（例えば、「ω１・ｘ１」）を組合せることにより作成される。
【００７４】
なお、生成部３１は、説明変数として扱う情報は、上述した例に限定されない。例えば、生成部３１は、施設の利用日の予測される天候、および施設の利用日の曜日といった情報も説明変数として扱うことができる。例えば、施設の利用日で予測される天候が悪い（例えば、暴風、台風、寒波など）とキャンセルの可能性が高くなるため、施設の利用日で予測される天候を説明変数とすることで、キャンセルリスクの推定精度を高めることができる。
【００７５】
また、生成部３１は、受付日時と利用日時との差を説明変数とすることもできる。これは、受付日時と利用日時との差でキャンセルの確率が変わることがあるためである。例えば、受付日時が利用日時の直前である場合、受付日時が利用日時から離れている場合に比べて、予約がキャンセルされる可能性は低い。そのため、受付日時と利用日時との差を説明変数とすることで、キャンセルリスクの推定精度を高めることができる。
【００７６】
なお、生成部３１は、説明変数として扱う情報は、上述した例に限定されない。例えば、生成部３１は、施設の利用日の予測される天候、および施設の利用日の曜日といった情報も説明変数として扱うことができる。例えば、施設の利用日で予測される天候が悪い（例えば、暴風、台風、寒波など）とキャンセルの可能性が高くなるため、施設の利用日で予測される天候を説明変数とすることで、キャンセルリスクの推定精度を高めることができる。
【００７７】
また、生成部３１は、過去の予約に対してキャンセルが発生したキャンセル日時を説明変数とすることもできる。すなわち、施設の利用日時までの期間を分割し、分割した分割期間毎のキャンセルリスクを求めることが可能となる。すなわち、キャンセルが発生する確率について時系列的な分布を求めることが可能となる。
【００７８】
また、生成部３１は、施設におけるキャンセル率や、施設が属する地域（市町村、区など）のキャンセル率、施設の業界全体（ホテル業、レストラン業など）のキャンセル率を説明変数として扱うことも可能である。例えば、風評被害や災害等によって地域におけるキャンセル率が上昇する場合や、業界全体でキャンセル率が上昇した場合等に、即座にキャンセルリスクへ反映させることが可能である。したがって、キャンセルリスクの推定精度を高めることができる。
【００７９】
また、生成部３１は、例えば、地域において同じ業界の予約状況を説明変数することも可能である。すなわち、地域における施設への需要が高い場合、キャンセルの発生後に、キャンセルされた予約枠が新たな予約で埋まる可能性が高く、キャンセルが発生したとしても、キャンセルに伴う損害を抑えることができる。すなわち、実際にキャンセルが発生した後のリカバリー率を考慮してキャンセルリスクを求めることも可能である。
【００８０】
また、生成部３１は、季節要因や、ユーザ層を説明変数として扱うことも可能である。例えば、季節要因として、四季毎のキャンセル履歴に関するデータや、夏休みや冬休み等の長期休暇と、それ以外におけるキャンセル履歴に関するデータを説明変数とする。これにより、季節要因に基づくキャンセルリスクを反映することが可能となり、キャンセルリスクの推定精度を高めることができる。
【００８１】
また、生成部３１は、周辺の施設の予約状況（例えば、予約率）、利用日時におけるイベント（音楽イベント、スポーツイベント、コミックマーケットなど）の種類毎の開催の有無などをそれぞれ説明変数とすることもできる。
【００８２】
なお、生成部３１は、全ての施設に共通のリスク評価モデルを生成することもでき、ｎ（ｎは自然数）以上の施設毎や施設の種別（例えば、ホテル、旅館、ペンションなどの宿泊施設の種別、中華、和食、イタリアンなどの飲食店の種別）毎にリスク評価モデルを生成することもできる。また、生成部３１は、季節毎にリスク評価モデルを生成することもできる。また、生成部３１は、ユーザ情報を用いずにリスク評価モデルを生成することもできる。
【００８３】
また、生成部３１は、ＳＶＭ（Support  Vector  Machine）やその他の機械学習法を用いて、リスク評価モデルを生成することもできる。また、生成部３１は、深層学習（ディープラーニング）の技術を用いてリスク評価モデルを生成することもできる。例えば、生成部３１は、ＤＮＮ（Deep  Neural  Network）やＲＮＮ（Recurrent  Neural  Network）やＣＮＮ（Convolutional  Neural  Network）等の種々のディープラーニングの技術を適宜用いてリスク評価モデルを生成することができる。
【００８４】
〔４．３．３．推定部〕
推定部３２は、取得部３０によって取得された予約情報に基づいて、キャンセルリスクを推定する。例えば、推定部３２は、取得部３０によって取得された予約情報に含まれるユーザＩＤに関連付けられたユーザＵの属性情報や行動履歴を含むユーザ情報を記憶部１１から抽出する。
【００８５】
そして、推定部３２は、抽出したユーザ情報と取得部３０によって取得された予約情報から抽出される複数の特徴情報を説明変数とする上記式（１）のリスク評価モデルを用いて、キャンセルスコアＳｃを演算することができる。具体的には、推定部３２は、下記式（２）の演算によって、キャンセルスコアＳｃを演算することができる。推定部３２は、演算した結果を補償関連情報テーブル４３に追加する。
Ｓｃ＝ω１・ｘ１＋ω２・ｘ２＋・・・＋ωｎ・ｘｎ      ・・・（２）
【００８６】
すなわち、推定部３２は、図６に示した発注時にキャンセルスコアＳｃ１−１を追加し、その後、現在のキャンセルスコアＳｃ１−ｎを随時更新していくこととなる。
【００８７】
〔４．３．４．決定部〕
決定部３３は、補償モードが第１補償モードに設定されている場合に、推定部３２によって推定されたキャンセルスコアＳｃに基づいて、予約のキャンセルに対する補填額および掛け金を決定する。
【００８８】
決定部３３は、キャンセルスコアＳｃと、補填額および掛け金との関係を示す演算式またはテーブルを有しており、かかる演算式またはテーブルを用いて補償サービスにおける補填額および掛け金を求めることができる。
【００８９】
なお、決定部３３は、キャンセルスコアＳｃと予約された施設の利用価格とに基づいて、補償サービスにおける補填額および掛け金を求めることもできる。例えば、決定部３３は、キャンセルスコアＳｃと掛け金との関係を示す演算式またはテーブルを有しており、かかる演算式またはテーブルを用いてキャンセルスコアＳｃに対応する掛け金を求める。そして、決定部３３は、キャンセルスコアに対応する掛け金に、予約された施設の利用価格を乗算することで、補償サービスにおける掛け金を演算することができる。この場合、施設の利用価格が補填額となる。
【００９０】
また、決定部３３は、利用日時が受付日時に近いほど掛け金が高くなるように掛け金を決定することができる。これは、利用日時が受付日時に近いほど予約がキャンセルされたことによる損害の発生確率が高くなるからである。この場合、決定部３３は、上述のように演算した掛け金を基本掛け金として求め、基本掛け金に利用日時が受付日時に近いほど大きくなる係数を乗算することで、補償サービスにおける掛け金を求めることができる。
【００９１】
また、決定部３３は、一括補償サービスに加入している施設の予約のキャンセルに対する補償の掛け金を低くすることができる。一括補償サービスとは、予約毎に補償サービスへの加入申請をすることなく、施設の予約のキャンセルに対する補償を行うサービスであり、施設事業者によって予約サーバ３を介して情報処理装置１へ事前に加入申請が行われる。
【００９２】
決定部３３は、一括補償サービスに加入している施設の予約に対し、上述のように演算した掛け金を基本掛け金として求め、基本掛け金に割引係数（１より小さい値）を乗算することで、補償サービスにおける掛け金を求めることができる。
【００９３】
また、決定部３３は、施設事業者によって指定された補填額に基づき、掛け金を決定することも可能である。この場合、施設の利用日時までの残日数毎に、補填額の指定を受け付けることも可能である。
【００９４】
これにより、施設事業者は、予約のキャンセル発生後に、新たな予約が埋まる可能性を考慮して補填額を指定することが可能となる。決定部３３は、指定された補填額に応じた掛け金を決定することとなるので、掛け金を安く抑えることが可能となる。
【００９５】
〔４．３．５．通知部〕
通知部３４は、推定部３２によって推定されるキャンセルスコアＳｃの推移に基づき、施設事業者に対して補償サービスへの加入を推奨する推奨情報を通知する。図７Ａ〜図７Ｄは、通知部３４による処理の一例を示す図である。
【００９６】
なお、図７Ａおよび図７Ｃでは、縦軸をキャンセルスコアＳｃとし、横軸を施設の利用日時までの残日数を示す。なお、一般的に、キャンセルスコアＳｃに応じて掛け金が変動するため、キャンセルスコアＳｃを掛け金と置き換えることも可能である。
【００９７】
図７Ａに示すように、通知部３４は、予約発注時のキャンセルスコアＳｃ１−１からキャンセルスコアＳｃが増大し、現在のキャンセルスコアＳｃ１−ｎへ上方修正した場合、推奨情報を施設端末４へ通知する。
【００９８】
この場合、キャンセルスコアＳｃの増加に伴って、キャンセルが発生する確率が高くなる。また、施設事業者は、実際にキャンセルが発生した場合、掛け金を支払って補償サービスへ加入していた方が損害額が少なくなる。
【００９９】
このため、通知部３４は、推奨情報を施設端末４に対してプッシュ通知する。これにより、施設事業者へキャンセルスコアＳｃが発注時から変動したことを通知することが可能となる。
【０１００】
図７Ｂに示すように、施設端末４には、補償サービスの加入または掛け金の増額を促す文言と共に、キャンセルスコアＳｃが増大した予約ＩＤ、予約内容、現在の補償内容等が巣賞情報として通知される。
【０１０１】
なお、「現在の補償内容」は、例えば、現在の補償サービスの加入状況を示し、加入中の掛け金や、補填額に関する情報が含まれる。施設事業者は、予約毎のチェックボックスを選択し、「申請画面へ」のボタンを選択すると、予約毎に補償サービスへの新規加入や掛け金の増額を選択することできる。このとき、施設事業者は、掛け金の増額を行うと、増額した分の掛け金を追加で補償サービスへ支払うこととなる。
【０１０２】
このように、通知部３４は、キャンセルスコアＳｃが増加した場合に、施設事業者に対して推奨情報を通知することで、キャンセルスコアＳｃに応じて適切な補償サービスへの加入を推奨することが可能となる。
【０１０３】
また、図７Ｃに示すように、通知部３４は、発注時のキャンセルスコアＳｃ１−１が、その後、現在のキャンセルスコアＳｃ−ｎまで下方修正した場合においても、推奨情報を通知することができる。
【０１０４】
この場合、通知部３４は、例えば、発注時に補償サービスへ加入しなかった施設に対して推奨情報を通知する。これは、施設事業者が、発注時に補償サービスへ加入しなかった原因の一つとして、発注時に提示した掛け金や補填額が施設事業者に対して納得行くものでなかったことが挙げられる。
【０１０５】
上述のように、補償サービスの仕組み上、キャンセルスコアＳｃが低下すると、キャンセルスコアＳｃに応じて掛け金が安くなる。すなわち、キャンセルスコアＳｃが低い方が、より少ない掛け金で補償を受けることが可能となる。
【０１０６】
このため、通知部３４は、補償サービスへの新規加入を推奨する図７Ｄに示すような推奨情報を施設端末４へプッシュ通知する。施設端末４には、掛け金を値下げした旨の文言と共に、掛け金の値下げ対象となる予約情報が表示される。なお、図７Ｄに示す施設端末４に表示する情報に、発注時の掛け金と現在の掛け金や、発注時の掛け金と現在の掛け金との差額に関する情報が含まれていてもよい。
【０１０７】
このように、通知部３４は、キャンセルリスクが発注時から低下した場合に、推奨情報を通知することで、施設事業者の補償サービスへの加入を促進することが可能となる。なお、通知部３４は、例えば、施設事業者から発注時に掛け金がいくらまで下がった場合に、補償サービスへ加入するかを示す加入条件の指定を受け付けておき、指定された加入条件を現在の掛け金が満たす場合に、推奨情報を通知することにしてもよい。
【０１０８】
［４．３．６．管理部〕
管理部３５は、補償サービスの加入状況を管理する。具体的には、管理部３５は、予約サーバ３から送信される補償申請情報を取得し、補償関連情報テーブル４３において、予約サーバ３から取得した補償申請情報に含まれる予約ＩＤに関連付けられる「補償サービスの加入の有無」を「有」に設定する。これにより、補償サービスへの加入申請が受け付けられる。なお、補償モードが第２補償モードに設定されている場合、補償申請情報は、保険申請情報である。
【０１０９】
管理部３５は、補償モードが第１補償モードに設定されている場合に、決定部３３によって決定された補填額および掛け金の情報である補償情報を予約サーバ３へ送信する。これにより、予約サーバ３から端末装置２へ補償情報が送信される。
【０１１０】
また、管理部３５は、補償モードが第２補償モードに設定されている場合、保険申請情報を保険業者サーバ５へ送信することで、保険申請情報を保険業者に提供する。保険申請情報は、補償申請情報の一例である。
【０１１１】
また、管理部３５は、補償モードが第２補償モードに設定されている場合、保険業者サーバ５から取得部３０で取得された保険情報を予約サーバ３へ送信する。これにより、予約サーバ３から端末装置２へ補償情報が送信される。保険情報は、補償情報の一例であり、保険情報には、推定部３２によって演算されたキャンセルスコアＳｃに基づいて決定部３３によって決定された保険額および保険料の情報が含まれる。保険額は、補償額の一例であり、保険料は、掛け金の一例である。
【０１１２】
〔４．３．７．補償処理部〕
補償処理部３６は、取得部３０によってキャンセル情報を取得した場合、キャンセルに対する補償を実行するための処理を行う。
【０１１３】
例えば、補償処理部３６は、補償モードが第１補償モードに設定されている場合、取得部３０によって取得されたキャンセル情報に基づいて、補填額に対応する補償金を支払うか否かの判定を行う。補償処理部３６は、予約に対するキャンセルが補償規約の条件を満たす場合に、補償金を支払うと判定し、予約に対するキャンセルが補償規約の条件を満たさない場合に、補償金を支払わないと判定する。
【０１１４】
補償処理部３６は、例えば、掛け金の支払いが予め設定された期間に行われていない場合や、予約に対するキャンセルによって損害が発生したことを証明することができない場合に、補償規約の条件を満たさないと判定する。なお、予約に対するキャンセルによって発生する損害は、例えば、予約に対するキャンセルが発生した場合に空き状態になった客室や席などが、キャンセルされた利用日時に利用されない場合に発生する。
【０１１５】
補償処理部３６は、補填額に対応する補償金を支払うと判定した場合、キャンセル情報に含まれる予約ＩＤに基づいて、補償情報ＤＢ２２に記憶された補填額の情報を取得する。補償処理部３６は、取得した補填額の情報に基づいて、補填額の補償金を金融機関のサーバを介して施設事業者へ送金することができる。
【０１１６】
また、補償処理部３６は、補償モードが第２補償モードに設定されている場合、取得部３０によって取得されたキャンセル情報を保険業者サーバ５へ送信する。これにより、保険業者サーバ５によってキャンセルに対する補償処理が実行される。
【０１１７】
〔５．情報処理装置の処理手順〕
図８を用いて、情報処理装置１の処理手順について説明する。図８は、実施形態に係る情報処理装置１が実行する処理手順を示すフローチャートである。
【０１１８】
図８に示すように、まず、情報処理装置１は、予約サーバ３から新たな予約情報を取得したか否かを判定する（ステップＳ１０１）。情報処理装置１は、新たな予約情報を取得した場合（ステップＳ１０１，Ｙｅｓ）、予約情報に基づき、キャンセルリスクの推定を開始する（ステップＳ１０２）。また、情報処理装置１は、新たな予約情報を取得していない場合（ステップＳ１０１，Ｎｏ）、そのまま処理を終了する。
【０１１９】
続いて、情報処理装置１は、キャンセルリスクに基づき、予約の発注時に施設事業者へ提示する補填額および掛け金を決定し（ステップＳ１０３）、施設事業者に対して決定した補填額および掛け金を含む補償情報を通知する（ステップＳ１０４）。
【０１２０】
続いて、情報処理装置１は、通知した補償情報に対する施設事業者の応答に応じて補償サービスへの加入処理を行う（ステップＳ１０５）。続いて、情報処理装置１は、キャンセルリスクの推移が推奨情報の通知条件を満たすか否かを判定する（ステップＳ１０６）。
【０１２１】
情報処理装置１は、キャンセルリスクの推移が通知条件を満たすと判定した場合（ステップＳ１０６，Ｙｅｓ）、施設事業者に対して通知条件に応じた推奨情報を通知する（ステップＳ１０７）。
【０１２２】
その後、情報処理装置１は、通知した推奨情報に対する施設事業者の応答結果に応じて施設事業者の補償サービスに対する加入情報を更新する（ステップＳ１０８）。続いて、情報処理装置１は、ユーザＵが予約した施設の利用日時を超過したか否かを判定し（ステップＳ１０９）、利用日時を超過していた場合（ステップＳ１０９，Ｙｅｓ）、処理を終了する。
【０１２３】
また、情報処理装置１は、利用日時を超過していない場合（ステップＳ１０９，Ｎｏ）、ステップＳ１０６の処理へ移行する。なお、情報処理装置１は、ステップＳ１０２以降のいずれかのタイミングでキャンセルが発生した場合、補償額を支払うか否かの支払判定を行い、補填額の支払い処理へ移行する。
【０１２４】
〔６．ハードウェア構成〕
上述した実施形態における情報処理装置１は、それぞれ例えば図９に示すような構成のコンピュータ２００がプログラムを実行することによって実現される。
【０１２５】
図９は、実施形態に係るプログラムを実行するコンピュータのハードウェア構成の一例を示す図である。コンピュータ２００は、ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、ＨＤＤ２０４、通信インターフェイス（Ｉ／Ｆ）２０５、入出力インターフェイス（Ｉ／Ｆ）２０６、およびメディアインターフェイス（Ｉ／Ｆ）２０７を備える。
【０１２６】
ＣＰＵ２０１は、ＲＯＭ２０３またはＨＤＤ２０４に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ２０３は、コンピュータ２００の起動時にＣＰＵ２０１によって実行されるブートプログラムや、コンピュータ２００のハードウェアに依存するプログラム等を格納する。
【０１２７】
ＨＤＤ２０４は、ＣＰＵ２０１によって実行されるプログラムによって使用されるデータ等を格納する。通信インターフェイス２０５は、通信部１０に対応し、ネットワーク６を介して他の機器からデータを受信してＣＰＵ２０１へ送り、ＣＰＵ２０１が生成したデータを、ネットワーク６を介して他の機器へ送信する。
【０１２８】
ＣＰＵ２０１は、入出力インターフェイス２０６を介して、ディスプレイやプリンタ等の出力装置、および、キーボードやマウス等の入力装置を制御する。ＣＰＵ２０１は、入出力インターフェイス２０６を介して、入力装置からデータを取得する。また、ＣＰＵ２０１は、生成したデータを、入出力インターフェイス２０６を介して出力装置へ出力する。
【０１２９】
メディアインターフェイス２０７は、記録媒体２０８に格納されたプログラムまたはデータを読み取り、ＲＡＭ２０２を介してＣＰＵ２０１に提供する。ＣＰＵ２０１は、当該プログラムを、メディアインターフェイス２０７を介して記録媒体２０８からＲＡＭ２０２上にロードし、ロードしたプログラムを実行する。記録媒体２０８は、例えばＤＶＤ（Digital  Versatile  Disc）、ＰＤ（Phase  change  rewritable  Disk）等の光学記録媒体、ＭＯ（Magneto-Optical  disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。
【０１３０】
コンピュータ２００のＣＰＵ２０１は、ＲＡＭ２０２上にロードされたプログラムを実行することにより、上述した取得部３０、生成部３１、推定部３２、決定部３３、通知部３４、管理部３５および補償処理部３６の機能を実現することができる。また、かかる取得部３０、生成部３１、推定部３２、決定部３３、通知部３４、管理部３５および補償処理部３６は、それぞれ一部または全部がハードウェアのみで構成されてもよい。
【０１３１】
コンピュータ２００のＣＰＵ２０１は、プログラムを、記録媒体２０８から読み取って実行するが、他の例として、他の装置から、ネットワーク６を介してこれらのプログラムを取得してもよい。なお、ＨＤＤ２０４は、記憶部１１に対応し、記憶部１１と同様のデータを記憶する。また、ＨＤＤ２０４に代えて、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子、または、光ディスク等の記憶装置を用いてもよい。
【０１３２】
〔７．効果〕
実施形態に係る情報処理装置１は、取得部３０と、推定部３２と、通知部３４とを備える。取得部３０は、施設の予約に関する予約情報を取得する。推定部３２は、取得部３０によって取得された予約情報に基づいて予約のキャンセルが発生するリスクを推定する。通知部３４は、推定部３２によって推定されたリスクの推移に基づき、キャンセルに対して補償を行う補償サービスへの加入を推奨する推奨情報を施設を提供する施設事業者へ通知する。したがって、実施形態に係る情報処理装置１によれば、予約のキャンセルに対する新たな仕組みを構築することが可能となる。特に、施設事業者に対して、キャンセルリスクの変動に応じて適切な補償サービスへの加入を促すことが可能となる。
【０１３３】
通知部３４は、推奨情報をプッシュ通知する。したがって、施設事業者に対して、迅速に推奨情報を通知することができるので、キャンセルリスクの変動に応じて、適切な推奨情報を通知することができる。
【０１３４】
通知部３４は、予約の発注時に補償サービスへの新規加入に関する情報を通知し、発注時のリスクを基準として、現在のリスクが変動した場合に、前記推奨情報を通知する。したがって、施設事業者に対して、発注時のリスクおよび現在のリスクを提示することができるので、施設事業者に対して、１つの予約に対するリスクの推移を把握させることが可能となる。
【０１３５】
通知部３４は、予約についてリスクが上方修正された場合に、推奨情報を通知する。したがって、キャンセルリスクに応じて適切な補償サービスへの加入を推奨することが可能となる。
【０１３６】
通知部３４は、補償サービスへ既に加入していない予約についてリスクが下方修正された場合に、前記推奨情報を通知する。これにより、施設事業者の補償サービスへの加入を促進することが可能となる。
【０１３７】
情報処理装置１は、施設を提供する事業者から補償サービスへの加入申請を受け付けることで、補償サービスの加入状況を管理する管理部３５を備える。したがって、施設のキャンセルに対する補償を行う補償サービスを施設事業者に提供することができる。
【０１３８】
管理部３５は、補償サービスへの加入申請が受け付けた場合に、補償サービスとして保険サービスを提供する保険業者の装置へ保険サービスへの加入申請を示す情報を提供する。したがって、保険業者と連携した補償サービスを施設事業者に提供することができる。
【０１３９】
また、上述した情報処理装置１は、それぞれ複数のサーバコンピュータで実現してもよく、また、機能によっては外部のプラットフォーム等をＡＰＩ（Application  Programming  Interface）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。
【０１４０】
また、上記してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。
【０１４１】
以上、上記実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されない。上記実施形態に多様な変更または改良を加えることが可能であることが当業者には明らかである。また、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【符号の説明】
【０１４２】
１  情報処理装置
２，２１〜２ｎ  端末装置
３  予約サーバ
４，４１〜４ｍ  施設装置
５  保険業者サーバ
６  ネットワーク
１０，５０  通信部
１１，５１  記憶部
１２，５２  制御部
２０  ユーザ情報ＤＢ
２１  予約情報ＤＢ
２２  補償情報ＤＢ
３０  取得部
３１  生成部
３２  推定部
３３  決定部
３４  通知部
３５  管理部
３６  補償処理部
４１  ユーザ情報テーブル
４２  予約情報テーブル
４３  補償関連情報テーブル
１００  情報処理システム
【図１】
2020030472.tif 000003
【図２】
2020030472.tif 000004
【図３】
2020030472.tif 000005
【図４】
2020030472.tif 000006
【図５】
2020030472.tif 000007
【図６】
2020030472.tif 000008
【図７Ａ】
2020030472.tif 000009
【図７Ｂ】
2020030472.tif 000010
【図７Ｃ】
2020030472.tif 000011
【図７Ｄ】
2020030472.tif 000012
【図８】
2020030472.tif 000013
【図９】
2020030472.tif 000014