決済システム

トップ :: G 物理学 :: G06 計算;計数

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

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

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

【出願人】	【識別番号】３９０００４７１０【氏名又は名称】株式会社第一興商
【出願日】	平成１４年２月２８日（２００２．２．２８）
【代理人】
【公開番号】	特開２００３－２５６７４２（Ｐ２００３－２５６７４２Ａ）
【公開日】	平成１５年９月１２日（２００３．９．１２）
【出願番号】	特願２００２－９７３１５（Ｐ２００２－９７３１５）