(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022082415
(43)【公開日】2022-06-01
(54)【発明の名称】決済方法及びプログラム
(51)【国際特許分類】
G06Q 20/38 20120101AFI20220525BHJP
【FI】
G06Q20/38 310
【審査請求】未請求
【請求項の数】13
【出願形態】OL
(21)【出願番号】P 2021097571
(22)【出願日】2021-06-10
(62)【分割の表示】P 2020193908の分割
【原出願日】2020-11-20
(71)【出願人】
【識別番号】514136107
【氏名又は名称】株式会社アクリート
(74)【代理人】
【識別番号】100159547
【弁理士】
【氏名又は名称】鶴谷 裕二
(74)【代理人】
【識別番号】100223365
【弁理士】
【氏名又は名称】大町 真義
(72)【発明者】
【氏名】田中 優成
(72)【発明者】
【氏名】上川 佳一
(72)【発明者】
【氏名】吉田 勝
【テーマコード(参考)】
5L055
【Fターム(参考)】
5L055AA75
(57)【要約】 (修正有)
【課題】クレジットカード決済等のキャッシュレス決済の確実性、情報セキュリティ、信用を維持しつつ決済の仲介を実現する方法及びプログラムを提供する。
【解決手段】顧客から顧客の取引相手への課金の決済処理を仲介する方法であって、顧客に対してユニークに割り当てられた電話番号が準備されており、事業者装置106は、課金を識別する第1の識別情報に関連付けられた課金の情報を、顧客装置102から受け取りS122、第1の識別情報と、課金の情報とを含む情報から決済処理を特定し、第1の識別情報と、取引相手携帯端末104から電話番号に宛てた通信において伝達された第2の識別情報とを比較した比較結果に基づいて、顧客装置102に、決済処理を送信する。
【選択図】
図1
【特許請求の範囲】
【請求項1】
顧客から前記顧客の取引相手への課金の決済処理を仲介する方法であって、
前記顧客に対してユニークに割り当てられた電話番号が準備されており、
前記課金を識別する第1の識別情報に関連付けられた前記課金の情報を、前記顧客の管理する装置から受け取るステップと、
前記第1の識別情報と、前記課金の情報とを含む情報から、決済処理を特定するステップと、
前記第1の識別情報と、前記取引相手の管理する携帯端末から前記電話番号に宛てた通信において伝達された第2の識別情報とを比較した比較結果に基づいて、前記顧客の管理する装置に、前記決済処理を実行させるメッセージを送信するステップと、
を有する決済を仲介する方法。
【請求項2】
前記メッセージを送信するステップは、
前記比較結果に基づいて、前記取引相手の管理する携帯端末が前記決済処理を取り扱うように、前記決済処理を扱うURIを含むメッセージを、前記通信の発信元電話番号に送信するステップと、
前記決済処理に関する情報を、前記決済処理を実行するシステムに提供するステップと、
前記取引相手の管理する携帯端末と前記決済処理を実行するシステムとの間でなされた前記決済処理の結果を、前記決済処理を実行するシステムから受信するステップと、
前記決済処理の結果を少なくとも前記顧客の管理する装置に伝達するステップと、
を含む、請求項1に記載の決済を仲介する方法。
【請求項3】
前記第1の識別情報は、前記発信元電話番号の一部分を含む、
請求項2に記載の決済を仲介する方法。
【請求項4】
前記第1の識別情報は、前記顧客又は前記取引相手によって指定された第1のストリングを含む、
請求項1ないし3のうちいずれか1項に記載の決済を仲介する方法。
【請求項5】
前記第1の識別情報は、前記顧客の管理する装置により生成された第2のストリングを含む、
請求項1ないし4のうちいずれか1項に記載の決済を仲介する方法。
【請求項6】
前記顧客の管理する前記装置に、第3のストリングを送信するステップを更に有し、
前記第1の識別情報は、前記第3のストリングを含む、
請求項1ないし5のうちいずれか1項に記載の決済を仲介する方法。
【請求項7】
前記メッセージは、SMS、RCS及びMMSのうちのいずれかによって転送される、
請求項1ないし6のうちいずれか1項に記載の決済を仲介する方法。
【請求項8】
前記通信は、音声通話若しくはSMS、RCS又はMMSによるメッセージ通信である、
請求項1ないし7のうちいずれか1項に記載の決済を仲介する方法。
【請求項9】
前記決済処理を実行するシステムに提供するステップは、
前記顧客の管理する装置からの指示を待って、前記決済処理に関する情報を、決済処理を実行するシステムに提供するステップ、
を含む、請求項1ないし8のうちいずれか1項に記載の決済を仲介する方法。
【請求項10】
前記顧客の管理する装置が取り扱う前記決済処理が、前記取引相手の管理する携帯端末が取り扱う決済処理と同一の決済処理であることがわかるように、前記顧客の管理する装置及び前記取引相手の管理する携帯端末のうちの少なくともいずれか1つに、前記決済処理を識別する情報を送信するステップ、
を更に有する、請求項1ないし9のうちいずれか1項に記載の決済を仲介する方法。
【請求項11】
前記決済処理を識別する情報は、前記決済処理に割り当てられたシンボルの情報である、
請求項1ないし10のうちいずれか1項に記載の決済を仲介する方法。
【請求項12】
前記シンボルの情報は、
前記決済処理の結果が完了したか又は未決済で終了したかに応じて、それぞれ異なる第2のシンボルの情報又は第3のシンボルの情報を含む、
請求項11に記載の決済を仲介する方法。
【請求項13】
請求項1ないし12のうちいずれか1項に記載の決済を仲介する方法をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、決済方法及びプログラムに関する。
【背景技術】
【0002】
クレジットカード決済、キャッシュレス決済など、現金が用いられない決済手段が利用される場合には、クレジットカードの情報、キャッシュレス決済に関する情報が不正に利用されないようにすることが重要である。
【0003】
例えば、クレジットカードの番号などの情報が店舗のシステム内に保存されてしまうと、この保存された情報は、クレジットカードの不正使用などの利用につながる危険性があることが指摘されている。このため、店舗などでは、クレジットカードの番号などの情報が店舗のシステム内に記憶されることを避けると共に、決済会社が提供する専用のハードウエア機器を準備して、この専用のハードウエアによりクレジットカードを読み取らせることで、決済を行わせるようにしている場合がある。
【0004】
例えば、POSシステムによって(または、顧客のモバイル機器によって)一意の一回限りのデジタルコードであって、上記取引を識別するデジタルコードを生成するステップと、上記の一意の一回限りのデジタルコードとともに取引データを、第1デジタルネットワーク経路を介して、POSシステムのオーナーの銀行へ送信するステップと、上記の一意の一回限りのデジタルコードおよび上記モバイル機器により発行された課金情報を、第2デジタルネットワーク経路を介して、上記銀行へ並行して送信するステップと、銀行によって(または支払システム/取引ネットワークによって)、POSシステムからの取引データとモバイル機器によって発行された課金情報とをマージし、上記マージが成功した場合、上記取引を決済するステップとを有し、マージは、上記コードが合致した場合、常に成功する。このように、銀行は、当該銀行でマージされた、異なる経路を介して、上記取引が承認されたことを通知される技術が存在する(例えば、特許文献1参照)。
【0005】
また、他の例では、利用者によるクレジットカード決済の要求に基づいて、前記利用者の携帯端末にSMSにおけるショートメッセージを送信する情報管理サーバであって、決済情報を入力させる画面のURLを取得する識別情報取得部と、前記識別情報取得部で取得した前記URLを前記ショートメッセージに付加する識別情報付加部と、前記URLを付加した前記ショートメッセージを前記利用者の前記携帯端末に送信する送信部と、を備えている。前記情報管理サーバは、サービス提供事業者の情報端末から利用者情報とサービスに必要な情報とを受信し、前記利用者情報と前記サービスに必要な情報とを組み合わせて第1の情報を生成する制御部を有し、制御部は、前記情報端末から前記利用者情報と前記サービスに必要な情報とを受信して前記第1の情報を生成する度に、前記情報端末が有する個人情報DBから前記携帯端末の電話番号を抽出して前記携帯端末にショートメッセージを送信し、前記画面には、前記利用者情報及び前記サービスに必要な情報が表示される技術が存在する(例えば、特許文献2参照)。
【0006】
このような従来の技術では、取引相手の機密情報を保護しつつ、取引相手の本人確認を行うために、専用のハードウエアを用意したり、予め取引相手の本人確認を行うための情報をデータベースに格納するシステムを準備するなどの高度なシステムを導入したりすることが必要とされていた。例えば、小規模の店舗、出先の営業スタッフがクレジットカードの決済などを行う場合においても、専用のクレジットカード処理のための機器を準備することが必要であった。
【0007】
また、クレジットカード以外によるキャッシュレス決済であっても、取引相手は、専用のアプリケーションを自己の携帯端末に予めインストールして事前にクレジットカードを登録するか事前に金銭のチャージ又はオートチャージの設定をするなどして、そのアプリケーションの決済の仕組みが使えるように、そのアプリケーションを使用するために要求される事前準備が必要であった。
【0008】
また、例えば、SMS又はメールなどにより金銭の支払いを要求するメッセージが突然送られてきた場合には、そのメッセージの信頼性に関して、利用者に疑問を抱かせる場合も発生していた。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特許第6085037号公報
【特許文献2】特許第6431377号公報
【発明の概要】
【発明が解決しようとする課題】
【0010】
開示の技術は、クレジットカード決済等のキャッシュレス決済のセキュリティ、完全性、信用を維持しつつ決済の仲介を実現することができる環境を提供することを目的としている。
【課題を解決するための手段】
【0011】
開示の技術は、顧客から前記顧客の取引相手への課金の決済処理を仲介する方法であって、前記顧客に対してユニークに割り当てられた電話番号が準備されており、前記課金を識別する第1の識別情報に関連付けられた前記課金の情報を、前記顧客の管理する装置から受け取るステップと、前記第1の識別情報と、前記課金の情報とを含む情報から、決済処理を特定するステップと、前記第1の識別情報と、前記取引相手の管理する携帯端末から前記電話番号に宛てた通信において伝達された第2の識別情報とを比較した比較結果に基づいて、前記顧客の管理する装置に、前記決済処理を実行させるメッセージを送信するステップと、を有する決済を仲介する方法を提供する。
また、開示の技術は、上記方法をコンピュータに実行させるプログラムを提供する。
【発明の効果】
【0012】
開示の技術によれば、クレジットカード決済等のキャッシュレス決済のセキュリティ、完全性、信用を維持しつつ決済の仲介を実現する環境を提供することができる。
【図面の簡単な説明】
【0013】
【
図1】
図1Aは、顧客に対してユニークな電話番号を割り当てる手順を示す図である。
図1Bは、事業者装置が他の装置との間で決済の仲介を行うシーケンスの概略を示す図である。
【
図2】
図2Aは、各装置の情報交換の概要を示す図である。
図2Bは、事業者装置のハードウエア構成を示す図である。
【
図3】
図3は、事業者装置における決済サービス生成処理フローの概略を示す図である。
【
図4】
図4は、事業者装置における電話着信処理フローの概略を示す図である。
【
図5】
図5は、取引相手携帯端末管理テーブルのエントリ無効化処理の概略を示す図である。
【
図6】
図6は、取引相手携帯端末へのメッセージ送信処理の概要のフローを示す図である。
【
図7】
図7は、事業者装置の機能ブロック図である。
【
図8】
図8は、事業者装置が顧客装置に表示させる表示画面と、事業者装置が取引相手携帯端末に表示させる表示画面の例を示す図である。
【
図9】
図9は、事業者装置が顧客装置に表示させる表示画面と、事業者装置が取引相手携帯端末に表示させる表示画面の例を示す図である。
【
図10】
図10は、事業者装置が顧客装置に表示させる表示画面と、事業者装置が取引相手携帯端末に表示させる表示画面の例を示す図である。
【
図11】
図11は、事業者装置が顧客装置に表示させる表示画面と、事業者装置が取引相手携帯端末に表示させる表示画面の例を示す図である。
【
図12】
図12は、事業者装置が顧客装置に表示させる表示画面と、事業者装置が取引相手携帯端末に表示させる表示画面の例を示す図である。
【
図13】
図13A及び
図13Bは、事業者装置が顧客装置に表示させる表示画面と、事業者装置が取引相手携帯端末に表示させる表示画面の例を示す図である。
図13Cは、取引相手携帯端末に表示された不正な画面の例である。
【
図14】
図14は、顧客の各々に対応して予め割り当てられた受信用の電話番号を管理する電話番号割当テーブルの例を示す図である。
【
図15】
図15は、決済サービス管理テーブルの例を示す図である。
【
図16】
図16は、取引相手携帯端末管理テーブルの例を示す図である。
【発明を実施するための形態】
【0014】
以下、図面を参照しながら実施の形態について説明する。
本明細書では、以下の用語を用いる。
事業者とは、事業者の顧客が、顧客の取引相手との間で取り交わされた契約に基づく決済を仲介する者を言う。事業者は、クレジットカード会社など実質的にキャッシュレス決済を実行する会社(決済業者)との間に入って決済業者に決済を依頼する企業である。
【0015】
顧客及び事業者は、顧客の取引相手が管理するクレジットカード番号、キャッシュレス決済の情報など、決済において特定の者以外が取り扱うことがセキュリティ上望ましくない秘密とされることが求められる情報を扱わない者である。
決済業者は、取引相手のクレジットカードの情報又はキャッシュレス決済の情報など、決済において特定の者以外が取り扱うことがセキュリティ上望ましくない秘密とされることが求められる情報を扱うことができる者である。
【0016】
また、顧客の管理下にある装置を顧客装置と言い、取引相手の管理下にある装置を取引相手携帯端末と言い、事業者の管理下にある装置を事業者装置と言い、決済業者の管理下にある装置を決済業者装置と言う。
【0017】
以下に示す実施の形態における方法の各ステップは、矛盾の無い限り順番を入れ換えて実行されてもよい。また、複数のステップが同時に実行されてもよい。各ステップは、メモリに記憶されたプログラムを実行することにより実現されてもよい。また各ステップの一部は、オペレーティングシステム或いはハードウエアにより実現されてもよい。また、各ステップが全て実行される必要はなく、特定のステップの実行が省略されてもよい。また、1つのステップが複数回実行されてもよい。また、複数のステップが、繰り返し実行されてもよい。各ステップは排他的なものではなく、矛盾の無い限り組み合わせることができる。
【0018】
開示の方法をコンピュータに実行させるプログラムは、非一時的(non-transitory)な記憶媒体に格納され得る。非一時的なメモリとしては、RAM,ROM、USBメモリ、DVDなどが挙げられるが、これらに限定されるものではない。プログラムの一部は、リエントラントなかたちで実行されてもよい。プログラムは、複数の処理対象の各々に対応した複数の相互に独立に処理されるタスクによって実質的に同時に実行されてもよい。
また、各実施形態は、ハードウエアの装置としてインプリメントされ得る。
【0019】
すなわち、請求項に記載された方法又はプログラムの順序とは異なる順序で実行される技術、或いは一部の処理が同時に実行される技術も、当該請求項に規定された発明の技術的範囲に属することは言うまでもない。
図1Aは、顧客に対してユニークな電話番号を割り当てる手順を示す図である。事業者は、事業者の顧客に対して、ユニークな電話番号を割り当てる。
【0020】
この電話番号は、以下のようにして利用される。例えば、顧客と、顧客に割り当てられた電話番号とを関連づけて、事業者の管理する装置の記憶部の電話番号割当テーブル(
図14)に記憶しておく。
図14に、この電話番号割当テーブルの具体例を示す。
【0021】
顧客は、顧客にユニークに割り当てられた電話番号を顧客の取引相手に伝達する。そして、取引相手は、取引相手の管理する取引相手携帯端末104を用いて、顧客にユニークに割り当てられた電話番号に電話をかけることで、事業者装置106は、取引相手携帯端末104を操作する取引相手が、いずれの顧客との間で取引を行っているのかを把握することができる。電話は、音声通話であってもよいし、電話番号を宛先としたメッセージ通信等であってもよい。
すなわち、事業者は、掛かってきた電話の電話番号(発信先電話番号)で、上記の電話番号割当テーブルを検索することによって、取引相手携帯端末104がいずれの顧客に対する取引相手の管理する取引相手携帯端末104であるかを特定することができる。
加えて、事業者は、掛かってきた電話の発信元電話番号から、取引相手の管理する取引相手携帯端末104の電話番号を知ることができる。したがって、事業者装置106は、発信元電話番号に対して通信を行うことで、取引相手携帯端末104との間で、確実な情報交換を実現することができる。
【0022】
なお、割り当てられる電話番号は、顧客に対して1つの電話番号が割り当てられてもよいし、顧客の支店毎(又は、営業担当者毎など)に異なる電話番号が割り当られてもよい。顧客の支店毎(又は、営業担当者毎など)に異なる電話番号が割り当られている場合には、取引相手携帯端末104が、いずれの顧客の支店(又は、営業担当者毎など)に対する取引相手の管理する取引相手携帯端末104であるのかを知ることができる。
【0023】
図1Bは、事業者装置106が他の装置と間で決済の仲介を行うシーケンスの概略を示す図である。
図1Bは、シーケンスの概略を示すものであるため、上下に隣接するシーケンスの間に他のシーケンスが入ってもよい。また、矛盾の無い限り、シーケンスの順番が入れ替わってもよい。また、1つのシーケンスが、時系列的に実行される双方向の複数の情報伝達のシーケンスを含んでもよい。
【0024】
以下に示す実施形態では、顧客と顧客の取引相手とが契約を取り交わし、顧客が取引相手から、所定の金額の料金を請求する場合(課金する場合)を想定している。課金を決済する処理を決済サービスと呼ぶ。取引相手携帯端末104と決済業者装置108とは、クレジットカード、キャシュレス決済などの決済サービスに利用される秘密の情報をやり取りすることができる。
【0025】
このような秘密の情報は、顧客装置102及び事業者装置106には伝達されないようにされる。このようにすることによって、クレジットカード決済又はキャッシュレス決済などの決済サービスに利用される秘密の情報の漏洩を防止することができる。
【0026】
図1Bのシーケンスは、顧客が管理する顧客装置102、顧客の取引相手が管理する取引相手携帯端末104、事業者が管理する事業者装置106及び決済業者が管理する決済業者装置108における処理のシーケンスの時間的順序を上から下に記載している。
【0027】
図2Aは、各装置の情報交換の概要を示す図である。顧客装置102と取引相手携帯端末104とは、インターネットなどのネットワーク、ブルートゥース(登録商標)などの近距離無線通信又は光通信(例えば、画面・紙媒体などに表示されたQRコード(登録商標)などとこのQRコード(登録商標)を撮像するカメラなどの光学系の読取装置との間の通信)などで電子的に情報の交換がなされてもよい。なお、顧客装置102と取引相手携帯端末104との識別情報などの伝達及びその情報の共有は、上記のような電子的な情報交換により共有される形、又は顧客装置102又は取引相手携帯端末104のいずれか又は双方の操作者によるキー入力などを受け取る形で実現されてもよい。後者の場合には、識別情報の共有は、ネットワークなどの電子的な情報交換のメカニズムを利用しない形(口頭による伝達、紙媒体に書かれた情報がキー入力されるなど)で実現され得る。
【0028】
顧客装置102と事業者装置106とは、通信経路102aを介して接続されている。また、取引相手携帯端末104と事業者装置106とは、通信経路104aを介して接続されている。取引相手携帯端末104と決済業者装置108とは、通信経路104bを介して接続されている。
顧客装置102及び取引相手携帯端末104には、事業者装置106が管理するウェブサイトを閲覧するブラウザなどの汎用の通信ソフトウエアがインストールされていることが望ましい。したがって、顧客装置102及び取引相手携帯端末104は、事業者装置106との接続に際して、接続のための専用のハードウエアを用意したり、汎用のブラウザ以外の専用のソフトウエアをインストールしたりすることは必ずしも必須ではない。
このようにすることによって、顧客装置102と取引相手携帯端末104は、一般的なセキュリティ機能を有するブラウザソフトウエアがインストールされた汎用的なPC又は携帯端末などの装置で実現され得る。このため、顧客装置102及び取引相手携帯端末104は、事業者装置106との情報交換に関して専用のハードウエアを準備したり又は専用のソフトウエアを予めインストールしたりする手間が省けることとなる。
なお、本実施形態は、所定のハードウエアを予め用意したり又は所定のソフトウエアを予めインストールしたりすることを本実施形態の対象外とするものではない。
【0029】
事業者装置106と決済業者装置108との間の通信106aは、あらかじめ定められたセキュアな通信方式で接続されていることが望ましい。事業者装置106から決済業者装置108には、顧客から取引相手に請求する課金情報と、その課金に関する管理情報を含む情報が伝達される。そして、決済業者装置108から事業者装置106に例えば管理情報に対応させて決済の結果が報告される。
【0030】
取引相手携帯端末104と決済業者装置108との間の通信104bは、決済業者があらかじめ定めた接続方式で接続され、クレジットカードの番号などの決済に必要な秘密の情報が伝達され得る。取引相手携帯端末104と決済業者装置108とのセキュアな通信104bは、顧客装置102及び事業者装置106が関与しない通信である。このため、顧客装置102及び事業者装置106は、クレジットカードの情報又はキャッシュレス決済に関する情報など、決済において秘密とされる情報を取り扱う必要がない。したがって、取引相手携帯端末104は、決済業者装置108との間で、秘密裡にクレジットカードの情報などの決済に必要な秘密情報の授受を安全に行うことができる。決済の結果は、決済業者装置108から取引相手携帯端末104にも伝達される。
【0031】
図1Bに戻る。
顧客装置102と取引相手携帯端末104とは、識別情報の共有がなされる。識別情報とは、顧客と取引相手との契約に基づき顧客から取引相手へ課金される決済サービスを事業者装置106が特定するために用いられる情報である。
【0032】
既に述べたように、顧客装置102と事業者装置106とは、通信経路102aを介して接続されている。また、取引相手携帯端末104と事業者装置106とは、通信経路104aを介して接続されている。すなわち、事業者装置106は、顧客装置102が扱う識別情報と、取引相手携帯端末104が扱う識別情報とを手掛かりに、通信経路102aと通信経路104aとの別個の通信において、同一の決済サービスを関連付けることができる。
【0033】
本明細書では、顧客装置102が扱う識別情報を第1の識別情報と称する場合がある。また、取引相手携帯端末104が扱う識別情報を第2の識別情報と称する場合がある。これらの第1の識別情報と第2の識別情報とが一致していれば、顧客装置102が扱う決済サービスと、取引相手携帯端末104が扱う決済サービスとが同じ決済サービスであることがわかる(或いは、同じ決済サービスである可能性が非常に高いことがわかる。)なお、ここで、「同じ決済サービスである可能性が非常に高い」ということは、顧客装置102が扱う決済サービスAと取引相手携帯端末104が扱う決済サービスBとが同一の決済サービスとして関連付けられてしまう意図しない事象の発生の可能性がゼロではないことを意味する。
【0034】
このような意図しない事象の発生は、何らかの人為的ミス、不正行為、通信上のエラー、意図的なネット上の攻撃、識別情報の偶然の一致などで発生する可能性があるということである。したがって、意図しない事象が発生する前に、これを検知し未然に防止するための確実性の担保を図ることが重要である。このような確実性の担保の観点からの実施形態のバリエーションの選択については、この実施形態が利用者にとって使いやすいものか否かの観点、フィッシングの防止の観点、スパムメッセージの拡散防止の観点、不正行為を行う者からのサイト攻撃の防止の観点などの多角的な観点から選択することが望ましい。その説明の詳細は個々の実施形態の構成のバリエーションに付随して説明する。
【0035】
図1Bのシーケンスを例にして以下に説明する。
顧客装置102の操作者と取引相手とが契約を結び、顧客から取引相手に課金する場合を想定する。そして、この場合に、顧客装置102及び事業者装置106がクレジットカード、キャッシュレス決済などの秘密にされるべき情報に関与することなく、取引相手携帯端末104と決済業者装置108との間での決済サービスを完結させることを実現するシーケンスの例が以下に記載されている。
【0036】
以下の例では、まず、取引相手携帯端末104の携帯電話番号の下4桁を識別情報に用いる例を取り上げる。なお、識別情報は、携帯電話番号の下4桁に限られるものではない、上述のように確実性を考慮した場合には、その他の識別情報が用いられてもよい。
なお例えば、取引相手携帯端末104の電話番号の全てを識別情報に用いる場合には、取引相手は、顧客装置を操作する顧客に、取引相手携帯端末104の電話番号の全てを伝えることになる。取引相手が、電話番号を顧客に開示したくない場合もあることを想定すると、携帯電話番号の全てを識別情報に用いることが妥当でない実施形態(例えば、携帯電話の電話番号を秘匿したい場合)では、識別情報に、電話番号の一部(例えば、取引相手携帯端末104の携帯電話番号の下4桁)を用いることが望ましい。なお、この場合には、電話番号の一部が一致する複数の取引相手携帯端末104から電話がかかってきた場合には、識別情報を手掛かりに、顧客装置102からの決済サービスを適切な取引相手携帯端末104と関連付けることができないことを防止する処理が必要となる。この処理については、後述する。
また、識別情報のその他の例については、実施形態の構成に関するそれぞれの変形例の説明の際において説明する。
【0037】
顧客装置102はログインID及びパスワードなどを用いて、事業者装置106とセキュアに接続されていることを前提とする。したがって、事業者装置106は、顧客装置102からの情報を受け取ると、どの顧客装置102から伝達された情報であるかを特定することができる。加えて、事業者装置106は、適切な顧客装置102に適切な情報を送信することができる。
【0038】
顧客装置102を操作する顧客は、取引相手携帯端末104を操作する取引相手から、たとえば取引相手携帯端末104の携帯電話番号の下4桁を、口頭により、あるいは紙媒体、画面の表示などにて伝えられ得る。(なお、携帯電話の下4桁の伝達は、これらに限られるものではなく、各種の通信、QRコード(登録商標)などの画像を読み取ることで伝達されてもよい。)
【0039】
シーケンスS122で、顧客装置102の操作者は、伝えられた下4桁を顧客装置102に入力すると共に、課金額を入力して、識別情報の下4桁及び課金額を事業者装置106に伝達する。
【0040】
事業者装置106は、シーケンスS122により伝達された、課金額、顧客装置102の情報に対して、個別の決済サービスを割り当てるように、この決済サービスに固有の管理情報を付与することが望ましい。この管理情報によって、この決済サービスを識別することができる。このようにすることによって、決済サービスが管理情報により特定されて、以後の処理が行われるようにすることができる。
【0041】
また、この管理情報は、シーケンスS122で、事業者装置106から顧客装置102に伝達されることが望ましい。顧客装置102の操作者は、管理情報を特定することにより、事業者装置106において取り扱われる課金に関する決済サービスを特定することができるようになる。
【0042】
シーケンスS124で、取引相手携帯端末104は、顧客に対しユニークに割り当てられた電話番号に宛てた通信をすること(例えば電話をかけること)により、事業者装置106に通信することで、第2の識別情報である取引相手携帯端末104の下4桁の電話番号を事業者装置106に伝えることができる。この通信は、音声電話であってもよいしメッセージ通信などであってもよい。
【0043】
顧客にユニークに割り当てられた電話番号(発信先電話番号)は、顧客から取引者に口頭にて伝えるか、顧客装置102の画面又は紙などの媒体を介して電話番号を取引相手に示すことで、取引相手に伝達されてもよい。あるいは、発信先電話番号の情報が含まれたQRコード(登録商標)を取引相手携帯端末104が読み取ることで、発信先電話番号が、取引相手携帯端末104に伝達されてもよい。あるいは、インターネット又はブルートゥース(登録商標)などの近距離無線通信によって、発信先電話番号が、取引相手携帯端末104に伝達されてもよい。取引相手は、取引相手携帯端末104を用いて、発信先電話番号宛に音声通話又はSMSなどのメッセージによる発信を行えばよい。
【0044】
なお、電話番号は、数字で構成されている。このため、メールアドレスなどのように数字以外にアルファベットなどの文字が含まれるアドレスよりも、口頭又は紙媒体などによる伝達によっても、伝達される情報に誤りが生じる可能性が少ないという利点がある。事業者装置106は、取引相手携帯端末104からの音声電話の着呼または、メッセージ通信の受信に伴って、発信元電話番号を抽出することにより、識別情報である下4桁の番号を知ることができる。したがって、取引相手携帯端末104の発信元番号の一部である下4桁の電話番号が識別情報として用いられる場合には、取引相手は、取引相手携帯端末104に識別情報を入力しなくてもよい。このことは、識別情報に取引相手携帯端末104の発信元番号の一部又は全部が識別情報に用いられるときに当てはまる。
【0045】
なお、取引相手携帯端末104の下4桁の電話番号が識別情報に用いられる場合には、たまたま、複数の決済サービスで、同じ番号が用いられる可能性、あるいは、複数の取引相手携帯端末の発信元電話番号の下4桁が一致する可能性が存在する。すなわち、顧客に対する複数の取引相手携帯端末104の下4桁の電話番号が偶然一致する場合があり得る。したがって、取引相手携帯端末104の電話番号の下4桁よりも多くの桁数の番号又はすべての桁を識別情報に用いるようにしてもよい。
携帯電話番号は、携帯電話にユニークに付与される番号であるから、取引相手携帯端末104のすべての桁を識別情報として用いることで、決済サービスを一意に特定することができる。なお、この場合には、顧客と取引相手が、同時に複数の決済サービスを利用しないことが前提となる。通常、買い物をするとき又はサービスを受けるときに、同じ取引相手により、同時に複数の決済サービスが利用されること(顧客から取引相手に複数の別個の課金の事象が発生すること)は事実上あり得ない事象であるから、全ての桁の携帯電話番号を識別情報に用いることとすれば、決済サービスを一意に特定することができる。
なお、複数の第1の識別情報と、複数の第2の識別情報とが一致する場合もあり得る。この場合、事業者装置106は、例えば一意に決済サービスを特定する管理情報を、取引相手携帯端末104から事業者装置106に送るよう促すよう報知する情報を顧客装置102及び取引相手携帯端末104の少なくともいずれか1つに送信してもよい。
なお、上記管理情報が取引相手携帯端末104から事業者装置106に送られてこない場合、あるいはその他の例外的な事象、例えば入力誤り、伝送での誤り、発信先電話番号宛に第三者から間違い電話がかかってきた場合などには、識別情報の一致によって同一の決済サービスを特定できないことがある。このような場合に対処する方法(確実性の確保)については後述する。
【0046】
処理140で、事業者装置106は、第1の識別情報と第2の識別情報とを比較する。例えば、顧客に1つの電話番号が割り当てられており、かつその顧客について複数の決済サービスが並行して発生することが無い場合には、事業者装置106が第1の識別情報と第2の識別情報とを比較し一致が確認できれば、一致が確認された顧客装置102からの情報と、取引相手携帯端末104からの情報とが、同一の決済サービスの情報であると判断してもよい。
【0047】
処理140で、識別情報1と識別情報2との一致が得られない場合には、顧客装置102及び取引相手携帯端末104のいずれかから送られてくる情報が事業者装置106に到達するのが遅れている可能性があるため、ある時間幅において識別情報1と識別情報2との一致の確認を繰り返すことが望ましい。そして、その時間幅が経過しても、識別情報1と識別情報2との一致が得られない場合には、事業者装置106は、該当する決済サービスについて、対応する取引相手携帯端末104が特定できない旨を顧客装置102に伝達してもよい。あるいは、この場合に、事業者装置106は該当する決済サービスをキャンセルして、該当する決済サービスがキャンセルされたことを顧客装置102に伝達してもよい。
このような事象が発生する原因としては、取引相手携帯端末104が、顧客に対してユニークに割り当てられた電話番号以外の電話番号に発信してしまった場合、人為的誤り又は伝送誤りなどで、事業者装置106に到達した第1の識別情報と第2の識別情報とが異なっている場合などが挙げられる。
【0048】
シーケンスS126で、処理140で一致が確認された決済サービスの処理を取り扱うURIの情報を含むSMSなどのメッセージが、取引相手携帯端末104の発信元電話番号宛に送信される。URIとは、決済サービスの処理が決済業者で行われるインターネットアドレス(URL)或いは、決済業者が決済サービスを実行するためになされる処理を遂行するために必要とされるアクセス情報、所定のAPIで定められた取引相手携帯端末104において実行されるコマンド、取引相手携帯端末104において決済サービスを扱うプログラムの実行に遷移させる情報などが挙げられる。なお、メッセージは、SMSに限られるものではなく、RCS、MMSなどであってもよい。或いは、SNSなどに付随した通信におけるメッセージなどであってもよい。
【0049】
第1の識別情報と第2の識別情報との一致が検出された場合にだけ、シーケンスS124において発信元電話番号にメッセージを送信することによって、誤って着信した通話の発信元電話番号に、或いは攻撃などを目的として故意に着信した電話の発信元電話番号に、決済のための上記メッセージが誤って送られてしまうことを避けることができる(或いは、このような状況を十分に防止することができる)。
【0050】
また、発信元電話番号(又は電話番号に準ずるアドレスを用いた通信の発信元)にメッセージを返すことによって、意図しない宛先へのメッセージ(例えば、スパムメッセージ)を発信してしまうことを避けることができる。また、電話番号を用いた通信又は電話番号に準ずるアドレスを用いた通信に対して対応することとし、通常のメールなどに応答することを避けることで、発信元を詐称した通信に対してメッセージを返してしまうことを避けることができる。また、大量のメールによるDOS攻撃などを避けることができる。このようにすることで、実施形態の信頼性を損なうなどの不利益を避けることができる。
【0051】
シーケンスS128で、取引相手携帯端末104は、URIに基づいて通信を開始する。この通信によって、取引相手携帯端末104は、適切な決済サービスの決済の手続を進めることができる。
【0052】
事業者装置106は、取引相手携帯端末104からURIに基づいてアクセスしてきた接続要求を受け取ってもよい。
シーケンスS130で、事業者装置106は、課金情報と、決済サービスを特定する管理情報を含む情報とともに、取引相手携帯端末104からの通信を、決済業者装置108にリダイレクトすることができる。
【0053】
シーケンスS132で、取引相手携帯端末104と決済業者装置108とが直接的に、決済サービスに関する情報の授受を行うことができる。このことにより、クレジットカードなどの情報又はキャッシュレス決済に関する情報など、決済において秘密にされるべき情報を取引相手携帯端末104と決済業者装置108とが直接的に授受することができる。このようにすることで、秘密にされるべき情報が第三者に漏洩されてしまうことを防止することができる。
この決済サービスの処理において、取引相手携帯端末104は、取引相手から決済に必要な情報を受け取り(154)、その情報を決済業者装置108に伝達することができる。決済サービスが完了した場合には、完了した旨が、決済業者装置108から取引相手携帯端末104に伝達され得る。なお、決済処理が完了しない場合には、完了しない旨の情報が決済業者装置108から取引相手携帯端末104に伝達され得る。
【0054】
シーケンスS134で、決済サービスが完了した場合には、管理情報と共に完了した旨が、決済業者装置108から事業者装置106に伝達され得る。なお、決済処理が完了しない場合には、管理情報と共に完了しない旨の情報が決済業者装置108から事業者装置106に伝達され得る。
【0055】
シーケンスS136で、決済サービスが完了した場合には、完了した旨が、事業者装置106から顧客装置102に伝達され得る。なお、決済処理が完了しない場合には、完了しない旨の情報が事業者装置106から顧客装置102に伝達され得る。
シーケンスS138で、決済サービスが完了した場合には、完了した旨が、事業者装置106から取引相手携帯端末104に伝達されてもよい。なお、決済処理が完了しない場合には、完了しない旨の情報が事業者装置106から取引相手携帯端末104に伝達されてもよい。
【0056】
<実施形態の総括>
以上のようにして、上記の実施形態において、顧客装置102及び事業者装置106は、取引相手携帯端末104及び決済業者装置108との間で授受されるクレジットカードなどの秘密にすべき情報或いはキャッシュレス決済に関する秘密にすべき情報に触れることなく、顧客が取引相手に課金した決済サービスを処理することができる。
【0057】
なお、上記のように通信経路102aと通信経路104aとの両者の経路を使い分ける理由について補足する。
まず、通信経路102aを介して、顧客装置102は、課金情報と第1の識別情報とを含む情報を事業者装置106に送る。通信経路104aを介して、取引相手携帯端末104は、取引相手携帯端末104の発信電話番号と第2の識別情報とを含む情報を事業者装置106に送る。
【0058】
取引相手携帯端末104が顧客に割り当てられた電話番号に通信を行うことで、事業者装置106は、取引相手携帯端末104が、どの顧客と関連しているのかを知ることができる。
事業者装置106は、第1の識別情報と第2の識別情報とが一致することを確認することで、顧客装置102の決済サービスと取引相手携帯端末104とを関連付けることができる。
【0059】
事業者装置106は、取引相手携帯端末104に、関連付けられた決済サービスを処理するためのURIを送る。
【0060】
取引相手携帯端末104は、得られたURIを元に、事業者装置106を経由して、リダイレクトなどで、決済業者装置108に直接アクセスすることが可能となる。その際、事業者装置106は、課金情報と決済サービスを特定する管理情報とを決済業者装置108に与える。
以上のように、取引相手携帯端末104は、顧客装置102及び事業者装置106に知られることなく、決済業者装置108との直接の通信によって、決済サービスを処理するためのクレジットカードなどの情報又はキャッシュレス決済などの秘密の情報を授受できる。通信経路102aと通信経路104aとを用いることによって、顧客装置102及び事業者装置106は、取引相手携帯端末104及び決済業者装置108の扱う秘密の情報の漏洩を回避しつつ、決済サービスを簡便に処理することができる。
【0061】
決済が終了すると、決済業者装置108から事業者装置106に決済サービスの決済の結果が伝達される。顧客装置102又は取引相手携帯端末104は、決済の結果を事業者装置106から受け取ることができる。
以上が、上記実施形態の処理の総括的な説明である。
【0062】
以上の実施形態では、取引相手携帯端末104の電話番号の一部又は全部を識別情報に用いた。識別情報の機能の1つは、同一の決済サービスの情報が、通信経路102aと通信経路104aとの両者の経路を用いて伝送されるため、これらの経路で送られる決済サービスを関連付けることであった。この機能を担保するには、取引相手携帯端末104の電話番号の情報以外に、又はこの情報に加えて、その他の情報を識別情報に用いることも可能である。或いは、複数の情報を組合わせて識別情報として用いることも可能である。
識別情報となり得る情報の例については後述する。
【0063】
なお、顧客装置102からの第1の識別情報と、取引相手携帯端末104からの第2の識別情報が一致する場合にのみ、事業者装置106から決済サービスの処理のURIを含むメッセージを取引相手携帯端末104に送信することに関する共通する効果の一つは、事業者装置106から、決済サービスの処理のURIを含むメッセージを誤った送信先に送信してしまうことを未然に防止できることが挙げられる。或いは、メッセージを誤った送信先に送信してしまうことの発生確率をゼロに近い値にまで減少させることが可能である。誤った送信先に、決済サービスの処理のURIを含むメッセージが送られた場合、そのメッセージを受信した携帯端末を管理する者に無用の混乱を与えることとなる。このような状況の発生を防止する(又は減少させる)ためには、顧客装置102からの第1の識別情報と、取引相手携帯端末104からの第2の識別情報とが一致する場合に、事業者装置106から決済サービスの処理のURIを含むメッセージを取引相手携帯端末104に送信することが望ましい。なお、誤った送信先に、決済サービスの処理のURIを含むメッセージが送られた場合の対処については、後述する。
【0064】
図2Bは、事業者装置106のハードウエア構成を示す図である。事業者装置106は、CPU251、ROM252、RAM253、ネットワークインターフェース255、入力インターフェース256、表示インターフェース257及び外部メモリインタフェース258を有する。
【0065】
ネットワークインターフェース255には、ネットワーク265が接続されている。ネットワーク265には、顧客装置102、取引相手携帯端末104、決済業者装置108等が接続される。入力インターフェース256には、タッチセンサ、カメラ及びマイクなどの入力デバイスが接続され得る。表示インターフェース257には、表示部267などの出力デバイスが接続され得る。外部メモリインタフェース258には、記憶媒体268が接続されている。本明細書及び図面に開示された実施形態を実現するコンピュータプログラムは、実体のある(tangible)非一時的でない(nontransitory)メモリである記憶媒体268、ROM252、又はRAM253に記憶され得る。このコンピュータプログラムはCPU251によって実行される。
また、このコンピュータプログラムは、ネットワーク265を介してダウンロードされ得る。これらのハードウエアは、バス254によって相互に接続されている。
図2Bに示される事業者装置106のハードウエアの構成は一例であって、その他のハードウエアが存在し得る。
【0066】
図3は、事業者装置106における決済サービス生成処理フローの概略を示す図である。各処理ステップについて順を追って説明する。
【0067】
以下の処理は、顧客装置102からの課金情報の受取のイベントが発生した時に、事業者装置106において開始されることが望ましい。
【0068】
[ステップS350]事業者装置106は、顧客装置から課金情報と、第1の識別情報とを受け取る。
【0069】
[ステップS352]事業者装置106は、顧客装置から課金情報及び第1の識別情報に対して、ユニークな管理情報を付与する。この管理情報によって、決済サービスを識別することができる。
【0070】
[ステップS354]事業者装置106は、管理情報、課金情報及び第1の識別情報を含む決済サービスのエントリを決済サービス管理テーブルに作成する。
図15は、決済サービス管理テーブル1500の一例を示している。
図15に示す決済サービス管理テーブル1500の詳細については後述する。
【0071】
以上のようにして、事業者装置106は、決済サービス管理テーブル1500を作成することで、決済サービスを管理することができる。なお、決済サービスを、
図15のような決済サービス管理テーブル1500で管理することが必須ではなく、その他の管理手法を用いてもよいことは言うまでもない。
【0072】
図4は、事業者装置106における電話着信処理フローの概略を示す図である。
【0073】
以下の処理は、顧客に割り当てられた電話番号に対する取引相手携帯端末104からの電話の着信のイベントが発生した時に、事業者装置106において開始されることが望ましい。なお、イベントは、電話の着信に限定されるものではなく、電話番号宛のメッセージの着信などのイベントであってもよい。
【0074】
[ステップS450]事業者装置106は、顧客に割り当てられた電話番号に着信した電話の発信元電話番号及び第2の識別情報を取得する。既に述べたように、発信元電話番号が第2の識別情報を含む場合があり得る。
図16に取引相手携帯端末管理テーブル1600の例を示す。取引相手携帯端末管理テーブル1600は、顧客に割り当てられた電話番号の各々に対応して作成されることが望ましい。取引相手携帯端末管理テーブル1600には、顧客に割り当てられた電話番号に着信した通話から得られた発信元電話番号、第2の識別情報などが格納されている。
図16に示す取引相手携帯端末管理テーブル1600の詳細は後述する。
【0075】
図4に戻る。
[ステップS452]事業者装置106は、同じ発信元番号の有効なエントリが、取引相手携帯端末管理テーブル1600に存在するかをチェックする。このチェックが肯定的な場合(Yes)、処理140は終了する。このチェックが否定的な場合(No)、処理はステップS454に移る。
この処理によって、取引相手携帯端末管理テーブル1600に既に重複した有効なエントリが重複して格納されることを避けることができる。
【0076】
[ステップS454]事業者装置106は、発信元電話番号及び第2の識別情報を含むエントリを取引相手携帯端末管理テーブル1600に作成する。
以上の処理によって、事業者装置106は、取引相手携帯端末104から顧客に割り当てられた電話番号宛に掛かってきた電話着信により得られた発信元電話番号及び第2の識別情報を含むエントリを、取引相手携帯端末管理テーブル1600に格納することができる。なお、発信元電話番号及び第2の識別情報を含む情報は、取引相手携帯端末管理テーブル1600を用いずに、他の管理手法により管理してもよいことは言うまでもない。
【0077】
図5は、事業者装置106によって行われる、取引相手携帯端末管理テーブル1600のエントリ無効化処理の概略を示す図である。
【0078】
顧客に対しユニークに割り当てられた電話番号宛に着信する電話には、顧客の取引相手からの電話以外に、誤って着信した電話、顧客の取引相手でない者が故意に掛けた電話などが存在する可能性がある。このような電話の発信元電話番号に決済サービスのためのメッセージを送る必要はない。そのため、このような電話によって取引相手携帯端末管理テーブル1600に生成されたエントリは、決済サービスに利用されないまま取引相手携帯端末管理テーブル1600に長い時間存在することとなる可能性がある。
このような状況を避けるために、所定の時間を定めて、決済サービスに利用されないまま、その所定の時間以上、取引相手携帯端末管理テーブル1600に存在しているエントリは、削除しておくことが望ましい。なぜなら、そのような決済サービスに利用される可能性が小さくなったエントリだからである。
なお、仮に削除されるべきでないエントリが誤って削除された場合には、取引相手携帯端末104から、同じ電話番号に再度電話をかけることとすればよい。
【0079】
図5の具体的な処理フローは以下のとおりである。
以下の処理は、割り込み処理により所定の間隔で実行されることが望ましい。
[ステップS552]取引相手携帯端末管理テーブルに、エントリが作成されてから所定の時間が経過しており、かつ対応する決済サービスが対応付けされていないエントリが存在するかをチェックする。チェック結果が肯定的であれば(Yes)、処理は、ステップS554に移る。チェック結果が否定的であれば(No)、処理140は終了する。
【0080】
[ステップS554]取引相手携帯端末管理テーブル1600の該当するエントリを無効化する。
以上の処理により、取引相手携帯端末管理テーブル1600に存在する不要なエントリを効果的に削除することができ、決済処理の信頼性を向上することができる。
【0081】
図6は、事業者装置106によって行われる取引相手携帯端末へのメッセージ送信処理の概要のフローを示す図である。この処理は、事業者装置106において実行される。
この処理は、決済サービス管理テーブル1500に決済サービスのエントリが作成されたイベントにより開始されることが望ましい。なお、決済サービス管理テーブル1500のエントリと取引相手携帯端末管理テーブル1600のエントリとのペアが破棄された場合にも、この一連の処理が開始されることが望ましい。
【0082】
[ステップS652]決済サービス管理テーブルのエントリの第1の識別情報と、取引相手携帯端末管理テーブルのエントリの第2の識別情報とが一致する新たなエントリのペアが存在するかがチェックされる。なお、過去にエントリのペアが存在していたが、ペアが破棄されたエントリ同士について、再度ペアを作ることは除外される。なぜなら、過去にペアが破棄されたエントリ同士は、ペアが容認されないエントリ同士だからである。すなわち、第1の識別情報と第2の識別情報とが一致していても、破棄されたペアについての取引相手携帯端末104は、対応する決済サービスを扱うことが適切ではないと既に判断されたからである。チェック結果が肯定的(Yes)であれば処理はステップS656に移る。チェック結果が否定的(No)であれば処理はステップS654に移る。
【0083】
[ステップS654]決済サービスのエントリが作成されてから所定の時間が経過したかがチェックされる。チェック結果が肯定的(Yes)であれば処理はステップS664に移る。チェック結果が否定的(No)であれば処理はステップS652に戻る。
【0084】
[ステップS656]決済サービス管理テーブル1500のエントリと、取引相手携帯端末管理テーブル1600のエントリとのペアを作成する。ペアを作成することで、取引相手携帯端末104と、決済サービスとが関連付けられることになる。なお、ペアを作成するとは、例えば、決済サービス管理テーブル1500のエントリ及び取引相手携帯端末管理テーブル1600のエントリが相互に関連付けられるように、夫々のエントリに関連付けの情報を格納することで実現することができる。なお、実施形態は、この例に限定されるものではない。
【0085】
[ステップS658]ペアの取引相手携帯端末管理テーブル1600の中の発信元電話番号に宛てて、決済サービス管理テーブル1500の対応するエントリで特定される決済サービスのURIを含むメッセージを送信する。
【0086】
[ステップS660]顧客装置102からのペアの容認の是非の連絡を受け取る。
[ステップS662]顧客装置から受け取った連絡が、ペアを容認する連絡かがチェックされる。チェック結果が肯定的(Yes)であれば処理は終了する。チェック結果が否定的(No)であれば処理はステップS666に移る。
【0087】
[ステップS664]決済サービスのタイムアウトを含むメッセージを顧客装置102に伝達する。この場合には、決済サービスが生成されてから、所定の時間が経過しても、決済ッサービスを取り扱う取引相手携帯端末104が見つからない状況であることになる。この場合の原因としては、取引相手携帯端末104が、誤った電話番号に電話をかけている場合、顧客装置102から送られる第1の識別情報又は取引相手携帯端末104から送られる第2の識別情報のいずれか又は双方に誤りが発生している場合などが考えられる。この場合には、タイムアウトを含むメッセージを顧客装置102に送ることとし、顧客装置102は、他の手段を用いて、取引相手携帯端末104が、適切なURIを取得できるようにする。適切なURIを取引相手携帯端末104に伝達する例としては、顧客装置102などに、適切なURIを含む機会読み取り可能なコード(例えばQRコード(登録商標))を表示させ、取引相手携帯端末104が、このQRコード(登録商標)を読み取るようにしてもよい。この具体例は後述する。
【0088】
[ステップS666]決済サービス管理テーブル1500のエントリと、取引相手携帯端末管理テーブル1600のエントリとのペアを破棄する。破棄されたペアが再びペアとならないように、該当する決済サービス管理テーブル1500のエントリと、該当する取引相手携帯端末管理テーブル1600のエントリには、破棄されたペアがわかるように、各々のエントリに破棄されたエントリを記憶するようにすることが望ましい。
破棄されたペアの決済サービス管理テーブル1500のエントリと、取引相手携帯端末管理テーブル1600のエントリは、他のペアの組合せが可能となるように、各エントリの状態(ステータス)を変更することが望ましい。このエントリの状態(ステータス)の変更の詳細については、後述する。処理は、ステップS652に戻る。
【0089】
図7は、事業者装置106の機能ブロック図である。事業者装置106は、電話番号割当テーブル702、顧客装置通信部704、取引相手携帯端末通信部706、決済業者装置通信部708、決済サービス制御部710及び決済記憶部720を有する。
【0090】
決済サービス制御部710は、事業者装置106において、決済サービス全体を制御する。
図14は、電話番号割当テーブル702の一例を示している。電話番号割当テーブル702は、複数の顧客の各々に対してユニークに割り当てられた電話番号を、顧客のIDに対応付けて記憶するエントリを持つ。例えば、取引相手携帯端末104から、電話番号099-1234-1234宛てに掛かってきた電話を受信した場合を想定する。電話番号099-1234-1234によって、電話番号割当テーブル702を検索して、顧客IDであるA12を得ることによって、取引相手に課金を行っている顧客の顧客IDがA12であることを特定することができる。
【0091】
図7に戻る。顧客装置通信部704は、顧客装置102との間での通信を行い、その通信の内容を決済サービス制御部710に渡す。また、決済サービス制御部710の指示に基づき、顧客装置通信部704は、顧客装置102に、決済サービスの管理情報、決済サービスの処理結果などを伝達する。
【0092】
取引相手携帯端末通信部706は、取引相手携帯端末104との間で通信を行い、その通信の内容を決済サービス制御部710に渡す。また、決済サービス制御部710の指示に基づき、取引相手携帯端末通信部706は、取引相手携帯端末104に決済サービスに関するURIを含むメッセージなどを送信する。
【0093】
決済業者装置通信部708は、顧客から取引相手に対する課金情報、決済サービスに関する管理情報などを、決済業者装置108に伝達する。また、取引相手携帯端末104から事業者装置106に対する通信を、決済業者装置108にリダイレクトすることができる。
なお、決済業者装置108は、クレジットカード会社の装置又はキャッシュレス決済業者の装置などに接続されていてもよい。
なお、決済記憶部720は、既に述べた決済サービス管理テーブル1500及び取引相手携帯端末管理テーブル1600を記憶することができ、課金情報、決済サービスに関する管理情報、顧客装置102及び取引相手携帯端末104などを関連付けて記憶することができる。
【0094】
図8ないし
図13は、事業者装置106が顧客装置102に表示させる表示画面と、事業者装置106が取引相手携帯端末104に表示させる表示画面の例を示す図である。これらの図は、上から下に向かって、時間が経過する順序に略描かれている。そして、サイドバイサイドで並んでいる顧客装置表示画面と取引相手携帯端末表示画面の表示時刻は、略同時刻であるように描かれていることに留意すべきである。なお、画面の表示の内容及びその表示のタイミングは、これらの例に限定されるものではない。そして、画面遷移の矢印に記載されているAないしE及びPないしTは、各図の画面遷移の矢印の対応を分かりやすくするために記載している。なお、画面遷移は一例を示すものであって、画面遷移の内容及び順番は、矛盾の無い限り入れ換えることができる。また、矛盾がない範囲において、全ての画面が表示されることが必須ではない点に留意すべきである。
【0095】
図8を用いて、顧客装置102が顧客による操作によって、事業者装置106にログインしていることを前提として、以下に説明する。
顧客装置表示画面800では、発信先電話番号801が表示されている。この発信先電番号801は、予め顧客に割り当てられた電話番号であり、取引相手に伝えることで、取引相手携帯端末104からこの電話番号に発信するための電話番号である。
具体的な電話番号は、0057-00-01であり(810)、取引相手携帯端末表示画面850には、取引相手によるキー入力により、発信先電話番号0057-00-01が入力され(852)、電話発信が行われている。なお、この発信先電話番号は、予め顧客に割り当てられているため、紙などの媒体に記載されていてもよい。この場合には、顧客は、この紙の媒体を取引相手に提示することによって、発信先電話番号801を取引相手に伝達することが可能である。その他の手段によって、発信先電話番号801を取引相手に伝達されてもよい。
顧客装置表示画面800では、さらに、課金額802、取引相手携帯端末104の下4桁804が顧客によって入力されている。取引相手携帯端末104の下4桁804は、第1の識別情報の一例である。また、第2の識別情報は、取引相手携帯端末104の発信元電話番号の下4桁となる。
顧客により登録ボタン806がタッチされることによって、課金額802と取引相手携帯端末104の下4桁(すなわち第2の識別情報)を含む情報が、事業者装置106に到達する。
【0096】
顧客装置表示画面810では、事業者装置106によって、この決済サービスに対する管理情報814すなわち987-62が割り当てられたことが表示されている。また、取引相手携帯端末104にメッセージが送信済みであることを示す表示「携帯にメッセージ送信済」815が表示されている。
そして、顧客に対して問い合わせのメッセージ「携帯にメッセージがとどいていますか?」816が表示されている。顧客に対して、答えることを促すYesボタン818と、Noボタン819が表示されている。
取引相手携帯端末表示画面860には、メッセージ862が届いており、表示されている。メッセージ862には、決済サービスを処理する具体的なURI863が含まれていることがわかる。
顧客は、取引相手の所持する取引相手携帯端末104にメッセージが着信していることを確認することができたため、Yesボタン818をタッチし、Yesボタン818が反転表示されると共に、Yesボタン818がタッチされたことが、事業者装置106に伝達される。
顧客装置102は、Yesボタン818がタッチされるまで、取引相手携帯端末104によるURI863へのアクセスを禁止してもよい。このようにすることによって、メッセージ862が、他の端末に送信され、この取引相手携帯端末104に届かない場合であっても、他の端末からのURI863へのアクセスを禁止することができる。
【0097】
顧客装置表示画面820では、事業者装置106によって、管理情報814に対応付けられたシンボル822が表示されている。
取引相手携帯端末表示画面870では、URIへのアクセスが成功して、管理情報874及びこの管理情報874に対応したシンボル872が表示されている。
顧客は、顧客装置表示画面810に表示されたシンボル822又は管理情報814のいずれかと、取引相手携帯端末表示画面870に表示されたシンボル872又は管理情報874の一致を確認することによって、取引相手携帯端末104が、顧客装置102と同じ決済サービスを処理していることを確認することができる。顧客は、シンボル822とシンボル872とが一致していることを認識することによって、管理情報814と管理情報874との一致を確認することよりも、容易にこのことを確認できる。
顧客に対して問い合わせのメッセージ「携帯に表示されたシンボルは同じですか?」826が表示されてもよい。顧客は、この問い合わせに対してYesボタン828又はNoボタン829のいずれかをタッチすることで、この問い合わせに答えることができると共に、取引相手携帯端末104が、顧客装置102と同じ決済サービスの処理を行っているか否かを、事業者装置106に伝達することができる。
事業者装置106は、このYesボタン828がタッチされるまで、取引相手携帯端末104による決済処理の進行を禁止するようにしてもよい。このようにすることによって、誤った(又は別の)決済サービスの処理が、取引相手携帯端末104によって行われてしまうことを未然に防止することができる。
【0098】
顧客装置表示画面830では、取引相手携帯端末104で決済サービスが進行していることを示すメッセージ「携帯で決済処理が行われています」826が表示されている。
取引相手携帯端末表示画面880では、決済サービスに移行することを示すメッセージ「お支払処理を開始します」887が表示されている。
取引相手により、Nextボタン888がタッチされることによって、事業者装置106は、課金額、管理情報を含む決済サービスに関する情報を決済業者装置108に伝達すると共に、取引相手携帯端末104からの通信を、決済業者装置108にリダイレクトする。
以上の処理によって、取引相手携帯端末104は、決済業者装置108とダイレクトに通信を行うことができる。取引相手携帯端末104と決済業者装置108とは、決済サービスの決済に必要なクレジットカードの番号などの秘密の情報を安全に交換することができる。
その後の処理については、
図12及び
図13を用いて後述する。
【0099】
図9は、
図8の顧客装置表示画面800及び取引相手携帯端末表示画面850の後の画面の例であって、事業者装置106からメッセージが届かない場合の例を示している。
取引相手携帯端末表示画面960では、メッセージが届いていないことがわかる。このようにメッセージが届かない場合には、顧客は例えば1分などの一定の時間、待つことが望ましい。その一定の時間、取引相手携帯端末104にメッセージが到達しない場合には、顧客装置表示画面910の問いかけのメッセージ「携帯にメッセージが届いていますか?」に応答して、顧客によって、Noボタン919がタッチされることとなる。
顧客装置表示画面910では、これに対処するため、決済サービスを処理するURIの情報を含むQRコード917(登録商標)が表示されるようにしてもよい。
取引相手は、取引相手携帯端末104がQRコード917(登録商標)を撮像して、決済サービスを処理するURIを含む情報を読み取らせてもよい。
このようにすることによって、メッセージが到達しない場合であっても、決済サービスの処理を進めることができる。
【0100】
なお、上記の例は一例であって、この例に限られるものではない。メッセージが到達しない原因として考えられるのは、第1の識別情報又は第2の識別情報に誤りが含まれている場合、取引相手携帯端末104が、誤った電話番号に電話発信を行っている場合、メッセージが誤って他の携帯端末に送信されている場合などが挙げあられる。なお、他の誤った携帯端末にメッセージが送信された場合には、
図6で説明したように、ペアの破棄が行われる場合がある。この場合には、その破棄の後に、新たなペアが作成され、メッセージが到達する場合がある。したがって、上述のように、メッセージが到達しない場合であっても、顧客は、一定の時間待つことが望ましい。
また、取引相手携帯端末104が誤った電話番号宛に発信してしまったことが分かった場合には、取引相手携帯端末104から、正しい電話番号にかけ直すことで、メッセージが到達すこともあり得る。
【0101】
また、取引相手が、取引相手携帯端末104の発信元電話番号の下4桁を誤って顧客に伝えた場合、或いは、顧客によって誤った下4桁が顧客装置102に入力された場合には、下4桁の再入力ができるようにしてもよい。あるいは、既に生成された決済サービスを顧客の指示に基づいて無効化して、正しいい下4桁と課金額が入力されるようにして、事業者装置106は、新たな決済サービスを生成するようにしてもよい。
取引相手携帯端末表示画面970では、QRコード917(登録商標)がカメラによって撮像されている様子が表示されている。取引相手携帯端末104は、QRコード917(登録商標)に含まれる決済サービス処理のURIによって、例えば
図8における取引相手携帯端末表示画面870に遷移することができる。
【0102】
図10は、メッセージによって誤った決済サービス処理のURIが送られた例外的ケースへの対応に関する画面遷移の例を示す図である。
取引相手携帯端末表示画面1060では、メッセージが表示されている。しかしながら、メッセージ1062の管理情報は、顧客装置表示画面1010の管理情報814とは異なっている。
このケースの場合には、メッセージが取引相手携帯端末表示画面1060に表示されたため、顧客は、顧客装置表示画面1010の問い合わせのメッセージ「携帯にメッセージがとどいていますか?」1016に対して、誤ってYesボタン1018をタッチしてしまったことを示している。顧客は、取引相手のメッセージ中の管理情報までチェックすることができない場合もあり得るため、このような状況が発生することがあり得る。
【0103】
図10の顧客装置表示画面1020に表示されたシンボル1022と、取引相手携帯端末表示画面1070に表示されたシンボル1072とは、この場合、異なったものとなる。したがって、顧客は、取引相手携帯端末表示画面1070に表示されたシンボルを確認することによって、容易に取引相手携帯端末104が誤った決済サービスの処理を開始しようとしていることが認識できる。
この場合には、問い合わせのメッセージ「携帯に表示されたシンボルは同じですか?」1026に応答して、顧客によって、Noボタンがタッチされる。この状況は、
図6のフローにおけるステップS662で、Noの場合の例である。この場合、ペアの破棄が行われる。したがって、その後、
図6のステップS652に示す新たなペアがあるかがチェックされることとなる。
図10の顧客装置表示画面1030のシンボル1022と、取引相手携帯端末表示画面1080のシンボル1082が一致することが顧客によって確認されることで、Yesボタン1028がタッチされる。この結果が、事業者装置106に伝達される。
【0104】
図11は、所定の時間が経過しても決済サービスの処理の一致が確認できない場合の例を示す図である。
顧客装置表示画面1130のシンボル1122と、取引相手携帯端末表示画面1180のシンボル1182が異なっている。したがって、顧客によって、Noボタン1129がタッチされる。そして、所定の時間が経過しても、シンボルが一致しない状態となったと仮定する。この事例は、
図6におけるステップS664の具体例である。
この場合、顧客装置表示画面1140では、URIを含むQRコード1138(登録商標)が表示されるようにしてもよい。取引相手は、取引相手携帯端末表示画面1190に示されるように、取引相手携帯端末104のカメラがQRコード1138(登録商標)を読み込んで(1193)、決済サービスを処理するURIを含む情報を読み取らせてもよい。
以上のようにすることによって、顧客装置102と取引相手携帯端末104とが、同じ決済サービスを処理することが担保される。
【0105】
図12は、決済が無事完了する場合の画面遷移の例を示す図である。
図12は
図8の処理の続きである。
取引相手携帯端末104では、決済1200が行われている。ここで、例えば、取引相手によって、取引相手携帯端末104にクレジットカード番号などの入力がなされる。決済1200において、取引相手携帯端末104は、決済業者装置108とセキュア―に接続することができる。決済1200において通信されるクレジットカードの番号など、秘密にされるべき情報は、顧客装置102及び事業者装置106には伝達されないようにすることができる。
決済1200が終了すると、決済業者装置108から、事業者装置106に、決済の結果が伝達される。
【0106】
図12において、事業者装置106は、顧客装置表示画面1230で、決済が無事完了したことを示す表示「決済完了」1236を表示させる。また、この決済サービスの管理情報814に対応するシンボル1232aが表示されてもよい。また、決済が無事に完了したことを示すシンボル1232bが表示されてもよい。
事業者装置106は、取引相手携帯端末表示画面1290で、決済が無事完了したことを示す表示「決済完了」1296を表示させる。また、この決済サービスの管理情報814に対応するシンボル1292aが表示されてもよい。また、決済が無事に完了したことを示すシンボル1292bが表示されてもよい。
【0107】
このように、顧客は、決済サービスの管理情報814に対応するシンボル1232aと同じシンボル1292bが取引相手携帯端末表示画面1290に表示されていることを確認することで、取引相手携帯端末104での決済サービスを特定することが容易にできる。すなわち、顧客装置102及び取引相手携帯端末104が、同じ決済サービスに対して処理を行っていることが確認されることで、取引相手携帯端末104が、正しい決済サービスに対して、処理を行ったことを確認することができる。
加えて、顧客が、決済が無事完了したことを示すシンボル1232b及びシンボル1292bを確認することで、決済が無事完了していることも容易に確認することができる。
【0108】
図13は、決済が失敗する場合の画面遷移の例を示す図である。
図13は
図8の処理の続きである。
図13Aは、顧客装置表示画面の例を示す図であり、
図13B及び
図13Cは、取引相手携帯端末表示画面の例を示す図である。
決済1300が実行された後、決済業者装置108は、事業者装置106に決済の結果を伝達する。
図13Aでは、事業者装置106は、顧客装置表示画面1330で、決済が失敗したことを示す表示「決済失敗」1336を表示させる。また、この決済サービスの管理情報814に対応するシンボル1332aが表示されてもよい。また、決済が失敗したことを示すシンボル1332bが表示されてもよい。
【0109】
図13Bでは、事業者装置106は、取引相手携帯端末表示画面1390で、決済が失敗したことを示す表示「決済失敗」1396を表示させる。また、この決済サービスの管理情報814に対応するシンボル1392aが表示されてもよい。また、決済が失敗したことを示すシンボル1392bが表示されてもよい。
このように、顧客は、決済サービスの管理情報814に対応するシンボル1332aと同じシンボル1392bが取引相手携帯端末表示画面1390に表示されていることを確認することで、取引相手携帯端末104での決済サービスを特定することが容易にできる。加えて、決済が失敗したことを示すシンボル1332b及びシンボル1392bを確認することで、決済が失敗していることも容易に確認することができる。
【0110】
図13Cは、取引相手が不正を行った例を示している。取引相手は、例えば取引相手携帯端末104に予め保存されていた過去の決済完了の取引相手携帯端末表示画面1395を提示していると仮定する。この場合、決済サービスの管理番号1396は、顧客装置102の本来の管理番号814と異なっており、決済サービスの管理番号1397に対応するシンボル1293aも、シンボル1223aと異なっている。したがって、顧客は取引相手携帯端末104に表示された取引相手携帯端末表示画面1395が、異なる決済サービスに基づく画面であることを容易に認識することができる。
また、決済の結果を示す表示「決済完了」1379が表示されており、その表示に対応するシンボル1393bが決済完了を示すシンボルであることは認識されるが、上述のように、シンボル1332aとシンボル1393aとが異なることから、顧客は、この取引相手携帯端末表示画面1395は異なる決済サービスの結果を示す画面であり、偽装された画面であることが容易に認識でき、不正を防止することができる。
【0111】
図14は、顧客の各々に対応して予め割り当てられた受信用の電話番号を管理する電話番号割当テーブル702の例を示す図である。
電話番号割当テーブルには、顧客の各々に割り当てられた顧客IDに対応して、予め割り当てられた受信用電話番号が保存されている。この電話番号は、顧客が予め紙などの媒体に記載して、顧客の取引相手に伝達してもよい。或いは、顧客装置102が事業者装置106にログインした際に、ログイン後の顧客装置102の画面に表示されるようにしてもよい。取引相手によってこの電話番号が、取引相手携帯端末104に入力されることで、取引相手携帯端末104から事業者装置106に電話が発信される。事業者装置106は、受けた着信した電話番号によって電話番号割当テーブル702を検索し顧客IDを得ることで、いずれの顧客に対する取引相手の取引相手携帯端末104からの電話であるかを認識することができる。また、事業者装置106は、発信元電話番号により、取引相手携帯端末104を管理することができると共に、発信元電話番号宛に決済サービスを処理するURIを含むメッセージを送ることができる。
【0112】
図15は、決済サービス管理テーブル1500の例を示す図である。
事業者装置106は、顧客装置102によって提供された課金及び第1の識別情報を含む情報に基づいて、決済サービスのエントリを、決済サービス管理テーブル1500に生成する。
決済サービス管理テーブル1500は、決済処理のステータス、第1の識別情報、課金額、決済サービス管理情報、決済サービスURI、シンボル特定情報、発信元電話番号である取引相手携帯端末104の電話番号、過去にペアがキャンセルされた取引相手携帯端末104の電話番号などが記憶される。事業者装置106は、過去にペアがキャンセルされた取引相手携帯端末104の電話番号を記憶しておくことで、ペアとすべきでなかった取引相手携帯端末104を再度ペアにしてしまうことを避けることができる。
なお、決済サービス管理テーブル1500には、各決済サービスのエントリの生成時刻が保存されてもよい。
また、シンボル特定情報は、シンボル特定情報に対応して、1つまたは複数のシンボルが割り当てられてもよい。シンボルは、上述したように、決裁サービス管理情報(決済結果など)を人間が識別しやすいように図形などで表現した情報である。
【0113】
ステータス情報には、例えば以下のステータスが保存されてもよい。
ステータス1:取引相手携帯端末の割当不可(決済サービス開始済・完了済、決済サービス未割当時間切れ等)
ステータス2:取引相手携帯端末の割当可能(決済サービス開始前のため、取引相手携帯端末の再割り当ての可能性あり)
ステータス3:取引相手携帯端末の割当可能(取引相手携帯端末が未割当)
上記ステータス2の場合には、既に述べたようにペアが破棄された場合、ステータス3に変更されることが望ましい。
【0114】
図16は、取引相手携帯端末管理テーブル1600の例を示す図である。
事業者装置106は、取引相手携帯端末104からの電話の着信によって得られた発信元電話番号、第2の識別情報を含む情報に基づいて、取引相手携帯端末104のエントリを、取引相手携帯端末管理テーブル1600に生成する。
取引相手携帯端末管理テーブル1600は、決済処理のステータス、着信時刻、発信元電話番号、第2の識別情報、決済サービス管理情報、メッセージ送信の有無、過去にペアがキャンセルされた決済サービスの管理情報などが記憶される。事業者装置106は、過去にペアがキャンセルされた決済サービスの管理情報を記憶しておくことで、ペアとすべきでなかった決済サービスを再度ペアにしてしまうことを避けることができる。
第2の識別情報には、例えば発信元電話番号の下4桁が格納されてもよい。なお、第2の識別情報は、上記の例に限られるものではない。
ステータス情報には、例えば以下のステータスが保存されてもよい。
ステータス1:決済サービス割当不可(決済サービス開始済・完了済、決済サービス未割当時間切れ等)
ステータス2:決済サービス割当可能(決済サービス開始前のため、決済サービス再割り当ての可能性あり)
ステータス3:決済サービス割当可能(決済サービスが未割当)
上記ステータス2の場合には、既に述べたようにペアが破棄された場合、ステータス3に変更されることが望ましい。
【0115】
<識別情報に用いることができる情報の例>
(1)取引相手携帯端末104の電話番号の一部又は全部を識別情報に用いる。
この点については、上述の実施形態に記載した。顧客が、複数の決済サービスの取り扱いを並行して行わない場合には、取引相手携帯端末104の電話番号のうちの一部の情報(例えば、電話番号の末尾4桁)を識別情報とすることも可能である。なお、顧客にユニークに割り当てられた電話番号に、偶然に又は故意にかかってきた第三者からの通話の発信元電話番号の下4桁が、取引相手携帯端末104の電話番号の下4桁と一致する確率は、1万分の1程度であるから、十分実用に耐える識別情報であると判断できる。電話番号の桁数をより多くすることで、このような誤りの確率はさらに低くなる。取引相手携帯端末104の電話番号を識別情報に用いれば、このような誤りの発生する確率は、小さくなる。なお、このような誤りを未然に防止する確実性の担保の例としては、既に述べたように、管理情報及び決済結果を文字又はシンボル画像で画面に表示させることによって、容易にしかも確実に回避することができる。
【0116】
上記の確実性の担保については、以下に示す例においても、同様に適用できる。
(2)決済サービスの各々に付与されたユニークな管理情報を識別情報に用いる。
この場合には、決済サービスごとにユニークに割り当てられた情報を識別情報に用いることができるため、原理的には、誤った決済サービスに対する処理が、取引相手携帯端末104によってなされることはない。しかしながら、管理情報の入力間違いが発生する可能性がある。この場合には、上記と同様に、確実性の担保を図ることが望ましい。
なお、管理情報は、上述の(2)の例においては、事業者装置106から顧客装置102に伝達されるため、顧客は顧客装置102に、識別情報(すなわち管理情報)を入力する手間が省けると共に、顧客装置102は、識別情報を事業者装置106に送信することを省くことができる。
顧客は、管理情報を取引相手に伝達し、取引相手は、電話をかけたのちに、IVRの指示などに基づき、キー入力などで、識別情報(すなわち管理番号)を入力するとよい。この場合には、取引相手の手間が増加する場合があるが、入力内容が正確であれば、確実性を容易に担保することができる。
なお、事業者装置106が生成するストリングを顧客装置102に送信して、このストリングを識別情報に用いてもよい。このストリングは、決済サービスを特定する管理情報と異なるものであってもよい。このストリングは、顧客装置102に表示され、取引相手携帯端末104に、顧客がキー入力するようにしてもよい。決済サービスを管理する情報は、桁数が長くなる場合がある。このため、識別情報に適した長さのストリングを事業者装置106が生成し、顧客装置102に伝達するようにしてもよい。あるいは、事業者装置が顧客装置に1桁毎にストリングを送り、そのストリングを顧客が取引相手に伝えて、取引相手のキー入力により、そのストリングの情報を事業者装置106に送るようにしてもよい。確認を取るこのストリングは、所定の時間の間において、重複しないユニークなストリングとすることで、ストリングの長さを短くすることができる。或いは、決済サービスの管理情報の一部の情報を識別情報に用いるようにしてもよい。
【0117】
(3)顧客又は取引相手が自由に選んだランダムなストリングを識別情報に用いる。
この場合、一定の確率で、異なる決済サービス間で、識別情報が偶然に一致する場合が発生する。このため、上記と同様に、確実性を担保することが望ましい。なお、ストリングを口頭で顧客及び取引相手の間で伝える場合には、アルファベットよりも番号を用いることが望ましい。アルファベットは、聞き間違える確率が数字よりも高いからである。
なお、このストリングは、顧客装置102又は取引相手携帯端末104により生成されてもよい。
【0118】
(4)上記の情報を複数組み合わせて、識別情報に用いる。
情報を組み合わせることで、識別情報のユニーク性は増すこととなる。その半面、識別情報の桁数が多くなるために、識別情報の入力負担が増し、利便性を犠牲にすることとなる場合もある。また、識別情報を口頭で伝達する場合には、伝達の際の誤りが発生する確率が高くなる。
【0119】
<識別情報の伝達方法>
識別情報を口頭で共有する場合には、聞き間違えが発生する場合があるが、操作者が耳で聴きとって、キーを操作して入力することができるため、単純な作業であり、アプリケーション(たとえばQRコード(登録商標)読み取りソフトなど)を起動する手間が省けるというメリットがある。
逆に、QRコード(登録商標)の読取あるいはネットワーク又は近距離無線通信を用いて識別情報の共有を行う場合には、識別情報の共有がより確実に行える。ただし、アプリケーションの起動を行う場合には、そのアプリケーションの起動が煩雑である場合がある。したがって、シンプルで簡単なUIを優先するのであれば、口頭で伝えた識別情報をキー入力させることが望ましい。逆に、確実に識別情報を共有させることに重点を置く場合には、電子的な手段により、識別情報を共有させることを選ぶこととしてもよい。
【0120】
上記の実施形態では、シンボルを用いて、管理情報の一致などを人間が確認しやすくする例を示したが、シンボルを用いない他の実施形態を採用することも可能である。例えば、顧客装置102と、取引相手携帯端末104とが、事業者装置106を介して、音声通話、チャット、などの連絡が成功したことを確認できるようにすることで、顧客装置102の決済サービスと取引相手携帯端末104の決済サービスとの一致を確認できるようにしてもよい。
上記実施形態における決済サービスは、決済処理の一例である。顧客装置は、顧客の管理する装置の一例である。取引相手携帯端末は、取引相手の管理する携帯端末の一例である。
【符号の説明】
【0121】
702 電話番号割当テーブル
704 顧客装置通信部
706 取引相手携帯端末通信部
708 決済業者装置通信部
710 決済サービス制御部
720 決済記憶部