JP2014203173A - 配車システム、配車方法、配車装置、および、配車プログラム - Google Patents

Abstract

【課題】車両の配車効率を高めることが可能な配車システム、配車方法、配車装置、および、配車プログラムを提供する。
【解決手段】配車システムは、目的地への配車を行う配車センターに設置されたセンター端末装置と、複数の車両の各々に搭載されたタクシー端末装置４０とを備える。センター端末装置は、タクシー端末装置４０の各々との通話の開始及び終了を制御する制御メッセージを生成し、制御メッセージの１つである通話への初期リクエストを生成し、初期リクエストにタクシー端末装置４０に自動で着呼させるフック制御コマンドを付加する制御メッセージ生成部と、初期リクエストを送信する制御メッセージ送受信部とを有する。タクシー端末装置４０の各々は、初期リクエストを受信する制御メッセージ送受信部４２と、受信した初期リクエストのフック制御コマンドを解釈してセンター端末装置からの発呼を自動で着呼させるコマンド実行部４５とを有する。
【選択図】図６

Description

本開示の技術は、例えばタクシー等の車両を目的地に対して割り振る配車システム、配車方法、配車装置、および、配車プログラムに関する。

利用客の乗車位置である目的地までのタクシーの配車は、例えば、以下の手順で行われている。まず、利用客が、自身の乗車したい位置をタクシーの配車を行う配車センターに電話等によって連絡する。利用客からの連絡を受けた配車センターは、連絡が可能な範囲に位置している複数のタクシーに対して、利用客の予約に関する情報、例えば、目的地等を一斉に知らせる。複数のタクシーのうちのいずれかが配車センターからの連絡に対して応答することによって、配車センターが、応答のあったタクシーのいずれかを目的地に配車されるタクシーとして選択する（例えば、特許文献１参照）。

配車センターと各タクシーとの音声通話に無線機が用いられる場合には、配車センターからの音声は、通常、全てのタクシーに対して一斉に送信される。各タクシーでは、無線機の受信する周波数が、基地局の送信する周波数にあわせられていれば、基地局を介した配車センターからの音声を無線機が受信する。そのため、各タクシーでは、乗務員が無線機の操作を特に行わずとも、配車センターからの音声が無線機から発せられる（例えば、特許文献２参照）。

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

ところで、配車センターと各タクシーとの音声通話に上述の無線機や基地局を含む無線配車システムが用いられる場合には、基地局等の設備に対する投資や、設備の維持のために費用が嵩む。また、電波法の改正等が行われた場合には、各タクシー会社は無線配車システムを構成する設備の一式を入れ替えなければならず、各タクシー会社が、個別に無線配車システムを維持および管理することは困難であった。

近年では、携帯電話の普及により、携帯電話用の通信インフラによる無線通信が簡単に使用できるため、携帯電話用の通信インフラがタクシーの配車システムとして用いられ始めている。携帯電話用の通信インフラを配車システムに用いた場合には、配車センターの携帯電話と、タクシー携帯電話との間で音声通話を行うことが可能であるものの、こうした音声通話では、配車センターは１台のタクシーにしか連絡することができない。そこで、携帯電話用の通信インフラを用いた配車システムでは、音声通話を行うためのデータ通信技術として、音声信号をデジタル化して送信するＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）が用いられつつある。

しかしながら、配車センターと各タクシーとの間での連絡がＶｏＩＰを用いた音声通話によって行われる場合には、配車センターと各タクシーとの通信が成立するために、各タクシーの乗務員は、配車センターからの着信に応答する動作を行わなければならない。つまり、ＶｏＩＰを用いた配車システムでは、乗務員は、上述した無線配車システムのように着信に対する応答操作を行わずに音声通話を開始することができない。

そのため、乗務員が、例えば車両の走行中等であるために応答する操作を行うことができない場合には、目的地からの距離が近いタクシーであっても、そのタクシーは配車されるタクシーとして選択されない。結果として、目的地に対するタクシーの配車効率が低くなってしまうため、より効率よくタクシーを配車することの可能なシステムが望まれている。こうした問題は、利用客を運送するタクシーの配車に限らず、例えば、故障車等を運搬するレッカー車や、荷物の集荷を行う宅配便の車両等の配車システムにおいても共通する。

本開示の技術は、車両の配車効率を高めることが可能な配車システム、配車方法、配車装置、および、配車プログラムを提供することを目的とする。

本開示の技術における配車システムの一態様は、目的地への配車を行う配車センターに設置されたセンター端末装置と、複数の車両の各々に搭載された車両端末装置とを備える。前記センター端末装置は、前記車両端末装置の各々との通話の開始及び終了を制御する制御メッセージの１つである前記通話への初期リクエストを生成し、前記初期リクエストに前記車両端末装置に自動で着呼させるフック制御コマンドを付加する初期リクエスト生成部と、前記初期リクエストを送信する初期リクエスト送信部とを有する。そして、前記車両端末装置の各々は、前記初期リクエストを受信する初期リクエスト受信部と、受信した前記初期リクエストの前記フック制御コマンドを解釈して前記センター端末装置からの発呼を自動で着呼させるコマンド実行部とを有する。

本開示の技術における配車方法の一態様は、目的地への配車を行う配車センターに設置されたセンター端末装置にて、複数の車両の各々に搭載された車両端末装置と前記センター端末装置との通話の開始および終了を制御する制御メッセージの１つである初期リクエストに前記車両端末装置に自動で着呼させるフック制御コマンドが付加される工程と、前記センター端末装置から前記車両端末装置の各々に前記初期リクエストが送信される工程とを含む。そして、前記車両端末装置の各々にて、前記初期リクエストが受信されて、受信された前記初期リクエストの前記フック制御コマンドが解釈され、前記センター端末装置からの発呼が自動で着呼される工程をさらに含む。

本開示の技術における配車装置の一態様は、目的地への配車を行う配車センターに設置され、複数の車両の各々に搭載された車両端末装置との通話の開始及び終了を制御する制御メッセージの１つである前記通話への初期リクエストを生成し、前記初期リクエストに、前記車両端末装置にて解釈可能なコマンドとして、前記車両端末装置に自動で着呼させるフック制御コマンドを付加する初期リクエスト生成部と、前記初期リクエストを送信する初期リクエスト送信部とを備える。

本開示の技術における配車プログラムの一態様は、目的地への配車を行う配車センターに設置されたセンター端末装置を、複数の車両の各々に搭載された車両端末装置との通話の開始及び終了を制御する制御メッセージの１つである前記通話への初期リクエストを生成し、前記初期リクエストに、前記車両端末装置にて解釈可能なコマンドとして、前記車両端末装置に自動で着呼させるフック制御コマンドを付加する初期リクエスト生成部と、前記初期リクエストを送信する初期リクエスト送信部として機能させる。

本開示における技術の一態様によれば、コマンド実行部が、センター端末装置からの初期リクエストに含まれるフック制御コマンドを解釈することによって、センター端末装置からの発呼を自動で着呼させる。そのため、車両の乗務員が着信に応答する操作を行わずとも、センター端末装置と車両端末装置との間での通話が可能になる。それゆえに、車両端末装置では、車両の走行中であってもセンター端末装置からの連絡を受けることができるため、乗務員の操作を必須とする構成と比べて、配車の効率を高めることができる。

本開示の技術における配車システムの他の態様では、前記車両端末装置の各々は、自車両の位置情報を取得する位置情報取得部と、前記センター端末装置からの発呼を自動で着呼させるか否かを判断する自動着呼判断部とを更に有する。前記初期リクエスト生成部は、前記初期リクエストに前記目的地の位置情報を更に付加する。そして、前記コマンド実行部は、前記自動着呼判断部が、前記目的地の位置情報と前記自車両の位置情報とから算出される距離が所定の距離以内であると判断したときに、前記センター端末装置からの発呼を自動で着呼させることが好ましい。

配車センターが複数の車両に対して予約に関する情報を一斉に知らせた場合には、各車両には、目的地との距離に関わりなく利用客の情報が連絡されるため、目的地に近い車両が配車センターからの連絡に対して応答するとは限らない。つまり、目的地に近い車両が、必ずしも配車される車両として選択されない。それゆえに、車両を目的地に対して効率よく配車する上では、複数の車両のうち、目的地からの距離が近い車両にのみ予約に関する情報が知らされることが好ましい。

しかしながら、配車センターが目的地からの距離が近い車両のみに情報を知らせるためには、配車センターが、各車両の位置情報を常に把握していること、および、目的地と各車両の位置との距離を把握することが必要とされる。そのため、配車センターには、これらを実現するための設備が必要になってしまう。

この点で、本開示の技術における配車システムの他の態様によれば、車両端末装置が、自車両の位置情報と目的地の位置情報とから、センター端末装置からの発呼を自動で着呼するか否かを判断する。そのため、センター端末装置が各車両の現在位置を把握せずとも、目的地から所定の距離以内の車両のみに配車に関する情報を伝えやすくなる。それゆえに、目的地と車両との距離に関わらず、全ての車両に対して情報を伝える構成と比べて、配車センターが高度な設備を備えることなく、目的地に対する配車の効率を高めることができる。

本開示の技術における配車システムの他の態様では、前記初期リクエスト生成部は、前記初期リクエストに前記目的地と車両の位置との間の距離を示す情報である範囲情報を更に付加する。そして、前記コマンド実行部は、前記自動着呼判断部が、前記目的地と前記自車両との間の距離が、前記範囲情報の示す距離以内であると判断したときに、前記センター端末装置からの発呼を自動で着呼させることが好ましい。

本開示の技術における配車システムの他の態様によれば、センター端末装置は、各車両の現在位置を把握せずとも、目的地からの距離がセンター端末装置の設定した距離以内である車両のみに自動着呼させることができる。

本開示の技術における配車システムの他の態様では、前記車両端末装置は、前記センター端末装置からの前記初期リクエストによって着呼したことを前記センター端末に知らせる応答メッセージを生成する応答メッセージ生成部と、前記応答メッセージを送信する応答メッセージ送信部とを更に有する。前記センター端末装置は、前記応答メッセージを受信する応答メッセージ受信部と、前記初期リクエストを送信してから経過した時間を測定する時間測定部とを有する。そして、前記初期リクエスト生成部は、前記時間測定部の測定する時間が所定の時間を経過しても前記応答メッセージ受信部が前記応答メッセージを受信できないとき、前記範囲情報の示す距離を、送信された前記初期リクエストでの前記範囲情報よりも大きい距離として再度前記初期リクエストを生成し、前記初期リクエスト送信部は、前記再度生成された前記初期リクエストを送信することが好ましい。

本開示の技術における配車システムの他の態様によれば、センター端末装置は、範囲情報をより大きい距離に設定し直して初期リクエストを再送信するため、範囲情報に合致する車両が存在しないために、配車が行うことができない状況が継続することを抑えることができる。

本開示の技術における配車システムの他の態様では、前記初期リクエスト生成部は、前記車両の進行方向と、前記目的地と前記車両の位置とを結ぶ直線とがなす角度を前記範囲情報に対応付けて記述し、前記角度が大きいほど、前記範囲情報として小さい距離が対応付けられることが好ましい。

本開示の技術における配車システムの他の態様によれば、車両の進行方向が目的地側を向いていないときほど、範囲情報として小さい距離が対応付けられる。そのため、車両端末装置が単に目的地からの距離によって自動で着呼するか否かを判断する構成と比べて、車両端末装置は、より目的地に辿り着きやすい場合に自動で着呼する。それゆえに、目的地に対する配車の効率がより高められる。

（ａ）（ｂ）本開示の技術の第１実施形態における配車システムの全体構成を示す図である。 ＳＩＰサーバの構成を示すブロック図である。 メディアサーバの構成を示すブロック図である。 センター端末装置の構成を示すブロック図である。 ＳＩＰ制御メッセージのデータ構成を示す図である。 タクシー端末装置の構成を示すブロック図である。 配車システムの動作を示すシーケンスチャートである。 タクシー端末装置での自動着呼の処理の手順を示すフローチャートである。 本開示の技術の第２実施形態におけるＳＩＰ制御メッセージのデータ構成を示す図である。 タクシー端末装置の構成を示すブロック図である。 タクシー端末装置での自動着呼処理の手順を示すフローチャートである。 本開示の技術の第３実施形態におけるＳＩＰ制御メッセージのデータ構成を示す図である。 タクシー端末装置での自動着呼処理の手順を示すフローチャートである。 センター端末装置でのセッション開始の処理の手順を示すフローチャートである。 本開示の技術の第４実施形態におけるＳＩＰ制御メッセージのデータ構成図である。 進行方向情報を説明するための図である。 タクシー端末装置での自動着呼処理の手順を示すフローチャートである。

［第１実施形態］
図１から図８を参照して、配車システムの第１施形態を説明する。以下では、配車システムの全体構成、各要素の構成、配車システムの動作の順に説明する。なお、本実施形態における配車システムは、通信制御プロトコルの１つであるＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｌ）を用いて具体化した形態であって、配車システムの一例である。

［配車システムの全体構成］
図１（ａ）および図１（ｂ）に示されるように、配車システムは、ＳＩＰサーバ１０、メディアサーバ２０、ＳＩＰ端末であるセンター端末装置３０、および、ＳＩＰ端末である複数のタクシー端末装置４０を備え、ＳＩＰサーバ１０、メディアサーバ２０、および、センター端末装置３０の各々は、ＩＰネットワーク５０に接続されている。本実施形態では、タクシー端末装置４０が車両端末装置を構成している。

ＳＩＰサーバ１０は、呼制御プロトコルの一例であるＳＩＰプロトコルに則りＳＩＰ端末間でのセッションの開始と終了とを制御する。メディアサーバ２０は、音声や映像の転送に用いられるプロトコルの一例であるＲＴＰ／ＲＴＣＰプロトコルに則りＳＩＰ端末間での音声パケットの送信および受信を可能にする。センター端末装置３０は、例えばタクシーの配車センターに設置され、各タクシー端末装置４０との音声通話を行う。各タクシー端末装置４０は、１台のタクシーに１つずつ搭載され、センター端末装置３０との間で音声通話を行う。

図１（ａ）に示されるように、ＳＩＰプロトコルによってセッションの開始と終了とが制御される場合には、センター端末装置３０が、ＳＩＰサーバ１０を経由して各タクシー端末装置４０と接続される。一方、図１（ｂ）に示されるように、ＲＴＰ／ＲＴＣＰプロトコルによる音声通話が行われている場合には、図中の破線で示されるように、センター端末装置３０のルータ機能によって、センター端末装置３０と、各タクシー端末装置４０とが接続される。もしくは、図中の実線で示されるように、センター端末装置３０が、メディアサーバ２０のルータ機能を用いて各タクシー端末装置４０と接続される。なお、センター端末装置３０がメディアサーバ２０を経由して接続される場合には、センター端末装置３０と各タクシー端末装置４０との間での音声通話だけでなく、センター端末装置３０と複数のタクシー端末装置４０との間での会議通話も可能である。

［ＳＩＰサーバの構成］
図２を参照してＳＩＰサーバ１０の構成を説明する。
図２に示されるように、ＳＩＰサーバ１０は、呼制御部１１、プロトコル制御部１２、および、メディアサーバ制御部１３を備えている。呼制御部１１は、プロトコル制御部１２およびメディアサーバ制御部１３の動作を制御する。呼制御部１１は、プロトコル制御部１２から入力されたＳＩＰ制御メッセージに基づき、音声通話に関するリソースの確保や解放等に関する制御信号を生成し、メディアサーバ制御部１３に出力する。

プロトコル制御部１２は、ＳＩＰアドレスやＩＰアドレスを管理するレジストラ機能、受信した接続要求を他のＳＩＰサーバ等に転送するプロキシサーバ機能、および、接続要求の内容が適当でない場合に、接続要求の送信元に内容の変更を促すダイレクトサーバ機能を有する。プロトコル制御部１２は、ＳＩＰプロトコルに基づいてＳＩＰサーバ１０に接続される端末間での音声通話の開始と終了とを制御する。プロトコル制御部１２は、各ＳＩＰ端末からのＳＩＰ制御メッセージを受信し、受信したＳＩＰ制御メッセージを呼制御部１１に出力する。

メディアサーバ制御部１３は、セッションが開始された後の音声通話にて、メディアサーバ２０が用いられる場合に必要とされ、呼制御部１１からの制御信号に基づいて、メディアサーバ２０に対する制御信号を生成して出力する。

［メディアサーバの構成］
図３を参照してメディアサーバ２０の構成を説明する。
図３に示されるように、メディアサーバ２０は、制御部２１、音声パケット生成部２２、音声パケット送受信部２３、および、会議通話機能部２４を備えている。制御部２１は、ＳＩＰサーバ１０から入力された制御信号に基づき、音声通話に関するリソースの確保や解放等を行う。音声パケット生成部２２は、各ＳＩＰ端末から送信された音声パケットの宛先をメディアサーバ２０から送信先のＳＩＰ端末に変更することによって音声パケットを生成する。音声パケット送受信部２３は、各ＳＩＰ端末から送信された音声パケットの受信と、各ＳＩＰ端末に対する音声パケットの送信とを行う。

会議通話機能部２４は、複数のＳＩＰ端末間で会議通話が行われる場合に、各ＳＩＰ端末から音声パケット送受信部２３を経由して受信した圧縮音声をミキシングする。会議通話機能部２４は、音声パケット送受信部２３を経由してエンコードした圧縮音声を各ＳＩＰ端末に送信する。

［センター端末装置の構成］
図４および図５を参照してセンター端末装置３０の構成を説明する。
図４に示されるように、センター端末装置３０は、制御メッセージ生成部３１、制御メッセージ送受信部３２、音声パケット生成部３３、および、音声パケット送受信部３４を備え、配車プログラムに従って各部での処理を実行する。本実施形態では、制御メッセージ生成部３１が初期リクエスト生成部を構成し、制御メッセージ送受信部３２がＳＩＰ（要求／応答）メッセージ送信部とＳＩＰ（要求／応答）メッセージ受信部とを構成している。制御メッセージ生成部３１は、ＳＩＰプロトコルに則って各種ＳＩＰ制御メッセージを生成し、ＳＩＰ制御メッセージ、特に、セッションの確立を要求することを意味する初期リクエストであるＩＮＶＩＴＥのヘッダ部に、フック制御コマンドを付加する。制御メッセージ送受信部３２は、ＳＩＰプロトコルに基づいてＳＩＰ制御メッセージをＳＩＰサーバ１０に向けて送信し、ＳＩＰサーバ１０からのＳＩＰ制御メッセージを受信する。なお、本実施形態では、制御メッセージ送受信部３２が、初期リクエスト送信部および応答メッセージ受信部を構成している。

音声パケット生成部３３は、ＲＴＰ／ＲＴＣＰプロトコルに則った形式で、音声情報のパケットを生成する。音声パケット送受信部３４は、ＲＴＰ／ＲＴＣＰプロトコルに則り生成された音声パケットを各タクシー端末装置４０に向けて、あるいは、メディアサーバ２０に向けて送信する。

図５を参照して、制御メッセージ生成部３１にて生成されるＳＩＰ制御メッセージを説明する。ＳＩＰ制御メッセージは、ＲＦＣ３２６１の規定において、基本的には、ＲＥＧＩＳＴＥＲ、ＩＮＶＩＴＥ、ＡＣＫ、ＢＹＥ、ＣＡＮＣＥＬ、および、ＯＰＴＩＯＮＳの６種類のメソッドで構成されている。ＲＥＧＩＳＴＥＲは、各ＳＩＰ端末を登録するときにＳＩＰサーバ１０に送信されるメッセージであり、ＩＮＶＩＴＥは、セッションの開始を要求するときにＳＩＰサーバ１０に送信されるメッセージである。ＡＣＫは、セッションの開始が成立したとき等にＳＩＰサーバ１０に送信されるメッセージであり、ＢＹＥは、セッションを終了するときにＳＩＰサーバ１０に送信されるメッセージである。ＣＡＮＣＥＬは、既に送信したメッセージを取り消すときにＳＩＰサーバ１０に送信されるメッセージであり、ＯＰＴＩＯＮＳは、ＳＩＰサーバ１０の機能や、各ＳＩＰ端末の機能を問い合わせるときにＳＩＰサーバ１０に送信されるメッセージである。
ＳＩＰ制御メッセージは、ヘッダ部とデータ部とから構成され、ヘッダ部には、メッセージの種類を示すメソッド名、送信者、および、受信者等が記述されている。

図５に示されるように、ＳＩＰ制御メッセージのメソッドがＩＮＶＩＴＥである場合には、ＩＮＶＩＴＥメッセージ１００のヘッダ部１０１に、フック制御コマンド１０１ａが付加されている。ヘッダ部１０１にフック制御コマンド１０１ａが付加されている場合には、ＳＩＰサーバ１０を経由してＳＩＰ制御メッセージを受信したタクシー端末装置４０が、セッションを自動着呼する。なお、以下では、各タクシー端末装置４０にて着信音が鳴った後に、タクシーの乗務員が応答操作を行うことによってセッションが成立することが、通常着呼として設定される。また、各タクシー端末装置４０にて着信音が鳴ること、および、乗務員が応答操作を行うことなしにセッションが成立することが、自動着呼として設定される。

データ部１０２には、セッションで使用されるメディアの型、コーデック、ＲＴＰ／ＲＴＣＰプロトコルによる音声通話に用いられるＩＰアドレス、および、ポート番号等が記述され、音声通話が行われる場合には、メディアの型としてａｕｄｉｏが記述されている。

［タクシー端末装置の構成］
図６を参照してタクシー端末装置４０の構成を説明する。
図６に示されるように、タクシー端末装置４０は、制御メッセージ生成部４１、制御メッセージ送受信部４２、音声パケット生成部４３、音声パケット送受信部４４、および、コマンド実行部４５を備えている。本実施形態では、制御メッセージ生成部４１が応答メッセージ生成部を構成し、制御メッセージ送受信部４２がＳＩＰ（要求／応答）メッセージ送信部とＳＩＰ（要求／応答）メッセージ受信部とを構成している。制御メッセージ生成部４１、制御メッセージ送受信部４２、音声パケット生成部４３、および、音声パケット送受信部４４の各々は、上述したセンター端末装置３０における同じ名称の機能部と同等の機能を有している。コマンド実行部４５は、ＳＩＰサーバ１０から送信されたＳＩＰ制御メッセージに含まれるフック制御コマンド１０１ａを解釈し、フック制御コマンド１０１ａに基づいて音声通話を自動着呼と通常着呼とのいずれかに設定する。なお、タクシー端末装置４０の制御メッセージ生成部４１もセンター端末装置３０の制御メッセージ生成部３１と同等のＳＩＰ制御メッセージを生成することが可能ではある。しかしながら、タクシー端末装置４０の生成するＩＮＶＩＴＥメッセージのヘッダ部には、フック制御コマンドが記述されない。また、本実施形態では、制御メッセージ送受信部４２が初期リクエスト受信部および応答メッセージ送信部を構成している。

［配車システムの動作］
図７を参照して配車システムの動作を説明する。なお、以下では、タクシー端末装置４０が、センター端末装置３０からの発呼に対して通常着呼を行う場合を説明する。また、センター端末装置３０が、メディアサーバ２０を経由して各タクシー端末装置４０と音声通話を行う場合を説明した後に、センター端末装置３０が、各タクシー端末装置４０と直に音声通話を行う場合を説明する。

［メディアサーバを経由した音声通話］
図７に示されるように、例えば、センター端末装置３０とタクシー端末装置４０との間での音声通話が行われる場合には、センター端末装置３０が、ＩＮＶＩＴＥメッセージを生成してＳＩＰサーバ１０のプロトコル制御部１２に送信する（ステップＳ１）。すなわち、センター端末装置３０が、ＳＩＰサーバ１０を経由してタクシー端末装置４０に対して発呼する。ステップＳ１にて送信されるＩＮＶＩＴＥメッセージには、センター端末装置３０のＩＰアドレスと、音声通話に用いられるポート番号とが記述されている。プロトコル制御部１２は、ＩＮＶＩＴＥメッセージを生成してタクシー端末装置４０に送信する（ステップＳ２）。ステップＳ２にて送信されるＩＮＶＩＴＥメッセージには、タクシー端末装置４０の接続先となるメディアサーバ２０のＩＰアドレスと、呼制御部１１から入力された制御信号に基づいてメディアサーバ２０が確保したポート番号とが記述されている。

そして、プロトコル制御部１２は、ステップＳ１でのＩＮＶＩＴＥメッセージに対する処理が試行中であることを意味する１００Ｔｒｙｉｎｇレスポンスメッセージを生成し、センター端末装置３０に送信する（ステップＳ３）。また、タクシー端末装置４０は、ステップＳ２でのＩＮＶＩＴＥメッセージに対する１００Ｔｒｙｉｎｇレスポンスメッセージを生成してプロトコル制御部１２に送信する（ステップＳ４）。その後、タクシー端末装置４０は、呼び出し中であることを意味する１８０Ｒｉｎｇｉｎｇレスポンスメッセージを生成してプロトコル制御部１２に送信し（ステップＳ５）、タクシー端末装置４０は着信音を鳴らす。プロトコル制御部１２は、タクシー端末装置４０からの１８０Ｒｉｎｇｉｎｇレスポンスメッセージを受信すると、１８０Ｒｉｎｇｉｎｇレスポンスメッセージを生成してセンター端末装置３０に送信する（ステップＳ６）。このとき、センター端末装置３０は、ＲＴＰ／ＰＴＣＰプロトコルを用いてセンター端末装置３０に対して送信されたリングバックトーンを再生する。

次いで、タクシーの乗務員が応答操作を行うと、タクシー端末装置４０が、ステップＳ２でのＩＮＶＩＴＥメッセージによる要求が成功したことを意味する２００ＯＫレスポンスメッセージを生成し、プロトコル制御部１２に送信する（ステップＳ７）。ステップＳ７にて送信される２００ＯＫレスポンスメッセージには、タクシー端末装置４０のＩＰアドレスとポート番号とが記述されている。プロトコル制御部１２は、２００ＯＫレスポンスメッセージを受信すると、２００ＯＫメッセージを生成してセンター端末装置３０に送信する（ステップＳ８）。ステップＳ８にて送信される２００ＯＫレスポンスメッセージには、メディアサーバ２０のＩＰアドレスとポート番号とが記述されている。これにより、センター端末装置３０とタクシー端末装置４０との間でのセッションが、メディアサーバ２０を経由して開始されるため、センター端末装置３０とタクシー端末装置４０との間での音声通話が可能になる。そして、センター端末装置３０とタクシー端末装置４０とが、ＲＴＰ／ＲＴＣＰプロトコルによる音声通話を行う（ステップＳ２０）。

センター端末装置３０は、２００ＯＫレスポンスメッセージを受信すると、ＡＣＫメッセージを生成してプロトコル制御部１２に送信し（ステップＳ９）、プロトコル制御部１２が、ＡＣＫメッセージを生成してタクシー端末装置４０に送信する（ステップＳ１０）。

そして、配車センターの従業員が音声通話を終了するときには、センター端末装置３０が、ＢＹＥメッセージを生成してプロトコル制御部１２に送信し（ステップＳ１１）、プロトコル制御部１２が、ＢＹＥメッセージを生成してタクシー端末装置４０に送信する（ステップＳ１２）。これにより、センター端末装置３０とタクシー端末装置４０との間でのセッションが終了され、センター端末装置３０とタクシー端末装置４０との間での音声通話が終了される。

タクシー端末装置４０は、ＢＹＥメッセージを受信すると、２００ＯＫレスポンスメッセージを生成してプロトコル制御部１２に送信し（ステップＳ１３）、プロトコル制御部１２が、２００ＯＫレスポンスメッセージを生成してセンター端末装置３０に送信する（ステップＳ１４）。

［メディアサーバを経由しない音声通話］
図７に示されるように、センター端末装置３０が、ＩＮＶＩＴＥメッセージを生成してＳＩＰサーバ１０のプロトコル制御部１２に送信する（ステップＳ１）。ステップＳ１にて送信されるＩＮＶＩＴＥメッセージには、センター端末装置３０のＩＰアドレスと、音声通話に用いられるポート番号とが記述されている。プロトコル制御部１２は、ＩＮＶＩＴＥメッセージを生成してタクシー端末装置４０に送信する（ステップＳ２）。ステップＳ２にて送信されるＩＮＶＩＴＥメッセージには、センター端末装置３０のＩＰアドレスとポート番号とが記述されている。

そして、ステップＳ３からステップＳ６までは、メディアサーバ２０を経由した場合と同様の処理が行われる。次いで、タクシー端末装置４０が、２００ＯＫレスポンスメッセージを生成してプロトコル制御部１２に送信する（ステップＳ７）。ステップＳ７にて送信される２００ＯＫレスポンスメッセージには、タクシー端末装置４０のＩＰアドレスとポート番号とが記述されている。プロトコル制御部１２は、２００ＯＫレスポンスメッセージを生成してセンター端末装置３０に送信する（ステップＳ８）。ステップＳ８にて送信される２００ＯＫレスポンスメッセージにも、タクシー端末装置４０のＩＰアドレスとポート番号とが記述されている。これにより、センター端末装置３０とタクシー端末装置４０との間でのセッションが開始されるため、センター端末装置３０とタクシー端末装置４０との間での音声通話が可能になる。
その後、音声通話（ステップＳ２０）を含むステップＳ９からステップＳ１４までは、メディアサーバ２０を経由した場合と同様の処理が行われる。

［タクシー端末装置での自動着呼処理］
図８を参照してタクシー端末装置４０での自動着呼処理を説明する。なお、自動着呼処理によるセッションの確立は、センター端末装置３０と１つのタクシー端末装置４０との間で行われる場合と、センター端末装置３０と複数のタクシー端末装置４０との間で同時に行われる場合とがある。セッションの確立が、センター端末装置３０と複数のタクシー端末装置４０との間で同時に行われる場合には、自動着呼処理は、各タクシー端末装置４０にて行われる。

図８に示されるように、セッションが開始されるときには、タクシー端末装置４０の制御メッセージ送受信部４２が、センター端末装置３０から送信されたＩＮＶＩＴＥメッセージ１００をＳＩＰサーバ１０のプロトコル制御部１２を経由して受信する（ステップＳ３１）。なお、ステップＳ３１での処理は、図７におけるステップＳ２での処理に相当する。

制御メッセージ送受信部４２は、ＩＮＶＩＴＥメッセージ１００をコマンド実行部４５に出力し、コマンド実行部４５が、ＩＮＶＩＴＥメッセージ１００を解釈する（ステップＳ３２）。

コマンド実行部４５が、ＩＮＶＩＴＥメッセージ１００のヘッダ部１０１にフック制御コマンド１０１ａが記述されていると判断した場合には（ステップＳ３２：ＹＥＳ）、コマンド実行部４５は、フック制御コマンドに基づいてタクシー端末装置４０に自動着呼を行わせる（ステップＳ３３）。すなわち、制御メッセージ生成部４１は、図７におけるステップＳ５での１８０Ｒｉｎｇｉｎｇレスポンスメッセージを生成せず、ステップＳ７での２００ＯＫレスポンスメッセージを生成する。これにより、タクシー端末装置４０では、着信音が鳴ること、および、乗務員による応答操作が行われることなく、センター端末装置３０とタクシー端末装置４０との間でのセッションが開始される。

そのため、車両の乗務員が着信に応答する操作を行わずとも、センター端末装置３０とタクシー端末装置４０との間での音声通話が可能になる。それゆえに、タクシー端末装置４０では、車両の走行中であってもセンター端末装置３０からの連絡を受けることができるため、乗務員の応答操作を必須とする構成と比べて、配車の効率を高めることができる。

一方、コマンド実行部４５が、ＩＮＶＩＴＥメッセージのヘッダ部にフック制御コマンドが記述されていないと判断した場合には（ステップＳ３２：ＮＯ）、コマンド実行部４５は、センター端末装置３０からのセッション確立の要求を受け付けて、タクシー端末装置４０に着信音を鳴らさせる（ステップＳ３４）。そして、タクシー端末装置４０では、図７を用いて説明した通常着呼が行われる（ステップＳ３５）。すなわち、制御メッセージ生成部４１が、図７におけるステップＳ５での１８０Ｒｉｎｇｉｎｇレスポンスメッセージを生成し、かつ、タクシー端末装置４０が着信音を鳴らす。タクシーの乗務員が応答操作を行った場合には、図７におけるステップＳ６からステップ１０までの処理が行われる。

なお、タクシーの乗務員が応答操作を行わなかった場合には、図７におけるステップＳ７以降の処理が行われない。例えば、ＳＩＰサーバ１０が、応答しなかったタクシー端末装置４０に対しては、ＣＡＮＣＥＬメッセージを生成して制御メッセージ送受信部４２に送信する。
以上説明したように、配車システムの第１実施形態によれば、以下の効果を得ることができる。

（１）コマンド実行部４５が、センター端末装置３０からのＩＮＶＩＴＥメッセージ１００に含まれるフック制御コマンド１０１ａを解釈することによって、センター端末装置３０からの発呼を自動で着呼させる。そのため、車両の乗務員が着信に応答する操作を行わずとも、センター端末装置３０とタクシー端末装置４０との間での通話が可能になる。それゆえに、タクシー端末装置４０では、車両の走行中であってもセンター端末装置３０からの連絡を受けることができるため、乗務員の応答操作を必須とする構成と比べて、配車の効率を高めることができる。

［第２実施形態］
図９から図１１を参照して、配車システムの第２実施形態を説明する。なお、第２実施形態は、第１実施形態と比べて、センター端末装置３０が送信するＩＮＶＩＴＥメッセージの構造、タクシー端末装置４０の構成、および、タクシー端末装置４０での自動着呼処理が異なる。そのため、以下では、こうした相違点を説明し、その他の説明を省略する。

［ＩＮＶＩＴＥメッセージの構造］
図９を参照してＩＮＶＩＴＥメッセージの構造を説明する。
図９に示されるように、ＩＮＶＩＴＥメッセージ１１０は、第１実施形態のＩＮＶＩＴＥメッセージ１００と同様、ヘッダ部１１１とデータ部１１２とを備えている。ヘッダ部１１１には、フック制御コマンド１１１ａに加えて、顧客の乗車位置に関する情報である乗車位置情報１１１ｂが付加されている。乗車位置情報１１１ｂには、例えば、乗車位置の緯度情報と経度情報とが含まれている。

［タクシー端末装置の構成］
図１０を参照してタクシー端末装置４０の構成を説明する。
図１０に示されるように、タクシー端末装置４０は、第１実施形態のタクシー端末装置４０と同様、制御メッセージ生成部４１、制御メッセージ送受信部４２、音声パケット生成部４３、音声パケット送受信部４４、および、コマンド実行部４５を備えている。タクシー端末装置４０は、第１実施形態のタクシー端末装置４０とは異なり、位置情報取得部４６、および、自動着呼判断部４７を備えている。

位置情報取得部４６は、タクシーの現在位置を検出する位置検出装置、例えば、ＧＰＳ受信装置等に接続され、位置検出装置から入力される自車両の現在位置情報を取得する。自動着呼判断部４７は、ＩＮＶＩＴＥメッセージ１１０のヘッダ部１１１に含まれる乗車位置情報と、自車両の現在位置とを用いて、所定の判断条件、例えば、乗車位置と自車両の現在位置とから算出される直線距離に基づいて、通常着呼もしくは自動着呼のいずれかを判断する。

［タクシー端末装置での自動着呼処理］
図１１を参照してタクシー端末装置４０での自動着呼処理を説明する。
図１１に示されるように、セッションが開始されるときには、タクシー端末装置４０の制御メッセージ送受信部４２が、センター端末装置３０から送信されたＩＮＶＩＴＥメッセージ１１０をＳＩＰサーバ１０のプロトコル制御部１２を経由して受信する（ステップＳ４１）。なお、ステップＳ４１での処理は、図７におけるステップＳ２での処理に相当する。

制御メッセージ送受信部４２は、ＩＮＶＩＴＥメッセージ１００をコマンド実行部４５に出力し、コマンド実行部４５がＩＮＶＩＴＥメッセージ１１０を解釈する（ステップＳ４２、ステップＳ４３）。

コマンド実行部４５が、ＩＮＶＩＴＥメッセージ１１０のヘッダ部１１１にフック制御コマンド１１１ａが記述され、かつ、乗車位置情報１１１ｂが記述されていると判断した場合には（ステップＳ４２：ＹＥＳ、ステップＳ４３：ＹＥＳ）、位置情報取得部４６が、自車両の現在位置を取得する（ステップＳ４４）。そして、自動着呼判断部４７が、乗車位置情報１１１ｂと、位置情報取得部４６の取得した自車両の現在位置を用いて２つの位置間の直線距離を算出する。自動着呼判断部４７は、直線距離が指定された所定の距離以内であるか否かを判断する（ステップＳ４５）。なお、直線距離と比べられる所定の距離は、予めタクシー端末装置４０に記憶された不変の距離であってもよいし、乗務員による変更が可能な距離であってもよい。

自動着呼判断部４７が、算出した直線距離が指定された距離以内であると判断した場合には（ステップＳ４５：ＹＥＳ）、タクシー端末装置４０では、自動着呼が行われる（ステップＳ４６）。すなわち、第１実施形態と同様、制御メッセージ生成部４１が図７におけるステップＳ７での２００ＯＫレスポンスメッセージを生成することで、センター端末装置３０とタクシー端末装置４０との間でのセッションが開始される。

一方、自動着呼判断部４７が、算出した直線距離が指定された距離よりも大きいと判断した場合には（ステップＳ４５：ＮＯ）、コマンド実行部４５は、センター端末装置３０からのセッション確立の要求を受け付けて、タクシー端末装置４０に着信音を鳴らさせ（ステップＳ４７）、タクシー端末装置４０に通常着呼を行わせる（ステップＳ４８）。

配車センターが複数の車両に対して予約に関する情報を一斉に知らせた場合には、各車両には、目的地との距離に関わりなく利用客の情報が連絡されるため、目的地に近い車両が配車センターからの連絡に対して応答するとは限らない。つまり、目的地に近い車両が、必ずしも配車される車両として選択されない。それゆえに、車両を目的地に対して効率よく配車する上では、複数の車両のうち、目的地からの距離が近い車両にのみ予約に関する情報が知らされることが好ましい。

しかしながら、配車センターが目的地からの距離が近い車両のみに情報を知らせるためには、配車センターが、各車両の位置情報を常に把握していること、および、目的地と各車両の位置との距離を把握することが必要とされる。そのため、配車センターには、これらを実現するための設備が必要になってしまう。

上述のように、本実施形態では、タクシー端末装置４０が、自車両の位置情報と目的地の位置情報とから、センター端末装置３０からの発呼を自動で着呼するか否かを判断する。そのため、センター端末装置３０が各車両の現在位置を把握せずとも、目的地から所定の距離以内の車両のみに配車に関する情報を伝えやすくなる。それゆえに、目的地と車両との距離に関わらず、全ての車両に対して情報を伝える構成と比べて、配車センターが高度な設備を備えることなく、目的地に対する配車の効率を高めることができる。

なお、第１実施形態と同様のＩＮＶＩＴＥメッセージ１１０、すなわち、ヘッダ部１１１にフック制御コマンド１１１ａのみが付加されたメッセージが、タクシー端末装置４０に送信される場合もある。この場合には、コマンド実行部４５は、ヘッダ部１１１にフック制御コマンド１１１ａが記述されている一方、乗車位置情報が記述されていないと判断する（ステップＳ４２：ＹＥＳ、ステップＳ４３：ＮＯ）。そして、コマンド実行部４５が、タクシー端末装置４０に自動着呼を行わせる（ステップＳ４６）。そのため、タクシー端末装置４０では、顧客の乗車位置と自車両の現在位置の距離に関わらず、センター端末装置３０からの発呼が自動で着呼することによって、センター端末装置３０とタクシー端末装置４０との間でのセッションが開始される。
以上説明したように、配車システムの第２実施形態によれば、上記（１）の効果に加えて、以下の効果を得ることができる。

（２）タクシー端末装置４０が、自車両の位置情報と目的地の位置情報とから、センター端末装置３０からの発呼を自動で着呼するか否かを判断する。そのため、センター端末装置３０が各車両の現在位置を把握せずとも、目的地から所定の距離以内の車両のみに配車に関する情報を伝えやすくなる。それゆえに、目的地と車両との距離に関わらず、全ての車両に対して情報を伝える構成と比べて、配車センターが高度な設備を備えることなく、目的地に対する配車の効率を高めることができる。

［第３実施形態］
図１２から図１４を参照して、配車システムの第３実施形態を説明する。なお、第３実施形態は、第２実施形態と比べて、センター端末装置３０の備える制御メッセージ生成部３１の機能、センター端末装置３０が送信するＩＮＶＩＴＥメッセージの構造、タクシー端末装置４０での自動着呼処理、および、センター端末装置３０でのＩＮＶＩＴＥメッセージの生成処理が異なる。そのため、以下では、こうした相違点を説明し、その他の説明を省略する。

［ＩＮＶＩＴＥメッセージの構造］
図１２を参照してＩＮＶＩＴＥメッセージの構造を説明する。
図１２に示されるように、ＩＮＶＩＴＥメッセージ１２０は、第２実施形態のＩＮＶＩＴＥメッセージ１１０と同様、ヘッダ部１２１とデータ部１２２とを備えている。ヘッダ部１２１には、フック制御コマンド１２１ａおよび乗車位置情報１２１ｂに加えて、範囲情報１２１ｃが付加されている。範囲情報１２１ｃは、例えば、タクシー端末装置４０に自動着呼を行わせる範囲であり、この範囲は、自車両の現在位置と乗車位置とから算出される直線距離の値によって指定されている。

［制御メッセージ生成部の機能］
センター端末装置３０の制御メッセージ生成部３１は、第２実施形態の制御メッセージ生成部３１と同様、ＳＩＰ制御メッセージを生成する。ＳＩＰ制御メッセージがＩＮＶＩＴＥメッセージである場合には、制御メッセージ生成部３１は、ＩＮＶＩＴＥメッセージ１２０のヘッダ部に対して上述した３つの情報を付加する。加えて、制御メッセージ生成部３１は、タクシー端末装置４０に対してＩＮＶＩＴＥメッセージを送信してから所定の時間内にタクシー端末装置４０とのセッションが開始されない場合には、前回よりも大きい値を範囲情報１２１ｃとして記述したＩＮＶＩＴＥメッセージを生成する。制御メッセージ生成部３１は、直線距離の値が更新されたＩＮＶＩＴＥメッセージをタクシー端末装置４０に向けて送信する。

［タクシー端末装置での自動着呼処理］
図１３を参照してタクシー端末装置４０での自動着呼処理を説明する。
図１３に示されるように、第２実施形態と同様、タクシー端末装置４０がＩＮＶＩＴＥメッセージ１２０を受信し（ステップＳ５１）、コマンド実行部４５が、フック制御コマンド１２１ａおよび乗車位置情報１２１ｂがヘッダ部１２１に記述されているか否かを判断する（ステップＳ５２、ステップＳ５３）。コマンド実行部４５が、フック制御コマンド１２１ａおよび乗車位置情報１２１ｂがヘッダ部１２１に記述されていると判断すると（ステップＳ５２：ＹＥＳ、ステップＳ５３：ＹＥＳ）、位置情報取得部４６が、自車両の現在位置を取得する（ステップＳ５４）。

そして、自動着呼判断部４７が、乗車位置情報１２１ｂ、および、位置情報取得部４６の取得した自車両の現在位置を用いて、乗車位置と自車両の現在位置との直線距離を算出する。自動着呼判断部４７は、直線距離が、センター端末装置３０の指定した距離以内、すなわち、範囲情報１２１ｃで指定された直線距離以内であるか否かを判断する（ステップＳ５５）。

自動着呼判断部４７が、算出した直線距離が範囲情報１２１ｃによって指定された距離以内であると判断した場合には（ステップＳ５５：ＹＥＳ）、コマンド実行部４５がタクシー端末装置４０に自動着呼を行わせる（ステップＳ５６）。一方、自動着呼判断部４７が、算出した直線距離が範囲情報１２１ｃによって指定された距離よりも大きいと判断した場合には（ステップＳ５５：ＮＯ）、コマンド実行部４５は、第２実施形態と同様、タクシー端末装置４０に着信音を鳴らさせ（ステップＳ５７）、通常着呼を行わせる（ステップＳ５８）。

［センター端末装置でのＩＮＶＩＴＥメッセージ生成処理］
図１４を参照してセンター端末装置３０でのＩＮＶＩＴＥメッセージ１２０の生成処理を説明する。
図１４に示されるように、センター端末装置３０が、タクシー端末装置４０に対してセッションの確立を要求する場合には、センター端末装置３０の制御メッセージ生成部３１は、ＩＮＶＩＴＥメッセージを生成する。制御メッセージ生成部３１は、範囲情報１２１ｃとしての直線距離の初期値を読み込む（ステップＳ６１）。初期値は、予め設定された所定の距離であって、センター端末装置３０の記憶部に保存されている。制御メッセージ生成部３１は、読み込んだ初期値を範囲情報１２１ｃとして設定し（ステップＳ６２）、制御メッセージ送受信部３２がＩＮＶＩＴＥメッセージ１２０をタクシー端末装置４０に向けて送信する（ステップＳ６３）。

センター端末装置３０は、ＩＮＶＩＴＥメッセージの送信から経過した時間を測定し、タクシー端末装置４０からの応答を所定時間内に確認できた場合には（ステップＳ６４：ＹＥＳ）、すなわち、図７におけるステップＳ８の２００ＯＫレスポンスメッセージを受信した場合には、センター端末装置３０とタクシー端末装置４０との間でのセッションが開始される。なお、本実施形態では、センター端末装置３０が時間測定部を構成している。

一方、センター端末装置３０が、タクシー端末装置４０からの応答を所定時間内に確認できない場合には（ステップＳ６４：ＮＯ）、制御メッセージ生成部３１が、前回の直線距離の値に対して所定の距離Ａを加算する（ステップＳ６５）。制御メッセージ生成部３１は、ステップＳ６５にて算出された直線距離の値を今回の範囲情報１２１ｃとして設定する（ステップＳ６２）。その後、センター端末装置３０は、送信されたＩＮＶＩＴＥメッセージ１２０に対して、タクシー端末装置４０から所定時間内に応答があるまで、ステップＳ６２からステップＳ６５までの処理を繰り返し行う。

そのため、センター端末装置３０は、各車両の現在位置を把握せずとも、目的地からの距離がセンター端末装置３０の設定した距離以内である車両のみに自動着呼させることができる。
また、センター端末装置３０は、タクシー端末装置４０からの応答がない場合には、範囲情報をより大きい距離に設定し直してＩＮＶＩＴＥメッセージ１２０を再送信するため、範囲情報に合致する車両が存在しないために、配車が行うことができない状況が継続することを抑えることができる。
以上説明したように、配車システムの第３実施形態によれば、上記（１）および（２）の効果に加えて、以下の効果を得ることができる。

（３）センター端末装置３０は、各車両の現在位置を把握せずとも、目的地からの距離がセンター端末装置３０の設定した距離以内である車両のみに自動着呼させることができる。

（４）センター端末装置３０は、前回のＩＮＶＩＴＥメッセージ１２０よりも範囲情報をより大きい距離に設定し直してＩＮＶＩＴＥメッセージ１２０を再送信するため、範囲情報に合致する車両が存在しないために、配車が行うことができない状況が継続することを抑えることができる。

［第４実施形態］
図１５から図１７を参照して、配車システムの第４実施形態を説明する。なお、第４実施形態は、第２実施形態と比べて、センター端末装置３０が送信するＩＮＶＩＴＥメッセージの構造、および、タクシー端末装置４０での自動着呼処理が異なる。そのため、以下では、こうした相違点を詳しく説明し、その他の説明を省略する。

［ＩＮＶＩＴＥメッセージの構造］
図１５を参照してＩＮＶＩＴＥメッセージの構造を説明する。
図１５に示されるように、ＩＮＶＩＴＥメッセージ１３０は、第２実施形態のＩＮＶＩＴＥメッセージ１１０と同様、ヘッダ部１３１とデータ部１３２とを備えている。ヘッダ部１３１には、フック制御コマンド１３１ａおよび乗車位置情報１３１ｂに加えて、進行方向情報１３１ｃが付加されている。進行方向情報１３１ｃには、顧客の乗車位置と自車両の現在位置とを結ぶ直線と、自車両の進行方向とのなす角度が、角度θとして設定されている。そして、進行方向情報１３１ｃには、角度θが±９０°以内であるときの範囲情報と、角度θの絶対値が９０°よりも大きく１８０°以内であるときの範囲情報とが、角度θの範囲に対応付けて各別に記述されている。角度θが±９０°以内であるときの範囲情報には、角度θの絶対値が９０°よりも大きく１８０°以内であるときの範囲情報と比べて、相対的に大きい直線距離が設定されている。

［進行方向情報］
図１６を参照してＩＮＶＩＴＥメッセージに記述される進行方向情報をより詳しく説明する。
図１６に示されるように、タクシー端末装置４０は、自車両に設定されている経路情報、あるいは、自車両の現在位置ＰＰと現在の目的地とから自車両の進行方向を決定し、自車両の現在位置ＰＰと乗車位置ＲＰとを結ぶ直線Ｂとのなす角度を上述した角度θとして算出する。また、センター端末装置３０が送信するＩＮＶＩＴＥメッセージ１３０には、角度θが±９０°以内であるときの範囲情報として大きい円で示される範囲Ｃが記述され、角度θの絶対値が９０°よりも大きく１８０°以内であるときの範囲情報として小さい円で示される範囲Ｄが記述されている。

図１６に示される５台の車両のうち、乗車位置ＲＰに近い２台の車両Ｖ１，Ｖ２は、現在位置ＰＰと乗車位置ＲＰとの直線距離が範囲Ｄに含まれているため、各車両Ｖ１，Ｖ２に搭載されたタクシー端末装置４０は、角度θに関わらずセンター端末装置３０からの発呼に対して自動着呼する。これに対し、乗車位置ＲＰから遠い３台の車両Ｖ３，Ｖ４，Ｖ５は、現在位置ＰＰと乗車位置ＲＰとの直線距離が範囲Ｃに含まれてはいるものの、範囲Ｄには含まれていない。そのため、各車両Ｖ３，Ｖ４，Ｖ５に搭載されたタクシー端末装置４０は、角度θが±９０°以内の範囲に含まれる場合には、センター端末装置３０の発呼に対して自動着呼を行う。一方、各車両Ｖ３，Ｖ４，Ｖ５に搭載されたタクシー端末装置４０は、角度θの絶対値が９０°よりも大きく１８０°以内の範囲に含まれる場合には、センター端末装置３０の発呼に対して通常着呼を行う。

このように、本実施形態では、車両の進行方向が目的地側を向いていないときほど、範囲情報として小さい距離が対応付けられる。そのため、タクシー端末装置４０が単に目的地からの距離によって自動で着呼するか否かを判断する構成と比べて、タクシー端末装置４０は、より目的地に辿り着きやすい場合に自動で着呼する。それゆえに、目的地に対する配車の効率がより高められる。

［タクシー端末装置の自動着呼処理］
図１７を参照してタクシー端末装置４０の自動着呼処理を説明する。
図１７に示されるように、第２実施形態と同様、タクシー端末装置４０がＩＮＶＩＴＥメッセージ１３０を受信し（ステップＳ７１）、コマンド実行部４５が、フック制御コマンド１３１ａおよび乗車位置情報１３１ｂがヘッダ部１３１に記述されているか否かを判断する（ステップＳ７２、ステップＳ７３）。コマンド実行部４５が、フック制御コマンド１３１ａおよび乗車位置情報１３１ｂがヘッダ部１３１に記述されていると判断すると（ステップＳ７２：ＹＥＳ、ステップＳ７３：ＹＥＳ）、位置情報取得部４６が、自車両の現在位置を取得する（ステップＳ７４）。

そして、自動着呼判断部４７が、乗車位置情報１３１ｂ、および、位置情報取得部４６の取得した自車両の現在位置を用いて、自車両の現在位置と乗車位置とを結ぶ直線Ｂと、自車両の進行方向とのなす角度θを算出する。自動着呼判断部４７は、算出した角度θと進行方向情報１３１ｃを参照して、センター端末装置３０によって指定された距離を選択する（ステップＳ７５）。次いで、自動着呼判断部４７は、乗車位置と自車両の現在位置との直線距離を算出し、直線距離が、ステップＳ７５で選択した距離以内であるか否かを判断する（ステップＳ７６）。

自動着呼判断部４７が、算出した直線距離が進行方向情報１３１ｃによって指定された距離以内であると判断した場合には（ステップＳ７６：ＹＥＳ）、コマンド実行部４５がタクシー端末装置４０に自動着呼を行わせる（ステップＳ７７）。一方、自動着呼判断部４７が、算出した直線距離が進行方向情報１３１ｃによって指定された距離よりも大きいと判断した場合には（ステップＳ７６：ＮＯ）、コマンド実行部４５は、第２実施形態と同様、タクシー端末装置４０に着信音を鳴らさせ（ステップＳ７８）、通常着呼を行わせる（ステップＳ７９）。
以上説明したように、配車システムの第４実施形態によれば、上記（１）および（２）の効果に加えて、以下の効果を得ることができる。

（５）車両の進行方向が目的地側を向いていないときほど、範囲情報として小さい距離が対応付けられる。そのため、タクシー端末装置４０が単に目的地からの距離によって自動で着呼するか否かを判断する構成と比べて、タクシー端末装置４０は、より目的地に辿り着きやすい場合に自動で着呼する。それゆえに、目的地に対する配車の効率がより高められる。
なお、上記各実施形態は、以下のように適宜変更して実施することができる。

・第４実施形態では、自車両の進行方向と、自車両の現在位置ＰＰと乗車位置ＲＰとを結ぶ直線Ｂとのなす角度θを２つの範囲に分けられ、角度θの絶対値が相対的に小さい範囲ほど、範囲情報として相対的に大きい距離が対応付けられている。これに限らず、角度θは、３以上の範囲に分けられる構成であってもよく、こうした構成であっても、角度θの絶対値が相対的に小さい範囲ほど、範囲情報として相対的に大きい距離が対応付けられる以上は、上記（５）に準じた効果を得ることができる。

・第３実施形態では、センター端末装置３０が、ＩＮＶＩＴＥメッセージ１２０を送信してから所定時間以内にタクシー端末装置４０の応答を確認できない場合に、センター端末装置３０が、範囲情報として設定される距離を更新して、ＩＮＶＩＴＥメッセージを再度送信する構成とした。これに限らず、センター端末装置３０は、範囲情報に設定される距離を更新することなく、ＩＮＶＩＴＥメッセージを再度送信する構成であってもよい。こうした構成であっても、センター端末装置３０が送信したＩＮＶＩＴＥメッセージに対して応答するタクシー端末装置４０が存在する確率を高めることはできる。

・第２実施形態では、タクシー端末装置４０による自動着呼が行われる範囲を決定するための距離が、タクシー端末装置４０に記憶されている。これに限らず、自動着呼が行われる範囲を決定するための距離は、第３実施形態のように、センター端末装置３０によって指定される構成でもよい。すなわち、センター端末装置３０から送信されるＩＮＶＩＴＥメッセージが、範囲情報を含む構成でもよい。こうした構成であれば、センター端末装置３０が各タクシーの現在地位に関する情報を有していなくとも、センター端末装置３０が指定した距離内のタクシー端末装置４０に自動着呼させることが可能である。

・配車システムは、第３実施形態の構成と、第４実施形態の構成とを組み合わせた構成であってもよい。すなわち、センター端末装置３０から送信されるＩＮＶＩＴＥメッセージには、フック制御コマンド、乗車位置情報、進行方向情報が含まれる。センター端末装置３０は、ＩＮＶＩＴＥメッセージが送信されてから所定時間内にタクシー端末装置４０の応答を確認できないときには、進行方向情報に含まれる範囲情報をより大きい距離に更新してＩＮＶＩＴＥメッセージを送信する。こうした構成であっても、上記（３）から（５）に準じた効果を得ることができる。

・第２実施形態から第４実施形態では、範囲情報として、自車両の現在位置と乗車位置とから算出される直線距離が設定されている。これに限らず、例えば、自車両の現在位置と乗車位置との道のりを算出することのできる装置、例えば、ナビゲーション装置等がタクシーに搭載されている場合には、範囲情報には、自車両の現在位置と乗車位置との道のりが設定されてもよい。そして、タクシー端末装置４０は、ナビゲーション装置に接続され、ナビゲーション装置から道のりを入力される構成であればよい。こうした構成によれば、範囲情報として直線距離が設定される構成と比べて、センター端末装置３０の発呼を自動着呼するタクシー端末装置４０が搭載された複数のタクシー間で、現在位置と乗車位置との間の距離にばらつきが生じることを抑えられる。

・第２実施形態から第４実施形態では、範囲情報として、自車両の現在位置と乗車位置とから算出される直線距離が設定されている。これに限らず、自車両が、乗車位置に辿り着くまでにかかる時間を算出することのできる装置、例えば、ナビゲーション装置等が搭載されたタクシーである場合には、範囲情報には、乗車位置にたどり着くまでにかかる時間が設定されてもよい。なお、この場合には、ナビゲーション装置等が、渋滞情報や交通規制等の道路情報をリアルタイムに受信できる機能、例えば、ＶＩＣＳ（ＶＩＣＳは財団法人道路交通情報通信システムセンターの登録商標）に接続され、ＶＩＣＳの情報をリアルタイムに受信できる機能を有することが好ましい。あるいは、他の方法によって渋滞情報や交通規制等の道路情報をリアルタイムに受信できる機能を有することが好ましい。こうした構成においては、乗車位置にたどり着くまでにかかる時間が、道路情報、例えば、渋滞情報等を加味して算出される構成であれば、配車システムは、乗車位置への配車により適したタクシーを選択することが可能になる。

・各実施形態は、タクシーに顧客が乗車している、すなわち、実車であること、あるいは、タクシーに顧客が乗車していない、すなわち、空車であることを示す実車情報をタクシー端末装置４０が参照し、実車であるときに、自動着呼を禁止する構成であってもよい。すなわち、コマンド実行部４５がフック制御コマンドを実行する条件に、タクシーが空車であることが追加された構成であってもよい。こうした構成では、コマンド実行部４５は、センター端末装置３０から送信されたＩＮＶＩＴＥメッセージにフック制御コマンドが記述されていても、フック制御コマンドを無視する構成であればよい。こうした構成によれば、タクシーの乗務員は、配車センターの従業員との通話を顧客に聞かせずに済む。

・各実施形態は、タクシーが実車である場合に、タクシー端末装置４０が、現在の目的地である降車位置までの距離情報を参照する構成であってもよい。この場合には、タクシー端末装置４０は、降車位置と現在地との距離が所定の距離以上であるときに、自動着呼を禁止し、降車位置と現在値との距離が所定の距離未満になるときに、自動着呼の禁止を解除する構成とすればよい。こうした構成によれば、タクシーの乗務員が、顧客が降車する直前に、次の顧客の乗車位置を把握することも可能になるため、タクシーが実車である間は自動着呼を禁止する構成と比べて、タクシーの配車効率を高めることが可能になる。

・第２実施形態から第４実施形態では、タクシー端末装置４０は、タクシー端末装置４０の搭載されたタクシーに対して営業上等の制約から設定される走行範囲情報、すなわち、顧客を乗車させることが可能な範囲を参照する構成でもよい。こうした構成では、タクシー端末装置４０が、ＩＮＶＩＴＥメッセージに記述された乗車位置が走行範囲に含まれないと判断したときに、自動着呼ではなく通常着呼を行うことが好ましい。こうした構成によれば、タクシーが、顧客を乗車させることができない位置に配車されない。

・第２実施形態から第４実施形態では、ＩＮＶＩＴＥメッセージのヘッダ部には、乗車位置情報に加えて、降車位置情報が記述された構成でもよい。こうした構成では、タクシー端末装置４０は、乗車位置情報と降車位置情報との差である乗車距離を算出し、乗車距離が所定の距離以上であるときに、範囲情報や進行方向情報に関わらず、センター端末装置３０からの発呼を自動着呼する構成でもよい。この構成によれば、タクシー端末装置４０には、所定の距離以上にわたって乗車する顧客の情報が送信されるため、タクシーでは、顧客あたりの運賃が高められやすくなる。

・タクシー端末装置４０の取得する自車両の現在位置は、ＧＰＳ受信装置から送信される情報に限らず、例えば、タクシー端末装置４０と通信中の基地局からその基地局の位置に関してタクシー端末装置４０に対して送信される情報から取得されてもよい。

・配車システムは、メディアサーバ２０を備えていなくともよく、センター端末装置３０と複数のタクシー端末装置４０とが、メディアサーバ２０を経由せずに接続される構成でもよい。こうした構成であっても、センター端末装置３０の生成するＩＮＶＩＴＥメッセージにフック制御コマンドが含まれる構成であれば、上記（１）に準じた効果を得ることができる。

・各実施形態にてセッションの開始と終了に用いられるプロトコルは、ＳＩＰプロトコルに限らず、例えば、Ｈ．３２３、ＭＧＣＰ、および、ＭＥＧＡＣＯ等のプロトコルを用いることも可能である。これらのプロトコルを用いた場合には、ＳＩＰプロトコルにおけるＩＮＶＩＴＥメッセージに相当するメッセージ、すなわち、接続先に対する接続を要求する初期リクエストにフック制御コマンドが記述されればよい。

・各実施形態にて音声通話に用いられるプロトコルは、ＲＴＰ／ＲＴＣＰプロトコルに限らず、音声の転送に用いられる他のプロトコルであってもよい。

・このように、各実施家形態にて説明したプロトコルであるＳＩＰおよびＲＴＰ／ＲＴＣＰは、他のプロトコルであってもよく、要は、デジタル化した音声の無線パケット通信を可能とするものであればよい。つまり、各実施形態におけるＳＩＰプロトコル等を実現するためのアプリケーションであるＳＩＰサーバ１０、メディアサーバ２０、センター端末装置３０、および、タクシー端末装置４０も、上述した構成に限らず、デジタル化した音声の無線パケット通信を可能とするものであればよい。なお、配車システムを他のプロトコルによる通信を実現するためのアプリケーションとして具体化した場合には、配車システムを構成する各要素の名称、各要素の機能、制御メッセージの名称、制御メッセージのパケット構造等は、各実施形態の記載と異なってもよい。

・本開示の技術の配車システムは、各実施形態にて説明したタクシーの配車システムとしてだけではなく、例えば、故障車を引き取るレッカー車の配車や、荷物の集荷を行う宅配便の車両の配車等の配車システムとして適用することも可能である。要は、本開示の技術の車両システムは、車両を配車するセンターと、目的地に対して配車される車両とを備えるシステムであれば適用することが可能である。

１０…ＳＩＰサーバ、１１…呼制御部、１２…プロトコル制御部、１３…メディアサーバ制御部、２０…メディアサーバ、２１…制御部、２２…音声パケット生成部、２３…音声パケット送受信部、２４…会議通話機能部、３０…センター端末装置、３１…制御メッセージ生成部、３２…制御メッセージ送受信部、３３…音声パケット生成部、３４…音声パケット送信部、４０…タクシー端末装置、４１…制御メッセージ生成部、４２…制御メッセージ送受信部、４３…音声パケット生成部、４４…音声パケット送受信部、４５…コマンド実行部、４６…位置情報取得部、４７…自動着呼判断部、５０…ＩＰネットワーク、１００，１１０，１２０，１３０…ＩＮＶＩＴＥメッセージ、１０１，１１１，１２１，１３１…ヘッダ部、１０１ａ，１１１ａ，１２１ａ，１３１ａ…フック制御コマンド、１０２，１１２，１２２，１３２…データ部、１１１ｂ，１２１ｂ，１３１ｂ…乗車位置情報、１２１ｃ…範囲情報、１３１ｃ…進行方向情報。

Claims (8)

1. 目的地への配車を行う配車センターに設置されたセンター端末装置と、
   複数の車両の各々に搭載された車両端末装置とを備え、
   前記センター端末装置は、
   前記車両端末装置の各々との通話の開始及び終了を制御する制御メッセージの１つである前記通話への初期リクエストを生成し、前記初期リクエストに前記車両端末装置に自動で着呼させるフック制御コマンドを付加する初期リクエスト生成部と、
   前記初期リクエストを送信する初期リクエスト送信部とを有し、
   前記車両端末装置の各々は、
   前記初期リクエストを受信する初期リクエスト受信部と、
   受信した前記初期リクエストの前記フック制御コマンドを解釈して前記センター端末装置からの発呼を自動で着呼させるコマンド実行部とを有する
   配車システム。
2. 前記車両端末装置の各々は、
   自車両の位置情報を取得する位置情報取得部と、
   前記センター端末装置からの発呼を自動で着呼させるか否かを判断する自動着呼判断部とを更に有し、
   前記初期リクエスト生成部は、
   前記初期リクエストに前記目的地の位置情報を更に付加し、
   前記コマンド実行部は、
   前記自動着呼判断部が、前記目的地の位置情報と前記自車両の位置情報とから算出される距離が所定の距離以内であると判断したときに、前記センター端末装置からの発呼を自動で着呼させる
   請求項１に記載の配車システム。
3. 前記初期リクエスト生成部は、
   前記初期リクエストに前記目的地と車両の位置との間の距離を示す情報である範囲情報を更に付加し、
   前記コマンド実行部は、
   前記自動着呼判断部が、前記目的地と前記自車両との間の距離が、前記範囲情報の示す距離以内であると判断したときに、前記センター端末装置からの発呼を自動で着呼させる
   請求項２に記載の配車システム。
4. 前記車両端末装置は、
   前記センター端末装置からの前記初期リクエストによって着呼したことを前記センター端末装置に知らせる応答メッセージを生成する応答メッセージ生成部と、
   前記応答メッセージを送信する応答メッセージ送信部とを更に有し、
   前記センター端末装置は、
   前記応答メッセージを受信する応答メッセージ受信部と、
   前記初期リクエストを送信してから経過した時間を測定する時間測定部とを有し、
   前記初期リクエスト生成部は、
   前記時間測定部の測定する時間が所定の時間を経過しても前記応答メッセージ受信部が前記応答メッセージを受信できないとき、前記範囲情報の示す距離を、送信された前記初期リクエストでの前記範囲情報よりも大きい距離として再度前記初期リクエストを生成し、
   前記初期リクエスト送信部は、
   前記再度生成された前記初期リクエストを送信する
   請求項３に記載の配車システム。
5. 前記初期リクエスト生成部は、
   前記車両の進行方向と、前記目的地と前記車両の位置とを結ぶ直線とがなす角度を前記範囲情報に対応付けて記述し、
   前記角度が大きいほど、前記範囲情報として小さい距離が対応付けられる
   請求項３または４に記載の配車システム。
6. 目的地への配車を行う配車センターに設置されたセンター端末装置にて、複数の車両の各々に搭載された車両端末装置と前記センター端末装置との通話の開始および終了を制御する制御メッセージの１つである初期リクエストに前記車両端末装置に自動で着呼させるフック制御コマンドが付加される工程と、
   前記センター端末装置から前記車両端末装置の各々に前記初期リクエストが送信される工程と、
   前記車両端末装置の各々にて、前記初期リクエストが受信されて、受信された前記初期リクエストの前記フック制御コマンドが解釈され、前記センター端末装置からの発呼が自動で着呼される工程と、
   を含む配車方法。
7. 目的地への配車を行う配車センターに設置され、
   複数の車両の各々に搭載された車両端末装置との通話の開始及び終了を制御する制御メッセージの１つである前記通話への初期リクエストを生成し、前記初期リクエストに前記車両端末装置にて解釈可能なコマンドとして、前記車両端末装置に自動で着呼させるフック制御コマンドを付加する初期リクエスト生成部と、
   前記初期リクエストを送信する初期リクエスト送信部とを備える、
   配車装置。
8. 目的地への配車を行う配車センターに設置されたセンター端末装置を、
   複数の車両の各々に搭載された車両端末装置との通話の開始及び終了を制御する制御メッセージの１つである前記通話への初期リクエストを生成し、前記初期リクエストに、前記車両端末装置にて解釈可能なコマンドとして、前記車両端末装置に自動で着呼させるフック制御コマンドを付加する初期リクエスト生成部と、
   前記初期リクエストを送信する初期リクエスト送信部として機能させる
   配車プログラム。

Images