JP2023058377A - 情報処理装置、情報処理システム及び情報処理方法 - Google Patents

Abstract

【課題】オンデマンドバスの利用予約をキャンセルするか否かを見直す機会をユーザに適切に与える情報処理装置、情報処理システム及び情報処理方法を提供する。【解決手段】複数の車両と、端末装置と、情報処理装置とが、ネットワークを介して通信可能な情報処理システムにおいて、情報処理装置は、オンデマンドバスの利用予約がキャンセルされる可能性が高いとユーザの情報に基づいて判定した場合Ｓ２３、オンデマンドバスの利用予約をキャンセルするか否かの問い合わせを、ユーザの端末装置２０に送信するＳ２４。【選択図】図４

Description

本開示は、情報処理装置、情報処理システム及び情報処理方法に関する。

特許文献１には、複数ユーザをまとめて送迎する車両の乗車料金の支払いを各ユーザに割り当てる制御部を備える制御装置が開示されている。

特開２０２１－８６５５７号公報

オンデマンドバスの利用予約をキャンセルするか否かを見直す機会をユーザに適切に与える技術が望まれている。

かかる点に鑑みてなされた本開示の目的は、オンデマンドバスの利用予約をキャンセルするか否かを見直す機会をユーザに適切に与える技術を提供することにある。

本開示の一実施形態に係る情報処理装置は、
通信部と、
オンデマンドバスの利用予約がキャンセルされる可能性が高いと前記利用予約をしたユーザの情報に基づいて判定した場合、前記利用予約をキャンセルするか否かの問い合わせを、前記ユーザの端末装置に前記通信部によって送信する制御部と、を備える。

本開示の一実施形態に係る情報処理システムは、
前記端末装置と、
前記情報処理装置と、を含む。

本開示の一実施形態に係る情報処理方法は、
オンデマンドバスの利用予約がキャンセルされる可能性が高いと前記利用予約をしたユーザの情報に基づいて判定した場合、前記利用予約をキャンセルするか否かの問い合わせを、前記ユーザの端末装置に送信することを含む。

本開示の一実施形態によれば、オンデマンドバスの利用予約をキャンセルするか否かを見直す機会をユーザに適切に与える技術を提供することができる。

本開示の一実施形態に係る情報処理システムの概略構成を示す図である。 図１に示す情報処理システムのブロック図である。 図２に示す端末装置の処理を示すフローチャートである。 図２に示す情報処理装置の処理を示すフローチャートである。

以下、本開示の実施形態について、図面を参照して説明する。

（システムの構成）
図１に示すように、情報処理システム１は、複数の車両１０と、少なくとも１つの端末装置２０と、少なくとも１つの情報処理装置３０とを含む。図１に示す情報処理システム１は、複数の車両１０を含む。ただし、情報処理システム１は、少なくとも一台の車両１０を含めばよい。

車両１０と、端末装置２０と、情報処理装置３０とは、ネットワーク２を介して通信可能である。ネットワーク２は、移動体通信網及びインターネット等を含む任意のネットワークであってよい。

車両１０は、オンデマンドバスとして運行される。オンデマンドバスは、ユーザの要求に応じて運行されるバスである。ユーザは、オンデマンドバスを事前に予約して利用する。

車両１０は、例えば、予め設定された基本ルートを走行する。ユーザは、例えば、予め指定した車両１０の配車場所で、車両１０に乗車する。車両１０の配車場所は、基本ルート上にあってもよいし、基本ルート上になくてもよい。車両１０の配車場所が基本ルート上にない場合、車両１０は、配車時刻が近づくと、基本ルートを外れて配車場所に向かう。

車両１０は、任意の自動車であってよい。車両１０は、例えば、ガソリン自動車、電気自動車（ＢＥＶ：Battery Electric Vehicle）、ハイブリッド自動車（ＨＥＶ：Hybrid Electric Vehicle）、プラグインハイブリッド自動車（ＰＨＥＶ：Plug-in Hybrid Electric Vehicle）又は燃料電池自動車（ＦＣＥＶ：Fuel Cell Electric Vehicle）等である。車両１０は、運転者によって運転されてもよい。車両１０の運転の一部は、任意のレベルで自動化されていてもよい。自動化のレベルは、例えば、ＳＡＥ（Society of Automotive Engineers）のレベル分けにおけるレベル１からレベル５の何れかである。車両１０は、ＭａａＳ（Mobility as a Service）専用車両であってもよい。

端末装置２０は、ユーザによって使用される。ユーザは、端末装置２０を操作してオンデマンドバスの利用予約をする。

端末装置２０は、ネットワーク２に接続可能であれば、任意の装置であってよい。端末装置２０は、例えば、携帯電話機、スマートフォン、タブレット又はパーソナルコンピュータ（ＰＣ：Personal Computer）等である。

情報処理装置３０は、オンデマンドバスの利用予約を管理する。情報処理装置３０は、ユーザの利用予約がキャンセルされる可能性が高いと判定した場合、オンデマンドバスの利用予約をキャンセルするか否かの問い合わせを、ネットワーク２を介して端末装置２０に送信する。

情報処理装置３０は、オンデマンドバスサービスを提供する主体によって運用されてよい。情報処理装置３０は、例えば、サーバとして機能するように構成された専用のコンピュータ、汎用のパーソナルコンピュータ又はクラウドコンピューティングシステム等である。

（車両の構成）
図２に示すように、車両１０は、通信部１１と、測位部１２と、出力部１３と、記憶部１４と、制御部１５とを備える。

通信部１１は、ネットワーク２に接続可能な少なくとも１つの通信モジュールを含んで構成される。通信モジュールは、例えば、ＬＴＥ（Long Term Evolution）、４Ｇ（4th Generation）又は５Ｇ（5th Generation）等の移動体通信規格に対応した通信モジュールである。ただし、通信モジュールは、これに限定されない。通信モジュールは、任意の通信規格に対応してよい。

測位部１２は、車両１０の位置情報を取得可能である。測位部１２は、衛星測位システムに対応する少なくとも１つの受信モジュールを含んで構成される。受信モジュールは、例えば、ＧＰＳ（Global Positioning System）に対応した受信モジュールである。ただし、受信モジュールは、これに限定されない。受信モジュールは、任意の衛星測位システムに対応した受信モジュールであってよい。

出力部１３は、データを出力可能である。出力部１３は、データを出力可能な少なくとも１つの出力用インタフェースを含んで構成される。出力用インタフェースは、例えば、ディスプレイ又はスピーカ等である。ディスプレイは、例えば、ＬＣＤ（Liquid Crystal Display）又は有機ＥＬ（Electro Luminescence）ディスプレイ等である。ただし、出力用インタフェースは、これに限定されない。

記憶部１４は、少なくとも１つの半導体メモリ、少なくとも１つの磁気メモリ、少なくとも１つの光メモリ又はこれらのうちの少なくとも２種類の組み合わせを含んで構成される。半導体メモリは、例えば、ＲＡＭ（Random Access Memory）又はＲＯＭ（Read Only Memory）等である。ＲＡＭは、例えば、ＳＲＡＭ（Static Random Access Memory）又はＤＲＡＭ（Dynamic Random Access Memory）等である。ＲＯＭは、例えば、ＥＥＰＲＯＭ(Electrically erasable programmable read only memory)等である。記憶部１４は、主記憶装置、補助記憶装置又はキャッシュメモリとして機能してよい。記憶部１４には、車両１０の動作に用いられるデータと、車両１０の動作によって得られたデータとが記憶される。

制御部１５は、少なくとも１つのプロセッサ、少なくとも１つの専用回路又はこれらの組み合わせを含んで構成される。プロセッサは、例えば、ＣＰＵ（Central Processing Unit）若しくはＧＰＵ（Graphics Processing Unit）等の汎用プロセッサ又は特定の処理に特化した専用プロセッサである。専用回路は、例えば、ＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit）等である。制御部１５は、車両１０の各部を制御しながら、車両１０の動作に関わる処理を実行する。

車両１０の機能は、本実施形態に係る車両プログラムを、制御部１５に相当するプロセッサで実行することにより実現される。つまり、車両１０の機能は、ソフトウェアにより実現される。車両プログラムは、車両１０の動作をコンピュータに実行させることにより、コンピュータを車両１０として機能させる。つまり、コンピュータは、車両プログラムに従って車両１０の動作を実行することにより、車両１０として機能する。

本開示において「プログラム」は、コンピュータで読取り可能な非一時的記録媒体に記録しておくことが可能である。コンピュータで読取り可能な非一時的記録媒体は、例えば、磁気記録装置、光ディスク、光磁気記録媒体又はＲＯＭである。プログラムの流通は、例えば、プログラムを記録したＤＶＤ（Digital Versatile Disc）又はＣＤ－ＲＯＭ（Compact Disc Read Only Memory）等の可搬型記録媒体を販売する、譲渡する、又は貸与することにより、行われる。プログラムは、サーバのストレージに格納されてよい。サーバのストレージに格納されたプログラムは、他のコンピュータに転送されることにより、流通されてもよい。プログラムは、プログラムプロダクトとして提供されてもよい。

本開示において「コンピュータ」は、例えば、可搬型記録媒体に記録されたプログラム又はサーバから転送されたプログラムを、一旦、主記憶装置に格納する。さらに、コンピュータは、主記憶装置に格納されたプログラムをプロセッサで読み取り、読み取ったプログラムに従った処理をプロセッサで実行する。コンピュータは、可搬型記録媒体から直接プログラムを読み取り、プログラムに従った処理を実行してもよい。コンピュータは、コンピュータにサーバからプログラムが転送される度に、逐次、受け取ったプログラムに従った処理を実行してもよい。コンピュータは、サーバからコンピュータへのプログラムの転送を行わず、実行指示及び結果取得のみによって機能を実現する、いわゆるＡＳＰ（Application Service Provider）型のサービスによって処理を実行してもよい。プログラムには、電子計算機による処理の用に供する情報であってプログラムに準ずるものが含まれる。例えば、コンピュータに対する直接の指令ではないがコンピュータの処理を規定する性質を有するデータは、「プログラムに準ずるもの」に該当する。

車両１０の一部又は全ての機能が、制御部１５に相当する専用回路により実現されてもよい。つまり、車両１０の一部又は全ての機能が、ハードウェアにより実現されてもよい。

制御部１５は、ネットワーク２を介して情報処理装置３０から、運行スケジュールを通信部１１によって受信する。運行スケジュールは、例えば、後述の、予定ルート、配車予定場所の位置情報、配車予定時刻、降車予定場所の位置情報及び降車予定時刻の少なくとも何れかを含む。ただし、運行スケジュールは、これらに限定されない。運行スケジュールは、車両１０の運行に用いられる任意の情報を含んでよい。制御部１５は、受信した運行スケジュールを記憶部１４に格納する。制御部１５は、新たな運行スケジュールを受信した場合、新たな運行スケジュールによって、記憶部１４の運行スケジュールを更新してよい。

制御部１５は、記憶部１４に記憶された運行スケジュールに従って車両１０が走行するように制御する。一例として、車両１０が運転者によって運転される場合、制御部１５は、運行スケジュールを出力部１３に出力させることにより、運行スケジュールを運転者に提示する。制御部１５は、運行スケジュールを運転者に提示することにより、運行スケジュールに従った車両１０の運転を運転者に促す。他の例として、車両１０の運転が自動化されている場合、制御部１５は、車両１０の自動運転システムに運行スケジュールに従った車両１０の運転を指示する。

制御部１５は、例えば車両１０の走行中、車両１０の位置情報を測位部１２によって取得する。制御部１５は、取得した車両１０の位置情報を、ネットワーク２を介して情報処理装置３０に通信部１１によって送信する。制御部１５は、任意の時間間隔で、車両１０の位置情報を取得し、取得した車両１０の位置情報を情報処理装置３０に送信してよい。この時間間隔は、車両１０の速度等に基づき、適宜設定されてよい。

（端末装置の構成）
図２に示すように、端末装置２０は、通信部２１と、測位部２２と、入力部２３と、出力部２４と、記憶部２５と、制御部２６とを備える。

通信部２１は、ネットワーク２に接続可能な少なくとも１つの通信モジュールを含んで構成される。通信モジュールは、例えば、ＬＴＥ、４Ｇ又は５Ｇ等の移動体通信規格に対応した通信モジュールである。ただし、通信モジュールは、これに限定されない。通信モジュールは、任意の通信規格に対応してよい。

測位部２２は、端末装置２０の位置情報を取得可能である。測位部２２は、衛星測位システムに対応する少なくとも１つの受信モジュールを含んで構成される。受信モジュールは、例えば、ＧＰＳに対応した受信モジュールである。ただし、受信モジュールは、これに限定されない。受信モジュールは、任意の衛星測位システムに対応した受信モジュールであってよい。

入力部２３は、ユーザからの入力を受付可能である。入力部２３は、ユーザからの入力を受付可能な少なくとも１つの入力用インタフェースを含んで構成される。入力用インタフェースは、例えば、物理キー、静電容量キー、ポインティングデバイス、ディスプレイと一体的に設けられたタッチスクリーン又はマイク等である。ただし、入力用インタフェースは、これに限定されない。

出力部２４は、データを出力可能である。出力部２４は、データを出力可能な少なくとも１つの出力用インタフェースを含んで構成される。出力用インタフェースは、例えば、ディスプレイ又はスピーカ等である。ディスプレイは、例えば、ＬＣＤ又は有機ＥＬディスプレイ等である。ただし、出力用インタフェースは、これに限定されない。

記憶部２５は、少なくとも１つの半導体メモリ、少なくとも１つの磁気メモリ、少なくとも１つの光メモリ又はこれらのうちの少なくとも２種類の組み合わせを含んで構成される。半導体メモリは、例えば、ＲＡＭ又はＲＯＭ等である。ＲＡＭは、例えば、ＳＲＡＭ又はＤＲＡＭ等である。ＲＯＭは、例えば、ＥＥＰＲＯＭ等である。記憶部２５は、主記憶装置、補助記憶装置又はキャッシュメモリとして機能してよい。記憶部２５には、端末装置２０の動作に用いられるデータと、端末装置２０の動作によって得られたデータとが記憶される。

制御部２６は、少なくとも１つのプロセッサ、少なくとも１つの専用回路又はこれらの組み合わせを含んで構成される。プロセッサは、例えば、ＣＰＵ若しくはＧＰＵ等の汎用プロセッサ又は特定の処理に特化した専用プロセッサである。専用回路は、例えば、ＦＰＧＡ又はＡＳＩＣ等である。制御部２６は、端末装置２０の各部を制御しながら、端末装置２０の動作に関わる処理を実行する。

端末装置２０の機能は、本実施形態に係る端末プログラムを、制御部２６に相当するプロセッサで実行することにより実現される。つまり、端末装置２０の機能は、ソフトウェアにより実現される。端末プログラムは、端末装置２０の動作をコンピュータに実行させることにより、コンピュータを端末装置２０として機能させる。つまり、コンピュータは、端末プログラムに従って端末装置２０の動作を実行することにより、端末装置２０として機能する。

端末装置２０の一部又は全ての機能が、制御部２６に相当する専用回路により実現されてもよい。つまり、端末装置２０の一部又は全ての機能が、ハードウェアにより実現されてもよい。

制御部２６は、オンデマンドバスの利用予約の申請の入力を、入力部２３によって受け付ける。この申請の入力は、オンデマンドバスを事前に予約して利用したいユーザによって入力部２３から入力される。例えば、ユーザは、この申請の入力を、オンデマンドバスを利用したい日時の数日前から数時間前に、入力部２３から入力する。この申請の入力とともに、制御部２６は、オンデマンドバスの利用においてユーザが希望する希望条件の入力を入力部２３によって受け付けてよい。希望条件は、希望日、配車希望場所、配車希望時刻、降車希望場所、降車希望時刻及び搭乗者の希望人数の少なくとも何れかを含んでよい。希望日は、オンデマンドバスの利用をユーザが希望する日である。配車希望場所は、ユーザが希望するオンデマンドバスを配車する場所である。配車希望時刻は、ユーザが希望するオンデマンドバスを配車する時刻である。降車希望場所は、ユーザが希望するオンデマンドバスからユーザが降車する場所である。降車希望時刻は、ユーザが希望するオンデマンドバスからユーザが降車する時刻である。搭乗者の希望人数は、ユーザ希望するオンデマンドバスに搭乗する人数である。制御部２６は、これらの入力を入力部２３によって受け付けると、オンデマンドバスの利用予約の申請を示す申請情報を生成する。申請情報は、例えば、ユーザの識別情報及び希望条件の情報を含む。制御部２６は、生成した申請情報を、ネットワーク２を介して情報処理装置３０に通信部２１によって送信する。

制御部２６は、申請情報の送信後、ネットワーク２を介して情報処理装置３０から、予約完了通知及び予約情報を、通信部２１によって受信し得る。予約完了通知は、オンデマンドバスの利用予約が完了したことを示す通知である。予約情報は、例えば、予定日、配車予定場所、配車予定時刻、降車予定場所、降車予定時刻、搭乗者の予定人数及び予定ルートの少なくとも何れかの情報を含む。予定日は、ユーザがオンデマンドバスを利用することが予定される日である。配車予定場所は、オンデマンドバスが配車される予定の場所である。配車予定時刻は、オンデマンドバスが配車される予定の時刻である。降車予定場所は、オンデマンドバスからユーザが降車する予定の場所である。降車予定時刻は、オンデマンドバスからユーザが降車する予定の時刻である。搭乗者の予定人数は、オンデマンドバスに搭乗する予定の人数である。予定ルートは、配車予定場所から降車予定場所まで、オンデマンドバスが走行する予定のルートである。制御部２６は、予約完了通知及び予約情報を出力部２４に出力させる。予約完了通知等が出力部２４から出力されることにより、ユーザは、オンデマンドバスの利用予約が完了したこと等を把握し得る。

＜位置情報の送信処理＞
制御部２６は、例えば予約情報の受信後、端末装置２０の位置情報を測位部２２によって取得してよい。制御部２６は、取得した端末装置２０の位置情報をユーザの位置情報として、ネットワーク２を介して情報処理装置３０に、通信部２１によって送信してよい。制御部２６は、任意の時間間隔で、端末装置２０の位置情報を取得し、取得した端末装置２０の位置情報をユーザの位置情報として情報処理装置３０に送信してよい。この時間間隔は、ユーザの平均歩行速度等に基づき、適宜設定されてよい。

＜問い合わせの受信処理＞
制御部２６は、ネットワーク２を介して情報処理装置３０から、オンデマンドバスの利用予約をキャンセルするか否かの問い合わせを、通信部２１によって受信し得る。制御部２６は、この問い合わせを受信すると、オンデマンドバスの利用予約をキャンセルするか否かの問い合わせを出力部２４に出力させる。この問い合わせが出力部２４から出力されると、ユーザは、オンデマンドバスの利用予約をキャンセルするか否かを見直し得る。ユーザは、オンデマンドバスの利用予約をキャンセルすると決定した場合、オンデマンドバスの利用予約をキャンセルする入力を入力部２３から入力する。ユーザは、オンデマンドバスの利用予約をキャンセルしないと決定した場合、オンデマンドバスの利用予約をキャンセルしない入力を入力部２３から入力する。

制御部２６は、ユーザがオンデマンドバスの利用予約をキャンセルすると決定した場合、オンデマンドバスの利用予約をキャンセルする入力を入力部２３によって受け付け得る。制御部２６は、この入力を受け付けると、ネットワーク２を介して情報処理装置３０に、受信したキャンセルするか否かの問い合わせに対する回答として、オンデマンドバスの利用予約をキャンセルする回答を、通信部２１によって送信する。

制御部２６は、ユーザがオンデマンドバスの利用予約をキャンセルしないと決定した場合、オンデマンドバスの利用予約をキャンセルしない入力を入力部２３によって受け付け得る。制御部２６は、この入力を受け付けると、ネットワーク２を介して情報処理装置３０に、受信したキャンセルするか否かの問い合わせに対する回答として、オンデマンドバスの利用予約をキャンセルしない回答を、通信部２１によって送信する。

（情報処理装置の構成）
図２に示すように、情報処理装置３０は、通信部３１と、記憶部３２と、制御部３３とを備える。

通信部３１は、ネットワーク２に接続可能な少なくとも１つの通信モジュールを含んで構成される。通信モジュールは、例えば、有線ＬＡＮ（Local Area Network）又は無線ＬＡＮ等の規格に対応した通信モジュールである。ただし、通信モジュールは、これに限定されない。通信モジュールは、任意の通信規格に対応してよい。通信部３１は、通信モジュールによって有線ＬＡＮ又は無線ＬＡＮを介して、ネットワーク２に接続される。

記憶部３２は、少なくとも１つの半導体メモリ、少なくとも１つの磁気メモリ、少なくとも１つの光メモリ又はこれらのうちの少なくとも２種類の組み合わせを含んで構成される。半導体メモリは、例えば、ＲＡＭ又はＲＯＭ等である。ＲＡＭは、例えば、ＳＲＡＭ又はＤＲＡＭ等である。ＲＯＭは、例えば、ＥＥＰＲＯＭ等である。記憶部３２は、主記憶装置、補助記憶装置又はキャッシュメモリとして機能してよい。記憶部３２には、情報処理装置３０の動作に用いられるデータと、情報処理装置３０の動作によって得られたデータとが記憶される。

制御部３３は、少なくとも１つのプロセッサ、少なくとも１つの専用回路又はこれらの組み合わせを含んで構成される。プロセッサは、例えば、ＣＰＵ若しくはＧＰＵ等の汎用プロセッサ又は特定の処理に特化した専用プロセッサである。専用回路は、例えば、ＦＰＧＡ又はＡＳＩＣ等である。制御部３３は、情報処理装置３０の各部を制御しながら、情報処理装置３０の動作に関わる処理を実行する。

情報処理装置３０の機能は、本実施形態に係る処理プログラムを、制御部３３に相当するプロセッサで実行することにより実現される。つまり、情報処理装置３０の機能は、ソフトウェアにより実現される。処理プログラムは、情報処理装置３０の動作をコンピュータに実行させることにより、コンピュータを情報処理装置３０として機能させる。つまり、コンピュータは、処理プログラムに従って情報処理装置３０の動作を実行することにより、情報処理装置３０として機能する。

情報処理装置３０の一部又は全ての機能が、制御部３３に相当する専用回路により実現されてもよい。つまり、情報処理装置３０の一部又は全ての機能が、ハードウェアにより実現されてもよい。

制御部３３は、ネットワーク２を介して端末装置２０から、申請情報を、通信部３１によって受信する。制御部３３は、申請情報を受信すると、オンデマンドバスの予約処理を実行する。

＜予約処理＞
制御部３３は、複数の車両１０のうちから、受信した申請情報に含まれるユーザの希望条件を満たす車両１０を抽出する。制御部３３は、ユーザの希望条件を満たす車両１０が存在しない場合、希望条件の変更をユーザに提案する提案情報を、ネットワーク２を介して端末装置２０に通信部３１によって送信してよい。この場合、端末装置２０では、制御部２６は、ネットワーク２を介して情報処理装置３０から、提案情報を通信部２１によって受信する。制御部２６は、提案情報を出力部２４に出力させる。ユーザは、出力部２４から出力された提案情報を見ると、変更後の希望条件の入力を入力部２３から入力する。制御部２６は、変更後の希望条件の情報を、ネットワーク２を介して情報処理装置３０に通信部２１によって送信する。情報処理装置３０では、制御部３３は、ネットワーク２を介して端末装置２０から、変更後の希望条件の情報を通信部３１によって受信する。制御部３３は、複数の車両１０のうちから、変更後の希望条件を満たす車両１０を抽出する。

制御部３３は、ユーザの希望条件を満たす車両１０を抽出すると、ユーザの希望条件を満たすように、抽出した車両１０の運行スケジュールを変更する。制御部３３は、変更後の運行スケジュールを、ネットワーク２を介して抽出した車両１０に、通信部３１によって送信する。また、制御部３３は、予約情報を生成する。制御部３３は、予約完了通知及び予約情報を、ネットワーク２を介して端末装置２０に、通信部３１によって送信する。

＜問い合わせの送信処理＞
制御部３３は、例えば予約処理の実行後、オンデマンドバスの利用予約がキャンセルされる可能性が高いか否かを、オンデマンドバスの利用予約をしたユーザの情報に基づいて判定する。ユーザの情報は、ユーザによってオンデマンドバスの利用予約がキャンセルされる可能性が高いか否かを判定可能な情報であれば、ユーザの任意の情報であってよい。制御部３３は、オンデマンドバスの利用予約がキャンセルされる可能性が高いと判定した場合、オンデマンドバスの利用予約をキャンセルするか否かの問い合わせを、ネットワーク２を介して端末装置２０に、通信部３１によって送信する。

以下、オンデマンドバスの利用予約がキャンセルされる可能性が高いか否かを判定する判定処理の一例について説明する。

［例１］
ユーザの情報は、ユーザのスケジュールの情報を含んでよい。制御部３３は、ユーザのスケジュールを、ネットワーク２を介して端末装置２０又は外部装置から、通信部３１によって受信してよい。この外部装置は、例えば、ユーザのスケジュールを管理するクラウドサーバ等である。

制御部３３は、例えばユーザのスケジュールの情報を解析し、ユーザのスケジュールにオンデマンドバスの配車予定場所へのユーザの移動時間が含まれているか否かを判定してよい。制御部３３は、ユーザのスケジュールにオンデマンドバスの配車予定場所へのユーザの移動時間が含まれていないと判定した場合、オンデマンドバスの利用予約がキャンセルされる可能性が高いと判定してよい。例えば、オンデマンドバスの配車予定時刻が１２：００であり、ユーザのスケジュールの情報に、終了予定時刻が１２：００である会議の情報が含まれているものとする。この場合、制御部３３は、ユーザのスケジュールにオンデマンドバスの配車予定場所へのユーザの移動時間が含まれていないと判定する。

ユーザのスケジュールにオンデマンドバスの配車予定場所への移動時間が含まれていない場合、ユーザが配車予定場所に配車予定時刻までに到着できず、結果として、ユーザがオンデマンドバスに乗車できなくなる可能性が高い。つまり、オンデマンドバスの利用予約がキャンセルされる可能性が高くなる。このような場合に、オンデマンドバスの利用予約をキャンセルするか否かの問い合わせを端末装置２０に送信することにより、キャンセルするか否かを見直す機会をユーザに適切に与えることができる。

［例２］
制御部３３は、例えば上述したユーザのスケジュールの情報を解析し、ユーザのスケジュールにオンデマンドバスからユーザが降車した後のイベントが登録されているか否かを判定してよい。制御部３３は、ユーザのスケジュールにオンデマンドバスからユーザが降車した後のイベントが登録されていないと判定した場合、オンデマンドバスの利用予約がキャンセルされる可能性が高いと判定してよい。イベントは、予定される任意の行事であってよい。イベントは、例えば、習い事、通院又は食事会等である。

ユーザは、オンデマンドバスを利用してイベントの開催地に行くことがある。この場合、ユーザのスケジュールには、ユーザがオンデマンドバスから降車した後のイベントが登録されている可能性が高い。つまり、ユーザのスケジュールにユーザがオンデマンドバスから降車した後のイベントが登録されていない場合、イベントの開催地まで行く必要がユーザにないため、オンデマンドバスの利用予約がキャンセルされる可能性が高い。このような場合に、オンデマンドバスの利用予約をキャンセルするか否かの問い合わせを端末装置２０に送信することにより、キャンセルするか否かを見直す機会をユーザに適切に与えることができる。

ここで、ユーザが帰宅するためにオンデマンドバスを利用する場合がある。さらに、ユーザが帰宅をイベントとしてスケジュールに登録しない場合がある。この場合、ユーザがオンデマンドバスを利用する予定であっても、ユーザの帰宅がユーザのスケジュールに降車後のイベントとして登録されていないこととなる。

そこで、制御部３３は、オンデマンドバスの降車予定時刻がユーザの帰宅予定時刻よりも第１時間前である場合、ユーザのスケジュールにオンデマンドバスからユーザが降車した後のイベントが登録されているか否かを判定してもよい。ユーザの帰宅予定時刻は、ユーザが自宅に到着することが予定される時刻であってよい。制御部３３は、例えば上述したユーザのスケジュールの情報を解析し、ユーザの帰宅予定時刻を推定してよい。第１時間は、例えば習い事等のイベントの平均時間等に基づき、予め設定されてよい。

［例３］
ユーザの情報は、ユーザのオンデマンドバスの利用予約のキャンセル履歴の情報を含んでよい。制御部３３は、ユーザの過去のオンデマンドバスの利用予約の情報から、ユーザのキャンセル履歴の情報を取得してよい。制御部３３は、ユーザのキャンセル履歴の情報からユーザのキャンセル率を取得してよい。ユーザのキャンセル率は、ユーザのオンデマンドバスの予約数に対するキャンセル数の割合であってよい。制御部３３は、例えば予め設定された任意の期間内の、ユーザのオンデマンドバスの予約数に対するキャンセル数の割合を算出することにより、キャンセル率を取得してよい。

なお、ユーザが初めてオンデマンバスの利用予約をする場合、当該ユーザのキャンセル履歴の情報が取得できない場合がある。この場合、制御部２６は、当該ユーザのキャンセル履歴の情報として、複数の他のユーザのキャンセル履歴の情報を用いてよい。制御部２６は、複数の他のユーザのキャンセル履歴の情報から複数の他のユーザのキャンセル率の平均値を算出し、算出した平均値をユーザのキャンセル率として用いてよい。

制御部２６は、取得したキャンセル率が閾値以上である場合、オンデマンドバスの利用予約がキャンセルされる可能性が高いと判定してよい。閾値は、例えば複数のユーザのキャンセル率の平均値に基づいて予め設定されてもよいし、後述するようなものであってもよい。

ユーザのキャンセル率が閾値以上である場合、例えば他のユーザよりも、ユーザの利用予約がキャンセルされる可能性が高い。このようにユーザのキャンセル率が閾値以上である場合に、オンデマンドバスの利用予約がキャンセルされる可能性が高いと判定し、情報処理装置３０から端末装置２０へキャンセルするか否かの問い合わせを送信する。このような構成により、オンデマンドバスの利用予約をキャンセルするか否かを見直す機会をユーザに適切に与えることができる。

閾値は、オンデマンドバスが配車予定場所に向かうために基本ルートから外れる前の第２時間内では、この第２時間が経過した後よりも、低くてよい。この場合、制御部２６は、オンデマンドバスが基本ルートを外れる前の第２時間内では、第２時間が経過した後よりも、閾値を低く設定してよい。第２時間は、例えば車両１０の平均速度等に基づき、予め設定されてよい。制御部３３は、車両１０の運行スケジュールに基づき、オンデマンドバスが基本ルートから外れる第２時間前を推定してよい。また、制御部３３は、ネットワーク２を介して車両１０から、車両１０の位置情報を通信部３１によって受信してよい。制御部３３は、受信した車両１０の位置情報と基本ルートとによって、オンデマンドバスが基本ルートから外れたか否かを判定してよい。

ここで、オンデマンドバスが基本ルートを走行する場合に、オンデマンドバスの配車予定場所が基本ルート上にない場合がある。この場合、オンデマンドバスは、配車予定時刻が近づくと、基本ルートを外れて配車予定場所に向かう。オンデマンドバスが基本ルートから外れた後に利用予約がキャンセルされた場合、オンデマンドバスには、基本ルートに戻ることが要求される。オンデマンドバスが基本ルートから外れた後に基本ルートに戻る場合、追加の燃料費等が発生するため、オンデマンドバスの運行にかかる追加のコストが発生する。

オンデマンドバスが基本ルートを外れる前の第２時間内において閾値が低くなることにより、当該第２時間内では、オンデマンドバスの利用予約をキャンセルするか否かの問い合わせが端末装置２０に送信されやすくなる。このような構成により、オンデマンドバスが基本ルートから外れる前に、オンデマンドバスの利用予約をキャンセルするか否かを見直す機会をユーザに与えることができる。さらに、ユーザがオンデマンドバスの利用予約をキャンセルしたい場合、オンデマンドバスが基本ルートを外れる前に、オンデマンドバスの利用予約がキャンセルされ得る。オンデマンドバスが基本ルートを外れる前に利用予約がキャンセルされることにより、利用予約がキャンセルされた後にオンデマンドバスが基本ルートに戻ることによる追加のコストの発生を抑制することができる。

他の例として、閾値は、オンデマンドバスが走行する予定ルートがユーザによって以前キャンセルされたことがある場合、予定ルートがユーザによって以前キャンセルされたことがない場合よりも、低くてもよい。この場合、制御部３３は、オンデマンドバスが走行する予定ルートがユーザによって以前キャンセルされたことがある場合、予定ルートがユーザによって以前キャンセルされたことがない場合よりも、閾値を低く設定してもよい。

オンデマンドバスの予定ルートがユーザによって以前キャンセルされたことがある場合、その予定ルートがユーザによって以前キャンセルされたことがない場合よりも、オンデマンドバスの利用予約がキャンセルされる可能性が高い。予定ルートがユーザによって以前キャンセルされたことがある場合に閾値が低くなることにより、予定ルートがユーザによって以前キャンセルされたことがない場合よりも、キャンセルするか否かの問い合わせが端末装置２０に送信されやすくなる。このような構成により、オンデマンドバスの利用予約をキャンセルするか否かを見直す機会をユーザにより適切に与えることができる。

＜判定処理のタイミング＞
制御部３３は、上述した判定処理を、任意のタイミングで実行してよい。以下、判定処理を実行するタイミングの一例について説明する。

［例１］
オンデマンドバスが基本ルートを走行する場合に、オンデマンドバスの配車予定場所が基本ルート上にない場合がある。この場合、制御部３３は、オンデマンドバスが配車予定場所に向かうために基本ルートから外れる前に、オンデマンドバスの利用予約がキャンセルされる可能性が高いか否かを判定してよい。このような構成により、オンデマンドバスの利用予約がキャンセルされる可能性が高い場合、オンデマンドバスが基本ルートから外れる前に、キャンセルするか否かの問い合わせを端末装置２０に送信することができる。さらに、ユーザがオンデマンドバスの利用予約をキャンセルしたい場合、オンデマンドバスが基本ルートから外れる前に、オンデマンドバスの利用予約がキャンセルされ得る。このような構成により、利用予約がキャンセルされた後にオンデマンドバスが基本ルートに戻ることによる追加のコストの発生を抑制することができる。

［例２］
制御部３３は、オンデマンドバスの配車予定時刻の第３時間前に、オンデマンドバスの利用予約がキャンセルされる可能性が高いか否か判定してよい。第３時間は、例えばユーザの情報に基づいて予め設定されてもよいし、以下に説明するようなものであってもよい。

第３時間は、ユーザの位置とオンデマンドバスの配車予定場所の位置とが離れているほど、長くてよい。この場合、制御部３３は、ユーザの位置とオンデマンドバスの配車予定場所の位置とが離れているほど、第３時間を長く設定してよい。制御部３３は、ユーザの位置情報を、ネットワーク２を介して端末装置２０から、通信部３１によって受信してよい。例えば、ユーザの位置とオンデマンドバスの配車予定場所の位置とが離れているほど、ユーザが配車予定場所に到達するまでにかかる時間が長くなる。そのため、ユーザの位置とオンデマンドバスの配車予定場所の位置とが離れているほど、ユーザが配車予定時刻までに配車予定場所に到達できず、結果として、ユーザがオンデマンドバスに乗車できなくなる可能性が高くなる。つまり、ユーザの位置とオンデマンドバスの配車予定場所の位置とが離れているほど、キャンセルされる可能性が高くなる。ユーザの位置とオンデマンドバスの配車予定場所の位置とが離れているほど、第３時間が長くなることにより、キャンセルするか否かの問い合わせを端末装置２０に送信するタイミングが早くなる。このような構成により、キャンセルされる可能性が高いほど、キャンセルするか否かの問い合わせを端末装置２０に送信するタイミングが早くなり得る。

第３時間は、オンデマンドバスの予約数が高いほど、長くてよい。この場合、制御部３３は、オンデマンドバスの予約数が高いほど、第３時間が長くなるように設定してよい。オンデマンドバスの予約数は、オンデマンドバスが利用される予定日の予約数であってよい。オンデマンドバスの予約数が高いほど、第３時間が長くなることにより、キャンセルするか否かの問い合わせを端末装置２０に送信するタイミングが早くなる。このような構成により、ユーザがオンデマンドバスの利用予約をキャンセルしたい場合、オンデマンドバスの利用予約が早いタイミングでキャンセルされ得る。オンデマンドバスの利用予約が早いタイミングでキャンセルされることにより、他のユーザがオンデマンドバスの利用予約できる可能性が高くなる。

第３時間は、ユーザのキャンセル率が高いほど、長くてよい。この場合、制御部３３は、ユーザのキャンセル率が高いほど、第３時間を長く設定してよい。上述したように、制御部３３は、ユーザのオンデマンドバスの利用予約のキャンセル履歴の情報からユーザのキャンセル率を取得してよい。ユーザのキャンセル率が高いほど、第３時間が長くなることにより、キャンセルするか否かの問い合わせを端末装置２０に送信するタイミングが早くなる。このような構成により、キャンセルされる可能性が高いほど、キャンセルするか否かの問い合わせを端末装置２０に送信するタイミングが早くなり得る。

＜回答の受信処理＞
制御部３３は、キャンセルするか否かの問い合わせの送信後、ネットワーク２を介して端末装置２０から、例えば当該問い合わせに対する回答として、オンデマンドバスの利用予約をキャンセルする回答を、通信部３１によって受信し得る。制御部３３は、この回答を受信すると、キャンセル処理を実行する。

キャンセル処理では、制御部３３は、複数の車両１０のうちから、ユーザが乗車する予定だった車両１０を特定する。制御部３３は、特定した車両１０の運行スケジュールを変更する。制御部３３は、変更後の運行スケジュールを、ネットワーク２を介して特定した車両１０に通信部３１によって送信する。

キャンセル処理では、制御部３３は、ユーザに対して請求するキャンセル料金を決定する。制御部３３は、キャンセルする回答を受信した場合、ユーザに対してキャンセル料金を請求しないと決定してもよい。このような構成により、オンデマンドバスの利用予約をキャンセルするか否かの問い合わせに対して、ユーザに積極的に回答させることができる。

キャンセル料金の他の例として、制御部３３は、キャンセルする回答を受信した場合、設定金額よりも低額なキャンセル料金を請求すると決定してもよい。つまり、キャンセル料金は、キャンセルする回答が受信された場合、設定金額よりも、低額であってよい。設定金額は、例えば、オンデマンドバスの配車予定時刻の直前に利用予約がキャンセルされた場合にユーザに請求するキャンセル料金等である。キャンセル料金を低額にすることにより、オンデマンドバスの利用予約をキャンセルするか否かの問い合わせに対して、ユーザに積極的に回答させることができる。

キャンセル料金のさらに他の例として、制御部３３は、キャンセルする回答を受信したタイミングが早いほど、低額なキャンセル料金を決定してもよい。つまり、キャンセル料金は、キャンセルする回答が受信されたタイミングが早いほど、低額であってよい。このような構成により、オンデマンドバスの利用予約をキャンセルするか否かの問い合わせに対して、ユーザに速やかに回答させることができる。

制御部３３は、キャンセルするか否かの問い合わせの送信後、ネットワーク２を介して端末装置２０から、例えば当該問い合わせに対する回答として、オンデマンドバスの利用予約をキャンセルしない回答を通信部３１によって受信し得る。制御部３３は、この回答を受信した場合、オンデマンドバスの配車予定場所の位置情報を端末装置２０に通信部３１によって送信してよい。この場合、端末装置２０では、制御部２６は、ネットワーク２を介して情報処理装置３０から、オンデマンドバスの配車予定場所の位置情報を通信部２１によって受信する。制御部２６は、オンデマンドバスの配車予定場所の位置情報を出力部２４に出力させる。オンデマンドバスの配車予定場所の位置情報が出力部２４から出力されることにより、ユーザは、オンデマンドバスの配車予定場所を確認することができる。このような構成により、ユーザが配車予定場所に到達できずに、結果として、オンデマンドバスの利用予約がキャンセルされる可能性が低減する。

制御部３３は、キャンセルしない回答を受信した場合であって、ユーザがオンデマンドバスの利用予約を以前キャンセルしたことがある場合、オンデマンドバスの配車予定場所の位置情報を端末装置２０に通信部３１によって送信してもよい。

制御部３３は、キャンセルしない回答を受信した場合、ユーザの位置からオンデマンドバスの配車予定場所までの移動時間を取得してもよい。例えば、制御部３３は、端末装置２０から受信したユーザの最新の位置情報と、オンデマンドバスの配車予定場所の位置情報と、ユーザの平均速度とに基づき、移動時間を算出して取得する。制御部３３は、取得した移動時間の情報を上述した配車予定場所の位置情報とともに、ネットワーク２を介して端末装置２０に通信部３１によって送信してもよい。この場合、端末装置２０では、制御部２６は、ネットワーク２を介して情報処理装置３０から、移動時間をオンデマンドバスの配車予定場所の位置情報とともに通信部２１によって受信する。制御部２６は、移動時間とオンデマンドバスの配車予定場所の位置情報とを出力部２４に出力させる。移動時間が出力部２４から出力されることにより、ユーザは、オンデマンドバスの配車予定場所までの移動時間を把握することができる。

（端末装置の動作）
図３は、図２に示す端末装置２０の処理を示すフローチャートである。この処理は、本実施形態に係る情報処理方法の一例に相当する。制御部２６は、オンデマンドバスの利用予約の申請の入力を入力部２３によって受け付けると、ステップＳ１からの処理を開始する。

制御部２６は、入力部２３によって受け付けた入力に基づき、申請情報を生成する（ステップＳ１）。制御部２６は、ネットワーク２を介して情報処理装置３０に、申請情報を通信部２１によって送信する（ステップＳ２）。制御部２６は、ネットワーク２を介して情報処理装置３０から、予約完了通知及び予約情報を、通信部２１によって受信する（ステップＳ３）。制御部２６は、予約完了通知及び予約情報を出力部２４に出力させる（ステップＳ４）。

制御部２６は、ネットワーク２を介して情報処理装置３０から、オンデマンドバスの利用予約をキャンセルするか否かの問い合わせを、通信部２１によって受信したか否かを判定する（ステップＳ５）。制御部２６は、キャンセルするか否かの問い合わせを受信したと判定した場合（ステップＳ５：ＹＥＳ）、ステップＳ６の処理に進む。ステップＳ６の処理では、制御部２６は、オンデマンドバスの利用予約をキャンセルするか否かの問い合わせを出力部２４に出力させる。一方、制御部２６は、キャンセルするか否かの問い合わせを受信したと判定しない場合（ステップＳ５：ＮＯ）、ステップＳ５の処理を再び実行する。

制御部２６は、オンデマンドバスの利用予約をキャンセルする入力を入力部２３によって受け付けたか否かを判定する（ステップＳ７）。制御部２６は、キャンセルする入力を受け付けたと判定した場合（ステップＳ７：ＹＥＳ）、ステップＳ８の処理に進む。一方、制御部２６は、キャンセルする入力を受け付けたと判定しない場合（ステップＳ７：ＮＯ）、ステップＳ９の処理に進む。

ステップＳ８の処理では、制御部２６は、ネットワーク２を介して情報処理装置３０に、オンデマンドバスの利用予約をキャンセルする回答を、通信部２１によって送信する。

ステップＳ９の処理では、制御部２６は、オンデマンドバスの利用予約をキャンセルしない入力を入力部２３によって受け付ける。制御部２６は、ネットワーク２を介して情報処理装置３０に、オンデマンドバスの利用予約をキャンセルしない回答を、通信部２１によって送信する（ステップＳ１０）。

ステップＳ１１の処理では、制御部２６は、ネットワーク２を介して情報処理装置３０から、オンデマンドバスの配車予定場所の位置情報を通信部２１によって受信する。制御部２６は、オンデマンドバスの配車予定場所の位置情報を出力部２４に出力させる（ステップＳ１２）。

（情報処理装置の動作）
図４は、図２に示す情報処理装置３０の処理を示すフローチャートである。この処理は、本実施形態に係る情報処理方法の一例に相当する。例えば、端末装置２０が申請情報を情報処理装置３０に送信すると、制御部３３は、ステップＳ２１からの処理を開始する。

制御部３３は、ネットワーク２を介して端末装置２０から、申請情報を通信部３１によって受信する（ステップＳ２１）。制御部３３は、申請情報を受信すると、予約処理を実行する（ステップＳ２２）。

制御部３３は、オンデマンドバスの利用予約がキャンセルされる可能性が高いか否かをユーザの情報に基づいて判定する（ステップＳ２３）。制御部３３は、オンデマンドバスの利用予約がキャンセルされる可能性が高いと判定した場合（ステップＳ２３：ＹＥＳ）、ステップＳ２４の処理に進む。一方、制御部３３は、オンデマンドバスの利用予約がキャンセルされる可能性が高いと判定しない場合（ステップＳ２３：ＮＯ）、図４に示すような処理を終了する。

ステップＳ２４の処理では、制御部３３は、ネットワーク２を介して端末装置２０に、オンデマンドバスの利用予約をキャンセルするか否かの問い合わせを、通信部３１によって送信する。

ステップＳ２５の処理では、制御部３３は、ネットワーク２を介して端末装置２０から、オンデマンドバスの利用予約をキャンセルする回答を通信部３１によって受信したか否かを判定する。制御部３３は、オンデマンドバスの利用予約をキャンセルする回答を受信したと判定した場合（ステップＳ２５：ＹＥＳ）、ステップＳ２６の処理に進む。ステップＳ２６の処理では、制御部３３は、キャンセル処理を実行する。一方、制御部３３は、オンデマンドバスの利用予約をキャンセルする回答を受信した判定しない場合（ステップＳ２５：ＮＯ）、ステップＳ２７の処理に進む。

ステップＳ２７の処理では、制御部３３は、ネットワーク２を介して端末装置２０から、オンデマンドバスの利用予約をキャンセルしない回答を、通信部３１によって受信する。制御部３３は、オンデマンドバスの配車予定場所の位置情報を、ネットワーク２を介して端末装置２０に通信部３１によって送信する（ステップＳ２８）。

このように情報処理装置３０では、制御部３３は、オンデマンドバスの利用予約がキャンセルされる可能性が高いと判定した場合、キャンセルするか否かの問い合わせを、ネットワーク２を介して端末装置２０に通信部３１によって送信する。キャンセルされる可能性が高いと判定した場合にキャンセルするか否かの問い合わせを端末装置２０に送信することにより、ユーザにオンデマンドバスの利用予約をキャンセルするか否かを見直す機会を適切に与えることができる。よって、本実施形態によれば、オンデマンドバスの利用予約をキャンセルするか否かを見直す機会をユーザに適切に与える技術を提供することができる。

本開示を諸図面及び実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形及び改変を行ってもよいことに注意されたい。したがって、これらの変形及び改変は本開示の範囲に含まれることに留意されたい。例えば、各構成部又は各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の構成部又はステップ等を１つに組み合わせたり、或いは分割したりすることが可能である。

例えば、汎用のコンピュータを、上述した実施形態に係る情報処理装置３０として機能させる実施形態も可能である。具体的には、上述した実施形態に係る情報処理装置３０の各機能を実現する処理内容を記述したプログラムを、汎用のコンピュータのメモリに格納し、プロセッサによって当該プログラムを読み出して実行させる。したがって、本開示は、プロセッサが実行可能なプログラム、又は、当該プログラムを記憶する非一時的なコンピュータ可読媒体としても実現可能である。

１ 情報処理システム
２ ネットワーク
１０ 車両
１１ 通信部
１２ 測位部
１３ 出力部
１４ 記憶部
１５ 制御部
２０ 端末装置
２１ 通信部
２２ 測位部
２３ 入力部
２４ 出力部
２５ 記憶部
２６ 制御部
３０ 情報処理装置
３１ 通信部
３２ 記憶部
３３ 制御部

Claims (20)

1. 通信部と、
   オンデマンドバスの利用予約がキャンセルされる可能性が高いと前記利用予約をしたユーザの情報に基づいて判定した場合、前記利用予約をキャンセルするか否かの問い合わせを、前記ユーザの端末装置に前記通信部によって送信する制御部と、を備える、情報処理装置。
2. 前記ユーザの情報は、前記ユーザのスケジュールの情報を含み、
   前記制御部は、前記ユーザのスケジュールに前記オンデマンドバスの配車予定場所への前記ユーザの移動時間が含まれていないと判定した場合、前記利用予約がキャンセルされる可能性が高いと判定する、請求項１に記載の情報処理装置。
3. 前記ユーザの情報は、前記ユーザのスケジュールの情報を含み、
   前記制御部は、前記ユーザのスケジュールに前記オンデマンドバスから前記ユーザが降車した後のイベントが登録されていないと判定した場合、前記利用予約がキャンセルされる可能性が高いと判定する、請求項１に記載の情報処理装置。
4. 前記制御部は、前記オンデマンドバスからの前記ユーザの降車予定時刻が前記ユーザの帰宅予定時刻よりも第１時間前である場合、前記ユーザのスケジュールに前記イベントが登録されているか否かを判定する、請求項３に記載の情報処理装置。
5. 前記ユーザの情報は、前記ユーザのオンデマンドバスの利用予約のキャンセル履歴の情報を含み、
   前記制御部は、前記キャンセル履歴の情報から前記ユーザのキャンセル率を取得し、取得した前記キャンセル率が閾値以上である場合、前記利用予約がキャンセルされる可能性が高いと判定する、請求項１に記載の情報処理装置。
6. 前記オンデマンドバスは、予め設定された基本ルートを走行し、
   前記閾値は、前記オンデマンドバスが配車予定場所に向かうために前記基本ルートから外れる前の第２時間内では、前記第２時間が経過した後よりも、低い、請求項５に記載の情報処理装置。
7. 前記閾値は、前記オンデマンドバスが走行する予定ルートが前記ユーザによって以前キャンセルされたことがある場合、前記予定ルートが前記ユーザによって以前キャンセルされたことがない場合よりも、低い、請求項５に記載の情報処理装置。
8. 前記オンデマンドバスは、予め設定された基本ルートを走行し、
   前記制御部は、前記オンデマンドバスが配車予定場所に向かうために前記基本ルートを外れる前に、前記利用予約がキャンセルされる可能性が高いか否かを判定する、請求項１から７までの何れか一項に記載の情報処理装置。
9. 前記制御部は、前記オンデマンドバスの配車予定時刻の第３時間前に、前記利用予約がキャンセルされる可能性が高いか否かを判定する、請求項１から７までの何れか一項に記載の情報処理装置。
10. 前記第３時間は、前記ユーザの位置と前記オンデマンドバスの配車予定場所の位置とが離れているほど、長い、請求項９に記載の情報処理装置。
11. 前記第３時間は、前記オンデマンドバスの予約数が高いほど、長い、請求項９に記載の情報処理装置。
12. 前記ユーザの情報は、前記ユーザのオンデマンドバスの利用予約のキャンセル履歴の情報を含み、
    前記第３時間は、前記キャンセル履歴の情報から取得される前記ユーザのキャンセル率が高いほど、長い、請求項９に記載の情報処理装置。
13. 前記制御部は、前記問い合わせの送信後、前記端末装置から、前記オンデマンドバスの利用予約をキャンセルする回答を前記通信部によって受信した場合、前記ユーザに対してキャンセル料金を請求しないと決定する、請求項１から１２までの何れか一項に記載の情報処理装置。
14. 前記制御部は、前記問い合わせの送信後、前記端末装置から、前記オンデマンドバスの利用予約をキャンセルする回答を前記通信部によって受信した場合、前記ユーザに対して設定金額よりも低額なキャンセル料金を請求すると決定する、請求項１から１２までの何れか一項に記載の情報処理装置。
15. 前記制御部は、前記キャンセルする回答を受信したタイミングが早いほど、低額になるようにキャンセル料金を決定する、請求項１４に記載の情報処理装置。
16. 前記制御部は、前記問い合わせの送信後、前記端末装置から、前記オンデマンドバスの利用予約をキャンセルしない回答を前記通信部によって受信した場合、前記オンデマンドバスの配車予定場所の位置情報を前記端末装置に前記通信部によって送信する、請求項１から１５までの何れか一項に記載の情報処理装置。
17. 前記制御部は、前記キャンセルしない回答を受信した場合であって、前記ユーザがオンデマンドバスの利用予約を以前キャンセルしたことがある場合、前記オンデマンドバスの配車予定場所の位置情報を前記端末装置に前記通信部によって送信する、請求項１から１６までの何れか一項に記載の情報処理装置。
18. 前記制御部は、前記ユーザの位置から前記オンデマンドバスの配車予定場所までの移動時間を取得し、取得した移動時間の情報を前記オンデマンドバスの配車予定場所の位置情報とともに、前記端末装置に前記通信部によって送信する、請求項１６又は１７に記載の情報処理装置。
19. 前記端末装置と、
    請求項１から１８までの何れか一項に記載の情報処理装置と、を含む、情報処理システム。
20. オンデマンドバスの利用予約がキャンセルされる可能性が高いと前記利用予約をしたユーザの情報に基づいて判定した場合、前記利用予約をキャンセルするか否かの問い合わせを、前記ユーザの端末装置に送信することを含む、情報処理方法。

Images