JP2005115585A - 支払い分割購入方法 - Google Patents

Abstract

【課題】
複数人での支払いの分割を行う際に、代表者が費用を集める必要がなく、各人もその場で費用を支払う必要のない方法を提案する。
【解決手段】
支払い者、または予約の委託者（以下委託者とする）の携帯端末から必要な情報を取得する。委託者の端末画面に確認メッセージを表示するなどして、代表者が支払いや予約のために個人情報を取得したい旨を委託者に伝え、委託者はその内容を確認し、ボタン押下などの動作により内容を承諾する。承諾すると委託者の端末は代表者の端末に支払いまたは予約に必要な情報を送信し、代表者はこの作業を全員分繰り返して情報を取得したのち、サービス提供者にこれらの情報をまとめて送信する。サービス提供者はこの情報を利用して、代表者のみからではなく代表者と各委託者から直接代価を徴収する。
【選択図】 図１

Description

本発明は携帯電話やPDAなどの携帯端末を用いた決済において複数人で支払いを分割することや複数人のチケット予約、および購入を同時に行う方式に関する。

複数人で支払いを分割する場合、代表者が人数など様々な要因を考慮して各個人の支払額を算出し、その料金を徴収する。その際に、支払いの効率的な分割を支援する装置が考案されている（特許文献1）。

また、携帯端末を利用してグループ単位でチケット予約や申し込みを行う場合、
（１）代表者をたて、代表者が全員分を処理する
（２）各々がそれぞれの端末から操作を行う
といういずれかの方法が考えられる。しかし、（１）の場合は代表者が各個人情報の把握、金銭管理を行う必要がある。（２）の場合も同じ作業を各々が行うため非効率であり、1度の申し込みで全員分を処理できないため、グループ単位での申し込みが難しいという問題点がある。この問題に対し、携帯端末内の電話帳を利用して、代表者が一度に複数人の予約を行う方法が提案されている（特許文献2）。

特開２０００−１１２６３号公報

特開２００２−３６６８１７号公報

支払いの分割を行う際、代表者は支払額を算出した後、支払い者全員から支払い料金を徴収する必要がある。このため、料金の徴収し忘れや、回収した料金が予定していた金額と一致しないといった問題が生じる可能性がある。

複数人の予約においても、特許文献２の電話帳を利用する方式では、あらかじめ各個人の情報が代表者の携帯端末内に格納されている必要がある。
本発明では支払いの分割を行う際に、代表者が費用を集める必要がなく、各人もその場で費用を支払う必要のない方法を提案する。また、複数人の予約を行う場合に、各個人の情報を代表者があらかじめ把握していなくても決済を個人単位で行える方法を提案する。

上記の課題を解決するために、支払い者、または予約の委託者（以下委託者とする）の携帯端末から必要な情報を取得する。具体的には代表者の携帯端末と委託者の携帯端末とで通信する。まず、委託者の端末画面に確認メッセージを表示するなどして、代表者が支払いや予約のために個人情報を取得したい旨を委託者に伝える。委託者はその内容を確認し、ボタン押下などの動作により内容を承諾する。承諾すると委託者の端末は代表者の端末に支払いまたは予約に必要な情報を送信する。代表者はこの作業を全員分繰り返して情報を取得したのち、サービス提供者にこれらの情報をまとめて送信する。サービス提供者はこの情報を利用して、代表者のみからではなく代表者と各委託者から直接代価を徴収する。サービス提供者が代表者から送信された情報だけで個人が特定できない場合、例えば得た情報が代表者と各委託者の電話番号のみなどの場合は、サービス提供者が他のサービス提供者や個人情報保持者と連携して必要な個人情報を得る。この仕組みにより、代表者と委託者は互いの携帯端末を通信させるだけで支払い分割や予約・購入が行える。

特にプライバシーを考慮する場合は、端末間での通信やサービス提供者と通信でやりとりされる個人情報を暗号化する。他にも個人情報の利用を厳密に行うために、通信で得た情報を一定期間、あるいは一定回数のみ有効となるようにしてもよく、暗号化と組み合わせてもかまわない。また、代表者は決済に必要な個人情報、例えば口座番号やクレジットカード番号などを取得するが、通信の確認に必要な内容以外の委託者の個人情報は暗号化し、代表者はその内容を知ることはできない。これにより、代表者は委託者の詳細な個人情報を知ることなく、複数人の各種チケットの申し込みや予約などが可能になり、決済を個人単位で行える。

本発明により、支払い分割を行う際に生じる料金計算や徴収の手間が省け、簡便に支払い分割を行える。また、各種予約も代表者が委託者の情報を完全に把握する必要がなくなり、精算も個人単位で行えるようになる。

以下、図面を用いて本発明の実施例を説明する。なお、本発明が実施例に限定されるものではない。

図1は本発明の一実施例の全体構成を示す。本発明は代表者の携帯端末30と委託者の携帯端末40、50とサービス提供者60、サービスを実行するアプリケーション70、およびサービスを提供する際に利用される個人情報を保管している個人情報保持者80と各々をつなぐ広域通信網10と条件が揃えば形成される近距離通信網20という構成からなる。

携帯端末30、40、50としては、携帯電話やPDAを想定している。これらの携帯端末の中には、無線技術を利用した通信や端末同士をケーブルで接続して通信する有線通信などを利用した近距離通信機能を持つものもある。この機能を持つ携帯端末や他の情報端末が互いに通信を行い、近距離通信網20を形成する。サービス提供者60は携帯端末用のサービスを提供し、サービスを実行する専用アプリケーション70を保持している。専用アプリケーション70は携帯端末を操作することで広域通信網10、あるいは近距離通信網20を介して利用者の端末に格納される。個人情報保持者80は携帯端末ユーザの個人情報を保持しており、例えば携帯電話のキャリアがこれにあたる。なお、サービス提供者60と個人情報保持者80は同一でもかまわない。携帯端末30、40、50、サービス提供者60、個人情報保持者80は広域通信網10を利用することで互いに通信可能である。また、近距離通信網20が形成可能であるなら、それを介して互いに通信することもできる。

図2は、携帯端末内に格納されるアプリケーションが持つ処理内容と端末間通信でやりとりされる情報の構造を示したものである。代表者用アプリケーション300、委託者用アプリケーション400とも暗号鍵を生成する機能310、410と暗号化を処理する機能320、420があり、これを利用して通信を行うことによりセキュリティを保障する。また、支払い分割、予約・購入を行える機能を持つ。あるいは、既存の電卓アプリケーション、支払い分割アプリケーション、予約アプリケーションなどを連動させて処理を行える機能を持つ。端末間で通信される内容は、代表者からの送信情報10000としてアプリ起動メッセージ11000、確認メッセージ12000、情報要求メッセージ13000があると考え、委託者からの送信情報として応答メッセージ21000、個人情報送信メッセージ22000、送信拒否メッセージ23000の各3種類のメッセージが考えられる。アプリ起動メッセージ11000は委託者用アプリケーション400を起動するものである。この起動用メッセージ11000が必要ない場合は確認メッセージ12000で代替してもよい。セキュアな通信を行う場合は、確認・応答メッセージとして暗号化に必要な情報も送信する。

図3は、本発明における端末間の操作や通信について簡単に示したものであり、UMLのアクティビティ図で記述している。まず、代表者は支払い分割／予約アプリケーションである代表者用アプリケーション300を起動し、分割方針の指定や支払い総額の入力、予約内容の決定などの必要な操作を行う（ステップ1000）。それらの情報を基にアプリケーションが必要な情報の準備を行う（ステップ1010）。その後、各委託者の端末と通信するために委託者の携帯端末の通信路を確立する（ステップ1020）。通信路として広域通信網10、近距離通信網20のどちらを利用してもよい。端末同士が通信できる状態になったのち、代表者が委託者の端末に対し代表者からの送信情報10000として各種情報を送信する（ステップ1030）。これを受けた委託者の携帯端末に委託者アプリケーション400が存在する場合、これを起動し（ステップ1070）、代表者用アプリケーション300同様初期化を行う（ステップ1080）。存在しない場合は専用アプリケーション70を取得する（ステップ1060）。その後、アプリケーションを起動し初期化を行う（ステップ1080）。なお、委託者があらかじめアプリケーションを起動し、通信可能な状態（ステップ1090）にしておいてもよい。このように代表者用アプリケーション300と委託者用アプリケーション400が通信可能な状態になったのち、お互いに様々なデータ10000、20000を送信して処理を行い（ステップ1030、1090）、委託者の個人情報を得る。代表者はこの作業を委託者の人数だけ繰り返す。委託者の数が多いときは小グループに分割し、各グループで情報を取得したあとで全体の代表者に収集した情報を送信してもよい。その場合も各携帯端末間で行う作業は図3の通りである。

支払い分割を行う場合、分割する金額を代表者が作業を行う前にアプリケーション300に入力する必要がある。入力方法としては、端末操作による入力だけでなく、飲食店などのPOS端末や別途設置された情報端末との通信、レシートなどに記述された情報の読み取りなど、どのような方法でもかまわない。同様に飲食店などで代表者が店に支払いを行う場合も、実際に代表者が店に料金を払って各委託者からの代金を自身の口座に振り込む、代表者の携帯端末とPOS端末などの店側の通信端末の通信によりオンラインで精算を行うなど様々な方法が考えられ、支払い方法について特に限定しない。

予約の場合も予約内容の入力や指定が必要になる。このため、サービス提供者60は、パンフレットに記載された番号などのIDを入力する、携帯端末から予約情報を提供しているWebサイトに接続して希望のものを選ぶなど、利用者にとって操作しやすいものを手段を提供してもよい。

図4は、図3での携帯端末間の通信について詳しく示したアクティビティ図であり、例として公開鍵暗号を用いてセキュリティを確保する方法を説明する。端末間の通信が行える状態では、代表者用アプリケーション300と委託者用アプリケーション400は既に起動済みで通信可能状態である。また、代表者、委託者のアプリケーションは起動後、初期化（ステップ1010、1090）を行う。ここでは初期化時に暗号鍵生成部310、410により、各端末が一時的な公開鍵と暗号鍵を作成しているものとする。
まず、代表者用アプリケーション300が確認メッセージ12000として自身の公開鍵12100を送信する。必要ならば鍵以外の情報も送信する（ステップ2000）。これを受けた委託者アプリケーション400（ステップ2060）は、応答メッセージ21000として自身の公開鍵21100を送信する（ステップ2070）。この場合も必要なら鍵以外の情報も送信する。このやりとりにより各端末の公開鍵をお互い入手し、互いに送受信可能な状態にあることが認識できる。

次に、代表者用アプリケーション300は情報要求メッセージ13000として委託者の端末40に送信する。このメッセージには委託者の公開鍵21100を用いて暗号化された代表者の情報13100や要求内容が含まれる。これを受けとった委託者アプリケーション400は自身の暗号鍵で復号し、その内容を端末の画面に表示する。委託者がその内容に納得し、承認を意味する動作を行うと（GUIで表示されたボタンを押すなど）、先ほど受け取った代表者アプリケーションの公開鍵12100で委託者の個人情報を暗号化し、個人情報送信メッセージ22000として代表者の携帯端末20に送信する（ステップ2120）。もしくは、委託者がその場で代金を支払う、予約のキャンセルを行うなどの個人情報を送信しない場合は、送信拒否メッセージ23000を代表者アプリケーション300に送信する（ステップ2120）。このメッセージを受け取った代表者はその旨を端末操作により処理する（ステップ2050）。送信拒否情報を送信した委託者の情報はサービス提供者60には送信しない。

以上で端末間の通信は終了する。この後、暗号化された個人情報を受け取った代表者アプリケーション300では、この情報を一時保存し、代表者は委託者数だけこの動作を繰り返す（ステップ1020〜1040）。このあと、蓄積された情報を一度自身の暗号鍵で復号し、全ての情報を再度サービス提供者60が提供する公開鍵により暗号化してサービス提供者60に送信する。なお、サービス提供者の公開鍵は専用アプリケーション70内に格納されているものとする。または、代表者がサービス提供者60と通信した際に取得してもよい。

この仕組みにより、端末間の通信が暗号化され、プライバシーが守られる。暗号化の一例として公開鍵暗号で説明したが、秘密鍵暗号を利用した方式でも同様に利用できる。なお、代表者と委託者が既知の間柄などで個人情報をやり取りすることに問題がない場合、端末間の通信は暗号化する必要がない場合も考えられる。この場合、委託者側に専用アプリケーションは必要なく、個人情報の送信に既存の情報通信アプリケーションを利用してもよい。例として、いくつかの携帯電話では端末同士で携帯電話の番号を赤外線で送信する機能がある。これを利用し、代表者用アプリケーション300でこの情報を取得するようにすれば委託者用アプリケーションは必要なくなる。得た電話番号を元にサービス提供者が必要な個人情報を入手し、支払い分割や予約、および購入の手続きを行えばよい。

図5は、サービス提供者側の処理の概要を示したアクティビティ図である。まず、サービス提供者は代表者から送られた情報を受け取る（ステップ3000）。そして受け取った情報を復号し、内容を確認する。その情報が電話番号などの個人情報を指定するIDのみの場合は個人情報保持者80に対しその情報を送信し、必要な個人情報を得る（ステップ3010）。こうして得た個人情報を基に各委託者に確認の案内3100を通知する（ステップ3020）。支払いの場合だと支払金額などを、予約の場合だと予約内容などを通知する。サービス提供者が委託者からの確認を必要としない場合は、そのまま支払い分割または予約・精算の処理を行う（ステップ3030）。委託者からの確認が必要な場合は、サービス提供者は予め定められた一定期間、委託者からの確認メッセージ3110を待つ（ステップ3050）。全員から確認メッセージ3110が帰ってきた場合、あるいは一定期間を経過した場合、支払い分割、または予約・精算の処理を行う（ステップ3030）。予約、精算が終了すると代表者に処理完了の連絡を行う（ステップ3040）。

図6は、図5の支払い／予約処理のうち、支払い方法について表した図であり、複数人で支払いの分割を行う場合の処理の流れを示す。まず、委託者からの確認が必要ない場合について説明する。この場合、各委託者は精算処理を代表者に完全に委託している状態であるため、まず代表者に支払い代金の分割方法について確認をとる（ステップ4000、4010）。分割方法は代表者用アプリケーション300を起動した後の操作により決定されており、その内容を表示する。代表者から最終確認が得られると処理内容に承認したことになり、得た個人情報を基に代表者、各委託者の精算を行う（ステップ4020）。精算が完了すると図5にあるように、結果を代表者に連絡して処理を終了する（ステップ3040）。

次にサービス提供者60が委託者からの確認を必要とする場合について説明する。まず、全委託者から確認情報3110が返信されている場合は、代表者が最初に決めた支払い代金の分割方法を全委託者が承諾しているため、委託者からの確認がない場合と同じ処理を行う。全員から確認が返信されていない場合、確認情報3110を送信した委託者の人数や名前を代表者に送信する（ステップ4030）。代表者はその情報を確認し、処理方法を検討・決定する（ステップ4040）。具体的には以下のようなものを考えている。
１．確認情報を送信した委託者と代表者で頭割り
２．代表者が最初に決定した分割案に基づく代金を、確認の取れた委託者から徴収し、足りない分は代表者が負担する
３．確認情報を受けつける期間を延長する
４．代表者も含め、確認情報を送信した委託者から最初に決定した分割案に基づく代金を徴収し、未確認である委託者の代金はサービス提供者が回収
支払いの方針が決定し、代表者からの確認が取れたのち、サービス提供者70は代金を徴収し、精算を行う（ステップ4050）。

図7は、図5における支払い／予約処理のうち、予約に関する内容を表した図である。予約の場合は希望しているものを確実に提供できる保障がないため、空席情報を調べるなどして予約内容の確認を行う（ステップ5000）。確認をすることにより、予約可能な場合、意図通りには予約できないが代替案がある場合、予約が不可能な場合の3通りの可能性がある。

まず、予約可能な場合は代表者に連絡をする（ステップ5030）。代表者はその内容を確認して予約を行う（ステップ5040）。この操作により、グループ単位で予約ができたので、個人単位で精算を行う（ステップ5050）。この一連の処理を行う際に委託者の確認の有無が問題になる。予約を行う時点では代表者が仮予約できるように、各委託者からの確認がなくても予約可能とする。しかし、精算を行う際（ステップ5050）は代金徴収の確認を行う必要があるため、図5、図6に示すような処理を行う。この場合、図6のステップ4000にある支払い代金は分割内容で決めたものではなく予約に必要な金額となる。

次に代替案がある場合について説明する。この場合、その内容を全員が受け入れるか確認をする必要がある。委託者からの確認を行う必要がない場合は、全ての責任が代表者にあるものとし、以下の処理は予約可能なときと同じである。委託者からの確認を行う場合、その代替案の内容を全員に送信する（ステップ5060）。そして、その内容について各委託者と代表者の意見を一定期間待つ（ステップ5070）。委託者の意見を徴収した結果により代表者が予約を行うかどうか判断する（ステップ5080）。予約する場合は再び予約確認を行い、空き状況を確認する（ステップ5000）。予約を行わない場合は次に示す予約不可の場合と同じ処理を行う。また、代替案に関して一定期間内に返信しない委託者をどのように扱うか（予約に賛成とみなすかキャンセルとするか）は代表者に一任する。

最後に予約不可能の場合について説明する。この場合、予約ができないためその旨を全員に通知する（ステップ5010）。その後、一定期間全員の確認メッセージを待つ（ステップ5020）。この処理は代表者が各委託者の状況を把握しやすいように用意しているものであり、なくてもかまわない。その後は図5のステップ3040にあるように、得た情報を代表者に連絡する。なお、サービス提供者は予約が不可能な場合でも、受信した予約内容などから代替案を提案してもよいものとする。

本発明の一実施例における全体構成を表す図。 携帯端末に格納されるアプリケーションの構造を表す図。 携帯端末間での通信を表すアクティビティ図。 個人情報を取得時に行う通信を表すアクティビティ図。 支払い分割・予約処理をするサーバ側の処理を示すアクティビティ図。 支払い分割をするサーバ側の処理を示すアクティビティ図。 予約処理をするサーバ側の処理を示すアクティビティ図。 代表者から各委託者に送信するメッセージを示す図。 委託者から代表者に送信するメッセージを表す図。

符号の説明

10…広域通信網、20…近距離通信網、30…代表者の携帯端末、60…サービス提供者、70…支払い分割・予約アプリケーション、300…代表者用アプリケーション、400…委託者用アプリケーション、13000…情報要求メッセージ、22000…個人情報送信メッセージ

Claims (13)

1. 債務を複数の債務者で分担して支払う場合において、債務者のそれぞれが所有しているコンピュータから、ネットワークを通じてそれぞれの個人情報を代表債務者の所有するコンピュータに集め、その情報を、ネットワークを通じて債権者に伝えることで、支払いを債務者で分担することを特徴とする支払い方法。
2. 複数人で商品購入を行う場合において、購入者のそれぞれが所有しているコンピュータから、ネットワークを通じてそれぞれの個人情報を代表購入者の所有するコンピュータに集め、その情報を、ネットワークを通じて購入先に伝えることで、纏めて商品の購入を行い、支払いは各購入者に対して行われることを特徴とする購入方法。
3. 請求項１もしくは請求項２において、債務者あるいは購入者の個人情報を代表者に送付する前に、予め選択された項目には暗号化を施し、代表者に予め定められた情報のみが平文で提示され、暗号化部分は債権者、購入先、あるいは個人情報提供者すなわち債権者あるいは購入者の個人情報を保持しており、債権者あるいは販売者の必要に応じて債務者あるいは購入者の個人情報を安全に債権者あるいは販売者に伝えるもののみが復号可能とすることを特徴とする暗号化方法。
4. 請求項１もしくは請求項２において、代表債務者あるいは代表購入者がネットワークを通じて各債務者あるいは代表者の個人情報を取得する際に、各債務者あるいは購入者が個人情報を送ることを承認したのちに個人情報を送ることを特徴とする支払い方法
5. 請求項４において、各債務者および購入者が個人情報を送ることを承認することにより、支払い手続きを代表債務者に、あるいは購入手続きを代表購入者に委託することを特徴とする支払い方法。
6. 請求項１もしくは請求項２において、債権者および販売者が債務者および購入者に支払いあるいは購入に関する情報を提示し、各債務者および購入者の意思を確認する機構を備えていることを特徴とする支払い方法あるいは購入方法。
7. 請求項６において、各債務者および購入者の意思確認が必要ない場合、代表債務者あるいは代表購入者が予め決定した方法で支払いの分担を行うことを特徴とする支払い方法。
8. 請求項６において、債務者および購入者全員の意思確認を予め定められた期間だけ待ち、債務者および購入者の意思確認が取れた後で支払いの分担を行うことを特徴とする支払い方法。
9. 請求項８において、予め定められた期間を経過した場合、代表債務者および代表購入者が全員の支払い分担方法を決定することを特徴とする支払い方法。
10. 請求項２において、購入商品の有無に応じてその後に行う購入手続きを変更することを特徴とする購入方法。
11. 請求項１０において、購入商品が存在しない場合、商品販売者が全購入者に内容を伝え、購入者からの返信確認を行うことを特徴とする購入方法。
12. 請求項１０において、購入商品が存在する場合、その後の支払いの分担以外の購入手続きを代表購入者に一任することを特徴とする購入方法。
13. 請求項１０において、購入商品は存在しないが代替商品がある場合、商品販売者が購入者からの意思確認を行わないときは代表購入者に支払い分担以外の購入手続きを一任し、意思確認を行う際は代替商品の内容を全購入者に連絡し、全購入者の意見を集めて代表購入者に伝え、最終的に代表購入者の意思決定により購入を行うことを特徴とする購入方法。
    

Images