(57)【特許請求の範囲】
【請求項１】
ユーザによって利用されるユーザ側装置（４）と、
ユーザが所望する目的地までの移動を実現する移動経路として、複数の車両提供者から提供される複数の運送車両のうちの少なくとも１つを用いた移動経路をユーザに提案する車両手配センタ（６）と、
前記ユーザに携帯される、固有の識別情報を含む通信パケットであるタグ情報パケットを所定の周波数帯の電波を用いて送信する発信器（５）と、
複数の前記運送車両のそれぞれに搭載される車載器（３）と、を備え、
前記車両手配センタと前記車載器とは相互通信可能に構成されてあって、
前記ユーザ側装置は、
前記車両手配センタと相互通信可能に構成されており、
ユーザによって指定された出発地から目的地までの移動手段の手配を要求する手配要求メッセージを前記車両手配センタへ送信し、
前記車両手配センタは、
複数の前記車両提供者から提供される複数の前記運送車両毎の運行スケジュールを記憶する運行スケジュール記憶部（６２）と、
前記ユーザ側装置から送信される前記手配要求メッセージを受信することで、前記出発地から目的地までの移動手段の手配要求を受け付ける手配要求受付部（Ｆｃ２）と、
前記運行スケジュール記憶部が記憶している前記運送車両毎の前記運行スケジュールに基づいて、前記手配要求メッセージに示されている前記出発地から前記目的地までの移動を実現する移動経路の候補を複数パターン算出する経路候補算出部（Ｆｃ３）と、
前記経路候補算出部が算出した前記移動経路の候補を、前記ユーザ側装置を介して前記ユーザに通知する経路候補通知部（Ｆｃ４）と、
前記ユーザ側装置に対するユーザ操作に基づいて、複数の前記移動経路の候補のうち、実際の移動経路として採用される前記移動経路である採用経路を特定する採用経路特定部
（Ｆｃ５）と、
前記採用経路特定部が特定した前記採用経路を提供する前記運送車両に対して、前記ユーザの乗車予約、及び、前記採用経路を実現するための走行ルートの設定を実施する車両予約部（Ｆｃ６）と、を備え、
前記車載器は、
前記発信器が発信する前記タグ情報パケットを受信するタグ情報受信部（３４）と、
書き換え可能な記憶媒体を用いて実現される車両側記憶部（３２）と、
衛星航法システムが備える航法衛星が送信する航法信号を受信することで自分自身の現在位置を特定する現在位置特定部（３３）と、を備え、
前記車両手配センタは、前記採用経路を提供する前記運送車両に対して、前記ユーザが携行する前記発信器に割り当てられている前記識別情報と、前記ユーザの乗車が予定されている地点である乗車予定地点と、前記ユーザの降車が予定されている地点である降車予定地点と、を含む乗車予定者情報を配信し、
前記車載器は、
前記車両手配センタから配信された前記乗車予定者情報を前記車両側記憶部に登録し、
前記車載器の現在位置が前記乗車予定地点となった場合に、当該地点において乗車が予定されている前記ユーザに対応する前記識別情報を含む前記タグ情報パケットを前記タグ情報受信部が受信できたか否かを判定し、
乗車が予定されている前記ユーザに対応する前記タグ情報パケットを受信できている場合には、前記ユーザが正常に乗車したことを示す通信パケットである乗車確認メッセージを前記車両手配センタに送信するとともに、
前記車載器の現在位置が前記乗車予定地点となった場合であって、かつ、当該地点において乗車が予定されている前記ユーザに対応する前記タグ情報パケットを受信できなかった場合には、前記ユーザとの合流に失敗したことを示す通信パケットである合流失敗メッセージを前記車両手配センタに送信することを特徴とする移動手段手配システム。
【請求項２】
請求項１において、
前記車載器は、
前記車載器の現在位置が前記降車予定地点となった場合に、前記タグ情報受信部の受信結果に基づいて、当該地点において降車が予定されている前記ユーザが降車したか否かを判定し、
降車が予定されている前記ユーザが降車したことを検出した場合には、前記ユーザが正常に降車したことを示す通信パケットである降車確認メッセージを前記車両手配センタに送信することを特徴とする移動手段手配システム。
【請求項３】
請求項１又は２において、
前記経路候補算出部は、
第１の前記運送車両から第２の前記運送車両への乗り継ぎが必要な前記移動経路を提案する場合には、徒歩での移動に要する時間を算出するためのパラメータとして予め設定されている歩行速度パラメータを用いて、前記運送車両の乗り継ぎのために徒歩で移動する区間の移動に要する徒歩移動時間を算出し、
第１の前記運送車両から第２の前記運送車両へ乗り継ぐために確保される時間が、算出した徒歩移動時間よりも長くなる前記移動経路を提案するものであって、
前記車両手配センタは、さらに、
第１の前記運送車両から第２の前記運送車両への乗り継ぎが必要な前記移動経路が前記採用経路に設定されている場合であって、かつ、第２の前記運送車両で用いられている前記車載器から前記合流失敗メッセージを受信した場合には、前記歩行速度パラメータを、当該移動経路の算出時に用いた値よりも小さい値に調整するパラメータ調整部（Ｆｃ９）を備えることを特徴とする移動手段手配システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザによって指定された目的地までの移動経路をユーザに提案する技術に関する。
【背景技術】
【０００２】
特許文献１に開示されているように、従来、タクシーの運行状況を管理するセンタが、ユーザからの配車要求を受け付けて、当該配車要求を出力したユーザの元へタクシーを配車するタクシー配車システムがある。このようなタクシー配車システムにおいて、配車要求の送信はユーザがスマートフォンなどの通信端末を操作することで実施される。
【０００３】
また、センタは、配車要求に応じたタクシーの配車を実施するとともに、タクシーの到着予定時刻や現在位置など情報を、配車要求を出力した通信端末へと提供する。このような態様によれば、ユーザは、通信端末を操作することで配車要求を送信できるとともに、送信した配車要求に対するセンタの処理結果を認識することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第５１４４８２５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１に開示されているタクシー配車システムによれば、ユーザはタクシーによって所望の目的地まで移動できる。しかしながら、一般的にタクシーによる移動には、移動距離に応じた料金がかかってしまう。また、ユーザの居住エリアがタクシーの営業エリア外である場合にはタクシーを利用できない。
【０００６】
もちろん、自分の足で目的地まで移動すれば、交通費は発生しないが、例えばお年寄りや足の不自由な方など、自分の足で移動することが困難な人もいる。なお、自分の足での移動には、自転車などの自分自身が保有する車両を用いて移動することも含む。
【０００７】
ところで、学校までの生徒の送迎を主目的とするスクールバスや、従業員の通勤の足として企業が運行させる通勤用バスなどといった、公共交通機関ではない車両（以降、非公共用車両）には、運行を実施しない時間（つまり空き時間）が存在すると想定される。例えば、生徒の登下校や従業員の移動は、朝と夕方に集中するため、それ以外の時間においてスクールバスや企業バスは運行されなかったり運行頻度が低減されたりする。
【０００８】
なお、ここでの非公共用車両とは、公衆の運送を主目的とする路線バスやタクシーに対して、公衆の運送が主目的ではない運送車両（換言すれば、特定の人物の輸送を主目的とする運送車両）を意味する。非公共用車両には、スクールバスや企業バスのほか、在宅介護用のデイケアバスや、観光バスなども該当する。
【０００９】
そのような空き時間となっている非公共用車両をユーザの移動手段として利用できれば、ユーザの移動手段としての選択肢が増加し、ユーザの利便性が向上すると考えられる。もちろん、公共交通機関による移動区間と非公共用車両による移動区間とを組み合わせた移動経路を提供できれば、ユーザが選択可能な移動経路がさらに増加し、ユーザは、より希望に沿った移動経路を採用できるようになる。
【００１０】
本発明は、この事情に基づいて成されたものであり、その目的とするところは、非公共用車両を用いた目的地までの移動経路をユーザに提案する交通手段手配システムを提供することにある。
【課題を解決するための手段】
【００１１】
その目的を達成するための本発明は、ユーザによって利用されるユーザ側装置（４）と、ユーザが所望する目的地までの移動を実現する移動経路として、複数の車両提供者から提供される複数の運送車両のうちの少なくとも１つを用いた移動経路をユーザに提案する車両手配センタ（６）と、ユーザに携帯される、固有の識別情報を含む通信パケットであるタグ情報パケットを所定の周波数帯の電波を用いて送信する発信器（５）と、複数の運送車両のそれぞれに搭載される車載器（３）と、を備え、車両手配センタと車載器とは相互通信可能に構成されてあって、ユーザ側装置は、車両手配センタと相互通信可能に構成されており、ユーザによって指定された出発地から目的地までの移動手段の手配を要求する手配要求メッセージを車両手配センタへ送信し、車両手配センタは、複数の車両提供者から提供される複数の運送車両毎の運行スケジュールを記憶する運行スケジュール記憶部（６２）と、ユーザ側装置から送信される手配要求メッセージを受信することで、出発地から目的地までの移動手段の手配要求を受け付ける手配要求受付部（Ｆｃ２）と、運行スケジュール記憶部が記憶している運送車両毎の運行スケジュールに基づいて、手配要求メッセージに示されている出発地から目的地までの移動を実現する移動経路の候補を複数パターン算出する経路候補算出部（Ｆｃ３）と、経路候補算出部が算出した移動経路の候補を、ユーザ側装置を介してユーザに通知する経路候補通知部（Ｆｃ４）と、ユーザ側装置に対するユーザ操作に基づいて、複数の移動経路の候補のうち、実際の移動経路として採用される移動経路である採用経路を特定する採用経路特定部
（Ｆｃ５）と、採用経路特定部が特定した採用経路を提供する運送車両に対して、ユーザの乗車予約、及び、採用経路を実現するための走行ルートの設定を実施する車両予約部（Ｆｃ６）と、を備え、車載器は、発信器が発信するタグ情報パケットを受信するタグ情報受信部（３４）と、書き換え可能な記憶媒体を用いて実現される車両側記憶部（３２）と、衛星航法システムが備える航法衛星が送信する航法信号を受信することで自分自身の現在位置を特定する現在位置特定部（３３）と、を備え、車両手配センタは、採用経路を提供する運送車両に対して、ユーザが携行する発信器に割り当てられている識別情報と、ユーザの乗車が予定されている地点である乗車予定地点と、ユーザの降車が予定されている地点である降車予定地点と、を含む乗車予定者情報を配信し、車載器は、車両手配センタから配信された乗車予定者情報を車両側記憶部に登録し、車載器の現在位置が乗車予定地点となった場合に、当該地点において乗車が予定されているユーザに対応する識別情報を含むタグ情報パケットをタグ情報受信部が受信できたか否かを判定し、乗車が予定されているユーザに対応するタグ情報パケットを受信できている場合には、ユーザが正常に乗車したことを示す通信パケットである乗車確認メッセージを車両手配センタに送信するとともに、車載器の現在位置が乗車予定地点となった場合であって、かつ、当該地点において乗車が予定されているユーザに対応するタグ情報パケットを受信できなかった場合には、ユーザとの合流に失敗したことを示す通信パケットである合流失敗メッセージを車両手配センタに送信することを特徴とする。
【００１２】
以上の構成では、車両手配センタは、ユーザからの要求に基づき、ユーザが所望する目的地までの移動経路として、複数種類の車両提供者から提供される運送車両を用いた移動経路を複数パターンユーザに提案する。このような構成において仮にスクールバスや、企業バスなどが運送車両として提供されている場合には、車両手配センタは、それらの空き時間を利用した移動経路を提案する。
【００１３】
つまり、以上の構成によれば非公共用車両を用いた目的地までの移動経路をユーザが選択可能となる。もちろん、路線バスやタクシーなどの公共交通機関も運送車両として登録されている場合には、それらを併用した移動経路を提案される。
【００１４】
また、車両手配センタがユーザに提案した複数パターンの移動経路の中にユーザの希望に沿った移動経路が存在する場合には、当該移動経路はユーザによって実際の移動経路として採用する操作が行われ、採用経路特定部によって当該移動経路が特定される。そして、車両予約部が、その移動経路を提供する運送車両の手配を実施する。このような構成によれば、ユーザは所望の目的地まで非公共用車両を用いて移動することができる。
【００１５】
なお、特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。
【図面の簡単な説明】
【００１６】
【図１】移動手段手配システム１００の概略的な構成を示すブロック図である。
【図２】車両手配センタ６の作動を説明するための図である。
【図３】車両手配センタ６の作動を説明するための図である。
【図４】運行管理サーバ１の概略的な構成を示すブロック図である。
【図５】車載器３の概略的な構成を示すブロック図である。
【図６】ユーザ側装置４の概略的な構成を示すブロック図である。
【図７】ユーザ側制御部４６の概略的な構成を示す機能ブロック図である。
【図８】無線タグ５の概略的な構成を示すブロック図である。
【図９】車両手配センタ６の概略的な構成を示すブロック図である。
【図１０】手配処理部６４の概略的な構成を示す機能ブロック図である。
【図１１】経路算出関連処理に対応するフローチャートである。
【図１２】乗車報告処理に対応するフローチャートである。
【図１３】降車報告処理に対応するフローチャートである。
【図１４】移動管理処理に対応するフローチャートである。
【図１５】車両手配センタ６の作動の一例を示す図である。
【発明を実施するための形態】
【００１７】
以下、本発明の実施形態について図を用いて説明する。図１は、本発明に係る移動手段手配システム１００の概略的な構成の一例を示す図である。図１に示すように移動手段手配システム１００は、複数の運送車両提供者のそれぞれが備える運行管理サーバ１と、各運送車両提供者が所有する複数の車両２と、複数の車両２のそれぞれに搭載される車載器３と、ユーザ側装置４と、ユーザによって携帯される無線タグ５と、車両手配センタ６を備える。
【００１８】
なお、図１では便宜上、ユーザ側装置４や無線タグ５を１つずつしか図示していないが、実際にはそれぞれ複数存在してもよい。また、図１では３つの運行管理サーバ１を示しているが、実際には４つ以上存在してもよいし、１つや２つであってもよい。３つの運行管理サーバ１をそれぞれ区別する場合には、それぞれの符号を１Ａ、１Ｂ、１Ｃと記載する。
【００１９】
＜移動手段手配システム１００の概要構成＞
移動手段手配システム１００は、ユーザによって指定された出発地から目的地までの移動経路として、運送車両提供者によって提供される車両２を利用した移動経路を提案するとともに、ユーザによって実際の移動経路として承認された移動経路を実現するための車両２の手配を行うシステムである。つまり、移動手段手配システム１００は、ユーザが所望する目的地までの移動手段を手配するシステムである。ここでのユーザとは、移動手段手配システム１００を利用する人物として車両手配センタ６に登録されている人物を指す。
【００２０】
車両２としては、路線バスや、タクシー、在宅介護用の車両（以降、デイケアバス）、生徒の送迎に供されるバス（以降、スクールバス）等を用いることができる。つまり、ここでの運送車両提供者とは、例えば、路線バスによる運送事業を営む路線バス事業者や、タクシーによる運送事業を行うタクシー事業者等、デイケアバスをユーザの運送手段として提供することを許諾している介護機関などである。また、スクールバスをユーザの運送手段として利用することを許諾している学校法人や、社員及び会社関係者の運送を主目的とする車両（以降、企業バス）をユーザの運送手段として利用することを許諾している企業なども運送車両提供者に該当する。もちろん、車両提供者は上述した存在に限らない。車両を保有する種々の存在が運送車両提供者となりうる。
【００２１】
ここでは一例として移動手段手配システム１００は、運送車両提供者Ａ、Ｂ、Ｃの三者のそれぞれが所有している運送車両を車両２として備えているものとする。運送車両提供者Ａは路線バス事業者であり、運送車両提供者Ｂはタクシー事業者であり、運送車両提供者Ｃは学校法人とする。したがって、本実施形態における移動手段手配システム１００は、路線バスやタクシー、スクールバスを利用した移動経路をユーザに提供するものである。
【００２２】
運行管理サーバ１は、輸送車両提供者が自分自身の保有する車両２の運行を管理するための設備である。例えば、図１に示す運行管理サーバ１Ａは運送車両提供者Ａとしての路線バス事業者が路線バスの運行を管理するための設備である。運行管理サーバ１Ｂは、運送車両提供者Ｂとしてのタクシー事業者がタクシーの稼働状況（例えば現在位置や乗客中であるか否か等）を管理するための設備である。運行管理サーバ１Ｃは、運送車両提供者Ｃとしての学校法人が、スクールバスの現在位置等を管理するための設備である。
【００２３】
車載器３は、自分自身が搭載されている車両２に対応する運行管理サーバ１と広域通信網を介して無線通信を実施するように構成されている。ある車両２に対応する運行管理サーバ１とは、当該車両２を保有する運送車両提供者が管理する運行管理サーバ１である。例えば運送車両提供者Ａが備える車両２に搭載されている車載器３は、何れも運行管理サーバ１Ａと広域通信網を介して通信を実施するように構成されている。
【００２４】
なお、ここでの広域通信網とは、携帯電話網やインターネット等の、電気通信事業者によって提供される公衆通信ネットワークを指す。複数の車両２のそれぞれには、他の車両と重複しない固有の識別番号（以降、車両ＩＤ）が設定されている。この車両ＩＤによって運行管理サーバ１などは、複数の車両２を区別することができる。
【００２５】
運行管理サーバ１は、運送車両提供者や車両手配センタ６からの指示に基づき、各車両２の走行ルートなどを含む運行スケジュールを計画するとともに、その計画した運行スケジュールを各車載器３に配信する。車載器３は運行管理サーバ１から配信されてきた走行ルートに沿ってドライバが運転できるように走行ルートの案内を実施する。
【００２６】
また、運行管理サーバ１は、広域通信網を介して車両手配センタ６と相互通信可能に接続されており、車両手配センタ６に対して各車両２の運行スケジュールを示す運行予定情報を提供する。
【００２７】
ユーザ側装置４は、ユーザによって操作される通信装置である。ユーザ側装置４は、ユーザ操作に基づいて、例えば出発地等といった、車両手配センタ６がユーザの所望する目的地までの移動経路を計算する上で用いる情報（以降、条件情報）を取得する。条件情報には、少なくとも出発地と目的地が含まれる。また、条件情報には、ユーザが希望する出発日時や、到着日時なども含まれる。
【００２８】
ユーザ側装置４は、広域通信網を介して車両手配センタ６と相互通信可能に構成されており、ユーザによって入力された条件情報を含む手配要求メッセージを車両手配センタ６に送信する。手配要求メッセージは、ユーザが指定した出発地から目的地までの移動手段の手配を要求する通信パケットである。
【００２９】
車両手配センタ６は、或るユーザ側装置４からの手配要求メッセージを受信した場合、その受信した手配要求メッセージに示されている条件情報と、各運行管理サーバ１から提供される運行予定情報に基づいて、出発地から目的地までの移動を実現する移動経路の候補（以降、移動経路候補）を算出する。そして、移動経路候補を示す通信パケット（以降、経路候補データ）をユーザ側装置４に返送する。
【００３０】
図２及び図３は、車両手配センタ６の作動の一例を説明するための図である。図２は、ユーザによって指定された出発地及び目的地に対する路線バスの停留所（以降、路線バス停）や、スクールバスの停留所（以降、スクールバス乗り場）などの位置関係を表している。図２中の地点Ｐｓｒｃは出発地を、地点Ｐｄｓｔは目的地を、地点Ｐａ、Ｐｂ、Ｐｃは路線バス停を、地点Ｐｘ、Ｐｙはスクールバス乗り場を、それぞれ表している。
【００３１】
図３は、ユーザが指定した出発地及び目的地に対して路線バス停やスクールバス乗り場が図２に示す位置関係で存在する場合に、車両手配センタ６が算出する移動経路候補の一例を示した図である。図３に示す第１〜第３候補のそれぞれが移動経路候補に相当する。
【００３２】
図３に示す第１候補は、路線バスとスクールバスを併用することで、ユーザが指定する到着時刻を満たす範囲において交通費を抑制するように算出した経路である。また、第２候補は、ユーザが指定する到着時刻を満たす範囲においてタクシーを利用する区間が最小となるように（換言すれば交通費が抑制されるように）算出した経路を表している。
【００３３】
第３候補は、ユーザが指定する到着時刻とは関係なく、移動手段手配システム１００がユーザに提案する経路を表している。第３候補は、生徒が登下校しない時間帯、つまりスクールバスの空き時間を利用して実現される経路である。スクールバスを利用した移動に要する料金は、運送車両提供者Ｃとしての学校法人との協議の上、適宜決定されれば良い。距離に応じた料金が発生してもよいし、定額であってもよい。また、最終的に当該スクールバスに乗り合わせた人数に応じて決定されても良い。さらに、スクールバスによる運送は、所定の人数以上のユーザから利用の申し込みがあった場合にのみ開催するなどの条件が設定されていてもよい。
【００３４】
何れにしても、車両手配センタ６は、以上のようにしてユーザからの要求に基づいて算出した移動経路候補を示すデータ（以降、経路候補データ）をユーザ側装置４に送信する。
【００３５】
ユーザ側装置４は、経路候補データを受信した場合、当該データに示される移動経路候補についての情報をユーザに提示し、実際の移動経路として採用する経路を選択するようにユーザに促す。そして、ユーザ側装置４は、ユーザによって経路が選択された場合には、その選択された経路を示す採用経路メッセージを車両手配センタ６に返送する。
【００３６】
車両手配センタ６は、採用経路メッセージを受信すると、その選択された移動経路を実現する車両２（以降、経路構成車両）の手配を行う。例えば第２候補のように、ユーザによって選択された移動経路にタクシーを用いて移動する区間が含まれている場合には、タクシーの予約を実施する。具体的には、バス停留所としての地点Ｐｂから目的地までの走行をタクシーに予約する。タクシーの乗車予定時刻は、路線バスが地点Ｐｂに到着する時刻とすればよい。タクシーは当該予約に基づいて、乗車予定時刻に地点Ｐｂ付近でユーザの到着を待機する。
【００３７】
また、例えば第３候補のように、ユーザによってスクールバスを利用した経路が選択された場合には、スクールバスに搭載されている車載器３に対して、スクールバスが担当するべき区間を走行ルートとして設定させる。
【００３８】
予定される利用時間における車両２の確保や、確保した車両２に対する走行ルートの設定は、車両手配センタ６が直接実施してもよいし、運行管理サーバ１を介して実現されてもよい。ここでは一例として、運行管理サーバ１と協働して車両２の確保や走行ルートの設定が実施されるものとする。
【００３９】
また、車両手配センタ６は、車両２の手配が完了すると、その車両２に乗車する予定のユーザについての情報（以降、乗車予定者情報）を、運行管理サーバ１を介してその手配した車両２に搭載されている車載器３へ配信する。乗車予定者情報については別途後述する。
【００４０】
無線タグ５は、車載器３と無線通信を実施することで、ユーザが予約内容に沿って移動できているか否かを管理するために用いられる。具体的には、ユーザが承諾した移動経路（つまり採用経路）を構成する車両２に無事に乗車できたか否か、及び、降車するべき地点で無事に降車できたか否かを管理するために用いられる。
【００４１】
もちろん、乗降車を管理することはユーザによるサービスの利用状況を管理することに繋がる。そのため、無線タグ５と車載器３との通信結果は、サービスの利用状況に応じた料金の請求にも利用することができる。なお、以降では採用経路を構成する車両２のことを、便宜上、車両手配センタ６が手配した車両２とも表現する。便宜上、以下、各部の構成及び作動について説明する。
【００４２】
＜運行管理サーバ１について＞
ここでは、運送車両提供者Ａが管理している運行管理サーバ１Ａを例にとって運行管理サーバ１の構成について述べる。なお、他の運送車両提供者が管理している運行管理サーバ１も同様の構成となっている。
【００４３】
運行管理サーバ１は、図４に示すように広域通信部１１、運行管理データベース（以降、運行管理ＤＢ）１２、及び運行管理部１３を備える。広域通信部１１及び運行管理ＤＢ１２はそれぞれ運行管理部１３と相互通信可能に接続されている。
【００４４】
広域通信部１１は、広域通信網に接続し、種々の外部装置（例えば車載器３や車両手配センタ６）と通信するための通信モジュールである。広域通信部１１は、運行管理部１３から入力されたデータを変調して広域通信網を介して所定の送信先に送信する。また、自分自身を宛先とする通信パケットを受信して運行管理部１３に提供する。なお、本実施形態では一例として運行管理サーバ１は広域通信網に有線接続している態様とするが、これに限らない。運行管理サーバ１は、広域通信網に無線接続する構成となっていても良い。
【００４５】
運行管理ＤＢ１２は、書き換え可能な不揮発性の記憶媒体を用いて実現されるデータベースである。運行管理ＤＢ１２は、運行管理部１３によるデータの書き込み、読出、削除等が実施可能に構成されている。運行管理ＤＢ１２には、運送車両提供者Ａが保有する車両２毎の運行スケジュールを示すデータ（以降、運行予定情報）が登録されている。
【００４６】
或る車両２の運行スケジュールとは、本来の役務のために車両２を稼働させる時間帯（以降、稼働時間帯）や、稼働時間帯における当該車両２が走行すべき経路（以降、走行ルート）、ドライバの休憩に供される時間帯（以降、休憩時間帯）、ユーザの輸送のために利用可能な時間帯（つまり空き時間）等を示す。車両２にとっての本来の役務とは、車両２の所属に由来するものである。例えばスクールバスにとっての本来の役務とは所定の学校に通学する生徒の送迎であり、企業バスにとっての本来の役務とは従業員等の運送である。また、デイケアバスにとっての本来の役務とは、介護対象者の元への訪問である。
【００４７】
また、運行管理ＤＢ１２には、各車両２の実際の運行状況を示すデータが登録される。運行状況とは、例えば現在位置や、所定のチェックポイントに対して予め設定されている目標通過時刻に対する遅延等である。チェックポイントとは、目標通過時刻が設定されている地点であって、例えば路線バスにとってのチェックポイントとは、バス停などとすればよい。種々の車両２は、車両２に割り当てられた車両ＩＤによって管理されればよい。
【００４８】
運行管理部１３は、運送車両提供者Ａが保有する車両２の運行スケジュールや、ドライバの割り当て等を計画し、運行管理ＤＢ１２に登録する。これにより、或る１日において或る車両２が走行すべきルート（つまり走行ルート）や、稼働時間帯、休憩時間帯、担当ドライバ等が決定される。
【００４９】
各車両２の運行スケジュールは、運送車両提供者の指示に加えて、車両手配センタ６からの要求にも対応して計画される。運行管理部１３は、広域通信部１１と協働して、計画した車両２毎の運行スケジュールを、運行予定情報として車両手配センタ６に送信する。なお、運行管理部１３は、車両手配センタ６から乗車予定者情報が配信されてきた場合には、その乗車予定者情報を、当該乗車予定者情報に対応する車両２の運行スケジュールに対応付けて保存する。
【００５０】
また、運送車両提供者によって車両２の基本走行ルートが設定されている場合には、運行管理部１３は、当該基本走行ルートを示す情報も車両手配センタ６に提供する。ここでの基本走行ルートとは、車両２が本来の役務を果たすために、運送車両提供者によって予め設定されている走行ルートのことである。例えば路線バスの基本走行ルートとは、路線バスが走行する経路、及び、停留所の位置を示す情報であり、スクールバスの基本走行ルートとは、スクールバスが生徒の運搬のために走行する経路、及び、スクールバス乗り場の位置を示す情報である。
【００５１】
さらに、運行管理部１３は、運送車両提供者によって運送対応エリアが設定されている場合には、その運送対応エリアを示す情報も車両手配センタ６に提供する。ここでの運送対応エリアとは、車両２を用いたユーザの移動依頼に対応可能なエリアである。運送対応エリアは、運送車両提供者によって予め設定されていればよい。
【００５２】
また、運行管理部１３は、広域通信部１１と協働し、所定のタイミング（例えば業務開始時刻等）で各車載器３に対して、その車載器３が用いられている車両２の運行スケジュールを示すデータを配信する。なお、乗車予定者情報の配信は、運行スケジュールと同じタイミングで配信されても良いし、異なるタイミングであってもよい。運行スケジュールと乗車予定車情報は互いに対応付けられた１セットのデータとして配信されることが好ましい。
【００５３】
また、運行管理部１３は、車載器３から送信されてくる位置情報を用いて運行管理ＤＢ１２に登録されている車両２毎の現在の運行状況を更新する。運行管理部１３は、ＣＰＵ、ＲＡＭ、ＲＯＭ、Ｉ／Ｏ、及びこれらの構成を接続するバスラインなどを備えるコンピュータとして構成されていればよい。
【００５４】
ＣＰＵは、種々の演算処理を実行する中央処理装置であって、マイクロプロセッサ等を用いて実現される。ＲＡＭは揮発性のメモリであり、ＲＯＭは不揮発性のメモリである。ＲＯＭには、通常のコンピュータを運行管理部１３として機能させるためのプログラム（以降、運行管理用プログラム）がインストールされている。運行管理部１３が備える種々の機能はＣＰＵが運行管理用プログラムを実行することで実現されれば良い。
【００５５】
＜車載器３について＞
次に、図５を用いて車載器３の構成及び作動について述べる。車載器３は図５に示すように、広域通信部３１、車両側記憶部３２、ロケータ３３、近距離通信部３４、ディスプレイ３５、スピーカ３６、及び車両側制御部３７を備える。広域通信部３１、車両側記憶部３２、ロケータ３３、近距離通信部３４、ディスプレイ３５、及びスピーカ３６のそれぞれは、車両側制御部３７と相互通信可能に接続されている。
【００５６】
便宜上、車載器３にとって自分自身が搭載されている車両２のことを自車両とも記載する。また、自車両と対応付けられている運行管理サーバ１のことを自車対応サーバとも記載する。
【００５７】
広域通信部３１は、広域通信網に無線接続するための通信モジュールである。広域通信部３１は、車両側制御部３７から入力されたデータを変調して所定の宛先とする通信端末（例えば自車対応サーバ）に送信する。また、他の通信端末から送信されてきたデータを受信して車両側制御部３７に提供する。
【００５８】
車両側記憶部３２は、書き換え可能な不揮発性の記憶媒体を用いて実現される記憶装置である。車両側記憶部３２は、車両側制御部３７によるデータの書き込み、読出、削除等が実施可能に構成されている。車両側記憶部３２には、広域通信部３１が受信した運行スケジュール等が保存される。また、車両側記憶部３２には、車両手配センタ６から運行管理サーバ１を介して配信される乗車予定者情報が、運行スケジュールと対応付けられて保存される。
【００５９】
ロケータ３３は、道路地図上において、自車両が現在走行している地点を特定する装置である。ロケータ３３は、より細かい構成要素として、ＧＮＳＳ受信機及び地図記憶部を備える。
【００６０】
ＧＮＳＳ受信機は、衛星航法システムであるＧＮＳＳ（Global Navigation Satellite System）が備える航法衛星が送信する航法信号を受信し、受信した航法信号に基づいて現在位置を逐次算出する。地図記憶部は、道路の接続関係や、道路の形状（換言すれば道路構造）を示す道路地図データを記憶している。地図記憶部は、ハードディスクドライブ等の不揮発性の記憶媒体を用いて実現されればよい。
【００６１】
ロケータ３３は、ＧＮＳＳ受信機が検出している現在位置に基づいて、道路地図上における自車両の位置を特定する。道路地図上における車両位置を特定することを、以降ではマッピングとも記載する。車両位置のマッピングは、ナビゲーション装置で慣用されている既知のマップマッチング技術を援用して実施すれば良い。マップマッチング技術は、複数時点における車両の進行方向や走行速度から車両の走行軌跡を求め、この車両の走行軌跡と地図情報から得た道路形状とを比較して車両の現在位置を求める技術である。ロケータ３３は、現在位置を示す位置情報を車両側制御部３７に逐次提供する。ロケータ３３が請求項に記載の現在位置特定部に相当する。
【００６２】
近距離通信部３４は、後述する無線タグ５と、広域通信網を介さない直接的な無線通信（以降、近距離通信）を行うための通信モジュールである。近距離通信を実現するための通信規格は、IEEE 802.11やIEEE 802.15.1など、任意のものを採用することができる。近距離通信部３４は、受信データを車両側制御部３７に提供するとともに、車両側制御部３７から入力されたデータを変調し、電波として空間に放射する。近距離通信部３４が請求項に記載のタグ情報受信部に相当する。
【００６３】
なお、近距離通信部３４が通信可能な範囲は、車室外を含まないように設計されていることが好ましい。ここでは一例として、近距離通信部３４にとって近距離通信可能な範囲が車室内の全領域をカバーし、かつ、車室外を含まないように、近距離通信用のアンテナの設置位置や指向性、送信電力が調整されているものとする。
【００６４】
ディスプレイ３５は、車両側制御部３７から入力されたデータに対応する画像を表示する。スピーカ３６は、車両側制御部３７から入力されたデータに対応する音声メッセージや音を出力する。
【００６５】
車両側制御部３７は、車載器３全体の作動を制御する。車両側制御部３７は、ＣＰＵ、ＲＡＭ、ＲＯＭ、Ｉ／Ｏ、及びこれらの構成を接続するバスラインなどを備えるコンピュータとして構成されている。
【００６６】
車両側制御部３７は、自車対応サーバから配信される運行スケジュールを車両側記憶部３２に登録する。また、乗車予定者情報を受信した場合には、その乗車予定者情報を車両側記憶部３２に保存する。車両側制御部３７は、車両側記憶部３２に保存されている運行スケジュールに沿って自車両が運行するように、１日のスケジュール等をドライバに通知する。
【００６７】
また、稼働時間帯においては、自車両が走行ルートに沿って走行するようにドライバの運転操作を支援する走行案内処理を実施する。例えば車両側制御部３７は走行案内処理として、ディスプレイ３５に走行ルートを示す地図画像を表示するとともに、スピーカ３６から右左折等の運転操作を案内する音声を出力させる。所定の走行ルートに沿った走行を支援する技術はナビゲーション装置として公知の技術を適用して実施することができる。
【００６８】
また、車両側制御部３７は、自車両の現在位置はロケータ３３から提供される自車両の現在位置を示す位置情報を、所定の報告周期で（例えば１秒毎に）自車対応サーバに送信する。さらに車両側制御部３７は、後述する乗車報告処理及び降車報告処理を実施する。
【００６９】
＜ユーザ側装置４について＞
次に、ユーザ側装置４について述べる。ユーザ側装置４は、ユーザが車両手配センタ６に対して所望の目的地までの移動手段の手配を要求するためのデバイスであって、ユーザ操作に基づいて生成した手配要求メッセージを車両手配センタ６に送信する。また、ユーザ側装置４は、車両手配センタ６から提供される移動経路候補をユーザに提示する。ユーザ側装置４としては、例えば、スマートフォンや、タブレット端末、携帯電話機、自宅やオフィスに設置されたコンピュータ、自宅等に設置された固定電話などを採用することができる。ここでは一例としてユーザ側装置４はスマートフォンなどの携帯型通信端末とする。
【００７０】
ユーザ側装置４は、図６に示すように、広域通信部４１、ＧＮＳＳ受信機４２、ディスプレイ４３、入力装置４５、スピーカ４４、及びユーザ側制御部４６を備える。広域通信部４１、ＧＮＳＳ受信機４２、ディスプレイ４３、スピーカ４４、及び入力装置４５のそれぞれは、ユーザ側制御部４６と相互通信可能に接続されている。
【００７１】
広域通信部４１は、広域通信網に無線接続して種々の外部装置（例えば車両手配センタ６）と通信するための通信モジュールである。ＧＮＳＳ受信機４２は、ＧＮＳＳが備える航法衛星が送信する航法信号を受信し、受信した航法信号に基づいてユーザ側装置４の現在位置を逐次（例えば１００ミリ秒毎に）算出する。ＧＮＳＳ受信機４２が算出した現在位置を示す位置情報はユーザ側制御部４６に逐次提供される。
【００７２】
ディスプレイ４３は、ユーザ側制御部４６から入力されるデータに対応する画像を表示する。スピーカ４４は、ユーザ側制御部４６から入力されたデータに対応する音声メッセージや音を出力する。
【００７３】
入力装置４５は、ユーザ側装置４に対するユーザの指示操作を受け付けるためのデバイスである。ここでは一例として入力装置４５は、ディスプレイ４３と一体になったタッチパネルとする。入力装置４５は、ユーザによってタッチされたことを検出すると、そのタッチ位置を示す制御信号をユーザ側制御部４６に出力する。なお、他の態様として入力装置４５は、キーボードやマウス、マイクなどであっても良い。マイクを入力装置４５として採用する場合には、ユーザ側装置４又は車両手配センタ６は、マイクに入力された音声を解析してテキスト化する（つまり音声認識する）音声認識処理部を備えるものとする。
【００７４】
ユーザ側制御部４６は、ＣＰＵ４６１、ＲＡＭ４６２、ＲＯＭ４６３、Ｉ／Ｏ４６４、及び、これらの構成を接続するバスラインなどを備えるコンピュータとして構成されている。ＲＯＭ４６３には、通常のコンピュータをユーザ側制御部４６として機能させるためのプログラム（以降、ユーザ用プログラム）がインストールされている。
【００７５】
なお、上述のユーザ用プログラムは、非遷移的実体的記録媒体（non- transitory tangible storage medium）に格納されていればよく、その具体的な記憶媒体はＲＯＭに限らない。例えばユーザ用プログラムはフラッシュメモリに保存されていても良い。ＣＰＵ４６１がユーザ用プログラムを実行することは、ユーザ用プログラムに対応する方法が実行されることに相当する。
【００７６】
このユーザ側制御部４６は、ＣＰＵ４６１がＲＯＭ４６３に格納されている上述のユーザ用プログラムを実行することによって、図７に示す種々の機能を提供する。すなわち、ユーザ側制御部４６は機能ブロックとして、表示処理部Ｆｕ１、条件情報取得部Ｆｕ２、送信処理部Ｆｕ３、受信処理部Ｆｕ４、経路選択受付部Ｆｕ５、及び予約通知部Ｆｕ６を備える。
【００７７】
表示処理部Ｆｕ１は、ディスプレイ４３に表示させる画像を生成する。例えば、表示処理部Ｆｕ１は、ユーザが目的地や出発地、到着時刻などといった種々の条件情報を入力するための画面（以降、条件情報入力画面）をディスプレイ４３に表示するための画像データを生成する。そして、表示処理部Ｆｕ１は、生成した画像データをディスプレイ４３に出力し、表示させる。つまり、表示処理部Ｆｕ１は、ディスプレイ４３の表示画面を制御する。
【００７８】
条件情報取得部Ｆｕ２は、表示処理部Ｆｕ１及び入力装置４５と協働し、条件情報を取得する。例えば、条件情報取得部Ｆｕ２は、表示処理部Ｆｕ１がディスプレイ４３に条件情報入力画面を表示している状態において入力装置４５が受け付けたユーザのタッチ操作に基づいて、目的地を特定する。その他の条件についても同様に条件情報取得部Ｆｕ２は、入力装置４５に対するユーザ操作に基づいて取得する。ユーザによって到着日時が設定された場合には、その設定された日時を到着日時として取得する。
【００７９】
出発地とする地点は、ＧＮＳＳ受信機４２から提供される現在位置とすればよい。また、出発地は、入力装置４５を介してユーザによって指定された地点であってもよい。例えば、ユーザは入力装置４５を操作することで、自宅の住所を出発地として指定できるものとする。条件情報に該当する個々の条件はユーザによって指定されれば良い。
【００８０】
条件情報取得部Ｆｕ２は、入力装置４５と協働し、条件情報の入力が完了した旨を示すユーザ操作が行われたことを検出した場合に、送信処理部Ｆｕ３に対して条件情報を含む手配要求メッセージ送信するように要求する。
【００８１】
送信処理部Ｆｕ３は、他の機能ブロックからの要求に基づいて、当該要求に対応する通信パケットを生成し、広域通信部４１から送信させる処理を行う。例えば送信処理部Ｆｕ３は、条件情報取得部Ｆｕ２からの要求に基づいて手配要求メッセージに相当する通信パケットを生成して広域通信部４１に出力し、送信させる。手配要求メッセージには、条件情報のほか、車両２の手配を要求しているユーザを車両手配センタ６が特定するためのユーザＩＤが含まれているものとする。
【００８２】
受信処理部Ｆｕ４は、広域通信部４１が受信したデータを取得する。例えば受信処理部Ｆｕ４は、手配要求メッセージに対する応答として車両手配センタ６から返送される経路候補データを取得する。受信処理部Ｆｕ４が取得したデータは書き換え可能な記憶媒体に保存される。
【００８３】
経路選択受付部Ｆｕ５は、受信処理部Ｆｕ４が経路候補データを受信した場合に、当該経路候補データに示される複数の移動経路候補のうち、ユーザが希望する経路を特定するための処理を実施する。
【００８４】
例えば経路選択受付部Ｆｕ５は、表示処理部Ｆｕ１と協働して複数の移動経路候補の中から、実際の移動経路として採用する移動経路（以降、採用経路）をユーザが選択するための画面（以降、経路選択画面）をディスプレイ４３に表示する。経路選択画面は、例えば移動経路候補毎の概略的な内容（例えば乗り換え回数や、総移動時間等）を表示するとともに、採用経路を選択するためのボタン（以降、経路選択用ボタン）を配置した画面とすればよい。
【００８５】
そして経路選択受付部Ｆｕ５は、経路選択画面を表示している状態において入力装置４５が受け付けたユーザ操作に基づいて、複数の移動経路候補の中から採用経路を特定する。経路選択受付部Ｆｕ５は採用経路を特定できた場合には、送信処理部Ｆｕ３に、当該採用経路を示す通信パケット（以降、採用経路メッセージ）を送信させる。
【００８６】
これにより、ユーザが希望する移動経路（つまり採用経路）が車両手配センタ６に伝えられ、車両手配センタ６は、当該採用経路を実現するための車両２の手配を実施する。なお、車両手配センタ６は、採用経路に対応する車両２の手配が完了すると、手配が完了したことを示す通信パケット（以降、手配完了メッセージ）をユーザ側装置４に返送する。
【００８７】
手配完了メッセージは、ユーザが希望する移動経路を実現するための車両の予約が完了したことを示すメッセージとして機能する。手配完了メッセージには、ユーザが出発地を出発するべき時刻（以降、移動開始時刻）が含まれているものとする。
【００８８】
予約通知部Ｆｕ６は、受信処理部Ｆｕ４が手配完了メッセージを受信した場合に、その内容を表示する。また、本実施形態ではより好ましい態様として予約通知部Ｆｕ６は、手配完了メッセージに示される移動開始時刻の所定時間（例えば２時間）前となった場合に、表示処理部Ｆｕ１と協働して予約内容を示す画面をディスプレイ４３に表示する。つまり、予約通知部Ｆｕ６は、周知のリマインダ機能を提供する。これにより、ユーザが移動手段の手配を依頼していたことを忘れてしまうことを抑制することができる。
【００８９】
＜無線タグ５について＞
無線タグ５は、鞄や靴等に取り付けられたり、衣服のポケット等に収容されたりすることで、ユーザによって携帯される。無線タグ５には予めユーザの属性情報や、他の無線タグ５とは重複しない固有の識別番号（以降、タグＩＤ）が登録されている。タグＩＤが請求項に記載の識別情報に相当する。
【００９０】
ここでの属性情報とは、年齢や、性別、社会的属性、備考情報などを含む。社会的属性とは、小学生、中学生、高校生、会社員などといった、いわゆる社会的な立場を示す項目である。また、備考情報には、ハンディキャップの有無や、妊娠中であるか否かなどといった、身体状態に関わる情報が示されていれば良い。
【００９１】
無線タグ５は、近距離通信によって無線タグ５に登録されているタグＩＤと属性情報とを含むタグ情報パケットを送信する。このタグ情報パケットは、ユーザが予約内容に沿って移動できているかの管理に用いられる。無線タグ５が請求項に記載の発信器に相当する。
【００９２】
この無線タグ５は図８に示すように、近距離通信部５１、近接場通信部５２、メモリ５３、及びメイン処理部５４を備える。メイン処理部５４は、近距離通信部５１及びメモリ５３と相互通信可能に構成されており、近接場通信部５２は、メモリ５３と相互通信可能に接続されている。
【００９３】
近距離通信部５１は、所定の周波数帯の電波を用いて車載器３と近距離通信を行うための通信モジュールである。近距離通信部５１はメイン処理部５４から入力されたデータを変調して電波として空間に放射するとともに、受信信号を復調してメイン処理部５４に提供する。
【００９４】
近接場通信部５２は、近接場通信（Near Field Communication：ＮＦＣ）を実施するための通信モジュールである。ここでの近接場通信とは、近距離通信よりも通信可能な距離が十分に小さい通信方式による通信を指す。例えば、近接場通信の通信可能な距離は数ｃｍから数十ｃｍ程度となる通信を指す。
【００９５】
近接場通信部５２は、ISO/IEC 14443やISO/IEC 18092といった、周知の通信規格に準拠して、図示しないリーダライタと近接場通信を実施する。リーダライタは、近接場通信によって無線タグ５に登録されている情報を参照したり、データを書き換えたりするための装置である。
【００９６】
無線タグ５のユーザは、リーダライタを用いて無線タグ５に属性情報を登録したり、登録内容を変更したり、登録内容を参照する事ができる。このように無線タグ５が近接場通信部５２を備えることで、無線タグ５に登録されている内容の確認や、登録内容の変更をユーザが実施することができる。
【００９７】
メモリ５３は、書き換え可能な不揮発性の記憶媒体である。メモリ５３は、例えばフラッシュメモリを用いて実現すればよい。メモリ５３には、タグＩＤのほか、属性情報が格納される。
【００９８】
メイン処理部５４は、近距離通信部５１の動作を制御する。メイン処理部５４は、例えば、ＣＰＵやＩＣを用いて実現されればよい。メイン処理部５４は、近距離通信部５１と協働し、タグ情報パケットを送信する処理（以降、発信処理）を実施する。
【００９９】
なお、メイン処理部５４は、車載器３からの問い合わせ信号を受信したことをトリガとしてタグ情報パケットを送信するパッシブ送信モードと、所定の送信周期でタグ情報パケットを定期的に送信するアクティブ送信モードの２つの動作モードを備える。
【０１００】
パッシブ送信モードでは、問い合わせ信号を受信していない状態においてはスリープモードになっている。スリープモードは、車載器３からの問い合わせ信号を受信したことを検出するために必要な機能については動作させる一方、その他の機能については動作を停止させることで消費電力を抑制している状態を指す。
【０１０１】
メイン処理部５４をパッシブ送信モードとして動作させるか、アクティブ送信モードとして動作させるかは、ユーザによって選択可能に構成されていることが好ましい。本実施形態では一例としてメイン処理部５４は、パッシブ送信モードに設定されているものとする。なお、他の態様として、メイン処理部５４は、パッシブ送信モードとアクティブ送信モードの何れか一方でしか動作しないように構成されていても良い。
【０１０２】
なお、メイン処理部５４はパッシブ送信モードに設定されている場合、メイン処理部５４は問い合わせ信号を受信した時点を起算時点としてランダム時間待機してからタグ情報パケットを送信するものとする。車載器３の周辺に複数の無線タグ５が存在する場合を想定し、複数の無線タグ５のそれぞれが応答するタイミングが重なってしまうリスクを低減するためである。待機時間は予め登録された乱数表を用いて決定されれば良い。
【０１０３】
＜車両手配センタ６について＞
次に、車両手配センタ６の構成及び作動について述べる。車両手配センタ６は図９に示すように、広域通信部６１、センタ側運行管理データベース（以降、センタ側運行管理ＤＢ）６２、ユーザ管理データベース（以降、ユーザ管理ＤＢ）６３、及び手配処理部６４を備える。広域通信部６１、センタ側運行管理ＤＢ６２、及びユーザ管理ＤＢ６３のそれぞれは、手配処理部６４と相互通信可能に接続されている。
【０１０４】
広域通信部６１は、広域通信網に接続し、種々の外部装置（例えば車載器３やユーザ側装置４）と通信するための通信モジュールである。なお、本実施形態では一例として車両手配センタ６は広域通信網に有線接続している態様とするが、これに限らない。車両手配センタ６は、広域通信網に無線接続する構成となっていても良い。
【０１０５】
センタ側運行管理ＤＢ６２は、書き換え可能な不揮発性の記憶媒体を用いて実現されるデータベースである。センタ側運行管理ＤＢ６２は、手配処理部６４によるデータの書き込み、読出、削除等が実施可能に構成されている。センタ側運行管理ＤＢ６２には、手配処理部６４によって各運行管理サーバ１から提供される各車両２の運行予定情報や基本走行ルート、運送対応エリアが登録される。センタ側運行管理ＤＢ６２が請求項に記載の運行スケジュール記憶部に相当する。
【０１０６】
ユーザ管理ＤＢ６３は、書き換え可能な不揮発性の記憶媒体を用いて実現されるデータベースである。ユーザ管理ＤＢ６３は、手配処理部６４によるデータの書き込み、読出、削除等が実施可能に構成されている。ユーザ管理ＤＢ６３は、移動手段手配システム１００のユーザについてのデータが格納されている。
【０１０７】
複数のユーザは、ユーザ固有の識別情報であるユーザＩＤによって互いに識別される。ユーザ管理ＤＢ６３は、或るユーザについてのデータ（以降、ユーザデータ）として、ユーザＩＤと当該ユーザが携行する無線タグ５のタグＩＤとを対応付けて保存している。
【０１０８】
なお、ユーザデータには、ユーザの電話番号やメールアドレスといった連絡先情報や、交通費やサービス使用料の精算に用いられる精算用情報なども含まれていることが好ましい。精算用情報とは、クレジットカード番号や、銀行口座番号など、クレジットカードによる支払いや、口座振替を実施するための情報とすればよい。
【０１０９】
手配処理部６４は、ユーザ側装置４から送信される手配要求メッセージに基づいた車両の手配を実施する。手配処理部６４は、ＣＰＵ、ＲＡＭ、ＲＯＭ、Ｉ／Ｏ、及び、これらの構成を接続するバスラインなどを備えるコンピュータとして構成されている。ＲＯＭには、通常のコンピュータを手配処理部６４として機能させるためのプログラム（以降、移動手段手配プログラム）がインストールされている。
【０１１０】
なお、上述の移動手段手配プログラムは、非遷移的実体的記録媒体（non- transitory tangible storage medium）に格納されていればよく、その具体的な記憶媒体はＲＯＭに限らない。例えば移動手段手配プログラムはフラッシュメモリに保存されていても良い。ＣＰＵが移動手段手配プログラムを実行することは、移動手段手配プログラムに対応する方法が実行されることに相当する。
【０１１１】
この手配処理部６４は、ＣＰＵがＲＯＭに格納されている移動手段手配プログラムを実行することによって、図１０に示す種々の機能を提供する。すなわち、手配処理部６４は機能ブロックとして、運行管理情報取得部Ｆｃ１、手配要求受付部Ｆｃ２、経路候補算出部Ｆｃ３、経路候補通知部Ｆｃ４、採用経路特定部Ｆｃ５、車両予約部Ｆｃ６、搭乗者情報配信部Ｆｃ７、移動管理部Ｆｃ８、及びパラメータ調整部Ｆｃ９を備える。
【０１１２】
運行管理情報取得部Ｆｃ１は、各運行管理サーバ１から提供される運行予定情報や、基本走行ルート、運送対応エリアを取得し、センタ側運行管理ＤＢ６２に登録する。手配要求受付部Ｆｃ２は、広域通信部６１が手配要求メッセージを受信した場合に、当該手配要求メッセージに示される条件情報に基づいた移動経路の算出要求を受け付ける。
【０１１３】
経路候補算出部Ｆｃ３は、手配要求受付部Ｆｃ２が受け付けた算出要求に対応する移動経路候補を、センタ側運行管理ＤＢ６２に登録されている運行予定情報に基づいて算出する。移動経路は、例えばダイクストラ法などの、周知の経路計算アルゴリズムを援用して算出されればよい。経路候補算出部Ｆｃ３は、移動経路候補として、交通費を抑制する経路や、移動時間を抑制する経路、徒歩で移動する距離を抑制する経路など、種々の目的に応じた複数パターンの経路を算出するものとする。
【０１１４】
経路候補算出部Ｆｃ３は、経路算出時に、移動に要する時間（つまり移動時間）も合わせて算出する。移動時間は、道路の制限速度や、時間帯に応じた巡航速度、道路の混雑度合いなどの種々の演算パラメータを用いて算出する。また、徒歩で移動する区間の移動に要する時間は、徒歩で移動する区間の距離を、予め設定された歩行速度パラメータで除算することで算出されれば良い。歩行速度パラメータは、徒歩での単位時間当りの移動速度を表すパラメータである。例えば移動速度パラメータは７０ｍ／分などに設定されている。
【０１１５】
経路候補通知部Ｆｃ４は、広域通信部６１と協働して、経路候補算出部Ｆｃ３が算出した複数の移動経路候補を示すデータ（つまり経路候補データ）を、手配要求メッセージの送信元に相当するユーザ側装置４に送信する。採用経路特定部Ｆｃ５は、ユーザ側装置４から送信されてくる採用経路メッセージにも基づいて、経路候補算出部Ｆｃ３が算出した移動経路候補のうち、ユーザが実際の移動経路として選択した経路（つまり採用経路）を特定する。
【０１１６】
車両予約部Ｆｃ６は、採用経路特定部Ｆｃ５が特定した採用経路を実現する車両２（つまり経路構成車両）に対して、その経路構成車両が担当すべき区間を、ユーザの移動に応じたタイミングで走行するように予約する。つまり、走行ルートの設定と乗車の予約を行う。乗車の予約の内容には、利用時間なども含まれる。
【０１１７】
なお、経路構成車両が路線バスなどの走行路線が設定されているものである場合には、走行ルートの設定は省略されれば良い。走行ルートの設定は、ユーザの移動手段として、タクシーや、空き時間となっているスクールバス等を利用する場合などに実施されればよい。なお、経路構成車両としての車両２に対する走行ルートの設定は、当該車両２に対応する運行管理サーバ１を介して実施されればよい。車両予約部Ｆｃ６は、採用経路に対応する車両２の手配が完了すると、広域通信部６１と協働し、手配完了メッセージをユーザ側装置４に返送する。
【０１１８】
搭乗者情報配信部Ｆｃ７は、経路提供車両に搭載されている車載器３に対して、乗車予定者情報を配信する。乗車所定者情報の車載器３への配信は、本実施形態では一例として、経路提供車両に対応する運行管理サーバ１と協働して実施するものとするがこれに限らない。搭乗者情報配信部Ｆｃ７が直接車載器３へ配信してもよい。
【０１１９】
乗車予定者情報には、少なくともユーザが携帯する無線タグ５のタグＩＤと、乗車予定地点と、降車予定地点とが含まれていれば良い。本実施形態ではより好ましい態様として乗車予定者情報には、さらに、乗車予定時刻と降車予定時刻が含まれているものとする。ユーザが携帯する無線タグ５に割り当てられているタグＩＤは、ユーザ管理ＤＢ６３を参照することで特定されれば良い。
【０１２０】
移動管理部Ｆｃ８は、ユーザが採用経路に沿って移動できているか否かを管理するとともに、ユーザの行動を示すデータをユーザ管理ＤＢ６３等に記録する。ユーザの行動を示すデータとは、経路構成車両に乗車できたか否か、降車するべき地点で降車できたか否か等を示すデータである。移動管理部Ｆｃ８の作動についての詳細は別途後述する。
【０１２１】
パラメータ調整部Ｆｃ９は、移動管理部Ｆｃ８が記録しているデータに基づいて、移動時間の算出に用いる種々のパラメータを調整する。例えば路線バスからスクールバスへのユーザの乗り継ぎが失敗してしまった場合には、歩行速度パラメータをより小さい値に設定する。これは或るバスから別のバスへの乗り継ぎに失敗する原因としては、バスの降車地点から次のバスの乗車地点への徒歩での移動が間に合わなかったことが想定されるためである。
【０１２２】
歩行速度パラメータをより小さい値に設定すれば、徒歩での移動に要する時間（以降、徒歩移動時間）を多めに見積もられるようになり、乗り継ぎの失敗が生じるリスクを低減することができる。なお、歩行速度パラメータの調整量は、適宜設計されれば良い。例えば、パラメータ調整部Ｆｃ９は、歩行速度パラメータを一定値（例えば１０ｍ／分）だけ少なくする態様としてもよいし、現在の設定値に１未満の所定の調整率（例えば０．９）を乗じることで、歩行速度パラメータの値を小さくしてもよい。また、あと何分あれば間に合ったかなどの情報を、ユーザからユーザ側装置４を介して提供してもらい、その結果を踏まえて歩行速度パラメータの具体値を調整してもよい。
【０１２３】
乗り継ぎが失敗したか否かは、乗り換え先に設定されている車両２で用いられている車載器３からの合流失敗メッセージを受信することで判定すればよい。合流失敗メッセージについては別途後述する。
【０１２４】
なお、歩行速度パラメータは、ユーザごとに設定されても良いし、年齢層毎に設定されても良い。また、ユーザが普段着用する靴の種類によって調整されても良い。ヒールの高い靴を着用しているユーザの歩行速度は、運動靴を着用しているユーザの歩行速度よりも小さくなることが想定されるためである。なお、ユーザが着用している靴の種類は、乗り継ぎの失敗が生じた場合に、ユーザに情報提供を求めることで特定されればよい。
【０１２５】
＜経路算出関連処理＞
次に、車両手配センタ６の手配処理部６４が実施する経路算出関連処理について図１１に示すフローチャートを用いて説明する。経路算出関連処理は、ユーザからの要求に対応する移動経路候補の算出及び車両の手配を実施する一連の処理である。図１１に示す経路算出関連処理は例えば広域通信部６１が手配要求メッセージを受信した場合に開始されればよい。
【０１２６】
まずステップＳ１０１では手配要求受付部Ｆｃ２が、手配要求メッセージに含まれている条件情報を抽出してステップＳ１０２に移る。ステップＳ１０２では経路候補算出部Ｆｃ３が、ステップＳ１０１で取得した条件情報と、センタ側運行管理ＤＢ６２に格納されている種々の情報と、に基づいて移動経路候補を複数パターン算出してステップＳ１０３に移る。
【０１２７】
ステップＳ１０３では経路候補通知部Ｆｃ４が、経路候補算出部Ｆｃ３が算出した複数の移動経路候補を示す経路候補データを、本フローの開始トリガとなった手配要求メッセージの送信元に相当するユーザ側装置４（以降、要求元装置）に送信する。
【０１２８】
ステップＳ１０４では車両予約部Ｆｃ６が、要求元装置から、採用経路メッセージが返送されてきたか否かを判定する。要求元装置から採用経路メッセージが返送されてきた場合には、ステップＳ１０４が肯定判定されてステップＳ１０６に移る。一方、一定時間（例えば５分）経過しても採用経路メッセージが返送されてこなかった場合には、ステップＳ１０４が否定判定されてステップＳ１０５に移る。ステップＳ１０５では、ユーザの要求はキャンセルされたと判定し、本フローを終了する。
【０１２９】
ステップＳ１０６では採用経路特定部Ｆｃ５が、受信した採用経路メッセージに基づいて採用経路を特定し、さらに、車両予約部Ｆｃ６が、当該採用経路に対応する車両２の手配を実施してステップＳ１０７に移る。ステップＳ１０７では搭乗者情報配信部Ｆｃ７が、乗車予定者情報をステップＳ１０５で手配した経路構成車両に対応する運行管理サーバ１に送信してステップＳ１０８に移る。ステップＳ１０８では車両予約部Ｆｃ６が手配完了メッセージを要求元装置に返送して本フローを終了する。
【０１３０】
＜乗車報告処理＞
次に、車載器３の車両側制御部３７が実施する乗車報告処理について、図１２に示すフローチャートを用いて説明する。乗車報告処理は、自車両への乗車が予定されているユーザが、自車両に所定の乗車予定地点で乗車したことを車両手配センタ６に報告する処理である。乗車報告処理は、車両の走行用電源（例えばイグニッション電源）がオンとなっている場合に、逐次実施されれば良い。
【０１３１】
まずステップＳ２０１では自車両に搭載されているセンサの検出結果に基づいて、自車両が停車したか否かを判定する。自車両が停車した場合にはステップＳ２０１が肯定判定されてステップＳ２０２に移る。一方、自車両が走行中である場合にはステップＳ２０１が否定判定されてステップＳ２０１に戻る。
【０１３２】
なお、車両が停車しているか否かは、車速センサの出力に基づいて判定してもよいし、シフトポジションに基づいて判定してもよい。例えば、車速が所定の閾値以下である場合に自車両は停車していると判定すればよい。自車両が停車しているか否かの判定方法、換言すれば自車両の停車の検出方法は、周知の方法を用いて実施されれば良い。
【０１３３】
ステップＳ２０２では、ロケータ３３から提供される自車両の現在位置が、ユーザの乗車が予定されている地点（つまり、乗車予定地点）であるか否かを判定する。現在位置が乗車予定地点であるか否かは、車両側記憶部３２に保存されている乗車予定者情報を参照することで判定される。なお、車両側制御部３７は、自車両の現在位置と乗車予定地点との距離が所定の誤差範囲内（例えば１５ｍ以内）である場合に、自車両の現在位置が乗車予定地点であると判定すれば良い。
【０１３４】
自車両の現在位置が乗車予定地点である場合にはステップＳ２０２が肯定判定されてステップＳ２０３に移る。一方、現在位置が乗車予定地点となっていない場合にはステップＳ２０２が否定判定されてステップＳ２０１に戻る。
【０１３５】
ステップＳ２０３では、近距離通信部３４と協働し、近距離通信用アンテナから問い合わせ信号を送信する。そして、タグ情報パケットが返送されてきた場合には、そのタグ情報パケットに示されている、タグＩＤなどのデータをＲＡＭ等に順次保存していく。問い合わせ信号を送信してから所定の待機時間経過した場合には、ステップＳ２０４に移る。
【０１３６】
ステップＳ２０４では、現在位置での乗車が予定されているユーザのタグＩＤを取得できたか否かを判定する。現在位置での乗車が予定されているユーザのタグＩＤを取得できている場合にはステップＳ２０４が肯定判定されてステップＳ２０５に移る。一方、現在位置での乗車が予定されているユーザのタグＩＤを取得できていない場合にはステップＳ２０４が否定判定されてステップＳ２０６に移る。
【０１３７】
ステップＳ２０５では、広域通信部３１と協働し、ステップＳ２０３で取得できたタグＩＤに対応するユーザが予定通り乗車できたことを示す通信パケット（以降、乗車確認メッセージ）を車両手配センタ６に送信して本フローを終了する。乗車確認メッセージには、乗車が確認できたユーザのタグＩＤが含まれていれば良い。
【０１３８】
ステップＳ２０６ではまだ自車両が停車中であるか否かを判定する。まだ自車両が停車している場合にはステップＳ２０６が肯定判定されてステップＳ２０３に戻る。一方、自車両が走行している場合にはステップＳ２０６が否定判定されてステップＳ２０７に移る。
【０１３９】
ステップＳ２０７では乗車エラー処理として、ユーザの乗車が失敗したことを示す通信パケット（以降、合流失敗メッセージ）を車両手配センタ６に送信して本フローを終了する。合流失敗メッセージは、当該地点において乗車する予定だったユーザを指し示す情報として、当該ユーザのタグＩＤが含んでいればよい。なお、ステップＳ２０７での処理は、ユーザと予定通りに合流できなかった場合の処理である。乗車エラー処理の内容は適宜設計されれば良い。
【０１４０】
＜降車報告処理＞
次に、車載器３の車両側制御部３７が実施する降車報告処理について、図１３に示すフローチャートを用いて説明する。降車報告処理は、ユーザの降車が予定されている地点において、降車するべきユーザが降車したか否かを車両手配センタ６に報告する処理である。降車報告処理は、車両の走行用電源（例えばイグニッション電源）がオンとなっている場合に、逐次実施されれば良い。なお、降車報告処理は、乗車報告処理とは独立した処理として逐次実施されれば良い。
【０１４１】
まずステップＳ３０１ではステップＳ２０１と同様にして自車両が停車したか否かを判定する。自車両が停車した場合にはステップＳ３０１が肯定判定されてステップＳ３０２に移る。一方、自車両が走行中である場合にはステップＳ３０１が否定判定されてステップＳ３０１に戻る。
【０１４２】
ステップＳ３０２では、ロケータ３３から提供される自車両の現在位置が、ユーザの降車が予定されている地点（つまり、降車予定地点）であるか否かを判定する。現在位置が降車予定地点であるか否かは、車両側記憶部３２に保存されている乗車予定者情報を参照することで判定される。なお、車両側制御部３７は、自車両の現在位置と降車予定地点との距離が所定の誤差範囲内（例えば１５ｍ以内）である場合に、自車両の現在位置は降車予定地点であると判定すれば良い。
【０１４３】
自車両の現在位置が降車予定地点である場合にはステップＳ３０２が肯定判定されてステップＳ３０３に移る。一方、現在位置が降車予定地点となっていない場合にはステップＳ３０２が否定判定されてステップＳ３０１に戻る。
【０１４４】
ステップＳ３０３では、近距離通信部３４と協働し、近距離通信用アンテナから問い合わせ信号を送信する。そして、タグ情報パケットが返送されてきた場合には、そのタグ情報パケットに示されているタグＩＤなどのデータをＲＡＭ等に順次保存していく。問い合わせ信号を送信してから所定の待機時間経過した場合には、ステップＳ３０４に移る。
【０１４５】
ステップＳ３０４では、現在位置での降車が予定されているユーザのタグＩＤを取得したか否かを判定する。現在位置での降車が予定されているユーザのタグＩＤを取得した場合にはステップＳ３０４が肯定判定されてステップＳ３０６に移る。一方、現在位置での降車が予定されているユーザのタグＩＤを取得できなかった場合にはステップＳ３０４が否定判定されてステップＳ３０５に移る。
【０１４６】
なお、降車が予定されているユーザのタグＩＤを取得したということは、当該ユーザがまだ乗車していることを意味する。したがって、ステップＳ３０３の結果、降車が予定されているユーザのタグＩＤを取得できなくなったということは、ユーザが車両を離脱（つまり降車）したことを意味する。つまり、ステップＳ３０４が否定判定される場合とは、ユーザが降車した場合に相当する。
【０１４７】
ステップＳ３０５では、広域通信部３１と協働し、ステップＳ３０３で取得できたタグＩＤに対応するユーザが予定通り降車できたことを示す通信パケット（以降、降車確認メッセージ）を車両手配センタ６に送信して本フローを終了する。降車確認メッセージには、ユーザＩＤ及びタグＩＤの少なくとも何れか一方が含まれていれば良い。本実施形態では一例として降車確認メッセージには、降車を確認できたユーザのタグＩＤが含まれているものとする。
【０１４８】
ステップＳ３０６では、自車両がまだ停車中であるか否かを判定する。まだ自車両が停車している場合にはステップＳ３０６が肯定判定されてステップＳ３０３に戻る。一方、自車両が走行している場合にはステップＳ３０６が否定判定されてステップＳ３０７に移る。
【０１４９】
ステップＳ３０７では降車エラー処理として、ユーザの降車が失敗したことを示す通信パケット（以降、降車失敗メッセージ）を車両手配センタ６に送信して本フローを終了する。降車失敗メッセージには、現在位置での降車が予定されていたユーザのタグＩＤが含まれているものとする。なお、このステップＳ３０７での処理は、ユーザが予定通りに降車できなかった場合の処理である。降車エラー処理の内容は適宜設計されれば良い。
【０１５０】
なお、車両側制御部３７は、自車両が降車予定地点に到着した場合（ステップＳ３０２  ＹＥＳ）、降車が予定されているユーザについての情報をディスプレイ３５に表示することで、ドライバにユーザの降車の促すアナウンスを実施させても良い。そのような態様によれば、ユーザによる降車忘れを低減することができる。
【０１５１】
また、降車予定地点ではない地点でのユーザの降車を検出した場合には、ユーザが降車地点を間違えている旨を示す画像をディスプレイに表示しても良い。さらに、車両側制御部３７は、降車予定地点ではない地点でのユーザの降車を検出した場合にも降車失敗メッセージを送信するように設計されていてもよい。
【０１５２】
＜移動管理処理＞
次に、車両手配センタ６の移動管理部Ｆｃ８が実施する移動管理処理について図１４に示すフローチャートを用いて説明する。移動管理処理は、ユーザが採用経路に沿って移動できているか否かを管理するとともに、その結果を記録する処理である。
【０１５３】
図１４に示す移動管理処理は移動開始時刻となった場合に開始されればよい。便宜上、本フローの対象とするユーザを、対象ユーザと記載する。移動管理処理は、複数のユーザのそれぞれを対象として実施されれば良い。
【０１５４】
まず、ステップＳ４０１では対象ユーザが乗車する予定の車両（以降、乗車予定車両）２から、対象ユーザが乗車したことを示す乗車確認メッセージが送信されてきたか否かを判定する。具体的には、対象ユーザのタグＩＤを含む乗車確認メッセージを受信できた否かを判定する。
【０１５５】
対象ユーザが乗車したことを示す乗車確認メッセージを受信できた場合にはステップＳ４０１が肯定判定されてステップＳ４０４に移る。一方、対象ユーザが乗車したことを示す乗車確認メッセージを受信していない場合にはステップＳ４０１が否定判定されてステップＳ４０２に移る。
【０１５６】
ステップＳ４０２では対象ユーザのタグＩＤを含む合流失敗メッセージを受信したか否かを判定する。対象ユーザのタグＩＤを含む合流失敗メッセージを受信した場合には、ステップＳ４０２は肯定判定されてステップＳ４０３に移る。一方、対象ユーザのタグＩＤを含む合流失敗メッセージを受信していない場合にはステップＳ４０２は否定判定されてステップＳ４０１に戻る。
【０１５７】
ステップＳ４０３では、エラー処理として、対象ユーザの乗車が失敗したことを記録して本フローを終了する。なお、移動手段手配システム１００は、ステップＳ４０３でのエラー処理として、オペレータが対象ユーザの連絡先として登録されている電話番号に電話をかけるなどの処置を実施するように構成されていても良い。
【０１５８】
ステップＳ４０４では対象ユーザが降車予定地点で降車したことを示す降車確認メッセージが送信されてきたか否かを判定する。具体的には、対象ユーザのタグＩＤを含む降車確認メッセージを受信できた否かを判定する。
【０１５９】
対象ユーザが正常に（つまり間違えること無く）降車できたことを示す降車確認メッセージを受信できている場合にはステップＳ４０４が肯定判定されてステップＳ４０７に移る。一方、対象ユーザが正常に降車できたことを示す降車確認メッセージを受信していない場合にはステップＳ４０４が否定判定されてステップＳ４０５に移る。
【０１６０】
ステップＳ４０５では対象ユーザのタグＩＤを含む降車失敗メッセージを受信したか否かを判定する。対象ユーザのタグＩＤを含む降車失敗メッセージを受信した場合には、ステップＳ４０２が肯定判定されてステップＳ４０６に移る。一方、対象ユーザのタグＩＤを含む降車失敗メッセージを受信していない場合にはステップＳ４０５は否定判定されてステップＳ４０４に戻る。ステップＳ４０６では、エラー処理として、対象ユーザの降車が失敗したことを記録して本フローを終了する。
【０１６１】
ステップＳ４０７では、目的地までの移動経路として、対象ユーザがまだ乗るべき車両２が存在するか否かを判定する。まだ乗るべき車両２が存在する場合にはステップＳ４０７が肯定判定されてステップＳ４０１に移る。一方、ユーザが乗るべき車両２が残っていない場合には、ステップＳ４０７が否定判定されてステップＳ４０８に移る。ステップＳ４０８では、目的地までのユーザの移動のために手配した車両２が、予約内容に沿って（つまり正常に）対象ユーザによって利用されたことを記録して本フローを終了する。
【０１６２】
なお、以上では、合流失敗メッセージを受信することによって、移動管理部Ｆｃ８は対象ユーザの乗車が失敗したことを認識する態様を例示したが、これに限らない。例えば、乗車予定時刻から所定の時間経過しても乗車確認メッセージを受信できなかった場合に、対象ユーザの乗車が失敗したと判定してもよい。
【０１６３】
また、以上では、降車失敗メッセージを受信することによって、移動管理部Ｆｃ８は対象ユーザの降車が失敗したことを検出する態様を例示したが、これに限らない。例えば、降車予定時刻から所定の時間経過しても降車確認メッセージを受信できなかった場合に、ユーザの降車が失敗したと判定してもよい。
【０１６４】
＜本実施形態のまとめ＞
以上の構成によれば、ユーザはユーザ側装置４を操作することで、所定の目的地までの移動を実現する車両２を手配することができる。また、ユーザは、選択肢として、複数種類の車両２を乗り継いで移動するパターンも選択することができるため、出発地から目的地までタクシーだけで移動する場合に比べて交通費を抑制可能な経路を選択できる場合がある。
【０１６５】
また、ユーザの居住地域が、タクシーや路線バスが存在しないエリアであっても、仮にデイケアバスやスクールバスが存在し、かつ、それらが車両２として登録されている場合には、それらを利用して移動することが可能となる。つまり、タクシーや路線バスが存在しないエリアに住む住民に、生活の足としての運送車両を提供することができる。
【０１６６】
図１５は上述した移動手段手配システム１００の作動を説明するための図であって、図１５中に示す領域Ａｒ１〜３は、それぞれ異なる介護機関に属するデイケアバスの運送対応エリアを表している。各介護機関のデイケアバスが車両２として登録されている場合、経路候補算出部Ｆｃ３は、必要に応じてそれらのデイケアバスを組み合わせた移動経路を算出する。その結果、ユーザは複数のデイケアバスを乗り継いで出発地Ｐｓｒｃから目的地Ｐｄｓｔまで移動できるようになる。なお、図１５中の地点Ｐｘ１、Ｐｘ２はデイケアバスを乗り換える地点を表している。
【０１６７】
以上、本発明の実施形態を説明したが、本発明は上述の実施形態に限定されるものではなく、以降で述べる種々の変形例も本発明の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。
【０１６８】
なお、前述の実施形態で述べた部材と同一の機能を有する部材については、同一の符号を付し、その説明を省略する。また、構成の一部のみに言及している場合、他の部分については先に説明した実施形態の構成を適用することができる。
【０１６９】
［変形例１］
手配処理部６４は、ユーザが入力した目的地の履歴から、ユーザの好みを学習し、ユーザの好みに応じた施設を目的地としてユーザに推挙する機能（いわゆるレコメンデーションを行う機能）を備えていても良い。例えば手配処理部６４は、或るショッピングセンター（以降、第１ショッピングセンター）を目的地として設定した回数や割合が多いユーザに対し、第１ショッピングセンターよりもユーザの自宅から近い位置に存在する第２ショッピングセンターを目的地として推挙してもよい。
【０１７０】
また、或る第１医療施設を目的地として設定した回数や割合が多いユーザに対し、第１医療施設よりもユーザの自宅から近い位置に存在する、第１医療施設と同種類の医療施設である第２医療施設を推挙してもよい。ユーザの自宅は、ユーザ側装置４に対するユーザ操作に基づいて登録されれば良い。
【０１７１】
推挙する施設の情報は、例えば、ユーザ側装置４のディスプレイ４３やスピーカ４４に出力すれば良い。例えば経路選択画面や手配完了画面に、推挙する施設の情報が表示すれば良い。
【０１７２】
また、手配処理部６４は、ユーザが目的地に求める内容に応じた施設を推挙する機能を備えていてもよい。ユーザが目的地に求める内容は、ユーザ操作によって登録される態様としても良いし、手配処理部６４が目的地の履歴から推定してもよい。例えば、目的地に求める内容として、他人とのコミュニケーションが設定されているユーザに対しては、公民館やコミュニティセンターなどを提案すれば良い。また、運動を求めるユーザに対しては、運動施設などを提案すれば良い。
【０１７３】
［変形例２］
上述した実施形態では、各運送車両提供者が運行管理サーバ１を備える態様を例示したが、これに限らない。例えば、運送車両提供者の中には、自分自身の車両２の運行管理を車両手配センタ６に委託する運送車両提供者が存在してもよい。換言すれば、車両手配センタ６は、或る運送車両提供者が保有する車両２の運行を管理する機能を備えてあって、運送車両提供者からの依頼に基づいて当該運送車両提供者が保有する車両２の運行を管理するように構成されていても良い。
【０１７４】
そのような態様によれば、運送車両提供者は運行管理サーバ１を備える必要がなくなり、運行管理に要するコストが低減される。すなわち、運送車両提供者にとっては移動手段手配システム１００への参画に対するメリットが大きくなり、移動手段手配システム１００への参画を促すことができる。当然、移動手段手配システム１００に参画する運送車両提供者の数が多いほど、つまり、車両２の種類や数が増えるほど、ユーザが希望する目的地までの移動を実現する経路候補のバリエーションを増やすことができる。経路候補のバリエーションを増やすことで、よりユーザの希望に合致した経路候補を提案できるようになる。
【０１７５】
［変形例３］
ユーザによる乗車予定車両への乗車の失敗等が発生した場合には、予めユーザの保護者として登録されている人物に、乗車の失敗が発生したことを通知するように構成されていても良い。或るユーザの保護者とは、例えば、ユーザが子供である場合にはそのユーザの両親が保護者に該当する。また、ユーザがお年寄りである場合には、その家族が保護者として登録されていれば良い。保護者情報の登録は、ユーザ又は保護者がユーザ側装置４を操作することで実施されれば良い。なお、保護者情報は、ユーザデータとしてユーザ管理ＤＢ６３に保存されれば良い。
【０１７６】
［変形例４］
以上ではスマートフォンをユーザ側装置４として用いる態様を例示したが、これに限らない。ユーザ側装置４は、固定電話などであっても良い。その場合、ユーザは、音声案内に従って番号をプッシュ操作したり、車両手配センタ６がユーザの発話内容を音声認識したりすることによって、条件情報を取得すれば良い。その場合、条件情報を含む音声データや操作ボタンを示す信号が手配要求メッセージに相当する。また、採用経路の選択や、予約内容の確認も音声案内等によって実施されれば良い。
【符号の説明】
【０１７７】
１００  移動手段手配システム、１・１Ａ・１Ｂ・１Ｃ  運行管理サーバ、２  車両、３  車載器、４  ユーザ側装置、５  無線タグ（発信器）、６  車両手配センタ、３２  スケジュール記憶部（車両側記憶部）、３３  ロケータ（現在位置特定部）、３４  近距離通信部（タグ情報受信部）、６１  広域通信部、６２  センタ側運行管理データベース（運行スケジュール記憶部）、６３  ユーザ管理データベース、６４  手配処理部、Ｆｃ１  運行管理情報取得部、Ｆｃ２  手配要求受付部、Ｆｃ３  経路候補算出部、Ｆｃ４  経路候補通知部、Ｆｃ５  採用経路特定部、Ｆｃ６  車両予約部、Ｆｃ７  搭乗者情報配信部、Ｆｃ８  移動管理部、Ｆｃ９  パラメータ調整部
【図１】
0006447551.tif 000002
【図２】
0006447551.tif 000003
【図３】
0006447551.tif 000004
【図４】
0006447551.tif 000005
【図５】
0006447551.tif 000006
【図６】
0006447551.tif 000007
【図７】
0006447551.tif 000008
【図８】
0006447551.tif 000009
【図９】
0006447551.tif 000010
【図１０】
0006447551.tif 000011
【図１１】
0006447551.tif 000012
【図１２】
0006447551.tif 000013
【図１３】
0006447551.tif 000014
【図１４】
0006447551.tif 000015
【図１５】
0006447551.tif 000016