JP2022070717A - 車載装置、配車管理装置、配車システムおよび配車方法 - Google Patents

Abstract

【課題】１台の輸送車両に対し、複数の配車システムからの配車要求が重複してしまうのを防止すること。【解決手段】実施形態に係る車載装置は、取得部と、応答制御部とを備える。取得部は、利用者の配車依頼に基づく輸送車両への配車要求を、第１の配車システムおよび第１の配車システム以外の第２の配車システムからそれぞれ取得可能である。応答制御部は、取得部によって取得された配車要求に対する受諾応答が第１の配車システムおよび第２の配車システムの間で排他的に可能となるように、配車要求の排他制御を実行する。【選択図】図４

Description

開示の実施形態は、車載装置、配車管理装置、配車システムおよび配車方法に関する。

従来、タクシー会社等によって運営されるタクシーの配車システムが知られている。かかるシステムでは、たとえばＧＰＳ（Global Positioning System）を介して各タクシーの現在位置を把握しておき、電話等を通じたタクシー利用者からの配車依頼に応じてセンター側で最適なタクシーを検索し、選出されたタクシーへ配車要求を行う。

また、近年では、タクシー利用者が利用する携帯端末上で動作するタクシー配車アプリを通じて、たとえばタクシー利用者の希望に最も適うタクシーを選出し、配車するタクシー配車サービスが登場してきている（たとえば、特許文献１参照）。

かかるサービスは、たとえばタクシー各社と提携するアプリ提供会社等によって運営され、タクシー利用者は、前述のアプリを通じて、タクシー会社を問わず自分にとって最適なタクシーの配車サービスを受けることができる。一方、タクシーのドライバーは、かかるサービスを通じ、自社の配車システム以外からの配車要求を受けることができ、タクシーが客を乗せている状態の割合を示す実車率を向上させることができる。

特開２０１９－２０９４２号公報

しかしながら、従来技術には、１台のタクシーに対し、複数の配車システムからの配車要求が重複してしまうのを防止するうえで、さらなる改善の余地がある。

たとえば、上述した従来技術を用いた場合、１台のタクシーがほぼ同時に複数の配車システムからの配車要求を受けることが起こりうる。かかる場合、たとえばドライバーが一方の配車要求を受諾し、他方の配車要求を断れば、断られた方は新たに適したタクシーを選出せねばならず、手間がかかってしまう。

また、たとえばドライバーが故意にまたはミス等により複数の配車要求を受諾してしまった場合、タクシー利用者を長時間待たせてしまったり、タクシー側の無断キャンセルが生じたりすることが起こりうる。

実施形態の一態様は、上記に鑑みてなされたものであって、１台の輸送車両に対し、複数の配車システムからの配車要求が重複してしまうのを防止することができる車載装置、配車管理装置、配車システムおよび配車方法を提供することを目的とする。

実施形態の一態様に係る車載装置は、取得部と、応答制御部とを備える。前記取得部は、利用者の配車依頼に基づく輸送車両への配車要求を、第１の配車システムおよび該第１の配車システム以外の第２の配車システムからそれぞれ取得可能である。前記応答制御部は、前記取得部によって取得された前記配車要求に対する受諾応答が前記第１の配車システムおよび前記第２の配車システムの間で排他的に可能となるように、前記配車要求の排他制御を実行する。

実施形態の一態様によれば、１台の輸送車両に対し、複数の配車システムからの配車要求が重複してしまうのを防止することができる。

図１は、実施形態の比較例に係る配車方法の概要説明図である。 図２は、実施形態に係る配車方法の概要説明図である。 図３は、第１の実施形態に係る配車方法の概要説明図である。 図４は、第１の実施形態に係る統合配車システムの構成例を示すブロック図である。 図５は、第１の実施形態に係る統合配車システムの処理シーケンスの一例を示す図である。 図６は、第２の実施形態に係る配車方法の概要説明図である。 図７は、第２の実施形態に係る統合配車システムの構成例を示すブロック図である。 図８は、第２の実施形態に係る統合配車システムの処理説明図である。 図９は、第２の実施形態に係る統合配車システムの処理シーケンスの一例を示す図である。 図１０は、第３の実施形態に係る配車方法の概要説明図である。 図１１は、環境情報の一例を示す図である。 図１２は、第３の実施形態に係る統合配車システムの構成例を示すブロック図である。 図１３は、第３の実施形態に係る統合配車システムの処理説明図である。 図１４は、第３の実施形態に係る統合配車システムの処理シーケンスの一例を示す図である。 図１５は、変形例の説明図である。

以下、添付図面を参照して、本願の開示する車載装置、配車管理装置、配車システムおよび配車方法の実施形態を詳細に説明する。なお、以下に示す実施形態によりこの発明が限定されるものではない。

また、以下では、実施形態に係る統合配車システム１が、１台のタクシーＴが第１の配車システム２および第２の配車システム３のそれぞれから配車要求を受けることができる統合システムである場合を例に挙げて説明を行う。

まず、実施形態に係る配車方法の概要について、図１および図２を用いて説明する。図１は、本実施形態の比較例に係る配車方法の概要説明図である。また、図２は、実施形態に係る配車方法の概要説明図である。

図１に示すように、統合配車システム１は、第１の配車システム２と、第２の配車システム３とを含む。

第１の配車システム２は、たとえばタクシー会社等により運営されるシステムであり、第１の配車管理装置２０を含む。第２の配車システム３は、たとえばタクシー各社と提携するアプリ提供会社等により運営されるシステムであり、第２の配車管理装置３０を含む。

第１の配車管理装置２０は、たとえばＧＰＳを介して各タクシーの現在位置を把握しておき、電話等を通じたタクシー利用者からの配車依頼に応じて最適なタクシーを検索し、選出されたタクシーへ配車要求を行う装置である。

また、第２の配車管理装置３０は、同じくＧＰＳを介して各タクシーの現在位置を把握しておき、タクシー利用者の携帯端末上で動作するタクシー配車アプリを通じた配車依頼に応じて、たとえばタクシー利用者の希望に最も適うタクシーを選出し、選出されたタクシーへ配車要求を行う装置である。

ただし、比較例に係る配車方法を用いた場合、図１に示すように、１台のタクシーＴが第１の配車システム２からの配車要求（以下、「第１の配車要求」という）と第２の配車システム３からの配車要求（以下、「第２の配車要求」という）をほぼ同時に受け、バッティングすることが起こりうる。

かかる場合、たとえばタクシーＴのドライバーが一方の配車要求を受諾し、他方の配車要求を断れば、断られた方は新たに適したタクシーを選出せねばならず、手間がかかってしまう。

また、たとえばドライバーが故意にまたはミス等により双方の配車要求を受諾してしまった場合、タクシー利用者を長時間待たせてしまったり、タクシー側の無断キャンセルが生じたりすることが起こりうる。

そこで、実施形態に係る配車方法では、図２に示すように、第１の配車システム２および第２の配車システム３のうちから配車要求を、タクシーＴのドライバーに対しては、常に１つのみ通知するようにした。

なお、図２には、第１の配車システム２からの第１の配車要求のみが、タクシーＴのドライバーに対して通知される例を示している。

これにより、タクシーＴのドライバーは、受諾対象となる配車要求を常に１つだけ認識することとなるので、１台のタクシーＴに対し、複数の配車システムからの配車要求が重複してしまうのを防止することができる。

以下、本実施形態に係る配車方法についてより具体的に、第１の実施形態、第２の実施形態および第３の実施形態の順に説明する。

（第１の実施形態）
図３は、第１の実施形態に係る配車方法の概要説明図である。第１の実施形態に係る配車方法では、タクシーＴに搭載された車載装置５０が、第１の配車要求および第２の配車要求のうち、早い方を優先的にドライバーに対し通知する。車載装置５０は、統合配車システム１におけるタクシーＴ側の端末装置である。

具体的には、図３に示すように、第１の実施形態に係る配車方法では、車載装置５０がたとえば第１の配車要求の方を先行して取得した場合、車載装置５０は、配車要求禁止フラグを第２の配車管理装置３０へ送信し、これを設定させる。

そして、かかる配車要求禁止フラグが設定された第２の配車管理装置３０は、図示略の配車要求許可フラグが車載装置５０から送信され、第２の配車管理装置３０に設定されるまでは、タクシーＴに対する配車要求を行わない。

一方、車載装置５０は、先行して取得した第１の配車要求については、タクシーＴのドライバーへこれを通知する。そして、ドライバーがかかる配車要求をたとえば車載装置５０を介して受諾したならば、車載装置５０は、第１の配車要求に応じた迎車・実車をガイドし、タクシーＴによる迎車・実車を支援する。

そして、第１の配車要求の依頼主であるタクシー利用者がタクシーＴを降車し、タクシーＴが空車状態となったならば、車載装置５０は、前述の配車要求許可フラグを第２の配車管理装置３０へ送信し、これを設定させる。また、ドライバーが第１の配車要求を受諾しなかった場合も、車載装置５０は配車要求許可フラグを第２の配車管理装置３０へ送信し、これを設定させる。

なお、図３に示した例では、第１の配車要求の方が先行して取得されることとしたが、第２の配車要求が先行して取得された場合には、車載装置５０は、配車要求禁止フラグを第１の配車管理装置２０へ送信し、これを設定させることとなる。

すなわち、第１の実施形態に係る配車方法では、先行して取得した配車要求１つのみを優先的に取り扱う排他制御を実行する。

これにより、１台のタクシーＴに対し、第１の配車システム２および第２の配車システム３それぞれからの配車要求が重複してしまうのを防止することができる。

次に、図４は、第１の実施形態に係る統合配車システム１の構成例を示すブロック図である。なお、図４では、本実施形態の特徴を説明するために必要な構成要素のみを表しており、一般的な構成要素についての記載を省略している。

換言すれば、図４に図示される各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。例えば、各ブロックの分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することが可能である。なお、かかる点は、後に図７および図１２に示すブロック図についても同様とする。

また、図４、後に示す図７および図１２を用いた説明では、既に説明済みの構成要素については、説明を簡略するか、説明を省略する場合がある。

図４に示すように、第１の実施形態に係る統合配車システム１は、第１の配車管理装置２０と、第２の配車管理装置３０と、車載装置５０と、携帯端末１００とを含む。なお、ここで、第２の配車管理装置３０は、第１の配車管理装置２０とほぼ同様の構成であるものとする。

第１の配車管理装置２０と、第２の配車管理装置３０と、車載装置５０と、携帯端末１００とは、インターネットや携帯電話回線網等のネットワークＮを介して相互に通信可能に設けられる。

第１の配車管理装置２０から説明する。第１の配車管理装置２０は、通信部１１と、記憶部１２と、制御部１３とを備える。

通信部１１は、たとえば、ＮＩＣ（Network Interface Card）等によって実現される。通信部１１は、ネットワークＮと有線または無線で接続され、ネットワークＮを介して、第２の配車管理装置３０、車載装置５０および携帯端末１００との間で情報の送受信を行う。

なお、通信部１１は、たとえば第１の配車システム２に含まれる各タクシーと携帯電話回線網等を介して直接に情報（現在位置や空車／実車状態等）の送受信を行うことも可能である。

記憶部１２は、たとえば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現され、図４の例では、車両情報１２ａと、依頼情報１２ｂと、交通情報１２ｃと、配車要求禁止フラグ情報１２ｄとを記憶する。

車両情報１２ａは、たとえば第１の配車システム２に含まれる各タクシーの状況に関する情報であり、各タクシーの現在位置や空車／実車状態等を含む。依頼情報１２ｂは、タクシー利用者から携帯端末１００を介して依頼される配車依頼に関する情報であり、配車依頼の依頼内容を含む。交通情報１２ｃは、たとえば図示略の交通情報提供システム等から提供される交通状況に関する情報であり、渋滞情報等を含む。

配車要求禁止フラグ情報１２ｄは、上述した配車要求禁止フラグに関する情報であり、車載装置５０から配車要求禁止フラグを取得した場合には、該当するタクシーＴに紐づけて配車要求禁止フラグが設定される。また、車載装置５０から配車要求許可フラグを取得した場合には、該当するタクシーＴに紐づけて配車要求許可フラグが設定される。

制御部１３は、コントローラ（controller）であり、たとえば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、記憶部１２に記憶されている図示略の各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１３は、たとえば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現することができる。

制御部１３は、取得部１３ａと、配車制御部１３ｂとを有し、以下に説明する情報処理の機能や作用を実現または実行する。

取得部１３ａは、通信部１１を介して、車載装置５０から送信される各タクシーの状況を取得し、車両情報１２ａへ格納する。また、取得部１３ａは、通信部１１を介して、携帯端末１００から送信される配車依頼を取得し、依頼情報１２ｂへ格納する。

また、取得部１３ａは、通信部１１を介して、図示略の交通情報提供システム等から提供される交通情報を取得し、交通情報１２ｃへ格納する。

また、取得部１３ａは、車載装置５０から配車要求禁止フラグが送信された場合に、通信部１１を介してこれを取得し、配車要求禁止フラグ情報１２ｄへ設定する。また、取得部１３ａは、車載装置５０から配車要求許可フラグが送信された場合に、通信部１１を介してこれを取得し、配車要求禁止フラグ情報１２ｄへ設定する。

配車制御部１３ｂは、車両情報１２ａ、依頼情報１２ｂおよび交通情報１２ｃに基づいて配車依頼に応じた最適なタクシーＴを選出する。また、配車制御部１３ｂは、通信部１１を介して、選出した該当のタクシーＴに対し配車要求を送信する。配車要求には、依頼情報１２ｂが含まれる。配車要求が送信されるまでには、（１）携帯端末１００のタクシー配車アプリ（各タクシー会社（組合）専用アプリ）を通じてタクシー利用者により入力され、送信された、配車依頼に必要なデータに基づいて配車制御部１３ｂが自動的に配車する方法がある。かかる方法では、機械学習を経て生成された学習モデル、いわゆるＡＩ（Artificial Intelligence）を用いることも可能である。また、（２）オペレータＯＰが電話等を通じたタクシー利用者の発話内容に基づいてマニュアル操作で配車依頼を入力し、かかる入力に応じてディスプレイ等に表示される配車関連情報を確認しつつ、オペレータＯＰがデータ送信操作や音声等により配車する方法もある。また、上記（１），（２）が混在する方法もある。

次に、車載装置５０について説明する。車載装置５０は、通信部５１と、記憶部５２と、制御部５３とを備える。

通信部５１は、通信部１１と同様に、たとえば、ＮＩＣ等によって実現される。通信部５１は、ネットワークＮと無線で接続され、ネットワークＮを介して、第１の配車管理装置２０、第２の配車管理装置３０および携帯端末１００との間で情報の送受信を行う。

記憶部５２は、記憶部１２と同様に、たとえば、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現され、図４の例では、依頼情報５２ａと、地図情報５２ｂと、交通情報５２ｃとを記憶する。

依頼情報５２ａは、前述の依頼情報１２ｂに相当する。地図情報５２ｂは、ナビゲーションに用いられる地図のデータベースである。交通情報５２ｃは、前述の交通情報１２ｃに相当する。

制御部５３は、制御部１３と同様に、コントローラであり、たとえば、ＣＰＵやＭＰＵ等によって、記憶部５２に記憶されている図示略の各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部５３は、制御部１３と同様に、たとえば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現することができる。

制御部５３は、取得部５３ａと、応答制御部５３ｂと、通知部５３ｃとを有し、以下に説明する情報処理の機能や作用を実現または実行する。

取得部５３ａは、通信部５１を介して、第１の配車管理装置２０または第２の配車管理装置３０から送信される配車要求を取得し、配車要求に含まれる依頼内容を依頼情報５２ａへ格納する。

応答制御部５３ｂは、第１の配車管理装置２０または第２の配車管理装置３０から送信される配車要求のうち、先行して取得された配車要求を優先的に取り扱う排他制御を行う。具体的には、上述したように、応答制御部５３ｂは、第１の配車管理装置２０または第２の配車管理装置３０のうち、先行して取得された配車要求の内容を、ドライバーＤに向けて通知部５３ｃに通知させる。

また、応答制御部５３ｂは、かかる通知に対し、ドライバーＤの受諾操作を受け付けた場合に、第１の配車管理装置２０または第２の配車管理装置３０のうち、先行して取得された配車要求を送信した一方へ受諾応答を送信する。また、応答制御部５３ｂは、受諾した配車要求に応じた迎車・実車を図示略のディスプレイやスピーカ等を介してガイドし、タクシーＴによる迎車・実車を支援する。

なお、受諾前である場合、基本的にドライバーＤに選択権がある。したがって、受諾前に複数の配車要求があった場合、たとえばドライバーＤは、ディスプレイ等に表示された複数の配車要求データの中から、そのうちの一つを選択する受諾操作を行うこととなる。なお、かかる選択の変形例として、たとえばドライバーＤによって行われる初期動作設定により、自動的に選択が行われるようにしてもよい。自動的な選択は、たとえば表示順に行われてもよいし、複数の配車要求があった場合にいずれを選択するかの既定の設定により行われてもよい。応答制御部５３ｂは、その選択した方に受諾応答を送信し、選択しなかった方に辞退応答を送信することとなる。

なお、他にも、応答時間制限を設けてもよい。かかる場合、配車管理装置側では、所定の応答時間内に車載装置５０から受諾応答がなければ、配車要求を取り消し、別の候補となるタクシーＴの車載装置５０へ改めて配信要求を送信する。また、予め複数の候補に一斉に配車要求を送信しておき、最も受諾応答の早いタクシーＴを配車するようにしてもよい。

また、応答制御部５３ｂは、第１の配車管理装置２０または第２の配車管理装置３０のうち、先行して取得された配車要求を送信した一方に対する他方へ、配車要求禁止フラグを送信する。配車要求禁止フラグを送信された第１の配車管理装置２０または第２の配車管理装置３０は、配車要求禁止フラグ情報１２ｄへ配車要求禁止フラグを設定する。そして、配車要求許可フラグが車載装置５０から送信され、配車要求禁止フラグ情報１２ｄへ設定されるまでは、該当の車載装置５０に対する配車要求を行わない。

通知部５３ｃは、図示略のディスプレイやスピーカ等の通知デバイスを介して、ドライバーＤに対し、先行して取得された配車要求の内容を通知する。

第２の配車管理装置３０は、第１の配車管理装置２０とほぼ同様の構成であるが、携帯端末１００上で動作するアプリを通じて配車依頼を受け付け、タクシー会社を問わず配車要求を車載装置５０へ送信できる点が第１の配車管理装置２０とは異なる。

次に、第１の実施形態に係る統合配車システム１が実行する処理の流れについて、図５を用いて説明する。図５は、第１の実施形態に係る統合配車システム１の処理シーケンスの一例を示す図である。なお、図５を用いた説明では、第１の配車要求が先行して取得され、ドライバーＤがこれを受諾するものとする。

まず、第１の配車管理装置２０が、携帯端末１００－１を介してタクシー利用者の配車依頼を受け付けると、第１の配車管理装置２０は、選出したタクシーＴの車載装置５０へ、第１の配車要求を送信する（ステップＳ１０１）。そして、車載装置５０は、第１の配車要求を取得する（ステップＳ１０２）。

そして、車載装置５０は、かかる第１の配車要求の内容をドライバーＤへ通知し、ドライバーＤがこれを受諾すると、受諾応答を第１の配車管理装置２０へ送信する（ステップＳ１０３）。そして、第１の配車管理装置２０はこの受託応答を受信し、その結果携帯端末１００－１を介してタクシー利用者へ配車情報を通知する。また、当該タクシーＴに対して配車要求禁止フラグを設定し、当該タクシーＴが空車になるまで配車要求が行われないようにする。

なお、ドライバーＤの受諾前に他の配車管理装置（たとえば第２の配車管理装置３０）から配車要求があった場合は、各配車要求が車載装置５０のディスプレイに表示され、ドライバーＤが、希望する配車要求を選択操作する。そして、ドライバーＤが選択した配車要求に対して受諾応答が送信され、他の配車要求に対しては辞退応答が送信される。たとえば、ドライバーＤが第１の配車要求の選択操作を行うと、受諾応答を第１の配車管理装置２０へ送信（ステップＳ１０３）することとなる。

一方、車載装置５０は、第２の配車管理装置３０へ配車要求禁止フラグを送信する（ステップＳ１０４）。第２の配車管理装置３０は、これを取得すると（ステップＳ１０５）、配車要求禁止フラグを設定する（ステップＳ１０６）。

そして、第２の配車管理装置３０は、かかる配車要求禁止フラグが設定されている間は、携帯端末１００－２からの配車依頼を受けても、車載装置５０に対しては、第２の配車要求を送信しない（ステップＳ１０７）。つまり、第２の配車管理装置３０は、配車要求禁止フラグが設定されていない適切な条件のタクシーＴに搭載された車載装置５０に配車要求を行う。

そして、車載装置５０は、受諾応答した第１の配車要求に応じた迎車・実車を支援する（ステップＳ１０８）。その後、第１の配車要求に応じた実車が終了すると（ステップＳ１０９）、車載装置５０は、タクシーＴが空車になったことを示す空車情報を第１の配車管理装置２０へ送信する（ステップＳ１１０）。そして、第１の配車管理装置２０はこの空車情報を受信し、当該タクシーＴに対する配車要求禁止フラグを解除し、当該タクシーＴに配車要求が行われるようにする。

また、車載装置５０は、第２の配車管理装置３０に対しては、配車要求許可フラグを送信する（ステップＳ１１１）。第２の配車管理装置３０は、これを取得すると（ステップＳ１１２）、配車要求許可フラグを設定する（ステップＳ１１３）、言い換えれば配車要求禁止フラグを解除する。

上述してきたように、第１の実施形態に係る車載装置５０は、取得部５３ａと、応答制御部５３ｂとを備える。取得部５３ａは、利用者の配車依頼に基づくタクシーＴ（「輸送車両」の一例に相当）への配車要求を、第１の配車システム２および第２の配車システム３からそれぞれ取得可能である。応答制御部５３ｂは、取得部５３ａによって取得された配車要求に対する受諾応答が第１の配車システム２および第２の配車システム３の間で排他的に可能となるように、配車要求の排他制御を実行する。

したがって、第１の実施形態に係る車載装置５０によれば、１台のタクシーＴに対し、第１の配車システム２および第２の配車システム３からの配車要求が重複してしまうのを防止することができる。また、受諾された配車要求以外の配車要求が、１台のタクシーＴに対し要求されたままの状態で長時間維持されるのを防止することができる。すなわち、他のタクシーＴへの配車要求の切り替えが適切にできなくなくなるのを防止することができる。

また、応答制御部５３ｂは、第１の配車システム２および第２の配車システム３のうち、先行して取得された配車要求を送信した一方に対し、受諾応答が可能となるように当該配車要求の内容をタクシーＴのドライバーＤへ向けて通知するとともに、上記一方に対する他方に対し、配車要求禁止フラグ（「配車要求禁止」の一例に相当）を設定させる。

したがって、第１の実施形態に係る車載装置５０によれば、車載装置５０の主導で、配車要求の排他制御を実行することが可能となる。

（第２の実施形態）
次に、第２の実施形態について説明する。図６は、第２の実施形態に係る配車方法の概要説明図である。第２の実施形態に係る配車方法では、第１の配車システム２Ａが第２の配車システム３Ａの配車情報を随時取得する。そして、第１の配車システム２ＡのオペレータＯＰが、第１の配車システム２Ａおよび第２の配車システム３Ａ双方の配車状況を監視する。

そして、タクシーＴの車載装置５０Ａが、第１の配車システム２Ａおよび第２の配車システム３のいずれからの配車要求を受け付け可能であるかを、オペレータＯＰが監視状況および指示操作に基づいて車載装置５０Ａに切り替えさせる。なお、オペレータＯＰは、配車管理者等であってもよい。

具体的には、図６に示すように、第１の配車管理装置２０Ａは、第２の配車管理装置３０Ａから、第２の配車システム３Ａの配車情報を随時取得する。そして、これに基づき、第１の配車システム２ＡのオペレータＯＰが、第１の配車システム２Ａおよび第２の配車システム３Ａ双方の配車状況を監視する。

そして、オペレータＯＰは、たとえば第１の配車システム２Ａにおいてタクシー利用者からの配車依頼があった場合に、かかる配車依頼に応じてあるタクシーＴを確保したければ、かかるタクシーＴの車載装置５０Ａへ第１の配車システム２Ａだけを配車要求の受付先として切り替えさせる切替指示を送信する。

そして、切替指示を受けた車載装置５０Ａは、かかる切替指示に応じて受付先システムを切り替える。第１の配車システム２Ａだけを配車要求の受付先とした場合、車載装置５０Ａは、第２の配車システム３Ａ側から配車要求を受けても受付不可応答を返す。

すなわち、第２の実施形態に係る配車方法では、第１の配車システム２Ａおよび第２の配車システム３Ａ双方の配車状況を監視し、監視状況に応じて車載装置５０Ａを一方からの配車要求のみを受け付け可能とさせる排他制御を実行する。

これにより、１台のタクシーＴに対し、第１の配車システム２Ａおよび第２の配車システム３Ａそれぞれからの配車要求が重複してしまうのを防止することができる。

次に、図７は、第２の実施形態に係る統合配車システム１Ａの構成例を示すブロック図である。なお、図７は、図４に対応しているため、図７を用いた説明では、図４と異なる点について主に説明する。

図７に示すように、第１の配車管理装置２０Ａは、記憶部１２が配車要求禁止フラグ情報１２ｄに代えて他システム監視情報１２ｅを記憶する点が第１の実施形態とは異なる。また、制御部１３が、監視部１３ｃをさらに有する点が第１の実施形態とは異なる。

他システム監視情報１２ｅは、通信部１１を介して取得部１３ａによって取得される自システム以外の他システムの配車状況等を含む情報である。監視部１３ｃは、かかる他システム監視情報１２ｅの内容を、ディスプレイ等を介してオペレータＯＰへ提示する。

また、監視部１３ｃは、監視状況に応じてオペレータＯＰから入力される指示操作を受け付け、かかる指示操作に応じたたとえば前述の切替指示を、車載装置５０Ａへ向けて配車制御部１３ｂに送信させる。

また、車載装置５０Ａは、制御部５３が、切替部５３ｄをさらに有する点が第１の実施形態とは異なる。切替部５３ｄは、通信部５１および取得部５３ａを介して第１の配車管理装置２０Ａからの切替指示を取得した場合に、かかる切替指示に応じて応答制御部５３ｂに受付先システムを切り替えさせる。

ここで、図８を用いて、より分かりやすく説明する。図８は、第２の実施形態に係る統合配車システム１Ａの処理説明図である。ここでは、第１の配車システム２Ａについてのみ専有的に受け付け可能とする例を示す。

図８に示すように、タクシー利用者から携帯端末１００を通じ、配車依頼を受けたものとする。そして、かかるタクシー利用者は、第１の配車システム２Ａにおけるお得意様であり、オペレータＯＰは、近くにいる自社のタクシーＴをぜひとも確保したいと判断したものとする。

かかる場合に、オペレータＯＰは、第２の配車システム３Ａの配車状況を含む他システム監視情報１２ｅの内容を確認し、所望のタクシーＴが空車である、すなわち他のシステムの配車要求を受諾していないことを把握できたならば、タクシーＴの車載装置５０Ａに対し切替指示を行う。

そして、車載装置５０Ａは、かかる切替指示に応じて受付先システムを切り替え、たとえば該当のタクシー利用者が降車するまでの間、図８に示すように第１の配車システム２Ａからのみ配車要求を受け付ける。

そして、たとえばタクシー利用者が降車したならば、車載装置５０Ａは、かかる第１の配車システム２Ａからのみ受け付ける切り替え状態を解除する。なお、実車中は配車要求を受諾できないため、かかる解除はタクシー利用者が乗車した際に行ってもよい。

次に、第２の実施形態に係る統合配車システム１Ａが実行する処理の流れについて、図９を用いて説明する。図９は、第２の実施形態に係る統合配車システム１Ａの処理シーケンスの一例を示す図である。

まず、第１の配車管理装置２０Ａは、第２の配車管理装置３０Ａから配車情報を随時取得し、かかる他システムの配車状況を随時監視する（ステップＳ２０１）。このとき、第１の配車管理装置２０Ａは、取得した配車情報をディスプレイ等に表示する。

ここで、携帯端末１００－１を介してタクシー利用者の配車依頼を受け付けたものとする。すると、オペレータＯＰは、配車情報に基づく所定の指示操作により、監視状況に応じて受付先システムの切り替えを指示し（ステップＳ２０２）、第１の配車管理装置２０Ａは、かかる切替指示を車載装置５０Ａへ送信する（ステップＳ２０３）。

そして、車載装置５０Ａは、切替指示を取得すると（ステップＳ２０４）、かかる切替指示に応じて受付先システムを切り替える（ステップＳ２０５）。

そして、第１の配車管理装置２０Ａは、受けていた配車依頼に応じた第１の配車要求を車載装置５０Ａへ送信する（ステップＳ２０６）。また、ここで、第２の配車管理装置３０Ａが、携帯端末１００－２を介したタクシー利用者の配車依頼を受け付け、第２の配車要求を車載装置５０Ａへ送信したものとする（ステップＳ２０７）。

これに応じ、車載装置５０Ａは、第１の配車要求および第２の配車要求を取得する（ステップＳ２０８）。ただし、車載装置５０Ａは、ステップＳ２０５において受付先システムを第１の配車システム２へ切り替えているので、第１の配車要求に対しては受諾応答を返すが（ステップＳ２０９）、第２の配車要求に対しては受付不可応答を返す（ステップＳ２１０）。なお、仮に第１の配車要求に先行して第２の配車要求を取得しても、車載装置５０Ａは、受付先システムを第１の配車システム２へ切り替えているので、第２の配車要求に対しては受付不可応答を返す。

そして、車載装置５０Ａは、受諾応答した第１の配車要求に応じた迎車・実車を支援する（ステップＳ２１１）。その後、第１の配車要求に応じた実車が終了すると（ステップＳ２１２）、車載装置５０Ａは、タクシーＴが空車になったことを示す空車情報を第１の配車管理装置２０Ａへ送信する（ステップＳ２１３）。

上述してきたように、第２の実施形態に係る第１の配車管理装置２０Ａは、利用者の配車依頼に基づいてタクシーＴを配車する第１の配車システム２の配車管理装置であって、取得部１１ａと、配車制御部１１ｂとを備える。取得部１１ａは、第１の配車システム２Ａ以外の第２の配車システム３Ａの配車状況を取得可能である。配車制御部１１ｂは、取得部１１ａによって取得された第２の配車システム３の配車状況に基づいて、タクシーＴが第１の配車システム２および第２の配車システム３のうちの一方からのみ上記配車依頼に基づく配車要求を受け付け可能となるように、配車要求の排他制御を実行する。

したがって、第２の実施形態に係る第１の配車管理装置２０Ａによれば、１台のタクシーＴに対し、第１の配車システム２および第２の配車システム３からの配車要求が重複してしまうのを防止することができる。

また、第２の配車システム３の配車状況を監視する監視部１３ｃをさらに備え、配車制御部１３ｂは、第１の配車システム２の指示に基づき、監視部１３ｃの監視状況に応じた配車要求の受付先の切替指示をタクシーＴへ送信し、上記一方について専有的に配車要求を受け付け可能となるように、切替指示に基づいてタクシーＴに上記受付先を切り替えさせる。第１の配車システム２の指示は、オペレータＯＰの操作に基づくものであってもよいし、学習モデルに基づく自動的なものであってもよいし、そのいずれを含むものであってもよい。

したがって、第２の実施形態に係る第１の配車管理装置２０Ａによれば、第１の配車管理装置２０Ａの主導で、配車要求の排他制御を実行することが可能となる。

（第３の実施形態）
次に、第３の実施形態について説明する。図１０は、第３の実施形態に係る配車方法の概要説明図である。なお、図１０は、図６に対応しているため、図１０を用いた説明では、図６と異なる点について主に説明する。

図１０に示すように、第３の実施形態に係る配車方法では、第１の配車管理装置２０Ｂがさらに各種の環境情報を取得する点が第２の実施形態とは異なる。また、タクシーＴの車載装置５０Ｂが、第１の配車システム２Ｂおよび第２の配車システム３Ｂのいずれからの配車要求を受け付け可能であるかを、オペレータＯＰが監視状況、指示操作および環境情報に基づいて車載装置５０Ｂに切り替えさせる点が第２の実施形態とは異なる。

環境情報の一例を図１１に示す。図１１は、環境情報の一例を示す図である。図１１に示すように、環境情報は、季節や、日付、時間、予約情報、顧客分布、イベントの進行状況等を含む。

すなわち、第３の実施形態に係る配車方法では、第１の配車システム２Ｂおよび第２の配車システム３Ｂ双方の配車状況を監視するとともにこれらの環境情報を取得し、監視状況および環境情報に応じて車載装置５０Ｂを一方からの配車要求のみを受け付け可能とさせる排他制御を実行する。

これにより、１台のタクシーＴに対し、第１の配車システム２Ｂおよび第２の配車システム３Ｂそれぞれからの配車要求が重複してしまうのを防止することができる。

次に、図１２は、第３の実施形態に係る統合配車システム１Ｂの構成例を示すブロック図である。なお、図１２は、図７に対応しているため、図１２を用いた説明では、図７と異なる点について主に説明する。

図１２に示すように、第１の配車管理装置２０Ｂは、記憶部１２がさらに環境情報１２ｆを記憶する点が第２の実施形態とは異なる。環境情報１２ｆは、図１１に示した各種の環境情報に相当し、たとえば通信部１１を介して取得部１３ａによって取得される。また、手入力によって設定されてもよい。監視部１３ｃは、環境情報１２ｆの内容を、他システム監視情報１２ｅの内容に加えてオペレータＯＰへ提示可能である。

また、監視部１３ｃは、監視状況および／または環境情報１２ｆの内容に応じてオペレータＯＰから入力される指示操作を受け付け、かかる指示操作に応じたたとえば前述の切替指示を、車載装置５０Ｂへ向けて配車制御部１３ｂに送信させる。

ここで、図１３を用いて、より分かりやすく説明する。図１３は、第３の実施形態に係る統合配車システム１Ｂの処理説明図である。ここでは、第１の配車システム２Ｂについてのみ専有的に受け付け可能とする例を示す。

なお、第３の実施形態では、第１，第２の実施形態のようにタクシー利用者の実際の配車依頼をトリガとするのではなく、将来の配車依頼を自社システムで受けたい場面を想定している。かかる場面は、たとえば、イベント終了時等、多くのタクシー利用者が見込め、利益の拡大を期待できる場面である。

図１３に示すように、オペレータＯＰは、たとえば大勢の帰宅客が見込めるとして、野球のナイター終了にあわせて自社のタクシー車両を確保しておきたいと判断したものとする。

そして、オペレータＯＰは、たとえば環境情報１２ｆに含まれるイベントの進行状況を確認し、ナイター終了が近づいていることを把握できたならば、複数のタクシーＴの各車載装置５０Ｂに対し、期限付き（ここでは２時間）の切替指示を行う。

そして、各車載装置５０Ｂは、かかる切替指示に応じて受付先システムを切り替え、２時間の間、図１３に示すように第１の配車システム２Ｂからのみ配車要求を受け付ける。

そして、２時間が経過したならば、各車載装置５０Ｂは、かかる第１の配車システム２Ａからのみ受け付ける切り替え状態を解除する。

このように、環境情報１２ｆの内容に応じたたとえばスケジューリングを可能とすることで、アプリ提供会社等と提携しつつも、タクシー会社の経営戦略を優先した配車を適宜行うことが可能となる。

なお、図１３では、イベント終了時を例に挙げたが、この他にも、たとえばお得意先の企業等の近くを走行している空車のタクシーＴを、出張帰りの人が多い時間や退社時間等の狙いの時間帯に自社システムから配車したい場合等にも有効である。また、第２の実施形態で示した図８の例で、たとえばお得意様の過去の利用状況に基づいて配車依頼が予測される場合に、自社システムから配車したい場合等にも有効である。また、解除は、スケジューリングに限らず、既に述べたように、タクシー利用者の乗車時または降車時のたびに行ってもよい。また、将来の配車依頼をオペレータＯＰが判断するのではなく、既に述べたようにＡＩ等を用いるようにしてもよい。

次に、第３の実施形態に係る統合配車システム１Ｂが実行する処理の流れについて、図１４を用いて説明する。図１４は、第３の実施形態に係る統合配車システム１Ｂの処理シーケンスの一例を示す図である。

まず、第１の配車管理装置２０Ｂは、第２の配車管理装置３０Ｂから配車情報を随時取得し、かかる他システムの配車状況を随時監視する（ステップＳ３０１）。

また、第１の配車管理装置２０Ｂは随時、外部や車載装置５０Ｂ等から各種の環境情報を取得する（ステップＳ３０２）。このとき、第１の配車管理装置２０Ｂは、取得した各種の環境情報をディスプレイ等に表示する。そして、オペレータＯＰは、各種の環境情報に基づく所定の指示操作により、監視状況および環境情報に応じた受付先システムの切り替えを指示し（ステップＳ３０３）、第１の配車管理装置２０Ｂは、かかる切替指示を車載装置５０Ｂへ送信する（ステップＳ３０４）。

そして、車載装置５０Ｂは、切替指示を取得すると（ステップＳ３０５）、かかる切替指示に応じて受付先システムを切り替える（ステップＳ３０６）。

以降の処理については、図９に示したステップＳ２０６～ステップＳ２１３と同様であるので、ここでの説明は省略する。

上述してきたように、第３の実施形態に係る第１の配車管理装置２０Ｂにおいて、取得部１３ａはさらに、環境情報１２ｆを取得可能であって、配車制御部１３ｂは、監視部１３ｃの監視状況および／または環境情報１２ｆに応じた指示に基づき、上記切替指示をタクシーＴへ送信する。

したがって、第３の実施形態に係る第１の配車管理装置２０Ｂによれば、監視状況および／または環境情報１２ｆに基づき、第１の配車管理装置２０Ａの主導で、配車要求の排他制御を実行することが可能となる。また、環境情報１２ｆの内容に応じたたとえばスケジューリングを可能とすることで、アプリ提供会社等と提携しつつも、タクシー会社の経営戦略を優先した配車を適宜行うことが可能となる。

（変形例）
なお、上述した第２の実施形態および第３の実施形態では、オペレータＯＰの指示操作に基づいて車載装置５０Ａ，５０Ｂへ切替指示を送信することとしたが、これに限られるものではない。たとえばオペレータＯＰの指示内容を学習した学習モデルを用いることによって、前述の切替指示の送信を自動化してもよい。

図１５は、かかる変形例の説明図である。図１５に示すように、変形例では、たとえば配車制御部１３ｂが、他システム監視情報１２ｅおよび／または環境情報１２ｆに応じたオペレータＯＰの指示内容を適宜学習することによって学習モデルを生成・更新する。かかる学習は、たとえばディープラーニング等の機械学習のアルゴリズムを用いて行うことができる。

学習モデルは、他システム監視情報１２ｅおよび／または環境情報１２ｆが入力された場合に、かかる入力情報に対応する配車要求や切替指示を出力する、指示内容の推定モデルとして機能する。変形例では、配車制御部１３ｂは、かかる学習モデルによって推定された配車要求や切替指示を、オペレータＯＰの指示操作によらず、自動的に車載装置５０Ａ，５０Ｂへ送信することが可能となる。

また、上述した各実施形態では、２つの配車システム２，３を例に挙げたが、３つ以上の配車システム間においても、各実施形態は適用可能である。

また、上述した各実施形態では、車載装置５０，５０Ａ，５０Ｂが、それぞれ物理的に一体で、統合配車システム１，１Ａ，１ＢにおけるタクシーＴ側のいわば端末装置として構成される例を挙げたが、これに限られるものではない。たとえば、車載装置５０，５０Ａ，５０Ｂは、タクシーＴに搭載されたタクシー会社の専用端末と、ドライバーＤが携帯するスマートフォン等の携帯端末上で動作するタクシーＴ向けのタクシー配車アプリとをＷｉ－Ｆｉ（登録商標）等の通信手段で接続し、それぞれを連携動作させることによって仮想的に一体化させるようにしてもよい。

また、上述した各実施形態では、タクシーを例に挙げたが、これに限られるものではなく、利用者の配車依頼に基づいて複数の配車システムから配車要求を受けることができる輸送車両であればよい。

さらなる効果や変形例は、当業者によって容易に導き出すことができる。このため、本発明のより広範な態様は、以上のように表しかつ記述した特定の詳細および代表的な実施形態に限定されるものではない。したがって、添付の特許請求の範囲およびその均等物によって定義される総括的な発明の概念の精神または範囲から逸脱することなく、様々な変更が可能である。

１，１Ａ，１Ｂ 統合配車システム
２，２Ａ，２Ｂ 第１の配車システム
３，３Ａ，３Ｂ 第２の配車システム
１１ 通信部
１１ａ 取得部
１１ｂ 配車制御部
１２ 記憶部
１２ａ 車両情報
１２ｂ 依頼情報
１２ｃ 交通情報
１２ｄ 配車要求禁止フラグ情報
１２ｅ 他システム監視情報
１２ｆ 環境情報
１３ 制御部
１３ａ 取得部
１３ｂ 配車制御部
１３ｃ 監視部
２０，２０Ａ，２０Ｂ 第１の配車管理装置
３０，３０Ａ，３０Ｂ 第２の配車管理装置
５０，５０Ａ，５０Ｂ 車載装置
５１ 通信部
５２ 記憶部
５２ａ 依頼情報
５２ｂ 地図情報
５２ｃ 交通情報
５３ 制御部
５３ａ 取得部
５３ｂ 応答制御部
５３ｃ 通知部
５３ｄ 切替部
１００ 携帯端末
Ｄ ドライバー
Ｎ ネットワーク
ＯＰ オペレータ
Ｔ タクシー

Claims (9)

1. 利用者の配車依頼に基づく輸送車両への配車要求を、第１の配車システムおよび該第１の配車システム以外の第２の配車システムからそれぞれ取得可能な取得部と、
   前記取得部によって取得された前記配車要求に対する受諾応答が前記第１の配車システムおよび前記第２の配車システムの間で排他的に可能となるように、前記配車要求の排他制御を実行する応答制御部と
   を備えることを特徴とする車載装置。
2. 前記応答制御部は、
   前記第１の配車システムおよび前記第２の配車システムのうち、先行して取得された前記配車要求を送信した一方に対し、前記受諾応答が可能となるように当該配車要求の内容を前記輸送車両のドライバーへ向けて通知するとともに、前記一方に対する他方に対し、配車要求禁止を設定させる
   ことを特徴とする請求項１に記載の車載装置。
3. 利用者の配車依頼に基づいて輸送車両を配車する第１の配車システムの配車管理装置であって、
   前記第１の配車システム以外の第２の配車システムの配車状況を取得可能な取得部と、
   前記取得部によって取得された前記第２の配車システムの配車状況に基づいて、前記輸送車両が前記第１の配車システムおよび前記第２の配車システムのうちの一方からのみ前記配車依頼に基づく配車要求を受け付け可能となるように、前記配車要求の排他制御を実行する配車制御部と
   を備えることを特徴とする配車管理装置。
4. 前記第２の配車システムの配車状況を監視する監視部
   をさらに備え、
   前記配車制御部は、
   前記第１の配車システムの指示に基づき、前記監視部の監視状況に応じた前記配車要求の受付先の切替指示を前記輸送車両へ送信し、前記一方について専有的に前記配車要求を受け付け可能となるように、前記切替指示に基づいて前記輸送車両に前記受付先を切り替えさせる
   ことを特徴とする請求項３に記載の配車管理装置。
5. 前記取得部はさらに、環境情報を取得可能であって、
   前記配車制御部は、
   前記監視部の監視状況および／または前記環境情報に応じた指示に基づき、前記切替指示を前記輸送車両へ送信する
   ことを特徴とする請求項４に記載の配車管理装置。
6. 前記配車制御部は、
   前記監視部の監視状況および／または前記環境情報に応じたオペレータによる指示操作の内容に基づいて生成された学習モデルを用いて自動的に前記切替指示を前記輸送車両へ送信する
   ことを特徴とする請求項５に記載の配車管理装置。
7. 利用者の配車依頼に基づいて輸送車両を配車する一の配車システムであって、
   配車管理装置と、
   前記輸送車両に搭載され、前記配車依頼に基づく当該輸送車両への配車要求を、前記一の配車システムおよび当該一の配車システム以外の他の配車システムからそれぞれ取得可能に設けられる車載装置と
   を備え、
   前記配車管理装置または前記車載装置は、
   前記配車要求に対する前記車載装置の受諾応答が前記一の配車システムおよび前記他の配車システムの間で排他的に可能となるように、前記配車要求の排他制御を実行する
   ことを特徴とする配車システム。
8. 利用者の配車依頼に基づく輸送車両への配車要求を、第１の配車システムおよび該第１の配車システム以外の第２の配車システムからそれぞれ取得する取得工程と、
   前記取得工程において取得された前記配車要求に対する受諾応答が前記第１の配車システムおよび前記第２の配車システムの間で排他的に可能となるように、前記配車要求の排他制御を実行する応答制御工程と
   を含むことを特徴とする配車方法。
9. 利用者の配車依頼に基づいて輸送車両を配車する第１の配車システムの配車管理装置を用いた配車方法であって、
   前記第１の配車システム以外の第２の配車システムの配車状況を取得する取得工程と、
   前記取得工程において取得された前記第２の配車システムの配車状況に基づいて、前記輸送車両が前記第１の配車システムおよび前記第２の配車システムのうちの一方からのみ前記配車依頼に基づく配車要求を受け付け可能となるように、前記配車要求の排他制御を実行する配車制御工程と
   を含むことを特徴とする配車方法。

Images