JP7034226B1 - プログラム、情報処理方法、端末 - Google Patents
プログラム、情報処理方法、端末 Download PDFInfo
- Publication number
- JP7034226B1 JP7034226B1 JP2020163973A JP2020163973A JP7034226B1 JP 7034226 B1 JP7034226 B1 JP 7034226B1 JP 2020163973 A JP2020163973 A JP 2020163973A JP 2020163973 A JP2020163973 A JP 2020163973A JP 7034226 B1 JP7034226 B1 JP 7034226B1
- Authority
- JP
- Japan
- Prior art keywords
- account
- user
- payment
- terminal
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 230000010365 information processing Effects 0.000 title claims description 12
- 238000003672 processing method Methods 0.000 title claims description 8
- 238000004891 communication Methods 0.000 claims abstract description 260
- 238000012545 processing Methods 0.000 claims abstract description 222
- 238000000034 method Methods 0.000 claims description 467
- 230000008569 process Effects 0.000 claims description 430
- 238000010586 diagram Methods 0.000 abstract description 64
- 238000012546 transfer Methods 0.000 abstract description 22
- 238000004148 unit process Methods 0.000 abstract 1
- 238000012790 confirmation Methods 0.000 description 144
- 238000012986 modification Methods 0.000 description 87
- 230000004048 modification Effects 0.000 description 87
- 230000000694 effects Effects 0.000 description 86
- 230000007704 transition Effects 0.000 description 44
- 230000006870 function Effects 0.000 description 40
- 230000008859 change Effects 0.000 description 20
- 238000010079 rubber tapping Methods 0.000 description 18
- 101100328360 Schizosaccharomyces pombe (strain 972 / ATCC 24843) clr1 gene Proteins 0.000 description 15
- 238000004364 calculation method Methods 0.000 description 13
- 102100038546 Fibronectin type III and SPRY domain-containing protein 1 Human genes 0.000 description 12
- 101001030521 Homo sapiens Fibronectin type III and SPRY domain-containing protein 1 Proteins 0.000 description 12
- 101000881131 Homo sapiens RNA/RNP complex-1-interacting phosphatase Proteins 0.000 description 12
- 102100037566 RNA/RNP complex-1-interacting phosphatase Human genes 0.000 description 12
- 230000006378 damage Effects 0.000 description 12
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 10
- 101150037440 MRR1 gene Proteins 0.000 description 10
- 101100464175 Candida albicans (strain SC5314 / ATCC MYA-2876) PIR32 gene Proteins 0.000 description 9
- 101000728145 Homo sapiens Calcium-transporting ATPase type 2C member 1 Proteins 0.000 description 9
- 101001064774 Homo sapiens Peroxidasin-like protein Proteins 0.000 description 9
- 101150045321 PIR3 gene Proteins 0.000 description 9
- 102100031894 Peroxidasin-like protein Human genes 0.000 description 9
- 238000012508 change request Methods 0.000 description 9
- 238000013475 authorization Methods 0.000 description 8
- 230000005540 biological transmission Effects 0.000 description 7
- 101100346444 Candida albicans (strain SC5314 / ATCC MYA-2876) MRR2 gene Proteins 0.000 description 5
- 238000001514 detection method Methods 0.000 description 5
- 101000772460 Arabidopsis thaliana Thioredoxin reductase 2 Proteins 0.000 description 4
- 101000591392 Leishmania infantum Probable flavin mononucleotide-dependent alkene reductase Proteins 0.000 description 4
- 102000017938 NTSR2 Human genes 0.000 description 4
- 230000015556 catabolic process Effects 0.000 description 4
- 230000007423 decrease Effects 0.000 description 4
- 238000012217 deletion Methods 0.000 description 4
- 230000037430 deletion Effects 0.000 description 4
- 108091047102 miR-4 stem-loop Proteins 0.000 description 4
- 108091049748 miR-4-1 stem-loop Proteins 0.000 description 4
- 108091058497 miR-4-2 stem-loop Proteins 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 101000772461 Arabidopsis thaliana Thioredoxin reductase 1, mitochondrial Proteins 0.000 description 3
- 101150051404 CGR1 gene Proteins 0.000 description 3
- 101100243090 Candida glabrata (strain ATCC 2001 / CBS 138 / JCM 3761 / NBRC 0622 / NRRL Y-65) PDH1 gene Proteins 0.000 description 3
- 102000017921 NTSR1 Human genes 0.000 description 3
- 230000001133 acceleration Effects 0.000 description 3
- 101150054999 cgrA gene Proteins 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 3
- 238000005259 measurement Methods 0.000 description 3
- 102100027674 CTD small phosphatase-like protein Human genes 0.000 description 2
- 101000725950 Homo sapiens CTD small phosphatase-like protein Proteins 0.000 description 2
- 101000969327 Homo sapiens Methylthioribose-1-phosphate isomerase Proteins 0.000 description 2
- 101100077149 Human herpesvirus 8 type P (isolate GK18) K5 gene Proteins 0.000 description 2
- 102100021415 Methylthioribose-1-phosphate isomerase Human genes 0.000 description 2
- 101100328361 Schizosaccharomyces pombe (strain 972 / ATCC 24843) clr2 gene Proteins 0.000 description 2
- 102100032889 Sortilin Human genes 0.000 description 2
- 238000005401 electroluminescence Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 230000006855 networking Effects 0.000 description 2
- 230000000630 rising effect Effects 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 108010014657 sortilin Proteins 0.000 description 2
- 102100021895 Bcl-2-like protein 13 Human genes 0.000 description 1
- 101100464170 Candida albicans (strain SC5314 / ATCC MYA-2876) PIR1 gene Proteins 0.000 description 1
- 101000971074 Homo sapiens Bcl-2-like protein 13 Proteins 0.000 description 1
- 101100057245 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) ENA1 gene Proteins 0.000 description 1
- 101100231811 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) HSP150 gene Proteins 0.000 description 1
- 101100464174 Schizosaccharomyces pombe (strain 972 / ATCC 24843) pir2 gene Proteins 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 239000013078 crystal Substances 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 108091084679 miR-3 stem-loop Proteins 0.000 description 1
- 108091033354 miR-3-1 stem-loop Proteins 0.000 description 1
- 108091058771 miR-3-2 stem-loop Proteins 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000008929 regeneration Effects 0.000 description 1
- 238000011069 regeneration method Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000008685 targeting Effects 0.000 description 1
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
【解決手段】決済に関する処理を行う端末によって実行されるプログラムは、端末の第1ユーザの第1アカウントと、第2アカウントとに基づく決済を行うための、第1アカウントと第2アカウントとの関連付けに関する第1情報を端末の通信部によって受信することと、第1情報に基づく第1表示を端末の表示部に表示することと、第1ユーザによる第1表示に対する入力に基づいて、第1アカウントと第2アカウントとの関連付けに関する処理を端末の制御部によって行うことと、第1アカウントと第2アカウントとの関連付けに基づき、少なくとも第2アカウントによって行われた第1決済に関する情報を表示部に表示することと、第1ユーザによる第1決済に関する情報に対する入力に基づいて、第1決済のうちの少なくとも一部である第1金額を第1アカウントから第2アカウントへ送金することに関する処理を制御部によって行うこととが端末によって実行される。
【選択図】図1-1
Description
本発明の第2の態様によると、決済に関する処理を行う端末の情報処理方法は、端末の第1ユーザの第1アカウントと、第2アカウントとに基づく決済を行うための、第1アカウントと第2アカウントとの関連付けに関する第1情報を端末の通信部によって受信することと、第1情報に基づく第1表示を端末の表示部に表示することと、第1ユーザによる第1表示に対する入力に基づいて、第1アカウントと第2アカウントとの関連付けに関する処理を端末の制御部によって行うことと、第1アカウントと第2アカウントとの関連付けに基づき、少なくとも第2アカウントによって行われた第1決済に関する情報を表示部に表示することと、第1ユーザによる第1決済に関する情報に対する入力に基づいて、第1決済のうちの少なくとも一部である第1金額を第1アカウントから第2アカウントへ送金することに関する処理を制御部によって行うこととを含む。
本発明の第3の態様によると、決済に関する処理を行う端末は、端末の第1ユーザの第1アカウントと、第2アカウントとに基づく決済を行うための、第1アカウントと第2アカウントとの関連付けに関する第1情報を受信する通信部と、第1情報に基づく第1表示を表示する表示部と、第1ユーザによる第1表示に対する入力に基づいて、第1アカウントと第2アカウントとの関連付けに関する処理を行う制御部とを備え、表示部は、第1アカウントと第2アカウントとの関連付けに基づき、少なくとも第2アカウントによって行われた第1決済に関する情報を表示し、制御部は、第1ユーザによる第1決済に関する情報に対する入力に基づいて、第1決済のうちの少なくとも一部である第1金額を第1アカウントから第2アカウントへ送金することに関する処理を行う。
本発明の第4の態様によると、決済に関する処理を行う端末は、メモリからプログラムを読み出し、プログラムに基づく処理を行うプロセッサーを備え、プロセッサーは、端末の第1ユーザの第1アカウントと、第2アカウントとに基づく決済を行うための、第1アカウントと第2アカウントとの関連付けに関する第1情報を端末の通信部によって受信することと、第1情報に基づく第1表示を端末の表示部に表示することと、第1ユーザによる第1表示に対する入力に基づいて、第1アカウントと第2アカウントとの関連付けに関する処理を行うことと、第1アカウントと第2アカウントとの関連付けに基づき、少なくとも第2アカウントによって行われた第1決済に関する情報を表示部に表示することと、第1ユーザによる第1決済に関する情報に対する入力に基づいて、第1決済のうちの少なくとも一部である第1金額を第1アカウントから第2アカウントへ送金することに関する処理を行うこととを実行する。
本発明の第5の態様によると、第1ユーザの端末と通信し、決済に関する処理を行うサーバは、第1ユーザの第1アカウントと、第2アカウントとに基づく決済を行うための、第1アカウントと第2アカウントとの関連付けに関する第1情報を端末に送信する通信部と、端末に表示された第1情報に基づく第1表示に対する、第1ユーザによる入力に基づいて、第1アカウントと第2アカウントとの関連付けに関する処理を行う制御部とを備え、通信部は、第1アカウントと第2アカウントとの関連付けに基づき、少なくとも第2アカウントによって行われた第1決済に関する情報を端末に送信し、制御部は、第1ユーザによる、端末に表示された第1決済に関する情報に対する入力に基づいて、第1決済のうちの少なくとも一部である第1金額を第1アカウントから第2アカウントへ送金することに関する処理を行う。
本発明の第6の態様によると、決済に関する処理を行う端末によって実行されるプログラムは、端末の第1ユーザの第1アカウントと、第2アカウントとに基づく決済を行うための、第1アカウントと第2アカウントとの関連付けに関する第1情報を端末の通信部によって第2アカウントに対して送信することと、第1情報を第2アカウントに対して送信してから、第1情報に基づく、第1アカウントと第2アカウントとの関連付けの承認に関する情報を第2アカウントから通信部によって受信するまでの間に、少なくとも第1アカウントに基づく第1決済に関する処理を端末の制御部によって行うことと、第1アカウントと第2アカウントとの関連付けに基づき、第2アカウントから送金された第1決済に基づく金額を受け取る処理を制御部によって行うこととが端末によって実行される。
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
近年、ネットワークサービスに関連するアプリケーション(アプリケーションソフトウェア)として、電子貨幣による支払い・決済を行うためのアプリケーション(支払いアプリケーション・決済アプリケーション)、電子貨幣による送金/受取を行うためのアプリケーション(送金アプリケーション)といったアプリケーションや、これらのアプリケーションの一部の機能または全部の機能を集約したアプリケーションが普及しつつあり、端末のユーザが、これらのアプリケーションを用いて、電子貨幣に関する各種のサービスを受けることが可能になってきている。
また、「電子貨幣(電子マネー)」や「デジタル通貨(デジタル貨幣)」として、法定通貨を用いてもよいし、仮想通貨を用いてもよい。
また、「電子貨幣(電子マネー)」や「デジタル通貨(デジタル貨幣)」には、暗号通貨(暗号資産)を含めてもよい。
また、仮想通貨には、クーポンなどの物的貨幣を含めてもよい。
(1)利用者提示型
(2)店舗提示型
の2種類を例示する。
店舗提示型とは、限定ではなく例として、店舗(限定ではなく例として加盟店)で提示または掲示される支払い店舗コードを利用者が端末のカメラやコードリーダ(支払いアプリケーションのコードリーダを含む。)で読み取って決済を行う方法である。
また、以下では、店舗提示型で端末が読み取るコードを「支払い店舗コード」と称するが、これに代えて「店舗提示型コード」等のように称してもよい。
しかし、利用者提示型についても本発明を同様に適用可能であり、利用者提示型の実施例についても後述する。
(A)アカウント連携決済
(B)共通アカウント決済
の2種類を例示する。
アカウント連携決済は、複数のアカウントを連携させて決済を行う手法である。アカウントの連携とは、複数のアカウントが決済に用いられるように関連付けることである。
この関連付けは、データ上(端末やサーバで管理されるデータ上)で、アカウント連携決済を行うことができるように複数のアカウントが関連付けられたものであればよい。
この場合、1人のユーザの複数のアカウントを連携させてもよいし、複数のユーザのアカウントを連携させてもよい。つまり、必ずしも他人のアカウントが連携に必須なわけではなく、限定ではなく例として、自分の複数のアカウントを連携させることも可能である。
アカウント連携決済は、ユーザが、自分のアカウントの他、異なるアカウント(自分の別のアカウントまたは他人のアカウント)を用いる決済と捉えることもできる。
なお、アカウント連携は、ウォレット連携と表現してもよい。また、アカウント連携決済は、ウォレット連携決済と表現してもよい。
(A-1)支払いを行う前は、限定ではなく例として、事後的な精算が面倒な場合に適用することができる。
(A-2)支払いを行う際は、限定ではなく例として、支払いの際に決済を行うアカウントして設定されているアカウント(限定ではなく例として自分のアカウント)の残高が不足している場合に適用することができる。この場合、限定ではなく例として、他のユーザのアカウントとアカウント連携して決済を行うようにすることができる。
共通アカウント決済は、複数のユーザが共通に使用可能なアカウント(以下、「共通アカウント」と称する。)に基づいて決済を行う手法である。この決済を「共通アカウント決済」と称する。共通アカウント決済は、共通ウォレットを利用することによって実現される。「共通ウォレット」は、複数のユーザによって設定される電子マネー口座の一形態であり、仮想的な1つのウォレットが構成されるものである。
共通アカウント決済は、ユーザが、複数のユーザに共通のアカウント(1つの共通のアカウント)を用いる決済と捉えることもできる。
なお、共通アカウント決済は、共通ウォレット決済と表現してもよい。
第2の形態として、共通アカウントは、共通ウォレットを利用するユーザのうち特定のユーザに紐づけられたアカウントとすることができる。特定のユーザは、限定ではなく例として、共通ウォレットの代表者やマスターとなるユーザ(以下、包括的に「共通アカウントマスターユーザ」と称する。)とすることができる。共通アカウントマスターユーザは、限定ではなく例として、共通アカウントを作成したユーザ等とすることができる。
具体的には、共通ウォレットの機能のうちの一部または全部の機能を利用できないようにしたり、共通ウォレットの機能のうちの一部または全部の機能を利用する場合に共通アカウントマスターユーザの承認を必要としてもよいし、そのようにしなくてもよい。
ただし、アカウント連携決済でも事後的な精算を行う場合があり、これについては実施例で後述する。
以下の説明では、適宜、複数のユーザの端末間で送受信されるコンテンツを各々のユーザが閲覧できるUI(User Interface)やGUI(Graphical User Interface)を「トークルーム」と称する。また、トークルームをチャットルームと称してもよい。
このため、メッセージングサービス:MSと、ソーシャルネットワーキングサービス:SNSとは区別してもよいし、区別しなくてもよい。
操作入力に代えて、または操作入力に加えて、音入力(音声入力を含む。)を端末に対する入力としてもよいし、しなくてもよい。
具体的には、限定ではなく例として、決済を行うためのコード情報をサーバから取得する処理(コード情報の生成をサーバに依頼する処理や、生成されたコード情報をサーバから受信する処理を含む。)、取得したコード情報を表示する処理、決済するようにサーバに依頼する処理、決済結果(決済完了通知等を含む。)をサーバから取得する処理などの、決済を行う上で何らかの関連のある処理、より具体的には、決済を行う上で関連のある処理として端末で実行される処理全般を含むものである。
具体的には、限定ではなく例として、決済を行うためのコード情報を生成する処理、生成したコード情報を端末に送信する処理、決済処理(決済する処理)、決済結果(決済完了通知等を含む。)を端末に送信する処理などの、決済を行う上で何らかの関連のある処理、より具体的には、決済を行う上で関連のある処理としてサーバで実行される処理全般を含むものである。
ただし、システムは、以下説明するシステムに限定されるわけではない。限定ではなく例として、以下のいずれかのパターンのシステムを構成することができる。
(1)端末&サーバ
(2)サーバ
(3)端末
この場合、システムの制御部は、端末の制御部とサーバの制御部とのうちの少なくともいずれか一方とすることができる。つまり、限定ではなく例として、(1A)端末の制御部のみ、(1B)サーバの制御部のみ、(1C)端末の制御部とサーバの制御部との両方、のうちのいずれかを、システムの制御部とすることができる。
また、(1C)では、限定ではなく例として、システムが制御部によって行う制御等のうちの一部の制御等を端末の制御部によって行うようにし、残りの制御等をサーバの制御部によって行うようにすることができる。
サーバを含まず、端末によって構成されるシステムは、限定ではなく例として、以下のようなシステムとすることができる。
・サーバの機能を端末に持たせるシステム(分散システム)。これは、限定ではなく例として、ブロックチェーンの技術を用いて実現することが可能である。
・端末同士が無線通信を行うシステム。これは、限定ではなく例として、ブルートゥース等の近距離無線通信技術を用いてP2P(ピアツーピア)方式等で通信を行うことで実現可能である。
第1実施例は、前述した(A)アカウント連携決済を実現するための基本的な実施例である。
アカウント連携決済を行う場合、アカウント連携決済に参加するアカウントの一部または全部のアカウントに、金額を負担させることが考えられる。
しかし、この場合、限定ではなく例として、連携されたアカウントのうちのいずれかのアカウントの残高が不足するなどして、アカウント連携決済を行うことができない場合があり得る。
また、アカウント連携決済を実現するために、複数のアカウントを連携させることを「アカウント連携」や「ウォレット連携」と称する。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
また、一例として、サーバ10がアカウント連携処理を実行する場合について説明する。
また、詳細は後述するが、アカウント連携処理を端末20が実行するようにすることも可能である。
図1-1は、本実施例における通信システム1Aのシステム構成の一例を示す図である。
通信システム1Aでは、限定ではなく例として、ネットワーク30を介して、サーバ10と、1以上の端末20(端末20A,端末20B,端末20C,・・・)とが接続される。
なお、ネットワーク30に接続されるサーバ10の数や端末20の数は限定されない。
なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
通信システム1Aに含まれる各装置のHW構成について説明する。
図1-1には、端末20のHW構成の一例を示している。
端末20は、制御部21(CPU:central processing unit(中央処理装置))、記憶部28、通信I/F22(インタフェース)、入出力部23、時計部29A、位置算出用情報検出部29Bを備える。端末20のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、端末20のHW構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末20は、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
音出力部26は、音データの出力に利用される。音出力部26は、スピーカなどを含む。
撮像部27は、画像データ(静止画像データ、動画像データを含む。以下同様。)の取得に利用される。撮像部27は、カメラなどを含む。
なお、限定ではなく例として、UWB測位ユニットは、不図示のアンテナから測位用超広帯域パルス信号を含む超広帯域RF信号を送信することで、端末20を測位用ビーコンとして機能させてもよいし、そうしなくてもよい。
図1-1には、サーバ10のHW構成の一例を示している。
サーバ10は、制御部11(CPU)、記憶部15、通信I/F14(インタフェース)、入出力部12、時計部19を備える。サーバ10のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、サーバ10のHWは、サーバ10のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ10のHWは、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
サーバ10は、プログラムPを記憶部15に記憶し、このプログラムPを実行することで、制御部11が、制御部11に含まれる各部としての処理を実行する。つまり、記憶部15に記憶されるプログラムPは、サーバ10に、制御部11が実行する各機能を実現させる。このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。
他の装置についても同様である。
他の装置についても同様である。
他の装置についても同様である。
他の装置についても同様である。
サーバ10および/または端末20における処理の少なくとも一部は、1以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末20における処理の少なくとも一部、または全部を、サーバ10により行う構成としてもよいし、そうでなくてもよい。この場合、端末20の制御部21の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、サーバ10で行う構成としてもよいし、そうでなくてもよい。
サーバ10における処理の少なくとも一部、または全部を、端末20により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ10の制御部11の各機能部の処理のうち少なくとも一部の処理、または全部の処理を、端末20で行う構成としてもよいし、そうでなくてもよい。
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
(1)サーバ
図1-2は、本実施例においてサーバ10の制御部11によって実現される機能の一例を示す図である。
制御部11は、限定ではなく例として、記憶部15に記憶された支払いアプリケーション管理処理プログラム151に従って支払いアプリケーション管理処理を実行するための支払いアプリケーション管理処理部111を機能部として含む。
記憶部15には、限定ではなく例として、支払いアプリケーション管理処理として実行される支払いアプリケーション管理処理プログラム151と、アカウント登録データ153と、アカウント管理データベース155と、連携ウォレット管理データベース157とが記憶される。
アカウント登録データ153には、限定ではなく例として、ユーザ名と、アプリケーションIDと、その他登録情報とが関連付けて記憶される。
このアプリケーションIDは、好ましくはアカウントごとに一意な値であり、限定ではなく例として、サーバ10によってアカウントごとに一意な値(固有の値)が設定されて記憶される。
アプリケーションIDは、端末20、またはその端末20のユーザに関連付けられた情報であり、端末に関する情報、または端末のユーザに関する情報の一例である。
また、端末20のユーザを識別するための識別情報は、限定ではなく例として、アプリケーションIDとすることができる。なお、アプリケーションIDに代えて「ユーザID」としてもよいし、しなくてもよい。
この場合、アプリケーションID等のIDの情報をアカウント登録データ153に記憶させるのに代えて、端末電話番号等の情報をアカウント登録データ153に記憶させるようにすることができる。
第1のアカウント管理データベース155Aには、アカウント登録データ153に記憶されたアプリケーションIDごとの管理データとして、アカウント管理データが記憶される。
電子マネー口座残高は、そのアプリケーションID(そのアカウント)の電子マネー口座の残高であって、限定ではなく例として、サーバ10によって記憶・管理される残高である。単に「残高」と称する場合もある。
第1の連携ウォレット管理データベース157Aには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。
この取引IDは、好ましくは取引ごとに一意な値であり、限定ではなく例として、サーバ10によって取引ごとに一意な値(固有の値)が設定されて記憶される。
この店舗IDは、好ましくは店舗ごとに一意な値であり、限定ではなく例として、サーバ10によって加盟店ごとに一意な値(固有の値)が設定されて記憶される。
図1-7は、本実施例において端末20の制御部21によって実現される機能の一例を示す図である。
制御部21は、限定ではなく例として、記憶部28に記憶された支払いアプリケーション処理プログラム281に従って支払いアプリケーション処理を実行するための支払いアプリケーション処理部211を機能部として含む。
記憶部28には、限定ではなく例として、支払いアプリケーション処理として実行される支払いアプリケーション処理プログラム281と、自己の端末20、または自己の端末20のユーザのアプリケーションID283とが記憶される。
なお、アプリケーションID283は、複数のアプリケーションIDを記憶できるようにしてもよいし、そうしなくてもよい。
以下では、限定ではなく例として、端末20が、縦長のディスプレイの表示部24を備えるスマートフォンである場合を例示する。
タップ(タップ操作)とは、限定ではなく例として、ユーザが、タッチパネルが一体的に構成された表示部24(タッチスクリーン)を指やペン先などで軽く叩くように触れる動作、触れてから離す動作である。
図1-9左側は、限定ではなく例として、ユーザA.Aの端末20Aの表示部24に表示される支払いアプリケーションのメインメニュー画面である。
この画面では、現在位置表示領域CLR1には、連携ウォレットの機能を利用中であることを示す「連携ウォレット」の文字が表示されている。また、現在位置表示領域CLR1の下に、連携ウォレットを用いて「店舗提示型」のコード支払いを行うための「コードリーダ」の文字で示されるコードリーダアイコンIC2と、「利用者提示型」のコード支払いを行うための「コード支払い」の文字で示されるコード支払いアイコンIC3とが横に並んで表示されている。
この画面では、現在位置表示領域CLR1の下に、現在実行中の機能である「コードリーダ」の文字が表示されている。また、画面中央には、支払い店舗コードを読み取るためのコード読み取り領域CR1が表示されている。
画面下方には、支払い金額を入力するためのキーボードが表示されるとともに、支払い金額表示領域PR1に入力されている支払い金額で支払いを実行するための「支払い」の文字で示された支払いボタンBT1が表示されている。
メンバー支払い結果表示領域MRR1には、連携アカウントごとに、支払ったユーザアカウントと、それぞれのユーザアカウントで支払った金額と、支払い後の電子マネー口座残高とが表示されている。
以下では、店舗提示型のコード決済で用いられる「支払い店舗コード」を、限定ではなく例として、加盟店を識別するための加盟店識別情報(限定ではなく例として加盟店に固有に割り振られる店舗ID)を含むコード(一次元コードや二次元コード)として説明する。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
なお、実際には、アカウント連携決済で連携するユーザアカウントは2つとは限らないが、3つ以上とする場合も同様であるため、ここでは図示・説明を省略する。
これは、以下説明する各フローチャート(処理)について同様である。
連携ウォレット支払いトークンは、限定ではなく例として、所定の桁数(限定ではなく例として12桁)の整数値によって識別される。
なお、連携ウォレット支払いトークンは、生成から所定の時間内(限定ではなく例として「5分」)に限り認可を行う、有効期限を持つトークンとしてもよいし、そうしなくてもよい。
一方、いずれかのアカウントにおいて「電子マネー口座残高-等分支払い金額」の値がマイナスとなる場合、連携アカウントへの決済処理は行われず、店舗提示型連携決済処理は失敗となる。
店舗提示型連携決済処理が成功した場合、ユーザA.Aのサブアカウントの電子マネー口座残高からも等分支払い金額が差し引かれて残高が減少する。このような場合に、サーバ10は、第1ユーザアカウント(メインアカウント)から第2ユーザアカウント(サブアカウント)に送金を行って第2ユーザアカウントの残高を補充するように、ユーザA.Aに促すことができる。
また、決済が失敗したアカウントに対して、限定ではなく例として、外部金融機関等からローンや借り入れを行うように促す情報を送金依頼情報として送信するようにしてもよいし、そうしなくてもよい。
本実施例は、端末20が、自己の端末20のユーザ(限定ではなく、端末の第1ユーザの一例)の第1ユーザアカウント(限定ではなく、第1アカウントの一例)と、第1ユーザアカウントと連携された第2ユーザアカウント(限定ではなく、第1アカウントと関連付けられた第2アカウントの一例)とに基づき、アカウント連携決済に関する処理(限定ではなく、第1決済に関する処理の一例)を制御部21によって行う。
また、端末20は、アカウント連携決済に基づいて、第1ユーザアカウントから第2ユーザアカウントへの送金依頼情報(限定ではなく、第2アカウントに送金することに関する第1情報の一例)を通信I/F22によって受信する。
そして、端末20は、受信した送金依頼情報の表示(限定ではなく、第1情報に基づく第1表示の一例)を表示部24に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、端末の第1ユーザの第1アカウントと、第1アカウントと関連付けられた第2アカウントとに基づき、第1ユーザの端末によって第1決済に関する処理を端末の制御部によって行うことで、関連付けられた少なくとも2つのアカウントによる第1決済を可能とすることができる。
また、第1決済により第2アカウントに送金することに関する第1情報を、端末の第1ユーザに知らせることができる。その結果、限定ではなく例として、第2アカウントに送金するように、第1ユーザに促すことができる。
このような構成により得られる実施例の効果の一例として、端末の第1ユーザの第1アカウントと、第1アカウントと関連付けられた第2アカウントとに基づき、サーバによって第1決済に関する処理をサーバの制御部によって行うことで、関連付けられた少なくとも2つのアカウントによる第1決済を行うことができる。
また、第1決済に基づいて、第2アカウントに送金することに関する第1情報を、端末の第1ユーザに知らせることができる。その結果、限定ではなく例として、第2アカウントに送金するように、第1ユーザに促すことができる。
第1実施例では、送金依頼情報は、第1ユーザアカウントから第2ユーザアカウントへの送金を促す情報、あるいは第1ユーザアカウントあるいは第2ユーザアカウント、もしくはその両方へのチャージを促す情報、ローンや借り入れを行うように促す情報等であったがこれに限定されない。限定ではなく例として、送金依頼情報は、これらの具体的金額を含む情報であってもよい。
図1-12は、図1-10の別例を示す画面図である。
図1-12左側および図1-12中央は、それぞれ図1-10と同様である。
図1-13は、この場合の各装置が実行する処理の流れの一例を示すフローチャートである。
左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
そして、サーバ10の制御部11は、処理を終了させる。
このような構成により得られる実施例の効果の一例として、第2アカウントによって、第1決済で支払われた金額に基づく第1情報を、端末の第1ユーザに知らせることができる。限定ではなく例として、送金やチャージを推奨する金額を、端末の第1ユーザに知らせることができる。
第1実施例では、端末20Aは、送金依頼情報を表示部24に表示すると、そのまま処理を終了した。
第2実施例は、これに加えて、送金依頼情報に基づいて、アカウント間での送金を実行する実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図2-1は、本実施例において端末20の表示部24に表示される画面の遷移の一例を示す図である。
図2-1左側は、連携支払い結果表示画面に続いて送金促進通知領域RER3が表示された場合の表示画面の一例である。
送金ボタンBT2がタップされたことに基づいて、支払いアプリケーションのおしらせ画面には、ユーザA.Aのメインアカウントからサブアカウントへの送金を行ったことを示す情報が表示されている。
図2-2に、本実施例において各装置が実行する処理の流れの一例を示すフローチャートを示す。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
本実施例は、端末20が、表示部24に表示した送金推奨額を第1ユーザアカウントから第2ユーザアカウントへ送金するか否かの選択用画面の表示(限定ではなく、第1表示の一例)に対する端末20のユーザによる入力に基づいて、第1ユーザアカウントから第2ユーザアカウントに送金するための処理を実行する構成を示している。
このような構成により得られる実施例の効果の一例として、端末が、第1情報に基づく第1表示に対する第1ユーザによる入力という簡単な方法で、第1情報に基づく金額を、第1アカウントから第2アカウントに送金することができる。
このような構成により得られる実施例の効果の一例として、サーバが、端末に表示された、第1情報に基づく第1表示に対する第1ユーザによる入力に基づいて、第1情報に基づく金額を、第1アカウントから第2アカウントに送金することができる。
第1実施例、第2実施例では、連携アカウントを一人のユーザの異なるユーザアカウントとして説明したが、これに限定されない。
以下では、異なるユーザのユーザアカウントを連携する場合(連携アカウントを異なるユーザのアカウントとする場合)について説明する。
この場合、負担額(立替金額)を支払い後に返却する必要が生じるが、限定ではなく例として、返却する処理を手動で実行する必要があり、利便性に欠ける。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
すなわち、ユーザA.AとユーザB.Bとを連携メンバーとする場合を例示する。
以下では、ユーザA.Aのユーザアカウントと、ユーザB.Bのユーザアカウントとが連携アカウントとして連携されており、これらの連携アカウントを用いてアカウント連携決済を行う例について説明する。この例では、複数のユーザの各々の1つのユーザアカウントが連携されているため、連携メンバーと連携アカウントとは一対一の対応関係となる。
図3-1左側は、前述した支払いアプリケーションのメインメニュー画面であり、連携ウォレットアイコンIC1がタップされた状態が示されている。
本実施例では、ユーザA.Aのユーザアカウントと、ユーザB.Bのユーザアカウントとが連携されているため、連携ウォレットの対象となるユーザ名を含む「A.AとB.Bの連携ウォレット」の文字が表示されている。
しかし、この例では、ユーザA.Aのユーザアカウントの電子マネー口座残高が不足していることに基づいて、限定ではなく例として、図3-2中央に示すような連携支払い確認画面が表示される。
・連携支払い可能額=全ての連携アカウントについての支払い余力の総和
・一の連携アカウントの支払い余力=その連携アカウントの電子マネー口座残高(その連携アカウントの電子マネー口座残高-等分支払い金額<0の場合)
・一の連携アカウントの支払い余力=等分支払い金額(その連携アカウントの電子マネー口座残高-等分支払い金額≧0の場合)
ただし、「等分支払い金額=支払い金額÷連携アカウント数」として算出される。
つまり、上記の連携アカウントを、一人のユーザの複数のユーザアカウント、限定ではなく例として、前述した第1ユーザアカウント(メインアカウント)と第2ユーザアカウント(サブアカウント)との2つのユーザアカウント等として、連携支払い可能額を算出するようにしてもよいし、しなくてもよい。
・連携支払い可能額=全ての連携メンバーについての支払い余力の総和
・一の連携メンバーの支払い余力=その連携メンバーの電子マネー口座残高(その連携メンバーの電子マネー口座残高-等分支払い金額<0の場合)
・一の連携メンバーの支払い余力=等分支払い金額(その連携メンバーの電子マネー口座残高-等分支払い金額≧0の場合)
ただし、「等分支払い金額=支払い金額÷連携メンバー人数」として算出される。
ユーザA.Aについては、支払い余力が等分支払い金額を下回るため、ユーザA.Aのアイコンの左上に警告マークが表示され、支払い余力が「1,000円」であることが示されている。
一方、ユーザB.Bについては、支払い余力が等分支払い金額を下回らないため、警告マークは表示されず、支払い余力が「2,250円」であることが示されている。
この連携支払い確認画面では、支払いメンバー確認領域PMR1において、ユーザB.Bの支払い余力が、等分支払い金額「2,250円」に立て替え必要額「1,250円」を加算した「3,500円」に増加している。それに伴い、支払い金額確認領域PIR1の連携支払い可能額が「4,500円」に増加し、「残高不足です」の文字が消えて、「支払い可能です」の文字が表示されている。
図3-3左側には、連携ウォレットを用いた支払い結果を確認するための、連携支払い結果表示画面が表示されている。
メンバー支払い結果表示領域MRR1には、連携メンバーごとに、支払ったユーザ名と、支払い余力として支払った金額と、支払い後の電子マネー口座残高とが表示されている。
なお、おしらせ画面へは、連携支払い結果表示画面に重ねて表示される、不図示の支払い完了通知をタップする等して遷移することも可能である。
連携決済結果情報CT2の下部には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図3-3左側の連携支払い結果表示画面が表示される。
または、ユーザA.Aが支払った金額と、総支払い金額の両方を表示するようにしてもよいし、そのようにしなくてもよい。
または、他のユーザが支払った金額を加えて表示するようにしてもよいし、そのようにしなくてもよい。
その下には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図3-3左側の連携支払い結果表示画面が表示される。
立て替え情報CT3の下部には、立て替え金額返金ボタンBT6が表示されている。
また、ユーザA.Aの電子マネー口座残高が立替分に満たない状態で立て替え金額返金ボタンBT6がタップされると、銀行口座からのチャージを促す画面へ遷移してもよいし、そのようにしなくてもよい。
図3-4~図3-5に、本実施例において各装置が実行する処理の流れの一例を示すフローチャートを示す。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、端末20B(ユーザB.Bの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
連携残高補充処理において、サーバ10の制御部11は、ユーザA.Aの支払い余力の不足分(立て替え必要額)を、ユーザB.Bの支払い余力に加算した金額を新たなユーザB.Bの支払い余力として更新させる。そして、サーバ10の制御部11は、立て替え必要額をユーザA.AからユーザB.Bへの返却必要額として記憶部15に記憶させる。
一方、連携残高補充処理が実行されなかった場合(S250:NO)、サーバ10の制御部11は、処理を終了させる。
一方、貸し借り情報を受信しない場合(A240:NO)、端末20Aの制御部21は、処理を終了させる。
なお、A250のステップとA260のステップとの間に、外部金融機関の口座からユーザA.Aのアカウントに対するチャージ、あるいは、他のアカウントからユーザA.Aのアカウントに対する送金等の処理を挟んでもよい。
一方、返却必要額をユーザB.Bに返却することが選択されない場合(A260:NO)、端末20Aの制御部21は、処理を終了させる。
貸し借り情報を受信しない場合(B210:NO)、端末20Bの制御部21は、処理を終了させる。
本実施例によれば、第1ユーザの第1ユーザアカウントと、この第1ユーザアカウントと連携された第2ユーザの第2ユーザアカウントとに基づき、決済を行うことができる。また、この決済に基づき、第1ユーザアカウントから第2ユーザアカウントに送金することができる。第2ユーザアカウントは第2ユーザのアカウントであるため、第1ユーザの第1アカウントと、この第1アカウントと関連付けられた第2ユーザの第2アカウントとに基づく決済を実現することができる。
このため、第2ユーザアカウントへの送金は、第2ユーザへの送金と捉えてもよいし、第2ユーザの端末への送金と捉えてもよい。
このような構成により得られる実施例の効果の一例として、第1決済において、少なくとも第2アカウントによって第1アカウントの不足分の支払いが行われるようにすることができる。これにより、第1アカウントの残高が不足していて、支払うべき金額の全部を支払うことができないような場合に、この不足分の金額を、第2アカウントに支払ってもらうことができる。また、第2アカウントによって第1アカウントの代わりに支払った金額を、第1アカウントから第2アカウントに送金するように、第1ユーザに促すことができる。
このような構成により得られる実施例の効果の一例として、第1決済において、第2アカウントから全ての支払いが行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、第1決済において、第1アカウントによる支払いも行うが、少なくとも第2アカウントによって、第1アカウントの不足分の支払いが行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、サーバを介して第1情報を簡単に取得することができる。
第3実施例では、不足額を立て替えてもらったユーザA.Aが能動的に返却必要額をユーザB.Bに返却する場合を示したが、これに限定されない。限定ではなく例として、返却必要額を立て替えた(貸し出した)連携メンバーであるユーザB.Bが、立て替えてもらったユーザA.Aに対して必要返却額の請求を行えるようにしてもよいし、そのようにしなくてもよい。
図3-6は、図3-3右側の端末20Aの連携支払い確認画面において、連携支払い実行ボタンBT5がタップされた場合の、端末20Bにおける画面の遷移の一例を示す図である。
連携決済結果情報CT4の下部には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図3-6右側の連携支払い結果表示画面が表示される。
その下には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図3-6右側の連携支払い結果表示画面が表示される。
立て替え情報CT5の下部には、ユーザB.BがユーザA.Aに立て替えた「1,250円」の返金を請求するための立て替え金額請求ボタンBT7が表示されている。
この画面では、メンバー支払い結果表示領域MRR2において、立て替え金額返金ボタンBT6の代わりに、ユーザA.Aの項目に、ユーザB.Bが立て替えた「1,250円」の返却を促すための立て替え金額請求ボタンBT7が加えて表示されている。
なお、ユーザA.Aの電子マネー口座残高が立替分より大きい場合、自動的にユーザA.Aの電子マネー口座からユーザB.Bの電子マネー口座への立替分の送金が実行されるようにしてもよいし、そのようにしなくてもよい。
図3-7~図3-8に、図3-4から続く本変形例において各装置が実行する処理の流れの一例を示すフローチャートを示す。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、端末20B(ユーザB.Bの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
第3実施例では、コード決済を実行するユーザA.Aのアカウントの電子マネー口座残高が等分支払い金額に満たない場合を示したが、これに限定されない。限定ではなく例として、連携メンバーのアカウントであるユーザB.Bの電子マネー口座残高が等分支払い金額に満たない場合に、ユーザA.AのアカウントによってユーザB.Bの支払い余力の不足分(すなわち等分支払い金額-ユーザB.Bの支払い余力)を負担し、連携ウォレットを用いた支払いを実行するようにしてもよいし、そのようにしなくてもよい。
図3-9は、端末20Bで表示されるアカウント連携決済を完了するまでの画面の遷移の一例である。この図は、図3-2の端末20Aで表示されるアカウント連携決済を完了するまでの画面の遷移を、端末20B側で見た場合の遷移を示す図である。
図3-9左側には、図3-2中央と同様に、警告マークと「残高不足です」の文字とを含む連携支払い確認画面を示している。
この画面では、支払いメンバー確認領域PMR2において、ユーザB.Bの支払い余力が等分支払い金額「2,250円」に立て替え必要額「1,250円」を加算した「3,500円」に増加している。それに伴い、支払い金額確認領域PIR2の連携支払い可能額は「4,500円」に増加し、「残高不足です」の文字が消えて、「支払い可能です」の文字が表示されている。
この画面には、連携ウォレットを用いた支払いが完了したことを示す「支払い完了」の文字とともに、支払い金額の送金先である「XX楽器」のアイコン画像と、その名称と、支払い日時とが表示されている。連携支払い結果表示画面の下部には、メンバー支払い結果表示領域MRR3が表示されている。
立て替え金額請求ボタンBT12がタップされた場合の挙動については、図3-6において立て替え金額請求ボタンBT7がタップされた場合と同様に構成可能である。
連携決済結果情報CT4の下部には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図3-10右側の連携支払い結果表示画面が表示される。
その下には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図3-10右側の連携支払い結果表示画面が表示される。
立て替え情報CT5の下部には、ユーザA.Aが、ユーザB.Bに立て替えてもらった「1,250円」を返却するための立て替え金額返金ボタンBT6が表示されている。
この画面では、メンバー支払い結果表示領域MRR2において、ユーザB.Bの項目に、ユーザB.Bに立て替えてもらった「1,250円」を返却するための立て替え金額返金ボタンBT6が加えて表示されている。
この場合の処理については、限定ではなく例として、図3-4のA210のステップにおいて、残高補充要求情報を、連携ウォレットの他の連携メンバー(この場合にはユーザB.B)の支払い余力の不足分(すなわち等分支払い金額-ユーザB.Bの支払い余力)をユーザA.Aが負担するための情報とし、図3-5の端末20Aおよび端末20Bの各ステップを端末間で入れ替えて実行することで、図3-4~図3-5と同様に実行することが可能である。
第3実施例では、コード決済を実行するユーザA.Aのアカウントの電子マネー口座残高が等分支払い金額に満たない場合、他の連携アカウントによって不足分を立て替えてもらう例を示したが、これに限定されない。限定ではなく例として、コード決済の実行時に不足分を外部金融機関の口座からユーザA.Aのアカウントに対してチャージするようにしてもよいし、そのようにしなくてもよい。
図3-11は、連携ウォレットを用いたコード支払いが実行された場合における連携支払い確認画面の画面の遷移の一例を示す図である。
この画面では、連携支払い確認画面の下側からチャージ表示領域CGR1がせり上がり、重ねて表示されている。
この画面では、ユーザA.Aの電子マネー口座残高が「2,000円」増加したことに伴って、支払いメンバー確認領域PMR1において、ユーザA.Aの支払い余力が「2,250円」に増加している。それに伴い、支払い金額確認領域PIR1の連携支払い可能額は「4,500円」に増加し、「残高不足です」の文字が消えて、「支払い可能です」の文字が表示されている。
この場合の処理については、限定ではなく例として、図3-4のA210のステップにおいて、端末20Aの制御部21は、残高補充要求情報の代わりに、予めユーザA.Aによって登録された外部金融機関の口座からユーザA.Aのアカウントに対して、支払い余力の不足分のチャージを行うためのチャージ要求情報を通信I/F22によってサーバ10に送信する。そして、図3-4のS230のステップにおいて、サーバ10の制御部11は、通信I/F14によって受信したチャージ要求情報に従って、支払い余力の不足分を外部金融機関の口座からユーザA.Aのアカウントにチャージすればよい。
第3実施例では、端末20Aは、連携残高不足情報(限定ではなく例として、第1情報の一例)をサーバ10から受信することとしたが、これに限定されない。限定ではなく例として、他メンバーの端末20(限定ではなく例として、端末20B)から連携残高不足情報を受信するようにしてもよいし、そのようにしなくてもよい。
図3-12に、本変形例において各装置が実行する処理の流れの一例を示すフローチャートを示す。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、端末20B(ユーザB.Bの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
第3実施例では、連携メンバーが二人の場合について説明したが、これに限定されない。
本実施例では、連携メンバーが三人以上の場合について説明する。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
(1)連携アカウントデータに登録される連携アカウント数を単純に増やす方法
(2)複数の連携メンバーで予め構成されるグループを導入する方法
なお、三人以上の連携メンバーの各々のユーザアカウントではなく、任意の連携メンバーの3以上のユーザアカウントを用いる場合でも同様である。
ここでは、限定ではなく例として、支払いアプリケーションにおいて複数のユーザを含むグループが形成され、このグループに含まれるユーザ(以下、「グループメンバー」と称する。)の各々のユーザアカウントを連携させてアカウント連携決済を行う場合について説明する。
また、ここでは、同じグループに含まれる全てのグループメンバーを連携メンバーとする場合を例示する。
記憶部15には、限定ではなく例として、支払いアプリケーション管理処理として実行される支払いアプリケーション管理処理プログラム151と、アカウント登録データ153と、アカウント管理データベース155と、連携ウォレット管理データベース157と、グループ管理データベース159とが記憶される。
グループ管理データベース159には、グループごとの管理データとして、グループ管理データが記憶される。
グループIDは、グループを識別するために用いられる情報(グループを識別するための識別情報)である。
このグループIDは、好ましくはグループごとに一意な値であり、限定ではなく例として、サーバ10によってグループごとに一意な値(固有の値)が設定されて記憶される。
第2の連携ウォレット管理データベース157Bには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。
ここでは、限定ではなく例として、(2)の方法を適用する場合の表示画面例について説明する。
図4-4左側は、限定ではなく例として、ユーザA.Aの端末20Aの表示部24に表示される支払いアプリケーションのメインメニュー画面である。
このメインメニュー画面において連携ウォレットアイコンIC1がタップされると、端末20Aからサーバ10に対して、ウォレット連携を行うグループを選択するためのグループ一覧情報を要求する情報が送信され、サーバ10から端末20Aに対して、グループ一覧情報が送信される。その結果、限定ではなく例として、図4-4右側に示すようなグループ選択画面が表示される。
図4-5左側は、連携ウォレットのメイン画面の一例であり、この画面では、連携メンバー情報表示領域MIR1に、グループ「バンド仲間」の各ユーザの電子マネー口座残高が表示されている。
この画面では、現在位置表示領域CLR1の下に、現在実行中の機能である「コードリーダ」の文字が表示されている。また、画面中央には、支払い店舗コードを読み取るためのコード読み取り領域CR1が表示されている。
画面下方には、支払い金額を入力するためのキーボードが表示されるとともに、支払い金額表示領域PR1に入力されている支払い金額で支払いを実行するための「支払い」の文字で示された支払いボタンBT1が表示されている。
図4-5右側に示される支払い金額入力画面において支払いボタンBT1がタップされると、連携ウォレットを用いたコード支払いが実行される。
図4-6左側には、連携支払い確認画面として、限定ではなく例として、現在位置表示領域CLR1の下に、支払い金額確認領域PIR1が表示されている。支払い金額確認領域PIR1には、限定ではなく例として、支払い金額の送金先である「XX楽器」のアイコン画像とともに、その名称「XX楽器」と、支払い金額「4,500円」とが表示されている。支払い金額の下には、現在の連携支払い可能額である「4,000円」が表示されている。また、支払い金額確認領域PIR1には、現在の連携支払い可能額が支払い金額を下回ることに基づいて、警告マークと「残高不足です」の文字とが表示されている。
ユーザA.Aのアイコンの左上に警告マークが表示され、支払い余力が「1,000円」であることが示されている。この場合、連携支払い可能額が支払い金額に満たず、このままでは支払いを行うことができない。
そのため、連携支払い確認画面の最下部には、等分支払い金額「1,500円」のうち、支払い余力「1,000円」では不足する立て替え必要額「1,500円-1,000円=500円」をユーザA.A以外の他のメンバーに立て替えてもらい、支払いを実行するための「他のメンバーに立て替えてもらう」の文字で示される立て替え依頼ボタンBT4が表示されている。
この画面では、支払いメンバー確認領域PMR1の代わりに、立て替えてもらうことが可能なメンバーの一覧を表示し、選択させるための立替メンバー選択領域PSR1が表示されている。
この画面では、支払いメンバー確認領域PMR1において、ユーザC.Cの支払い余力が等分支払い金額「1,500円」に立て替え必要額「500円」を加算した「2,000円」に増加している。それに伴い、支払い金額確認領域PIR1の連携支払い可能額は「4,500円」に増加し、「残高不足です」の文字が消え、代わりに「支払い可能です」の文字が表示されている。
図4-7左側には、連携ウォレットを用いた支払い結果を確認するための、連携支払い結果表示画面が表示されている。
メンバー支払い結果表示領域MRR1には、メンバーごとに、支払ったユーザ名と、支払い余力として支払った金額と、支払い後の電子マネー口座残高とが表示されている。
連携決済結果情報CT2の下部には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図4-7左側の連携支払い結果表示画面が表示される。
その下には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図4-7左側の連携支払い結果表示画面が表示される。
立て替え情報CT3の下部には、ユーザA.AがユーザC.Cに立て替えてもらった「500円」を返却するための立て替え金額返金ボタンBT6が表示されている。
連携決済結果情報CT4の下部には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図4-8右側の連携支払い結果表示画面が表示される。
その下には、支払いの詳細を確認するための「詳細を確認」の文字で示される詳細確認ボタンが表示されている。この詳細確認ボタンがタップされると、限定ではなく例として、図4-8右側の連携支払い結果表示画面が表示される。
立て替え情報CT5の下部には、ユーザC.CがユーザA.Aに立て替えた「500円」の返金を請求するための立て替え金額請求ボタンBT7が表示されている。
この画面では、メンバー支払い結果表示領域MRR2において、立て替え金額返金ボタンBT6の代わりに、ユーザA.Aの項目にユーザC.Cが立て替えた「500円」の返却を促すための立て替え金額請求ボタンBT7が加えて表示されている。
なお、ユーザA.Aの電子マネー口座残高が立替分より大きい場合、自動的にユーザA.Aの電子マネー口座からユーザC.Cの電子マネー口座への立替分の送金が実行されるようにしてもよいし、そのようにしなくてもよい。
本実施例における処理については、限定ではなく例として、連携ウォレットを用いて支払いを行うグループメンバーの端末20を端末20Aの処理に、それ以外のグループメンバーの端末20を端末20Bの処理にそれぞれ当てはめて、図3-4~図3-5と同様に実現可能であるため、再度の説明は省略する。
本実施例は、アカウント連携決済は、支払いを行うグループメンバーの第1ユーザアカウント(限定ではなく、第1アカウントの一例)と、他のグループメンバーの第2ユーザアカウント(限定ではなく、第2アカウントの一例)と、これら以外のグループメンバーの第4ユーザアカウント(限定ではなく、第1アカウントおよび第2アカウントと連携した第4アカウントの一例)とによって行われる構成を示している。
このような構成により得られる実施例の効果の一例として、第1アカウントと第2アカウントばかりでなく、第1アカウントと第2アカウントとが関連付けられた第4アカウントによっても支払いが行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、第1アカウントの不足分の支払いが、複数のアカウントによって行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、第1アカウントの不足分の支払いが、第4アカウントは用いずに、第2アカウントのみによって行われるようにすることができる。
このような構成により得られる実施例の効果の一例として、第1アカウントの不足分を支払う第2アカウントを、第2アカウントの残高に基づいて決定することができる。限定ではなく例として、残高が最も多い第2アカウントを、第1アカウントの不足分を支払い第2アカウントに決定することができる。
このような構成により得られる実施例の効果の一例として、第1アカウントの不足分を支払う第2アカウントを、第1ユーザによる端末に対する入力という簡単な方法で選択することができる。
第4実施例では、他の連携アカウントによって不足分を立て替えてもらう場合、立て替えを行うアカウントのユーザに承認を求めることなく連携残高補充処理が実行されることとしたが、これに限定されない。限定ではなく例として、不足分の立て替えが必要な場合には、立て替えを行うアカウントのユーザの承認が必要であるようにしてもよいし、そのようにしなくてもよい。
図4-9は、上記の例において、立て替えに相手の承認を必要とする場合の端末20における表示画面の遷移の一例を示す図である。
この図は、図4-6中央→図4-6右側に遷移する過程で、立て替えを行うユーザC.Cの承認を得ることを要している。具体的には、図4-9左側の端末20Aの表示部24に表示される画面において、立て替えを依頼するメンバーとしてユーザC.Cが選択されると、端末20Cの表示部24には、図4-9中央に示すようなお知らせ画面が表示される。このお知らせ画面には、ユーザA.Aから立て替えの依頼があったことを示す立て替え依頼情報が表示されている。
図4-10~図4-11に、本変形例において各装置が実行する処理の流れの一例を示すフローチャートを示す。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、端末20B(ユーザB.Bの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
このような構成により得られる実施例の効果の一例として、第1ユーザによる端末に対する入力に基づいて第2アカウントが選択された場合であっても、限定ではなく例として、第2アカウントの第2ユーザの許可がなければ、その第2アカウントが第1アカウントの不足分を支払う第2アカウントに決定されないようにすることができる。その結果、第2ユーザの意に反して、第2アカウントから第1アカウントの不足分が支払われることを防止することができる。
第4実施例で説明したように、グループに含まれる全てのグループメンバーを連携メンバーとしてもよいが、グループに含まれる一部のグループメンバーを連携メンバーとすることもできる。つまり、同じグループ内で、アカウント連携決済に参加するグループメンバーと、アカウント連携決済に参加しないグループメンバーとを分けることもできる。
これは、同じグループに属していても、ユーザによっては、アカウント連携決済への参加を希望しない場合も想定されるためである。
第4実施例では、アカウント連携決済の際に、支払い余力が不足する連携メンバーが一人(または支払い余力が不足する連携アカウントが1つ)として説明した。しかし、これは一例に過ぎない。
本実施例では、アカウント連携決済の実行時に、複数の連携メンバー(または複数の連携アカウント)の支払い余力が不足する場合について説明する。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図5-1は、本実施例において端末20Aの表示部24に表示される表示画面の遷移の一例を示す図である。連携ウォレットを用いたコード支払いが実行された場合における連携支払い確認画面の画面の遷移の一例を示している。
この画面では、支払いメンバー確認領域PMR3の代わりに、立替メンバー選択領域PSR3が表示されている。
この画面では、支払いメンバー確認領域PMR3において、ユーザC.Cの支払い余力が等分支払い金額「1,500円」に立て替え必要額の合計額「1,500円」を加算した「3,000円」に増加している。それに伴い、支払い金額確認領域PIR3の連携支払い可能額は「4,500円」に増加し、「残高不足です」の文字が消え、代わりに「支払い可能です」の文字が表示されている。
また、連携支払い確認画面の最下部には、連携支払い実行ボタンBT14が表示されている。
端末20Bのメンバー支払い結果表示領域MRR6には、ユーザC.Cの項目に、ユーザB.BがユーザC.Cに立て替えてもらった「1,000円」を返却するための立て替え金額返金ボタンBT16が表示されている。
端末20Cのメンバー支払い結果表示領域MRR7には、ユーザA.Aの項目にユーザC.CがユーザA.Aに立て替えた「500円」の返却を請求するための立て替え金額請求ボタンBT17が、ユーザB.Bの項目にユーザC.CがユーザB.Bに立て替えた「1,000円」の返却を請求するための立て替え金額請求ボタンBT18が、それぞれ表示されている。
本実施例における処理については、限定ではなく例として、残高補充要求情報を、複数のアカウントの支払い余力の不足分を立て替える場合の情報として、図3-4~図3-5の処理を適用することによって同様に実現可能であるため、再度の説明は省略する。
第5実施例では、連携メンバーの一人が、他の複数の連携メンバーで発生した支払い余力の不足分を立て替えることとしたが、これに限定されない。
限定ではなく例として、複数の連携メンバーで発生した支払い余力の不足分を、複数の連携メンバーで分散して立て替えることとしてもよいし、そのようにしなくてもよい。
また、複数の連携アカウントで発生した支払い余力の不足分を複数の連携アカウントで立て替えることとしてもよいし、そのようにしなくてもよい。
第1実施例~第5実施例では、アカウント連携決済を店舗提示型のコード決済によって実現する手法について説明した。しかし、これは一例に過ぎない。
第6実施例では、アカウント連携決済を利用者提示型のコード決済によって実現する手法について説明する。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図6-1は、本実施例における通信システム1Bのシステム構成の一例を示す図である。
通信システム1Bでは、限定ではなく例として、ネットワーク30を介して、サーバ10と、複数の端末20(端末20A,端末20B,端末20C,・・・)と、複数の店舗POSシステム40(店舗POSシステム40A,店舗POSシステム40B,店舗POSシステム40C,・・・)とが接続される。
通信システム1Aとは、店舗POSシステム40が構成要素として追加されている点が異なる。
店舗POSシステム40は、限定ではなく例として、サーバ10を運用する事業者と提携している店舗に導入されて使用されるPOSシステムであり、限定ではなく例として、店舗コードリーダ装置50と、コードレジ60と、店舗サーバ70とを含む。
コードレジ60は、支払いアプリケーションに対応可能に構成されたレジであり、支払いアプリケーション対応の据置端末と言うこともできる。
図6-3は、アカウント連携決済を「利用者提示型」の決済によって実現する場合の端末20の表示部24に表示される画面の遷移の一例を示す図である。
図6-3左側は、図4-5左側の画面に対応している。この画面においてコード支払いアイコンIC3がタップされると、端末20Aの表示部24には、図6-3中央に示すようなコード支払い画面が表示される。
図6-4に、本実施例において各装置が実行する処理の流れの一例を示すフローチャートを示す。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、端末20B(ユーザB.Bの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理、店舗コードリーダ装置50の制御部51が実行する処理の一例を示している。
この場合、サーバ10の制御部21は、連携ウォレット支払いトークンと、連携ウォレットコード情報とを再生成し、連携ウォレットコード情報を通信I/F14によって端末20Aに送信する。そして、通信I/F22によってサーバ10から再生成された連携ウォレットコード情報を受信すると、端末20Aの制御部21は、支払いコードと、有効期限とを表示部24に再表示させるようにすることができる。
ただし、利用者提示型連携決済処理では、サーバ10の制御部11は、連携ウォレットによる決済予定金額の支払いが成功したか否かの決済結果についての決済結果情報を通信I/F14によって店舗コードリーダ装置50に送信する点が異なる。
また、アカウント連携決済に基づいて、端末20は、送金依頼情報(限定ではなく、第2アカウントに送金することに関する第1情報の一例)を通信I/F22によって受信する。
そして、端末20は、受信した送金依頼情報の表示(限定ではなく、第1情報に基づく第1表示の一例)を表示部24に表示する。
この場合、端末20は、第1ユーザアカウントと第2ユーザアカウントとに基づきアカウント連携決済を行うための連携ウォレットコード情報(限定ではなく、コード情報の一例)を通信I/F22によってサーバ10から受信し、受信した連携ウォレットコード情報を表示部24に表示する。そして、表示部24に表示された連携ウォレットコード情報が店舗コードリーダ装置に読み取られることに基づいて、サーバ10によってアカウント連携決済が行われる構成を示している。
このような構成により得られる実施例の効果の一例として、端末の第1ユーザの第1アカウントと、第1アカウントと関連付けられた第2アカウントとに基づき、第1ユーザの端末によって第1決済に関する処理を端末の制御部によって行うことで、関連付けられた少なくとも2つのアカウントによる第1決済を実現することができる。また、第1決済により第2アカウントに送金することに関する第1情報を、端末の第1ユーザに知らせることができる。その結果、限定ではなく例として、第2アカウントに送金するように、第1ユーザに促すことができる。また、第1アカウントと第2アカウントとに基づき第1決済を行うためのコード情報を店舗のコードリーダに読み取らせるといった簡単な方法によって、第1決済を実現することができる。
第1実施例~第6実施例では、アカウント連携決済に基づいて、都度送金を促す手法について説明したが、これに限定されない。
第7実施例では、複数のアカウント連携決済に基づいて、発生した立て替えをまとめて精算する手法について説明する。また、これに関連して、連携ウォレットを破棄する手法について説明する。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
第3の連携ウォレット管理データベース157Cには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。
図7-2は、本実施例において端末20Aの表示部24に表示される画面の遷移の一例を示す図である。
図7-2左側は、図4-5左側と同様の連携ウォレットのメイン画面であるが、その表示が一部異なっている。具体的には、グループ「バンド仲間」の連携ウォレットであることを表示する領域内に、グループ「バンド仲間」の連携ウォレットで行った決済の履歴を表示するための履歴ボタンBT25が表示されている。
この画面には、グループ「バンド仲間」の連携ウォレットで行った決済に関する情報として、商品やサービスの購入履歴に関する情報が表示されている。この例では、「XX楽器」と「YYスタジオ」との2つの購入履歴に関する情報が表示されており、各々の購入履歴には、チェックボックスが関連付けて設けられている。精算を希望する購入履歴のチェックボックスにチェックを入れた状態で、画面下部の一括精算ボタンBT26がタップされると、チェックが入れられた購入履歴を、まとめて精算することが可能である。
この画面では、図7-2中央の画面の中央部に、一括精算を実行するための一括精算情報がポップアップ形式で表示されている。この例では、一括精算情報には、ユーザA.AからユーザB.Bに対して「500円」を送金し、ユーザA.AからユーザC.Cに対して「1,000円」を送金する必要があることを示すメッセージとともに、この内容を承認して一括精算するための「はい」のボタンと、一括精算をやめるための「いいえ」のボタンとが表示されている。
図7-3~図7-4に、本実施例において各装置が実行する処理の流れの一例を示すフローチャートを示す。
これらの図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、端末20B(ユーザB.Bの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
連携ウォレット精算処理において、まず、サーバ10の制御部11は、第3の連携ウォレット管理データベース157Cを参照し、連携ウォレット管理データの立替履歴データに、立替履歴が記録されているか否かを判定する(S400)。
立替履歴データに立替履歴が記録されていない場合(S400:NO)、サーバ10の制御部11は、処理を終了させる。
また、連携ウォレット精算依頼情報として、立替者IDのユーザアカウントへの立替金額の返却と、披立替者IDのユーザアカウントへの立替金額の請求とを含ませるようにしてもよいし、そのようにしなくてもよい。
なお、立替金額の請求については、披立替者IDのアカウントの端末に対して、送金を促す旨のメッセージを含む情報を送信するようにすればよい。
なお、連携メンバーの全ての端末に対して、精算を行った立替履歴に関する送金結果等を送信するようにしてもよいし、そのようにしなくてもよい。
連携ウォレット精算依頼情報を受信しない場合には(S420:NO)、サーバ10の制御部11は、処理を終了させる。
連携ウォレット精算結果情報を受信しない場合には(A440:NO)、端末20Aの制御部21は、処理を終了させる。
連携ウォレット破棄処理では、第3の連携ウォレット管理データベース157Cから、この連携ウォレットの連携ウォレット管理データの各レコードを消去する。なお、連携ウォレット管理データがグループIDで識別される場合、グループ管理データベース159のグループ管理データのうち、連携ウォレット破棄が選択されたグループIDのグループ管理データも消去するようにしてもよいし、そうしなくてもよい。
本実施例は、端末20は、第1ユーザアカウントと、第2ユーザアカウントとは異なる、第1ユーザアカウントに関連付けられた第3ユーザアカウントとに基づき、決済(限定ではなく、第3決済の一例)に関する処理を制御部21によって行う。また、端末20は、この決済に基づいて、第3ユーザアカウントに送金することに関する第3情報を通信I/F22によって受信し、受信した第3情報に基づく第3表示を表示部24に表示する。
そして、端末20は、第1表示と第3表示とに対する端末20のユーザによる入力に基づいて、第1情報に基づく金額を、第1ユーザアカウントから第2ユーザアカウントに送金することに関する処理を制御部21によって行い、第3情報に基づく金額を、第1ユーザアカウントから第3ユーザアカウントに送金することに関する処理を制御部21によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第1表示と第3表示とに対する第1ユーザによる入力という簡単な方法で、第1アカウントから複数のアカウントへの送金を実現することができる。
第1実施例~第7実施例では、アカウント連携決済において、ユーザアカウントを連携させる手法について説明したが、これに限定されない。
第8実施例では、共通ウォレットの概念を導入する。そして、この共通ウォレット(共通アカウント)とユーザアカウントとを連携した連携ウォレットで決済を行う。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
記憶部15には、支払いアプリケーション管理処理プログラム151と、アカウント登録データ153と、アカウント管理データベース155と、連携ウォレット管理データベース157とに加えて、限定ではなく例として、共通ウォレット管理データベース161が記憶される。
共通ウォレット管理データベース161には、共通ウォレットをユニークに識別するための共通ウォレットIDごとの管理データとして、共通ウォレット管理データが記憶される。
共通ウォレット名は、共通ウォレットIDで識別される共通ウォレットの名称である。
共通ウォレット残高は、共通ウォレットIDで識別される共通ウォレットを利用して支払いを行う際に用いられる電子マネーの残高である。
共通ウォレットメンバーIDは、共通ウォレットの生成時に指定される、共通ウォレットメンバーのアプリケーションIDである。
第4の連携ウォレット管理データベース157Dには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。
連携ウォレットIDと、決済履歴データとは、限定ではなく例として、第1の連携ウォレット管理データベース157Aと同様である。
本実施例における処理については、限定ではなく例として、連携アカウントを共通ウォレットとし、共通ウォレットIDをアプリケーションIDとみなして、図3-4~図3-5と同様に実現可能であるため、再度の説明は省略する。
本実施例は、第2アカウントは、共通ウォレットのアカウント(限定ではなく、複数のユーザが決済可能な共通アカウントの一例)であり、端末20は、表示部24に表示した送金推奨額を第1ユーザアカウントから共通ウォレットのアカウントへ送金するか否かの選択用画面の表示(限定ではなく、第1表示の一例)に対する端末20のユーザによる入力に基づいて、第1ユーザアカウントから共通ウォレットのアカウントに送金するための処理を実行する構成を示している。
このような構成により得られる実施例の効果の一例として、第1ユーザのアカウントと、複数のユーザが決済可能な共通アカウントとに基づいて決済を行うことができる。
また、第1表示に対する第1ユーザによる入力という簡単な方法で、第1情報に基づく金額を、第1アカウントから共通アカウントに送金することができる。
このような構成により得られる実施例の効果の一例として、共通アカウントとして関連付けられた複数のユーザの各々のアカウントに、共通アカウントから第1金額の少なくとも一部である第2金額が送金されるようにすることができる。
限定ではなく例として、共通アカウントに一定以上の金額が溜まったような場合に、返金可能な金額が第2金額として、共通アカウントから複数のユーザの各々のアカウントに返金されるようにすることができる。
上記の実施例では、アカウント連携決済において、連携アカウントが、決済予定金額を連携アカウント数で等分した等分支払い金額をそれぞれ負担する(割り勘する)こととして説明したが、これに限定されない。
第9実施例では、割り勘以外の負担分担方法について説明する。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
この場合、全ての連携メンバーは等しく支払いを負担し、それぞれの負担額は「1,000円」となる。このとき、ユーザB.Bは支払い余力が不足するため、支払いが実行できない。
この場合、限定ではなく例として、ユーザB.Bの負担額を「0」とし、ユーザA.AとユーザC.Cとが「3,000円」を等分して「1,500円」ずつ支払う。
限定ではなく例として、ユーザB.Bの負担額を「0」とし、ユーザA.AとユーザC.Cとが「3,000円」をそれぞれの電子マネー口座残高の割合(ユーザA.A:ユーザC.C=2:1)で負担する。
限定ではなく例として、ユーザB.Bは、均等支払い金額「1,000円」のうち、払える限界である「500円」を負担し、残りの「2,500円」をユーザA.AとユーザC.Cとで均等割りし負担する。
限定ではなく例として、ユーザB.Bは、均等支払い金額「1,000円」のうち、払える限界である「500円」を負担し、残りの「2,500円」のうち、電子マネー口座残高の多いユーザA.Aが均等支払い金額「1,000円」とユーザB.Bのアカウント不足分に相当する「500円」との合計額(「1,500円」)を負担し、ユーザC.Cは均等支払い金額「1,000円」を負担する。
しかし、限定ではなく例として、上記のパターン2~パターン5のように、支払い金額を連携アカウントで均等に負担するのではなく、負担する割合を変化させて支払いを行うようにすることも可能である。
上記の実施例では、アカウント連携決済において、予めアカウント連携が行われている、つまり、アカウント連携済みであるものとして説明したが、これに限定されない。
第10実施例では、アカウント連携の手法について説明する。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
第5の連携ウォレット管理データベース157Eには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。
連携状況管理データには、限定ではなく例として、アプリケーションIDと、ユーザ名と、連携承認とが関連付けて記憶される。
以下では、ユーザ(ユーザアカウント)が、連携ウォレットを用いて支払いを行うことを承認することを「連携承認する」と表現する場合がある。
同様に、「連携メンバー」は、限定ではなく例として、連携承認の有無に関わらず、連携ウォレットの連携候補となっているユーザとすることができる。
同様に、連携承認されて連携承認済みとなったユーザのことを「連携メンバー」と定義してもよいし、そのようにしなくてもよい。
図10-2は、本実施例において端末20Aの表示部24に表示される画面の遷移の一例を示す図である。
図10-2左側は、グループ選択画面の一例であり、現在位置表示領域CLR1には、連携ウォレットの機能を利用中であることを示す「連携ウォレット」の文字が表示され、その下に、ウォレット連携を行うグループを選択することをユーザに促す「グループを選択してください」の文字が表示されている。
この画面では、現在位置表示領域CLR1の下には、連携ウォレット情報表示領域WIR1が表示されている。連携ウォレット情報表示領域WIR1には、「ウォレット連携を依頼しますか?」の文字が表示され、その下には、ウォレット連携を行うグループ「バンド仲間」に所属するメンバーが一覧表示されている。限定ではなく例として、この画面では、グループ「バンド仲間」は、ユーザA.Aと、ユーザB.Bと、ユーザC.Cとの3名を含むグループであることが示されている。
なお、この画面では、まだ連携ウォレットが有効化されていないため、コードリーダアイコンIC2と、コード支払いアイコンIC3とは、タップされても機能せず、グレーアウトされて表示されている。
また、ユーザB.Bと、ユーザC.Cとは、ウォレット連携の依頼中であり、連携の承認が取れていないことが示されている。
このおしらせ画面では、現在位置表示領域CLR2には、支払いアプリケーションのおしらせ機能であることを示す「おしらせ」の文字が表示されている。
ウォレット連携承認確認情報CT1の下部には、グループ「バンド仲間」のメンバーとウォレット連携を行うことを承認するための「連携する」の文字で示されるウォレット連携承認ボタンと、ウォレット連携を承認しないための「断る」の文字で示されるウォレット連携拒否ボタンとが表示されている。
図10-4~図10-5に、本実施例において各装置が実行する処理の流れの一例を示すフローチャートを示す。
これらの図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、端末20B(ユーザB.Bの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
なお、ウォレット連携が失敗したことを示す情報をサーバ10から受信する場合には、端末20Aの制御部21は、処理を終了させるようにしてもよいし、そのようにしなくてもよい。
自端末の連携がまだ行われていない場合には(B550:NO)、端末20Bの制御部21は、B500のステップへ処理を戻す。
第10実施例では、複数のメンバーで予め構成されるグループにおいて連携ウォレットを導入する方法についての場合を例示したが、これに限定されない。限定ではなく例として、第4実施例の(1)の方法(連携アカウントデータに複数の連携アカウントを登録する方法)で構成される連携ウォレットにおいて、連携メンバーの認可に基づいて、連携ウォレットを使用可能にするようにしてもよいし、そのようにしなくてもよい。
上記の実施例において、連携承認を必要とせず、連携ウォレットが作成されたことを以ってアカウント連携が行われるようにしてもよいし、そのようにしなくてもよい。
つまり、連携承認に関する処理を省略し、連携ウォレットが作成される場合に、連携候補とされた複数のアカウントが連携ウォレット管理データにおいて自動的に関連付けられるようにしてもよいし、そのようにしなくてもよい。
この場合は、連携ウォレットが生成されることが「アカウント連携」となる。
第1実施例~第10実施例では、限定ではなく例として、アプリケーションとして支払いアプリケーションを適用した実施例について説明したが、これに限定されない。
第11実施例は、チャットアプリケーションのグループにおいて連携ウォレットを用いて支払いを行い、チャットルームにその表示を行う実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
また、メッセージンサービス(メッセージングアプリケーション)を適用する場合のチャットルームとして、以下ではトークルームを例示する。
以下では、メッセージングアプリケーションのユーザであるとともに支払いアプリケーションのユーザでもあるユーザA.Aと、ユーザB.Bと、ユーザC.Cとが、何れもグループ「バンド仲間」に属しており、友だち登録されているものとする。
グループトークルームには、ユーザA.Aから発信されたメッセージとして、ウォレット連携を依頼することを示すウォレット連携依頼メッセージMS1が、表示領域の左側に表示されている。このウォレット連携依頼メッセージMS1には、ウォレット連携を依頼することを示すテキストとともに、ウォレット連携の依頼を承認することを示す「連携する」の文字を含む連携ボタンと、ウォレット連携の依頼を拒否することを示す「断る」の文字を含む拒否ボタンとが表示されている。連携ボタンがタップされると、ウォレット連携に同意したことを示す情報がサーバ10に送信されて、ユーザB.Bのユーザアカウントが連携される。その結果、端末20Aの表示部24には、限定ではなく例として、図11-2右側の画面が表示される。
また、ユーザC.Cは、ウォレット連携の依頼中であり、連携の承認が取れていないことが示されている。
図11-3左側では、連携ウォレットによる支払いが完了したことを示す情報を含むメンバー支払い結果表示領域MRR8を含む連携ウォレット支払い完了通知が、画面下部からせり上がって、グループ「バンド仲間」のグループトークルームに重畳して表示されている。
この例では、ユーザA.Aのユーザアカウントの電子マネー口座残高が「1,000円」であり、等分支払い金額である「1,500円」に対して「500円」が不足していたことに基づき、「500円」をユーザC.Cに立て替えてもらった場合の例を示している。
ユーザB.Bについては、等分支払い金額「1,500円」を支払い、その結果、電子マネー口座残高が「1,500円」になったことが示されている。
ユーザC.Cについては、等分支払い金額「1,500円」のうちのユーザA.Aの不足分の金額「500円」を立て替え、「1,500円+500円=2,000円」を支払い、その結果、電子マネー口座残高が「4,000円」になったことが示されている。
立て替え金額返金ボタンBT6がタップされると、ユーザA.Aの電子マネー口座からユーザC.Cの電子マネー口座へ、立替分「500円」の送金が実行される。
なお、連携決済結果メッセージMS2と、立て替えメッセージMS3とを、まとめて一つの情報として表示するようにしてもよいし、そのようにしなくてもよい。
立て替え金額返金ボタンBT6がタップされると、ユーザA.Aの電子マネー口座からユーザC.Cの電子マネー口座へ、立替分「500円」の送金が実行される。
図11-4左側には、グループトークルームが表示されており、連携ウォレットによってユーザC.Cが「2,000円」を支払ったことを示す連携決済結果メッセージMS4(連携決済結果情報)と、ユーザC.CがユーザA.Aの支払い分の「500円」を立て替えたことを示す立て替えメッセージMS5(立て替え情報)とが表示されている。
なお、連携決済結果メッセージMS4と、立て替えメッセージMS5とを、まとめて一つの情報として表示するようにしてもよいし、そのようにしなくてもよい。
立て替え金額請求ボタンBT7がタップされると、サーバ10を介して、端末20Cから端末20Aに対して、立て替え金額を請求する情報が送信される。
メンバー支払い結果表示領域MRR9において、ユーザA.Aの項目には、立て替え金額請求ボタンBT7が表示されている。
図11-5左側には、図11-3右側に示したグループトークルームにおいて、チャットが進行した状態が示されている。この例では、ユーザA.Aからグループに対して、別の商品(この例では、スティック)を購入することを希望するメッセージが発信され、これを承認する旨のメッセージが、ユーザC.Cから発信された状態が示されている。
ユーザB.Bについては、等分支払い金額「300円」を支払い、その結果、電子マネー口座残高が「1,200円」になったことが示されている。
ユーザC.Cについては、等分支払い金額「300円」のうちのユーザA.Aの不足分の金額「300円」を立て替え、「300円+300円=600円」を支払い、その結果、電子マネー口座残高が「3,400円」になったことが示されている。
なお、連携決済結果メッセージMS6と、立て替えメッセージMS7とを、まとめて一つの情報として表示するようにしてもよいし、そのようにしなくてもよい。
立て替え金額返金ボタンBT6がタップされると、ユーザA.Aの電子マネー口座からユーザC.Cの電子マネー口座へ、立替分「300円」の送金が実行される。
この例では、図11-6左側に示すように、現在位置表示領域内のグループ名「バンド仲間(3)」から下方にぶら下がる形式で「連携ウォレットの精算が必要です」の文字を含む、連携ウォレットの精算を促すための通知が表示されている。この吹き出しがタップされると、図11-6右側に示すように、グループトークルームの画面下部から、連携ウォレットの一括精算に関する情報を表示する表示領域がせり上がって表示される。
本実施例における処理については、限定ではなく例として、支払いアプリケーションを管理する支払いアプリケーション管理サーバと、メッセージングサービスを管理するメッセージングアプリケーション管理サーバとの処理をサーバ10における処理として、図10-4~図10-5および図7-3~図7-5に従って同様に実現することが可能であるため、再度の説明は省略する。
本実施例は、送金依頼情報の表示(限定ではなく、第1表示の一例)は、第1ユーザアカウントと第2ユーザアカウントとが関連付けられたトークルーム(限定ではなく、第1アカウントと第2アカウントとが関連付けられたチャットルームの一例)に含まれ、端末20は、送金依頼情報の表示を含むトークルームを表示部24に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、第1アカウントと第2アカウントとが関連付けられたチャットルームへの表示という分かり易い形で、第2アカウントに送金することに関する第1情報を、端末の第1ユーザに知らせることができる。
このような構成により得られる実施例の効果の一例として、端末の第1ユーザの第1アカウントと、第1アカウントと関連付けられた第2アカウントとに基づき、第1ユーザの端末によって第2決済に関する処理を端末の制御部によって行うことで、関連付けられた少なくとも2つのアカウントによる第2決済を実現することができる。また、第1決済により第2アカウントに送金することに関する第1情報に加えて、第2決済により第2アカウントに送金することに関する第2情報を、チャットルームへの表示という分かり易い形で、端末の第1ユーザに知らせることができる。
このような構成により得られる実施例の効果の一例として、第1表示と第2表示とに対する第1ユーザによる入力という簡単な方法で、第1情報に基づく金額と第2情報に基づく金額とを、第1アカウントから第2アカウントに送金することができる。
第11実施例において、複数の連携アカウントのトークルーム(チャットルーム)におけるアカウント連携を解除することに基づいて、それまでに行われたアカウント連携決済について、未処理の返金を行うようにしてもよいし、しなくてもよい。
(A)チャットルームは破棄せずアカウント同士の関連付けを無くすこと
(B)チャットルームを破棄すること
図11-7左側には、グループ「バンド仲間」の連携ウォレットに関する、連携メンバー情報表示領域MIR1が、グループトークルームの画面下部からせり上がって表示されている。連携メンバー情報表示領域MIR1の下部には、連携ウォレット破棄ボタンBT30が表示されている。
このような構成により得られる実施例の効果の一例として、第1アカウントと、第2アカウントとのチャットルームにおける関連付けを解除する場合、第1情報に基づく金額と第2情報に基づく金額とを、第1アカウントから第2アカウントに送金することができる。限定ではなく例として、チャットルーム上で第1アカウントと第2アカウントとの関連付けを破棄したり、チャットルームそれ自体を破棄するような場合に、未処理分の金額を返金するといったことが可能となる。
上記の実施例では、連携メンバーの各々の端末20において、各連携アカウントの電子マネー口座残高を確認可能に構成されていた。この各連携アカウントにおける電子マネー口座残高の情報は、限定ではなく例として、サーバ10から連携メンバーの端末20に送信され、端末20で受信して表示部24に表示させることが可能である。なお、これとは異なり、電子マネー口座残高の情報を、端末20間で送受信するようにすることも可能である。
つまり、上記の実施例では、各連携アカウントにおいて、真の電子マネー口座残高が連携メンバーに共有されていた。
しかし、ユーザによっては、他の連携メンバーに対して、自分の真の電子マネー口座残高を開示することが憚られることが想定される。
以下では、連携ウォレットにおいて表示される、連携アカウントの表示上の残高のことを「表示残高」と称する。
そこで、まず本実施例では、同じユーザの複数のユーザアカウントを連携アカウントとする場合について説明する。
詳細後述する「表示上限金額」や、連携アカウントのユーザによって任意に入力・設定される金額を、表示残高を制限させるために設定される金額とすることもできる。
限定ではなく例として、ユーザアカウントを用いた通常の決済や、共通アカウント決済等に対しても同様に適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
第6の連携ウォレット管理データベース157Fには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。
限定ではなく例として、図12-1では、連携アカウントとして、ユーザA.AのメインアカウントであるアプリケーションID「U0001」のユーザアカウントと、ユーザA.AのサブアカウントであるアプリケーションID「U0005」のユーザアカウントとが関連付けられている。
この場合、アプリケーションID「U0005」の電子マネー口座残高が「5,000円」を下回っていても、表示残高は「5,000円」と表示される。一方、電子マネー口座残高が「5,000円」以上の場合には、電子マネー口座残高がそのまま表示残高として用いられる。
ここでは、ユーザA.Aのメインアカウントとサブアカウントとを連携アカウントとして連携させた連携ウォレットについて表示画面例を用いて説明する。ここで、サブアカウントの電子マネー口座残高は、「1,000円」であり、サブアカウントの表示下限金額が「5,000円」であるとする。
図12-2左側の支払いアプリケーションのメインメニュー画面において、連携ウォレットアイコンIC1がタップされると、図12-2中央の画面が表示される。この画面では、ユーザA.Aの連携ウォレットであることを示す情報とともに、その下の連携メンバー情報表示領域MIR1には、ユーザA.Aのメインアカウントの電子マネー口座残高(この例では「10,000円」)と、ユーザA.Aのサブアカウントに設定された表示残高(この例では「5,000円」)とが表示されている。ユーザA.Aのサブアカウントの残高表示欄には、メインアカウントとは異なり、設定された表示残高が表示されている。
連携メンバー情報表示領域MIR1には、ユーザA.Aのメインアカウントの支払い金額(この例では「3,000円」)と、ユーザA.Aのサブアカウントの支払い金額(この例では「3,000円」)とが表示されている。
しかし、ユーザA.Aのサブアカウントについては、表示残高は「5,000円」であるものの、実際の電子マネー口座残高は「1,000円」であり、電子マネー口座残高が等分支払い金額を下回っている。
その結果、連携支払い可能額が支払い金額を下回ることに基づいて、支払い金額確認領域PIR1には、警告マークと「残高不足です」の文字とが表示されている。
図12-4は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
この場合、端末20Aの制御部21は、受信した真の電子マネー口座残高と表示下限金額とを用いて表示残高を算出し、表示部24に表示させるようにすることができる。
本実施例は、端末20が、自己の端末20のユーザ(限定ではなく、第1ユーザの一例)の第2ユーザアカウント(限定ではなく、第2アカウントの一例)に設定された表示下限金額(限定ではなく、第2金額の一例)に基づく表示残高(限定ではなく、第2金額に基づく第2アカウントの残高の一例)を表示部24に表示する。そして、端末20は、自己の端末20のユーザの第1ユーザアカウント(限定ではなく、第1アカウントの一例)と、表示下限金額が設定された第2ユーザアカウントとに基づき、連携アカウント決済に関する処理(限定ではなく、第1決済に関する処理の一例)を制御部21によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第1ユーザの第1アカウントに関連付けられた第2アカウントに設定された第2金額に基づく第2アカウントの残高を、第1ユーザに確認させることができる。
また、第1アカウントと、第2金額が設定された第2アカウントとに基づき、第1ユーザの端末によって第1決済を行わせることができる。
このような構成により得られる実施例の効果の一例として、第2金額に基づく第2アカウントの残高情報を他の装置から受信して取得したことに基づいて、第2金額に基づく第2アカウントの残高を、第1ユーザに確認させることができる。
このような構成により得られる実施例の効果の一例として、第2アカウントに設定された第2金額に基づく第2アカウントの残高に関する情報を第1ユーザの端末に送信して、第1ユーザに確認させることができる。
また、第1アカウントと、第2金額が設定された第2アカウントとに基づき、第1決済を行うことができる。
第12実施例では、表示残高の概念を新たに導入した。
第12実施例で説明した表示残高は、設定された表示上の残高を表示させるものに過ぎなかったが、本実施例では、表示残高が決済処理に影響を及ぼし得る実施例について説明する。
また、限定ではなく例として、ユーザが端末20の紛失・盗難にあうなどして、自身の真の電子マネー口座残高を他人に見られてしまうような場合も想定される。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
第7の連携ウォレット管理データベース157Gには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。
限定ではなく例として、図13-1では、連携アカウントとして、ユーザA.AのメインアカウントであるアプリケーションID「U0001」のユーザアカウントと、ユーザA.AのサブアカウントであるアプリケーションID「U0005」のユーザアカウントとが関連付けられている。
一方、電子マネー口座残高が「5,000円」以下の場合には、電子マネー口座残高がそのまま表示残高として用いられる。
ここでは、ユーザA.Aのメインアカウントとサブアカウントとを連携アカウントとして連携させた連携ウォレットについて表示画面例を用いて説明する。ここで、サブアカウントの電子マネー口座残高は、「5,000円」であり、表示上限金額が「5,000円」に設定されていたとする。
図13-2左側は、連携ウォレットのメイン画面であり、連携メンバー情報表示領域MIR1に、ユーザA.Aのメインアカウントの電子マネー口座残高(10,000円)と、ユーザA.Aのサブアカウントについて設定された表示上限金額(5,000円)に基づく表示残高(5,000円)とが表示されている。
なお、サブアカウントについては表示上限金額が設定済みであるため、サブアカウントの表示欄には上限制限ボタンBT40は表示されていない。
このメイン画面では、図13-2左側のメイン画面とは異なり、ユーザA.Aのメインアカウントの表示欄に、表示残高として「3,000円」が表示されている。
また、表示上限金額が設定されたことに基づき、図13-2左側の画面のメインアカウントの表示欄に表示されていた上限制限ボタンBT40は非表示とされている。
コード読み取り領域CR1内に支払い店舗コードが収まり、連携ウォレットコードリーダ情報が読み取られると、図13-3中央に示す画面が表示される。この画面では、連携ウォレットでの支払い金額として「6,000円」が入力された状態が示されている。
ユーザA.Aのメインアカウントについては、電子マネー口座残高が「10,000円」であり、等分支払い金額を上回っている。
また、ユーザB.Bのサブアカウントについては、電子マネー口座残高は、「5,000円」であり、等分支払い金額を上回っている。
このため、連携ウォレットによる決済は可能であり、この状態で画面下部の支払いボタンBT1がタップされると、図13-3右側の画面が表示される。
等分支払い金額が「3,000円」であるため、メインアカウントについては、支払いによって電子マネー口座残高が「10,000円」→「7,000円」となったが、表示残高「3,000円」を上回っているため、表示残高として「3,000円」が表示されている。
一方、サブアカウントについては、支払いによって電子マネー口座残高が「5,000円」→「2,000円」となったが、表示残高「3,000円」を下回るため、表示残高として「2,000円」が表示されている。
図13-4は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
この場合、端末20Aの制御部21は、受信した真の電子マネー口座残高と表示上限金額とを用いて表示残高を算出し、表示部24に表示させるようにすることができる。
一方、いずれかのアカウントにおいて「表示残高-等分支払い金額」の値がマイナスとなる場合、連携アカウントへの決済処理は行われず、店舗提示型上限制限連携決済処理は失敗となる。
本実施例は、端末20が、自己の端末20のユーザ(限定ではなく、第1ユーザの一例)の第2ユーザアカウント(限定ではなく、第2アカウントの一例)に設定された表示上限金額(限定ではなく、第2金額の一例)に基づく表示残高(限定ではなく、第2金額に基づく第2アカウントの残高の一例)を表示部24に表示する。そして、端末20は、自己の端末20のユーザの第1ユーザアカウント(限定ではなく、第1アカウントの一例)と、表示上限金額が設定された第2ユーザアカウントとに基づき、連携アカウント決済に関する処理(限定ではなく、第1決済に関する処理の一例)を制御部21によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第1ユーザの第1アカウントに関連付けられた第2アカウントに設定された第2金額に基づく第2アカウントの残高を、第1ユーザに確認させることができる。
また、第1アカウントと、第2金額が設定された第2アカウントとに基づき、第1ユーザの端末によって第1決済を行わせることができる。
このような構成により得られる実施例の効果の一例として、第1アカウントに対しても表示上の金額(第1金額)を設定することができる。
また、設定された第1金額に基づく第1アカウントの残高と、設定された第2金額に基づく第2アカウントの残高との両方を、第1ユーザが確認できるようにすることができる。
このような構成により得られる実施例の効果の一例として、第2アカウントに設定された最大金額の情報を第1ユーザに確認させることができる。
このような構成により得られる実施例の効果の一例として、第2アカウントに設定された一回の決済に利用可能な最大金額を第1ユーザに確認させることができる。
このような構成により得られる実施例の効果の一例として、第2アカウントの残高と、第2アカウントに設定された第2金額との関係に基づいて、金額を適切に表示することができる。
上記の実施例では、決済処理として店舗提示型上限制限連携決済処理を実行したが、これに限定されない。限定ではなく例として、図13-4のS690のステップにおいて、図1-11のS110のステップで示した店舗提示型連携決済処理を実行するようにしてもよいし、そのようにしなくてもよい。
上記の実施例では、各連携アカウントにおいて異なる表示上限金額が用いられる例を示したが、これに限定されない。
限定ではなく例として、連携ウォレットごとに所定の表示上限金額が定められている、または連携ウォレットごとに表示上限金額が設定されるようにしてもよいし、そのようにしなくてもよい。
この場合、ある連携アカウントの電子マネー口座残高が連携ウォレットの表示上限金額を上回る場合には、この連携アカウントの表示残高は、連携ウォレットの表示上限金額となる。
この場合、連携ウォレットの表示上限金額より少ない金額のみを各連携アカウントにおいて表示上限金額として設定できるようにしてもよいし、そのようにしなくてもよい。
連携ウォレットの表示上限金額を上回る表示上限金額がある連携アカウントで設定される場合、この連携アカウントの表示残高では、アカウントごとに設定された表示上限金額が反映されることとしてもよいし、そのようにしなくてもよい。
上記の実施例では、連携アカウントとしてユーザアカウントを連携させた例を示したが、これに限定されない。限定ではなく例として、第8実施例で述べた共通ウォレットを連携アカウントとする連携ウォレットとしてもよいし、そのようにしなくてもよい。
このような構成により得られる変形例の効果の一例として、共通アカウントの真の残高を秘匿することができる。
表示上限金額が設定されたユーザアカウントについて、電子マネー口座残高の照会・表示に認証を必要としてもよいし、そのようにしなくてもよい。つまり、認証を行って認証結果がOK(認証OK)とならない限り、電子マネー口座残高が端末20の表示部24に表示されないようにしてもよいし、そのようにしなくてもよい。
この場合、端末20は、自己の端末20のユーザによる入力に基づいて認証処理を制御部21によって行い、認証OKである場合に、電子マネー口座残高を表示部24に表示させるようにすることができる。
限定ではなく例として、電子マネー口座残高が、設定された表示下限金額を下回っている場合は、表示残高として表示下限金額が表示されるため、真の電子マネー口座残高は秘匿される。この場合も、認証OKとならない限り、真の電子マネー口座残高は表示部24に表示されないことになる。
この場合、自身が所有するユーザアカウントごとに、または自身が所有する全てのユーザアカウントについて一括的に、認証に関する設定を行うことができるようにしてもよい。
また、限定ではなく例として、表示残高を制限させるための金額(上記の表示上限金額や表示下限金額等)が設定されたユーザアカウントに対してのみ、認証ONに設定するようにしてもよい。
第13実施例では、表示残高が決済処理に影響を及ぼし得る場合について説明した。
本実施例では、第13実施例を前述の第10実施例と組み合わせ、複数の連携メンバーにおける連携ウォレットにおいて、表示上限金額で制限を行った表示残高を導入する場合について説明する。
つまり、本実施例では、第1アカウントを第1ユーザのユーザアカウントとし、第2アカウントを第1ユーザとは異なる第2ユーザのユーザアカウントとして説明する。
また、前述したように、ユーザによっては、連携ウォレットにおいて1回の決済に使用可能な電子マネー口座残高を制限したいと考えることもあり得る。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
第8の連携ウォレット管理データベース157Hには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。
図14-2は、本実施例において端末20Aの表示部24に表示される画面の遷移の一例を示す図である。
図14-2左側には、グループ「バンド仲間」のメンバーに対して、ウォレット連携を依頼するための画面が表示されている。画面下部のウォレット連携依頼ボタンBT35がタップされると、図14-2中央の画面が表示される。
図14-3左側には、支払いアプリケーションのおしらせ画面が表示されており、現在位置表示領域CLR2の下には、ユーザA.Aからウォレット連携の依頼があった旨の通知が表示されている。
また、ユーザC.Cについては、ユーザA.Aからのウォレット連携の依頼に対する承認が未だなされていない状態であるため、「依頼中」のマークが表示されている。
この画面は、ユーザB.Bが自身の表示上限金額を設定するための画面であり、この例では、表示上限金額として「4,000円」が入力された状態が示されている。この状態で、画面下部の設定ボタンBT41がタップされると、図14-4左側の画面が表示される。
この画面では、連携メンバー情報表示領域MIR2において、ユーザB.Bの欄に、電子マネー口座残高として「6,000円」が、表示残高として「4,000円」がそれぞれ表示されている。
端末20A側では、連携メンバー情報表示領域MIR1において、ユーザB.Bの欄に表示されていた「依頼中」のマークが消え、その代わりに、表示残高として「4,000円」が表示されている。
なお、ユーザC.Cについては、ユーザA.Aからのウォレット連携の依頼に対する承認が未だなされていない状態であるため、「依頼中」のマークが表示されたままである。
図14-5左側には、支払いアプリケーションのおしらせ画面が表示されており、現在位置表示領域CLR3の下には、ユーザA.Aからウォレット連携の依頼があった旨の通知が表示されている。
端末20A側では、連携メンバー情報表示領域MIR1において、ユーザC.Cの欄に表示されていた「依頼中」のマークが消え、その代わりに、表示残高として「10,000円」が表示されている。
この連携支払い確認画面では、現在位置表示領域CLR1の下に、支払い金額確認領域PIR3が表示されている。支払い金額確認領域PIR3には、支払い金額として「12,000円」が表示されている。
・連携支払い可能額=全ての連携アカウントについての支払い余力の総和
・一の連携アカウントの支払い余力=その連携アカウントの表示残高(その連携アカウントの表示残高-等分支払い金額<0の場合)
・一の連携アカウントの支払い余力=等分支払い金額(その連携アカウントの表示残高-等分支払い金額≧0の場合)
ただし、「等分支払い金額=支払い金額÷連携アカウント数」として算出される。
ユーザA.Aのユーザアカウントについては、その表示残高が「3,000円」であり、等分支払い金額「4,000円」を下回るため、その支払い余力は「3,000円」となる。
ユーザB.Bのユーザアカウントについては、その表示残高が「4,000円」であり、等分支払い金額「4,000円」と同額であるため、その支払い余力は「4,000円」となる。
ユーザC.Cのユーザアカウントについては、その表示残高が「10,000円」であり、等分支払い金額「4,000円」を上回るため、その支払い余力は「4,000円」となる。
よって、連携支払い可能額は、「3,000円+4,000円+4,000円=11,000円」となる。
その結果、支払い金額確認領域PIR3には、警告マークと「残高不足です」の文字とが表示されている。
図14-7左側では、図14-6右側の画面の中央部に、表示上限金額を変更するための情報がポップアップ形式で表示されている。具体的には、「この支払いに関して表示上限金額を変更しますか?」の文字とともに、表示上限金額を、現在設定されている「3,000円」から「4,000円」に変更するように促す情報が表示されている。また、この変更に同意する場合に操作する「はい」のボタンと、この変更に同意しない場合に操作する「いいえ」のボタンとが表示されている。
この状態で、画面下部の連携支払い実行ボタンBT5がタップされると、図14-7右側の連携支払い結果表示画面が表示される。
メンバー支払い結果表示領域MRR1には、連携アカウントごとに、支払ったユーザアカウントと、それぞれのユーザアカウントで支払った金額と、支払い後の表示残高とが表示されている。
この画面では、ユーザA.Aの表示残高は変更前の「3,000円」に戻っている。また、ユーザB.Bの表示残高は、電子マネー口座残高が「6,000円-4,000円=2,000円」となったことに基づいて、「2,000円」に更新される。
図14-8~図14-10は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、端末20Bの制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
端末20Bの制御部21は、通信I/F22によって制限付き連携メンバー情報を受信すると、受信した制限付き連携メンバー情報を表示部24に表示させる(B630)。
また、限定ではなく例として、A640のステップにおいて、端末20Aの入出力部23に対するユーザ操作に基づいて、表示上限金額加算額の加算を一時的なものにするか恒久的なものにするかを設定可能なようにしてもよいし、そのようにしなくてもよい。
本実施例は、端末20が、異なる端末20のユーザ(限定ではなく、第2ユーザの一例)の第2ユーザアカウント(限定ではなく、第2アカウントの一例)に設定された表示上限金額(限定ではなく、第2金額の一例)に基づく表示残高(限定ではなく、第2金額に基づく第2アカウントの残高の一例)を表示部24に表示する。そして、端末20は、自己の端末20のユーザの第1ユーザアカウント(限定ではなく、第1アカウントの一例)と、表示上限金額が設定された第2ユーザアカウントとに基づき、第1ユーザの端末20によって連携アカウント決済に関する処理(限定ではなく、第1決済に関する処理の一例)を制御部21によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第1ユーザの第1アカウントに関連付けられた第2アカウントに設定された第2金額に基づく第2アカウントの残高を、第1ユーザに視認させることができる。この場合、限定ではなく例として、第2アカウントの真の残高に対応する金額とは異なる金額が第2金額として設定されることで、第2アカウントの真の残高を第1ユーザに秘匿することができる。
また、第1アカウントと、第2金額が設定された第2アカウントとに基づき、第1ユーザの端末によって第1決済を行わせることができる。
このような構成により得られる実施例の効果の一例として、第1アカウントに対しても表示上の金額(第1金額)を設定することができる。この場合、限定ではなく例として、第1アカウントの真の残高に対応する金額とは異なる金額を第1金額として設定することで、第1アカウントの真の残高を他のユーザに秘匿することができる。
また、設定された第1金額に基づく第1アカウントの残高と、設定された第2金額に基づく第2アカウントの残高との両方を、第1ユーザが確認できるようにすることができる。
このような構成により得られる実施例の効果の一例として、第2アカウントの真の残高を秘匿した上で、設定された最大金額を第1ユーザに視認させることができる。
このような構成により得られる実施例の効果の一例として、第2アカウントに設定された一回の決済に利用可能な最大金額を第1ユーザに視認させることができる。
このような構成により得られる実施例の効果の一例として、第2アカウントの残高が第2金額よりも大きい場合は、第2アカウントの真の残高が第1ユーザに秘匿されるようにすることができる。他方、第2アカウントの残高が第2金額よりも小さい場合は、第2アカウントの真の残高を第1ユーザに開示することができる。
このような構成により得られる実施例の効果の一例として、第1アカウントに一旦設定された第1金額を変更することができる。
このような構成により得られる実施例の効果の一例として、第1ユーザの第1アカウントと、第1アカウントと関連付けられた第2ユーザの第2アカウントとに基づき、決済を実現することができる。
上記の実施例では、支払いを実行する連携メンバーの支払い余力が、設定された表示上限金額では足りない場合に、表示上限金額を引き上げる例について説明したが、これに限定されない。
上記の実施例では、支払いの実行者(この例ではユーザA.A)の表示上限金額を引き上げることで、支払い余力の不足を解決する例を示したが、これに限定されない。
限定ではなく例として、他の連携メンバーに対して、表示上限金額の引き上げを要求するようにしてもよいし、そのようにしなくてもよい。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
限定ではなく例として、図14-8~図14-9の各ステップの実行後、図14-11~図14-12の処理が実行される。
このような構成により得られる実施例の効果の一例として、第1決済の金額が第1金額と第2金額の合計を超えていて第1決済を行うことができないような場合に、設定された第2金額を変更するように第2アカウントに要請することができる。
上記の実施例では、支払いを実行する連携メンバーの支払い余力が、設定された表示上限金額では足りない場合に、表示上限金額を引き上げる例について説明したが、これに限定されない。
限定ではなく例として、第3実施例で述べたように、他の連携メンバーに支払い余力の立て替えを依頼するようにしてもよいし、そのようにしなくてもよい。
図14-13は、本実施例において端末20Aの表示部24に表示される画面の遷移の一例を示す図である。
図14-13左側は、図14-6右側の連携支払い確認画面と同様の画面であるが、その表示が一部異なっている。具体的には、画面下部に、ユーザA.Aが、不足分の金額を他のユーザに立て替えてもらうための立て替え依頼ボタンBT4が表示されている。
この画面では、グループ「バンド仲間」の連携ウォレットであることを示す情報の下に、立て替えを依頼する連携メンバーの候補を選択するための領域が表示されている。この例では、立て替えを依頼する連携メンバーの候補としてユーザC.Cが表示されている。
なお、この例では、ユーザB.Bは表示残高が「4,000円」であり、ユーザA.Aの不足分の金額を立て替える余力がないため、立て替えを依頼する連携メンバーの候補として表示されていない。
この状態で、画面下部の連携支払い実行ボタンBT5がタップされると、支払いが実行される。
また、最も表示残高の多い連携メンバーを立て替え者として提案させるようにしてもよいし、そのようにしなくてもよい。
図14-14は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
限定ではなく例として、図14-8~図14-9の各ステップの実行後、図14-14の処理が実行される。
このような構成により得られる実施例の効果の一例として、第2アカウントに設定された第2金額と、第3アカウントに設定された第3金額とに基づいて、第1アカウントの不足分を支払うアカウントを適切に設定することができる。限定ではなく例として、第2アカウントと第3アカウントのうち、設定された金額が高い方のアカウントを、第1アカウントの不足分を支払うアカウントに設定することができる。
第14実施例では、サーバ10が、連携メンバーの端末20から取得した表示上限金額と、その連携メンバーの電子マネー口座残高とに基づいて、表示残高を算出した上で、各々の連携メンバーの端末20に送信することとしたが、これに限定されない。
つまり、端末20側で、表示する第2アカウントの残高の金額を制御するようにしてもよい。
第14実施例では、表示残高は表示上限金額による制限を受けることとした。表示上限金額は、個々の支払いにおいて連携支払い可能額に影響を及ぼす制限であった。
本実施例では、表示上限金額以外に、連携ウォレットにおいて複数回の支払いが生じる場合に影響を及ぼす制限として、限定ではなく例として、連続決済回数と、合計制限金額との2つの制限を導入する。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
第9の連携ウォレット管理データベース157Iには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。
・表示残高=MIN(MIN(表示上限金額,合計制限金額),電子マネー口座残高)
ただし、MIN(x,y)は、(x,y)のうち最小値を取る関数である。
すなわち、合計制限金額は、当初の定義から逸脱しないためには、表示上限金額以上の金額に設定する必要がある。
図15-2は、本実施例において端末20Aの表示部24に表示される画面の遷移の一例を示す図である。
図15-2左側の画面において、画面下部のウォレット連携依頼ボタンBT35がタップされると、図15-2中央の利用制限設定画面が表示される。
この画面は、表示上限金額を変更するための画面であり、この例では、変更する表示上限金額として「3,000円」が入力された状態が示されている。この状態で、画面下部の設定ボタンBT41がタップされると、入力された金額に表示上限金額が設定される。
この画面では、連携メンバー情報表示領域MIR4のユーザB.B、ユーザC.Cの欄の「依頼中」の文字が消え、それぞれの表示残高が表示されている。
また、連携メンバー情報表示領域MIR4のユーザA.Aの欄には、表示残高「3,000円」と電子マネー口座残高「10,000円」とが表示されている。また、その下には、表示上限金額「3,000円」と、連携決済回数「10回」と、合計制限金額「10,000円」とが表示されている。
また、グループ「バンド仲間」の全てのメンバーのウォレット連携が完了したことに伴い、コードリーダアイコンIC2およびコード支払いアイコンIC3のグレーアウトが解除され、アクティブな状態に変化して表示されている。
図15-4~図15-6は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
そして、サーバ10の制御部11は、算出された連携支払い可能額が決済予定金額を下回っているか否かを判定する(S645)。
すなわち、連続決済回数をデクリメントし、合計制限金額からその連携アカウントの支払い余力を減算する。
本実施例は、端末20が、自己の端末20のユーザ(限定ではなく、第1ユーザの一例)による自己の端末20に対する入力に基づいて、第1ユーザアカウントに対して、連続決済回数等の設定(限定ではなく、決済を複数回行うことに関する第1設定の一例)を制御部21によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、決済を複数回行うことに関する設定を、第1アカウントに対して簡易かつ適切に行うことができる。
このような構成により得られる実施例の効果の一例として、第1アカウントによって決済が可能な回数に関する設定を、簡易かつ適切に行うことができる。
このような構成により得られる実施例の効果の一例として、決済の回数が、第1設定によって設定された決済が可能な回数に達していない間は、第1ユーザの認証を不要として、第2アカウントと、第1ユーザの第1アカウントとに基づく決済を可能とすることができる。その一方で、決済の回数が、第1設定によって設定された決済が可能な回数に達している場合は、第1ユーザによる認証を必要とし、第1ユーザによって認証されなければ、第2アカウントと、第1ユーザの第1アカウントとに基づき決済が行われないようにすることができる。
上記の実施例では、支払いが繰り返し実行され、連携メンバーの連続決済回数が「0」以下になるか、合計制限金額が「0」以下になる場合、そのメンバーのアカウントからの支払いが実行されなくなる例を示したが、これに限定されない。
この場合、限定ではなく例として、自動的に連携ウォレットの破棄が実行されるようにしてもよいし、そうしなくてもよい。
上記の実施例では、連携ウォレットの支払い回数に対して連続決済回数による制限をかけていたが、これに限定されない。
限定ではなく例として、支払いを実行する各連携メンバーに対してそれぞれ連続決済回数を定めるようにしてもよいし、そうしなくてもよい。
上記の実施例では、連携メンバーの連続決済回数あるいは合計制限金額が「0」以下になる場合、そのメンバーのアカウントからの支払いが実行されなくなる例を示したが、これに限定されない。
限定ではなく例として、制限が発動し支払いの負担が行われないユーザについても、限定ではなく例として、支払い実行時に承諾を得ることで、支払いの負担が可能であるようにしてもよいし、そのようにしなくてもよい。
上記の実施例では、支払いを実行する連携メンバーの支払い余力が、設定された表示上限金額では足りない場合に、表示上限金額を引き上げる例について説明したが、これに限定されない。
限定ではなく例として、第14変形例で述べたように他の連携メンバーに支払い余力の立て替えを依頼するようにしてもよいし、そのようにしなくてもよい。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
限定ではなく例として、図15-4~図15-5の各ステップの実行後、図15-7の処理が実行される。
第12実施例~第15実施例では、アプリケーションとして支払いアプリケーションを適用する実施例について説明したが、これに限定されない。
第16実施例は、チャットアプリケーション(限定ではなく例として、メッセージングアプリケーション)において形成されるグループにおいて連携ウォレットを用いて支払いを行い、チャットルーム(限定ではなく例として、トークルーム)にその表示を行う実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
以下では、メッセージングアプリケーションのユーザであるとともに支払いアプリケーションのユーザでもあるユーザA.Aと、ユーザB.Bと、ユーザC.Cとが、何れもグループ「バンド仲間」に属しており、友だち登録されているものとする。
図16-1左側は、グループ「バンド仲間」のグループトークルーム画面であり、ユーザA.Aが、ユーザB.B、ユーザC.Cとグループトークを行っている状態が示されている。具体的には、ユーザA.Aから商品を購入しておく旨のメッセージが発信され、ユーザB.Bからそれに同意するメッセージが発信され、ユーザC.Cから代金をグループのメンバーみんなで支払うことを提案するメッセージが発信されている。
この状態で、画面下部の連携ウォレットアイコンIC1がタップされると、図16-1中央の画面が表示される。
また、その下の連携メンバー情報表示領域MIR4には、ユーザA.Aのユーザアカウントに関する情報と、ユーザB.Bのユーザアカウントに関する情報と、ユーザC.Cのユーザアカウントに関する情報とが表示されている。
また、この例では、他の連携メンバーであるユーザB.B、ユーザC.Cについては、表示残高が表示されている。
本実施例における処理については、限定ではなく例として、支払いアプリケーションを管理する支払いアプリケーション管理サーバと、メッセージングサービスを管理するメッセージングアプリケーション管理サーバとでの処理をサーバ10における処理として、図15-4~図15-6に従って同様に実行することが可能であるため、再度の説明は省略する。
第1実施例~第16実施例では、連携承認後に行われた支払いを対象として、連携アカウント間で精算(立替精算)を行う実施例について説明した。
第17実施例は、連携承認前に行われた支払いを対象とする場合の処理に関する実施例である。
上記の実施例では、未連携承認のアカウントが存在する場合、支払いを行うことができなかった。限定ではなく例として、アカウント連携の承認を得るまでに時間がかかることも想定され、この場合、連携承認されるまで支払いを行うことができなくなってしまう。
なお、遡及精算も精算の一種である。つまり、精算には「立替精算」と「遡及精算」とが含まれる。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
本実施例では、この場合における第1ユーザアカウントと第2ユーザアカウントとの連携(第1アカウントと第2アカウントとの関連付け)を、連携ウォレットが生成された後、第1ユーザアカウントが連携承認したこと(連携承認済みとなったこと)として説明する。
また、本実施例では、第1ユーザアカウントが連携承認したことに基づいて、連携ウォレットが生成される前(連携ウォレット生成要求情報がサーバに送信される前)に少なくとも第2ユーザアカウントによって行われた決済に関する情報を、第1ユーザアカウントの第1ユーザの端末20の表示部24に表示することとして説明する。
この場合、アカウントが連携されると、第1ユーザは、第2ユーザアカウントによる支払い履歴を確認する。
その後、第1ユーザは、限定ではなく例として、第2ユーザアカウントの電子マネー口座残高が少なくなっていることを確認した上で、第1ユーザアカウントから第2ユーザアカウントに対して送金するようにすることができる。
これは、限定ではなく例として、一のユーザが、自分の複数のユーザアカウントの電子マネー口座間で資金の移動を行う手法の1つと捉えることもできる。
第2のアカウント管理データベース155Bには、アカウント登録データ153に記憶されたアプリケーションIDごとの管理データとして、アカウント管理データが記憶される。
個々の要素については、限定ではなく例として、第1の連携ウォレット管理データベース157Aの連携ウォレット管理データにおける決済履歴データと同様に構成することが可能である。
第10の連携ウォレット管理データベース157Jには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。
以下、ユーザB.Bが、連携ウォレットを生成する前にユーザB.Bのユーザアカウントを用いてPPスーパーで「2,000円」の支払いを行った場合の表示画面例について説明する。
図17-3左側の画面は、支払いアプリケーションのおしらせ画面であり、この例では、ユーザB.Bからのウォレット連携の依頼に関する情報が表示されている。この情報には、限定ではなく例として、ユーザB.Bからウォレット連携の依頼があったことを示す文字と、ユーザB.Bによって生成されたユーザA.AとユーザB.Bの連携ウォレットであることを示すアイコンおよび文字とが含まれる。
なお、支払い履歴は決済履歴と表現してもよいし、しなくてもよい。
この画面には、現在位置表示領域CLR1の下に、ユーザB.Bのユーザアカウントによる単独支払い履歴(画面上は「購入履歴」)であることを示すアイコンおよび文字が表示され、その下には、その単独支払い履歴が表示されている。この例では、ユーザB.Bのユーザアカウントによって「PPスーパー」で「2020年8月2日19時10分33秒」に行われた、「2,000円」分の商品の購入に関する単独支払い履歴が表示されている。
図17-3右側の画面において、単独支払い履歴の表示欄には、ユーザB.Bのユーザアカウントが行った支払いを対象として、連携承認を行ったユーザA.AからユーザB.Bに対して遡及精算として送金を行うための送金ボタンBT52が表示されている。この例では、「2,000円」をユーザA.AとユーザB.Bとの2名で割り勘した金額として「1,000円」を送金するための送金ボタンBT52が表示されている。
図17-4~図17-5は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、端末20B(ユーザB.Bの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
そして、サーバ10の制御部11は、ウォレット連携承認確認情報を端末20Aに送信する(S510)。
一方、ウォレット連携承認情報を受信しない場合には(S520:NO)、サーバ10の制御部11は、処理を終了させる。
また、連携ウォレット生成要求情報に、S740のステップで送信する決済履歴を選択する情報を含むようにしてもよいし、そのようにしなくてもよい。
本実施例は、端末20が、自己の端末20のユーザ(限定ではなく、第1ユーザの一例)の第1ユーザアカウント(限定ではなく、第1アカウントの一例)と、第2ユーザアカウントとに基づくアカウント連携決済を行うためのウォレット連携承認確認情報(限定ではなく、第1情報の一例)を通信I/F22によって受信し、受信したウォレット連携承認確認情報の表示(限定ではなく、第1表示の一例)を表示部24に表示する。
また、端末20は、自己の端末20のユーザによるウォレット連携承認確認情報の表示に対する入力に基づいて、アカウント連携・連携承認に関する処理(限定ではなく、第1アカウントと第2アカウントとの関連付けに関する処理の一例)を制御部21によって行う。
そして、端末20は、アカウント連携・連携承認(限定ではなく、第1アカウントと第2アカウントとの関連付けの一例)に基づき、少なくとも第2ユーザアカウントによって行われた支払い履歴の情報(限定ではなく、少なくとも第2アカウントによって行われた第1決済に関する情報の一例)を表示部24に表示する構成を示している。
このような構成により得られる実施例の効果の一例として、第1アカウントと第2アカウントとの関連付けに基づき、少なくとも第2アカウントによって行われた第1決済に関する情報が端末の表示部に表示されるため、第1ユーザは、限定ではなく例として、第1アカウントと第2アカウントとが関連付けられる以前に少なくとも第2アカウントによって行われた第1決済の内容を確認して把握することができる。
このような構成により得られる実施例の効果の一例として、第1ユーザによる第1決済に関する情報に対する入力という簡単な方法によって、第1決済のうちの少なくとも一部である第1金額を、第1アカウントから第2アカウントへ送金させることができる。
また、サーバ10は、端末20に表示されたウォレット連携承認確認情報の表示(限定ではなく、第1表示の一例)に対する端末20のユーザによる入力に基づいて、アカウント連携・連携承認に関する処理(限定ではなく、第1アカウントと第2アカウントとの関連付けに関する処理の一例)を制御部11によって行う。
そして、サーバ10は、アカウント連携・連携承認(限定ではなく、第1アカウントと第2アカウントとの関連付けの一例)に基づき、少なくとも第2ユーザアカウントによって行われた支払い履歴の情報(限定ではなく、少なくとも第2アカウントによって行われた第1決済に関する情報の一例)を通信I/F14によって端末20に送信する構成を示している。
このような構成により得られる実施例の効果の一例として、第1アカウントと第2アカウントとの関連付けに基づき、少なくとも第2アカウントによって行われた第1決済に関する情報を第1ユーザの端末に送信することで、限定ではなく例として、第1アカウントと第2アカウントとが関連付けられる以前に少なくとも第2アカウントによって行われた第1決済の内容を第1ユーザに確認させることができる。
このような構成により得られる実施例の効果の一例として、第1ユーザによる、端末に表示された第1決済に関する情報に対する入力がなされたことに基づいて、第1決済のうちの少なくとも一部である第1金額を、第1アカウントから第2アカウントへ送金することができる。
また、端末20は、ウォレット連携承認確認情報を第2ユーザアカウントに対して送信してから、ウォレット連携承認確認情報に基づく、ウォレット連携承認情報(限定ではなく、第1アカウントと第2アカウントとの関連付けの承認に関する情報の一例)を第2アカウントから通信I/F22によって受信するまでの間に、少なくとも第1ユーザアカウントに基づくアカウント連携決済を行わせるための処理(限定ではなく、第1決済に関する処理の一例)を制御部21によって行う。
そして、端末20は、アカウント連携・連携承認(限定ではなく、第1アカウントと第2アカウントとの関連付けの一例)に基づき、第2ユーザアカウントから送金された第1金額(限定ではなく、第1決済に基づく金額の一例)を受け取る処理を制御部21によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、第1アカウントと第2アカウントとの関連付けに関する第1情報を第2アカウントに対して送信してから、第1情報に基づく第1アカウントと第2アカウントとの関連付けの承認に関する情報を第2アカウントから受信するまでの間に、少なくとも第1アカウントに基づく第1決済を行った上で、第1アカウントと第2アカウントとの関連付けに基づき、第2アカウントから送金された第1決済に基づく金額を受け取ることができる。
上記の実施例では、連携ウォレット生成要求情報が端末20Bからサーバ10に送信される前に行われた支払いについて、連携アカウント間で遡及精算を行うこととしたが、これに限定されない。
限定ではなく例として、連携ウォレット生成要求情報が端末20Bからサーバ10に送信されてから、ウォレット連携承認を依頼された第1ユーザアカウントが連携承認するまでの間に行われた支払いについて、遡及精算を行うようにしてもよいし、そのようにしなくてもよい。
このため、端末20Aがウォレット連携承認確認情報(限定ではなく、第1情報の一例)を受信してから、第1ユーザアカウントが連携承認するまでの間に行われた支払いについて遡及精算を行うこともこれに含まれる。
このため、サーバ10によってウォレット連携承認確認情報(限定ではなく、第1情報の一例)が送信されてから、第1ユーザアカウントが連携承認するまでの間に行われた支払いについて遡及精算を行うこともこれに含まれる。
この図では、左側から順に、端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、端末20B(ユーザB.Bの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
このような構成により得られる変形例の効果の一例として、端末が第1情報を受信してから第1アカウントと第2アカウントとの関連付けが行われるまでの間に行われた第1決済を対象として、その第1決済に関する情報を端末の表示部に表示して、第1ユーザがその内容を確認して把握できるようにすることができる。
また、端末が第1情報を受信してから第1アカウントと第2アカウントとの関連付けが行われるまでの間に行われた第1決済を対象として、その第1決済のうちの少なくとも一部である第1金額を第1アカウントから第2アカウントへ送金することができる。
上記の変形例では、図17-6のS740のステップにおいて送信される決済履歴情報を、ユーザアカウントでの決済の履歴の情報であることとしたが、これに限定されない。
限定ではなく例として、上記の決済履歴情報を、連携ウォレット生成後、連携アカウントが連携承認するまでの間に行われた連携ウォレットでの決済の履歴の情報とすることもできる。つまり、連携ウォレット生成後、連携アカウントが連携承認するまでの間に行われた連携ウォレットでの決済を対象として、決済履歴の表示や遡及精算を行うようにすることもできる。
図17-7左側は、支払いアプリケーションのメイン画面であり、ユーザA.Aが連携承認した状態が示されている。
この例では、ユーザA.AとユーザB.Bの連携ウォレットであることを示す情報の表示欄に、連携ウォレット生成後、ユーザA.Aが連携承認するまでの間に行われた連携ウォレットでの支払い履歴(以下、「連携ウォレット支払い履歴」と称する。)を表示するための連携ウォレット支払い履歴ボタンBT54が表示されている。この連携ウォレット支払い履歴ボタンBT54がタップされると、図17-7右側の画面が表示される。
さらに、この連携ウォレットによる支払い履歴を確認した上で、ユーザA.Aが、連携ウォレットによる支払い金額の一部または全部の金額を負担して、立替者であるユーザB.Bへの送金(立て替えてもらった金額の返却)を行うことができるように構成されている。
このような構成により得られる変形例の効果の一例として、第2アカウントと、第2アカウントと関連付けられた第3アカウントとに行われた第1決済を対象として、その第1決済に関する情報を端末の表示部に表示して、第1ユーザがその内容を確認して把握できるようにすることができる。
また、第2アカウントと、第2アカウントと関連付けられた第3アカウントとに行われた第1決済を対象として、その第1決済のうちの少なくとも一部である第1金額を第1アカウントから第2アカウントへ送金することができる。
このような構成により得られる実施例の効果の一例として、複数のユーザが決済可能な共通アカウントを第2アカウントとして、第1アカウントと関連付けることができるため、ユーザの利便性を向上させることができる。
上記の実施例において、第1ユーザアカウントが未連携承認の状態であっても、第1ユーザアカウントが、少なくとも第2ユーザアカウントによる決済履歴(前述した単独支払い履歴や連携ウォレット履歴)を閲覧したり、第2ユーザアカウントに対する送金(遡及精算)を行うことができるようにしてもよい。
この場合、第1ユーザアカウントが未だ連携承認を行っていない状態であっても、自己の端末20のユーザ(第1ユーザ)によって決済履歴(単独支払い履歴や連携ウォレット支払い履歴)を表示するための入力がなされると、端末20は、その決済履歴をサーバ10に要求し、サーバ10から送信された決済履歴を受信したことに基づいて、決済履歴を表示部24に表示するようにすることができる。
前述したように、遡及精算の対象とする期間として、限定ではなく例として、
(a)連携ウォレット生成要求情報が端末20Bからサーバ10に送信される前の期間
(b)連携ウォレット生成要求情報が端末20Bからサーバ10に送信されてから、ウォレット連携承認を依頼されたユーザアカウントが連携承認するまでの期間
のいずれかを適用することができる。
限定ではなく例として、支払い履歴の表示対象とする期間は(a)+(b)の期間とするが、遡及精算の対象とする期間は(a)の期間とする。または、限定ではなく例として、支払い履歴の表示対象とする期間は(a)+(b)の期間とするが、遡及精算の対象とする期間は(b)の期間とするなどしてもよい。
第17実施例では、連携ウォレットの連携メンバー全員が連携承認していない場合でも、連携ウォレットに関する支払いが可能であることについて説明した。
これに関連して、第18実施例は、メッセージングアプリケーション(メッセージングサービス)のグループを単位として連携ウォレットを生成し、グループメンバー全員が連携承認していない場合でも、このグループの連携ウォレットを用いて支払いを実行可能とする実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図18-1は、本実施例において用いられる連携ウォレットを管理するためのデータベースの一例である第11の連携ウォレット管理データベース157Kのデータ構成例を示す図である。
第11の連携ウォレット管理データベース157Kには、連携ウォレットごとの管理データとして、連携ウォレット管理データが記憶される。
以下では、メッセージングアプリケーションのユーザであるとともに支払いアプリケーションのユーザでもあるユーザA.Aと、ユーザB.Bと、ユーザC.Cとが、何れもグループ「バンド仲間」に属しており、友だち登録されているものとする。
図18-2左側は、端末20Aの表示部24に表示されるメッセージングアプリケーションのトークルーム画面の一例を示す図である。
このトークルーム画面は、グループ「バンド仲間」のグループトークルーム画面であり、ユーザA.Aが、ユーザB.BおよびユーザC.Cとトーク(チャット)を行っている状態が示されている。
このトークルーム画面は、グループ「バンド仲間」のグループトークルーム画面であり、ユーザA.AがユーザC.Cの後払いを了承したメッセージの下に、ユーザA.Aからのウォレット連携依頼メッセージが表示されている。また、その下には、ユーザA.Aが商品を購入したことを報告するメッセージが表示されている。
連携承認ボタンがタップされると、端末20Bの表示部24には、図18-3左側の画面が表示される。
連携ウォレット情報表示領域WIR1には、グループ「バンド仲間」の連携ウォレットであることを示す情報の表示欄に、連携ウォレット支払い履歴ボタンBT54が表示されている。
この画面では、連携ウォレット情報表示領域WIR1に、グループ「バンド仲間」の連携ウォレットの支払い履歴として、「XX楽器」での「4,500円」の支払いに関する情報が表示されている。また、この表示欄には、この支払いに対する遡及精算を行うための精算ボタンBT58が表示されている。精算ボタンBT58がタップされると、図18-3右側の画面が表示される。
左から順に、端末20A、端末20B、端末20Cで表示されるグループトークルーム画面の一例を示している。
このトークルーム画面は、グループ「バンド仲間」のグループトークルーム画面であり、図18-5左側の画面では、グループ「バンド仲間」のトークルーム画面の下部から、連携ウォレット情報表示領域WIR1がせり上がって表示されている。
具体的には、コードリーダアイコンIC2とコード支払いアイコンIC3とはグレーアウトしており、タップしても、その操作を受け付けないように構成されている。
また、連携ウォレット支払い履歴ボタンBT54もグレーアウトしており、タップしても、その操作を受け付けないように構成されている。
また、連携ウォレット破棄ボタンBT30もグレーアウトしており、タップしても、その操作を受け付けないように構成されている。
この画面では、連携ウォレット情報表示領域WIR1の中央部に、ウォレット連携を行わないと支払いを行うことができないことを示す情報が、ポップアップ形式で表示されている。具体的には、「連携しないと支払いできません」の文字が表示されている。「
その下には、「ウォレット連携する」と示された連携承認ボタンが表示されており、連携承認ボタンがタップされると、連携ウォレットの使用の制限も解除される。
図18-6は、この場合に各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、端末20およびサーバ10で構成されるシステムが実行する処理の一例を示している。なお、サーバ10を、支払いサービスを管理する支払いアプリケーション管理サーバと、メッセージングサービスを管理するメッセージングアプリケーション管理サーバに分けて構成するようにしてもよいし、そのようにしなくてもよい。
また、2人のユーザ間のトークルームにおいて、そのトークルームが生成されると、自動的にそのトークルームにおける連携ウォレットが生成されるようにしてもよいし、そのようにしなくてもよい。この場合には、トークルームを2人のメンバーのグループとして取り扱えばよい。
この図では、左側から順に、あるグループにおいて連携ウォレットの生成を指示するユーザの端末である端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、このグループメンバーの端末である端末20B(ユーザB.Bの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
この図では、左側から順に、連携済みユーザの端末である端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、未連携ユーザの端末である端末20B(ユーザB.Bの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
この図では、左側から順に、アカウント連携済みユーザの端末である端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、新たにアカウント連携したユーザの端末である端末20B(ユーザB.Bの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
・遡及精算必要額=決済での支払い額÷(決済参加アカウントデータに記録されたアカウント数+1)
・決済参加アカウントデータに記録された各アカウントへの送金額=遡及精算必要額÷決済参加アカウントデータに記録されたアカウント数
通信I/F22によってサーバ10から遡及精算結果情報を受信すると、端末20Aの制御部21は、遡及精算結果情報を表示部24に表示させ(B790)、処理を終了させる。
なお、連携ウォレット精算処理については、限定ではなく例として、図7-5に従って実行することが可能である。
なお、この場合、支払いを実行しようとする端末20の表示部24に、再度ウォレット連携承認確認情報を表示させ、連携承認を促すようにしてもよいし、そのようにしなくてもよい。
なお、端末20Aの制御部21は、加えて決済参加アカウントデータを受信し、決済履歴データと立替履歴データとのうち、端末20Aが連携承認を行った後の取引に関する履歴のみを表示するようにしてもよいし、そのようにしなくてもよい。
そして、精算内容が立替精算の場合は(L210:立替精算)、連携ウォレット精算処理を実行する(L180)。一方、精算内容が連携承認前の支払いに関する遡及精算の場合は(L210:遡及精算)、連携ウォレット遡及精算処理を実行する(L140)。
なお、複数の取引の立替精算や遡及精算をまとめて行うようにしてもよいし、そのようにしなくてもよい。
ここでは、上記のフローで説明したアカウント追加連携処理と、連携ウォレット支払い処理と、連携ウォレット遡及精算処理とが各端末において実行指示されるタイミングについて説明する。説明を簡略化するため、連携ウォレット支払い処理において、立て替えは発生しない場合を考える。
このタイミングチャートでは、横軸を時間軸とし、各端末20が、アカウント追加連携処理を行うタイミングを白の六角形で、連携ウォレット支払い処理を行うタイミングを白の丸で、連携ウォレット遡及精算処理を行うタイミングを白の四角形で示している。
その後、端末20Bにおいて、アカウント追加連携処理が実行される。そして、端末20Bにおいて、支払い1に関する連携ウォレット遡及精算処理が実行される。
その後、端末20Cにおいて、アカウント追加連携処理が実行される。そして、端末20Cにおいて、支払い1と支払い2とに関する連携ウォレット遡及精算処理が実行される。
そして、端末20Cにおいて、支払い3が実行される。支払い3には、ユーザA.AとユーザB.BとユーザC.Cとが参加している。
本実施例は、ウォレット連携承認確認情報(限定ではなく、第1情報の一例)は、第2ユーザアカウントの第2ユーザによる、第1ユーザアカウントの第1ユーザと、第2ユーザとを含むトークルーム(限定ではなく、チャットルームの一例)に対する入力に基づいて、第1ユーザの端末20に送信される構成を示している。
このような構成により得られる実施例の効果の一例として、第2アカウントの第2ユーザによる、第1ユーザと、第2ユーザとを含むチャットルームに対する入力に基づいて、第1情報が第1ユーザの端末に簡単に送信されるようにすることができる。
このような構成により得られる実施例の効果の一例として、第2アカウントの第2ユーザによる、第1ユーザと、第2ユーザとを含むチャットルームの作成に基づいて、第1情報が第1ユーザの端末に簡単に送信されるようにすることができる。
このような構成により得られる実施例の効果の一例として、チャットルームへの表示という分かり易い形で、第1金額を第2アカウントに送金したことを、第1アカウントの第1ユーザに知らせることができる。
このような構成により得られる実施例の効果の一例として、第1アカウントと第2アカウントとの関連付けが行われていない場合、第1アカウントと、第2アカウントとに基づく決済を行うことができないようにすることができる。
上記の実施例では、連携承認後、連携ウォレットでの支払い履歴が確認可能となるとして説明したが、これに限定されない。
第17変形例(3)と同様に、連携ウォレット生成後、連携承認が「未」であるアカウントの端末20においても、連携ウォレットでの支払い履歴の確認ができるようにしてもよいし、そのようにしなくてもよい。
図18-11左側および中央の端末20Aの表示部24に表示される画面は、図18-2左側および中央とそれぞれ同様である。
図18-11右側の端末20Bの表示部24に表示される画面は、図18-2右側と同様であるが、この例では、グループトークルームに表示されるメッセージの時系列が一部異なっている。
つまり、この表示画面例では、ユーザB.Bが連携承認する前に、連携ウォレットによる決済履歴を、自身の端末20Bに表示されるグループトークルーム画面で確認できるように構成されている。
上記の実施例では、連携ウォレットの支払い履歴確認後、立替精算や遡及精算が実行されるとしたが、これに限定されない。
限定ではなく例として、図18-6においてL110のステップで一括立替精算が選択されると、その時点までの取引(支払い)の立て替えを一括で精算するようにしてもよいし、そのようにしなくてもよい。
また、限定ではなく例として、図18-6においてL110のステップで一括遡及精算が選択されると、その時点までの取引(支払い)の遡及精算を一括で実行するようにしてもよいし、そのようにしなくてもよい。
もしくは、一括立替精算と一括遡及精算とを一括して実行するようにしてもよいし、そのようにしなくてもよい。
第18実施例では、連携ウォレット遡及精算処理は、新たに連携承認したアカウントのユーザが能動的に連携承認前の支払いについての精算を実行する処理として説明したが、これに限定されない。
第19実施例は、新たに連携承認したユーザに対して、連携承認前の支払いを催促する実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
図19-1は、本実施例において端末20Aの表示部24に表示される画面の遷移の一例を示す図である。
図19-1左側では、グループ「バンド仲間」のグループトークルームの画面下部から、連携ウォレット情報表示領域WIR1がせり上がって表示されている。また、グループ「バンド仲間」の連携ウォレットであることを示す情報の表示欄には、連携ウォレット支払い履歴ボタンBT54が表示されている。この連携ウォレット支払い履歴ボタンBT54がタップされると、図19-1中央の画面が表示される。
図19-2左側は、端末20Aに表示されるグループトークルーム画面であり、限定ではなく例として、連携ウォレットでの支払い完了通知メッセージ→ユーザA.Aからの商品購入報告メッセージ→ユーザB.Bによる連携承認メッセージ、の順でメッセージが表示されている。
この支払い催促メッセージには、支払いアプリケーション[Payment App]の文字および「おねだり」の文字とともに、支払いの催促の詳細に関する情報が表示されている。
また、支払い催促メッセージには精算ボタンが設けられており、精算ボタンをタップすることで、ユーザA.Aからの支払いの催促に対する精算、つまり、ユーザB.BからユーザA.Aへの送金を行うことが可能に構成されている。
なお、これに限定されず、端末20Aに表示されるグループトークルームにも、支払い催促メッセージを表示させるようにしてもよい。
図19-3は、本実施例における連携ウォレット遡及精算処理において各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、左側から順に、連携済みユーザの端末である端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、新たに連携したユーザの端末である端末20B(ユーザB.Bの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
通信I/F14によって端末20Bから遡及精算情報を受信する場合(S775:YES)、サーバ10の制御部11は、S780~S790のステップを実行する。
通信I/F22によってサーバ10から遡及精算結果情報を受信する場合(A750:YES)、端末20Aの制御部21は、A760のステップを実行する。
本実施例は、端末20は、第1ユーザアカウントと第2ユーザアカウントとの連携に基づき、少なくとも第2ユーザアカウントによって行われた支払い履歴の情報(限定ではなく、第2決済に関する情報の一例)を表示部24に表示する。また、端末20は、この支払い履歴に基づく支払いを催促する情報(限定ではなく、第2決済の支払いの依頼に関する第2情報の一例)を通信I/F22によって受信する構成を示している。
このような構成により得られる実施例の効果の一例として、第1アカウントと第2アカウントとの関連付けに基づき、少なくとも第2アカウントによって行われた第2決済に関する情報が端末の表示部に表示されるため、第1ユーザは、限定ではなく例として、第1アカウントと第2アカウントとが関連付けられる以前に少なくとも第2アカウントによって行われた第2決済に関する情報を確認して把握することができる。
このような構成により得られる実施例の効果の一例として、受信した第2決済の支払いの依頼に関する第2情報を確認した上で、第1ユーザが、第2決済の支払いを行うことができる。
このような構成により得られる実施例の効果の一例として、チャットルームに含まれる第1ユーザと第2ユーザとで送受信されるメッセージを中継するサーバから、第2情報を簡単に取得することができる。
このような構成により得られる実施例の効果の一例として、支払いの依頼先のユーザ(第1ユーザ)に第2決済の支払いの依頼があったことを確実に知らせることができる。一方、支払いの依頼元のユーザ(第2ユーザ)に対しては支払いを依頼したことを確認不要とすることができる。
このような構成により得られる実施例の効果の一例として、チャットルームに表示された第2表示に対する第1ユーザによる入力という簡単な方法で、第2決済のうちの少なくとも一部である第2金額を第1アカウントから第2アカウントへ送金することができる。
上記の実施例では、遡及精算依頼情報は、サーバ10から送信されるとしたが、これに限定されない。限定ではなく例として、図19-3のA740のステップにおいて、端末20Aの制御部21は、遡及精算要求情報を通信I/F22によって端末20Bに直接送信するようにしてもよいし、そのようにしなくてもよい。
上記の実施例では、連携ウォレットの破棄(全ての連携アカウントについて一括して連携ウォレットを無効化)について説明したが、これに限定されない。
第20実施例は、各々の連携アカウントがアカウント連携を解除する手法に関する実施例である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
(a)連携承認の解除
(b)連携アカウントの削除
なお、これとは異なり、アカウント連携の解除に、他の連携アカウントの承認を必要としてもよい。
図20-1は、本実施例において端末20の表示部24に表示される画面の遷移の一例を示す図である。
図20-1左側は、端末20Bの表示部24に表示される画面の一例を示す図である。この画面は、グループ「バンド仲間」のグループトークルーム画面であり、連携ウォレット情報表示領域WIR1が、画面下部からせり上がって表示されている。
なお、連携ウォレット破棄ボタンBT30の表示は必須ではなく、これを表示させないようにしてもよい。
図20-2は、この場合に各装置が実行する処理の流れの一例を示すフローチャートである。
この図では、端末20およびサーバ10で構成されるシステムが実行する処理の一例を示している。
なお、サーバ10を、支払いサービスを管理する支払いアプリケーション管理サーバと、メッセージングサービスを管理するメッセージングアプリケーション管理サーバに分けて構成するようにしてもよいし、そのようにしなくてもよい。
この図では、左側から順に、連携承認済みユーザの端末である端末20A(ユーザA.Aの端末20)の制御部21が実行する処理、アカウント連携の解除を選択したユーザの端末である端末20B(ユーザB.Bの端末20)の制御部21が実行する処理、サーバ10の制御部11が実行する処理の一例を示している。
端末20Aの入出力部23に対するユーザ操作に基づいて、アカウント連携の解除を実行することを認可することが選択される場合(A810:YES)、端末20Aの制御部21は、アカウント連携解除認可情報を、通信I/F22によってサーバ10に送信する。
認可しないことが選択される場合には(A810:NO)、端末20Aの制御部21は、処理を終了させる。
なお、アカウント連携解除情報は、アカウント連携解除を要求(申請)した端末20と、アカウント連携解除確認情報を送信した端末20とに対してのみ送信するようにしてもよいし、そのようにしなくてもよい。
また、アカウント連携解除情報は、アカウント連携解除を要求(申請)した端末20と、連携ウォレットを生成した端末20とに対して送信するようにしてもよいし、そのようにしなくてもよい。
また、連携ウォレットの代表者、またはグループの代表者の端末20も含めて送信するようにしてもよい。
アカウント連携解除情報を受信しない場合(B820:NO)、端末20Bの制御部21は、処理を終了させる。
・グループ全員からアカウント連携解除の認可を得た場合
・連携承認済みメンバー全員からアカウント連携解除の認可を得た場合
・設定人数を超えるメンバー(限定ではなく例として、連携承認済みメンバーの過半数)からアカウント連携解除の認可を得た場合
・連携ウォレットを生成したメンバーからアカウント連携解除の認可を得た場合
・連携ウォレットの代表者、またはグループの代表者からアカウント連携解除の認可を得た場合
・他のメンバーのアカウント連携解除の認可なしに無条件でアカウント連携解除が実行される場合
一方、アカウント連携が解除されていないメンバーが残っている場合は(L240:NO)、L110のステップに処理を戻す。
この場合は、連携ウォレット生成処理を実行せずとも、グループ内のメンバーが連携承認を行えば、再び連携ウォレットによる支払いを行うことが可能となる。
ここでは、上記のフローで説明したアカウント追加連携処理と、連携ウォレット支払い処理と、連携ウォレット遡及精算処理と、連携ウォレット脱退処理とが各端末において実行指示されるタイミングについて説明する。説明を簡略化するため、連携ウォレット支払い処理において、立て替えは発生しない場合を考える。
このタイミングチャートでは、横軸を時間軸とし、各端末20が、アカウント追加連携処理を行うタイミングを白の六角形で、連携ウォレット支払い処理を行うタイミングを白の丸で、連携ウォレット遡及精算処理を行うタイミングを白の四角形で、連携ウォレット脱退処理を行うタイミングを白の三角で示している。
その後、端末20Bにおいて、連携ウォレット脱退処理が実行される。
そして、端末20Cにおいて、支払い2が実行される。支払い3には、ユーザA.AとユーザC.Cとが参加している。
端末20Bにおいて、支払い3が実行される。支払い3には、ユーザA.AとユーザB.BとユーザC.Cとが参加している。
最後に、端末20Bにおいて、連携ウォレット脱退処理が実行され、その後、連携ウォレット破棄処理が実行される。
本実施例は、端末20が、第1ユーザアカウントのアカウント連携を解除するための処理、つまり、第1ユーザアカウントと第2ユーザアカウントとの連携を解除するための処理(限定ではなく、第1アカウントと第2アカウントとの関連付けの解除に関する処理の一例)を制御部21によって行う構成を示している。
このような構成により得られる実施例の効果の一例として、一旦関連付けた第1アカウントと第2アカウントとの関連付けを解除することができる。
このような構成により得られる実施例の効果の一例として、第2アカウントに対して関連付けを解除することを確認することができる。
このような構成により得られる実施例の効果の一例として、第2アカウントの第2ユーザの許可がなければ、第1アカウントと第2アカウントとの関連付けが解除されないようにすることができる。つまり、第2ユーザの意に沿わずに第1アカウントと第2アカウントとが解除されてしまうことを防止できる。
このような構成により得られる実施例の効果の一例として、第1ユーザが、第1ユーザと、第2アカウントの第2ユーザとを含むチャットルームから退出する場合に、第1アカウントと第2アカウントとの関連付けを併せて解除することができる。
上記の実施例では、連携ウォレット脱退処理が実行されると、アカウント連携が解除されることとしたが、これに限定されない。
限定ではなく例として、連携ウォレット脱退処理が実行されると、連携ウォレット精算処理または連携ウォレット遡及精算処理、あるいはその両方が実行され、その後、アカウント連携が解除されるようにしてもよいし、そのようにしなくてもよい。
図20-5左側には、図20-1左側と同様の画面が表示されている。連携ウォレット脱退ボタンBT70がタップされると、限定ではなく例として、図20-5右側の画面が表示される。
この場合、アカウント連携を解除しようとする連携アカウントに未精算である立替精算や遡及精算が残っている場合には、アカウント連携解除は行われないことになる。
すなわち、アカウント連携解除しようとする連携アカウントに連携ウォレット内での貸し借りが存在しない場合には、他のメンバーの認可不要で、アカウント連携を解除するようにすることも可能である。
このような構成により得られる実施例の効果の一例として、第1アカウントと第2アカウントとの関連付けに基づき、少なくとも第2アカウントによって行われた第3決済に関する情報を第1ユーザが閲覧して確認できるようにすることができる。また、第1アカウントと第2アカウントとが解除された場合に、第3決済の支払いに関する情報を第1ユーザが閲覧して確認できるようにすることができる。
10 サーバ
20 端末
30 ネットワーク
40 店舗POSシステム
50 店舗コードリーダ装置
Claims (21)
- 決済に関する処理を行う端末によって実行されるプログラムであって、
前記端末の第1ユーザの第1アカウントと、第2アカウントとに基づく前記決済を行うための、前記第1アカウントと前記第2アカウントとの関連付けに関する第1情報を前記端末の通信部によって受信することと、
前記第1情報に基づく第1表示を前記端末の表示部に表示することと、
前記第1ユーザによる前記第1表示に対する入力に基づいて、前記第1アカウントと前記第2アカウントとの関連付けに関する処理を前記端末の制御部によって行うことと、
前記第1アカウントと前記第2アカウントとの関連付けに基づき、少なくとも前記第2アカウントによって行われた第1決済に関する情報を前記表示部に表示することと、
前記第1ユーザによる前記第1決済に関する情報に対する入力に基づいて、前記第1決済のうちの少なくとも一部である第1金額を前記第1アカウントから前記第2アカウントへ送金することに関する処理を前記制御部によって行うこととが前記端末によって実行され、
前記第1決済は、前記第1情報を受信してから、前記第1アカウントと前記第2アカウントとの関連付けが行われるまでの間に行われた決済である。 - 決済に関する処理を行う端末によって実行されるプログラムであって、
前記端末の第1ユーザの第1アカウントと、第2アカウントとに基づく前記決済を行うための、前記第1アカウントと前記第2アカウントとの関連付けに関する第1情報を前記端末の通信部によって前記第2アカウントに対して送信することと、
前記第1情報を前記第2アカウントに対して送信してから、前記第1情報に基づく、前記第1アカウントと前記第2アカウントとの関連付けの承認に関する情報を前記第2アカウントから前記通信部によって受信するまでの間に、少なくとも前記第1アカウントに基づく第1決済に関する処理を前記端末の制御部によって行うことと、
前記第1アカウントと前記第2アカウントとの関連付けに基づき、前記第2アカウントから送金された前記第1決済に基づく金額を受け取る処理を前記制御部によって行うこととが前記端末によって実行される。 - 決済に関する処理を行う端末によって実行されるプログラムであって、
前記端末の第1ユーザの第1アカウントと、第2アカウントとに基づく前記決済を行うための、前記第1アカウントと前記第2アカウントとの関連付けに関する第1情報を前記端末の通信部によって受信することと、
前記第1情報に基づく第1表示を前記端末の表示部に表示することと、
前記第1ユーザによる前記第1表示に対する入力に基づいて、前記第1アカウントと前記第2アカウントとの関連付けに関する処理を前記端末の制御部によって行うことと、
前記第1アカウントと前記第2アカウントとの関連付けに基づき、少なくとも前記第2アカウントと、前記第2アカウントに関連付けられた第3アカウントとによって行われた第1決済に関する情報を前記表示部に表示することと、
前記第1ユーザによる前記第1決済に関する情報に対する入力に基づいて、前記第1決済のうちの少なくとも一部である第1金額を前記第1アカウントから前記第2アカウントへ送金することに関する処理を前記制御部によって行うこととが前記端末によって実行される。 - 決済に関する処理を行う端末によって実行されるプログラムであって、
前記端末の第1ユーザの第1アカウントと、第2アカウントとに基づく前記決済を行うための、前記第1アカウントと前記第2アカウントとの関連付けに関する第1情報を、前記第2アカウントの第2ユーザによる、前記第1ユーザと、前記第2ユーザとを含むチャットルームの作成に基づき前記端末の通信部によって受信することと、
前記第1情報に基づく第1表示を前記端末の表示部に表示することと、
前記第1ユーザによる前記第1表示に対する入力に基づいて、前記第1アカウントと前記第2アカウントとの関連付けに関する処理を前記端末の制御部によって行うことと、
前記第1アカウントと前記第2アカウントとの関連付けに基づき、少なくとも前記第2アカウントによって行われた第1決済に関する情報を前記表示部に表示することと、
前記第1ユーザによる前記第1決済に関する情報に対する入力に基づいて、前記第1決済のうちの少なくとも一部である第1金額を前記第1アカウントから前記第2アカウントへ送金することに関する処理を前記制御部によって行うこととが前記端末によって実行される。 - 請求項4に記載のプログラムであって、
前記第1アカウントから前記第2アカウントへ第1金額を送金することに関する処理に基づき、前記第1金額を前記第2アカウントに送金したことを示す表示を前記チャットルームに表示することが前記端末によって実行される。 - 請求項5に記載のプログラムであって、
前記第1アカウントと前記第2アカウントとの関連付けが行われていない場合、前記第1アカウントと、前記第2アカウントとに基づく前記決済を行うための第1コード情報、または前記第1アカウントと、前記第2アカウントとに基づく前記決済を行うための第2コード情報を読み取るための表示を前記表示部に表示しない制御を前記制御部によって行うことが前記端末によって実行される。 - 請求項1に記載のプログラムであって、
前記第1情報は、前記第2アカウントの第2ユーザによる、前記第1ユーザと、前記第2ユーザとを含むチャットルームに対する入力に基づいて、前記端末に送信される。 - 請求項1、請求項3から請求項7のいずれか一項に記載のプログラムであって、
前記第1アカウントと前記第2アカウントとの関連付けに基づき、少なくとも前記第2アカウントによって行われた第2決済に関する情報を前記表示部に表示することと、
前記第2決済の支払いの依頼に関する第2情報を前記通信部によって受信することとが前記端末によって実行される。 - 請求項8に記載のプログラムであって、
前記第1ユーザと、前記第2アカウントの第2ユーザとを含むチャットルームに前記第2情報に基づく第2表示を表示する制御を前記制御部によって行うことが前記端末によって実行される。 - 請求項9に記載のプログラムであって、
前記第2情報は、前記チャットルームに含まれる前記第1ユーザと前記第2ユーザとで送受信されるメッセージを中継するサーバによって送信される。 - 請求項9または請求項10に記載のプログラムであって、
前記第2表示は、前記第1ユーザの前記チャットルームに表示され、前記第2ユーザの前記チャットルームには表示されない。 - 請求項9から請求項11のいずれか一項に記載のプログラムであって、
前記チャットルームに表示された前記第2表示に対する前記第1ユーザによる入力に基づいて、前記第2決済のうちの少なくとも一部である第2金額を前記第1アカウントから前記第2アカウントへ送金することに関する処理を前記制御部によって行うことが前記端末によって実行される。 - 請求項1または請求項3に記載のプログラムであって、
前記第2アカウントは、複数のユーザが決済可能な共通アカウントである。 - 決済に関する処理を行う端末の情報処理方法であって、
前記端末の第1ユーザの第1アカウントと、第2アカウントとに基づく前記決済を行うための、前記第1アカウントと前記第2アカウントとの関連付けに関する第1情報を前記端末の通信部によって受信することと、
前記第1情報に基づく第1表示を前記端末の表示部に表示することと、
前記第1ユーザによる前記第1表示に対する入力に基づいて、前記第1アカウントと前記第2アカウントとの関連付けに関する処理を前記端末の制御部によって行うことと、
前記第1アカウントと前記第2アカウントとの関連付けに基づき、少なくとも前記第2アカウントによって行われた第1決済に関する情報を前記表示部に表示することと、
前記第1ユーザによる前記第1決済に関する情報に対する入力に基づいて、前記第1決済のうちの少なくとも一部である第1金額を前記第1アカウントから前記第2アカウントへ送金することに関する処理を前記制御部によって行うこととを含み、
前記第1決済は、前記第1情報を受信してから、前記第1アカウントと前記第2アカウントとの関連付けが行われるまでの間に行われた決済である。 - 決済に関する処理を行う端末の情報処理方法であって、
前記端末の第1ユーザの第1アカウントと、第2アカウントとに基づく前記決済を行うための、前記第1アカウントと前記第2アカウントとの関連付けに関する第1情報を前記端末の通信部によって前記第2アカウントに対して送信することと、
前記第1情報を前記第2アカウントに対して送信してから、前記第1情報に基づく、前記第1アカウントと前記第2アカウントとの関連付けの承認に関する情報を前記第2アカウントから前記通信部によって受信するまでの間に、少なくとも前記第1アカウントに基づく第1決済に関する処理を前記端末の制御部によって行うことと、
前記第1アカウントと前記第2アカウントとの関連付けに基づき、前記第2アカウントから送金された前記第1決済に基づく金額を受け取る処理を前記制御部によって行うこととを含む。 - 決済に関する処理を行う端末の情報処理方法であって、
前記端末の第1ユーザの第1アカウントと、第2アカウントとに基づく前記決済を行うための、前記第1アカウントと前記第2アカウントとの関連付けに関する第1情報を前記端末の通信部によって受信することと、
前記第1情報に基づく第1表示を前記端末の表示部に表示することと、
前記第1ユーザによる前記第1表示に対する入力に基づいて、前記第1アカウントと前記第2アカウントとの関連付けに関する処理を前記端末の制御部によって行うことと、
前記第1アカウントと前記第2アカウントとの関連付けに基づき、少なくとも前記第2アカウントと、前記第2アカウントに関連付けられた第3アカウントとによって行われた第1決済に関する情報を前記表示部に表示することと、
前記第1ユーザによる前記第1決済に関する情報に対する入力に基づいて、前記第1決済のうちの少なくとも一部である第1金額を前記第1アカウントから前記第2アカウントへ送金することに関する処理を前記制御部によって行うこととを含む。 - 決済に関する処理を行う端末の情報処理方法であって、
前記端末の第1ユーザの第1アカウントと、第2アカウントとに基づく前記決済を行うための、前記第1アカウントと前記第2アカウントとの関連付けに関する第1情報を、前記第2アカウントの第2ユーザによる、前記第1ユーザと、前記第2ユーザとを含むチャットルームの作成に基づき前記端末の通信部によって受信することと、
前記第1情報に基づく第1表示を前記端末の表示部に表示することと、
前記第1ユーザによる前記第1表示に対する入力に基づいて、前記第1アカウントと前記第2アカウントとの関連付けに関する処理を前記端末の制御部によって行うことと、
前記第1アカウントと前記第2アカウントとの関連付けに基づき、少なくとも前記第2アカウントによって行われた第1決済に関する情報を前記表示部に表示することと、
前記第1ユーザによる前記第1決済に関する情報に対する入力に基づいて、前記第1決済のうちの少なくとも一部である第1金額を前記第1アカウントから前記第2アカウントへ送金することに関する処理を前記制御部によって行うこととを含む。 - 決済に関する処理を行う端末であって、
前記端末の第1ユーザの第1アカウントと、第2アカウントとに基づく前記決済を行うための、前記第1アカウントと前記第2アカウントとの関連付けに関する第1情報を受信する通信部と、
前記第1情報に基づく第1表示を表示する表示部と、
前記第1ユーザによる前記第1表示に対する入力に基づいて、前記第1アカウントと前記第2アカウントとの関連付けに関する処理を行う制御部とを備え、
前記表示部は、前記第1アカウントと前記第2アカウントとの関連付けに基づき、少なくとも前記第2アカウントによって行われた第1決済に関する情報を表示し、
前記制御部は、前記第1ユーザによる前記第1決済に関する情報に対する入力に基づいて、前記第1決済のうちの少なくとも一部である第1金額を前記第1アカウントから前記第2アカウントへ送金することに関する処理を行い、
前記第1決済は、前記第1情報を受信してから、前記第1アカウントと前記第2アカウントとの関連付けが行われるまでの間に行われた決済である。 - 決済に関する処理を行う端末であって、
前記端末の第1ユーザの第1アカウントと、第2アカウントとに基づく前記決済を行うための、前記第1アカウントと前記第2アカウントとの関連付けに関する第1情報を前記第2アカウントに対して送信する通信部と、
前記第1情報を前記第2アカウントに対して送信してから、前記第1情報に基づく、前記第1アカウントと前記第2アカウントとの関連付けの承認に関する情報を前記第2アカウントから前記通信部によって受信するまでの間に、少なくとも前記第1アカウントに基づく第1決済に関する処理を行う制御部とを備え、
前記制御部は、前記第1アカウントと前記第2アカウントとの関連付けに基づき、前記第2アカウントから送金された前記第1決済に基づく金額を受け取る処理を行う。 - 決済に関する処理を行う端末であって、
前記端末の第1ユーザの第1アカウントと、第2アカウントとに基づく前記決済を行うための、前記第1アカウントと前記第2アカウントとの関連付けに関する第1情報を受信する通信部と、
前記第1情報に基づく第1表示を表示する表示部と、
前記第1ユーザによる前記第1表示に対する入力に基づいて、前記第1アカウントと前記第2アカウントとの関連付けに関する処理を行う制御部とを備え、
前記表示部は、前記第1アカウントと前記第2アカウントとの関連付けに基づき、少なくとも前記第2アカウントと、前記第2アカウントに関連付けられた第3アカウントとによって行われた第1決済に関する情報を表示し、
前記制御部は、前記第1ユーザによる前記第1決済に関する情報に対する入力に基づいて、前記第1決済のうちの少なくとも一部である第1金額を前記第1アカウントから前記第2アカウントへ送金することに関する処理を行う。 - 決済に関する処理を行う端末であって、
前記端末の第1ユーザの第1アカウントと、第2アカウントとに基づく前記決済を行うための、前記第1アカウントと前記第2アカウントとの関連付けに関する第1情報を、前記第2アカウントの第2ユーザによる、前記第1ユーザと、前記第2ユーザとを含むチャットルームの作成に基づき受信する通信部と、
前記第1情報に基づく第1表示を表示する表示部と、
前記第1ユーザによる前記第1表示に対する入力に基づいて、前記第1アカウントと前記第2アカウントとの関連付けに関する処理を行う制御部とを備え、
前記表示部は、前記第1アカウントと前記第2アカウントとの関連付けに基づき、少なくとも前記第2アカウントによって行われた第1決済に関する情報を表示し、
前記制御部は、前記第1ユーザによる前記第1決済に関する情報に対する入力に基づいて、前記第1決済のうちの少なくとも一部である第1金額を前記第1アカウントから前記第2アカウントへ送金することに関する処理を行う。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020163973A JP7034226B1 (ja) | 2020-09-29 | 2020-09-29 | プログラム、情報処理方法、端末 |
PCT/JP2021/002903 WO2022070453A1 (ja) | 2020-09-29 | 2021-01-27 | プログラム、情報処理方法、端末、サーバ |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020163973A JP7034226B1 (ja) | 2020-09-29 | 2020-09-29 | プログラム、情報処理方法、端末 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP7034226B1 true JP7034226B1 (ja) | 2022-03-11 |
JP2022056138A JP2022056138A (ja) | 2022-04-08 |
Family
ID=80999040
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2020163973A Active JP7034226B1 (ja) | 2020-09-29 | 2020-09-29 | プログラム、情報処理方法、端末 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP7034226B1 (ja) |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2020113176A (ja) | 2019-01-16 | 2020-07-27 | 株式会社メルカリ | 情報処理方法、情報処理装置、及びプログラム |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP7053396B2 (ja) * | 2018-07-25 | 2022-04-12 | 楽天グループ株式会社 | 決済システム、決済方法、及びプログラム |
-
2020
- 2020-09-29 JP JP2020163973A patent/JP7034226B1/ja active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2020113176A (ja) | 2019-01-16 | 2020-07-27 | 株式会社メルカリ | 情報処理方法、情報処理装置、及びプログラム |
Also Published As
Publication number | Publication date |
---|---|
JP2022056138A (ja) | 2022-04-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6977127B1 (ja) | プログラム、情報処理方法、端末、サーバ | |
JP7460686B2 (ja) | プログラム、情報処理方法、サーバ | |
WO2022085579A1 (ja) | プログラム、情報処理方法、端末、サーバ | |
JP7531463B2 (ja) | プログラム、情報処理方法、端末 | |
JP7175877B2 (ja) | プログラム、表示方法、端末 | |
JP2022025514A (ja) | 情報処理方法、情報処理装置、プログラム、及び現金自動預払機 | |
JP2022072359A (ja) | 情報処理装置、プログラム、方法、端末 | |
JP7034226B1 (ja) | プログラム、情報処理方法、端末 | |
WO2022070453A1 (ja) | プログラム、情報処理方法、端末、サーバ | |
JP7456986B2 (ja) | プログラム、情報処理方法、端末 | |
JP7146866B2 (ja) | プログラム、情報処理方法、端末 | |
JP7089551B2 (ja) | プログラム、情報処理方法、サーバ、端末 | |
JP7250186B2 (ja) | サーバ、プログラム、情報処理方法 | |
JP7183217B2 (ja) | プログラム、情報処理方法、端末 | |
JP7405930B2 (ja) | プログラム、情報処理方法、端末 | |
WO2022004339A1 (ja) | プログラム、情報処理方法、端末 | |
JP7357591B2 (ja) | プログラム、情報処理方法、端末 | |
JP7417482B2 (ja) | プログラム、情報処理方法、端末 | |
JP7492942B2 (ja) | プログラム、情報処理方法、情報処理装置 | |
WO2021255949A1 (ja) | プログラム、情報処理方法、端末、サーバ | |
JP7541500B2 (ja) | プログラム、情報処理方法、端末 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20210412 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20210607 |
|
A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20210607 |
|
RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20210706 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20211019 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20211105 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20220208 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20220301 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 7034226 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |