JP2022139230A - 情報処理装置 - Google Patents

Abstract

【課題】需要に見合った乗降車場所の候補を提示できる情報処理装置を提供する。【解決手段】情報処理装置（サーバ装置１８）において、取得部５０は、予め定められた複数の乗降車場所に停車可能なオンデマンド車両への過去の複数の利用者の乗車リクエストを取得する。決定部５２は、取得された複数の利用者の乗車リクエストのそれぞれに含まれる出発地と目的地にもとづいて、新設または位置変更を勧める乗降車場所の候補を決定する。提示部５４は、決定された乗降車場所の候補を提示する。【選択図】図２

Description

本発明は、オンデマンド車両サービスを管理する技術に関する。

特許文献１には、相乗り型デマンド交通車両の希望出発時刻及び希望到着時刻と出発地と目的地とを含む乗客の旅程要求を受信し、集約した旅程要求をもとにデマンド交通車両の配車計画を作成するデマンド交通運用システムが開示されている。

国際公開第２０１９／１０６７４５号

複数の仮想のバス停に停車可能なオンデマンドバスのサービスにおいて、移動需要の傾向が中長期的に変化する可能性がある。移動需要の傾向の変化に応じてバス停の位置を見直すことが望まれる。

本発明の目的は、需要に見合った乗降車場所の候補を提示できる情報処理装置を提供することにある。

上記課題を解決するために、本発明のある態様の情報処理装置は、予め定められた複数の乗降車場所に停車可能なオンデマンド車両への過去の複数の利用者の乗車リクエストを取得する取得部と、取得された複数の利用者の乗車リクエストのそれぞれに含まれる出発地と目的地にもとづいて、新設または位置変更を勧める乗降車場所の候補を決定する決定部と、決定された乗降車場所の候補を提示する提示部と、を備える。

本発明によれば、需要に見合った乗降車場所の候補を提示できる。

実施の形態の情報処理システムの構成を示す図である。 図１の情報処理システムの機能ブロックを示す図である。 図２のサーバ装置における乗降車場所の候補の提示処理を示すフローチャートである。

図１は、実施の形態の情報処理システム１の構成を示す。情報処理システム１は、予め定められたコミュニティにオンデマンド車両サービスを提供する。オンデマンド車両サービスは、オンデマンドバスサービスともよべる。このサービスでは、オンデマンド車両は、コミュニティ内外の予め定められた複数の仮想のバス停（以下、乗降車場所とよぶ）に停車可能である。コミュニティ内のサービスの利用者による乗車リクエストにもとづいて、オンデマンド車両が停車する乗降車場所、乗降車場所の出発時刻、走行経路が決定される。オンデマンド車両には複数の利用者が相乗りでき、各利用者が乗車する乗降車場所は異なってもよく、各利用者が降車する乗降車場所も異なってもよい。

情報処理システム１は、ユーザ端末装置１０、コミュニティ管理装置１２、車両端末装置１４、車両情報管理装置１６およびサーバ装置１８を備える。サーバ装置１８は、情報処理装置とも呼べる。

ユーザ端末装置１０は、たとえばスマートフォン、タブレットなどの携帯端末装置であり、コミュニティに所属するサービスの利用者に所持される。ユーザ端末装置１０は、携帯できなくてもよく、パーソナルコンピュータでもよい。車両端末装置１４は、オンデマンド車両２に搭載されてもよいし、オンデマンド車両２の運転者に所持される携帯端末装置であってもよい。

ユーザ端末装置１０と車両端末装置１４は、無線基地局や無線アクセスポイントを介して無線通信でネットワーク４に接続する。無線通信の規格は特に限定されないが、例えば、３Ｇ（第３世代移動通信システム）、４Ｇ（第４世代移動通信システム）または５Ｇ（第５世代移動通信システム）を含む。

ネットワーク４にはサーバ装置１８、コミュニティ管理装置１２、車両情報管理装置１６が接続されており、サーバ装置１８は、ユーザ端末装置１０、車両端末装置１４、コミュニティ管理装置１２、車両情報管理装置１６とネットワーク４経由で通信を行う。

コミュニティ管理装置１２は、コミュニティで管理される。車両情報管理装置１６は、オンデマンド車両２の運行業者に管理される。サーバ装置１８は、オンデマンド車両サービスのサービス事業者に管理される。運行業者は、サービス事業者であってもよい。

図１には、ユーザ端末装置１０、車両端末装置１４、オンデマンド車両２が１台ずつ示されているが、オンデマンド車両サービスは、複数の利用者と複数のオンデマンド車両２によって運用される。したがって情報処理システム１は、複数のユーザ端末装置１０、複数のオンデマンド車両２および複数の車両端末装置１４を備える。なお、コミュニティは複数であってもよく、この場合、情報処理システム１は複数のコミュニティ管理装置１２を備える。運行業者は複数であってもよく、この場合、情報処理システム１は複数の車両情報管理装置１６を備える。

図２は、図１の情報処理システム１の機能ブロックを示す。サーバ装置１８は、乗降車場所管理部３０、受付部３２、運行スケジュール決定部３４、記憶部３６、出力部３８および導出部４０を備える。

サーバ装置１８の構成は、ハードウエア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

コミュニティとサービス事業者のサービス契約時、コミュニティの担当者は、予め定められた数の希望乗降車場所をコミュニティ管理装置１２に登録する。コミュニティ管理装置１２は、登録された希望乗降車場所の情報をサーバ装置１８に送信する。

乗降車場所管理部３０は、コミュニティ管理装置１２から送信された複数の希望乗降車場所の情報にもとづいて複数の乗降車場所を決定し、決定した複数の乗降車場所を管理する。

車両情報管理装置１６は、コミュニティで利用可能なオンデマンド車両２の台数、オンデマンド車両２の乗車可能人数、営業時間などの情報を管理し、これらの情報をサーバ装置１８に送信する。

サービス利用を希望する利用者は、ユーザ端末装置１０のアプリを起動し、出発地と、目的地と、出発時刻または到着時刻とをユーザ端末装置１０に入力する。利用者は、出発地と目的地をアプリの地図上で検索して指定することができる。そのため、出発地と目的地は検索情報とも呼べる。出発地や目的地は、乗降車場所とは異なる任意の地点でもよいし、乗降車場所でもよい。出発時刻または到着時刻に替えて、出発時間帯または到着時間帯を入力してもよい。ユーザ端末装置１０は、利用者ＩＤ、コミュニティＩＤ、出発地、目的地、出発時刻または到着時刻を含む乗車リクエストをサーバ装置１８に送信する。乗車リクエストは、予約情報ともいえる。

コミュニティが会社などの組織である場合、ユーザ端末装置１０は、コミュニティ内予定表のアプリを有してもよい。利用者は、コミュニティ内予定表に出発地、目的地、出発時刻または到着時刻を登録できる。ユーザ端末装置１０は、コミュニティ内予定表に登録された情報をもとに、利用者ＩＤ、コミュニティＩＤ、出発地、目的地、出発時刻または到着時刻を含む乗車リクエストをサーバ装置１８に送信する。

受付部３２は、出発前の所定のリクエスト受付期間にユーザ端末装置１０から乗車リクエストを受け付け、受け付けた乗車リクエストを運行スケジュール決定部３４に出力する。リクエスト受付期間は、たとえば、出発の１週間前から出発の１時間前までの期間であり、実験やシミュレーションにより適宜定めることができる。

運行スケジュール決定部３４は、リクエスト受付期間が経過した場合、リクエスト受付期間に受け付けられた複数の利用者の乗車リクエストと、乗降車場所管理部３０から取得した複数の乗降車場所の情報と、車両情報管理装置１６から取得した情報とにもとづいて、オンデマンド車両２の運行スケジュールを決定する。

運行スケジュールは、公知の各種方法により決定でき、たとえば、出発地、目的地、出発時刻、到着時刻、オンデマンド車両２の台数などの制約条件を満たしながら、移動コストを最小化するように乗降車場所の訪問順序を最適化することで決定できる。

オンデマンド車両２の数は予め定められているため、乗車を希望する利用者の数、出発地、目的地、出発時刻、到着時刻によっては、全ての乗車リクエストを受理できない場合がある。

運行スケジュールは、配車されるそれぞれのオンデマンド車両２に関して決定され、走行経路、停車する乗降車場所、各乗降車場所への到着時刻、各乗降車場所で乗車または降車する利用者のユーザＩＤなどの情報を含む。運行スケジュール決定部３４は、運行スケジュールに車両ＩＤを添付して出力部３８に供給する。

出力部３８は、供給された運行スケジュールに添付された車両ＩＤで特定される車両端末装置１４に対して当該運行スケジュールを出力する。車両端末装置１４は、受信した運行スケジュールを表示する。オンデマンド車両２の運転者は、車両端末装置１４に表示された運行スケジュールにしたがい、オンデマンド車両２を運転する。オンデマンド車両２は自動運転車両であってもよく、その場合、オンデマンド車両２の自動運転制御装置（図示せず）は、車両端末装置１４から出力される運行スケジュールにしたがい自動運転を制御してよい。

運行スケジュール決定部３４は、決定された運行スケジュールにもとづいて、複数の乗車リクエストに含まれるユーザＩＤごとに、受理可否を示す情報、受理可能な場合の乗車予定時刻、走行経路、および、車両情報を含む予約結果を導出し、導出された予約結果にユーザＩＤを添付して出力部３８に供給する。走行経路は、乗車場所と降車場所の情報を含む。利用者が出発地や目的地として乗降車場所以外を指定した場合、出発地や目的地に最も近い乗降車場所が決定されるとは限らず、出発地や目的地に最も近い乗車場合以外の乗降車場所が決定される可能性もある。

出力部３８は、供給された予約結果に添付されたユーザＩＤで特定されるユーザ端末装置１０に対して当該予約結果を出力する。ユーザ端末装置１０は、受信した予約結果を表示する。予約結果を確認した利用者は、受理可否などを把握できる。

運行スケジュール決定部３４は、運行スケジュールを決定した場合、リクエスト受付期間の乗車リクエスト数に対する受理数の割合である乗車リクエストの受理率と、迂回時間を導出し、導出された乗車リクエストの受理率、導出された迂回時間および決定された運行スケジュールを含む運行実績の情報を記憶部３６に出力する。運行スケジュール決定部３４は、乗車リクエストの情報も記憶部３６に出力する。記憶部３６は、乗車リクエストと運行実績の情報をデータベースとして保持する。

ここで、既述のように、移動需要の傾向はたとえば数ヶ月から数年で中長期的に変化する可能性がある。この変化は、コミュニティ内のサービス利用者が入れ替わること、新たなサービス利用者が加わること、新たな施設が設けられることなどにより生じ得る。

移動需要の傾向が変化すると、殆ど利用されない乗降車場所が発生したり、乗降車場所が設定されていない地点を出発地または目的地とする多くの乗車リクエストが発生したりする可能性がある。つまり、コミュニティにより最初に設定された乗降車場所が不適切になる可能性がある。そのため、乗車リクエストの受理率が低下する可能性や、利用者が長距離を歩いて乗降車場所に移動しなければならない可能性があり、サービスの質や利便性が低下する恐れがある。

そこで実施の形態では、以下に説明するように、過去の乗車リクエストを含む本来の需要をもとに、新設、廃止または位置変更を勧める乗降車場所の候補をコミュニティと利用者に提示する。

導出部４０は、所定期間ごとに、新設、廃止または位置変更を勧める乗降車場所の候補を導出可能か判定し、可能な場合に候補を導出する。所定期間は、たとえば１日、数日、１ヶ月、数ヶ月などであってよく、実験やシミュレーションにより適宜定めることができる。導出部４０は、定期的に判定と導出を実行することに加えてまたは替えて、コミュニティまたは利用者から要求があった場合に判定と導出を実行してもよい。

導出部４０は、取得部５０および決定部５２を有する。取得部５０は、オンデマンド車両２への過去の複数の利用者の乗車リクエスト、および、オンデマンド車両２の過去の運行実績を記憶部３６から取得し、取得した情報を決定部５２に出力する。これらの乗車リクエストと運行実績は、需要量に関する情報ともいえる。

決定部５２は、取得部５０から出力された複数の利用者の乗車リクエストのそれぞれに含まれる出発地と目的地にもとづいて、新設または位置変更を勧める乗降車場所の候補を決定し、取得された運行実績にもとづいて廃止を勧める乗降車場所の候補を決定し、決定された乗降車場所の候補を出力部３８に出力する。

天候やイベント開催などの突発的な事象により、一時的に乗降車場所の利用者数が急増または急減し、短期的な需要量の変化が起こる場合がある。そこで、決定部５２は、機械学習などにより検出した短期的な需要量の変化を除くことで、中長期的な需要量の変化を抽出し、この中長期的な需要量の変化をもとに乗降車場所の候補を決定してよい。

以下に説明するように、乗降車場所の候補を決定する処理は、乗降車場所の候補を仮決定する処理と、所定の基準が満たされる場合、仮決定された乗降車場所の候補を本決定する処理を含む。決定部５２は、取得された複数の利用者の乗車リクエストのそれぞれに含まれる出発地と目的地にもとづいて、新設を勧める乗降車場所、または、位置変更を勧める乗降車場所および位置変更後の乗降車場所の候補を仮決定し、取得された運行実績にもとづいて廃止を勧める乗降車場所の候補を仮決定する。

決定部５２は、取得された複数の利用者の乗車リクエストに同等の出発地または同等の目的地が所定数以上含まれる場合、新設を勧める乗降車場所の候補を当該出発地または当該目的地に仮決定する。同等の出発地とは、緯度と経度が等しい出発地、および、緯度と経度が実質的に等しいとみなせる所定エリア内の出発地を表す。所定数と所定エリアは、実験やシミュレーションにより適宜定めることができる。これにより、新設を勧める乗降車場所の候補を本来の需要に見合った位置に決定できる。

決定部５２は、２つの新設を勧める乗降車場所の候補が仮決定された場合、これらが所定距離内にあれば、これらの乗降車場所の候補を統合し、統合により得られた乗降車場所を新設を勧める乗降車場所の候補に仮決定する。

決定部５２は、２つの新設を勧める乗降車場所の候補を、それらの乗降車場所の検索回数または運行実績で重み付けした重心に統合する。検索回数として乗車リクエスト数を利用できる。運行実績として利用者数または受理率を利用できる。所定距離は、徒歩で容易に移動可能な距離であり、実験やシミュレーションにより適宜定めることができる。これにより、乗降車場所が増えすぎないようにでき、迂回時間や停車時間の過度な増加を抑制できる。

決定部５２は、仮決定された新設を勧める乗降車場所の候補が既存の乗降車場所から所定距離内にある場合、当該既存の乗降車場所を位置変更を勧める乗降車場所の候補に仮決定し、当該新設を勧める乗降車場所の候補と当該既存の乗降車場所を統合して得られた乗降車場所を位置変更後の乗降車場所の候補に仮決定する。

決定部５２は、新設を勧める乗降車場所の候補と既存の乗降車場所を、それらの乗降車場所の検索回数または運行実績で重み付けした重心に統合する。これにより、位置変更を勧める乗降車場所と位置変更後の乗降車場所の候補を本来の需要に見合った位置に決定できる。乗降車場所が増えすぎないようにすることもできる。

決定部５２は、取得された運行実績にもとづいて、複数の乗降車場所の総利用者数に対する利用者数の割合が第１しきい値以下である乗降車場所、または、乗車リクエストの受理率が第２しきい値以下である乗降車場所を、廃止を勧める乗降車場所の候補に仮決定する。第１しきい値と第２しきい値は、実験やシミュレーションにより適宜定めることができる。これにより、廃止を勧める乗降車場所の候補を適切に決定できる。

決定部５２は、仮決定された乗降車場所の候補を既存の複数の乗降車場所に反映させた状態において、取得された一定期間の過去の乗車リクエストにもとづいて導出された指標が、取得された運行実績に含まれる指標に対して改善または維持された場合、仮決定された乗降車場所の候補を本決定する。一定期間の過去の乗車リクエストは、運行実績に含まれる指標の導出に用いられた乗車リクエストと同一である。つまり、同一の過去の乗車リクエストを用いて、仮決定された乗降車場所の候補を反映させた状態と、既存の乗降車場所のそれぞれで導出された指標を比較するともいえる。決定部５２は、本決定された乗降車場所の候補を出力部３８に出力する。決定部５２は、この指標が、取得された運行実績に含まれる指標に対して改善または維持されない場合、仮決定された乗降車場所の候補を破棄する。

具体的には、決定部５２は、仮決定された新設を勧める乗降車場所の候補を既存の複数の乗降車場所に加えた状態で、過去の乗車リクエストにもとづいて運行スケジュールを最適化し、指標として乗車リクエストの受理率と迂回時間を導出する。決定部５２は、同一の乗車リクエストにもとづいて導出された過去の運行実績に含まれる受理率と迂回時間と比較して、導出された受理率と迂回時間が改善された場合、仮決定された新設を勧める乗降車場所の候補を本決定する。

決定部５２は、仮決定された位置変更を勧める乗降車場所の候補を既存の複数の乗降車場所から除き、仮決定された位置変更後の乗降車場所の候補を残りの既存の乗降車場所に加えた状態で、過去の乗車リクエストにもとづいて運行スケジュールを最適化し、指標として乗車リクエストの受理率と迂回時間を導出する。決定部５２は、同一の乗車リクエストにもとづいて導出された過去の運行実績に含まれる受理率と迂回時間と比較して、導出された受理率と迂回時間が改善された場合、仮決定された位置変更を勧める乗降車場所の候補と位置変更後の乗降車場所の候補を本決定する。

決定部５２は、仮決定された廃止を勧める乗降車場所の候補を既存の複数の乗降車場所から除いた状態で、過去の乗車リクエストにもとづいて運行スケジュールを最適化し、指標として乗車リクエストの受理率と迂回時間を導出する。決定部５２は、同一の乗車リクエストにもとづいて導出された過去の運行実績に含まれる受理率と迂回時間と比較して、導出された受理率と迂回時間が改善された場合、仮決定された廃止を勧める乗降車場所の候補を本決定する。
これにより、サービスの質を向上しうる新設、廃止または位置変更を勧める乗降車場所の候補を決定できる。

出力部３８は、決定部５２から出力された乗降車場所の候補の情報をユーザ端末装置１０とコミュニティ管理装置１２に出力する。具体的には提示部５４は、乗降車場所の候補の情報を、ユーザ端末装置１０を介して利用者に提示し、コミュニティ管理装置１２を介してコミュニティの担当者に提示する。ユーザ端末装置１０とコミュニティ管理装置１２は、それぞれ、受信した乗降車場所の候補を表示する。乗降車場所の候補を確認した利用者は、ユーザ端末装置１０に対して賛成または反対の投票を入力でき、レビューも入力できる。ユーザ端末装置１０は、入力された投票とレビューの情報をコミュニティ管理装置１２に送信する。

コミュニティ管理装置１２は、複数のユーザ端末装置１０から送信された投票の情報を集計し、集計結果を表示する。コミュニティ管理装置１２は、重要な利用者のユーザ端末装置１０から送信された投票の情報に対して、重み付けしてもよい。重要な利用者は、たとえば、システムの利用料金を他の利用者より多く支払っている利用者である。

コミュニティ管理装置１２は、ユーザ端末装置１０から送信されたレビューの情報を複数のユーザ端末装置１０に表示させる。利用者は、他の利用者のレビューも参考にして投票できる。

決定部５２は、決定された乗降車場所の新設、廃止または位置変更による受理率と迂回時間のそれぞれの改善率を導出し、決定された乗降車場所の廃止により削減できる費用を導出し、導出した情報を提示部５４に出力してもよい。提示部５４は、新設、廃止または位置変更を勧める乗降車場所の候補とともに、新設、廃止または位置変更による受理率と迂回時間のそれぞれの改善率を、コミュニティ管理装置１２を介してコミュニティの担当者に提示してもよい。提示部５４は、廃止を勧める乗降車場所の候補とともに、廃止により削減できる費用を、コミュニティ管理装置１２を介してコミュニティの担当者に提示してもよい。

コミュニティの担当者は、これらの情報と、利用者による投票の集計結果にもとづいて、提示された乗降車場所の候補を受け入れるか否か決定し、決定した情報をコミュニティ管理装置１２に入力する。コミュニティ管理装置１２は、乗降車場所の候補を受け入れるか否かの情報をサーバ装置１８に送信する。

サーバ装置１８の乗降車場所管理部３０は、コミュニティ管理装置１２から乗降車場所の候補を受け入れることを示す情報を受信した場合、乗降車場所の候補の情報にもとづいて、管理している乗降車場所の情報を更新する。具体的には、乗降車場所管理部３０は、既存の複数の乗降車場所に対して新設を勧める乗降車場所を追加し、既存の複数の乗降車場所から廃止を勧める乗降車場所を削除し、既存の複数の乗降車場所から位置変更を勧める乗降車場所を削除して位置変更後の乗降車場所を追加する。これにより、次回からの運行スケジュールの決定は、更新された乗降車場所にもとづいて実行される。

このように、移動需要に見合った適切な新設、廃止または位置変更を勧める乗降車場所の候補を利用者とコミュニティに提示できる。そのため、乗降車場所の候補が乗降車場所として採用されることで、移動需要の変化に伴う受理率の低下やサービスの質の低下を抑制できる。

図３は、図２のサーバ装置１８における乗降車場所の候補の提示処理を示すフローチャートである。図３の処理は、所定期間ごとに定期的に実行されてもよいし、コミュニティや利用者から要求があった場合に実行されてもよい。

取得部５０は、過去の複数の利用者の乗車リクエストと、運行実績を取得し（Ｓ１０）、複数の乗車リクエストに含まれる同等の出発地または目的地が所定数以上でなければ（Ｓ１２のＮ）、Ｓ２８に移る。複数の乗車リクエストに含まれる同等の出発地または目的地が所定数以上であれば（Ｓ１２のＹ）、決定部５２は、新設を勧める乗降車場所の候補を当該出発地または当該目的地に仮決定する（Ｓ１４）。

仮決定された新設を勧める乗降車場所の候補が既存の乗降車場所から所定距離内にない場合（Ｓ１６のＮ）、受理率と迂回時間が改善されれば（Ｓ１８のＹ）、決定部５２は、新設を勧める乗降車場所の候補を本決定し、提示部５４は、その候補を提示する（Ｓ２０）。受理率と迂回時間が改善されなければ（Ｓ１８のＮ）、Ｓ２８に移る。

仮決定された新設を勧める乗降車場所の候補が既存の乗降車場所から所定距離内にある場合（Ｓ１６のＹ）、決定部５２は、位置変更を勧める乗降車場所の候補と、位置変更後の乗降車場所の候補を仮決定する（Ｓ２２）。受理率と迂回時間が改善されれば（Ｓ２４のＹ）、決定部５２は、位置変更を勧める乗降車場所の候補と、位置変更後の乗降車場所の候補を本決定し、提示部５４は、それらの候補を提示する（Ｓ２６）。受理率と迂回時間が改善されなければ（Ｓ２４のＮ）、Ｓ２８に移る。

利用者数の割合が第１しきい値以下、または、受理率が第２しきい値以下である乗降車場所がない場合（Ｓ２８のＮ）、処理を終了する。利用者数の割合が第１しきい値以下、または、受理率が第２しきい値以下である乗降車場所がある場合（Ｓ２８のＹ）、廃止を勧める乗降車場所の候補をこの乗降車場所に仮決定する（Ｓ３０）。受理率と迂回時間が改善されれば（Ｓ３２のＹ）、決定部５２は、廃止を勧める乗降車場所の候補を本決定し、提示部５４は、その候補を提示し（Ｓ３４）、処理を終了する。受理率と迂回時間が改善されなければ（Ｓ３２のＮ）、処理を終了する。

以上、実施の形態をもとに本発明を説明した。実施の形態はあくまでも例示であり、各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

たとえば、決定部５２は、仮決定する処理と、指標が改善する場合に本決定する処理を実行せず、指標が改善するか否かとは無関係に乗降車場所の候補を決定してもよい。この場合も、コミュニティ管理装置１２は、乗降車場所の候補とともに、新設、廃止または位置変更による受理率と迂回時間のそれぞれの改善率を表示してもよく、廃止を勧める乗降車場所の候補とともに、廃止により削減できる費用を表示してもよい。この変形例では、受理率や迂回時間が多少悪化しても許容できる場合にも、乗降車場所を新設、位置変更または廃止できる。

また、ユーザ端末装置１０は、廃止を勧める乗降車場所の候補を表示する場合、投票を受け付けず、「ａ月ｂ日までにバス停Ａをあとｘ人利用すれば廃止しません」などの廃止の撤回条件を含むメッセージを表示してもよい。廃止の撤回条件は、決定部５２が決定する。乗降車場所管理部３０は、撤回条件が満たされれば、廃止を勧める乗降車場所の候補を削除せず、撤回条件が満たされなければ、この乗降車場所の候補を削除する。

また、提示部５４は、需要量に関する情報のみをコミュニティ管理装置１２を介してコミュニティの担当者に提示し、乗降車場所の候補を提示しなくてもよい。提示される需要量に関する情報は、乗降車場所の利用率または検索回数、出発地と目的地の検索回数、コミュニティ内予定表に所定回数以上登録された出発地と目的地の少なくともいずれかを含む。提示される需要量に関する情報は、これらのランキングを含んでもよい。コミュニティの担当者は、これらの情報をもとに、新設、位置変更または廃止する乗降車場所をコミュニティ管理装置１２に登録してもよい。

さらに、決定部５２は、乗車リクエストとは無関係に、新設を勧める乗降車場所の候補をランダムに選択したランドマークに決定してもよい。

また、新規コミュニティがサービスに参加した場合などに、オンデマンド車両２の台数が不足し、乗降車場所を新設、廃止または位置変更しても受理率が向上しない可能性がある。そこで、導出部４０は、サービスの質を維持するために必要なオンデマンド車両２の台数を導出してもよい。出力部３８は、導出された台数を車両情報管理装置１６に出力してもよい。この場合、オンデマンド車両２の追加を運行業者に勧めることができる。

本発明の一態様は、次の通りである。
［項目１］
予め定められた複数の乗降車場所に停車可能なオンデマンド車両への過去の複数の利用者の乗車リクエストを取得する取得部と、
取得された複数の利用者の乗車リクエストのそれぞれに含まれる出発地と目的地にもとづいて、新設または位置変更を勧める乗降車場所の候補を決定する決定部と、
決定された乗降車場所の候補を提示する提示部と、
を備えることを特徴とする情報処理装置。
［項目２］
前記取得部は、オンデマンド車両の運行実績を取得し、
前記決定部は、取得された運行実績にもとづいて廃止を勧める乗降車場所の候補を決定する、
ことを特徴とする項目１に記載の情報処理装置。
［項目３］
前記決定部は、
取得された複数の利用者の乗車リクエストのそれぞれに含まれる出発地と目的地にもとづいて、新設を勧める乗降車場所、または、位置変更を勧める乗降車場所および位置変更後の乗降車場所の候補を仮決定し、取得された運行実績にもとづいて廃止を勧める乗降車場所の候補を仮決定し、
仮決定された乗降車場所の候補を前記複数の乗降車場所に反映させた状態において、取得された乗車リクエストにもとづいて導出された指標が、取得された運行実績に含まれる指標に対して改善された場合、仮決定された乗降車場所の候補を本決定する、
ことを特徴とする項目２に記載の情報処理装置。
［項目４］
前記決定部は、取得された複数の利用者の乗車リクエストに同等の出発地または同等の目的地が所定数以上含まれる場合、新設を勧める乗降車場所の候補を当該出発地または当該目的地に仮決定する、
ことを特徴とする項目３に記載の情報処理装置。
［項目５］
前記決定部は、仮決定された新設を勧める乗降車場所の候補が既存の乗降車場所から所定距離内にある場合、当該既存の乗降車場所を位置変更を勧める乗降車場所の候補に仮決定し、当該新設を勧める乗降車場所の候補と当該既存の乗降車場所を統合して得られた乗降車場所を位置変更後の乗降車場所の候補に仮決定する、
ことを特徴とする項目３または４に記載の情報処理装置。
［項目６］
前記決定部は、取得された運行実績にもとづいて、総利用者数に対する利用者数の割合が第１しきい値以下である乗降車場所、または、乗車リクエストの受理率が第２しきい値以下である乗降車場所を、廃止を勧める乗降車場所の候補に仮決定する、
ことを特徴とする項目３から５のいずれかに記載の情報処理装置。

１…情報処理システム、２…オンデマンド車両、１０…ユーザ端末装置、１２…コミュニティ管理装置、１４…車両端末装置、１６…車両情報管理装置、１８…サーバ装置、３０…乗降車場所管理部、３２…受付部、３４…運行スケジュール決定部、３６…記憶部、３８…出力部、４０…導出部、５０…取得部、５２…決定部、５４…提示部。

Claims (1)

1. 予め定められた複数の乗降車場所に停車可能なオンデマンド車両への過去の複数の利用者の乗車リクエストを取得する取得部と、
   取得された複数の利用者の乗車リクエストのそれぞれに含まれる出発地と目的地にもとづいて、新設または位置変更を勧める乗降車場所の候補を決定する決定部と、
   決定された乗降車場所の候補を提示する提示部と、
   を備えることを特徴とする情報処理装置。

Images