JP7058509B2 - 車両管理サーバおよびコンピュータプログラム - Google Patents

Description

本発明は、カーシェアリングにおける使用終了時刻をユーザが守り易くするための情報技術に関する。

複数の車両を複数のユーザが共同で使用するカーシェアリングシステムを利用する利用者（会員登録を済ませたユーザ）は、カーシェアリング用の自動車（以下、「シェアカー」）を確保している駐車場に出向いて、直接利用する場合のほか、利用予定の時間帯などを事前に連絡する予約制度を活用する。
その予約制度は、コールセンターに電話を入れて会話によって予約をする場合と、データ通信によって所定事項を送信するとともに予約した内容にてサービスが受けられるか否かを受信する場合とがある。
後者は、パーソナルコンピュータにて通信する場合のほか、携帯情報端末（いわゆるスマートフォンなど）のメール機能やウェブ閲覧機能にて通信する場合がある。

カーシェアリング事業者は、ユーザへのサービス提供やサービス対価徴収の円滑化などのため、会員登録を予めユーザに求めることが一般的である。すなわち、会員登録をした会員ユーザに対してのみ、カーシェアリングが利用できるようにしている。

さて、カーシェアリングによってシェアカーを運転し始めたものの、たとえば渋滞に巻き込まれたりして、予定していた時刻に返却することが困難になるような事態が発生したとする。
そのような事態においては、利用開始時と同じように予約が必要（正確には「利用時間の延長」）となる。利用者が自ら定めた利用終了時刻を守れないと、複数の利用者が一台の乗用車をシェアするという「カーシェアリング本来の趣旨」を逸脱してしまう。とはいえ、避けられない事態として、ある程度の頻度で発生してしまう。したがって、カーシェアリング事業者としては、そのような事態へ対応できるシステムを提供しなければならない。

特許文献１に開示された技術では、会員ユーザがシェアカーを運転中において、多機能カーナビゲーション装置の画面を操作するだけで、シェアカーの利用延長が簡易に実行できる情報処理システムが開示されている。

ところで、有料道路を管理運営する事業体（有料道路事業者）は、管理運営に掛かる道路が渋滞してしまうことが、事業としての損失を招くことに等しい。渋滞の原因は様々であるが、有料道路の交通量が少ない早朝深夜の時間帯へ有料道路ユーザの利用を分散させることは、渋滞原因を減らすことに繋がる。そのため、早朝深夜の時間帯で通行料金（サービス対価）を割り引くなどの制度を有料道路ユーザへ告知し、活用を呼びかけている。

本願に関わる先行技術を知るため、以下の検索式によって、先行する特許文献を抽出した。
検索式＝[有料道路/AC]*[分散/TX]*[渋滞/AC]
この検索式で２０件の特許出願がヒットし、その２０件から特許文献２，３，４を抽出して検討した。

特許文献２では、ＥＴＣ（Ｅｌｅｃｔｒｏｎｉｃ ＴｏｌｌＣｏｌｌｅｃｔｉｏｎ Ｓｙｓｔｅｍ）システムを利用し、料金ゲート設備の削減、料金支払い手続きの簡素化、料金体系の適正化および高速道路網の利用効率の向上に貢献する有料道路料金徴収システムが開示されている。

特許文献３には、到達時間や距離等に従った到達圏を算出する技術を発展させ、到達圏の変動要因の影響度合いを理解することが困難であるという問題点を解決した探索結果生成装置、探索結果生成システム、サーバ装置などが開示されている。

特許文献４には、道路の利用効率を高めることで道路の渋滞を緩和させるように有料道路の課金を実行する道路課金システムが開示されている。

特許文献５には、渋滞区間を避けて走行した車両に対し通行料金を割引する通行料金割引装置が開示されている。

特開２０１１－１５９０７２号公報 特開２００４－６２５４０号公報 特開２０１３－４０８１４号公報 特開２０１６－１４６０１３号公報 特開２０１４－６３４１６号公報

特許文献１に開示された技術は、会員ユーザが予定していた時刻を延長したいという場合であって延長可能な場合には、会員ユーザにとってもカーシェアリング事業者にとっても効果的であり、好ましい。
しかし、その会員ユーザが使用中の車両について、次の時間帯に別の会員ユーザによる予約が入っている場合には、特許文献１に開示された技術ではカーシェアリング事業者にとって根本的な解決には繋がらない。その会員ユーザが返却時刻を延長して得られる利益よりも、次の予約をしている会員ユーザに対する処理費用（代車の手配や事業者都合による返金などの諸費用）の方がコスト高であることが多く、好ましくないからである。

特許文献２～５の技術を組み合わせても、会員ユーザが返却時刻を守れるように導くことはできない。
前述した先行技術および解決すべき課題については、カーシェアリング事業を例にして説明したが、レンタカー事業など車両貸し出しサービスにおいては、同様の問題がある。

本発明が解決しようとする課題は、カーシェアリング事業やレンタカー事業などの車両貸し出しサービスにおいて、会員ユーザが返却予定時刻を守れるようなナビゲーション情報を提供することにある。

前述した課題を解決するため、本願では、車両管理サーバに係る第一の発明、第一の発明との通信をする車載機に係る第二の発明、第一の発明に係る車両管理サーバにおいて実行されるコンピュータプログラムに係る第三の発明、および第二の発明に係る車載機において実行されるコンピュータプログラムに係る第四の発明を提供する。

（第一の発明）
第一の発明は、車両共有サービスにおいて用いるサービス対象車両を管理する車両管理サーバに係る（図１１参照）。
この車両管理サーバは、貸し出し中のサービス対象車両の現在位置データを受信する現在位置データ受信手段と、
前記の現在位置データに係るサービス対象車両に関する返却地データ、返却予定時刻、および次の貸し出し予約である次予約データを含む車両管理データを格納している車両管理データベースと、
前記の現在位置データおよび前記の返却地データに関わる渋滞データを取得する渋滞データ取得手段と、
前記の現在位置データおよび前記の返却地データを用いて返却地までのルートを検索するルート演算手段と、
そのルート演算手段が検索したルートを前記の貸し出し中のサービス対象車両へ送信するルート選択肢出力手段と、
を備える。
そして、前記のルート演算手段は、検索したルート毎に返却予想時刻を演算することとし、
前記のルート選択肢出力手段は、前記の渋滞データおよび車両管理データを用いて返却予想時刻が前記の返却予定時刻よりも早くなるルートに係る時刻厳守ルートデータ、および／または返却予想時刻が返却予定時刻よりも遅い場合に最も早いルートに係る最速ルートデータを送信することとする。

（用語説明）
「車両共有サービス」とは、カーシェアリングを管理運営するサービス、およびカーレンタルサービスの両方を指すものとする。
「サービス対象車両」とは、カーシェアリングであれば「シェアカー」、カーレンタルサービスであれば「レンタルされる車両（レンタカー）」を指すものとする。

「渋滞データ」は、たとえば、渋滞情報を提供しているサービス用サーバから受信する。または、定期的に渋滞情報を取得して、車両管理サーバ内へ蓄積しておき、それを用いることとしても良い。
「ルート選択肢出力手段」が送信する「貸し出し中のサービス対象車両」とは、当該サービス対象車両である場合の他、当該サービス対象車両のユーザに係る携帯情報端末（たとえばスマートフォン）であってもよい。

（作用）
貸し出し中のサービス対象車両の現在位置データを、現在位置データ受信手段が受信する。
受信した現在位置データに係るサービス対象車両に関する返却地データ、返却予定時刻、および次の貸し出し予約である次予約データを含む車両管理データを、車両管理データベースが格納している。前記の現在位置データおよび前記の返却地データに関わる渋滞データを、渋滞データ取得手段が取得する。
前記の現在位置データおよび前記の返却地データを用いて、ルート演算手段が返却地までのルートを検索する。ルート演算手段は、検索したルート毎に返却予想時刻を演算する。

そのルート演算手段が検索したルートを前記の貸し出し中のサービス対象車両へルート選択肢出力手段が送信する。ルート選択肢出力手段は、前記の渋滞データおよび車両管理データを用いて返却予想時刻が前記の返却予定時刻よりも早くなるルートに係る時刻厳守ルートデータ、および／または返却予想時刻が返却予定時刻よりも遅い場合に最も早い最速ルートに係る最速ルートデータを送信させる（図１３参照）。

サービス対象車両の現在位置データと返却地データとを用いて、関連する渋滞データを取得し、次予約データにおける貸し出し予約時刻までに返却が可能かどうか、車両管理サーバにおいては概ね把握できる（たとえば、図１３におけるＳ２４）。
次予約データにおける貸し出し予約時刻までに返却が可能であれば、以後のステップを終了しても良い（図１３における「終了」）。ただし、実施レベルであれば、複数のルートは、安い順、返却時刻の早い順、など任意のソート順でルート選択肢出力手段が送信することとなる。

次予約データにおける貸し出し予約時刻までに返却が困難であると判断した場合には、前記の渋滞データおよび車両管理データを用いて返却予想時刻が前記の返却予定時刻よりも早くなるルートに係る時刻厳守ルートデータを検索し、送信する（図１３におけるＳ２８）。
その時刻厳守ルートデータが存在しない場合、すなわち、最も早くなるルートを使っても時間厳守が困難である場合には、最速ルートを優先して表示することとなる（図１３におけるＳ２７）。

（第一の発明のバリエーション１）
第一の発明は、以下のように形成すると、より好ましい。
すなわち、前記のルート選択肢出力手段は、前記のルート演算手段が検索したルートに有料道路が含まれている場合には、当該ルートに料金データを紐付けてサービス対象車両へ送信することとするのである（図６参照）。

（作用）
車両共有サービスは、車両を使用した時間に応じた利用料金をユーザがサービス提供者に対して支払う、というビジネスモデルである。したがって、有料道路を通ることによって支払うこととなる料金と、利用時間が短縮された車両の利用料金とを合算して出力されると、ユーザにとってはトータルの料金が分かりやすい。

（第一の発明のバリエーション２）
第一の発明における前記のバリエーション１は、以下のように形成すると、より好ましい。
すなわち、前記の車両共有サービスが提供するサービス対象車両を利用できる会員に関する利用履歴データを予め格納している会員データベースを備える。
そして、前記のルート選択肢出力手段は、前記のルート演算手段が検索したルートに有料道路が含まれている場合には、当該ルートの料金データを、前記の利用履歴データに基づいて割り引いた割引料金データ（優待プランデータ）としてサービス対象車両へ送信するのである（図１１参照）。

（作用）
利用履歴データに基づいて、所定のユーザを「ヘヴィーユーザ」として、たとえば有料道路の料金を限度とした共有車両の利用料金を割り引く割引料金データ（優待プラン）を作成する。そして、その割引料金データを採用できる会員ユーザが運転するサービス対象車両へ、割引料金データ（またはルート選択肢などのデータへ組み込んで）送信する。
ヘヴィーユーザである会員ユーザは、有料道路を利用することに対する抵抗感を低め、渋滞の軽減にも寄与する。

（第一の発明のバリエーション３）
第一の発明は、以下のように形成してもよい。
すなわち、渋滞緩和策を受信する渋滞緩和策受信手段を備え、
前記のルート演算手段は、前記の渋滞緩和策をも用いて返却地までのルートを検索することとしてもよい（図１５参照）。

渋滞緩和策に関するデータは、別のサーバ（たとえば、道路全般管理サーバ）などから受信する。

（第二の発明）
第二の発明は、第一の発明に係る車両管理サーバを制御するコンピュータプログラムに係る。
すなわち、貸し出し中のサービス対象車両の現在位置データを受信する現在位置データ受信手順と、
前記の現在位置データに係るサービス対象車両に関する返却地データ、返却予定時刻、および次の貸し出し予約である次予約データを含む車両管理データを車両管理データベースへ格納する車両管理データ格納手順と、
前記の現在位置データおよび前記の返却地データに関わる渋滞データを取得する渋滞データ取得手順と、
前記の現在位置データおよび前記の返却地データを用いて返却地までのルートを検索するルート演算手順と、
そのルート演算手段が検索したルートを前記の貸し出し中のサービス対象車両へ送信するルート選択肢出力手順と、
を前記の車両管理サーバに実行させる。
前記のルート演算手順は、検索したルート毎に返却予想時刻を演算することとし、
前記のルート選択肢出力手順は、前記の渋滞データおよび車両管理データを用いて返却予想時刻が前記の返却予定時刻よりも早くなるルートに係る時刻厳守ルートデータ、および／または返却予想時刻が返却予定時刻よりも遅い場合に最も早いルートに係る最速ルートデータを送信することとする。

（第二の発明のバリエーション１）
第二の発明における前記のルート選択肢出力手順においては、前記のルート演算手段が検索したルートに有料道路が含まれている場合には、当該ルートに料金データを紐付けてサービス対象車両へ送信することとすると、より好ましい。

（第二の発明のバリエーション２）
前記のバリエーション1は、以下のようにすることもできる。
すなわち、前記の車両管理サーバには、前記の車両共有サービスが提供するサービス対象車両を利用できる会員に関する利用履歴データを予め格納している会員データベースを備える。 そして、前記のルート選択肢出力手順においては、前記のルート演算手段が検索したルートに有料道路が含まれている場合には、当該ルートの料金データを、前記の利用履歴データに基づいて割り引いた割引料金データとしてサービス対象車両へ送信することとしてもよい。

（第二の発明のバリエーション３）
第二の発明は、以下のように形成してもよい。
すなわち、 渋滞緩和策を受信する渋滞緩和策受信手順を備え、 前記のルート演算手順においては、前記の渋滞緩和策をも用いて返却地までのルートを検索することとしてもよい。

第二の発明に係るコンピュータプログラムは、記録媒体へ格納して提供することもできる。また、別のサーバへ格納した当該コンピュータプログラムを、車両管理サーバへ通信回線を介してインストールすることもできる。

第一の発明によれば、返却予定時刻を守れるようなナビゲーション情報を車両共有サービスのユーザへ提供可能な車両管理サーバを提供することができた。
第二の発明によれば、返却予定時刻を守れるようなナビゲーション情報を車両共有サービスのユーザへ提供可能な車両管理サーバを制御可能なコンピュータプログラムを提供することができた。

一般のカーシェアリングにおける利用予約の様子を示す概念図である。 予約したカーシェアリングに対してサービス電子クーポンを発行する様子を示す概念図である。 電子クーポンの発行を示す概念図である。 従来技術の問題点を整理した図である。 第一の実施形態に係る最短時間ルートの演算とユーザへの提示手順を示す概念図である。 カーシェアユーザが利用中のカーナビゲーション装置へ出力されるルート選択肢やその料金などのデータの提示例を示す概念図である。 第二の実施形態を示す概念図である。 第三の実施形態を示す概念図である。 第四の実施形態を示す概念図である。 第三または第四の実施形態において採用されるカーシェア管理サーバにおける手順を示すフローチャートである。 第五の実施形態を示す概念図である。 第五の実施形態において採用されるカーシェア管理サーバにおける手順を示すフローチャートである。 第五の実施形態のバリエーションを示すフローチャートである。 第五の実施形態のバリエーションを示すフローチャートである。 第六の実施形態を示す概念図である。 第六の実施形態のバリエーションを示す概念図である。 第六の実施形態のバリエーションを示す概念図である。 第七の実施形態を示す概念図である。 第七の実施形態のバリエーションを示す概念図である。 第八の実施形態を示す概念図である。 第八の実施形態のバリエーションを示す概念図である。

以下、本発明の実施形態について、図面（図５から図２１）を参照して説明する。

（図５）
図５は、カーシェアリング事業におけるサービス対象車両（シェアカー）や予め会員登録を済ませた会員（カーシェアユーザ）の管理を実行するカーシェア管理サーバ、有料道路の料金に関する有料道路管理データベース（図中では「ＤＢ」と略記）を保有する有料道路管理サーバ、前記のシェアカー、および各種の道路渋滞データを随時更新している渋滞データベースの関係を示した第一の実施形態である。

カーシェアユーザは、シェアカーを予約する段階で、どこでシェアカーを借りてどこへ返却するか（返却地データ）、使用開始の日時および時刻、返却予定時刻などを入力している。それらのデータは、カーシェア管理サーバの車両管理データベースへ格納されている。

シェアカーには、ルート案内をするのみならず、カーシェア管理サーバとのデータ通信が可能な多機能カーナビゲーション（「多機能カーナビ」と略記）、シェアカーの現在位置に関するデータをカーシェア管理サーバへ送信するＧＰＳ、有料道路の料金精算のためのデータの送受信するＥＴＣが搭載されている。

カーシェア管理サーバには、シェアカーのＧＰＳからの現在位置データを受信する現在位置データ受信手段、前述の車両管理データベース、車両管理データベースのデータおよびカーシェアユーザが多機能カーナビへ入力した目的地データなどを用いて返却地までのルートを検索するルート演算手段、渋滞データを取得する渋滞データ取得手段、ルートおよび料金の選択肢を演算するルート＆料金の選択支援算手段などを備えている。

また、有料道路管理サーバから有料道路料金データを取得して蓄積する有料道路料金データベース、会員ユーザの管理のために会員の属性データや利用履歴データなどを蓄積する会員データベース、会員の利用履歴データなどに基づいて会員に対する優待特典などを蓄積する優待プランデータベース、渋滞データを取得する渋滞データ取得手段、を備えている。

カーシェア管理サーバは、以下のように作動する。
シェアカーの目的地データを車両管理データベースへ蓄積したり、シェアカーの現在位置データを現在位置データ受信手段で取得したりしている。そして、現在位置データ、目的地データ、返却地データ、返却予定時刻などに基づいて、ルート演算手段が現在位置データ（またはシェアカーの貸し出し位置データなど）と返却地データとを結ぶルートを算出する。

算出されたルートに関わる渋滞データを渋滞データ取得手段が取得し、最短時間ルート演算手段が算出されたルートと併せて最短時間ルートを演算する。
最短時間ルートに有料道路が含まれている場合には、その有料道路料金データを加え、ルート＆料金の選択肢演算手段がルート選択肢、返却予定時刻、ルート別料金などを演算して、多機能カーナビへ送信する。

多機能カーナビへ出力されたルート選択肢などの情報をカーシェアユーザ（運転者）が閲覧し、有料道路を含むルートを選択した場合、選択ルート予約データがＥＴＣへ送信される。それによって、有料道路の利用を円滑にする。

当該シェアカーの運転者が会員としてヘヴィーユーザであるような場合、優待プランデータがルート＆料金の選択支援算手段において加味され、有料道路の料金が割り引かれるなどのデータが追加された上で、ルート選択肢の料金データが変更される場合もある。

（図６）
図６では、ルート選択肢の抽出例と、多機能カーナビの画面を介してカーシェアユーザへ提示される様子を、概念的に示している。
多機能カーナビの画面の一部へ地図と、シェアカーの現在位置（または出発地）および返却地（または目的地）と、その両社を結ぶルートＡ，Ｂ，Ｃが表示される。

ルートＡは有料道路Ｙを、ルートＣは有料道路Ｚを含んでいる旨を、ルートＢには有料道路が含まれないが渋滞区間がある旨を表示している。
そして、算出したルートＡ，Ｂ，Ｃのそれぞれに対して、返却時刻が厳守できる可能性、利用予定の有料道路料金、カーシェアリングの利用料金、有料道路とカーシェアリングの料金を合算したトータル料金が演算される。

この事例においては、このユーザが利用しているシェアカーを、別のユーザが使うこととして予約が入っており、返却予定時刻を４５分以上超過することができない、とする。
この場合、ルートＢを選択しないように、多機能カーナビへの出力順位を最下位とする。

図５および図６に示した実施形態によれば、以下のような効果がある。
まず、カーシェアリングの事業者としては、あるシェアカーが使われている場合に、そのシェアカーを使う別のユーザによる予約が入っている場合に、返却予定時刻までに返却を促すような情報をユーザへ提供することができる。それによって、ユーザが返却予定時刻までに返却する確率を上昇させることに寄与する。

ユーザとしては、自らの予定として返却予定時刻までに返却できるような情報を得ることができたり、返却予定時刻までに返却しつつ、カーシェアリングの利用および有料道路の利用のトータル料金を比較することができる情報を得ることができたりする。
その結果、返却予定時刻までの返却を遵守できるだけでなく、利用料金の節約や、自らの予定の繰り上げなどに寄与する情報を得られる。

なお、図示は省略するが、このユーザに対する優待特典がある場合、カーシェア料金の割引が実行されるなどして、出力順が変更される場合もある。
ルートＢを選択しないように、警告を表示する、ルート案内の画面へ移動しない、など、ソフトウェア上の工夫をすることによって、返却時刻を早められるルートを選択するように、ユーザへ示しても良い。

（図７）
図７を用いて、第二の実施形態を説明する。
図７では、図５に示した第一の実施形態と異なり、カーシェア管理サーバにおいて、目的地データ受信手段を備える。そして、ユーザがシェアカーを運転を開始（または再開）する前に多機能カーナビへ入力した目的地データを用いて、すぐにルート演算を実行することとしている点が、異なってくる。

目的地が返却地と異なる場合には、車両管理データベースへ蓄積された返却地データや返却予定時刻などのデータが不要である場合もある。（そのため、車両管理データベースからルート演算手段への矢印を点線で示している。）

なお、図５に示した第一の実施形態と異なり、渋滞データ取得手段を省略しており、最短時間ルート演算手段が直接、渋滞データを取得することとして説明している。渋滞データは時々刻々と変化するので、カーシェア管理サーバ内へ蓄積するのではなく、演算に必要な瞬間に渋滞データベースへアクセスして取得する、という合理性に基づいている。本発明の主要な考え方ではなく、図５および図７を用いて、実施形態としてどちらもあり得る、という趣旨である。

シェアカーの運転者が目的地を変更したり、ある目的地から次の目的地へ移動したりする場合などにおいても、ルートの選択肢を素早く提供することができる。

（図８）
図８を用いて、第三の実施形態を説明する。
図８では、有料道路の閑散期において、時間限定での値下げが実行された場合を示している。
有料道路の管理運営者が利益の最大化を図るため、たとえば時間限定で値下げ（タイムサービス）をするような運用があり得る。このような場合に、カーシェアリングを利用している会員ユーザに向けて、そのタイムサービスの情報を伝達すれば、告知方法としての効率が良いのである。

有料道路管理サーバにおける有料道路管理データベースから、カーシェア管理サーバへ時間限定の値下げデータが送信される。その値下げデータは、カーシェア管理サーバの有料道路料金データベースへ蓄積される。
一方、カーシェア管理サーバにおいては、カーシェアリングサービスを利用中のユーザが運転するシェアカーからは、現在位置データを取得したり、目的地データなどを用いてルート演算手段がルートを演算し、渋滞データを取得しながら最短時間ルート演算手段が最短時間となるルートを演算したりしている。

有料道路料金データベースに蓄積された有料道路料金データが、前記のタイムサービスデータと関係があれば、ルート＆料金の選択肢演算手段がそのタイムサービスデータを反映させてルート選択肢を出力する。
場合によっては（図８に図示した例では）、前記のタイムサービスデータに関わるシェアカーの多機能カーナビに対しては、値下げされた有料道路を用いるルートを最優先で表示させるようにしても良い。

第三の実施形態においては、有料道路の管理運営者が効率良く最新の有料道路料金データを、より多くの運転者へ告知することに寄与するので、利益向上が期待できる。
また、道路資源の有効活用にも寄与することが期待できる。

なお、図８を用いた実施形態では、タイムサービスを例示したが、交通量の制限の必要性などから時間限定での値上げ情報を告知する場合にも、当然用いることができる。
同様に、事故などの原因で緊急に当該有料道路を時間限定で閉鎖する、といった情報の拡散手法としても、用いることができる。

（図９）
図９を用いて、第四の実施形態を説明する。
図９は、図８に示した第三の実施形態のバリエーションであり、有料道路の閑散期において、時間限定での値下げが実行された場合を示している。
図８に示した実施形態との相違点は、図８においては「最短時間ルート演算手段」を備えることとしていたところ、図９に示した実施形態では、「最短時間ルート演算手段」を省略し、渋滞データベースから渋滞データを取得することも省略している点である。

この実施形態では、渋滞データは有料道路管理サーバが取得しており、その渋滞データに応じた有料道路料金の時間限定での改訂を実施する場合に用いられる。

（図１０）
図１０は、前記した第三または第四の実施形態において採用されるカーシェア管理サーバにおける手順をフローチャートにて示したものである。
まず、有料道路データベースから時間限定の値下げデータを取得する（Ｓ１）。
一方、使用中のシェアカーの現在位置データを取得する（Ｓ２）。なお、図８や図９においては、図示の都合でシェアカーは１台としてしか表現していないが、カーシェア管理サーバは管理対象となっているシェアカー全てから現在位置データを随時取得している。

続いて、車両管理データベースへ蓄積されている、現在使用中のシェアカーの目的地データまたは返却地データを取得する（Ｓ３）。以上のようにして収集したデータを用いて、値下げ時間内に、値下げ対象となった有料道路を使う可能性のあるシェアカーか否か、を判断する（Ｓ４）。
値下げ対象となった有料道路を使う可能性のあるシェアカーである場合には、現在位置から目的地または返却地までのルートを演算し、そのルート別の料金も演算する（Ｓ５）。そしてその演算結果を、値下げ対象となった有料道路を使う可能性のあるシェアカーの多機能カーナビへ、値下げする有料道路を最優先でルート表示する（Ｓ６）。

前述のＳ５において、値下げ対象となった有料道路を使う可能性のあるシェアカーか否かを判断しており、使う可能性のないシェアカーの多機能カーナビへはルート表示として出力されない。無関係な情報を送信することによるシェアカー運転手（会員ユーザ）の混乱を防ぎ、通信の無駄（ハードウェア資源の無駄）を防ぐためである。

（図１１）
図１１を用いて、第五の実施形態を説明する。
図１１では、図５に示した第一の実施形態（における説明）と異なり、車両管理データベースから、当該車両に関する次予約データを取得していることとして説明している（図５に示した実施形態においては、次予約データが存在しなかったとして説明したのみであり、発明の構成要件として異なるということではない）。

次予約データには、次の予約者（別の会員ユーザ）が返却地を出発地点として当該シェアカーを使い始める時刻データが含まれている。この次予約データにおける時刻データを基準として、その時刻以前に当該シェアカーが返却可能であるように、ルート選択肢を提示するように作動するのが、この実施形態において説明するカーシェア管理サーバである。

（図１２）
カーシェア管理サーバの作動について、図１２を参照させながら説明する。
図１２では、使用されているシェアカーの現在位置データを取得する（Ｓ１１）。次に、車両管理データベースへ蓄積されている、現在使用中のシェアカーの返却地データを取得する（Ｓ１２）。そして、シェアカーが現在選択しているルートを推測するとともに、そのまま走り続けた場合の到着予定時刻を演算する（Ｓ１３）。このフローチャートでは示していないが、渋滞データを取得する場合もある。

前記の演算結果に基づいて、到着予想時刻が返却時刻に間に合うか否か、すなわち、源ルートを走行していて返却時刻に間に合うかどうかを判断する（Ｓ１４）。そして、到着予想時刻が返却時刻を過ぎているとして演算された場合には、源ルートよりも到着予定時刻が早くなるルートを演算し、そのルートを選択した場合に必要な有料道路の料金データを取得する（Ｓ１５）。
そして、該当するシェアカーの多機能カーナビへ、返却予定時刻での返却が可能なルートを優先して表示させる（Ｓ１６）。具体的には、「現在のルートでは返却予定時刻での返却が困難です。ルート変更をお願いします。」といった表示や音声を多機能カーナビから出力させる。

この実施形態によれば、次予約データが存在している場合であって、現在シェアカーを使用している会員ユーザが現在走行中のルートでは返却予定時刻までに返却ができない可能性がある場合についての対応策を含んでいる。そのため、返却予定時刻に間に合うような使用をするユーザが増えることが期待できる。
なお、は返却予定時刻までに返却ができない可能性が高まった場合において、次予約データに係るユーザに対しては、図２０および図２１に示すような対策を講じることとしている。

（図１３）
カーシェア管理サーバの作動についてのバリエーションを示す図１３を用いて、前述した図１２との相違点を説明する。
図１３では、Ｓ２１～Ｓ２５までは、図１２のＳ１１～Ｓ１５までと同じである。異なるのは、「演算した別ルートによって返却時刻内の返却が可能かどうか」を判断するステップ（Ｓ２６）を含んでいる点である。

返却地まで最も早いルートを使ったとしても返却時刻に間に合わない可能性がある場合には、返却時刻が最も早くなる最速ルートを優先して表示させる（Ｓ２７）。最速ルートの選択を強く促すためである。
なお、演算した別ルートによって返却時刻内の返却が可能であるとしても、時間厳守が可能なルートを優先して表示させる（Ｓ２８）。

（図１４）
カーシェア管理サーバの作動についての別のバリエーションを示す図１４を用いて、前述した図１２との相違点を説明する。
図１４では、Ｓ３１～Ｓ３５までは、図１２のＳ１１～Ｓ１５までと同じである。異なるのは、「当該シェアカーを運転する会員ユーザが優待会員か否か」」を判断するステップ（Ｓ３６）を含んでいる点である。

会員ユーザが優待会員である場合には、有料道路の割引額を演算し（Ｓ３７）、その割引が適用できる有料道路を用いたルートを優先して表示させる（Ｓ３８）。
なお、会員ユーザが優待会員ではない場合であっても、返却予定時刻での返却が可能なルートを優先して表示させる（Ｓ３８）。

（図１５）
図１５は、道路全般の管理を司る道路全般管理サーバを中心として、大都市での交通規制や渋滞緩和を図る対策として、大都市圏で開催されるイベント前に渋滞シミュレーションを実行するとともに、当日のナビゲーションデータを送信するサービスを実現するための第六の実施形態である。

イベントとしては、たとえば、他国の大統領などの重要人物が来日するような場合、市民マラソン大会やオリンピックといったスポーツイベントなど、交通規制を伴ったり、大規模な渋滞が予想されたりするイベントである。
そのイベントに対する渋滞緩和策を立案するのが道路全般管理サーバであり、渋滞緩和策の立案のために寄与するのが渋滞データ管理サーバであり、渋滞緩和策を実行するのがカーシェア管理サーバおよびそのカーシェア管理サーバの管理対象となっているシェアカーである。

道路全般管理サーバには、開催されるイベントの日時や場所などのイベントデータを予め入力するためのイベントデータ入力手段、そのイベントを原因の一つとして当日の渋滞を予測する渋滞シミュレーション演算手段、その渋滞予測に対して緩和策を仮定してシミュレーションする渋滞緩和策シミュレーション演算手段、渋滞緩和に効果的な緩和策をカーシェア管理サーバへ送信する渋滞緩和策出力手段を備えている。
渋滞緩和策シミュレーション演算手段は、渋滞管理サーバにおける渋滞データベースから過去の渋滞データを受信し、演算に用いる。

カーシェア管理サーバは、有料道路管理サーバにおける有料道路管理データベースから有料道路料金データを受信する有料道路料金データ受信手段と、道路全般管理サーバから渋滞緩和策を受信する渋滞緩和策受信手段と、管理対象のシェアカーから現在位置データを受信して車両管理データとして蓄積する車両管理データベースと、現在位置データおよび返却地データを用いることで返却地への合理的なルートおよびそのルートを選択した場合の料金などを演算するルート＆料金の選択肢演算手段と、を備えている。

シェアカーの多機能カーナビは、ルート＆料金の選択肢演算手段が演算したルート選択肢、返却予想時刻、ルート別料金などを受信して出力し、ルート選択に役立てる。選択したルートに有料道路が含まれている場合には、ＥＴＣへその有料道路を通過するためのデータを送っておく。

図１５に示した実施形態によれば、渋滞の原因となるイベントに伴う渋滞予測と、その緩和策を演算し、その緩和策をカーシェアリングサービスがイベント当日に実行することで、渋滞緩和に寄与する。

（図１６）
図１６に示す実施形態は、図１５に示した実施形態のバリエーションである。図１５がイベント当日の渋滞緩和を実行するものであったが、図１６は、イベント開催前に渋滞シミュレーションを演算するとともに、イベント当日前に予約されたシェアカーに対して、渋滞緩和のための情報を予めインストールしておくものである。
道路全般管理サーバは、図１５に示した実施形態と構成要件は同じである。渋滞シミュレーションを実行するために取得する渋滞データや、その渋滞データを用いて演算される渋滞緩和策などが異なることはあり得る。

カーシェア管理サーバにおいては、会員データベースや車両管理データベースに蓄積されたシェアカーの予約データを演算して、渋滞緩和策に関わるシェアカーを抽出しておく。そして、ルート選択肢、返却予想時刻、ルート別料金などのデータを予約が実行される直前に、多機能カーナビへ送信する。

なお、車両管理データベースに蓄積される予約データが大量にあり、渋滞シミュレーションにも影響を及ぼすと予想されるような場合には、渋滞シミュレーション演算手段へ予約データを提供することとしても良い。

カーシェアリングサービスをイベント当日に予約している会員に対しては、多機能カーナビへ渋滞回避のためのルート選択肢などの情報が予めインストールされているので、使い勝手がよい。
道路全般管理サーバの運営主体としても、渋滞緩和をイベントの事前や当日に、円滑に実行することができる。

（図１７）
図１７に示す実施形態は、図１５や図１６に示した実施形態のバリエーションである。
この実施形態においては、道路全般管理サーバにおいて演算した渋滞緩和策を、有料道路管理サーバが受け取ることとしている（カーシェア管理サーバが受信することを排除する意図ではない）。

この実施形態では、有料道路の料金をイベントの前後の時間帯で変更するという渋滞緩和策を演算し、有料道路管理サーバへ告知し、有料道路管理サーバから改訂される有料道路料金をカーシェア管理サーバが受信し、カーシェア管理サーバはそれに基づいてルート選択肢やルート別料金などをイベントの当日に、シェアカーへ送信する。

図１７に示す実施形態によれば、道路全般管理サーバにおいて演算される渋滞緩和策シミュレーションを有料道路の料金改定に限定しており、図１５に示した実施形態よりも簡素化できる。

（図１８）
図１８に示す第七の実施形態は、図１５に示した実施形態における渋滞緩和策の実行を、カーシェアリングサービスではなく、渋滞緩和のためのデータサービスを受けられる「ナビ会員」を介して実行する場合を示している。

この実施形態では、カーシェア管理サーバの代わりに、ナビ会員管理サーバが存在する。そのナビ会員管理サーバには、渋滞緩和に協力するとともに渋滞緩和に寄与するルート選択などの情報を提供してもらえるナビ会員登録を済ませたナビ会員データベースが存在する。

ナビ会員登録をした対象車両には、シェアカーと同じ多機能カーナビが搭載されており、渋滞緩和に寄与するルート選択などのデータを受信してナビゲーション出力ができるとともに、目的地データをナビ会員管理サーバへ送信することとしている。さらに、ＧＰＳを搭載し、現在位置データもナビ会員管理サーバへ随時送信する。

この実施形態では、ナビ会員登録車両のＧＰＳから提供される現在位置データと、多機能カーナビに入力された目的地データとを用いて、渋滞緩和策に関わるルート選択肢、目的地への到着時刻、ルート別料金などの情報をナビ会員は受け取ることができる。

（図１９）
図１９に示す実施形態は、図１８に示した実施形態のバリエーションである。
この実施形態においては、図１７と同様、道路全般管理サーバにおいて演算した渋滞緩和策を、有料道路管理サーバが受け取ることとしている。

前述してきた複数の実施形態によれば、カーシェアユーザが返却予定時刻を守れるようなナビゲーション情報を提供できたり、イベント開催に伴う渋滞の緩和に寄与したりする。また、有料道路の事業者の利益向上に寄与したり、都市部の自治体におけるイベント開催時の交通規制に寄与したりする。運送事業者にとっては、有料道路の有効利用や早期運送の最適化に寄与する情報を得ることができる。

図１５から図１９に示した実施形態によれば、イベントの開催および円滑な運用に伴って必要となる交通規制、イベントの開催によって発生する渋滞の抑制、イベント終了に伴う規制解除後の円滑な平常化などに寄与する。

前述してきた複数の実施形態においては、車両共有サービスとしてカーシェアリングを例として説明したが、レンタカーサービスであっても、本願発明は採用可能である。

（図２０）
図２０は、シェアカーの返却が次の予約時刻を超過するおそれがある場合、次予約に係る駐車場の周辺（たとえば半径数百メートル圏内）において、シェアカーまたはレンタカーの代車にて予約振替を手配するアルゴリズムを実行するためのハードウェアを含めたブロック図である。
シェアカーに搭載された多機能カーナビゲーション装置から、そのシェアカーにてカーシェアリングを利用していた会員ユーザＡから、図１１，１２などで示した到着予定時刻が早いルートを選択しても、予約に係る返却予定時刻を超過するおそれが生じた旨の緊急連絡を、カーシェアリング管理サーバが受信する。

会員ユーザＡからの連絡が無くても、シェアカーに搭載されたＧＰＳからの位置情報をカーシェアリング管理サーバが取得し、予約に係る返却予定時刻を超過するおそれが生じた旨を、予定超過検知手段が検知して判断する場合もある。

車両管理データベースからのデータ取得によって予定超過検知手段が、予約に係る返却予定時刻を超過するおそれが生じたと判断した場合、カーシェアリング車両管理データベースやレンタカー車両管理データベースへ代車検索手段がアクセスし、代車を探す。次予約ユーザの予約データにおける駐車地から、たとえば半径数百メートル圏内、といった条件での検索となる。
代車が検索できた場合には、その代車を次の予約に係る会員ユーザＢが希望する駐車場へ配車が可能であるか否かを検証する。

そして、代車の手配ができたものの会員ユーザＢが希望する車種ではない場合や、代車の手配ができなかった場合には、検証結果送信手段がその旨を会員ユーザＢに係る携帯通信端末へ送信する。
この図では、『予約いただいていたシェアカーですが、前のお客様の事故により予約遂行ができなくなりました。代車の手配も適いません。申し訳ありません。』という連絡をした場合について、図示している。

（図２１）
図２１は、カーシェアリングのへヴィーユーザや高額な基本料金を支払っている特別な会員ユーザ（以下「優待会員」と称する。「優待会員」か否かは、ユーザの利用履歴データに基づいて所定条件を定めることで決定する。優待プランデータを提示されるべき会員ともなる。）に対してのみ提供するカーシェアリングサービスの概要を示す実施形態に係るフローチャートである。
会員ユーザから送信されてきた予約データを遂行できるシェアカーが存在しない場合、まず、カーシェアリング管理サーバは、会員データベースを参照して、その予約データに係る会員ユーザがプレミア会員か否かを判断する（Ｓ４１）。

プレミア会員である場合には、カーシェアリング管理サーバは、周辺のカーシェアリング車両管理データベース、レンタカー車両管理データベースへアクセスし、シェアカー駐車場やレンタカー駐車場に配車可能な代車があるか否かを検索する（Ｓ４２）。続いて、配車可能な代車と予約車種とが一致しているか否かを確認する（Ｓ４３）。
Ｓ４１からＳ４３までがいずれも「Ｙｅｓ」であれば、予約ユーザへは代車である旨を連絡せずに、予約処理を完了する。

予約車種が一致していない場合（Ｓ４３が「Ｎｏ」の場合）、「予約車種と一致していなくても予約するかどうか」を予約データに係るユーザへ連絡する。
配車可能な代車がない場合（Ｓ４２が「Ｎｏ」の場合）、およびユーザがプレミア会員ではない場合（Ｓ４１が「Ｎｏ」の場合）については、予約ができない旨のお詫び連絡をカーシェアリング管理サーバが返信する（Ｓ４４）。

なお、配車を実行することについての追加料金が発生する場合、その連絡は、Ｓ１からＳ３までがいずれも「Ｙｅｓ」である場合、予約ユーザへは代車であって追加料金が発生する旨を連絡し、予約処理を完了する。
図２１では図示していないか、追加料金が発生するのであれば代車の予約は不要である、という会員ユーザ（次ユーザ）が選択できるようにしてもよい。

本発明は、カーシェアリングやレンタカーなどの車両貸し出しサービス業、車両による運送の関連業務サービス業、渋滞情報サービス業、など、幅広い範囲において利用可能性を有する。

Claims (8)

1. 車両共有サービスにおいて用いるサービス対象車両を管理する車両管理サーバであって、
   貸し出し中のサービス対象車両の現在位置データを受信する現在位置データ受信手段と、
   前記の現在位置データに係るサービス対象車両に関する返却地データ、返却予定時刻、および次の貸し出し予約である次予約データを含む車両管理データを格納している車両管理データベースと、
   前記の現在位置データおよび前記の返却地データに関わる渋滞データを取得する渋滞データ取得手段と、
   前記の現在位置データおよび前記の返却地データを用いて返却地までのルートを検索するルート演算手段と、
   そのルート演算手段が検索したルートを前記の貸し出し中のサービス対象車両へ送信するルート選択肢出力手段と、
   を備え、
   前記のルート演算手段は、検索したルート毎に返却予想時刻を演算することとし、
   前記のルート選択肢出力手段は、前記の渋滞データおよび車両管理データを用いて返却予想時刻が前記の返却予定時刻よりも早くなるルートに係る時刻厳守ルートデータ、および／または返却予想時刻が返却予定時刻よりも遅い場合に最も早いルートに係る最速ルートデータを送信することとし、
   且つ前記のサービス対象車両に対する別のユーザが使用することとして予約が入っている場合には、その別のユーザによる使用予定時刻よりも遅くなると予想されるルートは前記のサービス対象車両において出力順位を最下位とするように送信するとともに、
   別のユーザによる使用予定時刻よりも遅くなると予想されるルートを選択しないように警告を表示するおよび／またはルート案内の画面へ移動しないようにした
   車両管理サーバ。
2. 前記のルート選択肢出力手段は、前記のルート演算手段が検索したルートに有料道路が含まれている場合には、当該ルートに料金データを紐付けてサービス対象車両へ送信することとした
   請求項１に記載の車両管理サーバ。
3. 前記の車両共有サービスが提供するサービス対象車両を利用できる会員に関する利用履歴データを予め格納している会員データベースと、
   前記のルート選択肢出力手段は、前記のルート演算手段が検索したルートに有料道路が含まれている場合には、当該ルートの料金データを、前記の利用履歴データに基づいて割り引いた割引料金データとしてサービス対象車両へ送信することとした
   請求項２に記載の車両管理サーバ。
4. 渋滞緩和策を受信する渋滞緩和策受信手段を備え、
   前記のルート演算手段は、前記の渋滞緩和策をも用いて返却地までのルートを検索することとした
   請求項１から請求項３のいずれかに記載の車両管理サーバ。
5. 車両共有サービスにおいて用いるサービス対象車両を管理する車両管理サーバを制御するコンピュータプログラムであって、
   貸し出し中のサービス対象車両の現在位置データを受信する現在位置データ受信手順と、
   前記の現在位置データに係るサービス対象車両に関する返却地データ、返却予定時刻、
   および次の貸し出し予約である次予約データを含む車両管理データを車両管理データベースへ格納する車両管理データ格納手順と、
   前記の現在位置データおよび前記の返却地データに関わる渋滞データを取得する渋滞データ取得手順と、
   前記の現在位置データおよび前記の返却地データを用いて返却地までのルートを検索するルート演算手順と、
   そのルート演算手順が検索したルートを前記の貸し出し中のサービス対象車両へ送信するルート選択肢出力手順と、
   を前記の車両管理サーバに実行させるものであり、
   前記のルート演算手順は、検索したルート毎に返却予想時刻を演算することとし、
   前記のルート選択肢出力手順は、前記の渋滞データおよび車両管理データを用いて返却予想時刻が前記の返却予定時刻よりも早くなるルートに係る時刻厳守ルートデータ、および／または返却予想時刻が返却予定時刻よりも遅い場合に最も早いルートに係る最速ルートデータを送信することし、
   且つ前記のサービス対象車両に対する別のユーザが使用することとして予約が入っている場合には、その別のユーザによる使用予定時刻よりも遅くなると予想されるルートは前記のサービス対象車両において出力順位を最下位とするように送信することとするとともに、
   別のユーザによる使用予定時刻よりも遅くなると予想されるルートを選択しないように警告を表示するおよび／またはルート案内の画面へ移動しないようにした
   コンピュータプログラム。
6. 前記のルート選択肢出力手順においては、前記のルート演算手順にて検索したルートに有
   料道路が含まれている場合には、当該ルートに料金データを紐付けてサービス対象車両へ送信することとした
   請求項５に記載のコンピュータプログラム。
7. 前記の車両管理サーバには、前記の車両共有サービスが提供するサービス対象車両を利用できる会員に関する利用履歴データを予め格納している会員データベースを備えており、
   前記のルート選択肢出力手順においては、前記のルート演算手順にて検索したルートに有料道路が含まれている場合には、当該ルートの料金データを、前記の利用履歴データに基づいて割り引いた割引料金データとしてサービス対象車両へ送信することとした
   請求項６に記載のコンピュータプログラム。
8. 渋滞緩和策を受信する渋滞緩和策受信手順を備え、
   前記のルート演算手順においては、前記の渋滞緩和策をも用いて返却地までのルートを検索することとした
   請求項５から請求項７のいずれかに記載のコンピュータプログラム。

Images