JP2003256529A - チャットサービス機能を備えた決済システム - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】 客自身がオーダーを確認しながら注文でき、
かつチャットサービス機能を備えた決済システムを提供
する。 【解決手段】 サーバー装置８内に、携帯電話３又は携
帯情報端末４の複数クライアント端末２に対して、同一
グループ内のクライアント制御手段と、同一グループで
連携型プログラムを稼働させるネットワーク制御手段
と、クライアント端末２とサーバー装置８で構成される
閉じられたグループ内から外部ホスト装置７への送受信
手段とからなる決済システムであって、サーバー装置８
には連係型プログラムにより、外部ホスト装置７に同一
グループ内の携帯電話３又は携帯情報端末４の承認を行
うネットワークログイン手段と、連係型プログラムの開
始にともない、クライアント端末２からの発注情報を受
付ける発注情報受付手段を設け、かつ各クライアント端
末２同士のチャット機能を備えた決済システム。

Description

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

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

Claims (1)

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