JP2009276850A - 料金支払いシステム、車両用情報端末、代金支払い方法 - Google Patents

Abstract

【課題】車両に複数の乗員が乗車したまま、その支払いの分担を柔軟に調整できる車両用情報端末等を提供すること。
【解決手段】購入対象物の料金を複数の支払い端末６０又は車両用情報端末１００から集金する料金支払いシステム２００において、購入対象物のメニュー情報を車外端末５００から受信するメニュー情報受信手段２８と、乗員がメニュー情報に基づき注文した注文情報を取得する注文情報取得手段２１と、支払い端末６０の支払い比率を算出するための支払い方法を取得して、支払い方法に基づき支払い決定した支払い比率と、注文情報が含む価格情報に基づき、支払い端末６０毎の個別支払い金額を算出する案分計算手段２６と、個別支払い金額情報を各支払い端末に送信する支払い金額情報送信手段２１と、各支払い端末から取得した個別支払い代金情報を集金して車外端末５００に送信する代金情報送信手段２８と、を有する、ことを特徴とする。
【選択図】図１

Description

本発明は、車両に乗車した複数の乗員の注文に基づき、各乗員の支払い分を一括して支払う料金支払いシステム及び車両用情報端末に関し、特に、割り勘等、支払い比率を調整できる料金支払いシステム、車両用情報端末及び代金支払い方法に関する。

車両に搭載された車両用情報端末を介して乗員が種々のサービスを受ける技術が考えられている（例えば、特許文献１参照。）。特許文献１には、コンテンツサーバから音楽などのコンテンツを送信し、車両用情報端末にてコンテンツを再生するコンテンツ配信システムが記載されている。ユーザの携帯電話には、コンテンツを複合するための暗号キーデータが送信され、ユーザに対し課金される。コンテンツは他の車両で再ダウンロードできるので、携帯電話を携帯していればユーザは他の車両でもコンテンツを再生できる。

また、車両で来店した客に、飲食物を販売する販売形態（ドライブスルー）が知られており、店舗に到着する前に車両から予め注文を店舗に送信しておくことで、客の待ち時間を短縮する注文処理システムが提案されている（例えば、特許文献２参照。）。特許文献２では、車両にＩＤが与えられており車両毎に課金される。

しかしながら、特許文献１記載の課金方法では、ユーザに対し課金されるので、複数の乗員でコンテンツを視聴する場合に割り勘にすることができないという不都合がある。同様に、特許文献２記載の注文処理システムにおいても、複数の乗員が乗車している場合に割り勘することができない。

この点について、車両に複数の乗員が乗車している場合に、高速料金を分割して支払う有料道路料金支払い方法が提案されている（例えば、特許文献３参照。）。高速道路のゲートと所定の乗員の携帯電話とが通信し、分割して支払う乗員の携帯電話番号や支払い比率を、携帯電話がゲートを介してサーバに送信する。したがって、サーバは支払い比率に応じて各乗員から高速料金を集金することができる。
特開２００４−２４０６５５号公報 特開２００６−１６４１８９号公報 特開２００３−１８７２８１号公報

しかしながら、特許文献３記載の有料道路支払い方法では、ゲートと通信する乗員の携帯電話に支払いを分担する乗員の電話番号等を予め設定しておく必要があるため、利便性が低いという問題がある。例えば、ゲートの手前までに電話番号等を入力していないと割り勘にすることができない。

また、例えば、ドライブスルーなどで車両の乗員がそれぞれ注文を出す場合、乗員それぞれがメニューの内容を把握する必要があり、また、乗員毎に異なる料金が課金されることが多い。しかしながら、従来、乗員毎の料金を管理して、割り勘や支払い比率を決定すること、及び、複数の乗員の支払いを店舗側に一括して支払うことは困難であった。

例えば、各乗員のそれぞれ又は一部の者のみが注文し、各乗員全ての支払い金額に対し、乗員のうち一部の者（例えば、両親）が全て支払ったり、両親のうち父と母でさらに支払い比率に応じた支払いをしたい場合があるが、従来、係る考案は提案されていない。また、購入する商品に応じて、注文した乗員に関係なく支払い比率を調整したい場合があるが、係る考案は提案されていない。

本発明は、上記課題に鑑み、車両に複数の乗員が乗車したまま、その支払いの分担を柔軟に調整できる料金支払いシステム、車両用情報端末及び代金支払い方法を提供することを目的とする。

上記課題に鑑み、本発明は、購入対象物の料金を複数の支払い端末又は車両用情報端末から集金する料金支払いシステムにおいて、車両用情報端末は、購入対象物のメニュー情報を車外端末から受信するメニュー情報受信手段と、乗員がメニュー情報に基づき注文した注文情報を取得する注文情報取得手段と、支払い端末の支払い比率を算出するための支払い方法を取得して、支払い方法に基づき決定した支払い比率と、注文情報が含む価格情報に基づき、支払い端末毎の個別支払い金額を算出する案分計算手段と、個別支払い金額情報を各支払い端末に送信する支払い金額情報送信手段と、各支払い端末から取得した個別支払い代金情報を集金して車外端末に送信する代金情報送信手段と、を有する、ことを特徴とする。

本発明によれば、複数の乗員がそれぞれ注文する場合、割り勘や支払い比率を考慮して各乗員の支払額を決定し、一括して店舗に代金を支払うことができる。

車両に複数の乗員が乗車したまま、その支払いの分担を柔軟に調整できる車両用情報端末、料金支払いシステム、を提供することができる。

以下、本発明を実施するための最良の形態について、図面を参照しながら実施例を挙げて説明する。

図１は、本実施形態の料金支払いシステム２００を模式的に説明する図の一例を示す。店舗５００は、車両１１に乗車した乗員に店頭で商品を提供する店頭販売（以下、ドライブスルーという）を行っており、車両１１が図示する経路１３を走行する過程で、注文、支払い、商品の受け取りが完了するようになっている。

経路１３には１以上のアンテナ１２Ａ〜１２Ｃが設けられており、車両１１が経路１３を走行する間、少なくとも１以上のアンテナ１２Ａ〜１２Ｃを介して店舗５００と通信できる。

I．経路１３の進入口で車両１１がアンテナ１２Ａと通信すると、車両１１の車両用情報端末１００には、メニュー情報が送信される。
II．車両用情報端末１００は、受信したメニュー情報を各乗員の携帯端末６０に送信する。なお、携帯端末６０には携帯電話、ＰＨＳ（Personal Handyphone System）、ＰＨＳカードのような通信カードを装着したＰＤＡ（Personal Data Assistance）やパーソナルコンピュータを含む。
III．携帯端末６０の表示部４８にはメニューが表示されるので、各乗員がメニューを見ながらそれぞれが注文内容を確定する。確定されると携帯端末６０は注文情報を車両用情報端末１００に送信する。また、注文情報を送信する際、携帯端末６０は支払い方法を送信する。
支払い方法は割り勘の有無等を指定する情報である。例えば、次のような支払い方法がある。
Ａ．基本：各乗員がそれぞれ購入した商品の代金を支払う。
Ｂ．割り勘：各乗員が購入した商品全ての代金の合計を乗員数で除して、その金額を各乗員の代金とする。
Ｃ．傾斜：予め定めた傾斜情報に従い、各乗員間に支払いの傾斜（比率）を設定して各乗員が支払う代金を決定する。
Ｄ．ジャンル：購入した商品のジャンルと、予めジャンルに応じて定めた傾斜情報に従い各乗員が支払う代金を決定する。

支払い方法は商品毎に設定できる。したがって、一人の乗員が、ある商品の支払いは割り勘にしたり、ある商品の支払いには傾斜を付けるといった支払い方法の設定が可能となっている。
IV．車両用情報端末１００は店舗５００へ注文情報及び支払い方法を送信する。これにより、店舗５００では注文された商品を準備する。
Ｖ．注文後、車両用情報端末１００は、各乗員から受信した注文情報と支払い方法に基づき、各乗員の個別支払い金額を算出し、個別支払い金額情報を各乗員の携帯端末６０に送信する。携帯端末６０を有する乗員が個別支払い金額を確認して支払いを許可する操作を実行すると、携帯端末６０は個別支払い代金情報を車両用情報端末１００に送信する。個別支払い代金情報の送信は、車両用情報端末１００に設けられた非接触ＩＣカードに携帯端末６０が内蔵するＩＣカード４７をかざすことで行われる。
VI．車両用情報端末１００は、各携帯端末６０から個別支払い代金情報を受信すると、各乗員全ての注文の代金情報を店舗５００に送信する。店舗５００は、例えば車両１１又は車両用情報端末１００の識別情報（以下、単に車両識別情報という）を店舗５００のカウンタに表示し、この車両１１の代金の支払いが終了した旨を店員等に通知する。これにより、乗員は店舗５００のカウンタから商品を受け取ることができる。

（V.VI）なお、各携帯端末６０が直接、個別支払い代金情報を店舗５００に送信してもよい。この場合、車両識別情報を個別支払い代金情報に添付（含めて）おけば、店舗５００側では一台の車両１１毎に、全ての個別支払い代金情報を受信したか否か等の支払いを管理できる。なお、各携帯端末６０は車両用情報端末１００と通信する過程で車両識別情報を取得している。

したがって、本実施形態の料金支払いシステムは、各携帯端末６０に支払い比率を調整し、複数の乗員の個別支払い金額を算出するので、複数の乗員がそれぞれ注文する場合に、支払額を柔軟に調整することができる。また、店舗５００は車両１１毎に代金情報を受信するので、車両１１からの一括した支払いが可能となる。

図２は、車両用情報端末１００の機能ブロック図の一例を示す。車両用情報端末１００は、ＣＰＵ、ＲＡＭ、ＲＯＭ、フラッシュメモリやハードディスク装置などの不揮発メモリ（以下、単にメモリという）、入出力インターフェイス及び車載ＬＡＮ通信部等を有するコンピュータとして実装される。そして、ＣＰＵがメモリに記憶されたプログラムを実行するか、又は、ＡＳＩＣ（Application Specific Integrated Circuit）等のハードウェアにより図示する各ブロックが実現される。なお、車両用情報端末１００は、例えばナビゲーションシステムとして実装される。

Bluetooth（登録商標。以下、ＢＴという。）通信部２１は、乗員の携帯端末６０と通信する通信装置である。携帯端末６０もＢＴ通信部４６を備え、互いに通信可能となっている。ＢＴでは、ＳＣＯ（synchronous connection oriented：同期接続）接続とＡＣＬ（Asynchronous Connectionless Link：非同期接続）とが定義されている。ＳＣＯ接続は車両用情報端末１００と携帯端末６０の間に形成される回線接続タイプのポイント・ツー・ポイント・リンクであり、主に音声データの転送に使用される。また、ＡＣＬ 接続はパケット交換タイプの接続を行うリンクであり、主にデータ送信に使用される。したがって、本実施形態では主にＡＣＬ接続を利用する。

ＢＴ通信部２１には固有のＩＤが与えられており、接続する場合はこのＩＤにより通信相手を識別する。また、はじめてＢＴ通信部同士を接続する時はＰＩＮキー（暗証番号）の入力が必要であり、正しいＰＩＮキーが入力されることでペアリングが完了し、以降は携帯端末６０がＢＴ通信部４６を起動した状態で車両用情報端末１００に接近するだけで接続される。

例えば、車両用情報端末１００は接続可能なＢＴモジュールをPagingメッセージにて呼び出し（したがって、車両用情報端末１００がマスターとなる）、携帯端末６０がPagingメッセージに応答するとピコネットが形成される（携帯端末６０がスレーブ）。ピコネットが形成されると、以降はＢＴによる種々のデータの通信が可能となる。なお、複数の乗員が携帯端末６０を携帯して車両１１に乗車した場合、車両用情報端末１００はそれぞれの携帯端末６０と通信する。

リーダ／ライタ２２は、車両用情報端末１００の車室側に通信部を向けて備えられ、携帯端末６０が内蔵するＩＣカード４７を近づけると非接触状態のまま電磁誘導結合に基づく交信を行ってリーダ／ライタ２２がＩＣカード４７に所要のデータを書き込みまた読みだす。リーダ／ライタ２２は、データ送受信用のコイルアンテナと、電力送信用のコイルアンテナと、命令信号を送信する送信部と、ＩＣカード４７から搬送されてきた応答信号を受信する受信部と、ＩＣカード４７に電力を伝送する送信回路と、全体的な制御やＩＣカード４７との通信を行う制御部（マイクロプロセッサ）と、を有する。

携帯端末６０のＩＣカード４７は、リーダ／ライタ２２のコイルアンテナに対して相互誘導作用を利用して電磁誘導結合するコイルを有し、送信された命令信号を受信する受信部と、ＥＥＰＲＯＭ等の書き換え可能な不揮発性メモリが付設された制御回路（ＣＰＵ）と、応答信号を返送する送信部と、を有する。

不揮発メモリには、例えば前払い型の金額情報４５が記憶されている。リーダ／ライタ２２は携帯端末６０を識別してそれぞれに個別支払い代金情報を要求し（個別支払い金額情報を送信し）、携帯端末６０のＩＣカード４７は個別支払い代金に相当する金額を金額情報４５から減算すると共に、個別支払い代金情報をリーダ／ライタ２２に送信する。なお、クレジットカード型（後払い型）の支払いにも対応できる。この場合、リーダ／ライタ２２は携帯端末６０のクレジットカード番号を読み出して、各乗員の個別支払い代金情報に応じて課金する。

外部通信部２８は店舗５００と通信する通信手段である。外部通信部２８は、例えば数メートルから数１００メートルの範囲でのみ通信可能な狭域通信（ＤＳＲＣ；Dedicated Short Range Communication）方式により、1対1又は1対Ｎのアドホックネットワークを実現して店舗５００と通信する。ブルートゥース（登録商標）、ＵＷＢ（Ultra Wide Band）、Ｚｉｇｂｅｅ（登録商標）など所定の通信規格を用いて店舗５００と通信してもよい。

ユーザ情報ＤＢ２９には傾斜情報ＤＢ及びジャンル情報ＤＢが記憶されている。図３（ａ）は、傾斜情報ＤＢに記憶された情報を示す図の一例を、図３（ｂ）はジャンル情報ＤＢに記憶された情報を示す図の一例を、それぞれ示す。傾斜情報ＤＢ及びジャンル情報ＤＢの記憶内容は、ＢＴ通信部２１から各携帯端末６０が設定することができる。

携帯端末ＩＤはユーザを識別する識別情報となる。また、車両１１に乗車することの多い乗員と携帯端末ＩＤとが対応づけられており、携帯端末ＩＤにより親、友人、恋人、同僚、等、車両１１の所有者との関係が識別できるようになっている。傾斜情報は、１００％を乗員数（所有者を含む）で除した値を基準にして、乗員それぞれの支払い比率の増減をパーセント表示する。例えば、乗員が２人（所有者と親）の場合、基準は５０％となり、「５０＋３０％」が父（携帯端末ＩＤ：ＢＢＢ）の支払い比率に、「５０−３０％」が所有者の支払い比率になる。すなわち、他の乗員の支払い比率を決定して、残りを車両１１の所有者が支払う。なお、車両１１の所有者が乗車していない場合は、乗員数で均一に分担してもよいし、優先順位に示す順番に乗車している者を検出し、優先順位の高い乗員を車両１１の所有者の代わりに支払い比率を設定する。

また、ジャンル情報は、購入する商品のジャンルに応じて乗員の支払い比率を定める情報である。ジャンル情報には、日用品、本、電化製品等、いくつかのジャンルが登録されており、乗員がどのジャンルについて多く又は少なく支払うかを定めている。

情報配信部２３は、ＢＴ通信部２１が各携帯端末６０の応答により携帯端末ＩＤを受信して乗車した乗員を検出し、外部通信部２８が受信したメニュー情報を各携帯端末６０に配信する。また、情報配信部２３は必要に応じて車両識別情報を携帯端末６０に送信する。

注文管理部２４は、携帯端末６０が送信した注文情報を管理する。図４（ａ）は注文情報の一例を示す図である。携帯端末ＩＤに対応づけて、商品ＩＤ及び価格が登録されている。価格はメニュー情報と共に携帯端末６０に送信されるので携帯端末６０から受信してもよいし、注文管理部２４がメニュー情報と注文情報を照らし合わせてメニュー情報から抽出してもよい。

また、注文管理部２４は、注文情報を店舗５００に送信する（以下、店舗向け注文情報という）。図４（ｂ）は、車両１１から送信される店舗向け注文情報の一例を示す。車両１１から注文される時点では、各乗員が何を注文したかの情報が不要なので、各商品毎に個数が設定されている。なお、各商品の価格を含めてもよい。

購入管理部２５は、携帯端末６０が送信する支払い方法を商品毎に管理する。したがって、購入管理部２５は、携帯端末ＩＤ、商品及び価格毎に、支払い方法を対応づけて案配計算部に送出する。図４（ｃ）は購入管理部２５が管理する商品毎支払い方法の一例を示す。

案分計算部２６は、商品毎支払い方法から、各乗員の個別支払い金額を算出する。詳細は各実施例で詳述するが、支払い方法が「Ａ．基本」であれば各乗員の購入金額が各乗員の個別支払い金額になり、支払い方法が「Ｂ．割り勘」であれば各乗員の購入金額の合計を乗員数で除した値が各乗員の個別支払い金額となる。図４（ｄ）は個別支払い金額の一例を示す。図４（ｄ）の個別支払金額は、全ての商品が「Ａ．基本」の場合を示す。

代金管理部２７は、リーダ／ライタ２２が取得した個別支払い代金情報を集金して、店舗５００に送信する。代金管理部２７は、個別支払い金額の合計と、受信した個別支払い代金情報の合計を比較して、一致したらそれを代金情報として店舗５００に送信する。携帯端末６０がリーダ／ライタ２２から個別支払い代金情報を支払う際に支払った携帯端末６０が明らかとなるので、個別支払代金を支払っていない携帯端末６０は明らかである。したがって、代金を比較するのでなく、全ての携帯端末６０から個別支払い代金情報を受信したら、代金情報として店舗５００に送信してもよい。また、所定時間経過しても支払わない携帯端末６０に個別支払い代金を要求したり、ディスプレイ３１に「料金を支払ってください」等のメッセージを表示することができる。

また、代金管理部２７は代金情報を店舗５００に送信する。図４（ｅ）は代金情報の一例を示す図である。図４（ｅ）のように携帯端末６０を識別可能な形で代金を送信することで、クレジット会社は決済時にどの携帯端末６０の金額情報４５から送信されたものかを判別できる。また、代金情報に携帯端末６０を識別可能に含むのでなく、車両識別情報のみを送信してもよい。

なお、車両用情報端末１００は液晶等のディスプレイ３１及び音声を出力するスピーカ３２を有し、ディスプレイ３１には商品購入の進捗を示したり、スピーカ３２から各乗員がすべき行為を誘導する音声が出力される。また、ディスプレイ３１にメニュー情報を表示され、タッチパネル又はキーボード式の操作部から注文可能となっている。

〔携帯端末６０〕
図５（ａ）は、本実施形態の携帯端末６０の概略ブロック図を示す。携帯端末６０は、上記のＩＣカード４７の他に、メニュー情報に基づきこれを表示する表示部４８、注文を決定する操作部４９、等を有する。メニュー表示部４１、注文情報取得部４２及び支払い情報取得部は、各携帯端末６０のCPUが所定のアプリケーションプログラムを実行することで実現される。

メニュー表示部４１は、BT通信部４６が受信したメニュー情報を解釈して表示部４８に表示する。注文情報取得部４２は、乗員が操作部４９を操作して選択した商品に基づき注文情報を生成し、BT通信部４６を介して車両用情報端末１００に送信する。支払い情報取得部は、乗員が操作部４９を操作して選択した支払い方法を取得し、BT通信部４６を介して車両用情報端末１００に送信する。

そして、上記のように、ＩＣカード４７はカード／ライタから電力供給を受けて、個別支払い金額情報に応じた代金支払金額を記憶している金額情報４５から減じて、個別支払い代金情報をリーダ／ライタ２２に送信する。なお、支払い管理部４４は、ＩＣカード４７の制御回路（ＣＰＵ）により実現される。

また、携帯端末６０が直接、個別支払い代金情報を店舗５００に送信する場合、ＢＴ通信部４６の代わりに又はＢＴ通信部４６と共に、店舗５００の外部通信部５１と通信する通信手段（車両用情報端末１００が備える外部通信部２８に相当）を有すればよい。

〔店舗５００〕
店舗５００は、各車両の注文、支払い、商品の受け渡し、決済等を管理する。図５（ｂ）は店舗５００の機能ブロック図の一例を示す。図５の店舗５００はコンピュータを実体とし、コンピュータがプログラムを実行して各機能を実現する。

例えば、店舗５００が車両１１にメニューを配信する際に車両１１の車台番号などの車両識別情報を取得して各車両１１を識別している。車両１１の注文管理部２４は、注文情報を店舗５００に送信する際、この車両識別情報に対応づけて店舗向け注文情報を送信する。

注文管理部２４は、図４（ｄ）の店舗向け注文情報を、例えば商品の準備室に転送する。これにより、各商品が店舗５００のカウンタに準備される。なお、この時点で注文受け付け部５２は例えばワンタイムパッド等で生成された暗号キーを車両１１に送信することが好適となる。車両１１の代金管理部２７は暗号キーで代金情報を暗号化してから店舗５００に送信できるので、車両１１と店舗５００間の通信を秘匿化できる。

集金部５３は、注文受け付け部５２が受信した店舗向け注文情報から車両毎の代金を算出し、車両１１から送信された代金情報が車両毎の代金と一致するか否かを判定する。一致する場合には、商品の受け渡しを許可する。また、集金部５３は代金情報を決済部５４に送出する。決済部５４は、クレジット会社と通信して、代金情報と引き替えに支払いを要求する。これにより、店舗５００の例えば銀行口座に代金が支払われる。

以上の構成に基づき、車両１１の各乗員が店舗５００から商品を購入するいくつかの実施例を説明する。

〔支払い例１〕
本支払い例では、「Ａ．基本」の支払い方法で、車両１１が一括して代金情報を店舗５００に送信する態様を説明する。

図６は、商品購入の手順を示すシーケンス図の一例を示す。車両１１が店舗５００の経路１３に進入する前に、車両用情報端末１００と携帯端末６０が通信して、情報配信部２３が乗車している乗員の携帯端末６０から携帯端末ＩＤを受信している（Ｓ１０）。これにより、情報配信部２３はメニュー情報を配信すべき乗員（注文者）を検出する（Ｓ２０）。

店舗５００の経路１３に進入すると、店舗５００から車両用情報端末１００にメニュー情報が送信される（Ｓ３０）。メニュー情報が送信されると車両用情報端末１００はそれを各携帯端末６０に配信する（Ｓ４０）。図６では、２台の携帯端末６０を図示した。

携帯端末６０は例えばメニュー情報を受信したことを表示部４８に表示したり音声等で乗員に通知する。これにより乗員はアプリケーションプログラムを起動させることができる。アプリケーションプログラムのメニュー表示部４１は携帯端末６０の表示部４８にメニューを表示する（Ｓ５０）。図７（ａ）は表示部４８に表示されたメニュー情報の一例を示す。例えば１商品ずつスクールするようになっており、乗員は所望の商品を表示して「注文かごに入れる」ボタンをカーソル等で選択していく（Ｓ６０）。

また、例えば１つの商品を「注文かご」に入れる度に図７（ｂ）に示す支払い方法の選択画面が表示され、この画面から乗員が所望の支払い方法を選択する（Ｓ７０）。したがって、商品毎に支払い方法を選択することができる。本支払い例では、購入した全ての商品について「基本」が選択される。購入する全ての商品に対し同じ支払い方法を一度だけ設定するように設計してもよい。

なお、図７（ｂ）では、「ジャンル」の選択欄をかっこでくくったが、これは後述するようにジャンルは支払い方法として選択しなくても、商品のジャンルに応じて自動的に個別支払い金額に傾斜をつけられるためである。しかしながら、「ジャンル」を選択した場合にのみジャンルに応じて個別支払い金額に傾斜をつけてもよい。

注文かごに記憶された商品は乗員の所定の操作により、図７（ｃ）に示すように一覧表示される。乗員が注文内容及び支払い方法を確認して「注文確定」ボタンを操作すると、注文情報及び支払い方法が車両用情報端末１００に送信される（Ｓ８０）。

注文管理部２４は、携帯端末６０が送信した注文情報に車両識別情報を対応づけて、図４（ｂ）のような店舗向け注文情報を生成する（Ｓ９０）。そして外部通信部２８から店舗向け注文情報を店舗５００に送信する（Ｓ１１０）。なお、乗車していても注文しない乗員がいることがあるので、例えば乗員が注文したことを確認して、車両用情報端末１００を直接操作することで店舗向け注文情報を送信することが好適となる。

また、購入管理部２５は各携帯端末６０から受信した支払い方法に基づき、支払い方法を決定し、案分計算部２６は商品毎支払い方法に基づき個別支払い金額を算出する（Ｓ１２０）。図４（ａ）の注文情報を例にすれば、個別支払金額は次のようになる。すなわち、各乗員が購入した商品の価格の合計がそのまま個別支払い金額になる。
ＡＡＡ：５００円
ＤＤＤ：２００円
案分計算部２６は個別支払い金額情報を各携帯端末６０に送信する（Ｓ１３０）。個別支払い金額情報はまずＢＴ通信部２１を介して送信され、確認のため携帯端末６０の表示部４８に表示される。乗員が支払いに同意する情報を車両用情報端末１００に送信してもよい。

そして、乗員が携帯端末６０をリーダ／ライタ２２にかざすと、各携帯端末６０から個別支払い代金情報が車両用情報端末１００に送信される（Ｓ１４０）。これで携帯端末６０からの支払いは終了したことになる。代金管理部２７は、全ての携帯端末６０から個別支払い代金情報を受信したことを確認して（Ｓ１５０）、代金情報を店舗５００に送信する（Ｓ１６０）。店舗５００の集金部５３により、車両毎の代金と送信された代金情報が一致すると判定されれば、車両１１の乗員は商品を受け取ることができる。

したがって、本支払い例によれば、複数の乗員それぞれが個別に注文してその代金を個別に支払うことができ、また、店舗５００に一括して代金を支払うことができる。

〔支払い例２〕
本支払い例では、支払い方法「Ｂ．割り勘」が選択された場合について説明する。なお、商品購入の手順については図６と同じであるので説明は省略し、以下、図６の個別支払金額の算出（Ｓ１２０）について説明する。なお、乗員はＧさんとＨさんの二人であり、一方が車両１１の所有者であってもそうでなくてもよい。

図８は、本支払い例における個別支払い金額を模式的に説明する図である。図示するように、Gさんは「価格５００円の商品Ｇ１」、「価格３０００円の商品Ｇ２」を購入し、Ｈさんは「価格８００円の商品Ｈ１」を購入した。また、支払い方法は、商品「Ｇ１」「Ｈ１」が「Ａ．基本」、商品「Ｇ２」が「Ｂ．割り勘」である。購入管理部２５は図示するように、乗員毎、商品毎、に支払い方法を決定する。

個別支払い金額について説明する。Ｇさんが購入した商品「Ｇ１」の支払い方法が「Ａ．基本」なので、案分計算部２６は商品「Ｇ１」の価格をそのままＧさんの支払い分とする。商品「Ｇ２」の支払い方法は「Ｂ．割り勘」なので、案分計算部２６は商品「Ｇ２」の価格を乗員数（２人）で除して、Ｇさん及びＨさんの支払い分（３０００÷２＝１５００）を算出する。Ｈさんが購入した商品「Ｈ１」の支払い方法は「Ａ．基本」なので、案分計算部２６は商品「Ｈ１」の価格をそのままＨさんの支払い分とする。

以上から、Ｇさんの個別支払い金額は５００＋１５００＝２０００となり、Ｈさんの個別支払い金額は８００＋１５００＝２３００となる。案分計算部２６はこの個別支払い金額を各携帯端末６０に送信し、携帯端末６０はリーダ／ライタ２２から個別支払代金を支払う。また、代金情報が店舗５００に送信される。

本支払い例によれば、例えば割り勘により、各商品毎に各乗員の支払い分を決定でき、各乗員それぞれが別々の代金を支払っても、店舗５００に一括して代金を支払うことができる。

〔支払い方法３〕
本支払い例では、支払い方法「Ｃ．傾斜」が選択された場合について説明する。支払い方法を「傾斜」とすることで、予め定めた傾斜情報に従い各乗員が支払う代金を決定することができる。なお、乗員はＡさんとＩさんの二人であり、Ａさんが車両１１の所有者であるとする。

図９は、本支払い例における個別支払い金額を模式的に説明する図である。図示するように、Ａさんは「価格５０００円の商品Ａ１」を購入した。また、支払い方法は、商品「Ａ１」について「Ｃ．傾斜」である。購入管理部２５は図示するように、乗員毎、商品毎、に支払い方法を決定する。

個別支払い金額について説明する。支払い方法が「Ｃ．傾斜」の場合、案分計算部２６は、ユーザ情報ＤＢ２９から乗員の傾斜情報を読み出す。乗車している乗員は車両用情報端末１００にとって既知である。乗車している乗員をＡさんの携帯端末６０に送信して、傾斜の対象とする乗員を選択させてもよい。これにより、各乗員に対し傾斜を付ける／付けないを購入者が選択することができる。

本支払い例では、ユーザ情報ＤＢ２９には乗員Ｉさんに「−１０％」の傾斜情報が登録されているとする。乗員が２人なので基準の支払い比率は５０％である。このため、Ｉさんの支払い比率は４０％となり、車両１１の所有者Ａさんの支払い比率は６０％となる。

したがって、商品「Ａ１」の価格「５０００円」にそれぞれ支払い比率を乗じると、５０００×６０％＝３０００が、Ａさんの支払い金額となり、５０００×４０％＝２０００が、Ｉさんの支払い金額となる。

商品「Ａ１」の他には商品が購入されていないので、これらの支払い金額が個別支払い金額となる。案分計算部２６は、個別支払い金額を各携帯端末６０に送信し、携帯端末６０はリーダ／ライタ２２から個別支払代金を支払う。また、代金情報が店舗５００に送信される。

本支払い例によれば、１つの商品の価格に傾斜を付けて各乗員の個別支払い金額を決定でき、各乗員それぞれが別々の代金を支払っても、店舗５００に一括して代金を支払うことができる。

〔支払い方法４〕
本支払い例では、ジャンルに応じて自動的に支払い比率に傾斜がつけられる場合について説明する。購入した商品のジャンルに応じてジャンル情報ＤＢを参照すれば、各乗員が支払う代金に傾斜をつけることができる。なお、乗員はＡさんとＢさんの二人であり、Ａさんが車両１１の所有者であるとする。

ユーザ情報ＤＢ２９に記憶されたジャンル情報には、図３に示したように商品のジャンルに傾斜情報が対応づけられている。例えば、商品が電気製品の場合、Ａさんの傾斜情報は「＋５０％」となり、商品が日用品の場合、Ｂさんの傾斜情報は「＋２０％」となる。

ところで、商品購入時に商品のジャンルを店舗５００側が乗員に通知してくれる場合には、そのジャンルに基づき傾斜情報を読み出せばよい。店舗５００からかかる通知がない場合、購入した商品のジャンルを検出するにはいくつかの方法がある。例えば、商品名とジャンルを対応づけた商品・ジャンルＤＢを記憶しておく方法がある。本を購入すれば、店舗５００から新書、雑誌等の情報が通知されるので、新書や雑誌に「本」というジャンルを対応づけておく。商品・ジャンルＤＢは車両用情報端末１００が有していてもよいし、サーバに問い合わせてもよい。また、ドライブスルーにより購入する場合、車両１１の位置情報と地図ＤＢから現在位置のドライブスルーがどのジャンルの商品を提供する店舗５００なのか判別することができる。飲食店であればジャンルは食品になるし、ガソリンスタンドであれば燃料となる。

購入管理部２５は、このようにしてジャンルを決定し、購入した商品に基づきユーザ情報ＤＢ２９を参照し、商品毎に支払い比率を決定する。したがって、支払い方法が指定されていなくても購入した商品のジャンルに傾斜情報が登録されていれば、支払い比率を決定することができる。なお、図７（ｂ）に示すように、乗員がジャンルによる支払いを入力した場合にのみ、支払い分にジャンルによる傾斜をつけてもよい。これにより、普段はジャンルによる傾斜をつけるが、今回の購入では付けないといった使い分けが可能となる。

図９は、本支払い例における個別支払い金額を模式的に説明する図である。図示するように、Ａさんは「価格２０００円の商品Ａ１」、「価格７０００円の商品Ａ２」を購入した。購入管理部２５が、ユーザ情報ＤＢ２９を参照すると、商品Ａ１は日用品（以下、日用品Ａ１）であり、商品Ａ２は電化製品（以下、電化製品Ａ２）のジャンルに登録されている。したがって、Ａさんは電化製品Ａ２に対し「＋５０％」の傾斜情報にて支払いを分担し、Ｂさんは日用品Ａ１に対し「＋２０％」の傾斜情報にて支払いを分担する。これから、購入管理部２５は図示するように、日用品Ａ１のＡさんの支払い比率を３０％、Ｂさんの支払い比率を７０％、電化製品Ａ２のＡさんの支払い比率を１００％、Ｂさんの支払い比率を０％、にそれぞれ決定する。なお、この５０％は、乗員が二人の場合に所定の乗員（この場合はＡさん）が全額を負担する傾斜情報となるので、５０％の代わりに乗員数に関わらず全額を負担するための情報（例えば「全額負担する」）を登録してもよい。

したがって、商品「Ａ１」の価格「２０００円」にそれぞれ支払い比率を乗じると、２０００×３０％＝６００が、Ａさんの支払い金額となり、２０００×７０％＝１４００が、Ｂさんの支払い金額となる。同様に商品「Ａ２」の価格「７０００円」にそれぞれの支払い比率を乗じると７０００×１００％＝７０００が、Ａさんの支払い金額となり、７０００×０％＝０が、Ｂさんの支払い金額となる。

したがって、Ａさんの個別支払金額は６００＋７０００＝７６００円となり、Ｂさんの個別支払金額は１４００＋０＝１４００円、となる。案分計算部２６は、個別支払い金額を各携帯端末６０に送信し、携帯端末６０はリーダ／ライタ２２から個別支払代金を支払う。また、代金情報が店舗５００に送信される。

したがって、本支払い例によれば、購入する商品に傾斜情報が対応づけられている場合、乗員が携帯端末６０から支払い方法を送信しなくても、乗員間の支払い比率を調整して、乗員それぞれの個別支払い金額を決定することができる。

〔支払い方法に応じた個別支払い金額の計算〕
図１１は、支払い方法に応じた個別支払い金額の計算手順の一例を示すフローチャート図である。なお、図１１では携帯端末６０と店舗５００との通信については省略した。

まず、注文管理部２４は注文管理情報を受信し、購入管理部２５は商品毎支払い方法を生成する（Ｓ２１０）。そして、購入管理部２５は、商品毎に、支払い比率を調整するか否かを判定する（Ｓ２２０）。この判定は、支払い方法が「Ｂ．割り勘」「Ｃ．傾斜」の場合にＹｅｓとなる。

したがって、購入した商品に「Ａ．基本」又は特に指定がない場合（Ｓ２２０のＮｏ）、購入管理部２５は商品が、ユーザ情報ＤＢ２９のジャンルに対応づけて傾斜情報が登録された商品か否かを判定する（Ｓ２３０）。商品に傾斜情報が対応づけられていない場合（Ｓ２３０のＮｏ）、案分計算部２６は、各乗員が購入した商品の価格の合計をそのまま個別支払い金額に決定する（Ｓ２４０）。〔支払い例１〕

商品に傾斜情報が対応づけられている場合（Ｓ２３０のＹｅｓ）、購入管理部２５は、商品のジャンルに応じて各乗員の個別支払い金額を決定する（Ｓ２５０）。すなわち、購入管理部２５は、ユーザ情報ＤＢ２９から読み出したその商品に対応づけられた乗員の傾斜情報を読み出し、商品毎に各乗員の支払い比率を決定する。そして、案分計算部２６は、商品の価格と各乗員の支払い比率から、各乗員の個別支払金額を算出する。〔支払い例４〕

ステップＳ２２０に戻り、商品の支払い方法が「Ｂ．割り勘」又は「Ｃ．傾斜」の場合（Ｓ２２０のＹｅｓ）、購入管理部２５は均一に支払い比率を決定するか否かを判定する（Ｓ２６０）。均一に支払う場合（Ｓ２６０のＹｅｓ）、支払い方法が「Ｂ．割り勘」となるので、案分計算部２６は、商品毎に、その価格を人数で除して各乗員の個別支払い金額を算出する（Ｓ２７０）。〔支払い例２〕

均一に支払わない場合（Ｓ２６０のＮｏ）、支払い方法は「Ｃ．傾斜」となるので、購入管理部２５は、ユーザ情報ＤＢ２９から読み出した乗員の傾斜情報を読み出し、商品毎に各乗員の支払い比率を決定し、そして、案分計算部２６が、商品の価格と各乗員の支払い比率から、各乗員の個別支払金額を算出する。〔支払い例３〕

したがって、本実施例の車両用情報端末１００は、複数の乗員が乗車して商品を購入した場合、商品毎に、個別支払い、割り勘するかしないかの決定、支払い比率の調整、商品のジャンルに応じた支払い比率の調整、が可能なので、複数の乗員が個別に注文しても各乗員の支払い額を柔軟に調整することができる。

実施例１ではメニュー情報を各携帯端末６０に送信したが、本実施例ではメニュー情報を携帯端末６０に送信せず、車両用情報端末１００に乗員が直接、注文情報を入力する購入態様について説明する。

メニュー情報は車両用情報端末１００のディスプレイ３１に表示されるので、各乗員が注文情報を入力することができるが、この場合、車両用情報端末１００は、注文情報と各携帯端末６０を結びつけることになる。注文情報と各携帯端末６０を結びつけるにはいくつかの方法がある。例えば、注文情報を入力する前に携帯端末６０をリーダ／ライタ２２にかざす方法がある。これにより、これから入力される注文情報と携帯端末６０を対応づけることができる。また、車両用情報端末１００には携帯端末ＩＤが送信されているので、その携帯端末ＩＤをディスプレイ３１に表示して、注文前に乗員が自分の携帯端末ＩＤを選択してもよい。

注文時には、図７（ｂ）に示したように支払い方法を入力できるので、携帯端末６０と注文情報、支払い方法が対応づけられれば、以降は実施例１と同様の手順に従い、必要であれば支払い比率を決定した後、個別支払い金額を決定し、車両用情報端末１００から店舗５００に代金情報を送信することができる。

図１２は、本実施例の商品購入の手順を示すシーケンス図の一例を示す。なお、図１２において図６と同一ステップには同一の符号を付し、簡単に説明する。図示するように、車両用情報端末１００はメニュー情報を各携帯端末６０に送信していない。乗員はステップＳ５０で表示されたメニュー情報に対し、ステップＳ３１０で携帯端末６０と注文情報等を対応づける対応づけ情報を、ステップＳ３２０で注文情報を、ステップＳ３３０で支払い方法を、それぞれ入力する。タッチパネル等を操作してもよいし音声入力してもよい。

以降は、実施例１と同様である。すなわち、車両用情報端末１００は注文情報を店舗５００に送信し、購入管理部２５が商品、価格、支払い方法を管理し、案分計算部２６が各乗員の個別支払い金額を算出し、各乗員が携帯端末６０をリーダ／ライタ２２にかざして個別支払い代金を支払う。

したがって、本実施例によれば、実施例１の効果に加え、携帯端末６０にメニュー情報を送信しなくてよいので、携帯端末６０のアプリケーションプログラムの構成を最小限にでき、コスト増を抑制できる。

実施例１、２では、店舗５００から車両用情報端末１００にメニュー情報が送信されたが、メニュー情報そのものを車両用情報端末１００に送信しなくても、実施例１の複数の乗員による柔軟な支払いは可能である。例えば、携帯端末６０は通信網を介してインターネットに接続し、店舗５００の運営するサーバにアクセスすることができる。このサーバのホームページから例えばＨＴＭＬファイルで記述されたメニュー情報を取得でき、乗員が携帯端末６０から直接、注文することができるようになっている。したがって、各携帯端末６０からの注文情報及び支払い方法と、車両１１の車両識別情報とを結びつけておけば、車両１１の車両用情報端末１００に注文情報及び支払い方法を送信でき、同様に、複数の乗員間で支払いを分担できるようになる。

携帯端末６０は、ＢＴ通信部２１から車両識別情報を受信している。この車両識別情報は、車両１１を一意に特定できる情報であって、上記の車台番号等でもよいが、店舗５００がＤＳＲＣでなく通信網を介して注文情報と支払い方法を送信する場合は、車両１１の電話番号でもよい。車両用情報端末１００は、車台番号で識別された場合にはＤＳＲＣにより、電話番号で識別された場合には通信網を介して、各乗員の注文情報と支払い方法を受信できる。

このような形態はドライブスルーの経路１３に進入する前に各乗員が注文することを可能とするので、乗員はゆっくりと商品を注文でき、店舗側では商品の準備に時間的な余裕ができ、また、商品の受け渡し時に乗員の待ち時間が短縮できるという利点がある。なお、本実施例の購入形態はドライブスルーに限られず、車内で通信販売による商品を購入する際にも利用できる。この場合、商品は後日、例えば自宅に配送される。

図１３は、本実施例の商品購入の手順を示すシーケンス図の一例を示す。なお、図１３において図６と同一ステップには同一の符号を付し、簡単に説明する。サーバ５０１は店舗５００が運営するもので、図では店舗５００と別体に示したが事業体としては一体である。

図示するように、携帯端末６０はサーバ５０１にアクセスし（Ｓ４１０）、サーバ５０１に注文情報、支払い方法及び車両識別情報を送信する（Ｓ４２０）。サーバ５０１はネットワークを介して、注文情報、支払い方法及び車両識別情報を店舗５００に転送する（Ｓ４３０）。そして、店舗５００はドライブスルー又は路上を走行中の車両１１に注文情報、支払い方法を送信する（Ｓ４４０）。なお、サーバ５０１から車両用情報端末１００に直接、注文情報及び支払い方法を送信してもよい。

以降は、実施例１と同様である。すなわち、車両用情報端末１００は注文情報を店舗５００に送信し、購入管理部２５が商品、価格、支払い方法を管理し、案分計算部２６が各乗員の個別支払い金額を算出し、各乗員が携帯端末６０をリーダ／ライタ２２にかざして個別支払い代金を支払う。

したがって、本実施例によれば、実施例１の効果に加え、ドライブスルーなど所定の場所でなくても注文ができ、また、携帯端末６０にメニュー情報を送信しなくてよいので、携帯端末６０のアプリケーションプログラムの構成を最小限にでき、コスト増を抑制できる。

また、車両用情報端末１００から各携帯端末６０にメニュー情報を送信し、携帯端末６０から直接、店舗５００に注文情報及び支払い方法を送信してもよい。本実施例おいても、携帯端末６０は、ＢＴ通信部２１から車両識別情報を受信しており、注文情報及び支払い方法を車両識別情報と共に送信する。

図１４は、本実施例の商品購入の手順を示すシーケンス図の一例を示す。なお、図１４において図６と同一ステップには同一の符号を付し、簡単に説明する。図示するように、携帯端末６０ではメニューが表示され（Ｓ５０）、注文情報、支払い方法が入力される（Ｓ６０、Ｓ７０）。本実施例では、携帯端末６０は、車両用情報端末１００でなく、直接、店舗５００に注文情報、支払い方法、及び、車両識別情報を送信する（Ｓ５１０）。そして、店舗５００は、車両識別情報に従い、注文情報及び支払い方法を車両用情報端末１００に送信する（Ｓ５２０）。これより、車両用情報端末１００は注文情報と支払い方法を取得できたことになる。

以降は、実施例１と同様である。すなわち、車両用情報端末１００は注文情報を店舗５００に送信し、購入管理部２５が商品、価格、支払い方法を管理し、案分計算部２６が各乗員の個別支払い金額を算出し、各乗員が携帯端末６０をリーダ／ライタ２２にかざして個別支払い代金を支払う。

本実施例によれば、実施例１の効果に加えて、店舗５００に直接、注文情報等を送信するので、注文及び商品の準備にかかる時間を短縮できる。

また、店舗５００から直接、各携帯端末６０にメニュー情報を送信し、携帯端末６０から直接、店舗５００に注文情報及び支払い方法を送信してもよい。本実施例おいても、携帯端末６０は、ＢＴ通信部２１から車両識別情報を受信しており、注文情報及び支払い方法を車両識別情報と共に送信する。

店舗５００から、各携帯端末６０にメニュー情報を送信するにはいくつかの方法がある。例えば、携帯端末６０がＤＳＲＣの通信装置を備えていれば、ドライブスルーの経路１３に進入することで、各携帯端末６０がメニュー情報を受信することができる。また、携帯端末６０の電子メールアドレスを店舗５００が取得していれば、電子メールの態様でメニュー情報を携帯端末６０に送信できる。また、実施例３のように携帯端末６０が店舗５００にアクセスしてメニュー情報を受信することができる。携帯端末６０がメニュー情報を受信すれば、実施例４のように、各携帯端末６０は注文情報、支払い方法及び車両識別情報を店舗５００に送信することができる。

図１５は、本実施例の商品購入の手順を示すシーケンス図の一例を示す。なお、図１５において図６と同一ステップには同一の符号を付し、簡単に説明する。図示するように、店舗５００が携帯端末６０に直接メニュー情報を送信する（Ｓ６１０）。携帯端末６０ではメニューが表示され（Ｓ５０）、注文情報、支払い方法が入力される（Ｓ６０、Ｓ７０）。携帯端末６０は、車両用情報端末１００でなく、直接、店舗５００に注文情報、支払い方法、及び、車両識別情報を送信する（Ｓ６２０）。そして、店舗５００は、車両識別情報に従い、注文情報及び支払い方法を車両用情報端末１００に送信する（Ｓ６３０）。これより、車両用情報端末１００は注文情報と支払い方法を取得できたことになる。

以降は、実施例１と同様である。すなわち、車両用情報端末１００は注文情報を店舗５００に送信し、購入管理部２５が商品、価格、支払い方法を管理し、案分計算部２６が各乗員の個別支払い金額を算出し、各乗員が携帯端末６０をリーダ／ライタ２２にかざして個別支払い代金を支払う。

したがって、本実施例によれば、実施例１の効果に加え、車両用情報端末１００を介さずに注文できるので、注文及び商品の準備にかかる時間を短縮できる。

料金支払いシステムを模式的に説明する図の一例である。 車両用情報端末の機能ブロック図の一例である。 傾斜情報ＤＢ及びジャンル情報ＤＢ（ユーザ情報ＤＢ）に記憶された情報の一例を示す図である。 注文情報の一例等を示す図である。 携帯端末の概略ブロック図、店舗の機能ブロック図の一例である。 商品購入の手順を示すシーケンス図の一例である。 携帯端末に表示されるメニュー情報等の一例を示す図である。 個別支払い金額を模式的に説明する図である（支払い例２）。 個別支払い金額を模式的に説明する図である（支払い例３）。 個別支払い金額を模式的に説明する図である（支払い例４）。 支払い方法に応じた個別支払い金額の計算手順の一例を示すフローチャート図である。 商品購入の手順を示すシーケンス図の一例である（実施例２）。 商品購入の手順を示すシーケンス図の一例である（実施例３）。 商品購入の手順を示すシーケンス図の一例である（実施例４）。 商品購入の手順を示すシーケンス図の一例である（実施例５）。

符号の説明

１１ 車両
２４ 注文管理部
２５ 購入管理部
２６ 案分計算部
２９ ユーザ情報ＤＢ
４７ ＩＣカード
６０ 携帯端末
１００ 車両用情報端末
２００ 料金支払いシステム
５００ 店舗

Claims (10)

1. 購入対象物の料金を複数の支払い端末又は車両用情報端末から集金する料金支払いシステムにおいて、
   前記車両用情報端末は、
   購入対象物のメニュー情報を車外端末から受信するメニュー情報受信手段と、
   乗員がメニュー情報に基づき注文した注文情報を取得する注文情報取得手段と、
   支払い端末それぞれの支払い比率を算出するための支払い方法を取得して、支払い方法に基づき決定した支払い比率と、注文情報が含む価格情報に基づき、支払い端末毎の個別支払い金額を算出する案分計算手段と、
   個別支払い金額情報を各支払い端末に送信する支払い金額情報送信手段と、
   を有する、
   ことを特徴とする料金支払いシステム。
2. 前記車両用情報端末は、
   前記メニュー情報受信手段が受信したメニュー情報を支払い端末に送信するメニュー情報送信手段、を有し、
   前記注文情報取得手段は、乗員により各支払い端末に入力された注文情報をそれぞれの支払い端末から受信する、
   ことを特徴とする請求項１記載の料金支払いシステム。
3. 前記支払い比率決定手段は、購入対象物の種類などのジャンル情報を決定し、ジャンル情報に応じて支払い端末毎の支払い比率を決定する、
   ことを特徴とする請求項１記載の料金支払いシステム。
4. ジャンル情報と支払い比率情報とが関連づけられた情報を、支払い端末に対応づけるジャンル情報ＤＢを有する、
   ことを特徴とする請求項３記載の料金支払いシステム。
5. 前記案分計算手段は、
   乗員により入力された、個別支払い指示、割り勘指示、又は、所定の支払い端末に重みづけする傾斜指示、の支払い方法、に基づき支払い比率を決定する、
   ことを特徴とする請求項１記載の料金支払いシステム。
6. 支払い端末毎に支払い比率情報を定める支払い比率情報ＤＢを有し、
   前記按分計算手段は、支払い方法が前記傾斜指示の場合、前記支払い比率情報ＤＢを参照して支払い端末毎に支払い比率を決定する、
   ことを特徴とする請求項５記載の料金支払いシステム。
7. 前記車両用情報端末が、
   各支払い端末から取得した個別支払い代金情報を受信して車外端末に送信する代金情報送信手段を有するか、又は、
   外部端末が、各支払い端末から送信された個別支払い代金情報を直接受信する、
   ことを特徴とする請求項１記載の料金支払いシステム。
8. 購入対象物の料金を複数の支払い端末により分担して支払う車両用情報端末であって、
   購入対象物のメニュー情報を車外端末から受信するメニュー情報受信手段と、
   乗員がメニュー情報に基づき注文した注文情報を取得する注文情報取得手段と、
   支払い端末の支払い比率を算出するための支払い方法を取得する支払い方法取得手段と、
   支払い端末それぞれの支払い比率を算出するための支払い方法を取得して、支払い方法に基づき決定した支払い比率と、注文情報が含む価格情報に基づき、支払い端末毎の個別支払い金額を算出する案分計算手段と、
   個別支払い金額情報を各支払い端末に送信する支払い金額情報送信手段と、
   を有することを特徴とする車両用情報端末。
9. 前記メニュー情報受信手段が受信したメニュー情報を支払い端末に送信するメニュー情報送信手段、を有し、
   前記注文情報取得手段は、乗員により各支払い端末に入力された注文情報をそれぞれの支払い端末から受信する、
   ことを特徴とする請求項８記載の車両用情報端末。
10. 購入対象物の料金を複数の支払い端末又は車両用情報端末から集金する代金支払い方法であって、
    メニュー情報受信手段が、購入対象物のメニュー情報を車外端末から受信するステップと、
    注文情報取得手段が、乗員がメニュー情報に基づき注文した注文情報を取得するステップと、
    案分計算手段が、支払い端末それぞれの支払い比率を算出するための支払い方法を取得して、支払い方法に基づき決定した支払い比率と、注文情報が含む価格情報に基づき、支払い端末毎の個別支払い金額を算出するステップと、
    支払い金額情報送信手段が、個別支払い金額情報を各支払い端末に送信するステップと、
    を有することを特徴とする代金支払い方法。

Images