(57)【要約】【課題】車両の偏在を抑制する車両管理方法及び車両管理システムを提供する。【解決手段】複数のユーザに利用される複数の車両を管理方法であって、ユーザから車両の利用要求を受け付けるとともに、車両の利用状態及び前記車両のステーションの状態を管理し、車両の利用状態及び前記ステーションの状態を記憶し、ユーザから受け付けた利用要求に基づいて、車両の貸出を行うステーション及び車両が返却されるステーションを利用ステーションとして選定し、利用ステーションの状態に応じて車両の相乗りの可否を判定し、車両の相乗りが可能であると判定した場合に、相乗りに関する情報を前記ユーザに通知する。【選択図】  図５
2018081575.tif 000002
【特許請求の範囲】
【請求項１】
複数のユーザに利用される複数の車両の管理方法であって、
前記ユーザから前記車両の利用要求を受け付けるとともに、前記車両の利用状態及び前記車両のステーションの状態を管理し、
前記車両の利用状態及び前記ステーションの状態を記憶し、
前記ユーザから受け付けた前記利用要求に基づいて、前記車両の貸出を行う前記ステーション及び前記車両が返却される前記ステーションを、利用ステーションとして選定し、
前記利用ステーションの状態に応じて、前記車両の相乗りの可否を判定し、
前記車両の相乗りが可能であると判定した場合に、相乗りに関する情報を前記ユーザに通知する
車両の管理方法。
【請求項２】
請求項１記載の車両の管理方法であって、
前記車両の需要から前記利用ステーションの状態を推定し、
推定された前記利用ステーションの状態に応じて、前記車両の相乗りの可否を判定する
車両の管理方法。
【請求項３】
請求項２記載の車両の管理方法であって、
時間帯毎の前記車両の需要を推定し、
前記利用要求により示される前記車両の利用時間、及び、前記推定された前記時間帯毎の前記車両の需要から、前記利用ステーションの状態を推定する
車両の管理方法。
【請求項４】
請求項２又は３に記載の車両の管理方法であって、
前記複数のユーザから、前記車両の前記利用要求を利用予約として受け付け、
前記利用予約の情報をデータベースに記憶し、
前記データベースに記憶された前記利用予約の情報から前記車両の需要を推定する
車両の管理方法。
【請求項５】
請求項２又は３に記載の車両の管理方法であって、
前記車両の利用実績の情報をデータベースに記憶し、
前記データベースに記憶された前記利用実績の情報から前記車両の需要を推定する
車両の管理方法。
【請求項６】
請求項１〜５のいずれか１項に記載の車両の管理方法であって、
貸し出される前記車両の稼働率が最大となるように、前記車両の相乗りの可否を判定する
車両の管理方法。
【請求項７】
請求項１〜６のいずれか一項に記載の車両の管理方法であって、
前記利用ステーションの状態により示される前記車両の利用率が所定値より大きい場合には、前記車両の相乗りが可能であると判定する
車両の管理方法。
【請求項８】
複数のユーザに利用される複数の車両を管理する車両管理システムであって、
ユーザから前記車両の利用要求を受け付けるとともに、前記車両の利用状態及び前記車両のステーションの状態を管理するコントローラと、
前記車両の利用状態及び前記ステーションの状態を記憶するデータベースとを備え、
前記コントローラは、
前記ユーザから受け付けた前記利用要求に基づいて、前記車両の貸出を行う前記ステーション及び前記車両が返却される前記ステーションを、利用ステーションとして選定し、
前記利用ステーションの状態に応じて、前記車両の相乗りの可否を判定し、
前記車両の相乗りが可能であると判定した場合に、相乗りに関する情報を前記ユーザに通知する
車両管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両管理方法及び車両管理システムに関するものである。
【背景技術】
【０００２】
従来の相乗り仲介方法として、以下のような方法が知られている。仲介管理サーバは、ネットワーク網を介して、利用者端末からタクシーの相乗りが申し込まれた場合に、相乗り管理データベースを参照し、ユーザ同士の相乗り希望条件が適合するか否か判断する。ユーザ同士の相乗り希望条件が、例えば「女性に限る」であれば、その条件に適合する場合に限り、相乗りが成立したものとして決定し、その旨を各利用端末へ通知する（特許文献１）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−４４７０２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記従来の相乗り仲介方法をカーシェアリングシステム等の車両管理システムに適用する場合には、特定のエリアで車両が過剰に存在し、特定のエリアで車両が不足するような車両の偏在が発生するという問題があった。
【０００５】
本発明が解決しようとする課題は、車両の偏在を抑制する車両管理方法及び車両管理システムを提供することである。
【課題を解決するための手段】
【０００６】
本発明は、複数のユーザに利用される複数の車両を管理方法又は及び車両管理システムであって、ユーザから車両の貸出要求を受け付けるとともに、車両の利用状態及び車両のステーションの状態を管理し、利用要求に基づいて、車両の貸出を行うステーション及び車両が返却されるステーションを利用ステーションとして選定し、利用ステーションの状態に応じて、車両の相乗りの可否を判定し、車両の相乗りが可能であると判定した場合に、相乗りに関する情報をユーザに通知することによって上記課題を解決する。
【発明の効果】
【０００７】
本発明によれば、車両の偏在を抑制できるという効果を奏する。
【図面の簡単な説明】
【０００８】
【図１】図１は、本実施形態に係るカーシェアリングシステムのブロック構成図である。
【図２】図２は、サーバ側の制御装置の機能ブロックを示すブロック構成図である。
【図３】図３は、所定のステーション毎に複数の駐車スペースを設けた例を示す図である。
【図４】図４は、図３に示す各ステーションＡ〜Ｄと需要の関係を示す図である。
【図５】図５は、本実施形態に係るカーシェアリングシステムにおいて、制御装置の制御フローを示すフローチャートである。
【図６】図６は、所定のステーション毎に複数の駐車スペースを設けた例を示す図である。
【図７】図７は、本発明の他の実施形態に係るカーシェアリングシステムにおいて、制御装置の制御フローを示すフローチャートである。
【図８】図８は、出発側の相乗りの判定結果、到着側の相乗りの判定結果、及び最終的な相乗りの判定結果との対応関係を示す表である。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態を図面に基づいて説明する。  
【００１０】
《第１実施形態》
図１は、本実施形態に係るカーシェアリングシステムのブロック構成図である。図２は、サーバ側の制御装置の機能ブロックを示すブロック構成図である。図１に示すように、本実施形態のカーシェアリングシステムは、管理サーバ１００と、カーシェアリングに供される複数の共用車両２００と、インターネット３００を介して車両管理サーバ１００と通信可能な複数のユーザ端末４００とから構成される。なお、図１中においては、共用車両２００を２台のみ示したが、本実施形態のカーシェアリングシステムは、多数の共用車両２００から構成される。そして、本実施形態のカーシェアリングシステムにおいては、多数の共用車両２００が、各所に設けられた所定の駐車スペースにそれぞれ駐車されており、特定多数のユーザが、所望の駐車スペースに駐車された共用車両２００を選択して利用できるようになっている。
【００１１】
図１に示すように、共用車両２００は、管理サーバ１００と相互に通信が可能となっており、車載装置２１０と、通信装置２２０とを備えている。車載装置２１０は、共用車両２００の利用開始時刻および利用終了時刻の情報、走行距離の情報、自車両位置の情報、車速の情報、バッテリの残量の情報、車両のパワースイッチのオン、オフの情報などを、通信装置２２０から、無線通信により管理サーバ１００に備えられた通信装置１２０に送信する。また通信装置２２０は、管理サーバ１００から信号により送信される情報を受信する。
【００１２】
なお、車載装置２１０が、自車両位置の情報を取得する方法としては、たとえば、各共用車両２００に備えられたＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）により測位衛星から発信される電波を所定時間ごとに受信することで、各共用車両２００のリアルタイムの位置情報を取得する方法などが挙げられる。
【００１３】
ユーザ端末４００は、本実施形態のカーシェアリングシステムを利用する特定多数のユーザが所有する端末であり、インターネット３００を介して、管理サーバ１００に備えられた通信装置１２０と通信可能となっている。本実施形態のカーシェアリングシステムにおいては、各ユーザは、ユーザ端末４００により、共用車両２００の利用申込みを行うことができるようになっている。
【００１４】
ここで、共用車両２００の利用申込みとしては、ユーザが利用申込みの直後に共用車両２００の利用を開始するような即時利用の申込みでもよいし、ユーザが将来に共用車両２００を利用するための利用予約の申込みでもよい。
【００１５】
また、本実施形態のカーシェアリングシステムにおいては、ユーザがユーザ端末４００により共用車両２００の利用申込みをする際において、ユーザは、共用車両２００を利用した後に返却するための返却予定地の設定を行う。
【００１６】
なお、ユーザ端末４００としては、たとえば、パソコンの他、携帯電話、ＰＤＡなどの各種移動端末などが挙げられる。ユーザ端末４００が携帯電話である場合には、通信装置１２０で通信する車両情報を、各種の無線機規格に基づく無線通信でユーザ端末４００に読み込ませて、当該ユーザ端末４００が、車両情報等を管理サーバ１００に送信してもよい。図１中においては、ユーザ端末４００として４つの端末を例示して示したが、ユーザ端末４００および本実施形態のカーシェアリングシステムを利用するユーザの数は、特に限定されるものではない。
【００１７】
また、管理サーバ１００は、制御装置１１０と、通信装置１２０と、データベース１３０とを備えている。
【００１８】
通信装置１２０は、無線通信により、共用車両２００に備えられた通信装置２２０と、また、インターネット３００を介して、各ユーザの所有するユーザ端末４００と通信するための装置である。通信装置１２０は、無線通信により、車載装置２１０から、共用車両２００の利用開始時刻および利用終了時刻の情報、走行距離の情報、ならびに車両位置の情報などを、また、ユーザ端末４００から、ユーザによる共用車両２００の利用申込みの情報、およびユーザにより選択された返却予定地の情報などを取得する。利用申し込みの情報には、利用を希望する車両の情報、サービスの利用履歴、会員登録情報等を含む。
【００１９】
データベース１３０は、共用車両２００ごとに、利用受付情報、および返却予定地情報、駐車中の駐車スペースの位置情報等を記憶するための記憶装置である。なお、利用受付情報、および返却予定地情報は、ユーザによって、ユーザ端末４００を介して共用車両２００の利用申込み、利用可能車両の選択、及び返却予定地の選択がされた場合に、ユーザ端末４００から送信された情報に基づいて、共用車両２００ごとに生成される情報である。また、カーシェアリングシステムの利用者を会員に限定している場合には、データベース１３０は、登録した会員の情報、会員が登録したユーザ端末４００の識別情報なども記憶している。
【００２０】
さらに、データベース１３０には、共用車両２００を駐車するための複数の駐車スペースの情報が記憶されている。具体的には、データベース１３０には、所定の区域に複数設けられた駐車スペースの位置情報等が記憶されている。本実施形態のカーシェアリングシステムにおいて、駐車スペースは、共用車両２００を駐車するための駐車場であり、複数の駐車スペースが設けられた区域が駐車ステーションである。
【００２１】
図３は、所定のステーション毎に複数の駐車スペースを設けた例を示す図である。駐車ステーションは、駅等の公共施設、スタジアム等の集客施設に限らず、住宅街、オフィス街等の人が集まる施設に設けられている。例えばステーションＡ（ＳＴ＿Ａ）に設けられた４つの駐車スペースа〜ｄには、それぞれ共用車両２００が駐車されている。ユーザが、共用車両２００を利用して、例えばステーションＡからステーションＢに移動する場合には、ユーザは、貸出場所としてステーションＡを指定し、返却場所としてステーションＢを指定した上で、ユーザ端末４００を介して利用申込みを行う。そして、サーバが、利用申し込みに対して許可した場合には、ユーザは所望の共用車両２００を利用することができる。なお図３では、１つのステーションを、スタジアム、住宅街、駅、オフィス街として示しているが、複数のステーションから構成されるエリアの属性として考えてもよく、例えばスタジアムエリアにはа、ｂ、ｃ、ｄという１台の駐車スペースからなる複数のステーションで構成されていてもよい。
【００２２】
管理サーバ１００の制御装置１１０は、図１に示すように、各種プログラムが格納されたＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１１２と、このＲＯＭ１１２に格納されたプログラムを実行する動作回路としてのＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１１と、アクセス可能な記憶装置として機能するＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１１３と、を備えている。
【００２３】
そして、制御装置１１０は、本実施形態に係るカーシェアリングシステムを管理するために、ユーザからの予約を管理する予約管理機能、共用車両２００を管理する車両管理機能、ステーションの状態を管理するステーション管理機能及び相乗り判定機能を備える。制御装置１１０は、上記各機能を実現するためのソフトウェアと、上述したハードウェアの協働により各機能を実行することができる。また、制御装置１１０は、これらの各機能を発揮するための機能ブロックとして、図３に示すように、予約管理部１１、車両管理部１２、ステーション管理部１３及び相乗り判定部１４を有している。
【００２４】
以下に、管理サーバ１００の制御装置１１０が実現する各機能について、図２を用いてそれぞれ説明する。また、必要に応じて、車両側の制御も説明する。図２は、制御装置１１０の機能ブロックを示すブロック構成図である。
【００２５】
まず、制御装置１１０は、予約管理部１１により、ユーザから車両の利用の申し込みを受け付ける。具体的には、ユーザがユーザ端末４００を操作して共用車両２００の利用予約の申込みを行った場合に、予約管理部１１は、ユーザ端末４００から送信された利用予約情報に基づいて、利用の申し込みを受け付ける。
【００２６】
利用予約情報は、出発ステーションの情報、到着ステーションの情報、出発予定時刻、到着予定時刻等を含んでいる。出発ステーションの情報は、車両の貸出場所を示しており、到着ステーションの情報は、車両の返却予定地を示している。出発予定時刻は、車両の利用開始時刻であり、到着予定時刻は車両の返却予定時刻である。ユーザは、ユーザ端末４００を用いて、ステーションのリストから、出発ステーション及び到着ステーションを指定する。また、ユーザはユーザ端末４００を用いて、出発予定時刻及び到着予定時刻をそれぞれ入力する。このとき、ユーザ端末４００はサーバ１００と通信を行い、指定されたステーションに対して、利用可能な時間帯をディスプレイに表示してもよい。
【００２７】
予約管理部１１は、ユーザから受け付けた利用予約に基づいて、車両の貸出を行うステーションと車両が返却されるステーションを、管理対象のステーションの中から選定する。車両の貸出を行うステーションは、ユーザが指定した出発ステーションに相当し、車両が返却されるステーションはユーザが指定した到着ステーションに相当する。予約管理部１１は、選定したステーションの情報を含めて、利用予約情報を管理している。
【００２８】
また利用予約情報には、上記の情報に加えて、ユーザの現在地及び相乗り情報を含んでいる。ユーザ端末４００は、ユーザ端末に設けられたＧＰＳレシーバにより、ユーザの現在地を取得する。相乗り情報は、ユーザ端末４００の所有者（あるいは使用者）以外の他人が、同じ共用車両２００に乗車して、出発地から目的地まで移動してもよいか否かを表している。なお、相乗り情報は、利用申し込みをした複数のユーザが同じ共用車両２００に乗車して、出発地から目的地までの走行ルートの途中まで同乗してもよいか否かを表している。利用予約を行う際に、ユーザは、ユーザ端末４００を用いて、相乗りの希望があるか否かの意思表示を行う。そして、ユーザ端末４００は、ユーザからの入力が完了すると、ユーザの位置情報、相乗り情報及びステーション情報などを、利用予約情報として、サーバ１００に送信する。
【００２９】
予約管理部１１は、利用予約を受け付けた場合に、利用予約の情報をデータベース１３０に記憶する。データベース１３０は、時間、ステーション及びユーザ情報を対応させた上で、利用予約の情報を記憶する。
【００３０】
制御装置１１０は、ユーザからの車両の利用要求として、上記のような利用予約の申し込みに限らず、即時利用の申し込みを受け付けてもよい。例えば、共用車両２００をすぐに利用したい場合には、ユーザは共用車両２００の現在の空き状態を確認し、空いている共用車両２００、出発ステーション、到着ステーション及び到着予定時刻を指定する。出発ステーションは、指定された共用車両２００が現在駐車しているステーションである。制御装置１１０は、ユーザから即時利用の申し込みを受け付けると、利用要求に基づいて、出発ステーション及び到着ステーションを選定する。
【００３１】
車両管理部１２は、管理対象となる共用車両２００の利用状態を管理している。また、車両管理部１２は、通信装置１２０を用いて共用車両２００と通信を行い、共用車両２００の位置情報を取得することで、共用車両２００の位置を管理している。共用車両２００の利用状態には、現在車両が利用中である状態及び現在車両が利用されていない状態の少なくとも２つの状態を含んでいる。例えば、ユーザが共用車両２００の空き状態を知りたい場合には、車両管理部１２は、利用可能車両のリストを作成し、予約管理部１１に作成したリストを送信する。予約管理部１１は、通信装置１２０を用いてユーザに対して、利用可能車両のリストを送信する。利用可能車両は、現在利用されていない車両である。リストを受け取ったユーザはユーザ端末４００の表示画面上でリストを確認することで、利用可能車両と、当該利用可能車両の駐車位置を確認できる。
【００３２】
ステーション管理部１３は、ステーションの状態を管理している。ステーションの状態は、ステーションにおける車両の利用率を表す。車両の利用は、駐車スペースからの車両の出発だけでなく、駐車スペースへの車両の到着も含まれる。車両の利用率は、あるステーションにおいて、ユーザが車両を利用する割合又は確率を示しており、ユーザの需要によって決まる。また、車両の利用率は、日時及びステーションの場所に応じて決まる。
【００３３】
図３に示すステーションＡ〜Ｄについて、ステーションＡをスタジアムとし、ステーションＢを住宅街とし、ステーションＣを駅とし、ステーションＤをオフィス街とする。ステーションＡでは、車両の利用率は、スタジアムにおける開催行事の日時に応じて決まる。例えば、図４に示すように、イベントが１４時から１７時の間にスタジアムで行われる場合に、１４時より前の所定の時間帯（例えば１３時から１４時までの間）に、イベント参加予定者がスタジアムを訪問する。そのため、多くの共用車両２００がステーションＡの駐車スペースа〜ｄに到着する。すなわち、到着に関する車両の利用率が、１４時００分より前の所定の時間帯に高まる。イベント終了時からの所定の時間帯（例えば１７時から１８時までの間）には、イベント参加者がスタジアムから退出する。そのため、多くの共用車両２００がステーションＡの駐車スペースа〜ｄから出発する。すなわち、出発に関する車両の利用率が、１７時より後の所定の時間帯に高まる。
【００３４】
ステーションＢは住宅街のため、朝の通勤又は通学の時間帯（例えば、７時から８時までの間）に、出発に関する車両の利用率が高まる。夕方の通勤又は通学の時間帯（例えば、１９時から２０時までの間）に、到着に関する車両の利用率が高まる。なお、ステーションＢの車両の利用率は、平日の時間帯と祝祭日の時間帯でも変わる。
【００３５】
ステーションＣは駅のため、朝の通勤又は通学の時間帯（例えば、７時から８時）に、到着に関する車両の利用率が高まる。夕方の通勤又は通学の時間帯（例えば、１８時から１９時）に、出発に関する車両の利用率が高まる。
【００３６】
ステーションＤはオフィス街のため、始業予定時刻より前の所定の時間帯（例えば８時から９時の間）に、到着に関する車両の利用率が高まる。終業予定時刻より後の所定の時間帯（例えば１７時から１８時の間）に、出発に関する車両の利用率が高まる。
【００３７】
ステーション管理部１３は、ステーション毎の利用実績を管理している。ステーション管理部１３は、利用実績に基づいて車両の利用率を演算することで、共用車両２００の需要を管理する。そして、ステーション管理部１３は、共用車両２００の需要から、ステーションの状態を推定する。ステーションの状況を推定する場合には、ステーション管理部１３は、例えば以下の方法で、推定の対象となるステーションの利用率を時間帯ごとに演算する。時間帯は、例えば１時間刻み又は１５分刻みである。過去の利用実績は、データベース１３０に記憶されている。ステーション管理部１３は、データベース１３０から、ステーション管理部１３の利用実績の情報を取得する。利用実績の情報は、ステーションの識別情報、共用車両２００の出発回数、共用車両２００の到着回数等を含んでいる。なお、出発回数、到着回数、駐車時間は、時間帯と対応づけられている。
【００３８】
ステーション管理部１３は、取得した利用実績の情報を用いて、時間帯ごとの出発回数及び到着回数を演算することで、ステーションにおける共用車両２００の需要を推定する。例えば１時間当たりの出発回数が多いほど、又は、例えば１時間あたりの到着回数が多いほど、利用率は高まり、共用車両２００の需要度は高くなる。そして、ステーション管理部１３は、共用車両２００の需要度からステーションの状態を時間帯ごとに推定する。
【００３９】
ステーション管理部１３は、予約管理部１１で管理されている利用予約情報を用いて、車両の利用率を演算することで、共用車両２００の需要を管理してもよい。ステーション管理部１３は、データベース１３０から、利用予約情報を取得する。ステーション管理部１３は、取得した利用予約情報を用いて、時間毎の予約数を演算することで、ステーションにおける共用車両２００の需要を推定する。予約数は、出発と到着を区別した上で演算される。例えば１時間あたりの予約数が多いほど、共用車両２００の需要度は高くなる。そして、ステーション管理部１３は、共用車両２００の需要度からステーションの状態を時間帯ごとに推定する。なお、ステーション管理部１３は、利用実績の情報及び予約情報を両方用いて、共用車両２００の需要を演算により求めることで、ステーションの状態を推定してもよい。
【００４０】
相乗り判定部１４は、出発ステーションの状態及び返却ステーションの状態に応じて、共用車両２００の相乗りの可否を判定する。まず、予約管理部１１がユーザ端末４００から利用予約情報を取得すると、利用予約情報を相乗り判定部１４に送信する。相乗り判定部１４は、利用予約情報から相乗り情報を取得し、ユーザに相乗りの意思を確認する。
【００４１】
相乗りの希望がある場合には、相乗り判定部１４は、利用予約を申し込んだユーザ以外に、相乗りの希望があるユーザが存在するか否かを判定する。ここで、図３の例で、ユーザＶ及びユーザＷが、ステーションＡで行われる同じイベントに参加予定である、とする。ユーザＶ及びユーザＷは、共用車両２００を用いて、ステーションＢのある同じ住宅街に帰宅すると仮定する。ユーザＶが、共用車両２００を用いて、出発ステーションをステーションＡに指定し、到着ステーションをステーションＢに指定し、相乗りの希望があることを示し、利用予約の申し込みを行ったとする。ユーザＶの利用予約の申し込みの後、ユーザＷが利用予約の申し込みを行ったとする。ユーザＷは、出発ステーションをステーションＡに指定し、到着ステーションをステーションＢに指定し、相乗りの希望があることを示し、利用予約の申し込みを行ったとする。ユーザＶの利用開始時刻（出発時刻）とユーザＷの利用開始時刻（出発時刻）は、同じ時間帯（１６時から１７時）に属しているとする。
【００４２】
上記のような場合に、ユーザＷから利用予約の申し込みを受け付けると、相乗り判定部１４は、ユーザＷの相乗り情報に基づき、ユーザＷに相乗りの希望があることを確認する。
【００４３】
次に、相乗り判定部１４は、ユーザＷの条件に適した、相乗りを希望する他のユーザが存在するか否かを判定する。具体的には、相乗り判定部１４はユーザＷの現在地を中心とした許容範囲（以下、相乗り許容範囲とも称す）を設定する。相乗り許容範囲は、ユーザＷの現在地を中心として、例えば３００ｍを半径とする円で表される。相乗り許容範囲の中心は、ユーザＷの現在地に限らず、ユーザＷの出発ステーションの位置でもよい。相乗り判定部１４は、データベース１３０に記憶されている他のユーザの利用予約情報を取得し、利用予約情報に含まれるユーザの位置情報と相乗り許容範囲とを比較し、相乗り許容範囲内の他のユーザを特定する。相乗り許容範囲内に、相乗りを希望する他のユーザが存在しない場合には、相乗りは成立しない。図３の例では、ユーザＶが、ユーザＷの現在地の付近にいるため、相乗り判定部１４は、相乗り希望のユーザＶを特定する。
【００４４】
許容範囲内に、相乗りを希望する他のユーザが存在する場合には、相乗り判定部１４は、ユーザＷの利用条件と他のユーザの利用条件とを比較し、相乗りに適しているか否かを判定する。利用開始時刻が同じ時間帯に属し、出発ステーションが同一であり、到着ステーションが同一である場合に、相乗り判定部１４は、相乗りの条件を満たすと判定する。
【００４５】
相乗り許可の条件は、互いのユーザの出発ステーションの間の距離が所定距離未満である場合、又は、互いのユーザの到着ステーションの間の距離が所定距離未満である場合を含めてもよい。相乗り判定部１４は、ユーザＷにより指定されたステーションＡを中心とした所定範囲を、出発ステーション側の許容範囲（以下、出発ＳＴ許容範囲とも称す）に設定する。相乗り判定部１４は、ユーザＷにより指定されたステーションＢを中心とした所定範囲を、到着ステーション側の許容範囲（以下、到着ＳＴ許容範囲とも称す）に設定する。相乗り判定部１４は、出発ＳＴ許容範囲と、相乗りを希望している他のユーザの出発ステーションの位置を比較する。また、相乗り判定部１４は、到着ＳＴ許容範囲と、相乗りを希望している他のユーザの到着ステーションの位置を比較する。そして、出発ステーションの位置が出発ＳＴ許容範囲内であり、かつ、到着ステーションの位置が到着ＳＴ許容範囲内である場合には、乗り判定部１４は、相乗りの条件を満たすと判定する。
【００４６】
ユーザＶの利用予約のステーション条件及び時間条件は、ユーザＷの利用予約のステーション条件及び時間条件と合致する。そのため、相乗り判定部１４は、ユーザＷからの利用申し込みに対して、ユーザＶが相乗りに適していると判定する。
【００４７】
次に、相乗り判定部１４は、ステーション管理部１３から、出発ステーションにおける共用車両２００の需要に関する情報を取得する。共用車両２００の需要に関する情報は、時間帯毎及びステーション毎で区分けされている。相乗り判定部１４は、取得した車両需要の情報のうち、次の時間帯の車両の需要を特定する。次の時間帯は、利用予約の申し込みの際に、利用開始時刻に属する時間帯の次の時間帯である。利用開始時刻は、利用予約の申し込みの際に、取得した利用予約情報で示される。上記のユーザＷの例では、ユーザＷの利用開始時刻は１６時から１７時までの時間帯に属するため、次の時間帯は１７時から１８時までとなる。
【００４８】
ここで、図３に示す各ステーションＡ〜Ｄと需要の関係を、図４に示す。図４において、「出発需要増」は、該当する時間帯において、出発の利用率が高まることを示している。「到着需要増」は、該当する時間帯において、到着の利用率が高まることを示している。例えば、ステーションＡでは、共用車両２００を使ってステーションＡから出発したいことを希望しているユーザが、１７時から１８時の間に、多くなっていることを示している。また、ステーションＤでは、共用車両２００を使ってステーションＤから到着したいことを希望しているユーザが、８時から９時の間に、多くなっていることを示している。「出発需要増」の時間帯以外の時間帯は、出発の需要度が低くなっており、「到着需要増」の時間帯以外の時間帯は、到着の需要度が低くなっている。
【００４９】
図３のユーザＶ及びユーザＷの利用開始時刻が１６時から１７時までの時間帯に属する場合に、ユーザＷの利用開始時刻の次の時間帯（１７時から１８時まで）は、ステーションＡにおける「出発需要増」の時間帯に該当する。利用開始時刻の次の時間帯が「出発需要増」である場合には、利用開始時刻よりも後の時間帯に、多くの車両の需要が見込まれる。そのため、１７時の時点で、できるだけ多くの共用車両２００がステーションＡの駐車スペースに駐車していた方がよい。そして、相乗り可能なユーザが複数存在する場合に、出発後のステーションに、できるだけ多くの車両を駐車させた状態とするためには、相乗りを許可する方がよい。そして、相乗りを許可することで、車両の稼働率を高め、車両の偏在を抑制できる。
【００５０】
一方、例えば、ユーザＶ及びユーザＷの利用開始時刻が１８時から１９時までの時間帯に属する場合に、ユーザＷの利用開始時刻の次の時間帯（１９時から２０時まで）は、ステーションＡにおける「出発需要増」の時間帯から外れ、需要の少ない時間帯となる。このような場合には、利用開始時刻よりも後の時間に、共用車両２００の利用が見込まれないため、ステーションＡに共用車両２００を残すよりも、多くの車両をステーションＡから出発させた方がよい。相乗り可能なユーザが複数存在する場合でも、利用開始時刻よりも後、ステーションＡが車両過剰の状態となることを避けるために、相乗りを許可しない。これにより、今後、車両の需要増が見込まれないステーションから、多くの車両を移動させることができるため、車両の稼働率を高めることができる。
【００５１】
相乗り判定部１４は、次の時間帯の需要を表す利用率と所定の判定閾値とを比較する。利用率は、出発による需要を表している。あるステーションにおいて、利用率が高いほど、より多くのユーザが、当該ステーションに駐車されている共用車両２００を利用して、当該ステーションから出発することを希望していることになる。所定の判定閾値は、相乗りを許可するか否かを判定する閾値であって、システムの管理者によって予め設定されている。次の時間帯の利用率が判定閾値以上である場合には、相乗り判定部１４は相乗りを許可する。次の時間帯の利用率が判定閾値未満である場合には、相乗り判定部１４は相乗りを許可しない。
【００５２】
相乗り判定部１４は、各ステーションにおける共用車両２００の需要に関する情報と、データベース１３０に記録されている予約情報から、車両の稼働率を推定する。車両の稼働率は、管理対象の全ての共用車両２００の稼働率であって、例えば全車両の利用時間を全車両の台数で除算することで演算される。共用車両２００の利用時間は、利用予約情報から推定できる。そのため、相乗り判定部１４は、各ステーションにおける共用車両２００の需要に対して、共用車両２００の相乗りを許可した場合の、共用車両２００の稼働率と、共用車両２００の相乗りを許可しない場合の、共用車両２００の稼働率とを比較して、共用車両２００の稼働率が高くなるように、相乗りの可否を判定する。これにより、相乗り判定部１４は、共用車両２００の稼働率が最大となるように、共用車両２００の相乗りの可否を判定している。そして、相乗り判定部１４は、相乗りの判定結果を予約管理部１１に送信する。
【００５３】
次に、図５を用いて、制御装置１１０の制御フローを説明する。図５は、制御装置１１０の制御フローを示すフローチャートである。なお、図５に示す制御フローは、ユーザから利用予約の申し込みがあった場合に実行される。
【００５４】
ステップＳ１にて、予約管理部１１は、通信装置１２０から利用予約情報を取得し、車両の利用予約を受け付ける。ステップＳ２にて、予約管理部１１は、利用予約情報に基づき、予約ユーザが指定した出発ステーション及び到着ステーションを選定する。予約ユーザは、新規に予約を申し込んでいるユーザである。
【００５５】
ステップＳ３にて、相乗り判定部１４は、予約管理部１１から利用予約情報を受信し、利用予約情報から相乗り情報を取得する。予約管理部１１は、相乗り情報から相乗りの希望があるか否かを判定する。予約ユーザが相乗りを希望している場合には、制御フローはステップＳ４に進む。制御フローはステップＳ１４に進む。
【００５６】
ステップＳ４にて、相乗り判定部１４は、予約ユーザの現在地を中心として相乗り許容範囲を設定する。
【００５７】
ステップＳ５にて、相乗り判定部１４は、相乗り許容範囲内に、相乗りを許可する他のユーザがいるか否かを判定する。相乗りを許可する他のユーザが相乗り許容範囲内にいる場合には、制御フローはステップＳ６に進む。相乗りを許可する他のユーザが相乗り許容範囲内にいない場合には、制御フローはステップＳ１２に進む。
【００５８】
ステップＳ６にて、相乗り判定部１４は、ステーション管理部１３から、出発ステーションにおける共用車両２００の需要に関する情報を取得する。相乗り判定部１４は、取得した車両の需要に関する情報に基づき、出発ステーションにおける
車両の需要を時間帯ごとに特定する。出発ステーションは、予約ユーザによって指定されるステーションであって、ステップＳ２の制御フローで選定されたステーションである。相乗り判定部１４は、特定した時間帯ごとの車両の需要のうち、次の時間帯の需要を特定する。次の時間帯は、利用開始時刻に属する時間帯の次の時間帯である。これにより、相乗り判定部１４は、次の時間帯の需要を推定する。なお、次の時間帯の需要は、車両の利用率で表される。
【００５９】
ステップＳ７にて、相乗り判定部１４は、次の時間帯の利用率が所定の判定閾値以上であるか否かを判定する。また、相乗り判定部１４は、相乗りの判定結果を予約管理部１１に送信する。次の時間帯の利用率が判定閾値以上である場合には、相乗り判定部１４は相乗りを許可する。制御フローはステップＳ８に進む。次の時間帯の利用率が判定閾値未満である場合には、相乗り判定部１４は相乗りを許可しない。制御フローはステップＳ１１に進む。
【００６０】
ステップＳ８にて、予約管理部１１は、出発ステーション及び到着ステーションが予約可能であるか否かを判定する。例えば、予約管理部１１は、予約ユーザが指定する利用開始時刻の時間帯及び予約ユーザが指定する出発ステーションにおいて、予約数と予約の許容数とを比較する。予約数は、予約ユーザの申し込みを含めた、現在までの予約の申込数である。許容数は、ステーションに設定されている駐車スペースの数、ステーションにおける車両の需要等により設定される。予約数が許容数未満である場合には、予約管理部１１は、出発ステーションが予約可能であると判定する。予約数が許容数以上である場合には、予約管理部１１は、出発ステーションが予約不可であると判定する。予約管理部１１は、到着ステーションについても同様に、予約ユーザが指定する到着予定時刻の時間帯における予約数と許容数とを比較する。予約済みの予約数が許容数未満である場合には、予約管理部１１は、到着ステーションが予約可能であると判定し、予約済みの予約数が許容数以上である場合には、予約管理部１１は、到着ステーションが予約不可であると判定する。
【００６１】
出発ステーション及び到着ステーションが共に予約可能である場合には、制御フローはステップＳ９に進む。出発ステーション及び到着ステーションの少なくとも何れか一方のステーションが予約不可である場合には、制御フローはステップＳ１１に進む。
【００６２】
ステップＳ９にて、予約管理部１１は、データベース１３０に、確定した利用予約情報を記憶する。記憶される利用予約情報は、出発ステーション、到着ステーション、出発予定時刻、到着予定時刻、相乗りによる予約であること等を示す。
【００６３】
ステップＳ１０にて、予約管理部１１は、通信装置１２０を用いて、相乗りにより予約が完了したことを予約ユーザに通知する。そして制御フローが終了する。
【００６４】
ステップＳ１１にて、予約管理部１１は、通信装置１２０を用いて予約不可であることを予約ユーザに通知する。そして制御フローが終了する。
【００６５】
ステップＳ３の制御フローにおいて予約ユーザが相乗りを希望していない場合には、ステップＳ５の制御フローにおいて相乗りを許可する他のユーザが相乗り許容範囲内にいない場合には、又は、ステップＳ７の制御フローにおいて次の時間帯の利用率が判定閾値未満である場合（相乗りが許可されない場合）には、ステップＳ１２にて、予約管理部１１は、出発ステーション及び到着ステーションが予約可能であるか否かを判定する。ステップＳ１２の制御フローは、ステップＳ８の制御フローと同じである。
【００６６】
出発ステーション及び到着ステーションが共に予約可能である場合には、ステップＳ１３にて、予約管理部１１は、データベース１３０に、確定した利用予約情報を記憶する。ステップＳ１４にて、予約管理部１１は、通信装置１２０を用いて、相乗りではない予約が完了したことを予約ユーザに通知する。そして制御フローが終了する。
【００６７】
出発ステーション及び到着ステーションの少なくとも何れか一方のステーションが予約不可である場合には、ステップＳ１５にて、予約管理部１１は、通信装置１２０を用いて予約不可であることを予約ユーザに通知する。そして制御フローが終了する。
【００６８】
上記のように、本実施形態では、ユーザから共用車両２００の利用要求を受け付けるとともに、共用車両２００の利用状態及び共用車両２００のステーションの状態を管理し、共用車両２００の利用状態及び前記ステーションの状態を記憶する。ユーザから受け付けた利用要求に基づいて、共用車両２００の貸出を行うステーション及び車両が返却されるステーションを選定する。選定されたステーションの状態に応じて、共用車両２００の相乗りの可否を判定し、共用車両２００の相乗りが可能であると判定した場合に、相乗りに関する情報をユーザに通知する。これにより、カーシェアサービスの運行状況が適正になり、ユーザの利用機会の損失を減らしつつ、車両の偏在を抑制できる。
【００６９】
ところで、複数のユーザによって利用される車両を管理するシステムでは、ユーザの利用機会を確保しつつ、車両の利用回数を増やしたいという要望がある。相乗りを許可することは、共用車両２００を利用したい複数のユーザを、１台の車両で対応することになるため、事業者側にとっては利用回数が減ることになり、減収になる可能性がある。例えば、ステーションのある時間帯では、車両利用の需要が少ないにもかかわらず、利用可能車両が多く駐車していたり、車両利用の需要が多いにもかからず利用可能車両が不足したりする場合、すなわち車両の偏在が発生した場合には、ユーザからの要望を十分に受け入れることができない。
【００７０】
例えば、従来技術のように、ユーザの希望条件のみを考慮して、相乗りの可否判定を行った場合には、車両の偏在が発生し、サービスの運用効率が低下する。
【００７１】
本実施形態では、利用されるステーションの状態に応じて、車両の相乗りの可否を判定している。そのため、例えば、相乗りを希望するユーザから利用予約を受け付けた場合に、利用されるステーションの状態に応じて、車両の不足状態を防ぐために相乗りを許可したり、あるいは、車両の過剰状態を防ぐために相乗りを許可しなかったりする。これにより、車両の偏在を防ぎつつ、ユーザからの要望を十分に受け入れることができる。
【００７２】
また本実施形態では、車両の需要から、選定されたステーションの状態を推定し、推定されたステーションの状態に応じて、共用車両２００の相乗りの可否を判定する。これにより、車両の偏在を防ぎつつ、ユーザからの要望を十分に受け入れることができる。
【００７３】
また本実施形態では、時間帯毎の共用車両２００の需要を推定し、ユーザからの利用要求により示される共用車両２００の利用時間、及び、推定された時間帯毎の共用車両２００の需要から、利用ステーションの状態を推定する。これにより、時間帯ごとに変わる共用車両２００の需要を把握しつつ、車両の偏在を防ぐことができる。
【００７４】
また本実施形態では、複数のユーザから、共用車両２００の利用要求を利用予約として受け付け、利用予約の情報をデータベース１３０に記憶し、データベース１３０に記憶された利用予約の情報から共用車両２００の需要を推定する。これにより、共用車両２００の需要の予測精度を高めつつ、車両の偏在を防ぐことができる。
【００７５】
また本実施形態では、共用車両２００の利用実績の情報をデータベース１３０に記憶し、データベース１３０に記憶された共用車両２００の利用実績の情報から共用車両２００の需要を推定する。これにより、共用車両２００の需要の予測精度を高めつつ、車両の偏在を防ぐことができる。
【００７６】
また本実施形態では、貸し出される車両の稼働率が最大となるように、前記車両の相乗りの可否を判定する。これにより、共用車両２００の稼働率を高めつつ、共用車両２００の偏在を防ぐことができる。
【００７７】
また本実施形態では、車両の利用率が判定閾値より大きい場合には、共用車両２００の相乗りが可能であると判定する。これにより、車両の偏在を防ぐことができる。
【００７８】
なお、本実施形態では、ユーザから利用予約を受け付けた場合に、相乗りの可否を判定したが、相乗りの可否を判定するタイミングは任意のタイミングでよい。例えば、相乗り可否を判定することなく利用予約を受け付けて、相乗り判定部１４は、前日までに受け付けた利用予約と車両の需要に基づき、受け付けた利用予約のそれぞれに対して相乗りの可否を判定する。また、ステーション管理部１３は、所定のタイミング（例えば１時間毎）で、車両の需要を推定し、相乗り判定部１４は、車両の需要を推定したタイミングで、推定された需要に基づき相乗りの可否を判定する。なお、本実施形態では、ユーザからの相乗り希望に限らず、管理サーバ１００がユーザに対して相乗りを提案してもよい。例えば、車両の需要に対して、車両の稼働率が相乗りを行うことで高まる場合には、相乗り判定部１４は、ユーザの希望を示していないユーザに対して、相乗りを提案する。このとき、例えばシステム利用料の減額などを提案してもよい。
【００７９】
なお、共用車両２００の相乗りは、２人に限らず、共用車両２００の定員以内であれば３人以上のユーザでもよく、本実施形態は２人に限らず３人以上のユーザによる相乗りにも対応可能である。
【００８０】
《第２実施形態》
本発明の他の実施形態に係るカーシェアリングシステムについて説明する。本実施形態では、第１実施形態に対して、車両の相乗りの可否を判定する際の制御の一部が異なる。これ以外の構成は上述した第１実施形態と同じであり、その記載を援用する。
【００８１】
相乗り判定部１４は、利用予約を申し込んだユーザ以外に、相乗りの希望があるユーザが存在するか否かを判定する。この判定は、第１実施形態と同様である。
【００８２】
図６は、所定のステーション毎に複数の駐車スペースを設けた例を示す図である。ステーションＡ〜Ｄは、第１実施形態と同様に、スタジアム、住宅街、駅、オフィス街である。また、各ステーションにおける出発需要及び到着需要は、第１実施形態と同様であって、図４に示す時間帯に需要が増加する。
【００８３】
ここで、図６の例で、ユーザＸ及びユーザＹが、共用車両２００を用いて、ステーションＣを出発地として指定し、ステーションＤを到着地として指定したとする。またユーザＸ及びユーザＹは共に相乗りの希望を示しつつ、利用予約の申し込みを行ったとする。ユーザＸの利用予約の申し込みの後、ユーザＹが利用予約の申し込みを行ったとする。ユーザＸの利用開始時刻（出発時刻）とユーザＹの利用開始時刻（出発時刻）は、同じ時間帯に属しているとする。
【００８４】
第１実施形態と同様に、相乗り判定部１４は、ユーザＹから予約申し込みを受け付けると、ユーザＷの相乗り情報に基づき、ユーザＷに相乗りの希望があることを確認し、相乗りを希望する他のユーザとしてユーザＸを特定する。また、相乗り判定部１４は、ユーザＸの利用条件とユーザＹの利用条件とを比較し、ユーザＹがユーザＸとの相乗りに適していると判定する。
【００８５】
次に、相乗り判定部１４は、ステーション管理部１３から、到着ステーションにおける共用車両２００の需要に関する情報を取得し、取得した情報を用いて、到着ステーションにおける利用率を演算する。利用率は、出発利用率と到着利用率である。出発利用率は、ステーションから出発する車両の需要を表しており、例えば、演算対象のステーションを出発ステーションとして利用した実績数により演算される。到着利用率は、ステーションに到着する車両の需要を表しており、例えば、演算対象のステーションを到着ステーションとしてとして利用した実績数により演算される。各利用率は、時間帯ごとに演算される。なお、実績数の代わりに、予約数から各ステーションの需要を推定してもよい。
【００８６】
ここで、図６に示すユーザＸ及びユーザＹのステーションＤへの到着予定時刻が１６時から１７時までの時間帯に属する場合に、到着予定時刻の次の時間帯（１７時から１８時まで）は、ステーションＤにおける「出発需要増」の時間帯に該当する。到着予定時刻の次の時間帯が「出発需要増」である場合には、到着予定時刻よりも後の時間帯に、多くの車両の出発需要が見込まれる。そのため、１７時の時点で、車両不足の状態を防ぐために、できるだけ多くの共用車両２００がステーションＤの駐車スペースに駐車していた方がよい。そして、相乗り可能なユーザが複数存在する場合に、到着後のステーションに、できるだけ多くの車両を駐車させた状態とするためには、相乗りを許可せず、ユーザＸとユーザＹに別々の車両を貸し出した方がよい。相乗りを拒否することで、出発需要が増えているステーションに、多くの車両を移動させることができるため、車両の稼働率が高まる。
【００８７】
一方、図６に示すユーザＸ及びユーザＹのステーションＤへの到着予定時刻が１５時から１６時までの時間帯に属する場合に、到着予定時刻の次の時間帯（１６時から１７時まで）は、ステーションＤにおける「出発需要増」の時間帯から外れ、出発需要の少ない時間帯となる。このような場合には、到着予定時刻よりも後の時間に、共用車両２００の利用が見込まれないため、ステーションＤに多くの共用車両２００を移動させるよりも、ステーションＣに車両を残した方がよい。相乗り可能なユーザが複数存在する場合には、到着予定時刻よりも後に、ステーションＤが車両過剰の状態となることを避けるために、相乗りを許可する。これにより、今後、車両の需要増が見込まれないステーションに、多くの車両を移動させることを防ぎ、車両の稼働率の低下を抑制できる。
【００８８】
また、図６に示すユーザＸ及びユーザＹのステーションＤへの到着予定時刻が７時から８時までの時間帯に属する場合に、到着予定時刻の次の時間帯（８時から９時まで）は、ステーションＤにおける「到着需要増」の時間帯に該当する。到着予定時刻の次の時間帯が「到着需要増」である場合には、到着予定時刻よりも後の時間帯に、多くの車両の到着需要が見込まれる。すなわち、「到着需要増」の時間帯よりも前の予定時刻に、多くの車両がステーションＤに到着した場合には、ステーションＤは、「到着需要増」の時間帯に、車両過剰の状態になってしまう。そのため、ステーションＤにおいて、８時の時点で、できるだけ多くの駐車スペースを空き状態にした方がよい。そして、相乗り可能なユーザが複数存在する場合に、到着後のステーションに、できるだけ多くの駐車スペースを空けた状態とするためには、相乗りを積極的に許可する方がよい。相乗りを許可することで、到着需要が増えているステーションに移動する車両数が抑制されるため、「到着需要増」の時間帯に多くの車両を駐車させることができる。また複数のユーザＸ、Ｙの希望を満たすことができる。その結果として、ユーザの利用機会の損失を減らしつつ、車両の偏在を抑制できる。
【００８９】
一方、図６に示すユーザＸ及びユーザＹのステーションＤへの到着予定時刻が１０時から１１時までの時間帯に属する場合に、到着予定時刻の次の時間帯（１１時から１２時まで）は、ステーションＤにおける「到着需要増」の時間帯から外れ、到着需要の少ない時間となる。このような場合には、到着予定時刻よりも後の時間に、共用車両２００の到着が見込まれないため、ステーションＤに多くの共用車両２００を移動させてもよい。そして、相乗り可能なユーザが複数存在する場合に、到着後のステーションにおいて、駐車スペースを多く空けなくてもよいため、相乗りを許可せず、ステーションＣからステーションＤへ移動する車両数を多くする。これにより、車両の稼働率が高まる。
【００９０】
相乗り判定部１４は、到着予定時刻の次の時間帯の出発需要を表す出発利用率と、所定の出発判定閾値とを比較する。出発判定閾値は、相乗りを許可するか否かを判定する閾値であって、システムの管理者によって予め設定されている。次の時間帯の出発利用率が出発判定閾値以下である場合には、相乗り判定部１４は相乗りを許可する。次の時間帯の出発利用率が出発判定閾値より高い場合には、相乗り判定部１４は、到着利用率及び到着需要に基づき、相乗りの可否を判定する。
【００９１】
相乗り判定部１４は、到着予定時刻の次の時間帯の到着需要を表す到着利用率と、所定の到着判定閾値とを比較する。到着判定閾値は、相乗りを許可するか否かを判定する閾値であって、システムの管理者によって予め設定されている。次の時間帯の到着利用率が到着判定閾値以上である場合には、相乗り判定部１４は相乗りを許可する。次の時間帯の到着利用率が到着判定閾値未満である場合には、相乗り判定部１４は相乗りを許可しない。
【００９２】
次に、図７を用いて、制御装置１１０の制御フローを説明する。図７は、制御装置１１０の制御フローを示すフローチャートである。なお、図７に示す制御フローは、ユーザから利用予約の申し込みがあった場合に実行される。
【００９３】
ステップＳ２１からステップＳ３５までの制御フローのうち、ステップＳ２１〜Ｓ２６及びステップＳ２８〜Ｓ３５の制御フローは、第１実施形態に係るステップＳ１〜Ｓ６及びステップＳ８〜Ｓ１５の制御フローと同じである。
【００９４】
ステップＳ２７にて、相乗り判定部１４は、到着予定時刻の次の時間帯の出発利用率が出発判定閾値以下であるか否か、及び、到着予定時刻の次の時間帯の到着利用率が到着判定閾値以上であるか否か、を判定する。到着予定時刻の次の時間帯の出発利用率が出発判定閾値以下であることを第１条件とし、到着予定時刻の次の時間帯の到着利用率が到着判定閾値以上であることを第２条件とする。相乗り判定部１４は、第１条件及び第２条件のうちいずれか一方の条件を満たす場合には、相乗りを許可する。制御フローはステップＳ２８に進む。一方、相乗り判定部１４は、第１条件及び第２条件のいずれの条件を満たさない場合には、相乗りを許可しない。制御フローはステップＳ２９に進む。
【００９５】
上記のように、本実施形態では、ユーザから受け付けた利用要求に基づいて、共用車両２００の貸出を行うステーション及び車両が返却される前記ステーションを選定する。選定された到着ステーションの状態に応じて、共用車両２００の相乗りの可否を判定する。これにより、カーシェアサービスの運行状況が適正になり、ユーザの利用機会の損失を減らしつつ、車両の偏在を抑制できる。
【００９６】
《第３実施形態》
本発明の他の実施形態に係るカーシェアリングシステムについて説明する。本実施形態では、第１及び第２実施形態に対して、車両の相乗りの可否を判定する際の制御の一部が異なる。これ以外の構成は上述した第１、第２実施形態と同じであり、その記載を適宜、援用する。
【００９７】
管理サーバ１００が相乗りの希望があるユーザから利用予約を受け付けた場合に、相乗り判定部１４は、出発ステーションの需要に基づき相乗りの可否を判定しつつ、到着側ステーションの需要に基づき相乗りの可否を判定する。そして、相乗り判定部１４は、出発側の相乗りの判定結果と、到着側の相乗りの判定結果を合わせて、最終的に相乗りの可否を判定する。なお、相乗りの可否の判定以外の制御は、第１実施形態における制御装置１１０の制御と同様である。
【００９８】
出発側の相乗りの判定方法は、第１実施形態に係る判定方法と同様である。また、到着側の相乗りの判定方法は、第２実施形態に係る判定方法と同様である。
【００９９】
図８は、出発側の相乗りの判定結果、到着側の相乗りの判定結果、及び最終的な相乗りの判定結果との対応関係を示す表である。図８において、丸印は相乗りを許可することを表し、バツ印は相乗りを許可しないことを表す。三角印は、追加情報を加えたうえで、相乗りの可否を判定することを示している。
【０１００】
図８に示すように、相乗り判定部１４は、出発側の判定結果が相乗り許可であり、かつ、到着側の判定結果が相乗り許可である場合には、相乗りを許可する。相乗り判定部１４は、出発側の判定結果が相乗り拒否であり、かつ、到着側の判定結果が相乗り拒否である場合には、相乗りを許可しない。
【０１０１】
相乗り判定部１４は、出発側の判定結果が相乗り許可であり、かつ、到着側の判定結果が相乗り拒否である場合には、管理対象の全ステーションにおける車両の偏りに応じて、相乗りの可否を判定する。相乗り判定部１４は、出発側の判定結果が相乗り拒否であり、かつ、到着側の判定結果が相乗り許可である場合には、管理対象の全ステーションにおける車両の偏りに応じて、相乗りの可否を判定する。全ステーションにおける車両の偏りは、例えば、ステーションの車両占有率の分散値で表される。車両の占有率は、あるステーションに設置された複数の駐車スペースのうち、何台の車両が駐車しているかを表す。なお、分散値は、時間帯ごとに演算されてもよい。
【０１０２】
分散値が所定の閾値未満である場合には、相乗り判定部１４は、共用車両２００が特定のステーションに偏っているため、相乗りを許可しない。これにより、相乗りを許可しないことで、移動する車両数が増えるため、特定のステーションにおける車両の偏りを解消できる。分散値が所定の閾値以上である場合には、相乗り判定部１４は相乗りを許可する。
【０１０３】
上記のように、本実施形態では、本実施形態では、ユーザから受け付けた利用要求に基づいて、共用車両２００の貸出を行うステーション及び車両が返却される前記ステーションを選定する。選定された出発ステーション及び到着ステーションの状態に応じて、共用車両２００の相乗りの可否を判定する。これにより、カーシェアサービスの運行状況が適正になり、ユーザの利用機会の損失を減らしつつ、車両の偏在を抑制できる。
【０１０４】
なお、本実施系形態の変形例として、図８の三角印で示される判定結果になった場合には、相乗り判定部１４は相乗りを許可しない。これにより、移動する車両数が増えるため、車両の稼働率を高めることができる。
【符号の説明】
【０１０５】
１１…予約管理部
１２…車両管理部
１３…ステーション管理部
１４…相乗り判定部
１００…管理サーバ
１１０…制御装置
１１１…ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）
１１２…ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）
１１３…ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）
１２０…通信装置
１３０…データベース
２００…共用車両
２１０…車載装置
２２０…通信装置
３００…インターネット
４００…ユーザ端末
【図１】
2018081575.tif 000003
【図２】
2018081575.tif 000004
【図３】
2018081575.tif 000005
【図４】
2018081575.tif 000006
【図５】
2018081575.tif 000007
【図６】
2018081575.tif 000008
【図７】
2018081575.tif 000009
【図８】
2018081575.tif 000010