JP5911415B2 - 割り勘による支払いを支援するシステム及び方法 - Google Patents

Description

本発明は、割り勘による支払いを支援するシステム及び方法に関する。特に、本発明は、複数の支払者を含むグループの代表者が使用する代表者コンピュータと、複数の支払者の各々が使用する複数の支払者コンピュータと、被支払者が使用する被支払者コンピュータと、支払いの決済を行う決済コンピュータとを用いて、割り勘による支払いを支援するシステム及び方法に関する。

近年、様々な商品やサービスの料金をカードや電子マネーで支払うことが一般的になってきている。一方、何人かで食事をした場合等にその料金を所謂割り勘（割り前勘定）で支払うことがあるが、割り勘による支払いをカードや電子マネーで行うことは容易ではない。
ここで、割り勘による支払いを行う手法は、従来から種々提案されている（例えば、特許文献１〜６参照）。
特許文献１は、各種代金精算時に、客との取引に関するデータを処理するＥＣＲにおいて、複数の客からなるグループとの一取引において取引された商品の合計金額の支払いを割り勘（個別割り勘、又は単純割り勘）にする場合、支払人毎に、支払方法（現金払い、クレジットカード払い、デビットカード払い、プリペイドカード払い等）が指定されると、支払人毎に指定された支払方法に従って、各支払人に対する割り勘代金の決済を行う技術を開示する。

特許文献２は、提供者側への支払いの際は、代表者のカードにおいて支払い処理を行い、その後クレジットカード会社を含む決済業者のサーバからネットワークを介して、支払い分割対象者に対して、割り勘分の支払い処理を実行するための情報を提示する技術を開示する。

特許文献３、４は、クレジットカードの利用による売上が発生した場合に、利用に係る利用金額を示す利用金額情報を含む売上情報を蓄積し、クレジットカードシステムが、既に発生した売上の代金支払いを割り勘で行う旨の要求を受け付けた場合、受け付けた要求に係る売上情報を、蓄積されている売上情報から検索し、検索した売上情報に含まれる利用金額情報が示す利用金額の分割を実行し、分割の結果に基づいて、分割元の売上情報である検索された売上情報を更新し、その上、分割先の売上情報を蓄積する技術を開示する。

特許文献５は、代金の支払を割前勘定により実施する場合、一人当たりの支払金額を計算して、その支払金額をメンバー端末装置に送信し、メンバー端末装置から支払金額に見合う決済用データを取得する技術を開示する。

特許文献６は、グループを代表して店舗に合計代金を支払った代表者の携帯端末の計算部でグループの各人が負担すべき支払い代金を算出し、算出した各人の支払い代金を含む会計データを各人が携帯する携帯端末に送信し、各人の携帯端末により代表者の携帯端末へ各人の支払い代金に相当する電子マネーデータを送信させて、代表者の携帯端末にて受け取ることにより、グループの各人の分割精算を行う技術を開示する。

特開２００３−９９６８５号公報 特開２００４−２８０３１８号公報 特開２００５−２６７０１２号公報 特開２００５−１０７７７８号公報 ＷＯ２００３／０３８６９８号公報 特開２００８−１０７８７４号公報

このように、割り勘による支払いをカードや電子マネーで行う手法は従来から存在した。
しかしながら、特許文献１の技術では、ＥＣＲにおいて、支払人毎に、支払い方法の指定やその支払い方法に従った割り勘代金の決済を行うので、飲食店等のＥＣＲ前での処理が煩雑になってしまう。
また、特許文献２〜４の技術では、割り勘による支払いにおいて、代表者（分割依頼者）及び支払い分割対象者（分割承認者）がクレジットカードで支払うので、飲食店等のＥＣＲ前での処理が煩雑になることはないが、代表者（分割依頼者）が支払い分割対象者（分割承認者）に支払いを依頼した後は、支払い分割対象者（分割承認者）がクレジットカード会社に対して支払いを行うので、支払いに関する責任の所在が不明確になってしまう。
更に、特許文献５、６の技術は、割り勘による支払いにおいて、代表者端末が各メンバー端末から支払いの決済のための情報を受信してこれをＰＯＳ端末に送信するので、支払いに関する責任の所在は明確になるが、支払いの決済のための情報の内容が代表者に知られてしまう虞がある。

本発明の目的は、割り勘による支払いにおいて、支払いに関する責任の所在を明確にするために、代表者が各支払者から支払いの決済のための情報を受信してこれを被支払者に送信する際に、支払いの決済のための情報の内容が代表者に知られてしまう可能性を低下させることにある。

かかる目的のもと、本発明は、割り勘による支払いを支援するシステムであって、被支払者により使用される被支払者コンピュータと、複数の支払者を含むグループの代表者により使用されるコンピュータであって、代表者により複数の支払者の各支払者に対して決定された第１の金額を示す第１の金額情報を送信するコンピュータである代表者コンピュータと、複数の支払者の各々により使用される複数のコンピュータであって、各コンピュータが、代表者コンピュータにより送信された各コンピュータを使用する支払者に対する第１の金額情報を受信し、第１の金額情報で示される第１の金額に応じた第２の金額を示す第２の金額情報を送信する複数のコンピュータである複数の支払者コンピュータと、支払いの決済を行うコンピュータであって、複数の支払者コンピュータの各コンピュータにより送信された第２の金額情報を受信し、第２の金額情報で示される第２の金額に応じた支払いの決済のための決済情報を保持すると共に、決済情報を被支払者の公開鍵で暗号化した暗号化情報と、第２の金額情報とを、各コンピュータに送信する決済コンピュータとを含み、複数の支払者コンピュータの各コンピュータは、決済コンピュータにより送信された暗号化情報及び第２の金額情報を、代表者コンピュータに送信し、代表者コンピュータは、複数の支払者コンピュータの全てから暗号化情報及び第２の金額情報を受信したことを条件として、複数の支払者コンピュータの各コンピュータについて、各コンピュータにより送信された暗号化情報と、被支払者に対する支払額を分割した金額であって、各コンピュータにより送信された第２の金額に応じた金額である第３の金額を示す第３の金額情報とを、被支払者コンピュータに送信し、被支払者コンピュータは、複数の支払者コンピュータの各コンピュータについて、各コンピュータにより送信された暗号化情報を被支払者の秘密鍵で復号することにより決済情報を取得し、決済情報と、各コンピュータにより送信された第３の金額情報とを、決済コンピュータに送信する、システムを提供する。

ここで、被支払者コンピュータは、代表者コンピュータが第１の金額情報を送信する前に、請求の合計額を、代表者コンピュータに送信し、代表者コンピュータは、被支払者コンピュータにより送信された合計額を代表者が分割した割り勘額を、第１の金額に決定し、複数の支払者コンピュータの各コンピュータは、割り勘額を第２の金額とし、代表者コンピュータは、割り勘額を第３の金額とする、ものであってよい。
或いは、代表者コンピュータは、事前徴収額を第１の金額に決定し、複数の支払者コンピュータの各コンピュータは、事前徴収額に応じて各コンピュータを使用する支払者が決定した支払上限額を第２の金額とし、被支払者コンピュータは、代表者コンピュータが複数の支払者コンピュータの全てから暗号化情報及び第２の金額情報を受信した後に、請求の合計額を、代表者コンピュータに送信し、代表者コンピュータは、被支払者コンピュータにより送信された合計額を代表者が支払上限額を超えないように分割した割り勘額を、第３の金額に決定する、ものであってよい。

また、本発明は、複数の支払者を含むグループの代表者が使用する代表者コンピュータと、複数の支払者の各々が使用する複数の支払者コンピュータと、被支払者が使用する被支払者コンピュータと、支払いの決済を行う決済コンピュータとが、割り勘による支払いを支援する方法であって、代表者コンピュータが、代表者により複数の支払者の各支払者に対して決定された第１の金額を示す第１の金額情報を、複数の支払者コンピュータの各支払者が使用するコンピュータに送信するステップと、複数の支払者コンピュータの各コンピュータが、代表者コンピュータにより送信された第１の金額情報で示される第１の金額に応じた第２の金額を示す第２の金額情報を、決済コンピュータに送信するステップと、決済コンピュータが、複数の支払者コンピュータの各コンピュータにより送信された第２の金額情報で示される第２の金額に応じた支払いの決済のための決済情報を保持すると共に、決済情報を被支払者の公開鍵で暗号化した暗号化情報と、第２の金額情報とを、各コンピュータに送信するステップと、複数の支払者コンピュータの各コンピュータが、決済コンピュータにより送信された暗号化情報及び第２の金額情報を、代表者コンピュータに送信するステップと、代表者コンピュータが、複数の支払者コンピュータの全てから暗号化情報及び第２の金額情報を受信したことを条件として、複数の支払者コンピュータの各コンピュータについて、各コンピュータにより送信された暗号化情報と、被支払者に対する支払額を分割した金額であって、各コンピュータにより送信された第２の金額情報で示される第２の金額に応じた金額である第３の金額を示す第３の金額情報とを、被支払者コンピュータに送信するステップと、被支払者コンピュータは、複数の支払者コンピュータの各コンピュータについて、各コンピュータにより送信された暗号化情報を被支払者の秘密鍵で復号することにより決済情報を取得し、決済情報と、各コンピュータにより送信された第３の金額情報とを、決済コンピュータに送信するステップとを含む、方法も提供する。

また、本発明は、複数の支払者を含むグループの代表者により使用され、複数の支払者の各々が使用する複数の支払者コンピュータと、被支払者が使用する被支払者コンピュータとに接続された、割り勘による支払いを支援する装置であって、代表者の操作に応じて、複数の支払者の各支払者に対して第１の金額を決定する決定部と、決定部により複数の支払者の各支払者に対して決定された第１の金額を示す第１の金額情報を、複数の支払者コンピュータの各支払者が使用するコンピュータに送信する送信部と、送信部により送信した複数の支払者の各支払者に対する第１の金額情報で示される第１の金額に応じた第２の金額の支払いの決済のための決済情報を被支払者の公開鍵で暗号化した暗号化情報と、第２の金額を示す第２の金額情報とを、複数の支払者コンピュータの各支払者が使用するコンピュータから受信する受信部とを含み、送信部は、複数の支払者コンピュータの全てから暗号化情報及び第２の金額情報を受信したことを条件として、複数の支払者コンピュータの各コンピュータについて、各コンピュータにより送信された暗号化情報と、被支払者に対する支払額を分割した金額であって、各コンピュータにより送信された第２の金額に応じた金額である第３の金額を示す第３の金額情報とを、被支払者コンピュータに送信する、装置も提供する。

更に、本発明は、複数の支払者を含むグループの代表者により使用され、複数の支払者の各々が使用する複数の支払者コンピュータと、被支払者が使用する被支払者コンピュータとに接続された、割り勘による支払いを支援する装置として、コンピュータを機能させるプログラムであって、コンピュータを、代表者の操作に応じて、複数の支払者の各支払者に対して第１の金額を決定する決定部と、決定部により複数の支払者の各支払者に対して決定された第１の金額を示す第１の金額情報を、複数の支払者コンピュータの各支払者が使用するコンピュータに送信する送信部と、送信部により送信した複数の支払者の各支払者に対する第１の金額情報で示される第１の金額に応じた第２の金額の支払いの決済のための決済情報を被支払者の公開鍵で暗号化した暗号化情報と、第２の金額を示す第２の金額情報とを、複数の支払者コンピュータの各支払者が使用するコンピュータから受信する受信部として機能させ、送信部は、複数の支払者コンピュータの全てから暗号化情報及び第２の金額情報を受信したことを条件として、複数の支払者コンピュータの各コンピュータについて、各コンピュータにより送信された暗号化情報と、被支払者に対する支払額を分割した金額であって、各コンピュータにより送信された第２の金額に応じた金額である第３の金額を示す第３の金額情報とを、被支払者コンピュータに送信する、プログラムも提供する。

本発明によれば、割り勘による支払いにおいて、支払いに関する責任の所在を明確にするために、代表者が各支払者から支払いの決済のための情報を受信してこれを被支払者に送信する際に、支払いの決済のための情報の内容が代表者に知られてしまう可能性を低下させることができる。

本発明の実施の形態が適用されるコンピュータシステムの全体構成例を示した図である。 第１の実施の形態において代表者及びメンバーがクレジット会社に支払いを要求するときの概略動作を示した図である。 店舗端末が送信する合計額請求情報の具体例を示した図である。 代表者端末が送信する割り勘額請求情報の具体例を示した図である。 メンバー端末が送信する支払い要求情報の具体例を示した図である。 第１の実施の形態においてクレジット会社が支払いを許可したときの概略動作を示した図である。 第１の実施の形態におけるクレジット会社サーバ内のデータベースの内容の例を示した図である。 クレジット会社サーバが送信する支払い許可情報の具体例を示した図である。 代表者端末が送信する支払い許可情報の具体例を示した図である。 第１の実施の形態において店舗がクレジット会社に決済を要求するときの概略動作を示した図である。 第１の実施の形態において代表者端末に表示される画面の第１の例を示した図である。 第１の実施の形態において代表者端末に表示される画面の第２の例を示した図である。 第１の実施の形態においてメンバー端末に表示される画面の第１の例を示した図である。 第１の実施の形態においてメンバー端末に表示される画面の第２の例を示した図である。 第１の実施の形態における各装置の機能構成例を示したブロック図である。 第１の実施の形態における代表者端末の動作例を示したフローチャートである。 第１の実施の形態におけるメンバー端末の動作例を示したフローチャートである。 第２の実施の形態において合計額が確定していない状態で代表者及びメンバーがクレジット会社に支払いを要求するときの概略動作を示した図である。 第２の実施の形態におけるクレジット会社サーバ内のデータベースの内容の例を示した図である。 第２の実施の形態において合計額が確定した後に代表者が割り勘額を店舗に伝えるときの概略動作を示した図である。 第２の実施の形態における各装置の機能構成例を示したブロック図である。 第２の実施の形態における代表者端末の動作例を示したフローチャートである。 第２の実施の形態におけるメンバー端末の動作例を示したフローチャートである。 本発明の実施の形態を適用可能なコンピュータのハードウェア構成例を示した図である。

以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。
［コンピュータシステムの全体構成］
図１は、本実施の形態が適用されるコンピュータシステムの全体構成例を示した図である。
図示するように、このコンピュータシステムは、店舗端末１０と、代表者端末３０と、メンバー端末５０ａ，５０ｂ，５０ｃと、クレジット会社サーバ７０ａ，７０ｂ，７０ｃとが、ネットワーク８０で接続されることにより構成される。
尚、図では、メンバー端末５０ａ，５０ｂ，５０ｃを示したが、これらを区別する必要がない場合は、メンバー端末５０と称する。また、３台のメンバー端末５０しか示していないが、４台以上のメンバー端末５０を設けてもよい。更に、図では、クレジット会社サーバ７０ａ，７０ｂ，７０ｃを示したが、これらを区別する必要がない場合は、クレジット会社サーバ７０と称する。また、３台のクレジット会社サーバ７０しか示していないが、４台以上のクレジット会社サーバ７０を設けてもよい。

店舗端末１０は、店舗が使用するＰＯＳ（Point Of Sales）等の端末装置である。より詳しくは、代表者端末３０に合計額の支払いの請求を行い、代表者端末３０から合計額の支払いの許可があると、クレジット会社サーバ７０に対して支払いの決済を要求する。本実施の形態では、被支払者の一例として、店舗を用いており、被支払者コンピュータの一例として、店舗端末１０を設けている。

代表者端末３０は、店舗に対する支払いを行うグループの代表者が使用するＰＣ等の端末装置である。より詳しくは、店舗端末１０から伝えられた合計額を分割して割り勘額を決定し、各メンバー端末５０からの割り勘額の支払いの許可が揃ったことを確認して合計額の支払いの許可を店舗端末１０に送る。また、クレジット会社サーバ７０に対して支払いを要求することもある。本実施の形態では、代表者コンピュータの一例として、代表者端末３０を設けている。

メンバー端末５０は、店舗に対する支払いを行うグループの代表者以外のメンバーが使用するＰＣ等の端末装置である。より詳しくは、代表者端末３０から伝えられた情報に応じて、クレジット会社サーバ７０に対して支払いを要求し、支払いの予約が完了すると、支払いの許可を代表者端末３０に送る。本実施の形態では、支払者の一例として、メンバーを用いており、支払者コンピュータの一例として、メンバー端末５０を設けている。

クレジット会社サーバ７０は、クレジットカード会社（以下、「クレジット会社」という）が使用するサーバコンピュータである。より詳しくは、代表者端末３０及びメンバー端末５０からの支払いの要求に応じて支払いの予約を行い、店舗端末１０からの要求に応じて支払いの決済を行う。本実施の形態では、決済者の一例として、クレジット会社を用いており、決済コンピュータの一例として、クレジット会社サーバ７０を設けている。

ネットワーク８０は、店舗端末１０と代表者端末３０との間、代表者端末３０とメンバー端末５０との間、代表者端末３０とクレジット会社サーバ７０との間、メンバー端末５０とクレジット会社サーバ７０との間、及び、店舗端末１０とクレジット会社サーバ７０との間で情報の交換に用いる通信手段である。このネットワーク８０としては、インターネットが例示される。

［第１の実施の形態の概略動作］
第一に、代表者及びメンバーがクレジット会社に支払いを要求するときの概略動作について説明する。
図２は、このときの概略動作を示した模式図である。
図示するように、まず、店舗端末１０は、合計額を請求する合計額請求情報２１を代表者端末３０に送信する。ここで、合計額請求情報２１は、合計額の他に、請求を一意に識別する請求識別子の一例である請求コードを含む。請求コードはＵＵＩＤ（Universally Unique Identifier）であり、例えば、請求を行った日時及び連番を用いて生成される。また、請求コード及び合計額には、署名データが付されているのが望ましい。ここで、署名データとしては、例えば、請求コード及び合計額のダイジェスト値を店舗の秘密鍵で暗号化したものを用いることができる。更に、合計額請求情報２１は、支払いに使用可能なクレジット会社のリストである使用可能クレジット会社を含む。更にまた、合計額請求情報２１は、店舗の証明書を含む。ここで、店舗の証明書は、例えば、ＩＴＵ−Ｔ Ｘ．５０９で規定された電子証明書としてよく、店舗ＩＤ、店舗の公開鍵等を含むものとしてよい。

次に、代表者端末３０において、代表者は、合計額請求情報２１により請求される合計額を見ながら、各メンバーに対する割り勘額（第１の金額の一例）を決める。これにより、代表者端末３０は、この割り勘額を請求する割り勘額請求情報４１（第１の金額情報の一例）を各メンバーのメンバー端末５０に送信する。ここで、割り勘額請求情報４１は、合計額請求情報２１における請求コード、合計額、署名データ、使用可能クレジット会社、店舗の証明書に加え、割り勘額を含む。

次いで、メンバー端末５０において、各メンバーは、割り勘額請求情報４１に含まれる使用可能クレジット会社を見ながら、使用するクレジット会社を決定する。そして、そのクレジット会社のクレジット会社サーバ７０にログインし、請求された割り勘額（第２の金額の一例）の支払いを要求する支払い要求情報６１（第２の金額情報の一例）を送信する。ここで、支払い要求情報６１は、割り勘額請求情報４１における請求コード、合計額、署名データ、店舗の証明書、割り勘額を含むが、使用するクレジット会社が決定されたので、使用可能クレジット会社は含まず、使用するクレジット会社に登録されている氏名、カードＩＤ、有効期限等のクレジットカード情報を含む。

引き続き、クレジット会社サーバ７０は、店舗の証明書に基づいて支払いが可能かどうかをチェックする。例えば、店舗の証明書に含まれる店舗の公開鍵で署名データを復号して得られる値と、請求コード及び合計額のダイジェスト値とが一致するかどうかを調べ、一致すれば、請求コード及び合計額は改竄されていないので、支払いが可能であると判断する。支払いが可能であると判断されれば、クレジット会社サーバ７０は、支払いの予約を行う。

尚、代表者自身も支払いを行う場合は、代表者端末３０において、代表者が、自分に対する割り勘額を決める。そして、合計額請求情報２１に含まれる使用可能クレジット会社を見ながら、使用するクレジット会社を決定し、そのクレジット会社のクレジット会社サーバ７０にログインし、自分に対する割り勘額の支払いを要求する支払い要求情報４２（図示せず）を送信する。ここで、支払い要求情報４２は、支払い要求情報６１と同じ内容の情報である。

図３は、図２に示した合計額請求情報２１の具体例を示した図である。尚、ここでは、合計額請求情報２１をＸＭＬ（eXtensible Markup Language）形式としたが、他の形式としてもよい。
図において、記述２１１が請求コードに相当し、記述２１２が合計額に相当する。記述２１３は、ＰｒｏｔｅｃｔｅｄＤａｔａタグで囲まれた情報に対する署名データを示しているので、請求コード及び合計額に対する署名データに相当する。また、図２には示さなかったが、合計額請求情報２１には、記述２１４のような、請求の詳細を示す詳細情報を含めてもよい。更に、記述２１５が使用可能クレジット会社に相当し、記述２１６が店舗の証明書に相当する。

図４は、図２に示した割り勘額請求情報４１の具体例を示した図である。尚、ここでは、割り勘額請求情報４１をＸＭＬ形式としたが、他の形式でもよい。
図において、記述４１１が請求コードに相当し、記述４１２が合計額に相当し、記述４１３が署名データに相当し、記述４１４が割り勘額に相当し、記述４１５が使用可能クレジット会社に相当し、記述４１６が店舗の証明書に相当する。

図５は、図２に示した支払い要求情報６１の具体例を示した図である。尚、ここでは、支払い要求情報６１をＸＭＬ形式としたが、他の形式でもよい。
図において、記述６１１が請求コードに相当し、記述６１２が合計額に相当し、記述６１３が署名データに相当し、記述６１４が店舗の証明書に相当し、記述６１５が割り勘額に相当し、記述６１６がクレジットカード情報に相当する。

第二に、クレジット会社が支払いを許可したときの概略動作について説明する。
図６は、このときの概略動作を示した模式図であり、図７は、クレジット会社サーバ７０内のデータベース７４の内容の例を示した図である。
図６に示すように、まず、クレジット会社サーバ７０は、支払いの予約を行った場合、つまり、支払いの許可を行った場合、支払いの要求の受付を識別する受付識別子の一例である受付コード、店舗から受け取った請求コード及び割り勘額（支払額）を店舗の公開鍵で暗号化することにより、暗号化情報を生成する。ここで、受付コードは、支払いの許可ごとに生成されるワンタイムコードとする。店舗の公開鍵は、店舗の証明書に含まれるものを用いる。また、暗号化する情報には、この支払いに関する有効期限（以下、「支払い期限」という）を含めてもよい。これにより、クレジット会社サーバ７０は、暗号化情報に加え、代表者が支払額（第２の金額の一例）を確認できるように請求コード及び支払額をクレジット会社の署名データ付きで含む支払い許可情報６３（第２の金額情報の一例）を各メンバー端末５０に送信する。
尚、代表者自身も支払いを行う場合、クレジット会社サーバ７０は、支払い許可情報６３と同内容の支払い許可情報４３を代表者端末３０にも送信する。
また、このとき、図７に示すように、受付コード、請求コード、店舗ＩＤ、カードＩＤ、支払額、支払い期限がデータベース７４に登録される。

次に、各メンバーのメンバー端末５０は、支払い許可情報４３（第２の金額情報の一例）を代表者端末３０に送信する。ここで、この支払い許可情報４３は、クレジット会社サーバ７０から受け取った支払い許可情報６３と同じものである。

次いで、代表者端末３０は、全てのメンバーのメンバー端末５０から支払い許可情報４３が送られるのを待つ。全てのメンバーのメンバー端末５０から支払い許可情報４３が送られると、代表者は、これらのメンバーの支払額を集計し、店舗からの請求額と同じことを確認する。同じであれば、代表者端末３０は、メンバーごとの支払額（第３の金額の一例）を含む支払い許可情報２３（第３の金額情報の一例）を店舗端末１０に送信する。ここで、この支払い許可情報２３は、各メンバーのメンバー端末５０から受け取った支払い許可情報４３を連結したものである。
尚、代表者自身も支払いを行う場合、クレジット会社サーバ７０から支払い許可情報４３が送られるのも待ち、クレジット会社サーバ７０から支払い許可情報４３が送られると、この支払い許可情報４３も含めて連結する。

図８は、図６に示した支払い許可情報６３（支払い許可情報４３も同じ）の具体例を示した図である。尚、ここでは、支払い許可情報６３をＸＭＬ形式としたが、他の形式としてもよい。
図において、記述６３１が請求コードに相当し、記述６３２が支払額に相当し、記述６３３が暗号化情報に相当する。記述６３４は、ＰｒｏｔｅｃｔｅｄＤａｔａタグで囲まれた情報に対する署名データを示しているので、請求コード、支払額及び暗号化情報に対する署名データに相当する。また、記述６３５がクレジット会社の証明書に相当する。

図９は、図６に示した支払い許可情報２３の具体例を示した図である。尚、ここでは支払い許可情報２３をＸＭＬ形式としたが、他の形式でもよい。
図において、Ｐａｙｍｅｎｔタグで囲まれた情報が１人分の情報を示しており、この情報は、メンバー端末５０から受け取った支払い許可情報４３と同じものである。

第三に、店舗がクレジット会社に決済を要求するときの概略動作について説明する。
図１０は、このときの概略動作を示した模式図である。
まず、店舗端末１０は、代表者端末３０から受け取った支払い許可情報２３に含まれるメンバーごとの請求コード、支払額及び暗号化情報をチェックする。例えば、クレジット会社の証明書に含まれるクレジット会社の公開鍵で署名データを復号して得られる値と、請求コード、支払額及び暗号化情報のダイジェスト値とが一致するかどうかを調べ、一致すれば、請求コード、支払額及び暗号化情報は改竄されていないと判断する。そこで、店舗端末１０は、支払い許可情報２３に含まれるメンバーごとの暗号化情報を復号する。

次に、店舗端末１０は、受付コードと自身が発行した請求コードと請求額（第３の金額の一例）とを含む決済要求情報２４（第３の金額情報の一例）をクレジット会社サーバ７０に送信することにより、クレジット会社に決済を要求する。ここで、受付コード及び請求コードは、暗号化情報を復号した結果から取得すればよい。また、請求額としては、支払い許可情報２３において暗号化情報に付加された（暗号化されていない）支払額を用いるものとするが、支払い許可情報２３において暗号化情報に含まれる（暗号化された）支払額を用いてもよい。尚、クレジット会社サーバ７０から署名データ付きで支払い許可情報２３が送られてくるため、その署名データを検証するだけで代表者と店舗の間の支払いは済ませることができるので、クレジット会社と店舗の取引がリアルタイムである必要はない。

ここで、このような動作が行われる際に代表者端末３０及びメンバー端末５０に表示される画面について説明する。
図１１は、代表者端末３０に表示される画面の第１の例を示した図である。尚、この画面は、代表者端末３０にインストールされた代表者用割り勘アプリケーションにより表示されるものである。
図において、文字列３４１は、請求コードが「２０１２０４０１１２３０１２３」であることを示し、代表者用割り勘アプリケーションが図３の記述２１１を読み込むことにより表示される。文字列３４２は、合計額が６０００円であることを示し、代表者用割り勘アプリケーションが図３の記述２１２を読み込むことにより表示される。文字列３４３は、署名データが正しいことを示し、代表者用割り勘アプリケーションが図３の記述２１３を読み込むことにより取得した署名データに基づいて表示される。具体的には、代表者用割り勘アプリケーションは、例えば、この署名データを店舗の公開鍵で復号することにより求めた値と、請求コード及び合計額から求めたダイジェスト値とを比較し、これらが一致すれば、請求コード及び合計額が改竄されていないことを示す「ＯＫ」を表示し、これらが一致しなければ、請求コード及び合計額が改竄された可能性があることを示す「ＮＧ」を表示する。

また、画面には、プルダウンメニュー３４４が設けられており、割り勘方法を選択できるようになっている。ここでは、各メンバーが合計額を均等に負担する「均等割り」が選択されており、この支払いに関係するメンバーは４人なので、表示欄３４５には、合計額６０００円を４人のメンバーが１５００円ずつ負担することを示す情報が表示されている。尚、この表示欄３４５において「自分」とは代表者を意味しており、代表者も割り勘額を負担するようになっている。

この状態で、代表者が「自分」の行を選択してボタン３４８をクリックすると、後述する図１３の画面と同様の代表者用の画面が表示され、クレジット会社に対して、支払いのための認証が要求される。具体的には、クレジット会社サーバ７０に対して、支払い要求情報４２が送信される。
また、代表者がメンバーａの行を選択してボタン３４８をクリックすると、メンバーａに対して割り勘額の請求が行われ、代表者がメンバーｂの行を選択してボタン３４８をクリックすると、メンバーｂに対して割り勘額の請求が行われ、代表者がメンバーｃの行を選択してボタン３４８をクリックすると、メンバーｃに対して割り勘額の請求が行われる。具体的には、メンバーａ，ｂ，ｃがそれぞれ使用するメンバー端末５０ａ，５０ｂ，５０ｃに対して、図４の割り勘額請求情報４１が送信される。

この時点では、表示欄３４５の最も右の列のステータスは、全て「Ｗａｉｔｉｎｇ」となっている。ところが、その後、クレジット会社サーバ７０から図８の支払い許可情報４３を受信すると、「自分」に対応するステータスは「ＯＫ」となる。また、あるメンバーのメンバー端末５０から図８の支払い許可情報４３を受信すると、そのメンバーのステータスは「ＯＫ」となる。そして、全てのメンバーのステータスが「ＯＫ」となると、ボタン３４９が活性化され、クリックできるようになる。そこで、代表者がボタン３４９をクリックすると、店舗に対して、合計額の支払いの許可が伝えられる。具体的には、店舗端末１０に対して、図９の支払い許可情報２３が送信される。

図１２は、代表者端末３０に表示される画面の第２の例を示した図である。尚、この画面も、代表者端末３０にインストールされた代表者用割り勘アプリケーションにより表示されるものである。
図には、代表者がメンバーｂの行を選択してボタン３４７をクリックし、メンバーｂが現金を他のメンバーに渡したことを示すように情報を編集した状態を示している。また、メンバーｂが代表者に現金を渡して、代表者がクレジットカードでメンバーｂの分も支払う場合の状態も示している。即ち、代表者は「自分」の行を選択してボタン３４６をクリックし、「自分」の行の下に１行追加する。そして、ボタン３４７をクリックし、その追加した行が他のメンバーの現金分である１５００円の支払いを意味するように情報を編集している。
尚、その後のボタン３４８及びボタン３４９をクリックしたときの動作は、図１１を参照して説明したのと同様である。

図１３は、あるメンバーのメンバー端末５０に表示される画面の第１の例を示した図である。尚、この画面は、メンバー端末５０にインストールされたメンバー用割り勘アプリケーションにより表示されるものである。
図において、文字列５４１は、請求コードが「２０１２０４０１１２３０１２３」であることを示し、メンバー用割り勘アプリケーションが図４の記述４１１を読み込むことにより表示される。文字列５４２は、合計額６０００円のうち割り勘額が１５００円であることを示し、メンバー用割り勘アプリケーションが図４の記述４１２及び記述４１４を読み込むことにより表示される。文字列５４３は、署名データが正しいことを示し、メンバー用割り勘アプリケーションが図４の記述４１３を読み込むことにより取得した署名データに基づいて表示される。具体的には、メンバー用割り勘アプリケーションは、例えば、この署名データを店舗の公開鍵で復号することにより求めた値と、請求コード及び合計額から求めたダイジェスト値とを比較し、これらが一致すれば、請求コード及び合計額が改竄されていないことを示す「ＯＫ」を表示し、これらが一致しなければ、請求コード及び合計額が改竄された可能性があることを示す「ＮＧ」を表示する。

また、画面には、プルダウンメニュー５４４が設けられており、使用するクレジット会社を選択できるようになっている。ここでは、メンバー用割り勘アプリケーションが図４の記述４１５を読み込むことにより設定された複数のクレジット会社の中からクレジット会社Ａが選択されている。更に、画面には、プルダウンメニュー５４５が設けられており、支払い方法を選択できるようになっている。ここでは、一括払いが選択されているが、分割払い等を選択してもよい。更にまた、画面には、入力欄５４６が設けられており、このメンバーのクレジット会社Ａにおけるカード番号（カードＩＤ）を入力できるようになっている。図には示されていないが、クレジットカードの有効期限等を入力できてもよい。

この状態で、メンバーがボタン５４７をクリックすると、クレジット会社に対して、支払いのための認証が要求される。具体的には、クレジット会社サーバ７０に対して、図５の支払い要求情報６１が送信される。
その後、クレジット会社から支払いの許可（認証成功）が送られると、ボタン５４８が活性化され、クリックできるようになる。そこで、メンバーがボタン５４８をクリックすると、代表者に対して、割り勘額の支払いの許可が伝えられる。具体的には、代表者端末３０に対して、図８の支払い許可情報４３が送信される。

ところで、メンバーが割り勘額１５００円をクレジットカードと電子マネーとに分けて支払いたいと考えたとする。図１３の画面では、このような支払いを要求できないので、メンバーはボタン５４９をクリックする。
図１４は、このメンバーのメンバー端末５０に表示される画面の第２の例を示した図である。尚、この画面は、図１３のボタン５４９をクリックすると、メンバー端末５０にインストールされたメンバー用割り勘アプリケーションにより表示されるものである。
図において、文字列５９１〜５９３は、図１３の文字列５４１〜５４３と同じなので説明を省略する。
また、この画面の初期表示時には、表示欄５９４にはクレジットカードＡの行のみが表示されている。そこで、メンバーはその行を選択してボタン５９５をクリックし、その行の下に１行追加する。そして、ボタン５９６をクリックし、その追加した行が電子マネーＸでの５００円の支払いを意味するように情報を編集している。
尚、その後のボタン５９７及びボタン５９８をクリックしたときの動作は、それぞれ、図１３のボタン５４７及びボタン５４８をクリックしたときの動作と同様である。

ここで、電子マネーによる支払いとしては、例えば、アプリケーション等でスマートフォンにチャージしている電子マネーを引き出すことにより行うものが考えられる。但し、このような支払いも、実際には、店舗端末１０が電子マネー会社のサーバから署名付きの支払い許可情報（図６に示した支払い許可情報２３，４３，６３と同内容）を受信することで可能となる。また、実際の決済は、支払い期限内に店舗端末１０が決済要求情報（図１０に示した決済要求情報２４と同内容）を電子マネー会社のサーバに送信することで行われる。尚、電子マネーによる支払いを行う場合は、例えばスマートフォンに保持されている端末証明書を用いてアプリケーションが署名するようにしてもよい。

尚、この例では、クレジットカードで支払う金額の一部を電子マネーで支払うように設定したが、これには限らない。例えば、１つのクレジットカードで支払う金額を複数のクレジットカードで支払うように分割したり、１つのクレジットカードで支払う金額を複数の電子マネーで支払うように分割したりしてもよい。

また、この例では、図１３のボタン５４９をクリックすることにより図１４の画面を表示することとしたが、これには限らない。例えば、図１３の画面及び図１４の画面のうちのメンバーが選択した画面を最初から表示するようにしてもよい。

［第１の実施の形態の構成］
図１５は、第１の実施の形態のコンピュータシステムに含まれる各装置の機能構成例を示したブロック図である。
図示するように、店舗端末１０は、送信部１１と、生成部１２と、受信部１９とを備えている。代表者端末３０は、送信部３１と、生成部３２と、決定部３３と、検査部３４と、受信部３９とを備えている。メンバー端末５０は、送信部５１と、生成部５２と、受信部５９とを備えている。クレジット会社サーバ７０は、送信部７１と、生成部７２と、管理部７３と、データベース７４と、受信部７９とを備えている。

まず、店舗端末１０の構成要素について説明する。
送信部１１は、生成部１２が生成した情報を代表者端末３０又はクレジット会社サーバ７０に送信する。
生成部１２は、送信部１１が代表者端末３０に送信する情報として合計額請求情報２１を生成し、送信部１１がクレジット会社サーバ７０に送信する情報として決済要求情報２４を生成する。
受信部１９は、代表者端末３０から支払い許可情報２３を受信する。

次に、代表者端末３０の構成要素について説明する。
送信部３１は、生成部３２が生成した情報を店舗端末１０、メンバー端末５０又はクレジット会社サーバ７０に送信する。
生成部３２は、送信部３１が店舗端末１０に送信する情報として支払い許可情報２３を生成し、送信部３１がメンバー端末５０に送信する情報として割り勘額請求情報４１を生成し、送信部３１がクレジット会社サーバ７０に送信する情報として支払い要求情報４２を生成する。
決定部３３は、受信部３９が受信した合計額請求情報２１を参照した代表者の操作に応じて各メンバーに対する割り勘額を決定する。
検査部３４は、受信部３９が受信した合計額請求情報２１及び支払い許可情報４３の整合性を検査する。
受信部３９は、店舗端末１０から合計額請求情報２１を受信し、メンバー端末５０又はクレジット会社サーバ７０から支払い許可情報４３を受信する。

次に、メンバー端末５０の構成要素について説明する。
送信部５１は、生成部５２が生成した情報を代表者端末３０又はクレジット会社サーバ７０に送信する。
生成部５２は、送信部５１が代表者端末３０に送信する情報として支払い許可情報４３を生成し、送信部５１がクレジット会社サーバ７０に送信する情報として支払い要求情報６１を生成する。
受信部５９は、代表者端末３０から割り勘額請求情報４１を受信し、クレジット会社サーバ７０から支払い許可情報６３を受信する。

次いで、クレジット会社サーバ７０の構成要素について説明する。
送信部７１は、生成部７２が生成した情報を代表者端末３０又はメンバー端末５０に送信する。
生成部７２は、送信部７１が代表者端末３０に送信する情報として支払い許可情報４３を生成し、送信部７１がメンバー端末５０に送信する情報として支払い許可情報６３を生成する。
管理部７３は、決済に必要な情報をデータベース７４にて管理し、受信部７９が店舗端末１０から受信した決済要求情報２４をこの情報と突き合わせることにより決済を行う。
データベース７４は、決済に必要な情報を記憶する。
受信部７９は、店舗端末１０から決済要求情報２４を受信し、代表者端末３０から支払い要求情報４２を受信し、メンバー端末５０から支払い要求情報６１を受信する。

尚、各装置の機能部は、ソフトウェアとハードウェア資源とが協働することにより実現される。具体的には、各装置のＣＰＵ９０ａ（図２４参照）が所定のプログラムを例えば磁気ディスク装置９０ｇ（図２４参照）からメインメモリ９０ｃ（図２４参照）に読み込んで実行することにより実現される。また、データベース７４は、例えば磁気ディスク装置９０ｇ（図２４参照）により実現される。

［第１の実施の形態の詳細動作］
図１６は、代表者端末３０の動作例を示したフローチャートである。
図示するように、代表者端末３０では、受信部３９が、他の装置から情報を受信し、その情報が如何なる情報であるかを判定する（ステップ３０１）。
まず、受信部３９が受信した情報が、店舗端末１０から受信した合計額請求情報２１であった場合について説明する。ここで、合計額請求情報２１は、上述したように、請求コードと合計額と署名データと使用可能クレジット会社と店舗の証明書とを含む。
この場合、受信部３９は、合計額請求情報２１に含まれる署名データが正しいかどうかを、合計額請求情報２１に含まれる店舗の証明書によって判定し（ステップ３１１）、正しくなければ処理を終了する。

一方、署名データが正しければ、決定部３３が、合計額請求情報２１に含まれる請求コード及び合計額と、署名データが正しい旨の情報とを画面に表示する（ステップ３１２）。尚、このとき、請求コード及び合計額は図示しない合計額記憶部に記憶される。また、決定部３３は、代表者が各メンバーに対する割り勘額を指定する操作を画面上で行うと、この操作を受け付ける（ステップ３１３）。これにより、決定部３３は、メンバーごとの割り勘額を決定する（ステップ３１４）。尚、このとき、メンバーごとの割り勘額は図示しない割り勘額記憶部に記憶される。
次に、生成部３２は、メンバーごとに、割り勘額請求情報４１を生成する（ステップ３１５）。ここで、割り勘額請求情報４１は、請求コードと合計額と署名データと使用可能クレジット会社と店舗の証明書と割り勘額とを含む。
その後、送信部３１が、メンバーごとに、割り勘額請求情報４１をそのメンバーのメンバー端末５０に送信し（ステップ３１６）、処理を終了する。

次に、受信部３９が受信した情報が、メンバー端末５０又はクレジット会社サーバ７０から受信した支払い許可情報４３であった場合について説明する。ここで、支払い許可情報４３は、上述したように、請求コードと支払額と暗号化情報と署名データとクレジット会社の証明書とを含む。
この場合、受信部３９は、支払い許可情報４３に含まれる署名データが正しいかどうかを、支払い許可情報４３に含まれるクレジット会社の証明書によって判定し（ステップ３２１）、正しくなければ処理を終了する。

一方、署名データが正しければ、受信部３９は、割り勘額記憶部を参照して、全てのメンバー端末５０からの支払い許可情報４３が揃ったかどうかを判定する（ステップ３２２）。
全てのメンバー端末５０からの支払い許可情報４３が揃っていなければ、受信部３９は、図示しない一時記憶部に支払い許可情報４３を一時的に記憶する（ステップ３２３）。
また、全てのメンバー端末５０からの支払い許可情報４３が揃えば、検査部３４が、今回受信した支払い許可情報４３に含まれる支払額と、一時記憶部に一時的に記憶されていた支払い許可情報４３に含まれる支払額とから、支払額の合計を算出し（ステップ３２４）、これが合計額記憶部に記憶された合計額と一致するかどうかを判定する（ステップ３２５）。

その結果、支払い許可情報４３に含まれる支払額の合計が合計額記憶部に記憶された合計額と一致しなければ、処理を終了する。
一方、支払い許可情報４３に含まれる支払額の合計が合計額記憶部に記憶された合計額と一致すれば、生成部３２が、今回受信した支払い許可情報４３と一時記憶部に一時的に記憶されていた支払い許可情報４３とを連結することにより、支払い許可情報２３を生成する（ステップ３２６）。
その後、送信部３１が、支払い許可情報２３を店舗端末１０に送信し（ステップ３２７）、処理を終了する。

尚、この動作例では、合計額請求情報２１に含まれる署名データが正しいかどうか及び支払い許可情報４３に含まれる署名データが正しいかどうかを判定するようにしたが、この判定は必ずしも行わなくてよい。

図１７は、メンバー端末５０の動作例を示したフローチャートである。
図示するように、メンバー端末５０では、受信部５９が、他の装置から情報を受信し、その情報が如何なる情報であるかを判定する（ステップ５０１）。
まず、受信部５９が受信した情報が、代表者端末３０から受信した割り勘額請求情報４１であった場合について説明する。ここで、割り勘額請求情報４１は、上述したように、請求コードと合計額と署名データと使用可能クレジット会社と店舗の証明書と割り勘額とを含む。
この場合、受信部５９は、割り勘額請求情報４１に含まれる署名データが正しいかどうかを、割り勘額請求情報４１に含まれる店舗の証明書によって判定し（ステップ５１１）、正しくなければ処理を終了する。

一方、署名データが正しければ、生成部５２が、割り勘額請求情報４１に含まれる請求コード及び合計額と、署名データが正しい旨の情報とを画面に表示する（ステップ５１２）。
次に、生成部５２は、割り勘額請求情報４１に含まれる使用可能クレジット会社を画面に表示し、メンバーが使用するクレジット会社を選択してクレジットカード情報を入力する操作を画面上で行うと、この操作を受け付ける（ステップ５１３）。これにより、生成部５２は、支払い要求情報６１を生成する（ステップ５１４）。ここで、支払い要求情報６１は、請求コードと合計額と署名データと店舗の証明書と割り勘額とクレジットカード情報とを含む。
その後、送信部５１が、支払い要求情報６１をクレジット会社サーバ７０に送信し（ステップ５１５）、処理を終了する。

次に、受信部５９が受信した情報が、クレジット会社サーバ７０から受信した支払い許可情報６３であった場合について説明する。ここで、支払い許可情報６３は、上述したように、請求コードと支払額と暗号化情報と署名データとクレジット会社の証明書とを含む。
この場合、受信部５９は、支払い許可情報６３に含まれる署名データが正しいかどうかを、支払い許可情報６３に含まれるクレジット会社の証明書によって判定し（ステップ５２１）、正しくなければ処理を終了する。

一方、署名データが正しければ、生成部５２が、支払い許可情報４３を生成する（ステップ５２２）。ここで、支払い許可情報４３は、支払い許可情報６３と同じ内容の情報である。
その後、送信部５１が、支払い許可情報４３を代表者端末３０に送信し（ステップ５２３）、処理を終了する。

尚、この動作例では、割り勘額請求情報４１に含まれる署名データが正しいかどうか及び支払い許可情報６３に含まれる署名データが正しいかどうかを判定するようにしたが、この判定は必ずしも行わなくてよい。

［第２の実施の形態の概略動作］
この第２の実施の形態は、第１の実施の形態を前払い方式で実現するものである。即ち、第１の実施の形態のように、合計額が確定した状態で、その合計額を分割した割り勘額の支払いをクレジット会社に要求した後、その割り勘額の決済をクレジット会社に要求する、というものではなく、合計額が確定していない状態で事前徴収額に応じた支払上限額までの支払いをクレジット会社に要求し、合計額が確定した後にその合計額を分割した割り勘額の決済をクレジット会社に要求する、というものである。

第一に、合計額が確定していない状態で、代表者及びメンバーがクレジット会社に支払いを要求してクレジット会社が支払いを許可するときの概略動作について説明する。
図１８は、このときの概略動作を示した模式図であり、図１９は、クレジット会社サーバ７０内のデータベース７４の内容の例を示した図である。
図１８に示すように、まず、店舗端末１０は、店舗に関する情報を通知する店舗通知情報２６を代表者端末３０に送信する。ここで、店舗通知情報２６は、第１の実施の形態で述べたのと同様の請求コードと、未確定のために金額が設定されていない合計額とを含む。また、請求コード及び合計額には、第１の実施の形態で述べたのと同様の署名データが付されているのが望ましい。更に、店舗通知情報２６は、支払いに使用可能なクレジット会社のリストである使用可能クレジット会社を含む。更にまた、店舗通知情報２６は、第１の実施の形態で述べたのと同様の店舗の証明書を含む。

次に、代表者端末３０において、代表者は、例えば店舗から請求される合計額を予想して、各メンバーに対する事前徴収額（第１の金額の一例）を決める。これにより、代表者端末３０は、この事前徴収額を通知する事前徴収額通知情報４６（第１の金額情報の一例）を各メンバーのメンバー端末５０に送信する。ここで、事前徴収額通知情報４６は、店舗通知情報２６における請求コード、合計額、署名データ、使用可能クレジット会社、店舗の証明書に加え、事前徴収額を含む。

次いで、メンバー端末５０において、各メンバーは、事前徴収額通知情報４６に含まれる使用可能クレジット会社を見ながら、使用するクレジット会社を決定する。そして、そのクレジット会社のクレジット会社サーバ７０にログインし、各メンバーが事前徴収額に応じて決めた支払上限額（第２の金額の一例）までの支払いを要求する支払い要求情報６６（第２の金額情報の一例）を送信する。但し、各メンバーは、クレジット会社が支払上限額までの支払いを行ってもよいことを約束しているものとする。ここで、支払い要求情報６６は、事前徴収額通知情報４６における請求コード、合計額、署名データ、店舗の証明書を含むが、事前徴収額の代わりに支払上限額を含む。また、使用するクレジット会社が決定されたので、使用可能クレジット会社は含まず、使用するクレジット会社に登録されている氏名、カードＩＤ、有効期限等のクレジットカード情報を含む。

引き続き、クレジット会社サーバ７０は、店舗の証明書に基づいて支払いが可能かどうかをチェックする。例えば、店舗の証明書に含まれる店舗の公開鍵で署名データを復号して得られる値と、請求コード及び合計額のダイジェスト値とが一致するかどうかを調べ、一致すれば、請求コード及び合計額は改竄されていないので、支払いが可能であると判断する。支払いが可能であると判断されれば、クレジット会社サーバ７０は、支払いの予約を行う。

尚、代表者自身も支払いを行う場合は、代表者端末３０において、代表者が、自分に対する支払上限額を決める。そして、店舗通知情報２６に含まれる使用可能クレジット会社を見ながら、使用するクレジット会社を決定し、そのクレジット会社のクレジット会社サーバ７０にログインし、自分に対する支払上限額までの支払いを要求する支払い要求情報４７（図示せず）を送信する。ここで、支払い要求情報４７は、支払い要求情報６６と同じ内容の情報である。

クレジット会社サーバ７０は、支払いの予約を行った場合、つまり、支払いの許可を行った場合、支払いの許可の受付コード、店舗から受け取った請求コード及び支払上限額を店舗の公開鍵で暗号化することにより、暗号化情報を生成する。ここで、受付コード及び店舗の公開鍵は、第１の実施の形態で用いたのと同様のものを用いる。また、暗号化する情報には、この支払いに関する有効期限である支払い期限を含めてもよい。これにより、クレジット会社サーバ７０は、暗号化情報に加え、代表者が支払上限額（第２の金額の一例）を確認できるように請求コード及び支払上限額をクレジット会社の署名データ付きで含む支払い許可情報６８（第２の金額情報の一例）を各メンバー端末５０に送信する。
尚、代表者自身も支払いを行う場合、クレジット会社サーバ７０は、支払い許可情報６８と同内容の支払い許可情報４８を代表者端末３０にも送信する。
また、このとき、図１９に示すように、受付コード、請求コード、店舗ＩＤ、カードＩＤ、支払上限額、支払い期限がデータベース７４に登録される。

次に、各メンバーのメンバー端末５０は、支払い許可情報４８（第２の金額情報の一例）を代表者端末３０に送信する。ここで、この支払い許可情報４８は、クレジット会社サーバ７０から受け取った支払い許可情報６８と同じものである。

次いで、代表者端末３０は、全てのメンバーのメンバー端末５０から支払い許可情報４８が送られるのを待つ。
尚、代表者自身も支払いを行う場合、クレジット会社サーバ７０から支払い許可情報４８が送られるのも待つ。

第二に、合計額が確定した後に代表者が割り勘額を店舗に伝えるときの概略動作について説明する。
図２０は、このときの概略動作を示した模式図である。
図示するように、まず、店舗端末１０は、合計額を請求する合計額請求情報２７を代表者端末３０に送信する。ここで、合計額請求情報２７は、合計額の他に、第１の実施の形態で述べたのと同様の請求コードを含む。また、請求コード及び合計額には、第１の実施の形態で述べたのと同様の署名データが付されているのが望ましい。更に、合計額請求情報２７は、支払いに使用可能なクレジット会社のリストである使用可能クレジット会社を含む。更にまた、合計額請求情報２７は、第１の実施の形態で述べたのと同様の店舗の証明書を含む。

次に、代表者端末３０において、代表者は、合計額請求情報２７により請求される合計額を、各メンバーから預かった事前徴収額内に収まるように分割することにより、各メンバーに対する割り勘額（支払額）を決める。これにより、代表者端末３０は、メンバーごとの支払額（第３の金額の一例）を含む支払い許可情報２８（第３の金額情報の一例）を店舗端末１０に送信する。ここで、この支払い許可情報２８は、各メンバーのメンバー端末５０から受け取った支払い許可情報４８にここで決めた支払額を付加して連結したものである。
尚、この前払い方式において、代表者は各メンバーから事前徴収額を預かっているため、合計額が確定した後に、代表者と各メンバーとの間のやり取りは発生しない。従って、この方式は、合計額の確定時に、各メンバーのメンバー端末５０がなかったりオフラインであったりしても有効である。

また、合計額請求情報２７により請求される合計額が予想よりも高く事前徴収額に収まらなければ、代表者は、支払い許可情報４８に含まれる支払上限額を超えない範囲で各メンバーに対する割り勘額を決める。尚、このように割り勘額が事前徴収額を超えてしまう場合は、この時点で割り勘額をメンバーに伝えて同意を得るようにするのが望ましい。

第三に、店舗がクレジット会社に決済を要求するときの概略動作について説明する。
このときの概略動作は、図１０に示したものと同様なので、ここでの詳しい説明は省略するが、店舗端末１０は、支払上限額を超えない額の決済を要求する決済要求情報２９（図示せず）をクレジット会社サーバ７０に送信することになる。

［第２の実施の形態の構成］
図２１は、第２の実施の形態のコンピュータシステムに含まれる各装置の機能構成例を示したブロック図である。
図示するように、店舗端末１０は、送信部１１と、生成部１２と、受信部１９とを備えている。代表者端末３０は、送信部３１と、生成部３２と、決定部３３と、受信部３９とを備えている。メンバー端末５０は、送信部５１と、生成部５２と、決定部５３と、受信部５９とを備えている。クレジット会社サーバ７０は、送信部７１と、生成部７２と、管理部７３と、データベース７４と、受信部７９とを備えている。

まず、店舗端末１０の構成要素について説明する。
送信部１１は、生成部１２が生成した情報を代表者端末３０又はクレジット会社サーバ７０に送信する。
生成部１２は、送信部１１が代表者端末３０に送信する情報として店舗通知情報２６又は合計額請求情報２７を生成し、送信部１１がクレジット会社サーバ７０に送信する情報として決済要求情報２９を生成する。
受信部１９は、代表者端末３０から支払い許可情報２８を受信する。

次に、代表者端末３０の構成要素について説明する。
送信部３１は、生成部３２が生成した情報を店舗端末１０、メンバー端末５０又はクレジット会社サーバ７０に送信する。
生成部３２は、送信部３１が店舗端末１０に送信する情報として支払い許可情報２８を生成し、送信部３１がメンバー端末５０に送信する情報として事前徴収額通知情報４６を生成し、送信部３１がクレジット会社サーバ７０に送信する情報として支払い要求情報４７を生成する。
決定部３３は、受信部３９が受信した合計額請求情報２１を参照した代表者の操作に応じて各メンバーに対する割り勘額を決定する。
受信部３９は、店舗端末１０から店舗通知情報２６又は合計額請求情報２７を受信し、メンバー端末５０又はクレジット会社サーバ７０から支払い許可情報４８を受信する。

次に、メンバー端末５０の構成要素について説明する。
送信部５１は、生成部５２が生成した情報を代表者端末３０又はクレジット会社サーバ７０に送信する。
生成部５２は、送信部５１が代表者端末３０に送信する情報として支払い許可情報４８を生成し、送信部５１がクレジット会社サーバ７０に送信する情報として支払い要求情報６６を生成する。
決定部５３は、受信部５９が受信した事前徴収額通知情報４６を参照した各メンバーの操作に応じて各メンバーに対する支払上限額を決定する。
受信部５９は、代表者端末３０から事前徴収額通知情報４６を受信し、クレジット会社サーバ７０から支払い許可情報６８を受信する。

次いで、クレジット会社サーバ７０の構成要素について説明する。
送信部７１は、生成部７２が生成した情報を代表者端末３０又はメンバー端末５０に送信する。
生成部７２は、送信部７１が代表者端末３０に送信する情報として支払い許可情報４８を生成し、送信部７１がメンバー端末５０に送信する情報として支払い許可情報６８を生成する。
管理部７３は、決済に必要な情報をデータベース７４にて管理し、受信部７９が店舗端末１０から受信した決済要求情報２９をこの情報と突き合わせることにより決済を行う。
データベース７４は、決済に必要な情報を記憶する。
受信部７９は、店舗端末１０から決済要求情報２９を受信し、代表者端末３０から支払い要求情報４７を受信し、メンバー端末５０から支払い要求情報６６を受信する。

尚、各装置の機能部は、ソフトウェアとハードウェア資源とが協働することにより実現される。具体的には、各装置のＣＰＵ９０ａ（図２４参照）が所定のプログラムを例えば磁気ディスク装置９０ｇ（図２４参照）からメインメモリ９０ｃ（図２４参照）に読み込んで実行することにより実現される。また、データベース７４は、例えば磁気ディスク装置９０ｇ（図２４参照）により実現される。

［第２の実施の形態の詳細動作］
図２２は、代表者端末３０の動作例を示したフローチャートである。
図示するように、代表者端末３０では、受信部３９が、他の装置から情報を受信し、その情報が如何なる情報であるかを判定する（ステップ３５１）。
まず、受信部３９が受信した情報が、店舗端末１０から受信した店舗通知情報２６であった場合について説明する。ここで、店舗通知情報２６は、上述したように、請求コードと署名データと使用可能クレジット会社と店舗の証明書とを含む。
この場合、受信部３９は、店舗通知情報２６に含まれる署名データが正しいかどうかを、店舗通知情報２６に含まれる店舗の証明書によって判定し（ステップ３６１）、正しくなければ処理を終了する。

一方、署名データが正しければ、決定部３３が、店舗通知情報２６に含まれる請求コードと、署名データが正しい旨の情報とを画面に表示する（ステップ３６２）。また、決定部３３は、代表者が各メンバーに対する事前徴収額を指定する操作を画面上で行うと、この操作を受け付ける（ステップ３６３）。これにより、決定部３３は、メンバーごとの事前徴収額を決定する（ステップ３６４）。尚、このとき、メンバーごとの事前徴収額は図示しない事前徴収額記憶部に記憶される。
次に、生成部３２は、メンバーごとに、事前徴収額通知情報４６を生成する（ステップ３６５）。ここで、事前徴収額通知情報４６は、請求コードと署名データと使用可能クレジット会社と店舗の証明書と事前徴収額とを含む。
その後、送信部３１が、メンバーごとに、事前徴収額通知情報４６をそのメンバーのメンバー端末５０に送信し（ステップ３６６）、処理を終了する。

次に、受信部３９が受信した情報が、メンバー端末５０又はクレジット会社サーバ７０から受信した支払い許可情報４８であった場合について説明する。ここで、支払い許可情報４８は、上述したように、請求コードと支払上限額と暗号化情報と署名データとクレジット会社の証明書とを含む。
この場合、受信部３９は、支払い許可情報４８に含まれる署名データが正しいかどうかを、支払い許可情報４８に含まれるクレジット会社の証明書によって判定し（ステップ３７１）、正しくなければ処理を終了する。

一方、署名データが正しければ、受信部３９は、事前徴収額記憶部を参照して、全てのメンバー端末５０からの支払い許可情報４８が揃ったかどうかを判定する（ステップ３７２）。
全てのメンバー端末５０からの支払い許可情報４８が揃っていなければ、受信部３９は、図示しない一時記憶部に支払い許可情報４８を一時的に記憶する（ステップ３７３）。
また、全てのメンバー端末５０からの支払い許可情報４８が揃えば、生成部３２が、今回受信した支払い許可情報４８と一時記憶部に一時的に記憶されていた支払い許可情報４８とを連結し、一時記憶部に書き戻す（ステップ３７４）。

次いで、受信部３９が受信した情報が、店舗端末１０から受信した合計額請求情報２７であった場合について説明する。ここで、合計額請求情報２７は、上述したように、請求コードと合計額と署名データと使用可能クレジット会社と店舗の証明書とを含む。
この場合、受信部３９は、合計額請求情報２７に含まれる署名データが正しいかどうかを、合計額請求情報２７に含まれる店舗の証明書によって判定し（ステップ３８１）、正しくなければ処理を終了する。

一方、署名データが正しければ、決定部３３が、合計額請求情報２７に含まれる請求コード及び合計額と、署名データが正しい旨の情報とを画面に表示する（ステップ３８２）。また、決定部３３は、代表者が各メンバーに対する割り勘額（支払額）を指定する操作を画面上で行うと、この操作を受け付ける（ステップ３８３）。これにより、決定部３３は、メンバーごとの支払額を決定する（ステップ３８４）。
次に、生成部３２は、ステップ３７４で一時記憶部に書き戻された情報のメンバーごとの部分に支払額に付加することにより、支払い許可情報２８を生成する（ステップ３８５）。
その後、送信部３１が、支払い許可情報２８を店舗端末１０に送信し（ステップ３８６）、処理を終了する。

尚、この動作例では、店舗通知情報２６に含まれる署名データが正しいかどうか、支払い許可情報４８に含まれる署名データが正しいかどうか、及び、合計額請求情報２７に含まれる署名データが正しいかどうかを判定するようにしたが、これらの判定は必ずしも行わなくてよい。

図２３は、メンバー端末５０の動作例を示したフローチャートである。
図示するように、メンバー端末５０では、受信部５９が、他の装置から情報を受信し、その情報が如何なる情報であるかを判定する（ステップ５５１）。
まず、受信部５９が受信した情報が、代表者端末３０から受信した事前徴収額通知情報４６であった場合について説明する。ここで、事前徴収額通知情報４６は、上述したように、請求コードと署名データと使用可能クレジット会社と店舗の証明書と事前徴収額とを含む。
この場合、受信部５９は、事前徴収額通知情報４６に含まれる署名データが正しいかどうかを、事前徴収額通知情報４６に含まれる店舗の証明書によって判定し（ステップ５６１）、正しくなければ処理を終了する。

一方、署名データが正しければ、決定部５３が、事前徴収額通知情報４６に含まれる請求コード及び事前徴収額と、署名データが正しい旨の情報とを画面に表示する（ステップ５６２）。また、決定部５３は、メンバーが支払上限額を指定する操作を画面上で行うと、この操作を受け付ける（ステップ５６３）。これにより、決定部５３は、メンバーごとの支払上限額を決定する（ステップ５６４）。
次に、生成部５２は、事前徴収額通知情報４６に含まれる使用可能クレジット会社を画面に表示し、メンバーが使用するクレジット会社を選択してクレジットカード情報を入力する操作を画面上で行うと、この操作を受け付ける（ステップ５６５）。これにより、生成部５２は、支払い要求情報６６を生成する（ステップ５６６）。ここで、支払い要求情報６６は、請求コードと署名データと店舗の証明書と支払上限額とクレジットカード情報とを含む。
その後、送信部５１が、支払い要求情報６６をクレジット会社サーバ７０に送信し（ステップ５６７）、処理を終了する。

次に、受信部５９が受信した情報が、クレジット会社サーバ７０から受信した支払い許可情報６８であった場合について説明する。ここで、支払い許可情報６８は、上述したように、請求コードと支払上限額と暗号化情報と署名データとクレジット会社の証明書とを含む。
この場合、受信部５９は、支払い許可情報６８に含まれる署名データが正しいかどうかを、支払い許可情報６８に含まれるクレジット会社の証明書によって判定し（ステップ５７１）、正しくなければ処理を終了する。

一方、署名データが正しければ、生成部５２が、支払い許可情報４８を生成する（ステップ５７２）。ここで、支払い許可情報４８は、支払い許可情報６８と同じ内容の情報である。
その後、送信部５１が、支払い許可情報４８を代表者端末３０に送信し（ステップ５７３）、処理を終了する。

尚、この動作例では、事前徴収額通知情報４６に含まれる署名データが正しいかどうか及び支払い許可情報６８に含まれる署名データが正しいかどうかを判定するようにしたが、この判定は必ずしも行わなくてよい。

以上述べたように、本実施の形態では、割り勘による支払いにおいて、複数のメンバーの各々が店舗に対して支払いを行うのではなく、代表者端末３０が店舗端末１０と通信することにより複数のメンバーの支払いを行うことを前提とし、支払いの決済に必要な情報は、店舗の公開鍵で暗号化された状態で代表者端末３０を通過して店舗端末１０へ送られるようにした。これにより、支払いの決済に必要な情報は、その内容が代表者に知られることなく、店舗に伝わるようになった。

また、本実施の形態では、図１４のような画面上で割り勘額を決定するようにした。これにより、支払いの決済はクレジット会社だけでなく、インターネットで決済できるシステムを有する電子マネー等によっても行うことが可能となった。その結果、例えば、電子マネーによる支払いを複数の電子マネーによる支払いに分割すれば、電子マネーの残額が少ない場合でも、その残額を充当して支払うことが可能となる。

最後に、本実施の形態を適用するのに好適なコンピュータのハードウェア構成について説明する。
図２４は、このようなコンピュータのハードウェア構成例を示した図である。図示するように、コンピュータは、演算手段であるＣＰＵ（Central Processing Unit）９０ａと、Ｍ／Ｂ（マザーボード）チップセット９０ｂを介してＣＰＵ９０ａに接続されたメインメモリ９０ｃと、同じくＭ／Ｂチップセット９０ｂを介してＣＰＵ９０ａに接続された表示機構９０ｄとを備える。また、Ｍ／Ｂチップセット９０ｂには、ブリッジ回路９０ｅを介して、ネットワークインターフェイス９０ｆと、磁気ディスク装置（ＨＤＤ）９０ｇと、音声機構９０ｈと、キーボード／マウス９０ｉと、フレキシブルディスクドライブ９０ｊとが接続されている。

尚、図２４において、各構成要素は、バスを介して接続される。例えば、ＣＰＵ９０ａとＭ／Ｂチップセット９０ｂの間や、Ｍ／Ｂチップセット９０ｂとメインメモリ９０ｃの間は、ＣＰＵバスを介して接続される。また、Ｍ／Ｂチップセット９０ｂと表示機構９０ｄとの間は、ＡＧＰ（Accelerated Graphics Port）を介して接続されてもよいが、表示機構９０ｄがＰＣＩ Ｅｘｐｒｅｓｓ対応のビデオカードを含む場合、Ｍ／Ｂチップセット９０ｂとこのビデオカードの間は、ＰＣＩ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）バスを介して接続される。また、ブリッジ回路９０ｅと接続する場合、ネットワークインターフェイス９０ｆについては、例えば、ＰＣＩ Ｅｘｐｒｅｓｓを用いることができる。また、磁気ディスク装置９０ｇについては、例えば、シリアルＡＴＡ（AT Attachment）、パラレル転送のＡＴＡ、ＰＣＩ（Peripheral Components Interconnect）を用いることができる。更に、キーボード／マウス９０ｉ、及び、フレキシブルディスクドライブ９０ｊについては、ＵＳＢ（Universal Serial Bus）を用いることができる。

ここで、本発明は、全てハードウェアで実現してもよいし、全てソフトウェアで実現してもよい。また、ハードウェア及びソフトウェアの両方により実現することも可能である。また、本発明は、コンピュータ、データ処理システム、コンピュータプログラムとして実現することができる。このコンピュータプログラムは、コンピュータにより読取り可能な媒体に記憶され、提供され得る。ここで、媒体としては、電子的、磁気的、光学的、電磁的、赤外線又は半導体システム（装置又は機器）、或いは、伝搬媒体が考えられる。また、コンピュータにより読取り可能な媒体としては、半導体、ソリッドステート記憶装置、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、リジッド磁気ディスク、及び光ディスクが例示される。現時点における光ディスクの例には、コンパクトディスク−リードオンリーメモリ（ＣＤ−ＲＯＭ）、コンパクトディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）及びＤＶＤが含まれる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態には限定されない。本発明の精神及び範囲から逸脱することなく様々に変更したり代替態様を採用したりすることが可能なことは、当業者に明らかである。

１０…店舗端末、３０…代表者端末、５０…メンバー端末、７０…クレジット会社サーバ、１１，３１，５１，７１…送信部、１２，３２，５２，７２…生成部、３３，５３…決定部、３４…検査部、７３…管理部、７４…データベース

Claims (10)

1. 割り勘による支払いを支援するシステムであって、
   被支払者により使用される被支払者コンピュータと、
   複数の支払者を含むグループの代表者により使用されるコンピュータであって、当該代表者により当該複数の支払者の各支払者に対して決定された第１の金額を示す第１の金額情報を送信するコンピュータである代表者コンピュータと、
   前記複数の支払者の各々により使用される複数のコンピュータであって、各コンピュータが、前記代表者コンピュータにより送信された当該各コンピュータを使用する支払者に対する前記第１の金額情報を受信し、当該第１の金額情報で示される前記第１の金額に応じた第２の金額を示す第２の金額情報を送信する複数のコンピュータである複数の支払者コンピュータと、
   支払いの決済を行うコンピュータであって、前記複数の支払者コンピュータの各コンピュータにより送信された前記第２の金額情報を受信し、当該第２の金額情報で示される前記第２の金額に応じた支払いの決済のための決済情報を保持すると共に、当該決済情報を前記被支払者の公開鍵で暗号化した暗号化情報と、当該第２の金額情報とを、当該各コンピュータに送信する決済コンピュータと
   を含み、
   前記複数の支払者コンピュータの各コンピュータは、前記決済コンピュータにより送信された前記暗号化情報及び前記第２の金額情報を、前記代表者コンピュータに送信し、
   前記代表者コンピュータは、前記複数の支払者コンピュータの全てから前記暗号化情報及び前記第２の金額情報を受信したことを条件として、当該複数の支払者コンピュータの各コンピュータについて、当該各コンピュータにより送信された前記暗号化情報と、前記被支払者に対する支払額を分割した金額であって、当該各コンピュータにより送信された前記第２の金額に応じた金額である第３の金額を示す第３の金額情報とを、前記被支払者コンピュータに送信し、
   前記被支払者コンピュータは、前記複数の支払者コンピュータの各コンピュータについて、当該各コンピュータにより送信された前記暗号化情報を前記被支払者の秘密鍵で復号することにより前記決済情報を取得し、当該決済情報と、当該各コンピュータにより送信された前記第３の金額情報とを、前記決済コンピュータに送信する、システム。
2. 前記被支払者コンピュータは、前記代表者コンピュータが前記第１の金額情報を送信する前に、請求の合計額を、当該代表者コンピュータに送信し、
   前記代表者コンピュータは、前記被支払者コンピュータにより送信された前記合計額を前記代表者が分割した割り勘額を、前記第１の金額に決定し、
   前記複数の支払者コンピュータの各コンピュータは、前記割り勘額を前記第２の金額とし、
   前記代表者コンピュータは、前記割り勘額を前記第３の金額とする、請求項１のシステム。
3. 前記代表者コンピュータは、事前徴収額を前記第１の金額に決定し、
   前記複数の支払者コンピュータの各コンピュータは、前記事前徴収額に応じて当該各コンピュータを使用する支払者が決定した支払上限額を前記第２の金額とし、
   前記被支払者コンピュータは、前記代表者コンピュータが前記複数の支払者コンピュータの全てから前記暗号化情報及び前記第２の金額情報を受信した後に、請求の合計額を、当該代表者コンピュータに送信し、
   前記代表者コンピュータは、前記被支払者コンピュータにより送信された前記合計額を前記代表者が前記支払上限額を超えないように分割した割り勘額を、前記第３の金額に決定する、請求項１のシステム。
4. 複数の支払者を含むグループの代表者が使用する代表者コンピュータと、当該複数の支払者の各々が使用する複数の支払者コンピュータと、被支払者が使用する被支払者コンピュータと、支払いの決済を行う決済コンピュータとが、割り勘による支払いを支援する方法であって、
   前記代表者コンピュータが、前記代表者により前記複数の支払者の各支払者に対して決定された第１の金額を示す第１の金額情報を、前記複数の支払者コンピュータの当該各支払者が使用するコンピュータに送信するステップと、
   前記複数の支払者コンピュータの各コンピュータが、前記代表者コンピュータにより送信された前記第１の金額情報で示される前記第１の金額に応じた第２の金額を示す第２の金額情報を、前記決済コンピュータに送信するステップと、
   前記決済コンピュータが、前記複数の支払者コンピュータの各コンピュータにより送信された前記第２の金額情報で示される前記第２の金額に応じた支払いの決済のための決済情報を保持すると共に、当該決済情報を前記被支払者の公開鍵で暗号化した暗号化情報と、当該第２の金額情報とを、当該各コンピュータに送信するステップと、
   前記複数の支払者コンピュータの各コンピュータが、前記決済コンピュータにより送信された前記暗号化情報及び前記第２の金額情報を、前記代表者コンピュータに送信するステップと、
   前記代表者コンピュータが、前記複数の支払者コンピュータの全てから前記暗号化情報及び前記第２の金額情報を受信したことを条件として、当該複数の支払者コンピュータの各コンピュータについて、当該各コンピュータにより送信された前記暗号化情報と、前記被支払者に対する支払額を分割した金額であって、当該各コンピュータにより送信された前記第２の金額情報で示される前記第２の金額に応じた金額である第３の金額を示す第３の金額情報とを、前記被支払者コンピュータに送信するステップと、
   前記被支払者コンピュータは、前記複数の支払者コンピュータの各コンピュータについて、当該各コンピュータにより送信された前記暗号化情報を前記被支払者の秘密鍵で復号することにより前記決済情報を取得し、当該決済情報と、当該各コンピュータにより送信された前記第３の金額情報とを、前記決済コンピュータに送信するステップと
   を含む、方法。
5. 前記代表者コンピュータが前記第１の金額情報を送信するステップの前に、前記被支払者コンピュータが、請求の合計額を、当該代表者コンピュータに送信するステップを更に含み、
   前記代表者コンピュータが前記第１の金額情報を送信するステップでは、前記被支払者コンピュータにより送信された前記合計額を前記代表者が分割した金額である割り勘額を、前記第１の金額に決定し、
   前記複数の支払者コンピュータの各コンピュータが前記第２の金額情報を送信するステップでは、前記割り勘額を前記第２の金額とし、
   前記代表者コンピュータが前記暗号化情報と前記第３の金額情報とを送信するステップでは、前記割り勘額を前記第３の金額とする、請求項４の方法。
6. 前記複数の支払者コンピュータの各コンピュータが前記暗号化情報及び前記第２の金額情報を送信するステップの後に、前記被支払者コンピュータが、請求の合計額を、前記代表者コンピュータに送信するステップを更に含み、
   前記代表者コンピュータが前記第１の金額情報を送信するステップでは、事前徴収額を前記第１の金額に決定し、
   前記複数の支払者コンピュータの各コンピュータが前記第２の金額情報を送信するステップでは、前記事前徴収額に応じて当該各コンピュータを使用する支払者が決定した支払上限額を前記第２の金額とし、
   前記代表者コンピュータが前記第３の金額情報を送信するステップでは、前記被支払者コンピュータにより送信された前記合計額を前記代表者が分割した割り勘額を、前記第３の金額に決定する、請求項４の方法。
7. 複数の支払者を含むグループの代表者が使用する代表者コンピュータと、当該複数の支払者の各々が使用する複数の支払者コンピュータと、被支払者が使用する被支払者コンピュータと、支払いの決済を行う決済者が使用する決済コンピュータとが、割り勘による支払いを支援する方法であって、
   前記被支払者コンピュータが、請求を識別する請求識別子と、当該請求の合計額と、少なくとも当該請求識別子及び当該合計額に前記被支払者の秘密鍵で署名した第１の署名データと、前記被支払者の公開鍵である第１の公開鍵とを、前記代表者コンピュータに送信するステップと、
   前記代表者コンピュータが、前記被支払者コンピュータにより送信された前記請求識別子、前記合計額、前記第１の署名データ及び前記第１の公開鍵と、前記代表者が当該合計額を分割することにより前記複数の支払者の各支払者に対して決定した割り勘額とを、前記複数の支払者コンピュータの当該各支払者が使用するコンピュータに送信するステップと、
   前記複数の支払者コンピュータの各コンピュータが、前記代表者コンピュータにより送信された前記請求識別子、前記合計額、前記第１の署名データ、前記第１の公開鍵及び前記割り勘額を、前記決済コンピュータに送信するステップと、
   前記決済コンピュータが、前記複数の支払者コンピュータの各コンピュータにより送信された前記第１の署名データ及び前記第１の公開鍵に基づいて当該各コンピュータにより送信された前記請求識別子及び前記合計額が改竄されていないと判定された場合に、当該各コンピュータにより送信された前記割り勘額の支払いの決済のための情報であって、当該決済の受付を識別する受付識別子と、当該請求識別子と、当該割り勘額とを含む情報である決済情報を保持すると共に、当該決済情報を当該第１の公開鍵で暗号化した暗号化情報と、当該割り勘額と、少なくとも当該暗号化情報及び当該割り勘額に前記決済者の秘密鍵で署名した第２の署名データと、前記決済者の公開鍵である第２の公開鍵とを、当該各コンピュータに送信するステップと、
   前記複数の支払者コンピュータの各コンピュータが、前記決済コンピュータにより送信された前記暗号化情報、前記割り勘額、前記第２の署名データ及び前記第２の公開鍵を、前記代表者コンピュータに送信するステップと、
   前記代表者コンピュータが、前記複数の支払者コンピュータの全てから前記暗号化情報及び前記割り勘額を受信し、かつ、当該割り勘額の合計と前記合計額とが一致することを確認した旨の情報を前記代表者から受け付けたことを条件として、当該複数の支払者コンピュータの各コンピュータについて、当該各コンピュータにより送信された前記暗号化情報、前記割り勘額、前記第２の署名データ及び前記第２の公開鍵を、前記被支払者コンピュータに送信するステップと、
   前記被支払者コンピュータは、前記代表者コンピュータにより送信された前記第２の署名データ及び前記第２の公開鍵に基づいて前記代表者コンピュータにより送信された前記暗号化情報及び前記割り勘額が改竄されていないと判定された場合に、当該暗号化情報を前記被支払者の秘密鍵で復号することにより前記決済情報を取得し、当該決済情報に含まれる前記受付識別子及び前記請求識別子と、当該割り勘額とを、前記決済コンピュータに送信するステップと
   を含む、方法。
8. 複数の支払者を含むグループの代表者が使用する代表者コンピュータと、当該複数の支払者の各々が使用する複数の支払者コンピュータと、被支払者が使用する被支払者コンピュータと、支払いの決済を行う決済者が使用する決済コンピュータとが、割り勘による支払いを支援する方法であって、
   前記被支払者コンピュータが、請求を識別する請求識別子と、少なくとも当該請求識別子に前記被支払者の秘密鍵で署名した第１の署名データと、前記被支払者の公開鍵である第１の公開鍵とを、前記代表者コンピュータに送信するステップと、
   前記代表者コンピュータが、前記被支払者コンピュータにより送信された前記請求識別子、前記第１の署名データ及び前記第１の公開鍵と、前記代表者が前記複数の支払者の各支払者に対して決定した事前徴収額とを、前記複数の支払者コンピュータの当該各支払者が使用するコンピュータに送信するステップと、
   前記複数の支払者コンピュータの各コンピュータが、前記代表者コンピュータにより送信された前記請求識別子、前記第１の署名データ及び前記第１の公開鍵と、前記代表者コンピュータにより送信された前記事前徴収額に応じて当該各コンピュータを使用する支払者が決定した支払上限額とを、前記決済コンピュータに送信するステップと、
   前記決済コンピュータが、前記複数の支払者コンピュータの各コンピュータにより送信された前記第１の署名データ及び前記第１の公開鍵に基づいて当該各コンピュータにより送信された前記請求識別子が改竄されていないと判定された場合に、当該各コンピュータにより送信された前記支払上限額を上限とした支払いの決済のための情報であって、当該決済の受付を識別する受付識別子と、当該請求識別子と、当該支払上限額とを含む情報である決済情報を保持すると共に、当該決済情報を当該第１の公開鍵で暗号化した暗号化情報と、当該支払上限額と、少なくとも当該暗号化情報及び当該支払上限額に前記決済者の秘密鍵で署名した第２の署名データと、前記決済者の公開鍵である第２の公開鍵とを、当該各コンピュータに送信するステップと、
   前記複数の支払者コンピュータの各コンピュータが、前記決済コンピュータにより送信された前記暗号化情報、前記支払上限額、前記第２の署名データ及び前記第２の公開鍵を、前記代表者コンピュータに送信するステップと、
   前記被支払者コンピュータが、前記請求識別子と、前記請求の合計額と、少なくとも当該請求識別子及び当該合計額に前記被支払者の秘密鍵で署名した第３の署名データと、前記第１の公開鍵とを、前記代表者コンピュータに送信するステップと、
   前記代表者コンピュータが、前記被支払者コンピュータにより送信された前記第３の署名データ及び前記第１の公開鍵に基づいて前記被支払者コンピュータにより送信された前記請求識別子及び前記合計額が改竄されていないと判定された場合に、前記複数の支払者コンピュータの全てから前記暗号化情報及び前記支払上限額を受信したことを条件として、当該複数の支払者コンピュータの各コンピュータについて、当該各コンピュータにより送信された前記暗号化情報、前記支払上限額、前記第２の署名データ及び前記第２の公開鍵と、前記代表者が当該合計額を当該支払上限額を超えないように分割することにより前記複数の支払者の各支払者に対して決定した割り勘額とを、前記被支払者コンピュータに送信するステップと、
   前記被支払者コンピュータは、前記代表者コンピュータにより送信された前記第２の署名データ及び前記第２の公開鍵に基づいて前記代表者コンピュータにより送信された前記暗号化情報及び前記支払上限額が改竄されていないと判定された場合に、当該暗号化情報を前記被支払者の秘密鍵で復号することにより前記決済情報を取得し、当該決済情報に含まれる前記受付識別子及び前記請求識別子と、前記代表者コンピュータにより送信された前記割り勘額とを、前記決済コンピュータに送信するステップと
   を含む、方法。
9. 複数の支払者を含むグループの代表者により使用され、当該複数の支払者の各々が使用する複数の支払者コンピュータと、被支払者が使用する被支払者コンピュータとに接続された、割り勘による支払いを支援する装置であって、
   前記代表者の操作に応じて、前記複数の支払者の各支払者に対して第１の金額を決定する決定部と、
   前記決定部により前記複数の支払者の各支払者に対して決定された前記第１の金額を示す第１の金額情報を、前記複数の支払者コンピュータの当該各支払者が使用するコンピュータに送信する送信部と、
   前記送信部により送信した前記複数の支払者の各支払者に対する前記第１の金額情報で示される前記第１の金額に応じた第２の金額の支払いの決済のための決済情報を前記被支払者の公開鍵で暗号化した暗号化情報と、当該第２の金額を示す第２の金額情報とを、前記複数の支払者コンピュータの当該各支払者が使用するコンピュータから受信する受信部と
   を含み、
   前記送信部は、前記複数の支払者コンピュータの全てから前記暗号化情報及び前記第２の金額情報を受信したことを条件として、当該複数の支払者コンピュータの各コンピュータについて、当該各コンピュータにより送信された前記暗号化情報と、前記被支払者に対する支払額を分割した金額であって、当該各コンピュータにより送信された前記第２の金額に応じた金額である第３の金額を示す第３の金額情報とを、前記被支払者コンピュータに送信する、装置。
10. 複数の支払者を含むグループの代表者により使用され、当該複数の支払者の各々が使用する複数の支払者コンピュータと、被支払者が使用する被支払者コンピュータとに接続された、割り勘による支払いを支援する装置として、コンピュータを機能させるプログラムであって、
    前記コンピュータを、
    前記代表者の操作に応じて、前記複数の支払者の各支払者に対して第１の金額を決定する決定部と、
    前記決定部により前記複数の支払者の各支払者に対して決定された前記第１の金額を示す第１の金額情報を、前記複数の支払者コンピュータの当該各支払者が使用するコンピュータに送信する送信部と、
    前記送信部により送信した前記複数の支払者の各支払者に対する前記第１の金額情報で示される前記第１の金額に応じた第２の金額の支払いの決済のための決済情報を前記被支払者の公開鍵で暗号化した暗号化情報と、当該第２の金額を示す第２の金額情報とを、前記複数の支払者コンピュータの当該各支払者が使用するコンピュータから受信する受信部と
    して機能させ、
    前記送信部は、前記複数の支払者コンピュータの全てから前記暗号化情報及び前記第２の金額情報を受信したことを条件として、当該複数の支払者コンピュータの各コンピュータについて、当該各コンピュータにより送信された前記暗号化情報と、前記被支払者に対する支払額を分割した金額であって、当該各コンピュータにより送信された前記第２の金額に応じた金額である第３の金額を示す第３の金額情報とを、前記被支払者コンピュータに送信する、プログラム。

Images