ホーム > 特許ランキング > 矢崎エナジーシステム株式会社
特開2022-141327決済運用システム、決済運用システム用の車載器および決済運用プログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022141327
(43)【公開日】2022-09-29
(54)【発明の名称】決済運用システム、決済運用システム用の車載器および決済運用プログラム
(51)【国際特許分類】
G06Q 50/30 20120101AFI20220921BHJP
G06Q 20/06 20120101ALI20220921BHJP
G07B 13/00 20060101ALI20220921BHJP
G06Q 30/02 20120101ALI20220921BHJP
【ＦＩ】
G06Q50/30
G06Q20/06
G07B13/00 G
G06Q30/02 492
【審査請求】未請求
【請求項の数】10
【出願形態】ＯＬ
(21)【出願番号】P 2021041569
(22)【出願日】2021-03-15
(71)【出願人】
【識別番号】501418498
【氏名又は名称】矢崎エナジーシステム株式会社
(74)【代理人】
【識別番号】100083806
【弁理士】
【氏名又は名称】三好 秀和
(74)【代理人】
【識別番号】100101247
【弁理士】
【氏名又は名称】高橋 俊一
(74)【代理人】
【識別番号】100095500
【弁理士】
【氏名又は名称】伊藤 正和
(74)【代理人】
【識別番号】100098327
【弁理士】
【氏名又は名称】高松 俊雄
(72)【発明者】
【氏名】杉山 敏彦
【テーマコード（参考）】
3E127
5L049
5L055
【Ｆターム（参考）】
3E127AA19
3E127BA17
3E127BA50
3E127CA31
3E127CA38
3E127CA59
3E127EA02
5L049CC41
5L055AA11
(57)【要約】
【課題】タクシー料金決済時のトラブルや誤操作を防止することができる決済運用システム、決済運用システム用の車載器および決済運用プログラムを提供する。
【解決手段】通信回線Ｎ２を介してタクシーＶの配車をリクエストする配車用端末ＴＢ１と、タクシーについての運賃情報を管理する運賃管理サーバＳＡ１と、運賃情報の運賃管理サーバへの送信を行う車載器ＴＭ１と、配車用端末および車載器に設けられて、営業運転するタクシーについての料金支払条件をそれぞれ入力する料金支払条件入力部５０２、１１と、各料金支払条件について、予め設定した所定条件に合致するか否かを判定する料金支払条件判定部４１０と、料金支払条件判定部により所定条件に合致しないと判定された方の料金支払条件を無効とする無効化部１６０と、所定条件に合致すると判定された方の料金支払条件に基づいてタクシーについての運賃の決済を行う決済用機器１４とを備える。
【選択図】図２
【解決手段】通信回線Ｎ２を介してタクシーＶの配車をリクエストする配車用端末ＴＢ１と、タクシーについての運賃情報を管理する運賃管理サーバＳＡ１と、運賃情報の運賃管理サーバへの送信を行う車載器ＴＭ１と、配車用端末および車載器に設けられて、営業運転するタクシーについての料金支払条件をそれぞれ入力する料金支払条件入力部５０２、１１と、各料金支払条件について、予め設定した所定条件に合致するか否かを判定する料金支払条件判定部４１０と、料金支払条件判定部により所定条件に合致しないと判定された方の料金支払条件を無効とする無効化部１６０と、所定条件に合致すると判定された方の料金支払条件に基づいてタクシーについての運賃の決済を行う決済用機器１４とを備える。
【選択図】図２
【特許請求の範囲】
【請求項1】
通信回線を介してタクシーの配車をリクエストする配車用端末と、
前記タクシーについての運賃情報を管理する運賃管理サーバと、
前記タクシーに搭載され、運賃情報の前記運賃管理サーバへの送信を行う車載器と、
前記配車用端末および前記車載器に設けられて、営業運転する前記タクシーについての料金支払条件をそれぞれ入力する料金支払条件入力部と、
前記各料金支払条件について、予め設定した所定条件に合致するか否かを判定する料金支払条件判定部と、
前記料金支払条件判定部により前記所定条件に合致しないと判定された方の料金支払条件を無効とする無効化部と、
前記所定条件に合致すると判定された方の料金支払条件に基づいて前記タクシーについての運賃の決済を行う決済用機器と、
を備える決済運用システム。
前記タクシーについての運賃情報を管理する運賃管理サーバと、
前記タクシーに搭載され、運賃情報の前記運賃管理サーバへの送信を行う車載器と、
前記配車用端末および前記車載器に設けられて、営業運転する前記タクシーについての料金支払条件をそれぞれ入力する料金支払条件入力部と、
前記各料金支払条件について、予め設定した所定条件に合致するか否かを判定する料金支払条件判定部と、
前記料金支払条件判定部により前記所定条件に合致しないと判定された方の料金支払条件を無効とする無効化部と、
前記所定条件に合致すると判定された方の料金支払条件に基づいて前記タクシーについての運賃の決済を行う決済用機器と、
を備える決済運用システム。
【請求項2】
前記車載器は、
前記配車用端末および前記運賃管理サーバと情報通信を行う通信部と、
前記決済用機器と、
を備えるタクシーメータで構成される請求項１に記載の決済運用システム。
前記配車用端末および前記運賃管理サーバと情報通信を行う通信部と、
前記決済用機器と、
を備えるタクシーメータで構成される請求項１に記載の決済運用システム。
【請求項3】
前記料金支払条件判定部は、前記運賃管理サーバに設けられ、
前記配車用端末または前記決済用機器は、前記料金支払条件判定部の判定結果に基づく決済情報に基づいて前記運賃についての決済処理を行う請求項１または請求項２に記載の決済運用システム。
前記配車用端末または前記決済用機器は、前記料金支払条件判定部の判定結果に基づく決済情報に基づいて前記運賃についての決済処理を行う請求項１または請求項２に記載の決済運用システム。
【請求項4】
前記無効化部は、前記料金支払条件判定部により前記料金支払条件が前記所定条件に合致しないと判定された場合に、当該料金支払条件を入力した前記配車用端末または前記決済用機器への前記決済情報を送信しないように制御する請求項３に記載の決済運用システム。
【請求項5】
前記無効化部は、前記料金支払条件判定部により前記料金支払条件が前記所定条件に合致しないと判定された場合に、現金およびタクシーチケットによる決済操作を行うことができないように制御する請求項３に記載の決済運用システム。
【請求項6】
決済運用システム用の車載器であって、
通信回線を介してタクシーの配車をリクエストする配車用端末と、前記タクシーについての運賃情報を管理する運賃管理サーバとの通信部と、
前記タクシーについての料金支払条件を入力する料金支払条件入力部と、
を備える決済運用システム用の車載器。
通信回線を介してタクシーの配車をリクエストする配車用端末と、前記タクシーについての運賃情報を管理する運賃管理サーバとの通信部と、
前記タクシーについての料金支払条件を入力する料金支払条件入力部と、
を備える決済運用システム用の車載器。
【請求項7】
前記料金支払条件について、予め設定した所定条件に合致するか否かを判定する料金支払条件判定部により前記所定条件に合致しないと判定された場合に前記料金支払条件を無効とする無効化部と、
前記所定条件に合致すると判定された場合に、前記料金支払条件に基づいて前記タクシーについての運賃の決済を行う決済用機器を備える請求項６に記載の決済運用システム用の車載器。
前記所定条件に合致すると判定された場合に、前記料金支払条件に基づいて前記タクシーについての運賃の決済を行う決済用機器を備える請求項６に記載の決済運用システム用の車載器。
【請求項8】
決済運用システムで実行され、
配車用端末および車載器について、営業運転するタクシーの料金支払条件をそれぞれ入力する料金支払条件入力過程と、
前記各料金支払条件について、予め設定した所定条件に合致するか否かを判定する料金支払条件判定過程と、
前記料金支払条件について、前記所定条件に合致しないと判定された場合に前記料金支払条件を無効とする無効化過程と、
前記所定条件に合致すると判定された場合に、前記料金支払条件に基づいて前記タクシーについての運賃の決済を行う決済実行過程と、
を有する決済運用プログラム。
配車用端末および車載器について、営業運転するタクシーの料金支払条件をそれぞれ入力する料金支払条件入力過程と、
前記各料金支払条件について、予め設定した所定条件に合致するか否かを判定する料金支払条件判定過程と、
前記料金支払条件について、前記所定条件に合致しないと判定された場合に前記料金支払条件を無効とする無効化過程と、
前記所定条件に合致すると判定された場合に、前記料金支払条件に基づいて前記タクシーについての運賃の決済を行う決済実行過程と、
を有する決済運用プログラム。
【請求項9】
前記無効化過程は、前記料金支払条件判定過程において前記料金支払条件が前記所定条件に合致しないと判定された場合に、当該料金支払条件を入力した前記配車用端末または決済用機器への決済情報の送信を行わないように制御する請求項８に記載の決済運用プログラム。
【請求項10】
前記無効化過程は、前記料金支払条件判定過程により前記料金支払条件が前記所定条件に合致しないと判定された場合に、現金およびタクシーチケットによる決済操作を行うことができないように制御する請求項８に記載の決済運用プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、タクシー等の決済に適用される決済運用システム、決済運用システム用の車載器および決済運用プログラムに関する。
【背景技術】
【0002】
タクシーにおける決済運用に適用可能なネットワークに接続したタクシーメータ（車載器）に関する技術は種々提案されている（特許文献１）。
そして、例えば、タクシーメータに連動した複数の決済用機器を用いて決済運用を行う場合がある。
そして、例えば、タクシーメータに連動した複数の決済用機器を用いて決済運用を行う場合がある。
【0003】
また、昨今は、通信回線を介してタクシーの配車をリクエストする配車用アプリケーション（配車アプリ）を搭載したタブレット型の情報端末（配車用タブレット等）を利用してネット決済を行う場合も増加しつつある。
【0004】
例えば、決済運用システムの一種では、タクシーメータによって乗車した距離・時間から乗車運賃を算出する。そして、メータ表示部に運賃を表示すると共に、接続した決済用機器（例えば、配車用タブレット、決済専用機など）に料金情報を送信し、料金情報の共有を図っている。
【0005】
ここで、決済方法（支払い方法）について、一般的なタクシーメータでは、「現金決済」の他に、「タクシーチケット決済」が可能となっている。また、「配車用タブレット」では、ネットワークを介した「ネット決済」が可能となっている場合が多い。さらに、決済専用機では、「カード決済」、「電子マネー決済」等が可能となっている場合がある。
そして、決済システムが受信した金額情報に基づき、各決済用機器の操作によってタクシー運賃等の決済（支払い）を実行している。
そして、決済システムが受信した金額情報に基づき、各決済用機器の操作によってタクシー運賃等の決済（支払い）を実行している。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特表２０１６－５０１４０７号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
しかしながら、複数の決済用機器で決済処理が行われることにより、他方の決済用機器で処理済みとなっているにも関わらず、もう一方の決済用機器で重複して決済を行うという誤操作が発生するという問題があった。
【0008】
即ち、例えば、本来は事前に配車用タブレットによってネット決済での支払が予約されているところを、誤って決済用機器でカード決済を行ってしまう場合などが有り得る。
【0009】
このような場合には、誤った決済により乗客との間でトラブルが発生したり、乗務員による決済操作の取消や、決済操作のやり直しなどの手間が発生するという不都合があった。
【0010】
本発明は、上記課題に鑑みてなされたものであり、タクシー料金決済時のトラブルや誤操作を防止することができる決済運用システム、決済運用システム用の車載器および決済運用プログラムを提供することを目的とする。
【課題を解決するための手段】
【0011】
本発明の態様に係る決済運用システムは、通信回線を介してタクシーの配車をリクエストする配車用端末と、前記タクシーについての運賃情報を管理する運賃管理サーバと、前記タクシーに搭載され、運賃情報の前記運賃管理サーバへの送信を行う車載器と、前記配車用端末および前記車載器に設けられて、営業運転する前記タクシーについての料金支払条件をそれぞれ入力する料金支払条件入力部と、前記各料金支払条件について、予め設定した所定条件に合致するか否かを判定する料金支払条件判定部と、前記料金支払条件判定部により前記所定条件に合致しないと判定された方の料金支払条件を無効とする無効化部と、前記所定条件に合致すると判定された方の料金支払条件に基づいて前記タクシーについての運賃の決済を行う決済用機器と、を備える。
【0012】
前記配車用端末は、タブレット型の情報端末で構成され、タクシー配車のリクエスト処理、前記タクシーについての前記料金支払条件の入力処理、送信処理および前記運賃のネット決済処理を実行する配車用アプリケーションを搭載することが好ましい。
【0013】
前記車載器は、前記配車用端末および前記運賃管理サーバと情報通信を行う通信部と、前記決済用機器と、を備えるタクシーメータで構成されることが好ましい。
【0014】
前記料金支払条件判定部は、前記運賃管理サーバに設けられ、前記配車用端末または前記決済用機器は、前記料金支払条件判定部の判定結果に基づく決済情報に基づいて前記運賃についての決済処理を行うことが好ましい。
【0015】
前記無効化部は、前記料金支払条件判定部により前記料金支払条件が前記所定条件に合致しないと判定された場合に、当該料金支払条件を入力した前記配車用端末または前記決済用機器への前記決済情報を送信しないように制御することが好ましい。
【0016】
前記無効化部は、前記料金支払条件判定部により前記料金支払条件が前記所定条件に合致しないと判定された場合に、現金およびタクシーチケットによる決済操作を行うことができないように制御することが好ましい。
【0017】
本発明の他の態様に係る決済運用システム用の車載器は、通信回線を介してタクシーの配車をリクエストする配車用端末と、前記タクシーについての運賃情報を管理する運賃管理サーバとの通信部と、前記タクシーについての料金支払条件を入力する料金支払条件入力部と、を備える。
【0018】
前記料金支払条件について、予め設定した所定条件に合致するか否かを判定する料金支払条件判定部により前記所定条件に合致しないと判定された場合に前記料金支払条件を無効とする無効化部と、前記所定条件に合致すると判定された場合に、前記料金支払条件に基づいて前記タクシーについての運賃の決済を行う決済用機器を備えることが好ましい。
【0019】
本発明の他の態様に係る決済運用プログラムは、決済運用システムで実行され、配車用端末および車載器について、営業運転するタクシーの料金支払条件をそれぞれ入力する料金支払条件入力過程と、前記各料金支払条件について、予め設定した所定条件に合致するか否かを判定する料金支払条件判定過程と、前記料金支払条件について、前記所定条件に合致しないと判定された場合に前記料金支払条件を無効とする無効化過程と、前記所定条件に合致すると判定された場合に、前記料金支払条件に基づいて前記タクシーについての運賃の決済を行う決済実行過程と、を有する。
【0020】
前記無効化過程は、前記料金支払条件判定過程において前記料金支払条件が前記所定条件に合致しないと判定された場合に、当該料金支払条件を入力した前記配車用端末または決済用機器への決済情報の送信を行わないように制御することが好ましい。
【0021】
前記無効化過程は、前記料金支払条件判定過程により前記料金支払条件が前記所定条件に合致しないと判定された場合に、現金およびタクシーチケットによる決済操作を行うことができないように制御することが好ましい。
【発明の効果】
【0022】
本発明によれば、タクシー料金決済時のトラブルや誤操作を防止することができる決済運用システム、決済運用システム用の車載器および決済運用プログラムを提供することができる。
【図面の簡単な説明】
【0023】
【図1】実施の形態に係る決済運用システムの概略構成を示すブロック図である。
【図2】実施の形態に係る決済運用システムの機能構成を示す機能ブロック図である。
【図3】実施の形態に係る決済運用システムに適用されるタクシーメータの構成例を示すブロック図である。
【図4】実施の形態に係る決済運用システムにおける運賃表示例を示す説明図である。
【図5】実施の形態に係る決済運用システムで実行されるタクシー運賃決済処理の処理手順の例を示すフローチャートである。
【図6】実施の形態に係る決済運用システムで実行されるメータ事前確定取消・変更処理の処理手順の例を示すフローチャートである。
【図7】実施の形態に係る決済運用システムで実行されるメータ支払処理の処理手順の例を示すフローチャートである。
【発明を実施するための形態】
【0024】
【0025】
（決済運用システムの機能構成）
図１および図２を参照して、本実施の形態に係る決済運用システムＳ１の機能構成等について説明する。
図１および図２に示すように、決済運用システムＳ１は、通信回線Ｎ２を介してタクシーＶの配車をリクエストするタブレット型の情報端末等で構成される配車用端末（配車用タブレット等）ＴＢ１を備える。
なお、通信回線Ｎ２は、有線回線または無線回線の何れであってもよい。
図１および図２を参照して、本実施の形態に係る決済運用システムＳ１の機能構成等について説明する。
図１および図２に示すように、決済運用システムＳ１は、通信回線Ｎ２を介してタクシーＶの配車をリクエストするタブレット型の情報端末等で構成される配車用端末（配車用タブレット等）ＴＢ１を備える。
なお、通信回線Ｎ２は、有線回線または無線回線の何れであってもよい。
【0026】
この配車用端末ＴＢ１は、タクシーＶ等の利用者（顧客）等が所持するものであり、クシー配車のリクエスト処理、タクシーＶについての料金支払条件の入力処理、送信処理および運賃のネット決済処理等を実行するソフトウェア等で構成される配車用アプリケーション（配車アプリ）を搭載している。なお、配車アプリをインストールしたスマートフォン等を配車用端末ＴＢ１として利用することもできる。
【0027】
また、配車用端末ＴＢ１は、タクシーメータ（車載器）ＴＭ１と情報通信を行う通信部５０１、営業運転するタクシーＶについての料金支払条件を入力する料金支払条件入力部５０２、運賃の決済を行うネット決済部５０３等を備える。
また、決済運用システムＳ１は、タクシーＶについての運賃情報を管理する外部装置としての運賃管理サーバＳＡ１を備える。
運賃管理サーバＳＡ１は、複数のタクシーＶから運賃情報等を受信する通信部４０２を備える。
また、受信した各運賃情報を格納するハードディスク装置等で構成される格納部４００を備える。
また、ＣＰＵ等で構成され、各種処理を実行する処理部４０１等を備える。
また、決済運用システムＳ１は、タクシーＶについての運賃情報を管理する外部装置としての運賃管理サーバＳＡ１を備える。
運賃管理サーバＳＡ１は、複数のタクシーＶから運賃情報等を受信する通信部４０２を備える。
また、受信した各運賃情報を格納するハードディスク装置等で構成される格納部４００を備える。
また、ＣＰＵ等で構成され、各種処理を実行する処理部４０１等を備える。
【0028】
なお、処理部４０１は、通信部４０２により通信回線Ｎ１を介して受信した各料金支払条件に関する情報について、予め設定した所定条件に合致するか否かを判定する料金支払条件判定部４１０を構成する。
【0029】
また、決済運用システムＳ１は、各タクシーＶに搭載され、運賃情報の運賃管理サーバＳＡ１への送信を行う通信部１７を有するタクシーメータ等で構成される車載器ＴＭ１を備える。
車載器ＴＭ１は、営業運転するタクシーＶについての料金支払条件を入力するタクシーメータ画面上のテンキー入力部やキーボード等で構成される料金支払条件入力部１１を備える。
なお、車載器ＴＭ１にも配車用端末ＴＢ１と同様の配車アプリを搭載するようにしてもよい。
車載器ＴＭ１は、営業運転するタクシーＶについての料金支払条件を入力するタクシーメータ画面上のテンキー入力部やキーボード等で構成される料金支払条件入力部１１を備える。
なお、車載器ＴＭ１にも配車用端末ＴＢ１と同様の配車アプリを搭載するようにしてもよい。
【0030】
また、各料金支払条件について、運賃管理サーバＳＡ１が備える料金支払条件判定部４１０により所定条件に合致しないと判定された方の料金支払条件を無効とするＣＰＵ１５１等で構成される無効化部１６０を備える。
【0031】
また、料金支払条件判定部４１０により所定条件に合致すると判定された方の料金支払条件に基づいてタクシーＶについての運賃の決済を行うカードリーダ等で構成される決済用機器１４を備える。
【0032】
そして、配車用端末ＴＢ１または決済用機器１４は、料金支払条件判定部４１０の判定結果に基づく決済情報を受信し、その決済情報に基づいて運賃についての決済処理を行う。
なお、図２に示す実施の形態では、決済用機器１４はタクシーメータ（車載器）ＴＭ１の一部として示されているが、これには限定されない。即ち、例えば、決済用機器１４をタクシーメータ（車載器）ＴＭ１に外付けして設け、連動して動作する構成としてもよい。
なお、図２に示す実施の形態では、決済用機器１４はタクシーメータ（車載器）ＴＭ１の一部として示されているが、これには限定されない。即ち、例えば、決済用機器１４をタクシーメータ（車載器）ＴＭ１に外付けして設け、連動して動作する構成としてもよい。
【0033】
また、無効化部１６０は、例えば、料金支払条件判定部４１０により料金支払条件が所定条件に合致しないと判定された場合には、当該料金情報を入力した配車用端末ＴＢ１または決済用機器１４への決済情報を送信しないように制御する。
【0034】
また、無効化部１６０は、例えば、料金支払条件判定部４１０により料金支払条件が所定条件に合致しないと判定された場合には、現金やタクシーチケットによる支払い操作を行うことができないように制御してもよい。
【0035】
ここで、例えば、配車用端末ＴＢ１で入力された料金支払条件を優先することを所定条件として設定した場合を想定する。この条件では、配車用端末ＴＢ１によってネット決済での料金支払条件が予約されている場合には、車載器ＴＭ１側で入力された料金支払条件は所定条件に合致しないとして無効とされる。
【0036】
したがって、配車用端末ＴＢ１によってネット決済によって運賃の支払いが行われるにも関わらず、誤って車載器ＴＭ１側の決済用機器１４でカード決済を行ってしまう事態や、現金やタクシーチケットによる支払い操作を行う事態を有効に回避することができる。
このように、決済運用システムＳ１によれば、タクシー利用者と乗務員との間で決済に関するトラブルの発生を未然に防止することができる。また、乗務員による決済操作の取消や、決済操作のやり直しなどの手間が発生する事態を回避することができ利便性を向上することができる。
このように、決済運用システムＳ１によれば、タクシー利用者と乗務員との間で決済に関するトラブルの発生を未然に防止することができる。また、乗務員による決済操作の取消や、決済操作のやり直しなどの手間が発生する事態を回避することができ利便性を向上することができる。
【0037】
（車載器の構成例）
図３を参照して、本実施の形態に係る決済運用システムＳ１に適用される車載器（タクシーメータ）ＴＭ１の構成例について説明する。
タクシーメータＴＭ１は、タクシー（車両）Ｖに搭載され、例えばカーナビゲーションユニット（所謂カーナビ）機能、タクシーメータ機能等を備えている。
カーナビ機能としては、例えば車両の現在位置を検出する機能や、現在位置を含む地図の情報を出力する機能などが含まれる。
図３を参照して、本実施の形態に係る決済運用システムＳ１に適用される車載器（タクシーメータ）ＴＭ１の構成例について説明する。
タクシーメータＴＭ１は、タクシー（車両）Ｖに搭載され、例えばカーナビゲーションユニット（所謂カーナビ）機能、タクシーメータ機能等を備えている。
カーナビ機能としては、例えば車両の現在位置を検出する機能や、現在位置を含む地図の情報を出力する機能などが含まれる。
【0038】
図３に示す構成例では、タクシーメータＴＭ１の内部に、無効化部１６０等を構成するマイクロコンピュータ（ＣＰＵ）１５１、演算処理の作業領域等を構成する記憶部（ＲＡＭ）５２を備える。
【0039】
また、演算プログラム等のソフトウェアや運賃データ等の各種データを格納する固定情報記憶部（ＲＯＭ）５３、タッチパネル型の表示部（ＬＣＤ）１６を備える。
また、入力インタフェース５６、５７、５９、６０および演算タイミング等を図るクロック信号を生成する時計ＩＣ（ＲＴＣ）５８を備える。
さらに、位置情報取得部を構成するＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）受信器１０を備える。
また、入力インタフェース５６、５７、５９、６０および演算タイミング等を図るクロック信号を生成する時計ＩＣ（ＲＴＣ）５８を備える。
さらに、位置情報取得部を構成するＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）受信器１０を備える。
【0040】
また、各種データを書き込み可能なメモリカード６４を装着可能なカードＲ／Ｗインタフェース５４、空車、賃走、累計、迎車等の操作を行う操作部４０ａ～４０ｃを備える。
また、運賃管理サーバＳＡ１との間で目的地情報、経路情報、事前確定運賃、変更後運賃および車内情報等の送受信を行う通信部１７を備える。
また、報知部１８を構成するスピーカ、運賃等を印刷する印字部を構成する感熱式等のプリンタ６５等が設けられている。
なお、メモリカード６４には、例えば、乗務員の認証に必要なデータ、タクシー車両の走行履歴、運賃履歴等の営業データや時系列データ等を保存する。
また、運賃管理サーバＳＡ１との間で目的地情報、経路情報、事前確定運賃、変更後運賃および車内情報等の送受信を行う通信部１７を備える。
また、報知部１８を構成するスピーカ、運賃等を印刷する印字部を構成する感熱式等のプリンタ６５等が設けられている。
なお、メモリカード６４には、例えば、乗務員の認証に必要なデータ、タクシー車両の走行履歴、運賃履歴等の営業データや時系列データ等を保存する。
【0041】
また、マイクロコンピュータ（ＣＰＵ）１５１には、車両から出力される走行パルスＰ１が入力され、実走運賃に相当するメータ値を算出する。また、マイクロコンピュータ（ＣＰＵ）１５１には、タリフ情報が入力されるようになっている。
また、入力インタフェース５６には、ドライブレコーダ等が接続される。
また、入力インタフェース５６には、ドライブレコーダ等が接続される。
【0042】
（運賃の提示等について）
図４を参照して、本実施の形態に係る決済運用システムＳ１による運賃の提示例等について説明する。
図４に示すように、タクシーＶが目的地に到着すると、タクシーメータＴＭ１は、走行距離等に基づいて算出された確定運賃を表示する。
ここで、運賃の決済について、例えば、配車用端末ＴＢ１で入力された料金支払条件を優先することを所定条件として設定した場合を想定する。
この所定条件において、配車用端末ＴＢ１によってネット決済での料金支払条件が予約されている場合には、車載器ＴＭ１側で入力された料金支払条件は所定条件に合致しないとして無効とされる。そして、確定運賃は、配車用端末ＴＢ１側でネット決済によって支払いが行われる。
図４を参照して、本実施の形態に係る決済運用システムＳ１による運賃の提示例等について説明する。
図４に示すように、タクシーＶが目的地に到着すると、タクシーメータＴＭ１は、走行距離等に基づいて算出された確定運賃を表示する。
ここで、運賃の決済について、例えば、配車用端末ＴＢ１で入力された料金支払条件を優先することを所定条件として設定した場合を想定する。
この所定条件において、配車用端末ＴＢ１によってネット決済での料金支払条件が予約されている場合には、車載器ＴＭ１側で入力された料金支払条件は所定条件に合致しないとして無効とされる。そして、確定運賃は、配車用端末ＴＢ１側でネット決済によって支払いが行われる。
【0043】
一方、運賃の決済について、例えば、タクシーメータＴＭ１で入力（或いは操作）された料金支払条件を優先することを所定条件として設定されている場合も想定される。
【0044】
この条件においては、配車用端末ＴＢ１側で入力された料金支払条件（例えば、ネット決済の予約）は所定条件に合致しないとして無効とされる。そして、確定運賃は、タクシーメータＴＭ１側の決済用機器（カード決済用機器等）によって支払いが行われる。
また、この場合には、タクシー利用者の希望等により、現金或いはタクシーチケット等による支払いを行うことができるようにしてもよい。
また、この場合には、タクシー利用者の希望等により、現金或いはタクシーチケット等による支払いを行うことができるようにしてもよい。
【0045】
このように、決済運用システムＳ１によれば、配車用端末ＴＢ１によってネット決済によって運賃の支払いが行われるにも関わらず、誤って車載器ＴＭ１側の決済用機器１４でカード決済を行ってしまう事態や、現金やタクシーチケットによる支払い操作を行う事態などを有効に回避することができる。
【0046】
したがって、決済運用システムＳ１によれば、タクシー利用者と乗務員との間で決済に関するトラブルの発生を未然に防止することができる。また、乗務員による決済操作の取消や、決済操作のやり直しなどの手間が発生する事態を回避することができ利便性を向上することができる。
【0047】
（タクシー運賃決済処理について）
次に、図５のフローチャートを参照して決済運用システムＳ１で実行されるタクシー運賃決済処理（メイン処理）の処理手順の例について説明する。
なお、本処理は、例えば車載器（タクシーメータ）ＴＭ１側のＣＰＵ１５１等で実行され、車載器（タクシーメータ）が備えるＯＳ（オペレーティングシステム）と所定のアプリケーションプログラム（配車アプリ等）との協働により実現することができる。但し、配車アプリ等の各種機能の一部または全部をハードウェアで実現するようにしてもよい。
次に、図５のフローチャートを参照して決済運用システムＳ１で実行されるタクシー運賃決済処理（メイン処理）の処理手順の例について説明する。
なお、本処理は、例えば車載器（タクシーメータ）ＴＭ１側のＣＰＵ１５１等で実行され、車載器（タクシーメータ）が備えるＯＳ（オペレーティングシステム）と所定のアプリケーションプログラム（配車アプリ等）との協働により実現することができる。但し、配車アプリ等の各種機能の一部または全部をハードウェアで実現するようにしてもよい。
【0048】
また、ここでは、運賃の決済について、例えば、車載器（タクシーメータ）ＴＭ１側の配車アプリで入力された料金支払条件を優先することを所定条件として設定した場合を想定する。
この処理が開始されると、ステップＳ１０で、タクシーＶが目的地に搭載して運賃が確定するなどのイベントが発生してステップＳ１１に移行する。
この処理が開始されると、ステップＳ１０で、タクシーＶが目的地に搭載して運賃が確定するなどのイベントが発生してステップＳ１１に移行する。
【0049】
ステップＳ１１では、運賃管理サーバＳＡ１の料金支払条件判定部４１０により、車載器（タクシーメータ）ＴＭ１側の配車アプリで入力された料金支払条件を優先する判定処理を行ってステップＳ１２に移行する。
ステップＳ１２では、確定運賃について、タクシーメータＴＭ１側の決済用機器（カード決済用機器等）による支払処理を行ってステップＳ１３に移行する。
ステップＳ１３では、タクシーＶのタリフを空車に変更して処理を終了する。
ステップＳ１２では、確定運賃について、タクシーメータＴＭ１側の決済用機器（カード決済用機器等）による支払処理を行ってステップＳ１３に移行する。
ステップＳ１３では、タクシーＶのタリフを空車に変更して処理を終了する。
【0050】
なお、運賃の決済について、例えば、配車用端末ＴＢ１の配車アプリ５００で入力された料金支払条件を優先することを所定条件として設定した場合には、ステップＳ１１に代えて、運賃管理サーバＳＡ１の料金支払条件判定部４１０により、配車用端末ＴＢ１の配車アプリ５００で入力された料金支払条件を優先する判定処理を行う。そして、ステップＳ１２に代えて、配車用端末ＴＢ１側でネット決済等により確定運賃の支払処理を実行することとなる。
【0051】
（メータ事前確定取消・変更処理について）
次に、図６のフローチャートを参照して決済運用システムＳ１で実行されるメータ事前確定取消・変更処理の処理手順の例について説明する。
なお、この処理では、配車用端末ＴＢ１或いは車載器（タクシーメータ）ＴＭ１の配車アプリで事前に契約した運賃（仮運賃）を「事前確定運賃」という。
また、本処理は、例えば車載器（タクシーメータ）ＴＭ１側のＣＰＵ１５１等で実行され、車載器（タクシーメータ）が備えるＯＳ（オペレーティングシステム）と所定のアプリケーションプログラム（配車アプリ等）との協働により実現することができる。但し、配車アプリ等の各種機能の一部または全部をハードウェアで実現するようにしてもよい。
この処理が開始されると、ステップＳ２０で、事前確定運賃が発生したか否かが判定される。
次に、図６のフローチャートを参照して決済運用システムＳ１で実行されるメータ事前確定取消・変更処理の処理手順の例について説明する。
なお、この処理では、配車用端末ＴＢ１或いは車載器（タクシーメータ）ＴＭ１の配車アプリで事前に契約した運賃（仮運賃）を「事前確定運賃」という。
また、本処理は、例えば車載器（タクシーメータ）ＴＭ１側のＣＰＵ１５１等で実行され、車載器（タクシーメータ）が備えるＯＳ（オペレーティングシステム）と所定のアプリケーションプログラム（配車アプリ等）との協働により実現することができる。但し、配車アプリ等の各種機能の一部または全部をハードウェアで実現するようにしてもよい。
この処理が開始されると、ステップＳ２０で、事前確定運賃が発生したか否かが判定される。
【0052】
そして、判定結果が「Ｙｅｓ」の場合にはステップＳ２２に移行する。ステップＳ２２では、配車アプリ優先フラグをＯＮにして処理を終了する。これにより、配車アプリで契約した事前確定運賃が支払時に優先される。
また、ステップＳ２０で「Ｎｏ」と判定された場合にはステップＳ２１に移行する。
ステップＳ２１では、車載器（タクシーメータ）ＴＭ１の迎車ボタン（図４参照）が押下されたか否かが判定される。
判定結果が「Ｙｅｓ」の場合にはステップＳ２２に移行し、「Ｎｏ」の場合には処理を終了する。
また、ステップＳ２０で「Ｎｏ」と判定された場合にはステップＳ２１に移行する。
ステップＳ２１では、車載器（タクシーメータ）ＴＭ１の迎車ボタン（図４参照）が押下されたか否かが判定される。
判定結果が「Ｙｅｓ」の場合にはステップＳ２２に移行し、「Ｎｏ」の場合には処理を終了する。
【0053】
（メータ支払処理について）
次に、図７のフローチャートを参照して決済運用システムＳ１で実行されるメータ支払処理の処理手順の例について説明する。
本処理は、例えば車載器（タクシーメータ）ＴＭ１側のＣＰＵ１５１等で実行され、車載器（タクシーメータ）が備えるＯＳ（オペレーティングシステム）と所定のアプリケーションプログラム（配車アプリ等）との協働により実現することができる。但し、配車アプリ等の各種機能の一部または全部をハードウェアで実現するようにしてもよい。
この処理が開始されると、ステップＳ３０で、車載器（タクシーメータ）ＴＭ１の支払い（合計）ボタン（図４参照）を押下して、ステップＳ３１に移行する。
ステップＳ３１では、配車アプリ優先フラグがＯＮか否かが判定される。
次に、図７のフローチャートを参照して決済運用システムＳ１で実行されるメータ支払処理の処理手順の例について説明する。
本処理は、例えば車載器（タクシーメータ）ＴＭ１側のＣＰＵ１５１等で実行され、車載器（タクシーメータ）が備えるＯＳ（オペレーティングシステム）と所定のアプリケーションプログラム（配車アプリ等）との協働により実現することができる。但し、配車アプリ等の各種機能の一部または全部をハードウェアで実現するようにしてもよい。
この処理が開始されると、ステップＳ３０で、車載器（タクシーメータ）ＴＭ１の支払い（合計）ボタン（図４参照）を押下して、ステップＳ３１に移行する。
ステップＳ３１では、配車アプリ優先フラグがＯＮか否かが判定される。
【0054】
判定結果が「Ｙｅｓ」の場合にはステップＳ３２に移行して、配車アプリで設定された料金情報を決済用機器１４に送信する処理を開始してステップＳ３３に移行する。
ステップＳ３３では、現金およびタクシーチケット（チケット）による支払いを無効とする表示を表示部１６に表示してステップＳ３４に移行する。
ステップＳ３４では、送信ボタン（図４参照）を有効とする表示を行ってステップＳ３７に移行する。
一方、ステップＳ３１で「Ｎｏ」と判定された場合にはステップＳ３５に移行する。
ステップＳ３５では、配車アプリ優先フラグがＯＦＦの場合の料金情報を決済用機器１４に送信する処理を開始してステップＳ３６に移行する。
ステップＳ３６では、決済用機器１４に決済用の料金情報（決済情報）を送信する処理を開始してステップＳ３７に移行する。
ステップＳ３７では、車載器（タクシーメータ）ＴＭ１の送信ボタン（図４参照）が押下されたか否かが判定される。
判定結果が「Ｎｏ」の場合にはステップＳ３８に移行し、「Ｙｅｓ」の場合にはステップＳ３９に移行する。
ステップＳ３３では、現金およびタクシーチケット（チケット）による支払いを無効とする表示を表示部１６に表示してステップＳ３４に移行する。
ステップＳ３４では、送信ボタン（図４参照）を有効とする表示を行ってステップＳ３７に移行する。
一方、ステップＳ３１で「Ｎｏ」と判定された場合にはステップＳ３５に移行する。
ステップＳ３５では、配車アプリ優先フラグがＯＦＦの場合の料金情報を決済用機器１４に送信する処理を開始してステップＳ３６に移行する。
ステップＳ３６では、決済用機器１４に決済用の料金情報（決済情報）を送信する処理を開始してステップＳ３７に移行する。
ステップＳ３７では、車載器（タクシーメータ）ＴＭ１の送信ボタン（図４参照）が押下されたか否かが判定される。
判定結果が「Ｎｏ」の場合にはステップＳ３８に移行し、「Ｙｅｓ」の場合にはステップＳ３９に移行する。
【0055】
ステップＳ３９では、車載器（タクシーメータ）ＴＭ１の決済用機器１４に決済用の料金情報（決済情報）を送信する処理を実行してステップＳ４０に移行する。
ステップＳ４０では、現金およびタクシーチケット（チケット）による支払いを有効とする表示を表示部１６に表示してステップＳ４１に移行する。
ステップＳ４１では、送信ボタンを押下した情報を運賃管理サーバＳＡ１に送信してステップＳ３８に移行する。
ステップＳ４０では、現金およびタクシーチケット（チケット）による支払いを有効とする表示を表示部１６に表示してステップＳ４１に移行する。
ステップＳ４１では、送信ボタンを押下した情報を運賃管理サーバＳＡ１に送信してステップＳ３８に移行する。
【0056】
ステップＳ３８では、タクシーＶが空車状態か否かが判定される。判定結果が「Ｎｏ」の場合にはステップＳ３７に戻り、「Ｙｅｓ」の場合には処理を終了する。
【0057】
以上、本発明の決済運用システムＳ１を図示の実施形態に基づいて説明したが、本発明はこれに限定されるものではなく、各部の構成は、同様の機能を有する任意の構成のものに置き換えることができる。
例えば、メータ迎車が発生した営業運転および事前確定運賃が発生した営業運転においては、配車用端末ＴＢ１のみに料金情報を送信するようにしてもよい。
例えば、メータ迎車が発生した営業運転および事前確定運賃が発生した営業運転においては、配車用端末ＴＢ１のみに料金情報を送信するようにしてもよい。
【0058】
また、既に決済処理が行われている状態で、配車用端末ＴＢ１または車載器（タクシーメータ）ＴＭ１の決済用機器１４から決済情報を受信した場合には、車載器（タクシーメータ）ＴＭ１において警報表示や音声による注意喚起を行うようにしてもよい。
【0059】
また、車載器（タクシーメータ）ＴＭ１の送信ボタンの押下情報および決済情報は、リアルタイムで運賃管理サーバＳＡ１に送信し、管理事務所等で運賃管理を行うようにしてもよい。
【符号の説明】
【0060】
Ｓ１ 決済運用システム
ＳＡ１ 運賃管理サーバ
Ｖ タクシー
ＴＢ１ 配車用端末（配車用タブレット）
ＴＭ１ 車載器（タクシーメータ）
１１、５０２ 料金支払条件入力部
１４ 決済用機器
１６０ 無効化部
４１０ 料金支払条件判定部
５００ 配車アプリ
ＳＡ１ 運賃管理サーバ
Ｖ タクシー
ＴＢ１ 配車用端末（配車用タブレット）
ＴＭ１ 車載器（タクシーメータ）
１１、５０２ 料金支払条件入力部
１４ 決済用機器
１６０ 無効化部
４１０ 料金支払条件判定部
５００ 配車アプリ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】