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

Abstract

【課題】本発明は、所定の施設へ訪問する車両による混雑を緩和することが可能なライドシェアについての技術を提供する。【解決手段】所定の施設へ車両で訪問する複数の訪問者それぞれについて、該訪問者が該施設へ訪問する際に自身が乗車する予定の第一車両が特定されたスケジュール情報を取得することと、訪問車両の数が第一所定数以上となることがスケジュール情報に基づいて予測される場合、自身の第一車両とは異なる車両に相乗りして所定の施設へ訪問する訪問者の候補である相乗りユーザ候補、及びそのときに該相乗りユーザ候補が相乗り可能な第二車両を算出し、訪問車両の数が第一所定数よりも少なくなるように、算出した相乗りユーザ候補のうちの一部又は全部のユーザと、第二車両と、のマッチングを行うことと、を実行する制御部を備える。【選択図】図８

Description

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

近年、同一の車両に複数のユーザが相乗りする移動形態である、所謂ライドシェアの利用が広がっている。また、このようなライドシェアの利用のために、複数のユーザをマッチングするための技術が開発されている。

また、特許文献１には、各端末の所持者同士が同一の車両に相乗りしているか否かを判定するための技術が開示されている。

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

本発明は、所定の施設へ訪問する車両による混雑を緩和することが可能なライドシェアについての技術を提供することを目的とする。

本発明に係る情報処理装置は、所定の施設へ車両で訪問する複数の訪問者それぞれについて、該訪問者が該施設へ訪問するスケジュールに関する情報であって該訪問者が該施設へ訪問する際に自身が乗車する予定の車両である第一車両が特定されたスケジュール情報を取得することと、前記所定の施設へ所定の時間帯に訪問する複数の訪問車両の数が第一所定数以上となることが、前記複数の訪問者それぞれについての前記スケジュール情報に基づいて予測される場合、前記複数の訪問者のうち自身の前記スケジュール情報において特定されている前記第一車両とは異なる車両に相乗りして前記所定の施設へ前記所定の時間帯に訪問する訪問者の候補である相乗りユーザ候補、及びそのときに該相乗りユーザ候補が相乗り可能な車両であって該相乗りユーザ候補とは異なる訪問者の前記第一車両である第二車両を算出し、前記複数の訪問車両の数が前記第一所定数よりも少なくなるように、算出した前記相乗りユーザ候補のうちの一部又は全部のユーザと、前記第二車両と、のマッチングを行うことと、を実行する制御部を備える。

また、本発明は、情報処理方法の側面から捉えることもできる。例えば、本発明は、所定の施設へ車両で訪問する複数の訪問者それぞれについて、該訪問者が該施設へ訪問するスケジュールに関する情報であって該訪問者が該施設へ訪問する際に自身が乗車する予定の車両である第一車両が特定されたスケジュール情報を取得するステップと、前記所定の施設へ所定の時間帯に訪問する複数の訪問車両の数が第一所定数以上となることが、前記複数の訪問者それぞれについての前記スケジュール情報に基づいて予測される場合、前記複数の訪問者のうち自身の前記スケジュール情報において特定されている前記第一車両とは異なる車両に相乗りして前記所定の施設へ前記所定の時間帯に訪問する訪問者の候補である相乗りユーザ候補、及びそのときに該相乗りユーザ候補が相乗り可能な車両であって該相乗りユーザ候補とは異なる訪問者の前記第一車両である第二車両を算出し、前記複数の訪問車両の数が前記第一所定数よりも少なくなるように、算出した前記相乗りユーザ候補のうちの一部又は全部のユーザと、前記第二車両と、のマッチングを行うステップと、実行する情報処理方法であってもよい。そして、本発明は、このような情報処理方法をコ
ンピュータに実行させるためのプログラムであってもよい。

本発明によれば、所定の施設へ訪問する車両による混雑を緩和することが可能なライドシェアについての技術を提供することができる。

第一の実施形態に係る情報処理システムの概略構成を示す図である。 情報処理システムにおける、ユーザ端末、サーバ装置の各ハードウェア構成を例示する図である。 第一の実施形態に係るサーバ装置の機能構成を例示する図である。 第一の実施形態に係るスケジュール情報テーブルの一例を示す図である。 図４に示す地点の位置関係を表す図である。 交通情報テーブルの一例を示す図である。 交通情報テーブルの一例を示す図である。 交通情報テーブルの一例を示す図である。 マッチング情報テーブルの一例を示す図である。 マッチング情報テーブルの一例を示す図である。 サーバ装置が実行する処理のフローチャートである。 所定の施設周辺における移動経路を例示する第一の図である。 各入場口の通過率と入場予定台数とを表す第一の図である。 第一の実施形態の変形例に係るサーバ装置の機能構成を例示する図である。 各入場口の通過率と入場予定台数とを表す第二の図である。 所定の施設周辺における移動経路を例示する第二の図である。 第二の実施形態に係る情報処理システムの概略構成を示す図である。 第二の実施形態に係る情報処理システムの動作の流れを例示する図である。 第二の実施形態に係るスケジュール情報テーブルの一例を示す図である。 変更されたスケジュール情報テーブルの一例を示す図である。

所定の施設へ所定の時間帯に訪問する車両（訪問車両）の数が第一所定数以上となると、該車両により混雑が発生してしまう。なお、ここでいう混雑には、所定の施設に併設された駐車場の混雑や、該施設または該駐車場に通じる道路の混雑が含まれる。また、上記の第一所定数とは、例えば、所定の施設に併設された駐車場の収容可能台数に基づいて定められる数である。

ここで、第一所定数が駐車場の収容可能台数近くの数に定められた場合を想定すると、訪問車両の数が第一所定数以上となると、車両が駐車場に入場したとしても該車両の円滑な駐車が妨げられる。その結果、駐車場内の混雑や該駐車場に通じる道路の混雑が引き起こされる。

また、駐車場の収容可能台数が比較的多かったとしても、仮に該駐車場への入場口が収容可能台数に対して少なく該入場口が車両の流れのボトルネックになってしまうような場合には、駐車場は比較的空いているにもかかわらず、該駐車場に通じる道路が混雑する事態が生じ得る。この場合、第一所定数は、駐車場への入場のし易さに基づいて定められてもよい。つまり、駐車場の収容可能台数が同じであっても、駐車場へ入場し易い場合は入場し難い場合よりも第一所定数が多くされてもよい。

そこで、本発明に係る情報処理装置は、スケジュール情報を取得することで、訪問車両の数が第一所定数以上となるか否かを予測することができる。そして、訪問車両の数が第一所定数以上となることが予測される場合、制御部が、訪問車両の数が第一所定数よりも少なくなるように、同一の車両に複数のユーザを相乗りさせるライドシェアのマッチングを行う。詳しくは、制御部は、相乗りして所定の施設へ所定の時間帯に訪問する訪問者の候補である相乗りユーザ候補を算出するとともに、そのときに該相乗りユーザ候補が相乗り可能な車両であって該相乗りユーザ候補とは異なる訪問者の第一車両である第二車両を、相乗りユーザ候補毎に算出する。そして、算出した相乗りユーザ候補のうちの一部又は全部のユーザに対して、該ユーザそれぞれに対応する第二車両をマッチングする。

そうすると、第二車両とマッチングされた相乗りユーザ候補は、該第二車両に同乗して所定の施設を訪問することになり、以て、訪問車両の数が削減される。なお、第二車両とマッチングされ該第二車両に同乗して所定の施設を訪問する相乗りユーザ候補を、以下「相乗りユーザ」と称することもある。したがって、訪問車両の数が第一所定数よりも少なくなるようにライドシェアのマッチングが行われることによって、訪問車両により混雑が発生してしまう事態が可及的に抑制される。つまり、本発明に係る情報処理装置は、訪問車両による混雑を緩和することが可能なライドシェアシステムを提供することができる。

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

＜第一の実施形態＞
（システム構成）
図１は、本実施形態に係る情報処理システムの概略構成を示す図である。図１の例では、情報処理システム１は、該システムを利用するユーザそれぞれが有するユーザ端末２００と、サーバ装置３００とを含んで構成される。なお、ユーザ端末２００は、情報処理システム１を利用するユーザの数だけ存在する。

情報処理システム１においては、各ユーザ端末２００およびサーバ装置３００が、ネットワークＮ１によって相互に接続される。ネットワークＮ１には、例えば、インターネット等の世界規模の公衆通信網であるＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）やその他の通信網が採用されてもよい。また、ネットワークＮ１は、携帯電話等の電話通信網、ＷｉＦｉ等の無線通信網を含んでもよい。

情報処理システム１を利用するユーザは、ユーザ端末２００を用いて、自身が所定の施設へ車両で訪問するスケジュールに関する情報（以下、スケジュール情報）を入力することができる。ここで、各ユーザ端末２００には、情報処理システム１を利用するための所定のアプリケーション（以下、「所定のアプリ」と称する場合もある。）がインストールされており、各ユーザはユーザ端末２００にインストールされた所定のアプリを用いてスケジュール情報を入力することができる。ただし、ユーザ端末２００を用いてスケジュール情報を入力する態様に限定する意図はなく、ネットワークＮ１に接続可能な任意の端末（スマートフォン、携帯電話、タブレット端末、個人情報端末、ウェアラブルコンピュータ等）やパーソナルコンピュータ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ、ＰＣ）を用いてスケジュール情報が入力されてもよい。

ここで、上記の所定の施設とは、ユーザが車両で訪問することが可能な任意の施設である。また、上記のスケジュール情報には、所定の施設への訪問スケジュールの他、ユーザが該施設へ訪問する際に自身が乗車する予定の車両（以下、「第一車両」と称する場合もある。）に関する情報が含まれる。

サーバ装置３００は、所定の施設への交通を管理する管理サーバである。ここで、サーバ装置３００は、ユーザ端末２００を用いて入力されたスケジュール情報の登録を受付け、該スケジュール情報と、所定の施設周辺の交通情報（該交通情報には、該施設周辺の現在の交通状況や、所定の施設に併設された駐車場の収容可能台数・現在の駐車台数、該駐車場への入場口に関する情報等が含まれる。）と、に基づいて、所定の施設へ訪問する車両により混雑が発生してしまうか否かを予測する。そして、混雑の発生が予測される場合には、同一の車両に複数のユーザを相乗りさせるライドシェアのマッチングを行う。なお、マッチング処理の詳細については、後述する。

（ハードウェア構成）
図２は、ユーザ端末２００、サーバ装置３００の各ハードウェア構成を例示する図である。

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

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

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

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

通信部３０４は、他の装置と接続し、サーバ装置３００と他の装置との間の通信を制御する。通信部３０４は、例えば、ＬＡＮ（Local Area Network）インターフェースボード、無線通信のための無線通信回路である。ＬＡＮインターフェースボードや無線通信回路は、公衆通信網であるインターネット等のネットワークＮ１に接続される。

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

次に、ユーザ端末２００について説明する。ユーザ端末２００は、例えば、スマートフ
ォン、携帯電話、タブレット端末、個人情報端末、ウェアラブルコンピュータ（スマートウォッチ等）といった小型のコンピュータである。なお、ユーザ端末２００は、公衆通信網であるインターネット等のネットワークＮ１を介してサーバ装置３００に接続される、パーソナルコンピュータ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ、ＰＣ）であってもよい。

ユーザ端末２００は、プロセッサ２０１、主記憶部２０２、補助記憶部２０３、表示部２０４、入力部２０５、通信部２０６を有する。プロセッサ２０１、主記憶部２０２、補助記憶部２０３については、サーバ装置３００のプロセッサ３０１、主記憶部３０２、補助記憶部３０３と同様であるため、説明は省略される。表示部２０４は、例えば、ＬＣＤ（Liquid Crystal Display）、ＥＬ（Electroluminescence）パネル等である。入力部２
０５は、タッチパネル、押しボタン等を含む。また、入力部２０５は、映像や画像の入力を可能にするカメラや、マイクロフォンのような音声の入力部を含むことができる。通信部２０６は、例えば、携帯電話等の電話通信網、ＷｉＦｉ等の無線通信を利用してネットワークＮ１にアクセスし、サーバ装置３００等とデータ通信をするための通信回路である。

（サーバ装置の機能構成）
図３は、サーバ装置３００の機能構成を例示する図である。サーバ装置３００は、機能構成要素として、スケジュール情報取得部Ｆ３１０、交通情報取得部Ｆ３２０、マッチング処理部Ｆ３３０、マッチング情報提供部Ｆ３４０、スケジュール情報データベースＤ３１０、交通情報データベースＤ３２０、マッチング情報データベースＤ３３０を備える。また、マッチング処理部Ｆ３３０は、算出部Ｆ３３１およびマッチング部Ｆ３３２を含む。サーバ装置３００のプロセッサ３０１は、主記憶部３０２上のコンピュータプログラムにより、スケジュール情報取得部Ｆ３１０、交通情報取得部Ｆ３２０、マッチング処理部Ｆ３３０（算出部Ｆ３３１およびマッチング部Ｆ３３２）、マッチング情報提供部Ｆ３４０の処理を実行する。ただし、各機能構成素のいずれか、またはその処理の一部がハードウェア回路により実行されてもよい。

スケジュール情報データベースＤ３１０、交通情報データベースＤ３２０、マッチング情報データベースＤ３３０は、プロセッサ３０１によって実行されるデータベース管理システム（Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ、ＤＢＭＳ）のプログラムが、補助記憶部３０３に記憶されるデータを管理することで構築される。スケジュール情報データベースＤ３１０、交通情報データベースＤ３２０、マッチング情報データベースＤ３３０は、例えば、リレーショナルデータベースである。

なお、サーバ装置３００の各機能構成素のいずれか、またはその処理の一部は、ネットワークＮ１に接続される他のコンピュータにより実行されてもよい。例えば、マッチング処理部Ｆ３３０の処理と、スケジュール情報取得部Ｆ３１０、交通情報取得部Ｆ３２０、マッチング情報提供部Ｆ３４０の処理とは、別々のコンピュータにより実行されてもよい。

スケジュール情報取得部Ｆ３１０は、ユーザからのスケジュール情報を取得する。なお、スケジュール情報には、ユーザが所定の施設へ訪問するスケジュールに関する情報の他、ユーザが該施設へ訪問する際に乗車する予定の第一車両に関する情報が含まれる。そして、スケジュール情報取得部Ｆ３１０は、スケジュール情報をスケジュール情報データベースＤ３１０に登録する。

ここで、スケジュール情報データベースＤ３１０は、スケジュール情報を格納するデータベースである。スケジュール情報データベースＤ３１０は、図４に示すスケジュール情
報テーブルを有する。なお、スケジュール情報テーブルに格納される情報は、図４に示す例に限られず、適宜フィールドの追加、変更、削除が可能である。

図４に示すスケジュール情報テーブルは、ユーザＩＤ、車両識別ＩＤ、出発地、出発予定時刻、目的地、到着予定時刻のフィールドを有する。なお、ユーザＩＤを含むユーザ情報は、個別のテーブルで管理されており、該テーブルには、ユーザの連絡先等が含まれる。連絡先は、例えば、ユーザの携帯番号または電子メールアドレスである。

図４に示す例では、ユーザＳ００１〜Ｓ００４が、各々別の車両（車両１０１〜車両１０４）で目的地ａへ向かうことが予定されている。つまり、スケジュール情報テーブルでは、各ユーザに対する第一車両（車両１０１〜車両１０４）が特定されている。そして、各ユーザの目的地ａへの到着予定時刻は、８：３０−８：５０の範囲に属している。なお、目的地ａは所定の施設が立地している地点とする。また、目的地ａおよびユーザＳ００１〜Ｓ００４の出発地（地点ｂ−ｅ）の位置関係は、例えば図５によって表される。

このようなスケジュール情報は、ユーザがユーザ端末２００にスケジュール情報を入力することで、該情報がユーザ端末２００からサーバ装置３００に送信される。詳しくは、ユーザ端末２００は、スケジュール情報の入力を受付け、入力された情報をサーバ装置３００に送信する機能構成を有している。ユーザ端末２００のプロセッサ２０１は、主記憶部２０２上のコンピュータプログラムにより、入力部２０５から入力されたスケジュール情報を通信部２０６を介してサーバ装置３００に送信する処理を実行する。そして、スケジュール情報取得部Ｆ３１０は、ユーザ端末２００から送信された上記情報を取得する。

ここで、図３の説明に戻る。交通情報取得部Ｆ３２０は、所定の施設周辺の交通情報（以下、単に「交通情報」と称する。）を取得する。なお、交通情報には、所定の施設周辺の現在の交通状況や、所定の施設に併設された駐車場の収容可能台数・現在の駐車台数、該駐車場への入場口に関する情報等が含まれる。そして、交通情報取得部Ｆ３２０は、交通情報を交通情報データベースＤ３２０に登録する。

交通情報データベースＤ３２０は、交通情報を格納するデータベースである。交通情報データベースＤ３２０は、図６Ａ−図６Ｃに示す交通情報テーブルを有する。なお、交通情報テーブルに格納される情報は、図６Ａ−図６Ｃに示す例に限られず、適宜フィールドの追加、変更、削除が可能である。また、交通情報データベースＤ３２０は、図６Ａ−図６Ｃに示す交通情報テーブルの全てを有していてもよいし、その一部を有していてもよい。

図６Ａに示す交通情報テーブルは、施設ＩＤ、所在地、駐車場識別ＩＤ、駐車場の収容可能台数、現在の駐車台数のフィールドを有する。ここで、施設ＩＤ、所在地、駐車場識別ＩＤ、駐車場の収容可能台数は、所定のデータベースに予め登録された情報を読み込むことで取得され得る。また、現在の駐車台数は、周知の手法に基づいて取得され得る。

また、図６Ｂに示す交通情報テーブルは、施設ＩＤ、所在地、駐車場識別ＩＤ、各駐車場が有する入場口のゲート番号（以下、単に「入場口」と称する。）、各入場口について１分当たりに通過可能な車両の台数（以下、「通過率」と称する。）のフィールドを有する。なお、これら情報は、所定のデータベースに予め登録された情報を読み込むことで取得され得る。

また、図６Ｃに示す交通情報テーブルは、図６Ｂに示した情報に加えて、各入場口の周辺道路の混雑度合い（以下、単に「混雑度合い」と称する。）のフィールドを有する。なお、混雑度合いは、例えば高・中・低といった３段階で表され、周知の手法に基づいて取
得され得る。

ここで、図３の説明に戻る。マッチング処理部Ｆ３３０は、先ず、スケジュール情報取得部Ｆ３１０によって取得したスケジュール情報と、交通情報取得部Ｆ３２０によって取得した交通情報と、に基づいて、所定の施設へ訪問する車両により混雑が発生してしまうか否かを予測する。これについて、以下に詳しく説明する。

例えば、上記の図６Ａに示した施設Ｆ００１の駐車場Ｐ１は、３台車両を駐車することが可能で現在の駐車台数が０台となっている。この場合、施設Ｆ００１へ所定の時間帯に訪問する車両（訪問車両）の数が４台以上となると、駐車場Ｐ１が訪問車両を収容しきれなくなるため、該駐車場に混雑が発生してしまう。また、例えば、上記の図６Ａに示した施設Ｆ００２の駐車場Ｐ２は、５００台車両を駐車することが可能で現在の駐車台数が２０台となっている。この場合、例えば施設Ｆ００２へ所定の時間帯に訪問する車両（訪問車両）の数が４５０台以上となると、駐車場Ｐ２に混雑が発生し得る。訪問車両が４５０台である場合には駐車場Ｐ２の収容可能台数には未だ達しないものの、駐車場Ｐ２に入場した車両は駐車スペースを探し出す必要があり、駐車場内における車両の円滑な駐車が妨げられるからである。

また、混雑の発生は、上述した通過率を用いることによっても判断され得る。例えば、上記の図６Ｂに示した施設Ｆ００２の駐車場Ｐ２には３つの入場口（Ｅ２１−Ｅ２３）があり、該駐車場Ｐ２は１分間に１０台の車両を収容可能である。この場合、仮に駐車場Ｐ２に１分間に５０台の車両が入場しようとすると、駐車場内は比較的空いていたとしても、該駐車場に通じる道路が混雑する事態が生じ得る。また、このときに入場口の周辺道路の混雑度合いを加味することもできる。例えば、上記の図６Ｃによると、駐車場Ｐ２の入場口Ｅ２２の周辺道路の混雑度合いが高となっており、入場口Ｅ２３の周辺道路の混雑度合いが中となっている。そして、混雑度合いが中の場合は通過率が０．５倍になり、混雑度合いが高の場合は通過率が０．１倍になると仮定すると、このときに駐車場Ｐ２が１分間に収容可能な車両の数は４．３台にまで低下してしまう。そうすると、仮にこの数以上の車両が駐車場に入場しようとすると、駐車場に通じる道路が更に混雑し易くなる。

以上に鑑みると、スケジュール情報に基づいて算出される訪問車両の数が第一所定数以上となると、該車両により混雑が発生し得ることが判る。ここで、第一所定数とは、上述したように、交通情報（収容可能台数、現在の駐車台数、通過率、混雑度合い等）に基づいて定められる数である。

そして、所定の施設へ所定の時間帯に訪問する訪問車両の数が第一所定数以上となることが予測される場合、マッチング処理部Ｆ３３０の算出部Ｆ３３１およびマッチング部Ｆ３３２による処理が更に実行される。本実施形態では、上記の図４および図５に示したユーザＳ００１〜Ｓ００４が、所在地ａの施設Ｆ００１に所定の時間帯に訪問する場合を例にして説明する。なお、本例における所定の時間帯とは、例えば８：３０から９：００までの時間帯である。また、第一所定数は、上記の図６Ａに示した駐車場Ｐ１の収容可能台数および駐車台数に基づいて定められるものとする。なお、プロセッサ３０１がスケジュール情報取得部Ｆ３１０、算出部Ｆ３３１、およびマッチング部Ｆ３３２の処理を実行することで、本発明に係る制御部として機能する。そして、サーバ装置３００が、本発明に係る情報処理装置として機能する。

マッチング処理部Ｆ３３０の算出部Ｆ３３１は、相乗りユーザ候補および第二車両を算出する。なお、相乗りユーザ候補とは、相乗りして所定の施設へ所定の時間帯に訪問するユーザの候補である。ここで、相乗りとは、自身のスケジュール情報において特定されている第一車両とは異なる車両に同乗することをいう。また、第二車両とは、上記の相乗り
ユーザ候補が相乗り可能な車両であって該相乗りユーザ候補とは異なるユーザの第一車両である。つまり、相乗りユーザ候補とは異なるユーザのスケジュール情報において特定されている第一車両が、相乗りユーザ候補に対する第二車両となり得る。算出部Ｆ３３１が行う処理の例について、上記の図４および図５に基づいて説明する。

上記の図５によると、ユーザＳ００１が地点ｂから地点ａまで移動するとき、地点ｃを経由しても特段の遠回りとはならないことが判る。そして、上記の図４によると、地点ｃから地点ａに向かうユーザＳ００２は、ユーザＳ００１と同じ所定の時間帯に地点ａに到着することを予定していることが判る。そのため、算出部Ｆ３３１は、相乗りユーザ候補としてユーザＳ００２を算出し、相乗りユーザ候補Ｓ００２に対する第二車両として車両１０１を算出する。この場合、ユーザＳ００２は、ユーザＳ００１が乗車する車両１０１に相乗り可能であると判断されていることになる。

また、上記の図５によると、ユーザＳ００３が地点ｄから地点ａまで移動するとき、地点ｅを経由しても特段の遠回りとはならないことが判る。そして、上記の図４によると、地点ｅから地点ａに向かうユーザＳ００４は、ユーザＳ００３と同じ所定の時間帯に地点ａに到着することを予定していることが判る。そのため、算出部Ｆ３３１は、相乗りユーザ候補としてユーザＳ００４を算出し、相乗りユーザ候補Ｓ００４に対する第二車両として車両１０３を算出する。この場合、ユーザＳ００４は、ユーザＳ００３が乗車する車両１０３に相乗り可能であると判断されていることになる。

本実施形態では、以上に述べたように、算出部Ｆ３３１が、相乗りユーザ候補としてＳ００２およびＳ００４を算出し、Ｓ００２に対する第二車両として車両１０１を、Ｓ００４に対する第二車両として車両１０３を算出する。そうすると、次に、マッチング処理部Ｆ３３０のマッチング部Ｆ３３２が、訪問車両の数が第一所定数よりも少なくなるように、算出した相乗りユーザ候補のうちの一部又は全部のユーザと、第二車両と、のマッチングを行う。

上述したように、上記の図６Ａに示した施設Ｆ００１へ所定の時間帯に訪問する車両（訪問車両）の数が４台以上となると、駐車場Ｐ１が訪問車両を収容しきれなくなるため、該駐車場に混雑が発生してしまう。そこで、マッチング部Ｆ３３２は、訪問車両が４台よりも少なくなるように、相乗りユーザ候補Ｓ００２と第二車両１０１とのマッチング、又は／及び、相乗りユーザ候補Ｓ００４と第二車両１０３とのマッチングを行う。

そして、マッチング部Ｆ３３２は、相乗りユーザ候補と第二車両とをマッチングすると、マッチング情報を生成する。ここで、マッチング情報とは、マッチング情報データベースＤ３３０に登録される情報である。

マッチング情報データベースＤ３３０は、マッチング情報を格納するデータベースである。マッチング情報データベースＤ３３０は、図７Ａまたは図７Ｂに示すマッチング情報テーブルを有する。なお、マッチング情報テーブルに格納される情報は、図７Ａまたは図７Ｂに示す例に限られず、適宜フィールドの追加、変更、削除が可能である。

図７Ａに示すマッチング情報テーブルは、車両識別ＩＤ、スケジュール情報において定められた乗車ユーザのユーザＩＤ、車両にマッチングされた相乗りユーザ候補（相乗りユーザ）のユーザＩＤ、乗車ユーザの出発地とその出発予定時刻、相乗りユーザの出発地とその出発予定時刻、目的地、到着予定時刻のフィールドを有する。本例では、車両１０１に相乗りユーザＳ００２がマッチングされ、車両１０３に相乗りユーザＳ００４がマッチングされている。なお、相乗りユーザがマッチングされた車両の乗車ユーザとは、例えば該車両の運転者である。ただし、これに限定する意図はなく、例えば車両が所定の運行指
令に基づいて自律移動を行う自律移動体である場合には、乗車ユーザとは、上述したようにスケジュール情報において定められたユーザである。

一方、図７Ｂに示すマッチング情報テーブルのように、第二車両として算出された車両１０１および車両１０３のうち、車両１０３にのみ相乗りユーザがマッチングされてもよい。

そして、このようなマッチング情報は、図３に示すマッチング情報提供部Ｆ３４０によって、第二車両とマッチングされた相乗りユーザ、および該第二車両の乗車ユーザに対して提供される。このとき、マッチング情報提供部Ｆ３４０は、マッチング情報を提供するとともに、これらユーザに対してマッチングの承認を要求する。マッチングを承認したユーザは、マッチング情報に基づいて車両による移動を行うことができる。

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

図８に示す処理では、先ず、ステップＳ１０１において、スケジュール情報が取得され該情報が登録される。ステップＳ１０１では、サーバ装置３００が、ユーザ端末２００から送信されたスケジュール情報を、通信部３０４による受信を介して取得し、該スケジュール情報をスケジュール情報データベースＤ３１０に登録する。なお、スケジュール情報には、上述したように、第一車両に関する情報が含まれている。

次に、ステップＳ１０２において、交通情報が取得される。ステップＳ１０２では、サーバ装置３００は、例えば、所定のデータベースに予め登録された情報を読み込むことで交通情報の一つである駐車場の収容可能台数を取得したり、周知の手法に基づいて交通情報の一つである現在の駐車台数を取得したりすることができる。

次に、ステップＳ１０３において、訪問車両の数が第一所定数以上となることが予測されるか否かが判別される。ここで、サーバ装置３００は、ステップＳ１０１で取得したスケジュール情報における、所定の施設へ所定の時間帯に訪問する予定の第一車両の数を、訪問車両の数として算出することができる。また、サーバ装置３００は、ステップＳ１０２で取得した交通情報に基づいて、第一所定数を定めることができる。そして、ステップＳ１０３において肯定判定された場合、サーバ装置３００のプロセッサ３０１はステップＳ１０４の処理へ進み、ステップＳ１０３において否定判定された場合、本フローの実行が終了される。

ステップＳ１０３において肯定判定された場合、次に、ステップＳ１０４において、相乗りユーザ候補および第二車両が算出される。そして、ステップＳ１０５において、訪問車両の数が第一所定数よりも少なくなるように、ステップＳ１０４で算出した相乗りユーザ候補のうちの一部又は全部のユーザと、第二車両と、のマッチングが実行される。なお、ステップＳ１０４において実行される算出部Ｆ３３１による処理、およびステップＳ１０５において実行されるマッチング部Ｆ３３２による処理の詳細については、上述したとおりである。

次に、ステップＳ１０６において、ステップＳ１０５の処理によるマッチングのマッチング情報が送信される。ステップＳ１０６では、サーバ装置３００がマッチング情報をユーザ端末２００に送信する。そうすると、第二車両とマッチングされた相乗りユーザ、および該第二車両の乗車ユーザは、マッチング情報を取得することができる。そして、これらユーザは、ユーザ端末２００を用いて、マッチングを承認するか否かの情報をサーバ装
置３００に送信する。そうすると、サーバ装置３００は、ステップＳ１０７において、ステップＳ１０５の処理によるマッチングがユーザによって承認されたか否かを判別する。そして、ステップＳ１０７において肯定判定された場合、プロセッサ３０１はステップＳ１０８の処理へ進み、ステップＳ１０７において否定判定された場合、プロセッサ３０１はステップＳ１０５の処理へ戻る。

ステップＳ１０７において肯定判定された場合、次に、ステップＳ１０８において、ユーザによって承認されたマッチング情報が登録される。ステップＳ１０８では、サーバ装置３００は、マッチング情報をマッチング情報データベースＤ３３０に登録する。そして、ステップＳ１０８の処理の後、本フローの実行が終了される。

以上に述べた情報処理システムによれば、所定の施設へ所定の時間帯に訪問する訪問車両により混雑が発生してしまう事態が可及的に抑制される。つまり、本発明に係る情報処理装置は、訪問車両による混雑を緩和することが可能なライドシェアシステムを提供することができる。

（記録媒体）
コンピュータその他の機械、装置（以下、コンピュータ等）に上述したいずれかの機能を実現させるプログラムをコンピュータ等が読み取り可能な記録媒体に記録することができる。コンピュータ等に、この記録媒体のプログラムを読み込ませて実行させることにより、その機能を提供させることができる。

ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、又は化学的作用によって蓄積し、コンピュータ等から読み取ることができる非一時的な記録媒体をいう。このような記録媒体のうちコンピュータ等から取り外し可能なものとしては、例えばフレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／Ｗ、ＤＶＤ、ブルーレイディスク、ＤＡＴ、８ｍｍテープ、フラッシュメモリなどのメモリカード等がある。また、コンピュータ等に固定された記録媒体としてハードディスク、ＲＯＭ（リードオンリーメモリ）等がある。さらに、ＳＳＤ（Solid State Drive）は、コンピュータ等から取り外し可能な記録媒体としても、コン
ピュータ等に固定された記録媒体としても利用可能である。

＜第一の実施形態の変形例＞
次に、上述した第一の実施形態の変形例について説明する。なお、本変形例において、第一の実施形態と実質的に同一の構成、実質的に同一の制御処理については、その詳細な説明を省略する。

上述した第一の実施形態では、ライドシェアのマッチングが行われることで訪問車両の数が削減される。これによれば、所定の施設に併設された駐車場内の混雑や該駐車場に通じる道路の混雑が抑制され得るものの、訪問車両の該施設への移動経路によっては、未だ駐車場周辺において混雑が発生してしまうことがある。そこで、本変形例では、サーバ装置３００が、複数の訪問車両のうちの一部または全部の車両について、所定の施設周辺における移動経路をそれぞれ生成する。これについて、図９から図１３に基づいて説明する。

図９は、訪問車両が、上記の図６Ｂに示した施設Ｆ００２の駐車場Ｐ２へ入場する際の、施設Ｆ００２周辺における移動経路を例示する図である。なお、図９に示す例では、地域ｂ´から複数の訪問車両が出発し該訪問車両が地域ｃ´において相乗りユーザを同乗させ、地域ｄ´から複数の訪問車両が出発し該訪問車両が地域ｅ´において相乗りユーザを同乗させるようにライドシェアのマッチングが行われているものとする。そして、地域ｂ
´からの訪問車両は、地点ｆを経由して経路Ｌ１または経路Ｌ２を通って駐車場Ｐ２へ入場し、地域ｄ´からの訪問車両は、地点ｇを経由して経路Ｌ３または経路Ｌ４を通って駐車場Ｐ２へ入場するものとする。

ここで、地域ｂ´からの訪問車両１０台と地域ｄ´からの訪問車両１０台が、同時期に駐車場Ｐ２へ入場しようとする場合を想定する。この場合、上記の図６Ｂの説明で述べたように駐車場Ｐ２は１分間に１０台の車両を収容可能であるため、訪問車両が２０台となるようにライドシェアのマッチングが行われると、該訪問車両による混雑が発生し難くなるように思われる。しかしながら、このとき、経路Ｌ１に１台、経路Ｌ２に９台、経路Ｌ３に５台、経路Ｌ４に５台の車両が通行すると仮定すると、駐車場Ｐ２の入場口Ｅ２１へ通じる経路Ｌ４において混雑が発生し得る。なぜなら、図１０に示すように、入場口Ｅ２１の通過率は１台／ｍｉｎであるため、入場口Ｅ２１から５台の車両が入場するのに少なくとも５分を要するからである。また、入場口Ｅ２２の通過率は３台／ｍｉｎであって、入場口Ｅ２２から９台の車両が入場する場合にも少なくとも３分を要することになる。

そこで、本変形例に係るサーバ装置３００は、図１１に示すように、第一の実施形態の説明で述べた機能構成要素に加えて、移動経路生成部Ｆ３５０、移動経路提供部Ｆ３６０を備える。サーバ装置３００のプロセッサ３０１は、主記憶部３０２上のコンピュータプログラムにより、移動経路生成部Ｆ３５０、移動経路提供部Ｆ３６０の処理を実行する。ただし、各機能構成素のいずれか、またはその処理の一部がハードウェア回路により実行されてもよい。

移動経路生成部Ｆ３５０は、複数の訪問車両のうちの一部または全部の車両について、所定の施設周辺における移動経路（以下、単に「移動経路」と称する。）をそれぞれ生成する。詳しくは、移動経路生成部Ｆ３５０は、該移動経路生成部Ｆ３５０によって移動経路が生成された訪問車両のうち所定の経路を有する車両の数が第二所定数以下となるように該移動経路を生成する。これについて、図１２および図１３に基づいて説明する。

本変形例では、上記の図９に示した駐車場Ｐ２の入場口それぞれについて入場予定台数が通過率の２倍以下となるように、地域ｂ´からの訪問車両１０台と地域ｄ´からの訪問車両１０台とを合せた２０台の訪問車両の移動経路が生成される。そうすると、図１２に示すように、入場口Ｅ２１の入場予定台数は２台、入場口Ｅ２２の入場予定台数は６台、入場口Ｅ２３の入場予定台数は１２台となる。この場合、移動経路生成部Ｆ３５０は、図１３に示すように、２０台の訪問車両のうち地点ｆから入場口Ｅ２３までの経路Ｌ１を有する車両の数が４台となるように訪問車両の移動経路を生成する。同様に、移動経路生成部Ｆ３５０は、地点ｆから入場口Ｅ２２までの経路Ｌ２を有する車両の数が６台となるように、地点ｇから入場口Ｅ２３までの経路Ｌ３を有する車両の数が８台となるように、地点ｇから入場口Ｅ２１までの経路Ｌ４を有する車両の数が２台となるように訪問車両の移動経路を生成する。

これによれば、車両が各入場口から駐車場に入場するのに要する時間が所定時間以下に低減されるため、訪問車両により混雑が発生してしまう事態が抑制される。なお、経路Ｌ１、Ｌ２、Ｌ３、Ｌ４のそれぞれが上記の所定の経路に相当する。また、本変形例では、これらの各経路と繋がる各入場口について入場予定台数が通過率の２倍以下となるように、各径路に対する第二所定数が定義されている。

そして、このように生成された移動経路は、図１１に示す移動経路提供部Ｆ３６０によって、訪問車両に提供される。本変形例では、サーバ装置３００が移動経路を訪問車両の車載装置に送信することによって、該移動経路が訪問車両に提供される。ここで、車載装置は、ネットワークＮ１に接続可能な通信部、ＧＰＳ装置、ナビゲーションシステム等を
有している。ただし、これに限定する意図はなく、サーバ装置３００が移動経路をユーザ端末２００に送信することによって、該移動経路が訪問車両に提供されてもよい。そうすると、訪問車両の運転ユーザは、提供された移動経路（該移動経路は、車載装置が有するナビゲーションシステムの画面やユーザ端末２００の画面に表示される。）に従って、車両を走行させることができる。また、仮に訪問車両が所定の運行指令に基づいて自律移動を行う自律移動体である場合、サーバ装置３００が移動経路を所定の運行管理サーバに送信することによって、該移動経路が該運行管理サーバ経由で訪問車両に提供される。

なお、プロセッサ３０１がスケジュール情報取得部Ｆ３１０、算出部Ｆ３３１、マッチング部Ｆ３３２、移動経路生成部Ｆ３５０、および移動経路提供部Ｆ３６０の処理を実行することで、本発明に係る制御部として機能する。

以上に述べた情報処理システムによっても、所定の施設へ所定の時間帯に訪問する訪問車両により混雑が発生してしまう事態を可及的に抑制することができる。

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

上述した第一の実施形態では、サーバ装置３００は、ユーザ端末２００と通信を行うことによってスケジュール情報を取得する。そして、サーバ装置３００は、相乗りユーザ候補と第二車両とのマッチングを行うと、そのマッチング情報をユーザ端末２００に送信する。これに対して、本実施形態では、サーバ装置３００は、情報処理システム１を利用するユーザのスケジュール情報を管理する管理サーバと通信を行うことによってスケジュール情報を取得する。また、サーバ装置３００は、相乗りユーザ候補と第二車両とのマッチングを行うと、そのマッチング情報を管理サーバに送信する。

図１４は、本実施形態に係る情報処理システムの概略構成を示す図である。図１４の例では、情報処理システム１は、ユーザ端末２００と、サーバ装置３００と、管理サーバ４００とを含んで構成される。ここで、管理サーバ４００は、所定のグループに属するユーザのスケジュール情報を一括で管理するサーバ装置であって、情報処理システム１は、該システムを利用する所定のグループの数に応じた数の管理サーバ４００を含む。なお、所定のグループとは、例えば会社単位のグループである。

情報処理システム１においては、サーバ装置３００と管理サーバ４００が、ネットワークＮ１によって相互に接続される。また、各ユーザ端末２００および管理サーバ４００が、ネットワークＮ２によって相互に接続される。ここで、ネットワークＮ２には、例えば、インターネット等の世界規模の公衆通信網であるＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）やその他の通信網が採用されてもよい。また、ネットワークＮ２は、携帯電話等の電話通信網、ＷｉＦｉ等の無線通信網を含んでもよい。

また、管理サーバ４００は、サーバ装置３００と同様のハードウェア構成を備え、プロセッサ４０１、主記憶部４０２、補助記憶部４０３、通信部４０４を有する。更に、管理サーバ４００は、機能構成要素として、スケジュール情報取得部Ｆ４１０、マッチング情報提供部Ｆ４４０、スケジュール情報データベースＤ４１０を備える。これら機能構成は、第一の実施形態の説明で述べたスケジュール情報取得部Ｆ３１０、マッチング情報提供部Ｆ３４０、スケジュール情報データベースＤ３１０と同様に機能する。

ここで、本実施形態に係る情報処理システムの動作の流れについて説明する。図１５は
、本実施形態に係る情報処理システムの動作の流れを例示する図である。図１５は、情報処理システム１における、各構成要素間の動作の流れ、および各構成要素が実行する処理を説明する。

本実施形態では、先ず、ユーザによってスケジュール情報が登録される。ユーザ端末２００は、ユーザからスケジュール情報を受付け（ステップＳ２０１）、それを管理サーバ４００に送信する（ステップＳ２０２）。そして、管理サーバ４００は、ユーザ端末２００から送信されたスケジュール情報を、通信部４０４による受信を介して取得し、該スケジュール情報をスケジュール情報データベースＤ４１０に登録する（ステップＳ２０３）。更に、管理サーバ４００は、スケジュール情報をサーバ装置３００に送信する（ステップＳ２０４）。そして、サーバ装置３００は、管理サーバ４００から送信されたスケジュール情報を、通信部３０４による受信を介して取得する（ステップＳ２０５）。

次に、サーバ装置３００は、交通情報を取得する（ステップＳ２０６）。そして、訪問車両の数が第一所定数以上となることが予測される場合（上記の図８に示したステップＳ１０３において肯定判定された場合）、サーバ装置３００は、相乗りユーザおよび第二車両を算出し（上記の図８に示したステップＳ１０４）、更に相乗りユーザ候補と第二車両とのマッチングを行う（ステップＳ２０７）。サーバ装置３００は、ステップＳ２０７のマッチングを実行すると、マッチング情報を生成し該マッチング情報を管理サーバ４００に送信する（ステップＳ２０８）。ここで、本実施形態におけるマッチング情報には、相乗りユーザ候補と第二車両とのマッチング結果に加えて、第二車両をライドシェアして所定の施設へ訪問することを依頼するライドシェア依頼が含まれる。なお、ライドシェア依頼は、第二車両にマッチングされた相乗りユーザに対して、該第二車両に同乗して所定の施設を訪問することを要求する情報である。また、ライドシェア依頼には、相乗りユーザが設定された第二車両に当初から乗車することを予定していたユーザに対して、該第二車両に相乗りユーザを同乗させることを要求する情報を含めることができる。

管理サーバ４００は、ライドシェア依頼が含まれるマッチング情報を取得すると（ステップＳ２０９）、第二車両にマッチングされた相乗りユーザのスケジュール情報を変更する（ステップＳ２１０）。これについて、図１６および図１７に基づいて説明する。

図１６は、ステップＳ２０３においてスケジュール情報データベースＤ４１０に登録されたスケジュール情報テーブルを例示する図である。図１６に示されるユーザＳ００１〜Ｓ００４は、同一のグループに属するユーザである。ここで、本実施形態では、図１６に示すように、車両１０１にユーザＳ００１およびＳ００２が乗車し、車両１０３にユーザＳ００３およびＳ００４が乗車するようにスケジューリングされている。つまり、ユーザＳ００１およびＳ００２に対する第一車両は車両１０１であって、ユーザＳ００３およびＳ００４に対する第一車両は車両１０３である。

ここで、ステップＳ２０７におけるマッチングによって、ユーザＳ００１およびＳ００２と車両１０３とがマッチングされた場合を想定する。この場合、ユーザＳ００１およびＳ００２が本発明に係る相乗りユーザに該当し、車両１０３がユーザＳ００１およびＳ００２に対する第二車両に該当する。そうすると、管理サーバ４００は、図１７に示すように、車両１０３にマッチングされた相乗りユーザＳ００１およびＳ００２のスケジュール情報を変更する。詳しくは、ユーザＳ００１およびＳ００２が乗車する予定の車両が、車両１０１から車両１０３に変更されるとともに、出発予定時刻が変更される。なお、車両１０３への乗車人数の変更に伴って、ユーザＳ００３およびＳ００４の出発予定時刻も変更される。

そして、管理サーバ４００は、上記のように変更したスケジュール情報をユーザ端末２
００に送信する（ステップＳ２１１）。そうすると、ユーザ端末２００が、変更後のスケジュール情報を取得する（ステップＳ２１２）。また、管理サーバ４００は、変更したスケジュール情報をスケジュール情報データベースＤ４１０に登録する（ステップＳ２１３）。

このように、ユーザのスケジュール情報が管理サーバ４００によって管理されることによって、サーバ装置３００の負担が軽減される。なお、管理サーバ４００は、上述したようにスケジュール情報を変更する際、ユーザへ承認を要求してもよい。また、サーバ装置３００は、異なるグループに属するユーザ同士が一の車両に同乗するようにマッチングを行ってもよい。

以上に述べた情報処理システムによっても、所定の施設へ所定の時間帯に訪問する訪問車両により混雑が発生してしまう事態が可及的に抑制される。つまり、本発明に係る情報処理装置は、訪問車両による混雑を緩和することが可能なライドシェアシステムを提供することができる。

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

また、本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

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

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

２００・・・ユーザ端末
３００・・・サーバ装置
３０１・・・プロセッサ
３０２・・・主記憶部
３０３・・・補助記憶部

Claims (7)

1. 所定の施設へ車両で訪問する複数の訪問者それぞれについて、該訪問者が該施設へ訪問するスケジュールに関する情報であって該訪問者が該施設へ訪問する際に自身が乗車する予定の車両である第一車両が特定されたスケジュール情報を取得することと、
   前記所定の施設へ所定の時間帯に訪問する複数の訪問車両の数が第一所定数以上となることが、前記複数の訪問者それぞれについての前記スケジュール情報に基づいて予測される場合、前記複数の訪問者のうち自身の前記スケジュール情報において特定されている前記第一車両とは異なる車両に相乗りして前記所定の施設へ前記所定の時間帯に訪問する訪問者の候補である相乗りユーザ候補、及びそのときに該相乗りユーザ候補が相乗り可能な車両であって該相乗りユーザ候補とは異なる訪問者の前記第一車両である第二車両を算出し、前記複数の訪問車両の数が前記第一所定数よりも少なくなるように、算出した前記相乗りユーザ候補のうちの一部又は全部のユーザと、前記第二車両と、のマッチングを行うことと、
   を実行する制御部を備える情報処理装置。
2. 前記制御部は、
   前記複数の訪問者それぞれについての前記スケジュール情報を管理する管理サーバから、前記複数の訪問者それぞれの前記スケジュール情報を取得し、
   前記マッチングを行った場合、前記管理サーバに、前記マッチングの結果及び前記第二車両をライドシェアして前記所定の施設へ訪問することを依頼するライドシェア依頼を送信する、
   請求項１に記載の情報処理装置。
3. 前記制御部は、
   前記複数の訪問車両のうちの一部又は全部の車両について、前記所定の施設周辺における移動経路をそれぞれ生成し、且つ該移動経路が生成された訪問車両のうち所定の経路を有する車両の数が第二所定数以下となるように該移動経路を生成することと、
   生成した前記移動経路を、該移動経路が生成された前記訪問車両に提供することと、
   を更に実行する請求項１に記載の情報処理装置。
4. 前記制御部は、
   前記複数の訪問車両のうちの一部又は全部の車両について、前記所定の施設周辺における移動経路をそれぞれ生成し、且つ該移動経路が生成された訪問車両のうち所定の経路を有する車両の数が第二所定数以下となるように該移動経路を生成することと、
   生成した前記移動経路を前記管理サーバに送信することと、
   を更に実行する請求項２に記載の情報処理装置。
5. 前記第一所定数は、前記所定の施設に併設された駐車場の収容可能台数に基づいて定められる、
   請求項１から４の何れか１項に記載の情報処理装置。
6. 所定の施設へ車両で訪問する複数の訪問者それぞれについて、該訪問者が該施設へ訪問するスケジュールに関する情報であって該訪問者が該施設へ訪問する際に自身が乗車する予定の車両である第一車両が特定されたスケジュール情報を取得するステップと、
   前記所定の施設へ所定の時間帯に訪問する複数の訪問車両の数が第一所定数以上となることが、前記複数の訪問者それぞれについての前記スケジュール情報に基づいて予測される場合、前記複数の訪問者のうち自身の前記スケジュール情報において特定されている前記第一車両とは異なる車両に相乗りして前記所定の施設へ前記所定の時間帯に訪問する訪問者の候補である相乗りユーザ候補、及びそのときに該相乗りユーザ候補が相乗り可能な
   車両であって該相乗りユーザ候補とは異なる訪問者の前記第一車両である第二車両を算出し、前記複数の訪問車両の数が前記第一所定数よりも少なくなるように、算出した前記相乗りユーザ候補のうちの一部又は全部のユーザと、前記第二車両と、のマッチングを行うステップと、
   を有する情報処理方法。
7. 所定の施設へ車両で訪問する複数の訪問者それぞれについて、該訪問者が該施設へ訪問するスケジュールに関する情報であって該訪問者が該施設へ訪問する際に自身が乗車する予定の車両である第一車両が特定されたスケジュール情報を取得するステップと、
   前記所定の施設へ所定の時間帯に訪問する複数の訪問車両の数が第一所定数以上となることが、前記複数の訪問者それぞれについての前記スケジュール情報に基づいて予測される場合、前記複数の訪問者のうち自身の前記スケジュール情報において特定されている前記第一車両とは異なる車両に相乗りして前記所定の施設へ前記所定の時間帯に訪問する訪問者の候補である相乗りユーザ候補、及びそのときに該相乗りユーザ候補が相乗り可能な車両であって該相乗りユーザ候補とは異なる訪問者の前記第一車両である第二車両を算出し、前記複数の訪問車両の数が前記第一所定数よりも少なくなるように、算出した前記相乗りユーザ候補のうちの一部又は全部のユーザと、前記第二車両と、のマッチングを行うステップと、
   をコンピュータに実行させるためのプログラム。

Images