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

Description

本発明は、カーシェアリングとカーレンタルとを融合し、車両の有効利用を促進するための情報処理技術に関する。

複数の車両を複数のユーザが共同で使用するカーシェアリングシステムが、普及しつつある。
カーシェアリングを利用する利用者は、カーシェアリングの会員登録を済ませ、カーシェアリング用の自動車（シェアカー）を確保している駐車場に出向いて直接利用する。または、携帯電話やパーソナルコンピュータを用いて利用予定の時間帯などを事前に連絡する予約制度を活用する。

図１３を用いて、カーシェアリングの利用予約時の情報処理についての典型例を説明する。
カーシェアリングサービスを提供する事業者は、事前に会員登録がなされた会員に対して、会員を識別するＩＣカードを提供する。
会員ユーザは、自己に係るパソコンや携帯端末などの通信端末を介してインターネットを経由して予約管理システムに対し、予約データを送信する。予約システムにおけるカーシェア管理サーバは、利用を希望する車両（シェアカー）に対し、車両管理データベースを参照して希望時間枠を予約する。そして、予約が完了した場合、予約に係るシェアカーの車載機へ、予約データを送信する。

会員ユーザは、予約時間に予約したシェアカーに赴き、その車両に備えられた会員識別装置に対してその識別装置に読み込まれた会員識別子を使って、予約条件と予約した会員である旨が照合された場合に、そのシェアカーが使用可能となる。

多くのカーシェアリングの車両には、専用のカーナビゲーション装置を搭載している。また、カーシェアリングに用いる車両を管理するための車両管理サーバとの通信を実行する車載器を搭載している。そして、この車載器と車両管理サーバとの通信によって、車両の貸し出し、返却に関する管理を自動化（無人化）している。

一方、車両を貸し出すという類似のサービス業としては、古くからレンタカー事業（カーレンタル事業、レンタカー業）がある。事前の登録は不要である場合が多く、指定の店舗または指定の場所に配車を行う形態での車両の予約、貸出する、という点が主に異なっている。しかし、レンタカー事業もまたカーシェアリングサービスと同じように、車両管理を効率化し、収益性の向上を図っている点で共通する。

さて、特許文献１には、カーシェアリングの利用中に、利用時間を延長する手続きを、運転の妨げにならないように実行可能な技術が開示されている。
また、特許文献２には、営業車両の運行管理を遂行するシステムに関する技術が開示されている。

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

図１４を用いて、本発明が解決しようとする第一の課題を説明する。
カーシェアリングの会員ユーザに係る通信端末からカーシェア管理サーバへ予約データを送信し（１）、カーシェア管理サーバにて車両管理データベースにて、予約可能判断手段が判断した結果、予約ができない旨を返信したとする（２）。
この場合、会員ユーザは、レンタカーなどの別のサービスを検索し、レンタカー管理サーバへアクセスして予約が可能かどうかを閲覧し（３）、予約が可能であれば希望する予約データ（予約日時と氏名年齢などの属性情報）を再び入力して予約データを送信することとなる（４）。
つまり、新たに検索から始めなければならず、会員ユーザにとって不便であった。

図１５を用いて、本発明が解決しようとする第二の課題を説明する。
シェアカーを使用していたユーザが、予約していた時刻を超過して返却をしなければならない事態が発生したとする。この場合、多機能カーナビの通信機能を介して予約していた時刻を超過しそうである旨をカーシェアリング管理サーバへ送信する。あるいは、サービス対象車両に搭載されたＧＰＳによって位置データを把握したカーシェアリング管理サーバが、返却予定時刻を超過する旨を察知する場合もある。
この場合、当該シェアカーに次の予約が入っている場合、代車が手配できる場合を除いてその次の予約ユーザに対して、形態通信端末などへの緊急連絡手段を介して「予約をキャンセルしていただく旨」を連絡することとなる。代車が手配できたとしても車種が異なるなど予約内容に変更が入るのであれば、代車での対応をした旨のお詫び連絡が必要となる。
つまり、予約をしていた会員ユーザが、予定変更を余儀なくされる事態となる。これは、会員ユーザによって大きな負担であった。

第二の課題は、会員ユーザが予約していた時刻を超過する場合以外の原因でも発生する。たとえば、交通事故、各種機器の不具合、車内洗浄の必要性などを原因として車両が使えなくなる事態が発生することをゼロとすることはできない。しかし、そうした事態の発生に対して全てバックアップ体制を整備してシェアカーの運営管理をしたのでは、合理的な運用とはならず、コストアップにつながってしまう。

第一の課題、第二の課題とも、カーシェアリングサービスの視点から説明したが、カーレンタル事業におけるサービス提供の視点からも、同様の課題がある。すなわち、ユーザとしてレンタカーを予約できない場合であってユーザが代替手段を探さなければならない場合、予約していたレンタカーが車両トラブルなどを原因として予約遂行ができない場合であってユーザが代替手段を探さなければならない場合、があり得る。

本発明が解決しようとする課題は、カーシェアリングにおける車両管理とレンタカーにおける車両管理とを融合させることで、車両を合理的に融通し合うことが可能な車両管理システムを実現するための技術を提供することにある。

（第一の発明）
第一の発明は、車両共有サービスにおけるサービス対象車両に関するデータを管理する車両管理サーバに係る。
サービス対象車両の貸し出し状況や予約に関する車両管理データを蓄積する第一の車両管理データベースと、
その第一の車両管理データベースとは別の目的のサービス対象車両を管理および貸し出している当該車両の貸し出し状況や予約に関する車両管理データを蓄積する第二の車両管理データベースと、
ユーザに係る通信端末からの車両の貸し出し予約についての予約データを受信する予約データ受信手段と、 その予約データ受信手段が受信した予約データについて予約が可能であるか否かを前記の第一の車両管理データベースを用いて判断するとともに、予約ができないと判断した場合に第二の車両管理データベースを用いて判断する予約可能判断手段と、
その予約可能判断手段の判断結果を前記のユーザに係る通信端末へ出力する予約可否出力手段と、
ユーザに関する利用履歴データを格納した会員データベースと、を備える。
前記の予約可能判断手段は、前記の予約データに係るユーザが所定条件を満たしているか否かを、前記の会員データベースに格納されたデータを用いて判断するとともに、前記の所定条件を満たしている場合にのみ、前記の第二の車両管理データベースを用いての判断を実行する。
前記の予約可否出力手段は、第一の車両管理データベースに係る予約ができない場合であって第二の車両管理データベースに係る予約であれば予約が可能である場合には、その旨を判断結果に含むこととした（図１、図１２を参照）。

（用語説明）
「車両共有サービス」とは、カーシェアリングを管理運営するサービス、およびレンタカーを運営管理するサービスの両方を指すものとする。
「サービス対象車両」とは、カーシェアリングであれば「シェアされる車両（シェアカー）」、カーレンタルサービスであれば「レンタルされる車両（レンタカー）」を指すものとする。
「第一の車両管理データベース」および「第二の車両管理データベース」は、物理的にひとつの車両管理サーバの中に存在している場合（図１０）のほか、物理的に異なる（離れた場所に存在する）複数の車両管理サーバの中に存在している場合（図１、図９）もある。
サービス対象車両の利用を希望する「ユーザ」は、カーシェアリングのサービス対象車両を利用する場合には、予め会員登録をした会員ユーザであることが一般的である。

（作用）
第一の車両管理データベース（たとえばカーシェアの車両管理データベース）および第二の車両管理データベース（たとえばレンタカーの車両管理データベース）には、車両の貸し出し状況や予約に関する車両管理データを、予め蓄積している。
ユーザは、自らに係る通信端末から車両の貸し出し予約（たとえばカーシェアリング）についての予約データを送信する。その予約データは、車両管理サーバにおける予約データ受信手段が受信する。
その予約データ受信手段が受信した予約データについて予約が可能であるか否か、予約可能判断手段が第一の車両管理データベースを用いて判断する。第一の車両管理データベースにて管理されているサービス対象車両(シェアカー)では予約ができないと判断した場合には、予約可能判断手段が第二の車両管理データベースを用いて判断する。
第二の車両管理データベースに係る予約であれば(レンタカーの)予約が可能である場合には、その旨を含んだ判断結果を、予約可否出力手段が前記のユーザに係る通信端末へ出力する。

たとえば、所望する日時にカーシェアリングにて車両を使おうと意図していたユーザが、所望する日時にはカーシェアリングサービスの利用の予約ができないとなった場合、レンタカーであれば所望する日時に予約が可能である旨の情報を、レンタカー管理サーバへアクセスしなくても取得することができる。

カーシェアリングを管理運営するサービス業者としては、ユーザが所望する日時にシェアカーを調達できないとしても、レンタカーの情報をユーザへ提供することができる。そのため、ユーザの満足度を高めることに寄与する。
レンタカーを管理運営するサービス業者としては、ユーザが所望する日時にレンタカーを調達できないとしても、カーシェアリングの情報をユーザへ提供することができる。そのため、ユーザの満足度を高めることに寄与する。

（用語説明）
「会員データベース」とは、ユーザの氏名や住所や料金支払い方法などの属性データなどの予め登録した情報のほか、サービスの利用履歴などをユーザごとに蓄積したデータベースである。
「所定条件」とは、一般会員よりも高額な基本料金をお支払いいただいている会員ユーザ、大口の契約を締結している法人顧客など（たとえば「プレミア会員」などと称する）であることや、利用履歴が基準以上である会員ユーザ（いわゆる「ヘヴィーユーザ」）であること、などである。

車両管理サーバは、ユーザに関する利用履歴データなどを格納した会員データベースを予め備えている。そして、予約データに係るユーザが所定条件を満たしているか否かを、前記の会員データベースに格納されたデータを用いて判断する（図１２におけるＳ１に該当）。更に、その所定条件を満たしている場合にのみ、第二の車両管理データベースを用いての判断を実行する。
結果として、所定条件を満たしたユーザだけが、第一の車両管理データベースのみでは持ち得ない情報（この場合には、第二の車両管理データベースに格納された情報）を活用することができる。

（第一の発明のバリエーション２）
第一の発明は、以下のように形成してもよい。
すなわち、前記の予約可否出力手段は、前記の予約可能判断手段によって予約できない
と判断された車両の貸し出し場所および予約可能と判断された車両の貸出場所を前記の予
約データに係るユーザの通信端末へ地図データとともに一画面で出力させる（図３参照）
。
前記の第二の車両管理データベースに係る予約であれば予約が可能である旨を受信した
ユーザに係る通信端末から当該予約を希望する旨の第二の予約データを受信する第二の予
約データ受信手段を備える。
その第二の予約データ受信手段が受信した第二の予約データは、前記の第二の車両管理
データベースへ蓄積することとする（図１、図９を参照）。

（作用）
第二の車両管理データベースに係る予約であれば、予約が可能である旨をユーザに係る通信端末へ送信する。その旨を受信したユーザに係る通信端末から当該予約を希望する旨の第二の予約データを、第二の予約データ受信手段が受信する。その第二の予約データ受信手段が受信した第二の予約データは、第二の車両管理データベースが蓄積する。
ユーザとしては、第一の車両管理データベースに係るサービス（たとえばカーシェアリングサービス）での予約ができなくても第二の車両管理データベースに係るサービス（たとえばレンタカー）での予約ができる。一つ目のサービスでの予約が不可能であることが分かってから別のサービスでのサービスを検索して予約をする、といった手間が省ける。

（第一の発明のバリエーション３）
第一の発明におけるバリエーション２は、以下のようにすることもできる。
すなわち、ユーザが希望する受け取り場所のデータを含んだ配車予約データをユーザに係る通信端末から受信する配車予約データ受信手段と、その配車予約データに基づく配車の予約が可能かどうかを前記の第二の車両管理データベースを用いて判断するとともに、その判断結果をユーザに係る通信端末へ出力する配車可能判断手段と、配車が可能である旨の判断結果を受信したユーザに係る通信端末からの配車要請を実行するためのデータ処理する配車要請処理手段と、を備える（図４参照）。

「配車要請処理手段」とは、第一および第二の車両管理サーバ、ユーザの利用場所などに関する各種データ、配車に関わる地図データ、スケジュールデータなどから、配車要請データに含まれる内容を実行するためのデータ処理を実行する。

（作用）
ユーザが希望する受け取り場所のデータを含んだ配車予約データを、配車予約データ受信手段がユーザに係る通信端末から受信する。その配車予約データに基づく配車の予約が可能かどうかを、前記の第二の車両管理データベースを用いて配車可能判断手段が判断する。そして、配車可能判断手段はその判断結果をユーザに係る通信端末へ出力する。続いて、配車要請処理手段は、配車が可能である旨の判断結果を受信したユーザに係る通信端末から配車要請を受信し、実行するためのデータ処理を実行する。

たとえば、シェアカーを通常は利用しているユーザが、レンタカーの車両を使用することとなった場合に、通常のシェアカーの利用場所へ配車を要請し、いつものように利用する、といった使い方が可能となる。

（第一の発明のバリエーション４）
第一の発明におけるバリエーション３は、以下のようにしてもよい。
すなわち、前記の配車可能判断手段は、配車が可能である旨の判断結果を出力する場合において、前記の会員データベースの利用履歴データを用いて配車に係るサービス料金を算出することとし、前記の判断結果には、そのサービス料金を含ませることとしてもよい（図４、図５、図１１参照）。

（作用）
ユーザに関する利用履歴データなどを会員データベースが格納している。
配車が可能である旨の判断結果を出力する場合において、会員データベースの利用履歴データを用いて配車に係るサービス料金を配車可能判断手段が算出する。
その判断結果には、配車に関わるサービス料金を含ませることとしてもよいし、利用履歴が基準以上であるユーザや一般よりも高額な基本料金のユーザ（たとえば「プレミア会員」などと称する）に対しては、配車に関わるサービス料金を割り引いたり無料としたりすることも可能である（図１１参照）。

（第一の発明のバリエーション５）
第一の発明は、以下のようにしてもよい。
すなわち、一のユーザが使用中のサービス対象車両が返却予定時刻を超過するおそれがある旨を検知する予定超過検知手段と、その予定超過検知手段が検知したサービス対象車両を次に使用予定のユーザに係る予約データを遂行可能かどうか、第一の車両管理データベースおよび／または第二の車両管理データベースを検索する代車検索手段と、その代車検索手段によって検索したサービス対象車両が、前記の予約データに係る乗車場所へ配車が可能かどうかを検証する配車検証手段と、その配車検証手段における検証結果を、前記した次に使用予定のユーザに係る通信端末へ送信する検証結果送信手段と、を備えることとしてもよい（図７参照）。

（作用）
一のユーザが使用中のサービス対象車両が返却予定時刻を超過するおそれがある旨を予定超過検知手段が検知する。その予定超過検知手段が検知したサービス対象車両を次に使用予定のユーザに係る予約データを遂行可能かどうか、代車検索手段が第一の車両管理データベースおよび／または第二の車両管理データベースを検索する。
その代車検索手段によって検索したサービス対象車両が、前記の予約データに係る乗車場所へ配車が可能かどうかを、配車検証手段が検証する。その配車検証手段における検証結果を、前記した次に使用予定のユーザに係る通信端末へ検証結果送信手段が送信する。

一のユーザが使用していたサービス対象車両について、他のユーザの予約が入っている場合に、当該サービス対象車両について、返却時刻までに、前記他のユーザが使えない状態が発生したとする。
その場合、前記他のユーザが代車を検索したり予約したりする手間が省ける事態を提供できる（図８参照）。代車の手配ができない場合であっても、その旨の連絡をすることができる（図７参照）。

（第二の発明）
第二の発明は、車両共有サービスにおけるサービス対象車両に関するデータを管理する車両管理サーバを制御するためのコンピュータプログラムに係る。
前記の車両管理サーバは、サービス対象車両の貸し出し状況や予約に関する車両管理データを蓄積する第一の車両管理データベースと、その第一の車両管理データベースとは別の目的のサービス対象車両を管理および貸し出している当該車両の貸し出し状況や予約に関する車両管理データを蓄積する第二の車両管理データベースと、ユーザに関する利用履歴データを格納した会員データベースと、を備える。
車両管理サーバを制御するためのコンピュータプログラムは、ユーザに係る通信端末からの車両の貸し出し予約についての予約データを受信する予約データ受信手順と、その予約データ受信手順にて受信した予約データについて予約が可能であるか否かを前記の第一の車両管理データベースを用いて判断するとともに、予約ができないと判断した場合に第二の車両管理データベースを用いて判断する予約可能判断手順と、その予約可能判断手順における判断結果を前記のユーザに係る通信端末へ出力する予約可否出力手順と、を前記の車両管理サーバに実行させるものである。
前記の予約可能判断手順は、前記の予約データに係るユーザが所定条件を満たしているか否かを、前記の会員データベースに格納されたデータを用いて判断するとともに、前記の所定条件を満たしている場合にのみ、前記の第二の車両管理データベースを用いての判断を実行する
前記の予約可否出力手順は、第一の車両管理データベースに係る予約ができない場合であって第二の車両管理データベースに係る予約であれば予約が可能である場合には、その旨を前記の判断結果に含むこととしている。

（第二の発明のバリエーション２）
第二の発明は、以下のように形成してもよい。
すなわち、前記の予約可否出力手順においては、前記の予約可能判断手順において予約できないと判断された車両の貸し出し場所および予約可能と判断された車両の貸出場所を前記の予約データに係るユーザの通信端末へ地図データとともに一画面で出力させる。
加えて、前記の第二の車両管理データベースに係る予約であれば予約が可能である旨を受信したユーザに係る通信端末から当該予約を希望する旨の第二の予約データを受信する第二の予約データ受信手順と、その第二の予約データ受信手順にて受信した第二の予約データを前記の第二の車両管理データベースへ蓄積する第二の予約データ蓄積手順と、を前記の車両管理サーバに実行させることとしてもよい。

（第二の発明のバリエーション３）
第二の発明におけるバリエーション２は、以下のようにしてもよい。
すなわち、ユーザが希望する受け取り場所のデータを含んだ配車予約データをユーザに係る通信端末から受信する配車予約データ受信手順と、その配車予約データに基づく配車の予約が可能かどうかを前記の第二の車両管理データベースを用いて判断するとともに、その判断結果をユーザに係る通信端末へ出力する配車可能判断手順と、配車が可能である旨の判断結果を受信したユーザに係る通信端末からの配車要請を実行するためのデータ処理する配車要請処理手順と、を、車両管理サーバに実行させることとしてもよい。

（第二の発明のバリエーション４）
第二の発明におけるバリエーション３は、以下のようにしてもよい。
すなわち、 前記の配車可能判断手順は、配車が可能である旨の判断結果を出力する場合において、前記の会員データベースの利用履歴データを用いて配車に係るサービス料金を算出する手順を含むこととし、 前記の判断結果には、そのサービス料金を含ませることとしてもよい。

（第二の発明のバリエーション５）
第二の発明は、以下のようにしてもよい。
すなわち、一のユーザが使用中のサービス対象車両が返却予定時刻を超過するおそれがある旨を検知する予定超過検知手順と、その予定超過検知手順にて検知したサービス対象車両を次に使用予定のユーザに係る予約データを遂行可能かどうか、第一の車両管理データベースおよび／または第二の車両管理データベースを検索する代車検索手順と、その代車検索手順にて検索したサービス対象車両が、前記の予約データに係る乗車場所へ配車が可能かどうかを検証する配車検証手順と、その配車検証手順による検証結果を、前記した次に使用予定のユーザに係る通信端末へ送信する検証結果送信手順と、を、車両管理サーバに実行させることとしてもよい。

第二の発明に係るコンピュータプログラムを、記録媒体へ記憶させて提供することもできる。
ここで、「記録媒体」とは、それ自身では空間を占有し得ないプログラムを担持することができる媒体である。例えば、フレキシブルディスク、ハードディスク、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＭＯ（光磁気ディスク）、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、フラッシュメモリなどである。
また、この発明に係るプログラムを格納したコンピュータから、通信回線を通じて他の端末手段へ伝送することも可能である。

第一の発明によれば、カーシェアリングにおける車両管理とレンタカーにおける車両管理とを融合させることで、車両を合理的に融通し合うことが可能な車両管理システムを実現するための車両管理サーバを提供することができた。
第二の発明によれば、カーシェアリングにおける車両管理とレンタカーにおける車両管理とを融合させることで、車両を合理的に融通し合うことが可能な車両管理システムを実現するための車両管理サーバ制御用のコンピュータプログラムを提供することができた。

第一の実施形態を示すハードウェア構成の概略図である。 第一の実施形態の車両管理サーバにおけるデータの内容を示した概念図である。 第一の実施形態において、会員ユーザに係る通信端末へ出力される内容の一例を示した概念図である。 第二の実施形態を示すハードウェア構成の概略図である。 第二の実施形態において、会員ユーザに係る通信端末へ出力される内容の一例を示した概念図である。 第三の実施形態を示すフローチャートである。 第三の実施形態を示すハードウェア構成の概略図である。 第四の実施形態において、会員ユーザに係る通信端末へ出力される内容の一例を示した概念図である。 第五の実施形態を示すハードウェア構成の概略図である。 第一の実施形態におけるバリエーションのハードウェア構成の概略図である。 第六の実施形態を示すフローチャートである。 第七の実施形態を示すフローチャートである。 一般のカーシェアリングの予約時を示すブロック図である。 一般のカーシェアリングにおける第一の問題点を示すための概念図である。 一般のカーシェアリングにおける第二の問題点を示すための概念図である。

以下、本発明を実施形態に基づいて説明する。ここで使用する図面は、図１から図１２である。
以下、カーシェアリングサービスに用いる自動車（サービス対象車両）を「シェアカー」、レンタカーサービスに用いる自動車（サービス対象車両）を「レンタカー」と表記する。

本実施形態において説明するカーシェアリングを利用するには、管理および運営上の都合から、まず会員登録を済まさなければならないこととしている。すなわち、以下の実施形態に示すサービスを受けることができる「車両利用希望者」や「利用者」は、全て会員登録を済ませていることとなる。

会員登録は、氏名や住所の他、利用料金の支払い口座などの会員データを予め登録する。その登録データは、会員データベースへ蓄積されるとともに、会員であることを認証するためのＩＤカード（図中「ＴＰカード」、「登録済みカードα」と表している）が発行される。このＩＤカードには、そのユーザが会員であることを認証するために必要なデータがＩＣチップへ格納されたＩＣカードであり、シェアカーに搭載されたカードリーダ（車両解錠センサ）にかざすことでそのデータが読み取れるようになっている。施錠されているシェアカーの解錠も、前記の登録済みカードにて行う。

シェアカーの返却時には、利用者（ユーザ）は、以下のように動作する。
すなわち、シェアカーを、カーシェアリングの基地となっている駐車スペースへ停車させ、シェアカーのシフトレバーをパーキングモードにする。エンジンキーを抜き、グローブボックスをあける。グローブボックスの中には、エンジンキーを収納しておくキーボックスが設けられている。そのキーボックスへエンジンキーを挿入し、返却ポジションへ回す。登録済みカードをカードリーダ（車両解錠センサ）にかざすことで、シェアカーを施錠する。

利用者は、返却を約束した時刻までに、所定の場所へシェアカーを返却しなければならない。しかし、渋滞、事故、事情変更などを原因として返却すべき時刻までに返却が完了しない場合もある。その場合には、カーシェア運営サービス業者へ連絡を入れなければならない。

（図１）
図１は、カーシェアリング管理サーバと、シェアカーを利用する会員ユーザに係る携帯通信端末（スマートフォンを含む携帯電話、タブレット型ＰＣなど）と、レンタカー管理サーバとの関係を示している。
サービス対象車両には、カーシェアリング管理サーバとの無線通信を実行する車載機、カードリーダとしての車両解錠センサ、およびカーナビゲーションのみならずカーシェアリングに関する各種の案内や会員ユーザからの連絡事項などを入出力する多機能カーナビゲーション装置が、データ処理装置として搭載されている。

カーシェアリング管理サーバは、前述したように、会員管理、予約管理を含めた車両管理、優待データに関する管理などを実行する。
また、詳細な図示は省略しているが、シェアカーに搭載されている車載機は、カーシェアリング管理サーバとの無線通信のほか、車両解錠センサおよび多機能カーナビゲーション装置とのシリアル通信を行う。

多機能カーナビゲーション装置は、タッチパネルを備えており、車載機を介して送り込まれた各種のデータを用いての会員ユーザへのメッセージ表示や、会員の意思表示をタッチパネルによる入力の受付（サービス用ボタン表示）、その入力内容を車載機への送信、などを行うことができる。
カーナビゲーション機能を担保するため、ＧＰＳ(Global Position System)を利用して現在位置データを取得している。そしてその現在位置データは、車載機を介してカーシェアリング管理サーバへ送信する（図７）。

シェアカーを利用使用とする会員に係る通信端末（携帯端末も含む）は、カーシェアリング管理サーバとの無線通信が可能であるように、予め専用のアプリケーションをインストールしてある。そのアプリケーションは、シェアカーの予約などにも用いる。
ただし、専用のアプリケーションが必須であるとする必要はなく、カーシェアリング管理サーバが予め把握しているメールアドレスにて、カーシェアリング管理サーバからの連絡や電子クーポンの受信が可能である、としてもよい。

カーシェアの車両管理データベースおよびレンタカーの車両管理データベースには、車両の貸し出し状況や予約に関する車両管理データを、それぞれ予め蓄積している。
会員ユーザは、自らに係る通信端末からカーシェアリングについての予約データを送信する。その予約データは、カーシェアリング管理サーバにおける予約データ受信手段が受信する（１）。
予約データには、登録済みカードαのカード番号をあわせて送信する必要がある。前述したように、カーシェアリング管理サーバから提供されているカーシェアリング専用のアプリケーションを用いれば、入力作業は簡易化される。予約データには、会員を特定するためのデータ（カード番号）のほか、所定の日時、シェアカーがプールされている場所、利用時間、などが含まれる。

その予約データ受信手段が受信した予約データについて予約が可能であるか否か、予約可能判断手段がカーシェアリング管理データベースを用いて判断する（２）。カーシェアリング車両管理データベースにて管理されているサービス対象車両(シェアカー)では予約ができないと判断した場合には、予約可能判断手段がレンタカー車両管理データベースを用いて判断する（２'）。
レンタカー車両管理データベースに係る予約であればレンタカーの予約が可能である場合には、その旨を含んだ判断結果（希望する時間帯でのカーシェアリングサービスの利用はできないが、レンタカーであれば予約が可能である旨）を、予約可否出力手段が会員ユーザに係る通信端末へ出力する（３）。

所望する日時にカーシェアリングにて車両を使おうと意図していた会員ユーザは、レンタカーであれば所望する日時に予約が可能である旨の情報を、レンタカー管理サーバへアクセスしなくても取得することができる。
そのレンタカー管理サーバにおける車両データ閲覧手段へアクセスし（４）、予約が可能である旨を確認することができる。そして、納得した場合には、予約データを送信すればよい（５）。

カーシェアリングを管理運営するサービス業者としては、ユーザが所望する日時にシェアカーを調達できないとしても、レンタカーの情報をユーザへ提供することができる。そのため、ユーザの満足度を高めることに寄与する。
レンタカーを管理運営するサービス業者としては、ユーザが所望する日時にレンタカーを調達できないとしても、カーシェアリングの情報をユーザへ提供することができる。そのため、ユーザの満足度を高めることに寄与する。

（図２）
図２は、○○駅の近傍において、カーシェアリングのシェアカーを確保している駐車場ＸおよびＹと、レンタカー用駐車場Ｚがある場合に、会員ユーザが希カーシェアリングを希望する時間帯においてシェアカーの確保、またはレンタカーの確保が可能であるかを図１に示した予約可能判断手段が判断することについて、概念的に示したものである。

会員ユーザは、８：３０から１０：００まで、車種Ａを駐車場ＸまたはＹにおいて利用を開始可能かどうか、予約データを送信した。しかし、図２に示すように、８：３０から１０：００までで駐車場ＸまたはＹにおいて利用を開始可能な車種Ａは存在しなかった。
しかし、レンタカー用駐車場Ｚにおいて、車種Ａがまだ予約されていないことが分かった（図２における網掛け部分）。そこで、カーシェア管理サーバは、「レンタカーを貸与している駐車場Ｚであれば、８：３０から１０：００まで、車種Ａを予約できる」旨を、会員ユーザへ連絡する。

（図３）
図３は、会員ユーザに対する上記の連絡を、会員ユーザに係る通信端末の画面へ分かりやすく出力させた例である。
画面には、会員ユーザが予約データに含めた○○駅の近傍の駐車場Ｘ，Ｙ、およびその駐車場Ｘ，Ｙにおいて８：３０〜１０：００に予約できる車両がない旨が、地図データとともに表示されている。加えて、レンタカー駐車場Ｚであれば、８：３０〜１０：００に予約できる車両Ａが一台存在する旨も表示されている。
更に、画面の下方において、ユーザが希望した車種Ａを８：３０〜１０：００において、予約を完了させることができるようなボタンをも用意している。この「はい」のボタンをクリックすれば、「レンタカー駐車場Ｚにおける車両Ａにて８：３０〜１０：００の予約」が、会員ユーザの名前で完了することとなる。

（図４）
図４は、「レンタカー代車に対して配車を予約する」という流れを示している。ここで「代車」および「配車」とは、図３までの流れに続いて説明すれば、以下のようなことである。
すなわち、会員ユーザは、カーシェアリングのサービスによっては、希望する時間帯に希望する駐車場では希望する車両を確保することができなかった。それゆえ、レンタカーによって代用することとした。この場合のレンタカーが「代車」である。
さて、会員ユーザは、図３までの流れで「代車」を確保したものの、このままではレンタカーの駐車場である駐車場Ｚまで予約時刻の前までに出向かなければならない。そこで、最初の予約データ送信時に希望していた駐車場Ｘにおいて代車を受け取れるような予約をするまでの流れが図４に示されており、駐車場Ｘにおいて代車を受け取れるように手配することを「配車」としている。

図４で示すように、会員ユーザは、自らに係る通信端末を用いて、会員ユーザを特定するためのＩＤとともに配車予約データとして「借りる日時、借りに行く場所、希望する車両」を送信する。カーシェアリング管理サーバにおける配車予約データ受信手段が、その配車予約データを受信する。
受信した配車予約データによる配車が可能であるか否かは、レンタカー管理サーバにおけるレンタカー車両管理データベースを用いて配車可能判断手段が判断する。そして、その判断結果は、会員ユーザに係る通信端末へ送信する。

配車予約が可能である場合、配車を実行するためのサービス料金を算出して会員ユーザに係る端末へ送信する。そのサービス料金の算出には、会員データベースにおける利用履歴や利用料金などのデータを参照し、利用頻度や利用金額が高い場合には、標準的な料金から割り引いたり無料化したりする。

図４における下の方に図示しているが、配車が可能である場合には、配車要請に対するデータの処理を配車要請処理手段が実行する。すなわち、配車予約データを受信したのは、カーシェアリング管理サーバであるものの、配車に係る車両を管理しているのはレンタカー管理サーバだからである。レンタカー用の車両Ａをプールしている駐車場（Ｚ）から、ユーザが希望する駐車場（ＸまたはＹ）へ、所定の日時に移動させるために必要なデータ処理を実行しておく必要があるからである。

まず、配車予約データ出力手段が、配車要請データ送信手段へ配車予約データを送信する。このとき、必要であれば予約に係る会員ユーザの属性データも含める。続いて、配車要請データ送信手段からレンタカー管理サーバにおける配車要請データ受信手段が配車要請データを受信する。また、配車要請データ受信手段は、レンタカー車両管理データベースへ、配車要請データに対応する車両Ａが所定の日時に駐車場（ＸまたはＹ）へ移動し、その後レンタルされて返却される、というデータを記録する。

レンタカー車両管理データベースへのデータ書き込みが完了したら、会員ユーザに係る通信端末へ配車予約が完了した旨の配車完了データを送信する。その配車完了データは、レンタカー管理サーバから直接送信する場合を実線にて示しているが、カーシェアリング管理サーバを介する場合については、破線にて示している。

（図５）
図５に示すのは、会員ユーザがカーシェアリングを希望したものの希望する日時にはシェアカー（希望車種Ａ）が確保できなかった場合において、レンタカーであれば確保できる旨を、会員ユーザに係る通信端末の出力画面へ出力させた一例を示したものである。図３の画面下方における「はい」のボタンをクリックした後に出力される画面ともいえる。

会員ユーザは、カーシェアリングでの車両確保を希望していたので、駐車場Ｘまたは駐車場Ｙへ出向いて車両を確保することを想定していたはずである。そこで、出力画面の下方において、「車種Ａの予約をありがとうございます。車種Ａの駐車場Ｙへの配車を希望しますか？」という質問とともに、「はい」および「いいえ」のボタンを準備している。また、「配車」の意味を直観的に把握してもらえるような図示もしている。
そして、『「いいえ」の場合には、予約時刻までにＺへお越し下さい。「はい」の場合には、利用実績に応じて追加料金が掛かります。』という説明文も表示される。なお、追加料金について算出済みで表示も可能であれば、表示することが望ましい。

さて、詳細なアルゴリズムなどは省略しているが、配車が可能であるか否か、および可能である配車は駐車場Ｙ（駐車場Ｘではなく）としているのは、周辺地域の地理的な条件や交通事情などに基づいている。
図５に示した地域では、レンタカー駐車場Ｚとカーシェア駐車場Ｙは、○○駅のある線路によって分断された同じ側に位置しているが、カーシェア駐車場Ｘは、レンタカー駐車場Ｚから見て線路の反対側に位置している。そのため、レンタカー駐車場Ｚからカーシェア駐車場Ｘへ配車をするのは、カーシェア駐車場Ｙへの配車よりも距離が遠いのみならず、時間が掛かる確率が極めて高い。
そこで、会員ユーザに対しては、駐車場Ｙへの配車が可能であるという連絡はするものの、駐車場Ｘへの配車も可能である、というような積極的な表示をしていないのである。

（図６）
図６は、カーシェアリングを利用していた一の会員ユーザが、予約に係る返却予定時刻を超過するおそれが生じた場合であって、そのシェアカーに対する別の会員ユーザの予約が入っている場合に、代車を手配するためのアルゴリズムを示している。
予約に係る返却予定時刻を超過するおそれが生じた場合とは、事故、車両故障、車内清掃が必要な事態の発生などの場合もある。

まず、シェアカーの返却が次の予約時刻を超過するおそれが生じた場合、カーシェアリング管理サーバは、次の予約に係る駐車場に代車がないかどうかを確認する。代車が無い場合には、周辺（近傍）のシェアカー駐車場またはレンタカー駐車場に、次の予約内容を遂行可能な代車がないかを検索する（Ｓ１）。
周辺（近傍）のシェアカー駐車場またはレンタカー駐車場に、次の予約内容を遂行可能な代車が存在する場合、次の予約に係る駐車場までの配車が可能かどうかを検証する（Ｓ２）。
配車が可能である場合、次の予約に係る希望車種が一致しているかどうかを検証する（Ｓ３）。

次の予約内容を遂行可能な代車が検索しても見つけられない場合（Ｓ１）、次の予約に係る駐車場までの配車ができない場合（Ｓ２）、次の予約に係る希望車種が一致していない場合（Ｓ３）のいずれも、次の予約に係るユーザ（の携帯情報端末）へお詫びの連絡を入れる（Ｓ４）。
代車が見つかり、配車も可能であり、希望車種も一致している場合には、予約に係るユーザへの連絡は不要である。

（図７）
図７は、図６のアルゴリズムを実行するためのハードウェアを含めたブロック図である。
シェアカーに搭載された多機能カーナビゲーション装置から、そのシェアカーにてカーシェアリングを利用していた会員ユーザＡによる、予約に係る返却予定時刻を超過するおそれが生じた旨の緊急連絡を、カーシェアリング管理サーバが受信する。
会員ユーザＡからの連絡が無くても、シェアカーに搭載されたＧＰＳからの位置情報をカーシェアリング管理サーバが取得し、予約に係る返却予定時刻を超過するおそれが生じた旨を、予定超過検知手段が検知して判断する場合もある。

車両管理データベースからのデータ取得によって予定超過検知手段が、予約に係る返却予定時刻を超過するおそれが生じたと判断した場合、カーシェアリング車両管理データベースやレンタカー車両管理データベースへ代車検索手段がアクセスし、代車を探す。
代車が検索できた場合には、その代車を次の予約に係る会員ユーザＢが希望する駐車場へ配車が可能であるか否かを検証する。
そして、代車の手配ができたものの会員ユーザＢが希望する車種ではない場合や、代車の手配ができなかった場合には、検証結果送信手段がその旨を会員ユーザＢに係る携帯通信端末へ送信する。
この図では、『予約いただいていたシェアカーですが、前のお客様の事故により予約遂行ができなくなりました。代車の手配も適いません。申し訳ありません。』という連絡をした場合について、図示している。

（図８）
図８は、代車は手配できるが会員ユーザＢが希望する車種と異なるという場合に、検証結果送信手段がその旨を会員ユーザＢに係る携帯通信端末へ送信した画面内容を示したものである。
代車の予約をするか否かを、「はい」、「いいえ」ボタンを用意することによって、データ処理を素早く実行する。会員ユーザへの利便性を高める、という趣旨の他、代車を手配する都合上、会員ユーザからは即答してもらうことが望まれるためである。

（図９）
図９は、図１に示した第一の実施形態におけるバリエーションのハードウェア構成の概略図である。すなわち、レンタカーサービスを利用しようとしたユーザ（ここでは予めの会員をしていないユーザを想定）が、レンタカーを利用しようとして車両データを閲覧し、予約希望の旨を送信した場合に（１）、希望の時間帯でのレンタカー車両が確保できない場合に、カーシェアリングに用いているシェアカーを手配できるように、紹介データを送信する（２）。
レンタカーが利用できない場合にシェアカーを予約したい、とこのユーザが希望する場合、一時的にカーシェアリングを利用する会員登録をユーザにお願いし（３）、会員仮登録データを発行する（４）ことで、カーシェアリングサービスを利用できる（５）、というようにしている。

（図１０）
図１０は、図１や図９に示していたカーシェアリング管理サーバとレンタカー管理サーバとを一体とし、サービス運営者は、シェアカーとレンタカーとをシームレスで、カーシェアリングサービスの会員ユーザへ提供できるようにしたものである。
このサーバにおける予約可能判断手段が予約データを受信したら（１）、カーシェアリング車両管理データベースとレンタカー車両管理データベースとを検索し（２、２’）、予約可能な車両があれば、予約可否出力手段が会員ユーザに係る通信端末へ出力する（３）。
この図示例の場合には、シェアカーでは予約ができないが、所定のレンタカーであれば予約が可能である旨を出力している。

予約可否に関する出力を受信した会員ユーザは、レンタカー車両管理データベースを閲覧して確認し（４）、納得すれば、予約データを送信する（５）。この予約データは、予約を希望する日時や車種などの新たな入力は不要であり、再送信にちかい。

前述した実施形態によれば、カーシェアリングにおける車両管理とレンタカーにおける車両管理とを融合させることで、車両を合理的に融通し合うことが可能な車両管理システムを実現することができた。
車両の返却遅れや予約に係る車両の各種トラブルによっても代車を確保しやすくなり、ユーザにとってもサービス運営者にとっても各種トラブルへ対応する場合の選択肢を増やすことに貢献している。

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

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

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

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

（図１２）
図１２もまた、カーシェアリングのへヴィーユーザや高額な基本料金を支払っている特別な会員ユーザ（仮に「プレミア会員」と称する）に対してのみ提供するカーシェアリングサービスの概要を示す第七の実施形態に係るフローチャートである。図１も交えて説明する。
まず、図１のようにカーシェアリングの会員が予約データを送信したとする（１）。その予約データを受信したカーシェアリング管理サーバでは、カーシェアリング用の車両管理データベースへアクセスして検索し、予約内容を遂行できるかどうかを判断する（２）。その判断結果として、当該予約データを遂行できるシェアカーが存在しないことが判明した（図１２のＳ０）。

次に、図１に示した会員データベースへアクセスし、当該予約データに係る会員ユーザがプレミア会員か否かを判断する（図１２のＳ１）。プレミア会員であれば、レンタカー管理サーバの車両管理データベースへアクセスし、当該予約データを遂行できるレンタカーがあるかどうかを検索する（図１の２’、および図１２のＳ２、Ｓ３）。
予約データに係る条件を満たすレンタカーを検索できた場合には、当該予約データに係る会員ユーザ（の情報端末）に対して、レンタカー管理サーバの車両管理データベースへアクセスできるような案内を送信する（図１の３、および図１２のＳ４）。

その後、会員ユーザは、レンタカー管理サーバの車両データ閲覧手段へアクセスして閲覧し、予約に係る車両を確認する（４）。そして、その内容に満足したら、予約データをレンタカー管理サーバへ送信する（５）。
会員ユーザがプレミア会員ではない場合には（Ｓ１）、予約を受け付けられない旨を会員ユーザへ連絡して終了する。会員ユーザがプレミア会員であっても、レンタカーに空きがなければ（Ｓ３）、予約を受け付けられない旨をプレミア会員へ連絡して終了する。具体的には、カーシェアリング予約専用サイトからのアクセスなどの場合、図３や図８に示したような地図とともに、該当する車両がないことを表示することとなる。

第七の実施形態によれば、プレミア会員であれば、一般会員に比べて予約による車両の確保に関する検索範囲が広がり、車両を確保をしやすくなるという付加価値のあるサービスを提供可能となった。
会員が法人である場合において、規模の大きな法人会員は、ヘヴィーユーザになりやすく、車両の確保がシームレスでしやすくなる、ということは会員にとってもメリットが大きい。

本発明は、カーシェアリングまたはレンタカーを管理運営するサービス業、カーシェアリングまたはレンタカーを実現するためのサポートをする情報通信サービス業、カーシェアリングまたはレンタカーの運営のためのコンピュータソフトウェアを作成するソフトウェア産業、カードクレジット業、旅行代理業、営業用車両の管理を委託される代行業などにおいて利用可能性を有する。

Claims (10)

1. 車両共有サービスにおけるサービス対象車両に関するデータを管理する車両管理サーバであって、
   サービス対象車両の貸し出し状況や予約に関する車両管理データを蓄積する第一の車両管理データベースと、
   その第一の車両管理データベースとは別の目的のサービス対象車両を管理および貸し出している当該車両の貸し出し状況や予約に関する車両管理データを蓄積する第二の車両管理データベースと、
   ユーザに係る通信端末からの車両の貸し出し予約についての予約データを受信する予約データ受信手段と、
   その予約データ受信手段が受信した予約データについて予約が可能であるか否かを前記の第一の車両管理データベースを用いて判断するとともに、予約ができないと判断した場合に第二の車両管理データベースを用いて判断する予約可能判断手段と、
   その予約可能判断手段の判断結果を前記のユーザに係る通信端末へ出力する予約可否出力手段と、
   ユーザに関する利用履歴データを格納した会員データベースと、
   を備え、
   前記の予約可能判断手段は、前記の予約データに係るユーザが所定条件を満たしているか否かを、前記の会員データベースに格納された利用履歴データを用いて判断するとともに、前記の所定条件を満たしている場合にのみ、前記の第二の車両管理データベースを用いての判断を実行することとし、
   前記の予約可否出力手段は、第一の車両管理データベースに係る予約ができない場合であって第二の車両管理データベースに係る予約であれば予約が可能である場合には、その旨を前記の判断結果に含むこととした
   車両管理サーバ。
2. 前記の予約可否出力手段は、前記の予約可能判断手段によって予約できないと判断された車両の貸し出し場所および予約可能と判断された車両の貸出場所を前記の予約データに係るユーザの通信端末へ地図データとともに一画面で出力させることとし、
   前記の第二の車両管理データベースに係る予約であれば予約が可能である旨を受信したユーザに係る通信端末から当該予約を希望する旨の第二の予約データを受信する第二の予約データ受信手段を備え、
   その第二の予約データ受信手段が受信した第二の予約データは、前記の第二の車両管理データベースへ蓄積することとした請求項１に記載の車両管理サーバ。
3. ユーザが希望する受け取り場所のデータを含んだ配車予約データをユーザに係る通信端末から受信する配車予約データ受信手段と、
   その配車予約データに基づく配車の予約が可能かどうかを前記の第二の車両管理データベースを用いて判断するとともに、その判断結果をユーザに係る通信端末へ出力する配車可能判断手段と、
   配車が可能である旨の判断結果を受信したユーザに係る通信端末からの配車要請を実行するためのデータ処理する配車要請処理手段と、を備えた請求項２に記載の車両管理サーバ。
4. 前記の配車可能判断手段は、配車が可能である旨の判断結果を出力する場合において、
   前記の会員データベースの利用履歴データを用いて配車に係るサービス料金を算出することとし、
   前記の判断結果には、そのサービス料金を含ませることとした請求項３に記載の車両管理サーバ。
5. 一のユーザが使用中のサービス対象車両が返却予定時刻を超過するおそれがある旨を検知する予定超過検知手段と、
   その予定超過検知手段が検知したサービス対象車両を次に使用予定のユーザに係る予約データを遂行可能かどうか、第一の車両管理データベースおよび／または第二の車両管理データベースを検索する代車検索手段と、
   その代車検索手段によって検索したサービス対象車両が、前記の予約データに係る乗車場所へ配車が可能かどうかを検証する配車検証手段と、
   その配車検証手段における検証結果を、前記した次に使用予定のユーザに係る通信端末へ送信する検証結果送信手段と、
   を備えた請求項１から請求項４のいずれかに記載の車両管理サーバ。
6. 車両共有サービスにおけるサービス対象車両に関するデータを管理する車両管理サーバを制御するためのコンピュータプログラムであって、
   前記の車両管理サーバは、サービス対象車両の貸し出し状況や予約に関する車両管理データを蓄積する第一の車両管理データベースと、
   その第一の車両管理データベースとは別の目的のサービス対象車両を管理および貸し出している当該車両の貸し出し状況や予約に関する車両管理データを蓄積する第二の車両管理データベースと、ユーザに関する利用履歴データを格納した会員データベースと、を備え、
   車両管理サーバを制御するためのコンピュータプログラムは、
   ユーザに係る通信端末からの車両の貸し出し予約についての予約データを受信する予約データ受信手順と、
   その予約データ受信手順にて受信した予約データについて予約が可能であるか否かを前記の第一の車両管理データベースを用いて判断するとともに、予約ができないと判断した場合に第二の車両管理データベースを用いて判断する予約可能判断手順と、
   その予約可能判断手順における判断結果を前記のユーザに係る通信端末へ出力する予約可否出力手順と、
   を前記の車両管理サーバに実行させるものであり、
   前記の予約可能判断手順は、前記の予約データに係るユーザが所定条件を満たしているか否かを、前記の会員データベースに格納された利用履歴データを用いて判断するとともに、前記の所定条件を満たしている場合にのみ、前記の第二の車両管理データベースを用いての判断を実行することとし、
   前記の予約可否出力手順は、第一の車両管理データベースに係る予約ができない場合であって第二の車両管理データベースに係る予約であれば予約が可能である場合には、その旨を前記の判断結果に含むこととした
   コンピュータプログラム。
7. 前記の予約可否出力手順においては、前記の予約可能判断手順において予約できないと判断された車両の貸し出し場所および予約可能と判断された車両の貸出場所を前記の予約データに係るユーザの通信端末へ地図データとともに一画面で出力させるとともに、
   前記の第二の車両管理データベースに係る予約であれば予約が可能である旨を受信したユーザに係る通信端末から当該予約を希望する旨の第二の予約データを受信する第二の予約データ受信手順と、
   その第二の予約データ受信手順にて受信した第二の予約データを前記の第二の車両管理データベースへ蓄積する第二の予約データ蓄積手順と、
   を前記の車両管理サーバに実行させることとした請求項６に記載のコンピュータプログラム。
8. ユーザが希望する受け取り場所のデータを含んだ配車予約データをユーザに係る通信端末から受信する配車予約データ受信手順と、
   その配車予約データに基づく配車の予約が可能かどうかを前記の第二の車両管理データベースを用いて判断するとともに、その判断結果をユーザに係る通信端末へ出力する配車可能判断手順と、
   配車が可能である旨の判断結果を受信したユーザに係る通信端末からの配車要請を実行するためのデータ処理する配車要請処理手順と、
   を、車両管理サーバに実行させることとした請求項７に記載のコンピュータプログラム。
9. 前記の配車可能判断手順は、配車が可能である旨の判断結果を出力する場合において、
   前記の会員データベースの利用履歴データを用いて配車に係るサービス料金を算出する手順を含むこととし、
   前記の判断結果には、そのサービス料金を含ませることとした請求項８に記載のコンピュータプログラム。
10. 一のユーザが使用中のサービス対象車両が返却予定時刻を超過するおそれがある旨を検知する予定超過検知手順と、
    その予定超過検知手順にて検知したサービス対象車両を次に使用予定のユーザに係る予約データを遂行可能かどうか、第一の車両管理データベースおよび／または第二の車両管理データベースを検索する代車検索手順と、
    その代車検索手順にて検索したサービス対象車両が、前記の予約データに係る乗車場所へ配車が可能かどうかを検証する配車検証手順と、
    その配車検証手順による検証結果を、前記した次に使用予定のユーザに係る通信端末へ送信する検証結果送信手順と、
    を、車両管理サーバに実行させることとした請求項６から請求項９のいずれかに記載のコンピュータプログラム。

Images