【新規性喪失の例外の表示】特許法第30条第2項適用 ウェブサイトの掲載日: 平成29年3月1日 ウェブサイトのアドレス: https://twitter.com/JapanTaxi/status/836844789916139520 https://twitter.com/JapanTaxi/status/836876784268361729 公開者: JapanTaxi株式会社 ウェブサイトの掲載日: 平成29年3月8日 ウェブサイトのアドレス: https://www.facebook.com/japantaxi/posts/1266837013430037 公開者: JapanTaxi株式会社、で発表
【文献】
中村 勇介,日本交通はグーグルになれるか,日経デジタルマーケティング ,日本,日経BP社 ,2017年 4月25日,第115号,P.4−9
(58)【調査した分野】(Int.Cl.,DB名)
【発明の概要】
【発明が解決しようとする課題】
【0005】
以上のような背景を鑑み、本発明は、運送サービスを受けたユーザが迅速に運賃の支払いを完了させることができる精算システム、ホスト端末、精算方法、プログラム及び車両を提供する。
【課題を解決するための手段】
【0006】
本発明による精算システムは、
運送サービスに関する取引情報を出力する管理端末と、
前記取引情報を取得したユーザ端末からユーザ情報及び前記取引情報を取得し、前記ユーザ情報と紐づけ可能な運賃情報を運賃測定手段から取得するホスト端末と、
を備えてもよい。
【0007】
本発明による精算システムにおいて、
前記運賃測定手段は運賃メータであり、
前記管理端末は、前記運賃メータから前記運賃情報を取得し、前記運賃情報及び前記取引情報を前記ホスト端末に出力してもよい。
【0008】
本発明による精算システムにおいて、
前記管理端末は、前記取引情報を表示する管理表示部を有し、
前記ホスト端末は、前記管理表示部に表示された前記取引情報を読み取った前記ユーザ端末から前記取引情報を取得してもよい。
【0009】
本発明による精算システムにおいて、
前記管理表示部は前記取引情報をQRコードとして表示し、
前記ホスト端末は、前記QRコードを読み取った前記ユーザ端末から前記取引情報を取得してもよい。
【0010】
本発明による精算システムにおいて、
前記管理端末は、前記運送サービスを提供する前又は提供中に前記取引情報を出力してもよい。
【0011】
本発明による精算システムにおいて、
前記ホスト端末は、前記運送サービスを提供する前又は提供中に前記ユーザ端末から前記取引情報及び前記ユーザ情報を取得してもよい。
【0012】
本発明による精算システムにおいて、
前記運賃測定手段は運賃メータであり、
前記管理端末は、前記取引情報を出力する第一管理端末と、前記運賃メータから前記運賃情報を取得し、前記運賃情報を前記ホスト端末に出力する第二管理端末とを有してもよい。
【0013】
本発明による精算システムにおいて、
前記管理端末は、前記ホスト端末より配車情報を取得してもよい。
【0014】
本発明による精算システムにおいて、
前記ホスト端末は、ユーザ端末から取得した位置情報に基づき、所定の管理端末に配車指示を出力してもよい。
【0015】
本発明による精算システムは、
精算指示を入力するための精算入力部をさらに備え、
前記精算入力部から精算指示が入力されると、前記ホスト端末が前記運賃情報を取得してもよい。
【0016】
本発明によるホスト端末は、
ユーザ端末で取得された、管理端末から出力された運送サービスに関する取引情報及びユーザ情報を記憶するホスト記憶部と、
運賃測定手段で測定された運賃情報を前記ユーザ情報と紐づけて前記ホスト記憶部で記憶させるホスト制御部と、
を備えてもよい。
【0017】
本発明による精算方法は、
管理端末によって、運送サービスに関する取引情報を出力する工程と、
ユーザ端末によって、ユーザ情報及び前記取引情報をホスト端末に出力する工程と、
運賃測定手段によって測定された運賃情報を前記ユーザ情報と紐づけて前記ホスト端末が記憶する工程と、
を備えてもよい。
【0018】
本発明によるプログラムは、
ホスト端末によって精算方法を実行させるプログラムであって、
前記ホスト端末は、
ユーザ端末で取得された、管理端末から出力された運送サービスに関する取引情報及びユーザ情報を記憶する工程と、
運賃測定手段で測定された運賃情報を前記ユーザ情報と紐づけて記憶する工程と、
を含む精算方法を実行してもよい。
【0019】
本発明によるプログラムは、
ユーザ端末によって精算方法を実行させるプログラムであって、
前記ユーザ端末は、
管理端末から出力された運送サービスに関する取引情報を取得する工程と、
前記取引情報と、運賃測定手段で測定された運賃情報と紐づけて前記ホスト端末で記憶されることになるユーザ情報をホスト端末に出力する工程と、
を含む精算方法を実行してもよい。
【0020】
本発明による車両は、
運送サービスに関する取引情報を出力する管理端末を備え、
前記取引情報を取得したユーザ端末からユーザ情報及び前記取引情報を取得し、かつ前記ユーザ情報と紐づけ可能な運賃情報を運賃測定手段から取得するホスト端末と、前記管理端末が通信可能となってもよい。
【0021】
本発明による精算システムは、
ユーザを識別するための個人識別情報を入力可能な管理端末と、
前記個人識別情報に基づくユーザ情報を前記管理端末から取得し、前記ユーザ情報と紐づけ可能な運賃情報を運賃測定手段から取得するホスト端末と、
を備えてもよい。
【0022】
本発明による精算システムにおいて、
前記管理端末は、運送サービスに関する取引情報を出力してもよい。
【0023】
本発明による精算システムにおいて、
前記個人識別情報は生体情報を含んでもよい。
【発明の効果】
【0024】
本発明の一態様によれば、到着地に着くまでの間に取引情報及びユーザ情報を取得し、到着地に着くことで判明する運賃情報を既に取得しているユーザ情報と紐づけることができる。このため、運送サービスを受けたユーザが迅速に運賃の支払いを完了させることができ、従前のように電子マネーやクレジットカード等で決済する機器が迅速に稼働されない場合や運転手がこれらの機器の利用方法になれていない場合に、決済処理を行うためにかなりの時間がかかってしまうということもない。
【発明を実施するための形態】
【0026】
第1の実施の形態
《構成》
以下、本発明に係る精算システムの実施の形態について、図面を参照して説明する。本実施の形態において「又は」は「及び」の意味も含んでいる。つまり、本実施の形態においてA又はBとは、A、B並びにA及びBのいずれかを意味している。
【0027】
本実施の形態の精算システムは、例えばタクシー1の精算に関するものである。以下では、一例としてタクシー1の利用態様を用いて説明するが、運賃情報を利用する形態であれば、これに限られることはない。
【0028】
図1に示すように、本実施の形態の精算システムは、運賃情報を測定する運賃メータ20と、運賃メータ20とインターフェースボックス30を介して無線又は有線で接続され、運送サービスに関する取引情報を出力する管理端末10と、取引情報を取得したユーザ端末200からユーザ情報及び取引情報を受信した後で、ユーザ情報と紐づけ可能な運賃情報を取得するサーバ等のホスト端末100と、を有してもよい。
【0029】
本実施の形態における「接続」には、特に断りがない限り、有線の場合と無線の場合の両方が含まれている。本実施の形態にける「出力」には、取引情報を画面で表示させる態様、取引情報を送信する態様等が含まれている。なお、ユーザ端末200及びホスト端末100の各々は情報処理装置の一種であるし、通信端末の一種でもある。本実施の形態では、運賃メータ20を利用する態様で説明するが、これに限られることはなく、例えば運転手が所持するスマートフォン、タブレット等の通信端末又は後述する運転手端末45によって運賃情報が測定されてもよいし、タクシーの位置情報と乗車時間に関する情報からホスト端末100で運賃情報が測定されてもよい。なお、本実施の形態では、運賃メータ20、運賃情報を測定するための通信端末、タクシーの位置情報を取得するためのGPS等の運賃情報を測定するためのあらゆる手段を「運賃測定手段」と呼ぶ。ホスト端末100は、運賃測定手段から運賃情報を直接取得してもよいが、管理端末10やユーザ端末200等のその他の端末を介して運賃測定手段から運賃情報を取得してもよく、本実施の形態において「運賃情報を運賃測定手段から取得する」態様には、これらの両態様が含まれている。
【0030】
ユーザ情報と運賃情報とを紐づけるために、例えば取引情報を用いてもよい。つまり、運賃情報がホスト端末100に送信される際には取引情報もホスト端末100に送信されてもよく、後述するホスト制御部110が取引情報をキー情報として用いてユーザ情報と運賃情報とを紐づけてもよい。また、管理端末10が決済処理終了までユーザ情報を記憶しておき、運賃が確定した時点で運賃情報とユーザ情報を紐づけてホスト端末100に送信し、当該情報が後述するホスト記憶部120で記憶されてもよい。
【0031】
本実施の形態のホスト端末100は一台の装置から構成されてもよいが、複数の装置から構成されてもよい。ホスト端末100が複数の装置から構成される場合には、ホスト端末100を構成する装置は異なる部屋又は異なる場所に設置されてもよく、ホスト端末100の一部とホスト端末100の残部が遠隔地に配置されてもよい。
【0032】
本実施の形態のホスト端末100は、複数の管理端末10と通信可能になってもよい(
図2参照)。管理端末10の場所は限定されず、日本国内のいずれの場所であってもよいし、世界中のいずれの場所であってもよい。管理端末10はタクシー1内に設置され、例えば助手席の頭部後方側に設置されてもよい。このような場所に設置されることで、後部座席に乗車したユーザは管理端末10の後述する管理表示部12を容易に確認し、必要に応じて管理端末10を容易に操作できるようになる。
【0033】
管理端末10は、運賃情報をホスト端末100に送信するために用いられてもよい。
図1に示すように、管理端末10は、管理端末10に含まれる電子部品等を制御する管理制御部11と、取引情報等の様々な情報を表示する管理表示部12とを有してもよい。ホスト端末100は、様々な情報を記憶するホスト記憶部120と、ホスト端末100に含まれる電子部品等を制御するホスト制御部110とを有してもよい。
【0034】
図1に示すように、運賃メータ20は運賃測定開始部の一例である運賃測定開始ボタン21を有してもよく、運賃測定開始ボタン21を運転手が押下することで運賃メータ20による運賃測定が開始されてもよい。また、運賃測定開始ボタン21が押下されることで当該運送サービスに関する取引情報が決定されてもよい。ナビゲーションシステム40が設けられてもよく、ナビゲーションシステム40はインターフェースボックス30と接続されてもよい。また、運転手が操作する運転手端末45が設けられてもよく、運転手端末45はインターフェースボックス30と接続されてもよい。なお、運転手端末45がナビゲーションシステム40に組み込まれていてもよく、この場合には、ナビゲーションシステム40が運転手端末による機能を兼ねて行う。
【0035】
図1に示すように、運賃メータ20は精算入力部の一例である精算ボタン22を有してもよい。精算ボタン22が押下されることで、管理端末10は運賃情報と後述する降車情報をホスト端末100に送信してもよい。精算ボタン22が押下された場合等に、運賃メータ20には運賃を記載したレシートを印刷する印刷部29が接続されてもよい。
【0036】
管理端末10は、運賃メータ20から運賃情報を取得し、運賃情報を取引情報とともにホスト端末100に送信してもよい。この態様では、ホスト端末100は運賃情報を管理端末10から受信することになる。このような態様に限られることはなく、例えば運賃情報が後述する管理表示部12に表示され、管理表示部12に表示された運賃情報をユーザ端末200が読み取ることで、ユーザ端末200からホスト端末100に運賃情報が送信されてもよい。
【0037】
本実施の形態で用いられる運賃メータ20は、走行距離、走行時間等から算出される運賃情報等を測定するためのものであり、一般的なタクシー1に設置されているものであってもよい。
【0038】
取引情報は、車両情報及び営業情報を含んでもよい。この場合、取引情報は、営業番号等の個別取引番号、車両無線番号、乗車日時、乗車場所、会社ID等の会社識別情報等を含んでもよい。取引情報はトークンであってもよい。取引情報としてトークンが利用される場合には、トークンを取得することで、当該トークンに紐づいたトークン以外の取引情報を取得するようにしてもよい。本願における「取引情報」は取引を特定できる、運賃情報及びユーザ情報以外のあらゆる情報を含んでいる。このため、前述した「トークン」も本願の「取引情報」に含まれることには留意が必要である。取引情報とユーザ情報が紐づき、かつ、取引情報と運賃情報が紐づくことで、ユーザ情報と運賃情報とが紐づいてもよい。
【0039】
管理端末10は、降車日時又は降車場所を含む降車情報を取得可能となっており、当該降車情報をホスト端末100に送信できるようになってもよい。
【0040】
取引情報が乗車日時又は乗車場所を含む場合には、乗車日時又は乗車場所を含む取引情報を管理端末10が出力し、出力された取引情報がユーザ端末200を介してホスト端末100に送信されてもよい。乗車日時及び降車日時又は乗車場所及び降車場所がホスト記憶部120で記憶される場合には、乗車日時と降車日時とが紐づけられ、乗車場所と降車場所とが紐づけられてもよい。また、これら乗車日時、降車日時、乗車場所及び降車場所がユーザ情報と紐づけられて記憶されてもよい。このような態様を採用した場合には、ユーザ毎の乗車日時及び乗車場所並びに降車日時及び降車場所を例えばホスト端末100で記憶し、管理することができる。
【0041】
本実施の形態の管理端末10は、例えばタッチパネル式のタブレット端末であってもよい。ユーザ端末200は、例えばスマートフォンやタブレット等の携帯端末であってもよい。運賃メータ20と管理端末10とはシリアル通信ケーブル等で有線接続されてもよいし、Bluetooth(登録商標)やLTE等によって無線接続されてもよい。無線接続を採用した場合には管理端末10の配置位置を適宜選択でき、また見た目上もよい点で有益である。他方、有線接続を採用した場合には通信の確実性を実現できる点で有益である。
【0042】
ホスト端末100は、管理表示部12に表示された取引情報を読み取ったユーザ端末200からユーザ情報及び取引情報を受信してもよい。ホスト端末100にユーザ端末200から予め入力されて記憶されるユーザ情報は、ユーザ識別番号又はユーザ識別記号等のユーザ識別情報、ユーザの氏名、電話番号、メールアドレス、性別、年齢等の個人識別情報と、クレジットカードのカード番号、有効期限、デビットカードのカード番号、引き落とし口座情報等の決済手段情報とを含んでもよい。取引情報を読み取ったユーザ端末200から送信されるユーザ情報はユーザ識別情報だけを含み、ユーザ識別情報を用いて、取引情報とホスト端末100に記憶されているユーザ情報に含まれるその他の情報とが紐づけられてもよい。なお、クレジットカードのカード番号としてはスマートフォンに登録されている情報又はスマートフォンに紐づけて登録されている情報を利用してもよい。
【0043】
ユーザの各々に割り振られた固有のパスワードを管理端末10に入力したり、ユーザに帰属する固有の情報を管理端末10に入力することでユーザ情報が取得されてもよい。これら固有のパスワード及びユーザに帰属する固有の情報の各々は個人識別情報に含まれている。このような個人識別情報に基づくユーザ情報はホスト端末100に送信されてもよい。本実施の形態における「個人識別情報に基づくユーザ情報」は、個人識別情報と関連付けられた個人識別情報以外のユーザ情報であってもよいし、個人識別情報そのものであってもよい。このような個人識別情報が管理端末10から取得される態様を採用した場合には、ユーザによって行われる作業を簡易なものにすることができ、ひいては、多くのユーザに利用されうるサービスとなり得る点で有益である。
【0044】
前述したユーザに帰属する固有の情報には、指紋、虹彩等の生体情報が含まれている。このように生体情報を利用する場合には、管理端末10は生体情報が入力可能な構成となっており、例えば管理端末10は指紋を読み取り可能となったり虹彩を読み取り可能となっている。このように生体情報入力する場合には、ユーザはユーザ端末200を用いることなく生体情報によってユーザ情報を提供することができることから、例えばユーザは手ぶらでタクシーに乗車することができる点で有益である。なお、このような生体情報を管理端末10から入力する場合には、生体情報に加えてパスワードも管理端末10に入力するようにしてもよい。また、生体情報を利用する場合には、ユーザの生体情報がホスト記憶部120で記憶されており、ホスト記憶部120で記憶された生体情報と管理端末10から入力された生体情報とを照合することで、どのユーザがタクシーに乗車したかを判断するようにしてもよい。
【0045】
個人識別情報が管理端末10で取得される場合には、取引情報がホスト端末100に送信されてもよいし、取引情報がホスト端末100に送信されなくてもよい。取引情報がホスト端末100に送信されない態様としては、例えば、管理端末10から入力されたユーザ識別情報等のユーザ情報が決済完了まで管理端末10で記憶され、運賃が確定した時点で、ユーザ情報と運賃情報とが紐づけられてホスト端末100に送信されてもよい。また、ユーザ情報が管理端末10で入力されると、当該ユーザ情報がホスト端末100に送信され、運送サービスを提供している間に当該ユーザに対する与信審査が行われてもよい。また、ユーザ情報と取引情報が管理端末10からホスト端末100に送信される態様では、前述したように、取引情報をキー情報として用いてユーザ情報と運賃情報とを紐づけてもよい。
【0046】
ホスト制御部110は、運送サービスの提供が終了した後で運賃情報を受け取ると、取引情報によって運賃情報と関連付けられたユーザ情報を用いて、運賃情報に基づく運賃の支払いをクレジットカード発行会社等の決済代行会社又は銀行もしくは郵便局等の金融機関に要求してもよい。ホスト制御部110が決済代行会社による代金の支払い又は金融機関の口座からの代金の引き落としを確認すると、ホスト制御部110は決済処理が完了したと判断し、決済完了データをユーザ端末200又は管理端末10に送信してもよい(
図5参照)。管理端末10が決済完了データを受信すると、管理表示部12で決済が完了したことが表示されてもよい。ユーザ端末200に決済完了データが送信される場合には、当該決済完了データは領収書の形式となっていてもよく、日付、時間、金額等の情報が含まれてもよい。また、ユーザ端末200に決済完了データが送信される場合には、ユーザ端末200のユーザ表示部220で決済が完了したことが表示されてもよい。
【0047】
決済に関する情報はホスト記憶部120で記憶され、ユーザ端末200から適宜読み出すことができるようになってもよい。このような態様を採用した場合には、ユーザは過去の利用履歴を容易に確認することができる点で有益である。
【0048】
管理表示部12は取引情報をQRコード(登録商標)として表示してもよい(
図3参照)。この態様では、ユーザ端末200がQRコードを読み取り、ユーザ端末200からホスト端末100に対してユーザ情報と取引情報が送信されてもよい。ホスト端末100は、ユーザ情報と取引情報を受け取るとユーザ情報と取引情報とを紐づけてホスト記憶部120で記憶してもよい。また、ホスト端末100でユーザ情報と取引情報とが紐づけられる必要はなく、ユーザ端末200でユーザ情報と取引情報とが紐づけられ、当該情報がホスト記憶部120で記憶されてもよい。
【0049】
取引情報としてランダムな番号、記号等からなるトークンに基づいてQRコードを生成してもよい。そして、ユーザ端末200がQRコードを読み取ることで、トークン及びトークンの有効期限が読み取られてもよい。トークンが読み取られることで、トークンと紐づいた注文ID、ユーザ確認番号、会社ID、車両無線番号、営業番号等がホスト端末100で生成又は復元されてもよい。
【0050】
QRコードが用いられる必要はなく、例えば、ランダムな番号を管理表示部12が表示し、当該番号をユーザ端末200で入力することで、ユーザ情報及び取引情報がホスト端末100に送信されるようにしてもよいし、Bluetooth等で管理端末10からユーザ端末200に取引情報が送信され、当該取引情報を取得したユーザ端末200からユーザ情報及び取引情報がホスト端末100に送信されるようにしてもよい。
【0051】
ユーザ端末200に専用のアプリがインストールされ、当該アプリが起動されることで管理端末10から出力される情報を処理できるようになってもよい。より具体的な例としては、ユーザ端末200に専用のアプリがインストールされることで、管理表示部12に表示されるQRコード等が読み取り可能となり、またQRコード等の読み取られた情報とユーザ情報とがホスト端末100に送信可能となってもよい。
【0052】
管理端末10が運賃メータ20から運賃情報を取得して当該運賃情報をホスト端末100に送信する態様を採用する場合には、管理端末10は運賃情報を取引情報とともにホスト端末100に送信してもよい。この場合には、ホスト制御部110は取引情報を用いてユーザ情報と運賃情報とを紐づけ、ホスト記憶部120がユーザ情報と運賃情報とを紐づけて記憶してもよい。この場合には、ユーザ情報、取引情報及び運賃情報が表データとしてホスト記憶部120に記憶されてもよい。このような表データが記憶されている場合には、管理や確認等が容易になる点で有益である。なお、運賃情報とともに送信される取引情報には、個別取引番号や車両無線番号等の取引識別情報だけが含まれてもよい。この場合には、取引識別情報を用いて、運賃情報とホスト端末100に記憶されている取引情報に含まれるその他の情報とが紐づけられてもよい。
【0053】
ホスト記憶部120に記憶されたユーザ情報、取引情報及び運賃情報は、ユーザ情報と紐づいたユーザ端末200や、その他の携帯端末、パソコン等によって表示可能となってもよい。この場合には、ユーザからの要求に応じて、ホスト制御部110が運賃情報をユーザ端末200等に送信してもよい。なおこの態様では、ユーザ端末200から当該ユーザに関する情報にアクセスする際にはパスワード等が要求されず、他方、ユーザ端末200以外の端末から当該ユーザに関する情報にアクセスする際にはパスワードが要求されるようにしてもよい。
【0054】
管理端末10は、運送サービスを提供する前又は提供中に取引情報を出力してもよい。ホスト端末100は、運送サービスを提供する前又は提供中にユーザ端末200から取引情報及びユーザ情報を取得してもよい。乗車したユーザのユーザ情報が予めわかっている場合等では(後述する第2の実施の形態参照)、管理端末10から取引情報がホスト端末100に送信され、ホスト端末100が当該取引情報をユーザ情報と紐づけて記憶してもよい。
【0055】
精算ボタン22が押下されることで管理端末10に精算指示が入力されてもよい。精算指示が入力されると、管理端末10は最終的な運賃情報をホスト端末100に送信してもよい。但し、このような態様に限られることはなく、管理端末10は運賃メータ20から随時運賃情報を取得し、当該運賃情報をホスト端末100に送信してもよい。この場合には、ホスト端末100によって運賃情報を継続的に管理することができるようになる。
【0056】
管理表示部12は、利用料金を表示してもよい。利用料金は、運送サービスを提供している間に継続的に表示されてもよいし、利用料金の値段が上がったときに表示されてもよいし、精算ボタン22が押下されて運送サービスの提供が終了したときにだけ表示されてもよい。管理表示部12は、現在の位置情報、予想到着時間等を表示してもよいし、ナビゲーションシステム40から取得される情報をそのまま表示してもよい。
【0057】
管理表示部12に表示される文字情報の言語を選択可能となってもよい。管理端末10がタッチパネル式である場合には、画面に表示された選択ボタンを押下することで日本語、英語、中国語、韓国語等の各種の言語を選択できるようになってもよい。言語は、ユーザ情報に基づいて適宜選択されてもよい。一例としては、ユーザ端末200にインストールされている専用アプリの言語に合わせた表示が管理端末10で行われてもよい。この場合には、ユーザ端末200から取引情報及びユーザ情報がホスト端末100に送信された後、ホスト端末100から管理端末10にユーザ情報が送信され、当該ユーザ情報に基づいて管理表示部12で表示される言語が選択されてもよい。
【0058】
《作用・効果》
次に、上述した構成からなる本実施の形態による作用・効果であって、未だ説明していないものを中心に説明する。なお、「作用・効果」で述べるあらゆる構成は、本実施の形態の構成として利用することができる。
【0059】
本実施の形態において、ホスト端末100が、取引情報を取得したユーザ端末200からユーザ情報及び取引情報を取得した後で、ユーザ情報と紐づけ可能な運賃情報を取得する態様を採用した場合には、ユーザが運賃を決済する際の待ち時間を短くすることができる点で有益である。特に運送サービスを提供する前又は提供中に管理端末10が取引情報を出力する態様を採用し、ホスト端末100でのユーザ情報及び取引情報の取得が運送サービスの提供が完了する前に終了している場合には、ホスト端末100が最終的な運賃情報を取得するだけで運送サービスに対する決済処理が完了することから、ユーザの待ち時間を格段に短くすることができる。
【0060】
この点、タクシーに乗車した時点で例えばクレジットカードの読み取りだけを先に行うことも考えられる。しかしながら、クレジットカードの読み取り(認証)を行う場合には、ユーザ自身がクレジットカードの読み取りを行わなければならず、そのような作業になれていないユーザでは利用されにくい点で導入が難しいサービスである。また、タクシーの運転手がクレジットカードの読み取りを行うことも考えられるが、この場合にはカードの読み取り作業中は運転手がタクシーを運転することができず、結局、目的地に着くまでの時間がかかってしまう。これに対して、本実施の形態のように管理端末10から出力される取引情報をユーザ端末200が取得する場合には、ユーザ端末200が取引情報を取得するだけでよく、ユーザによって行われる作業を簡易なものにすることができる。このため、多くのユーザに利用されうるサービスとなり得る点で有益である。
【0061】
また、ユーザ端末200が取引情報を取得する態様を採用した場合には、ユーザ情報と取引情報とを確実に紐づけすることができる点で有益である。つまり、ユーザ端末200にアプリがインストールされており、当該アプリを用いて取引情報を取得することで、取引情報とユーザ情報とを確実に紐づけしたうえで、ホスト端末100にこれらの情報を送信できる点で有益である。
【0062】
管理端末10が運賃メータ20から運賃情報を取得し、運賃情報及び取引情報をホスト端末100に出力する態様を採用した場合には、運賃が確定した時点で管理端末10からホスト端末100に送信される運賃情報を取引情報と確実に紐づけしたうえで、ホスト端末100にこれらの情報を送信できる点で有益である。
【0063】
図3に示すように、ユーザ端末200が管理表示部12に表示された取引情報を読み取り、ユーザ端末200からホスト端末100にユーザ情報及び取引情報が送信される態様を採用した場合には、ユーザは管理表示部12に表示された情報を読み取るだけでよい。また、管理表示部12に表示された画面をユーザ端末200で読み取るという作業はユーザには分かりやすい作業であり、本実施の形態によって提供されるサービスの利用頻度を高めることが期待できる。
【0064】
また、クレジットカードのカード番号、有効期限、デビットカードのカード番号、引き落とし口座情報等の決済手段情報がホスト端末100で記憶されている場合には、タクシー会社としては運賃の未回収が生じる危険を防止できる点でも有益である。
【0065】
ユーザ端末200は、ホスト記憶部120で記憶された情報に基づき、PDF形式等によって領収書を発行できるようになってもよい。このような態様を採用した場合には、印刷された領収書がタクシー1内で発行されないようにしてもよい。また、印刷された領収書の要否をユーザ端末200又は管理端末10から入力できるようになってもよく、印刷された領収書が必要な場合にだけ、印刷部29で領収書が印刷されるようになってもよい。このような態様によれば、ユーザが印刷された領収書が不要である場合には、領収書の印刷を待つことなく降車することができ、より利便性を高めることができる。
【0066】
また、印刷された領収書が不要である場合には、決済処理が完了した時点又はそれ以降に、事前に登録したユーザのメールアドレスを用いてユーザ端末200にPDF等の形式で領収書が送信されてもよい。また、ユーザ端末200がホスト端末100にアクセスすることでPDF等の形式の領収書を取得できるようにしてもよい。さらに、決済処理が完了した時点でユーザ端末200に領収書が送信される態様を採用してもよい。この場合には、ユーザは領収書のメールによる受領を確認した後で降車することができる点で有益である。
【0067】
ホスト記憶部120にユーザ毎の乗車情報及び降車情報が記憶されている場合には、ホスト記憶部120でユーザ毎の乗車日時及び乗車場所並びに降車日時及び降車場所を記憶することができる。このため、タクシー運転手による日報の記載が不要になる点で有益であるし、タクシー会社は正確な情報を取得できる点で有益である。
【0068】
またホスト記憶部120に乗車情報及び降車情報が記憶されている場合には、ユーザ毎の利用状況を記憶し管理することができる。このため、例えばユーザが「会社」、「自宅」等の一定程度の頻度で訪れる場所等の過去に利用したことのある指定場所(行先)をユーザ端末200、管理端末10等で指定するだけで、当該場所までの案内がナビゲーションシステム40で行われるようにしてもよい。このような指定場所は過去利用場所である必要はなく、ユーザによって新たに登録されてもよい。また、指定場所の登録は、ユーザがタクシー1の配車を依頼する際にユーザ端末200から行われてもよいし、ユーザがタクシー1に乗車した後でユーザ端末200、管理端末10等から行われてもよい。
【0069】
《方法》
本実施の形態による精算システムの処理態様の一例について説明する。
【0070】
ユーザがタクシー1に乗車すると、タクシー1の運転手が運賃測定開始ボタン21を押下する。このように運賃測定開始ボタン21を運転手が押下することで運賃メータ20による運賃測定が開始され、また取引情報が決定される。
【0071】
本実施の形態による精算システムによる処理を希望するユーザは、助手席の頭部後方側に設置された管理端末10の管理表示部12をタップする。ユーザがこのように管理表示部12をタップすることで管理表示部12に取引情報が例えばQRコードで表示される(
図3及び
図6のS11参照)。なお、取引情報は、運賃測定開始ボタン21が押下されるときではなく、ユーザが管理表示部12にタップする等、管理端末10による処理が開始されるタイミングで決定されてもよい。
【0072】
ユーザは自己の所有するスマートフォンやタブレット等のユーザ端末200にインストールされたアプリを起動して、管理表示部12に表示されたQRコードを読み取る(
図3及び
図6のS12参照)。このようにQRコードを読み取ることで、取引情報及びユーザ情報がホスト端末100に例えばLTEを介して送信される(
図3及び
図6のS13参照)。ユーザによるこれらの作業は運送サービスが提供されている間になされてもよい。
【0073】
取引情報及びユーザ情報を受信したホスト端末100は、これら取引情報及びユーザ情報をホスト記憶部120に記憶する(
図3参照)。
【0074】
ユーザが到着地に着くと、運転手が精算ボタン22を押下する。このように精算ボタン22が押下されると、管理端末10は、取引情報、運賃情報及び降車情報をホスト端末100に送信する(
図4及び
図6のS31参照)。この際、印刷部29は運賃を記載したレシートを印刷してもよい。
【0075】
取引情報、運賃情報及び降車情報をホスト端末100が受信すると、ホスト制御部110は、取引情報の一部又は全部をキー情報として、ホスト記憶部120に記憶されているユーザ情報と運賃情報及び降車情報とを関連付け、ホスト記憶部120でこれらの情報を記憶させる(
図4参照)。
【0076】
運賃情報を受け取ったホスト制御部110は、ユーザ情報を用いて運賃情報に基づく運賃の支払いをクレジットカード発行会社等の決済代行会社に要求するか、又はユーザの口座からの引き落としを金融機関に要求し、決済代行会社による運賃の支払い又は金融機関の口座からの運賃の引き落としが確認できると決済処理が完了する(
図4及び
図6のS32参照)。このように決済処理が完了すると、ホスト制御部110は、決済完了データを管理端末10及びユーザ端末200に送信する(
図5及び
図6のS33参照)。決済完了データを受信した管理端末10の管理表示部12及びユーザ端末200のユーザ表示部220の各々に、決済が完了したことが表示されてもよい(
図5参照)。
【0077】
別の方法としては、以下のような方法を用いることもできる。
【0078】
ユーザがタクシー1に乗車すると、タクシー1の運転手が運賃測定開始ボタン21を押下する(
図1参照)。このように運賃測定開始ボタン21を運転手が押下することで運賃メータ20による運賃測定が開始される。この際、乗車時刻、乗車場所、車両無線番号、営業番号、会社ID等の車両情報及び営業情報が運転手端末45からホスト端末100に送信され(
図14のS100参照)、ホスト端末100から管理端末10にこれらの情報が送信されてもよい(
図14のS101参照)。
【0079】
ユーザが管理端末10の管理表示部12をタップすることで、管理端末10は、これら乗車時刻、乗車場所、車両無線番号、営業番号、会社ID等の車両情報及び営業情報と紐づいたトークンの生成をホスト端末100に依頼し(
図14のS110参照)、ホスト端末100がトークン、トークン有効期限及び会社IDを管理端末10に送信してもよい(
図14のS111参照)。
【0080】
管理端末10がトークン、トークン有効期限及び会社IDを受信すると、管理端末10がトークンを用いてQRコードを生成し、当該QRコードが管理表示部12で表示されてもよい。このようなトークンを用いることでQRコードの生成を簡易なものにすることができる点で有益である。
【0081】
管理表示部12で表示されたQRコードをユーザ端末200が読み取ると、ユーザ端末200からトークン及びトークン有効期限とユーザ情報とがホスト端末100に送信されてもよい(
図14のS120)。
【0082】
ホスト端末100がトークン及びトークン有効期限とユーザ情報とを受信すると、例えばトークン及びユーザ情報を用いて、ホスト端末100が注文ID、ユーザ確認番号、会社ID、無線番号、営業番号等を生成又は復元してもよい。このようにして生成又は復元された注文ID、ユーザ確認番号、会社ID、無線番号、営業番号がホスト端末100から運転手端末45に対して送信され、運転手端末45による承認を要求してもよい(
図14のS121)。なお、このように承認を要求する際には、ユーザに対する与信審査が済んでおり、ユーザ端末200にインストールされたアプリを利用して決済できることがホスト端末100で確認されていてもよい。トークン及びユーザ情報を用いて、ホスト端末100が注文ID、ユーザ確認番号、会社ID、無線番号、営業番号等を生成又は復元する態様としては、ホスト制御部110が、トークンと紐づいた会社ID、無線番号、営業番号等をホスト記憶部120から読み出し、これらの情報とユーザ情報に含まれるユーザ確認番号とを紐づけて、紐づけられた情報に対して注文IDが割り振られてもよい。
【0083】
運転手端末45によって承認が行われると、承認が行われたことがホスト端末100に送信されてもよい(
図14のS122)。その後、承認が行われたことがホスト端末100から管理端末10に送信され(
図14のS123)、管理表示部12にその旨が表示されてもよい。また、このように運転手端末45によって承認が行われると、承認が行われたことがホスト端末100からユーザ端末200に送信され(
図14のS124)、ユーザ表示部220にその旨が表示されてもよい。なお、このように運転手端末45によって承認を行う態様を採用した場合には、運転手はユーザに対して運賃を請求することなくユーザを降車させてよいかを事前に確認できる点で有益である。
【0084】
以上の通信及び制御はユーザにタクシーによる運送サービスが提供されている間になされてもよい。
【0085】
ユーザが到着地に着くと、運転手が精算ボタン22を押下する。このように精算ボタン22が押下されると、精算ボタン22が押下されたことが運転手端末45に送信され(
図14のS130)、運転手端末45に決済実行を承認するための表示がなされてもよい。そして、運転手が運転手端末45を操作して決済実行を承認すると決済が実行され、ホスト端末100に注文IDが送信され(
図14のS131)、当該注文IDについての決済が完了したことがホスト端末100で記憶されてもよい。このような態様を採用した場合には、運転手が決済処理が行われたことをより確実に認識でき、ひいては、運転手がユーザに運賃請求をしなくてもよいことをより確実に認識できる点で有益である。
【0086】
第2の実施の形態
次に、本発明の第2の実施の形態について説明する。
【0087】
第1の実施の形態では、一つの管理端末10が、取引情報を出力し、かつ、運賃メータ20から運賃情報を取得して運賃情報をホスト端末100に送信する態様となっていたが、第2の実施の形態では、管理端末10が、取引情報を出力する第一管理端末50と、運賃メータ20から運賃情報を取得し、運賃情報をホスト端末100に送信する第二管理端末55とを有している態様となっている。第一管理端末50は、第一管理端末50に含まれる電子部品等を制御する第一管理制御部51と、取引情報等の様々な情報を表示する第一管理表示部52とを有してもよい。第二管理端末55は、第二管理端末55に含まれる電子部品等を制御する第二管理制御部56と、第二管理端末55がナビゲーションシステムを兼ねている場合には位置情報や目的地情報等の様々な情報を表示する第二管理表示部57とを有してもよい。また、第二管理端末55は第1の実施の形態の運転手端末45を兼ねてもよい。本実施の形態では、第二管理端末55がナビゲーションシステム及び運転手端末の機能を兼ねている態様を用いて説明する。
【0088】
第2の実施の形態において、その他の構成は、第1の実施の形態と略同一の態様となっている。第1の実施の形態と同様の内容については説明を省略する。
【0089】
本実施の形態で用いられる第一管理端末50は、例えばタッチパネル式のタブレット端末であってもよい。第二管理端末55は、配車情報等も受信する配車管理端末であってもよい。第二管理端末55が配車管理端末から構成される場合には、第二管理端末55はホスト端末100より配車情報を取得することになる。一般に配車管理端末は運賃メータ20とシリアル通信ケーブル等の有線接続されていることが多いことから、第二管理端末55として配車管理端末を採用した場合には、第二管理端末55と運賃メータ20とをBluetooth等で接続した場合と比較して、通信の確実性を担保できる点で有益である。また、一般に配車管理端末はユーザの乗車位置から遠くに配置されることから、運賃メータ20と第二管理端末55とを有線接続することで見た目が悪くなることも防止できる。
【0090】
ホスト端末100は、ユーザ端末200から取得した位置情報又はユーザ端末200から入力されたピックアップ希望位置情報に基づき、所定の第二管理端末55に配車指示を出力してもよい。所定の第二管理端末55はホスト制御部110で適宜選択されてもよく、例えば空車となっているタクシー1のうち位置情報から最も近いタクシー1又は最も早い時間にユーザをピックアップできそうなタクシー1に搭載された第二管理端末55が選択されてもよい(
図2参照)。
【0091】
ホスト端末100から第二管理端末55に配車指示が送信され、運転手が当該配車指示を受けられることを返信すると、ユーザ端末200の位置情報又はユーザ端末200から入力されたピックアップ希望位置までのルートがタクシー1内に設置されたナビゲーションシステムに表示され、予測到着時間が表示されてもよい。配車管理端末である第二管理端末55はナビゲーションシステムとは別の装置であってもよいし、第二管理端末55はナビゲーションシステムと同じ装置であってもよい。なお、
図7乃至
図12では、第二管理端末55がナビゲーションシステムと同じ装置である態様を用いて説明している。このため、以下では、第二管理端末55がナビゲーションシステム及び配車管理端末を兼ねていることを前提として説明する。
【0092】
予想到着時間が第二管理端末55で計算されると、当該予想到着時間がホスト端末100に送信され、ホスト端末100からユーザ端末200に当該予想到着時間が送信されてもよい。
【0093】
ホスト端末100は人工知能機能を有してもよい。このような人工知能機能を有する場合には、過去の配車実績に基づき空車状態にあるタクシー1のうち最良のタクシー1を選択し、当該タクシー1に搭載されている第二管理端末55に対して配車指示を出してもよい。過去の配車実績は適宜更新され、ホスト端末100は機械的学習を行うことで、空車状態にあるタクシー1のうち最良のタクシー1を選択するようにしてもよい。
【0094】
本実施の形態でも、ユーザ端末200にインストールされている専用アプリの言語に合わせた表示が第一管理表示部52で行われてもよい。この場合にも、ユーザ端末200から取引情報及びユーザ情報がホスト端末100に送信された後、ホスト端末100から第一管理表示部52にユーザ情報が送信され、当該ユーザ情報に基づいて第一管理表示部52で表示される言語が選択されてもよい。また、ユーザ端末200から配車依頼が送信されることでユーザ識別情報がホスト端末100で取得され、当該ユーザ識別情報を含むユーザ情報に基づいて第一管理表示部52で表示される言語が選択されてもよい。
【0095】
《方法》
本実施の形態による精算システムの処理態様の一例について説明する。
【0096】
ユーザがアプリのインストールされたスマートフォンやタブレット等のユーザ端末200から配車を依頼する(
図8及び
図13のS1参照)。
【0097】
配車依頼を受けたホスト端末100は、ユーザ端末200の位置情報又はユーザ端末200から入力されたピックアップ希望位置と、空車状態にあるタクシー1の位置情報とから、最良のタクシー1を選択し、当該タクシー1に搭載されている第二管理端末55に対して配車指示を出す(
図8及び
図13のS2参照)。
【0098】
配車指示を受けた第二管理端末55は当該配車指示を受けられるかを運転手に問い合わせ、運転手が当該配車指示を受けられる旨の入力を行うと、その旨がホスト端末100に送信される(
図9及び
図13のS3参照)。
【0099】
運転手が当該配車指示を受けられることを入力すると、ユーザ端末200の位置情報又はユーザ端末200から入力されたピックアップ希望位置までのルートがタクシー1内に設置されたナビゲーションシステムを兼ねる第二管理端末55の第二管理表示部57に表示され、予測到着時間が表示される。予想到着時間が第二管理端末55で計算されると、当該予想到着時間がホスト端末100に送信され、ホスト端末100からユーザ端末200に当該予想到着時間が送信される。これらの制御をホスト制御部110が自動で行ってもよいが、配車センターの配車担当者がパソコン等の端末を適宜操作することでこれらの入力を行ってもよい。また、予想到着時間はタクシー1に搭載された第二管理端末55ではなく、ホスト端末100に接続され、配車センターに設置された別のナビゲーションシステムで計算されてもよい。
【0100】
配車指示を受けたタクシー1がユーザのもとに到着すると、ユーザはタクシー1に乗車する。ユーザがタクシー1に乗車すると、タクシー1の運転手が運賃測定開始ボタン(運賃測定開始部)21を押下する。このように運賃測定開始ボタン21を運転手が押下することで運賃メータ20による運賃測定が開始され、また取引情報が決定される。この取引情報は、第二管理端末55からホスト端末100に送信され、ホスト端末100から第一管理端末50に送信されるようにしてもよい(
図10参照)。このような態様ではなく、配車指示を受けられる旨、運転手が入力した時点で取引情報が決定されてもよい。また、タクシー1の運転手が運賃測定開始ボタン21を押下することで、配車に係ったルート及び時間に関する情報がホスト端末100に送られ、ホスト記憶部120で記憶されてもよい。このように記憶されたルート及び時間に関する情報は将来的な配車指示のためのデータとして利用されてもよく、ホスト端末100が人工知能機能を有する場合には、教師データとして機械的学習に用いられてもよい。ホスト端末100に送られる情報は、配車に係ったルート及び時間に関する情報に加えて、時間帯、天候等に関する情報も含んでもよい。これらの条件は渋滞状態とも関連する情報であることから、将来的な配車指示を行う際には有益な情報となる。
【0101】
本実施の形態による精算システムによる処理を希望するユーザは、助手席の頭部後方側に設置された管理端末10の管理表示部12をタップする。ユーザがこのように管理表示部12をタップすることで管理表示部12に取引情報が例えばQRコードで表示される(
図10及び
図13のS11参照)。
【0102】
ユーザはユーザ端末200にインストールされており配車依頼でも用いたアプリによって、第一管理端末50の第一管理表示部12に表示されたQRコードを読み取る(
図10及び
図13のS12参照)。このようにQRコードを読み取ることで、取引情報及びユーザ情報がホスト端末100に例えばLTEを介して送信される(
図10及び
図13のS13参照)。ユーザによるこれらの作業は運送サービスが提供されている間になされてもよい。
【0103】
取引情報及びユーザ情報を受信したホスト端末100は、これら取引情報及びユーザ情報をホスト記憶部120に記憶する。
【0104】
ユーザが到着地に着くと、運転手が精算ボタン22を押下する。このように精算ボタン22が押下されると、第二管理端末55は、取引情報、運賃情報及び降車情報をホスト端末100に送信する(
図11及び
図13のS31参照)。この際、印刷部29は運賃を記載したレシートを印刷してもよい。
【0105】
取引情報、運賃情報及び降車情報をホスト端末100が受信すると、ホスト制御部110は、取引情報の一部又は全部をキー情報として、ホスト記憶部120に記憶されているユーザ情報と運賃情報及び降車情報とを関連付け、ホスト記憶部120でこれらの情報を記憶させる(
図11参照)。
【0106】
運賃情報を受け取ったホスト制御部110は、ユーザ情報を用いて運賃情報に基づく運賃の支払いをクレジットカード発行会社等の決済代行会社に要求するか、又はユーザの口座からの引き落としを金融機関に要求し、決済代行会社による運賃の支払い又は金融機関の口座からの運賃の引き落としが確認できると決済処理が完了する(
図11及び
図13のS32参照)。このように決済処理が完了すると、ホスト制御部110は、決済完了データを第一管理端末50及びユーザ端末200に送信する(
図12及び
図13のS33参照)。決済完了データを受信した第一管理端末50の第一管理表示部12及びユーザ端末200のユーザ表示部220の各々に、決済が完了したことが表示されてもよい(
図12参照)。なお、決済完了データは第一管理端末50の代わりに又は第一管理端末50に加えて第二管理端末55に送信されてもよい。決済完了データが第二管理端末55に送信される場合には、第二管理表示部57によって決済が完了したことを知らせる旨のメッセージ等の決済完了情報が表示されてもよい。
【0107】
上述した実施の形態の記載及び図面の開示は、特許請求の範囲に記載された発明を説明するための一例に過ぎず、上述した実施の形態の記載又は図面の開示によって特許請求の範囲に記載された発明が限定されることはない。出願当初の特許請求の範囲の記載は本件特許明細書の範囲内で適宜変更することもでき、その範囲を拡張することもできる。
【0108】
第1の実施の形態の管理端末10もホスト端末100より配車情報を取得する態様となってもよく、第2の実施の形態の第一管理端末50及び第二管理端末55の各々で行われるのと同様の処理が一台の管理端末10で行われるようになってもよい。また、第1の実施の形態のナビゲーションシステム40が
図8及び
図9に示されているような配車情報の取得及び配車可能応答を行い、
図10乃至
図12に示されているような取引情報の取得等の一連の処理は管理端末10によって行われてもよい。また、第1の実施の形態のナビゲーションシステム40及び第2の実施の形態の第二管理端末55が配車管理端末を兼ねる必要はなく、ナビゲーションシステム40及び第二管理端末55とは別に配車管理端末が設けられてもよい。