特開 2024-111987 情報処理装置および情報処理方法

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024111987

(43)【公開日】2024-08-20

(54)【発明の名称】情報処理装置および情報処理方法

(51)【国際特許分類】

   G06Q 50/40 20240101AFI20240813BHJP

【ＦＩ】

G06Q50/30

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2023016775

(22)【出願日】2023-02-07

(71)【出願人】

【識別番号】000237592

【氏名又は名称】株式会社デンソーテン

(74)【代理人】

【識別番号】110001933

【氏名又は名称】弁理士法人 佐野特許事務所

(72)【発明者】

【氏名】三浦 寿

(72)【発明者】

【氏名】藤井 亮太

【テーマコード（参考）】

5L049

5L050

【Ｆターム（参考）】

5L049CC42

5L050CC42

(57)【要約】

【課題】タクシー車両とデマンド交通車両とに兼用される車両を、デマンド運行を行う車両に適切に割り当てることができる技術を提供する。
【解決手段】例示的な情報処理装置は、コントローラを備える情報処理装置であって、前記コントローラは、タクシー車両とデマンド交通車両とに兼用される車両に配置される車両用装置にデマンド運行情報を提示し、デマンド運行を行うドライバーの募集を行う。
【選択図】図３

【特許請求の範囲】

【請求項1】

コントローラを備える情報処理装置であって、
前記コントローラは、タクシー車両とデマンド交通車両とに兼用される車両に配置される車両用装置にデマンド運行情報を提示し、デマンド運行を行うドライバーの募集を行う、情報処理装置。

【請求項2】

前記デマンド運行情報は、運行に関わる時間情報、および、乗客の乗降場所情報を含む前記デマンド運行の運行計画である、請求項１に記載の情報処理装置。

【請求項3】

前記コントローラは、前記デマンド運行情報を提示する提示態様を、前記車両ごとに変更する、請求項１又は２に記載の情報処理装置。

【請求項4】

前記コントローラは、前記車両の位置情報と、前記車両のドライバーに関する情報との少なくとも一方に基づき前記提示態様の変更を行う、請求項３に記載の情報処理装置。

【請求項5】

前記提示態様の変更は、複数の前記デマンド運行情報を提示する順番の変更、或いは、前記デマンド運行情報を提示する数の変更である、請求項３に記載の情報処理装置。

【請求項6】

前記コントローラは、前記募集に対する応募に応じて前記デマンド運行を行うドライバーを決定する、請求項１又は２に記載の情報処理装置。

【請求項7】

前記コントローラは、前記デマンド運行を行うことに決定したドライバーからのキャンセル通知を受け付ける、請求項６に記載の情報処理装置。

【請求項8】

前記コントローラは、前記募集に対する応募が無かった場合に、前記デマンド運行を行うドライバーの決定を他の装置に依頼する、請求項１又は２に記載の情報処理装置。

【請求項9】

前記タクシー車両と前記デマンド交通車両とに兼用される車両は、一台で前記デマンド運行の他にタクシー運行が可能な車両である、請求項１に記載の情報処理装置。

【請求項10】

タクシー車両とデマンド交通車両とに兼用される車両に配置される車両用装置にデマンド運行情報を提示し、デマンド運行を行うドライバーの募集を行う処理を、情報処理装置が実行する情報処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、デマンド交通サービスにおける配車技術に関する。

【背景技術】

【0002】

従来、ユーザからの利用要求に応じてバスの運行計画を生成するデマンド型の運行管理システムが知られる（例えば特許文献１参照）。特許文献１においては、ユーザからのバスの利用要求に応じて、バスの運行経路、運行時刻等を動的に変更した運行計画を生成することが開示される。デマンド交通車両は、生成された運行計画にしたがってデマンド運行を行う。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】国際公開第２０２０／２６２６７３号

【発明の概要】

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

【0004】

タクシー車両が、デマンド交通車両としても活用されることがある。この場合、デマンド運行の運行計画を与えられたドライバーは、タクシー車両をデマンド交通車両に変更してデマンド運行を行う。タクシー車両からデマンド交通車両に切り替えられる場合、デマンド交通車両として業務を行うための準備期間が必要となる。準備期間には、例えば、業務形態の変更に伴う車両の外観変更を行う作業時間や、デマンド運行の出発地へ移動するための移動時間等が含まれる。

【0005】

上術の準備期間や、デマンド運行可能なドライバー（車両も含む）を確実に確保することを考慮すると、デマンド運行の開始時刻に対して余裕をもって（例えば１時間前等）ドライバーの確保を行っておく必要がある。単純にデマンド運行を行うドライバーの確保を早く行う構成とすると、タクシーとして業務を行う機会の損失が大きくなることが懸念される。

【0006】

また、タクシーの利用頻度が上昇する時間帯等においては、デマンド運行可能なタクシー車両を簡単に確保できないという事態が生じ得る。このような場合、オペレータが電話をかける等、手動でデマンド運行可能なタクシー車両を探す必要が生じ、オペレータの負担が大きくなることが懸念される。

【0007】

本発明は、上述の点に鑑み、タクシー車両とデマンド交通車両とに兼用される車両を、デマンド運行を行う車両に適切に割り当てることができる技術を提供することを目的とする。

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

【0008】

例示的な本発明の情報処理装置は、コントローラを備える情報処理装置であって、前記コントローラは、タクシー車両とデマンド交通車両とに兼用される車両に配置される車両用装置にデマンド運行情報を提示し、デマンド運行を行うドライバーの募集を行う。

【発明の効果】

【0009】

例示的な本発明によれば、タクシー車両とデマンド交通車両とに兼用される車両を、デマンド運行を行う車両に適切に割り当てることができる。

【図面の簡単な説明】

【0010】

【図1】デマンド運行管理システムの概略の構成を示すブロック図

【図2】デマンド運行管理装置の構成を示すブロック図

【図3】ドライバー募集装置の構成を示すブロック図

【図4A】車両用装置の表示画面に表示されるデマンド運行情報の具体例を示す図

【図4B】車両用装置の表示画面に表示されるデマンド運行情報の具体例を示す図

【図5】車両情報テーブルの一例を示す図

【図6】デマンド選択車両の確保方法の流れを例示するフローチャート

【図7】変形例に係るデマンド運行システムの概略の構成を示すブロック図

【図8】変形例に係るデマンド選択車両の確保方法の流れを例示するフローチャート

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

【0011】

以下、本発明の例示的な実施形態について、図面を参照しながら詳細に説明する。

【0012】

＜１．デマンド運行システム＞
図１は、本発明の実施形態に係るデマンド運行システム１００の概略の構成を示すブロック図である。デマンド運行システム１００は、運行経路や運行スケジュールをユーザの予約に応じる形で運行する地域公共交通であるデマンド型交通を実現するシステムである。

【0013】

なお、本実施形態においては、デマンド運行を行う車両には、タクシー車両とデマンド交通車両とに兼用される車両が含まれる。タクシー車両とデマンド交通車両とに兼用される車両は、一台でタクシー運行およびデマンド運行の両方を行うことが可能な車両である。タクシー車両とデマンド交通車両とに兼用される車両は、例えば、ミニバン、ワンボックスカー、セダン、バス車両、福祉車両等であってよい。福祉車両は、例えば、車椅子に乗る乗客を、そのまま載せることができる車両である。

【0014】

また、車両がタクシー車両として利用される（タクシー運行を行う）場合、当該車両は、ユーザ（乗客）からの乗車申し込みに応じて、個別契約でユーザの輸送を行う。タクシー車両は、場所を移動させながら、ユーザを随時乗せることができる。また、タクシー車両は、ユーザからの予約を随時受け付けることができる。デマンド交通車両は、デマンド型交通に利用される車両である。例えば、デマンド交通車両は、ユーザからの予約に応じて、予め決められた経路を順に運行する。また、例えば、デマンド交通車両は、ユーザからの予約状況に応じた自由な経路の設計が可能に設けられ、予約があった停車場（バス停等）のみを最短経路で運行する。

【0015】

図１に示すように、デマンド運行システム１００は、デマンド運行管理装置１と、ドライバー募集装置２と、車両用装置３と、予約端末装置４とを備える。

【0016】

デマンド運行管理装置１は、デマンド運行に関する管理を行う。当該管理には、乗車予約の管理、デマンド運行の運行計画の管理、および、デマンド運行を行う車両の管理等が含まれる。デマンド運行管理装置１は、インターネット等で構成される通信ネットワーク５に有線又は無線により接続される。

【0017】

ドライバー募集装置２は、デマンド運行を行うドライバーを募集する。詳細には、ドライバーは、タクシー車両とデマンド交通車両とに兼用される車両のドライバーである。すなわち、ドライバー募集装置２は、タクシー車両とデマンド交通車両とに兼用される車両を運転するドライバーを対象として、デマンド運行業務を行うドライバーを募集する。なお、ドライバーの募集には、ドライバーが運転する車両の募集も含まれる趣旨である。

【0018】

ドライバー募集装置２は、通信ネットワーク５に有線又は無線により接続される。ドライバー募集装置２は、デマンド運行管理装置１と通信可能に設けられる。ドライバー募集装置２は、通信ネットワーク５を介してデマンド運行管理装置１と通信する構成であってよい。また、ドライバー募集装置２は、デマンド運行管理装置１と有線又は無線によって接続されることで、デマンド運行管理装置１と通信する構成であってもよい。

【0019】

車両用装置３は、タクシー車両とデマンド交通車両とに兼用される車両に配置される。車両用装置３は、車両に常時搭載される車載装置であっても、車両から持ち運ぶことができる可搬型の装置であってもよい。可搬型の装置は、例えばタブレット端末やスマートフォン等であってよい。車両用装置３は、画像を表示する表示装置を含んで構成される。また、車両用装置３は、タッチパネル等の入力装置を備える。車両用装置３は、無線を利用して通信ネットワーク５と接続可能に設けられる。車両用装置３は、通信ネットワーク５を介して、デマンド運行管理装置１およびドライバー募集装置２と通信可能に設けられる。

【0020】

なお、図１においては、通信ネットワーク５に接続される車両用装置３が１つしか示されていないが、実際には、通信ネットワーク５に接続される車両用装置３の数は複数である。

【0021】

予約端末装置４は、ユーザがデマンド運行を行う車両を予約するための端末装置である。予約端末装置４は、有線又は無線により通信ネットワーク５と接続される。予約端末装置４は、通信ネットワーク５を介してデマンド運行管理装置１と通信可能に設けられる。予約端末装置４は、例えば、パーソナルコンピュータ、共用コンピュータ、スマートフォン、又は、タブレット端末等であってよい。

【0022】

なお、図１においては、通信ネットワーク５に接続される予約端末装置４が１つしか示されていないが、通信ネットワーク５に接続される予約端末装置４の数は複数であってよい。

【0023】

また、本実施形態では、ユーザは、ウェブ予約を利用してデマンド運行サービスを受けられる構成となっている。ただし、ユーザは、ウェブ予約に代えて、或いは、ウェブ予約に加えて、電話予約を利用してデマンド運行サービスを受けられる構成としてもよい。すなわち、デマンド運行システム１００は、ウェブ予約用の予約端末装置４を必ずしも備えなくてよい。電話予約が利用される場合、オペレータが、デマンド運行管理装置１に予約情報を入力する構成としてよい。

【0024】

また、本実施形態では、デマンド運行管理装置１とドライバー募集装置２とを別々の装置としているが、両者は１つの装置で構成されてよい。すなわち、デマンド運行管理装置１にドライバー募集装置２が含まれてよい。両者を１つとした装置は、いわゆるサーバであってよい。

【0025】

＜２．デマンド運行管理装置＞
図２は、本発明の実施形態に係るデマンド運行管理装置１の構成を示すブロック図である。図２においては、実施形態の特徴を説明するために必要な構成要素が示されており、一般的な構成要素の記載は省略されている。デマンド運行管理装置１はサーバである。デマンド運行管理装置１は、物理サーバであってもクラウドサーバであってもよい。デマンド運行管理装置１は、例えば、タクシー会社等の民間会社が有する装置や、地方自治体が有する装置であってよい。

【0026】

図２に示すように、デマンド運行管理装置１は、コントローラ１１と、メモリ部１２と、通信部１３とを備える。デマンド運行管理装置１は、いわゆるコンピュータ装置であってよい。なお、デマンド運行管理装置１は、キーボード等の入力装置や、ディスプレイ等の出力装置を備える構成であってもよい。

【0027】

コントローラ１１は、演算処理等を行うプロセッサを含む。プロセッサは、例えばＣＰＵ（Central Processing Unit）を含んで構成されてよい。コントローラ１１は、１つのプロセッサで構成されてもよいし、複数のプロセッサで構成されてもよい。複数のプロセッサで構成される場合には、それらのプロセッサは互いに通信可能に接続されればよい。なお、デマンド運行管理装置１がクラウドサーバで構成される場合、プロセッサを構成するＣＰＵは仮想ＣＰＵであってよい。

【0028】

メモリ部１２は、揮発性メモリおよび不揮発性メモリを含んで構成される。揮発性メモリには、例えばＲＡＭ（Random Access Memory）が含まれてよい。不揮発性メモリには、例えば、ＲＯＭ（Read Only Memory）、フラッシュメモリ、又は、ハードディスドライブが含まれてよい。不揮発性メモリには、コンピュータにより読み取り可能なプログラムおよびデータが格納される。

【0029】

通信部１３は、通信ネットワーク５（図１参照）に接続するためのインターフェース回路を有する通信インターフェースとして構成される。

【0030】

図２に示すように、コントローラ１１は、その機能として、予約受付部１１１と、運行計画管理部１１２と、配車管理部１１３とを備える。本実施形態においては、コントローラ１１の機能は、メモリ部１２に記憶されるプログラムにしたがった演算処理をプロセッサが実行することによって実現される。

【0031】

なお、本実施形態の範囲には、デマンド運行管理装置１の少なくとも一部の機能をプロセッサ（コンピュータ）に実現させるコンピュータプログラムが含まれてよい。また、本実施形態の範囲には、そのようなコンピュータプログラムを記録するコンピュータ読取り可能な不揮発性記録媒体が含まれてよい。不揮発性記録媒体は、例えば、上述の不揮発性メモリの他、光記録媒体（例えば光ディスク）、光磁気記録媒体（例えば光磁気ディスク）、ＵＳＢメモリ、或いは、ＳＤカード等であってよい。

【0032】

また、各機能部１１１～１１３は、１つのプログラムにより実現されてもよいが、例えば、機能部ごとに別々のプログラムにより実現される構成であってもよい。また、各機能部１１１～１１３が別々のサーバとして実現されてもよい。また、各機能部１１１～１１３は、上述のように、プロセッサにプログラムを実行させること、すなわちソフトウェアにより実現されてよいが、他の手法により実現されてもよい。各機能部１１１～１１３は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等を用いて実現されてもよい。すなわち、各機能部１１１～１１３は、専用のＩＣ等を用いてハードウェアにより実現されてもよい。また、各機能部１１１～１１３は、ソフトウェアおよびハードウェアを併用して実現されてもよい。また、各機能部１１１～１１３は、概念的な構成要素である。１つの構成要素が実行する機能が、複数の構成要素に分散されてよい。また、複数の構成要素が有する機能が１つの構成要素に統合されてもよい。

【0033】

予約受付部１１１は、デマンド運行管理装置１の外部から、デマンド運行サービスの利用を希望するユーザの乗車予約情報を取得する。乗車予約情報には、例えば、乗車を希望する日時、乗車地、および、降車地等が含まれる。乗車地や降車地は、例えば、既存のバス停等であってよいが、その他の場所でもよい。予約受付部１１１は、例えば、予約端末装置４から通信ネットワーク５および通信部１３を介して乗車予約情報を取得する。ユーザが電話を用いて乗車予約を行う場合には、予約受付部１１１は、例えば、オペレータが入力装置を用いて入力した乗車予約情報を取得する。

【0034】

運行計画管理部１１２は、取得した乗車予約情報に応じて運行計画を管理する。運行計画管理部１１２は、例えば、乗車予約情報に応じて既存の運行計画を更新する。また、運行計画管理部１１２は、乗車予約情報に応じて新たな運行計画を生成する。なお、運行計画には、例えば、デマンド運行の出発地および終着地、出発地から終着地までの経路、ユーザの乗車地および降車地、乗降地への予定到着時刻等が含まれる。運行計画管理部１１２が管理する運行計画は、単数でも複数でもよい。

【0035】

配車管理部１１３は、運行計画にしたがってデマンド運行を行うドライバーおよび車両の管理を行う。また、配車管理部１１３は、デマンド運行を行うことが決まった各車両に、車両用装置３を利用してデマンド運行に必要な運行計画を配信する。これにより、デマンド運行を行うことが決まっている車両のドライバーは、運行計画にしたがってデマンド運行を行うことができる。

【0036】

＜３．ドライバー募集装置＞
図３は、本発明の実施形態に係るドライバー募集装置２の構成を示すブロック図である。図３においては、実施形態の特徴を説明するために必要な構成要素が示されており、一般的な構成要素の記載は省略されている。ドライバー募集装置２の説明に際して、上述のデマンド運行管理装置１の説明と重複する内容については、その説明を適宜省略する。

【0037】

ドライバー募集装置２はサーバである。ドライバー募集装置２は、デマンド運行管理装置１と同様に、例えば、タクシー会社等の民間会社が有する装置や、地方自治体が有する装置であってよい。ドライバー募集装置２は、本発明の情報処理装置の一例である。上述のように、ドライバー募集装置２は、デマンド運行管理装置１に含まれてよい。このような構成の場合には、デマンド運行管理装置とドライバー募集装置とが一纏めとされた装置が本発明の情報処理装置であってよい。情報処理装置は、デマンド運行管理装置の機能と、ドライバー募集装置の機能とを備えた１つのサーバであってよい。

【0038】

前述のように、ドライバー募集装置２は、本発明の情報処理装置の一例である。また、図３に示すように、ドライバー募集装置２は、コントローラ２１と、メモリ部２２と、通信部２３とを備える。すなわち、情報処理装置２はコントローラ２１を備える。ドライバー募集装置２はコンピュータ装置であってよい。

【0039】

コントローラ２１は、演算処理等を行うプロセッサを含む。プロセッサは、例えばＣＰＵを含んで構成されてよい。メモリ部２２は、揮発性メモリおよび不揮発性メモリを含んで構成される。不揮発性メモリには、コンピュータにより読み取り可能なプログラムおよびデータが格納される。通信部２３は、通信ネットワーク５（図１参照）に接続するためのインターフェース回路を有する通信インターフェースとして構成される。

【0040】

図３に示すように、コントローラ２１は、その機能として、運行計画監視部２１１と、募集処理部２１２と、応募処理部２１３とを備える。本実施形態においては、コントローラ２１の機能は、メモリ部２２に記憶されるプログラムにしたがった演算処理をプロセッサが実行することによって実現される。

【0041】

なお、本実施形態の範囲には、ドライバー募集装置２の少なくとも一部の機能をプロセッサ（コンピュータ）に実現させるコンピュータプログラムが含まれてよい。また、本実施形態の範囲には、そのようなコンピュータプログラムを記録するコンピュータ読取り可能な不揮発性記録媒体が含まれてよい。

【0042】

また、各機能部２１１～２１３は、１つのプログラムにより実現されてもよいが、機能部ごとに別々のプログラムにより実現される構成等であってもよい。また、各機能部２１１～２１３は、別々のサーバとして実現されてもよい。また、各機能部２１１～２１３は、ソフトウェアにより実現されてよいが、他の手法により実現されてもよい。各機能部２１１～１１３は、ハードウェアにより実現されても、ソフトウェアおよびハードウェアを併用して実現されてもよい。また、各機能部２１１～２１３は、概念的な構成要素であり、複数の構成要素に分散されても、他の構成要素と統合されてもよい。

【0043】

運行計画監視部２１１は、デマンド運行管理装置１により管理される運行計画を監視する。詳細には、運行計画監視部２１１は、運行計画情報の更新状況を監視する。運行計画監視部２１１は、デマンド運行管理装置１から運行計画情報を定期的に取得し、運行計画情報の更新を行う。運行計画監視部２１１は、最新の運行計画を把握する。

【0044】

募集処理部２１２は、車両用装置３にデマンド運行情報を提示し、デマンド運行を行うドライバーの募集を行う。すなわち、コントローラ２１は、車両用装置３にデマンド運行情報を提示し、デマンド運行を行うドライバーの募集を行う。このような構成とすると、デマンド運行を行うドライバーおよび車両を、デマンド運行に対する配車を行う配車センターに用いることなく決定することができる。すなわち、本実施形態によれば、配車時間および配車工数の削減を図れる。また、本実施形態によれば、配車を行うオペレータの負担を抑制することができる。また、このような構成とすると、ドライバーは、自身のタクシー業務の都合を考慮しつつ、デマンド運行業務を引き受けることができる。例えば、タクシー業務を実行中のドライバーは、乗客の送り先や送り先への到着時間等を考慮して、デマンド運行業務を引き受けるか否かを判断することができる。このために、タクシー業務の機会を無駄に損失する可能性を低減しつつデマンド運行業務を行うことができ、売り上げの向上に寄与することができる。また、このような構成とすると、ドライバーは、自身の得意な地域で運行されるデマンド運行を選択して、デマンド運行業務を行うことができる。この場合、交通事情を十分に把握している者がデマンド運行を行うことになるために、デマンド運行の安全性の向上が期待できる。

【0045】

本実施形態では、募集処理部２１２は、車両用装置３を利用したドライバーからの要求により、デマンド運行情報を車両用装置３に提示する。ただし、デマンド運行情報は、ドライバー募集装置２と通信ネットワーク５によって繋がる各車両用装置３（各車両）へ、定期的に提示されてもよい。デマンド運行情報の提示は、詳細には、車両用装置３の表示画面にデマンド運行情報を表示させるために、デマンド運行情報を車両用装置３に配信することである。

【0046】

車両用装置３には、ドライバー募集装置２から配信されるデマンド運行情報を表示画面に表示するためのアプリケーションソフトウェア（以下、アプリとする）がインストールされている。車両用装置３が備えるプロセッサがアプリにしたがった演算処理を実行することにより、デマンド運行情報が表示画面に表示される。ドライバーは、表示画面に表示されるデマンド運行情報により、ドライバーを募集中の運行計画を把握することができる。そして、デマンド運行情報を見たドライバーは、車両用装置３を用いて募集に対する応募を行うことができる。

【0047】

詳細には、デマンド運行情報は、運行に関わる時間情報、および、乗客の乗降場所情報を含むデマンド運行の運行計画である。時間情報および場所情報が含まれているために、ドライバーは、タクシー業務の今後の予定や、自身の現在位置を考慮して、デマンド運行業務に応募するか否かを適切に判断することができる。なお、デマンド運行情報は、１つの運行計画のみで構成されてもよいが、複数の運行計画で構成されてもよい。

【0048】

図４Ａおよび図４Ｂは、車両用装置３の表示画面３ａに表示されるデマンド運行情報の具体例を示す図である。図４Ａは、ドライバーの募集が行われている運行計画の一覧を表示する画面の一例を示す図である。図４Ｂは、図４Ａに示される運行計画の一覧から１つの運行計画を選択した場合に表示される画面の一例を示す図である。

【0049】

図４Ａに示す画面には、運行計画一覧３１と、現在時刻３２と、更新ボタン３３と、スクロール部３４とが表示される。運行計画一覧３１は、ドライバーの募集が行われている運行計画の一覧を示す。図４に示す例では、運行計画一覧３１には、デマンド運行が行われる路線の路線名、デマンド運行の開始時刻、デマンド運行の出発地、および、デマンド運行の終了予定時刻が表示される。また、運行計画一覧３１には、デマンド運行情報が配信された車両の現在位置からデマンド運行の出発地までの到着予想時間が表示される。到着予想時間が表示されることで、ドライバーが募集に応募するか否かの判断をし易くすることができる。

【0050】

更新ボタン３３は、ドライバーを募集中の運行計画を最新情報に更新するためのボタンである。ドライバーが更新ボタン３３を操作（例えばタッチ操作）することにより、ドライバー募集装置２から最新情報が配信される。スクロール部３４は、表示画面３ａ上において、運行計画一覧３１の表示内容を上下に動かしながら表示させるための操作領域である。スクロール部３４は、ドライバーを募集中の運行計画が多く、表示画面３ａに一度に全ての運行計画を表示できない場合があることを想定して設けられる。スクロール部３４は、例えばタッチ操作により操作可能に設けられる。

【0051】

ドライバーが運行計画一覧３１における或る路線の表示領域にタッチすると、タッチされた路線の詳細な運行計画が表示画面３ａに表示される。図４Ａに示す例において、或る路線の表示領域とは、路線名、運行開始時刻、出発地、終了予定時刻、および、到着予想時間を表示する各領域を全て含む左右方向に延びる帯状領域である。図４Ｂに示す画面は、図４に示す運行計画一覧３１におけるＢ路線の表示領域がタッチされた場合の画面である。

【0052】

なお、図４Ａに示す例では、運行計画一覧３１において、募集に対する応募があってドライバーが決定した運行計画が、グレーアウトで表示されている。詳細には、路線Ａの運行計画がグレーアウトで表示されている。グレーアウトで表示される路線は、選択することができない。すなわち、グレーアウトで表示される路線の表示領域をタッチしても、詳細な運行計画を表示する画面には移行しない。本例では、募集によってドライバーが決定した運行計画をグレーアウトで表示する構成としているが、これは例示である。募集によってドライバーが決定した運行計画は、運行計画一覧３１に表示されない構成としてもよい。

【0053】

図４Ｂに示す画面には、図４Ａに示す画面と同様に、現在時刻３２、更新ボタン３３、および、スクロール部３４が表示される。また、運行計画一覧３１に替えて、選択した路線の運行計画の詳細な内容を示す計画詳細３５が表示される。計画詳細３５には、図４Ａの画面で表示される情報に加えて、乗降場所、乗降人数、および、乗降場所への到着予想時間等が表示される。また、図４Ｂに示す画面には、申込ボタン３６および戻るボタン３７が表示される。申込ボタン３６は、ドライバーの募集に応募する場合に、ドライバーが操作（例えばタッチ操作）するボタンである。戻るボタン３７は、運行計画一覧３１を示す画面に戻す場合に、ドライバーが操作（例えばタッチ操作）するボタンである。なお、図４Ｂに示す画面では、スクロール部３４は、計画詳細３５の表示内容を上下に動かしながら表示させるために利用される。

【0054】

募集処理部２１２は、好ましい形態として、車両用装置３にデマンド運行情報を提示するに際して、車両（車両用装置３）ごとに提示態様を変更する。すなわち、コントローラ２１は、デマンド運行情報を提示する提示態様を、車両ごとに変更する。コントローラ２１は、車両の位置情報と、車両のドライバーに関する情報との少なくとも一方に基づき提示態様の変更を行うことが好ましい。このような構成とすると、ドライバーが現在置かれている状況やドライバーの好み等に応じた募集内容を車両用装置３の表示画面に表示させることができる。

【0055】

提示態様の変更は、複数のデマンド運行情報を提示する順番の変更、或いは、デマンド運行情報を提示する数の変更であってよい。これによれば、簡単な処理で車両ごとに提示態様の変更を行うことができる。

【0056】

車両（車両用装置３）ごとのデマンド運行情報の提示態様の変更について、以下、具体例を挙げて説明する。本実施形態では、ドライバー募集装置２のメモリ部２２には、車両用装置３が配置される各車両の情報をテーブル化した車両情報テーブル２２１（図５参照）が格納されている。デマンド運行情報の提示態様の変更について説明する前に、車両情報テーブル２２１について説明する。なお、図５は、車両情報テーブル２２１の一例を示す図である。

【0057】

車両情報テーブル２２１の項目には、「車両ＩＤ」、「現在位置」、「ドライバーＩＤ」、「性別」、「業務エリア」、および、「評判」が含まれる。

【0058】

項目「車両ＩＤ」は、デマンド運行システム１００に登録する各車両を識別するための識別情報である車両ＩＤデータを記憶する。車両ＩＤデータは、車両情報テーブル２２１におけるデータレコードの主キーでもある。つまり車両情報テーブル２２１では、車両ＩＤデータごとにデータレコードが構成され、当該データレコードに車両ＩＤデータに紐づいた各項目のデータが記憶されることになる。例えば、車両用装置３からデマンド運行情報の配信がドライバー募集装置２に要求される場合、車両ＩＤデータが車両用装置３からドライバー募集装置２に送信される。これにより、ドライバー募集装置２において、車両ＩＤデータに紐づいた各項目のデータを抽出することができる。

【0059】

項目「現在位置」は、車両の現在位置を示す現在位置データを記憶する。現在位置データは、例えば車両用装置３が備えるＧＰＳ（Global Positioning System）センサを利用して取得することができる。現在位置データは、例えば緯度データおよび経度データを含む。現在位置データは、車両用装置３から適宜情報を得て更新される。例えば、現在位置データは、車両用装置３がドライバー募集装置２にデマンド運行情報の配信を要求する場合に、車両ＩＤデータと共にドライバー募集装置２に送信されてよい。別の例として、現在位置データは、車両用装置３から定期的にドライバー募集装置２に送信されてもよい。

【0060】

項目「ドライバーＩＤ」は、車両を運転するドライバーを識別するための識別情報であるドライバーＩＤデータを記憶する。通常、ドライバーが運転する車両は一定であり、車両ＩＤデータとドライバーＩＤデータは一定の組をなす。ただし、車両を運転するドライバーが変更されることがあり、この場合には、車両ＩＤデータに紐づけられるドライバーＩＤが変更される。

【0061】

項目「性別」は、車両を運転するドライバーの性別を示す性別データを記憶する。性別データは、ドライバーＩＤデータと紐づけられたデータである。車両ＩＤデータと紐づけられるドライバーＩＤデータが変更される場合には、車両ＩＤデータと紐づけられる性別データも変更される。性別データは、例えば、ドライバーＩＤの登録時に登録される。

【0062】

項目「業務エリア」は、車両を運転するドライバーが業務を行う主たるエリア（地域）示す業務エリアデータを記憶する。業務エリアデータは、ドライバーＩＤデータと紐づけられたデータである。車両ＩＤデータと紐づけられるドライバーＩＤデータが変更される場合には、車両ＩＤデータと紐づけられる業務エリアデータも変更される。業務エリアデータは、例えば、ドライバーＩＤの登録時に登録される。

【0063】

項目「評判」は、車両を運転するドライバーの評判を示す評判データを記憶する。評判データは、ドライバーＩＤデータと紐づけられたデータである。車両ＩＤデータと紐づけられるドライバーＩＤデータが変更される場合には、車両ＩＤデータと紐づけられる評判データも変更される。評判データは、例えば、デマンド運行される車両を利用したユーザ（乗客）の評価結果である。評価結果は、例えば、評判が良い方から順に、Ａランク、Ｂランク、Ｃランク等とされる。評価結果は、例えば、ユーザが所有する端末装置から通信ネットワーク５を介してドライバー募集装置２に送信される。

【0064】

例えば、募集処理部２１２は、ドライバーを募集中の複数の運行計画が存在する場合に、運行計画の提示を要求する車両の現在位置データに応じて、運行計画の提示順を変更する。例えば、デマンド運行の出発地が車両の現在位置に近い運行計画ほど、提示順を先とする。図４Ａに示す例において、デマンド運行の出発地が車両の現在位置に近い運行計画（路線）ほど上側に表示される。なお、現在位置に近いか否かは、距離を基準に判断してもよいし、到着に要する時間を基準に判断してもよい。

【0065】

また、例えば、募集処理部２１２は、ドライバーを募集中の複数の運行計画が存在する場合に、運行計画の提示を要求する車両のドライバーの業務エリアデータに応じて、運行計画の提示順を変更する。例えば、業務エリアデータと合致するエリアをデマンド運行する運行計画の提示順が先とされる。図４Ａに示す例において、業務エリアデータと合致するエリアをデマンド運行する運行計画が上側に表示される。

【0066】

また、例えば、募集処理部２１２は、ドライバーを募集中の複数の運行計画が存在する場合に、運行計画の提示を要求する車両のドライバーの性別データに応じて、運行計画の提示順を変更する。例えば、ドライバーが女性である場合、女性客のみが乗車するデマンド運行の運行計画の提示順が先とされる。図４Ａに示す例において、女性客のみが乗車するデマンド運行の運行計画が上側に表示される。

【0067】

なお、以上に示す例では、運行計画を提示する順番を変更する構成としたが、運行計画を提示する数が変更されてもよい。複数の運行計画の中に、特定の属性のドライバーにのみ提示される運行計画が存在してもよい。また、複数の運行計画の中に、特定の属性のドライバーには提示されない運行計画が存在してもよい。例えば、募集処理部２１２は、運行計画の提示を要求する車両のドライバーの評判データに応じて、運行計画を提示するか否かを判定してもよい。例えば、過去にトラブルを起こしたドライバーに、提示されない運行計画が存在してもよい。

【0068】

図３に戻って、応募処理部２１３は、デマンド運行のドライバー募集に対する応募を受け付けて、当該応募に対する処理を行う。なお、ドライバー募集に対する応募は、ドライバーが運転を行う車両に配置される車両用装置３を用いて行われる。ドライバー募集装置２は、当該応募により、ドライバーがデマンド業務の実行を希望する運行計画を取得する。また、ドライバー募集装置２は、当該応募により、デマンド運行を行うドライバーおよび車両の情報を取得する。ドライバーおよび車両の情報は、詳細には、上述のドライバーＩＤデータおよび車両ＩＤデータであってよい。

【0069】

本実施形態では、応募処理部２１３は、募集に対する応募に応じてデマンド運行を行うドライバーを決定する。すなわち、コントローラ２１は、募集に対する応募に応じてデマンド運行を行うドライバーを決定する。ドライバーの応募状況に応じて各運行計画のドライバーを決定することができる。なお、ドライバーの決定には、車両の決定も含まれる。また、応募に応じて各運行計画に対するドライバーを決定する処理は、ドライバー募集装置２ではなく、デマンド運行管理装置１によって行われてもよい。

【0070】

応募処理部２１３は、例えば、応募の先着順にドライバーを決定してよい。また、応募処理部２１３は、応募を一定期間募ってドライバーを決定してもよい。この場合、複数のドライバーが、同じ運行計画に応募することがあり得る。このような場合には、応募処理部２１３は、応募したドライバーのうち、評判データ（図５参照）により最も評価が高いと判定されるドライバーを、デマンド運行のドライバーに決定してよい。

【0071】

同じ運行計画に複数の応募があった場合の別の例として、応募処理部２１３は、ユーザ（乗客）の希望情報に応じて、デマンド運行を行うドライバーを決定してもよい。希望情報は、例えば、乗車予約時に予約端末装置４を用いて与えられる情報であってよい。応募処理部２１３は、例えば、ドライバーＩＤデータと紐づけられたドライバーの属性情報から、希望情報に最も近い属性を有するドライバーを、デマンド運行のドライバーに決定してよい。例えば、静かに乗車したい乗客が多い場合には、話好きのドライバーではなく、大人しいドライバーが、デマンド運行のドライバーに優先して決定されてよい。

【0072】

その他、応募処理部２１３は、複数のドライバーから応募があった場合に、ユーザにドライバーを決定させてもよい。また、応募処理部２１３は、デマンド運行業務の実行数（実績）に応じてドライバーの決定を行ってもよい。

【0073】

応募処理部２１３は、ドライバーが決定された運行計画については、決定されたドライバーの情報や車両の情報をデマンド運行管理装置１に送信する。これに応じて、デマンド運行管理装置１（配車管理部１１３）は、デマンド運行の運行計画の詳細情報を、対象となるドライバーが運転する車両に配置される車両用装置３に配信する。運行計画の詳細情報を受け取ったドライバーは、運行計画に従ったデマンド運行業務を実行する。

【0074】

なお、デマンド運行を行うことが決定された後に、ドライバーは、デマンド運行を行うドライバーとしての業務を行うことをキャンセルできる構成としてよい。例えば、コントローラ２１が、デマンド運行を行うことに決定したドライバーからのキャンセル通知を受け付ける構成としてよい。キャンセル通知は、車両用装置３を利用して行われてよい。そして、コントローラ２１は、キャンセル通知が所定要件を満たしている場合に、キャンセル通知を受け付ける構成としてよい。所定要件は、例えば、キャンセル通知が、運行計画における運行開始時刻の所定時間前（例えば２時間前）までに行われること等であってよい。キャンセル通知が受け付けられる構成とすることにより、タクシー業務を行う機会の損失が発生し難くすることができる。キャンセル通知を受け付けた場合には、対応する運行計画について、再度、ドライバーの募集が行われる構成としてよい。

【0075】

＜４．デマンド運行を行う車両の確保方法＞
次に、ドライバー募集装置２を用いてデマンド運行を行う車両を確保する方法について説明する。以下において、タクシー車両とデマンド交通車両とに兼用される車両であってデマンド運行を行う（デマンド運行業務を選択する）車両について、デマンド選択車両と表現することがある。

【0076】

ここで説明するデマンド選択車両の確保方法は、本発明の情報処理方法の一例である。ドライバー募集装置（情報処理装置）２が実行する情報処理方法には、タクシー車両とデマンド交通車両とに兼用される車両に配置される車両用装置３にデマンド運行情報を提示し、デマンド運行を行うドライバーの募集を行う処理が含まれる。以下、当該情報処理方法（デマンド選択車両の確保方法）の具体例について説明する。

【0077】

図６は、本発明の実施形態に係るデマンド選択車両の確保方法の流れを例示するフローチャートである。なお、図６に示す方法は、タクシー車両とデマンド交通車両とに兼用される車両の中から、デマンド運行を行う車両（デマンド選択車両）を確保する方法である。

【0078】

なお、本実施形態のデマンド選択車両の確保方法をコンピュータ装置に実現させるコンピュータプログラムは、本実施形態の範囲に含まれる。また、そのようなコンピュータプログラムを記録するコンピュータ読取り可能な不揮発性記録媒体は、本実施形態の範囲に含まれる。また、本実施形態のデマンド選択車両の確保方法をコンピュータ装置に実現させるコンピュータプログラムは、１つのプログラムのみで構成されてもよいが、複数のプログラムによって構成されてもよい。

【0079】

ステップＳ１では、運行計画監視部２１１が、デマンド運行管理装置１で管理されるデマンド運行の運行計画の監視を開始する。なお、運行計画は、ユーザからの予約に応じて適宜更新される。運行計画監視部２１１は、運行計画の監視により、最新の運行計画を常時取得する。運行計画の監視が開始されると、次のステップＳ２に処理が進められる。

【0080】

ステップＳ２では、募集処理部２１２が、ドライバーからの、運行計画の提示要求の有無について監視を開始する。ドライバーは、自身が運転する車両に配置される車両用装置３を用いて運行計画の提示要求を行う。運行計画の提示要求は、詳細には、複数のドライバーから要求されることが想定される。募集処理部２１２は、運行計画の提示要求が有った場合、その都度、運行計画を提示する。なお、上述のように、運行計画の提示態様は、車両ごとに異なってよい。

【0081】

当該提示により、運行計画の提示要求を行ったドライバーは、車両用装置３の表示画面３ａにより最新の運行計画を確認することができる。また、運行計画の提示要求を行ったドライバーは、運行計画ごとに設定されるドライバーの募集に応募することが可能となる。詳細には、上述した図４Ａに示すような運行計画一覧３１が表示画面３ａに表示される。そして、当該表示画面３ａの表示に応じた操作（タッチ操作等）を行うことにより、ドライバーの募集に応募することができる。例えば、図４Ｂに示す申込ボタン３６を操作することでドライバーの募集に応募することができる。運行計画の提示要求の有無について監視が開始されると、次のステップＳ３に処理が進められる。

【0082】

ステップＳ３では、応募処理部２１３が、ドライバーの募集に対する応募の有無を監視する。応募処理部２１３は、ドライバーの募集に対する応募の有無を定期的（例えば１分おき等）に監視する。例えば、上述の申込ボタン３６が操作されると、応募処理部２１３は、ドライバーの募集があったことを認識することができる。ドライバーの応募があった場合（ステップＳ３でＹｅｓ）、次のステップＳ４に処理が進められる。ドライバーの応募がない場合（ステップＳ３でＮｏ）、応募処理部２１３は、ステップＳ３の処理を続ける。

【0083】

ステップＳ４では、応募処理部２１３は、ドライバー募集に対する応募があった運行計画について、ドライバーを決定する。ここでは、先着順にドライバーが決定されることを想定している。ただし、上述のように先着順以外の手法でドライバーが決定されてよい。ドライバーの決定により、ドライバーが運転する車両をデマンド選択車両として確保することができる。ドライバーが決定されると、次のステップＳ５に処理が進められる。

【0084】

ステップＳ５では、応募処理部２１３は、デマンド選択車両の確保をデマンド運行管理装置１に通知する。これにより、デマンド運行管理装置１から、デマンド運行の運行計画の詳細が、デマンド運行を行うことに決まった車両のドライバーに通知される。詳細には、車両用装置３を介してデマンド運行の運行計画の詳細が通知される。なお、ドライバー募集装置２から車両用装置３を介して、デマンド運行を行うドライバーに決定されたことや、運行計画の詳細がドライバーに通知されてもよい。また、応募を行ったにもかかわらず、応募したドライバーに選ばれなかった者が生じることもあり得る。このような場合には、その旨が、ドライバー募集装置２から車両用装置３を介してドライバーに通知されてよい。デマンド選択車両の確保がデマンド運行管理装置１に通知されると、次のステップＳ６に処理が進められる。

【0085】

ステップＳ６では、応募処理部２１３は、ドライバーが未決定の運行計画が存在するか否かを判定する。ドライバーが未決定の運行計画が存在する場合（ステップＳ６でＹｅｓ）、ステップＳ３に処理が戻される。ドライバーが未決定の運行計画が存在しない場合（ステップＳ６でＮｏ）、図６に示す処理が完了する。

【0086】

以上のようにドライバー募集方式を利用してデマンド選択車両を確保する構成とすると、デマンド運行に対する配車を行う配車センターを用いることなく、デマンド選択車両を確保することができる。また、ドライバー募集方式を利用してデマンド選択車両を確保する構成とすると、ドライバーは、自身のタクシー業務の都合を考慮しつつ、デマンド運行業務を引き受けることができる。このために、タクシー業務の機会を無駄に損失する可能性を低減しつつデマンド運行業務を行うことができ、売り上げの向上に寄与することができる。

【0087】

＜５．変形例＞
図７は、変形例に係るデマンド運行システム１００Ａの概略の構成を示すブロック図である。変形例に係るデマンド運行システム１００Ａは、デマンド運行管理装置１、ドライバー募集装置２、車両用装置３、および、予約端末装置４の他に、配車装置６をさらに備える。

【0088】

配車装置６は、タクシー車両とデマンド車両とに兼用される複数の車両の中から、デマンド運行を行う車両の割り当てを行う。配車装置６は、例えばタクシー会社等が備えるサーバである。当該サーバは、物理サーバであっても、クラウドサーバであってもよい。配車装置６は、有線又は無線により通信ネットワーク５に接続される。配車装置６は、通信ネットワーク５を介してデマンド運行管理装置１や車両用装置３と通信可能に設けられる。

【0089】

配車装置６は、デマンド運行管理装置１からの指示に応じてデマンド運行を行う車両を配車する。本変形例では、詳細は後述するように、デマンド運行管理装置１は、ドライバー募集装置２によってドライバー（デマンド選択車両）を確保できなかった運行計画について、配車装置６に配車指示を行う。

【0090】

なお、図７においては、通信ネットワーク５に接続される配車装置６が１つしか示されていないが、通信ネットワーク５に接続される配車装置６の数は複数であってよい。また、変形例において、タクシー車両とデマンド車両とに兼用される車両は、配車装置６を備えるタクシー会社等が運営する配車センターと連携する車両であっても、配車センターと連携しない個人タクシー事業者が備える車両であってもよい。

【0091】

また、配車装置６は、デマンド運行管理装置１に含まれてもよい。デマンド運行管理装置１、ドライバー募集装置２、および、配車装置６は、１つの装置で構成されてよい。例えば、デマンド運行管理装置１、ドライバー募集装置２、および、配車装置６は、タクシー会社等が備える１つのサーバであってもよい。

【0092】

図８は、変形例に係るデマンド選択車両の確保方法の流れを例示するフローチャートである。変形例のデマンド選択車両の確保方法は、上述した実施形態のデマンド選択車両の確保方法（図６参照）にステップＳ７およびステップＳ８の処理が追加されている点が異なる。追加の処理に関わる部分以外は、上述の実施形態と同様であるので、それらの説明は省略する。以下、追加の処理に関わる説明を行う。なお、変形例の構成では、デマンド選択車両として確保された車両（ドライバー）は、配車センターと連携している場合がある。このような場合に、デマンド運行のドライバーに決定されたドライバーは、その旨を配車センターに通知する。当該通知は、車両用装置３を用いて行われてよい。

【0093】

上述の実施形態では、ステップＳ３の処理においてドライバーの応募がない場合（ステップＳ３でＮｏ）、応募処理部２１３（図３参照）は、ステップＳ３の処理を続ける構成とした。本変形例では、ステップＳ３の処理においてドライバーの応募がない場合（ステップＳ３でＮｏ）、応募処理部２１３は、ステップＳ７に処理を進める。この点、上述の実施形態と異なる。

【0094】

ステップＳ７では、応募処理部２１３が、応募締め切り時間か否かを判定する。応募締め切り時間は、例えば、運行計画における運行開始時間（例えば図４Ａ等参照）の１時間前等である。また、応募締め切り時間は、運行計画が複数ある場合、複数の運行計画のそれぞれに与えられる。応募締め切り時間である場合（ステップＳ７でＹｅｓ）、次のステップＳ８に処理が進められる。応募締め切り時間でない場合（ステップＳ７でＮｏ）、ステップＳ３に処理が戻される。

【0095】

ステップＳ８では、応募処理部２１３が配車依頼処理を行う。詳細には、応募処理部２１３は、応募締め切り時間までにデマンド選択車両を確保できなかった運行計画が発生したことをデマンド運行管理装置１に通知する。これに応じて、デマンド運行管理装置１が、配車装置６に対して、デマンド選択車両を確保できなかった運行計画に対する配車依頼を行う。当該配車依頼には、ドライバーの決定処理が含まれる。配車装置６は、配車依頼を受けて、デマンド運行を行う車両の配車処理を行う。配車依頼処理が完了すると、ステップＳ６に処理が進められる。

【0096】

以上からわかるように、変形例では、コントローラ２１は、ドライバーの募集に対する応募が無かった場合に、デマンド運行を行うドライバーの決定を他の装置に依頼する。このような構成とすることにより、デマンド運行を行う車両およびそのドライバーの確保ができないといった事態が発生する可能性を低減することができる。

【0097】

なお、デマンド運行管理装置１から配車依頼を受けた配車装置６は、例えば次のような処理を行う。配車装置６は、自動的にタクシー業務を実行中のタクシー車両の中からデマンド運行を行う車両の確保を試みる。配車装置６は、運行開始時刻の所定時間前（例えば５０分前等）までにデマンド運行を行う車両を確保できない場合、配車センターのオペレータに、その旨を通知する。この場合、オペレータが手動でデマンド運行を行う車両の確保を行う。変形例の構成では、基本的に、ドライバー募集装置２を用いたドライバー募集により、各運行計画についてデマンド選択車両を確保することができる。このために、配車装置６やオペレータを利用した、デマンド運行を行う車両の確保は最終手段である。すなわち、配車装置６やオペレータを利用することによって配車時間や配車工数が増える可能性は低く抑えることができる。また、オペレータの負担が増大する可能性も低く抑えることができる。

【0098】

また、デマンド運行管理装置１、ドライバー募集装置２、および、配車装置６が１つの装置である場合には、当該装置が備えるコントローラは、ドライバーの募集に対する応募が無かった場合に、デマンド運行を行うドライバーを自動決定する構成であってよい。

【0099】

＜６．付記＞
例示的な本発明のプログラムは、情報処理方法をコンピュータに実行させるプログラムであってよい。当該プログラムは、前記コンピュータを、タクシー車両とデマンド交通車両とに兼用される車両に配置される車両用装置にデマンド運行情報を提示し、デマンド運行を行うドライバーを募集することを行う手段として機能させる構成であってよい。

【0100】

＜７．留意事項等＞
本明細書の、発明を実施するための形態に開示される種々の技術的特徴は、その技術的創作の主旨を逸脱しない範囲で種々の変更を加えることが可能である。また、本明細書の、発明を実施するための形態に開示される複数の実施形態および変形例は可能な範囲で組み合わせて実施されてよい。

【0101】

以上の実施形態や変形例では、運行計画の全てについてドライバーの募集を行う構成としたが、これは例示にすぎない。運行計画の一部についてのみドライバーの募集を行う構成としてもよい。例えば、デマンド交通車両として専用に使われる車両がある場合には、当該車両に各運行計画を割り当て、残った運行計画について、ドライバーの募集を行う構成としてもよい。

【符号の説明】

【0102】

２・・・ドライバー募集装置（情報処理装置）
２１・・・コントローラ
３・・・車両用装置

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図5】

【図6】

【図7】

【図8】