JP2021174197A - 情報処理装置、情報処理方法、およびプログラム - Google Patents

Abstract

【課題】ユーザに車両を貸与するシステムにおいて、車両の稼働率を向上させる。【解決手段】ユーザに対する車両の貸与を管理する情報処理装置。第一ユーザに対する車両の貸与計画を生成することと、前記車両の需要に関する需要データを取得することと、前記需要データに基づいて、前記貸与計画に含まれる、前記第一ユーザが前記車両を返却する地点である車両返却地点を変更することと、を実行する。【選択図】図１

Description

本開示は、車両の貸与を管理する情報処理装置に関する。

カーシェアリングといった、ユーザに対して一時的に車両を貸与する形態が増えている。これに関連し、特許文献１には、利用者に効率よくレンタカーの返却期限を通知するシステムが開示されている。

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

ユーザに車両を貸与する場合、基本的に、出発した地点に車両を返却することが求められる。しかし、十分な数の車両を供給できない場合、異なる地点に車両を返却したほうが全体における効率が上がる場合がある。

本開示は上記の課題を考慮してなされたものであり、ユーザに車両を貸与するシステムにおいて、車両の稼働率を向上させる。

本開示の第一の態様に係る情報処理装置は、
第一ユーザに対する車両の貸与計画を生成することと、前記車両の需要に関する需要データを取得することと、前記需要データに基づいて、前記貸与計画に含まれる、前記第一ユーザが前記車両を返却する地点である車両返却地点を変更することと、を実行する制御部を有することを特徴とする。

また、本開示の第二の態様に係る情報処理方法は、
第一ユーザに対する車両貸与計画を生成するステップと、前記車両の需要に関する需要データを取得するステップと、前記需要データに基づいて、前記貸与計画に含まれる、前記第一ユーザが前記車両を返却する地点である車両返却地点を変更するステップと、を含むことを特徴とする。

また、他の態様として、上記の情報処理方法をコンピュータに実行させるためのプログラム、または、該プログラムを非一時的に記憶したコンピュータ可読記憶媒体が挙げられる。

本発明によれば、ユーザに車両を貸与するシステムにおいて、車両の稼働率を向上させることができる。

車両貸与計画の変更を説明する図。 システムに含まれる構成要素の一例を概略的に示したブロック図。 予約管理データおよび車両管理データの例を示した図。 需要データの例を示した図。 運行データの例を示した図。 システムに含まれる構成要素間で送受信されるデータのフローを示した図。 サーバ装置が行う予約処理のフローチャート。 サーバ装置が行う調整処理のフローチャート。 第一ユーザと第二ユーザとのマッチングを行う処理のフローチャート。 車両１０の運行経路の具体例を示す図。

本開示の一態様に係る情報処理装置は、シェアリング車両の貸し出しを管理する装置である。

具体的には、第一ユーザに対する車両の貸与計画を生成することと、前記車両の需要に関する需要データを取得することと、前記需要データに基づいて、前記貸与計画に含まれる、前記第一ユーザが前記車両を返却する地点である車両返却地点を変更することと、を実行する制御部を有する。

貸与計画は、車両をユーザに貸し出す際の計画である。貸与計画は、例えば、車両の貸し出し日時、返却日時、車両の貸し出し地点（ステーション）、返却地点などを含みうる。
制御部は、第一ユーザに対する車両の貸与計画を生成したのち、需要データに基づいて、第一ユーザが車両を返却する地点を変更すべきであるか否かを判定する。

例えば、第一ユーザと直接の関連が無い地点において、車両に対する需要が発生しており、かつ、当該需要に応えるための車両が用意できないケースがある。このようなケースにおいて、制御部は、車両の利用を希望する第二ユーザに車両を貸与するため、第一ユーザに、当初の予定とは異なる地点で車両を返却させる旨を判定し、当該車両の貸与計画を修正する。
かかる形態によると、シェアリングシステムの最適化（例えば、利益の向上、コストの削減など）を実現させることができる。
なお、需要データは、第一ユーザ以外の他のユーザについての、当該車両に対する需要を示すデータであれば、どのような形式であってもよい。例えば、統計的なデータであってもよいし、特定のユーザから送信されたリクエストの集合であってもよい。

また、前記制御部は、前記需要データに基づいて、前記第一ユーザが前記車両を返却した後に当該車両の貸与を受ける第二ユーザの乗車地点を決定し、前記車両返却地点を、前記第二ユーザの乗車地点に変更することを特徴としてもよい。

第一ユーザが車両を返却する地点を、第二ユーザが当該車両に乗車する地点に設定することで、第一ユーザから第二ユーザに車両を受け渡すことが可能になる。なお、車両の受け渡しを行う地点は無人の拠点（ステーション等）であってもよいし、有人の拠点（営業所等）であってもよい。

また、前記制御部は、前記車両返却地点を変更する場合に、前記第一ユーザに付与するインセンティブを示す還元データを生成することを特徴としてもよい。

第一ユーザに対してインセンティブを付与することで、車両返却地点を変更させる動機を第一ユーザに与えることができる。インセンティブは、例えば、当該車両の貸与に対する割引額を含んでもよい。

また、前記インセンティブは、前記第一ユーザの送還に必要な交通費を含んでもよい。
例えば、当初予定していた帰着地点まで戻るための交通費を、第一ユーザに対するインセンティブの一部とすることができる。なお、交通費は、人や荷物を移動させるための費用であり、必ずしも公共交通機関の運賃である必要はない。例えば、荷物の配送料や、他のシェアリング車両の利用料等であってもよい。また、第一ユーザの送還先は、必ずしも当初予定していた帰着地点でなくてもよい。

また、前記制御部は、前記第一ユーザが前記車両に積載する荷物の個数に基づいて、前記交通費を設定することを特徴としてもよい。
車両に積載している荷物がある場合、経路途中における降車が困難な場合がある。これに対応するため、車両に積載する荷物の量ないし個数に基づいて、荷物が無い場合と比較して交通費を増額するようにしてもよい。

また、前記制御部は、前記インセンティブと、前記車両を前記第二ユーザに貸与することにより増加する利益と、を比較した結果に基づいて、前記車両返却地点の変更是非を判断することを特徴としてもよい。
例えば、第一ユーザに支払うインセンティブよりも、第二ユーザに車両を貸与することで増える利益のほうが大きい場合、車両返却地点の変更を行うことが好ましい。

また、前記制御部は、前記車両の予測される経路から、前記第二ユーザの乗車地点までの距離に基づいて、前記第一ユーザと前記第二ユーザの組み合わせを決定することを特徴としてもよい。
車両の予測経路と、第二ユーザの乗車地点がより近いほど、より低いコストで第二ユーザに車両を届けることができるためである。

また、前記制御部は、前記車両返却地点を変更すると決定した場合に、前記第一ユーザが乗り継ぐ第二の車両を予約することを特徴としてもよい。

第二の車両を予約することで、第一ユーザが引き続き車両で移動できるようになる。第二の車両は、第二ユーザの乗車地点またはその近傍にある車両であってもよい。また、第二の車両が自律運転車両である場合、当該第二の車両を第二の出発地点に向かわせてもよい。

また、前記制御部は、前記第二ユーザの乗車地点に、前記第二ユーザの需要に応えられず、かつ、前記第一ユーザが乗り継ぎ可能な第二の車両がある場合に、前記車両返却地点を変更するとともに、前記第二の車両を前記第一ユーザのために予約することを特徴としてもよい。
例えば、第二の出発地点に、第一ユーザは乗車できるが、（定員や積載量などの制約により）第二ユーザの需要には応えることができない車両がある場合、当該車両を第一ユーザに利用させるようにしてもよい。

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

（第一の実施形態）
第一の実施形態に係るカーシェアリングシステムの概要について、図１および図２を参照しながら説明する。本実施形態に係るカーシェアリングシステムは、複数の拠点（ステーション）において車両の貸与が可能なシステムである。
システムは、車両１０の貸与を管理するサーバ装置１００と、車両１０に搭載された車載装置２００と、ユーザが所持するユーザ端末３００と、を含んで構成される。

本実施形態に係るシステムでは、ユーザ端末３００がサーバ装置１００にアクセスし、車両１０の予約を行う。車両１０は、いずれかの拠点に属しており、車載装置２００がユーザ端末３００を認証することで乗車が可能になる。

図１の例では、第一ユーザが、拠点Ａに属する車両１０を借り受け、所定の返却日時までに拠点Ａに車両を返却する旨の予約がなされたものとする。
ここで、拠点Ｂにおいて、第二ユーザによる新たな需要が発生したものとする。
このケースにおいて、拠点Ｂに、第二ユーザの需要に対応できる車両が存在しない場合、原則として第二ユーザのリクエストを断らなければならない。しかし、第一ユーザが拠点Ｂにおいて車両を返却することを許容する場合、拠点Ｂにおいて、第一ユーザから第二ユーザへの車両１０の引き渡しが可能になる。

本実施形態に係るサーバ装置１００は、このように、車両１０の貸与を受けている第一ユーザと、当該車両１０の貸与を希望する第二ユーザとをマッチングし、利益を最大化すべく、車両の貸与計画を変更する。さらに、貸与計画の変更（すなわち、経路途中での車両の返却）に同意したユーザについて、相応のインセンティブを付与する。

システムの構成要素について、詳しく説明する。
図２は、図１に示したサーバ装置１００、車載装置２００、およびユーザ端末３００の構成の一例を概略的に示したブロック図である。

サーバ装置１００は、複数の車両１０を管理する情報処理装置である。サーバ装置１００は、ユーザ端末３００からの求めに応じて車両１０の予約を受け付ける。また、対応する車両１０に搭載された車載装置２００に対して、予約を行ったユーザに関する情報を送信する。これにより、車載装置２００がユーザ端末３００を認証できるようになる。

サーバ装置１００は、汎用のコンピュータにより構成することができる。すなわち、サーバ装置１００は、ＣＰＵやＧＰＵ等のプロセッサ、ＲＡＭやＲＯＭ等の主記憶装置、ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコンピュータとして構成することができる。なお、リムーバブルメディアは、例えば、ＵＳＢメモリ、あるいは、ＣＤやＤＶＤのようなディスク記録媒体であってもよい。補助記憶装置には、オペレーティングシステム（ＯＳ）、各種プログラム、各種テーブル等が格納され、そこに格納されたプログラムを実行することによって、後述するような、所定の目的に合致した各機能を実現することができる。ただし、一部または全部の機能はＡＳＩＣやＦＰＧＡのようなハードウェア回路によって実現されてもよい。

サーバ装置１００は、通信部１０１、制御部１０２、および記憶部１０３を有して構成される。
通信部１０１は、サーバ装置１００をネットワークに接続するための通信手段である。本実施形態では、通信部１０１は、４ＧやＬＴＥ等の移動体通信サービスを利用して、ネットワーク経由で車載装置２００およびユーザ端末３００と通信を行うことができる。

制御部１０２は、サーバ装置１００の制御を司る手段である。制御部１０２は、例えば、ＣＰＵによって構成される。
制御部１０２は、機能モジュールとして、予約管理部１０２１、調整部１０２２、および還元部１０２３を有している。各機能モジュールは、ＲＯＭ等の記憶手段に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

予約管理部１０２１は、システムの管理下にある複数の車両１０の予約を管理する。具体的には、ユーザ端末３００から新規の予約リクエストを受け付けた場合に、後述する予
約管理データおよび車両管理データを参照し、指定された条件において車両の貸与が可能であるか否かを判定する。車両の貸与が可能な場合、予約を成立しさせ、その旨をユーザ端末３００に通知するとともに、予約された車両１０に搭載された車載装置２００に対して、予約の内容を示すデータを送信する。

調整部１０２２は、あるユーザが所持するユーザ端末３００から、直ちに応えられない予約リクエストを受信した場合に、他のユーザに係る予約の内容を調整することで車両を確保する。具体的な方法については後述する。
還元部１０２３は、予約の調整に協力したユーザに対してインセンティブを付与する。金額の算出方法等については後述する。

記憶部１０３は、情報を記憶する手段であり、ＲＡＭ、磁気ディスクやフラッシュメモリなどの記憶媒体により構成される。記憶部１０３には、制御部１０２にて実行される各種プログラム、データ等が記憶される。

また、記憶部１０３には、以下のデータが記憶される。
（１）複数の予約を管理するためのデータ（予約管理データ）
（２）複数の車両を管理するためのデータ（車両管理データ）
（３）リクエスト段階の予約を管理するためのデータ（需要データ）
（４）貸し出し中の車両の運行経路に関するデータ（運行データ）

予約管理データは、確定した予約を管理するデータである。図３（Ａ）は、予約管理データの例である。予約管理データには、車両の貸し出し日時、返却日時、ユーザの識別子、出発地点（車両の貸与を受ける地点）、帰着地点（車両を返却する地点）、車両の識別子、予約の識別子などが記録される。予約管理データは、予約リクエストに基づいて生成される。

車両管理データは、複数の車両１０を管理するデータである。図３（Ｂ）は、車両管理データの例である。車両管理データには、車両の識別子、状態、現在位置、車両の詳細情報などが記録される。車両管理データは、車載装置２００から収集した情報に基づいて適宜アップデートされる。

需要データは、ユーザによる車両に対する需要を記録するデータである。本実施形態では、需要データは、リクエスト段階の予約を管理するデータである。すなわち、予約リクエストに応えることができる車両が無い場合に生成される。
図４は、需要データの例である。需要データには、車両の希望貸し出し日時、希望返却日時、ユーザの識別子、希望出発地点、希望帰着地点、希望車種などが記録される。

運行データは、貸出中の車両の運行経路に関するデータである。図５は、運行データの例である。運行データには、例えば、予約の識別子、車両１０の運行経路ないし目的地、運行を予定しているエリアなどが記録される。なお、運行データには、車両の運行経路に関連しないデータ（例えば、乗員の人数、荷物の個数または数量など）が含まれていてもよい。運行データは、車両１０が出発する際に、車載装置２００によって生成される。

次に、車載装置２００について説明する。
車載装置２００は、ユーザ端末３００と近距離無線通信を行って当該ユーザ端末３００を認証する機能と、ユーザ端末３００を認証した結果に基づいて、電子ロックの施解錠を行う機能を有している。車載装置２００は、通信部２０１、制御部２０２、記憶部２０３、および近距離通信部２０４を有して構成される。

通信部２０１は、通信部１０１と同一の通信規格によって、サーバ装置１００との間で通信を行う手段である。

制御部２０２は、ユーザ端末３００と近距離無線通信を行い、ユーザ端末３００を認証する制御と、認証結果に基づいて電子ロックの施解錠を行う制御を行うモジュールである。制御部２０２は、例えば、マイクロコンピュータによって構成される。

制御部２０２は、機能モジュールとして認証部２０２１および鍵制御部２０２２を有している。各機能モジュールは、記憶手段（ＲＯＭ等）に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

認証部２０２１は、サーバ装置１００から送信された情報と、ユーザ端末３００から送信された情報に基づいて、ユーザ端末３００の認証を行う。
具体的には、認証部２０２１は、車両を予約しているユーザを認証するためのデータをサーバ装置１００から事前に取得する。また、近距離通信部２０４を介してユーザ端末３００からユーザ情報を取得し、これらが整合した場合に、認証成功と判断する。双方が整合しない場合、認証失敗と判断する。認証部２０２１がユーザ端末３００の認証に成功した場合、施解錠を行うための指令が、後述する鍵制御部２０２２へ送信される。
鍵制御部２０２２は、認証部２０２１から送信された指令に基づいて、車両の電子ロックを制御する。

記憶部２０３は、情報を記憶する手段であり、ＲＡＭ、磁気ディスクやフラッシュメモリなどの記憶媒体により構成される。記憶部２０３には、ユーザ端末３００から送信された電子鍵と照合するための認証情報、制御部２０２にて実行される各種プログラム、またはデータ等が記憶される。

近距離通信部２０４は、車載装置２００との間で近距離無線通信を行うためのインタフェースである。近距離通信部２０４は、所定の無線通信規格を用いて、近距離（数ｃｍ程度）における通信を行う。
本実施形態では、近距離通信部２０４は、ＮＦＣ規格（Near Field Communication）によるデータ通信を行う。なお、本実施形態ではＮＦＣを例示するが、他の無線通信規格も利用可能である。例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＵＷＢ（Ultra Wideband）、Ｗｉ−Ｆｉ（登録商標）などを利用することもできる。

なお、車載装置２００は、例示した機能以外を有していてもよい。車載装置２００は、例えば、ナビゲーションを行う機能、または、車両の予約に関連する機能（例えば、返却期限の通知や延長手続きを行う機能など）を実行可能に構成されていてもよい。

次に、ユーザ端末３００について説明する。
ユーザ端末３００は、例えばスマートフォン、携帯電話、タブレット端末、個人情報端末、ウェアラブルコンピュータ（スマートウォッチ等）といった小型のコンピュータである。ユーザ端末３００は、通信部３０１、制御部３０２、記憶部３０３、近距離通信部３０４、および入出力部３０５を有して構成される。

通信部３０１は、通信部２０１と同様に、ネットワーク経由でサーバ装置１００と通信を行うための通信インタフェースである。

制御部３０２は、ユーザ端末３００の制御を司る手段である。制御部３０２は、例えば、マイクロコンピュータによって構成される。制御部３０２は、後述する記憶部３０３に記憶されたプログラムをＣＰＵによって実行することでこれらの機能を実現してもよい。

制御部３０２は、機能モジュールとして予約部３０２１および認証要求部３０２２を有している。各機能モジュールは、記憶手段（ＲＯＭ等）に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

予約部３０２１は、ユーザから取得した情報に基づいてサーバ装置１００にアクセスし、車両１０の予約を行う。具体的には、後述する入出力部３０５を介して、車両の希望貸し出し日時、希望返却日時、ユーザの識別子、希望出発地点、希望帰着地点、希望車種などを取得し、予約リクエストを生成して、サーバ装置１００に送信する。

認証要求部３０２２は、ユーザが行った操作に基づいて、車両１０の施錠または解錠を行うための要求を生成し、近距離無線通信によって車載装置２００に送信する。例えば、認証要求部３０２２は、後述する入出力部３０５（タッチパネルディスプレイ等）に、施解錠を行うためのインタフェース画面を出力し、ユーザによって行われた操作に基づいて、施錠または解錠を要求するデータ（施解錠要求）を生成し、車載装置２００に送信する。施解錠要求には、ユーザ情報が含まれる。

記憶部３０３は、情報を記憶する手段であり、ＲＡＭ、磁気ディスクやフラッシュメモリなどの記憶媒体により構成される。記憶部３０３には、制御部３０２にて実行される各種プログラム、データ等が記憶される。
近距離通信部３０４は、近距離通信部２０４と同一の通信規格によって、ユーザ端末３００との間で通信を行う手段である。

入出力部３０５は、ユーザが行った入力操作を受け付け、ユーザに対して情報を提示する手段である。具体的には、タッチパネルとその制御手段、液晶ディスプレイとその制御手段から構成される。タッチパネルおよび液晶ディスプレイは、本実施形態では一つのタッチパネルディスプレイからなる。

次に、システムに含まれる各構成要素が送受信するデータについて、図６を参照して説明する。

車両１０の利用を希望するユーザが、ユーザ端末３００を介して予約操作を行うと、ユーザ端末３００（予約部３０２１）が予約リクエストを生成し、サーバ装置１００に送信する（ステップＳ１１）。

予約リクエストを受信したサーバ装置１００（予約管理部１０２１）は、車両１０を予約する処理を行い、その結果をユーザ端末３００に返す（ステップＳ１２）。
車両１０が予約できた場合、予約管理部１０２１は受諾応答を返す。
車両１０が予約できなかった場合（すなわち、車両１０の空きがなかった場合）、予約管理部１０２１は、予約ができない旨の通知を返し、リクエストを保留するか否かを確認する。ユーザがリクエストを保留した場合、システムが予約リクエストを預かり、予約内容の調整を試みる（後述）。預かり中の予約リクエストは、需要データに反映される。なお、需要データには、預かり期限が関連付いていてもよい。この場合、期限を過ぎた予約リクエストを削除するようにしてもよい。

ユーザが、予約した車両１０に乗車すると、車載装置２００が、運行データをサーバ装置１００に送信する（ステップＳ１３）。
運行データは、車両１０の運行経路に関するデータであって、典型的には、車両１０の予定経路、経由地、目的地、走行するエリアなどを含む。例えば、車載装置２００がナビゲーション機能を有している場合、車載装置２００から、運行経路または目的地に関する
情報を取得し、運行データとすることができる。
本実施形態では、サーバ装置１００が運行データを参照することで、既に出発した車両１０について予約内容の調整を行う。例えば、「第二ユーザに車両１０を利用させるため、経路途中の地点において第一ユーザに車両１０を返却させる」といった判断を行う。

なお、運行データは、運行経路に関するもの以外の情報を含んでいてもよい。例えば、車両１０に乗車している人の数、積載されている荷物の数や量などを含んでもよい。このような情報は、車両１０に備えられたセンサから取得したデータに基づいて生成してもよいし、車載装置２００を介してユーザに入力させてもよい。

サーバ装置１００は、予約管理データ、運行データ、および需要データに基づいて、予約内容の調整を周期的に行う（ステップＳ１４）。
本ステップでは、第一ユーザに既に貸与されている車両１０について、途中で第二ユーザに貸し渡すことが妥当であるか否かを判定し、妥当である場合に、第一ユーザの同意を得て車両返却地点の変更を行う。さらに、第一ユーザに対するインセンティブを生成する。ステップＳ１４で行う処理については後述する。

次に、ユーザが車両の予約を行う際の処理（ステップＳ１２）について、より詳細に説明する。図７は、サーバ装置１００（予約管理部１０２１）が行う処理のフローチャートである。

まず、ステップＳ２１で、ユーザ端末３００から予約リクエストを取得する。予約リクエストには、例えば、車両の希望貸し出し日時、希望返却日時、ユーザの識別子、希望出発地点、希望帰着地点、希望車種などが含まれる。
次に、ステップＳ２２で、車両の割り当てを行う。具体的には、車両管理データおよび予約管理データを参照し、ユーザの希望に合致する車両の確保を試みる。
ステップＳ２３では、車両の割り当てが成功したか否かを判定する。ここで、車両の割り当てが成功した場合、処理はステップＳ２４に遷移し、予約管理データに新規のレコードを追加する。また、予約が完了した旨をユーザ端末３００に通知する。
車両の割り当てが行えなかった場合、処理はステップＳ２５に遷移し、需要データに新規のレコードを追加する。なお、本ステップは、ユーザの意向を確認したうえで実行してもよい。

次に、サーバ装置１００が予約内容の調整を行う処理（ステップＳ１４）について、より詳細に説明する。図８は、サーバ装置１００（調整部１０２２）が行う処理のフローチャートである。

まず、ステップＳ３１で、最新の需要データを取得する。これにより、預かり中の予約リクエストが取得される。

次に、ステップＳ３２で、第一ユーザ（すなわち、車両１０の貸与を受けているユーザ）と第二ユーザ（すなわち、車両１０の予約が保留されているユーザ）とのマッチングを行う。具体的には、既に貸出中の車両１０について、以下の処理を行う。
（１）第一ユーザに既に貸出中の車両１０の帰着地点を変更することで、需要データに含まれる第二ユーザの予約リクエストに応えることができるかを判定する。
（２）帰着地点を変更させるために、第一ユーザに与えるインセンティブを算出する。
（３）帰着地点を変更した場合における収益の変化を算出する。
そして、これらを総合し、第一ユーザと第二ユーザをマッチングするか（すなわち、第一ユーザに貸与中である車両１０の帰着地点を変更するか）否かを決定する。

図９は、ステップＳ３２で実行される処理をより詳細に示したフローチャートである。
まず、ステップＳ３２１で、第一ユーザと第二ユーザとの組を生成する。具体的には、第二ユーザに対応する一つ以上の予約リクエストと、第一ユーザによって現在運行中である車両１０に対応する一つ以上の運行データを突き合わせ、第二ユーザの需要を満たせる可能性がある第一ユーザが存在するか否かを判定する。

図１０は、第一ユーザが予定している車両の運行経路を示した図である。本例では、地点Ａにおいて車両の貸し出しを受けた第一ユーザが、地点Ｂ、地点Ｃ、および地点Ｄを経由して、地点Ａに戻る旨が示されている。
ここで、第二ユーザが、地点Ｅを希望出発地点とする予約リクエストを入れていたとする。この場合、地点Ｅの近傍を通過する第一ユーザに地点Ｅへ向かってもらい、地点Ｅで車両１０を返却させることで、第二ユーザへの車両の貸与が可能になる。ステップＳ３２１では、このようなユーザの組を生成する。
ステップＳ３２１では、例えば、予約管理データ、需要データ、および、運行データに基づいて、以下の条件を満たす第一ユーザと第二ユーザの組み合わせを抽出する。
（１）第一ユーザが乗車した車両１０が、第二ユーザの出発希望地点の近傍を通過する（例えば、車両１０の経路と、第二ユーザの出発希望地点との距離が所定の値以下である）（２）当該通過の時刻が、第二ユーザの出発希望時刻の前後である

ステップＳ３２２〜Ｓ３２５の処理は、生成されたユーザの組み合わせごとに実行される。
ステップＳ３２２では、第一ユーザの、拠点間の移動にかかるコストを算出する。具体的には、第二のユーザに車両１０を引き渡す地点から、本来の帰着地点までの移動にかかる費用を算出する。移動にかかる費用は、例えば、公共交通機関の運賃であってもよいし、他のモビリティサービスの利用料金であってもよい。サーバ装置１００は、これらのコストを算出するためのデータを記憶または取得可能に構成されていてもよい。また、移動にかかる費用は、車両１０に乗車している人の数に基づいて決定してもよい。

ステップＳ３２３では、第一ユーザに与えるインセンティブを決定する。インセンティブは、例えば、車両１０の貸与料金に対する割引額であってもよいし、他のサービスで利用できるポイント等であってもよい。インセンティブの額は、第一ユーザにかかる不利益に応じた額とすることが好ましい。例えば、返却予定時刻までの残り時間が長いほどインセンティブを多くしてもよいし、第二のユーザに車両１０を引き渡す地点から、本来の帰着地点までの距離が長いほどインセンティブを多くしてもよい。
本実施形態では、ステップＳ３２２で算出したコストに、一定の額を上乗せしたものを、第一ユーザに付与するインセンティブとするが、インセンティブの算出は、ステップＳ３２２で算出したコストに基づくものであれば、どのような方法によってなされてもよい。

ステップＳ３２４では、第一ユーザに車両１０の貸与を続けた場合、すなわち、第二ユーザに対して車両１０の貸与を行わなかった場合における収益（第一の収益）を算出する。
ステップＳ３２５では、第一ユーザに車両１０を返却させ、第一ユーザにインセンティブを付与し、かつ、第二ユーザに車両１０を貸与した場合における収益（第二の収益）を算出する。
ここで、第二の収益が、第一の収益を上回っていた場合、第一ユーザから第二ユーザへ車両１０を引き渡したほうが全体の利益が向上することがわかる。

図８に戻り、説明を続ける。
ステップＳ３３では、ステップＳ３２で算出した結果に基づいて、車両返却地点の変更
を第一ユーザに打診するか否かを決定する。例えば、第二の収益＞第一の収益となるユーザの組み合わせが存在する場合、該当する第一ユーザに対して車両返却地点の変更を打診する旨を決定する。ユーザの組み合わせが存在しなかった場合、処理はステップＳ３１に戻る。

ステップＳ３３で肯定判定となった場合、処理はステップＳ３４へ遷移し、第一ユーザに対して、車両返却地点の変更を打診する。具体的には、第一ユーザが所持するユーザ端末３００に対して、変更後の車両返却地点、返却時刻、インセンティブの内容等を送信し、第一ユーザから承諾を得る。
ここで、承諾が得られた場合（ステップＳ３５−Ｙｅｓ）、処理はステップＳ３６へ遷移する。承諾が得られなかった場合（ステップＳ３５−Ｎｏ）、処理はステップＳ３１に戻る。

ステップＳ３６では、第二ユーザの予約を成立させるため、以下の処理を実行する。
（１）第一ユーザに対応する予約管理データについて、帰着地点および返却日時を変更する。
（２）第二ユーザに対応する需要データのレコードを削除し、予約管理データのレコードを新規作成する。
（３）第二ユーザが所持するユーザ端末３００に対して、予約が成立した旨（第二ユーザが希望した拠点に車両１０が返却される旨）を通知する。
これにより、第二ユーザに対する車両１０の予約が成立する。

ステップＳ３７では、第一ユーザに付与するインセンティブを表す還元データを生成する。還元データは一時的に記憶され、所定のタイミングで、ポイントや電子マネーを管理する外部サービスへ送信される。

なお、ステップＳ３２の処理において、ある第一ユーザに対して、第二ユーザの候補が複数ある場合、所定の基準によって第二ユーザを選択してもよい。例えば、全体の利益が最も高くなる第二ユーザを選択するようにしてもよい。
また、第一ユーザと第二ユーザの組が複数ある場合、それぞれについて、ステップＳ３３〜Ｓ３７の処理を実行してもよい。

以上に説明したように、第一の実施形態によると、第一ユーザに貸与した車両の帰着地点を変更することで、第二ユーザの需要に応えることが可能になり、サービス事業者の利益を向上させることが可能になる。さらに、第一ユーザに対してインセンティブを付与することで、第一ユーザの協力を積極的に引き出すことができる。

（第二の実施形態）
第一の実施形態では、拠点間の移動コストに基づいて、第一ユーザに付与するインセンティブを算出した。第二の実施形態では、これに加え、車両１０に積載されている荷物の量にさらに基づいて、第一ユーザに付与するインセンティブを決定する実施形態である。

第二の実施形態では、運行データに、車両１０に積載されている荷物の量や個数に関する情報を含ませる。当該情報は、車両１０に設けられたセンサによって取得されてもよいし、車両１０の貸し渡しが有人によって行われる場合、係員が入力してもよい。

また、第二の実施形態では、荷物の量ないし個数に関する情報にさらに基づいて、第一ユーザに付与するインセンティブの額を決定する。例えば、ステップＳ３２２において、拠点間で荷物を送るための輸送サービスの利用料金を算出し、当該料金を含んだインセンティブの額を決定してもよい。あるいは、荷物の量ないし個数が増えるほど、インセンテ
ィブの額そのものを増やすようにしてもよい。

（第三の実施形態）
第三の実施形態は、第一ユーザに貸与した車両１０の帰着地点を変更する場合において、当該第一ユーザに乗り継がせる他の車両を予約する実施形態である。
第二ユーザによる予約が成立しない原因として、車両のカテゴリ（サイズ、車種、キャパシティなど）がある。例えば、第二ユーザが、６人で乗車できる車両を希望したにもかかわらず、５人乗りの車両しか拠点に存在しないような場合である。
このような場合、変更後の車両返却地点において、第一ユーザが乗り継げる別の車両が存在する可能性がある。

第三の実施形態では、ステップＳ３６において、変更後の車両返却地点において他の車両（以下、車両１０Ｂ）が利用可能であるか否かを判定する。そして、車両１０Ｂが利用可能であって、第一ユーザが乗車可能な場合に、当該車両１０Ｂを、第一ユーザのために自動的に予約する。第一ユーザが乗車可能な場合とは、例えば、車両１０に乗車中のすべての人員が車両１０Ｂに乗車できる場合、または、車両１０に搭載しているすべての荷物が車両１０Ｂに搭載できる場合などである。
第三の実施形態によると、第一ユーザは、変更後の車両返却地点において、車両１０から車両１０Ｂへ乗り継ぐことができる。すなわち、公共交通機関による移動コストを抑えることができる。

（変形例）
上記の実施形態はあくまでも一例であって、本発明はその要旨を逸脱しない範囲内で適宜変更して実施しうる。
例えば、本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

また、実施形態の説明では、保留された予約リクエストを需要データとしたが、他の方法によって車両に対する需要を取得してもよい。例えば、他の配車サービス等を提供する装置から、車両に対する需要を表すデータをネットワーク経由で取得してもよい。
さらに、車両に対する需要は、特定のユーザに関連付いたものでなくてもよい。例えば、ある拠点において、車両１０に対する貸し出し需要が高まっていると判断した場合、第二ユーザを特定しない状態で、図８および図９に示した処理を実行するようにしてもよい。この場合、収益の変化は推定によって算出してもよい。

また、実施形態の説明では、運行データ（すなわち、車両１０の運行経路に関するデータ）に基づいて第一ユーザと第二ユーザとのマッチングを行ったが、運行データは必ずしも生成されなくてもよい。例えば、車両１０に搭載された車載装置２００から位置情報を周期的に収集し、当該収集した位置情報、または、当該位置情報に基づいて推定された車両１０の走行経路に基づいて、第一ユーザと第二ユーザとをマッチングしてもよい。
また、実施形態の説明では、第一ユーザが出発した後で予約内容の調整を行ったが、第一ユーザが車両１０の貸与を受ける前に予約内容の調整を行うようにしてもよい。例えば、第一ユーザが車両１０を予約した後で、車両返却地点の候補とインセンティブの組み合わせを第一ユーザに提示し、車両返却地点の変更を提案してもよい。

また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。

本開示は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤディスク・ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。

１００・・・サーバ装置
１０１，２０１，３０１・・・通信部
１０２，２０２，３０２・・・制御部
１０３，２０３，３０３・・・記憶部
２００・・・携帯端末
２０４，３０４・・・近距離通信部
３００・・・車載装置
３０５・・・入出力部

Claims (20)

1. 第一ユーザに対する車両の貸与計画を生成することと、
   前記車両の需要に関する需要データを取得することと、
   前記需要データに基づいて、前記貸与計画に含まれる、前記第一ユーザが前記車両を返却する地点である車両返却地点を変更することと、
   を実行する制御部を有する、情報処理装置。
2. 前記制御部は、
   前記需要データに基づいて、前記第一ユーザが前記車両を返却した後に当該車両の貸与を受ける第二ユーザの乗車地点を決定し、
   前記車両返却地点を、前記第二ユーザの乗車地点に変更する、
   請求項１に記載の情報処理装置。
3. 前記制御部は、
   前記車両返却地点を変更する場合に、前記第一ユーザに付与するインセンティブを示す還元データを生成する、
   請求項２に記載の情報処理装置。
4. 前記インセンティブは、前記車両の貸与に対する割引額を含む、
   請求項３に記載の情報処理装置。
5. 前記インセンティブは、前記第一ユーザの送還に必要な交通費を含む、
   請求項３または４に記載の情報処理装置。
6. 前記制御部は、前記第一ユーザが前記車両に積載する荷物の個数に基づいて、前記交通費を設定する、
   請求項５に記載の情報処理装置。
7. 前記制御部は、前記インセンティブと、前記車両を前記第二ユーザに貸与することにより増加する利益と、を比較した結果に基づいて、前記車両返却地点の変更是非を判断する、
   請求項３から６のいずれか１項に記載の情報処理装置。
8. 前記制御部は、前記車両の予測される経路から、前記第二ユーザの乗車地点までの距離に基づいて、前記第一ユーザと前記第二ユーザの組み合わせを決定する、
   請求項２から７のいずれか１項に記載の情報処理装置。
9. 前記制御部は、前記車両返却地点を変更すると決定した場合に、前記第一ユーザが乗り継ぐ第二の車両を予約する、
   請求項２から８のいずれか１項に記載の情報処理装置。
10. 前記制御部は、前記第二ユーザの乗車地点に、前記第二ユーザの需要に応えられず、かつ、前記第一ユーザが乗り継ぎ可能な第二の車両がある場合に、前記車両返却地点を変更するとともに、前記第二の車両を前記第一ユーザのために予約する、
    請求項２から８のいずれか１項に記載の情報処理装置。
11. 第一ユーザに対する車両の貸与計画を生成するステップと、
    前記車両の需要に関する需要データを取得するステップと、
    前記需要データに基づいて、前記貸与計画に含まれる、前記第一ユーザが前記車両を返
    却する地点である車両返却地点を変更するステップと、
    を含む、情報処理方法。
12. 前記需要データに基づいて、前記第一ユーザが前記車両を返却した後に当該車両の貸与を受ける第二ユーザの乗車地点を決定し、
    前記車両返却地点を、前記第二ユーザの乗車地点に変更する、
    請求項１１に記載の情報処理方法。
13. 前記車両返却地点を変更する場合に、前記第一ユーザに付与するインセンティブを示す還元データを生成する、
    請求項１２に記載の情報処理方法。
14. 前記インセンティブは、前記車両の貸与に対する割引額を含む、
    請求項１３に記載の情報処理方法。
15. 前記インセンティブは、前記第一ユーザの送還に必要な交通費を含む、
    請求項１３または１４に記載の情報処理方法。
16. 前記第一ユーザが前記車両に積載する荷物の個数に基づいて、前記交通費を設定する、
    請求項１５に記載の情報処理方法。
17. 前記インセンティブと、前記車両を前記第二ユーザに貸与することにより増加する利益と、を比較した結果に基づいて、前記車両返却地点の変更是非を判断する、
    請求項１３から１６のいずれか１項に記載の情報処理方法。
18. 前記車両の予測される経路から、前記第二ユーザの乗車地点までの距離に基づいて、前記第一ユーザと前記第二ユーザの組み合わせを決定する、
    請求項１２から１７のいずれか１項に記載の情報処理方法。
19. 前記車両返却地点を変更すると決定した場合に、前記第一ユーザが乗り継ぐ第二の車両を予約する、
    請求項１２から１８のいずれか１項に記載の情報処理方法。
20. 請求項１１から１９のいずれか１項に記載の情報処理方法をコンピュータに実行させるためのプログラム。

Images