JP2019096171A - 配車管理システム及び配車管理方法 - Google Patents

Abstract

【課題】ユーザが一度に複数の代行会社等に配車要求でき、代行会社等は、ユーザの配車要求に応じて効率よく配車を請け負うことができる配車管理システム及び配車管理方法を提供する。【解決手段】配車管理システムは、ユーザ端末と複数のオペレータ端末と管理サーバを含んで構成され、ユーザ端末は、管理サーバにユーザ情報と配車要求を送信し、管理サーバから営業車情報を受信し、営業車に対する応答を送信する通信手段を備え、複数のオペレータ端末は、管理サーバに営業車の情報を送信し、管理サーバから配車要求を受信して、それに対する応答を送信する通信手段を備え、管理サーバは、ユーザ情報と配車要求を格納するユーザ情報格納手段と、営業車情報を格納する営業車情報格納手段と、配車要求に対して最初に応答したオペレータ端末の営業車情報をユーザ端末に送信する通信手段を備える。【選択図】図１

Description

本発明は、ユーザが一度に複数の代行会社又はタクシー会社に配車要求でき、営業車を簡単に呼び出すことのできる配車管理システム及び配車管理方法に関する。

近年、スマートフォン等に備わっているＧＰＳ機能により、ユーザは、画面上に表示される地図にユーザの現在位置を表示することができ、目的地までのルート検索や到達に要する時間の予測などもできるようになってきた。また、このＧＰＳ機能を利用したアプリケーションプログラム（以下、アプリと記す）が広く普及している。

例えば、特許文献１には、ＧＰＳ機能を利用して、営業車を探す顧客（以下、ユーザと記す）の操作によってスマートフォン等の地図上に、ユーザの近隣にいる営業車を表示でき、その営業車にユーザの位置情報を含むユーザ情報を伝えることができる配車管理システム及び配車管理方法が開示されている。この発明によると、ユーザは営業車に対して簡単に配車要求ができ、営業車はユーザ情報を簡単に得ることができる。

また、特許文献２には、顧客および営業車の各位置に基づいてユーザに対する営業車の配車を管理する配車管理システムが開示されている。この発明によると、ユーザからの配車要求の受け付け処理および営業車の配車処理を、ＧＰＳ機能を利用して一元的に運用することができる。

特開２０１７−１３４５６９号公報 特開２００３−３３１３９４号公報

特許文献１又は２の配車管理システムでは、営業車にＧＰＳ機能を有する営業車端末を搭載することが必須であり、それにより営業車の位置情報をユーザに伝えることが可能になっている。しかし、スマートフォン等のＧＰＳ機能を有する営業車端末を運転手の人数分用意するのは、初期投資に費用がかかる。また、運転手が高齢者である場合などに、スマートフォンの操作を理解して覚えることが困難な場合もある。更に、従来通りオペレータと無線で連絡を取る方法を望む運転手も多い。そこで、営業車にＧＰＳ機能を有する営業車端末を搭載しない場合であっても、ユーザは簡単に配車要求ができ、営業車は従来通りオペレータを介してユーザ情報を簡単に得ることができるシステムが望まれる。

本発明は、上記課題に鑑み、営業車にＧＰＳ機能を有する営業車端末を搭載しない場合であっても、ユーザが一度に複数の代行会社又はタクシー会社に配車要求でき、代行会社又はタクシー会社は、ユーザの配車要求に応じて効率よく配車を請け負うことができる配車管理システム及び配車管理方法を提供することを目的とする。

（１）請求項１に記載の発明は、ユーザが操作するユーザ端末と、営業車に連絡する複数のオペレータ端末と、ユーザ情報と営業車情報を管理する管理サーバと、から構成される配車システムであって、ユーザ端末は、前記管理サーバに前記ユーザ情報と配車要求を送信し、前記管理サーバから前記営業車情報を受信し、前記営業車に対する応答を送信する通信手段を備え、複数のオペレータ端末は、前記管理サーバに前記営業車の情報を送信し、前記管理サーバから前記配車要求を受信し、前記配車要求に対する応答を送信する通信手段を備え、管理サーバは、前記ユーザ情報と配車要求を格納するユーザ情報格納手段と、前記営業車情報を格納する営業車情報格納手段と、前記配車要求に対して最初に応答したオペレータ端末の前記営業車情報を前記ユーザ端末に送信する通信手段と、を備えることを特徴とする配車システムである。
（２）請求項２に記載の発明は、請求項１に記載の配車システムにおいて、前記管理サーバは、前記ユーザ端末から受信した前記ユーザ情報、配車要求及び前記オペレータ端末への応答と、前記オペレータ端末から受信した前記配車要求に対する応答及び前記ユーザ端末への応答を記録する送迎記録格納手段を備えることを特徴とする配車管理システムである。
（３）請求項３に記載の発明は、請求項１又は２に記載の配車システムにおいて、前記ユーザ端末は、ユーザの位置情報を検出する位置検出手段を備えることを特徴とする配車管理システムである。
（４）請求項４に記載の発明は、請求項１〜３のいずれかに記載の配車システムにおいて、前記ユーザ情報には前記ユーザによって入力される配車希望時間が含まれることを特徴とする配車システムである。
（５）請求項５に記載の発明は、請求項１〜４のいずれかに記載の配車システムにおいて、前記営業車情報には運賃の情報が含まれることを特徴とする配車システムである。
（６）請求項６に記載の発明は、ユーザが操作するユーザ端末と、営業車に連絡する複数のオペレータ端末に接続する管理サーバが行なう配車管理方法であって、前記オペレータ端末から受信した営業車情報を格納するステップと、前記ユーザ端末から受信したユーザ情報及び配車要求を記録するステップと、前記オペレータ端末から受信した前記配車要求に対する応答を記録するステップと、前記ユーザ端末から受信した前記オペレータ端末に対する応答を記録するステップと、を含むことを特徴とする配車管理方法である。

本発明の配車管理システム及び配車管理方法によると、ユーザが営業車を簡単かつ迅速に呼び出すことができる。また、代行会社又はタクシー会社は、ユーザの配車要求に応じて効率よく配車を請け負うことができる。

本発明の一実施形態である配車管理システムの構成を示す概略図である。 本発明の一実施形態である配車管理システムの全体構成を示すブロック図である。 本発明の一実施形態であるユーザ端末で入力するユーザ情報（Ａ）と、管理サーバに格納されるユーザ情報（Ｂ）のデータを示す図である。 本発明の一実施形態である管理サーバに格納される営業車情報（Ａ）と、営業車の送迎記録（Ｂ）のデータを示す図である。 本発明の一実施形態であるユーザ端末における処理の流れを示すフローチャートである。 本発明の一実施形態であるオペレータ端末における処理の流れを示すフローチャートである。 本発明の一実施形態である管理サーバ、ユーザ端末、オペレータ端末の間で送受信される情報の流れを示すシーケンス図である。 本発明の一実施形態であるユーザ端末に表示される画面のイメージ図である。 本発明の一実施形態であるオペレータ端末に表示される画面のイメージ図である。 本発明の一実施形態であるオペレータ端末に表示される画面のイメージ図である。

以下、本発明の実施の形態（以下実施例と記す）を、図面に基づいて説明する。なお、以下の図において、共通する部分には同一の符号を付しており、同一符号の部分に対して重複した説明を省略する。また、以下の説明では、営業車として代行車を例に挙げて説明するが、本発明の営業車は代行車に限らず、タクシーなどを含むものである。

〔システムの構成〕
まず、図１〜図４を用いて、本実施例の配車管理システムの構成を説明する。図１は、本実施例の配車管理システムの構成を示す概略図であり、図２は、本実施例の配車管理システムの全体構成を示すブロック図である。図３は、本実施例のユーザ端末で入力するユーザ情報（Ａ）と、管理サーバに格納されるユーザ情報（Ｂ）のデータを示す図である。図４は、本実施例の管理サーバに格納される代行会社の情報（Ａ）と、代行車の送迎記録（Ｂ）のデータを示す図である。本実施例の配車管理システム１００は、代行車を利用するユーザが有するユーザ端末１０と、１つ又は複数の代行車４０に連絡する複数のオペレータ端末３０と、ユーザ情報と代行車情報（営業車情報）を管理する管理サーバ２０と、から構成される配車システムである。

図１において、ユーザ端末１０は２台、オペレータ端末３０は３台、各オペレータ端末３０が連絡する代行車４０はそれぞれ３台、２台、１台であるが、本発明の配車管理システム１００ではそれらの台数は限定されず、何台あってもよい。また、図２のブロック図では、簡単のため、ユーザ端末１０とオペレータ端末３０、代行車４０をそれぞれ１つだけ示してその関連を説明するが、実際には複数のユーザ端末１０とオペレータ端末３０、代行車４０がある。ユーザ端末１０、オペレータ端末３０と管理サーバ２０は、インターネット等のネットワーク５０に接続される。本実施例ではオペレータ端末３０と代行車４０は、従来通り無線で連絡をする。代行車４０が携帯端末を利用できる場合には、それを用いてもよい。なお、本実施例では、ユーザ端末１０はＧＰＳ衛星６０による測位機能を利用してユーザの位置情報を検出するが、ユーザ端末１０は位置情報を検出しない機種であってもよい。

〔ユーザ端末１０〕
ユーザ端末１０は、ネットワーク５０に接続され、ＧＰＳ機能を有し、通信機能と表示機能を有するものであれば、いかなる携帯端末でもよいが、本実施例では、いわゆるスマートフォンを例に挙げて説明する。ユーザ端末１０は、代行車を利用する予定のユーザによって操作され、管理サーバ２０を介してオペレータ端末３０にユーザ情報を送信する。ユーザ端末１０（スマートフォン）は、制御部１１、通信部１２、タッチパネル表示装置である表示部１３及び入力部１４と、記憶部１５、出力部１６及びＧＰＳ受信部１７を含んで構成される。各構成部は、一般のスマートフォンと同様に構成されるため、詳細な説明を省略する。

制御部１１は、上記の各部およびユーザ端末１０全体に対する制御を行う。特に本実施例では、管理サーバ２０を介してオペレータ端末３０との間の情報の送受信を行うアプリの制御を行う。また、制御部１１の位置検出手段１１１がＧＰＳ受信部１７により受信した信号からユーザ端末１０の位置を示す情報（緯度・経度）を生成する。

通信部１２（通信手段）は、通常のスマートフォンと同様にメッセージや画像を送受信する送信部と受信部を備える。特に本実施例では、管理サーバ２０にユーザ情報と配車要求を送信し、管理サーバ２０から代行車情報を受信し、代行車に対する応答を送信する。

表示部１３は表示画面上に設けられたタッチパネルの入力部１４を有しており、ユーザは表示された内容に対応して画面上で直接入力を行うことができる。タッチパネルで入力を行うことができることで画面切り替えの操作を簡単に行うことができる。本実施例では、タッチパネル上で図３（Ａ）に示すようなユーザ情報（氏名又はニックネーム、電話番号、送り先の住所、送迎希望時間）を入力する。なお、ユーザは氏名ではなくニックネームを入力してもよく、送り先の住所は町名まで入力すればよいため、プライバシー保護の観点からも本アプリは利用しやすくなっている。

表示部１３には、地図のデータを表示することができる。地図データとしては、例えば、インターネットを介して地図検索が可能ないわゆるＧｏｏｇｌｅ（登録商標）マップを表示することができる。この地図データを用いて、ユーザ端末１０の現在位置を表示することができる。また、表示部１３のタッチパネル上でオペレータ端末３０からの応答（メッセージ）を表示し、タッチパネルの入力部１４でオペレータ端末３０に対する応答を入力することができる。

記憶部１５は、入力したユーザ情報（図３（Ａ））を格納することができる。頻繁に本実施例のアプリを使用する場合には、ユーザ情報を格納することにより、入力したユーザ情報（ニックネームや自宅情報）は、再度入力しなくても利用することができ、入力する手間を省くことができる。また、記憶部１５には配車管理システム１００を構成する種々の機能を動作させるためのアプリや、ユーザ端末１０全体を制御するためのプログラムが格納されている。その他、ユーザが必要と考える情報（例えば代行車情報）などを記録することができる。

出力部１６は、記憶部１５に保持されたデータを記録するメモリーカードを挿入する端子やＵＳＢ端子などの出力端子を備える。また、出力部１６を介して、それらのデータや画像を印刷できる構成としてもよい。例えば、ユーザ端末１０の通信部１２が不具合により通信できない場合には、記憶部１３に保持されている代行車情報を出力し、手動で他の携帯端末や電話機から代行車を呼び出すことができる。

ＧＰＳ受信部１７は、ＧＰＳ衛星４０からの電波を受信するためのアンテナが内蔵されている。ＧＰＳ受信部１７は、そのアンテナにより受信された信号を復調し、制御部１１に供給し、制御部１１の位置検出手段１１１がユーザ端末１０の位置を示す情報（緯度・経度）を生成し、表示部１３の地図上に表示させる。その位置情報は、通信部１２の送信手段（送信部）により、管理サーバ２０を介してオペレータ端末３０に送られる。すなわち、オペレータ端末３０に送られるユーザ情報は、図３（Ａ）に示したユーザ情報に加え、図３（Ｂ）に示すように現在位置の情報と携帯番号も含めて送信される。それにより、ユーザが何も入力しなくても現在位置の情報と携帯番号をオペレータ端末３０に伝えることができる。

〔管理サーバ２０〕
管理サーバ２０は、主にユーザ情報と代行車情報を管理し、図２に示すように制御部２１、通信部２２、表示部２３及び入力部２４と、記憶部２５及び出力部２６を含んで構成される。

制御部２１は、ユーザ端末１０の制御部１１と同様に、上記の各部および管理サーバ２０全体に対するプログラムの制御を行う。また、配車管理システム１００を構成する種々の機能を動作させるためのアプリを制御する。特に本実施例では、記憶部２５の記録の更新やデータの読み出し、通信部２２を介して送受信されるユーザ端末１０とオペレータ端末３０との間のやりとりを記録するプログラムを制御する。

通信部２２（通信手段）は、ユーザ情報（図３（Ｂ））と代行車情報（図４（Ａ））を送受信する送信部と受信部を備える。受信部でユーザ端末１０からの配車要求を受け、送信部で複数のオペレータ端末３０に送信される。その配車要求に最初に応答したオペレータ端末３０の代行車情報が、送信部からユーザ端末１０に送信される。

記憶部２５は、オペレータ端末３０から送信される図４（Ａ）に示す代行車情報（会社名、電話番号、料金）を格納する代行車情報格納手段２５１（営業車情報格納手段）を備える。また、ユーザ端末１０から送信される図３（Ｂ）に示すユーザ情報を格納するユーザ情報格納手段２５２を備える。また、記憶部２５には、管理サーバ２０を制御するためのプログラムと、上記アプリが格納されている。更に、オペレータ端末３０の送迎記録（日時、地域、ユーザとの応答）を記録する送迎記録格納手段２５３を備える。送迎記録は、例えば図４（Ｂ）に示すように記録される。

送迎記録格納手段２５３に記録された１２時間以内の情報は、オペレータ端末３０に表示される構成としてもよい。また、一定の期間毎（例えば１カ月毎）にまとめ、表示部２３に表示し、出力部２６から出力して代行車４０の会社に送迎記録の報告書として提出することもできる。それにより、代行車４０の会社は、容易に送迎記録を管理することができる。

なお、本実施例の管理サーバ２０の主な役割は、オペレータ端末３０の代行車情報の記録と、オペレータ端末３０とユーザ端末１０との間の情報のやりとりの記録であり、代行車（代行会社）の選択、ユーザの選択はそれぞれユーザ端末１０とオペレータ端末３０で決定される。従って、ユーザは料金や送迎時間を確認した上で代行車を選択することができ、代行会社は、ユーザの配車要求（送迎希望時間）に応じて効率よく配車を請け負うことができる。

〔オペレータ端末３０と代行車４０〕
運転代行会社で使用するオペレータ端末３０は、異なる会社毎に１つ又は複数台設置される。例えば、規模の大きい会社の場合には、地域に分けてオペレータ端末３０を複数台設置してもよい。図１に示すように異なる会社のオペレータ端末３０が、同じ管理サーバ２０にネットワーク５０を介して接続され、ユーザ端末１０から配車要求を受ける。

オペレータ端末３０は、表示機能と通信機能を有するものであれば、いかなる端末でもよく、デスクトップ型のパーソナルコンピュータでもよいが、本実施例では、ユーザ端末１０と同様にスマートフォンを例に挙げて説明する。オペレータ端末３０は、代行会社のオペレータが１つ又は複数の代行車４０の位置や空き状態を無線で確認しながら操作する。オペレータ端末３０から管理サーバ２０に代行車情報（図４（Ａ））が送られ、管理サーバ２０を介してユーザ端末１０に代行車情報を送信する。図２に示すように、オペレータ端末３０は、制御部３１、通信部３２、表示部３３、入力部３４、記憶部３５、出力部３６を含んで構成される。

制御部３１は、上記の各部およびオペレータ端末３０全体に対する制御を行うが、本実施例では、配車管理システム１００を構成する種々の機能を動作させるためのアプリを制御し、特に管理サーバ２０を介してユーザ端末１０との間の情報の送受信を制御する。

また、本実施例では運転手がユーザを送迎した後に、アプリを終了すると、図３（Ｂ）に示すユーザの情報（氏名／ニックネーム、電話番号、送り先等）を記憶部３５から消去するユーザ情報消去のプログラムが備えられている。個人情報保護の観点から、ユーザ情報消去を有することで、ユーザは安心して配車を要求することができる。

通信部３２は、メッセージや画像を送受信する送信部と受信部を備える。送信部は、入力部３４で入力した代行車の情報（会社名、電話番号、運賃）（図４（Ａ））を管理サーバ２０に送信する。また、ユーザ端末１０から管理サーバ２０を介して送られる配車要求や、ユーザ端末１０に対する応答を送受信する。

表示部３３は表示画面上のタッチパネルの入力装置（入力部３４）を有しており、画面上で直接入力を行うことができる。ユーザ端末１０と同様に、表示部３３には、地図のデータを表示することができ、例えば、Ｇｏｏｇｌｅ（登録商標）マップを表示することができる。この地図データを使用し、ユーザ端末１０の迎え先（現在位置）や送り先などを表示することができる。また、表示部３３のタッチパネル上でユーザ端末１０からの配車要求を表示し、ユーザ端末１０に対する応答を入力することができる。

記憶部３５は、前述のアプリや、オペレータ端末３０全体を制御するためのプログラムが記憶されている。その他、ユーザ情報や代行車情報などを一時的に記録することもできる。出力部３６は、ユーザ端末１０と同様であるため、説明を省略する。

代行車４０は、運転代行会社のオペレータと対応できれば、携帯端末などを備えている必要はなく、従来通りの運行ができる。オペレータと連絡するため、少なくとも通信部４１（送信部、受信部）が必要であるが、従来の無線システムを使用することができる。通信部４１から、代行車４０の現在位置や空き状態を随時、オペレータに連絡する。

また、代行車４０は、カーナビゲーション機器等の表示部４２を備えていてもよい。表示部４２が備えているとユーザの送迎の際に便利である。本実施例の代行車４０は従来通りの車を使用することができ、携帯端末も必要ではないため、本システムを導入の際に新たな設備投資の費用は必要なく、経済的である。また、代行車４０の運転手は携帯端末の操作をする必要がないため、運転に集中することができる。勿論、運転手が携帯端末を既に持っている場合には、それを利用してもよい。

〔システムの流れと使用例〕
次に本発明に係る配車管理システム１００の流れと使用例を図５から図１０を用いて説明する。図５は、ユーザ端末１０における処理の流れを示すフローチャートであり、図６は、オペレータ端末３０における処理の流れを示すフローチャートである。図７は、ユーザ端末１０、管理サーバ２０、オペレータ端末３０の間で送受信される情報の流れを示すシーケンス図である。図５〜７における各ステップは、図においてＳ１１、Ｓ１２、…と略して表示する。

図８は、ユーザ端末１０に表示される画面の一例のイメージ図である。図９と図１０は、オペレータ端末３０に表示される画面の一例のイメージ図である。なお、ユーザ端末１０とオペレータ端末３０に表示される画面は、図８〜図１０に示す画面に限らず、ここに示していない画面も含まれる。まず、図５のユーザ端末１０における処理の流れを、図８を参照しながら説明する。

〔ユーザ端末１０における処理の流れ〕
ステップ１１において、ユーザが配車管理システムを実行するためのアプリを起動する。アプリをダウンロードしていない場合には、管理サーバ２０にアクセスして、利用規約を確認した上でダウンロードし、アプリを起動する。

次にステップ１２において、ユーザ情報（氏名、自宅、電話番号）の情報を入力する。その際、氏名の代わりにニックネームでもよく、自宅は町名まで入力すればよい。図８（Ａ）に示すように、最初にユーザ端末１０に表示される画面は、簡単な情報だけ入力すればよいため、操作が容易である。なお、図８（Ａ）の画面には、既に依頼している情報を表示するためのボタンもあり、そのボタンをタップすると、依頼状況の詳細を確認することができる。なお、現在配車を依頼中の場合には新たな配車要求を出すことはできない。

図８（Ａ）の画面で、ユーザは氏名と電話番号、自宅情報を入力して「運転代行を依頼」のボタンをタップすると、図８（Ｂ）に示すように詳細を入力する画面が表示される。そこで、送迎希望時間やお迎え地域、居場所のキーワードなどを入力する。送迎希望時間は、例えば１５分単位で、１５分後、３０分後、１時間後など選択して入力でき、お迎え地域も県内の地域を選択して入力できる。また、図８（Ａ）の画面で氏名や電話番号、自宅の情報を入れていなかった場合には、この画面で入力することもできる。入力後に「送迎を依頼する」のボタンをクリックして、送迎を依頼する（ステップ１３）。この送迎依頼の情報は複数の運転代行会社がアクセスできる管理サーバ２０に格納されるため、一度の依頼で複数の運転代行会社に送迎可否を問い合わせることができる。なお、ユーザがユーザ端末１０で入力する情報は、上記のように簡単な情報（図３（Ａ））のみであるが、管理サーバ２０にはユーザ端末１０に現在位置の情報も含めて登録される（図３（Ｂ））。

ステップ１４において、代行車の送迎可否が判断される。依頼中の画面の後、送迎依頼が可能な場合（ＹＥＳの場合）には、ステップ１５において図８（Ｃ）に示すように運転代行会社の情報（会社名、電話番号、到着予定時刻、料金）が表示される。ここで表示される運転代行会社は、ユーザの送迎依頼に対して最初に応答した会社であり、複数の会社が表示されることはない。ステップ１４において送迎依頼が不可能な場合（ＮＯの場合）には、ステップ１２に戻り、送迎依頼時間等を変更して入力し、再度運転代行を依頼する。

次にステップ１６において、図８（Ｃ）に示す運転代行会社に配車を依頼するか否かを判断する（最終確認）。依頼する場合（ＹＥＳの場合）には、図８（Ｃ）に表示される「送迎依頼を承認」のボタンをタップして送迎依頼（最終確認）を送信する（ステップ１７）。依頼しない場合（ＮＯの場合）には、図８（Ｃ）に表示される「送迎依頼をキャンセル」のボタンをタップする。すると、送迎依頼をキャンセルした旨が画面に表示され、アプリを終了し、再起動が必要である旨が画面に表示される（図示せず）。ユーザはその画面でアプリの終了ボタンをタップして、アプリを終了する。

ステップ１７で送迎依頼（最終確認）を送信した後は、代行会社の会社名と電話番号と到着予定時刻が画面に表示される。その後の送迎キャンセルや時間変更はアプリではできず、代行会社へ電話で連絡する。ステップ１７の後、ユーザ端末１０における一連の処理の流れが終了する。再度、送迎依頼を確認したい場合には、再度アプリを起動し、図８（Ａ）の画面で「依頼した情報を表示」のボタンをタップすると、依頼中の詳細を確認することができる。なお、オペレータ端末３０において「到着しました」のボタン（図示せず）がタップされると、依頼中の情報が表示されなくなる。

以上説明したように、ユーザ端末１０における代行車の配車依頼（配車要求）は、ユーザ端末１０の画面上で簡単なユーザ情報を入力して送迎依頼のボタンをタップして行うことができ、ユーザの操作は非常に容易である。それにより、例えば、ユーザの体調が優れず、送り先を上手く説明できない場合あっても、画面をタップするだけで配車要求することができ、ユーザの迎え先や送り先を運転手に確実に伝えることができるため、ユーザにとって負担が少なく、利点が多い。なお、図８（Ａ）〜（Ｃ）に示すように、ユーザは操作途中でいつでもアプリを終了できるように、アプリを終了するボタンが表示されている。それにより、操作途中であってもアプリを終了できるため、簡易かつ気軽に操作することができる。

〔オペレータ端末３０における処理の流れ〕
次にオペレータ端末３０における処理の流れを図６と図９及び図１０を用いて説明する。図６は、オペレータ端末３０における処理の流れを示すフローチャートであり、図９と図１０は、オペレータ端末３０に表示される画面の一例のイメージ図である。

まず、図６のステップ２１において、代行会社のオペレータが配車管理システムを実行するためのアプリを起動する。アプリをダウンロードしていない場合には、管理サーバ２０にアクセスして、利用規約を確認した上でダウンロードし、アプリを起動する。その際、代行会社の代行車情報（図４（Ａ））を管理サーバ２０に送信して登録する。既にアプリの使用申し込みのあった代行会社の情報を、管理サーバ２０が登録しているシステムであってもよい。代行会社の代行車情報を既に登録している場合には、アプリを起動して、認証を経てすぐに開始できる。

ステップ２２において、図９（Ａ）に示すように送迎可能な地域を選択し、「送迎依頼を確認」のボタンをタップする。送迎可能な地域は、例えば県内の地域を選択して入力することができる。なお、図９（Ａ）の画面には、既に送迎依頼受信中の情報を表示するためのボタンもあり、そのボタンをタップすると、送迎依頼受信中の詳細を確認することができる。なお、オペレータ端末３０においては、送迎依頼受信中であっても別の送迎依頼を受けることができ、複数の代行車４０の配車を請け負うことができる。

図９（Ａ）の「送迎依頼を確認」のボタンをタップすると、ステップ２３において、送迎依頼の有無が判断される。送迎依頼がある場合（ＹＥＳの場合）には、ステップ２４において図９（Ｂ）に示すように送迎情報の一覧が表示される。ステップ２３において送迎依頼が無い場合（ＮＯの場合）には、ステップ２２に戻り、地域を変更して再度送迎依頼を確認する。図９（Ｂ）に示すように、送迎依頼の情報には、お客様名（ユーザ名）、送迎希望日時、送迎経路や地図等が表示される。オペレータ端末３０のオペレータは、代行車４０の運転手と無線で連絡しながら、お客様の詳細情報（図９（Ｃ））を表示する。なお、図９（Ｂ）に示す送迎情報の一覧は時間の経過に伴い変化するため、「最新情報に更新」のボタンをタップすることで常に最新の情報を確認することができる。

図９（Ｃ）に示す「お客様の詳細情報」には、送迎希望時間までの残り時間も表示される。オペレータはこの画面を見て、配車要求を受けるか否かを判断する（ステップ２５）。配車要求を受ける場合（ＹＥＳの場合）には、図９（Ｃ）のお客様情報にある「行けます」のボタンをタップし、受けない場合（ＮＯの場合）には、「やめます」のボタンをタップする。配車要求を受けない場合（ＮＯの場合）には、ステップ２４に戻り送迎情報の一覧を表示し、他の配車要求を確認する。なお、「行けます」のボタンをタップした場合であっても、お客様がキャンセルした場合や他の運転代行会社が先に「行けます」のボタンをタップした場合等には、「依頼がキャンセルされました」の旨が画面に表示される。その場合には、ステップ２４に戻り、送迎情報の一覧（図９（Ｂ））を表示し、他の配車要求を確認する。

ステップ２５で配車要求を受ける場合（ＹＥＳの場合）には、ステップ２６で図１０（Ａ）に示すように、お客様（ユーザ）からの最終依頼の受信確認中の画面が表示され、最終依頼の有無が判断される。最終依頼があった場合（ＹＥＳの場合）には、図１０（Ｂ）に示すように、送迎依頼（最終依頼）を受信した旨がわかりやすく、大きく表示される。ステップ２６で最終依頼がない場合（ＮＯの場合）は、ユーザからの応答が暫くたってもない場合、又は依頼がキャンセルされた場合である。応答がない場合には、図１０（Ａ）の「強制停止」のボタンをタップする。依頼がキャンセルされた場合には、その旨が画面に表示される。最終依頼がない場合には、ステップ２２に戻り、再度、送迎情報を確認する。

ステップ２６で最終依頼があった場合は、ステップ２７でユーザに最終回答を送信する。例えば、図１０（Ｃ）に示すように依頼者情報の詳細が表示された画面上の「送迎依頼をお受けします」のボタンをタップすることで最終回答を送信する。その後、代行車がユーザの送り先に到着すると、「到着しました」のボタン（図示せず）をタップし、オペレータ端末３０における一連の処理の流れが終了する。終了すると、図９（Ａ）の画面の「送迎依頼受信中の案件を表示」の中で依頼受信中の案件として表示されなくなる。なお、本実施例では、オペレータ端末３０のアプリを終了すると、ユーザ情報が消去されるため、個人情報保護の観点からユーザが安心して使用できるが、ユーザ情報を消去しないように構成してもよい。

以上説明したように、代行会社のオペレータは、オペレータ端末３０でユーザから配車要求を受けることで、簡単かつ効率よく配車を請け負うことができる。特に繁忙期には、ユーザから配車要求を受ける可能性が高くなり、効率のよい送迎が可能となる。また、ユーザの送迎先をオペレータ端末３０で確認できるため送迎先を間違うこともなく、ユーザへの応答もオペレータ端末３０の画面上にあるボタンをタップすることで簡単に行うことができ、オペレータにとって負担が少ない。さらに、代行車の運転手は従来通りオペレータと無線で連絡ができ、新しいことを覚える負担がなく、新たな設備投資の費用も必要ないため低コストかつ効率良く送迎できる。

〔管理サーバ２０における処理の流れ〕
次に管理サーバ２０における処理の流れを、図７のシーケンス図を用いて説明する。図７は、管理サーバ２０、ユーザ端末１０、オペレータ端末３０の間で送受信される情報の流れを示すシーケンス図である。前述のように、本実施例の管理サーバ２０の主な役割は、ユーザ情報と代行車情報の記録と、オペレータ端末３０とユーザ端末１０との間の情報のやりとりの記録である。

まず、ステップ０１において、代行会社のオペレータがアプリを起動し、オペレータ端末３０から代行車情報（会社名、電話番号、料金表）を管理サーバ２０に送信すると、管理サーバ２０は代行車情報を記憶部２５（代行車情報格納手段２５１）に格納する。なお、既に代行車情報が登録されている場合にはこのステップは省略でき、オペレータ端末３０からの起動により認証を経て、起動状態が記憶される。

次にステップ０２において、ユーザがアプリを起動し、ユーザがユーザ端末１０の画面上（図８（Ａ））で名前又はニックネームと電話番号、自宅情報を入力する。簡単な情報を入力した後、送迎希望時間とお迎え場所（キーワード）を入力し（図８（Ｂ））、配車要求（送迎依頼）をする。管理サーバ２０は、そのユーザ情報をユーザ端末の電話番号と現在位置と共に記憶部２５（ユーザ情報格納手段２５２）に格納する（図３（Ｂ））。

ステップ０３においてオペレータ端末３０のオペレータが、管理サーバ２０に配車要求をしたユーザの情報を確認する。ユーザの情報は一覧で表示され（図９（Ｂ））、それぞれの詳細を確認することができる（図９（Ｃ））。詳細な情報を確認した上で、オペレータ端末３０のオペレータは、代行車の運転手と無線で連絡をとり、送迎の有無を確認する。

その後、ステップ０４において、オペレータがオペレータ端末３０の表示画面上で配車要求を受けるか否かのアイコン（図９（Ｃ））を選択してタップすると、管理サーバ２０はオペレータ端末３０から配車要求を受けるか否かの応答を記録し、ユーザ端末１０がそれを確認する。

ステップ０５において、ユーザがユーザ端末１０から代行車情報（図８（Ｃ））を確認する。その後、ステップ０６においてユーザがユーザ端末１０の画面上で送迎依頼（最終依頼）を承認するボタンをタップして応答すると、管理サーバ２０はユーザからの応答を記録する。

ステップ０７において、オペレータがオペレータ端末３０の画面（図１０（Ｂ））上でユーザからの最終依頼を確認する。その後、オペレータがオペレータ端末３０の画面（図１０（Ｃ））上で送迎依頼を受ける（最終回答）ボタンをタップして応答すると、管理サーバ２０はその応答を記録する。

ステップ０８において、代行車がユーザの送り先に到着して、オペレータが「到着しました」のボタン（図示せず）をタップすると、管理サーバ２０は送迎が完了したことを記録し、管理サーバ２０における一連の処理の流れが終了する。

上記の処理の中で、ユーザ端末１０の位置情報は随時、管理サーバ２０に送られ記録される。ユーザ端末１０から応答があったときにのみ、位置情報を記録するような構成としてもよい。以上のように、管理サーバ２０がユーザ端末１０とオペレータ端末３０のやり取りを記録しているため、代行車会社が簡単に送迎記録（図４（Ｂ））を得ることができる。例えば、１２時間以内の情報をオペレータ端末３０に表示することもでき、月に一度、管理サーバ２０に記録されている送迎記録をまとめて、月報として代行車会社に渡すことができる。

以上説明してきたように、配車管理システム及び配車管理方法は、ユーザからの視点では、配車要求をユーザ端末で簡単かつ容易に行うことができる。また、一度の操作で複数の代行会社に一斉に配車要求ができるため、特に繁忙期には待ち時間が今までよりも短縮される。

代行車会社からの視点では、代行会社のオペレータは、オペレータ端末で複数のユーザからの配車要求を受けることができ、ユーザを増やす営業をしなくても簡単に配車を請け負うことができる。さらに、代行会社のオペレータは、ユーザの送迎希望時間と地域に合わせて自社の配車ができるため、効率よく配車を請け負うことができる。また、代行車の運転手は従来通りオペレータと無線で連絡ができ、新しいことを覚える負担はなく、新たな設備投資の費用も必要ないため低コストで効率良く送迎できる。従って、ユーザと代行会社の双方にとって、利便性を向上させることができる。

なお、上述した実施例の配車管理システム及び配車管理方法は、一例であり、営業車として代行車を例に挙げて説明したが、本発明の営業車は代行車に限らず、タクシーなどその他の営業車を含むものである。また、本発明の構成や方法は、発明の趣旨を逸脱しない範囲で、適宜変更可能である。

１０ ユーザ端末
１１ 制御部
１２ 通信部
１３ 表示部
１４ 入力部
１５ 記憶部
１６ 出力部
１７ ＧＰＳ受信部
２０ 配車管理サーバ
２１ 制御部
２２ 通信部
２３ 表示部
２４ 入力部
２５ 記憶部
２６ 出力部
３０ オペレータ端末
３１ 制御部
３２ 通信部
３３ 表示部
３４ 入力部
３５ 記憶部
３６ 出力部
４０ 営業車（代行車）
４１ 通信部
４２ 表示部
５０ ネットワーク
６０ ＧＰＳ衛星
１００ 配車管理システム

Claims (6)

1. ユーザが操作するユーザ端末と、営業車に連絡する複数のオペレータ端末と、ユーザ情報と営業車情報を管理する管理サーバと、から構成される配車システムであって、
   ユーザ端末は、
   前記管理サーバに前記ユーザ情報と配車要求を送信し、前記管理サーバから前記営業車情報を受信し、前記営業車に対する応答を送信する通信手段
   を備え、
   複数のオペレータ端末は、
   前記管理サーバに前記営業車の情報を送信し、前記管理サーバから前記配車要求を受信し、前記配車要求に対する応答を送信する通信手段
   を備え、
   管理サーバは、
   前記ユーザ情報と配車要求を格納するユーザ情報格納手段と、
   前記営業車情報を格納する営業車情報格納手段と、
   前記配車要求に対して最初に応答したオペレータ端末の前記営業車情報を前記ユーザ端末に送信する通信手段と、
   を備えることを特徴とする配車システム。
2. 請求項１に記載の配車システムにおいて、前記管理サーバは、前記ユーザ端末から受信した前記ユーザ情報、配車要求及び前記オペレータ端末への応答と、前記オペレータ端末から受信した前記配車要求に対する応答及び前記ユーザ端末への応答を記録する送迎記録格納手段を備えることを特徴とする配車管理システム。
3. 請求項１又は２に記載の配車システムにおいて、前記ユーザ端末は、ユーザの位置情報を検出する位置検出手段を備えることを特徴とする配車管理システム。
4. 請求項１〜３のいずれかに記載の配車システムにおいて、前記ユーザ情報には前記ユーザによって入力される配車希望時間が含まれることを特徴とする配車システム。
5. 請求項１〜４のいずれかに記載の配車システムにおいて、前記営業車情報には運賃の情報が含まれることを特徴とする配車システム。
6. ユーザが操作するユーザ端末と、営業車に連絡する複数のオペレータ端末に接続する管理サーバが行なう配車管理方法であって、
   前記オペレータ端末から受信した営業車情報を格納するステップと、
   前記ユーザ端末から受信したユーザ情報及び配車要求を記録するステップと、
   前記オペレータ端末から受信した前記配車要求に対する応答を記録するステップと、
   前記ユーザ端末から受信した前記オペレータ端末に対する応答を記録するステップと、
   を含むことを特徴とする配車管理方法。