JP2003256742A - 決済システム - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】 客自身が自己のオーダーを確認しながら注文
することができ、かつグループで利用する場合は、割勘
精算機能を持つ注文・決済サービスにおけるグループ決
済システムを提供する。 【解決手段】 携帯電話３又は携帯情報端末４である複
数のクライアント端末２と、同一グループ内のクライア
ント端末２を制御し、同一グループで連携型プログラム
を稼働させるサーバー装置８とで構成される閉じられた
グループ内から、外部のホスト装置に送受信を行い、サ
ーバー装置８には、外部ホスト装置７に同一グループ内
の携帯電話３又は携帯情報端末４の承認を行うネットワ
ークログイン手段を有し、各クライアント端末２には、
発注情報入力手段と、プログラム実行状態表示手段とを
有し、決済データに基づいて、複数のクライアント端末
２からサーバー装置８への承認により決済条件を決定す
る複数のクライアント端末２での決済機能を有する。

Description

【発明の詳細な説明】 【発明の属する技術分野】本発明は、携帯電話や携帯情
報端末の付加機能に関し、特に、携帯電話・携帯情報端
末に注文・課金・精算機能を具現するに際して、至近の
注文・課金・精算機能を有する親端末との通信が可能な
携帯電話・携帯情報端末を用いたネットワーク上での決
済システムに関する。 【従来の技術】従来のオーダーデータ処理システムは、
図２７に示すように複数のハンディターミナル５０４
と、無線モデム５０５を有するステーション５０６と、
会計所５０９に配設された電子キャッシュレジスタ５０
８からなる会計機とを含み、オーダーメニューに関する
オーダーデーター処理業務を行える。ステーション５０
６には、データ通信回線５１０を介してカスタマープリ
ンタ５０７と厨房５１１に配設されたキッチンプリンタ
５１２とが接続されている。 【０００１】店内客席エリア５００には、多数のテーブ
ル５０１が配設され、ハンディターミナル５０４を携帯
した係員５０３は、当該テーブルNo.（番号）とともに
オーダーメニューを入力する。入力されたオーダーデー
タは、ステーション５０６へ無線送信される。 【０００２】ステーション５０６側では、ハンディター
ミナル５０４から受信したテーブルNo.（番号）ごとの
オーダーデータをオーダーファイルに登録（記憶）する
とともに、オーダーデータを編集してカスタマープリン
タ５０７とキッチンプリンタ５１２へ送信する。厨房５
１１では、キッチンプリンタ５１２で印字発行されたキ
ッチン伝票を基に直ちに調理にとりかかれる。カスタマ
ープリンタ５０７から印字発行されたカスタマー伝票
は、係員５０３によって当該顧客５０２に手渡される。
このカスタマー伝票は、オーダーメニューの確認用の客
控えや、システムによっては会計伝票として使用され
る。 【０００３】飲食後の顧客５０２は、会計所５０９にお
いて、カスタマー伝票をキャッシャーに手渡して会計を
受ける。すなわち、キャッシャーは、テーブルNo.（番
号）をキー入力する。制御部は、ステーション５０６側
に問合せる。当該オーダーデータの呼び出しである。こ
の呼び出しに応えてステーション５０６から送信されて
来た当該テーブルNo.（番号）のオーダーデータを受信
すると、取引（オーダーデータ）について会計処理す
る。かくして、複雑なオーダーデータ処理が正確かつ迅
速に行えるようになっている。 【０００４】そのため、来店した顧客はテーブルNo.
（番号）ごとに管理され、精算時まで一元管理される。
精算時、一つのテーブルNo.（番号）内に複数人の顧
客、つまりグループで利用した場合で、かつ個別に精算
を行う場合においては、会計所でキャッシャーにカスタ
マー伝票を手渡す際に、個々の注文した品物を自己申告
して精算する必要がある。 【０００５】また従来技術では、オーダー済みの注文内
容は、オーダーを完済し、かつ注文した品物が全てテー
ブル上に揃った段階で係員が持ってくるカスタマー伝票
でしか確認できない。そのため、誰が何を頼んだかを配
膳途中で確認することはできない。 【０００６】 【発明が解決しようとする課題】ところで、上記の従来
オーダーデータ処理システムでは、テーブル５０１に着
席した客が、手を挙げるなどして係員５０３を呼び、当
該係員５０３に客希望のメニュー、数量を含むオーダー
データを申し出る。これを申し受けた係員５０３が、携
帯するハンディターミナル５０４を用いて、当該オーダ
ーデータの入力を行っている。 【０００７】したがって、客にとっては、オーダーデー
タ入力までの待ち時間が長くなる。係員５０３にとって
は、急いで入力しなければならないので煩わしくかつ入
力ミスも生じ易い。特に、グループを成す複数人の客か
らそれぞれあるいはまとめてオーダーされる場合には、
聞き取りにくいこともあって不正確になり易い。また、
ピークタイムと呼ばれる昼食や夕食の時間帯において
は、稀に係員がオーダーを取り忘れてしまったり、客が
係員を呼んでも気づかないなどの、顧客サービスにおい
ては致命的な、客を店舗から遠ざけてしまうような行為
も見られる。さらに、店舗経営者側にとっては、一段の
人件費削減を図りたく、さらに店舗運用形態のリニュー
アルや斬新性を追求かつ提供したい。 【０００８】本発明の目的は、客自身がテーブルにおい
て、自己のオーダーを確認しながら注文することがで
き、かつグループで利用する場合においては、オーダー
した各自が自分の分としてできる精算機能を持つ注文・
決済サービスにおける決済システムを提供することにあ
る。 【０００９】 【課題を解決するための手段】上記目的を達成するため
に本発明は、サーバー装置内に、携帯電話又は携帯情報
端末である複数のクライアント端末に対して、同一グル
ープ内の前記クライアント端末とのクライアント制御手
段と、同一グループで連携型プログラムを稼働させるネ
ットワーク制御手段と、前記クライアント端末とサーバ
ー装置で構成される閉じられたグループ内から、外部の
ホスト装置に送受信を行う送受信手段とからなる決済シ
ステムであって、前記サーバー装置には、前記連係型プ
ログラムにより外部ホスト装置に同一グループ内の携帯
電話又は携帯情報端末の承認を行うデータの送信に基づ
いたネットワークログイン手段と、前記連係型プログラ
ムの開始にともない、クライアント端末からの発注情報
を受付る発注情報受付手段ととともに、前記サーバー装
置にはさらに、同一グループにおける全体の発注情報を
表示させるグループ発注情報データ集計手段と前記各ク
ライアント端末毎の決済データを算出する計算手段とを
設け、同一グループ内で各クライアント端末が発注した
ものを各クライアント端末毎に精算を行えるようにし
た。 【発明の実施の形態】以下、本発明のグループ決済シス
テムの実施例について、図面を参照しながら説明する。 【００１０】図１は、本発明の一実施形態によるグルー
プ決済システムの全体を示すブロック図である。図２
は、ユーザーがネットワークサービスを受けるために、
ネットワークを確立するまでのフロー図である。図３
は、ユーザーがネットワーク確立後、メニューが表示さ
れるまでのフロー図である。図４は、図２・図３のフロ
ー図の詳細な状態遷移を示す図、その１である。図５
は、図２・図３のフロー図の詳細な状態遷移を示す図、
その２である。図６は、図２・図３のフロー図の詳細な
状態遷移を示す図、その３である。図７は、図２・図３
のフロー図の詳細な状態遷移を示す図、その４である。
図８は、ユーザーがメニュー表示後、注文を行ったとき
の状態遷移を示す図、その１である。図９は、ユーザー
がメニュー表示後、注文を行ったときの状態遷移を示す
図、その２である。図１０は、ユーザーが精算メニュー
から一括精算を選択したときのフロー図である。図１１
は、図１０のフロー図の詳細な状態遷移を示す図、その
１である。図１２は、図１０のフロー図の詳細な状態遷
移を示す図、その２である。図１３は、図１０のフロー
図の詳細な状態遷移を示す図、その３である。図１４
は、図１０のフロー図の詳細な状態遷移を示す図、その
４である。図１５は、本発明の具体例を示すもので、ユ
ーザーが精算メニューからクライアント端末で注文を行
った各自が個別精算を選択したときのフロー図である。
図１６は、図１５のフロー図の詳細な状態遷移を示す
図、その１である。図１７は、図１５のフロー図の詳細
な状態遷移を示す図、その２である。図１８は、ユーザ
ーが精算メニューから割勘精算を選択したときのフロー
図である。図１９は、図１８のフロー図の詳細な状態遷
移を示す図、その１である。図２０は、図１８のフロー
図の詳細な状態遷移を示す図、その２である。図２１
は、図１８のフロー図の詳細な状態遷移を示す図、その
３である。図２２は、割勘精算時に適用される、均等割
り当ての計算方法を示すフロー図である。図２３は、ユ
ーザーがメニューから店舗情報を選択したときの処理状
態の遷移を示す図である。図２４は、ユーザーがメニュ
ーからユーザー情報を選択し、インスタントメッセージ
を利用したときの処理状態の遷移を示す図である。図２
５は、他のユーザーからインスタントメッセージを受信
したときの処理状態の遷移を示す図である。図２６は、
本発明の具体例を示すもので、ユーザーがメニューから
グループの注文確認を選択したときの処理状態の遷移を
示す図である。図２７は、従来のオーダーデータ処理シ
ステムを示すブロック図である。 ＝＝＝＝＝システムの概要＝＝＝＝＝ グループ決済システム１の主要部は、図１に示すよう
に、利用者端末２、店内システム装置５、運用管理ホス
ト装置７によって構成される。 【００１１】運用管理ホスト装置７は、電話回線やＩＳ
ＤＮ回線、また常時接続網である、ＡＤＳＬやＦＴＴＨ
網などを介して、店内システム装置内５のアクセスサー
バ８に接続し、アクセスサーバ８やレジ端末１０・厨房
端末１１に対して、各種データを配信し、さらに必要に
応じて更新プログラム等を配信する。 【００１２】運用管理ホスト装置７には、顧客情報デー
タベース１３があり、ここには本発明であるグループ決
済システムを利用する顧客の顧客データが登録されてい
る。顧客データは、顧客の持つ携帯電話３・携帯情報端
末４からデータを受信することで登録・変更され、デー
タの内容は、携帯電話番号やユーザー名・機種名・クレ
ジットカード番号といった個人を特定可能な個人情報部
と、趣味や好物などの付加情報部とに分かれ、連係型
（リレーショナル）管理が可能なテーブル構造になって
いる。 【００１３】店舗システム装置内５のアクセスサーバ８
では、認証機器９を利用して、携帯電話３・携帯情報端
末４からのユーザー認証を受けるための認証サーバとし
ての機能と、各種通信網を利用したデータの送受信機能
が主であるが、レジ端末１０や厨房端末１１・アクセス
サーバ８との間での情報を屋内ネットワーク（有線ＬＡ
Ｎ若しくは無線ＬＡＮ）で共有しており、レジ端末１０
や厨房端末１１側で何らかのアクションがあった場合
に、その動作内容を記録でき、レジ端末１０での売上デ
ータや、厨房端末１１でのオーダー内容を管理すること
も可能である。この機能を活用することで、レジ端末１
０や厨房端末１１上で処理されたデータを保持（バック
アップ）することができるため、レジ端末１０や厨房端
末１１が故障した場合であっても、直前のデータまでを
管理しているため、復旧作業が容易である。 【００１４】また、前記アクセスサーバ８は、たとえば
ｉモード（商品名）やＢｌｕｅｔｏｏｔｈ（ブルートゥ
ース）などと呼ばれているブラウザ機能付きの携帯型デ
ータ通信端末（携帯電話機）に、有線又は無線型の屋内
ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を介し
て、情報コンテンツを配信する。 【００１５】＝＝＝＝＝本発明の利用例＝＝＝＝＝ −−−−−ネットワークの確立−−−−− 以下、本発明であるグループ決済システムを利用するに
あたっての処理フローを図２乃至図７を用いて説明す
る。なお、図４乃至図６は、携帯電話３・携帯情報端末
４上の一連の動作を表すものである。 【００１６】このような店舗で、無線ＬＡＮの電波を送
受信可能な携帯電話３・携帯情報端末４を持ったユーザ
ーが店内に入ると、ある一定のタイミングでポーリング
動作（図２ ステップ２５）を行っている店内無線機に
より、無線ＬＡＮ利用可能エリアに入ったことを知らせ
るメッセージが携帯電話３・携帯情報端末４に向けて送
信される（図２ ステップ２６）。エリア内通知を受信
したユーザー（図２ステップ２７）は、携帯電話３・携
帯情報端末４の画面に表示されたメッセージを確認し、
「無線ＬＡＮによるネットワークサービスを受けてもよ
い・受けたい」場合には、携帯電話３・携帯情報端末４
よりオンライン要求を行う（図２ ステップ２８，図４
６０）。なお、ポーリング動作については、携帯電話
３や携帯情報端末４側の設定で外部からのネットワーク
アクセス要求を受信するか、などの設定を用意しておく
ことが望ましい。 【００１７】オンライン要求を受けたアクセスサーバ８
は（図２ ステップ２９）、この要求を基に、該当する
端末に対してネットワークを確立し、オンライン状態を
形成する（図２ ステップ３０，図４ ６１）。オンラ
イン状態での携帯電話３・携帯情報端末４は、アクセス
サーバ８から送信される店内情報を受信することができ
る。店内情報とは、その店舗内での宣伝や広告を指し、
オススメメニュー情報や、付近の観光地情報なども含ま
れる。ただし、この状態ではメニューをオーダーするこ
とはできない（図４ ６２）。 【００１８】店内でのオーダーを行いたい場合には、ユ
ーザー側携帯電話３・携帯情報端末４からユーザー認証
要求を行う必要がある（図３ ステップ３２）。ユーザ
ー認証要求を受けたアクセスサーバ８では（図３ ステ
ップ３３）、個々の携帯電話３・携帯情報端末４ごとの
認証を行うために、認証要求を送信する（図３ ステッ
プ３４）。認証要求を受けた携帯電話３・携帯情報端末
４は（図３ ステップ３５）、認証ＩＤを提示する必要
があるが、認証ＩＤとは、例えば２次元バーコードのよ
うな認識技術を利用した方法が考えれる。 【００１９】本発明の実施例では、２次元バーコードを
利用した認証方法を説明する（図３ステップ３６）。初
めて本発明であるグループ決済システムを利用する場合
には、ユーザーの携帯電話３・携帯情報端末４には認証
用ＩＤは記録されていないため、予め認証用ＩＤを登録
する必要がある。ユーザーが新規登録を選択した場合、
アクセスサーバ８には新規登録要求が送信され、新規登
録要求を受信したアクセスサーバ８（図３ ステップ３
７）では、この要求に基づいて、該当ユーザー宛てに登
録フォームを送信する（図３ ステップ３８）。このと
き、オンライン状態になっている携帯電話３・携帯情報
端末４のディスプレイ画面には、新規登録フォームが表
示されており（図３ ステップ３９）、ユーザーは新規
登録画面の表示に従い、登録する電話番号・ユーザー名
・生年月日などを入力し、アクセスサーバ８に送信する
（図３ ステップ４０）。この登録画面は、プロファイ
ル送信などの自己の履歴ファイルを予め作成しておき、
そのファイルを送信するなどの方法も考えられる。 【００２０】アクセスサーバ８では、入力された情報を
基に内容をチェックし、不備等なければ顧客管理ホスト
装置へデータが転送される（図３ ステップ４１）。ユ
ーザー情報を受け取った顧客管理ホスト装置では、ユー
ザー照会を行う（図３ ステップ４２）。ユーザー照会
とは、過去に同様のＩＤでの登録がないか、また、該当
するユーザーが金銭的なトラブルなどを起こしていない
かなどをチェックするものである。チェックでユーザー
が新規登録者として登録可能であれば（図３ステップ４
３）、認証ＩＤを生成し、そのデータをユーザーの携帯
電話３・携帯情報端末４に送信する（図３ ステップ４
４）。送信方法はアクセスサーバ８を介して行う通信方
法以外にも、電子メール送信を行うことも考えられる。 【００２１】認証ＩＤを受信したユーザーの携帯電話３
・携帯情報端末４のディスプレイ画面には、認証ＩＤを
受信したことを示すメッセージが表示される。送信方法
が電子メールであれば、メールを受信したことを示すメ
ッセージが表示される。認証ＩＤは保存することがで
き、ユーザーが新規登録時に行ったユーザー情報の内容
に変更などがなければ同一の認証ＩＤを利用し続けるこ
とができるが、本発明であるグループ決済システムのサ
ービスをしばらく受けていないユーザーは、適宜、顧客
管理ホスト装置からデータが削除される（図３ ステッ
プ４５）。 【００２２】こうして、認証ＩＤを持ったユーザーの携
帯電話３・携帯情報端末４のディスプレイ画面には、認
証ＩＤの提示を促すメッセージが表示される（図３ ス
テップ４６，図４ ６３）。ユーザーはこの情報を基
に、座席付近に予め用意されている認証口に携帯電話３
・携帯情報端末４の画面に表示された認証ＩＤをかざす
（図４ ６４）。認証口では認証ＩＤを読み取り、顧客
管理ホスト装置へユーザー照会を行う。ユーザー照会で
は、同ＩＤでの登録がないか、過去に金銭的なトラブル
を起こしていないかなどをチェックする（図３ ステッ
プ４７）。 【００２３】チェックに問題がなければ、携帯電話３・
携帯情報端末４に向けて認証許可を示すメッセージを送
信するとともに（図３ ステップ４８）、アクセスサー
バ８に該当ユーザーのグループ登録を行う（図３ ステ
ップ４９）。ここでいうグループ登録とは、同じ認証口
に認証ＩＤを提示した少なくとも一人以上のユーザーを
1つのグループとして管理しようというものである。こ
うして、処理が完了すると、ユーザーの携帯電話３・携
帯情報端末４には認証完了を示すメッセージが表示さ
れ、以後、ログオフするまで、メニュー画面からの注文
が行えるようになる（図３ ステップ５０，図４ ６
５）。 【００２４】しかしながら、同じ認証口に複数のユーザ
ーが認証行為を行った場合には、決済時の一括精算の請
求先や、割勘精算時の他のユーザーへの打診を行う場合
などに、その選択権を得るマスターを決定しておく必要
がある。複数のユーザーが同じ認証口からユーザー登録
を行った場合には、注文を行うことはできず、グループ
のマスターを決定するためのメニューが表示される（図
６ ６７）。マスターになるための権限は認証済みの全
てのユーザーに対して許可されるが、一定時間を過ぎた
段階でマスターの決定を行わなかった場合には、最初に
ログインしたユーザーに、マスター登録が行われる。ま
た、マスター登録ユーザーが精算以前にログオフした場
合には、順次、ログインしたユーザー順にマスター登録
が行われる。 【００２５】こうしてマスター登録指示に従って（図６
６８）、マスターとなったユーザーの携帯電話３・携
帯情報端末４のディスプレイ画面には、マスター登録の
完了を示すメッセージが表示される（図６ ６９）。グ
ループ内のユーザーが複数人存在する場合には、以上の
操作の後、注文画面が表示される（図６ ７０）。ま
た、マスター以外のユーザーも同様に注文受け付けが可
能になるが、マスターユーザーとの違いとして、精算メ
ニューは表示されない（図７ ７１）。 【００２６】−−−−− オーダー −−−−− ユーザーの携帯電話３・携帯情報端末４から注文を行う
場合には、メニュー内の注文を選択する。注文を選択す
るとメニューが分類別に表示され、例えばフードメニュ
ーや、アルコールメニューなどに分けられている（図８
８０）。ユーザーはその中から、求めている分類を選
択すると、さらにその階層下にあるサブメニューが表示
される。サブメニューとは、例えば、分類でアルコール
メニューを選択したときに表示されるアルコールの各分
類で、生ビールや日本酒、焼酎、カクテルなどに分類さ
れている。ユーザーはその分類から、好みの飲み物を選
択する（図８ ８１）。このとき、さらに階層下に分類
がある場合には、その内容が表示される。それは例え
ば、サブメニューで生ビールを選択したときに表示され
る、大生ビール、中生ビール、ライトビールグラスなど
である（図８ ８２）。 【００２７】こうして最終的なメニューが決定すると、
その商品をいくつ頼むかを決定する。（図８ ８３）数
量を決定した後、確認を選択すると、注文した内容を確
認するメッセージが表示される。ユーザーはその内容を
確認し、注文を確定する場合には、決定を選択する。注
文に対して訂正を行う場合には、もどるを選択すると、
一処理ずつ前に戻ることができる。キャンセルを選択し
た場合には、処理はキャンセルされ、一連の注文処理は
クリアされる（図８ ８４）。こうして、注文を確定し
たユーザーのデータはアクセスサーバ８に送信され、厨
房端末にデータを送信するとともに、ユーザーの携帯電
話３・携帯情報端末４のディスプレイ画面には、注文を
受け付けたことを示すメッセージが表示される（図８
８５）。 【００２８】また、アクセスサーバ８では、グループご
と・ユーザーごとの注文内容を保持しており、精算の際
には、アクセスサーバ８内のデータを利用して精算処理
を行う。また、一連の注文処理で表示される分類データ
であるが、これはアクセスサーバ８内に、予めデータを
作成しておく必要がある。このデータ作成に関しては、
分類別テーブルを用意し、その中に各種メニューを作成
するもので、非常に多数のデータを扱うので、対話式の
アプリケーションなどを利用して行われることが望まし
い。 【００２９】−−−−− 精算方法 −−−−− 以下、精算方法について図１０乃至図２２を用いて説明
する。精算方法の前提処理として、本発明であるグルー
プ決済システムを利用した場合には、精算時に複数人数
の精算を行うに際し、アクセスサーバ８が、マスターユ
ーザーからの精算指示を受信した時点で精算処理が開始
となる。 【００３０】＜＜＜＜＜ 一括精算 ＞＞＞＞＞一括精
算処理については、図１０乃至図１４を用いて説明す
る。一括精算処理を行う場合には、マスターユーザー
（図１０ ９０）となったユーザーの携帯電話３・携帯
情報端末４のディスプレイ画面に表示されているメニュ
ーから精算を選択する。精算を選択すると、精算方法が
表示される。精算方法には、一括精算、割勘精算、個別
精算などが考えられる（図１１ １２０）。ここで、一
括精算を選択すると、同グループ内で注文されたオーダ
ーの請求先が、マスターユーザーに一括請求される旨の
メッセージが表示される。マスターユーザーは、この内
容を確認し、操作を続ける場合には、同意を示すＯＫな
どのボタンを押し、選択をやり直す場合にはキャンセル
を押すことで、処理を１つ手前に戻すこともできる（図
１０ ステップ１００，図１１ １２１）。 【００３１】精算処理を受信したアクセスサーバ８では
（図１０ ステップ１１３）、グループごとのオーダー
データを管理しており、マスターユーザーからの精算要
求を受信すると、該当するグループのオーダーデータを
検索し（図１０ ステップ１０１）、オーダーデータ内
でオーダーの合計額データを、受信したマスターユーザ
ーのＩＤを持つ、携帯電話３・携帯情報端末４に向けて
一括精算処理データとして送信する（図１０ ステップ
１０３）。 【００３２】マスターユーザーの携帯電話３・携帯情報
端末４側では、一括精算処理データを受信すると、精算
プログラムが作動し、精算画面が表示される（図１０
ステップ１０４）。精算画面の始めには、同グループで
注文されたオーダーのリストと、合計金額が表示される
（図１２ １２２）。マスターユーザーはこの内容を確
認した上で、確認ボタンを押すと、一括精算として、マ
スターユーザーが支払うべき請求金額が表示される。マ
スターユーザーはこの画面を確認した後、支払い方法を
選択する（図１０ ステップ１０５）。 【００３３】支払い方法には、現金やクレジットカー
ド、電子マネーなどが考えられる（図１２ １２３）。
本実施例では現金での支払いを例にとって説明するが、
クレジットカードを利用する場合などには、別途、クレ
ジット会社へのオンラインコールなどでクレジットによ
る精算の可否を打診する処理なども必要である。現金で
の精算を選択すると、アクセスサーバ８に支払い方法デ
ータが送信される。支払い方法データを受信したアクセ
スサーバ８では、付加価値サービスに関する案内データ
を送信する（図１０ ステップ１１０）。 【００３４】ここでは、その他に付加価値情報によるサ
ービスを適用することもでき、それは認証ＩＤによって
ユーザーが持っている付加価値情報を顧客管理ホスト装
置から引き出しておくことが可能で、認証が取れた時点
で、顧客管理ホスト装置から該当する付加価値情報を送
信し、アクセスサーバ８内に一時的に記憶しておくこと
も可能である。ここでいう付加価値情報とは、例えばレ
ストランなどで利用されるポイントカードのようなもの
である。この方法を利用した場合、支払い方法を選択し
た場合には、ポイントを利用するか否かを選択すること
ができる（図１０ ステップ１０９，図１２ １２
４）。ここで、ユーザーの意思によってポイントを利用
する選択をすると、そのポイントによって、再度ユーザ
ー課金計が計算し直される（図１０ ステップ１１０，
図１３ １２５）。ここでのユーザー課金計やマスター
課金計は、各ユーザーごとのデータテーブルで管理され
ているので、他のユーザーに影響を及ぼすことはない。
また、一括精算の請求内容と支払い方法が確定した段階
で（図１０ ステップ１１１）、同グループ内の他のユ
ーザーの携帯電話３・携帯情報端末４には、マスターユ
ーザーが精算を行う旨のメッセージと、ユーザー自身に
は支払い義務が発生しないことを告げる旨のメッセージ
が表示される（図１０ ステップ１１３，図１４ １２
６）。 【００３５】そうして、再度計算された値が表示され、
支払う意思が決定した場合には、確認を示すボタン等を
押すことで、支払い方法と支払い金額が確定する（図１
０ステップ１１２）。現金支払いの場合には、アクセス
サーバ８で処理した計算結果が、予め店内のレジ端末に
向けて送信されており、各ユーザーごとに精算を行う方
法と、携帯電話３・携帯情報端末４の認証ＩＤを認証口
などから読み取って精算を行う方法が考えられる。 【００３６】＜＜＜＜＜ 個別精算 ＞＞＞＞＞次に、
本発明における個別精算処理を、図１５乃至図１７を用
いて説明する。個別精算処理を行う場合には、マスター
ユーザー（図１５ ９０）となったユーザーの携帯電話
３・携帯情報端末４のディスプレイ画面に表示されてい
るメニューから精算を選択する。精算を選択すると、精
算方法が表示される。精算方法には、一括精算、割勘精
算、個別精算などが考えられる。ここで、個別精算を選
択すると、同グループ内で注文されたオーダーの請求先
が、注文を行ったそれぞれのユーザーの携帯電話３・携
帯情報端末４ごとに請求される旨のメッセージが表示さ
れる。マスターユーザーは、この内容を確認し、操作を
続ける場合には、同意を示すＯＫなどのボタンを押し、
選択をやり直す場合にはキャンセルを押すことで、処理
を１つ手前に戻すこともできる（図１５ ステップ１３
０）。 【００３７】精算処理を受信したアクセスサーバ８では
（図１５ ステップ１３１）、グループごとのオーダー
データを管理しており、マスターユーザーからの精算要
求を受信すると、該当するグループのオーダーデータを
検索し（図１５ ステップ１３２）、オーダーデータ内
での各ユーザーのオーダーごとの合計金額を計算し（図
１５ ステップ１３３）、同グループ内のユーザーＩＤ
を持つ携帯電話・携帯情報端末に向けて個別精算処理デ
ータとして送信する（図１５ ステップ１３４）。 【００３８】各ユーザーの携帯電話３・携帯情報端末４
側では、個別精算処理データを受信すると、精算プログ
ラムが作動し、精算画面が表示される（図１５ ステッ
プ１３５）。精算画面の始めには、同グループ内で該当
ユーザーの携帯電話・携帯情報端末から注文されたオー
ダーのリストと、合計金額が表示される。各ユーザーは
この内容を確認した上で、確認ボタンを押すと、個別精
算として、各ユーザーが支払うべき請求金額が表示され
る。各ユーザーはこの画面を確認した後、支払い方法を
選択する（図１５ ステップ１３６）。なお、個別精算
処理においては、各ユーザーの携帯電話３・携帯情報端
末４から注文したオーダー分だけが、それぞれ請求され
るので、各ユーザーによって請求額は変わる。 【００３９】支払い方法には、現金やクレジットカー
ド、電子マネーなどが考えられる。本実施例では現金で
の支払いを例にとって説明するが、クレジットカードを
利用する場合などには、別途、クレジット会社へのオン
ラインコールなどでクレジットによる精算の可否を打診
する処理なども必要である。現金での精算を選択する
と、アクセスサーバ８に支払い方法データが送信され
る。支払い方法データを受信したアクセスサーバ８で
は、付加価値サービスに関する案内データを送信する
（図１５ ステップ１３７）。 【００４０】ここでは、その他に付加価値情報によるサ
ービスを適用することもでき、それは認証ＩＤによって
ユーザーが持っている付加価値情報を顧客管理ホスト装
置から引き出しておくことが可能で、認証が取れた時点
で、顧客管理ホスト装置から該当する付加価値情報を送
信し、アクセスサーバ８内に一時的に記憶しておくこと
も可能である。ここでいう付加価値情報とは、例えばレ
ストランなどで利用されるポイントカードのようなもの
である。この方法を利用した場合、支払い方法を選択し
た場合には、ポイントを利用するか否かを選択すること
ができる（図１５ ステップ１３９）。ここで、ユーザ
ーの意思によってポイントを利用する選択をすると、そ
のポイントによって、再度、請求金額が計算し直される
（図１５ステップ１３８）。ここでの請求金額は、各ユ
ーザーごとのデータテーブルで管理されているので、他
のユーザーに影響を及ぼすことはない。 【００４１】そうして、再度計算された値が表示され、
支払う意思が決定した場合には、確認を示すボタン等を
押すことで、支払い方法と支払い金額が確定する（図１
５ステップ１４０）。現金支払いの場合には、アクセス
サーバ８で処理した計算結果が、予め店内のレジ端末に
向けて送信されており、各ユーザーごとに精算を行う方
法と、携帯電話３・携帯情報端末４の認証ＩＤを認証口
などから読み取って精算を行う方法が考えられる（図１
５ ステップ１４１）。 【００４２】＜＜＜＜＜ 割勘精算 ＞＞＞＞＞割勘精
算処理については、図１８乃至図２２を用いて説明す
る。割勘精算処理を行う場合には、マスターユーザー
（図１８ ９０）となったユーザーの携帯電話３・携帯
情報端末４のディスプレイ画面に表示されているメニュ
ーから精算を選択する。精算を選択すると、精算方法が
表示される。精算方法には、一括精算、割勘精算、個別
精算などが考えられる（図１９ １８０）。ここで、割
勘精算を選択すると（図１８ ステップ１６０）、精算
対象となるユーザーを選択するために、アクセスサーバ
８に対してユーザー情報要求を送信する。ユーザー情報
要求を受信（図１８ ステップ１６１）したアクセスサ
ーバ８内のグループデータには、現在サービスを受けて
いるユーザーが管理されており、この中から、ユーザー
情報要求の送信者の属しているグループのユーザーを検
索（図１８ １６２）、リストを作成し、マスタユーザ
ー宛にグループユーザー情報としてデータ送信する（図
１８ ステップ１６３）。 【００４３】そうして、グループユーザー情報を受信し
たマスターユーザーの携帯電話・携帯情報端末のディス
プレイには、同グループに属するユーザーを選択する画
面が表示される（図１８ ステップ１６４，図１９ １
８１）。ここでは、課金対象をユーザーが選定すること
ができるが、全てのユーザーでの割勘精算以外にも、本
発明であるグループ決済システムを利用できる端末を持
たないユーザーもグループ人数として精算対象に入れる
ことも可能である。この場合、端末を持たないユーザー
も含める選択を行うと、グループ内で端末を持たないユ
ーザー人数を入力する画面が表示される。ここで、該当
する人数を入力（図１９ １８２）することで、アクセ
スサーバ８に精算要求を送信する（図１８ ステップ１
６５）。 【００４４】精算処理を受信したアクセスサーバ８で
は、グループごとのオーダーデータを管理しており、マ
スターユーザーからの精算要求を受信すると、該当する
グループのオーダーデータを検索し、割勘精算処理を行
う。なお、割勘処理については、均等割り当て計算方法
を適用する。これは、以下説明に基づいて処理される。 【００４５】割勘処理時の均等割り当て計算方法は、図
２２を用いて説明する。ステップ２０１：初期化作業。
計算結果を格納するための各メモリの初期化（分割計、
分割整数計、中間計、端数、メンバ課金計、マスタ課金
計）。 ステップ２０２：合計金額を精算要求データ内
に含まれるユーザー数で割り、演算結果を分割計に格納
する。 ステップ２０３：分割計を整数化する（分割計
内の小数点以下の数字を切り捨てた値を分割整数計に格
納）。 ステップ２０４：分割計に小数点が存在するか
どうかチェックする。この分岐にＮｏの場合には、ステ
ップ２０７へ、Ｙｅｓの場合ステップ２０５へ。ステッ
プ２０５：分割計に小数点以下桁数が存在する場合に
は、分割整数計にユーザー数を掛け、この結果を中間計
に格納する。ステップ２０６：合計金額から中間計を差
し引いた値を端数に格納する。ステップ２０７：分割整
数計とユーザー課金計を足し、その結果をユーザー課金
計に格納する。ステップ２０８：分割整数計と端数を足
した結果とマスタ課金計の合計をマスタ課金計に格納す
る。 【００４６】以上のフローによって、割勘精算が可能と
なり、計算の結果、ユーザー課金計には、ユーザーの割
勘精算請求額が格納され、マスター課金計には、マスタ
ーの割勘精算請求額が格納される。 【００４７】アクセスサーバ８では、割勘精算処理が完
了すると、マスターユーザーに対してはマスター課金計
と注文リストから構成される割勘精算処理データを送信
し、ユーザーに対しては、ユーザー課金計と注文リスト
から構成される割勘精算処理データをそれぞれ送信する
（図１８ ステップ１６７）。各ユーザー側の携帯電話
３・携帯情報端末４側では、割勘精算処理データを受信
すると、精算プログラムが作動し、精算画面が表示され
る（図１８ ステップ１６８）。精算画面の始めには、
マスターユーザーから精算要求があった知らせととも
に、合計金額及び、注文したリストが一覧形式で表示さ
れる（図２０ １８３）。この画面については、明細は
表示せずに、ユーザーからの指示があった場合にのみ明
細を表示するようにしてもよい。次の画面では、割勘精
算時に適用されたユーザーの人数と、各々が支払うべき
請求金額が表示される（図２０ １８４）。ユーザーは
この画面を確認した後、支払い方法を選択する（図１８
ステップ１６９）。 【００４８】支払い方法には、現金やクレジットカー
ド、電子マネーなどが考えられる。本実施例では現金で
の支払いを例にとって説明するが、クレジットカードを
利用する場合などには、別途、クレジット会社へのオン
ラインコールなどでクレジットによる精算の可否を打診
する処理なども必要である。現金での精算を選択する
と、アクセスサーバ８に支払い方法データが送信され
る。支払い方法データを受信したアクセスサーバ８では
（図１８ ステップ１７０）、付加価値サービスに関す
る案内データを送信する（図１８ ステップ１７１）。 【００４９】ここでは、その他に付加価値情報によるサ
ービスを適用することもでき、それは認証ＩＤによって
ユーザーが持っている付加価値情報を顧客管理ホスト装
置から引き出しておくことが可能で、認証が取れた時点
で、顧客管理ホスト装置から該当する付加価値情報を送
信し、アクセスサーバ８内に一時的に記憶しておくこと
も可能である。ここでいう付加価値情報とは、例えばレ
ストランなどで利用されるポイントカードのようなもの
である。この方法を利用した場合、支払い方法を選択し
た場合には、ポイントを利用するか否かを選択すること
ができる。（図１８ ステップ１７２，図２１ １８
５）ここで、ユーザーの意思によってポイントを利用す
る選択をすると、そのポイントによって、再度ユーザー
課金計が計算し直される（図１８ ステップ１７１，図
２１ １８６）。ここでのユーザー課金計やマスター課
金計は、各ユーザーごとのデータテーブルで管理されて
いるので、他のユーザーに影響を及ぼすことはない。 【００５０】そうして、再度計算された値が表示され、
支払う意思が決定した場合には、確認を示すボタン等を
押すことで、支払い方法と支払い金額が確定する（図１
８ステップ１７３）。現金支払いの場合には、アクセス
サーバ８で処理した計算結果が、予め店内のレジ端末に
向けて送信されており、各ユーザーごとに精算を行う方
法と、携帯電話３・携帯情報端末４の認証ＩＤを認証口
などから読み取って精算を行う方法が考えられる。端末
を持たないユーザーが存在する場合には、別途レジ端末
からレシートを出力し、該当する顧客が店を出る前に、
手渡しておくなどの方法が考えられる（図１８ ステッ
プ１７４）。 【００５１】本発明の決済システムでは、店舗内にアク
セスサーバ８と呼ばれる中間管理ホスト装置があること
で、以下のようなサービスが可能となる。 【００５２】＜＜＜＜＜ 注文確認 ＞＞＞＞＞すなわ
ち、グループ内で注文した注文確認について、図２６を
用いて説明すると、認証を受けたユーザーの携帯電話３
・携帯情報端末４のメニュー画面から、オーダーを選択
すると、メニューの分類と注文確認が表示されるように
なっている。注文確認を選択すると、操作方法を示すメ
ッセージが表示され、個別オーダー表示か全オーダー表
示を選択することができる（図２６ ２４０）。個別オ
ーダー表示を選択すると、該当するユーザーの携帯電話
３・携帯情報端末４から受け付けた注文のみをリスト表
示でき、全オーダー表示を選択すると、同グループ内で
受け付けた全ての注文をリスト表示できる。ユーザーが
どちらかの表示方法を選択すると、アクセスサーバ８に
ユーザーの認証ＩＤを付加した注文確認指示データを送
信する。 【００５３】個別オーダー表示を選択した場合には、注
文確認指示データを受信したアクセスサーバ８内では、
問い合わせのあったユーザーの認証ＩＤから、該当ユー
ザーの注文テーブルデータを参照し、注文内容確認デー
タをユーザーの携帯電話３・携帯情報端末４に送信す
る。注文内容確認データを受信した携帯電話３・携帯情
報端末４では、データを解読し、リストを形成、該当ユ
ーザーの携帯電話３・携帯情報端末４に表示する。全オ
ーダー表示を選択した場合には、注文確認指示データを
受信したアクセスサーバ８内では、問い合わせのあった
ユーザーの認証ＩＤから、ユーザーがログインしている
グループを割り出し、グループ内での注文データの統計
を持つグループ統計データテーブルを参照し、注文内容
確認データをユーザーの携帯電話３・携帯情報端末４に
送信する。注文内容確認データを受信した携帯電話３・
携帯情報端末４では、データを解読し、リストを形成、
該当ユーザーの携帯電話３・携帯情報端末４に表示する
（図２６ ２４１）。 【００５４】＜＜＜＜＜ 店舗情報 ＞＞＞＞＞店舗情
報については、図２３を用いて説明する。認証を受けた
ユーザーの携帯電話３・携帯情報端末４のメニュー画面
から店舗情報を選択すると、現在サービスを受けている
店舗の情報を知ることができる（図２３ ２２０）。こ
れは、アクセスサーバ８内で管理されている店舗データ
であり、従来のように、インターネットを使って、外部
ネットワークにアクセスする必要がないため、通信費が
ユーザーの負担にならない。また、店舗情報は、ユーザ
ーの携帯電話３・携帯情報端末４内のメモリーに保存す
ることもできるので、店舗に再度来店したいときなどに
は、非常に便利である（図２３ ２２１，２２２）。 【００５５】＜＜＜＜＜ ユーザー情報 ＞＞＞＞＞ユ
ーザー情報については、図２４，図２５を用いて説明す
る。認証を受けたユーザーの携帯電話３・携帯情報端末
４のメニュー画面からユーザー情報を選択すると、現在
同グループ内でサービスを受けている全てのユーザー名
称などを知ることができる（図２４ ２３０）。また、
ユーザー情報では、インスタントメッセージと呼ばれる
簡易型の電子メールを送信する機能を持ち、希望するユ
ーザー名を選択後、表示されたメッセージ枠内に文章を
入力後、送信を選択（図２４２３１）することで目的の
ユーザーにインスタントメッセージを送信することがで
きる（図２４ ２３２，図２５）。また、本発明であ
る、グループ決済システムでは、店舗内にアクセスサー
バ８のような中間管理サーバを置いているため、従来の
ように、インターネットを使って、外部ネットワークに
アクセスする必要がないため、通信費がユーザーの負担
にならない。インスタントメッセージは、他のユーザー
にデータを盗まれることがないので、１：１での情報の
やりとりが簡単に行えるため、騒がしい場所で会話した
い場合や、静かな場所での秘密の会話などをしたい場合
には最適である。 【００５６】 【発明の効果】オフィス環境で利用されるＬＡＮ（Ｌｏ
ｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を利用し、オフィス
環境とは対照的なレストランやカラオケボックスなどの
小規模な環境でＬＡＮを利用し、なおかつ無線ＬＡＮや
ｂｌｕｅｔｏｏｔｈ（ブルートゥース）などの無線技術
を導入することで、利用者が持つ携帯電話・携帯情報端
末と、外部ネットワーク（インターネットなど）にアク
セス可能な店舗内のアクセスサーバと呼ばれる中間管理
ホスト装置、またレジ端末や厨房端末といった各種機器
との連係によって、個別はもちろん、グループごとにサ
ービスを受けるに際し、特にグループ内で発注した内容
を容易に確認できるとともに、オーダーした各自（クラ
イアント端末）単位での決済が可能となる。これによ
り、飲食店に来たグループの各自において、飲みたい
人、食べたい人が他人を遠慮することなく注文・精算が
簡単にでき、付加価値の高いサービスを提供することも
可能となる。

【図面の簡単な説明】 【図１】 本発明の一実施形態によるグループ決済シス
テムの全体を示すブロック図である。 【図２】 ユーザーがネットワークサービスを受けるた
めに、ネットワークを確立するまでのフロー図である。 【図３】 ユーザーがネットワーク確立後、メニューが
表示されるまでのフロー図である。 【図４】 図２・図３のフロー図の詳細な状態遷移を示
す図、その１である。 【図５】 図２・図３のフロー図の詳細な状態遷移を示
す図、その２である。 【図６】 図２・図３のフロー図の詳細な状態遷移を示
す図、その３である。 【図７】 図２・図３のフロー図の詳細な状態遷移を示
す図、その４である。 【図８】 ユーザーがメニュー表示後、注文を行ったと
きの状態遷移を示す図、その１である。 【図９】 ユーザーがメニュー表示後、注文を行ったと
きの状態遷移を示す図、その２である。 【図１０】 ユーザーが精算メニューから一括精算を選
択したときのフロー図である。 【図１１】 図１０のフロー図の詳細な状態遷移を示す
図、その１である。 【図１２】 図１０のフロー図の詳細な状態遷移を示す
図、その２である。 【図１３】 図１０のフロー図の詳細な状態遷移を示す
図、その３である。 【図１４】 図１０のフロー図の詳細な状態遷移を示す
図、その４である。 【図１５】 ユーザーが精算メニューから個別精算を選
択したときのフロー図である。 【図１６】 図１５のフロー図の詳細な状態遷移を示す
図、その１である。 【図１７】 図１５のフロー図の詳細な状態遷移を示す
図、その２である。 【図１８】 ユーザーが精算メニューから割勘精算を選
択したときのフロー図である。 【図１９】 図１８のフロー図の詳細な状態遷移を示す
図、その１である。 【図２０】 図１８のフロー図の詳細な状態遷移を示す
図、その２である。 【図２１】 図１８のフロー図の詳細な状態遷移を示す
図、その３である。 【図２２】 割勘精算時に適用される、均等割り当ての
計算方法を示すフロー図である。 【図２３】 ユーザーがメニューから店舗情報を選択し
たときの処理状態の遷移を示す図である。 【図２４】 ユーザーがメニューからユーザー情報を選
択したときの処理状態の遷移を示す図、その１である。 【図２５】 ユーザーがメニューからユーザー情報を選
択したときの処理状態の遷移を示す図、その２である。 【図２６】 ユーザーがメニューから注文確認を選択し
たときの処理状態の遷移を示す図である。 【図２７】 従来のオーダーデータ処理システムを示す
ブロック図である。 【符号の説明】 １・・・本発明であるグループ決済システムの全体図 ２・・・クライアント端末 ３・・・携帯電話 ４・・・携帯情報端末 ５・・・店舗内ＬＡＮシステム ６・・・インターネット網 ７・・・運用管理ホスト装置 ８・・・アクセスサーバ ９・・・認証機器 １０・・・レジ端末 １１・・・厨房端末 １３・・・顧客管理データベース

Claims (1)

1. 【特許請求の範囲】 【請求項１】 サーバー装置内に、携帯電話又は携帯情
   報端末である複数のクライアント端末に対して、同一グ
   ループ内の前記クライアント端末とのクライアント制御
   手段と、同一グループで連携型プログラムを稼働させる
   ネットワーク制御手段と、前記クライアント端末とサー
   バー装置で構成される閉じられたグループ内から、外部
   のホスト装置に送受信を行う送受信手段とからなる決済
   システムであって、前記サーバー装置には、前記連係型
   プログラムにより外部ホスト装置に同一グループ内の携
   帯電話又は携帯情報端末の承認を行うデータの送信に基
   づいたネットワークログイン手段と、前記連係型プログ
   ラムの開始にともない、クライアント端末からの発注情
   報を受付る発注情報受付手段ととともに、前記サーバー
   装置にはさらに、同一グループにおける全体の発注情報
   を表示させるグループ発注情報データ集計手段と前記各
   クライアント端末毎の決済データを算出する計算手段と
   を設け、同一グループ内で各クライアント端末が発注し
   たものを各クライアント端末毎に精算を行えるようにし
   たこを特徴とする決済システム。