JP7147441B2 - 運行ルート判断装置、運行ルート判断プログラムおよび運行ルート判断方法 - Google Patents

Description

本発明は、運行ルート判断装置、運行ルート判断プログラムおよび運行ルート判断方法に関する。

車両の効率的運用、交通渋滞の緩和、燃料代の節約、環境対策などを目的として一台の車両に複数の乗員が相乗りして移動を行う形態が各国で広がっている。特許文献１には、同乗者を募る車両のドライバと同乗を希望するユーザとの間で仲介を行うシステムが開示されており、これによればドライバとユーザの双方がメリットを受けることができる。

特開２０１８－５５５３８号公報

ところで、実際には車両もユーザも複数存在しておりそれぞれの出発地および目的地も多様であるが、各ユーザは所定の１台の車両で目的地まで搬送されることが前提となっており、必ずしも効率的な搬送が実現されている訳ではない。

本発明は、上記の課題に鑑みてなされたものであって、搬送対象を効率的に搬送することのできる運行ルート判断装置、運行ルート判断プログラムおよび運行ルート判断方法を提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明にかかる運行ルート判断装置は、第１車両の第１運行ルートデータおよび第２車両の第２運行ルートデータを取得し、前記第１運行ルートデータと前記第２運行ルートデータとを比較して効率条件を満たすように、前記第１車両または前記第２車両の少なくとも一方が搬送する搬送対象を他方に乗り換えさせる乗換地を探索し、前記第１運行ルートデータを修正して前記乗換地を経由させた第１修正運行ルートデータと前記第２運行ルートデータを修正して前記乗換地を経由させた第２修正運行ルートデータとを探索して出力する。

前記効率条件は、前記第１車両または前記第２車両の運行時間または運行距離の少なくとも一方を短縮させる条件であってもよい。これにより、運行時間、運行距離の短縮を図ることができる。

前記効率条件は、前記搬送対象がその目的地に到着するまでの時間または距離の少なくとも一方を短縮させる条件であってもよい。これにより、搬送対象を短時間、短距離で搬送することができる。

前記第１運行ルートデータおよび前記第２運行ルートデータには、それぞれ搬送する前記搬送対象の数、大きさまたは重量と、さらに追加搬送可能な前記搬送対象の数、大きさまたは重量が含まれ、前記ルート探索処理部は、乗り換えさせる前記搬送対象の数、大きさまたは重量が相互に適合する場合に処理を実行してもよい。これにより搬送対象の乗り換え困難な場合が取り除かれ、第１車両と第２車両とのマッチングが適正に行われる。

前記ルート探索処理部は、前記第１車両および前記第２車両の到着予想時刻に利用可能な商業施設または交通施設から前記乗換地を選択してもよい。これにより、搬送対象および運転主体の双方に利便性があり、適正でスムーズな乗り換えが行われる。

通信網を介して受信した情報から３以上の車両についてそれぞれの状況を把握する車両状況把握部と、前記搬送対象の出発地と目的地とに基づき、前記車両状況把握部で把握する前記車両の中から前記第１車両および前記第２車両を選択するマッチング部と、を有してもよい。これにより、搬送対象は１台の車両に同乗して目的地に行くことができない場合であっても、複数台の車両を乗り継いで行くことができ、いろいろな場所への相乗りが実現する。

前記第１車両と前記第２車両が搬送する前記搬送対象の合計が複数ある場合に、前記ルート探索処理部は、個別の前記搬送対象について前記効率条件を満たすように前乗換地を探索して、最も効率が高くなるように前記第１修正運行ルートデータと前記第２修正運行ルートデータとを探索してもよい。これにより、搬送対象を搬送する効率が一層向上する。

前記第１運行ルートデータは前記搬送対象に基づいて出発地と目的地が設定され、および／または、前記第２運行ルートデータは前記搬送対象に基づいて出発地と目的地が設定されてもよい。これにより、搬送対象にとっての利便性が高まる。

前記第１運行ルートデータは第１運転主体によって出発地と目的地が設定され、および／または、前記第２運行ルートデータは第２運転主体によって出発地と目的地が設定されてもよい。これにより、第１運転主体、第２運転主体は自らの当初予定である運行ルートデータにほぼ沿って運転を行えばよく、好都合である。

前記第１車両は前記第１運行ルートデータを前記第２車両に対して車々間通信で送信し、前記第２車両は前記第２運行ルートデータを前記第１車両に対して車々間通信で送信し、前記第１車両または前記第２車両の一方が備える前記ルート探索処理部によって、前記第１修正運行ルートデータと前記第２修正運行ルートデータとが探索され、他方に対して車々間通信で送信されてもよい。このような車々間通信では、第１車両と第２車両との間で直接的な交信がなされて迅速で簡易な処理が実現される。

また、本発明にかかる運行ルート判断プログラムは、第１車両の第１運行ルートデータおよび第２車両の第２運行ルートデータを取得し、前記第１運行ルートデータと前記第２運行ルートデータとを比較して効率条件を満たすように、前記第１車両または前記第２車両の少なくとも一方が搬送する搬送対象を他方に乗り換えさせる乗換地を探索し、前記第１運行ルートデータを修正して前記乗換地を経由させた第１修正運行ルートデータと前記第２運行ルートデータを修正して前記乗換地を経由させた第２修正運行ルートデータとを探索して出力することをコンピュータに実行させる。

さらに、本発明にかかる運行ルート判断方法は、第１車両の第１運行ルートデータおよび第２車両の第２運行ルートデータを取得し、前記第１運行ルートデータと前記第２運行ルートデータとを比較して、記憶部から読み出した効率条件を満たすように、前記第１車両または前記第２車両の少なくとも一方が搬送する搬送対象を他方に乗り換えさせる乗換地を探索し、前記第１運行ルートデータを修正して前記乗換地を経由させた第１修正運行ルートデータと前記第２運行ルートデータを修正して前記乗換地を経由させた第２修正運行ルートデータとを探索して出力する。

本発明にかかる運行ルート判断装置、運行ルート判断プログラムおよび運行ルート判断方法では、第１車両の第１運行ルートデータと第２車両の第２運行ルートデータとを比較して効率条件を満たすように、第１車両または第２車両の少なくとも一方が搬送する搬送対象を他方に乗り換えさせる乗換地を探索し、第１運行ルートデータおよび第２運行ルートデータを修正して乗換地を経由させた第１修正運行ルートデータおよび第２修正運行ルートデータとを探索して出力する。第１修正運行ルートデータおよび第２修正運行ルートデータを認識した第１車両および第２車両の各運転主体は、適切であると判断した後に乗換地で搬送対象を乗り換えさせることができる。これにより、搬送対象の乗り換えが実現され、該搬送対象を効率的に搬送することができる。

図１は、実施の形態にかかるナビゲーション装置およびサーバが含まれる相乗り支援システムのブロック図である。 図２は、実施の形態にかかるナビゲーション装置のブロック図である。 図３は、実施の形態にかかるプログラムの構成を示す図である。 図４は、実施の形態にかかるサーバのブロック図である。 図５は、携帯端末に表示される利用申し込み画面を示す図である。 図６は、携帯端末に表示される確認画面を示す図である。 図７は、第１の運行ルート判断例における車両、ユーザ、出発地、乗換地および目的地を示す模式図である。 図８は、第１の運行ルート判断例におけるフローチャートである。 図９は、第２の運行ルート判断例における車両、ユーザ、出発地、乗換地および目的地を示す模式図である。 図１０は、第２の運行ルート判断例におけるフローチャートである。 図１１は、第３の運行ルート判断例における車両、ユーザ、出発地、乗換地および目的地を示す模式図である。 図１２は、第３の運行ルート判断例におけるフローチャートである。 図１３は、第４の運行ルート判断例における車両、ユーザ、出発地、乗換地および目的地を示す模式図である。 図１４は、第４の運行ルート判断例におけるフローチャートである。

以下に、本発明にかかる運行ルート判断装置、運行ルート判断プログラムおよび運行ルート判断方法の実施形態を図面に基づいて詳細に説明する。なお、この実施形態によりこの発明が限定されるものではない。

図１は、本発明にかかる運行ルート判断装置、運行ルート判断プログラムおよび運行ルート判断方法の各実施形態が適用される相乗り支援システム１０の模式ブロック図である。本発明にかかる運行ルート判断装置の実施形態は後述するサーバ１４またはナビゲーション装置１６に相当し、本発明にかかる運行ルート判断プログラムの実施形態は後述するプログラム３０またはプログラム６６に相当し、本発明にかかる運行ルート判断方法の実施形態はサーバ１４、ナビゲーション装置１６によって実行され、またはプログラム３０やプログラム６６がコンピュータによって読み取り実行されることによる。

相乗り支援システム１０は、インターネットなどの通信網１２に接続されたサーバ１４によって管理されており、ドライバ（運転主体）Ｄａ，Ｄｂ，Ｄｃ…（代表的にドライバＤともいう。）およびユーザＵａ，Ｕｂ，Ｕｃ…（代表的にユーザＵともいう。）によって利用される。ドライバＤおよびユーザＵは予めサーバ１４に登録されているが、条件によっては非登録の者が利用可能としてもよい。

ドライバＤａ，Ｄｂ，Ｄｃ…は車両Ｃａ，Ｃｂ，Ｃｃ…（代表的に車両Ｃともいう。）を運転し、これらの車両Ｃａ，Ｃｂ，Ｃｃとともにサーバ１４に登録されている。車両Ｃａ，Ｃｂ，Ｃｃ…はナビゲーション装置１６ａ，１６ｂ，１６ｃ…（代表的にナビゲーション装置１６ともいう。）を備えている。車両Ｃはナビゲーション装置１６が保持する運行ルートデータＲに基づき、ドライバＤによって運行される。この運行ルートデータＲは広義であって目的地がない自由走行状態を示す場合もあり、さらに時間情報や同乗するユーザＵやその荷物にかかる情報も含まれ得る。

ナビゲーション装置１６は通信網１２を介してサーバ１４と相互通信が可能となっており、さらに２以上の車両Ｃの相互間における車々間通信が可能となっている。これによりナビゲーション装置１６は運行ルートデータＲなどをサーバ１４や相手の車両Ｃに送信することができる。図１における屈曲矢印は無線による通信ルートを示している。

ユーザ（搬送対象）Ｕａ，Ｕｂ，Ｕｃ…はスマートフォンなどの携帯端末１８ａ，１８ｂ，１８ｃ…（代表的に携帯端末１８ともいう。）を持っている。ユーザＵは相乗り支援システム１０の利用に際して予め所定の登録をするとともに、利用のためのアプリケーション１９を携帯端末１８にダウンロードしておく。携帯端末１８はこのアプリケーション１９により通信網１２を介してサーバ１４にアクセス可能である。

相乗り支援システム１０は、概略的にはユーザＵが携帯端末１８によって乗車の利用申し込み送信をして、サーバ１４が条件に適合する車両Ｃを検索し、ドライバＤとユーザＵとを仲介するシステムであるが、さらに効率条件を考慮してルート途中の乗換地Ｚにおいて２以上の車両Ｃの相互間でユーザＵの乗り換えを支援する。ユーザＵの乗り換えについての判断はサーバ１４を介さずに車両Ｃの相互間で行われる場合もある。

以下の説明では煩雑とならずかつ理解が容易となるように、ドライバＤやナビゲーション装置１６によって行われる処理を車両Ｃの処理として記す場合があり、ユーザＵが携帯端末１８を介して行う処理を単にユーザＵの処理として記す場合がある。また、その時点の説明で処理主体となっている車両Ｃを自車両Ｃと記す場合がある。さらに、自車両Ｃとの間でユーザＵを乗り換えさせ、またはその候補となる他の車両Ｃを乗換車両Ｃ’と記す場合がある。

図２に示すように、ナビゲーション装置１６は、全体を管理および制御する制御部２０と、ディスプレイ２２ａに画像や文字を表示する表示部２２と、スピーカ２４ａから出力をする音声出力部２４と、スイッチ２６ａ、マイク２６ｂおよびリモコン２６ｃからの入力を受け付ける入力部２６と、記憶部２８とを有する。

制御部２０および後述する制御部６０は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等の処理装置にプログラムを実行させること、すなわち、ソフトウェアにより実現してもよいし、ＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）等のハードウェアにより実現してもよいし、ソフトウェア及びハードウェアを併用して実現してもよい。

記憶部２８には制御部２０が読み込み実行するプログラム３０と、地図データ３２と、ルート情報３４とが記憶されている。地図データ３２は車両Ｃをナビゲートするのに必要な道路情報、交差点情報、施設情報等が含まれる。記憶部２８は書き替えが可能である。プログラム３０および地図データ３２は、例えば外部記憶媒体から所定の入出力ポートを介してロードされ、またはサーバ１４などから通信網１２を介してロードされる。ルート情報３４は、車両Ｃが走行する運行ルートデータＲや、該運行ルートデータＲが修正された修正運行ルートデータＲ’である。

ナビゲーション装置１６は、さらに通信網１２に接続さている回線通信部３６と、無線アンテナ３８ａを介して車々間通信を行う無線通信部３８と、センサ４０ａの入力信号を処理するセンサインターフェース４０と、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）アンテナ４１ａと接続されるＧＰＳ部４１とを有する。

回線通信部３６は通信網１２を介してサーバ１４などとの相互アクセスが可能である。無線通信部３８は車々間通信に用いられ、他の車両Ｃとの間で位置、方向、速度といったデータを短い間隔で送受信する。そして衝突の可能性があれば相手に警告し、自動運転車の場合は自動でブレーキをかけるなどの対策をとる。車々間通信の規格としては、例えばＤＳＲＣ（ｄｅｄｉｃａｔｅｄ ｓｈｏｒｔ ｒａｎｇｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ、登録商標）が用いられる。なお、車々通信は近距離の車両Ｃ同士の間で無線によって直接的に通信する形態に限らず、通信網１２や他の媒介手段によって通信をしてもよいし、ＩｏＴ通信にも限られない。センサ４０ａは速度センサ、加速度センサ、ジャイロセンサなどであり、車両Ｃの現在地や挙動を検出するのに用いられる。ＧＰＳ部４１では人工衛星から送信される電波によって車両Ｃの現在地を取得することができる。

このようなナビゲーション装置１６の構成要素は相互にバス接続されている。また、このようなナビゲーション装置１６の構成要素は必ずしも１つのユニットにまとまっていなくてもよく、例えば一部の構成要素が他のコンピュータユニットに含まれていてもよい。ナビゲーション装置１６は必ずしも車載型に限らず、例えばドライバＤが持っている携帯端末で代用してもよい。

図３に示すように、プログラム３０は、ルート案内部４２と、相手車両データ受信部４４と、前提条件適合判断部４６と、ルート探索処理部４８と、通知処理部５２と、承諾確認部５４と、ルート情報書換え部５６とを有する。

ルート案内部４２は、ルート情報３４と車両Ｃの現在地とに基づいてドライバＤに対してルートの案内をする。ルートの案内はディスプレイ２２ａやスピーカ２４ａを用いる。相手車両データ受信部４４は、車々間通信によって相手側の車両Ｃの各種データを受信する。このデータには走行中のルート情報、搬送しているユーザＵの人数、ユーザＵの荷物の大きさや重量、ユーザＵの目的地、ドライバＤの目的地などが含まれる。

前提条件適合判断部４６は、ユーザＵを乗車させまたは乗り換えさせる場合に、乗車可能人数や荷物の大きさなどの基本事項が相手の車両Ｃとの間で適合するか否かを判断する部分である。適合する車両Ｃが存在すれば、該車両Ｃを乗換車両Ｃ’の候補とする。

ルート探索処理部４８は基本機能として、ドライバＤが目的地を入力することにより現在地から目的地までの適切なルートを探索して運行ルートデータＲとし、これをディスプレイ２２ａに表示する。このルート検索では必要に応じて経由地の指定も可能である。得られた運行ルートデータＲはルート情報３４として記憶され、ルート案内部４２によって参照されてドライバＤに案内される。車両Ｃが運行ルートデータＲと異なるルートを走行している場合には、ルート探索処理部４８は現在地に基づいて適宜自動的にルート検索を再実行し運行ルートデータＲを書き替える。運行ルートデータＲには目的地の到着予想時刻と予想運行時間とが含まれる。

ルート探索処理部４８は付加的な機能部として、乗換地探索部５０ａと、変更ルート探索部５０ｂとを有し、さらに乗換地探索部５０ａおよび変更ルート探索部５０ｂで参照される効率条件データ５０ｃを有する。

乗換地探索部５０ａは、自車両Ｃと乗換車両Ｃ’との間で１以上のユーザＵを乗り換えさせる場合に、適当な乗換地Ｚを探索する部分である。乗換地Ｚは、自車両Ｃと乗換車両Ｃ’のそれぞれのルート情報３４（つまり運行ルートデータＲ１，Ｒ２）に基づき、そのルート上から近い範囲であって、自車両Ｃおよび乗換車両Ｃ’の到着時刻差が条件値より小さい範囲で選択される。乗換地Ｚは、自車両Ｃおよび乗換車両Ｃ’の到着予想時刻に利用可能な商業施設（大小のストア，飲食店など）または交通施設（ＳＡ（Ｓｅｒｖｉｃｅ ａｒｅａ），ＰＡ（Ｐａｒｋｉｎｇ ａｒｅａ），高速バス停，道の駅，駅ロータリー，ガソリンスタンドなど）から選択される。交通施設には相乗り車両専用の乗降施設も含まれる。また乗換地Ｚとしては適度な駐車スペース、ベンチ、ルーフおよびトイレのある場所が望ましく、さらに夜間の場合には照明のある場所が望ましい。乗換地Ｚの候補となる施設は地図データ３２に記憶されている。このような施設を乗換地Ｚとして選定することによりユーザＵおよびドライバＤの双方に利便性があり、適正でスムーズな乗り換えが行われる。特に乗り換えるユーザＵにとって多少の待ち時間が発生する場合に便利である。

変更ルート探索部５０ｂは、自車両Ｃおよび乗換車両Ｃ’の各ルート情報３４についてそれぞれ乗換地Ｚを含むルートを探索する。

乗換地探索部５０ａおよび変更ルート探索部５０ｂは効率条件データ５０ｃで規定されている条件を満たすように処理が行われる。効率条件データ５０ｃではいくつかの条件が規定されている。そのうちの１つは、自車両Ｃまたは乗換車両Ｃ’の運行時間または運行距離の少なくとも一方を短縮させる条件である。また他の１つは、ユーザＵがその目的地に到着するまでの時間または距離の少なくとも一方を短縮させる条件である。時間の判断には渋滞情報・事故情報が加味されてもよい。さらに他の１つは、自車両Ｃまたは乗換車両Ｃ’の一方または両者合計の運行費用（例えば燃料代および有料道路代）を低減させる条件である。さらにまた他の１つは、車両Ｃの使用燃料と燃費と運行距離とから算出される環境負荷を低減させる条件である。効率条件データ５０ｃにはさらに他の効率条件が規定されていてもよい。これらの効率条件は状況によっていずれか１つが選択され、または複数条件を重み付けして用いられる。

乗換地探索部５０ａおよび変更ルート探索部５０ｂによる乗換地Ｚおよびルートの探索は、効率条件データ５０ｃで規定されている効率条件を満たすか否かが所定の閾値に基づいて判断される。閾値を満たす探索結果がない場合にはユーザＵの乗り換えは行われない。閾値を満たす探索結果が複数存在する場合には、最もスコアの高いものが選択される。乗換地探索部５０ａと変更ルート探索部５０ｂの処理は一体的に行われてもよい。

図４に示すように、サーバ１４は制御部６０と、回線通信部６２と、記憶部６４とを有する。

記憶部６４にはプログラム６６、地図データ６８、ドライバデータベース７０、ユーザデータベース７２が記憶されている。記憶部６４は書き替え可能である。制御部６０はプログラム６６を読み込み実行する。回線通信部６２は通信網１２を介してナビゲーション装置１６および携帯端末１８などとの相互アクセスが可能である。

地図データ６８は上記の地図データ３２と同様のものであるが、記憶容量の余裕によっては地図データ３２より詳細なものであってもよい。ドライバデータベース７０は、登録されたドライバＤについてのデータベースであり識別番号とともに、氏名、性別、年齢、評価、連絡先、運転する車両Ｃ、運行頻度の高いルートなどが記憶されている。このうち、評価は過去に搬送したユーザＵによって採点される。運行頻度の高いルートは過去のデータからサーバ１４が判断して適宜書き替えられる。ユーザデータベース７２は、登録されたユーザＵについてのデータベースであり識別番号とともに、氏名、性別、年齢、評価、利用頻度の高いルートなどが記憶されている。このうち、評価は過去に利用した車両ＣのドライバＤによって採点される。利用頻度の高いルートは過去のデータからサーバ１４が判断して適宜書き替えられる。

プログラム６６は、受付・問い合わせ部７４と、マッチング部７６と、ルート探索処理部８０と、車両状況把握部７８と、経過観察部８２と、後処理部８４とを有する。受付・問い合わせ部７４は、ユーザＵからの利用申し込みを受け付け、車両Ｃとの間で承諾可能か否か問い合わせを行う部分である。マッチング部７６は、ユーザＵの希望に応じて複数の車両Ｃの中から適合するものを検索し、ユーザＵといずれかの車両Ｃとを組み合わせる部分である。

車両状況把握部７８は、登録された複数の車両Ｃの状況を把握する部分であり各車両Ｃの現在地と、運行ルートデータＲと、目的地と、時刻情報（到着予想時間など）とが保持されている。これらの情報は各車両Ｃのナビゲーション装置１６から通信網１２を介して定期的に送信されており、サーバ１４で取得されている。また、車両状況把握部７８は、各車両Ｃについての未出発の運行予定についても記憶可能となっている。

ルート探索処理部８０は、上記のナビゲーション装置１６におけるルート探索処理部４８と同様の機能を持ち、乗換地探索部８０ｂ、変更ルート探索部８０ｃおよび効率条件データ８０ｄは順に上記の乗換地探索部５０ａ、変更ルート探索部５０ｂおよび効率条件データ５０ｃに相当する。ルート探索処理部８０はさらにユーザ搬送ルート探索部８０ａを備える。

ユーザ搬送ルート探索部８０ａは、利用申し込みがあったユーザＵの出発希望時間（例えば５分後）、出発地（例えば現在地）および目的地と、該ユーザＵが乗車すべき車両Ｃの現在地、目的地、ルート、および上記出発希望時間における予想位置などに基づいて、車両ＣがユーザＵをその目的地まで搬送するのに適したルートを地図データ６８を参照しながら探索する部分である。

経過観察部８２は、ユーザＵと車両Ｃとの組み合わせが決定し、ユーザＵが車両Ｃに乗車した後に搬送され、目的地に到着して下車するまでユーザＵと車両Ｃとの状況を把握する部分である。経過観察部８２は車両状況把握部７８に含まれていてもよい。後処理部８４は車両ＣがユーザＵの搬送を終了した後に必要な後処理を行う部分である。

なお、サーバ１４の制御部６０、回線通信部６２および記憶部６４は必ずしも１つのユニットにまとまっていなくてもよく、例えば記憶部６４は通信網１２を介した遠隔地にあってもよい。サーバ１４およびそのプログラム６６が存在する場所は車両Ｃの運行国に限られないが、その運行国で制御が可能であり、その運行国でなんらかの利益を享受することができるならば、その運行国で設置・使用されているのと実質的に同じことである。また、サーバ１４はハードウェアとしては汎用品を利用可能であり、ハードウェアについての詳細な説明は省略する。

図５に示すように、携帯端末１８にはアプリケーション１９によって利用申し込み画面９０が表示される。利用申し込み画面９０はユーザＵが相乗り支援システム１０を利用する申し込み時に用いられる画面である。利用申し込み画面９０には基本事項の入力部として出発地入力ボックス９２ａ、目的地入力ボックス９２ｂ、日時入力ボックス９２ｃ、出発／到着選択ラジオボタン９２ｄ、人数選択入力ボックス９２ｅ、荷物区分ラジオボタン９２ｆおよび荷物重量入力ボックス９２ｇが設けられている。出発地入力ボックス９２ａおよび目的地入力ボックス９２ｂはユーザＵが搬送を希望する出発地と目的地が入力される部分であり住所、電話番号、郵便番号、著名施設名などを入力し、または地図上でポイント指定し、さらには過去ログから選択することができる。出発地としては携帯端末１８が有する現在地取得機能に基づいて現在地を指定してもよい。日時入力ボックス９２ｃは希望の日時を入力する部分であり、出発日時か到着日時かは出発／到着選択ラジオボタン９２ｄで選択する。

人数選択入力ボックス９２ｅは乗車希望の人数を大人と小人とに分けて入力する部分である。荷物区分ラジオボタン９２ｆは手荷物の大きさをいくつかの区分から選択入力する部分であり、例えば大、小、無からいずれかを選択する。荷物重量入力ボックス９２ｇは手荷物の重量を入力する部分であるが、所定重量よりも明らかに軽い場合には入力を省略できる。

利用申し込み画面９０には、さらに条件入力部９４が設けられている。条件入力部９４はユーザＵの要望を入力する部分であり、特段の要望がない場合にはデフォルトのままとすればよい。条件入力部９４には、高速利用可否ラジオボタン９４ａ、ドライバ評価ラジオボタン９４ｂ、車種選択ラジオボタン９４ｃ、禁煙／喫煙ラジオボタン９４ｄ、途中乗換ラジオボタン９４ｅ、他のユーザの同乗ラジオボタン９４ｆおよび備考ボックス９４ｇが設けられている。

高速利用可否ラジオボタン９４ａでは高速利用の可否を選択する。ドライバ評価ラジオボタン９４ｂでは希望するドライバＤの評価ランクを選択する。車種選択ラジオボタン９４ｃでは希望する車種を選択する。禁煙／喫煙ラジオボタン９４ｄでは禁煙車か喫煙車かを選択する。途中乗換ラジオボタン９４ｅでは、状況による車両Ｃの途中乗り換えの可否を選択する。他のユーザの同乗ラジオボタン９４ｆでは、搬送ルート中の一部または全部において他のユーザＵが同乗することの可否を選択する。備考ボックス９４ｇにはその他の要望があれば記入する。

以上の入力を行った後、ユーザＵが送信ボタン９６をタップすることにより入力された情報がサーバ１４に送信される。サーバ１４（図４参照）では、受付・問い合わせ部７４でユーザＵからの申し込みにかかる情報を受け付け、マッチング部７６が車両状況把握部７８によって把握している車両Ｃの状況から条件に合ういくつかを候補として選び出す。この選択は、例えばユーザＵの現在地または出発地の近くにいる車両Ｃや、ユーザＵの出発地と目的地とを略含むルートで走行予定となっている車両Ｃの中から選択する。また、必要に応じてドライバデータベース７０およびユーザデータベース７２からドライバＤおよびユーザＵの情報を参照して絞り込みを行う。

そして、ユーザＵが候補の車両Ｃによって搬送される場合のルートをユーザ搬送ルート探索部８０ａで探索する。適当なルートが探索されると、受付・問い合わせ部７４が該車両ＣにユーザＵの搬送の可否を問い合わせる。このとき探索されたルートの情報およびユーザデータベース７２に記憶されているユーザＵの情報も車両Ｃに送信する。車両Ｃから承諾を示す信号を受信すると、受付・問い合わせ部７４は該車両ＣおよびドライバＤに係る情報および探索されたルートの情報をユーザＵの携帯端末１８に送信する。これを受けて携帯端末１８では、アプリケーション１９の作用下に図６に示す確認画面１００が表示される。また、サーバ１４で適当な車両Ｃを見つけられなかった場合にはその旨を携帯端末１８に送信して、ユーザＵに通知する。

図６に示すように、確認画面１００にはドライバ情報表示部１００ａ、ドライバ評価表示部１００ｂ、車種表示部１００ｃ、時間表示部１００ｅ、料金表示部１００ｆ、付記事項表示部１００ｇが設けられている。ドライバ情報表示部１００ａは選定された車両ＣにかかるドライバＤについて氏名、性別、年齢などが表示される部分である。ドライバ評価表示部１００ｂは、そのドライバＤの評価ランクが表示される部分である。車種表示部１００ｃは、選定された車両Ｃの車種を表示する部分である。ルート表示部１００ｄはサーバ１４で探索されたルートを地図上で示すとともに距離および予想行程時間を表示する部分である。時間表示部１００ｅは目的地への到着予想時間を表示する部分である。料金表示部１００ｆはユーザＵが支払う料金を表示する部分である。料金の支払いは、例えばカード決済などの自動手続きが利用可能である。なお、ユーザＵが支払う料金や、それに基づいてドライバＤや相乗り支援システム１０の運営者が取得する報酬については、その国や地域の法制に従うことはもちろんである。付記事項表示部１００ｇは付記事項を表示する部分であり、例えば「途中乗換が発生する場合があります」、「他のユーザが同乗する場合があります」といった事項を表示する。

これらの条件を確認したユーザＵは承諾する場合には承諾ボタン１０２をタップし、これにより相乗り契約が成立することになる。表示された条件が希望に合わず別のドライバＤを希望するなどの場合には再選定ボタン１０４をタップし、サーバ１４に対して再選定を依頼する。また、表示された条件が希望に合わず、利用申込みをキャンセする場合にはキャンセルボタン１０６をタップする。なお、携帯端末１８は汎用品にアプリケーション１９をロードすることで適用可能となることから、携帯端末１８のハードウェアについての詳細な説明は省略する。

次に、このように構成される相乗り支援システム１０による第１の運行ルート判断例～第４の運行ルート判断例を図７～図１４を参照しながら説明する。以下の例では、各ユーザＵは、途中の乗り換えおよび他のユーザＵの同乗を承諾しているものとする。なお以下の説明では理解が容易となるように、ステップ番号は実行主体を区別せずほぼ時刻順としている。最初に第１の運行ルート判断例について、図７および図８を参照しながら説明する。

（第１の運行ルート判断例）
図７に示すように、第１の運行ルート判断例では、ユーザＵａが出発地Ｘ１から目的地Ｙ１へ向かい、ユーザＵｂが出発地Ｘ２から目的地Ｙ２へ向かい、ユーザＵｃが出発地Ｘ３から目的地Ｙ２へ向かうものとする。出発地Ｘ１と出発地Ｘ２は近い。出発地Ｘ１および出発地Ｘ２はインターチェンジＩＣ１に近く、出発地Ｘ３はインターチェンジＩＣ２に近い。目的地Ｙ１はインターチェンジＩＣ３に近い。目的地Ｙ２は目的地Ｙ１にやや近いが十分に近い訳ではなく、目的地Ｙ１よりもインターチェンジＩＣ４に近い。インターチェンジＩＣ３とインターチェンジＩＣ４とは隣り合っている。車両Ｃａは出発地Ｘ１の近くにおり、車両Ｃｂは出発地Ｘ３の近くにいるものとする。ユーザＵｂの目的地Ｙ２とユーザＵｃの目的地Ｙ２は厳密に一致してなくてもよい。

図８に示すように、まずステップＳ１０１においてユーザＵａは相乗りの申し込みの入力および送信の処理を行う。同様にステップＳ１０２においてユーザＵｂは相乗りの申し込みの入力および送信処理を行う。これらの入力および送信は、図５の利用申し込み画面９０を用いて利用直前または事前にサーバ１４に対して行われる。

ステップＳ１０３において、サーバ１４はユーザＵと車両Ｃとのマッチングを行う。この場合、出発地Ｘ１と出発地Ｘ２とが近く、目的地Ｙ１と目的地Ｙ２とがやや近いため、出発地Ｘ１の近くにいる車両Ｃａが１台で２人のユーザＵａ，Ｕｂの搬送をすることが効率的であると判断される。この処理はマッチング部７６（図４参照）により行われる。

さらにステップＳ１０４において、車両ＣａがユーザＵａ，Ｕｂを出発地Ｘ１、Ｘ２から目的地Ｙ１，Ｙ２へ搬送する運行ルートデータＲ１を探索する。この場合の運行ルートデータＲ１は、車両Ｃａはまず出発地Ｘ１に行ってユーザＵａを乗車させ、さらに出発地Ｘ２に行ってユーザＵｂを乗車させた後、インターチェンジＩＣ１からインターチェンジＩＣ３まで高速道路を利用し、目的地Ｙ１でユーザＵａを下車させ、最後の目的地Ｙ２でユーザＵｂを下車させることが適当であると判断され、そのルートが探索される。この探索結果である運行ルートデータＲ１には出発地Ｘ１、Ｘ２および目的地Ｙ１，Ｙ２の予想到着時刻が含まれる。さらに途中ポイント、例えばインターチェンジＩＣ１，ＩＣ３の予想通過時刻が含まれていてもよい。これらの処理はユーザ搬送ルート探索部８０ａ（図４参照）により行われる。マッチング部７６とユーザ搬送ルート探索部８０ａの処理は互いの処理結果を参照しながら複数回繰り返し実行され、または同時並列的に行われてもよい。

ステップＳ１０５において、サーバ１４はユーザＵａ，Ｕｂに対して運行ルートデータＲ１の情報と車両Ｃａにかかる情報を携帯端末１８に送信して図６の確認画面１００を表示させ、その諾否を問い合わせる。ユーザＵａ，Ｕｂは表示された情報を基に諾否をサーバ１４に送信する。一方サーバ１４は車両Ｃａに対して運行ルートデータＲ１の情報とユーザＵａ，Ｕｂにかかる情報を送信してディスプレイ２２ａに表示させ、その諾否を問い合わせる。ドライバＤａは表示された情報を基に諾否をサーバ１４に送信する。三者から承諾が得られた場合には契約が成立し、サーバ１４はその旨を三者に返信する。その際に、ドライバＤａにはユーザＵａ，Ｕｂの連絡先を通知し、ユーザＵａ，ＵｂにはドライバＤａの連絡先を通知する。契約成立の後、車両Ｃａは運行ルートデータＲ１に従い、出発地Ｘ１，Ｘ２でユーザＵａ，Ｕｂを乗車させて最初の目的地Ｙ１へ向かう。問い合わせおよびその諾否の手順・順序については様々な形態をとり得る。

一方、この後のステップＳ１０６において、ユーザＵｃが相乗りの申し込みの入力および送信の処理を行ったものとする。ステップＳ１０７およびＳ１０８において、サーバ１４は上記のステップＳ１０３およびＳ１０４と同様にマッチングおよびルート探索を行う。この場合、出発地Ｘ３の近くにいる車両Ｃｂによる搬送が適当であると判断される。またその運行ルートデータＲ２は、まず出発地Ｘ３に行ってユーザＵｃを乗車させた後、インターチェンジＩＣ２から高速道路を利用し、インターチェンジＩＣ３を通過して次のインターチェンジＩＣ４で高速道路を降り、目的地Ｙ２でユーザＵｃを下車させるのが適当であると判断され、ルートが探索される。この探索結果である運行ルートデータＲ２には出発地Ｘ３および目的地Ｙ２の予想到着時刻が含まれる。さらに途中ポイント、例えばインターチェンジＩＣ２，ＩＣ３，ＩＣ４の予想通過時刻が含まれていてもよい。

そして次のステップＳ１０９において、サーバ１４はステップＳ１０５と同様にユーザＵｃおよびドライバＤｂに対して互いの情報と探索された運行ルートデータＲ２の情報を送信して、その諾否を問い合わせる。両者から承諾が得られると契約が成立する。契約成立の後、車両Ｃｃは運行ルートデータＲ２に従い、出発地Ｘ３でユーザＵｃを乗車させて目的地Ｙ２へ向かう。

この後、車両Ｃａ，ＣｂはインターチェンジＩＣ１，ＩＣ２からそれぞれ高速道路に入りほぼ同時刻に同方向に走行し、ステップＳ１１０において車々間通信が成立したとする。車々間通信では互いの車両Ｃにおける運行ルートデータ、乗車中のユーザＵの人数、荷物量、目的地、および追加乗車可能な余裕人数、荷物量にかかる情報が互いに取得される。また、車々通信によれば車両Ｃａと車両Ｃｂとの間で直接的な交信がなされて迅速で簡易な処理が実現される。

ステップＳ１１１において、これらの情報を受けた車両Ｃａのナビゲーション装置１６ａまたは車両Ｃｂのナビゲーション装置１６ｂはルート再探索処理を行う。ナビゲーション装置１６ａまたは車両Ｃｂのナビゲーション装置１６ｂのいずれが処理を担当するのかは取決めによって決定される。取決めとは、例えば先に相手方の車々間通信電波を受信した側であったり、ハードウェア能力の優れた側であったり、その時点の処理負荷の軽い側であったり、運行予定距離の長い側であったり、または乗車しているユーザＵの人数の多い側である。ここでは車両Ｃａの側が処理を担当するものとする。

処理を担当する側では、前提条件適合判断部４６（図３参照）において車両ＣａのユーザＵａ，Ｕｂおよびその荷物量（大きさや重量）が車両Ｃｂで受入可能か、および、車両ＣｂのユーザＵｃおよびその荷物量が車両Ｃａで受入可能かを判断する。この判断により、ユーザＵの乗り換え困難な場合が取り除かれ、車両Ｃａと車両Ｃｂとのマッチングが適正に行われる。そして、車両Ｃａ，ＣｂおよびユーザＵａ，Ｕｂ，Ｕｃのそれぞれについて個別にまたは総合的にどのようなルートを辿ることが効率的かを考慮して運行ルートデータＲ１および運行ルートデータＲ２に基づいて再探索を行う。この探索はルート探索処理部４８（図３参照）によって、そのときの状況に基づいて効率条件データ５０ｃを参照しながら行われる。

この第１の運行ルート判断例の場合（図７参照）、車両Ｃａに乗車中のユーザＵｂと車両Ｃｂに乗車中のユーザＵｃはともに目的地Ｙ２へ向かうことから車両Ｃａまたは車両Ｃｂのいずれかに同乗した方が効率的であると判断される。つまり、車両Ｃａは、２つの目的地Ｙ１，Ｙ２へ行くよりも最初の目的地Ｙ１へ到着した時点で搬送が終了すれば、目的地Ｙ２まで行く必要がなくて運行距離および運行時間の面から効率的である。ユーザＵｂにとっても目的地Ｙ１を経由することなく自らの目的地Ｙ２へ直接的に行けることから時間的にも距離的にも効率的である。

そこで、乗換地探索部５０ａはユーザＵｂを車両Ｃａから車両Ｃｂに乗り換えさせるのに適当な乗換地Ｚを地図データ３２から探索する。上記のとおり、乗換地Ｚとしては通過予想時間に利用可能な商業施設や交通施設が適当であり、この場合には高速道路における途中のＳＡまたはＰＡから選択される。そして、変更ルート探索部５０ｂは運行ルートデータＲ１およびＲ２についてそれぞれ修正して、乗換地Ｚを経由させた修正運行ルートデータＲ１’および修正運行ルートデータＲ２’（図７参照）を探索する。

その上で修正運行ルートデータＲ１’およびＲ２’について、距離の増加や乗り換え時間を検証し、車両ＣａおよびユーザＵｂにとって効率的であるかを判断するとともに、他の車両ＣｂおよびユーザＵａ，Ｕｃにとって不都合がないかを判断する。この場合、車両ＣｂやユーザＵａ，Ｕｃにとっても乗換地Ｚを経由しても大きな不利益はないと判断されたものとする。特に、ある程度長い距離を走行する際には一般的に途中で休憩を取るものであり、乗換地Ｚを休憩地の一つとすれば実質的に到着時間の遅れはない。また、高速道路であればＳＡまたはＰＡに寄っても走行距離の増加はほとんどない。

なお、車両Ｃａと車両Ｃｂが搬送するユーザＵの合計が複数ある場合に、ルート探索処理部４８では個別のユーザＵについて効率条件を満たすように前乗換地を探索して、最も効率が高くなるように修正運行ルートデータＲ１’と修正運行ルートデータＲ２’とを探索する。ここでは、ユーザＵｂを乗換地Ｚで乗り換えさせる修正運行ルートデータＲ１’およびＲ２’が最も効率が高くなると判断したものとする。また、効率的な修正運行ルートデータＲ１’，Ｒ２’が存在しない場合には車両Ｃａと車両Ｃｂとの間でのユーザＵの乗り換え検討処理は終了する。

上記の効率条件データ５０ｃの内容に基づいて総合的に勘案し、効率が向上すると判断されると、通知処理部５２はディスプレイ２２ａに修正運行ルートデータＲ１’およびＲ２’を表示出力するとともにスピーカ２４ａからの音声・音響出力により乗換地ＺにおけるユーザＵｂの乗り換えにかかる情報をドライバＤａに通知する。この情報はドライバＤａからユーザＵａ，Ｕｂにも通知される。この乗り換えにかかる情報についてドライバＤａ、ユーザＵａ，Ｕｂはそれぞれ同意したものとする。

また、ステップＳ１１２において、通知処理部５２は同様の情報を車両ＣｂのドライバＤｂに通知させる手続きとして、車々間通信によって車両Ｃｂに乗り換えの問い合わせの通信をする。車両Ｃｂのナビゲーション装置１６ｂでは、得られた情報をディスプレイ２２ａに表示出力するとともにスピーカ２４ａから音声・音響出力してドライバＤｂに通知する。この情報はドライバＤｂからユーザＵｃにも通知される。情報には修正運行ルートデータＲ１’、Ｒ２’、乗換地Ｚとその予想乗換時刻、および乗り換えるユーザＵｂとその荷物量にかかるデータが含まれる。

ステップＳ１１３において、通知・問い合わせを受けた車両Ｃｂでは、ドライバＤｂおよびユーザＵｃが受信して表示された情報を基に乗り換え受入の可否を判断する。そして、乗り換えを承諾すれば契約が成立するのでその旨を車両Ｃａに返信する。契約が成立すれば、ユーザＵａとドライバＤｂとの相互間で相手の連絡先が通知される。またこれらの情報はサーバ１４にも通知する。通知を受けたサーバ１４は、ステップＳ１１４で車両Ｃａ，Ｃｂに確認通知を送信する。ドライバＤａ，ＤｂおよびユーザＵａ，Ｕｂ，Ｕｃのうちいずれかが乗り換えの拒否または乗換地経由の許否をした場合には、改めて別のマッチングやルートを探索し、または今回の相乗り申込みが不成立であるとしてそれぞれにその旨の通知をする。

ステップＳ１１５において、車両Ｃａのルート情報書換え部５６は元の運行ルートデータＲ１を修正運行ルートデータＲ１’に入れ換え設定し、ルート情報３４として記憶する。同様にステップＳ１１６において、車両Ｃｂのルート情報書換え部５６は元の運行ルートデータＲ２を修正運行ルートデータＲ２’に入れ換え設定し、ルート情報３４として記憶する。そして車両Ｃａ，Ｃｂは修正運行ルートデータＲ１’，Ｒ２’に従って乗換地Ｚに向かう。車両Ｃａ，Ｃｂはルート案内部４２によって明示的に乗換地Ｚへと案内される。このとき相互の車両Ｃでは車々間通信により相手の位置を確認し、ディスプレイ２２ａに自車両Ｃに加えて乗換車両Ｃ’の位置も表示すると、相互の位置確認が可能になる。

ステップＳ１１７において、車両Ｃａ，Ｃｂが乗換地Ｚに到着すると、ルート案内部４２がドライバＤａ，Ｄｂに到着を知らせる。このとき、ルート案内部４２は自車両Ｃが乗換地Ｚに到着したことと、乗換車両Ｃ’が乗換地Ｚに到着したこととを個別に案内するとよい。ルート案内部４２はさらにユーザＵｂの乗り換えを促す。そして、ユーザＵｂは自分の荷物とともに車両Ｃａから車両Ｃｂに乗り換える。ユーザＵｂの乗り換えについては、車両Ｃａおよび車両Ｃｂが同時刻に乗換地Ｚにいる必要はなく、ユーザＵｂの承諾があれば車両Ｃａは、該ユーザＵａを乗換地Ｚで降ろした後に車両Ｃｂの到着を待たずに出発してもよい。乗換地Ｚは商業施設や交通施設から選択されていることから、例えばユーザＵｂが食事や買い物をする希望する場合もあり、その場合ユーザＵｂの予想待ち時間はある程度長く設定されていてもよい。乗り換えの事実は相互のナビゲーション装置１６に記録するとともに、サーバ１４にも通知するとよい。

そして、車両ＣａはユーザＵａを乗せたまま再出発し、インターチェンジＩＣ３を経由してステップＳ１１８で目的地Ｙ１に到着する。車両ＣａにはユーザＵｂが乗っていないのでその先の目的地Ｙ２に行く必要はない。

一方の車両Ｃｂは、ユーザＵｂ，Ｕｃを乗せて再出発し、インターチェンジＩＣ３を通過し、さらにインターチェンジＩＣ４を経由してステップＳ１１９で目的地Ｙ２に到着する。ユーザＵｂは当初予定の運行ルートデータＲ１に含まれている目的地Ｙ１を経由することなく、またインターチェンジＩＣ３で降りることなく直接的に目的地Ｙ２に行くことができる。

目的地Ｙ１，Ｙ２に到着した車両Ｃａ，Ｃｂはサーバ１４にユーザＵの搬送が終了したことを報告する。これを受けてサーバ１４はステップＳ１２０で必要な後処理を行う。この後処理は、例えば走行ログの記録、ドライバＤに対するユーザＵの評価受け付け、ユーザＵに対するドライバＤの評価受け付け、および精算処理などである。

（第２の運行ルート判断例）
次に、第２の運行ルート判断例について図９および図１０を参照しながら説明する。

図９に示すように、第２の運行ルート判断例では、第１の運行ルート判断例と同様に、ユーザＵａが出発地Ｘ１から目的地Ｙ１へ向かい、ユーザＵｂが出発地Ｘ２から目的地Ｙ２へ向かうものとする。車両Ｃａは出発地Ｘ１の近くにいるものとする。車両Ｃｂは乗車予定のユーザＵがなく、例えば単にドライブを楽しんでいたり、またはいずれかの場所で待機しているものとする。この場合、車両Ｃｂの運行ルートデータＲ２としては自由走行状態であることがサーバ１４に通知され、車両状況把握部７８（図４参照）に記録されている。図９では、車両Ｃｂの自由走行状態にかかる運行ルートデータＲ２を円形矢印で示している。

図１０のステップＳ２０１～Ｓ２０５は、上記のステップＳ１０１～Ｓ１０５と同じである。そして、ステップＳ２０６において車両Ｃａと車両Ｃｂとの間で車々間通信が成立したものとする。

ステップＳ２０７では、情報を受けたナビゲーション装置１６ａまたは１６ｂがルート再探索の処理を行う。処理を担当する側では、効率条件データ５０ｃに基づき、各車両Ｃおよび各ユーザＵのそれぞれについて個別にまたは総合的にどのようなルートを辿ることが効率的かを考慮して運行ルートデータＲ１および運行ルートデータＲ２に基づいて再探索を行う。

またこのとき、車両Ｃｂについては走行予定のルートが実質的に存在していないことから、これを考慮する必要がなく、または考慮の重み付けを小さくしてもよい。特に、車両ＣｂのドライバＤｂがドライブ好きであったり、同乗者を歓迎する者である場合、その旨がドライバデータベース７０に登録されていれば、車両Ｃａの側でもその情報をサーバ１４から取得して優先的なマッチングをしてもよいし、車両Ｃｂの側からは車両Ｃａに対して積極的に乗換受け入れの問い合わせをするような設定としてもよい。

これ以降のステップＳ２０８～Ｓ２１６は上記のステップＳ１１２～Ｓ１２０と同様である。ただし、ステップＳ２１２における元の運行ルートデータＲ２を変更した修正運行ルートデータＲ２’に入れ換える処理については、実質的には修正運行ルートデータＲ２’を新規設定するのと同じになる。

この第２の運行ルート判断例では第１の運行ルート判断例と同様に、車両Ｃａは２つの目的地Ｙ１，Ｙ２へ行くよりも最初の目的地Ｙ１到着時点で搬送が終了することから、目的地Ｙ２まで行く必要がなくて運行距離および運行時間の面から効率的である。ユーザＵｂにとっても目的地Ｙ１を経由することなく自らの目的地Ｙ２へ直接的に行けることから時間的に効率的である。さらに、車両ＣｂのドライバＤｂにとっては同乗者が得られるとともにドライブの目的ができて有意義となる。

（第３の運行ルート判断例）
次に、第３の運行ルート判断例について図１１および図１２を参照しながら説明する。

図１１に示すように、第３の運行ルート判断例では、ユーザＵａが出発地Ｘ１から目的地Ｙへ向かい、ユーザＵｂが出発地Ｘ２から目的地Ｙへ向かうものとする。車両Ｃａは出発地Ｘ１の近くにおり、車両Ｃｂは出発地Ｘ２の近くにいるものとする。この場合の出発地Ｘ１と出発地Ｘ２は離れていてもよいが、目的地Ｙから見てほぼ同方向にあるものとする。

図１２のステップＳ３０１は、上記のステップＳ１０１と同じである。ステップＳ３０２において、サーバ１４はユーザＵａと車両Ｃとのマッチングを行う。この場合、ユーザＵａの搬送は出発地Ｘ１の近くにいる車両Ｃａによる搬送が適当であると判断される。さらにステップＳ３０３において、車両ＣａがユーザＵａを出発地Ｘ１から目的地Ｙへ搬送する運行ルートデータＲ１を探索する。この運行ルートデータＲ１では、車両Ｃａはまず出発地Ｘ１に行ってユーザＵａを乗車させてから目的地Ｙへ向かう設定とする。そしてステップＳ３０４において、サーバ１４はユーザＵａに対しては運行ルートデータＲ１の情報と車両Ｃａの情報とを通知し、車両Ｃａに対しては運行ルートデータＲ１の情報とユーザＵａの情報とを通知し、それぞれ諾否の問い合わせをする。双方から承諾が得られると契約が成立する。契約成立の後、車両Ｃａは運行ルートデータＲ１に従い、出発地Ｘ１でユーザＵａを乗車させて目的地Ｙへ向かう。

一方、ステップＳ３０５ではユーザＵｂからサーバ１４に対して利用申し込みがあったとする。サーバ１４ではステップＳ３０６～Ｓ３０８において、上記のステップＳ３０２～Ｓ３０４と同様に車両ＣｂとユーザＵｂとをマッチングして出発地Ｘ２から目的地Ｙに至る運行ルートデータＲ２を探索し、双方に問い合わせ・承諾・契約成立させる。そして車両Ｃｂは運行ルートデータＲ２に従い出発地Ｘ２でユーザＵｂを乗車させて目的地Ｙへ向かう。ここで、車両Ｃａの運行ルートデータＲ１と車両Ｃｂの運行ルートデータＲ２とは後半部分がほとんど一致しているものとする。

そして、ステップＳ３０９では同方向へ向かう車両Ｃａと車両Ｃｂとの間で車々間通信が行われ、前記のステップＳ１１０と同様の情報交換が行われる。

ステップＳ３１０では、情報を受けたナビゲーション装置１６ａまたは１６ｂで処理を担当する側では、効率条件データ５０ｃに基づき、各車両Ｃおよび各ユーザＵのそれぞれについて個別にまたは総合的にどのようなルートを辿ることが効率的かを考慮して運行ルートデータＲ１および運行ルートデータＲ２に基づいて再探索を行う。

この第３の運行ルート判断例の場合（図１１参照）、車両Ｃａに乗車中のユーザＵａと車両Ｃｂに乗車中のユーザＵｂはともに目的地Ｙへ向かい、しかも運行ルートデータＲ１と運行ルートデータＲ２とは後半部分がほとんど一致していることから、ユーザＵａとユーザＵｂはいずれかの車両Ｃに同乗した方が効率的であると判断される。

そこで、乗換地探索部５０ａは、まずユーザＵａまたはユーザＵｂを車両Ｃａまたは車両Ｃｂに乗り換えさせるのに適当な乗換地Ｚを地図データ３２から探索する。これは上記のステップＳ１１１にも含まれる処理である。変更ルート探索部５０ｂは、さらに車両ＣａのユーザＵａを車両Ｃｂに乗り換えさせるのか、それとも車両ＣｂのユーザＵｂを車両Ｃａに乗り換えさせるのか、いずれが適当かを判断する。この判断も効率条件データ５０ｃを参照しながら行われる。例えば車両ＣａはユーザＵａの搬送後に出発地Ｘ１の近くへ戻ることが想定されていてしかも出発地Ｘ１が目的地Ｙからある程度遠い場合には、復路の距離と時間とを考慮すれば車両Ｃａは乗換地ＺでユーザＵａの搬送を終了し、車両Ｃｂが目的地Ｙまで行くことが効率的であると判断される。

そして、変更ルート探索部５０ｂは、車両Ｃａの運行ルートデータＲ１を、乗換地Ｚで終了するように変更した修正運行ルートデータＲ１’を探索するとともに、車両Ｃｂの運行ルートデータＲ２を修正して乗換地Ｚを経由して目的地Ｙへ行くようにした修正運行ルートデータＲ２’を探索する。修正運行ルートデータＲ１’は乗換地Ｚで終了するが、広義には乗換地Ｚを経由していると言える。

ステップＳ３１１～Ｓ３１６は上記のステップＳ１１２～Ｓ１１７と同様であるが、ステップＳ３１６でユーザＵａの乗り換えが行われた後、車両Ｃａは相乗りが終了するのでその時点でサーバ１４に対して終了報告をする。車両Ｃａはフリーとなるので、例えば、その近くの出発地Ｘ３から別のユーザＵｃを同乗させてもよい。一方、車両ＣｂはユーザＵａ，Ｕｂを乗車させて修正運行ルートデータＲ２’に従って目的地Ｙへ向かい、ステップＳ３１７で到着して終了報告をする。サーバ１４はステップＳ３１８で後処理を行う。

このような第３の運行ルート判断例によれば、車両Ｃａについては運行距離と運行時間とを短縮することができ、車両Ｃｂについては運行距離と運行時間とがほとんど増加することがなく、総合的にみて効率的となる。なお、この第３の運行ルート判断例では、当初は目的地Ｙへ向かっていた車両Ｃａが何らかの理由により異なる目的地へ向かうことになった場合（例えばユーザＵｃの利用申し込みに対応するために出発地Ｘ３へ向かうことになった場合）においても、同様に適用可能であることは容易に理解されるであろう。また、車両Ｃａが目的地を変更するのはドライバＤａの都合・判断によるものでもよいし、サーバ１４からの指示によるものでもよい。

上記の第１～第３の運行ルート判断例では、車両Ｃの出発地Ｘと目的地Ｙは、ユーザＵの利用申し込みに基づいて設定されており、ユーザＵにとっての利便性が高まっている。

また上記の第１～第３の運行ルート判断例では、当初の運行ルートデータＲ１およびＲ２に対して乗換地Ｚを経由するように探索・変更するのは車両Ｃａのナビゲーション装置１６ａまたは車両Ｃｂのナビゲーション装置１６ｂとしたが、このような処理はサーバ１４の変更ルート探索部８０ｃで行ってもよい。この場合、ユーザＵから利用申し込みを受信した時点で車両ＣとユーザＵとのマッチングと、乗換地Ｚの探索と、該乗換地Ｚを経由する修正運行ルートデータＲ’の探索を行った上で各車両Ｃおよび各ユーザＵに対して承諾問い合わせを行ってもよい。すなわち、車両状況把握部７８は３以上の車両について状況を把握しており、マッチング部７６がユーザＵの出発地Ｘと目的地Ｙとに基づいて車両状況把握部７８で把握する車両Ｃの中から車両Ｃａおよび車両Ｃｂを選択してもよい。

具体的には、車両Ｃａ，Ｃｂから定期的に取得されて車両状況把握部７８に記憶されている運行ルートデータＲ１，Ｒ２を参照し、ルート探索処理部８０の処理により、運行ルートデータＲ１，Ｒ２が乗換地Ｚを含むようにした修正運行ルートデータＲ１’，Ｒ２’を探索する。そして、受付・問い合わせ部７４の作用下に修正運行ルートデータＲ１’，Ｒ２’およびその他の情報を各車両Ｃのディスプレイ２２ａやスピーカ２６ａに出力させ、ドライバＤａ，Ｄｂにそれぞれ通知する。この後の承諾・乗車の手順は上記のとおりである。

（第４の運行ルート判断例）
次に、第４の運行ルート判断例について図１３および図１４を参照しながら説明する。

図１３に示すように、第４の運行ルート判断例では、車両Ｃａが出発地Ｘ１から目的地Ｙ１へ向かい、車両Ｃｂが出発地Ｘ２から目的地Ｙ２へ向かい、ユーザＵａが出発地Ｘ１から目的地Ｙ２へ向かうものとする。出発地Ｘ１から目的地Ｙ１へ向かう運行ルートデータＲ１と出発地Ｘ２から目的地Ｙ２へ向かう運行ルートデータＲ２とは途中で近くを通るものとする。

図１４のステップＳ４０１では、車両Ｃａが出発地Ｘ１から目的地Ｙ１へ向かう運行ルートデータＲ１を探索・設定しその予定日時とともにサーバ１４に送信する。同様に、ステップＳ４０２では、車両Ｃｂが出発地Ｘ２から目的地Ｙ２は向かう運行ルートデータＲ２を探索・設定しその予定日時とともにサーバ１４に送信する。このような車両Ｃについての運行予定は予め複数を送信しておいてもよい。また、例えば毎週の定期的な運行予定を送信しておいてもよい。サーバ１４はステップＳ４０３において、受け取った情報を車両状況把握部７８によって記憶する。

ステップＳ４０４において、ユーザＵａは、出発地Ｘ１から目的地Ｙ２へ向かう希望について利用申し込みの入力および送信の処理を行う。なお、車両Ｃによる送信処理であるステップＳ４０１，Ｓ４０２とユーザＵによる送信処理であるステップＳ４０４は順序を逆として、１以上のユーザＵからの利用申し込み情報が予めサーバ１４に記憶されていてもよい。

ステップＳ４０５においてサーバ１４のマッチング部７６はユーザＵと車両Ｃとのマッチングを行う。この場合、運行ルートデータＲ１および運行ルートデータＲ２は、ユーザＵａの出発地Ｘ１および目的地Ｙ２と一方は同じであるが他方は異なっているため、車両Ｃａまたは車両Ｃｂのいずれか１台でユーザＵａを搬送することはできないと判断される。

そして、マッチング部７６はユーザＵａを途中で乗り換えさせることにして、２以上の車両Ｃで搬送可能な組み合わせがないか調べる。ユーザＵａと車両Ｃａは同じ出発地Ｘ１から出発し、ユーザＵａと車両Ｃｂは同じ目的地Ｙ２へ向かうこととなっており、しかも運行ルートデータＲ１と運行ルートデータＲ２はそれぞれ途中で近くを通ることが確認される。これを受けて、乗換地探索部５０ａは運行ルートデータＲ１と運行ルートデータＲ２が近接する付近で適当な乗換地Ｚを探索する。

ステップＳ４０６において、変更ルート探索部５０ｂは運行ルートデータＲ１およびＲ２についてそれぞれ乗換地Ｚを経由するルート探索を行い、変更された修正運行ルートデータＲ１’（図１３参照）および修正運行ルートデータＲ２’を得る。

その上で修正運行ルートデータＲ１’およびＲ２’について、距離の増加や乗り換え時間を検証し、車両Ｃａ，ＣｂおよびユーザＵａにとって効率的であるかを判断する。この判断は効率条件データ５０ｃに基づく。次にステップＳ４０７において、サーバ１４は車両Ｃａ、車両Ｃｂおよびに対して修正運行ルートデータＲ１’、修正運行ルートデータＲ２’の情報とユーザＵａにかかる情報を送信し、ユーザＵａに対しては修正運行ルートデータＲ１’、修正運行ルートデータＲ２’の情報と車両Ｃａ，Ｃｂにかかる情報を送信することによりその諾否を問い合わせる。三者に対しては、特に乗換地ＺでユーザＵａを乗り換えさせることを明示的に知らせる。三者から承諾が得られた場合には契約が成立し、サーバ１４はその旨を三者に返信する。これは上記のステップＳ１０５と同様である。

そして、ステップＳ４０８では車両Ｃａが運行ルートデータＲ１を修正運行ルートデータＲ１’に入れ換え設定し、ステップＳ４０９では車両Ｃｂが運行ルートデータＲ２を修正運行ルートデータＲ２’に入れ換え設定する。ステップＳ４１０で出発予定時刻になれば、車両Ｃａは出発地Ｘ１でユーザＵａを同乗させて修正運行ルートデータＲ１’に従って出発する。一方の車両Ｃｂも自身の出発予定時刻に出発地Ｘ２から修正運行ルートデータＲ２’に従って出発する。

ステップＳ４１１で車両Ｃａおよび車両Ｃｂはそれぞれ乗換地Ｚに到着し、ここでユーザＵａは車両Ｃｂに乗り換える。車両ＣａはユーザＵａの搬送が終了したのでサーバ１４に終了報告をする。車両Ｃｂは乗換地Ｚを出発し、さらに修正運行ルートデータＲ２’に従って走行し、やがてステップＳ４１２で目的地Ｙ２に到着するとユーザＵａを下車させ、サーバ１４に終了報告をする。ステップＳ４１３でサーバ１４は後処理を行う。

このような第４の運行ルート判断例では、ユーザＵａはいずれか１台の車両Ｃに同乗して目的地Ｙ２に行くことができない場合であっても、車両状況把握部７８は３以上の車両から２以上の車両Ｃを選び出す。そしてユーザＵａはこれらの車両Ｃを乗り継いで目的地Ｙ２へ行くことができ、いろいろな場所への相乗りが実現する。ユーザＵａが向かう目的地は、乗換地Ｚから目的地Ｙ２までの途中地Ｙ２’であってもよい。

また、第４の運行ルート判断例では、ドライバＤは自らの当初予定である運行ルートデータＲにほぼ沿って運転を行えばよく、好都合である。

上述したように各運行ルート判断例では、サーバ１４またはナビゲーション装置１６でそのプログラム３０または６６の処理により、車両Ｃａの運行ルートデータＲ１と車両Ｃｂの運行ルートデータＲ２とを比較して効率条件データ５０ｃ，８０ｄの効率条件を満たすように、車両Ｃａまたは車両Ｃｂの少なくとも一方が搬送するユーザＵを他方に乗り換えさせる乗換地Ｚを探索する。そして、運行ルートデータＲ１を修正して乗換地Ｚを経由させた（乗換地Ｚを終点とする場合を含む）ようにした修正運行ルートデータＲ１’と運行ルートデータＲ２を修正して乗換地Ｚを経由させた修正運行ルートデータＲ２’とを探索し、車両Ｃａおよび車両Ｃｂのディスプレイ２２ａやスピーカ２４ａから出力させる。修正運行ルートデータＲ１’および修正運行ルートデータＲ２’の通知を受けたドライバＤａ，Ｄｂは、適切であると判断した後に乗換地ＺでユーザＵの乗り換えを行うことができる。これにより、ユーザＵの途中乗り換えが実現され、該ユーザを効率的に搬送することができる。

なお、上記した各運行ルート判断例では様々なバリエーションを取り得る。例えば１人のユーザＵは２以上の乗換地Ｚで乗り換えを行い、３以上の車両Ｃに同乗してもよい。１台の車両Ｃは修正運行ルートデータＲ’の途中の２以上の乗換地Ｚで異なるユーザＵの乗り換えをさせてもよい。１か所の乗換地Ｚでは３以上の車両Ｃの間で２以上のユーザＵが乗り換えを行ってもよい。ユーザＵが車両Ｃに乗車する出発地Ｘ、およびユーザＵが車両Ｃから下車する目的地ＹについてはユーザＵとドライバＤとの間である程度調整してもよい。ナビゲーション装置１６で行われる処理の一部またはそのほとんどはサーバ１４に委託処理させてもよいし、ナビゲーション装置１６とサーバ１４とは協働的に運行ルート判断をしてもよいし、双方のデータ（例えば地図データ３２，６８）は共有しあるいは相互補完してもよい。

上記した各運行ルート判断例では、車両ＣはユーザＵを搬送するものとしたが、ユーザＵではなくて荷物（搬送対象）を搬送する場合においても同様に実施可能であり、同様の効果が得られる。搬送対象としてユーザＵと荷物とを混載してもよい。各車両Ｃの運転主体はドライバＤに限らず、自動運転装置（半自動運転式を含む）でもよい。この場合の自動運転装置はナビゲーション装置１６と一体的なものであってもよい。出発地Ｘから目的地Ｙまでは遠距離でもよいし近距離でもよい。相乗り支援システム１０は様々な利用形態があるが、例えばスポーツイベント、音楽イベント、文化イベント、空港、主要駅、災害被災地など多人数が集まる場所へ向かうドライバＤやユーザＵによって好適に利用され得る。

本発明は、上記した実施形態に限定されるものではなく、本発明の主旨を逸脱しない範囲で自由に変更できることは勿論である。また、本発明が実施される場合には、その国や地域の法制の範囲内で実施されるのはもちろんであり、さらに法制に沿うように変更できることはもちろんである。

１０ 相乗り支援システム
１２ 通信網
１４ サーバ（運行ルート判断装置）
１６，１６ａ，１６ｂ，１６ｃ ナビゲーション装置（運行ルート判断装置）
１８，１８ａ，１８ｂ，１８ｃ 携帯端末
１９ アプリケーション
３０，６６ プログラム（運行ルート判断プログラム）
４８，８０ ルート探索処理部
５０ａ，８０ｂ 乗換地探索部
５０ｂ，８０ｃ 変更ルート探索部
５０ｃ，８０ｄ 効率条件データ
５２ 通知処理部
７６ マッチング部
Ｃ，Ｃａ，Ｃｂ，Ｃｃ 車両
Ｄ，Ｄａ，Ｄｂ，Ｄｃ ドライバ（運転主体）
Ｒ，Ｒ１，Ｒ２ 運行ルートデータ
Ｒ’、Ｒ１’，Ｒ２’ 修正運行ルートデータ
Ｕ，Ｕａ，Ｕｂ，Ｕｃ ユーザ（搬送対象）
Ｘ１，Ｘ２，Ｘ３ 出発地
Ｙ，Ｙ１，Ｙ２ 目的地
Ｚ 乗換地

Claims (11)

1. 第１車両の第１運転主体によって出発地と目的地が設定された第１運行ルートデータおよび第２車両の第２運転主体によって出発地と目的地が設定された第２運行ルートデータを取得し、前記第１運行ルートデータと前記第２運行ルートデータとを比較して効率条件を満たすように、前記第１車両または前記第２車両の少なくとも一方が搬送する搬送対象を他方に乗り換えさせる乗換地を探索し、前記第１運行ルートデータを修正して前記乗換地を経由させた第１修正運行ルートデータと前記第２運行ルートデータを修正して前記乗換地を経由させた第２修正運行ルートデータとを探索して出力するルート探索処理部
   を有する運行ルート判断装置。
2. 前記効率条件は、前記第１車両または前記第２車両の運行時間または運行距離の少なくとも一方を短縮させる条件である請求項１に記載の運行ルート判断装置。
3. 前記効率条件は、前記搬送対象がその目的地に到着するまでの時間または距離の少なくとも一方を短縮させる条件である請求項１に記載の運行ルート判断装置。
4. 前記第１運行ルートデータおよび前記第２運行ルートデータには、それぞれ搬送する前記搬送対象の数、大きさまたは重量と、さらに追加搬送可能な前記搬送対象の数、大きさまたは重量が含まれ、
   前記ルート探索処理部は、乗り換えさせる前記搬送対象の数、大きさまたは重量が相互に適合する場合に前記乗換地を探索しさらに前記第１修正運行ルートデータおよび前記第２修正運行ルートデータを探索して出力する処理を実行する請求項１～３のいずれか１項に記載の運行ルート判断装置。
5. 前記ルート探索処理部は、前記第１車両および前記第２車両の到着予想時刻に利用可能な商業施設または交通施設から前記乗換地を選択する請求項１～４のいずれか１項に記載の運行ルート判断装置。
6. 通信網を介して受信した情報から３以上の車両についてそれぞれの状況を把握する車両状況把握部と、
   前記搬送対象の出発地と目的地とに基づき、前記車両状況把握部で把握する前記車両の中から前記第１車両および前記第２車両を選択するマッチング部と、
   を有する請求項１～５のいずれか１項に記載の運行ルート判断装置。
7. 前記第１車両と前記第２車両が搬送する前記搬送対象の合計が複数ある場合に、
   前記ルート探索処理部は、個別の前記搬送対象について前記効率条件を満たすように前乗換地を探索して、最も効率が高くなるように前記第１修正運行ルートデータと前記第２修正運行ルートデータとを探索する請求項１～６のいずれか１項に記載の運行ルート判断装置。
8. 前記第１運行ルートデータは前記搬送対象に基づいて出発地と目的地が設定され、および／または、前記第２運行ルートデータは前記搬送対象に基づいて出発地と目的地が設定される請求項１～７のいずれか１項に記載の運行ルート判断装置。
9. 前記第１車両は前記第１運行ルートデータを前記第２車両に対して車々間通信で送信し、前記第２車両は前記第２運行ルートデータを前記第１車両に対して車々間通信で送信し、
   前記第１車両または前記第２車両の一方が備える前記ルート探索処理部によって、前記第１修正運行ルートデータと前記第２修正運行ルートデータとが探索され、他方に対して車々間通信で送信される請求項１～８のいずれか１項に記載の運行ルート判断装置。
10. 第１車両の第１運転主体によって出発地と目的地が設定された第１運行ルートデータおよび第２車両の第２運転主体によって出発地と目的地が設定された第２運行ルートデータを取得し、前記第１運行ルートデータと前記第２運行ルートデータとを比較して効率条件を満たすように、前記第１車両または前記第２車両の少なくとも一方が搬送する搬送対象を他方に乗り換えさせる乗換地を探索し、前記第１運行ルートデータを修正して前記乗換地を経由させた第１修正運行ルートデータと前記第２運行ルートデータを修正して前記乗換地を経由させた第２修正運行ルートデータとを探索して出力することをコンピュータに実行させる運行ルート判断プログラム。
11. 第１車両の第１運転主体によって出発地と目的地が設定された第１運行ルートデータおよび第２車両の第２運転主体によって出発地と目的地が設定された第２運行ルートデータを取得し、前記第１運行ルートデータと前記第２運行ルートデータとを比較して、記憶部から読み出した効率条件を満たすように、前記第１車両または前記第２車両の少なくとも一方が搬送する搬送対象を他方に乗り換えさせる乗換地を探索し、前記第１運行ルートデータを修正して前記乗換地を経由させた第１修正運行ルートデータと前記第２運行ルートデータを修正して前記乗換地を経由させた第２修正運行ルートデータとを探索して出力することをコンピュータが実行する運行ルート判断方法。

Images