JP2019139687A - 車両制御システム及び車両制御方法 - Google Patents

Abstract

【課題】ユーザと車両に乗車中の他のユーザとを合流させる。【解決手段】複数の車両１００Ａ、１００Ｂと、複数の車両のそれぞれについて、乗車中のユーザＡ、Ｂに関する情報を記憶する記憶部と、複数の車両のうちのいずれかに乗車中のユーザとの合流を要求するマッチング要求を受信する受信部と、記憶部に記憶される情報に基づいて、マッチング要求に合致する第１のユーザＡが乗車中の第１の車両を特定し、第１の車両とマッチング要求の要求元とを合流させるように、第１の車両に対する制御を行う制御部と、を備える車両制御システムである。【選択図】図１

Description

本発明は、車両制御システム及び車両制御方法に関する。

車両内に事務用備品が設置された移動式オフィスが開示されている（例えば、特許文献１）。移動式オフィスでは、車両走行中でも搭乗者は事務作業を行うことができる。

特開平０９−１８３３３４号公報

しかしながら、例えば、移動式オフィス内で事務作業を行うユーザ同士が会って相談したいというニーズが生じる場合がある。

本発明は、上記したような種々の実情に鑑みてなされたものであり、その目的は、車両に乗車中の他のユーザとの合流を可能にする車両制御システム及び車両制御方法を提供することにある。

本発明の態様の一つは、複数の車両と、複数の車両のそれぞれについて、乗車中のユーザに関する情報を記憶する記憶部と、複数の車両のうちのいずれかに乗車中のユーザとの合流を要求するマッチング要求を受信する受信部と、記憶部に記憶される情報に基づいて、マッチング要求に合致する第１のユーザが乗車中の第１の車両を特定し、第１の車両とマッチング要求の要求元とを合流させるように、第１の車両に対する制御を行う制御部と、を備える車両制御システムである。複数の車両のそれぞれは、例えば、有人運転又は無人運転の自動車である。

これによって、マッチング要求の要求元のユーザは、第１のユーザと合流することができる。また、第１の車両に乗車中の第１のユーザにとって、第１の車両に乗車中の時間は空き時間又はすきま時間である可能性が高く、本発明の態様の一つによれば、空き時間を有効に利用することができる。

また、本発明の態様の一つでは、複数の車両のそれぞれは、移動指令に基づいて自律走行可能な車両であり、制御部は、第１の車両に対する制御として、要求元との合流地点を決定し、第１の車両に合流地点への移動指令を送信するようにしてもよい。車両が自律走行可能な車両である場合、例えば、有人運転の車両よりも車両制御システムが制御しやすく、よりマッチング要求の要求元のユーザと第１のユーザとを合流させやすくなる。また、車両が自律走行可能な車両である場合、第１の車両に乗車中の第１のユーザにとって第１の車両に乗車中の時間が空き時間又はすきま時間となる可能性がより高くなり、空き時間を有効に利用することができる。

また、本発明の態様の一つでは、複数の車両のそれぞれは自律走行可能な車両であり、マッチング要求の要求元は、複数の車両のうちの第１の車両以外の車両であって、第２のユーザが乗車中の第２の車両であってもよい。この場合には、制御部は、第２の車両にも合流地点への移動指令を送信する。第１の車両及び第２の車両の双方が合流地点に向かう
ことで、より早く第１のユーザと第２のユーザとを合流させることができる。また、要求元の第２の車両も自律走行可能な車両であるので、第２のユーザにとっても第２の車両に乗車中の時間は空き時間である可能性が高く、第１のユーザ及び第２のユーザ双方にとって空き時間を有効に活用することができる。

また、本発明の態様の一つでは、マッチング要求の要求元は、第２のユーザのユーザ端末であってもよい。これによって、マッチング要求の要求元がユーザ端末であっても、要求元のユーザ（第２のユーザ）と第１のユーザとを合流させることができる。

また、本発明の態様の一つでは、マッチング要求の要求元は、複数の車両うちの第１の車両以外の第２の車両に乗車している第２のユーザのユーザ端末であってもよい。この場合には、制御部は、第２の車両にも合流地点への移動指令を送信するようにしてもよい。これによって、第２のユーザが第２の車両に乗車している場合には、第１の車両と第２の車両との双方が合流地点に向かうので、より早く第１のユーザと第２のユーザとが合流することができる。

また、本発明の態様の一つでは、マッチング要求の要求元は、複数の車両のうちのいずれの車両にも乗車していない第２のユーザのユーザ端末であってもよい。この場合には、例えば、制御部は、複数の車両のうちの第１の車両以外の第２の車両へ、ユーザ端末の所在地への移動指令と、ユーザ端末の所在地における第２のユーザの乗車指令と、ユーザ端末の所在地から合流地点への移動指令とを送信するようにしてもよい。これによって、第２の車両が、第２のユーザの元に向かい、第２のユーザを乗せて合流地点へと向かうので、第２のユーザが車両１００に乗車していない場合でも、より早く第１のユーザと第２のユーザとを合流させることができる。

また、本発明の態様の一つでは、第１の車両及び第２の車両が自律走行可能な車両である場合に、制御部は、第１の車両と第２の車両とが合流地点において合流し、第１のユーザ又は第２のユーザのうちのいずれか一方が、第２の車両又は第１の車両に乗り換えた場合に、第１の車両と第２の車両とのうちユーザが乗車していない車両に、所定の位置への移動指令を送信するようにしてもよい。これによって、ユーザが乗車していない車両は、所定の位置に戻るようになり、車両を管理しやすくなる。

また、本発明の態様の一つでは、制御部は、第１の車両にマッチング要求についての確認要求を通知し、第１の車両から応答が受信された場合に、第１の車両に対する制御を行うようにしてもよい。これによって、第１の車両に乗車中の第１のユーザの状態を考慮して、マッチング要求元のユーザと第１の車両に乗車中の第１のユーザとを合流させるか否かを判定することができる。

なお、本発明の車両制御システムは、一又は複数の、コンピュータ等の処理装置で構成されてもよい。当該車両制御システムが複数の処理装置で構成される場合には、当該車両制御システムの各構成は複数の処理装置に分散して備えられ、それぞれの処理装置が協働して車両制御システムとしての処理を実現する。

本発明を、車両制御方法の側面から捉えることもできる。当該車両制御方法は、複数の車両を制御する制御装置が、複数の車両のそれぞれについて、乗車中のユーザに関する情報を記憶部に記憶し、複数の車両のうちのいずれかに乗車中のユーザとのマッチング要求を受信し、記憶部に記憶される情報に基づいて、マッチング要求に合致する第１のユーザが乗車中の第１の車両を特定し、第１の車両とマッチング要求の要求元とを合流させるように、第１の車両に対する制御を行う。なお、上述までの車両制御システムに関して開示された技術的思想は、技術的な齟齬が生じない範囲で当該車両制御方法にも適用できる。

本発明によれば、ユーザと車両に乗車中の他のユーザとを合流させることができる。

図１は、第１実施形態に係る車両制御システムのシステム構成の一例を示す図である。 図２は、車両のハードウェア構成の一例を示す図である。 図３は、ＥＶパレットに搭載される制御系および制御系に関係する各部のハードウェア構成の一例を示す図である。 図４は、センタサーバのハードウェア構成を例示する図である。 図５は、車両制御システムにおけるセンタサーバと車両との機能構成の一例を示す図である。 図６は、車両管理情報テーブルの一例である。 図７は、センタサーバの運行制御部によるマッチング制御処理のフローチャートの一例である。 図８は、センタサーバの運行制御部による車両返却制御処理のフローチャートの一例である。 図９は、具体例における処理シーケンスの一例である。 図１０は、第２実施形態に係る車両制御システムのシステム構成の一例を示す図である。 図１１は、第２実施形態に係るセンタサーバの運行制御部によるマッチング制御処理のフローチャートの一例である。 図１２は、第２実施形態の変形例に係るセンタサーバの運行制御部によるマッチング制御処理のフローチャートの一例である。

以下、図面に基づいて、本発明の実施の形態を説明する。以下の実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。

＜ＥＶパレットについて＞
本実施形態では、Electric Vehicle（ＥＶ）パレットと呼ばれる自走式の電動車両がネットワーク上のコンピュータシステムと連携して、ユーザに様々な機能あるいはサービスを提供する。本実施形態のＥＶパレット（以下、単にＥＶパレット）は、自動運転および無人運転可能な移動体であり、用途に応じて様々な寸法のものが存在する。例えば、スーツケース代わりに利用可能な小型のものから、人、物を搬送可能な大型のものまで、様々なＥＶパレットが利用可能である。

また、ＥＶパレットは、ＥＶパレットの制御、ＥＶパレットを利用するユーザとのユーザインターフェースの提供、および、ネットワーク上の各種サーバとの情報授受等のための情報処理装置および通信装置を有している。ＥＶパレットは、ネットワーク上の各種サーバと連携して、ＥＶパレット単独で実行可能な処理に加えて、ネットワーク上の各種サーバによって付加される機能およびサービスをユーザに提供する。

＜第１実施形態＞
＜システム概要＞
図１は、第１実施形態に係る車両制御システム１のシステム構成の一例を示す図である。車両制御システム１は、複数の車両１００、複数の車両１００を管理するセンタサーバ５００を含む。車両制御システム１は、センタサーバ５００が２台の車両１００を合流させるマッチングサービスを提供するシステムである。

複数の車両１００のそれぞれは、例えば、無線通信網を介してインターネットに接続し、インターネットを通じて、センタサーバ５００と接続されている。車両１００は、それぞれ、例えば、３Ｇ、ＬＴＥ（Long Term Evolution）、ＬＴＥ−Ａｄｖａｎｃｅｄ等の
移動体通信、ＷｉＦｉ等の無線ＬＡＮの規格に従った無線通信を行う。

車両１００は、例えば、ＥＶパレットである。ＥＶパレットは、人あるいは物品を搬送する自動運転走行および無人運転走行可能な移動体である。ＥＶパレットは、コンピュータ制御によるユーザインターフェースを有し、ユーザからの要求を受け付け、ユーザに反応し、ユーザからの要求に対して所定の処理を実行し、処理結果をユーザに報告する。例えば、ＥＶパレットは、音声、画像、あるいは、コンピュータの入出力機器からユーザの指示を受け付け、処理を実行する。また、ＥＶパレットは、ユーザの画像あるいは音声等からユーザを認識し、ユーザの移動に伴ってユーザに追従する。ただし、ＥＶパレットは、ユーザからの要求のうち、ＥＶパレット単独では処理できない要求については、ユーザからの要求をセンタサーバ５００に通知し、センタサーバ５００と連携して処理を実行する。ＥＶパレット単独では処理できない要求には、例えば、センタサーバ５００上のデータベースからの情報の取得、学習マシンによる認識あるいは推論等を要求されるものが例示される。なお、車両１００は、ＥＶパレットに限定されず、例えば、人が運転を行う貨物用自動車であってもよい。

車両１００は、センタサーバ５００から運行指令を受けて、運行計画を作成し、運行計画に従って目的地まで自律走行を行う。車両１００は、位置情報の取得手段を備えており、所定の周期で、位置情報を取得し、センタサーバ５００に送信する。また、車両１００は、当該車両１００に対して乗車又は降車するユーザからの入力に応じて、ユーザの乗車通知又は降車通知をセンタサーバ５００に送信する。

センタサーバ５００は、車両１００の制御を行う。より具体的には、センタサーバ５００は、車両管理データベースに、車両１００の位置情報、車両１００に乗車中のユーザの情報を保持している。センタサーバ５００は、例えば、ユーザＡが乗車中の車両１００ＡからユーザＢとのマッチング要求を受け付け、ユーザＢが乗車中の車両１００Ｂを車両管理データベースから抽出し、合流地点と時刻とを決定し、車両１００Ａと車両１００Ｂとに運行指令を送信する。

車両１００は、センタサーバ５００からの運行指令を受けて、運行経路を計算して運行を開始し、指定された時刻までに合流地点に向かって移動する。第１実施形態では、車両１００はＥＶパレットであることが想定される。車両１００及びＥＶパレットは、「車両」の一例である。マッチング要求の対象のユーザは、「第１のユーザ」の一例である。マッチング要求の対象のユーザが乗車中の車両１００は、「第１の車両」の一例である。第１実施形態におけるマッチング要求の送信元である車両１００は、「第２の車両」の一例である。第１実施形態におけるマッチング要求の送信元である車両１００に乗車中のユーザは、「第２のユーザ」の一例である。センタサーバ５００は、「制御装置」の一例である。

図２は、車両１００のハードウェア構成の一例を示す図である。図３は、ＥＶパレットに搭載される制御系１０および制御系１０に関係する各部のハードウェア構成の一例を示す図である。図２及び図３は、車両１００としてＥＶパレットが採用される場合の図である。図２及び図３において、車両１００をＥＶパレット１００として説明される。

ＥＶパレット１００は、箱形のボディ１Ｚと、ボディ１Ｚ下部の両側方で進行方向に対して前後に設けられた４つの車輪ＴＲ１からＴＲ４とを有する。４つの車輪ＴＲ１からＴ
Ｒ４は、図示しない駆動軸に連結され、図２及び図３に例示する駆動用モータ１Ｃによって駆動される。また、４つの車輪ＴＲ１からＴＲ４の走行時の進行方向（４つの車輪ＴＲ１からＴＲ４の回転面に平行は方向）は、図２及び図３に例示する操舵用モータ１Ｂによって、ボディ１Ｚに対して相対的に変位し、進行方向が制御される。

図２のように、ＥＶパレット１００のボディ１Ｚの外壁には、ディスプレイ１６−１から１６−５が固定されている。ディスプレイ１６−１から１６−５は、例えば、液晶ディスプレイ、エレクトロルミネッセンスパネル等である。ディスプレイ１６−１から１６−５を個々に区別しないで総称する場合には、ディスプレイ１６と呼ぶ。

いま、図２では、ＥＶパレット１００は、矢印ＡＲ１の方向に進行していると仮定する。したがって、図２の左方向が進行方向であると仮定する。そこで、図２では、ボディ１Ｚの進行方向側の側面をＥＶパレット１００の前面と呼び、進行方向と逆方向の側面をＥＶパレット１００の後面と呼ぶ。また、ボディ１Ｚの進行方向に対して右側の側面を右側面と呼び、左側の側面を左側面と呼ぶ。

図２のように、ＥＶパレット１００は、前面で両側の角部に近い位置に障害物センサ１８−１、１８−２を有し、後面で両側の角部に近い位置に障害物センサ１８−３、１８−４を有する。また、ＥＶパレット１００は、前面、左側面、後面、および右側面にそれぞれ、カメラ１７−１、１７−２、１７−３、１７−４を有している。障害物センサ１８−１等を個々に区別しないで総称する場合には、本実施形態では、障害物センサ１８と呼ぶことにする。また、カメラ１７−１、１７−２、１７−３、１７−４を個々に区別しないで総称する場合には、本実施形態では、カメラ１７と呼ぶことにする。

また、ＥＶパレット１００は、操舵用モータ１Ｂと、駆動用モータ１Ｃと、操舵用モータ１Ｂおよび駆動用モータ１Ｃに電力を供給する二次電池１Ｄを有する。また、ＥＶパレット１００は、車輪の回転角を刻々検出する車輪エンコーダ１９と、車輪の走行方向である操舵角を検出する操舵角エンコーダ１Ａを有する。さらに、ＥＶパレット１００は、制御系１０と、通信部１５と、ＧＰＳ受信部１Ｅと、マイクロフォン１Ｆと、スピーカ１Ｇを有する。なお、図示していないが、二次電池１Ｄは、制御系１０等にも電力を供給する。ただし、操舵用モータ１Ｂおよび駆動用モータ１Ｃに電力を供給する二次電池１Ｄとは別に、制御系１０等に電力を供給する電源を設けてもよい。

制御系１０は、Engine Control Unit（ＥＣＵ）とも呼ばれる。図３のように、制御系
１０は、ＣＰＵ １１と、メモリ１２と、画像処理部１３とインタフェースＩＦ１を有する。インタフェースＩＦ１には、外部記憶装置１４、通信部１５、ディスプレイ１６、タッチパネル付ディスプレイ１６Ａ、カメラ１７、障害物センサ１８、車輪エンコーダ１９、操舵角エンコーダ１Ａ、操舵用モータ１Ｂ、駆動用モータ１Ｃ、ＧＰＳ受信部１Ｅ、マイクロフォン１Ｆ、スピーカ１Ｇ、ＢＬＥ通信部１Ｈ、施解錠装置１５０等が接続される。

障害物センサ１８は、超音波センサ、レーダ等である。障害物センサ１８は、検出対象方向に超音波、電磁波等を発し、反射波を基に検出対象方向での障害物の存在、位置、相対速度等を検出する。

カメラ１７は、Charged-Coupled Devices（ＣＣＤ）、Metal-Oxide-Semiconductor（ＭＯＳ）あるいはComplementary Metal-Oxide-Semiconductor（ＣＭＯＳ）等のイメージセ
ンサによる撮影装置である。カメラ１７は、フレーム周期と呼ばれる所定時間間隔で画像を取得し、制御系１０内の図示しないフレームバッファに格納する。フレーム周期でフレームバッファに格納される画像をフレームデータと呼ぶ。

操舵用モータ１Ｂは、制御系１０からの指示信号にしたがって、車輪の回転面と水平面とが交差する交差線の方向、つまり車輪の回転による進行方向となる角度を制御する。駆動用モータ１Ｃは、制御系１０からの指示信号にしたがって、例えば、車輪ＴＲ１からＴＲ４を駆動し、回転させる。ただし、ただし、駆動用モータ１Ｃは、車輪ＴＲ１からＴＲ４のうち、一対の車輪ＴＲ１、ＴＲ２または他の一対の車輪ＴＲ３、ＴＲ４を駆動してもよい。二次電池１Ｄは、操舵用モータ１Ｂ、駆動用モータ１Ｃ、および制御系１０に接続される部品に電力を供給する。

操舵角エンコーダ１Ａは、車輪の回転に進行方向となる車輪の回転面と水平面とが交差する交差線の方向（または車輪の回転軸の水平面内での角度）を所定の検出時間間隔で検出し、制御系１０の図示しないレジスタに格納する。例えば、図２で進行方向（矢印ＡＲ１方向）に対して、車輪の回転軸が直交する方向を角度の原点が設定される。また、車輪エンコーダ１９は、車輪の回転速度を所定の検出時間間隔で取得し、制御系１０の図示しないレジスタに格納する。

通信部１５は、例えば、携帯電話基地局および携帯電話基地局に接続される公衆通信回線網を通じて、ネットワーク上の各種サーバ等と通信するための通信部である。通信部１５は、所定の無線通信規格に従った無線信号及び無線通信方式で無線通信を行う。

Global Positioning System（ＧＰＳ）受信部１Ｅは、地球の周囲を周回する複数の人
工衛星（Global Positioning Satellite）から時刻信号の電波を受信し、制御系１０の図示しないレジスタに格納する。マイクロフォン１Ｆは、音声を検出して、ディジタル信号に変換し、制御系１０の図示しないレジスタに格納する。スピーカ１Ｇは、制御系１０または図示しない信号処理部に接続されるＤ／Ａ変換器および増幅器により駆動され、音および音声を含む音響を再生する。

制御系１０のＣＰＵ １１は、メモリ１２に実行可能に展開されたコンピュータプログラムを実行し、制御系１０としての処理を実行する。メモリ１２は、ＣＰＵ １１が実行するコンピュータプログラム、ＣＰＵ １１が処理するデータ等を格納する。メモリ１２は、例えば、Dynamic Random Access Memory（ＤＲＡＭ）、Static Random Access Memory（ＳＲＡＭ）、Read Only Memory（ＲＯＭ）等である。画像処理部１３は、ＣＰＵ １
１と連携し、カメラ１７から所定のフレーム周期ごとに得られるフレームバッファのデータを処理する。画像処理部１３は、例えば、ＧＰＵとフレームバッファとなる画像メモリを有する。外部記憶装置３４は、不揮発性の記憶装置であり、例えば、Solid State Drive（ＳＳＤ）、ハードディスクドライブ等である。

例えば、図３のように、制御系１０は、インタフェースＩＦ１を介して、ＥＶパレット１００の各部のセンサから検出信号を取得する。また、制御系１０は、ＧＰＳ受信部１Ｅからの検出信号により、地球上の位置である緯度と経度を計算する。さらに、制御系１０は、外部記憶装置１４に格納される地図情報データベースから地図データを取得し、計算した緯度と経度を地図データの上の位置とを照合し、現在地を決定する。また、制御系１０は、地図データ上で現在地から目的地に至る経路を取得する。また、制御系１０は、障害物センサ１８、カメラ１７等からの信号に基づき、ＥＶパレット１００の周囲の障害物を検知し、障害物を回避するように、進行方向を決定し、操舵角を制御する。

さらに、制御系１０は、画像処理部１３と連携し、カメラ１７から取得される画像をフレームデータごとに処理し、例えば、画像の差分に基づく変化を検知し、障害物を認識する。また、制御系１０は、カメラ１７からの画像の各フレームデータでユーザを認識し、ユーザとの距離を所定値に維持し、ユーザの移動に追従する。また、制御系１０は、カメ
ラ１７からの画像のフレームデータ中で、ユーザのジェスチャを認識し、認識されたジェスチャから得られるユーザの意思に応答する。また、制御系１０は、マイクロフォン１Ｆから得られる音声信号を解析し、音声認識から得られたユーザの意思に応答する。なお、制御系１０は、カメラ１７からの画像のフレームデータおよびマイクロフォン１Ｆから得られる音声データを通信部１５からネットワーク上のセンタサーバ５００に送信してもよい。そして、画像のフレームデータおよび音声データの解析をセンタサーバ５００に分担させてもよい。

さらにまた、制御系１０は、ディスプレイ１６に画像、文字その他の情報を表示する。また、制御系１０は、タッチパネル付ディスプレイ１６Ａへの操作を検出し、ユーザからの指示を受け付ける。また、制御系１０は、タッチパネル付ディスプレイ１６Ａ、カメラ１７、マイクロフォン１Ｆを介したユーザからの指示に対して、ディスプレイ１６、タッチパネル付ディスプレイ１６Ａ、またはスピーカ１Ｇから応答する。

図３では、インタフェースＩＦ１が例示されているが、制御系１０と制御対象との間の信号の授受がインタフェースＩＦ１に限定される訳ではない。すなわち、制御系１０は、インタフェースＩＦ１以外の複数の信号授受経路を有してもよい。また、図３では、制御系１０は、単一のＣＰＵ １１を有している。ただし、ＣＰＵは、単一のプロセッサに限定される訳ではなく、マルチプロセッサ構成であってもよい。また、単一のソケットで接続される単一のＣＰＵがマルチコア構成を有していても良い。上記各部の少なくとも一部の処理は、ＣＰＵ以外のプロセッサ、例えば、Digital Signal Processor（ＤＳＰ）、Graphics Processing Unit（ＧＰＵ）等の専用プロセッサで行われても良い。また、上記各部の少なくとも一部の処理は、集積回路（ＩＣ）、その他のディジタル回路であっても良い。また、上記各部の少なくとも一部にアナログ回路が含まれても良い。

図４は、センタサーバ５００のハードウェア構成を例示する図である。センタサーバ５００は、ＣＰＵ ５１、メモリ５２、インタフェースＩＦ５、外部記憶装置５４、および通信部５５を有する。ＣＰＵ ５１、メモリ５２、インタフェースＩＦ５、および外部記憶装置５４の構成および作用は、図２のＣＰＵ １１、メモリ１２、インタフェースＩＦ１、外部記憶装置１４と同様である。通信部５５は、例えば、ＬＡＮを通じて公衆通信回線網に接続し、公衆通信回線網を通じて、ネットワーク上の各種サーバ等と通信する。ＣＰＵ ５１は、「受信部」、「制御部」の一例である。外部記憶装置５４は、「記憶部」の一例である。

図５は、車両制御システム１におけるセンタサーバ５００と車両１００との機能構成の一例を示す図である。センタサーバ５００は、メモリ５２上のコンピュータプログラムにより、図５に例示された各部として動作する。すなわち、センタサーバ５００は、機能構成要素として、要求受付部５０１、位置情報管理部５０２、運行制御部５０３、車両管理データベース（ＤＢ）５０４を備える。

要求受付部５０１は、例えば、車両１００からユーザとのマッチング要求を受け付ける。マッチング要求は、対象のユーザとの合流の要求である。マッチング要求には、例えば、対象となるユーザの識別情報が含まれている。なお、マッチング要求の対象となるユーザの指定方法は、例えば、車両１００のタッチパネル付ディスプレイ１６Ａにユーザの識別情報を直接入力する方法であっても、車両１００のタッチパネル付ディスプレイ１６Ａに表示されたユーザの一覧から選択する方法であってもよい。なお、センタサーバ５００が、マッチングサービスの契約を結んでいる複数の組織によって用いられる場合には、マッチング要求の対象として同じ組織に所属するユーザを指定することはできるが、異なる組織に属するユーザを指定することはできない。

したがって、マッチング要求の対象のユーザをユーザの一覧から選択する方法の場合には、一覧に表示されるユーザは、例えば、マッチング要求を行うユーザと同じ組織に属するユーザのような、ユーザ間での情報共有が認められているユーザであるとする。ただし、マッチング要求の対象のユーザの指定方法は、これらに限定されない。要求受付部は、「受信部」の一例である。

位置情報管理部５０２は、例えば、各車両１００から所定の周期で送信される位置情報を受信し、後述の車両管理ＤＢ ５０４に登録する。

運行制御部５０３は、例えば、マッチング要求が受け付けられた場合に、マッチング要求の対象のユーザが乗車中の車両１００を特定する。運行制御部５０３は、要求元の車両１００とマッチング要求の対象の車両１００との合流地点及び合流予定時刻を決定し、合流地点及び合流予定時刻を含む運行指令を、要求元の車両１００とマッチング要求の対象の車両１００とに送信する。運行制御部５０３の処理の詳細は後述される。運行制御部５０３は、「制御部」の一例である。

車両管理ＤＢ ５０４は、例えば、センタサーバ５００の外部記憶装置５４内に作成される。車両管理ＤＢ ５０４は、例えば、車両制御システム１内の各車両１００に関する情報を保持する車両管理情報テーブルを格納している。車両管理情報テーブルの詳細は後述される。車両管理ＤＢ ５０４は、「記憶部」の一例である。

センタサーバ５００の各機能構成要素のいずれか、又はその処理の一部は、ネットワークに接続される他のコンピュータにより実行されてもよい。また、センタサーバ５００で実行される一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。

次に、車両１００は、メモリ上のコンピュータプログラムにより、図５に例示された各部として動作する。車両１００は、例えば、機能構成要素として、走行制御部１０１、運行計画制御部１０２、環境検出部１０３、入出力制御部１０４、送受信部１０５、位置情報取得部１０６を備える。

送受信部１０５は、センタサーバ５００とのインタフェースである。送受信部１０５は、例えば、他の機能構成要素から入力されたデータを通信部１５を通じてセンタサーバ５００に送信したり、通信部１５を通じてセンタサーバ５００からデータを受信し所定の機能構成要素に出力したりする。

入出力制御部１０４は、例えば、車両１００に対するユーザからの操作入力を受け付け、操作入力に応じて要求や通知を作成する。ユーザからの操作入力を受け付ける手段には、例えば、タッチパネル付ディスプレイ１６Ａ、ハードウェアスイッチ（図示せず）、ＩＣカードリーダ（図示せず）である。例えば、入出力制御部１０４は、タッチパネル付ディスプレイ１６Ａに操作画面を出力する。タッチパネル付ディスプレイ１６Ａに表示される操作画面には、例えば、マッチング要求の対象のユーザの情報の入力欄又は一覧、マッチング要求の対象のユーザとの合流完了を入力するためのアイコン、車両１００の使用終了を入力するためのアイコン等のそれぞれを含む画面がある。入出力制御部１０４は、例えば、タッチパネル付ディスプレイ１６Ａに対してユーザによって行われた操作に基づいて、マッチング要求、マッチングサービス完了通知、車両１００の使用終了の通知等を生成する。

また、例えば、各ユーザはユーザの識別情報を記録するＩＣカードを保持している。ユーザは、車両１００に対して乗車又は降車する際には、車両１００に設置されたＩＣカー
ドリーダにＩＣカードを近づけ、ユーザの識別情報をＩＣカードリーダに読み取らせる。入出力制御部１０４は、例えば、ＩＣカードリーダからユーザの識別情報の入力を受け、当該ユーザの識別情報を含む乗車通知又は降車通知を生成する。

例えば、マッチング要求、マッチングサービスの完了の通知、車両１００の使用終了の通知、乗車通知、降車通知は、入出力制御部１０４から送受信部１０５に出力され、通信部１５を通じてセンタサーバ５００に送信される。なお、車両１００に乗車するユーザが行う操作は、上述のものに限られない。例えば、音声によって操作が行われてもよい。

位置情報取得部１０６は、例えば、ＧＰＳ受信部１Ｅ等によって取得される車両１００の位置情報を、所定の周期で取得し、センタサーバ５００に送信する。車両１００の位置情報は、例えば、緯度、経度である。または、車両１００の位置情報は、例えば、住所であってもよい。また、位置情報取得部１０６によって取得される車両１００の位置情報は、例えば、運行計画制御部１０２、走行制御部１０１にも出力される。

運行計画制御部１０２は、センタサーバ５００からの運行指令を受信する。運行計画制御部１０２は、運行指令と、位置情報取得部１０６により得られた自車両の位置情報とに基づいて、車両１００が進むべき経路を算出し、運行計画を生成する。運行計画には、このように算出された車両１００が走行する経路に関するデータと、経路の一部または全部において車両１００が行うべき処理を規定したデータとを含む。運行計画に含まれるデータの例として、例えば、以下の（１）、（２）のようなものが挙げられる。

（１）自車両が走行する経路を道路リンクの集合によって表したデータ
自車両が走行する経路は、例えば、記憶された地図データを参照し、与えられた出発地、経由地、及び、目的地に基づいて自動的に生成されてもよい。なお、自車両が走行するルート算出は、車両１００内ではなく、外部装置（例えば、センタサーバ５００）の処理に頼ってもよい。この場合、センタサーバ５００は、車両１００からその自車両位置を取得し、当該車両１００が進むべき経路を算出するとともに、その算出した経路データを、上記の運行指令に含む。

（２）経路上の地点において自車両が行うべき処理を表したデータ
自車両が行うべき処理には、例えば、「ユーザを乗降させる」、「荷物を搭載する」といったものがあるが、これらに限られない。運行計画制御部１０２が生成した運行計画は、後述する走行制御部１０１へ送信される。

環境検出部１０３は、車両１００に搭載される各種センサによって取得されたデータに基づいて、自律走行に用いられる車両１００の周囲の環境情報を検出する。環境検出部１０３の検出の対象は、例えば、車線の数や位置、自車両の周囲に存在する車両の数や位置、自車両の周囲に存在する障害物（例えば歩行者、自転車、構造物、建築物など）の数や位置、道路の構造、道路標識などの情報であるが、これらに限られない。自律的な走行を行うために用いられるものであれば、検出の対象はどのようなものであってもよい。例えば、センサがステレオカメラである場合には、それにより撮像された画像データを画像処理することで車両１００の周囲の物体検出が行われる。また、環境検出部１０３は、単に車両１００の周囲の物体を検出するだけではなく、検出した物体をトラッキングしてもよい。トラッキングとは、例えば、検出した対象物を継続して検出し続けることである。例えば、１ステップ前に検出した物体の座標と、現在の物体の座標との差分から、当該物体の相対速度を求めることができる。環境検出部１０３が検出した、車両１００の周囲環境に関するデータは、後述する走行制御部１０１へ出力される。

走行制御部１０１は、例えば、運行計画制御部１０２が生成した運行計画と、環境検出
部１０３が生成した車両１００の周囲環境に関するデータ、位置情報取得部１０６が取得した自車両の位置情報に基づいて、自車両の自律的な走行を制御するための制御指令を生成する。例えば、走行制御部１０１は、運行計画制御部１０２から走行開始指令が入力されると、所定の経路に沿って走行し、且つ、自車両を中心とする所定の安全領域内に障害物が進入しないように自車両を走行させるべく制御指令を生成する。生成された制御指令は、駆動用モータ１Ｃへ送信される。車両を自律走行させるための制御指令の生成方法については、公知の方法を採用することができる。

図６は、車両管理情報テーブルの一例である。車両管理情報テーブルは、センタサーバ５００の車両管理ＤＢ ５０４に格納されている。車両管理情報テーブルは、車両制御システム１内の車両１００に関する車両管理情報を保持するテーブルである。車両管理情報テーブルには、車両管理情報として、例えば、車両ＩＤ、初期位置、現在位置、サービス状態、サービスＩＤ、乗車中ユーザＩＤのフィールドが含まれている。

車両ＩＤフィールドには、車両１００の識別情報が入力される。車両１００の識別情報は、例えば、車両制御システム１において各車両１００に割り振られた識別情報であってもよいし、車両１００のナンバープレートに刻印されたナンバーであってもよい。

初期位置フィールドには、車両１００の初期位置の位置情報が入力される。車両１００は、例えば、サービスが完了し、他にサービスが割り当てられていない場合には、初期位置に戻るように制御される。車両ＩＤフィールドと初期位置フィールドには、車両管理情報テーブルの初期状態から予め値が入力されている。

現在位置フィールドには、車両１００から所定の周期で受信される、車両１００の現在位置の位置情報が入力される。現在位置フィールドは、例えば、位置情報管理部５０２によって車両１００からの位置情報が受信される度に更新される。

サービス状態フィールドには、車両１００のサービス状態を示す値が入力される。第１実施形態では、車両１００のサービス状態を示す値として、「非サービス中」、「サービス中」のいずれかが入力される。サービス状態フィールドの初期値は、例えば、「非サービス中」である。サービス状態フィールドは、例えば、運行制御部５０３によって更新される。

サービスＩＤフィールドには、車両１００に割り当てられているサービスの識別情報が入力される。サービスの識別情報は、例えば、センタサーバ５００の要求受付部５０１によって付与される。サービスＩＤフィールドは、サービス状態フィールドが「サービス中」である場合に、割り当てられているサービスの識別情報が入力された状態であり、「非サービス中」である場合には空となる。サービスＩＤフィールドは、例えば、運行制御部５０３によって更新される。なお、車両１００が用いられるサービスは、マッチングサービスの他にも存在し、車両１００はサービスの内容によっては並行して複数のサービスを実行することも可能である。そのため、車両１００が実行しているサービスが複数である場合には、サービスＩＤフィールドには複数のサービスの識別情報が入力される。サービスＩＤフィールドは、例えば、運行制御部５０３によって更新される。

乗車中ユーザＩＤフィールドには、車両１００に乗車中のユーザの識別情報が入力される。車両１００に乗車中のユーザ情報は、例えば、車両１００からの乗車通知によって通知される。乗車中ユーザＩＤフィールドは、例えば、当該車両１００について乗車通知又は降車通知が受信される度に運行制御部５０３によって更新される。

＜処理の流れ＞
図７は、センタサーバ５００の運行制御部５０３によるマッチング制御処理のフローチャートの一例である。図７に示される処理は、例えば、所定の周期で繰り返し実行される。図７に示される処理の実行主体は、センタサーバ５００のＣＰＵ ５１であるが、便宜上、機能構成要素である運行制御部５０３を主体として説明する。なお、図７以降のフローチャートの説明についても同様とする。

Ｓ１０１では、運行制御部５０３は、マッチング要求が受信されたか否かを判定する。マッチング要求が受信された場合には（Ｓ１０１：ＹＥＳ）、処理がＳ１０２に進む。マッチング要求が受信されていない場合にが（Ｓ１０１：ＮＯ）、図７に示される処理が終了する。

Ｓ１０２では、運行制御部５０３は、車両管理情報テーブルとマッチング要求とともに受信される対象のユーザの識別情報とから、対象のユーザが乗車中の車両１００があるか否かを判定する。対象のユーザが乗車中の車両１００がある場合には（Ｓ１０２：ＹＥＳ）、処理がＳ１０３に進む。対象のユーザがいずれの車両１００に乗車中でない場合には（Ｓ１０２：ＮＯ）、処理がＳ１０９に進む。

Ｓ１０３では、運行制御部５０３は、Ｓ１０２において特定された対象のユーザが乗車中の車両１００に、マッチング確認要求を送信する。マッチング確認要求は、対象のユーザに、要求元のユーザとの合流の了解を確認するための要求である。マッチング確認要求とともに、例えば、マッチング要求の要求元のユーザの識別情報も送信される。以降、対象のユーザが乗車中の車両１００を、マッチング要求の対象車両、又は、単に、対象車両、と称する。

マッチング要求の対象車両では、マッチング確認要求が受信されると、例えば、タッチパネル付ディスプレイ１６Ａに、要求元のユーザからのマッチング確認要求のメッセージと、ＯＫ又はＮＧ応答のアイコンが表示される。マッチング要求の対象車両に乗車中の対象のユーザがＯＫまたはＮＧのアイコンを選択することで、センタサーバ５００にＯＫ応答又はＮＧ応答が送信される。

Ｓ１０４では、運行制御部５０３は、対象車両からＯＫ応答を受信したか否かを判定する。対象車両からＯＫ応答が受信された場合は（Ｓ１０４：ＹＥＳ）、処理がＳ１０５に進む。対象車両からＯＫ応答が受信されない場合には（Ｓ１０４：ＮＯ）、すなわち、対象車両からＮＧ応答が受信された場合、所定の時間が経過してもＯＫ応答もＮＧ応答も受信されない場合には、処理がＳ１０９に進む。

Ｓ１０５では、運行制御部５０３は、合流場所と合流予定時刻とを決定する。合流場所と合流予定時刻との決定方法は特定のものに限定されず、公知のいずれの方法が用いられてもよい。例えば、合流場所は、要求元の車両１００の現在位置と対象車両の現在位置との中間点に決定されてもよい。または、合流場所は、要求元の車両１００又は対象車両のいずれかが、他の移動サービスを実行中は、当該他の移動サービスの目的地の位置情報も考慮して決定されてもよい。各車両１００の現在位置は、車両管理情報テーブルに格納されている。また、合流予定時刻は、例えば、移動速度を所定の速度とみなし、要求元の車両１００又は対象車両の現在位置から合流地点までの距離と移動速度とから、要求元の車両１００又は対象車両の合流地点の到着予定時刻を算出し、どちらか遅い方の時刻に許容時間を加算した値に決定される。

Ｓ１０６では、運行制御部５０３は、要求元の車両１００と対象車両とに、運行指令を送信する。Ｓ１０６において送信される運行指令には、例えば、Ｓ１０５において求められた合流地点への合流予定時刻までの移動指令と、合流地点において対象車両又は要求元
のユーザとの合流指令とが含まれている。また、Ｓ１０６では、運行制御部５０３は、車両管理情報テーブルにおける要求元の車両１００と対象車両とのサービス状態フィールドを「サービス中」に更新し、サービスＩＤフィールドに、当該マッチングサービスの識別情報を入力する。

Ｓ１０７では、運行制御部５０３は、要求元の車両１００及び対象車両との両方からマッチング完了通知が受信されたか否かを判定する。マッチング完了通知は、要求元の車両１００と対象車両１００とが合流したことを示す通知であり、例えば、ユーザが車両１００に入力することで車両１００からセンタサーバ５００へ送信される。要求元の車両１００及び対象車両との両方からマッチング完了通知が受信された場合には（Ｓ１０７：ＹＥＳ）、処理がＳ１０８に進む。要求元の車両１００及び対象車両との両方からマッチング完了通知が受信されていない場合には（Ｓ１０７：ＮＯ）、待機状態となる。

Ｓ１０８では、運行制御部５０３は、マッチングサービスを終了させる。また、Ｓ１０８では、運行制御部５０３は、車両管理情報テーブルにおける要求元の車両１００と対象車両とのサービスＩＤフィールドから当該マッチングサービスの識別情報を削除し、サービスＩＤフィールドが空となる場合にはサービス状態フィールドを「非サービス中」に更新する。その後、図７に示される処理が終了する。

Ｓ１０９では、運行制御部５０３は、Ｓ１０２において対象のユーザがいずれの車両１００に乗車中でない、又はＳ１０４において対象車両からＯＫ応答が受信されないので、要求元の車両１００に、マッチングできないことを示すマッチング不可通知を送信する。マッチング不可通知には、マッチングできない理由が含まれていてもよい、その後、図７に示される処理が終了する。

図８は、センタサーバ５００の運行制御部５０３による車両返却制御処理のフローチャートの一例である。車両返却制御処理は、車両１００が非サービス状態となった場合に、初期位置に戻るように制御する処理である。図８に示される処理は、例えば、所定の周期で繰り返し実行される。

Ｓ２０１では、運行制御部５０３は、車両使用終了通知が受信されたか否かを判定する。車両使用終了通知は、ユーザによる車両１００の使用の終了を示す通知であって、例えば、車両１００にユーザによって入力される。より具体的には、車両使用終了通知は、例えば、車両１００に乗車していたユーザが車両１００から降車する場合に車両１００に入力される。車両使用終了通知が受信された場合には（Ｓ２０１：ＹＥＳ）、処理がＳ２０２に進む。車両使用終了通知が受信されていない場合にが（Ｓ２０１：ＮＯ）、図８に示される処理が終了する。

Ｓ２０２では、運行制御部５０３は、車両管理情報テーブルにおいて、当該車両１００のサービス状態フィールドの値が「非サービス中」であるか否かを判定する。当該車両１００のサービス状態フィールドの値が「非サービス中」である場合には（Ｓ２０２：ＹＥＳ）、処理がＳ２０３に進む。当該車両１００のサービス状態フィールドの値が「非サービス中」でない場合には（Ｓ２０２：ＮＯ）、図８に示される処理が終了する。

Ｓ２０３では、運行制御部５０３は、車両管理情報テーブルにおいて、当該車両１００の乗車中ユーザＩＤフィールドが空であるか否か、すなわち、当該車両１００に乗車中ユーザがあるか否かを判定する。当該車両１００に乗車中ユーザがある場合には（Ｓ２０３：ＹＥＳ）、図８に示される処理が終了する。当該車両１００に乗車中ユーザがいない場合には（Ｓ２０３：ＮＯ）、処理がＳ２０４に進む。

Ｓ２０４では、運行制御部５０３は、車両管理情報テーブルから、当該車両１００の初期位置を取得する。Ｓ２０５では、運行制御部５０３は、通知元の車両１００への運行指令を生成する。Ｓ２０５において生成される運行指令には、例えば、Ｓ２０４において取得された当該車両１００の初期位置への移動指令が含まれている。Ｓ３０６では、運行制御部５０３は、Ｓ２０５において生成した運行指令を通知元の車両１００へ送信する。その後、図８に示される処理が終了する。

＜具体例＞
図９は、具体例における処理シーケンスの一例である。具体例では、車両＃ＡにはユーザＡが乗車しており、車両＃ＢにはユーザＢが乗車していることを前提とする。また、ユーザＡとユーザＢとは、同じ組織に属しており、両者が属する組織が車両制御システム１によって提供されるサービスに契約している。そのため、ユーザＡとユーザＢとは車両１００を利用可能であり、また、互いの車両１００の利用状況を参照可能とする。また、車両＃Ａ及び車両＃Ｂは、いずれのサービスも実行中でないことを想定する。

Ｓ５０１では、車両＃Ａは、ユーザＡからの入力によって、ユーザＢとのマッチング要求をセンタサーバ５００へ送信し、センタサーバ５００は車両＃Ａからのマッチング要求を受信する（図７、Ｓ１０１：ＹＥＳ）。例えば、車両＃Ａのタッチパネル付ディスプレイ１６Ａに、ユーザＡ及びユーザＢが属する組織に属するユーザの識別情報のリストが表示され、ユーザＡは当該リストの中からマッチング要求の対象となるユーザＢの識別情報を選択することで、ユーザＢとのマッチング要求が車両＃Ａからセンタサーバ５００へ送信される。

Ｓ５０２では、センタサーバ５００は、マッチング要求の対象車両として、マッチング要求の対象のユーザであるユーザＢが乗車中の車両＃Ｂと決定する（図７、Ｓ１０２：ＹＥＳ）。Ｓ５０３では、センタサーバ５００は、車両＃Ｂへマッチング確認要求を送信する（図７、Ｓ１０３）。Ｓ５０４では、ユーザＢが車両＃ＢにＯＫ応答を入力し、車両＃Ｂはセンタサーバ５００へＯＫ応答を送信し、センタサーバ５００は車両＃ＢからＯＫ応答を受信する（図７、Ｓ１０４：ＹＥＳ）。

Ｓ５０５では、センタサーバ５００は、車両＃Ａと車両＃Ｂとの合流地点及び合流予定時刻を決定する（図７、Ｓ１０５）。本具体例では、合流地点として地点Ａが決定されたとする。Ｓ５０６では、センタサーバ５００は、運行指令を生成し、車両＃Ａと車両＃Ｂとに送信する（図７、Ｓ１０６）。Ｓ５０６において車両＃Ａ及び車両＃Ｂに送信される運行指令は、例えば、合流地点である地点Ａへの合流予定時刻までの移動指令と、地点Ａにおける車両＃Ｂ又は車両＃Ａとの合流指令を含む。

Ｓ５１１／Ｓ５２１では、車両＃Ａ／車両＃Ｂは、センタサーバ５００からの運行指令を受信し、運行計画を生成する。Ｓ５１１／Ｓ５２１において作成される運行計画には、例えば、合流地点Ａまでの経路、合流地点Ａにおいて車両＃Ｂ／車両＃Ａと合流すること、等が含まれている。Ｓ５１２／Ｓ５２２では、車両＃Ａ／車両＃Ｂは、作成した運行計画に従って運行を開始する。Ｓ５１３／Ｓ５２３では、車両＃Ａ／車両＃Ｂは、合流地点Ａに到着し、車両＃Ｂ／車両＃Ａと合流する。

Ｓ５３１では、ユーザＡが車両＃Ａから車両＃Ｂに移動し、車両＃Ａの使用が終了したとする。なお、ユーザＡは車両＃Ａから降車する際に、車両＃Ａの使用終了と車両＃Ｂとの合流によるマッチングサービスの完了とを、例えば、車両＃Ａのタッチパネル付ディスプレイ１６Ａに入力する。また、ユーザＡは、例えば、車両＃Ａに備えられているＩＣカードリーダに自身が保持するＩＣカードを近づけて自身のユーザの識別情報を読み取らせ、降車を記録させる。ユーザＡは、例えば、次に乗車した車両＃Ｂにおいても、同様のこ
とを行い、乗車を記録させる。

Ｓ５３２では、車両＃Ａは、センタサーバ５００へ、マッチングサービスの完了通知と、車両使用終了通知とを送信し、センタサーバ５００は、これらを受信する（図８、Ｓ２０１：ＹＥＳ）。また、図示は省略されているが、ユーザＡの降車通知も車両＃Ａからセンタサーバ５００へ送信される。Ｓ５３３では、車両＃Ｂは、センタサーバ５００へ、マッチングサービスの完了通知とユーザＡの乗車通知とを送信し、センタサーバ５００はこれらを受信する（図７、Ｓ１０８）。

なお、例えば、ユーザＢは、車両＃Ａとの合流によるマッチングサービスの完了を、例えば、車両＃Ｂのタッチパネル付ディスプレイ１６Ａに入力する。車両＃Ｂは、ユーザＢからの入力とユーザＡの乗車記録を受けて、マッチングサービスの完了通知とユーザＡの乗車通知とを作成する。

また、センタサーバ５００は、車両＃ＡからユーザＡの降車通知を受信すると、例えば、車両管理情報テーブルの車両＃Ａの乗車中ユーザＩＤフィールドからユーザＡの識別情報を削除する。センタサーバ５００は、車両＃ＢからユーザＡの乗車通知を受信すると、例えば、車両管理情報テーブルの車両＃Ｂの乗車中ユーザＩＤフィールドにユーザＡの識別情報を追加する。また、センタサーバ５００は、車両＃Ａと車両＃Ｂとからマッチングサービスの完了通知を受信すると（図７、Ｓ１０８）、車両管理情報テーブルの車両＃Ａ及び車両＃Ｂのサービス状態フィールドを「非サービス中」に更新する。ただし、車両＃ＢにはユーザＡとユーザＢとが引き続き乗車しており、いずれかのユーザから新たな移動サービスの要求が入力されると、車両＃Ｂは再度「サービス中」となる。

Ｓ５４１では、センタサーバ５００は、車両使用終了通知を受信した車両＃Ａへの、初期位置への移動指令を含む運行指令を生成する（図８、Ｓ２０５）。Ｓ５４２では、センタサーバ５００は、車両＃Ａへ運行指令を送信する（図８、Ｓ２０６）。車両＃Ａは、センタサーバ５００から運行指令を受信すると、車両＃Ａの初期位置への運行を開始し、車両＃Ａは初期位置に戻ることとなる。

＜第１実施形態の作用効果＞
第１実施形態では、車両１００に乗車中のユーザが、他の車両１００に乗車中の他のユーザと合流することができる。車両１００は自律走行車両であって、例えば、車両１００に乗車中のユーザは、所定の目的地へ移動中である可能性が高い。したがって、車両１００のユーザにとって、車両１００に乗車中の時間は空き時間である可能性が高く、比較的会いやすい状態にある。したがって、車両１００に乗車中のユーザ同士が合流できることによって、移動等のすきま時間を有効に使用することができるようになる。

また、例えば、２台の車両１００同士の合流地点を各車両１００の現在地点の間のいずれかの地点（例えば、中間地点）等に設定することで、より迅速に合流することができる。また、センタサーバ５００は、合流予定時刻を決定し、運行指令の一部として各車両１００に通知するので、各車両１００に乗車しているユーザは、両者が合流する予定時刻を知ることができる。

また、マッチング要求対象の車両１００に対して、マッチング要求確認を送信して、マッチング要求の対象のユーザに対して、要求元のユーザとの合流について確認することで、マッチング要求の対象のユーザの状態に応じて、合流するか否かを決定することができる。

また、第１実施形態では、マッチング要求の要求元の車両１００又は対象の車両１００
のいずれか一方のユーザが他方の車両１００に移動した場合には、ユーザが乗車していない車両１００は、初期位置に戻るように制御される。これによって、車両１００はサービスが終了すると予め決められた初期位置に戻るので、車両１００の管理がしやすくなる。

＜第２実施形態＞
図１０は、第２実施形態に係る車両制御システム１Ｘのシステム構成の一例を示す図である。第２実施形態に係る車両制御システム１Ｘは、ユーザ端末２００を含む。第２実施形態では、車両１００に乗車中のユーザに対するマッチング要求がユーザ端末２００からセンタサーバ５００へ送信される。ユーザ端末２００から送信されるマッチング要求には、対象のユーザの識別情報と、当該ユーザ端末２００の位置情報が含まれている。

センタサーバ５００の処理は、第１実施形態とほぼ同様である。具体的には、センタサーバ５００は、ユーザ端末２００からマッチング要求を受信すると、マッチング要求の対象のユーザが乗車中の車両１００を特定し、当該車両１００にマッチング確認要求を送信する。センタサーバ５００は、マッチング要求の対象の車両１００からＯＫ応答を受信すると、合流地点を決定して、マッチング要求の対象の車両１００へ合流地点への移動指令を含む運行指令を送信する。

要求元のユーザとマッチング要求の対象の車両１００との合流地点は、例えば、要求元のユーザ端末２００の現在位置であってもよいし、要求元のユーザ端末２００の現在位置とマッチング要求の対象の車両１００の現在位置とに基づいて決定されてもよい。合流地点に応じて、要求元のユーザ端末２００にも合流地点への移動指令が送信されてもよい。

ユーザ端末２００は、例えば、スマートフォン、タブレット端末等である。ユーザ端末２００には、例えば、マッチングサービスを利用するためのアプリケーションプログラムがインストールされており、当該アプリケーションプログラムの実行を通じて、マッチング要求を送信可能となる。

ユーザ端末２００は、例えば、ユーザからの入力にしたがって、センタサーバ５００へマッチング要求、マッチングサービスの完了通知等を送信する。第２実施形態におけるユーザ端末２００は、「第２のユーザのユーザ端末」の一例である。

図１１は、第２実施形態に係るセンタサーバ５００の運行制御部５０３によるマッチング制御処理のフローチャートの一例である。図１１に示されるフローチャートでは、図７に示される第１実施形態におけるマッチング制御処理と同じ処理には同じ符号が付されている。図１１に示される処理も、所定の周期で繰り返し実行される。

Ｓ１０１からＳ１０４の処理は、図７において説明された通りである。ただし、図１１において、マッチング要求の送信元は、ユーザ端末２００である。すなわち、運行制御部５０３は、ユーザ端末２００からマッチング要求を受信し（Ｓ１０１：ＹＥＳ）、マッチング要求の対象のユーザが乗車中の対象車両を特定し（Ｓ１０２：ＹＥＳ）、対象車両にマッチング確認要求を送信し（Ｓ１０３）、対象車両からＯＫ応答を受信する（Ｓ１０４：ＹＥＳ）。なお、マッチング要求の対象のユーザがいずれの車両１００にも乗車していない場合（Ｓ１０２：ＮＯ）、対象車両からＮＧ応答を受信した場合（Ｓ１０４：ＮＯ）には、運行制御部５０３は、要求元のユーザ端末２００のマッチング不可通知を送信する（Ｓ１０９）点も第１実施形態と同様である。

Ｓ２０１では、運行制御部５０３は、例えば、車両管理情報テーブルを参照し、要求元のユーザ端末２００のユーザはいずれかの車両１００に乗車中であるか否かを判定する。要求元のユーザ端末２００のユーザがいずれかの車両１００に乗車中である場合には（Ｓ
２０１：ＹＥＳ）、処理がＳ１０５に進み、図７のＳ１０５からＳ１０８と同様の処理が、要求元のユーザが乗車中の車両１００と対象車両とに対して行われる。すなわち、運行制御部５０３は、要求元のユーザが乗車中の車両１００と対象車両との現在位置に基づいて、合流地点と合流予定時刻とを決定し（Ｓ１０５）、両車両１００に運行指令を送信し（Ｓ１０６）、両車両１００又は要求元のユーザ端末２００と対象車両とからマッチングサービスの完了通知を受信すると（Ｓ１０７：ＹＥＳ）、サービスを終了させる（Ｓ１０８）。

要求元のユーザ端末２００のユーザがいずれの車両１００にも乗車中でない場合には（Ｓ２０１：ＮＯ）、処理がＳ２０２に進む。Ｓ２０２では、運行制御部５０３は、合流地点を要求元のユーザ端末２００の現在位置に設定する。Ｓ２０３では、運行制御部５０３は、対象車両に運行指令を送信する。その後は処理がＳ１０７に進み、運行制御部５０３は、要求元のユーザ端末２００と対象車両とからマッチングサービスの完了通知を受信すると（Ｓ１０７：ＹＥＳ）、サービスを終了させる（Ｓ１０８）。なお、合流地点は、例えば、要求元のユーザ端末２００の所在地に限定されず、要求元のユーザ端末２００の現在位置とマッチング要求の対象の車両１００の現在位置との間のいずれかの地点であってもよい。

第２実施形態によれば、車両１００に乗車していないユーザであっても、車両１００に乗車中のユーザと合流するマッチングサービスを利用することができる。

＜第２実施形態の変形例＞
第２実施形態では、要求元のユーザ端末２００のユーザが車両１００に乗車していない場合には、例えば、マッチング要求の対象の車両がユーザ端末２００の所在地の方に移動して、要求元のユーザとマッチング要求の対象のユーザとを合流させる。これに代えて、要求元のユーザ端末２００のユーザが車両１００に乗車していない場合には、例えば、センタサーバ５００は、ユーザ端末２００の所在地に車両１００を向かわせ、当該車両１００に当該ユーザを乗車させ、合流地点に向かわせてもよい。

図１２は、第２実施形態の変形例に係るセンタサーバ５００の運行制御部５０３によるマッチング制御処理のフローチャートの一例である。図１２に示されるフローチャートでは、図７及び図１１に示されるマッチング制御処理と同じ処理には同じ符号が付されている。図１２に示される処理も、所定の周期で繰り返し実行される。

Ｓ１０１からＳ１０４、Ｓ２０１の処理は、図１１において説明された通りである。要求元のユーザ端末２００のユーザがいずれかの車両１００に乗車中である場合（Ｓ２０１：ＹＥＳ）の処理は、図１１において説明された通り、図７のＳ１０５からＳ１０８と同様の処理が、要求元のユーザが乗車中の車両１００と対象車両とに対して行われる。

要求元のユーザ端末２００のユーザがいずれの車両１００にも乗車中でない場合には（Ｓ２０１：ＮＯ）、処理がＳ３０１に進む。Ｓ３０１では、運行制御部５０３は、要求元のユーザ端末２００の所在地への迎車を決定する。例えば、要求元のユーザ端末２００の所在地への迎車には、「非サービス中」であり、且つ、いずれのユーザも乗車中でなく、且つ、ユーザ端末２００の所在地の最も近くに位置する車両１００が選択される。

以降のＳ１０５からＳ１０８の処理は、図１１で説明された通りである。すなわち、運行制御部５０３は、要求元のユーザ端末２００への迎車車両１００と対象車両との現在位置に基づいて、合流地点と合流予定時刻とを決定し（Ｓ１０５）、両車両１００に運行指令を送信し（Ｓ１０６）、両車両１００又は要求元のユーザ端末２００と対象車両とからマッチングサービスの完了通知を受信すると（Ｓ１０７：ＹＥＳ）、サービスを終了させ
る（Ｓ１０８）。

なお、この場合、Ｓ１０６において、要求元のユーザ端末２００への迎車車両１００へ送信される運行指令には、例えば、要求元のユーザ端末２００の所在地への移動指令、当該ユーザ端末２００の所在地におけるユーザの乗車指令、当該ユーザ端末２００の所在地から合流地点への移動指令、合流地点においてマッチング要求の対象の車両１００との合流指令を含む。

第２実施形態の変形例によれば、要求元のユーザ端末２００のユーザが車両１００に乗車中でない場合には、当該ユーザの元に車両１００を向かわせ、当該車両１００に当該ユーザを合流地点まで移動させることによって、より早く要求元のユーザとマッチング要求の対象のユーザとを合流させることができる。

＜その他＞
第１実施形態及び第２実施形態では、ユーザがマッチング要求を送信する場合には、車両１００又はユーザ端末２００にマッチング要求の対象となるユーザの識別情報を、直接入力又は同じ組織に属するユーザのリストから選択することで指定する。これに代えて、例えば、マッチング要求を行う前に、要求元のユーザは、車両１００又はユーザ端末２００を通じて、センタサーバ５００に車両１００に乗車中のユーザの一覧を要求し、当該一覧からマッチング要求の対象となるユーザを選択するようにしてもよい。

また、第１実施形態及び第２実施形態では、マッチング要求の対象として指定されるのは、ユーザ個人であるが、これに限られず、例えば、「部署Ａに属するユーザ」等の、ユーザの属性をマッチング要求の対象として指定するようにすることもできる。また、マッチング要求の対象として、複数のユーザを指定することも可能である。

また、第１実施形態及び第２実施形態では、車両１００はＥＶパレットが想定されていたが、車両１００は、例えば、有人運転の自動車であってもよい。この場合には、当該自動車には、例えば、データ通信装置が搭載されており、データ通信装置が第１実施形態又は第２実施形態における車両１００と同様の処理（例えば、センタサーバ５００との通信等）を行うようにしてもよい。または、自動車の運転手等の乗車ユーザが所持するユーザ端末に第１実施形態又は第２実施形態における車両１００の処理（例えば、センタサーバ５００との通信等）を行わせるようにしてもよい。

＜記録媒体＞
コンピュータその他の機械、装置（以下、コンピュータ等）に上記の車両制御を実現させるプログラムを、コンピュータ等が読み取り可能な記録媒体に記録することができる。コンピュータ等に、この記録媒体のプログラムを読み込ませて実行させることにより、当該コンピュータが上記のセンタサーバ５００として機能する。

ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、又は化学的作用によって蓄積し、コンピュータ等から読み取ることができる非一時的な記録媒体をいう。このような記録媒体のうちコンピュータ等から取り外し可能なものとしては、例えばフレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／Ｗ、ＤＶＤ、ブルーレイディスク、ＤＡＴ、８ｍｍテープ、フラッシュメモリなどのメモリカード等がある。また、コンピュータ等に固定された記録媒体としてハードディスク、ＲＯＭ（リードオンリーメモリ）等がある。さらに、ＳＳＤ（Solid State Drive）は、コンピュータ等から取り外し可能な記録媒体としても、コン
ピュータ等に固定された記録媒体としても利用可能である。

１、１Ｘ ：車両制御システム
５１ ：ＣＰＵ
５２ ：メモリ
５４ ：外部記憶装置
５５ :通信部
１００ ：車両
２００ ：ユーザ端末
５００ ：センタサーバ
５０１ ：要求受付部
５０２ ：位置情報管理部
５０３ ：運行制御部
５０４ ：車両管理データベース

Claims (9)

1. 複数の車両と、
   前記複数の車両のそれぞれについて、乗車中のユーザに関する情報を記憶する記憶部と、
   前記複数の車両のうちのいずれかに乗車中のユーザとの合流を要求するマッチング要求を受信する受信部と、
   前記記憶部に記憶される情報に基づいて、前記マッチング要求に合致する第１のユーザが乗車中の第１の車両を特定し、前記第１の車両と前記マッチング要求の要求元とを合流させるように、前記第１の車両に対する制御を行う制御部と、
   を備える車両制御システム。
2. 前記複数の車両のそれぞれは、移動指令に基づいて自律走行可能な車両であり、
   前記制御部は、前記第１の車両に対する前記制御として、前記要求元との合流地点を決定し、前記第１の車両に前記合流地点への移動指令を送信する、
   請求項１に記載の車両制御システム。
3. 前記マッチング要求の要求元は、前記複数の車両のうちの前記第１の車両以外の車両であって、第２のユーザが乗車中の第２の車両であり、
   前記制御部は、前記第２の車両にも前記合流地点への移動指令を送信する、
   請求項２に記載の車両制御システム。
4. 前記マッチング要求の要求元は、第２のユーザのユーザ端末である、
   請求項１又は２に記載の車両制御システム。
5. 前記マッチング要求の要求元は、前記複数の車両のうちの前記第１の車両以外の第２の車両に乗車している第２のユーザのユーザ端末であり、
   前記制御部は、前記第２の車両にも前記合流地点への移動指令を送信する、
   請求項２に記載の車両制御システム。
6. 前記マッチング要求の要求元は、前記複数の車両のうちのいずれの車両にも乗車していない第２のユーザのユーザ端末であり、
   前記制御部は、前記複数の車両のうちの前記第１の車両以外の第２の車両へ、前記ユーザ端末の所在地への移動指令と、前記ユーザ端末の所在地における前記第２のユーザの乗車指令と、前記ユーザ端末の所在地から前記合流地点への移動指令とを送信する、
   請求項２に記載の車両制御システム。
7. 前記制御部は、前記第１の車両と前記第２の車両とが前記合流地点において合流し、前記第１のユーザ又は前記第２のユーザのうちのいずれか一方が、前記第２の車両又は前記第１の車両に乗り換えた場合に、前記第１の車両と前記第２の車両とのうちユーザが乗車していない車両に、所定の位置への移動指令を送信する、
   請求項３、５、及び６のいずれか一項に記載の車両制御システム。
8. 前記制御部は、前記第１の車両に前記マッチング要求についての確認要求を通知し、前記第１の車両から応答が受信された場合に、前記第１の車両に対する前記制御を行う、
   請求項２から７のいずれか一項に記載の車両制御システム。
9. 複数の車両を制御する制御装置が、
   前記複数の車両のそれぞれについて、乗車中のユーザに関する情報を記憶部に記憶し、
   前記複数の車両のうちのいずれかに乗車中のユーザとの合流を要求するマッチング要求
   を受信し、
   前記記憶部に記憶される情報に基づいて、前記マッチング要求に合致する第１のユーザが乗車中の第１の車両を特定し、前記第１の車両と前記マッチング要求の要求元とを合流させるように、前記第１の車両に対する制御を行う、
   車両制御方法。

Images