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

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）パネル
等である。入力部２０５は、例えば、文字等の記号を入力可能なタッチパネルや押しボタン、音声を入力可能なマイクロフォン、動画像や静止画像を撮像可能なカメラ等を含む。位置取得部２０６は、ユーザ端末２００の現在位置を取得する機器であり、典型的にはＧＰＳ受信器等を含んで構成される。通信部２０７は、例えば、移動体通信サービス（携帯電話等の電話通信網、ＷｉＦｉ等の無線通信）を利用してネットワークＮ１にアクセスし、サーバ装置３００等とデータ通信をするための通信回路である。

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

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

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

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

図５に示す走行スケジュール情報テーブルは、車両ＩＤ、運転ユーザＩＤ、出発地、出発予定時間、目的地、到着予定時間、相乗り可能人数、通勤経路、ステータス、及び残数等の各フィールドを有する。車両ＩＤフィールドには、各相乗り車両１０を識別するための情報である車両ＩＤが登録される。ここでいう車両ＩＤは、各相乗り車両１０の運転ユーザがライドシェアサービスの会員登録を行う際に、後述のユーザＩＤとともに付与される情報であり、個々の相乗り車両１０を識別するための情報である。運転ユーザＩＤフィールドには、各相乗り車両１０の運転ユーザを識別するための情報であるユーザＩＤが登録される。ユーザＩＤは、相乗り車両１０の運転ユーザがライドシェアサービスの会員登録を行う際に付与される情報である。出発地フィールドには、各相乗り車両１０の出発地（例えば、自宅又は職場）を示す情報が登録される。出発予定時間フィールドには、運転ユーザが自身の運転する相乗り車両１０で上記出発地を出発する予定時間を示す情報が登録される。目的地フィールドには、運転ユーザが相乗り車両１０で向かう目的地（例えば、職場又は自宅）を示す情報が登録される。到着予定時間フィールドには、運転ユーザが自身の運転する相乗り車両１０で上記目的地に到着する予定時間を示す情報が登録される。相乗り可能人数フィールドには、各相乗り車両１０に相乗り可能な同乗ユーザ数を示す情報が登録される。通勤経路フィールドには、運転ユーザの出発地から目的地までに相乗り車両１０が通行可能な経路であって、且つ前記到着予定時間までに前記目的地へ到着することができると予測される経路を示す情報が登録される。ステータスフィールドには、各相乗り相乗り車両１０の予約状況を示す情報が登録される。例えば、既に予約が確定している相乗り車両１０については「予約済」と登録される。また、運転ユーザと同乗ユーザとのマッチング処理が実行中である相乗り車両１０については「マッチング中」と登録される。残数フィールドには、各相乗り車両１０において残っている座席数（各相乗り車両１０への相乗りが確定している同乗ユーザ数を、各相乗り車両１０の相乗り可能人数からを差し引いた数）が登録される。例えば、相乗り可能人数が３人の相乗り車両１０において、該相乗り車両１０への相乗りが確定している同乗ユーザ数が１人であれば、残数フィールドに「２」が登録される。

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

図６に示す移動スケジュール情報テーブルは、同乗ユーザＩＤ、乗車地、乗車希望時間、降車地、及び降車希望時間等の各フィールドを有する。同乗ユーザＩＤフィールドには、各同乗ユーザを識別するためのユーザＩＤが登録される。同乗ユーザのユーザＩＤは、前述した運転ユーザＩＤと同様に、同乗ユーザがライドシェアサービスの会員登録を行う際に付与される情報である。乗車地フィールドには、各同乗ユーザが相乗り車両１０への乗車を希望する場所（乗車希望場所）を示す情報が登録される。乗車希望時間フィールドには、各同乗ユーザが上記乗車希望場所において相乗り車両１０への乗車を希望する時間を示す情報が登録される。降車地フィールドには、各同乗者が相乗り車両１０からの降車を希望する場所（降車希望場所）を示す情報が登録される。降車希望時間フィールドには、各同乗ユーザが上記降車希望場所において相乗り車両１０からの降車を希望する時間を示す情報が登録される。

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

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

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

利用傾向管理データベースＤ３４０は、各運転ユーザによる相乗りの利用傾向を示す情報が格納されており、そこでは過去に運転ユーザとして相乗りを利用したユーザの識別情報と利用傾向情報との紐付けが行われている。ここで、利用傾向管理データベースＤ３４
０に格納される利用傾向情報の一構成例について、図９に基づいて説明する。図９は、利用傾向情報のテーブル構成を例示する図である。なお、利用傾向情報テーブルに登録される情報は、図９に示す例に限られず、適宜フィールドの追加、変更、削除が可能である。

図９に示す利用傾向情報テーブルは、ユーザＩＤ、通勤経路、走行時間帯、走行回数、承諾率、応答時間等の各フィールドを有する。ユーザＩＤフィールドには、過去に運転ユーザとして相乗りを利用したユーザのユーザＩＤが登録される。ユーザＩＤは、前述したように、各ユーザがライドシェアサービスの会員登録を行った際に付与されるユーザＩＤである。通勤経路フィールドには、各ユーザの通勤経路を示す情報が登録される。走行時間帯フィールドには、各ユーザの運転する相乗り車両１０が通勤経路を走行し得る時間帯を所定時間単位（図９に示す例では、１時間単位）で区切った情報が登録される。走行回数フィールドには、走行時間帯フィールドに登録された各時間帯において、ユーザの運転する相乗り車両１０が過去に通勤経路を走行した回数を示す情報が登録される。例えば、走行時間帯フィールドの０６時００分から０７時００分までの時間帯に対応する走行回数フィールドには、「０」が登録されている。これは、０６時００分から０７時００分までの時間帯において、ユーザの運転する相乗り車両１０が過去に通勤経路を走行した回数が「０回」であることを示している。また、走行時間帯フィールドの０７時００分から０８時００分までの時間帯に対応する走行回数フィールドには、「１１」が登録されている。これは、０７時００分から０８時００分までの時間帯において、ユーザの運転する相乗り車両１０が過去に通勤経路を走行した回数が「１１回」であることを示している。なお、走行回数フィールドに登録される回数は、ユーザがライドシェアサービスの会員登録を行ってから現時点までの期間における走行回数が登録されてもよく、直近の所定期間（例えば、数ヶ月前から現時点までの期間）における走行回数が登録されてもよい。承諾率フィールドには、ユーザが過去に前述の意思確認に対して肯定的な応答をした割合（意思確認の回数に対して肯定的な応答をした回数の比率、以下「承諾率」と記す場合もある。）を示す情報が登録される。例えば、ユーザに対して過去に行われた意思確認の回数が１０回であって、そのうちユーザが肯定的な応答をした回数が７回であれば、承諾率フィールドに「７０％」が登録される。また、応答時間フィールドには、ユーザが過去に意思確認に応答した際の応答時間（平均値）を示す情報が登録される。なお、承諾率およびまたは応答時間は、走行時間帯毎に分けて登録されてもよい。また、利用履歴情報テーブルは、曜日毎およびまたは天候毎に分けて生成されてもよい。

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

次に、再マッチング処理部Ｆ３２０は、マッチング処理部Ｆ３１０による運転ユーザと同乗ユーザとのマッチングが完了した後に、運転ユーザからのキャンセル等によって同乗ユーザと相乗りする運転ユーザを決定し直す必要（以下、「再マッチング要求」と記す場合もある。）が生じた場合に、再マッチング処理を行う。その際、再マッチング要求が発生してから同乗ユーザの乗車希望時間までの残り時間（以下、「猶予時間」と記す場合もある。）が十分に長い場合（例えば、同乗ユーザの相乗り希望日の前日以前に発生した場合等）、再マッチング処理部Ｆ３２０は、前述のマッチング処理部Ｆ３１０と同様の方法で、同乗ユーザと相乗りする運転ユーザを決定する（通常マッチング処理）。一方、上記猶予時間が短い場合（例えば、再マッチング要求が同乗ユーザの相乗り希望日の当日や同乗希望時間の直前に発生した場合等）、再マッチング処理部Ｆ３２０は、利用傾向管理データベースＤ３４０に登録されている各ユーザの利用傾向情報に基づいて、同乗ユーザと相乗りする運転ユーザを決定する（緊急マッチング処理）。

緊急マッチング処理では、再マッチング処理部Ｆ３２０は、先ず、走行スケジュール管理データベースＤ３１０に格納されている各運転ユーザの走行スケジュール情報テーブルを参照して、同乗ユーザの移動スケジュールに適合する走行スケジュールが登録されている走行情報テーブルのうち、残数フィールドに「１」以上の数が登録されている走行情報テーブルを特定する。そして、再マッチング処理部Ｆ３２０は、斯様にして特定された走行スケジュール情報テーブルに紐付けられている運転ユーザを、第１の運転ユーザ候補として抽出する。次に、再マッチング処理部Ｆ３２０は、利用傾向管理データベースＤ３４０に格納されている利用傾向情報テーブルを参照して、運転ユーザ候補の絞り込みを行う。具体的には、再マッチング処理部Ｆ３２０は、上記第１の運転ユーザ候補に対応する利用傾向情報テーブルの応答時間フィールドにアクセスして、上記第１の運転ユーザ候補のうち応答時間が上記猶予時間より短いユーザを抽出する。そして、再マッチング処理部Ｆ３２０は、斯様にして上記第１の運転ユーザ候補の中から抽出されたユーザを、最終的な
運転ユーザ候補に設定する。なお、上記第１の運転ユーザ候補の中に応答時間が上記猶予時間より短いユーザが多数含まれる場合は、応答時間が短い順における上位所定数（例えば、３人から５人）のユーザを、最終的な運転ユーザ候補に設定してもよい。斯様にして最終的な運転ユーザ候補が抽出されると、再マッチング処理部Ｆ３２０は、抽出された運転ユーザ候補のユーザ端末２００に対して、同乗ユーザを相乗りさせるための条件（例えば、同乗ユーザの乗車希望場所、同乗ユーザの乗車希望時間、同乗ユーザの降車希望場所、及び同乗ユーザの降車希望時間等）を送信することで、同乗ユーザを自身の運転する相乗り車両１０へ相乗りさせる意思があるかの確認を行う。そして、同乗ユーザを自身の運転する相乗り車両１０へ相乗りさせることを承諾する情報が何れかの運転ユーザ候補のユーザ端末２００から返信されてくると、その運転ユーザ候補を、同乗ユーザを相乗りさせる運転ユーザに決定する。

ここで、同乗ユーザの移動スケジュールに適合する走行スケジュールが登録されている走行情報テーブルが走行スケジュール管理データベースＤ３１０に格納されていない場合（上記第１の運転ユーザ候補に該当するユーザが存在しない場合）も想定し得る。斯様な場合に、再マッチング処理部Ｆ３２０は、利用傾向管理データベースＤ３４０にアクセスして、同乗ユーザの乗車希望場所及び降車希望場所を経由する通勤経路が通勤経路フィールドに登録されている利用傾向情報テーブルを特定する。そして、再マッチング処理部Ｆ３２０は、斯様にして特定された利用傾向情報テーブルに紐付けられているユーザを、第２の運転ユーザ候補として抽出する。次に、再マッチング処理部Ｆ３２０は、上記第２の運転ユーザ候補のそれぞれの評価値Ｅｖを算出する。斯様な評価値Ｅｖは、同乗ユーザの移動希望時間帯に対応する走行時間帯における走行回数、承諾率、及び応答時間等のうち、少なくとも応答時間に基づいて算出される。本例においては、評価値Ｅｖは、以下の式（１）に従って算出される。
Ｅｖ＝Ａ_１＋Ａ_２＋Ａ_３・・・（１）

上記式（１）中のＡ_１は、同乗ユーザの移動希望時間帯に対応する走行時間帯における走行回数に基づいて設定される第１の係数である。第１の係数Ａ_１は、例えば、図１０に示すような基準で設定される。図１０に示す例では、第１の係数Ａ_１は、同乗ユーザの移動希望時間帯に対応する走行時間帯における走行回数が５１回以上であれば「５」に設定され、上記走行回数が４１回以上５０回以下であれば「４」に設定され、上記走行回数が３１回以上４０回以下であれば「３」に設定され、上記走行回数が２１回以上３０回以下であれば「２」に設定され、上記走行回数が１１回以上２０回以下であれば「１」に設定され、上記走行回数が１０回未満であれば「０」に設定される。なお、図１０に示す基準は、あくまで一例であって、適宜変更し得る。

上記式（１）中のＡ_２は、承諾率に基づいて設定される第２の係数である。第２の係数Ａ_２は、例えば、図１１に示すような基準で設定される。図１１に示す例では、第２の係数Ａ_２は、承諾率が９１％以上であれば「５」に設定され、承諾率が７１％以上９０％以下であれば「４」に設定され、承諾率が５１％以上７０％以下であれば「３」に設定され、承諾率が３１％以上５０％以下であれば「２」に設定され、承諾率が１１％以上３０％以下であれば「１」に設定され、承諾率が１０％未満であれば「０」に設定される。なお、図１１に示す基準は、あくまで一例であって、適宜変更し得る。

上記式（１）中のＡ_３は、応答時間に基づいて設定される第３の係数である。第３の係数Ａ_３は、例えば、図１２に示すような基準で設定される。図１２に示す例では、第３の係数Ａ_３は、応答時間が１５分以内であれば「５」に設定され、応答時間が１６分以上３０分以下であれば「４」に設定され、応答時間が３１分以上６０分以下であれば「３」に設定され、応答時間が６１分以上１２０分以下であれば「２」に設定され、応答時間が１２１分以上１８０分以下であれば「１」に設定され、応答時間が１８１分以上であれば「
０」に設定される。なお、図１２示す基準は、あくまで一例であって、適宜に変更し得る。

上記式（１）に従って第２の運転ユーザ候補のそれぞれの評価値Ｅｖが算出されると、再マッチング処理部Ｆ３２０は、第２の運転ユーザ候補のうち、評価値Ｅｖの高い順における上位所定数（例えば、３人から５人）のユーザを、最終的な運転ユーザ候補に設定する。斯様にして最終的な運転ユーザ候補が抽出されると、再マッチング処理部Ｆ３２０は、抽出された運転ユーザ候補のユーザ端末２００に対して、同乗ユーザを相乗りさせるための条件を送信することで、同乗ユーザを自身の運転する相乗り車両１０へ相乗りさせる意思があるかの確認を行う。そして、同乗ユーザを自身の運転する相乗り車両１０へ相乗りさせることを承諾する情報が運転ユーザ候補の何れかから返信されてくると、その運転ユーザ候補を、同乗ユーザを相乗りさせる運転ユーザに決定する。

なお、同乗ユーザを自身の運転する相乗り車両１０へ相乗りさせることを承諾する情報を、上記した最終的な運転ユーザ候補の何れからも得られなかった場合は、再マッチング処理部Ｆ３２０は、第２の運転ユーザ候補のうち、評価値Ｅｖの高い順における上位所定数のユーザに次いで評価値Ｅｖの高いユーザに対して、意思確認を行えばよい。

（処理の流れ）
本実施形態に係るサーバ装置３００の処理の流れについて図１３に基づいて説明する。図１３は、再マッチング要求が発生したことをトリガにしてサーバ装置３００で行われる処理（再マッチング処理）を示すフローチャートである。

図１３では、マッチングが完了している運転ユーザからのキャンセル等によって再マッチング要求が発生すると、サーバ装置３００の再マッチング処理部Ｆ３２０が、猶予時間が所定時間未満であるかを判別する（ステップＳ１０１）。ここでいう「猶予時間」は、前述したように、再マッチング要求が発生した時点から、再マッチング処理の対象となる同乗ユーザの乗車希望時間までの残り時間である。また、「所定時間」は、通常マッチング処理によって前記同乗ユーザと相乗りする運転ユーザを決定するために必要な最低の時間、又はその時間にマージンを加算した時間である。

前記猶予時間が前記所定時間以上であれば（ステップＳ１０１で否定判定）、再マッチング処理部Ｆ３２０は、前述の通常マッチング処理を行うことで、前記同乗ユーザと相乗りする運転ユーザを決定し直す（ステップＳ１０９）。

前記猶予時間が前記所定時間未満であれば（ステップＳ１０１で肯定判定）、再マッチング処理部Ｆ３２０は、前述したように、緊急マッチング処理を行う。具体的には、再マッチング処理部Ｆ３２０は、先ず、走行スケジュール管理データベースＤ３１０へアクセスすることで、同乗ユーザの移動スケジュールに適合する走行スケジュールが登録されており且つ残数フィールドに「１」以上の数が登録されている走行情報テーブルが、前記走行スケジュール管理データベースＤ３１０に格納されているかを判別する。すなわち、再マッチング処理部Ｆ３２０は、前述した第１の運転ユーザ候補に該当する運転ユーザがいかを判別する（ステップＳ１０２）。その際、同乗ユーザの移動スケジュールに適合する走行スケジュールが登録されており且つ残数フィールドに「１」以上の数が登録されている走行情報テーブルが、走行スケジュール管理データベースＤ３１０に格納されていれば（ステップＳ１０２で肯定判定）、再マッチング処理部Ｆ３２０は、該当する走行情報テーブルに紐付けられている運転ユーザを、第１の運転ユーザ候補として抽出する。そして、再マッチング処理部Ｆ３２０は、前記第１の運転ユーザ候補の中から最終的な運転ユーザ候補を抽出する（ステップＳ１０３）。具体的には、再マッチング処理部Ｆ３２０は、前述したように、利用傾向管理データベースＤ３４０へアクセスして、前記第１の運転ユ
ーザ候補のそれぞれに対応する利用傾向情報テーブルの応答時間フィールドを参照する。そして、再マッチング処理部Ｆ３２０は、前記第１の運転ユーザ候補のうち、利用傾向情報テーブルの応答時間フィールドに登録されている応答時間が前述の猶予時間より短いユーザを、最終的な運転ユーザ候補として抽出する。

再マッチング処理部Ｆ３２０は、前記ステップＳ１０３で抽出された最終的な運転ユーザ候補に対して、前記同乗ユーザと相乗りする意思があるかの問い合わせ（意思確認）を行う（ステップＳ１０４）。すなわち、再マッチング処理部Ｆ３２０は、前記最終的な運転ユーザ候補のユーザ端末２００に対して、前記同乗ユーザを相乗りさせるための条件を送信する。斯様な意思確認に対し、前記同乗ユーザを自身の運転する相乗り車両１０へ相乗りさせることを承諾する情報が何れかの運転ユーザ候補のユーザ端末２００から返信されてくると、その運転ユーザ候補を、前記同乗ユーザを相乗りさせる運転ユーザに決定する（ステップＳ１０５）。

また、前記ステップＳ１０２において否定判定された場合は、再マッチング処理部Ｆ３２０は、利用傾向管理データベースＤ３４０に格納されている利用傾向情報テーブルに基づいて、前述の第２の運転ユーザ候補に該当するユーザを抽出する（ステップＳ１０６）。具体的には、再マッチング処理部Ｆ３２０は、同乗ユーザの乗車希望場所及び降車希望場所を経由する通勤経路が通勤経路フィールドに登録されている利用傾向情報テーブルを特定する。そして、再マッチング処理部Ｆ３２０は、斯様にして特定された利用傾向情報テーブルに紐付けられているユーザを、第２の運転ユーザ候補として抽出する。

再マッチング処理部Ｆ３２０は、前記ステップＳ１０６で抽出された第２の運転ユーザ候補のそれぞれの評価値Ｅｖを演算する（ステップＳ１０７）。具体的には、再マッチング処理部Ｆ３２０は、先ず、前記第２の運転ユーザ候補に対応する利用傾向情報テーブルから、前記同乗ユーザの移動希望時間帯に対応する走行時間帯における走行回数、承諾率、及び応答時間を読み出す。次いで、再マッチング処理部Ｆ３２０は、前記走行回数と前述の図１０に示したような基準とに基づいて、第１の係数Ａ_１を設定する。また、再マッチング処理部Ｆ３２０は、前記承諾率と前述の図１１に示したような基準とに基づいて、第２の係数Ａ_２を設定する。さらに、再マッチング処理部Ｆ３２０は、前記応答時間と前述の図１２に示したような基準とに基づいて、第３の係数Ａ_３を設定する。そして、再マッチング処理部Ｆ３２０は、第１の係数Ａ_１、第２の係数Ａ_２、及び第３の係数Ａ_３を、前述の式（１）に代入することで、各第２の運転ユーザ候補の評価値Ｅｖを演算する（Ｅｖ＝Ａ_１＋Ａ_２＋Ａ_３）。

再マッチング処理部Ｆ３２０は、前記ステップＳ１０７で算出された評価値Ｅｖを参照することで、前記ステップＳ１０６で抽出された第２の運転ユーザ候補の中から最終的な運転ユーザ候補を抽出する（ステップＳ１０８）。例えば、再マッチング処理部Ｆ３２０は、前記第２の運転ユーザ候補のうち、前記評価値Ｅｖの高い順における上位所定数のユーザを、最終的な運転ユーザ候補に設定する。斯様にして最終的な運転ユーザ候補が抽出されると、再マッチング処理部Ｆ３２０は、ステップＳ１０４及びステップＳ１０５の処理を順次実行することで、前記同乗ユーザと相乗りする運転ユーザを決定する。

図１３に示したような手順で再マッチング処理が行われると、運転ユーザと同乗ユーザとのマッチングが完了した後において、同乗ユーザの同乗希望時間の直前に運転ユーザからのキャンセルが発生した場合のように、比較的短い時間で同乗ユーザと相乗りする運転ユーザを決定し直す必要がある場合に、各ユーザの利用傾向情報に基づいて運転ユーザ候補を抽出することで、同乗ユーザと相乗りする運転ユーザを効率的に決定することができる。これにより、同乗ユーザの利便性が低下したり、同乗ユーザのライドシェア利用意欲が低減したりすることを抑制することができる。その結果、通勤時におけるライドシェア
の利用を促進させることができる。

なお、第２の運転ユーザ候補の評価値は、利用傾向情報テーブルに予め登録されるようにしてもよい。例えば、利用傾向情報テーブルには、前述の図９に示したフィールドに加え、走行時間帯フィールドに登録された各時間帯毎の評価値を登録するためのフィールドを設けてもよい。そして、利用傾向情報テーブルの走行回数フィールド、承諾率フィールド、又は応答時間フィールドに登録されるデータが更新される都度、評価値が算出されるとともに評価値フィールドに登録されるデータが更新されるようにしてもよい。

＜変形例＞
前述の実施形態では、通勤時にライドシェアを利用する場合を例に挙げたが、通勤以外の移動においてライドシェアを利用する場合も本発明を適用し得る。要するに、比較的短時間で同乗ユーザと相乗りする運転ユーザを決定する必要がある場合であれば、各ユーザの利用傾向情報に基づいて運転ユーザ候補を抽出することで、同乗ユーザと相乗りする運転ユーザを効率的に決定することができる。

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

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

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

１０：相乗り車両
２００Ａ：第１ユーザ端末
２００Ｂ：第２ユーザ端末
３００：サーバ装置
３０１：プロセッサ
３０３：補助記憶部
Ｆ３２０：再マッチング処理部
Ｄ３４０：利用傾向管理データベース

Claims (6)

1. 複数のユーザが同一の車両に相乗りする形態において、相乗りに使用される車両を運転するユーザである運転ユーザと非運転者として車両への相乗りを希望するユーザである同乗ユーザとの組合せを決定する情報処理装置であって、
   １以上の前記運転ユーザによる相乗りの利用傾向に関する情報である利用傾向情報を記憶する記憶部を備えるとともに、
   前記同乗ユーザの移動希望区間及び移動希望時間帯を含む同乗条件情報を取得することと、
   前記同乗条件情報と前記利用傾向情報とに基づいて、前記同乗ユーザと相乗りすることが可能な前記運転ユーザの候補である運転ユーザ候補を抽出することと、
   前記運転ユーザ候補に対して前記同乗ユーザと相乗りする意思を問い合わせ、該問い合わせに対する応答に基づいて前記同乗ユーザと相乗りする前記運転ユーザを決定することと、を実行する制御部を備え、
   前記利用傾向情報は、１以上の前記運転ユーザが過去に前記問い合わせに応答した際の応答時間に関する情報を含み、
   前記制御部は、前記組合せを決定する時から前記移動希望時間帯の開始時間までの期間が所定時間未満であるか否かを判定し、前記期間が所定時間未満であると判定される場合に、前記応答時間に関する情報を利用して前記運転ユーザ候補を抽出する、
   情報処理装置。
2. 前記制御部は、前記同乗条件情報と前記利用傾向情報に基づいて１以上の前記運転ユーザの評価値を算出し、前記評価値の低い運転ユーザよりも前記評価値の高い運転ユーザを優先的に前記運転ユーザ候補として抽出するものであって、前記応答時間が長い運転ユーザよりも前記応答時間が短い運転ユーザの前記評価値を高く算出する、
   請求項１に記載の情報処理装置。
3. 前記利用傾向情報は、時間帯毎の１以上の前記運転ユーザによる相乗りの利用回数に関する情報を更に含み、
   前記制御部は、前記移動希望時間帯における前記利用回数が少ない運転ユーザよりも前記移動希望時間帯における前記利用回数が多い運転ユーザの前記評価値を高く算出する、請求項２に記載の情報処理装置。
4. 前記利用傾向情報は、１以上の前記運転ユーザが過去に前記問い合わせに対して肯定的な応答をした割合である承諾率に関する情報を更に含み、
   前記制御部は、前記承諾率が低い運転ユーザよりも前記承諾率が高い運転ユーザの前記評価値を高く算出する、
   請求項２又は３に記載の情報処理装置。
5. 複数のユーザが同一の車両に相乗りする形態において、相乗りに使用される車両を運転するユーザである運転ユーザと非運転者として車両への乗車を希望するユーザである同乗ユーザとの組合せを決定する情報処理方法であって、
   １以上の前記運転ユーザによる相乗りの利用傾向に関する情報である利用傾向情報を記憶するための記憶部を備えるコンピュータが、
   前記同乗ユーザの移動希望区間及び移動希望時間帯を含む同乗条件情報を取得するステップと、
   前記同乗条件情報と前記利用傾向情報とに基づいて、前記同乗ユーザと相乗りすることが可能な前記運転ユーザの候補である運転ユーザ候補を抽出するステップと、
   前記運転ユーザ候補に対して前記同乗ユーザと相乗りする意思を問い合わせ、該問い合わせに対する応答に基づいて前記同乗ユーザと相乗りする前記運転ユーザを決定するステップと、
   を実行する情報処理方法であり、
   前記利用傾向情報は、１以上の前記運転ユーザが過去に前記問い合わせに応答した際の応答時間に関する情報を含み、
   前記運転ユーザ候補を抽出するステップでは、前記コンピュータが、前記組合せを決定する時から前記移動希望時間帯の開始時間までの期間が所定時間未満であるか否かを判定し、前記期間が所定時間未満であると判定される場合に、前記応答時間に関する情報を利用して前記運転ユーザ候補を抽出する、
   情報処理方法。
6. 複数のユーザが同一の車両に相乗りする形態において、車両を運転するユーザである運転ユーザと非運転者として車両への乗車を希望するユーザである同乗ユーザとの組合せを決定する情報処理プログラムであって、
   １以上の前記運転ユーザによる相乗りの利用傾向に関する情報である利用傾向情報を記憶するための記憶部を備えるコンピュータに、
   前記同乗ユーザの移動希望区間及び移動希望時間帯を含む同乗条件情報を取得するステップと、
   前記同乗条件情報と前記利用傾向情報とに基づいて、前記同乗ユーザと相乗りすることが可能な前記運転ユーザの候補である運転ユーザ候補を抽出するステップと、
   前記運転ユーザ候補に対して前記同乗ユーザと相乗りする意思を問い合わせ、該問い合わせに対する応答に基づいて前記同乗ユーザと相乗りする前記運転ユーザを決定するステップと、
   を実行させる情報処理プログラムであり、
   前記利用傾向情報は、１以上の前記運転ユーザが過去に前記問い合わせに応答した際の応答時間に関する情報を含み、
   前記運転ユーザ候補を抽出させるステップでは、前記コンピュータに、前記組合せを決定する時から前記移動希望時間帯の開始時間までの期間が所定時間未満であるか否かを判定させ、前記期間が所定時間未満であると判定される場合に、前記応答時間に関する情報を利用して前記運転ユーザ候補を抽出させる、
   情報処理プログラム。

Images