JP2020119441A - 配車プログラム及び配車システム - Google Patents

Abstract

【課題】相乗りの利用者及び提供者の利便性を向上することができる配車プログラム及び配車システムを提供することである。【解決手段】利用者が複数のルートの中から選択した利用ルートで車両に乗車することの予約を受け付ける乗車予約ステップと、前記乗車予約ステップで予約した利用者を利用者リストに登録する利用者リスト登録ステップと、前記利用者リストに登録された利用者のうち前記利用ルートが同一である利用者が所定人数に達した場合、前記利用ルートが同一である利用者を同一グループに登録するグループ化ステップと、前記グループ化ステップで同一グループに登録された利用者が予約した前記利用ルートの出発地点に車両の配車を指示する配車指示ステップと、前記グループ化ステップで同一グループに登録された利用者に、前記配車指示ステップで配車指示した車両を特定可能な車両番号を通知する車両番号通知ステップと、を実行させることを備えた。【選択図】図１

Description

本発明は、配車プログラム及び配車システムに関する。

従来、利用者が時間、場所を意識することなく簡便にタクシー等のサービスを受けることを目的とした送迎装置が知られている（特許文献１参照）。特許文献１に記載の送迎装置では、ＧＰＳ（グローバル ポジショニング システム）により利用者の位置情報を取得し、利用者の位置に基づいて、タクシー会社の選定、車両の選定を行う発明を開示している。

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

特許文献１に記載の発明によれば、ＧＰＳにより利用者個人の位置情報は取得できるものの、他の利用者の位置との連携については何ら考慮しておらず、課題として捉えてさえいないものであった。

例えば、最近の公共交通機関の利用に際しては、タクシー待ちをしている利用者同士が、自分たちの意思により申し合わせて同乗する相乗りが知られている。この相乗りによれば、利用者には、同乗した利用者で利用料金を分割することによって一人で利用する場合と比べて割安な料金で利用できるというメリットがある。

従来、相乗りの利用者は、日常的に相乗りが行われている場所に行っても、スムーズに相乗りができる仕組みがあるわけではなく、相乗りの同乗者が見つからない場合や、相乗りの同乗者が見つかってもタクシーが来ない場合があるという問題があった。また、タクシー側から見ても、相乗りの利用者の集まり具合がわからず、日常的に相乗りが行われている場所であっても正規の乗り場以外では客待ちをすることができないため、利用者がいない場合には他の場所に移動しなければならず、無駄足になってしまうという問題があった。

本発明は以上のような課題を解決するためになされたものであり、相乗りの利用者及び提供者の利便性を向上することができる配車プログラム及び配車システムを提供することを目的とする。

上記課題を解決するために、本発明は、コンピュータで実行される配車プログラムであって、前記配車プログラムは、前記コンピュータに、利用者が複数のルートの中から選択した利用ルートで車両に乗車することの予約を受け付ける乗車予約ステップと、前記乗車予約ステップで予約した利用者を利用者リストに登録する利用者リスト登録ステップと、前記利用者リストに登録された利用者のうち前記利用ルートが同一である利用者が所定人数に達した場合、前記利用ルートが同一である利用者を同一グループに登録するグループ化ステップと、前記グループ化ステップで同一グループに登録された利用者が予約した前記利用ルートの出発地点に車両の配車を指示する配車指示ステップと、前記グループ化ステップで同一グループに登録された利用者に、前記配車指示ステップで配車指示した車両を特定可能な車両番号を通知する車両番号通知ステップと、を実行させることを特徴とする。

本発明によれば、相乗りの利用者及び提供者の利便性を向上することができる配車プログラム及び配車システムを提供することができる。

本発明の実施例１に係る配車システムの構成を示すブロック図である。 配車システム１の動作の全体の流れを示すフローチャートである。 図２に示した乗車意思登録処理の詳細を示すフローチャートである。 図２に示した乗車意思再確認処理の詳細を示すフローチャートである。 図２に示した乗車処理の詳細を示すフローチャートである。 図２に示した料金精算処理の詳細を示すフローチャートである。 図１に示した配車システム１の動作におけるデータ送受信の流れを示すフローチャートであって、図２〜図６の処理とは別の例を示す図である。 同乗者によっては出発地点及び到着地点が他の同乗者と異なる場合であっても同一の利用ルートとする場合を説明する図である。

以下、本発明に係る配車システムについて、図面を参照しながら詳細に説明する。なお、以下に示す実施形態は本発明に係るシステムの好適な具体例であり、一般的なハードウェア、ソフトウェア構成に即した種々の限定を付している場合もあるが、本発明の技術範囲は、特に本発明を限定する記載がない限り、これらの態様に限定されるものではない。また、以下に示す実施形態における構成要素は、適宜、既存の構成要素等との置き換えが可能であり、かつ、他の既存の構成要素との組み合わせを含む様々なバリエーションが可能である。したがって、以下に示す実施形態の記載をもって、特許請求の範囲に記載された発明の内容を限定するものではない。

（配車システム１の構成）
図１は、本発明の実施例１に係る配車システムの構成を示すブロック図である。本実施例は、タクシーの配車を行う配車システムについて説明するが、本発明はこれに限られるものではなく、タクシー以外の如何なる乗り物、バスや船舶や航空機などを対象にするものであってもよい。配車システム１は、図１に示すように、システムの制御を行うサーバ２と、サーバ３と、タクシーの利用者が携帯する端末５、６及び７とを、ネットワーク４で接続して構成される。

端末５、６及び７は、スマートフォン、フィーチャーフォン、ＰＤＡ（Personal Digital Assistant）、又はタブレット型コンピュータ等の携帯端末であってよい。端末５、６及び７は、同様の構成であるので、以下では代表して端末５について説明する。端末５は、端末５全体の制御を行う制御部５１と、制御部５１で実行するプログラムや制御に必要なデータを記憶する記憶部５２と、ネットワーク４を介してサーバ２と通信する通信部５３と、各種入出力を行う入出力部５４と、を有して構成される。入出力部５４は、表示を行うとともに利用者による操作入力を受け付けるタッチパネルや、音声出力を行うスピーカ、音声入力を行うマイク、バーコードの撮影などの撮影を行う撮影部を含む。端末５は、端末５の位置を検出するためのＧＰＳ機能を有する。

サーバ２は、サーバ２全体の制御を行う制御部２１と、制御部２１で実行するプログラムや制御に必要なデータを記憶する記憶部２２と、ネットワーク４を介してサーバ３や端末５、６及び７と通信する通信部２３と、を有して構成される。サーバ２は、例えば、配車システム１を運営する事業者に設けられたサーバである。

サーバ３は、サーバ３全体の制御を行う制御部３１と、制御部３１で実行するプログラムや制御に必要なデータを記憶する記憶部３２と、ネットワーク４を介してサーバ２と通信する通信部３３と、を有して構成される。サーバ３は、例えば、タクシーの配車を実施するタクシー会社に設けられたサーバである。サーバ３は、制御部３１による処理経過をタクシー会社の社員に通知する通知部を有してもよい。

（配車システム１の動作説明）
次に、配車システム１の動作についてフローチャートを参照しながら説明する。図２は、配車システム１の動作の全体の流れを示すフローチャートである。図３は、図２に示した乗車意思登録処理の詳細を示すフローチャートである。図４は、図２に示した乗車意思再確認処理の詳細を示すフローチャートである。図５は、図２に示した乗車処理の詳細を示すフローチャートである。図６は、図２に示した料金精算処理の詳細を示すフローチャートである。

図２のステップＳ２０１では乗車意思登録処理を行う。図３を参照して乗車意思登録処理について説明する。配車システム１では、端末５を携帯する利用者に、タクシーの相乗り利用を提供する。サーバ２の制御部２は、利用者が利用可能なルートに関するルート情報を予め記憶部２２に登録している。ルート情報は、タクシー利用の出発地点（すなわち利用者の乗車地点）、タクシー利用の到着地点（すなわち利用者の降車地点）、及び出発地点から到着地点までの道順に関する情報を含む。

利用者は、端末５の制御部５１で配車システム１を構成するアプリケーションを実行し、サーバ２に対して予め利用者登録をしておく。この利用者登録は、端末５からサーバ２に送信した利用者情報を、記憶部２２内に記憶することで行われる。利用者情報は、少なくとも、利用者を特定可能な利用者ＩＤと、その利用者に対応付けられ配車システム１の利用の際に照合されるパスワードと、を含む。

利用者は、キャッシュレスでタクシー料金を電子決済可能な例えば電子タクシーチケットを提供するシステムである電子タクシーチケットシステムと契約していてもよく、配車システム１と電子タクシーチケットシステムとが連携することで、利用者にスムーズなタクシーの相乗り利用を提供することができる。

端末５の制御部５１で配車システム１を構成するアプリケーションが実行されると、サーバ２から端末５へルート情報が送信される。端末５は、受信したルート情報を利用者に向けて表示する。この表示は、配車システム１が予め設定した、配車システム１がタクシーの相乗り乗車を提供するルートである。なお、利用者が、予め端末５を操作して、配車システム１が提供するルートのうち自身がよく利用するルートをお気に入りルートとしてサーバ２の記憶部２２に登録しておくことで、端末５がお気に入りルートを表示可能な構成としてもよい。

配車システム１がタクシーの相乗り乗車を提供するルートは、一つでも複数でもよいが、利用者の需要に応じて複数用意するのが望ましい。配車システム１が提供するルートを、予め設定したルートにしているのは、過去の実績調査に基づき、相乗り利用者が多数であることが確認できたルートを利用者に提供することで、出発地点に行っても同乗者が集まらないなどの不都合を低減するためである。

利用者は、携帯する端末５に表示されたルート情報を参照し、例えばお気に入りルートを参照し、端末５の入出力部５４を操作して、今回、タクシーの相乗り利用をするルートを選択する。この選択により利用者は、タクシーの相乗り利用について、利用者が選択した利用ルートで車両に乗車することの乗車意思を表示する。ルート選択を行う時期は、利用者がタクシーの相乗り利用をしようと思い立った時点以降の何時行ってもよく、例えば、家を出るときでもよい。

端末５は、利用者により選択されたルートのルート情報をサーバ２に送信する（ステップＳ３０１）。サーバ２は、端末５から受信したルート情報を利用者に関連付けて、記憶部２２に登録する（ステップＳ３０２）。続いて、サーバ２は、第１段階車両手配を行う。この第１段階車両手配は、利用者により選択されたルートの出発地点に配車依頼をする可能性が生じたことをタクシー会社に通知し、出発地点に短時間で配車可能なエリア（第２エリア）にタクシーを移動させることを依頼する（指示する）ものである。具体的には、サーバ２は、サーバ３に対して第１段階車両手配要求を送信する（ステップＳ３０３）。サーバ３は、第１段階車両手配要求を受信すると、タクシー会社の社員にその旨を通知してもよいし、直接タクシーにその旨を送信してもよい。タクシー会社の社員は、サーバ３が第１段階車両手配要求を受信したことを受けて、タクシーを第２エリア内に移動させるが否かを任意に判断することができる。タクシー会社にはタクシーを第２エリア内に移動させる義務はないが、受信した第１段階車両手配要求の出発地点においてタクシー相乗り利用の需要があることが予想されることから、タクシー会社の社員は、タクシーを第２エリア内に移動させることでその需要に迅速に対応することができる。タクシー会社の社員の判断によりタクシーを第２エリア内に移動させることとした場合、その移動させる台数は、過去の実績に基づいて決定してもよいし、第１段階車両手配要求の受信数に応じて決定してもよい。

続いて、図２のステップＳ２０２では乗車意思再確認処理を行う。図４を参照して乗車意思再確認処理について説明する。サーバ２は、端末５のＧＰＳ機能を利用して端末５の位置すなわち端末５を携帯する利用者の位置を取得可能である。ステップＳ４０１では、サーバ２は、端末５を携帯する利用者の位置を取得し、利用者の現在位置を確認する。サーバ２は、利用者の現在位置が、ステップＳ３０１で選択されたルートの出発地点の近傍である第１エリア、例えば出発地点の最寄り駅になったならば、利用者に対して乗車意思の再確認を行う。具体的には、サーバ２は、端末５に対して乗車意思再確認を送信する（ステップＳ４０２）。

第１エリアは第２エリアよりも狭いエリアである。このようにすることにより、第１エリアにいる利用者が出発地点に到達する時間（例えば徒歩を想定）と、第２エリアにいるタクシーが出発地点に到達する時間とを近づけ、利用者及びタクシー両者の出発地点での待ち時間を減らすことができる。

端末５は受信した乗車意思再確認を表示し、乗車意思再確認に対する利用者の操作を受け付ける。利用者が乗車意思再確認に対して乗車意思を示さなかった場合（例えば、乗車しない意思を示す操作をした場合）は、端末５は、その旨をサーバ２に通知し、これを受けたサーバ２では、その利用者に対する処理を終了する。利用者が乗車意思再確認に対して乗車意思を示した場合（例えば、乗車意思再確認に対して乗車する意思を示す操作をした場合）は、端末５は、その旨をサーバ２に通知し、これを受けたサーバ２は、第２段階車両手配を実施する。利用者が、乗車意思再確認に対して乗車する意思を示す操作をしたことは、利用者がタクシーの相乗り利用を予約したことになる。第１エリアは、例えば、出発地点を中心に半径２５０ｍ〜４００ｍの範囲、又は出発地点から徒歩３〜５分程度の距離のエリアとすることができる。

ステップＳ４０３の第２段階車両手配では、サーバ２は、ステップＳ４０２で所定時間内に乗車意思再確認に対して乗車する意思を示す操作をした利用者を、記憶部２２内の利用者リストに登録する。サーバ２は、利用者リストに登録された利用者のうち、同じルートを選択した利用者が所定数（タクシーに相乗りする人数）に達したならば、その所定数の利用者をグループ化するとともに、そのルートの出発地点にタクシーを配車するよう、サーバ３に対して第２段階車両手配要求を送信する（ステップＳ４０３）。

相乗り利用者が支払うタクシー料金は、１台のタクシー料金を同乗者の数で割った金額になるため、配車システム１では利用者が同乗者の数を指定することができる。利用者は、予め、同乗者が何人であれば相乗り利用をするかの許容同乗人数情報を端末５からサーバ２に送信し、サーバ２は、記憶部２２内の利用者情報内の利用者ＩＤに対応付けて記憶部２２内に許容同乗人数情報を登録しておく。

ステップＳ４０３において、サーバ２がグループ化する際には、記憶部２２内の許容同乗人数情報を参照し、利用者が指定した同乗者数でグループ化を行う。許容同乗人数情報としては、例えば、「同乗者が自分を含めてｎ人でなければ乗らない」、「同乗者が自分を含めてｎ人以下なら何人でもよい」、「同乗者が自分を含めてｎ人以上なら何人でもよい」（ｎは１以上の自然数であるが、５人乗りタクシーの場合にはｎは１以上且つ４以下である。）、などのように、条件付きで許容同乗人数を指定してもよい。なお、ｎ＝１の場合の利用例として、例えば「同乗者が自分を含めて１人以上なら何人でもよい」とすることで、相乗り相手が見つかればよりよいが、とにかく急いでいるので１人であっても早くタクシーに乗りたい場合に用いることができる。また、例えば「同乗者が自分を含めて１人でなければ乗らない」とすることで、タクシーの１人利用の場合にも配車システム１を利用することができる。例えば電車の乗り継ぎでタクシーを利用する場合に、従来は下車駅を出てからタクシーを探す必要があったが、配車システム１によれば、下車駅に着くとタクシーが配車されているという状況を提供することができる。このように、配車システム１によれば、電車とタクシーを組み合わせて目的地までの移動手段を提供するというＭａａＳ（モビリティ・アズ・ア・サービス）の実現手段の一つを提供することができる。許容同乗人数情報は、予め記憶部２２内に登録しておくものに限られず、利用者が、乗車意思再確認に対して乗車する意思を示す操作を行う際に、許容同乗人数情報を端末５に入力し、端末５が入力された許容同乗人数情報をサーバ２に送信することで、サーバ２は、ステップＳ４０のグループ化の際に、乗車意思再確認に応答して受信した許容同乗人数情報を参照し、利用者が指定した同乗者数でグループ化を行うようにしてもよい。許容同乗人数情報は「自分が出発地点に到着してからＮ分以内に同乗者が見つからなければ（グループ化されなければ）相乗り利用を辞退する」といった条件を登録可能にしてもよい。グループ化の進行状況（４人で相乗りする場合の２人目の同乗者が見つかった、４人で相乗りする場合の３人目の同乗者が見つかったなどの状況）は、サーバ２から端末５に送信し、端末５はこのグループ化の進行状況を随時表示するようにしてもよい。ここで「同乗者が見つかった」とは、同じ利用ルートの他の利用者が利用者リストに登録されたことを示す。また、グループ化された後、利用ルートの出発地点にタクシーが到着する予定時刻やタクシーの現在位置などのタクシー到着予定情報を、タクシーを管理するサーバ３からサーバ２を介して端末５に送信し、端末５が随時表示するようにしてもよい。また、グループ化された後、グループ化された同乗者の現在位置を示す同乗者現在位置情報は、同乗者それぞれの端末５のＧＰＳ機能によりサーバ２が取得し、サーバ２はグループ化された他の同乗者すべての端末５に送信し、端末５が随時表示するようにしてもよい。

サーバ３は、第２段階車両手配要求を受信すると、タクシー会社の社員にその旨を通知してもよいし、直接タクシーにその旨を送信してもよい。タクシー会社の社員は、サーバ３が第２段階車両手配要求を受信したことを受けて、グループ化された利用者が選択したルートの出発地点にタクシーを移動させる。タクシー会社の社員は、この移動させた、すなわち配車したタクシーの車両番号をサーバ３に入力し、サーバ３は、配車したタクシーの車両番号をサーバ２に送信する。

続いて、図２のステップＳ２０３では乗車処理を行う。図５を参照して乗車処理について説明する。サーバ２は、サーバ３から受信した車両番号を、グループ化したユーザそれぞれが携帯する端末５に送信する。端末５は、受信した車両番号を入出力部５４に表示する（ステップＳ５０１）ことで車両番号を利用者に通知する。利用者は、選択したルートの出発地点に到達したならば、端末５に表示された車両番号のタクシーを探し、その車両番号のタクシーに乗車する。

利用者がタクシーに乗車する際には、相乗りの同乗者同士で互いを確認できるように、サーバ２は、グループ化された利用者の端末５に暗証番号を送信するようにしてもよい。端末５はその暗証番号を表示し、相乗りの同乗者同士は、端末５に表示された暗証番号を見せ合うことで、互いに同乗者であることを認識することができる。

タクシーの車体には、バーコードやＱＲコード（登録商標）のような２次元バーコードによる車両識別情報を設けておき、相乗り利用の利用者は、端末５で車両識別情報を撮影して読み取るようにしてもよい。利用者が、読み取った車両識別情報を端末５からサーバ２に送信することで、サーバ２は、そのタクシーはその利用者が乗車すべきタクシーであるかを判定し、判定結果を端末５に送信する（ステップＳ５０２）。そのタクシーがその利用者が乗車すべきタクシーである場合には、端末５は「乗車可」の旨の表示を行う（ステップＳ５０３）。利用者は、端末５に「乗車可」が表示されてからタクシーに乗車するように定めてもよい。車両識別情報は、車両番号を含む情報であってよい。なお、上述のように端末５はサーバ２から車両番号を受信しており、端末５において車両番号と車両識別情報との照合を行うことができるので、端末５は、撮影した車両識別情報をサーバ２に送信せずに、以下の処理を行うようにしてもよい。すなわち、端末５は、利用者が撮影した車両識別情報を、サーバ２から受信した車両番号と照合して、そのタクシーがその利用者が乗車すべきタクシーであるかを判定し、そのタクシーがその利用者が乗車すべきタクシーである（照合結果が一致）場合、端末５は「乗車可」の旨の表示を行うようにしてもよい。

続いて、図２のステップＳ２０４では料金精算処理を行う。図６を参照して料金精算処理について説明する。同乗者がタクシーに乗車し、タクシーが利用ルートの到着地点に到着すると、サーバ２は料金算出を行う（ステップＳ６０１）。配車システム１で配車するタクシーは、利用ルートの出発地点に客を迎えに行くものであるとして迎車料金を適用することができる。タクシーは迎車料金及び利用ルートの出発地点から到着地点までのタクシー料金の合計金額の情報をサーバ３に送信する。サーバ３は、受信した合計金額の情報をサーバ２に送信する。

サーバ２は、サーバ３から受信した合計金額の情報に基づき、合計金額を同乗者の数で均等に割り、利用者それぞれに請求する料金を算出する。このとき、金額が割り切れず端数が出る場合には、利用者リストに登録された順番に応じて端数を処理するのが望ましい。具体的には、合計金額が９８０円で同乗者が３人の場合には、利用者リストに最初に登録された利用者の請求金額は３２６円にして、利用者リストに２番目及び３番目に登録された利用者の請求金額は３２７円にすることができる。利用者リストに最初に登録された利用者は利用ルートの出発地点で待っていた時間が最も長く、利用者リストに最後に登録された利用者は利用ルートの出発地点で待っていた時間が最も短いことから、料金設定を異ならせることで利用者の不満を軽減することができる。なお、この料金設定は、合計金額を同乗者の数で均等に割って端数が出る場合にだけ適用してもよいし、合計金額を同乗者の数で均等に割ることなく適用してもよい。例えば、合計金額が９８０円で同乗者が３人の場合には、利用者リストに最初に登録された利用者の請求金額は３１０円で、利用者リストに２番目に登録された利用者の請求金額は３３０円にして、利用者リストに３番目に登録された利用者の請求金額は３４０円にしてもよい。

サーバ２が算出した利用者ごとの請求金額の情報は、サーバ２から利用者それぞれの端末５に送信され、端末５は、受信した請求金額の情報に基づき、その利用者に請求する金額を表示する。このとき、端末５は、利用者に確認を要求する画面を表示する。利用者は、端末５に表示された金額を確認し、金額に問題がなければ、端末５を操作して金額確認応答を入力する（ステップＳ６０２）。端末５は、入力された金額確認応答をサーバ２に送信する。金額確認応答を受信したサーバ２は、請求金額を確定する。確定した請求金額は、例えば電子タクシーチケットで支払われる（ステップＳ６０２）。このような処理にすることで、スムーズな降車ができる。確定した請求金額の支払いは電子タクシーチケットに限らず、他の電子決済手段を用いてもよい。

また、サーバ２で確定した請求金額は、サーバ２からサーバ３に送信され、サーバ３からタクシーに送信されることでタクシーの運転手に通知され、各利用者はその金額を直接タクシーの運転手に支払ってもよい。

図７は、図１に示した配車システム１の動作におけるデータ送受信の流れを示すフローチャートであって、図２〜図６の処理とは別の例を示す図である。図７ではデータの流れが見やすいようにサーバ３、サーバ２及び端末５を横に並べて表示している。まず、端末５からサーバ２に対して乗車意思が送信される（ステップＳ７０１）。乗車意思を受信したサーバ２はその利用者を利用者リストに登録する（ステップＳ７０２）。利用者リストへの登録は、このように乗車意思を受信した時点で行ってもよい。

続いてサーバ２は、利用者リストに利用者を登録したことに応じて、サーバ３に第１段階車両手配要求を送信する（ステップＳ７０３）。第１段階車両手配要求を受信（ステップＳ７０４）したサーバ３は、上述の第２エリアにタクシーを移動させる第１段階車両手配の指示を、例えばタクシー会社の社員に向けて出力する。

端末５は、自身の位置情報である利用者位置をサーバ２に送信する（ステップＳ７０５）。サーバ２は、端末５から受信した利用者位置が上述の第１エリア内になった場合、乗車意思再確認を端末５に送信する（ステップＳ７０６）。乗車意思再確認を受信した端末５は、再確認応答をサーバ２に送信する（ステップＳ７０７）。

続いてサーバ２は、再確認応答を受信したことに応じて、サーバ３に第２段階車両手配要求を送信する（ステップＳ７０８）。第２段階車両手配要求を受信したサーバ３は、タクシー相乗りの利用ルートの出発地点にタクシーを配車する第２段階車両手配の指示を、例えばタクシー会社の社員に向けて出力する。タクシー会社の社員は、タクシーを配車したならば、その配車したタクシーの車両番号をサーバ３に入力し、サーバ３は、配車したタクシーの車両番号をサーバ２に送信する（ステップＳ７０９）。配車したタクシーの車両番号を受信したサーバ２は、その車両番号を端末５に送信する（ステップＳ７１０）。端末５は、受信した車両番号を表示する（ステップＳ７１１）。

タクシーがタクシー相乗りの利用ルートの到着地点に到着したなら、その料金の通知がタクシーからサーバ３に送信され、また、その料金の通知はサーバ３からサーバ２に送信される（ステップＳ７１２）、料金の通知を受信したサーバ２は、その料金の通知を端末５に送信する（ステップＳ７１３）。料金の通知を受信した端末５は、その料金を表示して、利用者による確認をサーバ２に送信する（ステップＳ７１４）。

上述の例では、タクシー相乗りの利用ルートが、同乗者全員で出発地点及び到着地点が同じ場合に説明したが、本発明はこれに限られるものではない。図８は、同乗者によっては出発地点及び到着地点が他の同乗者と異なる場合であっても同一の利用ルートとする場合を説明する図である。本発明では、図８（ｂ）及び（ｃ）に示すように乗車地点又は降車地点が他の利用者と異なる利用者が同乗する場合や、乗車地点及び降車地点が他の利用者と異なる利用者が同乗する場合、も同一ルートとして許容することができる。

図８（ａ）は、同乗者全員が出発地点及び到着地点が同じである場合の例を示す。この例では、利用者ａ１、ａ２及びａ３の全員の出発地点はＡ地点であり、到着地点はＢ地点である。この場合、同乗者全員がＡ地点に集まることでスムーズな乗車を行うことができる。また、同乗者全員が出発地点及び到着地点が同一であることから、タクシー料金は同乗者全員で均等に割ればよい。

図８（ｂ）は、同乗者全員が出発地点は同じであるが、利用者ｂ３の到着地点は他の利用者と異なる場合の例を示す。この例では、利用者ｂ１、ｂ２及びｂ３の全員の出発地点はＡ地点であり、利用者ｂ１及びｂ２の到着地点はＢ地点であり、利用者ｂ３の到着地点はＣ地点である。この場合、同乗者全員がＡ地点に集まることでスムーズな乗車を行うことができる。しかしながら、利用者ｂ３は降車地点が他の同乗者と異なることから、利用者ｂ１、ｂ２及びｂ２で料金を均等に割ったのでは不公平が生じる。そこで、本実施例では、Ａ地点からＢ地点までの標準的なタクシー料金、及びＡ地点からＣ地点までの標準的なタクシー料金を予め調べておき、これをルート情報に含める。標準的なタクシー料金とは、例えば、渋滞せずにスムーズに進んだ場合のタクシー料金である。

ステップＳ６０１では、標準的なタクシー料金に応じて、実際にかかった料金を同乗者のそれぞれに割り振る料金算出を行う。例えば、迎車料金を含まない標準的なタクシー料金がＡ地点からＢ地点までは４１０円であり、Ａ地点からＣ地点までは４９０円であるとする。この場合、本実施例では、途中の渋滞などの影響も含んだ実際の料金の各利用者への割り振り方は、利用者ｂ１の料金Ｘと利用者ｂ２の料金Ｙと利用者ｂ３の料金Ｚの比率Ｘ：Ｙ：Ｚが、標準的なタクシー料金の比率４１０：４１０：４９０になるようにする。この処理によれば、各利用者に適切な料金配分を行うことができ、各利用者の不満を生じさせることなく、配車システム１の利用を促進することができる。なお、標準的なタクシー料金は、迎車料金を含んだ料金にしてもよい。

図８（ｃ）は、利用者ｃ３の出発地点は他の利用者と異なり、同乗者全員の到着地点は同じである場合の例を示す。この例では、利用者ｃ１及びｃ２の出発地点はＤ地点であり、利用者ｃ３の出発地点はＥ地点であり、利用者ｃ１、ｃ２及びｃ３の全員の到着地点はＦ地点である。この場合、利用者ｃ１及びｃ２が乗車した後に、Ｅ地点にて利用者ｃ３を乗せる必要があり、各利用者及びタクシーの待ち時間がＤ地点及びＥ地点で生じる可能性があるが、その旨を予め各利用者に通知して承諾してもらうことで、各利用者の不満を生じさせることなく、配車システム１の利用を促進することができる。図８（ｃ）の料金算出は、図８（ｂ）と同様に行えばよい。

以上説明した実施例によれば、タクシーに相乗りで乗車する利用者に対しては、
（１）時間短縮
・相乗り相手を探す時間の短縮
・タクシーを待つ時間の短縮
（２）料金負担軽減
・迎車料金も均等割りしたうえで配車依頼が可能であるので、配車依頼が少額の負担で可能になる。
（３）待ち行列不要
・出発地点への到着に合わせてタクシーが配車されるので、従来の相乗りのような路端で待ち行列に並ぶ必要をなくすことができる。
（４）確実性（確度向上）
・相乗り相手のマッチングの確度を向上することができる。
・配車によりタクシーを確保する確度を向上することができる。
（５）精算
・各同乗者の利用料金が自動で計算され、従来の相乗りのように利用者同士で現金のやり取りを生じることなく、トラブルを低減することができる。
・電子決済によりキャッシュレス決済を提供することができ、スムーズに降車することができる。
という効果を提供することができる。

以上説明した実施例によれば、タクシーに対しては、
（１）確実性
・配車依頼を受けることで売上が確定し、競合他社に対抗して乗客を確保することができる。
（２）迎車料金分の売上増
（３）配車指示を受けるまで出発地点にいる必要がないので、路上客待ちを回避することができる。
（４）降車時間短縮
・キャッシュレス決済により降車時間を短縮することができる。
（５）需要予測
・第１段階車両手配を受けることにより、数分〜数十分後という直近の需要予測を実需に基づいて行うことができる。
という効果を提供することができる。

以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されるものではない。本発明の目的は、上述の実施例の機能を実現するプログラムコード（コンピュータプログラム）を格納した記憶媒体をシステムあるいは装置に供給し、供給されたシステムあるいは装置のコンピュータが記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が上述した実施例の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、上述した実施形態では、コンピュータがプログラムを実行することにより、各処理部として機能するものとしたが、処理の一部または全部を専用の電子回路（ハードウェア）で構成するようにしても構わない。本発明は、説明された特定の実施例に限定されるものではなく、特許請求の範囲に記載された本発明の趣旨の範囲内において、種々の変形・変更が可能である。

１ 配車システム
２ サーバ
３ サーバ
４ ネットワーク
５、６、７ 端末

Claims (5)

1. コンピュータで実行される配車プログラムであって、
   前記配車プログラムは、前記コンピュータに、
   利用者が複数のルートの中から選択した利用ルートで車両に乗車することの予約を受け付ける乗車予約ステップと、
   前記乗車予約ステップで予約した利用者を利用者リストに登録する利用者リスト登録ステップと、
   前記利用者リストに登録された利用者のうち前記利用ルートが同一である利用者が所定人数に達した場合、前記利用ルートが同一である利用者を同一グループに登録するグループ化ステップと、
   前記グループ化ステップで同一グループに登録された利用者が予約した前記利用ルートの出発地点に車両の配車を指示する配車指示ステップと、
   前記グループ化ステップで同一グループに登録された利用者に、前記配車指示ステップで配車指示した車両を特定可能な車両番号を通知する車両番号通知ステップと、
   を実行させることを特徴とする配車プログラム。
2. 請求項１に記載の配車プログラムであって、
   前記乗車予約ステップは、
   利用者による前記利用ルートで車両に乗車することの予約を受け付ける第１予約ステップと、
   前記第１予約ステップによる予約の後、利用者が前記利用ルートの出発地点を含む第１エリアに到達した際に、前記利用ルートで車両に乗車する意思を利用者に再確認する第２予約ステップと、
   を有し、
   前記利用者リスト登録ステップは、前記第２予約ステップにおいて前記利用ルートで車両に乗車する意思を示した利用者を前記利用者リストに登録する、
   ことを特徴とする配車プログラム。
3. 請求項２に記載の配車プログラムであって、
   前記配車指示ステップは、前記第１予約ステップで予約された前記利用ルートの出発地点を含むエリアであって、前記第１エリアよりも広い第２エリア内に所定台数の車両の配車を指示する、
   ことを特徴とする配車プログラム。
4. 請求項１乃至３のいずれか１項に記載の配車プログラムであって、
   前記配車プログラムは、前記コンピュータに、
   前記利用ルートの出発地点に配車された車両に乗車した利用者それぞれに課金する料金を算出する料金算出ステップと、
   前記利用ルートの出発地点に配車された車両に乗車した利用者それぞれに、前記料金算出ステップで算出した料金を通知する料金通知ステップと、
   をさらに実行させることを特徴とする配車プログラム。
5. サーバと端末とをネットワークで接続して成る配車システムであって、
   利用者が複数のルートの中から選択した利用ルートで車両に乗車することの予約を受け付ける乗車予約部と、
   前記乗車予約部で予約した利用者を利用者リストに登録する利用者リスト登録部と、
   前記利用者リストに登録された利用者のうち前記利用ルートが同一である利用者が所定人数に達した場合、前記利用ルートが同一である利用者を同一グループに登録するグループ化部と、
   前記グループ化部で同一グループに登録された利用者が予約した前記利用ルートの出発地点に車両の配車を指示する配車指示部と、
   前記グループ化部で同一グループに登録された利用者に、前記配車指示部で配車指示した車両を特定可能な車両番号を通知する車両番号通知部と、
   を備えたことを特徴とする配車システム。

Images