(57)【要約】【課題】予約を促進させつつ、キャンセルに対する適切な対策を施設事業者へ提案すること。【解決手段】本願に係る表示処理装置は、取得部と、推定部と、提案部とを備える。取得部は、施設の予約を行ったユーザの行動に関する情報である行動情報を取得する。推定部は、取得部によって取得された行動情報に基づいて、ユーザによる予約のキャンセルが発生するリスクであるキャンセルリスクを推定する。提案部は、推定部によって推定されたキャンセルリスクに基づいて、キャンセルに対する対策を施設事業者へ提案する。【選択図】図３
2020030460.tif 000002
【特許請求の範囲】
【請求項１】
施設の予約を行ったユーザの行動に関する情報である行動情報を取得する取得部と、
前記取得部が取得した前記行動情報に基づいて前記ユーザによる前記予約のキャンセルが発生するリスクを推定する推定部と、
前記推定部によって推定された前記リスクに基づいて、前記キャンセルに対する対策を前記施設の事業者へ提案する提案部と
を備えることを特徴とする情報処理装置。
【請求項２】
前記推定部は、
前記行動情報に基づいて前記施設における顧客としての前記ユーザの価値をさらに推定し、
前記提案部は、
前記価値および前記リスクに基づいて前記対策を提案すること
を特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記推定部は、
前記価値として顧客生涯価値を推定すること
を特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記提案部は、
前記対策として、前記施設の優遇に関する優遇情報を前記ユーザに提供すること、および、前記キャンセルが発生した際に補償を行う補償サービスへの加入のうち、少なくとも一方を前記施設の事業者へ提案すること
を特徴とする請求項１〜３のいずれか１つに記載の情報処理装置。
【請求項５】
前記推定部は、
前記行動情報を入力することで、前記リスクの度合いを示すスコアを出力するモデルを用いて、前記リスクを推定すること
を特徴とする請求項１〜４のいずれか１つに記載の情報処理装置。
【請求項６】
前記行動情報は、
前記ユーザの行動における信用度、および、前記ユーザの行動履歴のうち少なくとも一つを含むこと
を特徴とする請求項１〜５のいずれか１つに記載の情報処理装置。
【請求項７】
前記ユーザの行動履歴には、
前記施設、前記施設の周辺施設および前記施設と種別が類似する他の施設の少なくとも一つの施設に対する行動履歴を含むこと
を特徴とする請求項６に記載の情報処理装置。
【請求項８】
前記推定部は、
前記予約の受付時、または、前記施設の状況変化時のいずれかのタイミングで前記リスクを推定すること
を特徴とする請求項１〜７のいずれか１つに記載の情報処理装置。
【請求項９】
コンピュータが実行する情報処理方法であって、
施設の予約を行ったユーザの行動に関する情報である行動情報を取得する取得工程と、
前記取得工程によって取得された前記行動情報に基づいて前記ユーザによる前記予約のキャンセルが発生するリスクを推定する推定工程と、
前記推定工程によって推定された前記リスクに基づいて、前記キャンセルに対する対策を前記施設の事業者へ提案する提案工程と
を含むことを特徴とする情報処理方法。
【請求項１０】
施設の予約を行ったユーザの行動に関する情報である行動情報を取得する取得手順と、
前記取得手順によって取得された前記行動情報に基づいて前記ユーザによる前記予約のキャンセルが発生するリスクを推定する推定手順と、
前記推定手順によって推定された前記リスクに基づいて、前記キャンセルに対する対策を前記施設の事業者へ提案する提案手順と
をコンピュータに実行させることを特徴とする情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法および情報処理プログラムに関する。
【背景技術】
【０００２】
従来、旅館、ホテル、飲食店などの施設を利用しようとするユーザは、一般にインターネットや電話などを通じて施設を予約することができる。施設事業者は、予約を行ったユーザに対して規約として前受金や解約料を要求する場合もあるが、ユーザが前受金や解約料を支払わずにキャンセルすることも多く、施設事業者側に損害が発生することがある。
【０００３】
そこで、特許文献１には、施設利用予約システムへユーザから施設の予約があったときは、ユーザから前受金をカードによって徴収し、予約がキャンセルされたときは前受金を施設事業者側に解約料として支払う技術が提案されている。かかる施設利用予約システムでは、ユーザから前受金を徴収することから、予約がキャンセルされた場合において損害の発生を防止することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−１９６４０６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、キャンセル対策として、上記したように一律に前受金や解約料を要求すると、キャンセルを行わないようなユーザであっても上記施設利用予約システムを利用した予約を躊躇し予約を控えるといった事態が発生する可能性がある。このため、施設事業者にとって、ユーザに予約させることを促進しつつ、キャンセルに対する適切な対策をとることが望まれている。
【０００６】
本願は、上記に鑑みてなされたものであって、予約を促進させつつ、キャンセルに対する適切な対策を提案することができる情報処理装置、情報処理方法、および情報処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本願に係る情報処理装置は、取得部と、推定部と、提案部とを備える。前記取得部は、施設の予約を行ったユーザの行動に関する情報である行動情報を取得する。前記推定部は、前記取得部が取得した前記行動情報に基づいて前記ユーザによる前記予約のキャンセルが発生するリスクを推定する。前記提案部は、前記推定部によって推定された前記リスクに基づいて、前記キャンセルに対する対策を前記施設の事業者へ提案する。
【発明の効果】
【０００８】
実施形態の一態様によれば、予約を促進させつつ、キャンセルに対する適切な対策を提案することができる情報処理装置、情報処理方法、および情報処理プログラムを提供することができる。
【図面の簡単な説明】
【０００９】
【図１】図１は、実施形態に係る情報処理の説明図である。
【図２】図２は、実施形態に係る情報処理システムの構成の一例を示す図である。
【図３】図３は、実施形態に係る情報処理装置の構成の一例を示す図である。
【図４】図４は、実施形態に係るユーザ情報テーブルの一例を示す図である。
【図５】図５は、実施形態に係る予約情報テーブルの一例を示す図である。
【図６】図６は、実施形態に係る補償関連情報テーブルの一例を示す図である。
【図７】図７は、提案部による対策の決定処理を示す図である。
【図８】図８は、実施形態に係る情報処理装置が実行する処理の手順を示すフローチャートである。
【図９】図９は、実施形態に係るプログラムを実行するコンピュータのハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００１０】
以下に、本願に係る情報処理装置、情報処理方法、および情報処理プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報処理装置、情報処理方法、および情報処理プログラムが限定されるものではない。
【００１１】
図１を用いて、実施形態に係る情報処理について説明する。図１は、実施形態に係る情報処理の説明図である。図１では、予約サーバに対して予約を行ったユーザの行動情報に基づいて予約のキャンセルリスクを推定し、推定したキャンセルリスクに基づいてキャンセルに対する対策を施設の事業者へ提案する情報処理について説明する。
【００１２】
まず、図１に示すように、ユーザが予約サーバに対し施設利用の予約を要求する予約要求を行うと（ステップＳ１）、予約サーバは、ユーザからの予約要求を受け付けて、予約要求に基づいて、予約要求にかかる予約を登録する（ステップＳ２）。また、予約サーバは、施設利用の予約に関する情報である予約情報を情報処理装置へ送信する（ステップＳ３）。
【００１３】
情報処理装置は、予約サーバから予約情報を取得すると、予約を行ったユーザの行動に関する情報である行動情報を取得する（ステップＳ４）。行動情報とは、例えば、各種サイトでのユーザの行動履歴等を含む情報であるが、行動情報の詳細については後述する。なお、情報処理装置は、ユーザの端末装置から直接行動情報を取得してもよく、予約サーバを介して行動情報を取得してもよい。
【００１４】
情報処理装置は、取得した予約情報および行動情報に基づいてユーザによる予約のキャンセルが発生するリスク（以下、キャンセルリスクと記載する）を推定するリスク推定処理を行う（ステップＳ５）。かかるリスク推定処理は、例えば、予約毎（ユーザ毎）に行われる。
【００１５】
例えば、情報処理装置は、キャンセルリスクを推定するためのリスク評価モデルを記憶している。情報処理装置は、かかるリスク評価モデルによってキャンセルリスクのスコア（以下、キャンセルスコアＳｃと記載する）を演算することができる。かかるキャンセルスコアＳｃがキャンセルリスクの推定値である。
【００１６】
リスク評価モデルは、例えば、過去の予約情報およびユーザの行動情報を説明変数とし、過去のキャンセルの有無を教師データ（目的変数）として生成される。予約情報には、例えば、予約された施設の地域、予約された施設の利用期間、利用価格、利用される部屋の数や広さの情報が含まれており、これらの情報を説明変数としてリスク評価モデルを生成することができる。
【００１７】
また、行動情報には、例えば、ユーザの行動における信用度や、ユーザの決済に関する履歴、ユーザの検索履歴等の情報が含まれており、これらの情報を説明変数としてリスク評価モデルを生成することができる。
【００１８】
さらに、予約情報および行動情報に加え、予約したユーザの特徴に関する情報である特徴情報を説明変数としてリスク評価モデルを生成することができる。なお、予約情報には、ユーザの識別情報が含まれており、情報処理装置は、ユーザの識別情報に基づいて、ユーザの属性や行動履歴を含む行動情報を取得してもよい。なお、予約情報に含まれるユーザの情報に、ユーザの属性や行動履歴を含む行動情報が含まれていてもよい。
【００１９】
情報処理装置は、ステップＳ５で推定したキャンセルリスクに基づいて、予約のキャンセルに対する対策を決定し（ステップＳ６）、予約サーバを介して施設を提供する事業者（以下、施設事業者と記載する）へ決定した対策を提案する（ステップＳ７）。
【００２０】
かかる対策としては、例えば、キャンセルの発生を未然に防ぐための予防的な対策と、キャンセルが発生した場合の損害を抑えるための事後的な対策とがある。予防的な対策としては、例えば、クーポン発行や、施設のアップグレード等といった施設の優遇を行う対策である。また、事後的な対策としては、例えば、キャンセルが発生した際に補償を行う補償サービスへ加入する対策である。具体的には、情報処理装置は、補償サービスについて、キャンセルが発生した場合に生じる損害の補填額および補填額に応じた補償料を決定する。なお、これら対策は、例えば、キャンセルリスクや、ＬＴＶ（Life  Time  Value）を総合的に評価して決定するが、かかる対策の詳細な決定方法については後述する。
【００２１】
情報処理装置は、例えば、発行すべきクーポンの内容や、予約した施設のアップグレードの内容等を含む対策の情報を施設事業者へ提案し、施設事業者は、かかる提案の情報に基づいて、最終的な対策内容を決定する。例えば、図１では、施設事業者は、ユーザに対してクーポン発行等の優遇を提供する（ステップＳ８−１）。これにより、クーポン発行やアップグレード等の優遇を受けたユーザが予約をキャンセルすることを踏みとどまらせることができる、すなわち、キャンセルの発生を抑えることができる。
【００２２】
また、施設事業者は、情報処理装置によって決定された補填額および補償料による補償サービスへの加入申請を行う（ステップＳ８−２）。なお、施設事業者は、情報処理装置から提案された補填額および補償料を変更して加入申請を行ってもよい。
【００２３】
情報処理装置は、補償サービスへの加入申請を受け付けると、ステップＳ１の予約要求に対する補償サービスへの施設事業者の加入処理を行う（ステップＳ９）。これにより、施設事業者は、補償料を支払った後、ユーザによって予約がキャンセルされた場合に、かかるキャンセルで発生した損害の補償を受けることができる。
【００２４】
このように、実施形態に係る情報処理装置は、キャンセルリスクに基づいて、キャンセルに対する対策を提案することで、キャンセルの発生を抑える対策や、キャンセルが発生した場合の補償の対策等を行うことができる。
【００２５】
すなわち、実施形態に係る情報処理装置は、キャンセルに対する対策を提案することで、従来のように施設事業者が前受金や解約料をユーザに要求する必要が無くなるため、ユーザが予約自体を控えることもない。従って、実施形態に係る情報処理装置によれば、予約を促進させつつ、キャンセルに対する適切な対策を施設事業者へ提案することができる。
【００２６】
図２は、実施形態に係る情報処理システムの構成の一例を示す図である。図２に示すように、実施形態に係る情報処理システム１００は、情報処理装置１と、複数の端末装置２１〜２ｎ（ｎは２以上の整数）と、予約サーバ３と、複数の施設装置４１〜４ｍ（ｍは２以上の整数）と、保険業者サーバ５とを備える。保険業者サーバ５は、保険業者の装置である。
【００２７】
これら情報処理装置１、複数の端末装置２１〜２ｎ、予約サーバ３、複数の施設装置４１〜４ｍ、および保険業者サーバ５は、ネットワーク６を介して有線または無線により互いに通信可能に接続される。ネットワーク６は、例えば、ＬＡＮ（Local  Area  Network）や、インターネットなどのＷＡＮ（Wide  Area  Network）である。端末装置２１〜２ｎは、ユーザＵ１〜Ｕｎによって操作される。
【００２８】
以下においては、端末装置２１〜２ｎの各々を区別せずに示す場合、端末装置２と記載する。また、施設装置４１〜４ｍの各々を区別せずに示す場合、施設装置４と記載し、ユーザＵ１〜Ｕｎの各々を区別せずに示す場合、ユーザＵと記載する。
【００２９】
端末装置２は、ユーザＵの端末装置であり、スマートフォン、タブレット型端末、ＰＤＡ（Personal  Digital  Assistant）、パーソナルコンピュータなどのスマートデバイス（通信端末）である。端末装置２は、ブラウザ、施設予約アプリケーションなどの各種のアプリケーションが実行可能である。端末装置２は、ブラウザ、施設予約アプリケーションなどのアプリケーションから、予約サーバ３にネットワーク６を介してアクセスし、各施設事業者が提供する施設を予約することができる。
【００３０】
施設装置４は、施設事業者の装置であり、図２に示す例では、施設事業者毎に設けられる。施設事業者は、例えば、旅館、ホテル、ペンション、飲食店、マッサージ店、歯科医院、美容院などの施設を運営する事業者である。
【００３１】
図２に示すように、予約サーバ３は、通信部５０と、記憶部５１と、制御部５２とを備える。通信部５０は、ネットワーク６との間で情報の送受信を行う通信インターフェイスである。制御部５２は、通信部５０およびネットワーク６を介して、情報処理装置１、端末装置２、および施設装置４の各々との間で各種の情報を送受信することができる。
【００３２】
記憶部５１は、施設予約サービスに必要な各種の情報を記憶する。記憶部５１は、例えば、フラッシュメモリ等の半導体メモリ素子、または、ＨＤＤ（Hard  Disk  Drive）、光ディスク等の記憶装置である。
【００３３】
制御部５２は、施設装置４から施設情報を取得し、記憶部５１に記憶する。施設装置４の施設情報には、予約可能な施設の情報が含まれる。予約可能な施設の情報は、例えば、施設が宿泊施設である場合、予約可能な部屋の数、各部屋の広さ、各部屋の利用可能人数、各部屋の利用価格などの情報が含まれる。
【００３４】
制御部５２は、端末装置２からアクセスがあった場合、施設の予約をするための施設情報画面の情報を端末装置２へ提供する。端末装置２は、施設情報画面の情報を不図示の表示部に表示する。施設情報画面には、例えば、上述した予約可能な施設の情報が含まれる。ユーザＵは、表示部に表示される施設情報画面を見ながら不図示の入力部への入力によって、施設の予約申請を予約サーバ３へ送信することができる。
【００３５】
制御部５２は、予約申請があった場合、予約申請の対象となる施設の施設装置４へ予約申請の情報を送信する。施設装置４は、予約サーバ３から送信された予約申請の情報に基づいて、予約の可否を判定し、予約が可能であると判定した場合、予約が可能であることを示す情報を予約サーバ３へ送信する。制御部５２は、施設装置４から予約が可能であることを示す情報を取得すると、予約を確定するか否かを問い合わせる情報を端末装置２へ送信する。これにより、端末装置２の表示部には、予約確定ボタンが表示される。
【００３６】
端末装置２のユーザＵが予約確定ボタンを操作すると、端末装置２から予約要求が予約サーバ３へ送信される。制御部５２は、予約要求を受け付けると、施設装置４へ予約要求があったことを示す情報を送信する。施設装置４は、予約要求があったことを示す情報を予約サーバ３から取得すると、予約を確定する。
【００３７】
また、制御部５２は、予約要求を受け付けると、予約情報を情報処理装置１へ送信する。情報処理装置１へ送信される予約情報には、例えば、予約を行ったユーザＵのユーザＩＤ（identifier）、予約ＩＤ、予約の受付日時、および予約内容の情報が含まれる。予約内容の情報には、例えば、利用期間、施設名、施設の地域、利用人数、利用価格、利用部屋数、および利用する部屋の広さなどの情報が含まれる。
【００３８】
また、制御部５２は、情報処理装置１から補償情報を取得すると、取得した補償情報を施設装置４へ送信する。また、制御部５２は、施設装置４から補償の申請があった場合に補償申請情報を情報処理装置１へ送信する。
【００３９】
また、制御部５２は、端末装置２から予約のキャンセルがあった場合、キャンセル要求を施設装置４へ送信し、その後、予約がキャンセル済であることを示すキャンセル済情報を取得すると、情報処理装置１へキャンセル情報を送信する。
【００４０】
図３は、実施形態に係る情報処理装置の構成の一例を示す図である。図３に示すように、情報処理装置１は、通信部１０と、記憶部１１と、制御部１２（コントローラ）とを備える。以下、通信部１０、記憶部１１および制御部１２を具体的に説明する。
【００４１】
通信部１０は、ネットワーク６との間で情報の送受信を行う通信インターフェイスである。制御部１２は、通信部１０およびネットワーク６を介して、端末装置２、予約サーバ３、および保険業者サーバ５の各々との間で各種の情報を送受信することができる。
【００４２】
記憶部１１は、ユーザ情報ＤＢ２０と、予約情報ＤＢ２１と、補償情報ＤＢ２２とを有する。記憶部１１は、例えば、フラッシュメモリ等の半導体メモリ素子、または、ＨＤＤ、光ディスク等の記憶装置である。
【００４３】
ユーザ情報ＤＢ２０は、ユーザＵの情報であるユーザ情報を複数含むユーザ情報テーブルを有する。ユーザＵは、情報処理装置１の運営および管理を行う事業者が提供するサービスのユーザである。かかる事業者が提供するサービスは、ユーザＵに対してオンラインでサービスを提供するオンラインサービスであり、例えば、予約サーバ３の施設予約サイトで提供される施設予約サービス、電子商取引サイトで提供される電子商取引サービス、オークションサイトで提供されるオークションサービス、動画配信サイトで提供される動画配信サービス、ニュースサイトで提供されるニュース配信サービスなどが含まれる。
【００４４】
図４は、実施形態に係るユーザ情報テーブルの一例を示す図である。図４に示すユーザ情報テーブル４１は、「ユーザＩＤ」、「デモグラフィック属性」、「サイコグラフィック属性」、および「行動履歴」などの情報が互いに関連付けられた情報である。
【００４５】
「ユーザＩＤ」は、ユーザＵの識別情報であり、図４に示す例では、ユーザＵ１、Ｕ２、Ｕ３のユーザＩＤとして「Ｕ１」、「Ｕ２」、「Ｕ３」が設定される。かかるユーザＩＤは、上述したオンラインサービスに対するユーザＵのアカウントである。なお、ユーザＩＤは、ユーザＵを識別する情報であればよく、ユーザＵが使用する端末装置２の識別情報をユーザＩＤとしてもよい。例えば、ユーザＩＤは、ＨＴＴＰ（Hypertext  Transfer  Protocol）クッキーで特定される識別情報であってもよい。
【００４６】
「デモグラフィック属性」は、ユーザＵの人口統計学的な属性の情報である。かかる「デモグラフィック属性」は、例えば、ユーザＵの「性別」、「年齢」などの情報である。「性別」には、ユーザＵが女性である場合には「１」が設定され、ユーザＵが男性である場合には「２」が設定される。また、「年齢」には、ユーザＵの年齢が設定される。なお、「デモグラフィック属性」は、図４に示した属性の例に限られず、ユーザＵの職業、家族構成、年収、住所、出身地、学歴など様々な属性を含んでいてもよい。
【００４７】
「サイコグラフィック属性」は、ユーザＵの心理学的な属性の情報であり、例えば、ユーザＵの価値観、ライフスタイル、性格、嗜好などの情報である。図４に示す例では、属性要素毎に、ユーザＵの嗜好が相対的に高い場合に「１」が設定され、それ以外の場合には「０」が設定される。また、「サイコグラフィック属性」は、図４に示した属性の例に限られず、経済、政治、野球、サッカー、その他スポーツ、スイーツ、パソコン、白物家電、家具など様々な属性を含んでいてもよい。なお、属性の情報は、０と１の２段階に限定されず、３段階以上の値であってもよい。
【００４８】
「行動履歴」は、ユーザＵの行動に関する行動情報であり、例えば、上述した各種サイトでのユーザＵの行動履歴の情報である。「行動履歴」は、例えば、施設予約サイトでの施設の予約の履歴、電子商取引サイトやオークションサイトでの商品またはサービスの購入履歴、動画配信サイトでの動画の視聴履歴、ニュースサイトで閲覧したニュースの履歴などである。また、「行動履歴」には、各サイトで提供される広告に対するアクション（例えば、クリック）などの情報が含まれる。
【００４９】
予約情報ＤＢ２１は、施設事業者の施設の予約に関する情報である予約情報を複数含む予約情報テーブルを有する。図５は、実施形態に係る予約情報テーブルの一例を示す図である。図５に示す予約情報テーブル４２は、「予約ＩＤ」、「ユーザＩＤ」、「受付日時」、「予約内容」、および「キャンセル情報」などの情報が互いに関連付けられた情報である。
【００５０】
「予約ＩＤ」は、予約毎に割り当てられる固有の識別情報である。「ユーザＩＤ」は、ユーザＵ毎に割り当てられる固有の識別情報である。「受付日時」は、予約サーバ３によってユーザＵから予約を受け付けた日時を示す情報である。
【００５１】
「予約内容」は、予約サーバ３によってユーザＵから受け付けられた予約の内容を示す情報である。「予約内容」には、利用期間、施設名、利用人数、施設の地域、利用価格、利用部屋数、利用する部屋の広さなどの情報が含まれる。
【００５２】
利用期間は、ユーザＵが施設を利用する期間である。施設名は、ユーザＵが予約した施設の名称である。利用人数は、施設を利用する人数である。施設の地域は、ユーザＵが予約した施設が位置する地域である。
【００５３】
利用価格は、予約内容に従って施設を利用した場合にユーザＵが施設事業者に支払う額である。例えば、予約された施設が宿泊施設である場合、予約の内容に飲食やマッサージなどが含まれる場合には、利用価格には、宿泊料に加え、食事やマッサージなどの料金が含まれる。また、予約された施設が飲食店の場合、利用価格は、施設内での飲食に必要な価格である。
【００５４】
利用部屋数は、ユーザＵが予約した部屋の数である。利用する部屋の広さは、ユーザＵが予約した部屋の広さである。なお、予約された施設が飲食店の場合、利用部屋数に代えて、利用場所の種別（テーブル席、カウンター席、座敷など）の情報や、利用場所の広さなどが含まれる。
【００５５】
「キャンセル情報」は、予約のキャンセルに関する情報であり、予約のキャンセルの有無を示す情報、および予約のキャンセルが受け付けられた日時であるキャンセル日時の情報を含む。
【００５６】
補償情報ＤＢ２２は、予約に対する補償サービスに関する情報である補償関連情報を複数含む補償関連情報テーブルを有する。図６は、実施形態に係る補償関連情報テーブルの一例を示す図である。図６に示す補償関連情報テーブル４３は、「予約ＩＤ」、「補償サービスの加入の有無」、「キャンセルスコア」、「補償料」、および「補填額」などの情報が互いに関連付けられた情報である。
【００５７】
「予約ＩＤ」は、予約毎に割り当てられる固有の識別情報である。「キャンセルスコア」は、制御部１２によって演算されるキャンセルスコアＳｃの情報である。図６に示す例では、キャンセルスコアＳｃを便宜上「Ｓｃ１」、「Ｓｃ２」、「Ｓｃ３」などと表しているが、キャンセルスコアＳｃは数値化されたスコアである。
【００５８】
「ＬＴＶ」は、施設における顧客としてのユーザＵの価値、いわゆる顧客生涯価値（Life  Time  Value）に関する情報であり、制御部１２によって演算される。図６に示す例では、「ＬＴＶ」を便宜上「ｌｔｖ１」、「ｌｔｖ２」、「ｌｔｖ３」などと表しているが、「ＬＴＶ」は、施設にとっての利益率や、利益となる金額等の数値である。
【００５９】
「補償サービスの加入の有無」は、予約に対して施設事業者が補償サービスに加入しているか否かを示す情報である。図６に示す例では、予約ＩＤ「Ｃ１」の予約および予約ＩＤ「Ｃ３」の予約に対して各々施設事業者が補償サービスに加入しており、予約ＩＤ「Ｃ２」の予約に対して施設事業者が補償サービスに加入していないことを示している。「補償料」は、補償サービスの補償料の情報である。また、「補填額」は、補償サービスの補填額の情報である。
【００６０】
制御部１２は、例えば、ＣＰＵ（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）等の種々のディープラーニングの技術を適宜用いてリスク評価モデルを生成することができる。
【００８１】
推定部３２は、取得部３０によって取得された予約情報およびユーザ情報に基づいて、キャンセルリスクを推定する。例えば、推定部３２は、取得部３０によって取得された予約情報に含まれるユーザＩＤに関連付けられたユーザＵの属性情報や行動履歴等の行動情報を含むユーザ情報を記憶部１１から抽出する。
【００８２】
そして、推定部３２は、抽出したユーザ情報と取得部３０によって取得された予約情報から抽出される複数の特徴情報を説明変数とする上記式（１）のリスク評価モデルを用いて、キャンセルスコアＳｃを演算することができる。具体的には、推定部３２は、下記式（２）の演算によって、キャンセルスコアＳｃを演算することができる。推定部３２は、演算した結果を補償関連情報テーブル４３に追加する。
Ｓｃ＝ω１・ｘ１＋ω２・ｘ２＋・・・＋ωｎ・ｘｎ      ・・・（２）
【００８３】
推定部３２は、上記したキャンセルスコアＳｃを、予約の受付時、または、施設の状況変化時のいずれかのタイミングで算出する。状況変化時とは、例えば、利用日時における施設周辺の予測される天候の変化や、利用日時における施設周辺でのイベントの開催の有無の変化や、イベント内容の変更等の外部要因の変化である。また、状況変化時として、例えば、予約した施設周辺にある他施設のユーザの予約状況の変化や、予約した人数の変化等、ユーザの行動による変化等を含んでもよい。
【００８４】
言い換えれば、状況変化時とは、上記したリスク評価モデルの説明変数の情報が変化する時であり、キャンセルリスクＳｃが上昇したり、低下したりする時である。このように、推定部３２は、状況変化があった毎にキャンセルリスクＳｃを推定することで、後述の提案部３３がより適切な対策を提案することができる。
【００８５】
また、推定部３２は、取得部３０によって取得された行動情報に基づいて施設における顧客としてのユーザＵの価値を推定する。上記したように、ユーザＵの価値の一例である顧客生涯価値とは、施設の顧客であるユーザが生涯にどの程度の利益を施設にもたらすかを示す指標である。顧客生涯価値は、例えば、施設の利用一回あたり（あるいは予約一回あたり）の利益と、生涯の期間もしくは顧客ライフサイクル内に想定される利用回数（予約回数）とを積算して得ることができる。なお、ユーザＵの価値は、顧客生涯価値に限定されるものではなく、顧客獲得コスト（CAC:Customer  Acquisition  Cost）や、ＲＯＩ（Return  on  Investment）等の指標をユーザＵの価値としてもよい。
【００８６】
また、推定部３２は、上記により算出した生涯価値に、ユーザＵの行動情報を含むユーザ情報を加味した生涯価値を算出してもよい。例えば、推定部３２は、上記により算出した生涯価値に対して、行動情報に応じた係数を乗算して最終的な生涯価値を算出する。このように、ユーザＵの行動情報を加味することで、算出される生涯価値の精度を高めることができる。
【００８７】
提案部３３は、推定部３２によって推定されたキャンセルリスクに基づいて、予約のキャンセルに対する対策を施設事業者へ提案する。例えば、提案部３３は、推定部３２によって推定されたキャンセルリスクおよびユーザＵの生涯価値に基づいて提案する対策を決定する。ここで、図７を用いて、提案部３３による対策の具体的な決定方法について説明する。
【００８８】
図７は、提案部３３による対策の決定処理を示す図である。図７では、横軸にキャンセルリスク、縦軸にＬＴＶ（生涯価値）とした２軸のグラフを示す。図７に示すように、提案部３３は、ＬＴＶおよびキャンセルリスクＳｃそれぞれを２段階（閾値以上か閾値未満か）に分け、それぞれの組み合わせからなる４種類の対策の中から一を選択する。
【００８９】
例えば、提案部３３は、ＬＴＶが高い、かつ、キャンセルリスクＳＣが高い場合、保険の加入およびクーポン発行を対策として提案する。なお、加入すべき保険の内容については後述する。クーポン発行とは、施設の優遇に関する優遇情報の一例であり、例えば、施設に付随する施設（ホテルのレストランなど）の利用割引クーポン等を利用日よりも前にユーザＵへ提供することを指す。ＬＴＶおよびキャンセルリスクＳｃがともに高いユーザＵは、一見ではなく、施設を利用すれば常連となる可能性が高いユーザであるが、一方で、キャンセルをしやすいユーザでもある。つまり、提案部３３は、このようなユーザＵについては、利用日よりも前に予め優遇情報を提供することで、キャンセルさせにくくさせることができる。
【００９０】
また、例えば、提案部３３は、ＬＴＶが高い、かつ、キャンセルリスクＳｃが低い場合、保険の加入およびアップグレードを対策として提案する。アップグレードとは、施設の優遇に関する優遇情報の一例であり、例えば、予約した施設を利用する際に施設の予約内容（部屋のグレード等）の質を上げることである。ＬＴＶが高く、キャンセルリスクＳｃが低いユーザＵは、一見ではなく、施設を利用すれば常連となる可能性が高いユーザであり、かつ、キャンセルをあまりしないユーザでもある。つまり、提案部３３は、このようなユーザＵについては、利用日の当日に施設を利用した際に優遇情報を提供することによって、ユーザＵが施設を気に入って常連客になる可能性を高めることができる。なお、ＬＴＶが高い、かつ、キャンセルリスクＳｃが低いユーザＵについては、保険の加入の提案はせず、優遇情報のみの提案を行ってもよい。
【００９１】
また、例えば、提案部３３は、ＬＴＶが低い、かつ、キャンセルリスクＳｃが高い場合と、ＬＴＶが低い、かつ、キャンセルリスクＳｃが低い場合とについては、保険の加入のみを対策として提案する。このようなユーザＵは、仮に、優遇情報を提供したとしても常連客となる可能性が低い、つまり、優遇情報の提供が効果的でないため、保険加入によりキャンセル発生時の損失のみに備える。これにより、施設事業者は、効果的でない優遇情報の提供を行わずに済むため、施設の利益が低下することを防止できる。なお、ＬＴＶが低い、かつ、キャンセルリスクＳｃが低いユーザＵについては、保険の加入の提案はせず、すなわち、対策の提案を行なわないようにしてもよい。
【００９２】
なお、図７では、ＬＴＶおよびキャンセルリスクＳｃの２軸により提案する対策を決定したが、３軸以上であってもよい。また、図７では、各軸について、高・低の２段階に分けたが、高・中・低の３段階以上に分けてもよい。
【００９３】
また、提案部３３は、施設事業者に対して対策を提案したが、施設事業者に加えて、ユーザＵに対して直接情報を提供してもよい。例えば、提案部３３は、提案した対策を施設事業者が実行することを条件として、情報処理装置１から直接ユーザＵに対してキャンセルの発生を抑えるための情報を提供してもよい。例えば、提案部３３は、情報処理装置１が管理する他のサービスの優遇情報等をユーザＵに対して直接提供する。これにより、キャンセルの発生を抑えることができるため、施設の利益を向上させることができる。
【００９４】
また、提案部３３による上記した保険内容の決定については、補償モードに応じた処理が行われる。
【００９５】
例えば、提案部３３は、補償モードが第１補償モードに設定されている場合に、推定部３２によって推定されたキャンセルスコアＳｃに基づいて、予約のキャンセルに対する補填額および補償料を決定する。
【００９６】
提案部３３は、キャンセルスコアＳｃと、補填額および補償料との関係を示す演算式またはテーブルを有しており、かかる演算式またはテーブルを用いて補償サービスにおける補填額および補償料を求めることができる。
【００９７】
なお、提案部３３は、キャンセルスコアＳｃと予約された施設の利用価格とに基づいて、補償サービスにおける補填額および補償料を求めることもできる。例えば、提案部３３は、キャンセルスコアＳｃと補償料との関係を示す演算式またはテーブルを有しており、かかる演算式またはテーブルを用いてキャンセルスコアＳｃに対応する補償料を求める。そして、提案部３３は、キャンセルスコアに対応する補償料に、予約された施設の利用価格を乗算することで、補償サービスにおける補償料を演算することができる。この場合、施設の利用価格が補填額となる。
【００９８】
また、施設事業者から補填額の指定がある場合、提案部３３は、「予約された施設の利用価格」に代えて「指定された補填額」を用いることができる。この場合、提案部３３は、キャンセルスコアＳｃに対応する補償料に、指定された補填額を乗算することで、補償サービスにおける補償料を演算することができる。なお、補償サービスにおける補償料の演算は、上述した例に限定されず、キャンセルスコアＳｃに基づいて算出される補償料であればよい。また、提案部３３は、補償サービスにおける補償料のみを決定することもできる。
【００９９】
また、提案部３３は、利用日時が受付日時に近いほど補償料が高くなるように補償料を決定することができる。これは、利用日時が受付日時に近いほど予約がキャンセルされたことによる損害の発生確率が高くなるからである。この場合、提案部３３は、上述のように演算した補償料を基本補償料として求め、基本補償料に利用日時が受付日時に近いほど大きくなる係数を乗算することで、補償サービスにおける補償料を求めることができる。
【０１００】
また、提案部３３は、一括補償サービスに加入している施設の予約のキャンセルに対する補償の補償料を低くすることができる。一括補償サービスとは、予約毎に補償サービスへの加入申請をすることなく、施設の予約のキャンセルに対する補償を行うサービスであり、施設事業者によって予約サーバ３を介して情報処理装置１へ事前に加入申請が行われる。
【０１０１】
提案部３３は、一括補償サービスに加入している施設の予約に対し、上述のように演算した補償料を基本補償料として求め、基本補償料に割引係数（１より小さい値）を乗算することで、補償サービスにおける補償料を求めることができる。
【０１０２】
提案部３３は、補償モードが第１補償モードに設定されている場合に、提案部３３によって決定された補填額および補償料の情報である補償情報を予約サーバ３へ送信する。これにより、予約サーバ３から端末装置２へ補償情報が送信される。
【０１０３】
また、提案部３３は、補償モードが第２補償モードに設定されている場合、受付部３４によって取得された保険申請情報を保険業者サーバ５へ送信することで、保険申請情報を保険業者に提供する。保険申請情報は、補償申請情報の一例である。
【０１０４】
また、提案部３３は、補償モードが第２補償モードに設定されている場合、保険業者サーバ５から取得部３０で取得された保険情報を予約サーバ３へ送信する。これにより、予約サーバ３から端末装置２へ補償情報が送信される。保険情報は、補償情報の一例であり、保険情報には、推定部３２によって演算されたキャンセルスコアＳｃに基づいて保険業者によって決定された保険額および保険料の情報が含まれる。保険額は、補償額の一例であり、保険料は、補償料の一例である。
【０１０５】
また、提案部３３は、補償モードが第２補償モードに設定されている場合、推定部３２によって演算されたキャンセルリスクの情報を含むリスク情報を保険業者サーバ５へ送信する。キャンセルリスクの情報は、例えば、キャンセルスコアＳｃの情報である。なお、キャンセルリスクの情報には、予約情報に含まれる利用価格の情報を含んでいてもよい。
【０１０６】
上述したように、提案部３３は、キャンセルに対する対策として、施設の優遇に関する優遇情報をユーザＵに提供すること、および、キャンセルが発生した際に補償を行う補償サービスへの加入のうち、少なくとも一方を施設事業者へ提案する。これにより、キャンセルの発生を抑えつつ、キャンセルの発生に対して補償を行うことができる。
【０１０７】
受付部３４は、予約毎に補償サービスへの加入申請を受け付ける。具体的には、受付部３４は、予約サーバ３から送信される補償申請情報を取得し、補償関連情報テーブル４３において、予約サーバ３から取得した補償申請情報に含まれる予約ＩＤに関連付けられる「補償サービスの加入の有無」を「有」に設定する。これにより、補償サービスへの加入申請が受け付けられる。なお、補償モードが第２補償モードに設定されている場合、補償申請情報は、保険申請情報である。
【０１０８】
補償処理部３５は、取得部３０によってキャンセル情報を取得した場合、キャンセルに対する補償を実行するための処理を行う。
【０１０９】
例えば、補償処理部３５は、補償モードが第１補償モードに設定されている場合、取得部３０によって取得されたキャンセル情報に基づいて、補填額に対応する補償金を支払うか否かの判定を行う。補償処理部３５は、予約に対するキャンセルが補償規約の条件を満たす場合に、補償金を支払うと判定し、予約に対するキャンセルが補償規約の条件を満たさない場合に、補償金を支払わないと判定する。
【０１１０】
補償処理部３５は、例えば、補償料の支払いが予め設定された期間に行われていない場合や、予約に対するキャンセルによって損害が発生したことを証明することができない場合に、補償規約の条件を満たさないと判定する。なお、予約に対するキャンセルによって発生する損害は、例えば、予約に対するキャンセルが発生した場合に空き状態になった客室や席などが、キャンセルされた利用日時に利用されない場合に発生する。
【０１１１】
補償処理部３５は、補填額に対応する補償金を支払うと判定した場合、キャンセル情報に含まれる予約ＩＤに基づいて、補償情報ＤＢ２２に記憶された補填額の情報を取得する。補償処理部３５は、取得した補填額の情報に基づいて、補填額の補償金を金融機関のサーバを介して施設事業者へ送金することができる。
【０１１２】
また、補償処理部３５は、補償モードが第２補償モードに設定されている場合、取得部３０によって取得されたキャンセル情報を保険業者サーバ５へ送信する。これにより、保険業者サーバ５によってキャンセルに対する補償処理が実行される。
【０１１３】
次に、図８を用いて、実施形態に係る情報処理装置１が実行する処理の手順について説明する。図８は、実施形態に係る情報処理装置１が実行する処理の手順を示すフローチャートである。
【０１１４】
図８に示すように、まず、取得部３０は、予約サーバから予約情報を取得したか否かを判定する（ステップＳ１０１）。取得部３０は、予約情報を取得した場合（ステップＳ１０１，Ｙｅｓ）、ユーザＵの行動に関する情報である行動情報を取得する（ステップＳ１０２）。
【０１１５】
つづいて、推定部３２は、取得部３０が取得した行動情報に基づいてユーザＵによる予約のキャンセルが発生するリスクを推定する（ステップＳ１０３）。つづいて、推定部３２は、ユーザＵの行動情報に基づいて施設に対するユーザＵの生涯価値をさらに推定する（ステップ１０４）。
【０１１６】
つづいて、提案部３３は、推定部３２によって推定されたキャンセルリスクＳｃおよび生涯価値に基づいてキャンセルに対する対策を提案し（ステップＳ１０５）、処理を終了する。
【０１１７】
上述した情報処理システム１００では、施設の予約が行われた後に、キャンセルリスクを演算し、演算したキャンセルリスクに基づく補償料（保険料を含む）や補填額（保険額を含む）を決定するが、かかる例に限定されない。
【０１１８】
例えば、情報処理装置１は、施設の予約が申請された場合に、キャンセルリスクを演算することができる。例えば、情報処理装置１の制御部１２は、予約処理が完了する前の予約に関する情報を予約情報として予約サーバ３から取得することができる。この場合、情報処理装置１の制御部１２は、予約処理が完了する前の予約に関する情報を予約情報としてキャンセルリスクを推定することができる。
【０１１９】
そして、情報処理装置１は、予約処理が完了する前の予約に基づき演算されたキャンセルリスクに基づいて対策を提案する。予約サーバは、情報処理装置１から提案された対策を施設事業者へ送信する。これにより、施設事業者は、提案された対策に基づいて、対策を実行するか否かに加え、予約を受け付けるかどうかも判断することができる。
【０１２０】
また、上述した情報処理システム１００では、キャンセルリスクを補償サービスに用いるが、キャンセルリスクを補償サービス以外に用いることもできる。例えば、情報処理装置１の制御部１２は、予約処理が完了する前の予約に関する情報を予約情報としてキャンセルリスクを推定する。情報処理装置１の制御部１２は、推定したキャンセルリスクの情報を予約サーバ３へ送信する。なお、情報処理装置１の制御部１２は、キャンセルリスクが所定値以上の場合に、キャンセルリスクの情報を予約サーバ３へ送信することもできる。
【０１２１】
予約サーバ３の制御部５２は、キャンセルリスクの情報を取得した場合、施設装置４へキャンセルリスクの情報を送信することができる。これにより、施設事業者は、キャンセルリスクの情報に基づいて、予約を受け付けるかどうかを判断することができる。なお、予約サーバ３の制御部５２は、キャンセルリスクが所定値以上の場合、予約を受け付けないこともできる。
【０１２２】
また、予約サーバ３の制御部５２または施設装置４は、キャンセルリスクの情報に基づいて、利用価格を変更することもできる。例えば、予約サーバ３の制御部５２または施設装置４は、キャンセルリスクが低いほど利用価格を下げることができる。また、予約サーバ３の制御部５２または施設装置４は、キャンセルリスクが高いほど利用価格を上げることができる。
【０１２３】
上述した実施形態における情報処理装置１は、それぞれ例えば図９に示すような構成のコンピュータ２００がプログラムを実行することによって実現される。
【０１２４】
図９は、実施形態に係るプログラムを実行するコンピュータのハードウェア構成の一例を示す図である。コンピュータ２００は、ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、ＨＤＤ２０４、通信インターフェイス（Ｉ／Ｆ）２０５、入出力インターフェイス（Ｉ／Ｆ）２０６、およびメディアインターフェイス（Ｉ／Ｆ）２０７を備える。
【０１２５】
ＣＰＵ２０１は、ＲＯＭ２０３またはＨＤＤ２０４に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ２０３は、コンピュータ２００の起動時にＣＰＵ２０１によって実行されるブートプログラムや、コンピュータ２００のハードウェアに依存するプログラム等を格納する。
【０１２６】
ＨＤＤ２０４は、ＣＰＵ２０１によって実行されるプログラムによって使用されるデータ等を格納する。通信インターフェイス２０５は、通信部１０に対応し、ネットワーク６を介して他の機器からデータを受信してＣＰＵ２０１へ送り、ＣＰＵ２０１が生成したデータを、ネットワーク６を介して他の機器へ送信する。
【０１２７】
ＣＰＵ２０１は、入出力インターフェイス２０６を介して、ディスプレイやプリンタ等の出力装置、および、キーボードやマウス等の入力装置を制御する。ＣＰＵ２０１は、入出力インターフェイス２０６を介して、入力装置からデータを取得する。また、ＣＰＵ２０１は、生成したデータを、入出力インターフェイス２０６を介して出力装置へ出力する。
【０１２８】
メディアインターフェイス２０７は、記録媒体２０８に格納されたプログラムまたはデータを読み取り、ＲＡＭ２０２を介してＣＰＵ２０１に提供する。ＣＰＵ２０１は、当該プログラムを、メディアインターフェイス２０７を介して記録媒体２０８からＲＡＭ２０２上にロードし、ロードしたプログラムを実行する。記録媒体２０８は、例えばＤＶＤ（Digital  Versatile  Disc）、ＰＤ（Phase  change  rewritable  Disk）等の光学記録媒体、ＭＯ（Magneto-Optical  disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。
【０１２９】
コンピュータ２００のＣＰＵ２０１は、ＲＡＭ２０２上にロードされたプログラムを実行することにより、上述した取得部３０、生成部３１、推定部３２、提案部３３、受付部３４および補償処理部３５の機能を実現することができる。また、かかる取得部３０、生成部３１、推定部３２、提案部３３、受付部３４および補償処理部３５は、それぞれ一部または全部がハードウェアのみで構成されてもよい。
【０１３０】
コンピュータ２００のＣＰＵ２０１は、プログラムを、記録媒体２０８から読み取って実行するが、他の例として、他の装置から、ネットワーク６を介してこれらのプログラムを取得してもよい。なお、ＨＤＤ２０４は、記憶部１１に対応し、記憶部１１と同様のデータを記憶する。また、ＨＤＤ２０４に代えて、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子、または、光ディスク等の記憶装置を用いてもよい。
【０１３１】
実施形態に係る情報処理装置１は、取得部３０と、推定部３２と、提案部３３とを備える。取得部３０は、施設の予約を行ったユーザＵの行動に関する情報である行動情報を取得する。推定部３２は、取得部３０によって取得された行動情報に基づいて、ユーザＵによる予約のキャンセルが発生するリスクであるキャンセルリスクを推定する。提案部３３は、推定部３２によって推定されたキャンセルリスクに基づいて、キャンセルに対する対策を施設事業者へ提案する。これにより、キャンセルの発生を抑える対策や、キャンセルが発生した場合の補償の対策等を行うことができる。また、キャンセルに対する対策を提案することで、従来のように施設事業者が前受金や解約料をユーザに要求する必要が無くなるため、ユーザが予約自体を控えることもない。従って、実施形態に係る情報処理装置によれば、予約を促進させつつ、キャンセルに対する適切な対策を施設事業者へ提案することができる。
【０１３２】
また、推定部３２は、行動情報に基づいて施設における顧客としてのユーザＵの価値を推定する。提案部３３は、ＬＴＶおよびキャンセルリスクに基づいて対策を提案する。このように、顧客としてのユーザＵの価値およびキャンセルリスクを用いて対策を提案することで、より適切な対策を施設事業者へ提案することができる。
【０１３３】
また、推定部３２は、ユーザＵの価値として顧客生涯価値であるＬＴＶを推定する。これにより、顧客としてのユーザＵの価値を精度良く推定することができる。
【０１３４】
また、提案部３３は、対策として、施設の優遇に関する優遇情報をユーザＵに提供すること、および、キャンセルが発生した際に補償を行う補償サービスへの加入のうち、少なくとも一方を施設事業者へ提案する。例えば、優遇情報を利用日時よりも前にユーザＵに提供することで、キャンセルすることを踏みとどまらせることができ、利用日当日に優遇情報を提供することで、一見ではなく常連客になる可能性を高めることができる。また、例えば、補償サービスへの加入を提案することで、万が一にキャンセルが発生したとしても補償を受けることで、キャンセルに伴う損失を抑えることができる。
【０１３５】
また、推定部３２は、行動情報を入力することで、キャンセルリスクの度合いを示すキャンセルスコアＳｃを出力するモデルであるリスク評価モデルを用いて、キャンセルリスクを推定する。このように、リスク評価モデルを用いてキャンセルスコアＳｃを演算することで、キャンセルリスクを精度よく推定することができる。
【０１３６】
また、行動情報は、ユーザＵの行動における信用度、および、ユーザＵの行動履歴のうち少なくとも一つを含む。これにより、キャンセルリスクを精度よく推定することができる。
【０１３７】
また、ユーザＵの行動履歴は、施設、施設の周辺施設および施設と種別が類似する他の施設の少なくとも一つの施設に対する行動履歴を含む。このように、予約した施設や、周辺施設、予約した施設と種別が類似する他の施設に対する行動履歴を用いることで、キャンセルリスクを精度よく推定することができる。
【０１３８】
また、推定部３２は、予約の受付時、または、施設の状況変化時のいずれかのタイミングでキャンセルリスクを推定する。例えば、予約の受付時にキャンセルリスクを推定することで、施設事業者に対して早期にキャンセルの対策を提案できる。また、例えば、施設の状況変化時にキャンセルリスクを推定することで、例えば、天候悪化等によりキャンセルリスクが高まった場合等に、早急に対策を提案することができる。
【０１３９】
また、上述した情報処理装置１は、それぞれ複数のサーバコンピュータで実現してもよく、また、機能によっては外部のプラットフォーム等をＡＰＩ（Application  Programming  Interface）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。
【０１４０】
また、上記してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。
【０１４１】
以上、上記実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されない。上記実施形態に多様な変更または改良を加えることが可能であることが当業者には明らかである。また、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【符号の説明】
【０１４２】
１  情報処理装置
２，２１〜２ｎ  端末装置
３  予約サーバ
４，４１〜４ｍ  施設装置
５  保険業者サーバ
６  ネットワーク
１０，５０  通信部
１１，５１  記憶部
１２，５２  制御部
２０  ユーザ情報ＤＢ
２１  予約情報ＤＢ
２２  補償情報ＤＢ
３０  取得部
３１  生成部
３２  推定部
３３  提案部
３４  受付部
３５  補償処理部
４１  ユーザ情報テーブル
４２  予約情報テーブル
４３  補償関連情報テーブル
１００  情報処理システム
【図１】
2020030460.tif 000003
【図２】
2020030460.tif 000004
【図３】
2020030460.tif 000005
【図４】
2020030460.tif 000006
【図５】
2020030460.tif 000007
【図６】
2020030460.tif 000008
【図７】
2020030460.tif 000009
【図８】
2020030460.tif 000010
【図９】
2020030460.tif 000011