JP2020030590A - 情報処理装置、情報処理方法、及び情報処理プログラム - Google Patents

Abstract

【課題】移動を目的とする複数のユーザが同一の車両に相乗りする形態において、相乗りに利用される車両が不足することを抑制可能な技術を提供する。【解決手段】本発明の情報処理装置は、相乗り車両の台数が所定の下限値を下回るときに、自身の運転する車両に同乗希望ユーザを同乗させることが可能なユーザの候補である運転ユーザ候補を抽出する。そして、本発明の情報処理装置は、抽出された運転ユーザ候補の使用する端末に対して、該運転ユーザ候補の運転する車両に同乗希望ユーザを同乗させることについて承諾を求める情報、すなわち、該運転ユーザ候補が所有又は所有権を有する車両を相乗り車両として提供することについて承諾を求める情報を送信することで、相乗り車両の台数増加を促進させる。【選択図】図１１

Description

本発明は、情報処理装置、情報処理方法、及び情報処理プログラムに関する。

各端末の位置情報に基づいて、それらの端末の所有者が同一の車両に相乗り中であるか否かを判断し、その判定結果に基づいてＣＯ_２排出量や燃料の消費量といった環境負荷を算出する技術が知られている（例えば、特許文献１を参照）。

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

本発明は、移動を目的とする複数のユーザが同一の車両に相乗りする形態において、相乗りに利用される車両が不足することを抑制可能な技術を提供することを目的とする。

本発明は、複数のユーザが同一の車両に相乗りする形態において、相乗りに利用可能な車両に非運転者として同乗することを希望するユーザである同乗希望ユーザの人数と、相乗りに利用される車両の台数と、の調整を図る情報処理装置である。該情報処理装置は、相乗りに利用される車両の台数が所定の下限値を下回るときに、自身の運転する車両に前記同乗希望ユーザを同乗させることが可能なユーザの候補である運転ユーザ候補を抽出することと、前記運転ユーザ候補の運転する車両に前記同乗希望ユーザを相乗りさせることについて承諾を求める情報である第１情報を送信することと、を実行する、制御部を備える。

本発明は、複数のユーザが同一の車両に相乗りする形態において、相乗りに利用可能な車両に非運転者として同乗することを希望するユーザである同乗希望ユーザの人数と、相乗りに利用される車両の台数と、の調整を図る情報処理方法として捉えることもできる。その場合、本発明に係る情報処理方法は、相乗りに利用される車両の台数が所定の下限値を下回るときに、自身の運転する車両に前記同乗希望ユーザを同乗させることが可能なユーザの候補である運転ユーザ候補を抽出するステップと、前記運転ユーザ候補の運転する車両に前記同乗希望ユーザを相乗りさせることについて承諾を求める情報である第１情報を送信するステップと、をコンピュータが実行するようにしてもよい。

本発明は、複数のユーザが同一の車両に相乗りする形態において、相乗りに利用可能な車両に非運転者として同乗することを希望するユーザである同乗希望ユーザの人数と、相乗りに利用される車両の台数と、の調整を図る情報処理プログラムとして捉えることもできる。その場合、本発明に係る情報処理プログラムは、相乗りに利用される車両の台数が所定の下限値を下回るときに、自身の運転する車両に前記同乗希望ユーザを同乗させることが可能なユーザの候補である運転ユーザ候補を抽出するステップと、前記運転ユーザ候補の運転する車両に前記同乗希望ユーザを相乗りさせることについて承諾を求める情報である第１情報を送信するステップと、をコンピュータに実行させるようにしてもよい。

本発明によれば、移動を目的とする複数のユーザが同一の車両に相乗りする形態におい
て、相乗りに利用される車両が不足することを抑制することができる。

ライドシェアの概要を説明するための図である。 ライドシェアシステムの概略構成を示す図である。 ユーザ端末及びサーバ装置のハードウェア構成を示す図である。 サーバ装置の機能構成を示すブロック図である。 走行スケジュール情報テーブルの構成例を示す図である。 移動スケジュール情報テーブルの構成例を示す図である。 予約情報テーブルの構成例を示す図である。 予約情報テーブルの他の構成例を示す図である。 会員情報テーブルの構成例を示す図である。 相乗り車両の台数が所定の下限値を下回る状態の一例を示す図である。 第１実施形態に係るサーバ装置の処理の流れを示すフローチャートである。 同乗ユーザ候補の抽出方法の一例を示す図である。 第２実施形態に係るサーバ装置の処理の流れを示すフローチャートである。

本発明は、本発明は、複数のユーザが同一の車両に相乗りする形態において、前記車両に非運転者として同乗することを希望するユーザである同乗希望ユーザの人数と、相乗りに利用される車両の台数と、の調整を図る情報処理装置である。

ここで、上記したライドシェアにおいて、同乗希望ユーザの人数が、相乗りに利用される車両（以下、「相乗り車両」と記す場合もある。）に非運転者として同乗可能なユーザの人数より多くなると、一部の同乗希望ユーザが相乗り車両に同乗することができなくなることで、該一部の同乗希望ユーザの利便性が低下したり、該一部の同乗ユーザのライドシェア利用意欲が低下したりする可能性がある。

これに対し、本発明の情報処理装置では、相乗り車両の台数が所定の下限値を下回るときに、制御部が、自身の運転する車両に同乗希望ユーザを同乗させることが可能なユーザの候補である運転ユーザ候補を抽出する。そして、前記制御部が、抽出された運転ユーザ候補の使用する端末に対して、該運転ユーザ候補の運転する車両に同乗希望ユーザを同乗させることについて承諾を求める情報（第１情報）を送信する。すなわち、前記制御部は、抽出された運転ユーザ候補に対して、該運転ユーザ候補が所有又は所有権を有する車両を相乗り車両として提供することを提案する。これにより、自身の運転する車両に同乗希望ユーザを同乗させることについて運転ユーザ候補が承諾すれば、相乗り車両の台数を増やすことができるため、相乗り車両に同乗することができない同乗希望ユーザの人数を減らすことができる。その結果、相乗り車両が不足することを抑制することが可能になる。

なお、ここでいう「所定の下限値」は、例えば、同一の時間帯における移動を希望している同乗希望ユーザであって、且つ同一の経路上に出発地及び目的地が含まれる同乗希望ユーザの全員の移動を達成するために必要となる相乗り車両の最小の台数（すなわち、各相乗り車両に定員数の同乗希望ユーザを同乗させると仮定した場合に、上記同乗希望ユーザの全員を乗せるために必要となる相乗り車両の台数）に相当する。よって、「相乗り車両の台数が所定の下限値を下回る」とは、上記時間帯に上記経路を含む走行経路を走行予定の相乗り車両の全車で同乗させることができるユーザの最大人数に対して、上記同乗希望ユーザの人数の方が多いことを意味する。

また、本発明に係る情報処理装置において、前記制御部は、前記同乗希望ユーザの中から前記運転ユーザ候補を抽出してもよい。例えば、前記制御部は、前記同乗希望ユーザのうち、自身で運転することができる車両を所有又はその車両の所有権を有している同乗希望ユーザを、運転ユーザ候補として抽出してもよい。斯様にして抽出された運転ユーザ候補が、自身の運転する車両へ同乗希望ユーザを同乗させることを承諾すれば、相乗り車両の台数を増やすことができると同時に、同乗希望ユーザの人数を減らすことができる。その結果、相乗り車両に同乗することができない同乗希望ユーザの人数を、より確実に減らすことができる。

なお、前記制御部は、前記第１情報を前記運転ユーザ候補の使用する端末へ送信する際に、該運転ユーザ候補の運転する車両に前記同乗希望ユーザを同乗させると仮定した場合に該運転ユーザ候補に供与されるインセンティブに関する情報も送信するようにしてもよい。ここでいう「インセンティブ」とは、例えば、所定のサービスに使用可能なポイント、割引券や商品券の電子データ、電子マネー等である。斯様なインセンティブに関する情報が第１情報とともに運転ユーザ候補に提供されることで、自身の運転する車両へ同乗希望ユーザを同乗させることについて運転ユーザ候補が承諾する意欲を喚起することができる。

ところで、上記したライドシェアにおいては、同乗希望ユーザの人数が、相乗り車両に非運転者として同乗可能なユーザの人数より少なくなる場合も想定し得る。その場合、自身の運転する相乗り車両に同乗希望ユーザを同乗させることを希望しているユーザ（以下、「運転希望ユーザ」と記す場合もある。）の一部が、該運転希望ユーザの運転する相乗り車両に同乗希望ユーザを同乗させることができなくなることで、運転希望ユーザの利便性が低下したり、運転希望ユーザのライドシェア利用意欲が低下したりする可能性がある。

これに対し、本発明に係る情報処理装置では、相乗り車両の台数が所定の上限値を上回るときに、前記制御部が、他のユーザが運転する車両に同乗することが可能なユーザの候補である同乗ユーザ候補を抽出し、抽出された同乗ユーザ候補の使用する端末に対して、他のユーザの運転する車両に同乗することについて承諾を求める情報である第２情報を送信するようにしてもよい。すなわち、前記制御部は、同乗ユーザ候補に対して、自身の運転する車両による移動形態から他のユーザの運転する相乗り車両へ同乗する移動形態への変更を提案する。これにより、他のユーザの運転する相乗り車両に同乗することについて同乗ユーザ候補が承諾すれば、相乗り車両の台数を減らすことができるため、自身の運転する相乗り車両に同乗希望ユーザを同乗させることができない運転希望ユーザの人数を減らすことができる。

ここでいう「所定の上限値」は、例えば、同一の時間帯における移動を希望している同乗希望ユーザであって、且つ同一の経路上に出発地及び目的地が含まれる同乗希望ユーザの全員の移動を達成するために必要となる相乗り車両の最大の台数（すなわち、各相乗り車両に最小人数（例えば、１人ずつ）の同乗希望ユーザを同乗させると仮定した場合に、上記同乗希望ユーザの全員を乗せるために必要となる相乗り車両の台数）に相当する。よって、「相乗り車両の台数が所定の上限値を上回る」とは、上記同乗希望ユーザの全員を同乗させることができる最大台数の相乗り車両の運転に必要なユーザの人数に対して、運転希望ユーザの人数の方が多いことを意味する。

また、本発明に係る情報処理装置において、前記制御部は、前記運転希望ユーザの中から前記同乗ユーザ候補を抽出してもよい。斯様にして抽出された同乗ユーザ候補が、他のユーザが運転する相乗り車両に同乗することを承諾すれば、相乗り車両の台数を減らすことができると同時に、同乗希望ユーザの人数を増やすことができる。その結果、自身の運
転する相乗り車両に同乗希望ユーザを同乗させることができない運転希望ユーザの人数を、より確実に減らすことができる。

なお、前記制御部は、前記第２情報を前記同乗ユーザ候補の使用する端末へ送信する際に、他のユーザが運転する車両に該同乗ユーザ候補が同乗すると仮定した場合に該同乗ユーザ候補に供与されるインセンティブに関する情報も送信するようにしてもよい。この場合のインセンティブは、運転ユーザ候補の運転する車両に同乗希望ユーザを同乗させると仮定した場合に該運転ユーザ候補に供与されるインセンティブと同様である。

以下、本発明の具体的な実施形態について図面に基づいて説明する。本実施例に記載されている構成部品の寸法、材質、形状、その相対配置等は、特に記載がない限りは発明の技術的範囲をそれらのみに限定する趣旨のものではない。

＜第１実施形態＞
本実施形態では、移動を目的とする複数のユーザが同一の車両に相乗りする形態（以下、「ライドシェア」と記す場合もある。）において、本発明を実施する例について述べる。なお、移動を目的とする複数のユーザが相乗りすることができる車両としては、自動車や電車等を使用することができるが、本実施形態では、自動車を対象とする例について述べる。

（ライドシェアの概要）
先ず、ライドシェアの概要について図１に基づいて説明する。図１に示す例では、ユーザＡは地点ｄから地点ｅまで移動し、ユーザＢは地点ｆから地点ｇまで移動し、ユーザＣは地点ｈから地点ｅまで移動するものとする。

ここで、仮にユーザＡ〜Ｃが各々の車両で別々に移動すると、３台の車両が必要となる。これに対して、ユーザＡ〜Ｃが相乗りを行うと、１台の車両で各目的地までの移動が可能となる。図１に示す例では、ユーザＡ自身が車両を運転して地点ｄから地点ｅまで移動する。このとき、ユーザＡは、地点ｆにおいて、自身が運転する車両にユーザＢを乗車させ、地点ｈにおいて、自身が運転する車両にユーザＣを乗車させる。そして、ユーザＡは、自身とユーザＣの目的地である地点ｅまで車両を移動させる途中で地点ｇを経由し、地点ｇでユーザＢを降車させることで、ユーザＢを出発地点ｆから目的地点ｇまで移動させることができる。その後、ユーザＡは、車両を地点ｇから地点ｅまで移動させることで、ユーザＣを地点ｈから地点ｅまで移動させることができるとともに、ユーザＡ自身の移動も達成することもできる。

このようなライドシェアでは、道路を走行する車両の台数を削減することができるため、交通渋滞を抑制することができる。また、例えば、車両の移動に要する交通費（燃料代等）を該車両に相乗りした複数のユーザで分担することで、各ユーザが個別の車両で移動する場合と比較して、ユーザ１人あたりの交通費を軽減することもできる。

なお、図１に示したライドシェアの態様はあくまで一例であり、１台の車両に相乗りするユーザの組合せや、相乗りに使用される車両（相乗り車両）の走行経路等は、種々の方法を用いて設定することが可能である。ただし、同一の時間帯における移動を希望している同乗希望ユーザであって、且つ同一の経路上に出発地及び目的地が含まれる同乗希望ユーザのグループ（以下、「同乗希望グループ」と記す場合もある。）の人数に対して、上記時間帯に上記経路を含む走行経路を走行予定の相乗り車両の全車で同乗させることができるユーザの人数の方が少なければ、上記同乗希望グループの一部の同乗希望ユーザが相乗り車両に同乗することができなくなる。これにより、当該一部の同乗希望ユーザの利便性が低下したり、当該一部の同乗希望ユーザのライドシェア利用意欲が低下したりする可
能性がある。

これに対し、本実施形態では、ライドシェアサービスの運用及び管理に関わる情報処理を行うためのサーバ装置が、相乗り車両の台数が所定の下限値を下回るときに、自身の運転する相乗り車両に同乗希望ユーザを同乗させることが可能なユーザの候補である運転ユーザ候補を抽出し、抽出された運転ユーザ候補に対して、自身の運転する車両に同乗希望ユーザを同乗させることを提案することで、相乗り車両の台数増加を促進する。

（システム構成）
図２は、ライドシェアサービスの提供を行うためのシステム（以下、「ライドシェアシステム」と記す場合もある。）の一構成例を示す図である。図２に示す例では、ライドシェアシステムは、相乗りに利用される車両（相乗り車両）１０、該相乗り車両１０に相乗りするユーザが使用するユーザ端末２００、及びサーバ装置３００を含んで構成される。ユーザ端末２００とサーバ装置３００とは、ネットワークＮ１によって相互に接続可能である。ネットワークＮ１には、例えば、インターネット等の世界規模の公衆通信網であるＷＡＮ（Wide Area Network）やその他の通信網が採用されてもよい。また、ネットワー
クＮ１は、携帯電話等の電話通信網、ＷｉＦｉ等の無線通信網を含んでもよい。

なお、図２に示す例では、相乗りに使用される車両（相乗り車両）として、１台の車両１０のみが図示されているが、当該ライドシェアサービスで利用可能な車両として登録されている台数分の相乗り車両がライドシェアシステムに含まれるものとする。また、図２に示す例では、ユーザ端末２００として、運転希望ユーザが使用する第１ユーザ端末２００Ａと、同乗希望ユーザが使用する第２ユーザ端末２００Ｂとの２個のみが図示されているが、当該ライドシェアサービスを利用可能な会員として登録されているユーザ数に応じた個数のユーザ端末がライドシェアシステムに含まれるものとする。

ユーザ端末２００には、ライドシェアサービスを利用するための所定のアプリケーションがインストールされている。ユーザ端末２００のユーザは、自身のユーザ端末２００に上記所定のアプリケーションを実行させることで、相乗りを行う際の条件等に関する情報（以下、「リクエスト情報」と記す場合もある。）を、サーバ装置３００に登録することができる。例えば、運転希望ユーザは、第１ユーザ端末２００Ａに上記所定のアプリケーションを実行させることで、自身の運転する相乗り車両１０の走行予定区間や走行予定日時等に関する情報（走行スケジュール）を、リクエスト情報として、サーバ装置３００に登録することができる。また、同乗希望ユーザは、第２ユーザ端末２００Ｂに上記所定のアプリケーションを実行させることで、自身の希望する移動区間や移動日時等に関する情報（移動スケジュール）を、リクエスト情報として、サーバ装置３００に登録することができる。

サーバ装置３００は、運転希望ユーザからのリクエスト情報、及び同乗希望ユーザからのリクエスト情報を各々受け付ける。そして、サーバ装置３００は、運転希望ユーザからのリクエスト情報と同乗希望ユーザからのリクエスト情報とに基づいて、運転希望ユーザと同乗希望ユーザとの暫定的な組合せを決定する。例えば、サーバ装置３００は、運転希望ユーザの出発地から目的地までに該運転希望ユーザの運転する相乗り車両１０が走行する経路（走行予定経路）を設定し、設定された走行予定経路若しくは設定された走行予定経路近傍に乗車地及び降車地が位置する同乗希望ユーザを該運転希望ユーザと暫定的に組み合わせる。サーバ装置３００は、上記した暫定的な組合せにおける運転希望ユーザと同乗希望ユーザとの各々のユーザ端末２００に対して、相乗りの条件を示す情報を送信する。そして、運転希望ユーザと同乗希望ユーザとの各々のユーザ端末２００から相乗りの条件に承諾する情報を受信すると、サーバ装置３００が、上記した暫定的な組合せを正式な組合せに確定する。以下では、上記した手順でサーバ装置３００が運転希望ユーザと同乗
希望ユーザとの組合せを確定する処理を、「マッチング処理」と称する。また、サーバ装置３００は、上記マッチング処理を行う機能に加え、相乗り車両の台数が所定の下限値を下回るときに、相乗り車両１０の台数増加を促進させる処理（以下、「台数調整処理」と記す場合もある。）を行う機能も有する。これらの機能を有するサーバ装置３００が、本発明に係る「情報処理装置」に相当する。

（ハードウェア構成）
図３は、ユーザ端末２００、及びサーバ装置３００の各々のハードウェア構成を例示する図である。なお、前述の図２に示した第１ユーザ端末２００Ａと第２ユーザ端末２００Ｂは、図３中のユーザ端末２００と同様のハードウェア構成を含むものとする。

サーバ装置３００は、一般的なコンピュータの構成を有している。すなわち、サーバ装置３００は、プロセッサ３０１、主記憶部３０２、補助記憶部３０３、通信部３０４を有する。これらは、互いにバスによって接続されている。主記憶部３０２及び補助記憶部３０３は、コンピュータで読み取り可能な記録媒体である。コンピュータのハードウェア構成は、図３に示す例に限らず、適宜構成要素の省略、置換、追加が行われてもよい。

サーバ装置３００は、プロセッサ３０１が記録媒体に記憶されたプログラムを主記憶部３０２の作業領域にロードして実行し、プログラムの実行を通じて各機能構成部等が制御されることによって、所定の目的に合致した機能を実現する。

プロセッサ３０１は、例えば、ＣＰＵ（Central Processing Unit）やＤＳＰ（Digital
Signal Processor）である。プロセッサ３０１は、サーバ装置３００を制御し、様々な
情報処理の演算を行う。主記憶部３０２は、例えば、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）を含む。補助記憶部３０３は、例えば、ＥＰＲＯＭ（Erasable Programmable ROM）、ハードディスクドライブ（Hard Disk Drive :HDD）である。ま
た、補助記憶部３０３は、リムーバブルメディア、即ち可搬記録媒体を含むことができる。リムーバブルメディアは、例えば、ＵＳＢ（Universal Serial Bus）メモリや、ＣＤ（Compact Disc）又はＤＶＤ（Digital Versatile Disc）等のようなディスク記録媒体である。

補助記憶部３０３は、各種のプログラム、各種のデータ及び各種のテーブルを読み書き自在に記録媒体に格納する。補助記憶部３０３には、オペレーティングシステム（Operating System :OS）、各種プログラム、各種テーブル等が格納される。なお、これらの情報の一部又は全部は、主記憶部３０２に格納されてもよい。また、主記憶部３０２に格納される情報は、補助記憶部３０３に格納されてもよい。

通信部３０４は、外部の装置とサーバ装置３００との間における情報の送受信を行う。通信部３０４は、例えば、ＬＡＮ（Local Area Network）インターフェースボード、無線通信のための無線通信回路である。ＬＡＮインターフェースボードや無線通信回路は、ネットワークＮ１に接続される。

上記したように構成されるサーバ装置３００で実行される一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。

次に、ユーザ端末２００は、例えば、スマートフォン、携帯電話、タブレット端末、個人情報端末、ウェアラブルコンピュータ（スマートウォッチ等）等のように、ユーザが携帯可能な小型のコンピュータである。なお、ユーザ端末２００は、公衆通信網であるインターネット等のネットワークＮ１を介してサーバ装置３００に接続される、パーソナルコンピュータ（Personal Computer :PC）であってもよい。

ユーザ端末２００は、プロセッサ２０１、主記憶部２０２、補助記憶部２０３、表示部２０４、入力部２０５、位置取得部２０６、通信部２０７を有する。プロセッサ２０１、主記憶部２０２、補助記憶部２０３については、サーバ装置３００のプロセッサ３０１、主記憶部３０２、補助記憶部３０３と同様であるため、説明は省略される。表示部２０４は、例えば、ＬＣＤ（Liquid Crystal Display）、ＥＬ（Electroluminescence）パネル
等である。入力部２０５は、例えば、文字等の記号を入力可能なタッチパネルや押しボタン、音声を入力可能なマイクロフォン、動画像や静止画像を撮像可能なカメラ等を含む。位置取得部２０６は、ユーザ端末２００の現在位置を取得する機器であり、典型的にはＧＰＳ受信器等を含んで構成される。通信部２０７は、例えば、移動体通信サービス（携帯電話等の電話通信網、ＷｉＦｉ等の無線通信）を利用してネットワークＮ１にアクセスし、サーバ装置３００等とデータ通信をするための通信回路である。

（サーバ装置の機能構成）
ここで、サーバ装置３００の機能構成について、図４に基づいて説明する。図４に示すように、本実施形態のサーバ装置３００は、その機能構成要素として、マッチング処理部Ｆ３１０、調整処理部Ｆ３２０、走行スケジュール管理データベースＤ３１０、移動スケジュール管理データベースＤ３２０、及び予約管理データベースＤ３３０を含む。ここで、マッチング処理部Ｆ３１０及び調整処理部Ｆ３２０は、サーバ装置３００のプロセッサ３０１が主記憶部３０２上のコンピュータプログラムを実行することにより形成される。なお、マッチング処理部Ｆ３１０と調整処理部Ｆ３２０の何れか、又はその一部がハードウェア回路により形成されてもよい。

走行スケジュール管理データベースＤ３１０、移動スケジュール管理データベースＤ３２０、予約管理データベースＤ３３０、及び会員情報管理データベースＤ３４０は、サーバ装置３００のプロセッサ３０１によって実行されるデータベース管理システム（Database Management System :DBMS）のプログラムが、補助記憶部３０３に記憶されているデータを管理することで構築される。これら走行スケジュール管理データベースＤ３１０、移動スケジュール管理データベースＤ３２０、予約管理データベースＤ３３０、及び会員情報管理データベースＤ３４０は、例えば、リレーショナルデータベースである。

なお、サーバ装置３００の各機能構成要素の何れか、又はその処理の一部は、ネットワークＮ１に接続される他のコンピュータにより実行されてもよい。例えば、マッチング処理部Ｆ３１０に含まれる各処理と、調整処理部Ｆ３２０に含まれる各処理とは、別々のコンピュータにより実行されてもよい。

走行スケジュール管理データベースＤ３１０は、各相乗り車両１０の走行スケジュールが格納されており、そこでは相乗り車両１０の運転を希望するユーザである運転希望ユーザの識別情報と相乗り車両１０の走行スケジュールとの紐付けが行われている。ここで、走行スケジュール管理データベースＤ３１０に格納される走行スケジュール情報の一構成例について、図５に基づいて説明する。図５は、走行スケジュール情報のテーブル構成を例示する図である。なお、走行スケジュール情報テーブルに登録される情報は、図５に示す例に限られず、適宜フィールドの追加、変更、削除が可能である。

図５に示す走行スケジュール情報テーブルは、車両ＩＤ、運転希望ユーザＩＤ、出発地、出発予定日時、目的地、到着予定日時、走行予定経路、及びステータス等の各フィールドを有する。車両ＩＤフィールドには、各相乗り車両１０を識別するための情報である車両ＩＤが登録される。ここでいう車両ＩＤは、各相乗り車両１０の運転希望ユーザがライドシェアサービスの会員登録を行う際に、後述のユーザＩＤとともに付与される情報であり、個々の相乗り車両１０を識別するための情報である。運転希望ユーザＩＤフィールド
には、各相乗り車両１０の運転希望ユーザを識別するための情報であるユーザＩＤが登録される。ユーザＩＤは、相乗り車両１０の運転希望ユーザがライドシェアサービスの会員登録を行う際に付与される情報である。出発地フィールドには、各相乗り車両１０の出発地を示す情報が登録される。なお、ここでいう出発地は、運転希望ユーザが相乗り車両１０による移動を開始する場所に限定されず、運転希望ユーザが自身の都合等に応じて適宜に変更することができる。出発予定日時フィールドには、運転希望ユーザが自身の運転する相乗り車両１０で上記出発地を出発する予定日時を示す情報が登録される。目的地フィールドには、運転希望ユーザが相乗り車両１０で向かう目的地を示す情報が登録される。なお、ここでいう目的地は、運転希望ユーザが相乗り車両１０による移動を終了する場所に限定されず、運転希望ユーザが自身の都合等に応じて適宜に変更することができる。到着予定日時フィールドには、運転希望ユーザが自身の運転する相乗り車両１０で上記目的地に到着する予定日時を示す情報が登録される。走行予定経路フィールドには、運転希望ユーザの出発地から目的地までに相乗り車両１０が通行可能な経路であって、且つ前記到着予定日時までに前記目的地へ到着することができると予測される経路を示す情報が登録される。ステータスフィールドには、運転希望ユーザによる相乗り車両１０の移動状況を示す情報が登録される。例えば、運転希望ユーザの運転によって相乗り車両１０が目的地に既に到着している場合には、「到着済」と登録され、運転希望ユーザの運転によって相乗り車両１０が出発地から目的地へ移動中である場合には、「移動中」と登録され、運転希望ユーザの運転によって相乗り車両１０が出発地から未だ出発していない場合には、「出発前」と登録される。なお、上記ステータスフィールドに「移動中」と登録される相乗り車両１０については、該相乗り車両１０の現在位置に関する情報も当該ステータスフィールドに登録されるようにしてもよい。その場合における相乗り車両１０の現在位置は、サーバ装置３００が運転希望ユーザのユーザ端末２００と通信することで取得されてもよく、又は相乗り車両１０に搭載されている通信可能な機器とサーバ装置３００が通信することで取得されてもよい。

移動スケジュール管理データベースＤ３２０は、任意の相乗り車両１０への相乗りを希望する同乗希望ユーザの移動スケジュールが格納されており、そこでは同乗希望ユーザの識別情報と移動スケジュールとの紐付けが行われている。ここで、移動スケジュール管理データベースＤ３２０に格納される移動スケジュール情報の一構成例について、図６に基づいて説明する。図６は、移動スケジュール情報のテーブル構成を例示する図である。なお、移動スケジュール情報テーブルに登録される情報は、図６に示す例に限られず、適宜フィールドの追加、変更、削除が可能である。

図６に示す移動スケジュール情報テーブルは、同乗希望ユーザＩＤ、乗車地、乗車希望日時、降車地、降車希望日時、及びステータス等の各フィールドを有する。同乗希望ユーザＩＤフィールドには、各同乗希望ユーザを識別するためのユーザＩＤが登録される。同乗希望ユーザのユーザＩＤは、前述した運転希望ユーザＩＤと同様に、同乗希望ユーザがライドシェアサービスの会員登録を行う際に付与される情報である。乗車地フィールドには、各同乗希望ユーザが相乗り車両１０への乗車を希望する場所（出発地）を示す情報が登録される。乗車希望日時フィールドには、各同乗希望ユーザが上記乗車地において相乗り車両１０への乗車を希望する日時を示す情報が登録される。降車地フィールドには、各同乗者が相乗り車両１０からの降車を希望する場所（目的地）を示す情報が登録される。降車希望日時フィールドには、各同乗希望ユーザが上記降車地において相乗り車両１０からの降車を希望する日時を示す情報が登録される。ステータスフィールドには、同乗希望ユーザの移動状況を示す情報が登録される。例えば、同乗希望ユーザが相乗り車両１０から既に降車している場合には、「降車済み」と登録され、同乗希望ユーザと組み合わせる運転希望ユーザが確定しているが、その運転希望ユーザの運転する相乗り車両１０に該同乗希望ユーザが乗車する前の段階にある場合には、「予約中」と登録され、該同乗希望ユーザと組み合わせる運転希望ユーザが確定していない段階にある場合には、「マッチング
中」と登録される。

予約管理データベースＤ３３０は、ライドシェアサービスの予約情報が格納されており、そこでは運転希望ユーザに関する情報と該運転希望ユーザの運転する相乗り車両１０に相乗り予定の同乗希望ユーザに関する情報との紐付けが行われている。ここで、予約管理データベースＤ３３０に格納される予約情報の一構成例について、図７に基づいて説明する。図７は、予約情報のテーブル構成を例示する図である。なお、予約情報テーブルに登録される情報は、図７に示す例に限られず、適宜フィールドの追加、変更、削除が可能である。

図７に示す予約情報テーブルは、予約ＩＤ、運転希望ユーザＩＤ、車両情報、同乗希望ユーザＩＤ、乗車地、乗車予定日時、降車地、降車予定日時、及びステータス等の各フィールドを有する。予約ＩＤフィールドには、個々の予約情報を識別するための情報である予約ＩＤが登録される。この予約ＩＤは、例えば、各ユーザが予約内容について確認や変更等を行う場合に使用される。運転希望ユーザＩＤフィールドには、相乗り車両１０を運転する運転希望ユーザのユーザＩＤが登録される。車両情報フィールドには、各運転希望ユーザが運転する相乗り車両１０を、該相乗り車両１０に同乗予定の同乗希望ユーザが識別するために必要な情報が登録される。例えば、車両情報フィールドには、車種、自動車登録番号（ナンバープレートに標記された番号）、車体色等の情報が登録される。同乗希望ユーザＩＤフィールドには、各運転希望ユーザの運転する相乗り車両１０に相乗りする予定の同乗希望ユーザのユーザＩＤが登録される。乗車地フィールドには、各運転希望ユーザが自身の運転する相乗り車両１０に同乗希望ユーザを乗車させる場所（乗車地）を示す情報が登録される。乗車予定日時フィールドには、上記乗車地において各運転希望ユーザが自身の運転する相乗り車両１０に同乗希望ユーザを乗車させる予定日時を示す情報が登録される。降車地フィールドには、各運転希望ユーザが自身の運転する相乗り車両１０から同乗希望ユーザを降車させる場所（降車地）を示す情報が登録される。降車予定日時フィールドには、上記降車地において各運転希望ユーザが自身の運転する相乗り車両１０から同乗希望ユーザを降車させる予定日時を示す情報が登録される。ステータスフィールドには、各相乗り車両１０の相乗り状況を示す情報が登録される。例えば、同乗希望ユーザが上記降車地点で相乗り車両１０から既に降車している場合には、「降車済み」と登録され、同乗希望ユーザが相乗り車両１０に乗車中である場合には、「乗車中」と登録され、同乗希望ユーザが相乗り車両１０に乗車する前の段階にある場合には、「乗車前」と登録される。

図７の予約情報テーブルは、各運転希望ユーザの運転する相乗り車両１０に１人の同乗希望ユーザが相乗りする場合のテーブル構成例を示しているが、各運転希望ユーザの運転する相乗り車両１０に相乗りする同乗希望ユーザの人数は２人以上であってもよい。その場合は、図８に示すように、１つの運転希望ユーザＩＤに対して、複数の同乗希望ユーザの情報が紐付けられればよい。

会員情報管理データベースＤ３４０は、ライドシェアサービスに会員登録されているユーザの情報（会員情報）が格納されている。ここで、会員情報管理データベースＤ３４０に格納される会員情報の一構成例について、図９に基づいて説明する。図９は、会員情報のテーブル構成を例示する図である。なお、会員情報テーブルに登録される情報は、図９に示す例に限られず、適宜フィールドの追加、変更、削除が可能である。

図９に示す会員情報テーブルは、ユーザＩＤ、連絡先、属性、認証、及び車両情報等の各フィールドを有する。ユーザＩＤフィールドには、各ユーザがライドシェアサービスの会員登録を行った際に付与されるユーザＩＤが登録される。連絡先フィールドには、各ユーザの連絡先を示す情報（例えば、電子メールアドレスや電話番号等であり、少なくとも
各ユーザが使用するユーザ端末２００の電子メールアドレスを含む）が登録される。属性フィールドには、各ユーザの属性を示す情報（例えば、氏名、ニックネーム、年齢、性別、職業、勤務先（通学先）、趣味、特技等）が登録される。認証フィールドには、前述のリクエスト情報をサーバ装置３００に登録する場合や、前述の予約情報を確認する場合等の認証に必要となるパスワード等を示す情報が登録される。車両情報フィールドには、各ユーザが相乗り車両１０として使用可能な車両の車両ＩＤや該車両の乗車定員等を示す情報、すなわち、相乗り車両として使用可能な車両を所有又はその車両の所有権を有していることを示す情報が登録される。なお、相乗り車両１０として使用可能な車両を所有していないユーザについては、例えば、車両情報フィールドに「無」と登録される。

次に、マッチング処理部Ｆ３１０は、運転希望ユーザや同乗希望ユーザからのリクエスト情報に基づいて、マッチング処理を行う。詳細には、運転希望ユーザのユーザ端末２００から送信されるリクエスト情報をサーバ装置３００が受信した場合に、マッチング処理部Ｆ３１０は、該リクエスト情報に含まれる出発地と目的地とを結ぶ経路であって、相乗り車両１０が通行可能な経路を全て抽出する。続いて、マッチング処理部Ｆ３１０は、抽出された経路のうち、上記リクエスト情報に含まれる到着予定日時までに上記目的地へ到着することができると予測される経路を、走行予定経路に設定する。その際、マッチング処理部Ｆ３１０は、運転希望ユーザが出発地から目的地へ移動する時間帯における渋滞予測情報や通行規制情報等を考慮して、走行予定経路を設定してもよい。斯様な方法で走行予定経路が設定されると、マッチング処理部Ｆ３１０は、運転希望ユーザからのリクエスト情報及び上記走行予定経路に基づいて、前述の図５に示したような走行スケジュール情報テーブルを生成し、生成された走行スケジュール情報テーブルを走行スケジュール管理データベースＤ３１０に格納する。また、同乗希望ユーザのユーザ端末２００から送信されるリクエスト情報をサーバ装置３００が受信した場合には、マッチング処理部Ｆ３１０は、該リクエスト情報に基づいて、前述の図６に示したような移動スケジュール情報テーブルを生成し、生成された移動スケジュール情報テーブルを移動スケジュール管理データベースＤ３２０に格納する。そして、マッチング処理部Ｆ３１０は、走行スケジュール管理データベースＤ３１０に格納されている走行スケジュール情報テーブルと、移動スケジュール管理データベースＤ３２０に格納されている移動スケジュール情報テーブルとを比較して、各同乗希望ユーザの移動スケジュールに適合する走行スケジュールを抽出する。例えば、マッチング処理部Ｆ３１０は、同乗希望ユーザの移動スケジュール情報テーブルにおける乗車地フィールドに登録されている乗車地、及び移動スケジュール情報テーブルの降車地フィールドに登録されている降車地が、走行予定経路フィールドに登録されている走行予定経路上に位置する走行スケジュール情報テーブルを抽出する。続いて、マッチング処理部Ｆ３１０は、抽出された走行スケジュール情報テーブルに紐づけられている運転希望ユーザを上記同乗希望ユーザと暫定的に組み合わせる。斯様な手順で運転希望ユーザと同乗希望ユーザとの暫定的な組合せが決定されると、マッチング処理部Ｆ３１０は、上記した暫定的な組合せにおける運転希望ユーザと同乗希望ユーザとの各々のユーザ端末２００Ａ、２００Ｂに対して、相乗りの条件を示す情報（例えば、同乗希望ユーザの乗車地、同乗希望ユーザの乗車予定日時、同乗希望ユーザの降車地、同乗希望ユーザの降車予定日時、走行予定経路、相乗り車両１０の種類等）を送信する。これに対し、運転希望ユーザ及び同乗希望ユーザの双方のユーザ端末２００から上記した相乗りの条件に承諾する情報が返信されてくると、マッチング処理部Ｆ３１０は、上記した暫定的な組合せを正式な組合せに確定する。これに伴い、マッチング処理部Ｆ３１０は、上記した正式な組合せに基づいて、前述の図７、８に示したような予約情報テーブルを生成し、生成された予約情報テーブルを予約管理データベースＤ３３０に格納する。

ところで、マッチング処理部Ｆ３１０が上記マッチング処理を行うにあたり、相乗り車両１０の台数が所定の下限値を下回っている場合もあり得る。すなわち、同一の時間帯の移動を希望している同乗希望ユーザであって、且つ同一の経路上に乗車地（出発地）及び
降車地（目的地）が含まれる同乗希望ユーザが複数人である場合に、それらの同乗希望ユーザ（同乗希望グループ）の移動を達成するために必要となる車両の最小の台数（各車両に定員数の同乗希望ユーザを同乗させると仮定した場合に、上記同乗希望グループの全員を乗せるために必要となる車両の台数（所定の下限値））に対し、上記時間帯に上記経路を含む走行経路を走行予定の相乗り車両１０の台数の方が少ない状況が発生し得る。例えば、図１０に示す例では、所定の経路Ｒｐ上に乗車地及び降車地が含まれる同乗ユーザは、乗車地Ｓ１から降車地Ｇ１までの移動を希望している同乗希望ユーザＡ、乗車地Ｓ２から降車地Ｇ２までの移動を希望している同乗希望ユーザＢ、乗車地Ｓ３から降車地Ｇ３までの移動を希望している同乗希望ユーザＣ、乗車地Ｓ４から降車地Ｇ４までの移動を希望している同乗希望ユーザＤ、及び乗車地Ｓ５から目的地Ｇ５までの移動を希望している同乗希望ユーザＥの５人である。これに対し、上記所定の経路Ｒｐを含む走行経路を走行予定の相乗り車両は、出発地Ｓｄから目的地Ｇｄへ向かう走行予定経路Ｒｄを走行予定の相乗り車両Ｃ１のみの１台である。ここで、相乗り車両Ｃ１の乗車定員が運転者を含め４人であれば、該相乗り車両Ｃ１に同乗することができる同乗希望ユーザの最大人数は３人となる。よって、同乗希望ユーザＡ〜Ｅを含む同乗希望グループのうち、２人の同乗希望ユーザが相乗り車両Ｃ１に同乗することができないことになる。

そこで、相乗り車両１０の台数が所定の下限値を下回るときには、調整処理部Ｆ３２０が、台数調整処理を実行することで、相乗り車両１０の台数増加を促進させる。台数調整処理では、調整処理部Ｆ３２０は、先ず、自身の運転する車両に同乗希望ユーザを同乗させることが可能なユーザの候補（運転ユーザ候補）を抽出する。本例では、調整処理部Ｆ３２０は、上記同乗希望グループのうち、相乗り車両として使用可能な車両を所有又はその車両の所有権を有する同乗希望ユーザを、自身の運転する相乗り車両に同乗希望ユーザを同乗させることが可能なユーザの候補（運転ユーザ候補）として抽出する。具体的には、調整処理部Ｆ３２０は、上記同乗希望グループに含まれる同乗希望ユーザの各々の会員情報テーブル（前述の図９を参照）へアクセスし、該会員情報テーブルの車両情報フィールドに車両ＩＤや乗車定員等の情報（相乗り車両として使用可能な車両を所有又はその車両の所有権を有していることを示す情報）が登録されている同乗希望ユーザを、運転ユーザ候補として抽出する。その際、会員情報テーブルの車両情報フィールドに車両ＩＤや乗車定員等の情報が登録されている同乗希望ユーザが複数人であれば、調整処理部Ｆ３２０は、それら複数人の同乗希望ユーザのうち、自身の希望している移動区間に乗車地及び降車地が含まれる他の同乗希望ユーザの人数が最も多い同乗希望ユーザを、運転ユーザ候補として抽出すればよい。ここで、前述の図１０に示す例において、同乗希望ユーザＡ〜Ｅの全員が相乗り車両として使用可能な車両を所有又はその車両の所有権を有していれば、それら同乗希望ユーザＡ〜Ｅのうち、自身の希望している移動区間に乗車地及び降車地が含まれる他の同乗希望ユーザの人数が最も多いのは、同乗希望ユーザＡである。すなわち、同乗希望ユーザＡの移動区間Ｓ１〜Ｇ１には、同乗希望ユーザＢの乗車地Ｓ２及び降車地Ｇ２、同乗希望ユーザＣの乗車地Ｓ３及び降車地Ｇ３、同乗希望ユーザＤの乗車地Ｓ４及び降車地Ｇ４が含まれる。これにより、同乗希望ユーザＡの移動区間Ｓ１〜Ｇ１に乗車地及び降車地が含まれる他の同乗希望ユーザの人数は３人となる。また、同乗希望ユーザＢの移動区間Ｓ２〜Ｇ２には、同乗希望ユーザＣの乗車地Ｓ３及び降車地Ｇ３、同乗希望ユーザＤの乗車地Ｓ４及び降車地Ｇ４が含まれる。これにより、同乗希望ユーザＢの移動区間Ｓ２〜Ｇ２に乗車地及び降車地が含まれる他の同乗希望ユーザの人数は２人となる。なお、同乗希望ユーザＣ〜Ｅの各々の移動区間Ｓ３〜Ｇ３、Ｓ４〜Ｇ４、Ｓ５〜Ｇ５には、他の同乗希望ユーザの乗車地及び降車地が含まれていない。そのため、同乗希望ユーザＣ〜Ｅの各々の移動区間Ｓ３〜Ｇ３、Ｓ４〜Ｇ４、Ｓ５〜Ｇ５に乗車地及び降車地が含まれる他の同乗希望ユーザの人数は０人となる。よって、調整処理部Ｆ３２０は、同乗希望ユーザＡ〜Ｅのうち、同乗希望ユーザＡを運転ユーザ候補として抽出することになる。なお、同乗希望ユーザＡ〜Ｅの中に、相乗り車両として使用可能な車両を所有又はその車両の所有権を有する同乗希望ユーザがいない場合、或いは同乗希望ユーザＡ〜Ｅの各々の移
動区間に乗車地及び降車地が含まれる他の同乗希望ユーザの人数が０人である場合には、調整処理部Ｆ３２０は、同乗希望グループ以外のユーザ会員の中から、運転ユーザ候補を抽出してもよい。例えば、調整処理部Ｆ３２０は、同乗希望グループ以外のユーザ会員のうち、上記所定の区間Ｒ１を含む走行経路の走行頻度が高いユーザ会員を、運転ユーザ候補として抽出してもよい。

上記した方法で運転ユーザ候補が抽出されると、調整処理部Ｆ３２０は、運転ユーザ候補として抽出された同乗希望ユーザの会員情報テーブルにおける連絡先フィールドから、該同乗希望ユーザの使用するユーザ端末２００の電子メールアドレスを読み出し、その電子メールアドレス宛に第１情報を送信する。ここでいう「第１情報」は、自身の運転する車両に同乗希望ユーザを同乗させることについて承諾を求める情報である。言い換えると、第１情報は、運転ユーザ候補が所有又は所有権を有する車両を相乗り車両として提供することについて承諾を求める情報である。また、第１情報は、運転ユーザ候補のカテゴリを同乗希望ユーザから運転希望ユーザへ変更することについて承諾を求める情報とも言える。そして、上記第１情報に応答する形で、自身の運転する車両に同乗希望ユーザを同乗させることに承諾する情報が、運転ユーザ候補のユーザ端末２００からサーバ装置３００へ送信されると、調整処理部Ｆ３２０は、上記運転ユーザ候補のカテゴリを、同乗希望ユーザから運転希望ユーザへ変更する。具体的には、調整処理部Ｆ３２０は、運転ユーザ候補の移動スケジュール情報テーブルに基づいて、該運転ユーザ候補の走行スケジュールを生成する。その際、調整処理部Ｆ３２０は、運転ユーザ候補の移動スケジュール情報テーブルに登録されている乗車地、乗車予定日時、降車地、降車予定日時を、出発地、出発予定日時、目的地、到着予定日時に各々変更することで、運転ユーザ候補の走行スケジュールを生成する。斯様にして生成された走行スケジュールは、調整処理部Ｆ３２０からマッチング処理部Ｆ３１０へ渡される。それに伴い、運転ユーザ候補の移動スケジュール情報テーブルは、移動スケジュール管理データベースＤ３２０から削除される。

なお、上記第１情報に応答する形でユーザ端末２００からサーバ装置３００へ送信される情報が、自身の運転する車両に同乗希望ユーザを同乗させることに承諾しない情報である場合には、調整処理部Ｆ３２０は、上記同乗希望グループの中から、上記運転ユーザ候補とは異なる同乗希望ユーザを新たな運転ユーザ候補として抽出し直す。例えば、図１０に示した例においては、同乗希望ユーザＡを除く４人の同乗希望ユーザＢ〜Ｅのうち、自身の希望している移動区間に乗車地及び降車地が含まれる他の同乗希望ユーザの人数が最も多い同乗希望ユーザＢを、新たな運転ユーザ候補として抽出し直せばよい。

また、調整処理部Ｆ３２０によって生成された走行スケジュールがマッチング処理部Ｆ３１０に渡された場合には、マッチング処理部Ｆ３１０は、運転希望ユーザからのリクエスト情報を受け取ったときと同様の手順で、運転ユーザ候補の走行スケジュール情報テーブルを生成し、生成された走行スケジュール情報テーブルを走行スケジュール管理データベースＤ３１０に登録する。その際、上記した所定の経路のうち、運転ユーザ候補の出発地と目的地とを結ぶ区間が、走行予定経路に設定されるものとする。そして、マッチング処理部Ｆ３１０は、運転ユーザ候補の走行スケジュールに基づくマッチング処理を行う。

相乗り車両の台数が所定の下限値を下回るときに、上記した方法で台数調整処理及びマッチング処理が行われると、相乗り車両の台数を増やすことができるとともに、同乗希望グループの人数を減らすことができるため、相乗り車両に同乗することができない同乗希望ユーザの人数を減らすことができる。

（処理の流れ）
本実施形態に係るサーバ装置３００の処理の流れについて図１１に基づいて説明する。図１１は、サーバ装置３００が実行する処理のフローチャートである。

図１１において、サーバ装置３００は、各運転希望ユーザの走行スケジュールを取得する（ステップＳ１０１）。具体的には、先ず、各運転希望ユーザの使用する第１ユーザ端末２００Ａにおいて、運転希望ユーザによる入力部２０５への走行スケジュールの入力が行われることで、該走行スケジュールがリクエスト情報として通信部２０７からサーバ装置３００へ送信される。そして、第１ユーザ端末２００Ａから送信されるリクエスト情報をサーバ装置３００の通信部３０４が受信することで、各運転希望ユーザの走行スケジュールが取得される。

ステップＳ１０２では、サーバ装置３００は、上記ステップＳ１０１で取得された走行スケジュールに基づいて、各運転希望ユーザが運転する相乗り車両１０の走行予定経路を設定する。具体的には、サーバ装置３００のマッチング処理部Ｆ３１０が、先ず、上記ステップＳ１０１で取得された走行スケジュールから、運転希望ユーザの出発地及び目的地を取得する。続いて、マッチング処理部Ｆ３１０が、取得された出発地から目的地まで相乗り車両１０が通行可能な経路を全て抽出する。また、マッチング処理部Ｆ３１０が、上記ステップＳ１０１で取得された走行スケジュールに含まれる、出発予定日時及び到着予定日時に基づいて、運転希望ユーザが出発地から目的地へ移動する時間帯における渋滞予測情報及び通行規制情報を取得する。そして、マッチング処理部Ｆ３１０は、渋滞予測情報や通行規制情報に基づいて、運転希望ユーザの出発地から目的地まで相乗り車両１０が通行可能な全経路のうち、運転希望ユーザが予定到着日時までに目的地へ到着することができると予測される経路を、走行予定経路に設定する。

ステップＳ１０３では、サーバ装置３００は、上記ステップＳ１０１で取得された走行スケジュール、及び上記ステップＳ１０２で設定された走行予定経路に基づいて、前述の図５に示したような走行スケジュール情報テーブルを生成し、生成された走行スケジュール情報テーブルを走行スケジュール管理データベースＤ３１０に登録する。

また、ステップＳ１０４では、サーバ装置３００は、各同乗希望ユーザの移動スケジュールを取得する。具体的には、先ず、各同乗希望ユーザの使用する第２ユーザ端末２００Ｂにおいて、同乗希望ユーザによる入力部２０５への移動スケジュールの入力が行われることで、該移動スケジュールがリクエスト情報として通信部２０７からサーバ装置３００へ送信される。そして、第２ユーザ端末２００Ｂから送信されるリクエスト情報をサーバ装置３００の通信部３０４が受信することで、各同乗希望ユーザの移動スケジュールが取得される。

ステップＳ１０５では、サーバ装置３００は、上記ステップＳ１０４で取得された移動スケジュールに基づいて、前述の図６に示したような移動スケジュール情報テーブルを生成し、生成された移動スケジュール情報テーブルを移動スケジュール管理データベースＤ３２０に登録する。

なお、各ユーザが上記リクエスト情報をサーバ装置３００に登録する方法は、ユーザ端末２００Ａ、２００Ｂを利用した方法に限定されるものではなく、例えば、ネットワークＮ１に接続可能な任意の端末（スマートフォン、携帯電話、タブレット端末、個人情報端末、ウェアラブルコンピュータ等）やパーソナルコンピュータ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ、ＰＣ）を利用して、上記リクエスト情報をサーバ装置３００に登録してもよい。また、図１１に示す例では、各運転希望ユーザの走行スケジュールの取得、及び各運転希望ユーザの走行スケジュール情報テーブルの生成が、各同乗希望ユーザの移動スケジュールの取得、及び各同乗希望ユーザの移動スケジュール情報テーブルの生成より先に行われているが、各同乗希望ユーザの移動スケジュールの取得、及び各同乗希望ユーザの移動スケジュール情報テーブルの生成が、各運転希望ユーザの走行スケジュールの取得、
及び各運転希望ユーザの走行スケジュール情報テーブルの生成より先に行われてもよい。

ステップＳ１０６では、サーバ装置３００は、相乗り車両１０の台数が所定の下限値を下回っているかを判別する。具体的には、サーバ装置３００は、移動スケジュール管理データベースＤ３２０を参照して、同一の時間帯における移動を希望している同乗希望ユーザであって、且つ同一の経路上に乗車地及び降車地が含まれる同乗希望ユーザを全て抽出することで、それら同乗希望ユーザ（同乗希望グループ）の人数Ｈｃを取得する。また、サーバ装置３００は、走行スケジュール管理データベースＤ３１０を参照して、上記時間帯に上記経路を含む走行予定経路を走行予定の相乗り車両１０を全て抽出し、抽出された相乗り車両１０に同乗させることができるユーザの最大人数（以下、「最大同乗人数」と記す場合もある。）Ｈｃｍａｘを取得する。その際、サーバ装置３００は、上記時間帯に上記経路を含む走行予定経路を走行予定の相乗り車両１０に紐付けられている運転希望ユーザの会員情報テーブルへアクセスして、車両情報フィールドに登録されている乗車定員情報を参照することで、上記最大同乗人数Ｈｃｍａｘを演算してもよい。すなわち、各相乗り車両１０の乗車定員から運転希望ユーザの人数（１人）を差し引いた人数の総和を、最大同乗人数Ｈｃｍａｘとして演算してもよい。なお、上記時間帯に上記経路を含む走行予定経路を走行予定の相乗り車両１０に運転希望ユーザの家族や友人等が乗車している場合には、それらの乗車人数を差し引いて上記最大同乗人数Ｈｃｍａｘを演算すればよい。そして、サーバ装置３００は、上記同乗希望グループの人数Ｈｃに比して上記最大同乗人数Ｈｃｍａｘの方が少なければ、相乗り車両１０の台数が所定の下限値を下回っていると判定する一方で、上記同乗希望グループの人数Ｈｃに比して上記最大同乗人数Ｈｃｍａｘが同数以上であれば、相乗り車両１０の台数が所定の下限値を下回っていないと判定する。

上記ステップＳ１０６で否定判定がなされた場合には、サーバ装置３００は、ステップＳ１０７〜ステップＳ１１０をスキップして、ステップＳ１１１へ進む。一方、上記ステップＳ１０６において肯定判定がなされた場合には、サーバ装置３００は、ステップＳ１０７〜ステップＳ１１０において台数調整処理を実行する。

ステップＳ１０７では、サーバ装置３００は、運転ユーザ候補を抽出する。運転ユーザ候補の抽出方法は、前述の図１０の説明で述べた方法を用いることができる。すなわち、サーバ装置３００は、上記同乗希望グループに含まれる同乗希望ユーザのうち、相乗り車両として使用可能な車両を所有又はその所有権を有する同乗希望ユーザを、運転ユーザ候補として抽出する。その際、相乗り車両として使用可能な車両を所有又はその所有権を有する同乗希望ユーザが複数であれば、サーバ装置３００は、自身の希望している移動区間に乗車地及び降車地が含まれる他の同乗希望ユーザの人数が最も多い同乗希望ユーザを、運転ユーザ候補として抽出する。

ステップＳ１０８では、サーバ装置３００は、上記ステップＳ１０７で抽出された運転ユーザ候補に紐付けられている会員情報テーブルへアクセスすることで、連絡先フィールドに登録されている、ユーザ端末２００の電子メールアドレスを抽出する。そして、サーバ装置３００は、抽出された電子メールアドレス宛に、第１情報を送信する。ここでいう第１情報は、前述したように、運転ユーザ候補の運転する他の同乗希望ユーザを同乗させることについて承諾を求める情報、言い換えると、運転ユーザ候補が所有又は所有権を有する車両を相乗り車両として提供することについて承諾を求める情報である。

上記第１情報に応答する形で運転ユーザ候補のユーザ端末２００から送信される情報を、サーバ装置３００の通信部３０４が受信すると、サーバ装置３００は、受信した情報が承諾情報（運転ユーザ候補の運転する車両に他の同乗希望ユーザを同乗させることについて承諾する情報）であるかを判別する（ステップＳ１０９）。

上記ステップＳ１０９で否定判定がなされた場合は、サーバ装置３００は、ステップＳ１０７に戻り、上記運転ユーザ候補とは異なるユーザを新たな運転ユーザ候補として抽出し直す。一方、上記ステップＳ１０９で肯定判定がなされた場合は、サーバ装置３００は、ステップＳ１１０へ進み、上記運転ユーザ候補のカテゴリを同乗希望ユーザから運転希望ユーザへ変更する。具体的には、サーバ装置３００は、先ず、運転ユーザ候補の移動スケジュール情報テーブルに基づいて、運転ユーザ候補の走行スケジュール情報テーブルを生成し、生成された走行スケジュール情報テーブルを走行スケジュール管理データベースＤ３１０に登録する。その際の走行スケジュール情報テーブルの生成方法及び登録方法は、上記ステップＳ１０２〜Ｓ１０３と同様である。

ステップＳ１１１では、サーバ装置３００は、走行スケジュール管理データベースＤ３１０に登録されている走行スケジュール情報テーブル、及び移動スケジュール管理データベースＤ３２０に登録されている移動スケジュール情報テーブルに基づいて、運転希望ユーザと同乗希望ユーザとの組合せを決定する処理（マッチング処理）を実行する。

以上述べたフローによれば、相乗り車両の台数が所定の下限値を下回るときに、相乗り車両の台数増加を促進させるための台数調整処理が行われることで、相乗り車両の台数を増やすことができるとともに、同乗希望グループの人数を減らすことができる。それにより、相乗り車両に同乗することができない同乗希望ユーザの人数を減らすことができる。その結果、相乗り車両が不足することを抑制することが可能になる。

＜第１実施形態の変形例＞
なお、上記台数調整処理において、サーバ装置３００から運転ユーザ候補のユーザ端末２００へ第１情報が送信される際に、自身の運転する車両に他の同乗希望ユーザを同乗させることについて承諾したと仮定した場合に該運転ユーザ候補に供与されるインセンティブに関する情報を送信するようにしてもよい。ここでいう「インセンティブ」とは、例えば、所定のサービスに使用可能なポイント、割引券や商品券の電子データ、電子マネー等である。斯様なインセンティブに関する情報が第１情報とともに運転ユーザ候補に提供されることで、自身の運転する車両へ同乗希望ユーザを同乗させることについて運転ユーザ候補が承諾する意欲を喚起することができる。それにより、相乗り車両が不足することを抑制し易くなる。

＜第２実施形態＞
次に、本発明に係る情報処理装置の第２実施形態について説明する。なお、本実施形態において、前述した第１実施形態と実質的に同一の構成、実質的に同一の制御処理については、その詳細な説明を省略する。

本実施形態では、相乗り車両１０の台数が所定の下限値を下回る場合に加え、相乗り車両１０の台数が所定の上限値を上回る場合においても、台数調整処理が行われる例について述べる。

ここで、マッチング処理部Ｆ３１０が上記マッチング処理を行うにあたり、相乗り車両１０の台数が所定の上限値を上回っている場合もあり得る。すなわち、同乗希望グループの移動を達成するために必要となる相乗り車両の最大の台数（各相乗り車両に最小人数（例えば、１人ずつ）の同乗希望ユーザを同乗させると仮定した場合に、上記同乗希望グループの全員を乗せるために必要となる車両の台数（所定の上限値））に対し、上記時間帯に上記経路を含む走行予定経路を走行予定の相乗り車両の台数の方が多い状況が発生し得る。その場合、上記時間帯に上記経路を含む走行予定経路を走行予定の相乗り車両のうち、一部の相乗り車両に同乗希望ユーザを１人も同乗させることができなくなることで、該
相乗り車両の運転希望ユーザの利便性が低下したり、該運転希望ユーザのライドシェア利用意欲が低下したりする可能性がある。

そこで、相乗り車両１０の台数が所定の上限値を上回るときには、調整処理部Ｆ３２０が、相乗り車両１０の台数減少を促進させるための台数調整処理を実行する。その場合の台数調整処理では、調整処理部Ｆ３２０は、先ず、他の運転希望ユーザが運転する相乗り車両に同乗することが可能なユーザの候補（同乗ユーザ候補）を抽出する。本例では、調整処理部Ｆ３２０は、上記時間帯に上記経路を含む走行予定経路を走行予定の相乗り車両１０の運転希望ユーザ（以下、「運転希望グループ」と記す場合もある。）のうち、自身の出発地及び目的地が他の運転希望ユーザの運転する相乗り車両１０の走行予定経路に含まれる運転希望ユーザを、同乗ユーザ候補として抽出する。例えば、図１２に示す例では、出発地Ｓｄ１から目的地Ｇｄ１へ向かう走行予定経路Ｒｄ１を走行予定の相乗り車両Ｃ１と、出発地Ｓｄ２から目的地Ｇｄ２へ向かう走行予定経路Ｒｄ２を走行予定の相乗り車両Ｃ２とのうち、相乗り車両Ｃ２の運転希望ユーザが同乗ユーザ候補として抽出される。これは、相乗り車両Ｃ２の出発地Ｓｄ２及び目的地Ｇｄ２が相乗り車両Ｃ１の走行予定経路Ｒｄに含まれるためである。

上記した方法で同乗ユーザ候補が抽出されると、調整処理部Ｆ３２０は、同乗ユーザ候補として抽出された運転希望ユーザの会員情報テーブルにおける連絡先フィールドから、該運転希望ユーザの使用するユーザ端末２００の電子メールアドレスを読み出し、その電子メールアドレス宛に第２情報を送信する。ここでいう「第２情報」は、他の運転希望ユーザが運転する相乗り車両に同乗することについて承諾を求める情報である。言い換えると、第２情報は、自身の運転する車両による移動形態から他の運転希望ユーザの運転する相乗り車両へ同乗する移動形態への変更について承諾を求める情報である。また、第２情報は、同乗ユーザ候補のカテゴリを運転希望ユーザから同乗希望ユーザへ変更することについて承諾を求める情報とも言える。そして、上記第２情報に応答する形で、他の運転希望ユーザの運転する相乗り車両に同乗することに承諾する情報が、同乗ユーザ候補のユーザ端末２００からサーバ装置３００へ送信されると、調整処理部Ｆ３２０は、上記同乗ユーザ候補のカテゴリを、運転希望ユーザから同乗希望ユーザへ変更する。具体的には、調整処理部Ｆ３２０は、同乗ユーザ候補の走行スケジュール情報テーブルに基づいて、該同乗ユーザ候補の移動スケジュールを生成する。その際、調整処理部Ｆ３２０は、同乗ユーザ候補の走行スケジュール情報テーブルに登録されている出発地、出発予定日時、目的地、到着予定日時を、乗車地、乗車予定日時、降車地、降車予定日時に各々変更することで、同乗ユーザ候補の移動スケジュールを生成する。斯様にして生成された移動スケジュールは、調整処理部Ｆ３２０からマッチング処理部Ｆ３１０へ渡される。それに伴い、同乗ユーザ候補の走行スケジュール情報テーブルは、走行スケジュール管理データベースＤ３１０から削除される。

なお、上記第２情報に応答する形でユーザ端末２００からサーバ装置３００へ送信される情報が、他の運転希望ユーザの運転する相乗り車両に同乗することに承諾しない情報である場合には、調整処理部Ｆ３２０は、上記運転希望グループの中から、上記同乗ユーザ候補とは異なる運転希望ユーザを新たな同乗ユーザ候補として抽出し直せばよい。

また、自身の出発地及び目的地が他の運転希望ユーザの運転する相乗り車両１０の走行予定経路に含まれる運転希望ユーザが運転希望グループの中にいない場合には、調整処理部Ｆ３２０は、運転希望グループ以外のユーザ会員の中から、同乗ユーザ候補を抽出してもよい。例えば、調整処理部Ｆ３２０は、運転希望グループ以外のユーザ会員のうち、上記経路に含まれる区間の移動頻度が高いユーザ会員を、同乗ユーザ候補として抽出してもよい。

上記したように生成される移動スケジュールが調整処理部Ｆ３２０からマッチング処理部Ｆ３１０へ渡されると、マッチング処理部Ｆ３１０が、同乗希望ユーザからのリクエスト情報を受け取ったときと同様の手順で、同乗ユーザ候補の移動スケジュール情報テーブルを生成し、生成された移動スケジュール情報テーブルを移動スケジュール管理データベースＤ３２０に登録する。そして、マッチング処理部Ｆ３１０は、同乗ユーザ候補の移動スケジュール情報テーブルに基づくマッチング処理を行う。

相乗り車両の台数が所定の上限値を上回るときに、上記した方法で台数調整処理及びマッチング処理が行われると、相乗り車両の台数を減らすことができるとともに、運転希望グループの人数を減らすことができるため、自身の運転する相乗り車両に同乗希望ユーザを１人も同乗させることができない運転希望ユーザの人数を減らすことができる。

（処理の流れ）
ここで、本実施形態に係るサーバ装置３００の処理の流れについて図１３に基づいて説明する。図１３は、本実施形態に係るサーバ装置３００が実行する処理の流れを示すフローである。図１３中において、前述の図１１と同様の処理ついては同様の符号を付している。

図１３においては、ステップＳ１０６で否定判定がなされた場合に、サーバ装置３００が、ステップＳ２０１〜ステップＳ２０５の処理を実行する。先ず、ステップＳ２０１では、サーバ装置３００は、相乗り車両１０の台数が所定の上限値を上回っているかを判別する。具体的には、サーバ装置３００は、移動スケジュール管理データベースＤ３２０を参照して、同一の時間帯における移動を希望している同乗希望ユーザであって、且つ同一の経路上に乗車地及び降車地が含まれる同乗希望ユーザを全て抽出することで、それら同乗希望ユーザ（同乗希望グループ）の人数Ｈｃを取得する。また、サーバ装置３００は、走行スケジュール管理データベースＤ３１０を参照して、上記時間帯に上記経路を含む走行予定経路を走行予定の相乗り車両１０を全て抽出し、抽出された相乗り車両１０に同乗させることができるユーザの最小人数（以下、「最小同乗人数」と記す場合もある。）Ｈｃｍｉｎを取得する。ここでいう「最小同乗人数Ｈｃｍｉｎ」は、各相乗り車両１０に同乗希望ユーザを１人ずつ同乗させると仮定した場合に、抽出された相乗り車両１０の全車で同乗させることができる同乗希望ユーザの総数であり、抽出された相乗り車両１０の台数と同数である。そして、サーバ装置３００は、上記同乗希望グループの人数Ｈｃに比して上記最小同乗人数Ｈｃｍｉｎの方が多ければ、相乗り車両１０の台数が所定の上限値を上回っていると判定する一方で、上記同乗希望グループの人数Ｈｃに比して上記最小同乗人数Ｈｃｍｉｎが同数以下であれば、相乗り車両１０の台数が所定の上限値を上回っていないと判定する。

上記ステップＳ２０１で否定判定がなされた場合には、サーバ装置３００は、ステップＳ２０２〜ステップＳ２０５をスキップして、ステップＳ１１１へ進む。一方、上記ステップＳ２０１において肯定判定がなされた場合には、サーバ装置３００は、ステップＳ２０２〜ステップＳ２０５において、相乗り車両１０を減少させるための台数調整処理を実行する。

ステップＳ２０２では、サーバ装置３００は、同乗ユーザ候補を抽出する。具体的には、サーバ装置３００は、前述の図１２の説明で述べたように、運転希望グループに含まれる運転希望ユーザのうち、自身の出発地及び目的地が他の運転希望ユーザの運転する相乗り車両１０の走行予定経路に含まれる運転希望ユーザを、同乗ユーザ候補として抽出する。

ステップＳ２０３では、サーバ装置３００は、上記ステップＳ２０２で抽出された同乗
ユーザ候補に紐付けられている会員情報テーブルへアクセスすることで、連絡先フィールドに登録されている、ユーザ端末２００の電子メールアドレスを抽出する。そして、サーバ装置３００は、抽出された電子メールアドレス宛に、第２情報を送信する。ここでいう第２情報は、前述したように、他の運転希望ユーザが運転する相乗り車両１０に同乗することについて承諾を求める情報、言い換えると、同乗ユーザ候補が自身の運転する車両による移動形態から他の運転希望ユーザの運転する相乗り車両１０へ同乗する移動形態へ変更することについて承諾を求める情報である。

上記第２情報に応答する形で同乗ユーザ候補のユーザ端末２００から送信される情報を、サーバ装置３００の通信部３０４が受信すると、サーバ装置３００は、受信した情報が承諾情報（他の運転希望ユーザの運転する相乗り車両１０に同乗することについて承諾する情報）であるかを判別する（ステップＳ２０４）。

上記ステップＳ２０４で否定判定がなされた場合は、サーバ装置３００は、ステップＳ２０２に戻り、上記同乗ユーザ候補とは異なる運転希望ユーザを新たな同乗ユーザ候補として抽出し直す。一方、上記ステップＳ２０４で肯定判定がなされた場合は、サーバ装置３００は、ステップＳ２０５へ進み、上記同乗ユーザ候補のカテゴリを運転希望ユーザから同乗希望ユーザへ変更する。具体的には、サーバ装置３００は、先ず、同乗ユーザ候補の走行スケジュール情報テーブルに基づいて、同乗ユーザ候補の移動スケジュール情報テーブルを生成し、生成された移動スケジュール情報テーブルを移動スケジュール管理データベースＤ３２０に登録する。その際の移動スケジュール情報テーブルの生成方法及び登録方法は、上記ステップＳ１０５と同様である。

以上述べたフローによれば、相乗り車両の台数が所定の下限値を下回るときには、相乗り車両の台数増加を促進させるための台数調整処理が行われる一方で、相乗り車両の台数が所定の上限値を上回るときには、相乗り車両の台数減少を促進させるための台数調整処理が行われることになる。これにより、相乗り車両の台数が所定の下限値を下回るときには、相乗り車両の台数を増やすことができるとともに、同乗希望グループの人数を減らすことができる一方で、相乗り車両の台数が所定の上限値を上回るときには、相乗り車両の台数を減らすことができるとともに、同乗希望グループの人数を増やすことができる。その結果、相乗り車両の過不足を抑制することが可能となる。

＜第２実施形態の変形例＞
なお、相乗り車両の台数減少を促進するための台数調整処理において、サーバ装置３００から同乗ユーザ候補のユーザ端末２００へ第２情報が送信される際に、他の運転希望ユーザの運転する相乗り車両に同乗することに承諾したと場合に該同乗ユーザ候補に供与されるインセンティブに関する情報を送信するようにしてもよい。ここでいう「インセンティブ」とは、例えば、所定のサービスに使用可能なポイント、割引券や商品券の電子データ、電子マネー等である。斯様なインセンティブに関する情報が第２情報とともに同乗ユーザ候補に提供されることで、他の運転希望ユーザの運転する相乗り車両に同乗することについて同乗ユーザ候補が承諾する意欲を喚起することができる。それにより、相乗り車両が過多になることを抑制し易くなる。

＜その他＞
なお、上記した実施形態はあくまでも一例であって、本発明はその要旨を逸脱しない範囲内で適宜変更して実施し得る。

また、本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。さらに、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。若しくは、異なる装置が行う
ものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成で実現するかは柔軟に変更可能である。

また、本発明は、上記の各実施形態及び各変形例で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、データやプログラム等の情報を電気的、磁気的、光学的、機械的、又は化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体であり、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤディスク・ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、ＳＳＤ（Solid State Drive）等の媒体
である。

１：ライドシェアシステム
１０：相乗り車両
２００Ａ：第１ユーザ端末
２００Ｂ：第２ユーザ端末
３００：サーバ装置
３０１：プロセッサ

Claims (8)

1. 複数のユーザが同一の車両に相乗りする形態において、相乗りに利用される車両に非運転者として同乗することを希望するユーザである同乗希望ユーザの人数と、相乗りに利用される車両の台数と、の調整を図る情報処理装置であって、
   相乗りに利用される車両の台数が所定の下限値を下回るときに、自身の運転する車両に前記同乗希望ユーザを同乗させることが可能なユーザの候補である運転ユーザ候補を抽出することと、
   前記運転ユーザ候補の使用する端末に対し、該運転ユーザ候補の運転する車両に前記同乗希望ユーザを同乗させることについて承諾を求める情報である第１情報を送信することと、
   を実行する、制御部を備える、
   情報処理装置。
2. 前記制御部は、前記同乗希望ユーザの中から前記運転ユーザ候補を抽出する、
   請求項１に記載の情報処理装置。
3. 前記制御部は、前記第１情報を前記運転ユーザ候補の使用する端末へ送信する際に、該運転ユーザ候補の運転する車両に前記同乗希望ユーザを同乗させると仮定した場合に該運転ユーザ候補に供与されるインセンティブに関する情報も送信する、
   請求項１又は２に記載の情報処理装置。
4. 前記制御部は、
   相乗りに利用される車両の台数が所定の上限値を上回るときに、他のユーザが運転する車両に同乗することが可能なユーザの候補である同乗ユーザ候補を抽出することと、
   前記同乗ユーザ候補の使用する端末に対し、他のユーザの運転する車両に同乗することについて承諾を求める情報である第２情報を送信することと、
   を実行する、
   請求項１から３の何れか１項に記載の情報処理装置。
5. 前記制御部は、相乗りに利用される車両の運転を希望しているユーザである運転希望ユーザの中から、前記同乗ユーザ候補を抽出する、
   請求項４に記載の情報処理装置。
6. 前記制御部は、前記第２情報を前記同乗ユーザ候補の使用する端末へ送信する際に、他のユーザが運転する車両に該同乗ユーザ候補が同乗すると仮定した場合に該同乗ユーザ候補に供与されるインセンティブに関する情報も送信する、
   請求項４又は５に記載の情報処理装置。
7. 複数のユーザが同一の車両に相乗りする形態において、相乗りに利用可能な車両に非運転者として同乗することを希望するユーザである同乗希望ユーザの人数と、相乗りに利用される車両の台数と、の調整を図る情報処理方法であって、
   コンピュータが、
   相乗りに利用される車両の台数が所定の下限値を下回るときに、自身の運転する車両に前記同乗希望ユーザを同乗させることが可能なユーザの候補である運転ユーザ候補を抽出するステップと、
   前記運転ユーザ候補の使用する端末に対し、該運転ユーザ候補の運転する車両に前記同乗希望ユーザを同乗させることについて承諾を求める情報である第１情報を送信するステップと、
   を実行する、情報処理方法。
8. 複数のユーザが同一の車両に相乗りする形態において、相乗りに利用可能な車両に非運転者として同乗することを希望するユーザである同乗希望ユーザの人数と、相乗りに利用される車両の台数と、の調整を図る情報処理プログラムであって、
   コンピュータに、
   相乗りに利用される車両の台数が所定の下限値を下回るときに、自身の運転する車両に前記同乗希望ユーザを同乗させることが可能なユーザの候補である運転ユーザ候補を抽出するステップと、
   前記運転ユーザ候補の使用する端末に対し、該運転ユーザ候補の運転する車両に前記同乗希望ユーザを同乗させることについて承諾を求める情報である第１情報を送信するステップと、
   を実行させる、情報処理プログラム。

Images