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

Description

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

近年、スマートフォン等のユーザ端末で動作可能なタクシー配車用のアプリケーションプログラム（以下、「タクシー配車アプリ」と略称する場合もある。）が普及してきている。上記タクシー配車アプリを利用した技術として、ユーザからの配車要求を受け付けたときに、タクシーの現在位置と、現在位置から乗車位置までの走行予定経路と、をユーザ端末へ通知する技術が知られている（例えば、特許文献１を参照。）。

特開２０１５－１３８３２４号公報

本開示の目的は、タクシーを効率的に配車することができる技術を提供することにある。

本開示は、情報処理装置として捉えることができる。その場合の情報処理装置は、例えば、
タクシーの配車を要求する信号であって、且つユーザの希望乗車位置に関する情報を含む信号である配車要求信号を、前記ユーザの使用する端末であるユーザ端末から受信することと、
前記希望乗車位置を含む所定エリア内における道路の物理的条件に関する情報である物理情報と、前記所定エリア内におけるタクシーへの乗車およびまたはタクシーからの降車の実績に関する情報である実績情報と、前記所定エリア内の道路の状態に関する情報である道路情報と、の少なくとも一つに基づいて、推奨乗車位置を決定することと、
前記推奨乗車位置で待機することを前記ユーザに促すための情報を、前記ユーザ端末へ送信することと、
を実行する制御部を備えるようにしてもよい。

また、本開示は、情報処理方法として捉えることもできる。その場合の情報処理方法は、例えば、
タクシーの配車を要求する信号であって、且つユーザの希望乗車位置に関する情報を含む信号である配車要求信号を、前記ユーザの使用する端末であるユーザ端末から受信するステップと、
前記希望乗車位置を含む所定エリア内における道路の物理的条件に関する情報である物理情報と、前記所定エリア内におけるタクシーへの乗車およびまたはタクシーからの降車の実績に関する情報である実績情報と、前記所定エリア内の道路の状態に関する情報である道路情報と、の少なくとも一つに基づいて、推奨乗車位置を決定するステップと、
前記推奨乗車位置で待機することを前記ユーザに促すための情報である乗車位置情報を、前記ユーザ端末へ送信するステップと、
をコンピュータが実行するようにしてもよい。

また、本開示は、上記した情報処理方法をコンピュータに実行させるための情報処理プ
ログラム、又は該情報処理プログラムを格納する非一時的記憶媒体として捉えることもできる。

本開示によれば、タクシーを効率的に配車することができる技術を提供することができる。

タクシー配車システムの一構成例を示す図である。 タクシーの一構成例を示す図である。 車載装置、ユーザ端末、及びサーバ装置の各々のハードウェア構成例を示す図である。 実施形態におけるサーバ装置の機能構成例を示すブロック図である。 実施形態における物理情報テーブルの構成例を示す図である。 実施形態における実績情報テーブルの構成例を示す図である。 実施形態におけるタクシー情報テーブルの構成例を示す図である。 実施形態におけるサーバ装置で行われる処理フローを示すフローチャートである。 変形例５におけるサーバ装置の機能構成例を示すブロック図である。 変形例５における臨時実績情報テーブルの構成例を示す図である。 変形例５におけるサーバ装置で行われる処理フローを示すフローチャートである。

本開示は、タクシー配車サービスにおいて、ユーザの乗車位置を最適化することで、タクシーを効率的に配車することを特徴とする。なお、以下に記載する「タクシー」は、特段の記載がない限り、空車状態のタクシーを示すものとする。

タクシー配車サービスを提供するシステム（以下、「タクシー配車システム」と記す場合もある。）では、ユーザからの配車要求が発生した場合に、ユーザの希望する乗車位置（希望乗車位置）へ向けてタクシーを配車するのが一般的である。ここでいう「希望乗車位置」は、例えば、ユーザの現在位置、又はユーザの指定する場所（現在位置以外の場所）である。

ところで、上記希望乗車位置がタクシーの乗車場所に適しているとは限らない。例えば、希望乗車位置と車道との間にガードレール又は植え込み等の仕切りが設置されている場合、又は希望乗車位置が駐停車禁止場所に臨んでいる場合は、希望乗車位置においてユーザをタクシーに乗車させることが物理的に不可能になる可能性がある。それらの場合、ユーザとタクシーとは、仕切りが設定されておらず且つ駐停車禁止場所に臨んでいない場所まで移動する必要がある。また、希望乗車位置が臨む車道に駐車車両が存在する場合は、タクシーが希望乗車位置にアクセスすることができない可能性がある。その場合も、ユーザとタクシーとは、駐車車両の存在しない場所まで移動する必要がある。また、希望乗車位置の周辺の道路において、工事等に起因する交通規制等が行われている場合も、タクシーが希望乗車位置にアクセスすることができない可能性がある。その場合も、ユーザとタクシーとは、交通規制等が行われていない場所まで移動する必要がある。また、希望乗車位置へタクシーがアクセスするための道路（以下、「アクセス路」と記す場合もある。）で渋滞等が発生している場合は、タクシーが希望乗車位置に到着するまでに時間がかかる可能性がある。その場合、ユーザの待ち時間が不要に長くなるとともに、タクシーの売上げに反映されない移動時間が不要に長くなる可能性がある。また、希望乗車位置の近辺で集会（スポーツ等の競技、コンサート、展示会、又は祭事等のように、大勢の人が集まる
イベント）が開催されている場合は、タクシーの乗車を希望する人が希望乗車位置の近辺に集中する可能性がある。その場合、希望乗車位置の近辺に多数のタクシーが集まる可能性がある。それにより、配車対象のタクシーが希望乗車位置へ速やかにアクセスすることができない可能性がある。

上記した種々の要因によって希望乗車位置がタクシーの乗車場所に適していない場合、ユーザをスムーズにタクシーへ乗車させることが困難になる可能性がある。それにより、ユーザの利便性が低下したり、又はタクシーの運転者の手間が増加したりする可能性もある。その結果、タクシーを効率的に配車することが困難になる可能性がある。

これに対し、本開示に係る情報処理装置では、配車要求信号を受信したときに、制御部が、推奨乗車位置を決定し、決定された推奨乗車位置に関する情報（乗車位置情報）をユーザ端末へ送信する。ここでいう「配車要求信号」は、ユーザがタクシーの配車を要求するための信号であって、ユーザの希望乗車位置に関する情報を含む。「推奨乗車位置」は、タクシーの乗車に適した場所であり、物理情報と実績情報と道路情報との少なくとも１つに基づいて決定される。「物理情報」は、希望乗車位置を含むエリア（所定エリア）内における道路の物理的条件に関する情報である。「実績情報」は、所定エリア内におけるタクシーへの乗車およびまたはタクシーからの降車の実績に関する情報である。「道路情報」は、所定エリア内の道路の状態に関する情報である。また、「乗車位置情報」は、推奨乗車位置でタクシーの到着に待機することをユーザに促すための情報である。斯様な乗車位置情報を受け取ったユーザは、推奨乗車位置でタクシーの到着に待機することで、タクシーへの乗車をスムーズに行うことができる。これにより、ユーザの利便性が低下したり、又はタクシーの運転者の手間が増加したりすることを抑制することができる。その結果、タクシーを効率的に配車することが可能になる。

ここで、本開示における物理情報は、所定エリア内において歩道と車道とを隔てる仕切りが設置されている場所に関する情報と、所定エリア内における駐停車禁止場所に関する情報と、の少なくとも一つを含んでもよい。これにより、所定エリア内において、タクシーに乗車することが物理的に可能な場所と、タクシーに乗車することが物理的に不可能な場所と、を区別することができる。よって、希望乗車位置がタクシーに乗車することが物理的に可能な場所であるかを判定することができる。また、所定エリア内においてタクシーに乗車することが物理的に可能な場所を特定することも可能になる。

本開示における実績情報は、実績場所に関する情報と、実績回数に関する情報と、を含んでもよい。「実績場所」は、所定エリア内において実際にタクシーへの乗車およびまたはタクシーからの降車が行われた場所である。「実績回数」は、各実績場所で実際にタクシーへの乗車およびまたはタクシーからの降車が行われた回数である。ここで、実績場所は、タクシーの乗り降りが可能な場所であるとみなすことができる。特に、実績回数が多い実績場所は、ユーザがタクシーの乗り降りをし易い場所、又はタクシーの運転者にとってユーザを乗り降りさせ易い場所であるとみなすことができる。これにより、希望乗車位置がタクシーの乗り降りがし易い場所であるかを判定することができる。また、所定エリア内においてタクシーの乗り降りがし易い場所を特定することも可能になる。

本開示における道路情報は、所定エリア内における道路の渋滞情報と、所定エリア内における駐車車両の有無に関する情報と、所定エリア内における道路の規制に関する情報と、所定エリア内における集会の開催有無に関する情報と、の少なくとも１つを含んでもよい。これにより、希望乗車位置のアクセス路に渋滞が発生しているかを判定することができる。また、希望乗車位置が臨む車道に駐車車両が存在するかを判定することもできる。また、希望乗車位置の近辺で集会が開催されているかを判定することもできる。また、希望乗車位置のアクセス路で交通規制が行われているかを判定することもできる。そして、
それらの判定結果に基づいて、タクシーが希望乗車位置へ速やかにアクセスすることができるかを判定することも可能になる。また、所定エリア内において渋滞が発生していない場所、駐車車両が存在しない場所、又は集会の開催期間中においてタクシーに乗車し易い場所等を特定することもできる。

ここで、制御部は、物理情報と実績情報と道路情報との少なくとも一つに基づいて、希望乗車位置がタクシーの乗車場所に適しているかを判定してもよい。例えば、希望乗車位置と車道との間に仕切りがなく、且つ希望乗車位置が駐停車禁止場所に臨んでおらず、且つ希望乗車位置が臨む車道に駐車車両が存在しない場合は、希望乗車位置がタクシーの乗車場所に適していると判定してもよい。また、上記の条件に加え、以下に示す２つの条件のうち、少なくとも１つが成立している場合に、希望乗車位置がタクシーの乗車場所に適していると判定してもよい。
（条件１）希望乗車位置のアクセス路で渋滞が発生していない
（条件２）希望乗車位置のアクセス路で交通規制が行われていない

希望乗車位置がタクシーの乗車場所に適していると判定された場合は、制御部が、希望乗車位置を推奨乗車位置に決定してもよい。その場合、ユーザは、希望乗車位置でスムーズにタクシーに乗車することができる。

希望乗車位置がタクシーの乗車場所に適していないと判定された場合は、所定エリア内において、車道との間に仕切りがなく、且つ駐停車禁止場所に臨んでおらず、且つ駐車車両が存在しない場所（乗車可能場所）の中から推奨乗車位置が決定されてもよい。その場合、制御部は、例えば、乗車可能場所のうち、実績回数が最も多い場所を、推奨乗車位置に決定してもよい。その場合、タクシーに乗車することが物理的に可能であり、且つタクシーがアクセス可能であり、且つタクシーの乗り降りがし易い場所が、推奨乗車位置に決定される。斯様な推奨乗車位置でユーザを待機させることで、タクシーへの乗車をスムーズに且つ確実に行うことが可能になる。なお、実績回数が最も多い場所のアクセス路で渋滞が発生している場合又は交通規制が行われている場合は、実績回数が２番目に多い場所が、推奨乗車位置に決定されてもよい。

また、希望乗車位置がタクシーの乗車場所に適していないと判定された場合に、制御部は、上記したような乗車可能場所のうち、渋滞が最も小さい場所を、推奨乗車位置に決定してもよい。その場合、タクシーに乗車することが物理的に可能であり、且つタクシーが速やかにアクセスすることが可能な場所が、推奨乗車位置に決定される。斯様な推奨乗車位置でユーザを待機させることで、タクシーへの乗車を速やかに且つ確実に行うことが可能になる。

なお、希望乗車位置がタクシーの乗車場所に適していないと判定された場合において、制御部は、悪天候時は好天候時に比べ、希望乗車位置により近い乗車可能場所の中から、推奨乗車位置を決定してもよい。例えば、悪天候時は、所定エリアより狭い範囲のエリア（以下、「狭小エリア」と記す場合もある。）内の乗車可能場所の中から、推奨乗車位置が決定されてもよい。その際の狭小エリアには、希望乗車位置が含まれるものとする。斯様な方法により推奨乗車位置が決定されると、希望乗車位置がタクシーの乗車場所に適していない場合に、悪天候のなかでユーザが移動する距離を可能な限り小さく抑えることができる。

ところで、所定エリア内に希望乗車位置が含まれる複数の配車要求信号を、情報処理装置が同じ時間帯に受信する場合も想定され得る。斯様な場合に、それら複数の配車要求信号のうち、少なくとも２つの配車要求信号に対する推奨乗車位置が重複すると、該推奨乗車位置においてユーザをスムーズにタクシーへ乗車させることが難しくなる可能性がある
。そこで、制御部は、複数の配車要求信号に対する推奨乗車位置を、互いに異なる場所に決定してもよい。これにより、所定エリア内に希望乗車位置が含まれる複数の配車要求信号を、情報処理装置が同じ時間帯に受信した場合であっても、それらの配車要求信号に係るユーザをスムーズにタクシーへ乗車させることが可能になる。

本開示における配車要求信号は、ユーザの希望乗車位置に関する情報に加え、ユーザの希望する目的地に関する情報を含んでもよい。その場合、制御部は、物理情報と実績情報と道路情報とに加え、所定エリアから目的地へかけてタクシーが走行するのに適した車線の向きに基づいて、推奨乗車位置を決定してもよい。例えば、乗車可能場所のうち、所定エリアから目的地へかけてタクシーが走行するのに適した向きの車線（以下、「適正車線」と記す場合もある。）に臨む場所が、推奨乗車位置に決定されてもよい。その際、乗車可能場所の中に適正車線に臨む場所が複数箇所あれば、実績回数が最も多い場所、アクセス路の渋滞が最も小さい場所、アクセス路で交通規制が行われていない場所、又は希望乗車位置から最も近い場所が、推奨乗車位置に決定されてもよい。これにより、ユーザの乗車後にタクシーを転回（Ｕターン）させる等の手間がかからなくなるため、乗車料金の不要な増加を抑えることができる。

また、本開示に係る情報処理装置は、所定エリア内で集会を開催可能な施設と、臨時実績場所と、を関連付けて記憶する記憶部を更に備えてもよい。「臨時実績場所」は、上記施設で集会が開催された期間において、実際にタクシーへの乗車およびまたはタクシーからの降車が行われた場所である。そして、上記施設で集会が開催されている期間においては、制御部が、臨時実績場所の中から推奨乗車位置を決定してもよい。その際、臨時実績場所のうち、実績回数が最も多い臨時実績場所、希望乗車位置から最も近い臨時実績場所、アクセス路の渋滞が最も小さい臨時実績場所、又はアクセス路で交通規制が行われていない臨時実績場所等が、推奨乗車位置に決定されてもよい。これにより、所定エリア内の施設で集会が開催されている期間においても、タクシーの乗り降りがし易く、且つタクシーがアクセスし易い場所を、推奨乗車位置に決定することができる。

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

＜実施形態＞
本実施形態では、タクシー配車システムに、本開示を適用する例について述べる。

（タクシー配車システムの概要）
図１は、タクシー配車システムの一構成例を示す図である。図１に示す例では、タクシー配車システムは、タクシー１０と、ユーザ端末２００と、サーバ装置３００と、を含んで構成される。なお、図１に示す例では、タクシー１０とユーザ端末２００とが各々１つのみ図示されているが、複数でもよい。

タクシー１０は、図２に示すように、車載装置１００を搭載している。車載装置１００は、該車載装置１００を搭載するタクシー１０の現在位置を取得する。そして、車載装置１００は、取得した現在位置を示す情報（位置情報）を、該車載装置１００が搭載されるタクシー１０の識別情報（車両ＩＤ）とともにサーバ装置３００へ送信する。車載装置１００による現在位置の取得及び位置情報の送信は、所定の周期で繰り返し行われる。なお、車載装置１００による現在位置の取得及び位置情報の送信は、サーバ装置３００からの要求に応じて行われてもよい。

また、本例における車載装置１００は、サーバ装置３００からの配車指令に基づいて、
運転者に対する経路案内を行う。本例における配車指令は、ユーザを乗車させる位置（推奨乗車位置）に関する情報、及びタクシー１０の現在位置から推奨乗車位置までの走行予定経路に関する情報を含む。車載装置１００は、上記配車指令に従って、タクシー１０の現在位置から推奨乗車位置までの経路案内を行う。

ユーザ端末２００は、タクシー１０の配車を希望するユーザが使用するコンピュータである。ユーザ端末２００には、タクシー配車サービスを利用するためのアプリケーション（タクシー配車アプリ）がインストールされている。ユーザは、ユーザ端末２００に上記タクシー配車アプリを実行させることで、タクシー１０の配車要求を行うことができる。ユーザによるタクシー１０の配車要求が行われると、ユーザ端末２００が、ユーザの希望する乗車位置（希望乗車位置）に関する情報を含む配車要求信号を、サーバ装置３００へ送信する。希望乗車位置は、ユーザの現在位置でもよく、又はユーザが任意に指定した場所（現在位置以外の場所）でもよい。なお、配車要求信号には、ユーザの目的地（降車位置）に関する情報が含まれてもよい。

また、本例におけるユーザ端末２００は、サーバ装置３００からの乗車位置情報に従って、推奨乗車位置でタクシー１０の到着に待機することをユーザに促すための処理を行う。すなわち、ユーザ端末２００は、推奨乗車位置でタクシー１０に乗車することをユーザに促すための処理を行う。ここでいう「乗車位置情報」は、上記配車要求信号に応答する形でサーバ装置３００からユーザ端末２００へ送信される情報であり、推奨乗車位置で待機することをユーザに促すための情報を含む。推奨乗車位置は、タクシー１０の乗車に適した場所であり、希望乗車位置又は希望乗車位置の近辺の位置である。

サーバ装置３００は、本開示に係る「情報処理装置」に相当する。サーバ装置３００は、ユーザ端末２００からの配車要求信号に従って、推奨乗車位置を決定する処理、推奨乗車位置に従ってタクシー１０の配車を行う処理、及び上記乗車位置情報をユーザ端末２００へ送信する処理等を行う。本例では、サーバ装置３００は、上記配車要求信号を受信したときに、先ず、推奨乗車位置を決定する。具体的には、サーバ装置３００は、希望乗車位置がタクシー１０の乗車場所に適しているかを判定する。希望乗車位置がタクシー１０の乗車場所に適していると判定された場合は、サーバ装置３００は、希望乗車位置を推奨乗車位置に決定する。一方、希望乗車位置がタクシー１０の乗車場所に適していないと判定された場合は、サーバ装置３００は、希望乗車位置を含む所定エリア内においてタクシー１０の乗車に適した場所を、推奨乗車位置に決定する。ここでいう「所定エリア」は、ユーザが徒歩で容易に移動することができる範囲であり、例えば、希望乗車位置から数メートル以内又は数十メートル以内の範囲である。上記した方法で推奨乗車位置が決定されると、サーバ装置３００は、タクシー１０の配車処理を実行する。具体的には、サーバ装置３００は、タクシー１０の車載装置１００から受信した位置情報に基づいて、推奨乗車位置に最も近いタクシー１０を特定する。続いて、サーバ装置３００は、特定されたタクシー１０の現在位置から推奨乗車位置までの走行予定経路を決定する。そして、サーバ装置３００は、推奨乗車位置に関する情報、及び走行予定経路に関する情報を含む配車指令を、上記で特定されたタクシー１０の車載装置１００へ送信する。また、サーバ装置３００は、上記で決定された推奨乗車位置において待機することをユーザに促すための情報（乗車位置情報）を、ユーザ端末２００へ送信する。

（ハードウェア構成）
図３は、車載装置１００、ユーザ端末２００、及びサーバ装置３００の各々のハードウェア構成例を示す図である。図３に示す例では、車載装置１００が１つのみ図示されているが、サーバ装置３００の管理下にある全てのタクシー１０には、図３中の車載装置１００と同様のハードウェア構成を有する車載装置１００が搭載される。また、タクシー配車アプリがインストールされているユーザ端末は、図３中のユーザ端末２００と同様のハー
ドウェア構成を有する。

車載装置１００は、例えば、ネットワークＮ１に接続可能なカーナビゲーションシステムである。なお、車載装置１００は、ネットワークＮ１に接続されるパーソナルコンピュータ（Personal Computer :PC）であってもよい。また、車載装置１００は、例えば、ス
マートフォン、携帯電話、タブレット端末、個人情報端末、ウェアラブルコンピュータ（スマートウォッチ等）等のように、タクシー１０の運転者が携帯可能な小型のコンピュータであってもよい。

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

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

プロセッサ１０１は、例えば、ＣＰＵ（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）も格納される。なお、これらの情報の一部又は全部は、主記憶部１０２に格納されてもよい。また、主記憶部１０２に格納される情報は、補助記憶部１０３に格納されてもよい。

入出力部１０４は、タクシー１０の運転者が行った入力操作を受け付け、又は運転者に対する情報（例えば、地図上におけるタクシー１０の現在位置、又は現在位置から推奨乗車位置までの走行予定経路等）を提示する機器である。典型的には、入出力部１０４は、タッチパネルディスプレイ、マイクロフォン、及びスピーカ等を含んで構成される。

位置取得部１０５は、車載装置１００の現在位置（すなわち、タクシー１０の現在位置）を取得する機器であり、典型的にはＧＰＳ受信器等を含んで構成される。

通信部１０６は、例えば、移動体通信サービス等の無線通信を利用してネットワークＮ１に接続することで、サーバ装置３００等の外部機器とデータ通信を行う。ネットワークＮ１は、例えば、インターネット等の世界規模の公衆通信網であるＷＡＮ（Wide Area Network）、又はその他の通信網等である。なお、本例における車載装置１００は、無線通
信を利用してネットワークに接続される。無線通信は、例えば、５Ｇ（5th Generation）、又はＬＴＥ（Long Term Evolution）等の移動体通信である。なお、無線通信は、ＤＳ
ＲＣ（Dedicated Short Range Communications）等の狭帯域通信、又はWi-Fi（登録商標
）等でもよい。

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

次に、ユーザ端末２００は、スマートフォン、携帯電話、タブレット端末、若しくはウェアラブルコンピュータ等のようにユーザが携帯可能な小型のコンピュータである。なお、ユーザ端末２００は、ネットワークＮ１に接続可能なパーソナルコンピュータ（PC）等のように、ユーザの自宅若しくは会社等に設置される端末でもよい。

ユーザ端末２００は、図３に示すように、プロセッサ２０１、主記憶部２０２、補助記憶部２０３、入出力部２０４、位置取得部２０５、及び通信部２０６を含む。これらの構成要素は、互いにバスによって接続される。プロセッサ２０１と主記憶部２０２と補助記憶部２０３と入出力部２０４と位置取得部２０５と通信部２０６は、車載装置１００のプロセッサ１０１と主記憶部１０２補助記憶部１０３と入出力部１０４と位置取得部１０５と通信部１０６に各々同様である。なお、車載装置１００のハードウェア構成は、図３に示す例に限らず、適宜構成要素の省略、置換、追加が行われてもよい。

次に、サーバ装置３００は、一般的なコンピュータの構成を有する。すなわち、サーバ装置３００は、図３に示すように、プロセッサ３０１、主記憶部３０２、補助記憶部３０３、及び通信部３０４を含む。これらの構成要素は、互いにバスによって接続される。プロセッサ３０１と主記憶部３０２と補助記憶部３０３は、車載装置１００のプロセッサ１０１と主記憶部１０２と補助記憶部１０３に各々同様である。

通信部３０４は、外部の装置とサーバ装置３００との間におけるデータ通信を行う。通信部３０４は、例えば、ＬＡＮ（Local Area Network）インターフェースボード、又は無線通信のための無線通信回路である。ＬＡＮインターフェースボード又は無線通信回路は、ネットワークＮ１に接続される。なお、サーバ装置３００のハードウェア構成は、図３に示す例に限らず、適宜構成要素の省略、置換、追加が行われてもよい。

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

（サーバ装置の機能構成）
ここで、本例におけるサーバ装置３００の機能構成について、図４に基づいて説明する。図４に示すように、本例におけるサーバ装置３００は、その機能構成要素として、位置決定部Ｆ３１０、配車処理部Ｆ３２０、情報生成部Ｆ３３０、物理情報管理データベースＤ３１０、実績情報管理データベースＤ３２０、及びタクシー情報管理データベースＤ３３０を含む。

位置決定部Ｆ３１０と配車処理部Ｆ３２０と情報生成部Ｆ３３０とは、サーバ装置３００のプロセッサ３０１が主記憶部３０２上のコンピュータプログラムを実行することにより形成される。これら位置決定部Ｆ３１０と配車処理部Ｆ３２０と情報生成部Ｆ３３０との組合せは、本開示に係る「制御部」に相当する。なお、位置決定部Ｆ３１０と配車処理部Ｆ３２０と情報生成部Ｆ３３０との何れか、又はその一部は、ハードウェア回路により形成されてもよい。

物理情報管理データベースＤ３１０と実績情報管理データベースＤ３２０とタクシー情報管理データベースＤ３３０とは、プロセッサ３０１により実行されるデータベース管理システム（Database Management System :DBMS）のプログラムで構築される。詳細には、
ＤＢＭＳのプログラムが、補助記憶部３０３に記憶されているデータを管理することで、上記３つのデータベースが構築される。物理情報管理データベースＤ３１０と実績情報管理データベースＤ３２０とタクシー情報管理データベースＤ３３０とは、例えば、リレーショナルデータベースである。

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

物理情報管理データベースＤ３１０は、タクシー１０への乗車が物理的に可能な場所と不可能な場所とを識別するための情報（物理情報）を格納する。斯様な情報は、エリア別に格納される。ここでいう「エリア」とは、タクシー配車サービスの営業地域を複数のエリアに分割した際の個々のエリアを示す。各エリアの大きさは、例えば、ユーザが徒歩で容易に移動することができる程度の大きさ（例えば、各エリアの最大移動距離が数メートルから数十メートル以内になる大きさ）に設定される。ここで、物理情報管理データベースＤ３１０に格納される情報の一構成例について、図５に基づいて説明する。図５は、物理情報管理データベースＤ３１０に格納される情報のテーブル構成を例示する図である。なお、物理情報管理データベースＤ３１０に格納されるテーブル（以下、「物理情報テーブル」と記す場合もある。）の構成は、図５に示す例に限定されるものではなく、適宜フィールドの追加、変更、又は削除が可能である。

図５に示す物理情報テーブルは、エリアＩＤと、物理情報と、の各フィールドを有する。エリアＩＤフィールドには、上記営業地域内の各エリアを識別するための情報（エリアＩＤ）が登録される。エリアＩＤフィールドに登録されるエリアＩＤは、上記営業地域を複数のエリアに分割した際に、各エリアに割り当てられた識別情報である。物理情報フィールドには、各エリアの道路地図情報が登録される。物理情報フィールドに登録される道路地図情報では、歩道と車道との間に仕切りが設置されている場所、及び駐停車禁止場所のマーキングが為されている。ここでいう「仕切り」とは、ガードレール又は植え込み等のように、歩道と車道とを隔てる構造物であって、ユーザが歩道から車道へ移動することを阻止し得る構造物である。図５に示す物理情報テーブルによれば、各エリア内の道路において、タクシー１０への乗車が物理的に可能な場所と不可能な場所とを識別することができる。本例において、タクシー１０への乗車が物理的に可能な場所とは、歩道と車道との間に仕切りが設置されておらず、且つ駐停車禁止場所に臨んでいない場所である。また、タクシー１０への乗車が物理的に不可能な場所とは、歩道と車道との間に仕切りが設置されている場所、又は駐停車禁止場所に臨む場所である。なお、物理情報フィールドに登録される情報は、タクシー１０への乗車が物理的に可能な場所と不可能な場所とを識別することができる情報であれば、道路地図情報に限定されない。

実績情報管理データベースＤ３２０は、実際にタクシー１０への乗車またはタクシー１０からの降車が行われた場所に関する情報（実績情報）を格納する。斯様な情報は、上記営業地域内のエリア別に格納される。ここで、実績情報管理データベースＤ３２０に格納される情報の一構成例について、図６に基づいて説明する。図６は、実績情報管理データベースＤ３２０に格納される情報のテーブル構成を例示する図である。なお、実績情報管理データベースＤ３２０に格納されるテーブル（以下、「実績情報テーブル」と記す場合もある。）の構成は、図６に示す例に限定されるものではなく、適宜フィールドの追加、変更、又は削除が可能である。

図６に示す実績情報テーブルは、エリアＩＤと、実績場所と、実績回数と、の各フィールドを有する。エリアＩＤフィールドには、上記営業地域内の各エリアを識別するための
エリアＩＤが登録される。実績情報テーブルのエリアＩＤフィールドに登録される情報は、物理情報テーブルのエリアＩＤフィールドに登録される情報と同様である。実績場所フィールドには、各エリア内で実際にタクシー１０への乗車およびまたはタクシー１０からの降車が行われた場所（実績場所）に関する情報（例えば、住所、又は地図上の座標（緯度・経度）等）が登録される。実績回数フィールドには、各実績場所において実際にタクシー１０への乗車およびまたはタクシー１０からの降車が行われた回数を示す情報が登録される。なお、複数の実績場所が存在するエリアについては、そのエリアのエリアＩＤに対して複数の実績場所フィールド及び実績回数フィールドが紐付けられる。

タクシー情報管理データベースＤ３３０は、各タクシー１０（空車状態にある各タクシー１０）の位置情報を格納する。タクシー情報管理データベースＤ３３０では、各タクシー１０の識別情報と各タクシー１０の現時位置との紐付が行われている。ここで、タクシー情報管理データベースＤ３３０に格納される情報の一構成例について、図７に基づいて説明する。図７は、タクシー情報管理データベースＤ３３０に格納される情報のテーブル構成を例示する図である。なお、タクシー情報管理データベースＤ３３０に格納されるテーブル（以下、「タクシー情報テーブル」と記す場合もある。）の構成は、図７に示す例に限定されるものではなく、適宜フィールドの追加、又は変更、又は削除が可能である。

図７に示すタクシー情報テーブルは、車両ＩＤと、現在位置と、の各フィールドを有する。車両ＩＤフィールドには、サーバ装置３００の管理下にあるタクシー１０を個々に識別するための情報（車両ＩＤ）が登録される。現在位置フィールドには、各タクシー１０の現在位置を示す情報が登録される。現在位置フィールドに登録される情報は、例えば、各タクシー１０が位置する場所の住所を示す情報であってもよく、又は各タクシー１０が位置する場所の地図上の座標を示す情報でもよい。現在位置フィールドに登録される情報は、所定の周期毎に各タクシー１０の車載装置１００から送信される位置情報をサーバ装置３００が受信する度に更新される。

位置決定部Ｆ３１０は、ユーザ端末２００からの配車要求信号をサーバ装置３００の通信部３０４が受信したことをトリガにして、推奨乗車位置を決定する。推奨乗車位置は、前述したように、タクシー１０の乗車に適した場所である。斯様な推奨乗車位置を決定するにあたり、位置決定部Ｆ３１０は、先ず、希望乗車位置がタクシー１０の乗車場所に適しているかを判定する。具体的には、位置決定部Ｆ３１０は、希望乗車位置が属するエリア（所定エリア）を特定する。位置決定部Ｆ３１０は、上記物理情報管理データベースＤ３１０にアクセスして、所定エリアに対応する物理情報テーブルを特定する。位置決定部Ｆ３１０は、特定された物理情報テーブルの物理情報フィールドに登録されている道路地図情報を抽出する。そして、位置決定部Ｆ３１０は、抽出された道路地図情報と希望乗車位置とを照合することで、希望乗車位置におけるタクシー１０への乗車が物理的に可能であるかを判定する。その際、歩道と車道とを隔てる仕切りが希望乗車位置に設置されておらず、且つ希望乗車位置が駐停車禁止場所に臨んでいなければ、希望乗車位置におけるタクシー１０への乗車が物理的に可能であると判定する。希望乗車位置におけるタクシー１０への乗車が物理的に可能であると判定された場合、位置決定部Ｆ３１０は、希望乗車位置が臨む車道に駐車車両が存在するかを判定する。斯様な判定処理は、例えば、道路に設置されている監視カメラで撮影された画像データ、又は希望乗車位置の近傍を走行しているタクシー１０のドライブレコーダで撮影された画像データ等に基づいて行われる。なお、上記した画像データ等の情報は、外部のサービスを利用して取得されてもよい。そして、希望乗車位置が臨む車道に駐車車両が存在しないと判定された場合は、希望乗車位置がタクシー１０の乗車場所に適していると判定される。その場合、位置決定部Ｆ３１０は、希望乗車位置を推奨乗車位置に決定する。

なお、希望乗車位置がタクシー１０の乗車場所に適しているかの判定は、上記した条件
に加え、以下に示す２つの条件のうち、少なくとも１つを加味して行われてもよい。すなわち、上記した条件が成立しており、且つ以下に示す２つの条件のうち、少なくとも１つが成立している場合に、希望乗車位置がタクシー１０の乗車場所に適していると判定されてもよい。
（条件１）希望乗車位置のアクセス路で渋滞が発生していない
（条件２）希望乗車位置のアクセス路で交通規制が行われていない

なお、希望乗車位置のアクセス路における渋滞及び交通規制に関する情報は、例えば、アクセス路の近傍を走行しているタクシー１０の運転者から提供されてもよく、又は外部のサービス（例えば、道路交通情報を提供するサービス）を利用して取得されてもよい。

また、希望乗車位置におけるタクシー１０への乗車が物理的に不可能であると判定された場合、又は希望乗車位置が臨む車道に駐車車両が存在すると判定された場合は、希望乗車位置がタクシー１０の乗車場所に適していないと判定される。その場合、位置決定部Ｆ３１０は、希望乗車位置以外の場所を推奨乗車位置に決定する。本例では、所定エリア内において歩道と車道との間に仕切りがなく、且つ駐停車禁止場所に臨んでおらず、且つ駐車車両が存在しない場所（乗車可能場所）のうち、実績回数が最も多い場所が、推奨乗車位置に決定される。斯様な推奨乗車位置を決定するにあたり、位置決定部Ｆ３１０は、先ず、実績情報管理データベースＤ３２０へアクセスして、所定エリアに対応する実績情報テーブルを特定する。続いて、位置決定部Ｆ３１０は、特定された実績情報テーブルの実績回数フィールドに登録されている情報に基づいて、実績回数が最も多い場所（以下、「第１候補」と記す場合もある。）を特定する。位置決定部Ｆ３１０は、所定エリアの道路地図情報と第１候補とを照合することで、第１候補におけるタクシー１０への乗車が物理的に可能であるかを判定する。第１候補におけるタクシー１０への乗車が物理的に可能であると判定された場合は、位置決定部Ｆ３１０は、第１候補が臨む車道に駐車車両が存在するかを判定する。第１候補が臨む車道に駐車車両が存在しないと判定されると、位置決定部Ｆ３１０が、第１候補を推奨乗車位置に決定する。なお、第１候補におけるタクシー１０への乗車が物理的に不可能であると判定された場合、又は第１候補が臨む車道に駐車車両が存在すると判定された場合は、位置決定部Ｆ３１０は、第１候補の次に実績回数が多い場所（以下、「第２候補」と記す場合もある。）を特定する。そして、位置決定部Ｆ３１０は、第２候補に対して、第１候補に対する一連の判定処理と同様の処理を行う。斯様な一連の判定処理は、実績情報に基づいて選出された候補が乗車可能場所であると判定されるまで、繰り返し実行される。斯様な手順でタクシー１０の乗車場所に適した場所が特定されると、その場所が推奨乗車位置に決定される。これにより、所定エリア内における乗車可能場所のうち、実績回数が最も多い場所が、推奨乗車位置に決定される。

配車処理部Ｆ３２０は、位置決定部Ｆ３１０により決定された推奨乗車位置に基づいて、タクシー１０の配車処理を行う。配車処理では、配車処理部Ｆ３２０が、先ず、配車対象のタクシー１０を決定する。本例では、配車処理部Ｆ３２０は、推奨乗車位置に最も近い場所に位置するタクシー１０を、配車対象に決定する。具体的には、配車処理部Ｆ３２０は、タクシー情報管理データベースＤ３３０へアクセスして、タクシー情報テーブルの現在位置フィールドに登録されている現在位置が推奨乗車位置に最も近いタクシー情報テーブルを特定する。配車処理部Ｆ３２０は、特定されたタクシー情報テーブルの車両ＩＤフィールドに登録されている車両ＩＤを抽出する。そして、配車処理部Ｆ３２０は、抽出された車両ＩＤにより識別されるタクシー１０を、配車対象に決定する。なお、配車対象のタクシー１０を決定する方法は、上記した方法に限定されない。例えば、各タクシー１０の現在位置から推奨乗車位置へ至る経路の渋滞情報及び交通規制情報等に基づいて、各タクシー１０が推奨乗車位置に到着する予定時間を演算（予測）し、その予定時間が最も早いタクシー１０を配車対象に決定してもよい。

配車対象のタクシー１０が決定されると、配車処理部Ｆ３２０は、該タクシー１０の現在位置から推奨乗車位置までの走行予定経路を決定する。例えば、配車処理部Ｆ３２０は、現在位置から推奨乗車位置へ至る経路のうち、推奨乗車位置への到着予定時間が最も早い経路を、走行予定経路に決定する。

配車対象のタクシー１０の走行予定経路が決定されると、配車処理部Ｆ３２０は、配車指令を生成する。本例における配車指令は、配車対象のタクシー１０の車載装置１００に、走行予定経路に従った経路案内を行わせるための指令であり、推奨乗車位置に関する情報、及び走行予定経路に関する情報を含む。配車処理部Ｆ３２０により生成される配車指令は、通信部３０４を通じて、配車対象のタクシー１０の車載装置１００へ送信される。

情報生成部Ｆ３３０は、乗車位置情報を生成する。乗車位置情報は、推奨乗車位置でタクシー１０の到着に待機することを、ユーザに促すための情報である。斯様な乗車位置情報は、配車要求を受諾したことをユーザに通知する機能も有する。斯様な乗車位置情報は、配車対象のタクシー１０の到着予定時間に関する情報を更に含んでもよい。情報生成部Ｆ３３０により生成される乗車位置情報は、通信部３０４を通じて、ユーザ端末２００へ送信される。

（処理の流れ）
次に、本例におけるサーバ装置３００で行われる処理フローについて図８に基づいて説明する。図８は、ユーザ端末２００からの配車要求信号を受信したことをトリガにして、サーバ装置３００で行われる処理フローを示すフローチャートである。

図８では、ユーザ端末２００から送信される配車要求信号を、サーバ装置３００の通信部３０４が受信すると（ステップＳ１０１）、位置決定部Ｆ３１０が、希望乗車位置がタクシー１０の乗車場所に適しているかを判定する（ステップＳ１０２）。具体的には、位置決定部Ｆ３１０は、前述したように、希望乗車位置が属するエリア（所定エリア）を特定し、該所定エリアの道路地図情報を物理情報管理データベースＤ３１０から抽出する。そして、位置決定部Ｆ３１０は、抽出された道路地図情報と希望乗車位置とを照合することで、希望乗車位置におけるタクシー１０への乗車が物理的に可能であるか判定する。希望乗車位置におけるタクシー１０への乗車が物理的に可能であると判定されると、位置決定部Ｆ３１０は、希望乗車位置が臨む車道に駐車車両が存在するかを判定する。希望乗車位置が臨む車道に駐車車両が存在しないと判定されると、位置決定部Ｆ３１０は、希望乗車位置がタクシー１０の乗車場所に適していると判定する（ステップＳ１０２で肯定判定）。その場合、位置決定部Ｆ３１０は、希望乗車位置を推奨乗車位置に決定する（ステップＳ１０３）。

また、希望乗車位置におけるタクシー１０への乗車が物理的に不可能であると判定された場合、又は希望乗車位置が臨む車道に駐車車両が存在すると判定された場合は、位置決定部Ｆ３１０は、希望乗車位置がタクシー１０の乗車場所に適していないと判定する（ステップＳ１０２で否定判定）。その場合、位置決定部Ｆ３１０は、希望乗車位置以外の場所を推奨乗車位置に決定する（ステップＳ１０４）。具体的には、位置決定部Ｆ３１０は、前述したように、実績情報管理データベースＤ３２０に格納されている実績情報と物理情報管理データベースＤ３１０に格納されている物理情報とに基づいて、所定エリア内の乗車可能場所のうち、実績回数が最も多い場所を特定する。すなわち、位置決定部Ｆ３１０は、所定エリアに対応する実績情報テーブルの実績場所フィールド及び実績回数フィールドに登録されている情報に基づいて、実績回数が最も多い場所（第１候補）を特定する。続いて、位置決定部Ｆ３１０は、所定エリアに対応する物理情報テーブルの物理情報フィールドに登録されている道路地図情報と第１候補とを照合することで、第１候補におけるタクシー１０への乗車が物理的に可能であるかを判定する。第１候補におけるタクシー
１０への乗車が物理的に可能であると判定されると、位置決定部Ｆ３１０は、第１候補が臨む車道に駐車車両が存在するかを判定する。第１候補が臨む車道に駐車車両が存在しないと判定されると、位置決定部Ｆ３１０は、第１候補を推奨乗車位置に決定する。なお、第１候補におけるタクシー１０への乗車が物理的に不可能であると判定された場合、又は第１候補が臨む車道に駐車車両が存在すると判定された場合は、第１候補の次に実績回数が多い場所（第２候補）を特定する。そして、位置決定部Ｆ３１０は、第２候補に対して、第１候補に対する一連の判定処理と同様の処理を行う。斯様な一連の判定処理は、実績情報に基づいて選出される候補が乗車可能場所であると判定されるまで、繰り返し実行される。斯様な手順でタクシー１０の乗車場所に適した場所が特定されると、その場所が推奨乗車位置に決定される。

ステップＳ１０３又はＳ１０４で決定された推奨乗車位置に関する情報は、位置決定部Ｆ３１０から配車処理部Ｆ３２０へ渡される。配車処理部Ｆ３２０は、上記推奨乗車位置に基づいて、配車対象のタクシー１０を決定する（ステップＳ１０５）。その際、配車処理部Ｆ３２０は、前述したように、タクシー情報管理データベースＤ３３０に格納されている情報に基づいて、上記推奨乗車位置から最も近い場所に位置するタクシー１０を特定する。そして、配車処理部Ｆ３２０は、特定されたタクシー１０を、配車対象のタクシー１０に決定する。

配車対象のタクシー１０が決定されると、配車処理部Ｆ３２０が、配車指令を生成する（ステップＳ１０６）。具体的には、配車処理部Ｆ３２０は、前述したように、配車対象のタクシー１０の現在位置から推奨乗車位置までの走行予定経路を決定する。続いて、配車処理部Ｆ３２０は、推奨乗車位置と走行予定経路とに基づいて、配車指令を生成する。配車指令は、配車対象のタクシー１０の車載装置１００に、走行予定経路に従った経路案内を行わせるための指令であって、推奨乗車位置に関する情報及び走行予定経路に関する情報を含む指令である。配車処理部Ｆ３２０により生成される配車指令は、通信部３０４を通じて、配車対象のタクシー１０の車載装置１００へ送信される（ステップＳ１０７）。

また、ステップＳ１０３又はＳ１０４で決定された推奨乗車位置に関する情報は、位置決定部Ｆ３１０から情報生成部Ｆ３３０へも渡される。情報生成部Ｆ３３０は、上記推奨乗車位置に基づいて、乗車位置情報を生成する（ステップＳ１０８）。乗車位置情報は、前述したように、推奨乗車位置でタクシー１０の到着に待機することを、ユーザに促すための情報である。情報生成部Ｆ３３０により生成される乗車位置情報は、ユーザ端末２００へ送信される（ステップＳ１０９）。

図８の処理フローによれば、希望乗車位置を含むエリア内において、歩道と車道との間に仕切りがなく、且つ駐停車禁止場所に臨んでおらず、且つ駐車車両が存在しない場所（乗車可能場所）のうち、実績回数が最も多い場所が、推奨乗車位置に決定される。つまり、タクシー１０に乗車することが物理的に可能であり、且つタクシー１０がアクセスすることが可能であり、且つタクシー１０の乗り降りがし易い場所が、推奨乗車位置に決定される。これにより、ユーザの利便性が低下したり、又はタクシー１０の運転者の手間が増加したりすることが抑制される。その結果、タクシー１０を効率的に配車することが可能になる。

＜変形例１＞
前述した実施形態では、希望乗車位置がタクシー１０の乗車場所に適していないと判定された場合に、所定エリア内の乗車可能場所のうち、実績回数が最も多い場所を、推奨乗車位置に決定する例について述べた。これに対し、希望乗車位置がタクシー１０の乗車場所に適していないと判定された場合に、所定エリア内の乗車可能場所のうち、アクセス路
の渋滞が最も小さい場所を、推奨乗車位置に決定してもよい。

本変形例では、希望乗車位置がタクシー１０の乗車場所に適していないと判定された場合に、位置決定部Ｆ３１０が、所定エリア内の乗車可能場所を抽出する。位置決定部Ｆ３１０は、抽出された各乗車可能場所のアクセス路について渋滞情報を取得する。斯様な渋滞情報は、前述したように外部のサービスを利用して取得することができる。そして、位置決定部Ｆ３１０は、アクセス路の渋滞が最も小さい乗車可能場所を、推奨乗車位置に決定する。斯様にして決定される推奨乗車位置は、タクシー１０に乗車することが物理的に可能であり、且つタクシー１０が速やかにアクセスすることが可能な場所になる。

本変形例によれば、ユーザの待ち時間、及びタクシー１０の売上げに反映されない移動時間を可能な限り短く抑えつつ、ユーザをスムーズにタクシー１０に乗車させることが可能になる。

なお、希望乗車位置がタクシー１０の乗車場所に適していないと判定された場合に、アクセス路の渋滞情報に加え、アクセス路の交通規制の有無も考慮して、推奨乗車位置が決定されてもよい。その場合、位置決定部Ｆ３１０は、先ず、所定エリア内の乗車可能場所のうち、アクセス路で交通規制が行われていない乗車可能場所を抽出する。続いて、位置決定部Ｆ３１０は、抽出された乗車可能場所のうち、アクセス路の渋滞が最も小さい乗車可能場所を、推奨乗車位置に決定してもよい。これにより、ユーザの待ち時間、及びタクシー１０の売上げに反映されない移動時間をより確実に短く抑えつつ、ユーザをよりスムーズにタクシー１０に乗車させることが可能になる。

＜変形例２＞
前述した実施形態では、希望乗車位置がタクシー１０の乗車場所に適していないと判定された場合に、天候を考慮せずに、推奨乗車位置を決定する例について述べた。これに対し、希望乗車位置がタクシー１０の乗車場所に適していないと判定された場合に、天候を考慮して、推奨乗車位置を決定してもよい。

本変形例では、希望乗車位置がタクシー１０の乗車場所に適していないと判定された場合に、天候が悪ければ、位置決定部Ｆ３１０が、狭小エリア内の乗車可能場所の中から、推奨乗車位置を決定する。例えば、位置決定部Ｆ３１０は、上記狭小エリア内の乗車可能場所のうち、実績回数が最も多い場所、又はアクセス路の渋滞が最も小さい場所、又はアクセス路で交通規制が行われていない場所を、推奨乗車位置に決定する。ここでいう「狭小エリア」は、所定エリアよりも狭い範囲のエリアであって、希望乗車位置を含むエリアである。別法として、所定エリア内の乗車可能場所のうち、希望乗車位置から最も近い乗車可能場所が、推奨乗車位置に決定されてもよい。なお、希望乗車位置がタクシー１０の乗車場所に適していないと判定された場合に、天候が良ければ、前述の実施形態又は変形例１と同様の方法により推奨乗車位置が決定されてもよい。なお、ここでいう「天候が悪い」とは、例えば、雨が降っている、雪が降っている、又は強風が吹いている等の状態をいう。

本変形例によれば、希望乗車位置がタクシー１０の乗車場所に適していないと判定された場合に、悪天候の中でユーザが移動する距離を、可能な限り小さく抑えることができる。

＜変形例３＞
ここで、鉄道の運転見合せ又は遅延等が発生した場合は、駅周辺に位置する複数のユーザによって同じ時間帯に配車要求が行われる可能性がある。また、スポーツ等の競技、コンサート、展示会、又は祭事等の集会が開催される場合も、集会場周辺に位置する複数の
ユーザによって同じ時間帯に配車要求が行われる可能性がある。これらの場合、所定エリア内に希望乗車位置が含まれる複数の配車要求信号を、同じ時間帯にサーバ装置３００が受信することになる。そして、複数の配車要求信号のうち、少なくとも２つの配車要求信号に対する推奨乗車位置が重複すると、ユーザをスムーズにタクシー１０へ乗車させることが難しくなる可能性がある。

そこで、本変形例では、所定エリア内に希望乗車位置が含まれる複数の配車要求信号を、同じ時間帯にサーバ装置３００が受信した場合に、位置決定部Ｆ３１０が、複数の配車要求信号に対する推奨乗車位置を、互いに異なる場所に決定してもよい。例えば、希望乗車位置がタクシー１０の乗車場所に適していると判定された場合は、位置決定部Ｆ３１０は、該希望乗車位置が他の配車要求信号に対する推奨乗車位置に設定中であるかを判定する。すなわち、他の配車要求信号に係るユーザが当該希望乗車位置で待機中であるかの判定が行われる。そして、当該希望乗車位置が他の配車要求信号に対する推奨乗車位置に設定中であれば、位置決定部Ｆ３１０は、当該希望乗車位置とは異なる場所（例えば、所定エリア内の乗車可能場所の中で実績回数の最も多い場所）を、推奨乗車位置に決定する。また、希望乗車位置がタクシー１０の乗車場所に適していないと判定された場合は、所定エリア内の乗車可能場所の中で実績回数の最も多い場所が特定された際に、当該場所が他の配車要求信号に対する推奨乗車位置に設定中であるかを判定する。そして、当該場所が他の配車要求信号の推奨乗車位置に設定中であれば、位置決定部Ｆ３１０は、当該場所とは異なる場所（例えば、当該場所の次に実績回数の多い場所）を、推奨乗車位置に決定してもよい。

本変形例によれば、所定エリア内に希望乗車位置が含まれる複数の配車要求信号を、同じ時間帯にサーバ装置３００が受信した場合に、それら複数の配車要求信号に対する推奨乗車位置が重複することを抑制することができる。すなわち、それら複数の配車要求信号に対する推奨乗車位置を分散させることができる。その結果、複数の配車要求信号に係る複数のユーザの各々を、配車対象のタクシー１０へスムーズに乗車させることが可能になる。

＜変形例４＞
また、ユーザ端末２００から送信される配車要求信号には、ユーザの希望する目的地（降車位置）に関する情報が含まれる場合がある。その場合、所定エリアから上記目的地へかけてタクシー１０が走行するのに適した車線の向きを考慮して、推奨乗車位置が決定されてもよい。

本変形例では、推奨乗車位置を決定する際に、先ず、希望乗車位置におけるタクシー１０の乗車が物理的に可能であるかの判定、及び希望乗車位置が臨む車道に駐車車両が存在するかの判定に加え、希望乗車位置が臨む車線が適正車線であるかの判定が行われる。ここでいう「適正車線」は、所定エリアから目的地へかけてタクシー１０が走行するのに適した向きの車線である。希望乗車位置におけるタクシー１０への乗車が物理的に可能であり、且つ希望乗車位置が臨む車道に駐車車両が存在せず、且つ希望乗車位置の臨む車線が適正車線であれば、位置決定部Ｆ３１０が、希望乗車位置を推奨乗車位置に決定する。一方、上記した３つの条件のうち、少なくとも１つが成立しなければ、位置決定部Ｆ３１０は、希望乗車位置以外の場所を推奨乗車位置に決定する。例えば、位置決定部Ｆ３１０は、所定エリア内における乗車可能場所のうち、適正車線に臨む場所を、推奨乗車位置に決定する。その際、適正車線に臨む乗車可能場所が複数箇所ある場合は、実績回数が最も多い場所、アクセス路の渋滞が最も小さい場所、アクセス路で交通規制が行われていない場所、又は希望乗車位置から最も近い場所が、推奨乗車位置に決定されてもよい。

本変形例によれば、ユーザの乗車後にタクシー１０を転回（Ｕターン）させる等の手間
がかからなくなるため、乗車料金の不要な増加を抑えることができる。

＜変形例５＞
また、希望乗車位置の近辺の施設において、スポーツ等の競技、コンサート、展示会、又は祭事等の集会が開催される場合も想定される。斯様な場合、タクシーへの乗車を希望する人が希望乗車位置の近辺に集中する可能性がある。それに伴い、希望乗車位置の近辺に多数のタクシーが集まる可能性がある。その結果、配車対象のタクシー１０が希望乗車位置へ速やかにアクセスすることができなくなったり、又はユーザが配車対象のタクシー１０へスムーズに乗車することができなくなったりする可能性がある。そこで、本変形例では、希望乗車位置の近辺の施設で集会が開催されている場合は、臨時実績場所の中から推奨乗車位置が決定されるようにした。ここでいう「臨時実績場所」は、上記施設で集会が開催された期間において、実際にタクシー１０への乗車およびまたはタクシー１０からの降車が行われた場所である。

（サーバ装置の機能構成）
ここで、本変形例におけるサーバ装置３００の機能構成について、図９に基づいて説明する。図９に示すように、本変形例におけるサーバ装置３００は、その機能構成要素として、位置決定部Ｆ３１０、配車処理部Ｆ３２０、情報生成部Ｆ３３０、物理情報管理データベースＤ３１０、実績情報管理データベースＤ３２０、及びタクシー情報管理データベースＤ３３０に加え、臨時情報管理データベースＤ３４０を含む。

臨時情報管理データベースＤ３４０は、ＤＢＭＳのプログラムが、補助記憶部３０３に記憶されているデータを管理することで構築される、リレーショナルデータベースである。臨時情報管理データベースＤ３４０は、本開示に係る「記憶部」に相当するものであり、イベントホール、広場、競技場、又は展示場等の施設で集会が開催された期間における臨時実績場所に関する情報を格納する。臨時情報管理データベースＤ３４０では、各施設と臨時実績場所との紐付けが行われている。ここで、臨時情報管理データベースＤ３４０に格納される情報の一構成例について、図１０に基づいて説明する。図１０は、臨時情報管理データベースＤ３４０に格納される情報のテーブル構成を例示する図である。なお、臨時情報管理データベースＤ３４０に格納されるテーブル（以下、「臨時実績情報テーブル」と記す場合もある。）の構成は、図１０に示す例に限定されるものではなく、適宜フィールドの追加、変更、又は削除が可能である。

図１０に示す臨時実績情報テーブルは、エリアＩＤと、施設と、臨時実績場所と、実績回数と、の各フィールドを有する。エリアＩＤフィールドには、上記営業地域内の各エリアを識別するためのエリアＩＤが登録される。臨時実績情報テーブルのエリアＩＤフィールドに登録される情報は、物理情報テーブルのエリアＩＤフィールドに登録される情報、及び実績情報テーブルのエリアＩＤフィールドに登録される情報と同様である。施設フィールドには、各エリア内に存在する施設を識別するための情報（例えば、施設名等）が登録される。なお、複数の施設が存在するエリアについては、そのエリアのエリアＩＤに対して複数の会場フィールドが紐付けられる。臨時実績場所フィールドには、各施設の臨時実績場所に関する情報（例えば、住所、又は地図上の座標等）が登録される。実績回数フィールドには、各臨時実績場所において実際にタクシー１０への乗車およびまたはタクシー１０からの降車が行われた回数を示す情報が登録される。なお、複数の臨時実績場所が存在する施設については、その施設の施設フィールドに対して複数の臨時実績場所フィールド及び実勢回数フィールドが紐付けられる。

次に、本変形例における位置決定部Ｆ３１０は、推奨乗車位置を決定するにあたり、先ず、希望乗車位置を含む所定エリア内の施設で集会が開催されているかを判定する。上記施設において集会が開催されているかの判定は、上記施設の集会開催スケジュールに基づ
いて行われてもよい。集会開催スケジュールは、上記施設のホームページ等から取得されてもよく、又は各施設の集会開催スケジュールを提供するための外部サービスを利用して取得されてもよい。

ここで、上記施設で集会が開催されていないと判定された場合は、位置決定部Ｆ３１０は、前述の実施形態、又は変形例１から４の何れかと同様の方法によって推奨乗車位置を決定すればよい。一方、上記施設で集会が開催されていると判定された場合は、位置決定部Ｆ３１０は、臨時情報管理データベースＤ３４０にアクセスすることで、上記施設に紐付けられている臨時実績場所のうち、実績回数が最も多い臨時実績場所を抽出する。そして、位置決定部Ｆ３１０は、抽出された臨時実績場所を、推奨乗車位置に決定する。別法として、上記施設に紐付けられている臨時実績場所のうち、アクセス路の渋滞が最も小さい臨時実績場所が、推奨乗車位置に決定されてもよい。また、上記施設に紐付けられている臨時実績場所のうち、アクセス路で交通規制が行われていない臨時実績場所が、推奨乗車位置に決定されてもよい。また、上記施設に紐付けられている臨時実績場所のうち、希望乗車位置から最も近い臨時実績場所が、推奨乗車位置に決定されてもよい。

（処理の流れ）
次に、本変形例におけるサーバ装置３００で行われる処理フローについて図１１に基づいて説明する。図１１は、ユーザ端末２００からの配車要求信号を受信したことをトリガにして、サーバ装置３００で行われる処理フローを示すフローチャートである。なお、図１１中において、前述の図９と同様の処理については同一の符号が付されている。

図１１では、ユーザ端末２００から送信される配車要求信号を、サーバ装置３００の通信部３０４が受信すると（ステップＳ１０１）、位置決定部Ｆ３１０が、所定エリア内の施設において集会が開催されているかを判定する（ステップＳ２０１）。その際、位置決定部Ｆ３１０は、前述したように、所定エリア内の施設の集会開催スケジュールに基づいて、該施設において集会が開催されているかを判定する。所定エリア内の施設で集会が開催されていない場合（ステップＳ２０１で否定判定）は、位置決定部Ｆ３１０は、ステップＳ１０２からＳ１０４の処理を実行する。すなわち、位置決定部Ｆ３１０は、前述の実施形態と同様の方法によって推奨乗車位置を決定する。そして、前述の実施形態と同様に、ステップＳ１０５からステップＳ１０９の処理が実行される。

また、所定エリア内の施設で集会が開催されている場合（ステップＳ２０１で肯定判定）は、位置決定部Ｆ３１０は、上記施設に紐付けられている臨時実績場所の中から推奨乗車位置を決定する（ステップＳ２０２）。具体的には、位置決定部Ｆ３１０は、前述したように、臨時情報管理データベースＤ３４０にアクセスすることで、上記施設に紐付けられている臨時実績場所のうち、実績回数が最も多い臨時実績場所を抽出する。そして、位置決定部Ｆ３１０は、抽出された臨時実績場所を、推奨乗車位置に決定する。ステップＳ２０２の処理が実行された後は、前述の実施形態と同様に、ステップＳ１０５からステップＳ１０９の処理が実行される。

本変形例によれば、所定エリア内で集会が開催されている期間においては、タクシー１０の乗り降りがし易く、且つタクシー１０がアクセスし易い場所が、推奨乗車位置に決定される。これにより、所定エリア内で集会が開催されている期間であっても、ユーザをスムーズにタクシー１０へ乗車させることが可能になる。

なお、所定エリア内の施設で集会が開催されている期間は、前述の変形例３で述べたように、所定エリア内に希望乗車位置が含まれる複数の配車要求信号を、同じ時間帯にサーバ装置３００が受信する可能性がある。よって、位置決定部Ｆ３１０により抽出された臨時実績場所が他の配車要求信号の推奨乗車位置に設定中であれば、抽出された臨時実績場
所とは異なる臨時実績場所が、推奨乗車位置に決定されてもよい。これにより、推奨乗車位置を分散させることができるため、ユーザをよりスムーズにタクシー１０へ乗車させることが可能になる。

＜その他＞
上記した実施形態及び変形例はあくまでも一例であって、本開示はその要旨を逸脱しない範囲内で適宜変更して実施し得る。例えば、上記した実施形態と変形例とは、可能な限り組み合わせて実施することもできる。

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

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

１０ タクシー
１００ 車載装置
２００ ユーザ端末
３００ サーバ装置
３０１ プロセッサ
３０２ 主記憶部
３０３ 補助記憶部
３０４ 通信部
Ｄ３１０ 物理情報管理データベース
Ｄ３２０ 実績情報管理データベース
Ｄ３３０ タクシー情報管理データベース
Ｄ３４０ 臨時情報管理データベース
Ｆ３１０ 位置決定部
Ｆ３２０ 配車処理部
Ｆ３３０ 情報生成部

Claims (10)

1. タクシーの配車を要求する信号であって、且つユーザの希望乗車位置に関する情報を含む信号である配車要求信号を、前記ユーザの使用する端末であるユーザ端末から受信することと、
   前記希望乗車位置を含む所定エリア内における道路の物理的条件に関する情報である物理情報と、前記所定エリア内におけるタクシーへの乗車およびまたはタクシーからの降車の実績に関する情報である実績情報と、前記所定エリア内の道路の状態に関する情報である道路情報と、の少なくとも一つに基づいて、推奨乗車位置を決定することと、
   前記推奨乗車位置で待機することを前記ユーザに促すための情報である乗車位置情報を、前記ユーザ端末へ送信することと、
   を実行する制御部を備え、
   前記物理情報は、前記所定エリア内において歩道と車道とを隔てる仕切りが設置されている場所に関する情報と、前記所定エリア内における駐停車禁止場所に関する情報と、の少なくとも１つを含み、
   前記実績情報は、前記所定エリア内において実際にタクシーへの乗車およびまたはタクシーからの降車が行われた場所である実績場所に関する情報と、前記実績場所で実際にタクシーへの乗車およびまたはタクシーからの降車が行われた回数である実績回数に関する情報と、を含み、
   前記道路情報は、前記所定エリア内における道路の渋滞情報と、前記所定エリア内における駐車車両の有無に関する情報と、前記所定エリア内における道路の規制に関する情報と、前記所定エリア内における集会の開催有無に関する情報と、の少なくとも１つを含み、
   前記制御部は、
   前記物理情報と前記実績情報と前記道路情報との少なくとも一つに基づいて、前記希望乗車位置がタクシーの乗車場所に適しているかを判定することと、
   前記希望乗車位置がタクシーの乗車場所に適していると判定された場合に、前記希望
   乗車位置を前記推奨乗車位置に決定することと、
   前記希望乗車位置がタクシーの乗車場所に適していないと判定された場合に、車道との間に仕切りがなく、且つ駐停車禁止場所に臨んでおらず、且つ駐車車両が存在しない場所である乗車可能場所のうち、前記実績回数が最も多い場所を、前記推奨乗車位置に決定することと、
   を実行する、
   情報処理装置。
2. 前記希望乗車位置がタクシーの乗車場所に適していないと判定された場合に、前記制御部は、車道との間に仕切りがなく、且つ駐停車禁止場所に臨んでおらず、且つ駐車車両が存在しない場所である乗車可能場所のうち、道路の渋滞が最も小さい場所を、前記推奨乗車位置に決定する、
   請求項１に記載の情報処理装置。
3. 前記制御部は、悪天候の場合は好天候の場合に比べ、前記希望乗車位置により近い前記乗車可能場所の中から、前記推奨乗車位置を決定する、
   請求項１又は２に記載の情報処理装置。
4. 前記所定エリア内に希望乗車位置が含まれる複数の配車要求信号を、同じ時間帯に受信した場合に、前記制御部は、複数の配車要求信号に対する推奨乗車位置を、互いに異なる場所に決定する、
   請求項１から３の何れか１項に記載の情報処理装置。
5. 前記配車要求信号は、ユーザの希望する目的地に関する情報を更に含み、
   前記制御部は、前記物理情報と前記実績情報と前記道路情報との少なくとも１つに加え、前記所定エリアから前記目的地へかけてタクシーが走行するのに適した車線の向きに基づいて、前記推奨乗車位置を決定する、
   請求項１から４の何れか１項に記載の情報処理装置。
6. 前記所定エリア内で集会を開催可能な施設と、該施設で集会が開催された期間に実際にタクシーへの乗車およびまたはタクシーからの降車が行われた場所である臨時実績場所と、を関連付けて記憶する記憶部を更に備え、
   前記施設で集会が開催されている期間においては、前記制御部は、前記臨時実績場所の中から前記推奨乗車位置を決定する、
   請求項１から５の何れか１項に記載の情報処理装置。
7. タクシーの配車を要求する信号であって、且つユーザの希望乗車位置に関する情報を含む信号である配車要求信号を、前記ユーザの使用する端末であるユーザ端末から受信するステップと、
   前記希望乗車位置を含む所定エリア内における道路の物理的条件に関する情報である物理情報と、前記所定エリア内におけるタクシーへの乗車およびまたはタクシーからの降車の実績に関する情報である実績情報と、前記所定エリア内の道路の状態に関する情報である道路情報と、の少なくとも一つに基づいて、推奨乗車位置を決定するステップと、
   前記推奨乗車位置で待機することを前記ユーザに促すための情報である乗車位置情報を、前記ユーザ端末へ送信するステップと、
   をコンピュータが実行する情報処理方法であって、
   前記物理情報は、前記所定エリア内において歩道と車道とを隔てる仕切りが設置されている場所に関する情報と、前記所定エリア内における駐停車禁止場所に関する情報と、の少なくとも１つを含み、
   前記実績情報は、前記所定エリア内において実際にタクシーへの乗車およびまたはタク
   シーからの降車が行われた場所である実績場所に関する情報と、前記実績場所で実際にタクシーへの乗車およびまたはタクシーからの降車が行われた回数である実績回数に関する情報と、を含み、
   前記道路情報は、前記所定エリア内における道路の渋滞情報と、前記所定エリア内における駐車車両の有無に関する情報と、前記所定エリア内における道路の規制に関する情報と、前記所定エリア内における集会の開催有無に関する情報と、の少なくとも１つを含み、
   前記推奨乗車位置を決定するステップは、
   前記物理情報と前記実績情報と前記道路情報との少なくとも一つに基づいて、前記希望乗車位置がタクシーの乗車場所に適しているかを判定するステップと、
   前記希望乗車位置がタクシーの乗車場所に適していると判定された場合に、前記希望乗車位置を前記推奨乗車位置に決定するステップと、
   前記希望乗車位置がタクシーの乗車場所に適していないと判定された場合に、車道との間に仕切りがなく、且つ駐停車禁止場所に臨んでおらず、且つ駐車車両が存在しない場所である乗車可能場所のうち、前記実績回数が最も多い場所を、前記推奨乗車位置に決定するステップと、
   を含む、
   情報処理方法。
8. 前記推奨乗車位置を決定するステップは、
   前記希望乗車位置がタクシーの乗車場所に適していないと判定された場合に、車道との間に仕切りがなく、且つ駐停車禁止場所に臨んでおらず、且つ駐車車両が存在しない場所である乗車可能場所のうち、渋滞が最も小さい場所を、前記推奨乗車位置に決定するステップを含む、
   請求項７に記載の情報処理方法。
9. 前記コンピュータは、前記所定エリア内で集会を開催可能な施設と、該施設で集会が開催された期間に実際にタクシーへの乗車およびまたはタクシーからの降車が行われた場所である臨時実績場所と、を関連付けて記憶する記憶部を備え、
   前記推奨乗車位置を決定するステップでは、前記施設で集会が開催されている期間における推奨乗車位置が、前記臨時実績場所の中から決定される、
   請求項７又は８に記載の情報処理方法。
10. 請求項７から９の何れか１項に記載の情報処理方法を、コンピュータに実行させるための情報処理プログラム。

Images