CN114424224A - 程序、信息处理方法、终端 - Google Patents
程序、信息处理方法、终端 Download PDFInfo
- Publication number
- CN114424224A CN114424224A CN201980100427.XA CN201980100427A CN114424224A CN 114424224 A CN114424224 A CN 114424224A CN 201980100427 A CN201980100427 A CN 201980100427A CN 114424224 A CN114424224 A CN 114424224A
- Authority
- CN
- China
- Prior art keywords
- account
- terminal
- user
- information
- settlement
- 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.)
- Pending
Links
- 230000010365 information processing Effects 0.000 title claims abstract description 12
- 238000003672 processing method Methods 0.000 title claims abstract description 8
- 238000012545 processing Methods 0.000 claims abstract description 391
- 238000004891 communication Methods 0.000 claims description 326
- 238000000034 method Methods 0.000 claims description 315
- 230000008569 process Effects 0.000 claims description 270
- 238000012546 transfer Methods 0.000 claims description 259
- 238000004364 calculation method Methods 0.000 claims description 51
- 238000012986 modification Methods 0.000 description 225
- 230000004048 modification Effects 0.000 description 225
- 238000010586 diagram Methods 0.000 description 146
- 230000000694 effects Effects 0.000 description 99
- 230000010354 integration Effects 0.000 description 66
- 238000003860 storage Methods 0.000 description 50
- 230000006870 function Effects 0.000 description 34
- 230000007812 deficiency Effects 0.000 description 24
- 238000012790 confirmation Methods 0.000 description 14
- 230000006833 reintegration Effects 0.000 description 14
- 150000001875 compounds Chemical class 0.000 description 9
- 244000025254 Cannabis sativa Species 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 5
- 239000000470 constituent Substances 0.000 description 5
- 239000002131 composite material Substances 0.000 description 4
- 238000007596 consolidation process Methods 0.000 description 4
- 230000007423 decrease Effects 0.000 description 4
- 238000001514 detection method Methods 0.000 description 4
- 230000001133 acceleration Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 238000012508 change request Methods 0.000 description 3
- 238000005259 measurement Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 101100049746 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) WTM1 gene Proteins 0.000 description 2
- 101100049747 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) WTM2 gene Proteins 0.000 description 2
- 230000004931 aggregating effect Effects 0.000 description 2
- 238000012937 correction Methods 0.000 description 2
- 230000006735 deficit Effects 0.000 description 2
- 238000009826 distribution Methods 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 230000003213 activating effect Effects 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000001174 ascending effect Effects 0.000 description 1
- 238000007664 blowing Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 239000013078 crystal Substances 0.000 description 1
- 230000002950 deficient Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000006855 networking 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
- 239000004065 semiconductor Substances 0.000 description 1
- 239000000758 substrate Substances 0.000 description 1
- 230000007306 turnover Effects 0.000 description 1
- 238000009424 underpinning Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/108—Remote banking, e.g. home banking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/326—Payment applications installed on the mobile devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/326—Payment applications installed on the mobile devices
- G06Q20/3267—In-app payments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
Abstract
本发明提供程序、信息处理方法、终端。该程序是用于使终端执行的程序，该终端基于代码信息而执行与结算相关的处理，其中，通过该终端执行以下的处理：将与终端的用户能够结算的第一帐户建立了关联的第一代码信息或者作为与代码信息的读取相关的显示的第一读码器信息、和与不同于第一帐户的第二帐户相关的第二帐户信息显示于终端的显示区域；以及基于由终端的用户针对第二帐户信息进行的输入，由终端的控制部执行与基于第一帐户和第二帐户的第一结算相关的处理。
Description
技术领域
本公开涉及程序、信息处理方法、终端。
背景技术
近年来，通过能够由智能手机等终端执行的应用程序来实现终端或者终端的用户的电子结算的服务不断普及。例如在专利文献1中公开了一种进行商品的购买金额的结算的技术。
在先技术文献
专利文献
专利文献1：日本特开2002-176671号公报
发明内容
根据本发明的第一方案，用于使基于代码信息而执行与结算相关的处理的终端执行的程序通过终端执行以下的处理：将与终端的用户能够结算的第一帐户建立了关联的第一代码信息或者作为与代码信息的读取相关的显示的第一读码器信息、和与不同于第一帐户的第二帐户相关的第二帐户信息显示于终端的显示区域；以及基于由终端的用户针对第二帐户信息进行的输入，由终端的控制部执行与基于第一帐户和第二帐户的第一结算相关的处理。
根据本发明的第二方案，基于代码信息而执行与结算相关的处理的终端的信息处理方法包括：将与终端的用户能够结算的第一帐户建立了关联的第一代码信息或者作为与代码信息的读取相关的显示的第一读码器信息、和与不同于第一帐户的第二帐户相关的第二帐户信息显示于终端的显示区域；以及基于由终端的用户针对第二帐户信息进行的输入，由终端的控制部执行与基于第一帐户和第二帐户的第一结算相关的处理。
根据本发明的第三方案，基于代码信息而执行与结算相关的处理的终端具备：显示部，其显示与终端的用户能够结算的第一帐户建立了关联的第一代码信息或者作为与代码信息的读取相关的显示的第一读码器信息、和与不同于第一帐户的第二帐户相关的第二帐户信息；以及控制部，其基于由终端的用户针对第二帐户信息进行的输入，执行与基于第一帐户和第二帐户的第一结算相关的处理。
根据本发明的第四方案，基于代码信息而执行与结算相关的处理的终端具备处理器，该处理器读出存储于存储器的程序，执行基于程序的处理，处理器执行以下的处理：基于终端的用户能够结算的第一帐户，由终端的控制部执行与第一结算相关的处理；将与终端的用户能够结算的第一帐户建立了关联的第一代码信息或者作为与代码信息的读取相关的显示的第一读码器信息、和与不同于第一帐户的第二帐户相关的第二帐户信息显示于终端的显示区域；以及基于由终端的用户针对第二帐户信息进行的输入，执行与基于第一帐户和第二帐户的第一结算相关的处理。
附图说明
图1-1是示出实施方式的一方案中的通信系统的系统结构的一例的图。
图1-2是示出实施方式的一方案的店铺POS系统的系统结构的一例的图。
图1-3是示出由第一实施例的服务器的控制部实现的功能的一例的图。
图1-4是示出第一实施例的服务器的存储部所存储的信息的一例的图。
图1-5是示出第一实施例的支付应用用户注册数据的一例的图。
图1-6是示出第一实施例的用户管理数据库的数据结构的一例的图。
图1-7是示出作为第一实施例的共同钱包管理数据库的一例的第一共同钱包管理数据库的数据结构例的图。
图1-8是示出第一实施例的各装置所执行的处理流程的一例的流程图。
图1-9是示出第一实施例的各装置所执行的处理流程的一例的流程图。
图1-10是示出第一实施例的各装置所执行的处理流程的一例的流程图。
图1-11是示出第一实施例的各装置所执行的处理流程的一例的流程图。
图2-1是示出第二实施例的终端的显示部所显示的画面的一例的图。
图2-2是示出第二实施例的终端的显示部所显示的画面的一例的图。
图2-3是示出第二实施例的终端的显示部所显示的画面的一例的图。
图2-4是示出第二实施例的终端的显示部所显示的画面的一例的图。
图2-5是示出第二实施例的终端的显示部所显示的画面的一例的图。
图2-6是示出第二实施例的终端的显示部所显示的画面的一例的图。
图2-7是示出第二实施例的终端的显示部所显示的画面的一例的图。
图2-8是示出第二实施例的各装置所执行的处理流程的一例的流程图。
图2-9是示出第二实施例的各装置所执行的处理流程的一例的流程图。
图2-10是示出第二变形例的终端的显示部所显示的画面的一例的图。
图2-11是示出第二变形例的终端的显示部所显示的画面的一例的图。
图2-12是示出第二变形例的终端的显示部所显示的画面的一例的图。
图2-13是示出第二变形例的各装置所执行的处理流程的一例的流程图。
图2-14是示出第二变形例的各装置所执行的处理流程的一例的流程图。
图3-1是示出第三实施例的终端的显示部所显示的应用画面的一例的图。
图3-2是示出第三实施例的终端的显示部所显示的共同钱包选择画面的一例的图。
图3-3是示出第三实施例的终端的显示部所显示的露营资金支付画面的一例的图。
图3-4是示出第三实施例的终端的显示部所显示的代码支付画面的一例的图。
图3-5是示出第三实施例的终端的显示部所显示的转账用画面的一例的图。
图3-6是示出第三实施例的终端的显示部所显示的代码支付画面的一例的图。
图3-7是示出第三实施例的终端的显示部所显示的代码支付完成画面的一例的图。
图3-8是示出第三实施例的各装置所执行的处理流程的一例的流程图。
图3-9是示出第三实施例的终端的显示部所显示的读码器画面的一例的图。
图3-10是示出第三变形例的终端的显示部所显示的读取完成画面的一例的图。
图3-11是示出第三变形例的终端的显示部所显示的支付金额输入画面的一例的图。
图3-12是示出第三变形例的各装置所执行的处理流程的一例的流程图。
图3-13是示出第三变形例的终端的显示部所显示的代码支付画面的一例的图。
图3-14是示出第三变形例的终端的显示部所显示的充值画面的一例的图。
图3-15是示出第三变形例的终端的显示部所显示的代码支付画面的一例的图。
图3-16是示出第三变形例的各装置所执行的处理流程的一例的流程图。
图3-17是示出第三变形例的各装置所执行的处理流程的一例的流程图。
图3-18是示出第三变形例的终端的显示部所显示的代码支付画面的一例的图。
图3-19是示出第三变形例的终端的显示部所显示的成员选择画面的一例的图。
图3-20是示出第三变形例的服务器的结构的一例的图。
图3-21是示出第三变形例的终端的显示部所显示的成员选择画面(谈话室选择画面)的一例的图。
图4-1是示出第四实施例的终端的显示部所显示的共同钱包余额不足画面的一例的图。
图4-2是示出第四实施例的终端的显示部所显示的代码支付画面的一例的图。
图4-3是示出第四实施例的终端的显示部所显示的代码支付完成画面的一例的图。
图4-4是示出第四实施例的各装置所执行的处理流程的一例的流程图。
图4-5是示出第四实施例的各装置所执行的处理流程的一例的流程图。
图4-6是示出第四变形例的终端的显示部所显示的共同钱包余额不足画面的一例的图。
图4-7是示出第四变形例的各装置所执行的处理流程的一例的流程图。
图4-8是示出第四实施例的各装置所执行的处理流程的一例的流程图。
图4-9是示出第四变形例的各装置所执行的处理流程的一例的流程图。
图4-10是示出第四变形例的终端的显示部所显示的代码支付画面的一例的图。
图4-11是示出第四变形例的终端的显示部所显示的共同钱包余额不足画面的一例的图。
图4-12是示出第四变形例的终端的显示部所显示的自己的钱包余额不足画面的一例的图。
图4-13是示出第四变形例的终端的显示部所显示的代码支付完成画面的一例的图。
图4-14是示出第四变形例的终端的显示部所显示的通知画面的一例的图。
图4-15是示出第四变形例的终端的显示部所显示的支付历史画面的一例的图。
图4-16是示出第四变形例的终端的显示部所显示的谈话室画面的一例的图。
图4-17是示出第四变形例的终端的显示部所显示的谈话室画面的一例的图。
图4-18是示出第四变形例的各装置所执行的处理流程的一例的流程图。
图4-19是示出第四变形例的各装置所执行的处理流程的一例的流程图。
图4-20是示出第四变形例的各装置所执行的处理流程的一例的流程图。
图4-21是示出第四变形例的各装置所执行的处理流程的一例的流程图。
图4-22是示出第四变形例的店铺读码器装置的结构的一例的图。
图5-1是示出第五实施例的服务器的存储部所存储的信息的一例的图。
图5-2是示出第五实施例的统合帐户管理数据库的数据结构的一例的图。
图5-3是示出第五实施例的终端的显示部所显示的代码支付画面的一例的图。
图5-4是示出第五实施例的终端的显示部所显示的代码信息更新中画面的一例的图。
图5-5是示出第五实施例的终端的显示部所显示的代码支付画面的一例的图。
图5-6是示出第五实施例的各装置所执行的处理流程的一例的流程图。
图5-7是示出第五实施例的各装置所执行的处理流程的一例的流程图。
图5-8是示出第五变形例的终端的显示部所显示的读码器画面的一例的图。
图5-9是示出第五变形例的终端的显示部所显示的支付代码信息更新中画面的一例的图。
图5-10是示出第五变形例的终端的显示部所显示的读码器画面的一例的图。
图5-11是示出第五变形例的各装置所执行的处理流程的一例的流程图。
图5-12是示出第五变形例的各装置所执行的处理流程的一例的流程图。
图5-13是示出第五变形例的终端的显示部所显示的代码支付画面的另一例的图。
图5-14是示出第五变形例的各装置所执行的处理流程的一例的流程图。
图5-15是示出第五变形例的各装置所执行的处理流程的一例的流程图。
图5-16是示出第五变形例的各装置所执行的处理流程的一例的流程图。
图5-17是示出第五变形例的终端的显示部所显示的代码支付画面的一例的图。
图5-18是示出第五变形例的终端的显示部所显示的代码支付画面的一例的图。
图5-19是示出第五变形例的终端的显示部所显示的代码支付画面的一例的图。
图5-20是示出第五变形例的各装置所执行的处理流程的一例的流程图。
图5-21是示出第五变形例的终端的显示部所显示的代码支付画面的一例的图。
图5-22是示出第五变形例的终端的显示部所显示的代码支付画面的一例的图。
图5-23是示出第五变形例的终端的显示部所显示的通知画面的一例的图。
图5-24是示出第五变形例的终端的显示部所显示的代码信息更新画面的一例的图。
图5-25是示出第五变形例的终端的显示部所显示的代码支付画面的一例的图。
图5-26是示出第五变形例的终端的显示部所显示的代码支付画面的一例的图。
图5-27是示出第五变形例的终端的显示部所显示的代码支付画面的另一例的图。
图5-28是示出第五变形例的各装置所执行的处理流程的一例的流程图。
图5-29是示出第五变形例的各装置所执行的处理流程的一例的流程图。
图5-30是示出第五变形例的终端的显示部所显示的代码支付画面的一例的图。
图5-31是示出第五变形例的终端的显示部所显示的代码支付画面的一例的图。
图5-32是示出第五变形例的终端的显示部所显示的代码信息更新画面的一例的图。
图5-33是示出第五变形例的终端的显示部所显示的代码支付画面的一例的图。
图6-1是示出第六实施例的各装置所执行的处理流程的一例的流程图。
图6-2是示出第六实施例的各装置所执行的处理流程的一例的流程图。
图6-3是示出第六变形例的各装置所执行的处理流程的一例的流程图。
图6-4是示出第六变形例的各装置所执行的处理流程的一例的流程图。
图6-5是示出第六变形例的各装置所执行的处理流程的一例的流程图。
图6-6是示出第六变形例的各装置所执行的处理流程的一例的流程图。
图6-7是示出第六变形例的各装置所执行的处理流程的一例的流程图。
图6-8是示出第六变形例的各装置所执行的处理流程的一例的流程图。
图6-9是示出第六变形例的各装置所执行的处理流程的一例的流程图。
图7-1是示出第七实施例的各装置所执行的处理流程的一例的流程图。
图7-2是示出第七变形例的各装置所执行的处理流程的一例的流程图。
图7-3是示出第七变形例的各装置所执行的处理流程的一例的流程图。
图7-4是示出第七变形例的各装置所执行的处理流程的一例的流程图。
图7-5是示出第七变形例的各装置所执行的处理流程的一例的流程图。
图7-6是示出第七变形例的各装置所执行的处理流程的一例的流程图。
图7-7是示出第七变形例的各装置所执行的处理流程的一例的流程图。
图7-8是示出第七变形例的各装置所执行的处理流程的一例的流程图。
图8-1是示出作为第八实施例的共同钱包管理数据库的一例的第二共同钱包管理数据库的数据结构例的图。
图8-2是示出作为第八变形例的共同钱包管理数据库的一例的第三共同钱包管理数据库的数据结构例的图。
图8-3是示出第八变形例的终端的显示部所显示的概要显示画面的一例的图。
图8-4是示出第八变形例的终端的显示部所显示的概要显示画面的一例的图。
图8-5是示出第八变形例的终端的显示部所显示的概要显示画面的一例的图。
图9-1是示出第九实施例的终端的显示部所显示的代码支付画面的一例的图。
图9-2是示出第九实施例的终端的显示部所显示的谈话室选择画面的一例的图。
图9-3是示出第九实施例的终端的显示部所显示的代码支付画面的一例的图。
图9-4是示出第九实施例的终端的显示部所显示的代码支付完成画面的一例的图。
图9-5是示出第九实施例的终端的显示部所显示的谈话室画面的一例的图。
图9-6是示出第九实施例的终端的显示部所显示的谈话室画面的一例的图。
图9-7是示出第九实施例的终端的显示部所显示的谈话室画面的一例的图。
图10是示出用于说明第十实施例的第一帐户与第二帐户的组合的表的一例的图。
具体实施方式
＜法律事项的遵守＞
需要注意的是，本说明书所记载的公开以遵守通信保密等本公开的实施所需的实施国的法律事项为前提。
参照附图来说明用于实施本公开的程序、信息处理方法、显示方法、终端、服务器等的实施方式。
＜概要＞
近年来，作为与网络服务关联的应用(应用软件)，用于进行基于电子货币的支付/结算的应用(支付应用/结算应用)、用于进行基于电子货币的转账/接收的应用(转账应用)这样的应用、或者汇集了这些应用的一部分功能或全部功能的应用不断普及，终端20的用户能够使用这些应用，接受与电子货币相关的各种服务。
“电子货币”是指区别于物理货币的电子式的货币，是在上述的各种应用中管理的终端20或终端20的用户所拥有的电子式的货币。
需要说明的是，电子货币可以表现为“电子钱币”或“数字通货(数字货币)”，也可以不表现为“电子钱币”或“数字通货(数字货币)”。
另外，作为“电子货币(电子钱币)”或“数字通货(数字货币)”，可以使用法定通货，也可以使用虚拟通货。
另外，“电子货币(电子钱币)”或“数字通货(数字货币)”也可以包含加密通货(加密资产)。
另外，虚拟通货也可以包含优惠券等实物货币。
在本说明书中，适当使用“通过通信I/F”这样的表现。作为非限定的例子，这表示装置基于控制部(处理器等)的控制，经由通信I/F(经由通信部)来收发各种信息或数据。
另外，在本说明书中，“结算”是指电子式的结算(电子结算)。其一例是利用了电子货币的电子结算。
另外，在本说明书中，作为非限定的例子，“与结算相关的处理”是与终端20所执行的结算相关的处理，包括从服务器等取得用于进行结算的代码信息的处理(包括将代码信息的生成委托于服务器等的处理、从服务器等接收所生成的代码信息的处理。)、显示所取得的代码信息的处理、从服务器等取得结算结果(包括结算通知。)的处理等在进行结算的方面具有某些关联的处理，更具体而言，作为在进行结算的方面具有关联的处理而由终端20执行的全部处理。
另外，在本说明书中，“代码信息”包括代码图像、通过编码等而存储于代码图像的信息(存储信息)、或者成为存储的对象的信息(存储对象信息)。作为非限定的例子，存储信息或存储对象信息包括详细后述的令牌。
另外，在本说明书中，作为非限定的例子，针对利用了代码(代码信息)的支付方法/结算方法即代码结算，例示出(1)利用者提示型、(2)店铺提示型这两个种类。
作为非限定的例子，利用者提示型是指如下方法：利用者(终端20的用户)向店铺(作为非限定的例子，为加盟店)的店员等提示终端20的显示部24所显示的支付码，通过店铺读码器装置50的读码器58读取该支付码来进行结算。
作为非限定的例子，店铺提示型是指如下方法：利用者利用终端20的相机27或读码器(包括支付应用的读码器。)读取由店铺(作为非限定的例子，为加盟店)提示或揭示的支付店铺码来进行结算。
需要说明的是，以下，将在利用者提示型中显示于终端20的显示部24的代码称为“支付码”，但取而代之，也可以称为“利用者提示型码”等。
另外，以下，将在店铺提示型中由终端20读取的代码称为“支付店铺码”，但取而代之，也可以称为“店铺提示型码”等。
另外，在本说明书中，作为非限定的例子，针对基于帐户的结算，例示出(A)共同帐户结算、(B)帐户联合结算这两个种类。
作为非限定的例子，“帐户”是指用于进行基于电子货币的支付/结算的应用(支付应用/结算应用)的帐户。
共同帐户结算是基于多个用户能够共同使用的帐户(以下称为“共同帐户”。)来进行结算的方法。将该结算称为“共同帐户结算”。共同帐户结算通过利用共同钱包来实现。“共同钱包”是由多个用户设定的电子钱币账户的一个方式，构成虚拟的一个钱包。
共同帐户结算也能够理解为用户使用多个用户共同的帐户(一个共同的帐户)的结算。
需要说明的是，共同帐户结算也可以表现为共同钱包结算。
帐户联合结算是使多个帐户联合来进行结算的方法。帐户的联合是以使多个帐户使用于结算的方式建立关联，将使帐户联合称为“帐户联合”，将利用了帐户联合的结算称为“帐户联合结算”。
在该情况下，可以使一个用户的多个帐户联合，也可以使多个用户的帐户联合。即，并非必须使他人的帐户联合，作为非限定的例子，也能够使自己的多个帐户联合。
为了实现帐户联合结算，作为非限定的例子，在将多个帐户建立了关联的基础上，作为非限定的例子，执行设定为从建立了关联的各个帐户通过均等分配来进行结算的处理(帐户联合处理)。
帐户联合结算也能够理解为用户除了使用自己的帐户之外还使用不同的帐户(自己的其他帐户或他人的帐户)所进行的结算。
需要说明的是，帐户联合也可以表现为钱包联合。另外，帐户联合结算也可以表现为钱包联合结算。
以下，仅仅作为一例，来说明假定了朋友彼此或友人彼此等多个用户一起进行购物等的支付的结算的情况的实施例。
共同帐户结算是从假定为原则上由多个用户共同使用的一个帐户进行结算的结算方式，但在以下说明的实施例中，也说明基于共同帐户和不同于共同帐户的帐户而进行结算的方法。
另外，作为非限定的例子，能够在(B-1)进行支付前、(B-2)进行支付时的任意一方进行帐户联合。
(B-1)作为非限定的例子，进行支付前能够应用于事后的细算(作为非限定的例子，为基于均摊方式进行的细算)麻烦的情况。
(B-2)作为非限定的例子，进行支付时能够应用于作为在支付时进行结算的帐户而设定的帐户(作为非限定的例子，为自己的帐户)的余额不足的情况。在该情况下，作为非限定的例子，能够与其他用户的帐户进行帐户联合来进行结算。
在共同帐户结算中，多个用户使用共同的帐户，因此，在一个用户垫付其他用户的支付部分而进行了结算的情况下，有时需要进行事后的细算(清算)的处理，对此详细后述。即，在结算完成后的某个时机，需要进行转账处理/收款处理等调整各个用户的金额的处理。
与此相对，在帐户联合结算中，预先获得所联合的帐户的用户的许可，或者当场获得许可，在此基础上从各个帐户消费金额，由此，原则上不需要事后的细算的处理。
基于以上，针对“共同帐户结算”和“帐户联合结算”各自的实施例进行说明。
需要说明的是，“联合”包括为了一个目的而一起做事这样的含义。因此，在多个用户一起进行结算这样的含义上，无论是共同帐户结算还是帐户联合结算，可以说目的是相同的。
＜系统结构＞
图1-1是示出本实施例中的通信系统1的系统结构的一例的图。
在通信系统1中，作为非限定的例子，经由网络30而将服务器10、多个终端20(终端20A、终端20B、终端20C、···)、以及多个店铺POS系统40(店铺POS系统40A、店铺POS系统40B、店铺POS系统40C、···)连接。
服务器10具有经由网络30向用户所拥有的终端20提供支付服务的功能。服务器10也能够如支付服务服务器、支付管理服务器、结算服务服务器、结算管理服务器等那样表现。
需要说明的是，与网络30连接的服务器10的数量或终端20的数量不被限定。
网络30担负将一个以上的终端20、一个以上的服务器10以及一个以上的店铺POS系统40连接的作用。即，网络30是指以在上述各种装置连接后能够收发数据的方式提供连接路径的通信网。
网络30中的一个或多个部分可以是有线网络或无线网络，也可以不是这些网络。作为非限定的例子，网络30能够包括自组网(ad hoc network)、内网、外网、虚拟专用网(virtual private network：VPN)、局域网(local area network：LAN)、无线局域网(wireless LAN：WLAN)、广域网(wide area network：WAN)、无线广域网(wireless WAN：WWAN)、大都会网(metropolitan area network：MAN)、因特网的一部分、公共交换电话网(Public Switched Telephone Network：PSTN)的一部分、便携电话网，ISDN(integratedservice digital networks)、无线LAN、LTE(long term evolution)、CDMA(code divisionmultiple access)、蓝牙(Bluetooth(注册商标))、卫星通信等、或者它们的两个以上的组合。网络30能够包括一个或多个网络30。
服务器10(非限定，是服务器、信息处理装置、信息管理装置的一例)具备向终端20提供规定的服务(在本实施例中为支付服务)的功能。服务器10只要是能够实现在各实施方式中记载的功能的信息处理装置即可，可以是任何的装置。作为非限定的例子，服务器10包括服务器装置、计算机(作为非限定的例子，为台式电脑、笔记本电脑、平板电脑等)、媒体计算机平台(作为非限定的例子，为有线、卫星机顶盒、数字视频录像机)、手持计算机设备(作为非限定的例子，PDA，电子邮件客户端等)、或者其他种类的计算机、或者交流平台。另外，服务器10也可以表现为信息处理装置。在无需区分服务器10与终端20的情况下，服务器10和终端20可以分别表现为信息处理装置，也可以不表现为信息处理装置。
[各装置的硬件(HW)结构]
针对通信系统1所包含的各装置的HW结构进行说明。
(1)终端的HW结构
在图1-1中示出终端20的HW结构的一例。
终端20具备控制部21(CPU：central processing unit(中央处理装置))、存储部28、通信I/F22(接口)、输入输出部23、显示部24、麦克风25、扬声器26、相机27、时钟部29A、位置计算用信息检测部29B。作为非限定的例子，终端20的HW的各结构要素经由总线B相互连接。需要说明的是，作为终端20的HW结构，不需要包括所有的结构要素。作为非限定的例子，终端20也可以为取掉麦克风25、相机27等各个结构要素或多个结构要素的结构，还可以不为这样的结构。
通信I/F22经由网络30进行各种数据的收发。通信可以通过有线、无线中的任意一种执行，只要能够执行相互的通信即可，可以使用任何的通信协议。通信I/F22具有经由网络30而执行与服务器10等各种装置的通信的功能。通信I/F22按照来自控制部21的指示，向服务器10等各种装置发送各种数据。另外，通信I/F22接收从服务器10等各种装置发送的各种数据，并向控制部21传递。另外，也有时将通信I/F22仅表现为通信部。另外，在通信I/F22由在物理上被结构化的电路构成的情况下，也有时表现为通信电路。
输入输出部23包括输入针对终端20的各种操作的装置、以及输出由终端20进行处理后的处理结果的装置。输入输出部23可以将输入部与输出部一体化，也可以分离为输入部和输出部，还可以不为这样的结构。
输入部通过能够受理来自用户的输入并将与输入相关的信息向控制部21传递的全部种类的装置中的任意一方或者其组合来实现。作为非限定的例子，输入部包括触摸面板、触摸显示器、键盘等硬键、鼠标等指点设备、相机(经由动态图像的操作输入)、麦克风(基于声音的操作输入)。
输出部通过能够输出由控制部21进行处理后的处理结果的全部种类的装置中的任意一方或其组合来实现。作为非限定的例子，输出部包括触摸面板、触摸显示器、扬声器(声音输出)、镜头(作为非限定的例子，为3D(three dimensions)输出、全息图输出)、打印机等。
显示部24通过能够按照写入到帧缓冲区的显示数据进行显示的全部种类的装置中的任意一方或其组合来实现。作为非限定的例子，显示部24包括触摸面板、触摸显示器、监视器(作为非限定的例子，为液晶显示器、OELD(organic electroluminescencedisplay))、头戴式显示器(HDM：Head Mounted Display)、能够在投影图、全息图、空气中等(也可以是真空，还可以不是真空)显示图像或文本信息等的装置。需要说明的是，这些显示部24可以通过3D来显示显示数据，也可以不采用这种方式。
在输入输出部23为触摸面板的情况下，输入输出部23与显示部24也可以以大致相同的大小和形状对置配置。
时钟部29A是终端20的内置时钟，输出时刻信息(计时信息)。作为非限定的例子，时钟部29A构成为具有利用了晶体振荡器的钟表等。作为非限定的例子，时钟部29A也能够表现为计时部或时刻信息检测部。
需要说明的是，时钟部29A也可以具有应用了NITZ(Network Identity and TimeZone)标准等的钟表，还可以不具有该钟表。
位置计算用信息检测部29B是检测(计测)由控制部21计算(测定)自己的终端20的位置所需的信息(以下称为“位置计算用信息”。)的功能部。作为非限定的例子，位置计算用信息检测部29B也能够表现为位置计算用传感器部。
作为非限定的例子，位置计算用信息检测部29B包括用于利用GPS(GlobalPositioning System)等卫星测位系统来计算终端20的位置的传感器或单元即卫星测位传感器(卫星测位单元)、用于利用惯性导航系统来计算终端20的位置的传感器或单元即惯性计测传感器(惯性计测单元(IMU(Inertial Measurement Unit)))等。
作为非限定的例子，卫星测位单元具有将包括由未图示的天线接收的从测位用卫星发送的测位用卫星信号的RF(Radio Frequency)信号转换成数字信号的RF接收电路、针对从RF接收电路输出的数字信号进行相关运算处理等来捕捉测位用卫星信号并将从测位用卫星信号取出的卫星轨道数据或时刻数据等信息作为位置计算用信息而输出的基带处理电路等。
惯性计测单元具有惯性传感器，该惯性传感器是检测通过惯性导航运算而计算终端20的位置所需的信息的传感器。作为非限定的例子，惯性传感器包括3轴的加速度传感器、3轴的陀螺仪传感器，将由加速度传感器检测到的加速度和由陀螺仪传感器检测到的角速度作为位置计算用信息而输出。
作为非限定的例子，控制部21基于由位置计算用信息检测部29B检测到的位置计算用信息，在定期的时机或特定的时机计算自己的终端20的位置。将终端的位置称为“终端位置”，将计算出的终端位置称为“计算终端位置”。而且，控制部21将计算终端位置与计算出该计算终端位置的日期时间建立关联并作为计算终端位置历史数据而存储于存储部28。
控制部21具有为了执行由程序内所包含的代码或命令实现的功能而在物理上被结构化的电路，作为非限定的例子，由内置于硬件的数据处理装置实现。因此，控制部21也可以表现为控制电路，还可以不表现为控制电路。
作为非限定的例子，控制部21包括中央处理装置(CPU)、微处理器(microprocessor)、处理器核心(processor core)、多处理器(multiprocessor)、ASIC(application-specific integrated circuit)、FPGA(field programmable gatearray)。
存储部28具有存储在终端20进行动作时需要的各种程序或各种数据的功能。作为非限定的例子，存储部28包括HDD(hard disk drive)、SSD(solid state drive)、闪存、RAM(random access memory)、ROM(read only memory)等各种存储介质。另外，存储部28也可以表现为存储器(memory)，还可以不表现为存储器(memory)。
终端20将程序P存储于存储部28并执行该程序P，由此，控制部21执行控制部21所包含的作为各部分的处理。即，存储于存储部28的程序P使终端20实现控制部21所执行的各功能。另外，该程序P也可以表现为程序模块，还可以不表现为程序模块。
麦克风25用于声音数据的输入。扬声器26用于声音数据的输出。相机27用于动态图像数据的取得。
(2)服务器的HW结构
在图1-1中示出服务器10的HW结构的一例。
服务器10具备控制部11(CPU)、存储部15、通信I/F14(接口)、输入输出部12、显示器13、时钟部19。作为非限定的例子，服务器10的HW的各结构要素经由总线B相互连接。需要说明的是，作为服务器10的HW的结构，服务器10的HW不需要包括全部的结构要素。作为非限定的例子，服务器10的HW也可以为取掉显示器13的结构，还可以不为这种结构。
控制部11具有为了执行由程序内所包含的代码或命令实现的功能而在物理上被结构化的电路，作为非限定的例子，由内置于硬件的数据处理装置实现。
作为代表，控制部11为中央处理装置(CPU)，除此之外，也可以为微处理器、处理器核心、多处理器、ASIC、FPGA，还可以不为这些装置。在本公开中，控制部11不限定于此。
存储部15具有存储在服务器10进行动作时所需的各种程序或各种数据的功能。存储部15由HDD、SSD、闪存等各种存储介质实现。但是，在本公开中，存储部15不限定于此。另外，存储部15也可以表现为存储器(memory)，还可以不表现为存储器(memory)。
通信I/F14经由网络30进行各种数据的收发。通信可以通过有线、无线中的任意一种执行，只要能够执行相互的通信即可，可以使用任何的通信协议。通信I/F14具有经由网络30而执行与终端20等各种装置的通信的功能。通信I/F14按照来自控制部11的指示，向终端20等各种装置发送各种数据。另外，通信I/F14接收从终端20等各种装置发送的各种数据，并向控制部11传递。另外，也有时将通信I/F14仅表现为通信部。另外，在通信I/F14由在物理上被结构化的电路构成的情况下，也有时表现为通信电路。
输入输出部12由输入针对服务器10的各种操作的装置实现。输入输出部12通过能够受理来自用户的输入并将与输入相关的信息向控制部11传递的全部种类的装置中的任意一方或其组合来实现。作为代表，输入输出部12由以键盘等为代表的硬键或鼠标等指点设备实现。需要说明的是，作为非限定的例子，输入输出部12也可以包括触摸面板、相机(经由动态图像的操作输入)、麦克风(基于声音的操作输入)，还可以不包括这些设备。但是，在本公开中，输入输出部12不限定于此。
作为代表，显示器13由监视器(作为非限定的例子，为液晶显示器、OELD(organicelectroluminescence display))实现。需要说明的是，显示器13也可以是头戴式显示器(HDM)等，还可以不是头戴式显示器(HDM)等。需要说明的是，这些显示器13也可以通过3D来显示显示数据，还可以不采用这种方式。在本公开中，显示器13不限定于此。
时钟部19是服务器10的内置时钟，输出时刻信息(计时信息)。作为非限定的例子，时钟部19构成为具有作为硬件钟表的RTC(Real Time Clock)或系统钟表等。作为非限定的例子，时钟部19也能够表现为计时部或时刻信息检测部。
(3)店铺POS的系统结构
在图1-2中示出店铺POS系统40的系统结构的一例。
店铺POS系统40是向与运用服务器10的运营商合作的店铺导入而使用的POS系统，作为非限定的例子，包括店铺读码器装置50、代码收银机60以及店铺服务器70。
店铺读码器装置50通过POS通信I/F57(作为非限定的例子，为店铺内的有线通信I/F、无线通信I/F)而与代码收银机60、店铺服务器70进行通信连接，在通过代码收银机60进行结账时，读取终端20的显示部24所显示的代码信息。然后，基于所读取的代码信息，通过通信I/F54向服务器10发送结算请求信息，在由服务器10进行了结算之后，通过通信I/F54从服务器10接收与结算结果相关的信息。
作为非限定的例子，店铺读码器装置50具有控制部51、输入输出部52、显示部53、通信I/F54、存储部55、声音输出部56、POS通信I/F57、读码器58以及时钟部59。
读码器58是用于读取一维码(一维码图像)或二维码(二维码图像)、作为非限定的例子的后述的支付码(支付码图像)的读码器。
作为非限定的例子，代码收银机60通过POS通信I/F57而与店铺读码器装置50、店铺服务器70进行通信连接，基于店铺读码器装置50从服务器10接收到的结算完成通知等，发行打印有所销售的商品的总额、终端20的用户的电子货币的余额等信息的收据。
另外，作为非限定的例子，也能够与代码收银机60一体或者与代码收银机60分离设置而构成显示面面向顾客侧的显示器。
代码收银机60是构成为能够应对支付应用的收银机，也能够说是应对支付应用的固定终端。
作为非限定的例子，店铺服务器70管理与本店铺相关的店铺信息、与由本店铺销售的商品相关的信息或与由本店铺提供的服务相关的信息、与伴随着本店铺中的商品的销售或服务的提供的营业额相关的信息等各种信息。店铺服务器70构成为能够通过POS通信I/F57而与店铺读码器装置50、代码收银机60进行通信，并且构成为能够经由网络30而与服务器10等外部装置进行通信。
需要说明的是，店铺服务器70并非一定要构成为能够与店铺读码器装置50直接进行通信，也可以构成为能够经由代码收银机60而与店铺读码器装置50进行通信。作为非限定的例子，也能够将店铺读码器装置50从服务器10接收到的结算完成通知等送至代码收银机60，然后从代码收银机60送至店铺服务器70等。
(4)其他
服务器10将程序P存储于存储部15并执行该程序P，由此，控制部11执行控制部11所包含的作为各部分的处理。即，存储于存储部15的程序P使服务器10实现控制部11所执行的各功能。该程序P也可以表现为程序模块，还可以不表现为程序模块。
其他装置也是同样的。
在本公开的各实施方式中，说明通过终端20及/或服务器10的CPU执行程序P来实现的情况。
其他装置也是同样的。
需要说明的是，终端20的控制部21及/或服务器10的控制部11不仅通过具有控制电路的CPU来实现各处理，也可以通过形成于集成电路(IC(Integrated Circuit)芯片、LSI(Large Scale Integration))等的逻辑电路(硬件)或专用电路来实现各处理，还可以不采用这种方式。另外，这些电路可以由一个或多个集成电路实现，也可以由一个集成电路实现各实施方式所示的多个处理，还可以不采用这种方式。另外，根据集成度的差异，LSI也有时被称为VLSI、超级LSI、特级LSI等。因此，控制部21也可以表现为控制电路，还可以不表现为控制电路。
其他装置也是同样的。
另外，本公开的各实施方式的程序P(作为非限定的例子，为软件程序、计算机程序或者程序模块)也可以以存储在计算机可读取的存储介质中的状态被提供，还可以不采用这种方式。关于存储介质，能够在“非暂时的有形介质”中存储程序P。另外，程序P也可以用于实现本公开的各实施方式的功能的一部分，还可以不采用这种方式。此外，也可以采用能够通过与已经记录在存储介质中的程序P的组合来实现本公开的各实施方式的功能的所谓的差分文件(差分程序)，还可以不采用这种方式。
存储介质能够包括一个或多个半导体基板或其他的集成电路(IC)(作为非限定的例子，为现场可编程门阵列(FPGA)或面向特定用途的IC(ASIC)等)、硬盘驱动器(HDD)、混合硬盘驱动器(HHD)、光盘、光盘驱动器(ODD)、光磁盘、光磁驱动器、软盘、软盘驱动器(FDD)、磁带、固体驱动器(SSD)、RAM驱动器、安全数字卡、或者驱动器、其他任意的适当的存储介质、或者这些装置中的两个以上的适当组合。在适当的情况下，存储介质可以是易失性、非易失性、或者易失性与非易失性的组合。需要说明的是，存储介质不限于这些例子，只要能够存储程序P即可，可以是任何的设备或介质。另外，也可以将存储介质表现为存储器(memory)，还可以不表现为存储器(memory)。
服务器10及/或终端20能够通过读出存储介质所存储的程序P并执行所读出的程序P来实现各实施方式所示的多个功能部的功能。
其他装置也是同样的。
另外，本公开的程序P也可以经由能够传输程序的任意的传输介质(通信网络或广播波等)被提供给服务器10及/或终端20，还可以不采用这种方式。作为非限定的例子，服务器10及/或终端20通过执行经由因特网等而下载的程序P来实现各实施方式所示的多个功能部的功能。
其他装置也是同样的。
另外，即便是通过电子传输来体现程序P的数据信号的方式，也能够实现本公开的各实施方式。
服务器10及/或终端20中的处理的至少一部分也可以通过由一个以上的计算机构成的云计算来实现，还可以不采用这种方式。
也可以采用由服务器10进行终端20中的处理的至少一部分的结构，还可以不采用这种结构。在该情况下，也可以采用由服务器10进行终端20的控制部21的各功能部的处理中的至少一部分处理的结构，还可以不采用这种结构。
也可以采用由终端20进行服务器10中的处理的至少一部分的结构，还可以不采用这种结构。在该情况下，也可以采用由终端20进行服务器10的控制部11的各功能部的处理中的至少一部分处理的结构，还可以不采用这种结构。
除非明确说明，否则本公开的实施方式中的判定的结构就不是必须的，也可以在满足了判定条件的情况下进行规定的处理或者在不满足判定条件的情况下进行规定的处理，还可以不采用这种方式。
需要说明的是，作为非限定的例子，使用ActionScript、JavaScript(注册商标)等脚本语言、Objective-C、Java(注册商标)等编译器语言、HTML5等标记语言等来安装本公开的程序。
＜第一实施例＞
首先，对上述的“(A)共同帐户结算”的实施例进行说明。
首先，作为共同帐户结算的基本实施例(第一实施例)，对以下的实施例进行说明：终端20利用支付应用，经由服务器10从共同钱包的余额(共同钱包的电子钱币的余额，以下称为“共同钱包余额”。)进行在能够通过支付应用进行支付的店铺中的支付。
以下，将通过支付应用提供支付服务的运营商称为“支付服务的运营商”。
需要说明的是，支付服务的运营商能够表现为提供支付应用的运营商、或者服务器10的运营商。
另外，在提供结算服务的运营商这一含义上，也能够表现为结算服务的运营商。
另外，以下，将与支付服务的运营商合作并在针对由店铺提供的商品销售/服务的支付中能够利用使用支付应用的支付服务的店铺称为“加盟店”，该支付服务进行。
另外，以下，说明由支付服务的运营商运用/管理服务器10的情况。另外，以下，将支付应用的名称适当称为“Payment App”来进行图示/说明。
另外，支付应用可以作为不具有所谓的消息收发服务(MS：Messaging Service)的功能的单体的应用而由服务器10提供，也可以作为具有MS的功能的复合应用而由服务器10提供。另外，在消息收发服务中，可以包括能够进行终端20间的简单消息等内容的收发的即时消息收发服务(IMS：Instant Messaging Service)，也可以不包括该即时消息收发服务。
在内容中，除了包括包含单纯的文本或图形文字等的消息之外，作为非限定的例子，还能够包括图像信息(包含静止图像、动态图像等。)、操作用信息(包含按钮、图标等。)、通信用信息/连接信息(包含URI、URL等。)等能够在终端20之间收发的各种信息。
另外，支付应用可以作为不具有所谓的社交网络服务(SNS：Social NetworkingService)的功能的单体的应用而由服务器10提供，也可以作为具有SNS的功能的复合应用而由服务器10提供。
需要说明的是，消息收发服务：MS(包含IMS。)也能够认为是社交网络服务：SNS的一个方式(一方式)。
因此，可以区分MS与SNS，也可以不区分MS与SNS。
＜功能结构＞
图1-3是示出在本实施例中由服务器10的控制部11实现的功能的一例的图。
作为非限定的例子，控制部11包括用于按照存储于存储部15的支付应用管理处理程序151来执行支付应用管理处理的支付应用管理处理部111作为功能部。
图1-4是示出在本实施例中存储于服务器10的存储部15的信息的一例的图。
作为非限定的例子，在存储部15中存储有作为支付应用管理处理而执行的支付应用管理处理程序151、支付应用用户注册数据153、用户管理数据库155、以及共同钱包管理数据库157。
支付应用用户注册数据153是与利用支付应用的终端20或者该终端20的用户相关的注册数据，图1-5示出其数据结构的一例。
作为非限定的例子，在支付应用用户注册数据153中关联地存储有用户名、支付应用ID、终端电话号码以及其他注册信息。
用户名是利用支付应用的终端20的用户的名称，作为非限定的例子，存储有终端20的用户在利用支付应用时注册的名称。
支付应用ID是支付应用的帐户(帐户信息)，是能够识别终端20或终端20的用户的ID。作为非限定的例子，该支付应用ID由服务器10设定固有的ID并存储。
终端电话号码是该用户名的用户的终端20的电话号码，作为非限定的例子，存储有终端20的用户在利用支付应用时注册的终端20的电话号码。
在其他注册信息中，作为非限定的例子，能够包括该用户名的用户的终端20的邮件地址(终端邮件地址)、支付应用中的用于各种认证的认证密码等认证信息、该用户所使用的图标的图像数据(图标图像)、用户的资料(用户资料)等。
但是，这些信息不是必须的。
用户管理数据库155是基于支付应用用户注册数据153所存储的帐户(帐户信息)的用户的管理用的数据库，图1-6示出其数据结构的一例。
在用户管理数据库155中，作为支付应用用户注册数据153所存储的每个支付应用ID的管理数据，存储有用户管理数据。
在各个用户管理数据中，作为非限定的例子，存储有支付应用ID和电子钱币账户余额。
这里，参照共同钱包管理数据库157对共同钱包详细进行说明。
共同钱包是指，由利用支付应用的多个用户在进行支付前预先设定的电子钱币账户的一个方式。
在共同钱包中，能够由所设定的多个用户利用其余额进行支付。以下，将能够利用共同钱包的用户称为“共同钱包成员”。
为了利用共同钱包，首先，用户进行用于生成共同钱包的操作。在该生成中，作为非限定的例子，需要使用确定共同钱包成员的电子钱币账户的信息(作为非限定的例子，为支付应用ID)。
共同钱包管理数据库157是服务器10用于管理共同钱包的数据库，图1-7示出作为其一例的第一共同钱包管理数据库157A的数据结构例。
在第一共同钱包管理数据库157A中，作为用于唯一地识别共同钱包的每个共同钱包ID的管理数据，存储有共同钱包管理数据。
作为非限定的例子，在各个共同钱包管理数据中关联地存储有共同钱包ID、共同钱包名、共同钱包余额以及共同钱包成员ID。
共同钱包ID是支付应用中的共同钱包的帐户(以下，适当称为“共同帐户”。)。
共同钱包名是由共同钱包ID识别的共同钱包的名称。
共同钱包余额是在利用由共同钱包ID识别的共同钱包进行支付时使用的电子钱币的余额。
共同钱包成员ID是在生成共同钱包时指定的共同钱包成员的支付应用ID。
需要说明的是，也能够通过在生成共同钱包后向共同钱包成员ID追加支付应用ID，来追加新的共同钱包成员。另外，也可以将同一用户所具有的多个支付应用ID存储于共同钱包成员ID，还可以不采用这种方式。
在生成共同钱包的情况下，其共同钱包余额为“0”。在进行支付前，共同钱包成员从各个电子钱币账户将电子钱币转账到共同钱包，使共同钱包余额增加。
需要说明的是，共同钱包成员也能够从在支付服务中注册的外部金融机构的账户(作为非限定的例子，为银行账户)向共同钱包充值(转换成电子钱币并转账)。
在不再需要共同钱包的情况下，进行用于取消所存在的共同钱包的共同钱包废弃操作。当执行共同钱包废弃操作时，将共同钱包余额以共同钱包成员的人数进行均摊(均等分配)而得到的金额转账给共同钱包成员的各个电子钱币账户。进而，在共同钱包余额成为“0”之后，从第一共同钱包管理数据库157A中删除该共同钱包管理数据的记录。
＜处理＞
(1)利用者提示型的码结算
图1-8～图1-9是示出在本实施例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。本处理是与利用者提示型的代码结算相关的处理的一例。
作为一例，将能够由用户A.A的终端20(终端A)和用户B.B的终端20(终端B)利用的电子钱币账户作为共同钱包进行说明。实际上，能够使用共同钱包进行支付的终端不限于两个，但由于成为与终端B同样的处理，因此，在本说明书中省略图示。
需要说明的是，该处理只不过是用于实现本公开的方法的处理的一例，不限定于该处理。也可以向该处理追加其他步骤，还可以省略(删除)一部分步骤。
这在以下说明的各流程图(处理)中是同样的。
另外，在附图中记载了各装置所执行的处理的序号，但在说明书中省略记载。在以后的实施例中也是同样的。
首先，终端A的控制部21通过通信I/F22，向服务器10发送共同钱包制作/选择信息(A100)。
具体而言，通过通信I/F22，向服务器10发送选择能够从终端A利用的共同钱包的信息(作为非限定的例子，为共同钱包ID)。在本步骤中，可以通过通信I/F22从服务器10接收能够选择的共同钱包ID，也可以调用预先存储于存储部28的能够选择的共同钱包ID。
另外，在不存在能够从终端A利用的共同钱包的情况下，通过通信I/F22，向服务器10发送用于新制作共同钱包的信息。这里，在用于新制作共同钱包的信息中，作为非限定的例子，包括构成共同钱包的成员的帐户信息(作为非限定的例子，为用户A.A和用户B.B的支付应用ID)、共同钱包的名称、向共同钱包的初始转账额。
在通过通信I/F14从终端A接收到选择共同钱包的信息或者用于新制作共同钱包的信息时，服务器10的控制部11基于接受了请求的共同钱包ID、或者新制作并由控制部11唯一地(以没有重复的方式)分配的共同钱包ID，生成认可从钱包支付的支付令牌。
以下，将认可从与共同钱包ID绑定的共同钱包余额支付的支付令牌称为“共同钱包支付令牌”。这里，作为非限定的例子，通过规定的位数(作为非限定的例子，为12位)的整数值来识别共同钱包支付令牌。另外，共同钱包支付令牌可以是只限于在从生成开始的规定的时间内(作为非限定的例子，为“5分”)进行认可的、具有有效期限的令牌，也可以不是这样的令牌。
当生成共同钱包支付令牌后，服务器10的控制部11生成包括共同钱包支付令牌的代码信息即共同钱包码信息。作为非限定的例子，共同钱包码信息包括将共同钱包支付令牌的识别符编码为一维码(条形码等)或二维码(QR码等)的支付码(图像信息)。
需要说明的是，在共同钱包支付令牌具有有效期限的情况下，共同钱包码信息也可以包括该有效期限。另外，也可以包括生成了共同钱包支付令牌的共同钱包的名称。
之后，服务器10的控制部11通过通信I/F14向终端A发送共同钱包码信息(S100a)。
在通过通信I/F22从服务器10接收到共同钱包码信息时，终端A的控制部21使接收到的共同钱包码信息显示于显示部24(A110a)。具体而言，作为非限定的例子，作为共同钱包码信息使支付码显示于显示部24。
需要说明的是，在共同钱包码信息中包括共同钱包支付令牌的识别符、有效期限的情况下，终端A的控制部21也可以显示识别符、有效期限，还可以不显示识别符、有效期限。
另外，在支付码的显示中共同钱包支付令牌的有效期限过期的情况下，终端A的控制部21也可以通过通信I/F22向服务器10发送申请共同钱包支付令牌的重新生成的信息，还可以不采用这种方式。
在该情况下，服务器10的控制部21重新生成共同钱包支付令牌和共同钱包码信息，通过通信I/F14向终端A发送共同钱包码信息。然后，在通过通信I/F22从服务器10接收到重新生成的共同钱包码信息时，终端A的控制部21能够使支付码和有效期限重新显示于显示部24。
接着，服务器10的控制部11通过通信I/F14，向终端A发送与生成了共同钱包支付令牌的共同钱包相关的信息即共同钱包信息(S110)。作为非限定的例子，共同钱包信息包括共同钱包余额。
在通过通信I/F22从服务器10接收到共同钱包信息时，终端A的控制部21使接收到的共同钱包信息显示于显示部24(A120)。具体而言，作为非限定的例子，作为共同钱包信息使共同钱包余额加入到显示部24中进行显示。
店铺读码器装置50的控制部51执行店铺结算处理，基于针对店铺读码器装置50的输入输出部52的操作，向控制部51输入规定的结算预定金额(作为非限定的例子，为“3，000日元”)。然后，店铺读码器装置50的控制部51使用读码器58，读取终端A的显示部24所显示的支付码(P140)。在该情况下，显示部24所显示的支付码与共同钱包支付令牌建立了关联，因此，在读码器58的读取结果中包括共同钱包支付令牌作为支付令牌。
作为非限定的例子，店铺读码器装置50的控制部51通过通信I/F54，向服务器10发送包括店铺ID、结算预定金额以及支付令牌(在该情况下为共同钱包支付令牌)的结算请求信息(P150)。
在通过通信I/F14从店铺读码器装置50接收到结算请求信息时，服务器10的控制部11根据接受了请求的共同钱包支付令牌来检索共同钱包ID，针对该共同钱包，执行与由店铺ID决定的加盟店之间进行结算预定金额的支付的结算处理(S170a)。
作为非限定的例子，服务器10的控制部11通过通信I/F14，向终端A和店铺读码器装置50发送包括结算处理的成功与否和结算处理后的共同钱包余额的结算结果信息(S180a)，结束处理。
在通过通信I/F22从服务器10接收到结算结果信息时，终端A的控制部21使结算结果信息显示于显示部24(A180)，结束处理。
另外，在通过通信I/F54从服务器10接收到结算结果信息时，店铺读码器装置50的控制部51使结算结果信息显示于显示部53(P160)，结束处理。
(2)店铺提示型的码结算
以下，作为非限定的例子，将“支付店铺码”作为包括用于识别加盟店的加盟店识别信息(作为非限定的例子，为向加盟店固有地分配的店铺ID)的代码(一维码或二维码)来进行说明。
需要说明的是，也可以使支付店铺码包括特定的结算预定金额(作为非限定的例子，为“500日元”)的信息，还可以不包括该信息。
图1-10～图1-11是示出在该情况下由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理的一例。
需要说明的是，针对与已经出现的流程图(处理)相同的步骤标注相同的标号并省略再次的说明。
这在以下说明的各个流程图(处理)中是同样的。
与上述的处理同样，在由服务器10的控制部11生成共同钱包支付令牌时，服务器10的控制部11生成包括共同钱包支付令牌的代码读取用信息即共同钱包读码器信息。然后，服务器10的控制部11通过通信I/F14向终端A发送共同钱包读码器信息(S100b)。
在A100之后，当通过通信I/F22从服务器10接收到共同钱包读码器信息时，终端A的控制部21基于接收到的共同钱包读码器信息，使用于读取支付店铺码的读码器画面显示于显示部24。另外，终端A的控制部21为了读取代码而起动相机27(A110b)。然后，终端A的控制部21将处理移至A120。
在A120之后，终端A的控制部21执行使用相机27等来读取支付店铺码的代码读取处理(A190)。由此，从读取的支付店铺码取得店铺ID。
之后，作为非限定的例子，终端A的控制部21使用于输入结算预定金额的显示画面显示于显示部24。当基于针对终端A的输入输出部23的用户操作而输入结算预定金额时，作为非限定的例子，控制部21将包括共同钱包读码器信息所包含的共同钱包支付令牌、店铺ID以及结算预定金额的结算请求信息通过通信I/F22向服务器10发送(A200)。然后，终端A的控制部21将处理移至A180。
需要说明的是，在支付店铺码中包含结算预定金额的情况下，终端A中的结算预定金额的输入能够省略。
在S110之后，当通过通信I/F14从终端A接收到结算请求信息时，服务器10的控制部11根据接受了请求的共同钱包支付令牌来检索共同钱包ID，针对该共同钱包，执行与由店铺ID决定的加盟店之间进行结算预定金额的支付的店铺提示型的结算处理(S170b)。
之后，作为非限定的例子，服务器10的控制部11通过通信I/F14，向终端A发送包括结算处理的成功与否和结算处理后的共同钱包余额的结算结果信息(S180b)。然后，控制部11结束处理。
＜第二实施例＞
第二实施例是这样的实施例：终端20利用支付应用，从共同钱包余额执行加盟店中的支付，但在支付时共同钱包余额不足的情况下，显示与共同钱包余额不足相关的信息。
另外，第二实施例是在共同钱包余额不足的情况下代替共同钱包(共同帐户)而从自己的钱包(自己的用户帐户)进行结算的实施例。
第二实施例所记载的内容也能够应用于其他的各实施例或其他的各变形例中的任意一个。
另外，针对与已经出现的结构要素相同的结构要素标注相同的标号并省略再次的说明。
＜显示画面例＞
以下，例示终端20为具备显示部24的智能手机的情况，该显示部24为纵长的显示器。
作为非限定的例子，在智能手机中，作为输入部发挥功能的触摸面板与该显示器对置配置。在图标、按钮、条目或输入区域等要素显示于显示器的情况下，当触摸面板的一部分区域并且是与显示有该要素的区域对置的区域被用户触摸到时，执行与该要素建立了关联的程序或者该程序的子程序。以下，与显示器中显示有该要素的区域对置的触摸面板的区域也称为对置区域。即，对置区域作为受理单元发挥功能。
图2-1是示出在由终端20执行的支付应用中显示于显示部24的应用画面的一例的图。该应用画面是在由用户进行了起动支付应用的操作且支付应用起动了的情况下显示的画面的一例。
在该应用画面中，作为非限定的例子，在最上层的标题栏中显示有作为支付应用的应用名的“Payment App”，在“Payment App”的横侧显示有用户A.A的图标图像和用户名“A.A”的文字。在标题栏的下方显示有“Payment App”的分层菜单中的当前位置。具体而言，作为非限定的例子，显示有作为当前执行中的最上位的菜单的“钱包主菜单”。在“钱包主菜单”的下方设置有用于显示自己(用户A.A)的电子钱币账户余额的电子钱币账户余额显示区域(以下仅称为“余额显示区域”。)241。
在该例中，在余额显示区域241中，作为由“Payment App”管理的用户A.A的电子钱币账户余额而显示有“25，000日元”，在“25，000日元”的横侧显示有用于充入金额的充值按钮241A。另外，在它们的下方设置有图标显示区域，该图标显示区域显示与支付应用的各种功能对应的多个图标，作为能够从“钱包主菜单”选择的子菜单。在该例中，在图标显示区域中，分别显示有与“转账”、“代码支付”、“读码器”、“优惠券”、“积分”以及“共同钱包”分别对应的六个图标。以下，将与“共同钱包”对应的图标作为共同钱包图标CN1进行说明。
图2-2是示出在图2-1的应用画面中对共同钱包图标CN1进行了触摸操作的情况下显示的共同钱包选择画面的一例的图。
在该例中，在标题栏的下方显示有作为当前执行中的子菜单的“共同钱包”来作为“Payment App”的分层菜单中的当前位置。
在“共同钱包”的下方，显示有“请选择共同钱包”的说明文作为针对用户的操作引导，在该说明文的下方设置有多个共同钱包的显示区域。在该例中，显示有作为露营资金用的共同钱包显示区域的露营资金显示区域242和作为韩国旅行用的共同钱包显示区域的韩国旅行显示区域243。另外，在共同钱包的显示区域的下方设置有用于新追加/注册共同钱包的用户能够操作的新注册操作区域244。
在露营资金显示区域242，在上层与表示是共同钱包的“方形钱包”的图像一起显示有该共同钱包的名称(在该例中，为“露营资金”)。另外，在该共同钱包的名称的横侧显示有各种设定图标。
另外，在下层显示有该露营资金的共同钱包余额(这里为“1，000日元”)，在共同钱包余额的横侧显示有共同使用该共同钱包的用户的图标图像和用户名。在该例中，显示有用户A.A和用户B.B的图标图像以及用户名。即，该露营资金用的共同钱包可以说是由用户A.A和用户B.B这两名用户构成的共同钱包。
同样，在韩国旅行显示区域243，在上层与表示是共同钱包的方形钱包的图像一起显示有该共同钱包的名称(在该例中为“露营资金”)。另外，在该共同钱包的名称的横侧显示有各种设定图标。
另外，在下层显示有余额(在该例中为“90，000日元”)，在该余额的横侧显示有共同使用该共同钱包的用户的图标图像和用户名。在该例中，显示有用户A.A、用户D.D以及用户E.E的图标。即，该韩国旅行用的共同钱包可以说是由用户A.A、用户D.D以及用户E.E这三名用户构成的共同钱包。
在新注册操作区域244，在中央部显示有“+”标记，构成为用户能够容易识别是用于新追加/注册共同钱包的操作区域。不限于对该“+”标记进行触摸操作，通过对新注册操作区域244内的任意的位置进行触摸操作，能够进行共同钱包的新制作/注册。
图2-3是示出在图2-2的共同钱包选择画面中对露营资金显示区域242内进行了触摸操作的情况下显示的露营资金支付画面的一例的图。
在该例中，在标题栏的下方，显示有作为当前执行中的子菜单的“共同钱包：露营资金”来作为上述分层菜单中的当前位置。另外，在“共同钱包：露营资金”的下方显示有“主菜单”作为针对用户的操作引导，在“主菜单”的下方显示有露营资金显示区域242。在露营资金显示区域242的下方显示有与作为能够从“主菜单”选择的子菜单的“进账”、“代码支付”、“读码器”、“通知”、“转账”以及“钱包废弃”分别对应的六个图标。
这些图标中的表示为“代码支付”的图标是用于在进行“利用者提示型”的代码结算时从服务器10取得支付码的“代码支付图标”。另外，表示为“读码器”的图标是用于在进行“店铺提示型”的代码结算时为了由终端20读取终端读取用码而使作为代码支付应用的功能设置的读码器(以下称为，“应用读码器”。)起动的读码器图标。
图2-4是示出在图2-3的露营资金支付画面中由终端20的用户A.A对表示为“代码支付”的图标进行了触摸操作的情况下显示的代码支付画面的一例的图。
在该例中，在标题栏的下方显示有作为当前执行中的子菜单的“露营资金”来作为“Payment App”的分层菜单中的当前位置。另外，在“露营资金”的下方显示有“代码支付”作为针对用户的操作引导，在“代码支付”的下方显示有露营资金代码支付区域2421。
在露营资金代码支付区域2421，与上述同样，与方形钱包的图像及共同钱包的名称(露营资金)一起显示有该露营资金的共同钱包余额(在该例中为“1，000日元”)。
在它们的下方，与表示是终端20的用户的钱包(电子钱币账户)的与袋状钱包的图像一起显示有“自己的钱包”的文字，在“自己的钱包”的横侧，显示有其余额(电子钱币账户余额)(在该例中为“25，000日元”)。
另外，在“自己的钱包”的下方，显示有作为非限定的例子由条形码表示的一维的支付码和作为非限定的例子由QR码(注册商标)表示的二维的支付码，来作为从服务器10发送并由终端20接收到的代码(代码图像)，并且是为了通过共同钱包进行结算而使用的代码即支付码。
另外，在这些支付码中，规定了能够利用这些支付码来进行结算的期间(以下称为“代码能够使用期间”。)，在该例中，与支付码建立关联地以倒计时形式显示有代码能够使用期间的剩余时间。代码能够使用期间能够为任意的期间，但作为非限定的例子，能够预先规定为“5分钟”的期间。
需要说明的是，也可以将代码能够使用期间设为在终端20中显示支付码的期间(以下称为“代码显示期间”。)，在代码显示期间结束的情况下，将显示中的支付码设为非显示，还可以不采用这种方式。
终端20的用户在代码收银机处向店铺的店员提示代码支付画面，通过店铺读码器装置50读取支付码，由此进行代码支付。
图2-5是示出在由店铺读码器装置50读取了图2-4的代码支付画面的支付码的结果是共同钱包余额不足的情况下显示于终端20的显示部24的共同钱包余额不足画面的一例的图。
在该共同钱包余额不足画面中，显示有“露营资金”作为当前位置，在“露营资金”的下方，以弹出窗口的形式显示有共同钱包余额不足信息显示/操作区域2427。在该例中，作为表示余额不足的图像而显示“愁容满面的机器人”的图像，在该图像的下方，显示有“共同钱包余额不足”作为余额不足消息。
另外，在“共同钱包余额不足”的下方，以文字的形式显示有“要支付的购物”，在该例中，与AA运动株式会社的标志图像一起显示有其公司名即“AA运动株式会社”的文字。在“AA运动株式会社”的横侧显示有“3，000日元”的文字作为支付金额，在它们的下方，与方形钱包的图像及共同钱包的名称(露营资金)一起显示有该露营资金的共同钱包余额(在该例中为“1，000日元”)作为明细。
另外，在“露营资金”的下方，与袋状钱包的图像及自己的钱包一起显示有自己的电子钱币账户余额(在该例中，为“25，000日元”)。此外，在“自己的钱包”的下方显示有“从自己的钱包余额中支付2，000日元？”这样的引导文，来作为用于确认用户是否有意愿从自己的钱包支付结算余额不足额(＝结算预定金额-共同钱包余额)的信息。在该例中，支付金额为“3，000日元”，与此相对，共同钱包余额为“1，000日元”，因此，缺少“2，000日元”，不足部分的金额成为“2，000日元”。
另外，在该例中，在共同钱包余额不足信息显示/操作区域2427的下部，显示有用于从自己的钱包余额执行支付的作为非限定的例子而表示为“支付”的支付执行按钮242W、以及用于不从自己的钱包余额执行支付的作为非限定的例子而表示为“不支付”的支付非执行按钮242X。
图2-6是示出在图2-5的共同钱包余额不足画面中对支付执行按钮242W进行了触摸操作之后由服务器10完成了结算处理的情况下显示于终端20的显示部24的代码支付完成画面的一例的图。
在该代码支付完成画面中，显示有“露营资金”作为当前位置，在“露营资金”的下方显示有与结算结果相关的信息。具体而言，与“代码支付”的文字一起显示有“THanKYOU！”的文字作为支付完成消息，在“THanK YOU！”的下方显示有表示感谢心情的“以笑脸贺喜的机器人的图像”。此外，在“以笑脸贺喜的机器人的图像”的下方，与支付金额“3，000日元”一起显示有“支付完成。”的文字。
另外，在“支付完成。”的下方，显示有支付日为“2020年4月11日”并且其时刻为“16时30分”作为支付的详细信息。另外，在支付的详细信息的下方显示有支付对方为“AA运动株式会社”。
另外，在支付对方的下方，隔着横线而显示有支付明细。在该例中，显示有表示从露营资金的共同钱包支付的支付金额为“1，000日元”且从自己的钱包支付的支付金额为“2，000日元”的信息。
＜处理＞
图2-7～图2-8是示出在本实施例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。本处理是与利用者提示型的代码结算相关的处理的一例。
在S110之后，服务器10的控制部11通过通信I/F14，向终端A发送与终端A的用户即用户A.A的支付应用ID绑定的用户帐户信息(作为非限定的例子，为电子钱币账户余额)(S120)。
在A120之后，当通过通信I/F22从服务器10接收到用户帐户信息时，终端A的控制部21使接收到的用户帐户信息显示于显示部24(A130)。具体而言，作为非限定的例子，使终端A的用户A.A的电子钱币账户余额加入到显示部24中进行显示。
店铺读码器装置50的控制部51执行店铺结算处理，基于针对店铺读码器装置50的输入输出部52的操作，向控制部51输入规定的结算预定金额(作为非限定的例子，为“3，000日元”)。然后，店铺读码器装置50的控制部51使用读码器58，读取终端A的显示部24所显示的支付码(P100)。在该情况下，显示部24所显示的支付码与共同钱包支付令牌建立了关联，因此，在读码器58的读取结果中包括共同钱包支付令牌。
作为非限定的例子，店铺读码器装置50的控制部51通过通信I/F54，向服务器10发送包括店铺ID、结算预定金额以及共同钱包支付令牌的结算请求信息(P110)。
当通过通信I/F14从店铺读码器装置50接收到结算请求信息时，服务器10的控制部11根据接受了请求的共同钱包支付令牌来检索共同钱包ID，针对该共同钱包，执行与由店铺ID决定的加盟店之间进行结算预定金额的支付的结算处理(S250a)。
在结算处理中结算成功的情况下(S260a：是)，服务器10的控制部11将处理进入S180c。
另一方面，在结算处理中结算失败的情况下(S260a：否)，作为非限定的例子，服务器10的控制部11通过通信I/F14，向终端A和店铺读码器装置50发送包括结算失败这一旨意和该情况下的共同钱包中的结算余额不足额的结算余额不足信息(S270a)。
在A130之后，当通过通信I/F22从服务器10接收到结算余额不足信息时(A270a：是)，终端A的控制部21使接收到的结算余额不足信息加入显示部24中进行显示(A280)。另外，终端A的控制部21使接收到的结算余额不足信息所包含的结算余额不足额存储于存储部28(A290)。
之后，作为非限定的例子，基于针对在显示部24中与结算余额不足信息一起显示的用户帐户信息进行了操作输入(针对输入输出部23的操作输入)，终端A的控制部21通过通信I/F22向服务器10发送结算请求信息，该结算请求信息向服务器10请求从自己(用户A.A)的电子钱币账户余额支付不足部分，来从共同钱包余额和自己的电子钱币账户余额进行结算(A295)。
当通过通信I/F14从终端A接收到结算请求信息时，服务器10的控制部11执行结算处理(S170c)。具体而言，作为非限定的例子，使共同钱包余额减少至“0”，从用户A.A的电子钱币账户余额扣除不足部分。
之后，作为非限定的例子，服务器10的控制部11通过通信I/F14，向终端A和店铺读码器装置50发送包括图2-6的支付完成画面中包含的各种信息的结算结果信息(S180c)，结束处理。
另一方面，在没有从服务器10接收到结算余额不足信息的情况下(A270a：否)，终端A的控制部21通过通信I/F22从服务器10接收结算结果信息，使处理移至A180。
在P110之后，当通过通信I/F54从服务器10接收到结算余额不足信息时(P120：是)，店铺读码器装置50的控制部51使结算余额不足信息显示于显示部53(P130)。然后，店铺读码器装置50的控制部51在从服务器10接收到结算结果信息后，使处理移至P160。
＜结算余额不足信息的显示＞
“显示了结算余额不足信息”是指“显示了结算余额不足信息之后”和“一旦显示了结算余额不足信息的情况”，不一定需要当前也显示有结算余额不足信息。
即，“针对显示了结算余额不足信息的显示部24的输入”是包括如下两种情况的概念。
(1)在显示了结算余额不足信息之后，在显示有结算余额不足信息的状态下进行了针对显示部24的输入的情况
(2)在显示了结算余额不足信息之后，将结算余额不足信息设为非显示，然后进行了针对显示部24的输入的情况。
这在以下说明的实施例中也是同样的。
＜针对终端的输入＞
在上述的处理中，示出了基于针对终端20的输入输出部23的操作输入来实现是否从终端20的用户的用户帐户(电子钱币账户)中支付不足部分的选择的例子，但不限定于此。这也可以通过针对终端20的麦克风25的声音输入(包括语言输入。)等来实现，还可以不采用这种方式。
这在针对终端20的各种输入时是同样的。
＜第二实施例的效果＞
第二实施例示出以下的结构：终端20基于自己的终端20的用户能够结算的帐户(不限定，第一帐户的一例)，通过控制部21来执行与结算相关的处理。另外，终端20将结算余额不足信息(不限定，基于第一结算的金额和第一帐户的余额的、与第一帐户的余额不足相关的第一信息的一例)显示于显示部24。进而，终端20基于针对显示了结算余额不足信息的显示部24的输入，执行从自己的终端20的用户的用户帐户(不限定，与第一帐户不同的第二帐户的一例)支付不足部分来进行结算的处理(不限定，与第一结算相关的处理的一例)。
作为通过这样的结构而得到的效果的一例，能够向终端的用户通知终端的用户能够结算的第一帐户的余额不足。另外，除了能够基于第一帐户实现结算之外，还能够至少基于与第一帐户不同的第二帐户实现结算。
另外，第二实施例示出自己的终端20的用户能够结算的帐户是共同帐户(不限定，是至少终端的用户和与终端的用户不同的第一用户能够结算的共同帐户的一例)的结构。
作为通过这样的结构而得到的效果的一例，能够基于至少终端的用户和与终端的用户不同的第一用户能够结算的共同帐户来实现结算。
＜第二变形例(1)＞
在第二实施例中，针对利用者提示型的代码结算进行了说明，但不限定于此。
具体而言，作为非限定的例子，也能够应用店铺提示型的代码结算。
＜显示画面例＞
图2-9是示出终端20的显示部24所显示的读码器画面的一例的图。
在图2-3的露营资金支付画面中不是“代码支付”的图标而是“读码器”的图标被终端20的用户A.A进行了触摸操作的情况下，作为非限定的例子，起动应用读码器，使图2-9所示的用于读取支付店铺码的读码器画面显示于显示部24。
在该读码器画面中，在标题栏的下方，显示有作为当前执行中的子菜单的“露营资金”来作为“Payment App”的分层菜单中的当前位置。
另外，在“露营资金”的下方，显示有代码读取区域CR1，在代码读取区域CR1的下方，显示有“读码器”作为针对用户的操作引导，在“读码器”的下方显示有露营资金代码支付区域2423。
在露营资金代码支付区域2423的上部，与方形钱包的图像一起显示有“露营资金”的文字，在“露营资金”的横侧，显示有该露营资金的共同钱包余额(在该例中为“1，000日元”)。另外，在它们的下方，与袋状钱包的图像一起显示有“自己的钱包”的文字，在“自己的钱包”的横侧显示有自己的电子钱币账户余额(在该例中为“25，000日元”)。
图2-10是示出在图2-9的读码器画面中读取了支付店铺码的情况下显示的读取完成画面的一例的图。
在代码读取区域CR1内显示有所读取的支付店铺码。另外，在画面下部的露营资金代码支付区域2423显示有与图2-9同样的信息。
图2-11是示出接着图2-10而显示的支付金额输入画面的一例的图。当通过解码从所读取的支付店铺码取得信息时，显示用于输入支付金额的支付金额输入画面。
在该支付金额输入画面中，作为针对用户的操作引导而显示有“支付金额的输入”，在“支付金额的输入”的下方，与作为支付金额的转账对方的“AA运动株式会社”的图标图像一起显示有其名称“AA运动株式会社”。另外，在“AA运动株式会社”的下方，显示有用于显示所输入的支付金额的支付金额显示区域2424。另外，在支付金额显示区域2424的下方，显示有“请输入支付金额(含税)”的文字，在“请输入支付金额(含税)”的下方显示有支付按钮242C。
另外，在画面下部显示有用于输入支付金额的键盘，并且显示有用于消除支付金额的消除按钮CN4。
在该例中，示出作为支付金额而输入“3，000日元”并显示于支付金额显示区域2424的状态。
图2-12是示出在图2-10的支付金额输入画面中对支付按钮242C进行了触摸操作之后基于共同钱包余额不足而显示的共同钱包余额不足画面的一例的图。
该共同钱包余额不足画面的结构与图2-5是同样的。与图2-5的不同点在于，共同钱包余额不足信息显示/操作区域2427的背景为读码器画面。
在图2-12的共同钱包余额不足画面中对支付执行按钮242W进行了触摸操作并且由服务器10进行的结算处理完成时，显示与图2-6同样的代码支付完成画面。
＜处理＞
图2-13～图2-14是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理的一例。
在A300之后，作为非限定的例子，终端A的控制部21使用于输入结算预定金额的显示画面显示于显示部24。当基于针对终端A的输入输出部23的用户操作而输入结算预定金额时，作为非限定的例子，终端A的控制部21通过通信I/F22向服务器10发送包括共同钱包读码器信息所包含的共同钱包支付令牌、店铺ID以及结算预定金额的结算请求信息(A310)。
需要说明的是，在支付店铺码中包含结算预定金额的情况下，能够省略终端A中的结算预定金额的输入。
当通过通信I/F14从终端A接收到结算请求信息时，服务器10的控制部11根据接受了请求的共同钱包支付令牌来检索共同钱包ID，针对该共同钱包，执行与由店铺ID决定的加盟店之间进行结算预定金额的支付的店铺提示型的结算处理(S250b)。
在S250b中结算成功的情况下(S260b：是)，服务器10的控制部11使处理移至S180d。
在S250b中结算失败的情况下(S260b：否)，服务器10的控制部11通过通信I/F14向终端A发送包括结算失败这一旨意和该情况下的共同钱包中的结算余额不足额的结算余额不足信息(S270b)。
当通过通信I/F22从服务器10接收到结算余额不足信息时(A270b：是)，终端A的控制部21使结算余额不足信息显示于显示部24(A280)，使结算余额不足额存储于存储部28(A290)。然后，终端A的控制部21使处理移至A295。具体而言，终端A的控制部21通过通信I/F22向服务器10发送与图2-8的A295同样的主旨的结算请求信息。然后，终端A的控制部21通过通信I/F22从服务器10接收结算结果信息，使处理移至A180。
当通过通信I/F14从终端A接收到结算请求信息时，服务器10的控制部11执行与图2-8的S170c同样的主旨的店铺提示型的结算处理(S170d)。然后，服务器10的控制部11通过通信I/F14向终端A发送结算结果信息(S180d)，结束处理。
另一方面，在没有从服务器10接收到结算余额不足信息的情况下(A270b：否)，终端A的控制部21通过通信I/F22从服务器10接收结算结果信息，使处理移至A180。
＜第二变形例(2)＞
在第二实施例中，在共同钱包余额不足的情况下，从终端20的用户的用户帐户支付不足部分，但不限定于此。
具体而言，在共同钱包余额不足的情况下，也可以不使用共同钱包余额而从终端20的用户的用户帐户支付全额，还可以不采用这种方式。即，也可以将进行结算的帐户从共同帐户(共同钱包)变更(切换)为终端20的用户的用户帐户(用户的电子钱币账户余额)，还可以不采用这种方式。
＜第三实施例＞
第三实施例是实现从自己的钱包向共同钱包转账的实施例。
通过能够从自己的钱包向共同钱包转账，从而作为非限定的例子，能够预先补充共同钱包余额，或者在支付时共同钱包余额不足的情况下补充共同钱包余额。
第三实施例所记载的内容也能够应用于其他的各实施例或其他的各变形例中的任意一个。
另外，针对与已经出现的结构要素相同的结构要素标注相同的标号并省略再次的说明。
＜显示画面例＞
针对终端20的显示部24所显示的显示画面例进行说明。
图3-1～图3-3的显示画面与图2-1～图2-3的显示画面分别是同样的。
图3-4是示出在图3-3的露营资金支付画面中由终端20的用户A.A对表示为“代码支付”的图标进行了触摸操作的情况下显示的代码支付画面(转账前)的一例的图。
在该例中，在标题栏的下方，显示有作为当前执行中的子菜单的“露营资金”来作为“Payment App”的分层菜单中的当前位置。另外，在“露营资金”的下方，显示有“代码支付”作为针对用户的操作引导，在“代码支付”的下方显示有露营资金代码支付区域2421。
在露营资金代码支付区域2421中，与上述同样地，与方形钱包的图像及共同钱包的名称(露营资金)一起显示有该露营资金的共同钱包余额(在该例中为“1，000日元”)。
在“露营资金”的下方，与在圆圈内包含选择标记的选择标记按钮CN2一起显示有“从自己的钱包转账”的文字，在“从自己的钱包转账”的横侧显示有余额(在该例中，为25，000日元)。当对选择标记按钮CN2进行触摸操作时，显示用于从自己的钱包向共同钱包转账的转账用画面。
另外，在选择标记按钮CN2的下方，显示有作为非限定的例子而由条形码表示的一维的支付码和作为非限定的例子而由QR码(注册商标)表示的二维的支付码，来作为从服务器10发送并由终端20接收到的代码(代码图像)，并且是为了通过“利用者提示型”进行结算而使用的代码即支付码。
另外，在这些支付码中，规定了能够利用这些支付码来进行结算的期间(以下称为“代码能够使用期间”。)，在该例中，与支付码建立关联地以倒计时形式显示有代码能够使用期间的剩余时间。代码能够使用期间能够为任意的期间，但作为非限定的例子，能够预先规定为“5分钟”的期间。
需要说明的是，也可以将代码能够使用期间设为在终端20中显示支付码的期间(以下称为“码显示期间”。)，在代码显示期间结束的情况下，将显示中的支付码设为非显示，还可以不采用这种方式。
图3-5是示出在图3-4的代码支付画面中由终端20的用户A.A对选择标记按钮CN2进行了触摸操作的情况下显示的转账用画面的一例的图。
在该例中，在标题栏的下方，显示有作为当前执行中的子菜单的“露营资金”来作为“Payment App”的分层菜单中的当前位置。另外，在“露营资金”的下方，显示有“转账”作为针对用户的操作引导，在“转账”的下方，显示有作为转账预定对象的用户A.A的图标图像和用户名“A.A”。
另外，在用户A.A的下方，与“转账额”的显示一起显示有用于显示所输入的转账预定金额的转账预定金额输入区域2422。这里，示出作为转账预定金额而输入了“5，000日元”的状态。另外，在“5，000日元”的下方，为了向转账预定金额输入区域2422输入相加金额，这里沿横向并排地显示有用于加上“100日元”的第一相加按钮BT1、用于加上“1，000日元”的第二相加按钮BT2、以及用于加上“10，000日元”的第三相加按钮BT3。
作为非限定的例子，在作为转账预定金额而输入了“5，000日元”的状态下对第一相加按钮BT1进行了一次触摸操作时，转账预定金额输入区域2422内显示为“5，100日元”，接下来在对第二相加按钮BT2进行了一次触摸操作时，显示为“6，100日元”，接下来在对第三相加按钮BT3进行了一次触摸操作时，显示为“16，100日元”。
另外，在该例中，在转账预定金额输入区域2422内的左部显示有消除按钮CN3，当对消除按钮CN3进行了触摸操作时，转账预定金额输入区域2422内的金额被消除，转账预定金额输入区域2422内显示为“0日元”。
另外，在该例中，在第一相加按钮BT1的下方，显示有用户A.A自身的钱包内的余额(这里为“25，000日元”)。
另外，在该例中，在转账用画面下部，显示有用于执行输入到转账预定金额输入区域2422内的金额的转账的转账按钮242A。
需要说明的是，当触摸了转账预定金额输入区域2422时，也可以在显示部24的下部显示有用于输入转账预定额的数字键盘区域，基于向数字键盘区域的输入，详细输入转账预定额。
图3-6是示出在图3-5的转账用画面中对转账按钮242A进行了触摸操作的情况下显示的代码支付画面(转账后)的一例的图。
露营资金代码支付区域2421内与图3-4是同样的，但由于是转账后，因此，各个余额的金额变得不同。即，作为露营资金的共同钱包余额，显示有加上了转账额的“6，000日元”，作为自己的电子钱币账户余额，显示有扣除了转账额的“20，000日元”。另外，表示进行了转账的选择标记按钮CN2被反相显示(反転表示)。
需要说明的是，在该例中，支付码都为与图3-4的支付码相同的码。
终端20的用户A.A通过在代码收银机处向店铺的店员提示上述的代码支付画面，通过店铺读码器装置读取支付码，由此进行代码支付。
图3-7是示出在由服务器10完成了代码支付的情况下显示于终端20的代码支付完成画面的一例的图。
在该代码支付完成画面中，显示有“露营资金”作为当前位置，在“露营资金”的下中央显示有“代码支付”。
另外，在该例中，在“代码支付”的下方，显示有“THanK YOU！”的文字作为支付完成消息，在“THanK YOU！”的下方显示有表示感谢心情的“以笑脸贺喜的机器人的图像”，此外，在“以笑脸贺喜的机器人的图像”的下方，以大写文字显示有“3，000日元”作为支付金额，在“3，000日元”的下方显示有“支付完成。”的文字作为完成通知。
另外，在“支付完成。”的下方，示出支付日为“2020年4月11日”并且其时刻为“16时30分”作为支付完成信息。另外，在支付完成信息的下方，示出支付对方为AA运动株式会社。
另外，在代码支付完成画面下部，显示有确认按钮242B。
＜处理＞
图3-8是示出在本实施例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。本处理是与利用者提示型的代码结算相关的处理的一例。
需要说明的是，关于处理的后半部分，作为非限定的例子，能够与图1-9相同，因此，这里省略说明。
在A130之后，终端A的控制部21将用于选择是否从用户A.A的电子钱币账户向共同钱包转账的信息(作为非限定的例子，为具有选择功能的按钮)加入到显示部24中进行显示。然后，终端A的控制部21基于针对输入输出部23的用户操作，判定是否选择了从用户A.A的电子钱币账户向共同钱包转账(A140)。
在选择了向共同钱包转账的情况下(A140：是)，作为非限定的例子，终端A的控制部21使促使输入转账额的画面(转账用画面)显示于显示部24。当基于针对终端A的输入输出部23的用户操作而输入了转账额时，终端A的控制部21通过通信I/F22向服务器10发送包括转账额的转账委托信息(A150)。
在S120之后，当通过通信I/F14从终端A接收到转账委托信息时(S130：是)，服务器10的控制部11执行从用户A.A的电子钱币账户向共同钱包对转账额进行转账的转账处理(S140)。
然后，服务器10的控制部11通过通信I/F14向终端A发送包括转账后的共同钱包余额的共同钱包信息(S150)。
当通过通信I/F22从服务器10接收到共同钱包信息时，终端A的控制部21基于接收到的共同钱包信息，作为非限定的例子而将共同钱包余额更新并显示于显示部24(A160)。
另外，服务器10的控制部11通过通信I/F14向终端A发送包括转账后的用户A.A的电子钱币账户余额的用户帐户信息(S160)。然后，服务器10的控制部11使处理移至图1-9的S170a。
当通过通信I/F22从服务器10接收到用户帐户信息时，终端A的控制部21基于接收到的用户帐户信息，作为非限定的例子而将用户A.A的电子钱币账户余额更新并显示于显示部24(A170)。然后，终端A的控制部21使处理移至图1-9的A180。
需要说明的是，在没有选择从用户A.A的电子钱币账户向共同钱包转账的情况下(A140：否)，不执行A150～A170的步骤。因此，服务器10的控制部11不会接收到转账委托信息(S130：否)，也不执行S140～S160的步骤。
需要说明的是，如上所述，针对终端20的输入不限定于操作输入。
在上述的处理中，示出了基于针对终端20的输入输出部23的操作输入来实现是否从终端20的用户的用户帐户(电子钱币账户)向共同钱包转账的选择的例子，但不限定于此。这也可以通过针对终端20的麦克风25的声音输入(包括语音输入。)等来实现，还可以不采用这种方式。
＜第三实施例的效果＞
第三实施例示出以下的结构：终端20将与自己的终端20的用户能够结算的帐户(不限定，第一帐户的一例)建立了关联的共同钱包码信息(不限定，第一代码信息的一例)和与自己的终端20的用户的用户帐户(不限定，第二帐户的一例)相关的用户帐户信息(不限定，第二帐户信息的一例)显示于显示部24。进而，终端20通过控制部21来执行以下的处理，即：基于由自己的终端20的用户进行的用于选择从该用户的用户帐户的电子钱币账户向共同钱包转账的输入(操作输入、声输入等)(不限定，针对第二帐户信息的输入的一例)而将转账用画面显示于显示部24的处理、向服务器10发送转账委托信息的处理、从服务器10接收更新后的共同钱包余额的处理、将接收到的共同钱包余额更新并显示于显示部24的处理、从服务器10接收用户帐户的电子钱币账户余额的处理、将接收到的用户帐户的电子钱币账户余额更新并显示于显示部24的处理、使支付码显示于显示部24的处理、从服务器10接收结算结果信息的处理、使接收到的结算结果信息显示于显示部24的处理等，作为与结算关联的处理而由终端20执行的处理(不限定，与基于第一帐户和第二帐户的第一结算相关的处理的一例)。
作为通过这样的结构而得到的效果的一例，能够将与终端的用户能够结算的第一帐户建立了关联的第一代码信息显示于终端的显示区域而用于结算，并且，能够使终端的用户识别和与第一帐户不同的第二帐户相关的第二帐户信息。另外，能够基于针对第二帐户信息的输入，来实现基于第一帐户和第二帐户的结算。
另外，第三实施例示出以下的结构：上述的自己的终端20的用户能够结算的帐户是至少自己的终端20的用户(作为一例，为用户A.A)(不限定，终端的用户的一例)和不同的终端20的用户(作为一例，为用户B.B)(不限定，与终端的用户不同的第一用户的一例)能够结算的共同帐户。
作为通过这样的结构而得到的效果的一例，能够将第一代码信息显示于终端的显示区域而用于结算，并且，能够使终端的用户识别与和共同帐户不同的第二帐户相关的第二帐户信息。另外，能够基于针对第二帐户信息的输入，来实现基于共同帐户和第二帐户的结算。
另外，第三实施例示出以下的结构：终端20将共同钱包余额(不限定，与共同帐户建立了关联的第一电子货币的金额)的信息和转账用画面(不限定，用于从第二帐户向共同帐户进行转账的第一显示的一例)显示于显示部24。进而，终端20基于由自己的终端20的用户针对转账用画面进行的输入(操作输入、声音输入等)，执行从自己的终端20的用户的用户帐户向共同帐户的转账，基于向共同帐户的转账，将转账后的共同钱包余额(不限定，与共同帐户建立了关联的第二电子货币的金额)的信息显示于显示部24。
作为通过这样的结构而得到的效果的一例，能够向终端的用户通知与共同帐户建立了关联的第一电子货币的金额。另外，能够基于针对第一显示的输入，简单地实现从第二帐户向共同帐户的转账，并且，能够基于向共同帐户的转账，向终端的用户通知与共同帐户建立了关联的第二电子货币的金额。
另外，第三实施例示出了基于从自己的终端20的用户的用户帐户(不限定，第二帐户的一例)转账的共同帐户来执行与第一结算相关的处理的结构。
作为通过这样的结构而得到的效果的一例，能够基于从第二帐户转账的共同帐户来实现结算。
另外，第三实施例示出了针对转账用画面的输入(不限定，针对第一显示的输入的一例)包括从自己的终端20的用户的用户帐户(不限定，第二帐户的一例)向共同帐户转账的金额的输入的结构。
作为通过这样的结构而得到的效果的一例，能够基于从第二帐户向共同帐户转账的金额的输入来实现从第二帐户向共同帐户的转账。
另外，第三实施例示出了第二帐户是自己的终端20的用户的用户帐户(不限定，终端的用户的帐户的一例)的结构。
作为通过这样的结构而得到的效果的一例，能够将终端的用户的帐户作为第二帐户来实现结算。
＜第三变形例(1)＞
在第三实施例中，针对利用者提示型的代码结算进行了说明，但不限定于此。
具体而言，作为非限定的例子，也能够应用店铺提示型的代码结算。
＜显示画面例＞
图3-9是示出终端20的显示部24所显示的读码器画面的一例的图。
在图3-3的露营资金支付画面中不是“代码支付”的图标而是“读码器”的图标被终端20的用户A.A进行了触摸操作的情况下，作为非限定的例子而起动应用读码器，将图3-9所示的用于读取支付店铺码的读码器画面显示于显示部24。
在该读码器画面中，在标题栏的下方，显示有作为当前执行中的子菜单的“露营资金”来作为“Payment App”的分层菜单中的当前位置。
另外，在“露营资金”的下方显示有代码读取区域CR1，在代码读取区域CR1的下方显示有“读码器”作为针对用户的操作引导，在“读码器”的下方显示有露营资金代码支付区域2423。
在露营资金代码支付区域2423，在上部与表示是共同钱包的方形钱包的图像一起显示有“露营资金”的文字，在“露营资金”的横侧显示有该露营资金的共同钱包余额(在该例中为“1，000日元”)。另外，在它们的下方，与选择标记按钮CN2及从自己的钱包转账的文字一起显示有自己的电子钱币账户余额(在该例中为“25，000日元”)。
这里，在图3-9的读码器画面中由终端20的用户A.A对选择标记按钮CN2进行了触摸操作时，显示与图3-5同样的转账用画面。在该例中，例示在转账用画面中用户A.A从自己的钱包向共同钱包转账“5，000日元”的情况。
图3-10是示出在图3-5的转账用画面中对转账按钮242A进行触摸操作而完成了从自己的钱包向露营资金的转账、之后完成了支付店铺码的读取的情况下显示的读取完成画面的一例的图。
在该代码读取区域CR1内显示有所读取的支付店铺码。另外，在露营资金代码支付区域2423中，基于如上述那样用户A.A从自己的钱包向共同钱包转账了“5，000日元”而显示有“6，000日元”作为露营资金的共同钱包余额，并且显示有“20，000日元”作为自己的电子钱币账户余额。另外，表示进行了转账的选择标记按钮CN2被反相显示。
图3-11是示出在通过解码从在图3-10的读取完成画面中所读取的支付店铺码取得了信息的情况下显示的支付金额输入画面的一例的图。
在该支付金额输入画面中，显示有“支付金额的输入”作为针对用户的操作引导，在“支付金额的输入”的下方，与作为支付金额的转账对方的“AA运动株式会社”的图标图像一起显示有其名称“AA运动株式会社”。另外，在它们的下方，显示有用于显示所输入的支付金额的支付金额显示区域2424，这里，输入并显示“3，000日元”作为支付金额。另外，在“3，000日元”的下方，显示有“请输入支付金额(含税)”的文字，在“请输入支付金额(含税)”的下方，显示有支付按钮242C。
另外，在画面下方，显示有用于输入支付金额的键盘并且显示有用于消除支付金额的消除按钮CN4。
在图3-11所示的支付金额输入画面中对用于执行支付的支付按钮242C进行触摸操作而完成了代码支付时，与图3-7同样地显示代码支付完成画面。
＜处理＞
图3-12是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理的一例。
需要说明的是，关于处理的后半部分，作为非限定的例子，能够与图1-11相同，因此，这里省略说明。
与图3-8的S100a同样地生成共同钱包支付令牌，服务器10的控制部11生成包括共同钱包支付令牌的代码读取用信息即共同钱包读码器信息。然后，服务器10的控制部11通过通信I/F14向终端A发送共同钱包读码器信息(S100b)。然后，服务器10的控制部11使处理移至S110。
在A100之后，当通过通信I/F22从服务器10接收到共同钱包读码器信息时，终端A的控制部21基于接收到的共同钱包读码器信息，使用于读取支付店铺码的读码器画面显示于显示部24。另外，终端A的控制部21为了读取代码而起动相机27(A110b)。然后，终端A的控制部21使处理移至A120。
在A170之后，当使用相机27等读取被加盟店提示的支付店铺码时，终端A的控制部21从读取的支付店铺码取得店铺ID(A190)。
之后，终端A的控制部21使用于输入结算预定金额的显示画面显示于显示部24。当基于针对终端A的输入输出部23的用户操作而输入了结算预定金额时，作为非限定的例子，控制部21通过通信I/F22向服务器10发送包括共同钱包读码器信息所包含的共同钱包支付令牌、店铺ID以及结算预定金额的结算请求信息(A200)。然后，终端A的控制部21使处理移至A180。
需要说明的是，在支付店铺码包含结算预定金额的情况下，能够省略终端A中的结算预定金额的输入。
在S160之后，当通过通信I/F14从终端A接收到结算请求信息时，服务器10的控制部11根据接受了请求的共同钱包支付令牌来检索共同钱包ID，针对该共同钱包，执行与由店铺ID决定的加盟店之间进行结算预定金额的支付的结算处理(S170b)。
之后，作为非限定的例子，服务器10的控制部11通过通信I/F14向终端A发送包括结算处理的成功与否和结算处理后的共同钱包余额的结算结果信息(S180b)。然后，控制部11结束处理。
本变形例示出以下的结构：终端20将基于共同钱包读码器信息的、用于读取支付店铺码(不限定，代码信息的一例)的读码器画面(不限定，第一读码器信息的一例)和与自己的终端20的用户的用户帐户(不限定，第二帐户的一例)相关的用户帐户信息(不限定，第二帐户信息的一例)显示于显示部24。进而，终端20通过控制部21执行以下的处理，即：基于由自己的终端20的用户进行的、用于选择从该用户的用户帐户的电子钱币账户向共同钱包转账的输入(操作输入、声音输入等)(不限定，针对第二帐户信息的输入的一例)而将转账用画面显示于显示部24的处理、向服务器10发送转账委托信息的处理、从服务器10接收共同钱包余额的处理、将接收到的共同钱包余额更新并显示于显示部24的处理、从服务器10接收用户帐户的电子钱币账户余额的处理、将接收到的用户帐户的电子钱币账户余额更新并显示于显示部24的处理、读取支付店铺码的处理、向服务器10发送结算请求信息的处理、从服务器10接收结算结果信息的处理、将接收到的结算结果信息显示于显示部24的处理这样的作为与结算关联的处理而由终端20执行的处理(不限定，与基于第一帐户和第二帐户的第一结算相关的处理的一例)。
作为通过这样的结构而得到的效果的一例，能够将作为与代码信息的读取相关的显示的第一读码器信息显示于终端的显示区域而用于结算，并且，能够使终端的用户识别与和第一帐户不同的第二帐户相关的第二帐户信息。另外，能够基于针对第二帐户信息的输入，来实现基于第一帐户和第二帐户的结算。
＜第三变形例(2)＞
在第三实施例中，示出了在支付开始时从用户A.A的电子钱币账户余额内向共同钱包转账的例子，但不限定于此。
作为非限定的例子，也可以在向共同钱包转账前，从由用户A.A预先注册的外部金融机构的账户向用户A.A的电子钱币账户进行充值(转账)。
＜显示画面例＞
图3-13是示出在图3-3的露营资金支付画面中由终端20的用户A.A对“代码支付”的图标进行了触摸操作的情况下显示的代码支付画面(转账前)的一例的图。
露营资金代码支付区域2421内的显示与图3-4大致是同样的，但一部分不同。具体而言，作为非限定的例子，在与“从自己的钱包转账”建立了关联的自己的电子钱币账户余额的金额的横侧，显示有用于向自己的电子钱币账户充值的充值按钮CN5。另外，在该例中，显示有“1，000日元”作为自己的电子钱币账户余额。
另外，在“从自己的钱包转账”的下方，与选择标记按钮CN2一起显示有“向共同钱包充值”的文字作为用于向共同钱包充值的显示。
图3-14是示出在图3-13的代码支付画面(充值前)中对充值按钮CN5进行了触摸操作的情况下显示的充值画面的一例的图。
在标题栏的下方，显示有作为当前执行中的子菜单的“自己的钱包”来作为“Payment App”的分层菜单中的当前位置。另外，在“自己的钱包”的下方，显示有“充值”作为针对用户的操作引导，在“充值”的下方，设置有银行账户显示区域2425。
在该例中，在银行账户显示区域2425内，与“〇×银行”的标志(〇×BANK)一起显示有该银行名“〇×银行”。另外，在“〇×银行”的下方，显示有“一般存款账户＊＊＊＊＊＊＊”作为存款种类和账户账号，在“一般存款账户＊＊＊＊＊＊＊”的下方显示有作为开户人的“A.A”。
在银行账户显示区域2425的下方，与“充值金额”的显示一起设置有用于显示所输入的充值预定金额的充值预定金额输入区域2426。这里，输入并显示“24，000日元”作为充值预定金额。
另外，在充值预定金额的下方，为了向充值预定金额输入区域2426输入充值金额，在该例中沿横向并排地显示有用于充入“100日元”的第一充值按钮BT5、用于充入“1，000日元”的第二充值按钮BT6、以及用于充入“10，000日元”的第三充值按钮BT7。
在该例中，在对第一充值按钮BT5进行了触摸操作时，充值预定金额输入区域2426内显示为“24，100日元”，接下来在对第二充值按钮BT6进行了触摸操作时，显示为“25，100日元”，接下来在对第三充值按钮BT7进行了触摸操作时，显示为“35，100日元”。
需要说明的是，在充值预定金额输入区域2426内的左部显示有消除按钮BT8，当对消除按钮BT8进行了触摸操作时，充值预定金额输入区域2426内的金额被消除，充值预定金额输入区域2426内显示为“0日元”。
另外，在充值用画面下部，显示有用于执行输入到充值预定金额输入区域2426内的金额的充值的充值按钮242D。在对充值按钮242D进行了触摸操作的情况下，向自己的钱包充入了“24，000日元”。
需要说明的是，在对充值预定金额输入区域2426进行了触摸操作时，也可以在显示部24的下部显示用于输入转账预定额的数字键盘区域，基于向数字键盘区域的输入，详细输入转账预定额。
图3-15是示出在图3-14的充值画面中对充值按钮242D进行了触摸操作的情况下显示的代码支付画面的一例的图。
露营资金代码支付区域2421内与图3-13是同样的，但由于被充值，因此，在“从自己的钱包转账”的文字的横侧显示的余额(在该例中为“25，000日元”)的金额不同。
需要说明的是，在该例中，支付码都为与图3-13的支付码相同的码。
如上所述，在触摸了与“从自己的钱包转账”对应的选择标记按钮CN2而对露营资金执行了转账之后，终端20的用户A.A在代码收银机处向店铺的店员提示上述的代码支付画面，通过店铺读码器装置读取支付码，由此进行代码支付。当由服务器10完成结算处理时，显示与图3-7同样的代码支付完成画面。
＜处理＞
图3-16是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理的一例。
在A130之后，作为非限定的例子，终端A的控制部21使是否向用户A.A的电子钱币账户进行充值的选择用画面显示于显示部24。然后，终端A的控制部21基于针对终端A的输入输出部23的用户操作，来判定是否选择了向用户A.A的电子钱币账户进行充值(A210)。
在选择了向用户A.A的电子钱币账户进行充值的情况下(A210：是)，终端A的控制部21使促使输入充值金额的画面显示于显示部24。当基于针对终端A的输入输出部23的用户操作而输入了充值金额时，终端A的控制部21通过通信I/F22向服务器10发送包括充值金额的充值委托信息(A220)。
在S120之后，当通过通信I/F14从终端A接收到充值委托信息时(S190：是)，服务器10的控制部11执行从用户A.A的外部金融机构的账户余额扣除充值金额并使用户A.A的电子钱币账户余额增加充值金额的充值处理(S200)。
之后，服务器10的控制部11通过通信I/F14向终端A发送包括充值处理后的用户A.A的电子钱币账户余额的用户帐户信息(S210)。
需要说明的是，在S200的处理中由于用户A.A的外部金融机构的账户余额低于充值金额等原因而无法正常地进行充值的情况下，也可以发送包括充值失败这一旨意的用户帐户信息，还可以不发送该户帐户信息。
当通过通信I/F22从服务器10接收到用户帐户信息时，终端A的控制部21基于接收到的用户帐户信息，作为非限定的例子而将终端A的用户A.A的电子钱币账户余额更新并显示于显示部24(A230)。
另一方面，在没有选择向用户A.A的电子钱币进行充值的情况下(A210：否)，不执行A220～A230的步骤。因此，服务器10的控制部11不会接收到充值委托信息(S190：否)，也不执行S200～S210的步骤。
需要说明的是，也可以在向共同钱包的转账处理(图3-16的A170和S160)之后通过执行A210～A230的步骤和S190～S210的步骤而向用户A.A的电子钱币账户充入电子钱币，还可以不采用这种方式。
＜第三变形例(3)＞
在第三实施例中，示出了在进行结算处理的时间点从用户A.A的电子钱币账户余额内向共同钱包转账的例子，但不限定于此。
作为非限定的例子，也可以在向共同钱包转账前，从由用户A.A预先注册的外部金融机构的账户向共同钱包作为电子钱币进行充值(转账)。
图3-17是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理的一例。
在A130之后，作为非限定的例子，终端A的控制部21使是否向共同钱包进行充值的选择用画面显示于显示部24。然后，终端A的控制部21基于针对终端A的输入输出部23的用户操作，来判定是否选择了向共同钱包进行充值(A240)。
在选择了向共同钱包进行充值的情况下(A240：是)，终端A的控制部21使促使输入向共同钱包充值的充值金额的画面显示于显示部24。当基于针对终端A的输入输出部23的用户操作而输入了向共同钱包充值的充值金额时，终端A的控制部21通过通信I/F22向服务器10发送包括向共同钱包充值的充值金额的共同钱包充值委托信息(A250)。
在S120之后，当通过通信I/F14从终端A接收到共同钱包充值委托信息时(S220：是)，服务器10的控制部11执行从用户A.A的外部金融机构的账户余额扣除向共同钱包充值的充值金额并使共同钱包余额增加向共同钱包充值的充值金额的共同钱包充值处理(S230)。
之后，服务器10的控制部11通过通信I/F14向终端A发送包括共同钱包充值处理后的共同钱包余额的共同钱包信息(S240)。
需要说明的是，在S230的处理中由于用户A.A的外部金融机构的账户余额低于向共同钱包充值的充值金额等原因而无法正常地充值的情况下，也可以发送包括充值失败这一旨意的共同钱包信息，还可以不发送该共同钱包信息。
当通过通信I/F22从服务器10接收到共同钱包信息时，终端A的控制部21基于接收到的共同钱包信息，作为非限定的例子而将共同钱包余额更新并显示于显示部24(A260)。
另一方面，在没有选择向共同钱包充入电子钱币的情况下(A240：否)，不执行A250～A260的步骤。因此，服务器10的控制部11不会接收到共同钱包充值委托信息(S220：否)，也不执行S230～S240的步骤。
需要说明的是，也可以在向共同钱包的转账处理(图3-17的A170和S160)之后通过执行A240～A260的步骤和S220～S240的步骤而向共同钱包充入电子钱币，还可以不采用这种方式。
＜第三变形例(4)＞
在第三实施例中，终端20也可以向与自己的终端20的用户不同的其他共同钱包成员的终端20发送委托向共同钱包转账的信息等而向共同钱包进行转账，还可以不采用这种方式。
图3-18是示出在本变形例中显示于终端20的显示部24的代码支付画面的一例的图，示出用户A.A的终端20(终端A)的显示部24所显示的画面的一例。
该代码支付画面是与韩国旅行用的共同钱包对应的代码支付画面，在韩国旅行用的共同钱包的显示区域即韩国旅行显示区域2431内，除了设置有上述的用于从自己的钱包向共同钱包转账的“从自己的钱包转账”的项目和用于向共同钱包进行充值的“向共同钱包充值”的项目之外，还设置有用于向其他共同钱包成员委托向共同钱包转账的“向其他成员委托转账”的项目。另外，与这些各个项目建立关联地设置有用于执行与该项目对应的处理的选择标记按钮CN2。
图3-19是示出在图3-18的代码支付画面中对与向其他成员委托转账的项目建立了关联的选择标记按钮CN2进行了触摸操作的情况下显示于显示部24的成员选择画面的一例的图。
该成员选择画面是用于选择委托转账的共同钱包成员(转账委托对方)的画面，在画面中央部，一览显示有共同钱包成员的候选。在该例中，作为韩国旅行用的共同钱包的共同钱包成员并且是自己的终端20的用户(用户A.A)以外的共同钱包成员，与图标图像及用户名一起显示有用户D.D和用户E.E这两名用户。
与各个共同钱包成员建立关联地显示有选择标记按钮CN2，构成为通过将选择标记按钮CN2设为“打开”(“ON”)的状态，能够将该共同钱包成员选择为转账委托对方。
在该情况下，不限于1人，也能够将2人以上(包括全员。)的共同钱包成员选择为转账委托对方。
另外，在画面下部，显示有用于执行转账的委托的表示为“转账委托”的转账委托按钮242U、以及用于返回到前一个画面的表示为“返回”的返回按钮242V。
作为非限定的例子，转账委托按钮242U在全部的选择标记按钮CN2为“关闭”(“OFF”)的状态下变灰，成为不能受理操作的状态。当至少一个选择标记按钮CN2成为“打开”的状态时，解除变灰，成为能够受理操作的状态。
需要说明的是，也能够与该例不同，基于至少包括自己的终端20的用户和其他的共同钱包成员在内的聊天室的选择来选择转账委托对方的用户。
以下，将消息收发应用中的谈话室作为例子来进行说明。利用了消息收发应用的谈话是“聊天”的一例，谈话室是“聊天室”的一例。
“聊天”是用于终端20的用户彼此使用计算机网络上的数据通信线路进行交流的手段，“聊天室”是用于进行该聊天的虚拟的房间。在聊天中包括利用消息收发服务：MS(包括即时消息收发服务(IMS)。)、社交网络服务：SNS的聊天。另外，作为非限定的例子，也可以包括利用所谓的短消息服务的聊天。
在本说明书中，聊天包括利用了消息收发服务的谈话，聊天室包括用于进行谈话的谈话室。谈话室除了包括用于供用户以一对一的形式进行谈话的谈话室之外，还包括用于以在消息收发服务中形成的包含多个用户的组来进行谈话的组谈话室。
图3-20是示出本变形例中的服务器10的结构的一例的图。
作为非限定的例子，服务器10具备支付管理服务器10A和消息收发管理服务器10B。
支付管理服务器10A是提供支付服务的服务器(支付应用的应用服务器)。
消息收发管理服务器10B是提供消息收发服务(MS：Messaging Service)的服务器(消息收发应用的应用服务器)。
需要说明的是，支付应用可以如上述的实施例那样作为不具有消息收发服务的功能的单体的应用而由服务器10提供，也可以如本变形例那样作为具有消息收发服务的功能的复合的应用而由服务器10提供。
另外，在消息收发服务中可以包含能够进行终端20之间的简单的消息等内容的收发的即时消息收发服务(IMS：Instant Messaging Service)，也可以不包含该即时消息收发服务(IMS：Instant Messaging Service)。
在本变形例中，作为非限定的例子，来说明消息收发管理服务器10B提供IMS作为消息收发服务的情况。
另外，以下，说明消息收发应用和支付应用构成为复合的应用且消息收发应用的用户的信息和支付应用的用户的信息作为共同的信息而由服务器10管理的情况。
另外，以下，将消息收发应用的名称适当作为“Messaging App”进行图示/说明。
图3-21是示出在该情况下由用户A.A的终端A执行的消息收发应用中的成员选择画面(谈话室选择画面)的一例的图。
作为非限定的例子，在图3-18的代码支付画面中对与向其他成员委托转账的项目建立了关联的选择标记按钮CN2进行了触摸操作时，从支付应用的画面转移到消息收发应用的画面，显示该成员选择画面。
在该成员选择画面中，在画面上部显示有“Messaging App”的文字，在“MessagingApp”的横侧显示有自己的终端20的用户(在该例中为用户A.A)的图标图像和用户名。
另外，与“从谈话室选择”的文字一起显示有“请选择委托转账的谈话室”的文字，在“请选择委托转账的谈话室”的下方显示有作为转账委托对方而选择的谈话室的候选。
具体而言，作为非限定的例子，在消息收发应用中作为用于在与用户A.A注册为朋友的用户并且是与韩国旅行用的共同钱包具有关联的用户之间用户A.A进行谈话的谈话室，显示有作为共同钱包成员的用户D.D的谈话室和同样作为共同钱包成员的用户E.E的谈话室。
另外，在该例中，作为非限定的例子，在消息收发应用中作为用于在与用户A.A注册为朋友的用户并且是与韩国旅行用的共同钱包具有关联的用户之间用户A.A进行组谈话的组谈话室，显示有作为非限定的例子而由用户A.A、用户D.D以及用户E.E这三名用户构成的“韩国美食联盟(3)”的组谈话室。
与各个谈话室建立关联地显示有选择标记按钮CN2，构成为通过将选择标记按钮CN2设为“打开”的状态，能够将该谈话室(该谈话室的用户)选择为转账委托对方。
在该情况下，作为非限定的例子，不限于1人，也能够将2人以上(包括全员。)的用户选择为转账委托对方。
需要说明的是，在上述的消息收发应用中的成员选择画面中，组谈话室也可以不作为转账委托对方的候选而显示。另外，也可以将在消息收发应用中与用户A.A注册为朋友的全部用户、在支付应用中与用户A.A成为共同钱包成员的用户、预先由用户A.A选择/设定的用户等的谈话室作为转账委托对方的候选而显示，还可以不采用这种方式。
本变形例示出第二帐户是与自己的终端20的用户不同的其他共同钱包成员(不限定，第一用户的一例)的用户帐户(不限定，第一用户的帐户的一例)的结构。
作为通过这样的结构而得到的效果的一例，能够将第一用户的帐户作为第二帐户而实现基于共同帐户和第二帐户的结算。
另外，本变形例示出基于由自己的终端20的用户针对自己的终端20进行的输入来选择其他的共同钱包成员的用户帐户的结构。
作为通过这样的结构而得到的效果的一例，能够基于由终端的用户针对终端进行的输入来简单地选择第二帐户。
另外，本变形例示出基于包括自己的终端20的用户和其他的共同钱包成员在内的谈话室(不限定，聊天室的一例)的选择来选择其他的共同钱包成员的用户帐户的结构。
作为通过这样的结构而得到的效果的一例，能够基于由终端的用户进行的、包括终端的用户和第一用户的聊天室的选择来简单地选择第二帐户。
＜第四实施例＞
第四实施例是在终端20利用支付应用从共同钱包余额执行加盟店中的支付但在支付时共同钱包余额不足的情况下显示与共同钱包余额不足相关的信息的实施例。
另外，第四实施例是在共同钱包余额不足的情况下代替共同钱包而基于在第三实施例中说明的方法通过从自己的终端20的用户的电子钱币账户向共同钱包进行转账从而弥补共同钱包的余额不足的实施例。
第四实施例所记载的内容能够应用于其他的各实施例或其他的各变形例中的任意一个。
另外，针对与已经出现的结构要素相同的结构要素标注相同的标号并省略再次的说明。
＜显示画面例＞
图4-1是示出在图3-4的代码支付画面中不对选择标记按钮CN2进行触摸操作而利用支付码进行了代码支付的情况下并且是在共同钱包余额不足的情况下显示的共同钱包余额不足画面的一例的图。
在该共同钱包余额不足画面中，显示有“露营资金”作为当前位置，在“露营资金”的下方，以弹出窗口形式显示有共同钱包余额不足信息显示/操作区域2427。在该例中，显示有“愁容满面的机器人”的图像作为表示余额不足的图像，在“愁容满面的机器人”的下方显示有“共同钱包余额不足”作为余额不足消息。
另外，在“共同钱包余额不足”的下方显示有“要支付的购物”的文字，在“要支付的购物”的下方，与AA运动株式会社的标志图像一起显示有其公司名即“AA运动株式会社”的文字。在“AA运动株式会社”的横侧，显示有“3，000日元”的文字作为支付金额，在“AA运动株式会社”的下方，与方形钱包的图像及共同钱包的名称(露营资金)一起显示有该露营资金的共同钱包余额(在该例中为“1，000日元”)作为明细。
另外，在“露营资金”的下方，与表示是终端20的用户的钱包(电子钱币账户)的袋状钱包的图像及自己的钱包一起显示有自己的电子钱币账户余额(在该例中为“25，000日元”)。此外，在它们的下方，为了从自己的钱包转账共同钱包余额不足而显示有“从自己的钱包余额转账2，000日元？”的引导文。
另外，在该例中，在共同钱包余额不足信息显示/操作区域2427的下部，显示有为了弥补余额不足而用于执行不足金额的转账的、作为非限定的例子而表示为“转账”的转账按钮242E。另外，在“转账”的下方，显示有用于不执行不足金额的转账的、作为非限定的例子而表示为“现在不这样做”的取消按钮242F。
图4-2是示出在图4-1的共同钱包余额不足画面中对转账按钮242E进行了触摸操作的情况下显示的代码支付画面(转账后)的一例的图。
露营资金代码支付区域2421内与图3-4是同样的，但由于是从自己的钱包转账后，因此，各个余额的金额变得不同。即，作为露营资金的共同钱包余额而显示加上了转账额的“3，000日元”，作为自己的电子钱币账户余额而显示扣除了转账额的“23，000日元”。
图4-3是示出与图3-7同样地在由服务器10完成了代码支付的情况下显示于终端20的代码支付完成画面的一例的图。
图4-3所示的代码支付完成画面与图3-7所示的代码支付完成画面的不同点在于，在支付对方的下方，隔着横线而追加有支付明细。具体而言，作为支付明细，与方形钱包的图像及露营资金的文字一起显示有该“露营资金”的共同钱包余额(在该例中为“1，000日元”)。另外，在它们的下方，与袋状钱包的图像及自己的钱包的文字一起显示有自己的电子钱币账户余额(在该例中为“2，000日元”)。
＜处理＞
图4-4～图4-5是示出在本实施例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。本处理是与利用者提示型的代码结算相关的处理的一例。
店铺读码器装置50的控制部51执行店铺结算处理，基于针对店铺读码器装置50的输入输出部52的操作，向控制部51输入规定的结算预定金额(作为非限定的例子，为“3，000日元”)。然后，店铺读码器装置50的控制部51使用读码器58，读取终端A的显示部24所显示的支付码(P100)。在该情况下，显示部24所显示的支付码与共同钱包支付令牌建立了关联，因此，在读码器58的读取结果中包括共同钱包支付令牌。
作为非限定的例子，店铺读码器装置50的控制部51通过通信I/F54向服务器10发送包括店铺ID、结算预定金额以及共同钱包支付令牌的结算请求信息(P110)。
在S120之后，当通过通信I/F14从店铺读码器装置50接收到结算请求信息时，服务器10的控制部11根据接受了请求的共同钱包支付令牌来检索共同钱包ID，针对该共同钱包，执行与由店铺ID决定的加盟店之间进行结算预定金额的支付的结算处理(S250a)。
在结算处理中结算成功的情况下(S260a：是)，服务器10的控制部11使处理进入S180a。
另一方面，在结算处理中结算失败的情况下(S260a：否)，服务器10的控制部11通过通信I/F14向终端A和店铺读码器装置50发送包括结算失败这一旨意和该情况下的共同钱包中的结算余额不足额的结算余额不足信息(S270a)。然后，服务器10的控制部11将处理移至S130。S130～S160的各步骤与图3-8是同样的。然后，服务器10的控制部11使处理进入S170a。
在A130之后，当通过通信I/F22从服务器10接收到结算余额不足信息时(A270a：是)，终端A的控制部21使接收到的结算余额不足信息显示于显示部24(A280)。
另外，终端A的控制部21使接收到的结算余额不足信息所包含的结算余额不足额存储于存储部28(A290)。然后，终端A的控制部21使处理移至A140。A140～A170的各步骤与图3-8是同样的。然后，终端A的控制部21通过通信I/F22从服务器10接收结算结果信息，使处理进入A180。
另一方面，在没有从服务器10接收到结算余额不足信息的情况下(A270a：否)，终端A的控制部21通过通信I/F22从服务器10接收结算结果信息，使处理进入A180。
在P110之后，当通过通信I/F54从服务器10接收到结算余额不足时(P120：是)，店铺读码器装置50的控制部51使结算余额不足信息显示于显示部53(P130)。然后，店铺读码器装置50的控制部51再次执行代码读取处理(P140)。然后，店铺读码器装置50的控制部51使处理进入P150。
另一方面，在没有从服务器10接收到结算余额不足信息的情况下(P120：否)，店铺读码器装置50的控制部51通过通信I/F54从服务器10接收结算结果信息，使处理进入P160。
需要说明的是，本实施例中的“显示了结算余额不足信息”的含义与第二实施例是同样的。
＜第四实施例的效果＞
第四实施例示出以下的结构：终端20通过控制部21基于自己的终端20的用户能够结算的帐户(不限定，第一帐户的一例)来执行与结算相关的处理。另外，终端20使结算余额不足信息(不限定，基于第一结算的金额和第一帐户的余额的、与第一帐户的余额不足相关的第一信息的一例)显示于显示部24。进而，终端20基于针对显示了结算余额不足信息的显示部24的输入，执行从自己的终端20的用户的用户帐户(不限定，与第一帐户不同的第二帐户的一例)向共同帐户转账的处理(不限定，与第一结算相关的处理的一例)。
作为通过这样的结构而得到的效果的一例，能够向终端的用户通知终端的用户能够结算的第一帐户的余额不足。另外，除了能够基于第一帐户实现结算之外，还能够至少基于与第一帐户不同的第二帐户而实现结算。
另外，第四实施例示出自己的终端20的用户能够结算的帐户是共同帐户(不限定，至少终端的用户和与终端的用户不同的第一用户能够结算的共同帐户的一例)的结构。
作为通过这样的结构而得到的效果的一例，能够基于至少终端的用户和与终端的用户不同的第一用户能够结算的共同帐户而实现结算。
另外，第四实施例示出基于针对显示了结算余额不足信息的显示部24的输入并基于共同帐户和自己的终端20的用户的用户帐户来执行与结算相关的处理的结构。
作为通过这样的结构而得到的效果的一例，能够至少基于共同帐户和第二帐户而实现结算。
另外，第四实施例示出在结算(不限定，第一结算的一例)时从共同钱包余额和自己的终端20的用户的用户帐户的电子钱币账户余额中的共同钱包余额(不限定，共同帐户的余额的一例)优先进行支付的结构。
作为通过这样的结构而得到的效果的一例，由于从共同帐户的余额优先进行支付，因此，能够将第二帐户作为随附的帐户。
另外，第四实施例示出从自己的终端20的用户的用户帐户向共同帐户转账并基于共同帐户的余额来进行结算的结构。
作为通过这样的结构而得到的效果的一例，能够从第二帐户向共同帐户转账来补充金额，并且能够基于共同帐户的余额进行结算。
另外，第四实施例示出在与结算相关的处理中基于由自己的终端20的用户针对自己的终端20进行的输入而从自己的终端20的用户的用户帐户向共同帐户转账的结构。
作为通过这样的结构而得到的效果的一例，终端的用户能够进行针对终端的输入，从第二帐户向共同帐户转账。
另外，第四实施例示出以下的结构：终端20基于由自己的终端20的用户针对显示了结算余额不足信息的显示部24进行的输入，将与自己的终端20的用户的用户帐户建立了关联的支付码(不限定，与第二帐户建立了关联的第一代码信息的一例)或者基于共同钱包读码器信息的、用于读取支付店铺码(不限定，代码信息的一例)的读码器画面(不限定，第一读码器信息的一例)显示于显示部24。进而，终端20基于支付码被读取或者基于通过在显示部24上显示了读码器画面的终端20来读取支付店铺码，执行与结算相关的处理。
作为通过这样的结构而得到的效果的一例，能够基于由终端的用户针对显示了第一信息的显示区域进行的输入，将与第二帐户建立了关联的第一代码信息或者作为与代码信息的读取相关的显示的读码器信息显示于终端的显示区域而用于结算。另外，能够基于第一代码信息被读取或者基于通过在显示区域显示了读码器信息的终端来读取代码信息，简单地实现结算。
另外，第四实施例示出第二帐户是自己的终端20的用户的用户帐户(不限定，终端的用户的帐户的一例)的结构。
作为通过这样的结构而得到的效果的一例，能够至少基于与第一帐户不同的终端的用户的帐户来实现结算。
另外，第四实施例示出基于显示部24所显示的支付码被通过店铺读码器装置50读取来执行与结算相关的处理的结构。
作为通过这样的结构而得到的效果的一例，能够基于显示区域所显示的代码信息被读取，简单地实现结算。
另外，第四实施例示出基于结算预定金额(不限定，第一结算的金额的一例)和共同钱包余额(不限定，共同帐户的余额的一例)、在共同钱包余额不足的情况下，从服务器10(不限定，执行第一结算的处理的服务器的一例)通过终端20的通信I/F22接收结算余额不足信息(不限定，第一信息的一例)的结构。
作为通过这样的结构而得到的效果的一例，在共同帐户的余额不足的情况下，能够从执行第一结算的处理的服务器简单地取得第一信息。
另外，第四实施例示出以下的结构：服务器10基于一个终端20的用户能够结算的帐户(不限定，终端的用户能够结算的第一帐户的一例)，通过控制部11来执行结算处理(不限定，与第一结算相关的处理的一例)。另外，服务器10通过通信I/F14向一个终端20发送结算余额不足信息(不限定，基于第一结算的金额和第一帐户的余额的、与第一帐户的余额不足相关的第一信息的一例)。然后，服务器10基于由一个终端20的用户针对该终端20的显示部24所显示的结算余额不足信息进行的输入，至少基于该终端20的用户的用户帐户(不限定，与第一帐户不同的第二帐户的一例)，通过控制部11来执行结算处理。
作为通过这样的结构而得到的效果的一例，能够向终端通知终端的用户能够结算的第一帐户的余额不足。另外，除了能够基于第一帐户进行结算之外，还能够至少基于与第一帐户不同的第二帐户进行结算。
需要说明的是，与上述同样，作为非限定的例子，一个终端20的用户能够结算的帐户能够为共同帐户(不限定，至少终端的用户和与终端的用户不同的第一用户能够结算的共同帐户的一例)。
＜第四变形例(1)＞
在第四实施例中，在选择了从用户A.A的电子钱币账户向共同钱包转账的情况下(图4-4的A140：是)，终端A的控制部21使促使输入转账额的画面显示于显示部24，但不限定于此。
作为非限定的例子，终端A的控制部21也可以将在图4-4的A290中存储的结算余额不足额设定为转账额，向服务器10发送转账委托信息，还可以不采用这种方式。
＜第四变形例(2)＞
在第四实施例中，店铺读码器装置50的控制部51在使结算结果信息显示于显示部53后(图4-4的P130)，再次执行代码读取处理，向服务器10发送结算请求信息，但不限定于此。
作为非限定的例子，也可以是，服务器10的控制部11在图4-4的S130中接收到转账委托信息的情况下(S130：是)向终端20发送用户帐户信息时(图4-4的S160)，即便没有从店铺读码器装置50接收到结算请求信息，也基于在图4-4的S250a的结算处理中使用的结算请求信息，执行图4-5的S170a的结算处理，还可以不执行该结算处理。
在该情况下，店铺读码器装置50的控制部51在图4-4的P130的步骤之后通过通信I/F54从服务器10接收结算结果信息，执行图4-5的P160的步骤。
＜第四变形例(3)＞
在第四实施例中，针对利用者提示型的代码结算进行了说明，但不限定于此。具体而言，也可以为店铺提示型的代码结算。
＜显示画面例＞
图4-6是示出在从图3-9的读码器画面进行了代码支付的情况下并且是在共同钱包余额不足的情况下显示的共同钱包余额不足画面的一例的图。
图4-6与图4-1的不同点在于，共同钱包余额不足信息显示/操作区域2427的背景为读码器画面。
在图4-6中，在为了从自己的钱包余额转账“2，000日元”而对转账按钮242E进行了触摸操作时，与图3-11同样地显示支付金额输入画面。这里，在与图3-11同样地输入“3，000日元”并对支付按钮242C进行了触摸操作时，与图4-3同样地显示代码支付完成画面。
＜处理＞
图4-7～图4-8是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理的一例。
在A130之后，终端A的控制部21使用相机27读取由加盟店所提示的支付店铺码，从支付店铺码取得店铺ID(A300)。
之后，终端A的控制部21使用于输入结算预定金额的显示画面显示于显示部24。当基于针对终端A的输入输出部23的用户操作而输入了结算预定金额时，作为非限定的例子，控制部21通过通信I/F22向服务器10发送包括共同钱包读码器信息所包含的共同钱包支付令牌、店铺ID以及结算预定金额的结算请求信息(A310)。
需要说明的是，在支付店铺码包含结算预定金额的情况下，能够省略终端A中的结算预定金额的输入。
当通过通信I/F14从终端A接收到结算请求信息时，服务器10的控制部11根据接受了请求的共同钱包支付令牌来检索共同钱包ID，针对该共同钱包，执行与由店铺ID决定的加盟店之间进行结算预定金额的支付的结算处理(S250b)。
在S250b中结算成功的情况下(S260b：是)，服务器10的控制部11使处理移至S180b。
在S250b中结算失败的情况下(S260b：否)，服务器10的控制部11通过通信I/F14向终端A发送包括结算失败这一旨意和该情况下的共同钱包中的结算余额不足额的结算余额不足信息(S270b)。然后，服务器10的控制部11使处理移至S130。另外，在S160之后，服务器10的控制部11从终端A接收结算请求信息，使处理移至S170b。
终端A的控制部21在通过通信I/F22从服务器10接收到结算余额不足信息时(A270b：是)，使结算余额不足信息显示于显示部24(A280)，使结算余额不足额存储于存储部28(A290)。然后，终端A的控制部21使处理移至A140。另外，终端A的控制部21在A170之后使处理移至A190。
需要说明的是，也可以与第四变形例(1)同样地在选择了从用户A.A的电子钱币账户向共同钱包转账的情况下(图4-7的A140：是)，终端A的控制部21将在图4-7的A290中存储的结算余额不足额设定为转账额，向服务器10发送转账委托信息，还可以不采用这种方式。
本变形例示出基于由终端20进行的支付店铺码的读取来执行与结算相同的处理的结构。
作为通过这样的结构而得到的效果的一例，能够基于由终端进行的代码信息的读取，简单地实现结算。
＜第四变形例(4)＞
在第四变形例(3)中，终端A的控制部21在使结算余额不足信息显示于显示部53后(图4-7的A280)，再次执行代码读取处理(图4-8的A190)，向服务器10发送结算请求信息，但不限定于此。
作为非限定的例子，终端A的控制部21也可以在更新用户帐户信息后(图4-7的A170)，基于在图4-7的A310中发送的结算请求信息，向服务器10发送图4-8的A200的结算请求信息。
＜第四变形例(5)＞
在第四实施例中，在加盟店的支付中，即便在通过从终端A的用户A.A的电子钱币账户转账而垫付了共同钱包的余额不足的情况下，也不向共同钱包的其他用户(作为非限定的例子为用户B.B)请求垫付部分，但也可以请求该垫付部分，还可以不采用这种方式。
图4-9是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、终端B(作为非限定的例子，为用户B.B的终端20)的控制部21所执行的结算联合处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
需要说明的是，关于处理的前半部分，作为非限定的例子而能够通过与图4-4、图4-5相同的处理来实现，因此，这里省略说明。
终端A的控制部21在显示结算结果信息时(A180)，使是否进行垫付部分的细算(清算)的选择用画面显示于显示部24(A320)。
需要说明的是，在终端A的存储部28所存储的结算余额不足额为“0”的情况下或者在结算失败的情况下，无需进行细算(A320：否)，因此，也可以不使选择用画面显示于显示部24而结束处理，还可以不采用这种方式。
另外，在终端A的存储部28所存储的结算余额不足额大于“0”且结算成功的情况下，也可以不使选择用画面显示于显示部24而自动地进行细算(A320：是)，还可以不采用这种方式。
在基于针对终端A的输入输出部23的用户操作而选择了进行细算的情况下(A320：是)，终端A的控制部21通过通信I/F22向服务器10发送终端A的存储部28所存储的结算余额不足额(A330)。
另一方面，在选择了不进行细算的情况下(A320：否)，终端A的控制部21结束处理。
服务器10的控制部11在发送结算结果信息(S180a)并通过通信I/F14从终端A接收到结算余额不足额时，判定结算余额不足额是否大于“0”(S280)。
在接收到的结算余额不足额为“0”或者没有接收到结算余额不足额的情况下(S280：否)，判断为没有成为结算余额不足或者不需要细算，服务器10的控制部11结束处理。
在接收到的结算余额不足额大于“0”的情况下(S280：是)，作为非限定的例子，服务器10的控制部11在将结算余额不足额设为“M”且将共同钱包成员的用户数(共同钱包的构成用户数)设为“N”时，计算“M÷N”作为向共同钱包的各构成用户的支付垫付额。然后，服务器10的控制部11通过通信I/F14，向除了共同钱包的垫付者之外的各构成用户的终端(这里为终端B)发送包括支付垫付额的支付垫付额请求信息(S290)。
终端B的控制部21在通过通信I/F22从服务器10接收到支付垫付额请求信息时(B100：是)，使接收到的支付垫付额与是否响应于支付垫付额的请求的选择用画面显示于显示部24(B110)。需要说明的是，终端B的控制部21在没有接收到支付垫付额请求信息的情况下(B100：否)，结束处理。
在基于针对终端B的输入输出部23的用户操作而选择了响应于支付垫付额的请求的情况下(B110：是)，终端B的控制部21通过通信I/F22向服务器10发送用于委托支付垫付额的细算的细算委托信息(B120)。
在基于针对终端B的输入输出部23的用户操作而选择了不响应于支付垫付额的请求的情况下(B110：否)，终端B的控制部21结束处理。
在通过通信I/F14从终端B接收到细算委托信息的情况下(S300：是)，服务器10的控制部11执行细算转账处理(S310)。
另一方面，在没有接收到细算委托信息的情况下(S300：否)，服务器10的控制部11使处理移至S330。
在细算转账处理中，首先从终端B的用户B.B的电子钱币账户向共同钱包转账支付垫付额。当除了垫付者之外的各构成用户的转账完成后，从共同钱包向终端A的用户A.A的电子钱币账户转账通过“(N-1)×支付垫付额”而计算出的支付者负担额。然后，服务器10的控制部11通过通信I/F14向共同钱包的各构成用户的终端(这里为终端B)发送包括转账结果的细算委托结果信息(S320)。
需要说明的是，也可以是，在S290中针对两个以上的终端发送支付垫付额请求信息的情况下，服务器10的控制部11除非从发送的全部的终端接收到细算委托信息，否则不执行细算转账处理，还可以不采用这种方式。
另外，在细算转账处理中，也可以不经由共同钱包而在用户的电子钱币账户之间进行转账，还可以不采用这种方式。
最后，服务器10的控制部11通过通信I/F14向作为垫付者的用户A.A的终端A发送包括转账结果的细算结果信息(S330)，结束处理。
当通过通信I/F22从服务器10接收到细算委托结果信息时，终端B的控制部21使细算委托结果信息显示于显示部24(B130)，结束处理。
另外，当通过通信I/F22从服务器10接收到细算结果信息时，终端A的控制部21使细算结果信息显示于显示部24(A340)，结束处理。
本变形例示出以下的结构：基于终端20的用户B.B的输入，执行基于支付垫付额请求信息的、向共同钱包的转账处理。在在共同钱包中包括通过由用户A.A进行的结算(不限定，第一结算的一例)而从用户A.A的终端20的用户帐户支付的金额以上或者比该金额多的金额的情况下，从共同钱包向用户A.A的帐户(不限定，第一帐户的一例)转账通过由用户A.A进行的结算而从用户A.A的用户帐户支付的金额。
作为通过这样的结构而得到的效果的一例，在在共同帐户中包括通过第一结算而从第一帐户支付的金额以上或者比该金额多的金额的情况下，能够从共同帐户向第一帐户转账通过第一结算而从第一帐户支付的金额。
＜第四变形例(6)＞
在第四实施例中，终端A的控制部21在选择了从用户A.A的电子钱币账户向共同钱包转账的情况下，基于所选择的时间点的用户A.A的电子钱币账户向服务器10发送了转账委托信息，但不限定于此。
＜显示画面例＞
图4-10是示出在图3-3的露营资金支付画面中由终端20的用户A.A对表示为“代码支付”的图标进行了触摸操作的情况下显示的代码支付画面(转账前)的一例的图。
图4-10与图3-4的不同之处在于，在露营资金代码支付区域2421内在“从自己的钱包转账”的文字的横侧显示的自己的电子钱币账户余额(在该例中为“1，000日元”)的金额。
图4-11是示出在图4-10所示的代码支付画面中利用支付码进行了代码支付的情况下并且是在共同钱包余额不足的情况下显示的共同钱包余额不足画面的一例的图。
图4-11与图4-1的不同之处在于，在共同钱包余额不足信息显示/操作区域2427中在“从自己的钱包转账”的文字的横侧显示的自己的电子钱币账户余额(在该例中为“1，000日元”)的金额。在该例中，结算预定金额为“3，000日元”，与此相对，露营资金的共同钱包余额为“1，000日元”，缺少“2，000日元”。因此，选择是否从自己的钱包余额转账不足部分的“2，000日元”。
图4-12是示出在图4-11所示的共同钱包余额不足画面中对转账按钮242E进行了触摸操作的情况下显示的自己的钱包余额不足画面的一例的图。
图4-12与图4-11中的共同钱包余额不足信息显示/操作区域2427是同样的，但不同之处在于，显示有在机器人的下方显示的“自己的钱包的余额不足”的文字、以及显示有“向自己的钱包充值？”的引导文。另外，不同之处在于，在共同钱包余额不足信息显示/操作区域2427下部，显示有为了弥补余额不足而用于执行不足金额的充值的充值按钮242G。另外，在充值按钮242G的下方，显示有用于不执行充值的作为非限定的例子而表示为“现在不这样做”的取消按钮242H。
在图4-12中，当为了向自己的钱包充值而对充值按钮242G进行了触摸操作时，作为非限定的例子而显示与图3-14同样的充值画面。然后，在该充值画面中能够充入所希望的金额。
在该例中，通过向自己的钱包充入“1，000日元”，从而自己的钱包余额成为“2，000日元”，能够弥补上述的不足部分。
需要说明的是，在该情况下，也能够如第四变形例(5)中说明的那样，向其他用户(作为非限定的例子为用户B.B)请求用户A.A通过支付而垫付的部分的金额。
图4-13与图4-2同样，是示出在由服务器10完成了代码支付的情况下显示于终端20的代码支付完成画面的一例的图。
图4-13与图3-7的不同之处在于，在代码支付完成画面下部显示有支付历史确认按钮242J和垫付部分请求按钮242K。
图4-14是示出在图4-13的代码支付完成画面中对垫付部分请求按钮242K进行了触摸操作的情况下为了对作为垫付部分的请求对方的用户B.B进行垫付部分的请求而显示的通知画面的一例的图，其中，该用户B.B是共同钱包的露营资金的成员。
在图4-14中，在该应用画面中，作为非限定的例子，在最上层的标题栏显示有支付应用的应用名即“Payment App”，在“Payment App”的横侧显示有用户B.B的图标图像和用户名“B.B”的文字。在标题栏的下方显示有“通知”文字作为“Payment App”的分层菜单中的当前位置。
在“通知”的文字的下方显示有指代通知的铃铛的图标图像，在铃铛的横侧的上下层内，在上层显示有“共同钱包：露营资金”的文字作为件名，并且在下层显示有“从A.A先生/女士收到垫付部分的请求”的文字作为其内容。在“从A.A先生/女士收到垫付部分的请求”的下方，显示有表示通知日的“今日”的文字，在“今日”的下方显示有露营资金通知显示区域2429。
在露营资金通知显示区域2429中，在上层与表示是共同钱包的方形钱包的图像一起显示有该共同钱包的名称(在该例中为“露营资金”)。另外，在“露营资金”的横侧显示有“2020年4月11日16时35分”作为通知日期时间，在通知日期时间的下方显示有共同使用该共同钱包的用户A.A和用户B.B的图标图像。
另外，在露营资金的下方，显示有“垫付部分请求金额”的文字作为垫付部分的请求金额(以下称为“垫付部分请求金额”。)，在“垫付部分请求金额”的下方显示有该露营资金的共同钱包余额(在该例中为“1，000日元”)。在露营资金通知显示区域2429的下层，显示有“关闭详细内容”的文字，在“关闭详细内容”的下方，与作为支付金额的转账对方的AA运动株式会社的标志图像一起显示有其公司名“AA运动株式会社”的文字作为垫付部分请求金额的详细信息。另外，在横侧，显示有“2020年4月11日16时30分”作为转账日期时间，在转账日期时间的下方显示有“3，000日元”作为支付金额。
另外，在“AA运动株式会社”的下方，显示有“支付明细”的文字，在“支付明细”的下方，与方形钱包的图像及共同钱包的名称(露营资金)一起显示有该露营资金的共同钱包余额(在该例中为“1，000日元”)。在“露营资金”的下方，显示有袋状钱包的图像和“A.A先生/女士的垫付”的文字，并且显示有垫付额(在该例中为“2，000日元”)。另外，在它们的下方，与共同钱包成员的图标图像一起显示有“共同钱包的成员”的文字，作为人数在该例中显示有“2人”。
另外，在该例中，在露营资金通知显示区域2429的下部，并排地显示有用于执行补填余额不足用的金额的转账的转账按钮242L和用于稍后进行转账的稍后按钮242M。另外，在这两个按钮的下方，显示有用于返回菜单的菜单按钮242N。
图4-15是示出在图4-13的代码支付完成画面中对支付历史确认按钮242J进行了触摸操作的情况下显示的支付历史画面的一例的图。
在图4-15中，按照时间序列的升序分层显示有支付历史。
在支付历史的第一层，显示为“2020年4月5日11时12分”作为支付日期时间，在支付日期时间的下方显示有“EE超市”的文字作为支付对方，在该例中显示有“5，000日元”作为支付金额。
在支付历史的第二层，显示为“2020年4月11日16时30分”作为支付日期时间，在支付日期时间的横侧，显示有“垫付部分请求(2，000日元)”被反相显示的垫付部分请求图标242k作为垫付部分。垫付部分请求图标242k是具有与垫付部分请求按钮242K同样的功能的图标，当被触摸操作后转移到图4-14。另外，在它们的下方，显示有“AA运动株式会社”作为支付对方，并且显示有“3，000日元”作为支付金额。
需要说明的是，在上述的例子中，能够使表示请求了垫付部分的信息显示于请求方的用户的终端20的显示部24，或者使表示请求了垫付部分的信息显示于请求对方的用户的终端20的显示部24。
在该情况下，这些信息也可以显示于支付应用的应用画面，但取而代之，也能够显示于上述的消息收发应用的谈话室画面。
图4-16是示出基于在图4-13的代码支付完成画面中对垫付部分请求按钮242K进行了操作而显示于用户A.A的终端20(终端A)的显示部24的消息收发应用的谈话室画面的一例的图。
通过终端A的用户(用户A.A)向终端B的用户(用户B.B)进行了垫付部分的请求，从而将表示这一旨意的消息从消息收发管理服务器10B发送到终端A，并显示于用于用户A.A与用户B.B进行谈话的谈话室(将用户B.B作为谈话对象的谈话室)。在该例中，面对画面在右侧，以吹出对话框的形式显示有包括向用户B.B请求了垫付部分以及其详细信息的第一垫付部分请求消息2433作为以用户A.A为发送源的消息。
图4-17是示出基于在图4-13的代码支付完成画面中对垫付部分请求按钮242K进行了操作而显示于用户B.B的终端20(终端B)的显示部24的消息收发应用的谈话室画面的一例的图。
通过从终端A的用户(用户A.A)对终端B的用户(用户B.B)进行了垫付部分的请求，从而将表示这一旨意的消息从消息收发管理服务器10B发送到终端B并显示于与用户A.A进行谈话的谈话室。在该例中，面对画面在左侧，以吹出对话框的形式显示有包括从用户A.A向用户B.B请求了垫付部分以及其详细信息的第二垫付部分请求消息2434作为以用户A.A为发送源的消息。
＜处理＞
图4-18是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
在选择了从用户A.A的电子钱币账户向共同钱包转账时(A140：是)，终端A的控制部21基于在A290中存储的结算余额不足额和在A130中显示的用户帐户信息，判定用户A.A的电子钱币账户余额是否少于结算余额不足额(A350)。
在用户A.A的电子钱币账户余额为结算余额不足额以上的情况下(A350：否)，终端A的控制部21使处理移至A150。
在电子钱币账户余额不足的情况下(A350：是)，终端A的控制部21执行A210～A230的步骤。因此，在该情况下，服务器10的控制部11在执行S270a的步骤后，执行S190～S210的步骤。
需要说明的是，在A210的步骤中，在没有选择向帐户进行充值的情况下(A210：否)，终端A的控制部21也可以返回到A140执行处理，还可以不这样进行。
本变形例示出以下的结构：终端20基于结算预定金额(不限定，第一结算的金额的一例)、共同钱包余额(不限定，共同帐户的余额的一例)以及自己的终端20的用户的用户帐户(不限定，第二帐户的一例)，将结算余额不足信息(不限定，基于第一结算的金额、共同帐户的余额以及第二帐户的、与共同帐户的余额不足相关的第二信息的一例)显示于显示部24。进而，终端20基于由自己的终端20的用户针对显示了结算余额不足信息的显示部24进行的输入，通过控制部21来执行向自己的终端20的用户的用户帐户的电子钱币账户进行充值的处理(不限定，向第二帐户转账的处理的一例)。
作为通过这样的结构而得到的效果的一例，能够向终端的用户通知共同帐户的余额不足。另外，能够基于由终端的用户进行的输入，向第二帐户转账。
另外，本变形例示出以下的结构：终端20基于结算预定金额(不限定，第一结算的金额的一例)、共同钱包余额(不限定，共同帐户的余额的一例)、以及自己的终端20的用户的用户帐户(不限定，第二帐户的一例)，将结算余额不足信息(不限定，基于共同帐户的余额和第二帐户的余额、与共同帐户和第二帐户的余额不足相关的第一信息的一例)显示于显示部24。进而，终端20基于由自己的终端20的用户针对显示了结算余额不足信息的显示部24进行的输入，通过控制部21来执行向自己的终端20的用户的用户帐户的电子钱币账户进行充值的处理(不限定，向第二帐户转账的处理的一例)。
作为通过这样的结构而得到的效果的一例，能够向终端的用户通知共同帐户与第二帐户的余额不足。另外，能够基于由终端的用户针对第一信息进行的输入，向第二帐户转账。
＜第四变形例(7)＞
在第四实施例中，选择是否从执行结算处理的终端(作为非限定的例子为终端A)的用户(作为非限定的例子为用户A.A)的电子钱币账户向共同钱包转账，但转账方的电子钱币账户不限定于此。
作为非限定的例子，也可以从构成共同钱包的其他成员(作为非限定的例子为用户B.B)的电子钱币账户进行转账。
图4-19是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、终端B(作为非限定的例子，为用户B.B的终端20)的控制部21所执行的结算联合处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
需要说明的是，关于处理的后半部分，作为非限定的例子而能够与图4-5相同，因此，这里省略说明。
在A290之后，作为非限定的例子，终端A的控制部21将具有是否从作为共同钱包成员的其他用户(作为非限定的例子为用户B.B)的电子钱币账户向共同钱包委托转账的选择功能的按钮加入到显示部24中进行显示。然后，终端A的控制部21基于针对终端A的输入输出部23的用户操作，判定是否选择了从其他用户(作为非限定的例子为用户B.B)的电子钱币账户向共同钱包委托转账(A360)。
在选择了从用户B.B的电子钱币账户向共同钱包委托转账的情况下(A360：是)，终端A的控制部21通过通过通信I/F22向服务器10发送包括委托转账和作为非限定的例子而与结算余额不足额相等的金额的转账申请额的转账申请信息(A370)。
在没有选择从用户B.B的电子钱币账户向共同钱包委托转账的情况下(A360：否)，终端A的控制部21通过通信I/F22从服务器10接收结算结果信息，执行图4-5的A180的步骤。
在通过通信I/F14从终端A接收到转账申请信息的情况下(S340：是)，服务器10的控制部11通过通信I/F14向终端B发送包括转账申请额的转账确认信息(S350)。
在没有接收到转账申请信息的情况下(S340：否)，服务器10的控制部11通过通信I/F14从店铺读码器装置50接收结算请求信息，执行图4-5的S170a的步骤。
在通过通信I/F22从服务器10接收到转账确认信息的情况下(B140：是)，终端B的控制部21基于转账确认信息，使是否认可从用户B.B的电子钱币账户向共同钱包转账的选择用画面显示于显示部24(B150)。
另一方面，在没有接收到转账确认信息的情况下(B140：否)，终端B的控制部21结束处理。
在基于针对终端B的输入输出部23的用户操作而选择了认可向共同钱包转账的情况下(B150：是)，终端B的控制部21通过通信I/F22向服务器10发送转账委托信息(B160)。
另一方面，在选择了不认可向共同钱包转账的情况下(B150：否)，终端B的控制部21结束处理。
在通过通信I/F14从终端B接收到转账委托信息的情况下(S360：是)，服务器10的控制部11执行从用户B.B的电子钱币账户向共同钱包对转账申请额进行转账的转账处理(S370)。然后，作为非限定的例子，服务器10的控制部11通过通信I/F14向终端B发送包括转账处理的成功与否和转账后的用户B.B的电子钱币账户余额的转账委托结果信息(S380)。
接着，服务器10的控制部21通过通信I/F14向终端A发送包括转账后的共同钱包余额的共同钱包信息(S390)。
在没有从终端B接收到转账委托信息的情况下(S360：否)，服务器10的控制部11通过通信I/F14向终端A发送包括共同钱包余额的共同钱包信息(S390)。
需要说明的是，在该情况下，也可以将表示转账申请被终端B拒绝的信息组入到共同钱包信息中进行发送，还可以不采用这种方式。
接着，服务器10的控制部11通过通信I/F14从店铺读码器装置50接收结算请求信息，执行S170a的步骤。
当通过通信I/F22从服务器10接收到转账委托结果信息时，终端B的控制部21使转账委托结果信息显示于显示部24(B170)，结束处理。
当通过通信I/F22从服务器10接收到共同钱包信息时，终端A的控制部21基于接收到的共同钱包信息，作为非限定的例子而将共同钱包余额更新并显示于显示部24(A380)。
需要说明的是，在表示转账申请被终端B拒绝的信息包含在共同钱包信息中的情况下，作为非限定的例子，使这一旨意以弹出窗口等的形式显示于显示部24，还可以不采用这种方式。
接着，终端A的控制部21通过通信I/F22从服务器10接收结算结果信息，执行A180的步骤。
需要说明的是，在上述的处理中，作为非限定的例子，终端20的控制部21也可以基于由自己的终端20的用户(作为非限定的例子为用户A.A)进行的至少包括自己的终端20的用户和其他用户(作为非限定的例子为用户B.B)在内的谈话室(不限定，聊天室的一例)的选择，来选择从其他用户(作为非限定的例子为用户B.B)的电子钱币账户向共同钱包委托转账，还可以不采用这种方式。
在该情况下，作为非限定的例子，能够使与图3-21所说明的消息收发应用中的成员选择画面(谈话室选择画面)同样的画面显示于终端20的显示部24，使用户选择委托转账的谈话室。
本变形例示出第二帐户是与自己的终端20的用户不同的用户(不限定，第一用户的一例)的用户帐户的结构。
作为通过这样的结构而得到的效果的一例，能够至少基于与终端的用户不同的第一用户的帐户来实现结算。
另外，本变形例示出基于由自己的终端20的用户针对自己的终端20进行的输入来选择与自己的终端20的用户不同的用户的用户帐户(不限定，第二帐户的一例)的结构。
作为通过这样的结构而得到的效果的一例，能够基于由终端的用户针对终端进行的输入而简单地选择第二帐户。
另外，本变形例示出基于由自己的终端20的用户进行的包括自己的终端20的用户和其他用户(不限定，第一用户的一例)在内的聊天室的选择来选择与自己的终端20的用户不同的用户的用户帐户(不限定，第二帐户的一例)的结构。
作为通过这样的结构而得到的效果的一例，能够基于包括终端的用户和第一用户的聊天室的选择而简单地选择第二帐户。
另外，本变形例示出以下的结构：终端20通过通信I/F22向与自己的终端20不同的终端20发送转账申请信息(不限定，与委托许可基于第二帐户的结算相关的信息的一例)。进而，基于与自己的终端20的用户不同的用户(不限定，第一用户的一例)许可通过该用户的帐户(不限定，第二帐户的一例)进行结算来执行与结算相关的处理。
作为通过这样的结构而得到的效果的一例，能够基于由第一用户进行了许可通过第二帐户进行结算而使结算成为可能。反之，在没有由第一用户进行了许可通过第二帐户进行结算的情况下，不能够进行结算。
＜第四变形例(8)＞
在第四变形例(7)中，在加盟店的支付中，即便在通过委托从共同钱包的其他用户(作为非限定的例子为用户B.B)的电子钱币账户进行转账而垫付了共同钱包的余额不足的情况下，自身也不会被请求垫付部分，但也可以被请求垫付部分，还可以不采用这种方式。
图4-20～图4-21是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、终端B(作为非限定的例子，为用户B.B的终端20)的控制部21所执行的结算联合处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
需要说明的是，关于处理的前半部分，作为非限定的例子而能够与图4-19相同，因此这里省略说明。
终端A的控制部21在显示结算结果信息时(A180)，使是否进行垫付部分的细算的选择用画面显示于显示部24(A320)。
在选择了进行细算的情况下(A320：是)，终端A的控制部21通过通信I/F22向服务器10发送终端A的存储部28所存储的结算余额不足额(A330)，然后使处理移至A400。
另一方面，在选择了不进行细算的情况下(A320：否)，终端A的控制部21结束处理。
服务器10的控制部11在通过通信I/F14从终端A接收到的结算余额不足额大于“0”的情况下(S280：是)，向垫付者的终端20(这里为终端B)发送结算余额不足额(S400)。
在通过通信I/F22从服务器10接收到结算余额不足额的情况下(B180：是)，终端B的控制部21使是否向共同钱包的其他成员请求终端B的用户B.B所垫付的结算余额不足额部分的电子钱币的选择用画面显示于显示部24(B190)。
另一方面，在没有接收到结算余额不足额的情况下(B180：否)，终端B的控制部21结束处理。
在基于针对终端B的输入输出部23的用户操作而选择了请求垫付部分的情况下(B190：是)，终端B的控制部21通过通信I/F22向服务器10发送细算请求信息(B200)。
另一方面，在选择了不请求垫付部分的情况下(B190：否)，终端B的控制部21跳过B200而进行处理。
在通过通信I/F14从终端B接收到细算请求信息的情况下(S410：是)，服务器10的控制部11执行S420～S450的步骤。
需要说明的是，这些步骤能够将发送对方/接收方设为终端A并与图4-9的S290～S320同样地执行，因此，省略详细的说明。
在没有接收到细算请求信息的情况下(S410：否)，服务器10的控制部11使处理移至S460的步骤。
终端A的控制部21在通过通信I/F22从服务器10接收到支付垫付额请求信息时(A400：是)，执行A410～A440的步骤。
需要说明的是，这些步骤能够与图4-9的B110～B130的步骤同样地执行，因此省略详细的说明。
在没有接收到支付垫付额请求信息的情况下(A400：否)，终端A的控制部21通过通信I/F22从服务器10接收细算结果信息，执行A340的步骤。
最后，服务器10的控制部11通过通信I/F14向作为垫付者的用户B.B的终端B和提出了细算的用户A.A的终端A发送包括转账结果的细算结果信息(S460)，结束处理。
另外，当通过通信I/F22从服务器10接收到细算结果信息时，终端B的控制部21使细算结果信息显示于显示部24(B210)，结束处理。
终端A也是同样的(A340)。
需要说明的是，在上述的处理中，终端B从自己的终端20的用户(用户B.B)的用户帐户垫付了结算余额不足额部分的电子钱币，但不限定于此。
作为非限定的例子，终端B也可以从作为共同钱包成员并且是用户A.A和用户B.B以外的用户(作为非限定的例子，为终端C的用户C.C)的用户帐户使用(消费)结算余额不足额部分的电子钱币来进行结算。在该情况下，用户B.B预先从用户C.C获得许可即可。
另外，在发送了细算请求信息的情况下(B200)，作为非限定的例子，终端B的控制部21能够使表示请求了垫付部分的信息显示于终端B的显示部24。
另外，在接收到支付垫付额请求信息的情况下(A400：是)，终端A的控制部21能够使表示请求了垫付部分的信息显示于终端A的显示部24。
在该情况下，也可以使这些信息显示于支付应用的应用画面，但取而代之，也能够显示于上述的消息收发应用的谈话室画面。作为非限定的例子，这些画面能够仿效图4-16、图4-17所示的画面同样地构成。
本变形例示出以下的结构：第二终端20(请求对方的终端20)经由服务器10从第一终端20(请求方的终端20)通过通信I/F22接收支付垫付额请求信息(不限定，与金额的请求相关的请求信息的一例，其中金额基于通过第二帐户进行的支付)。然后，第二终端20使基于接收到的支付垫付额请求信息的显示(不限定，基于请求信息的第一显示、第三显示的一例)显示于显示部24。
作为通过这样的结构而得到的效果的一例，能够向终端的用户通知存在基于通过第二帐户进行的支付的金额的请求以及其内容。
另外，本变形例示出以下的结构：第一终端20经由服务器10通过通信I/F22向第二终端20发送支付垫付额请求信息(不限定，与金额的请求相关的请求信息的一例，其中金额基于通过第二帐户进行的支付)。然后，第一终端20使基于所发送的支付垫付额请求信息的显示(不限定，基于请求信息的第二显示的一例)显示于显示部24。
作为通过这样的结构而得到的效果的一例，能够在请求了基于通过第二帐户进行的支付的金额的基础上，向终端的用户通知与该请求相关的信息。
另外，本变形例示出以下的结构：第二终端20基于至少第二终端20的用户与第一终端20的用户(不限定，第一用户的一例)能够结算的共同帐户、以及第一终端20的用户的用户帐户(不限定，第一帐户的一例)，通过第一终端20(不限定，第一终端的一例)来执行与结算相关的处理(不限定，与第一结算相关的处理的一例)，基于由第一终端20的用户进行的结算(不限定，第一结算的一例)，经由服务器10通过通信I/F22从第一终端20接收支付垫付额请求信息(不限定，与基于第一结算的金额的请求相关的请求信息的一例)。进而，第二终端20使基于接收到的支付垫付额请求信息的显示(不限定，基于请求信息的第一显示的一例)显示于显示部24。
作为通过这样的结构而得到的效果的一例，基于至少终端的用户和与终端的用户不同的第一用户能够结算的共同帐户以及与共同帐户不同的第一帐户，通过第一用户的第一终端来执行与第一结算相关的处理，基于此，能够接受基于第一结算的金额的请求，向终端的用户通知与该请求相关的信息。
另外，本变形例示出第一帐户是第一终端20的用户(不限定，第一用户的一例)的用户帐户的结构。
作为通过这样的结构而得到的效果的一例，能够基于至少终端的用户和与终端的用户不同的第一用户能够结算的共同帐户以及第一用户的帐户，通过第一用户的第一终端来执行与第一结算相关的处理。
另外，本变形例示出以下的结构：基于由第一终端20的用户的用户帐户垫付的金额(不限定，由第一帐户支付的金额的一例)来决定支付垫付额请求信息。进而，第二终端20通过控制部21来执行从自己的终端20的用户的用户帐户对第一终端20的用户的用户帐户的转账处理(不限定，与基于请求信息的金额的转账相关的处理的一例)。
作为通过这样的结构而得到的效果的一例，能够从终端的用户的帐户向第一帐户转账基于请求信息的金额，该请求信息是基于由第一帐户支付的金额决定的。
另外，本变形例示出基于共同钱包成员(不限定，能够通过共同帐户进行结算的用户的一例)而决定支付垫付额请求信息中的金额的结构。
作为通过这样的结构而得到的效果的一例，能够接受基于请求信息的金额的请求，向终端的用户通知与该请求相关的信息，其中该请求信息是基于能够通过共同帐户进行结算的用户而决定的。
另外，本变形例示出终端20在能够与共同钱包成员进行消息等(不限定，内容的一例)的收发的谈话室(不限定，聊天室的一例)中显示支付垫付额请求信息的结构。
作为通过这样的结构而得到的效果的一例，能够以向聊天室的显示这样的容易理解的形式将与请求相关的信息通知给终端的用户，该聊天室可与能够通过共同帐户进行结算的用户进行内容的收发。
另外，本变形例示出基于针对转账按钮等(不限定，转账信息的一例)的操作(不限定，针对转账信息的用户的输入的一例)来执行基于支付垫付额请求信息的转账处理的结构。
作为通过这样的结构而得到的效果的一例，能够基于针对转账信息的用户的输入而简单地实现转账，该转账信息用于进行基于请求信息的转账。
另外，本变形例示出基于支付垫付额请求信息的显示包括第一终端20的用户的信息的结构。
作为通过这样的结构而得到的效果的一例，能够向终端的用户通知第一帐户的用户的信息。
另外，本变形例示出以下的结构：基于共同帐户和第二终端20的用户的用户帐户(不限定，第二帐户的一例)，执行与结算相关的处理(不限定，与第二结算相关的处理的一例)。进而，第二终端20经由服务器10通过通信I/F22从第一终端20接收基于由第一终端20的用户进行的结算(不限定，第一结算的一例)和由第二终端20的用户进行的结算(不限定，第二结算的一例)的支付垫付额请求信息。进而，第二终端20通过控制部21来执行从自己的终端20的用户的用户帐户向第一终端20的用户的用户帐户的转账处理(不限定，与基于请求信息的金额的转账相关的处理的一例)。
作为通过这样的结构而得到的效果的一例，能够基于共同帐户和与共同帐户不同的第二帐户，执行与第二结算相关的处理，接受基于第一结算和第二结算的请求，从终端的用户的帐户向第一帐户进行转账。
另外，本变形例示出从服务器10(不限定，执行与第一结算相关的处理的服务器的一例)发送支付垫付额请求信息(不限定，与基于第一结算的金额的请求相关的请求信息的一例)的结构。
作为通过这样的结构而得到的效果的一例，能够从执行与第一结算相关的处理的服务器简单地取得请求信息。
另外，本变形例示出第一帐户是如下的用户帐户的结构，即：是能够通过共同帐户结算的、与第二终端20的用户(不限定，第一用户的一例)不同的用户的用户帐户(不限定，与第一用户不同的用户的一例)。
作为通过这样的结构而得到的效果的一例，基于至少终端的用户和与终端的用户不同的第一用户能够结算的共同帐户、以及能够通过共同帐户结算的、与第一用户不同的用户的帐户，通过第一用户的第一终端执行了与第一结算相关的处理，基于此，能够接受基于第一结算的金额的请求，向终端的用户通知与该请求相关的信息。
另外，本变形例示出以下的结构：服务器10基于至少第二终端20的用户(不限定，终端的用户的一例)和第一终端20的用户(不限定，第一用户的一例)能够结算的共同帐户、以及第一终端20的用户的用户帐户(不限定，第一帐户的一例)，通过控制部11来执行结算处理(不限定，与第一结算相关的处理的一例)。进而，服务器10基于该结算(不限定，第一结算的一例)，通过通信I/F14向第二终端20发送支付垫付额请求信息(不限定，与基于第一结算的金额的请求相关的请求信息的一例)。
作为通过这样的结构而得到的效果的一例，能够基于至少终端的用户和与终端的用户不同的第一用户能够结算的共同帐户、以及与共同帐户不同的第一帐户，执行与第一结算相关的处理而实现结算。另外，能够向终端的用户请求基于第一结算的金额。
＜第四变形例(9)＞
在上述的实施例中，基于由店铺读码器装置50读取终端20的显示部24所显示的支付码或者基于由终端20读取支付店铺码而实现了结算。即，在上述的实施例中，示出了进行码结算的方法，但不限定于此。也能够代替码结算，通过无线通信(包括近距离无线通信。)进行结算。
图4-22是示出本变形例中的店铺读码器装置50的结构例的图。
店铺读码器装置50除了图1-2的结构之外，作为非限定的例子，还具备近距离无线通信I/F581。
近距离无线通信I/F581是用于与终端20之间进行近距离无线通信的接口。
这里，在近距离无线通信中，作为非限定的例子，包括所谓的非接触式的近距离通信(以下称为“非接触式通信”。)、利用了蓝牙的近距离通信(以下称为“蓝牙通信”。)等。
在应用非接触式通信的情况下，作为非限定的例子，在近距离无线通信I/F581中，能够包括用于读取设置于终端20的NFC芯片等非接触型IC卡所存储的信息的读卡器、用于读取信息/写入信息的卡读写器。在该情况下，代替上述的实施例中的代码结算(利用者提示型或店铺提示型)，终端20的用户能够通过将自己的终端20靠近店铺的读卡器或卡读写器上而与上述的实施例同样地进行结算。
在该情况下，在由读卡器读取了信息的结果是共同钱包余额(第一帐户的余额)不足的情况下，作为非限定的例子，服务器10的控制部11通过通信I/F14向终端20发送表示共同钱包余额不足的信息(结算余额不足信息)。当通过通信I/F22从服务器10接收到结算余额不足信息时，终端20的控制部21使结算余额不足信息显示于显示部24。进而，基于由自己的终端20的用户针对所显示的结算余额不足信息进行的输入，作为非限定的例子，将进行结算的帐户从共同帐户变更/设定为自己的终端20的用户的用户帐户(第二帐户)。然后，终端20的用户能够通过将自己的终端20再次靠近店铺的读卡器上而进行结算。
需要说明的是，在由读卡器读取了信息的结果是共同钱包余额(第一帐户的余额)不足的情况下，作为非限定的例子，也可以通过卡读写器向终端20的非接触型IC卡写入表示共同钱包余额不足的信息，还可以不采用这种方式。也可以是，响应于此，终端20的控制部21使结算余额不足信息显示于显示部24，基于由自己的终端20的用户针对所显示的结算余额不足信息进行的输入，作为非限定的例子，将进行结算的帐户从共同帐户变更/设定为自己的终端20的用户的用户帐户(第二帐户)，还可以不采用这种方式。进而，也可以是，终端20的用户能够通过将自己的终端20再次靠近店铺的读卡器上而进行结算，还可以不采用这种方式。
另外，在应用蓝牙通信的情况下，近距离无线通信I/F581包括用于与终端20之间进行蓝牙通信的蓝牙通信用的模块等。在该情况下，通过代替非接触式通信而将通信方式设为蓝牙通信，也能够通过与上述同样的方法进行结算。
本变形例示出通过基于通信I/F22(不限定，终端的通信部的一例)的、与店铺读码器装置50(不限定，销售通过第一结算而购入的商品或提供服务的店铺的终端的一例)之间的无线通信来执行与结算相关的处理的结构。
作为通过这样的结构而得到的效果的一例，能够通过终端的通信部进行与销售通过第一结算而购入的商品或提供服务的店铺的终端之间的无线通信，由此简单地实现结算。
另外，本变形例示出上述的无线通信是非接触式通信或蓝牙通信(不限定，近距离通信的一例)的结构。
作为通过这样的结构而得到的效果的一例，能够通过近距离通信来实现与销售通过第一结算购入的商品或提供服务的店铺的终端之间的无线通信。
＜第五实施例＞
第五实施例是这样的实施例：终端20(作为非限定的例子为终端A)利用支付应用，从共同钱包余额执行加盟店中的支付，或者从将共同钱包余额与终端20的用户(作为非限定的例子为用户A.A)的电子钱币账户余额合计的暂时的支付用帐户(以下称为“统合帐户”。)的电子钱币余额执行加盟店中的支付。
第五实施例所记载的内容也能够应用于其他的各实施例或其他的各变形例中的任意一个。
另外，针对与已经出现的结构要素相同的结构要素标注相同的标号并省略再次的说明。
＜数据结构＞
图5-1是示出在本实施例中存储于服务器10的存储部15的信息的一例的图。
在存储部15中，除了存储有支付应用管理处理程序151、支付应用用户注册数据153、用户管理数据库155以及共同钱包管理数据库157之外，作为非限定的例子，还存储有统合帐户管理数据库159。
统合帐户管理数据库159是用于服务器10管理统合帐户的数据库，图5-2示出其数据结构的一例。
在统合帐户管理数据库159中，存储有统合帐户管理数据作为每个统合帐户的管理数据。
在各个统合帐户管理数据中，作为非限定的例子，存储有作为用于识别该统合帐户的识别信息的一例的统合帐户ID、以及表示该统合帐户所包含的用户的帐户的统合帐户成员ID。在统合帐户成员ID中存储有在统合帐户中所统合的支付应用的帐户(包括用户的支付应用ID、共同钱包ID等。)。
在图5-2中，作为非限定的例子，示出以“UN0001”识别的统合帐户由“U0001”(即用户A.A)和“S0001”(即共同钱包“露营资金”)构成。
＜显示画面例＞
图5-3是示出在图3-3的露营资金支付画面中由终端20的用户A.A对表示为“代码支付”的图标进行了触摸操作的情况下显示的代码支付画面(统合前)的一例的图。
图5-3的画面与图3-4的画面大致同样，但露营资金代码支付区域2421内的一部分显示不同。
在图3-4的露营资金代码支付区域2421内，与选择标记按钮CN2一起显示有“从自己的钱包转账”的文字，在“从自己的钱包转账”的横侧显示有余额(在该例中为“25，000日元”)，但在图5-3的露营资金代码支付区域2421内，作为用于将露营资金的共同钱包与自己的钱包统合的信息，与“与自己的钱包统合”的文字一起配置有用于选择是否执行统合的(用于切换的)滑动按钮CN7。另外，在“与自己的钱包统合”的下方，新显示有“自己的钱包”这样的文字，在“自己的钱包”的横侧显示有自己的电子钱币账户余额(在该例中为“25，000日元”)。
滑动按钮CN7成为具有长圆和在该长圆内具有圆圈的图像，圆圈位于长圆内左端的状态(在该例中为“关闭”)成为默认状态，作为非限定的例子，通过对圆圈进行触摸操作或滑动操作而变化为圆圈位于长圆内右端的状态(在该例中为“打开”)，并且长圆内的颜色被反相显示。
图5-4是示出在图5-3的代码支付画面(统合前)中对滑动按钮CN7进行了操作的情况下显示的代码信息更新中画面的一例的图。
图5-4与图5-3的不同之处在于，露营资金代码支付区域2421内的滑动按钮CN7成为“打开”的状态，在露营资金代码支付区域2421重叠显示有表示正在更新代码信息的更新中信息CJK。在更新中信息CJK中，在中央显示有表示正在更新代码信息的两个旋转的箭头，并且，在两个旋转的箭头的下方显示有“代码信息更新中…”的文字。
图5-5是示出在更新了图5-4的支付代码信息更新中画面的情况下显示的代码支付画面(统合后)的一例的图。
即，在露营资金代码支付区域2421内的上部，显示有钱包的图像和共同钱包的名称(露营资金)、表示相加的“+”、以及钱包的图像和“自己的钱包”的文字，并且，显示有将共同钱包(露营资金)与自己的钱包相加并统合的统合后的余额(在该例中为“26，000日元”)。
另外，在图5-5的露营资金代码支付区域2421内显示的支付代码通过统合帐户而成为与图5-3的支付码不同的码。
如上所述，终端20的用户A.A通过代码收银机向店铺的店员提示上述的代码支付画面，通过店铺读码器装置读取支付码，由此进行代码支付。当由服务器10完成结算处理后，显示与图3-7同样的代码支付完成画面。
＜处理＞
图5-6～图5-7是示出在实施例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。本处理是与利用者提示型的代码结算相关的处理的一例。
作为非限定的例子，终端A的控制部21在将终端A的用户A.A的电子钱币账户余额加入到显示部24中进行显示时(A130)，将具有是否执行通过统合帐户进行的支付的选择功能的按钮加入到显示部24中进行显示(A450a)，该统合帐户是对用户A.A的电子钱币账户余额与共同钱包余额进行合算的帐户。
在基于针对终端A的输入输出部23的用户操作而选择了执行通过统合帐户进行的支付的情况下(A450a：是)，终端A的控制部21通过通信I/F22向服务器10发送帐户统合委托信息(A460)。
在没有选择执行通过统合帐户进行的支付的情况下(A450a：否)，终端A的控制部21通过通信I/F22从服务器10接收结算结果信息，执行图1-9的A180的步骤。
在通过通信I/F14从终端A接收到帐户统合委托信息的情况下(S470a：是)，服务器10的控制部11执行帐户统合处理(S480)。
在没有接收到帐户统合委托信息的情况下(S470a：否)，服务器10的控制部11从店铺读码器装置50接收结算请求信息，执行图1-9的S170a的步骤。
在帐户统合处理中，服务器10的控制部11向统合帐户管理数据库159追加具有唯一的统合帐户ID的统合帐户管理数据的记录，使该记录的统合帐户成员ID存储用户A.A的支付应用ID和共同钱包的共同钱包ID。
然后，服务器10的控制部11生成认可从与统合帐户ID绑定的统合帐户的余额支付的支付令牌。以下，将该令牌称为“统合帐户支付令牌”。
这里，统合帐户的余额成为与存储于统合帐户成员ID的支付应用ID及共同钱包ID关联的电子钱币的余额的合计额。
另外，作为非限定的例子，统合帐户支付令牌与共同钱包支付令牌同样地由规定位数(作为非限定的例子为12位)的整数值来识别。统合帐户支付令牌可以是具有有效期限的令牌，也可以不是具有有效期限的令牌。
当通过帐户统合处理而生成统合帐户支付令牌时，服务器10的控制部11生成包括统合帐户支付令牌的代码信息即统合帐户代码信息。作为非限定的例子，在统合帐户代码信息中，包括将统合帐户支付令牌的识别符编码为一维码(条形码)或二维码(QR码)的支付码(图像信息)。
需要说明的是，在统合帐户支付令牌具有有效期限的情况下，在统合帐户代码信息中也可以包括该有效期限。
然后，服务器10的控制部11通过通信I/F14向终端A发送统合帐户代码信息(S490a)。
需要说明的是，在通过通信I/F14从终端A没有接收到帐户统合委托信息的情况下(S470a：否)，服务器10的控制部11通过通信I/F14从店铺读码器装置50接收结算请求信息，执行图1-9的S170a的步骤。
当通过通信I/F22从服务器10接收到统合帐户代码信息时，终端A的控制部21基于接收到的统合帐户代码信息，将支付码更新并显示于显示部24(A470a)。
需要说明的是，在统合帐户代码信息中包括统合帐户支付令牌的识别符、有效期限的情况下，终端A的控制部21也可以更新并显示识别符、有效期限。
店铺读码器装置50的控制部51使用读码器58来读取终端A的显示部24所显示的支付码(P140)。在该情况下，由于显示部24所显示的支付码与统合帐户支付令牌建立关联，因此，在读码器58的读取结果中包括统合帐户支付令牌作为支付令牌。
作为非限定的例子，店铺读码器装置50的控制部51通过通信I/F54向服务器10发送包括店铺ID、结算预定金额以及支付令牌(在该情况下为统合帐户支付令牌)的结算请求信息(P150)。
当通过通信I/F14从店铺读码器装置50接收到结算请求信息时，服务器10的控制部11执行统合帐户结算处理(S500a)。
在统合帐户结算处理中，服务器10的控制部11根据接受了请求的统合帐户支付令牌来检索统合帐户ID。服务器10的控制部11还基于与统合帐户ID绑定的统合帐户成员ID(这里为用户A.A的支付应用ID和共同钱包的共同钱包ID)，使用由统合帐户成员ID指示的用户A.A的电子钱币账户余额和共同钱包余额的合计额，针对统合帐户，执行与由店铺ID决定的加盟店之间进行结算预定金额的支付的结算处理。
在统合帐户中的结算成功的情况下，服务器10的控制部11使共同钱包余额减少结算预定金额。如果在共同钱包余额未达到结算预定金额的情况下，则使共同钱包余额减少至“0”，从用户A.A的电子钱币账户余额扣除不足部分。
需要说明的是，也可以是，在统合帐户中的结算成功的情况下，服务器10的控制部11使用户A.A的电子钱币账户余额减少结算预定金额，如果在用户A.A的电子钱币账户余额未达到结算预定金额的情况下，使用户A.A的电子钱币账户余额减少至“0”，从共同钱包余额扣除不足部分，还可以不采用这种方式。
接着，作为非限定的例子，服务器10的控制部11通过通信I/F14向店铺读码器装置50发送包括结算处理的成功与否和结算处理后的统合帐户余额的结算结果信息(S510)。
另外，作为非限定的例子，服务器10的控制部11通过通信I/F14向终端A发送包括结算处理的成功与否、结算处理后的构成统合帐户的电子钱币账户/共同钱包余额、以及电子钱币账户/共同钱包中的支付额的统合帐户结算结果信息(S520)，结束处理。
当通过通信I/F54从服务器10接收到结算结果信息时，店铺读码器装置50的控制部51使结算结果信息显示于显示部53(P160)，结束处理。
当通过通信I/F22从服务器10接收到统合帐户结算结果信息时，终端A的控制部21使统合帐户结算结果信息显示于显示部24(A480)，结束处理。
＜统合帐户支付令牌与代码信息的关系＞
如上所述，作为非限定的例子，统合帐户支付令牌是认可从与统合帐户ID建立关联(绑定)的统合帐户的余额支付的支付令牌。即，统合帐户ID与统合帐户支付令牌建立关联。而且，对该统合帐户支付令牌进行编码而得到的代码信息是统合帐户代码信息。
另外，作为非限定的例子，在统合帐户ID中，作为统合帐户成员ID而关联了统合对象的支付应用ID和共同钱包的共同钱包ID。
因此，可以说在统合帐户代码信息(不限定，第一代码信息的一例)中包括或者关联了统合对象的支付应用ID(不限定，与第二帐户相关的信息的一例)和共同钱包ID(不限定，与共同帐户相关的信息的一例)。
＜第五实施例的效果＞
第五实施例示出以下的结构：终端20基于共同钱包余额而执行与结算相关的处理。另外，能够从自己的终端20的用户的用户帐户向共同钱包余额进行转账。
根据这样的结构，作为非限定的例子，能够得到与第三实施例、第四实施例同样的效果。
另外，第五实施例示出以下的结构：终端20基于针对自己的终端20的用户的用户帐户信息(不限定，第二帐户信息的一例)的输入，将使该用户帐户信息和共同帐户建立了关联的统合帐户代码信息(不限定，第一代码信息的一例)显示于显示部24。进而，终端20基于读取统合帐户代码信息，执行与结算相关的处理。
作为通过这样的结构而得到的效果的一例，能够基于针对第二帐户信息的输入，将使第二帐户和共同帐户建立了关联的第一代码信息显示于终端的显示区域而用于结算。另外，能够基于读取第一代码信息，简单地实现结算。
另外，第五实施例示出以下的结构：终端20使与共同帐户建立了关联的共同钱包码信息(不限定，第一代码信息的一例)和自己的终端20的用户的用户帐户信息(不限定，第二帐户信息的一例)显示于显示部24。进而，终端20基于针对自己的终端20的用户的用户帐户信息的输入，将使该用户帐户信息与共同帐户建立了关联的统合帐户代码信息(不限定，第二代码信息的一例)显示于显示部24。
作为通过这样的结构而得到的效果的一例，能够将与共同帐户建立了关联的第一代码信息显示于终端的显示区域而用于结算，并且能够使终端的用户识别第二帐户信息。另外，能够基于针对第二帐户信息的输入，将使第二帐户和共同帐户建立了关联的第二代码信息显示于终端的显示区域而用于结算。
另外，第五实施例示出从服务器10(不限定，执行与第一结算相关的处理的服务器的一例)向终端20发送共同钱包码信息(不限定，第一代码信息的一例)和统合帐户代码信息(不限定，第二代码信息的一例)的结构。
作为通过这样的结构而得到的效果的一例，能够从外部简单地取得第一代码信息和第二代码信息。
另外，第五实施例示出以下的结构：终端20使将共同钱包余额(不限定，与共同帐户建立了关联的第一电子货币的金额的一例)的信息与用户帐户的电子钱币账户余额(不限定，与第二帐户建立了关联的第二电子货币的金额)相加而得到的统合帐户的余额的信息、和统合帐户代码信息(不限定，第二代码信息的一例)显示于显示部24。
作为通过这样的结构而得到的效果的一例，能够向终端的用户通知与共同帐户建立了关联的第一电子货币的金额和与第二帐户建立了关联的第二电子货币的金额的相加金额。另外，能够使第二代码信息显示于终端的显示区域而用于结算。
＜第五变形例(1)＞
在第五实施例中，当接收到统合帐户代码信息时，终端A的控制部21将统合帐户代码信息更新并显示于显示部24，但也可以不更新支付码。
在该情况下，作为非限定的例子，服务器10的控制部11在图5-6的S480中，删除在图5-6的S100a中生成的共同钱包支付令牌(将其无效化)。进而，生成具有与在图5-6的S100a中生成的共同钱包支付令牌相同的识别符的统合帐户支付令牌即可。
＜第五变形例(2)＞
在第五实施例中，针对利用者提示型的代码结算进行了说明，但不限定于此。具体而言，也可以为店铺提示型的代码结算。
＜显示画面例＞
图5-8是示出在图3-3的露营资金支付画面中由终端20的用户A.A对“读码器”的图标进行了触摸操作的情况下显示的读码器画面(统合前)的一例的图。
在图5-8中，在标题栏的下方显示有作为当前执行中的子菜单的“露营资金”来作为“Payment App”的分层菜单中的当前位置。另外，在“露营资金”的下方显示有代码读取区域CR1，并且显示有“读码器”作为针对用户的操作引导，在“读码器”的下方显示有露营资金代码支付区域2423。
在露营资金代码支付区域2423的上部，与图3-4同样，与方形钱包的图像及共同钱包的名称(露营资金)一起显示有该露营资金的共同钱包余额(在该例中为“1，000日元”)。在“露营资金”的下方显示有“与自己的钱包统合”的文字，在“与自己的钱包统合”的横侧配置有滑动按钮CN7。另外，在“与自己的钱包统合”的下方显示有“自己的钱包”的文字，并且在“自己的钱包”的横侧显示有余额(在该例中为“25，000日元”)。
图5-9是示出在图5-8的读码器画面(统合前)中对滑动按钮CN7进行了触摸操作的情况下显示的支付代码信息更新中画面的一例的图。
在该例中，滑动按钮CN7通过被进行触摸操作等而成为“打开”的状态(圆圈在长圆内向右端移动而被反相显示的状态)。另外，与图5-4同样，以弹出窗口形式显示有更新中信息CJK。
图5-10是示出在更新了图5-9的支付代码信息更新中画面的情况下显示的读码器画面(统合后)的一例的图。
在该画面中，在图5-9的画面中以弹出窗口形式显示的更新中信息CJK通过帐户的统合(代码信息的更新)完成而被消除。另外，在露营资金代码支付区域2423内的上部，作为表示统合了共同钱包和自己的钱包的信息而显示有将方形钱包的图像及露营资金的文字与袋状钱包的图像及自己的钱包的文字用“+”结合后的信息。另外，与该信息建立关联地显示有通过钱包的统合而合算的余额(在该例中为“26，000日元”)。
当在图5-10所示的读码器画面中支付店铺码的读取完成并且图3-11所示的支付金额的输入完成且由服务器10完成结算处理后，显示与图3-7同样的代码支付完成画面。
＜处理＞
图5-11～图5-12是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理的一例。
终端A的控制部21在使用户帐户信息显示于显示部24时(A130)，使具有是否执行通过统合帐户进行的支付的选择功能的按钮加入到显示部24中进行显示，该统合帐户是对用户A.A的电子钱币账户余额与共同钱包余额进行合算的帐户(A450b)。
在基于针对终端A的输入输出部23的用户操作而选择了执行通过统合帐户进行的支付的情况下(A450b：是)，终端A的控制部21执行A460的步骤。
在没有选择执行通过统合帐户进行的支付的情况下(A450b：否)，终端A的控制部21执行图1-11的A190的步骤。
在通过通信I/F14从终端A接收到帐户统合委托信息的情况下(S470b：是)，服务器10的控制部11执行帐户统合处理(S480)。
在没有接收到帐户统合委托信息的情况下(S470b：否)，服务器10的控制部11从终端A接收结算请求信息，执行图1-11的S170b的步骤。
服务器10的控制部11在执行S480的步骤后，生成包括所生成的统合帐户支付令牌的代码读取用信息即统合帐户读码器信息。然后，服务器10的控制部11通过通信I/F14向终端A发送统合帐户读码器信息(S490b)。
当通过通信I/F22从服务器10接收到统合帐户读码器信息时，终端A的控制部21基于接收到的统合帐户读码器信息，使用于读取支付店铺码的读码器画面显示于显示部24，为了读取代码而起动相机27(A470b)。然后，终端A的控制部21执行A190的步骤。
当通过通信I/F14从终端A接收到结算请求信息时，服务器10的控制部11执行统合帐户店铺提示型结算处理(S500b)。
统合帐户店铺提示型结算处理能够与统合帐户结算处理同样地执行，因此，省略详细的说明。
然后，服务器10的控制部11执行S520的步骤，结束处理。
当通过通信I/F22从服务器10接收到统合帐户结算结果信息时，终端A的控制部21执行A480的步骤，结束处理。
本变形例示出以下的结构：终端20基于针对自己的终端20的用户的用户帐户信息(不限定，第二帐户信息的一例)的输入，将基于统合帐户读码器信息的、用于读取支付店铺码的读码器画面(不限定，第一读码器信息的一例)显示于显示部24。然后，基于通过在显示部24中显示了读码器画面的终端20来读取支付店铺码，终端20通过控制部21来执行与结算相关的处理。
作为通过这样的结构而得到的效果的一例，能够基于针对第二帐户信息的输入，将第一读码器信息显示于终端的显示区域而用于结算。另外，基于通过在显示区域显示了第一读码器信息的终端来读取代码信息，能够简单地实现结算。
另外，本变形例示出以下的结构：终端20将用于读取支付店铺码的读码器画面(不限定，第一读码器信息的一例)显示于显示部24。然后，终端20基于针对自己的终端20的用户的用户帐户信息(不限定，第二帐户信息的一例)的输入，将基于统合帐户读码器信息的、用于读取支付店铺码的读码器画面(不限定，第二读码器信息的一例)显示于显示部24。然后，基于通过在显示部24中显示了读码器画面的终端20来读取支付店铺码，终端20通过控制部21来执行与结算相关的处理。
作为通过这样的结构而得到的效果的一例，能够将第一读码器信息显示于终端的显示区域而用于结算，并且能够使终端的用户识别第二帐户信息。另外，能够基于针对第二帐户信息的输入，将第二读码器信息显示于终端的显示区域而用于结算。
另外，本变形例示出以下的结构：终端20将共同钱包余额(不限定，与共同帐户建立了关联的第一电子货币的金额的一例)的信息与用户帐户的电子钱币账户余额(不限定，与第二帐户建立了关联的第二电子货币的金额)相加得到的统合帐户的余额的信息以及、基于统合帐户读码器信息的、用于读取支付店铺码的读码器画面(不限定，第二读码器信息的一例)显示于显示部24。
作为通过这样的结构而得到的效果的一例，能够向终端的用户通知与共同帐户建立了关联的第一电子货币的金额和与第二帐户建立了关联的第二电子货币的金额的相加金额。另外，能够将第二读码器信息显示于终端的显示区域而用于结算。
＜第五变形例(3)＞
在第五实施例中，在帐户统合处理中多个帐户与单一的代码绑定，但也可以不采用这种方式。作为非限定的例子，也可以使多个支付码显示于终端，使用这些代码进行结算。
需要说明的是，在使用多个代码进行结算的情况下，能够结算的最大金额为与多个代码绑定的多个帐户的电子钱币账户余额的合计额。
以下，将这样的支付方法称为“帐户并列使用”。
＜显示画面例＞
图5-13是示出代码支付画面的另一例的图。
在图5-13中，与图5-5不同，沿上下并排地显示有由条形码表示的一维的支付码和同样由条形码表示的一维的支付码这两个支付码。
作为非限定的例子，上面的支付码是存储有支付令牌(后述的第一并列支付令牌)的第一并列码信息，该支付令牌认可从与用户A.A的支付应用ID绑定的电子钱币账户余额支付并包括选择帐户并列使用的标志。
与此相对，作为非限定的例子，下面的支付码是存储有支付令牌(后述的二并列支付令牌)的第二并列码信息，该支付令牌认可从与共同钱包ID绑定的共同钱包余额支付并包括选择帐户并列使用的标志。
需要说明的是，第一并列代码信息和第二并列代码信息的显示位置及其排列能够自由地设定变更。
另外，第一并列代码信息和第二并列代码信息也能够不为上述那样的一维的支付码，而为由QR码等表示的二维的支付码。
＜处理＞
图5-14～图5-15是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
终端A的控制部21在执行A130的步骤后，将具有是否执行通过帐户并列使用进行的支付的选择功能的按钮加入到显示部24中进行显示，在该帐户并列使用中，使用用户A.A的电子钱币账户和共同钱包(A490)。
在基于针对终端A的输入输出部23的用户操作而选择了执行通过帐户并列使用进行的支付的情况下(A490：是)，终端A的控制部21通过通信I/F22向服务器10发送帐户并列使用委托信息(A500)。
在没有选择执行通过帐户并列使用进行的支付的情况下(A490：否)，终端A的控制部21通过通信I/F22从服务器10接收结算结果信息，执行图1-9的A180的步骤。
在通过通信I/F14从终端A接收到帐户并列使用委托信息的情况下(S530：是)，服务器10的控制部11执行帐户并列使用处理(S540)。
在没有接收到帐户并列使用委托信息的情况下(S530：否)，服务器10的控制部11从店铺读码器装置50接收结算请求信息，执行图1-9的S170a的步骤。
在帐户并列使用处理中，服务器10的控制部11首先生成支付令牌，该支付令牌认可从与用户A.A的支付应用ID绑定的电子钱币账户余额支付并包括选择帐户并列使用的标志。以下，将该支付令牌设为“第一并列支付令牌”。
另外，服务器10的控制部11生成支付令牌，该支付令牌认可从与共同钱包ID绑定的共同钱包余额支付并包括选择帐户并列使用的标志。以下，将该支付令牌设为“第二并列支付令牌”。
作为非限定的例子，第一并列支付令牌/第二并列支付令牌由规定位数(作为非限定的例子为12位)的整数值识别。这些令牌可以为具有有效期限的令牌，也可以不为具有有效期限的令牌。
而且，服务器10的控制部11生成包括第一并列支付令牌的代码信息即第一并列代码信息和包括第二并列支付令牌的代码信息即第二并列代码信息。
作为非限定的例子，在第一并列代码信息/第二并列代码信息中，包括将各个令牌的识别符编码为一维码(条形码)或二维码(QR码)的支付码(图像信息)。
需要说明的是，在第一并列支付令牌/第二并列支付令牌具有有效期限的情况下，在这些代码信息中也可以包括该有效期限。
服务器10的控制部11在通过通信I/F14向终端A发送第一并列代码信息后(S550)，通过通信I/F14向终端A发送第二并列代码信息(S560)。
在通过通信I/F22接收到第一并列代码信息和第二并列代码信息时，终端A的控制部21使第一并列代码信息和第二并列代码信息排列显示于显示部24(A510)。
店铺读码器装置50的控制部51使用读码器58，读取终端A的显示部24所显示的一个支付码(P140)。然后，作为非限定的例子，店铺读码器装置50的控制部51通过通信I/F54向服务器10发送包括店铺ID、结算预定金额以及支付令牌(在该情况下为第一并列支付令牌或第二并列支付令牌)的结算请求信息(P150)。
当通过通信I/F14从店铺读码器装置50接收到结算请求信息时，服务器10的控制部11根据接收到的第一并列支付令牌或第二并列支付令牌来检测选择帐户并列使用的标志。这样，服务器10的控制部11为了请求在帐户并列使用处理中生成的另一方的支付令牌，通过通信I/F14向店铺读码器装置50发送其他代码读入委托信息(S570)。
当通过通信I/F54从服务器10接收到其他代码读入委托信息时，店铺读码器装置50的控制部51使促使读取另一方的支付码的画面显示于显示部53(P170)。
店铺读码器装置50的控制部51使用读码器58，读取终端A的显示部24所显示的另一方的支付码(P180)。然后，作为非限定的例子，店铺读码器装置50的控制部51通过通信I/F54向服务器10发送包括店铺ID、结算预定金额以及支付令牌(在该情况下为第一并列支付令牌或第二并列支付令牌中的在P150中未发送的令牌)的第二结算请求信息(P190)。
当通过通信I/F14从终端A接收到第二结算请求信息时，服务器10的控制部11执行帐户并列结算处理(S580)。
帐户并列结算处理通过看作是基于由与第一并列支付令牌绑定的用户A.A的电子钱币账户和与第二并列支付令牌绑定的共同钱包形成的统合帐户进行的支付而能够与统合帐户结算处理同样地执行，因此省略详细的说明。
然后，服务器10的控制部11执行S590、S600的步骤，结束处理。另外，当通过通信I/F22从服务器10接收到帐户并列结算结果信息时，终端A的控制部21执行A520的步骤，结束处理。
需要说明的是，关于S590、S600、A520的各步骤，通过看作是与帐户并列结算处理同样的通过统合帐户进行的支付，从而能够与S510、S520、A480的各步骤同样地执行，因此省略再次的说明。
＜第五变形例(4)＞
在第五实施例中，在通过统合帐户进行支付时，即便在共同钱包余额不足而使用用户的电子钱币账户的余额进行了垫付的情况下，也不会向共同钱包的其他用户(作为非限定的例子为用户B.B)请求垫付部分，但也可以请求垫付部分，还可以不采用这种方式。
图5-16是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、终端B(作为非限定的例子，为用户B.B的终端20)的控制部21所执行的结算联合处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
需要说明的是，关于处理的前半部分，作为非限定的例子而能够通过与图5-6、图5-7相同的处理来实现，因此，这里省略说明。
终端A的控制部21在执行A480的步骤后，使是否进行垫付部分的细算的选择用画面显示于显示部24(A530)
需要说明的是，也可以是，在A480的步骤中使用的统合帐户结算结果信息中，在从用户A.A的电子钱币账户支付的支付额为“0”或者结算失败的情况下，无需进行细算(A530：否)，因此，不使选择用画面显示于显示部24而结束处理，还可以不采用这种方式。另外，也可以是，在从用户A.A的电子钱币账户支付的支付额大于“0”且结算成功的情况下，不使选择用画面显示于显示部24而自动地进行细算(A530：是)，还可以不采用这种方式。
在基于针对终端A的输入输出部23的用户操作而选择了进行细算的情况下(A530：是)，终端A的控制部21通过通信I/F22向服务器10发送包括统合帐户结算结果信息所包含的从用户A.A的电子钱币账户支付的支付额的用户帐户结算额请求信息(A540)。
然后，当通过通信I/F22从服务器10接收到细算结果信息时，终端A的控制部21执行A340的步骤，结束处理。
需要说明的是，在选择了不进行细算的情况下(A530：否)，终端A的控制部21结束处理。
服务器10的控制部11在发送统合帐户结算结果信息(S520)并通过通信I/F14从终端A接收到用户帐户结算额请求信息时(S610：是)，将用户帐户结算额请求信息所包含的从用户A.A的电子钱币账户支付的支付额作为结算余额不足额而执行S290～S330的步骤。
在没有接收到用户帐户结算额请求信息的情况下(S610：否)，服务器10的控制部11结束处理。
终端B的控制部21在通过通信I/F22从服务器10接收到支付垫付额请求信息时(B100：是)，执行B110～B130的步骤。在没有接收到支付垫付额请求信息的情况下(B100：否)，终端B的控制部21结束处理。
＜第五变形例(5)＞
在第五实施例中，将使支付开始时的用户A.A的电子钱币账户的余额与共同钱包余额相加的金额设为统合帐户的余额(能够通过统合帐户进行支付的金额)，但不限定于此。
作为非限定的例子，也可以在统合共同钱包与用户A.A的电子钱币账户之前，从由用户A.A预先注册的外部金融机构的账户向用户A.A的电子钱币账户进行充值(转账)。
＜显示画面例＞
图5-17是示出在图3-3的露营资金支付画面中由终端20的用户A.A对表示为“代码支付”的图标进行了触摸操作的情况下显示的代码支付画面(统合前)的一例的图。
图5-17与图5-3不同，在露营资金代码支付区域2421内的“自己的钱包”的横侧显示的余额(在该例中为“1000日元”)的金额不同，并且，在余额的金额的横侧显示有充值按钮CN5。当对充值按钮CN5进行了触摸操作时，在图3-14所示的充值画面中进行充值。
图5-18是示出在图3-14的充值画面中完成了充值的情况下显示的代码支付画面(充值后)的一例的图。在该例中，通过进行了充值，余额成为“25，000日元”。
图5-19是示出基于在图5-18的代码支付画面(统合前)中对滑动按钮CN7进行触摸操作后统合了帐户而显示的代码支付画面(统合后)的一例的图。
在该例中，在图5-19的露营资金代码支付区域2421的上部，显示有方形钱包的图像和共同钱包的名称(露营资金)、表示相加的“+”、以及袋状钱包的图像和“自己的钱包”的文字，并且，显示有基于统合了共同帐户和自己的帐户而得到的统合后的余额(在该例中为“26，000日元”)。
另外，在图5-19的露营资金代码支付区域2421内显示的支付码通过统合了共同帐户和自己的帐户而成为与图5-18的支付码不同的码。
＜处理＞
图5-20是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
终端A的控制部21在执行A130的步骤后，执行A210～A230的步骤。接着，终端A的控制部21执行A450a的步骤。
因此，在该情况下，服务器10的控制部11在执行S120的步骤后，执行S190～S210的步骤。接着，服务器10的控制部11执行A470a的步骤。
需要说明的是，也可以在统合了共同钱包和用户A.A的电子钱币账户之后向用户A.A的电子钱币账户进行充值。在该情况下，终端A的控制部21在执行A470a的步骤后执行A210～A230的步骤，在从服务器10接收到统合帐户结算结果信息时执行A480的步骤即可。另外，服务器10的控制部11在执行S490a的步骤后执行S190～S210的步骤，在从店铺读码器装置50接收到结算请求信息时执行S500a的处理即可。
＜第五变形例(6)＞
在第五实施例中，选择是否统合执行结算处理的终端(作为非限定的例子为终端A)的用户(作为非限定的例子为用户A.A)的电子钱币账户与共同钱包，但所统合的电子钱币账户不限定于此。作为非限定的例子，也可以与构成共同钱包的其他成员(作为非限定的例子为用户B.B)的电子钱币账户进行统合。
＜显示画面例＞
图5-21是示出在图3-3的露营资金支付画面中由终端20的用户A.A对表示为“代码支付”的图标进行了触摸操作的情况下显示的代码支付画面(统合前)的一例的图。
图5-21与图5-3不同，在露营资金代码支付区域2421内显示有“钱包统合”的文字，但没有如图5-3那样进行与自己的钱包的统合相关的显示。
图5-22是示出在图5-21的代码支付画面(统合前)中对滑动按钮CN7进行了操作的情况下显示的代码支付画面(成员统合前)的一例的图。
在该例中，示出图5-18的露营资金代码支付区域2421内的滑动按钮CN7为“打开”的状态。另外，在它们的下方，包括“钱包统合”的文字的钱包统合引导区域WT1重叠显示在代码支付画面中，来作为针对用户的操作引导。
在“钱包统合”的下方，用于选择要统合的用户(成员)的钱包统合成员选择区域WTM1进一步重叠显示在钱包统合引导区域WT1。
在钱包统合成员选择区域WTM1，在上部显示有“与哪个成员的钱包统合？”的说明文，在其下方，与选择标记按钮CN2建立关联地显示有作为帐户的统合对象的用户的候选。
具体而言，作为非限定的例子，显示有与自己相关的信息(自己的图标图像、表示是自己的“自己”、自己的电子钱币账户余额(在该例中为“25，000日元”))作为用户的候选。另外，在与自己相关的信息的下方，显示有与用户B.B相关的信息(用户B.B的图标图像、用户名“用户B.B”)作为其他用户的候选。
作为非限定的例子，当对与用户B.B建立了关联的选择标记按钮CN2进行了触摸操作时，将用户B.B的用户帐户(电子钱币账户)与共同钱包统合。
图5-23是示出在图5-22的代码支付画面(成员统合前)中对用于选择用户B.B的选择标记按钮CN2进行了触摸操作的情况下显示于用户B.B的终端20的显示部24的通知画面的一例的图。
在图5-23中，在标题栏中显示有用户B.B的图标图像及其用户名“B.B”。另外，在标题栏的下方显示有“通知”的文字作为“Payment App”的分层菜单中的当前位置。
在“通知”的文字的下方显示有指代通知的“铃铛”的图标图像，在“铃铛”的横侧，在上层显示有“共同钱包：露营资金”的文字，在下层显示有通知的概要(在该例中为“从A.A先生/女士收到钱包统合委托”)。另外，在通知的概要的下方，显示有表示通知日的“今日”的文字。
在通知日的下方，设置有露营资金通知显示区域2429。
作为非限定的例子，在露营资金通知显示区域2429，在上层与表示是共同钱包的方形钱包的图像一起显示有该共同钱包的名称(在该例中为“露营资金”)。另外，在“露营资金”的横侧显示有“2020年4月11日16时18分”作为通知日期时间，在“露营资金”的下方，显示有共同使用该共同钱包的用户(在该例中为“用户A.A”和“用户B.B”)的图标图像。
另外，作为非限定的例子，在露营资金通知显示区域2429，显示有“钱包统合委托”作为来自用户A.A的委托项目，在“钱包统合委托”的下方，显示有“从A.A先生/女士收到钱包统合委托”的文字作为委托内容。
另外，在“从A.A先生/女士收到钱包统合委托”的下方，与方形钱包的图像及共同钱包的名称(在该例中为“露营资金”)一起显示有该露营资金的共同钱包余额(在该例中为“1，000日元”)作为钱包统合委托的详细信息。另外，在“露营资金”的下方，与袋状钱包的图像及“自己的钱包”(在该例中为用户B.B的钱包)的文字一起显示有自己的钱包的余额(在该例中为“20，000日元”)。另外，在“自己的钱包”的下方，与表示共同钱包成员的图标图像一起显示有“共同钱包的成员”的文字，在“共同钱包的成员”的横侧显示有共同钱包成员的人数(在该例中为“2人”)。
另外，在露营资金通知显示区域2429的下部，显示有用于许可钱包统合的许可按钮242P和用于拒绝钱包统合的拒绝按钮242Q。
图5-24是示出在图5-23的通知画面中对许可按钮242P进行了触摸操作的情况下显示于用户A.A的终端20的显示部24的代码信息更新画面的一例的图。
在该代码信息更新画面中，与图5-22不同，在露营资金代码支付区域2421内的“钱包统合”的文字的下方，与反相显示的选择标记按钮CN2一起，新显示有用户B.B的图标图像、该用户名“B.B”以及用户B.B的电子钱币账户余额(在该例中为“20，000日元”)。另外，在露营资金代码支付区域2421，重叠显示有表示正在更新代码信息的更新中信息CJK。
图5-25是示出在图5-24的代码信息更新画面之后显示于用户A.A的终端20的显示部24的代码支付画面(成员统合后)的一例的图。
在该代码支付画面中，显示有对共同帐户统合了用户B.B的用户帐户的结果。具体而言，在露营资金代码支付区域2421内的上部，显示有方形钱包的图像和共同钱包的名称(露营资金)、表示相加的“+”、以及袋状钱包的图像和“B.B先生/女士的钱包”。另外，作为帐户统合后的余额，显示有将共同钱包余额与用户B.B的电子钱币账户余额相加后的金额(在该例中为“21，000日元”)。
另外，通过帐户的统合，在图5-25的露营资金代码支付区域2421内显示的支付码成为与图5-21所示的支付码不同的码。
图5-26是示出在图5-23的通知画面中在由用户B.B对许可按钮242P和拒绝按钮242Q中的任意一个按钮进行操作为止的期间显示于用户A.A的终端20的显示部24的代码支付画面(统合申请中)的一例的图。
在该例中，在露营资金代码支付区域2421中，与“钱包统合”的文字建立了关联的滑动按钮CN7成为“打开”的状态。
另外，在“钱包统合”的下方，与以灰色反相显示的选择标记按钮CN2一起显示有用户B.B的图标图像和用户名“B.B”。另外，在其横侧显示有包括“申请中”的文字的矩形框。通过进行这样的显示，用户A.A能够知晓正在向用户B.B申请帐户的统合，并且仍然没有被用户B.B许可申请(或者没有被拒绝申请)。
图5-27是示出图5-21的代码支付画面的另一例的图。
图5-27与图5-21的不同之处在于，在“钱包统合”的文字的下方，与选择标记按钮CN2一起新显示有“向共同钱包充值”的文字。在该例中，通过对选择标记按钮CN2进行触摸操作，用户A.A能够向共同钱包进行充值。
＜处理＞
图5-28是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、终端B(作为非限定的例子，为用户B.B的终端20)的控制部21所执行的结算联合处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
终端A的控制部21在执行A130的步骤后，作为非限定的例子，将具有选择功能的按钮加入到显示部24中进行显示，该选择功能为，是否向其他用户(作为非限定的例子为用户B.B)委托、将作为共同钱包成员的其他用户(作为非限定的例子为用户B.B)的电子钱币账户与共同帐户统合而能够支付(A550)。
在基于针对终端A的输入输出部23的用户操作而选择了委托将用户B.B的电子钱币账户与共同钱包统合的情况下(A550：是)，终端A的控制部21通过通信I/F22向服务器10发送帐户统合申请信息(A560)。
在没有选择委托将用户B.B的电子钱币账户与共同钱包统合的情况下(A550：否)，终端A的控制部21通过通信I/F22从服务器10接收结算结果信息，执行图1-9的A180的步骤。
在通过通信I/F14从终端A接收到帐户统合申请信息的情况下(S620：是)，服务器10的控制部11通过通信I/F14向终端B发送帐户统合确认信息(S630)。
在没有接收到帐户统合申请信息的情况下(S620：否)，服务器10的控制部11通过通信I/F14从店铺读码器装置50接收结算请求信息，执行图1-9的S170a的步骤。
在通过通信I/F22从服务器10接收到帐户统合确认信息的情况下(B220：是)，终端B的控制部21基于帐户统合确认信息，使是否认可将用户B.B的电子钱币账户与共同钱包统合的选择用画面显示于显示部24(B230)。在没有接收到帐户统合确认信息的情况下(B220：否)，终端B的控制部21结束处理。
在基于针对终端B的输入输出部23的用户操作而选择了认可帐户的统合的情况下(B230：是)，终端B的控制部21通过通信I/F22向服务器10发送帐户统合认可信息(B240)，结束处理。在选择了不认可的情况下(B230：否)，终端B的控制部21结束处理。
在通过通信I/F14从终端B接收到帐户统合认可信息的情况下(S640：是)，服务器10的控制部11执行将用户B.B的电子钱币账户与共同钱包统合的帐户统合处理(S650)，执行S490a的步骤。
需要说明的是，关于帐户统合处理，能够与图5-6的S480的步骤同样地进行处理，因此，省略处理的详细说明。
在没有接收到帐户统合认可信息的情况下(S640：否)，服务器10的控制部11通过通信I/F14从店铺读码器装置50接收结算请求信息，执行图1-9的S170a的步骤。
接着，服务器10的控制部11通过通信I/F14向终端A发送包括用户B.B的电子钱币账户余额的用户帐户信息(S660)。然后，服务器10的控制部11在通过通信I/F14从店铺读码器装置50接收到结算请求信息时，执行图5-7的S500a的步骤。
在通过通信I/F22从服务器10接收到统合帐户代码信息的情况下(A570)，终端A的控制部21执行A470a的步骤。接着，在通过通信I/F22从服务器10接收到用户帐户信息时，终端A的控制部21基于接收到的用户帐户信息，作为非限定的例子而使用户B.B的电子钱币账户余额加入到显示部24中进行显示(A580)。然后，终端A的控制部21在通过通信I/F22从服务器10接收到统合帐户结算结果信息时，执行图5-7的A480的步骤。
在没有接收到统合帐户代码信息的情况下(A570：否)，终端A的控制部21在通过通信I/F22从服务器10接收到结算结果信息时，执行图1-9的A180的步骤。
＜第五变形例(7)＞
在第五变形例(6)中，在通过共同钱包与共同钱包的其他用户(作为非限定的例子为用户B.B)的电子钱币账户的统合帐户进行支付时，即便在共同钱包余额不足而使用其他用户的电子钱币账户的余额进行了垫付的情况下，也不会向进行了支付的终端A的用户A.A请求垫付部分，但也可以请求垫付部分，还可以不采用这种方式。
图5-29是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、终端B(作为非限定的例子，为用户B.B的终端20)的控制部21所执行的结算联合处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
需要说明的是，关于处理的前半部分，作为非限定的例子而能够与图5-28相同，关于处理的后半部分，作为非限定的例子而能够与图4-21相同，因此，这里省略说明。
终端A的控制部21在执行图5-28的A580的步骤后，通过通信I/F22从服务器10接收统合帐户结算结果信息，执行A480的步骤。
接着，终端A的控制部21使是否进行垫付部分的细算的选择用画面显示于显示部24(A590)
需要说明的是，也可以是，在A480的步骤中使用的统合帐户结算结果信息中，在从委托了统合的用户B.B的电子钱币账户支付的支付额为“0”或者结算失败的情况下，无需进行细算(A590：否)，因此，不使选择用画面显示于显示部24而结束处理，还可以不采用这种方式。另外，也可以是，在从用户B.B的电子钱币账户支付的支付额大于“0”且结算成功的情况下，不使选择用画面显示于显示部24而自动地进行细算(A590：是)，还可以不采用这种方式。
在基于针对终端A的输入输出部23的用户操作而选择了进行细算的情况下(A590：是)，终端A的控制部21通过通信I/F22向服务器10发送包括统合帐户结算结果信息所包含的从用户B.B的电子钱币账户支付的支付额的用户帐户结算额请求信息(A600)。
然后，终端A的控制部21执行图4-21的A400以后的步骤。
另一方面，在选择了不进行细算的情况下(A590：否)，终端A的控制部21结束处理。
服务器10的控制部11在发送统合帐户结算结果信息(S520)并通过通信I/F14从终端A接收到用户帐户结算额请求信息时(S670：是)，将用户帐户结算额请求信息所包含的从用户B.B的电子钱币账户支付的支付额作为结算余额不足额而执行S400以后的步骤。
在没有接收到用户帐户结算额请求信息的情况下(S670：否)，服务器10的控制部11结束处理。
在通过通信I/F22从服务器10接收到结算余额不足额时(B180：是)，终端B的控制部21执行图4-21的B190以后的步骤。在没有接收到结算余额不足额的情况下(B180：否)，终端B的控制部21结束处理。
＜第五变形例(8)＞
终端20将共同钱包码信息或者基于共同钱包读码器信息的、用于读取支付店铺码的读码器画面显示于显示部24。进而，终端20能够基于针对自己的终端20的用户的用户帐户信息的输入，将与该用户帐户信息建立了关联的支付码或者用于读取支付店铺码的读码器画面显示于显示部24。
另外，在该情况下，作为非限定的例子，能够从共同钱包余额和自己的终端20的用户的用户帐户的电子钱币账户余额中的共同钱包余额优先地进行结算。
本变形例示出以下的结构：终端20将共同钱包码信息(不限定，与共同帐户建立了关联的第一代码信息的一例)或者基于共同钱包读码器信息的、用于读取支付店铺码的读码器画面(不限定，第一读码器信息的一例)显示于显示部24。然后，终端20基于针对自己的终端20的用户的用户帐户信息(不限定，第二帐户信息的一例)的输入，将与用户帐户信息建立了关联的支付码(不限定，与第二帐户建立了关联的第三代码信息的一例)或者基于用户帐户信息的、用于读取支付店铺码的读码器画面(不限定，第三读码器信息的一例)显示于显示部24。
作为通过这样的结构而得到的效果的一例，能够将与共同帐户建立了关联的第一代码信息或者第一读码器信息显示于终端的显示区域而用于结算。另外，能够基于针对第二帐户信息的输入，将与第二帐户建立了关联的第三代码信息或者第三读码器信息显示于终端的显示区域而用于结算。
另外，本变形例示出以下的结构：在结算时，从共同钱包余额与自己的终端20的用户的用户帐户的电子钱币账户余额中的共同钱包余额(不限定，共同帐户的余额的一例)优先地进行支付。
作为通过这样的结构而得到的效果的一例，由于从共同帐户的余额优先地进行支付，因此，能够使第二帐户成为随附的帐户。
＜第五变形例(9)＞
上述所示的各种显示画面和用户界面(UI)只不过是一例，不限定于此。
＜显示画面例＞
图5-30是示出在图3-1的子菜单中对“自己的钱包”(未图示)进行了触摸操作并且在自己的钱包画面中由终端20的用户A.A对表示为“代码支付”的图标进行了触摸操作的情况下显示的代码支付画面(统合前)的一例的图。该代码支付画面是用于以自己的帐户为基础而将共同帐户选择为统合对方的画面的一例。
在图5-30中，在标题栏的下方，显示有作为当前执行中的子菜单的“代码支付”来作为“Payment App”的分层菜单中的当前位置。另外，在设置于“代码支付”的下方的代码支付区域2451，与袋状钱包的图像及“自己的钱包”的文字一起显示有自己的电子钱币账户余额(在该例中为“25，000日元”)。
在“自己的钱包”的下方显示有“钱包统合”的文字，并且在“钱包统合”的横侧配置有滑动按钮CN7。通过对该滑动按钮CN7进行操作，能够选择与自己的用户帐户统合的共同帐户。
图5-31是示出在图5-30的代码支付画面(统合前)中对滑动按钮CN7进行了触摸操作的情况下显示的代码支付画面(共同钱包统合前)的一例的图。
在图5-31中，图5-30的代码支付区域2451内的滑动按钮CN7成为“打开”的状态。另外，在滑动按钮CN7的下方，包括“钱包统合”的文字的钱包统合引导区域WT2重叠显示于代码支付画面作为针对用户的操作引导。在“钱包统合”的下方，用于选择要统合的共同钱包的共同钱包统合选择区域WTM2进一步重叠显示于钱包统合引导区域WT2。
在共同钱包统合选择区域WTM2中，在上部显示有“请选择要统合的共同钱包”的说明文，在该说明文的下方，与选择标记按钮CN2一起显示有表示是露营资金用的共同钱包的“露营资金”的文字，在“露营资金”的横侧显示有该共同钱包余额(在该例中为“1，000日元”)。
另外，在“露营资金”的下方，与选择标记按钮CN2一起显示有表示是韩国旅行用的共同钱包的“韩国旅行”的文字，在“韩国旅行”的横侧显示有该共同钱包余额(在该例中为“90，000日元”)。
图5-32是示出在图5-31的代码支付画面(共同钱包统合前)中对与韩国旅行用的共同钱包建立了关联的选择标记按钮CN2进行了触摸操作的情况下显示的代码信息更新画面的一例的图。
图5-32与图5-31的不同之处在于，在代码支付区域2451内的“钱包统合”的文字的下方，与反相显示的选择标记按钮CN2一起新显示有“韩国旅行”的文字，在“韩国旅行”的横侧显示有余额(在该例中为“90，000日元”)，在露营资金代码支付区域2421，重叠显示有表示正在更新代码信息的更新中信息CJK。
图5-33是示出在图5-32的代码信息更新画面之后显示的代码支付画面(共同钱包统合后)的一例的图。
在该代码支付画面中，在代码支付区域2451内的上部显示有袋状钱包的图像和自己的钱包、表示相加的“+”、方形钱包的图像和“韩国旅行”的文字，并且，显示有作为统合了自己的用户帐户与共同帐户(韩国旅行)的结果的余额(在该例中为“115，000日元”)。另外，通过统合了帐户，显示在代码支付区域2451内的支付码成为与图5-30的支付码不同的码。
＜第六实施例＞
第六实施例是这样的实施例：终端20(作为非限定的例子为终端A)利用支付应用从共同钱包余额执行加盟店中的支付，但在支付时共同钱包余额不足的情况下，基于用户A.A的电子钱币账户与共同钱包的统合帐户来执行支付，由此弥补共同钱包的余额不足。
第六实施例所记载的内容也能够应用于其他的各实施例或其他的各变形例中的任意一个。
另外，针对与已经出现的结构要素相同的结构要素标注相同的标号并省略再次的说明。
＜处理＞
图6-1～图6-2是在实施例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。本处理是与利用者提示型的代码结算相关的处理的一例。
店铺读码器装置50的控制部51执行P100～P160的步骤作为店铺结算处理。
服务器10的控制部11在执行S120的步骤后，通过通信I/F14从店铺读码器装置50接收结算请求信息，执行S250a的步骤。另外，在执行S270a的步骤后，执行S470a的步骤。
终端A的控制部21在执行A130的步骤后，执行A270a的步骤。另外，在执行A290的步骤后，执行A450a的步骤。
图6-2是为了便于以后的说明而记述的流程，各装置的步骤与图5-7相同，因此省略说明。
需要说明的是，关于店铺读码器装置50在执行P130后是将处理移至图6-2的流程还是将处理移至图4-5的流程，在P130的执行时，店铺读码器装置50无法进行判断，因此，通过服务器10的控制部11的处理进行分支。在图6-2和图4-5中，店铺读码器装置50的控制部51所执行的处理相同，因此，不受服务器10的分支结果的直接影响。
＜第六实施例的效果＞
第六实施例示出以下的结构：终端20基于结算预定金额(不限定，第一结算的金额的一例)和共同钱包余额(不限定，第一帐户的余额)，在共同钱包余额不足的情况下，基于共同帐户(不限定，第一帐户的一例)和自己的终端20的用户的用户帐户(不限定，第二帐户的一例)，通过控制部21来执行与结算相关的处理。
作为通过这样的结构而得到的效果的一例，即便在第一帐户的余额不足的情况下，也能够基于第一帐户和第二帐户，适当地进行结算。
＜第六变形例(1)＞
在第六实施例中，针对利用者提示型的码结算进行了说明，但不限定于此。具体而言，也可以为店铺提示型的码结算。
图6-3是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理的一例。
终端A的控制部21在执行A130的步骤后执行A300的步骤。另外，在执行A290的步骤后执行A450b的步骤。
服务器10的控制部11执行S120的步骤，在通过通信I/F14从终端A接收到结算请求信息时，执行S250b的步骤。另外，在执行S270b的步骤后，执行S470b的步骤。
＜第六变形例(2)＞
在第六实施例中，使用帐户统合处理将多个帐户与单一的代码相关联，但也可以不采用这种方式。作为非限定的例子，也可以通过对多个帐户进行帐户并列使用而进行支付。
图6-4～图6-5是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
店铺读码器装置50的控制部51执行P100～P160的步骤作为店铺结算处理。
服务器10的控制部11在执行S120的步骤后，通过通信I/F14从店铺读码器装置50接收结算请求信息，执行S250a的步骤。另外，在执行S270a的步骤后，执行S530的步骤。
终端A的控制部21在执行A130的步骤后执行A270a的步骤。另外，在执行A290的步骤后执行A490的步骤。
图6-5中的各装置的步骤与图5-15相同，因此省略说明。
需要说明的是，关于店铺读码器装置50在执行P130后是将处理移至图6-5的流程还是将处理移至图4-5的流程，在P130的执行时，店铺读码器装置50无法进行判断，因此，通过服务器10的控制部11的处理进行分支。
＜第六变形例(3)＞
在第六实施例中，将支付开始时的用户A.A的电子钱币账户的余额与共同钱包余额相加的金额设为统合帐户的余额(能够通过统合帐户进行支付的金额)，但不限定于此。
作为非限定的例子，也可以是，在即便合算了用户A.A的电子钱币账户的余额与共同钱包余额也未达到支付额的情况下，在统合共同钱包与用户A.A的电子钱币账户之前，从由用户A.A预先注册的外部金融机构的账户向用户A.A的电子钱币账户进行充值(转账)。
图6-6是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
需要说明的是，关于处理的后半部分，作为非限定的例子而能够与图6-2或图4-5相同，因此，这里省略说明。
终端A的控制部21在执行A290的步骤后执行A350的步骤，根据需要而执行A210～A230的步骤。之后，终端A的控制部21执行A450a以后的步骤。
需要说明的是，终端A的控制部21也可以不执行A350的步骤而总是执行A210～A230的步骤，还可以不采用这种方式。
服务器10的控制部11在执行S270a的步骤后执行S190～S210的步骤，执行S470a以后的步骤。
店铺读码器装置50的控制部51在执行P130的步骤后，执行P140以后的步骤。
＜第六变形例(4)＞
在第六实施例中，在通过统合帐户进行支付时，即便在共同钱包余额不足而使用用户的电子钱币账户的余额进行了垫付的情况下，也不会向共同钱包的其他用户(作为非限定的例子为用户B.B)请求垫付部分，但也可以请求垫付部分，还可以不采用这种方式。
图6-7是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、终端B(作为非限定的例子，为用户B.B的终端20)的控制部21所执行的结算联合处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
终端A的控制部21在执行A480的步骤后，执行A530～A340的步骤，结束处理。
终端B的控制部21执行B100～B130的步骤，结束处理。
服务器10的控制部11在执行S520的步骤后，执行S610～S330的步骤，结束处理。
店铺读码器装置50的控制部51在执行P160的步骤后，结束处理。
关于各步骤，能够与图5-16同样地实现，因此，省略详细的说明。
需要说明的是，也可以通过从图6-6的处理的后半部分连接到图6-7的流程，向共同钱包的其他用户(作为非限定的例子为用户B.B)请求用户A.A的垫付部分，还可以不采用这种方式。
＜第六变形例(5)＞
在第六实施例中，在由于共同钱包中的余额不足而无法进行支付的情况下，选择是否将执行结算处理的终端(作为非限定的例子为终端A)的用户(作为非限定的例子为用户A.A)的电子钱币账户与共同钱包统合，但要统合的电子钱币账户不限定于此。作为非限定的例子，也可以与构成共同钱包的其他成员(作为非限定的例子为用户B.B)的电子钱币账户进行统合。
图6-8是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、终端B(作为非限定的例子，为用户B.B的终端20)的控制部21所执行的结算联合处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
需要说明的是，关于处理的后半部分，作为非限定的例子而能够与图6-2相同，因此，这里省略说明。
终端A的控制部21在执行A290的步骤后，执行A550～A580的步骤。当通过通信I/F22从服务器10接收到统合帐户结算结果信息时，终端A的控制部11执行A480以后的步骤。
终端B的控制部21执行B220～B240的步骤，结束处理。
服务器10的控制部11在执行S270a的步骤后，执行S620～S660的步骤。当通过通信I/F14从店铺读码器装置50接收到结算请求信息时，服务器10的控制部11执行S500a以后的步骤。
店铺读码器装置50的控制部51在执行P130的步骤后，执行P140以后的步骤。
关于各步骤，能够与图5-28同样地实现，因此，省略详细的说明。
＜第六变形例(6)＞
在第六变形例(5)中，即便在使用其他用户的电子钱币账户的余额进行了垫付的情况下，也不会向进行了支付的终端A的用户A.A请求垫付部分，但也可以请求垫付部分，还可以不采用这种方式。
图6-9是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、终端B(作为非限定的例子，为用户B.B的终端20)的控制部21所执行的结算联合处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
需要说明的是，关于处理的前半部分，作为非限定的例子而能够与图6-8相同，关于处理的后半部分，作为非限定的例子而能够与图4-21相同，因此，这里省略说明。
终端A的控制部21在执行A580的步骤后，通过通信I/F22从服务器10接收统合帐户结算结果信息，执行A480～A600的步骤。在A600为是的情况下，终端A的控制部21执行A400以后的步骤。
终端B的控制部21执行B180的步骤。在B180为是的情况下，执行B190以后的步骤。
服务器10的控制部11在执行S660的步骤后，通过通信I/F14从店铺读码器装置50接收结算请求信息，执行S500a～S400的步骤。在执行了S400的步骤的情况下，服务器10的控制部11执行S410以后的步骤。
店铺读码器装置50的控制部51在执行P130的步骤后，执行P140～P160的处理。
关于各步骤，能够与图5-29同样地实现，因此，省略详细的说明。
＜第七实施例＞
第七实施例是这样的实施例：终端20(作为非限定的例子为终端A)利用支付应用，从合算了共同钱包余额与终端20的用户(作为非限定的例子为用户A.A)的电子钱币账户余额的统合帐户的电子钱币余额执行加盟店中的支付。与第五实施例不同，在本实施例中，从使用统合帐户的支付开始处理。
第七实施例所记载的内容也能够应用于其他的各实施例或其他的各变形例中的任意一个。
另外，针对与已经出现的结构要素相同的结构要素标注相同的标号并省略再次的说明。
＜处理＞
图7-1是示出在实施例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。本处理是与利用者提示型的代码结算相关的处理的一例。
需要说明的是，关于处理的后半部分，作为非限定的例子而能够与图5-7同样地执行，因此，省略详细的说明。
首先，作为非限定的例子，终端A的控制部21通过通信I/F22向服务器10发送选择将能够从终端A利用的共同钱包与自身的电子钱币账户统合后的统合帐户的信息(A610)。
作为非限定的例子，选择统合帐户的信息包括共同钱包ID和用户A.A的支付应用ID。终端A的控制部21也可以在本步骤中通过通信I/F22从服务器10接收能够选择的共同钱包ID，还可以调用预先存储在存储部28中的共同钱包ID。另外，终端A的控制部21也可以不发送支付应用ID，而发送在服务器10的控制部11中能够确定支付应用ID的终端电话号码。
当通过通信I/F14从终端A接收到选择统合帐户的信息时，服务器10的控制部11基于选择统合帐户的信息，执行S480的步骤。
需要说明的是，在已经制作出统合帐户的情况下，终端A的控制部21也可以通过通信I/F22向服务器10发送选择包括该统合帐户ID的统合帐户的信息作为选择统合帐户的信息。终端A的控制部21也可以在本步骤中通过通信I/F22从服务器10接收能够选择的统合帐户ID，还可以调用预先存储在存储部28中的统合帐户ID。在该情况下，服务器10的控制部11在S480的步骤中，在帐户统合处理中也可以不执行统合帐户管理数据的记录追加。
然后，服务器10的控制部11执行S490a～S120的各步骤，在通过通信I/F14从店铺读码器装置50接收到结算请求信息时，执行S500a以后的步骤。
终端A的控制部21在通过通信I/F22从服务器10接收到统合帐户代码信息时，执行A470a～A130的各步骤，在通过通信I/F14接收到统合帐户结算结果信息时，执行A480以后的步骤。
需要说明的是，在A610的步骤中，作为非限定的例子，终端A的控制部21也可以通过通信I/F22向服务器10发送选择将能够从终端A利用的共同钱包与自身以外的共同钱包成员的电子钱币账户统合后的统合帐户的信息，还可以不采用这种方式。在该情况下，作为非限定的例子，选择统合帐户的信息包括共同钱包ID和用户B.B的支付应用ID。
＜第七实施例的效果＞
第七实施例示出以下的结构：终端20将使自己的终端20的用户能够结算的第一帐户与自己的终端20的用户的用户帐户(不限定，与第一帐户不同的第二帐户的一例)建立了关联的统合帐户代码信息(不限定，第一代码信息的一例)显示于显示部24。进而，终端20基于读取统合帐户代码信息，通过控制部21来执行与结算相关的处理。
作为通过这样的结构而得到的效果的一例，能够将使终端的用户能够结算的第一帐户和不同于第一帐户的第二帐户建立了关联的第一代码信息显示于终端的显示区域而用于结算。另外，能够基于读取第一代码信息而简单地实现结算。
另外，第七实施例示出第一帐户是共同帐户(不限定，至少终端的用户和与终端的用户不同的第一用户能够结算的共同帐户的一例)的结构。
作为通过这样的结构而得到的效果的一例，能够将使共同帐户和不同于共同帐户的第二帐户建立了关联的第一代码信息显示于终端的显示区域而用于结算。另外，能够基于读取第一代码信息而简单地实现结算。
另外，第七实施例示出统合帐户代码信息(不限定，第一代码信息的一例)是一个代码(不限定，一个代码信息的一例)的结构。
作为通过这样的结构而得到的效果的一例，能够不通过多个代码信息而通过一个代码信息而简单地实现结算。
另外，第七实施例示出统合帐户代码信息(不限定，第一代码信息的一例)包括自己的终端20的用户的支付应用ID或者不同的终端20的用户的支付应用ID(不限定，与第二帐户相关的信息的一例)、以及共同钱包ID(不限定，与共同帐户相关的信息的一例)的结构。
作为通过这样的结构而得到的效果的一例，能够与上述相互结合地使与第二帐户相关的信息和与共同帐户相关的信息包含在一个代码信息中，因此是有效的。
另外，第七实施例示出以下的结构：终端20将选择包括与自己的终端20的用户(作为非限定的例子为用户A.A)不同的终端20的用户(作为非限定的例子为用户B.B)的支付应用ID(不限定，第三帐户的一例)的统合帐户的信息(不限定，与第三帐户相关的第三帐户信息的一例)、以及选择包括自己的终端20的用户的支付应用ID(不限定，第二帐户的一例)的统合帐户的信息(不限定，与第二帐户相关的第二帐户信息的一例)显示于显示部24。
作为通过这样的结构而得到的效果的一例，除了第二帐户信息之外，还能够向终端的用户通知与不同于第二帐户的第三帐户相关的第三帐户信息。
另外，第七实施例示出以下的结构：终端20将选择包括自己的终端20的用户(作为非限定的例子为用户A.A)的支付应用ID(不限定，第二帐户的一例)的统合帐户的信息(不限定，与第二帐户相关的第二帐户信息的一例)和选择包括不同的终端20的用户(作为非限定的例子为用户B.B)的支付应用ID(不限定，第三帐户的一例)的统合帐户的信息(不限定，与第三帐户相关的第三帐户信息的一例)显示于显示部24。进而，终端20基于针对所显示的选择包括自己的终端20的用户(作为非限定的例子为用户A.A)的支付应用ID(不限定，第二帐户的一例)的统合帐户的信息的输入，将统合了共同帐户与自己的终端20的用户的用户帐户的统合帐户代码信息(不限定，第一代码信息的一例)显示于显示部24。
作为通过这样的结构而得到的效果的一例，能够使终端的用户与和第二帐户相关的第二帐户信息一起识别与不同于第二帐户的第三帐户相关的第三帐户信息。另外，能够基于由终端的用户针对第二帐户信息的输入，使第一代码信息或第一读码器信息显示于显示区域而用于结算。
另外，第七实施例示出第二帐户是自己的终端20的用户的帐户(不限定，终端的用户的帐户的一例)的结构。
作为通过这样的结构而得到的效果的一例，能够将终端的用户的帐户作为第二帐户来实现结算。
另外，第七实施例示出以下的结构：服务器10通过通信I/F14，向终端20发送使该终端20的一个用户能够结算的第一帐户与该终端20的用户的用户帐户(不限定，与第一帐户不同的第二帐户的一例)建立了关联的统合帐户代码信息(不限定，第一代码信息的一例)。另外，服务器10通过通信I/F14从店铺读码器装置50接收结算请求信息(不限定，第一代码信息与商品信息的一例)。然后，服务器10基于接收到的结算请求信息，通过控制部11来执行结算处理(不限定，与第一结算相关的处理的一例)。
作为通过这样的结构而得到的效果的一例，能够使终端的用户取得使终端的用户能够结算的第一帐户与不同于第一帐户的第二帐户建立了关联的第一代码信息。
＜第七变形例(1)＞
在第七实施例中，针对利用者提示型的码结算进行了说明，但不限定于此。具体而言，也可以为店铺提示型的代码结算。
图7-2是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理的一例。
需要说明的是，关于处理的后半部分，作为非限定的例子而能够与图5-12同样地执行，因此，省略详细的说明。
终端A的控制部21在执行A610～A130的各步骤后，执行A190以后的步骤。
服务器10的控制部11在执行S480～S120的各步骤后，通过通信I/F14从终端A接收结算请求信息，执行S500b以后的步骤。
本变形例示出以下的结构：终端20将基于使自己的终端20的用户能够结算的第一帐户与自己的终端20的用户的用户帐户(不限定，第二帐户的一例)建立了关联的统合帐户读码器信息的、用于读取支付店铺码的读码器画面(不限定，第一读码器信息的一例)显示于显示部24。进而，终端20根据通过将基于统合帐户读码器信息的读码器画面显示于显示部24的终端20来读取支付店铺码，由控制部21执行与结算相关的处理。
作为通过这样的结构而得到的效果的一例，能够将使终端的用户能够结算的第一帐户与不同于第一帐户的第二帐户建立了关联的第一读码器信息显示于终端的显示区域而用于结算。另外，基于通过显示了第一读码器信息的终端来读取代码信息，能够简单地实现结算。
＜第七变形例(2)＞
使用帐户统合处理将多个帐户与单一的码相关联，但也可以不采用这种方式。作为非限定的例子，也可以通过对多个帐户进行帐户并列使用而进行支付。
图7-3是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理的一例。
需要说明的是，关于处理的后半部分，作为非限定的例子而能够与图5-15同样地执行，因此，省略详细的说明。
首先，作为非限定的例子，终端A的控制部21通过通信I/F22向服务器10发送选择对能够从终端A利用的共同钱包和自身的电子钱币账户进行帐户并列使用的信息(A620)。
作为非限定的例子，在选择进行帐户并列使用的信息中包括共同钱包ID和用户A.A的支付应用ID。
当通过通信I/F14从终端A接收到选择进行帐户并列使用的信息时，服务器10的控制部11基于选择进行帐户并列使用的信息，执行S540的步骤。然后，服务器10的控制部11执行S550～S120的各步骤，当从店铺读码器装置50接收到结算请求信息时，执行S570以后的步骤。
当通过通信I/F22从服务器10接收到第一并列代码信息和第二并列代码信息时，终端A的控制部21执行A510～A130的各步骤，当通过通信I/F22从服务器10接收到帐户并列结算结果信息时，执行A520以后的步骤。
需要说明的是，如上所述，可以说是在统合帐户代码信息(不限定，第一代码信息的一例)中包括或者关联了统合对象的支付应用ID(不限定，与第二帐户相关的信息的一例)和共同钱包ID(不限定，与共同帐户相关的信息的一例)。
本变形例示出以下的结构：统合帐户代码信息(不限定，第一代码信息的一例)包括第二代码信息和第三代码信息，第二代码信息与共同钱包ID(不限定，共同帐户的一例)建立关联，第三代码信息与统合对象的支付应用ID(不限定，第二帐户的一例)建立关联，第二代码信息与第三代码信息显示在不同的区域。
作为通过这样的结构而得到的效果的一例，能够基于显示于不同区域的单独的代码信息来实现结算。
＜第七变形例(3)＞
在第七实施例中，最初对代码进行提示的统合帐户中的支付失败时，结束处理，但也可以不采用这种方式。
作为非限定的例子，也可以是，当统合帐户中的支付失败时，对自身的帐户执行充值，使统合帐户的余额增加，由此弥补余额不足，再次进行支付。
图7-4～图7-5是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
需要说明的是，关于处理的后半部分，作为非限定的例子而能够与图6-2同样地执行，因此，省略详细的说明。
终端A的控制部21执行A610～A130的各步骤。然后，服务器10的控制部11执行S480～S120的各步骤。店铺读码器装置50的控制部51执行P100～P110的处理。
服务器10的控制部11通过通信I/F14从店铺读码器装置50接收结算请求信息。在该情况下，在结算请求信息中，包括基于在S490a的步骤中发送的统合帐户代码信息的、统合帐户支付令牌。因此，服务器10的控制部11执行统合帐户结算处理(S680)。统合帐户结算处理能够与图5-7的S500a的步骤同样地执行，因此，省略详细的说明。
在S680中结算成功的情况下(S690：是)，服务器10的控制部11使处理进入图6-2的S510的步骤。
在S680中结算失败的情况下(S690：否)，服务器10的控制部11通过通信I/F14向终端A和店铺读码器装置50发送包括结算失败这一旨意和该情况下的统合帐户中的结算余额不足额的结算余额不足信息(S700)。
这里，本变形例中的结算余额不足信息是表示统合帐户的余额不足的信息，但统合帐户是将共同帐户与用户A.A的用户帐户统合后的帐户。因此，本变形例中的结算余额不足信息是表示共同钱包余额和用户A.A的电子钱币账户余额不足的信息。
然后，服务器10的控制部11进一步执行S190～S210的步骤，当通过通信I/F14从店铺读码器装置50接收到结算请求信息时，执行S500a以后的步骤。
当通过通信I/F22从服务器10接收到结算余额不足信息时(A610：是)，终端A的控制部21执行A280～A290的步骤。终端A的控制部21在进一步执行A210～A230的步骤后，通过通信I/F22从服务器10接收统合帐户结算结果信息，执行A480的步骤。
在没有接收到结算余额不足信息的情况下(A610：否)，终端A的控制部21通过通信I/F22从服务器10接收统合帐户结算结果信息，执行A480以后的步骤。
当通过通信I/F54从服务器10接收到结算余额不足额时(P200：是)，店铺读码器装置50的控制部51执行P130以后的步骤。在没有接收到结算余额不足额的情况下(P200：否)，店铺读码器装置50的控制部51通过通信I/F54从服务器10接收结算结果信息，执行P160以后的步骤。
本变形例示出以下的结构：终端20基于结算预定金额(不限定，第一结算的金额的一例)、共同钱包余额(不限定，共同帐户的余额的一例)以及自己的终端20的用户的电子钱币账户余额(不限定，第二帐户的余额的一例)，将表示共同钱包余额与自己的终端20的用户的电子钱币账户余额的余额不足的结算余额不足信息(不限定，与共同帐户和第二帐户的余额不足相关的第一信息的一例)显示于显示部24。进而，终端20基于由自己的终端20的用户针对结算余额不足信息进行的输入，通过控制部21来执行向自己的终端20的用户的电子钱币账户进行充值的处理(不限定，向第二帐户转账的处理的一例)。
作为通过这样的结构而得到的效果的一例，能够向终端的用户通知共同帐户和第二帐户的余额不足。另外，能够基于由终端的用户针对第一信息进行的输入而向第二帐户转账。
＜第七变形例(4)＞
在第七实施例和第七变形例(3)中，在通过统合帐户进行支付时，即便在共同钱包余额不足而使用用户的电子钱币账户的余额进行了垫付的情况下，也不会向共同钱包的其他用户(作为非限定的例子为用户B.B)请求垫付部分，但也可以请求垫付部分，还可以不采用这种方式。
在该情况下，在处理的后半部分，代替图6-2的流程而执行图6-7的流程即可。
＜第七变形例(5)＞
在第七变形例(3)中，当统合帐户中的支付失败时，向自身的帐户执行充值，使统合帐户的余额增加，由此来弥补余额不足，但也可以不采用这种方式。
作为非限定的例子，也可以通过向其他的共同钱包成员委托向共同钱包转账来弥补余额不足。
图7-6是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、终端B(作为非限定的例子，为用户B.B的终端20)的控制部21所执行的结算联合处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
需要说明的是，关于处理的前半部分，作为非限定的例子而能够与图7-4相同，关于处理的后半部分，作为非限定的例子而能够与图6-2相同，因此，这里省略说明。
终端A的控制部21在执行A290的步骤后，执行A360～A380的步骤，当通过通信I/F22从服务器10接收到统合帐户结算结果信息时，执行A480以后的步骤。
终端B的控制部21执行B140～B170的步骤，结束处理。
服务器10的控制部11在执行S340～S390的步骤后，通过通信I/F14从店铺读码器装置50接收结算请求信息，执行S500a以后的步骤。
需要说明的是，关于处理的各步骤，能够与图4-19同样地执行，因此，省略详细的说明。
另外，作为处理的后半部分，也可以代替图6-2的流程而执行图6-9、图4-21的流程，由此在使用其他用户的电子钱币账户的余额而进行了垫付的情况下，向进行了支付的终端A的用户A.A请求垫付部分，还可以不采用这种方式。
另外，在虽然向其他的共同钱包成员委托了向共同钱包转账但没有被该共同钱包成员认可向共同钱包转账的情况下，也可以在委托了转账的终端20中不将统合帐户代码信息显示于显示部24或者不执行与自此以后的结算相关的处理。
＜第七变形例(6)＞
在第七变形例(3)中，当统合帐户中的支付失败时，向自身的帐户执行充值，使统合帐户的余额增加，由此来弥补余额不足，但也可以不采用这种方式。
作为非限定的例子，也可以对由共同钱包和自身的电子钱币账户构成的统合帐户进一步添加其他的共同钱包成员的电子钱币账户。
图7-7～图7-8是示出在本变形例中由各装置执行的处理流程的一例的流程图。从左侧依次分别示出终端A(作为非限定的例子，为用户A.A的终端20)的控制部21所执行的结算处理、服务器10的控制部11所执行的结算管理处理、作为店铺POS系统(作为非限定的例子，为加盟店S1的店铺POS系统40)的结构要素的店铺读码器装置50的控制部51所执行的店铺结算处理的一例。
需要说明的是，关于处理的前半部分，作为非限定的例子而能够与图7-4相同，因此，这里省略说明。
终端A的控制部21在执行A290的步骤后，使是否进一步向统合帐户统合其他的电子钱币账户(作为非限定的例子为用户B.B的电子钱币账户)的选择用画面显示于显示部24(A620)。以下，将向统合帐户进一步追加电子钱币账户称为“帐户重新统合”。
在针对终端A的输入输出部23的用户操作而选择了重新统合帐户的情况下(A620：是)，终端A的控制部21通过通信I/F22向服务器10发送包括统合方的统合帐户ID和要追加的用户的支付应用ID的帐户重新统合委托信息。
基于针对终端A的输入输出部23的用户操作而没有选择重新统合帐户的情况下(A620：否)，终端A的控制部21通过通信I/F22从服务器10接收统合帐户结算结果信息，执行图6-2的A480的步骤。
在通过通信I/F14从终端A接收到帐户重新统合委托信息的情况下(S710：是)，服务器10的控制部11执行帐户重新统合处理(S720)。
在没有接收到帐户重新统合委托信息的情况下(S710：否)，服务器10的控制部11通过通信I/F14从店铺读码器装置50接收结算请求信息，执行S500a以后的步骤。
在帐户重新统合处理中，服务器10的控制部11从统合帐户管理数据库159中检索具有统合方的统合帐户ID的统合帐户管理数据的记录，向该记录的统合帐户成员ID追加用户B.B的支付应用ID并存储。统合帐户的余额成为进一步加上追加到统合帐户成员ID的支付应用ID的电子钱币余额而得到的金额。
然后，服务器10的控制部11通过通信I/F14向终端A发送包括重新统合后的统合帐户的电子钱币余额的重新统合帐户信息(S730)。
终端A的控制部21在通过通信I/F22从服务器10接收到重新统合帐户信息时，将重新统合后的统合帐户的电子钱币余额更新并显示于显示部24(A640)。然后，店铺读码器装置50的控制部11执行P140～P160的步骤，结束处理。
需要说明的是，服务器10的控制部11也可以在执行帐户重新统合处理时，重新生成包括统合帐户支付令牌和新的统合帐户支付令牌的统合帐户代码信息，通过通信I/F14向终端A进行发送。在该情况下，终端A的控制部21在通过通信I/F22从服务器10接收到统合帐户代码信息时，将统合帐户代码信息更新并显示于显示部24。
当通过通信I/F14从店铺读码器装置50接收到结算请求信息时，服务器10的控制部11执行重新统合帐户结算处理(S740)。
在统合帐户结算处理中，服务器10的控制部11根据接受了请求的统合帐户支付令牌来检索统合帐户ID。服务器10的控制部11进一步基于与统合帐户ID绑定的统合帐户成员ID(这里为用户A.A的支付应用ID、用户B.B的支付应用ID以及共同钱包的共同钱包ID)，使用由统合帐户成员ID指示的用户A.A的电子钱币账户余额、用户B.B的电子钱币账户余额以及共同钱包余额的合计额，针对统合帐户执行与由店铺ID决定的加盟店之间进行结算预定金额的支付的结算处理。
在统合帐户中的结算成功的情况下，服务器10的控制部11使共同钱包余额减少结算预定金额。
另一方面，在共同钱包余额未达到结算预定金额的情况下，作为非限定的例子，服务器10的控制部11在支付中优先地使用共同钱包余额并且共同钱包余额成为“0”之后，由用户A.A的电子钱币账户余额和用户B.B的电子钱币账户余额均摊(均等分配)而扣除不足部分(＝结算预定金额-共同钱包余额)。
接着，作为非限定的例子，服务器10的控制部11通过通信I/F14向店铺读码器装置50发送包括结算处理的成功与否和结算处理后的进行了重新统合的统合帐户余额的结算结果信息(S750)。
另外，作为非限定的例子，服务器10的控制部11通过通信I/F14向终端A发送包括结算处理的成功与否、结算处理后的构成统合帐户的各用户的电子钱币账户/共同钱包余额、以及各个电子钱币账户/共同钱包中的支付额的重新统合帐户结算结果信息(S760)，结束处理。
当通过通信I/F22从服务器10接收到重新统合帐户结算结果信息时，终端A的控制部21使重新统合帐户结算结果信息显示于显示部24(A650)，结束处理。
需要说明的是，在帐户重新统合中，能够向统合帐户追加的电子钱币账户不限定于用户帐户。也可以追加其他的共同钱包，还可以不采用这种方式。
本变形例示出以下的结构：在结算时，从共同钱包余额、自己的终端20的用户的用户帐户的电子钱币账户余额、以及不同的终端20的用户的用户帐户的电子钱币账户余额中的共同钱包余额(不限定，共同帐户的余额的一例)优先地进行支付。
作为通过这样的结构而得到的效果的一例，由于从共同帐户的余额优先地进行支付，因此，能够将其他帐户作为随附的帐户。
另外，本变形例示出以下的结构：终端20基于包括自己的终端20的用户的用户帐户(不限定，第二帐户的一例)及其他的共同钱包成员的用户帐户在内的、共同钱包成员的各个用户帐户和共同帐户，通过控制部21来执行与结算相关的处理。
作为通过这样的结构而得到的效果的一例，可基于共同帐户和包括第二帐户在内的、能够通过共同帐户进行结算的用户的各个帐户和实现结算。
另外，本变形例示出统合帐户代码信息(不限定，第一代码信息的一例)与共同钱包成员的各个用户帐户建立关联的结构。
作为通过这样的结构而得到的效果的一例，可使与通过共同帐户能够结算的用户的各个帐户建立了关联的第一代码信息用于结算。
另外，本变形例示出以下的结构：通过共同钱包成员的各个用户帐户均摊(均等分配)而扣除共同钱包余额的不足部分，执行基于结算的支付。
作为通过这样的结构而得到的效果的一例，共同帐户的余额的不足部分被均等地分配给通过共同帐户能够结算的用户的各个帐户，因此，能够实现公平的结算。
＜第七变形例(7)＞
在第七变形例(6)中，在曾使用统合帐户尝试支付并失败之后，进行将共同钱包与两个以上的用户的电子钱币账户统合的帐户重新统合处理以及使用重新统合帐户的支付，但不限定于此。
作为非限定的例子，也可以在图6-1之后进行帐户的重新统合。
＜第七变形例(8)＞
在应用利用者提示型的代码结算的情况下，也可以是，终端20将与自己的终端20的用户的用户帐户建立了关联的代码信息(支付码等)(不限定，与第二帐户建立了关联的第三代码信息的一例)显示于显示部24。另外，作为非限定的例子，终端20在与其相同的画面中显示与共同钱包相关的信息(共同钱包ID等)(不限定，共同帐户信息的一例)。进而，终端20基于由自己的终端20的用户针对所显示的与共同钱包相关的信息进行的输入，作为非限定的例子，将使共同帐户与自己的终端20的用户的用户帐户建立了关联的统合帐户代码信息(不限定，第一代码信息的一例)显示于显示部24，还可以不采用这种方式。
同样，在应用店铺提示型的代码结算的情况下，也可以是，终端20将基于与自己的终端20的用户的用户帐户建立了关联的读码器信息的、用于读取支付店铺码的读码器画面(不限定，与第二帐户建立了关联的第三读码器画面的一例)显示于显示部24。另外，作为非限定的例子，终端20在与其相同的画面中显示与共同钱包相关的信息(共同钱包ID等)。然后，终端20基于由自己的终端20的用户针对所显示的与共同钱包相关的信息进行的输入，作为非限定的例子，将基于使共同帐户与自己的终端20的用户的用户帐户建立了关联的统合帐户读码器信息的、用于读取支付店铺码的读码器画面(不限定，第一读码器画面的一例)显示于显示部24，还可以不采用这种方式。
作为通过这样的结构而得到的效果的一例，能够将与第二帐户建立了关联的第三代码信息或者第三读码器信息显示于终端的显示区域而用于结算。另外，能够基于由终端的用户针对共同帐户信息进行的输入，将使终端的用户能够结算的第一帐户与不同于第一帐户的第二帐户建立了关联的第一代码信息、或者作为与代码信息的读取相关的显示的第一读码器信息显示于终端的显示区域而用于结算。
另外，在上述中，在应用利用者提示型的代码结算的情况下，也可以是，终端20代替与自己的终端20的用户的用户帐户建立了关联的代码信息(支付码等)，作为非限定的例子而显示与共同帐户建立了关联的共同钱包码信息(不限定，与第一帐户建立了关联的第三代码信息的一例)，还可以不采用这种方式。
另外，在上述中，在应用店铺提示型的码结算的情况下，也可以是，终端20代替基于与自己的终端20的用户的用户帐户建立了关联的读码器信息的、用于读取支付店铺码的读码器画面，作为非限定的例子而显示基于共同钱包读码器信息的、用于读取支付店铺码的读码器画面(不限定，与第一帐户建立了关联的第三代码信息的一例)，还可以不采用这种方式。
作为通过这样的结构而得到的效果的一例，能够将与第一帐户建立了关联的第三代码信息或者第三读码器信息显示于终端的显示区域而用于结算。另外，能够基于由终端的用户针对共同帐户信息进行的输入，将使终端的用户能够结算的第一帐户与不同于第一帐户的第二帐户建立了关联的第一代码信息或者作为与代码信息的读取相关的显示的第一读码器信息显示于终端的显示区域而用于结算。
＜第七变形例(9)＞
在第七实施例中，也能够与第四变形例(9)同样地代替代码结算而通过无线通信(包括近距离无线通信。)进行结算。
这通过将第四变形例(9)中说明的处理应用于第七实施例中说明的帐户统合而能够同样地实现。
＜第八实施例＞
第八实施例是与上述的垫付金额的请求/转账关联的实施例。垫付金额的请求/转账也能够应用于上述的第二实施例～第七实施例中的任意一个实施例。
在第八实施例中，共同钱包成员的终端20利用支付应用，从共同钱包的电子钱币余额执行加盟店中的支付。在支付时共同钱包的电子钱币余额不足的情况下，通过从用户的电子钱币账户向共同钱包进行转账来弥补共同钱包的余额不足。
在此基础上，在第八实施例中，在废弃共同钱包的情况下，从用户的电子钱币账户余额请求垫付的金额。
第八实施例所记载的内容也能够应用于其他的各实施例或其他的各变形例中的任意一个。
另外，针对与已经出现的结构要素相同的结构要素标注相同的标号并省略再次的说明。
“共同钱包的废弃”是指使结束共同钱包，更具体而言，作为非限定的例子，是指为了以后不使用共同钱包而将其删除。
作为非限定的例子，执行根据来自共同钱包成员的代表者的终端20或其他的共同钱包成员的终端20的废弃委托而将在服务器10中存储/管理的共同钱包的数据删除的共同钱包废弃处理。
关于每一次的共同钱包成员的终端中的支付处理，作为非限定的例子，能够与第四实施例的图4-4～图4-5同样地执行，因此，这里省略详细的说明。
＜数据结构＞
图8-1是示出在本实施例中存储于服务器10的存储部15的共同钱包管理数据库157的一例即第二共同钱包管理数据库157B的数据结构例的图。
在第二共同钱包管理数据库157B中作为每个共同钱包ID的管理数据而存储有共同钱包管理数据。
作为非限定的例子，在各个共同钱包管理数据中关联地存储有共同钱包ID、共同钱包名、共同钱包余额、共同钱包成员ID以及垫付历史数据。
共同钱包ID、共同钱包名、共同钱包余额以及共同钱包成员ID与第一共同钱包管理数据库157A是同样的。
垫付历史数据是用于记录在使用该共同钱包进行支付并且由于共同钱包余额不足而从用户的电子钱币账户余额垫付了结算预定金额的一部分或全部的情况下对该共同钱包执行的垫付支付的历史的数据，作为非限定的例子，关联地存储有垫付者ID、垫付者名、垫付日期时间以及垫付金额。
垫付者ID是用于识别针对该共同钱包的余额不足使用自身的电子钱币账户余额执行垫付支付的执行者(垫付者)的识别符，作为非限定的例子，存储有进行垫付支付的用户的支付应用ID。
垫付者名是垫付者的名称，作为非限定的例子，存储有与垫付者ID对应的用户名。
垫付日期时间是记录进行垫付支付的日期时间的项目，作为非限定的例子，存储有服务器10的控制部11执行了图4-5的S170a的步骤的日期时间。
垫付金额是产生共同钱包余额不足而从用户的电子钱币账户余额垫付的金额，作为非限定的例子，存储有在图4-4的S250a的步骤中计算出的结算余额不足额。
设为在共同钱包成员的终端(作为非限定的例子为用户A.A的终端A)中，按照图4-4～图4-5而执行结算处理(第一结算处理)。进而，作为非限定的例子，设为在图4-4的S250a的步骤中结算处理失败且结算余额不足额为“1，000日元”。
在图4-5的S170a的步骤中结算处理成功时，服务器10的控制部11将正在执行结算处理的支付应用ID(在该例中为作为用户A.A的支付应用ID的“U0001”)、该用户名(在该例中为“A.A”)、执行了结算处理的日期时间(在该例中为“2020/5/1/＊＊：＊＊：＊＊”)、以及在图4-4的S270a的步骤中发送的结算余额不足额(＝垫付金额)(在该例中为“1，000日元”)建立关联地追记到垫付历史数据中。
需要说明的是，在结算余额不足额为“0”或者在图4-5的S170a的步骤中结算处理失败的情况下，不执行向垫付历史数据的追记处理。
另外，设为在终端B中，按照图4-4～图4-5而执行另一个结算处理(第二结算处理)。在该情况下，作为非限定的例子，在将结算余额不足额设为“3，000日元”且通过从用户B.B的电子钱币账户向共同钱包转账而使结算处理成功的情况下，服务器10的控制部11将正在执行结算处理的支付应用ID(在该例中为作为用户B.B的支付应用ID的“U0002”)、该用户名(在该例中为“B.B”)、执行了结算处理的日期时间(在该例中为“2020/5/5/＊＊：＊＊：＊＊”)、以及结算余额不足额(＝垫付金额)(在该例中为“3，000日元”)建立关联地追记到垫付历史数据中。
在任意一个共同钱包成员的终端20(作为非限定的例子为用户A.A的终端A)中选择了废弃共同钱包时，终端A的控制部21通过通信I/F22向服务器10发送共同钱包废弃申请信息。
当通过通信I/F14从终端A接收到共同钱包废弃申请信息时，服务器10的控制部11针对存储于垫付历史数据的各个垫付金额而执行垫付金额的请求处理。
作为非限定的例子，在图8-1所例示的第二共同钱包管理数据库157B中，基于垫付历史数据，首先对终端B请求作为“2020/5/1/＊＊：＊＊：＊＊”的支付垫付额的“500日元”(＝1，000日元÷2名)。接着，对终端A请求作为“2020/5/5/＊＊：＊＊：＊＊”的支付垫付额的“1，500日元”(＝3，000日元÷2名)。
关于单独的请求处理，作为非限定的例子，能够与图4-9同样地执行，因此，省略详细的说明。
需要说明的是，作为非限定的例子，在终端A中选择废弃共同钱包时选择了不进行自身的垫付金额的请求的情况下，服务器10的控制部11也可以通过对终端B发送包括不请求“2020/5/1/＊＊：＊＊：＊＊”的支付垫付额这一旨意的信息等而不执行请求处理。
当针对存储于垫付历史数据的全部的垫付金额执行了垫付金额的请求处理时，服务器10的控制部11执行共同钱包废弃处理。
需要说明的是，终端所执行的支付处理不限定于第四实施例，也能够应用于第二实施例～第七实施例中的任意一个实施例。
在伴随帐户统合处理的情况下，作为垫付金额，使用由用户的电子钱币账户余额垫付的金额即可。
＜第八实施例的效果＞
第八实施例示出基于共同钱包的废弃(不限定，共同帐户的废弃的一例)向第二终端20(接受请求的终端20)发送支付垫付额请求信息的结构。
作为通过这样的结构而得到的效果的一例，能够基于共同帐户的废弃，向终端发送基于结算的请求信息。
另外，第八实施例示出以下的结构：上述的支付垫付额请求信息是针对第二终端20的用户的支付垫付额请求信息(不限定，第一请求信息的一例)，基于共同帐户和第二终端20(请求方的终端20)的用户的用户帐户(不限定，第二帐户的一例)而执行与结算相关的处理(不限定，与第二结算相关的处理的一例)，基于共同钱包的废弃，向第一终端20(不限定，第一终端的一例)发送基于由第二终端20的用户进行的结算(不限定，第二结算的一例)的、针对第一终端20的用户的支付垫付额请求信息(不限定，与第一请求信息不同的第二请求信息的一例)。
作为通过这样的结构而得到的效果的一例，能够基于共同帐户的废弃，向第一终端发送基于第二结算的、不同于第一请求信息的第二请求信息。
另外，本实施例示出终端20通过通信I/F22向共同钱包成员的终端20的至少一个终端20发送包括不请求支付垫付额这一旨意的信息(不限定，与变更请求信息相关的信息的一例)的结构。
作为通过这样的结构而得到的效果的一例，通过向能够由共同帐户结算的用户的终端的至少一个终端发送与变更请求信息相关的信息，能够通知变更请求信息。
＜第八变形例(1)＞
在第八实施例中，在废弃共同钱包的情况下，执行了目前为止使用共同钱包执行的垫付金额的请求，但不限定于此。
在本变形例中，共同钱包成员的终端20利用支付应用，从共同钱包的电子钱币余额或者共同钱包与用户的电子钱币账户的统合帐户的电子钱币余额执行加盟店中的支付。进而，在进行共同钱包废弃操作时，基于从用户帐户向共同钱包的转账额和由用户帐户垫付的垫付金额，向用户帐户分配共同钱包余额而进行转账(退还)。
以下，将从用户帐户向共同钱包转账称为“向共同钱包的出资”，将该转账额称为“出资金额”。
关于每一次的共同钱包成员的终端中的支付处理，作为非限定的例子，能够与第六实施例的图6-1、图6-2、图4-5同样地执行，因此，这里省略详细的说明。
图8-2是示出服务器10的存储部15所存储的作为共同钱包管理数据库157的一例的第三共同钱包管理数据库157C的数据结构例的图。
在第三共同钱包管理数据库157C中存储有共同钱包管理数据作为每个共同钱包ID的管理数据。
在各个共同钱包管理数据中，作为非限定的例子，关联地存储有共同钱包ID、共同钱包名、共同钱包余额、共同钱包成员ID、共同钱包生成日期时间、出资历史数据以及支付历史数据。
共同钱包ID、共同钱包名、共同钱包余额以及共同钱包成员ID与第一共同钱包管理数据库157A是同样的。
在共同钱包生成日期时间中存储有生成了共同钱包的日期时间。
出资历史数据是对该共同钱包执行的出资的历史数据，作为非限定的例子，关联地存储有出资者ID、出资者名、出资日期时间以及出资金额。
出资者ID是用于识别对该共同钱包执行出资的执行者(出资者)的识别符，作为非限定的例子，存储有进行出资的用户的支付应用ID。
出资者名是出资者的名称，作为非限定的例子，存储有与出资者ID对应的用户名。
出资日期时间是进行出资的日期时间，作为非限定的例子，存储有出资者执行了向共同钱包的出资的日期时间。
出资金额是每次出资者执行的向该共同钱包的出资的出资金额。
在图8-2中，作为非限定的例子，示出针对共同钱包“露营资金”，用户A.A在“2020/3/11/＊＊：＊＊：＊＊”出资了“3，000日元”，在“2020/4/14/＊＊：＊＊：＊＊”出资了“3，000日元”。另外，作为非限定的例子，示出用户B.B在“2020/3/12/＊＊：＊＊：＊＊”出资了“3，000日元”，在“2020/4/14/＊＊：＊＊：＊＊”出资了“3，000日元”。
支付历史数据是使用该共同钱包而执行的已成立的支付的历史数据，作为非限定的例子，关联地存储有支付者ID、店铺名、支付日期时间、支付金额、垫付金额以及回收标志。
支付者ID是用于识别在加盟店中使用该共同钱包执行支付的执行者(支付者)的识别符，作为非限定的例子，存储有进行支付的用户的支付应用ID。
店铺名是用于识别被进行支付的加盟店的名称，作为非限定的例子，存储有加盟店在支付应用利用注册时进行注册的该店铺或者服务的名称。
支付日期时间是在该店铺名的加盟店中支付者通过支付应用执行支付的日期时间，作为非限定的例子，存储有在服务器10的控制部11中执行了结算处理或统合帐户结算处理并成功的日期时间。
支付金额是在该店铺名的加盟店中通过支付应用执行支付的结算预定金额，作为非限定的例子，存储有基于服务器10的控制部11通过通信I/F14从店铺读码器装置50接收到的结算请求信息的结算预定金额。
垫付金额是在从共同钱包与用户的电子钱币账户的统合帐户的电子钱币余额执行支付的情况下由于共同钱包余额不足而从用户的电子钱币账户余额垫付的金额，作为非限定的例子，存储有基于统合帐户结算处理的结果的、从支付者的电子钱币账户支付的支付额。需要说明的是，在不执行统合帐户结算处理的情况下，垫付金额为“0”。
回收标志是用于记录在垫付金额大于“0”的情况下是否在每次支付时进行垫付金额的请求并完成了细算的标志信息，作为非限定的例子，在服务器10的控制部11中执行细算转账处理并成功的情况下，作为非限定的例子，存储有“已”。在服务器10的控制部11中未进行细算转账处理或者细算请求处理失败的情况下，作为非限定的例子，存储有“未”。另外，在垫付金额为“0”的情况下，无需执行细算，因此，作为非限定的例子，存储有“-”。
关于每次支付的垫付金额的请求处理，作为非限定的例子，能够与图6-7同样地执行，因此，省略详细的说明。
作为非限定的例子，在图8-2中，在支付历史数据中，示出支付者“U0001”(即用户A.A)使用共同钱包“露营资金”在“2020/4/5/＊＊：＊＊：＊＊”在店铺“EE超市”进行了“5，000日元”的支付。另外，示出支付者“U0001”(即用户A.A)在“2020/4/11/＊＊：＊＊：＊＊”在店铺“AA运动”中进行了“3，000日元”的支付并通过用户A.A的电子钱币账户垫付了“2，000日元”，是垫付部分的细算仍未完成的“未”。
作为非限定的例子，当通过通信I/F14从终端A接收到共同钱包废弃申请信息时，服务器10的控制部11基于第三共同钱包管理数据库157C的共同钱包管理数据，执行共同钱包细算废弃处理。
在共同钱包细算废弃处理中，首先按照每个出资历史数据的出资者ID而计算每个出资者的合计出资金额。接着，按照每个支付历史数据的支付者ID而计算每个支付者的合计垫付金额。需要说明的是，在合计垫付金额的计算中，仅将回收标志成为“未”的垫付金额作为合算对象。
作为非限定的例子，在图8-2中，用户A.A的合计出资金额成为“6，000日元”(＝3，000日元+3，000日元)，用户B.B的合计出资金额成为“6，000日元”(＝3，000日元+3，000日元)。另外，用户A.A的合计垫付金额成为“2，000日元”，用户B.B的合计垫付金额成为“6，000日元”。
接着，将全部的共同钱包成员的合计出资金额与合计垫付金额合在一起的金额计算作为共同钱包“露营资金”的总出资金额。作为非限定的例子，在图8-2中，总出资金额为“20，000日元”(＝6，000日元+6，000日元+2，000日元+6，000日元)。
之后，根据“(总出资金额-共同钱包余额)÷共同钱包成员人数”来计算在执行共同钱包细算废弃处理的时间点从共同钱包支出的每一个共同钱包成员的平均支付额。
作为非限定的例子，在图8-2中，平均支付额成为“(20，000日元-6，000日元)÷2＝7，000日元”。
接着，按照存储于共同钱包成员ID的每个支付应用ID，计算用于基于出资额的比例退还共同钱包余额的退还预定额。通过“(合计出资金额+合计垫付金额)-平均支付额”来计算退还预定额。
退还预定额成为从各个用户对共同钱包直接出资的金额(合计出资金额)与通过垫付而间接出资的金额(合计垫付金额)的合计减去对共同钱包中的支付金额进行了均等分配的金额而得到的金额。
作为非限定的例子，在图8-2中，向用户A.A退还的退还预定额成为“6，000日元+2，000日元-7，000日元＝1，000日元”，向用户B.B退还的退还预定额成为“6，000日元+6，000日元-7，000日元＝5，000日元”。
最后，服务器10的控制部11执行使用共同钱包余额向共同钱包成员的各个电子钱币账户转账退还预定额的退还处理。
需要说明的是，在退还预定额成为负的情况下，通过将退还预定额的绝对值作为转账金额而从该用户的电子钱币账户向共同钱包转账，来进行细算。
在执行共同钱包细算废弃处理且共同钱包余额成为“0”后，服务器10的控制部11执行共同钱包废弃处理。
需要说明的是，终端所执行的支付处理不限定于第六实施例，也能够应用于第二实施例～第七实施例中的任意一个实施例。
在执行向共同钱包的转账处理的情况下，作为垫付金额而存储结算余额不足额即可，该结算余额不足额是在使共同钱包中的支付成立而至少需要向共同钱包转账的金额。
＜显示画面例＞
图8-3是示出在图3-3的露营资金支付画面中由终端20的用户A.A对表示为“钱包废弃”的图标进行了触摸操作的情况下显示的露营资金的概要显示画面的一例的图。以下说明的显示画面例是应用了图8-2的例子的画面图。
在该例中，在标题栏的下方，显示有作为当前执行中的子菜单的“露营资金”来作为“Payment App”的分层菜单中的当前位置。另外，在“露营资金”的下方显示有“钱包废弃”作为针对用户的操作引导，在“钱包废弃”的下方显示有露营资金的概要显示区域2452。
露营资金的概要显示区域2452分为三层来显示，在上层显示有“2020年4月15日”作为当前的日期，在其下方显示有方形钱包的图像和共同钱包的名称(露营资金)的概要。
在中层，与“余额”的文字一起显示有“6，000日元”作为露营资金的共同钱包余额。另外，在它们的横侧显示有“2020年3月11日”作为制作日，在制作日的下方显示有“2人”作为露营资金的共同钱包成员的人数。而且，在露营资金的共同钱包成员的人数的下方，显示有作为共同钱包成员的用户A.A的图标图像和用户B.B的图标图像。
另外，在下层，显示有“20，000日元”作为总出资金额，并且显示有“14，000日元”作为总支付金额。作为非限定的例子，总支付金额为通过“总出资金额-共同钱包余额”而计算出的金额。
另外，在露营资金的概要显示区域2452的下方，以列表形式显示有向各个成员退还的退还预定额。
在退还预定额的第一行，与用户A.A的图标图像一起显示有用户名“自己”的文字，在“自己”的横侧，在该例中显示有“1，000日元”作为退还预定额。另外，在“1，000日元”的横侧，并排显示有用于修正自己的退还预定额的修正按钮BT9和用于确认自己的退还预定额的详情的详细按钮BT10。
另外，在退还预定额的第二行，与用户B.B的图标图像一起显示有用户名“B.B”的文字，在“B.B”的横侧，在该例中显示有“5，000日元”作为退还预定额。另外，在“5，000日元”的横侧，与用户A.A同样地并排显示有修正按钮BT9和详细按钮BT10。
另外，在画面下部，并排显示有用于取消共同钱包的废弃的取消按钮242R和用于执行共同钱包的废弃的废弃按钮242S。
图8-4是示出在图8-3的露营资金的概要显示画面中对自己的行中的详细按钮BT10进行了触摸操作的情况下显示的自己的概要显示画面的一例的图。
在该例中，自己的概要显示区域2453分为两层来显示，在上层显示有“2020年4月15日”作为当前的日期，在其下方，与用户A.A的图标图像一起显示有用户名“自己”的文字。在下层，显示有“出资金额”的文字作为出资金额，并且在“出资金额”的横侧显示有作为用户A.A的合计出资金额的“6，000日元”。
另外，在“出资金额”的下方，显示有“支付金额”的文字作为支付金额，并且在“支付金额”的横侧，显示有作为使用了共同钱包“露营资金”的用户A.A的支付金额的合计额的“8，000日元”。在“支付金额”的下方，显示有“垫付金额”的文字作为垫付金额，并且在“垫付金额”的横侧显示有作为用户A.A的合计垫付金额的“2，000日元”。
另外，在自己的概要显示区域2453的下方，以列表形式按照时间序列顺序显示有自己的利用历史。在第一行，显示有“2020年3月11日20时55分”作为利用日的日期时间，在利用日的日期时间的下方，显示有“出资”的文字作为利用项目，并且显示有“3，000日元”作为出资金额。
在第二行，显示有“2020年4月5日11时12分”作为利用日的日期时间，在利用日的日期时间的下方，显示有“支付”的文字作为利用项目，并且显示有“EE超市”作为支付对方。另外，在“EE超市”的横侧，显示有“5，000日元”作为支付金额。
在第三行，显示有“2020年4月11日16时30分”作为利用日的日期时间，在利用日的日期时间的下方，显示有“支付”的文字作为利用项目，并且显示有“AA运动”作为支付对方。在“AA运动”的横侧，显示有“3，000日元”作为支付金额。另外，在它们的下方，显示有“垫付”的文字作为利用项目，并且显示有“2，000日元”作为垫付金额。
在第四行，显示有“2020年4月14日12时21分”作为利用日的日期时间，在利用日的日期时间的下方，显示有“出资”的文字作为利用项目，并且显示有“3，000日元”作为出资金额。
另外，在自己的概要显示区域2453的最下部，显示有返回图标242T。
图8-5是示出在图8-3的露营资金的概要显示画面中对用户B.B的行中的详细按钮BT10进行了触摸操作的情况下显示的用户B.B的概要显示画面的一例的图。
在该例中，针对用户B.B的概要显示画面进行说明，但显示形式与上述的自己的概要显示画面相同。
在用户B.B的概要显示画面中，用户B.B的概要显示区域2454分为两层来显示，在上层，显示有“2020年4月15日”作为当前的日期，在其下方，与用户B.B的图标图像一起显示有用户名“B.B”的文字。在下层，显示有“出资的金额”的文字作为出资金额，并且在“出资的金额”的横侧显示有作为用户B.B的合计出资金额的“6，000日元”。
另外，在“出资的金额”的下方显示有“支付金额”的文字作为支付金额，并且，在“支付金额”的横侧显示有作为使用了共同钱包“露营资金”的用户B.B的支付金额的合计额的“6，000日元”。在“支付金额”的下方，显示有“垫付金额”的文字作为垫付金额，并且在“垫付金额”的横侧，显示有作为用户B.B的合计垫付金额的“6，000日元”。
另外，在用户B.B的概要显示区域2454的下方，以列表形式按照时间序列顺序显示有用户B.B的利用历史。在第一行，显示有“2020年3月12日8时24分”作为利用日的日期时间，在其下方，显示有“出资”的文字作为利用项目，并且显示有“3，000日元”作为出资金额。
在第二行，显示有“2020年4月12日12时5分”作为利用日的日期时间，在利用日的日期时间的下方，显示有“支付”的文字作为利用项目，并且显示有“BB家居建材中心”作为支付对方。另外，在“BB家居建材中心”的横侧，显示有“6，000日元”作为支付金额。另外，在它们的下方，显示有“垫付”的文字作为利用项目，并且显示有“6，000日元”作为垫付金额。
在第三行，显示有“2020年4月14日15时38分”作为利用日的日期时间，在利用日的日期时间的下方，显示有“出资”的文字作为利用项目，并且显示有“3，000日元”作为出资金额。
另外，在用户B.B的概要显示区域2454的最下部显示有返回图标242T。
本变形例示出以下的结构：基于终端20的用户的输入，执行基于支付垫付额请求信息的向共同钱包转账的转账处理。在在共同钱包中包括通过由第一终端20的用户进行的结算(不限定，第一结算的一例)而从第一终端20的用户帐户支付的金额以上或者比该金额多的金额的情况下，从共同钱包向第一终端20的用户帐户(不限定，第一帐户的一例)转账通过由第一终端20的用户进行的结算而从第一终端20的用户的用户帐户支付的金额。
作为通过这样的结构而得到的效果的一例，在在共同帐户中包括通过第一结算从第一帐户支付的金额以上或者比该金额多的金额的情况下，能够从共同帐户向第一帐户转账通过第一结算从第一帐户支付的金额。
另外，本变形例示出以下的结构：终端20经由服务器10通过通信I/F22向其他的终端20发送用于修正向自己的终端20的用户退还的退还预定额的信息(不限定，与变更关于退还的信息相关的信息的一例)。
作为通过这样的结构而得到的效果的一例，通过向能够由共同帐户结算的用户的终端的至少一个终端发送与变更退还信息相关的信息，能够通知变更退还信息。
＜第八变形例(2)＞
在第八变形例(1)中，服务器10的控制部11执行使用共同钱包余额向共同钱包成员的各个电子钱币账户转账退还预定额的退还处理，但不限定于此。作为非限定的例子，也可以执行以下那样的处理。
在废弃共同钱包的情况下，服务器10的控制部11执行向各个用户临时退还对共同钱包余额进行了均等分配的金额(以下称为“人均临时退还额”。)的临时退还处理。然后，控制部11基于该人均临时退还额和在第八变形例(1)中说明的退还预定额(＝(合计出资金额+合计垫付金额)-平均支付额)，来计算/决定各个用户的转账额/收款额。然后，通过使终端20执行基于计算/决定出的转账额/收款额的转账处理/收款处理，来调整最终的金额。
以图8-2所示的金额的例子进行说明。
由于废弃共同钱包时的共同钱包余额为“6，000日元”，因此，服务器10的控制部11将人均临时退还额设为“6000日元÷2名＝3000日元”，临时退还给用户A.A和用户B.B。
另一方面，在图8-2的例子中，向用户A.A退还的退还预定额为“6，000日元+2，000日元-7，000日元＝1，000日元”，向用户B.B退还的退还预定额为“6，000日元+6，000日元-7，000日元＝5，000日元”。因此，用户A.A多出2，000日元，而用户B.B缺少2，000日元。于是，控制部11通过通信I/F14向用户A.A的终端20和用户B.B的终端20分别发送通知从用户A.A的用户帐户向用户B.B的用户帐户转账“2，000日元”的信息。然后，控制部11从用户A.A的电子钱币账户余额减去“2，000日元”，并且向用户B.B的电子钱币账户余额加上“2，000日元”。然后，控制部11执行共同钱包废弃处理。
本变形例示出以下的结构：在废弃共同钱包的情况下，第二终端20基于从第一终端20(不限定，第一终端的一例)转账到共同钱包的金额(不限定，第二金额的一例)的信息和从第二终端20转账到共同钱包的金额(不限定，第一金额的一例)的信息，通过通信I/F22来接收通知从第二终端20的用户的用户帐户向第一终端20的用户的用户帐户转账的信息(不限定，与从终端的用户向第一终端的第一用户转账相关的信息的一例)、或者通知从第一终端20的用户的用户帐户向第二终端20的用户的用户帐户转账的信息(不限定，与从第一终端的第一用户向终端的用户转账相关的信息的一例)。
作为通过这样的结构而得到的效果的一例，能够实现针对共同帐户的转账。另外，在废弃共同帐户的情况下，能够至少基于从第一终端转账到共同帐户的第二金额的信息和第一金额的信息，接收与从用户向第一用户转账相关的信息或者与从第一用户向用户转账相关的信息，并报知给终端的用户。
另外，本变形例示出以下的结构：通知从上述的第二终端20的用户的用户帐户向第一终端20的用户的用户帐户转账的信息、或者通知从第一终端20的用户的用户帐户向第二终端20的用户的用户帐户转账的信息是基于从第二终端20转账到共同钱包的金额(不限定，第一金额的一例)、从第一终端20转账到共同钱包的金额(不限定，第二金额的一例)以及共同钱包余额(不限定，共同帐户的余额的一例)而决定的。
作为通过这样的结构而得到的效果的一例，能够基于第一金额、第二金额以及共同帐户的余额，来适当地决定与从用户向第一用户转账相关的信息、或者与从第一用户向用户转账相关的信息。
另外，本变形例示出以下的结构：基于第一终端20的用户的用户帐户(不限定，第一帐户的一例)和共同帐户，由第一终端20(不限定，第一用户的第一终端的一例)执行与结算相关的处理，第二终端20基于共同钱包的废弃，通过通信I/F22来接收基于由第一终端20的用户进行的结算的支付垫付额请求信息(不限定，与基于第一结算的金额的请求相关的请求信息的一例)。
作为通过这样的结构而得到的效果的一例，能够基于共同帐户的废弃，来接收与基于第一结算的金额的请求相关的请求信息。
另外，本变形例示出以下的结构：服务器10通过通信I/F22来接收从第二终端20向至少第二终端20的用户(不限定，终端的用户的一例)与第一终端20的用户(不限定，第一用户的一例)能够结算的共同帐户转账的金额(不限定，第一金额的一例)的信息、以及从第一终端20向共同帐户转账的金额(不限定，第二金额的一例)的信息。进而，服务器10基于共同钱包的废弃并基于上述的转账的金额的信息，通过控制部11来执行从第二终端20的用户的用户帐户向第一终端20的用户帐户的转账处理(不限定，与从终端的用户的帐户向第一终端的第一用户的帐户转账相关的处理的一例)、或者从第一终端20的用户的用户帐户向第二终端20的用户的用户帐户的转账处理(不限定，与从第一终端的第一用户的帐户向终端的用户的帐户转账相关的处理的一例)。
作为通过这样的结构而得到的效果的一例，能够基于共同帐户的废弃并至少基于第一金额的信息和第二金额的信息，通过服务器的控制部来执行与从用户的帐户向第一用户的帐户转账相关的处理、或者与从第一用户的帐户向用户的帐户转账相关的处理，能够适当地对金额进行细算。
＜第九实施例＞
接着，对上述的“(B)帐户联合结算”的实施例进行说明。第九实施例是实现帐户联合结算的实施例。
第九实施例所记载的内容也能够应用于其他的各实施例或其他的各变形例中的任意一个。
另外，针对与已经出现的结构要素相同的结构要素标注相同的标号并省略再次的说明。
在本实施例中，作为帐户联合的一例，针对将由消息收发应用形成的组所包含的用户(以下称为“组成员”。)的用户帐户联合的实施例进行说明。实现该实施例的服务器10的结构与图3-20是同样的。
在本实施例中，说明服务器10执行帐户联合处理的情况。
需要说明的是，不限于此，也可以由终端20执行帐户联合处理，还可以不采用这种方式。
＜显示画面例＞
以下，以上述的消息收发应用中的谈话室为例来对显示画面例进行说明。如上所述，利用了消息收发应用的谈话是“聊天”的一例，谈话室是“聊天室”的一例。
以下，例示将在消息收发应用中形成的组所包含的多个组成员的用户帐户联合来进行帐户联合结算的情况。
图9-1与图5-30同样，是示出在图3-1的子菜单中对“自己的钱包”(未图示)进行了触摸操作并且在自己的钱包画面中由终端20的用户A.A对表示为“代码支付”的图标进行了触摸操作的情况下显示于用户A.A的终端20的显示部24的代码支付画面(联合前)的一例的图。
在从自己的钱包开始的代码支付区域2451内的上部，与袋状钱包的图标图像一起显示有“自己的钱包”的文字，在“自己的钱包”的下方，相对于在图5-3中显示有“钱包统合”的文字，在图9-1中与锁的标记一起显示有“钱包联合”的文字，在“钱包联合”的横侧，显示有用于切换钱包联合的“打开/关闭”的滑动按钮CN7。钱包联合与帐户联合实质上是同义的。
图9-2是示出在图9-1中对滑动按钮CN7进行了触摸操作的情况下显示的谈话室选择画面的一例的图。
在该画面中，作为非限定的例子，在最上层的标题栏中，显示有作为消息应用的应用名的“Messaging App”，在“Messaging App”的横侧，显示有用户A.A的图标图像和用户名“A.A”的文字。在标题栏的下方，显示有“Messaging App”的分层菜单中的当前位置。
具体而言，作为非限定的例子，显示有作为当前执行中的最上位的菜单的“钱包联合”。在“钱包联合”的下方，显示有“选择谈话室”的文字，在“选择谈话室”的横侧，显示有用于关闭该画面的“×图标”。另外，在“选择谈话室”的下方，显示有“请选择进行钱包联合的谈话室”的说明文作为针对用户的操作引导，在“请选择进行钱包联合的谈话室”的下方，以列表形式显示有多个谈话室(更具体而言为组谈话室)。
在该列表中，包括用户能够选择的沿纵向并排的多个行条目，在行条目中，与谈话室的谈话室图标图像建立关联地显示有该谈话室的名称。
在该例中，在该列表中，包括与树的图标图像建立关联地显示有“春季摩周湖露营(2)”的文字的行条目、与盘子上的刀和叉的图标图像建立关联地显示有“韩国美食联盟(3)”的文字的行条目、以及与正在接球的手套的图标图像建立关联地显示有“草地棒球队(10)”的文字的行条目。“()内的数字”表示该组所包含的用户(组成员)的人数。
图9-3是示出在图9-2所示的谈话室选择画面中对显示有“草地棒球队(10)”的文字的行条目进行了触摸操作的情况下显示的代码支付画面(联合后)的一例的图。
图9-3与图9-1的不同之处在于，在代码支付区域2451内，滑动按钮CN7成为“打开”的状态，在其下方，与正在接球的手套的图标图像一起新显示有“草地棒球队(10)”的文字。
另外，通过联合了帐户(钱包)，所显示的支付码成为与图9-1的支付码不同的码。
图9-4与图3-7同样地是示出在由服务器10完成了结算处理的情况下显示于终端20的代码支付完成画面的一例的图。
图9-4的代码支付完成画面与图3-7的代码支付完成画面的不同之处在于，在该画面下部比示出支付对方为“AA运动株式会社”的部分靠下的部分。具体而言，在支付对方的显示的下方，经由横线新显示有与“草地棒球队”的组相关的信息。更具体而言，作为“草地棒球队”的成员的人数而显示有“10人”，作为人均金额而显示有“500日元”。
另外，在画面下部，显示有用于通知用户确认了代码支付的完成的确认按钮242B。
图9-5是示出在由终端20执行的消息收发应用中显示于显示部24的谈话室画面的一例的图。
在该谈话室画面中，作为非限定的例子，在最上层的标题栏中显示有作为消息收发应用的应用名的“Messaging App”。在标题栏的下方显示有“Messaging App”的分层菜单中的当前位置。具体而言，作为非限定的例子，显示有作为当前执行中的最上位的菜单的“草地棒球队(10)”。在“草地棒球队(10)”的下方设置有谈话室区域2461，在谈话室区域2461的下方设置有图标显示区域2471。
在该例中，在谈话室区域2461，在上部中央显示有“今日”的文字作为日期。在“今日”的下方，与用户X.X的图标图像一起显示有用户名“X.X”，作为从用户X.X在“12时10分”发出的消息，面对画面在左侧以吹出对话框的方式显示有“在下一场比赛中使用的球不够…”这样的消息。
另外，在“在下一场比赛中使用的球不够…”的下方，作为自己的终端20的用户即用户A.A在“12时33分”返回的消息，面对画面在右侧以吹出对话框的方式显示有“我正好在AA运动购物，由我来购入吧”这样的消息。
另外，在“我正好在AA运动购物，由我来购入吧”的下方，与用户Y.Y的图标图像一起显示有用户名“Y.Y”，作为从用户Y.Y在“12时48分”发出的消息，面对画面在左侧以吹出对话框的方式显示有“拜托了！”这样的消息。
另外，在图标显示区域2471中，作为非限定的例子，显示有与“文件”、“联系人”、“位置信息”、“礼物”、“转账”、“钱包联合”分别对应的六个图标。以下，将与“钱包联合”对应的图标作为钱包联合图标CN8来进行说明。
图9-6是示出在图9-5的谈话室画面中对钱包联合图标CN8进行了触摸操作的情况下显示的谈话室画面的一例的图。
在图9-6中，在图9-5的谈话室区域2461所显示的从用户Y.Y发出的“拜托了！”的消息的下方，显示有用于通知帐户被联合且从联合的帐户进行了支付的联合通知消息2462作为从用户A.A发出的消息。
作为非限定的例子，在用户A.A的终端20的显示部24显示有图9-4时，作为非限定的例子经由API从支付管理服务器10A向消息收发管理服务器10B发送与支付相关的信息。这样，作为非限定的例子，通过消息收发管理服务器10B的控制部而生成联合通知消息2462，向联合了帐户的各终端自动地发送消息。
在该联合通知消息2462中，在上层显示有[Payment App]的文字，在[PaymentApp]的下方，与锁的标记一起显示有“钱包联合支付”的文字。另外，在“钱包联合支付”的下方，显示有人均支付金额为“500日元”。
另外，在下层，显示有支付对方为“AA运动株式会社”，支付金额为“5，000日元”，组成员的人数为“10人”。另外，在它们的下方，显示有用于确认详细内容的详细确认图标。
图9-7是示出与图9-6对应的用户X.X的终端20的显示部24所显示的谈话室画面的一例的图，在从用户Y.Y发出的“拜托了！”的消息的下方，显示有上述的联合通知消息2462。
＜第九实施例的效果＞
第九实施例示出以下的结构：终端20通过控制部21来执行用于将自己的终端20的用户的用户帐户(不限定，第一帐户的一例)与其他的组成员的用户帐户(不限定，第二帐户的一例)联合的处理(不限定，将第一帐户与第二帐户建立关联的处理的一例)。进而，终端20基于所联合的自己的终端20的用户的用户帐户和其他的组成员的用户帐户，通过控制部21执行与结算相关的处理。
作为通过这样的结构而得到的效果的一例，能够将终端的用户能够结算的第一帐户与不同于第一帐户的第二帐户建立关联。而且，能够实现基于建立了关联的第一帐户和第二帐户的结算。
另外，第九实施例示出基于组谈话室(不限定，聊天室的一例)的选择来选择要联合的其他组成员的用户帐户(不限定，第二帐户的一例)的结构。
作为通过这样的结构而得到的效果的一例，能够通过聊天室的选择这样的简单的方法来选择第二帐户。
＜第九变形例(1)＞
在第九实施例中，通过选择组谈话室而进行了帐户联合，但不限定于此。当然也能够采取在两人的用户之间联合用户帐户这样的方式。
作为非限定的例子，也可以是，在使用户A.A与用户B.B这两名用户帐户联合来进行结算的情况下，用户A.A在由自己的终端20执行的支付应用或消息收发应用中直接选择用户B.B，使自己的用户帐户与用户B.B的用户帐户联合。在该情况下，将用户A.A的用户帐户与用户B.B的用户帐户联合来进行帐户联合结算。
需要说明的是，当用户A.A随意进行帐户联合时，可能使用户B.B蒙受损失。因此，可以使用户A.A向用户B.B取得帐户联合的许可。
＜第九变形例(2)＞
在第九实施例中，与第四变形例(9)同样，也能够代替码结算而通过无线通信(包括近距离无线通信。)进行结算。
在应用上述的非接触式通信的情况下，终端20的用户通过将自己的终端20靠近店铺的读卡器或卡读写器上而与上述的实施例同样地进行结算。在该情况下，在由读卡器读取了信息的结果是自己的终端20的用户的用户帐户的电子钱币账户余额不足的情况下，作为非限定的例子，服务器10的控制部11通过通信I/F14向终端20发送表示该余额不足的信息(结算余额不足信息)。当通过通信I/F22从服务器10接收到结算余额不足信息时，终端20的控制部21使结算余额不足信息显示于显示部24。进而，终端20的控制部21基于由自己的终端20的用户针对所显示的结算余额不足信息进行的输入，执行帐户联合处理。然后，终端20的用户能够通过将自己的终端20再次靠近店铺的读卡器上来进行帐户联合结算。
需要说明的是，如上所述，也能够预先联合帐户。
这在应用蓝牙通信的情况下也是同样的。
本变形例示出通过由终端20的通信I/F22进行的与店铺读码器装置50(不限定，销售通过结算而购入的商品或者提供服务的店铺的终端的一例)之间通过无线通信来执行与结算相关的处理的结构。
作为通过这样的结构而得到的效果的一例，能够通过与销售通过第一结算而购入的商品或提供服务的店铺的终端之间的无线通信来实现结算。
另外，本变形例示出上述的无线通信是近距离通信的结构。
作为通过这样的结构而得到的效果的一例，能够通过近距离通信而实现与销售通过第一结算而购入的商品或者提供服务的店铺的终端之间的无线通信。
＜第九变形例(3)＞
也能够将第九实施例中说明的帐户联合结算作为暂时制作共同钱包并使用该共同钱包进行结算的共同帐户结算。
具体而言，作为非限定的例子，在图9-2的谈话室选择画面中选择了进行帐户联合结算的组谈话室的情况下，服务器10制作将所选择的组谈话室的成员作为共同钱包成员的暂时的共同钱包(共同钱包余额＝0)。
当要从制作出的共同钱包进行结算时，由于共同钱包余额为“0”，因此结算失败。在该情况下，作为非限定的例子，能够应用在上述的第二实施例～第七实施例中说明的方法来进行结算。
即，在该情况下，能够同样地应用在上述的第二实施例～第七实施例中说明的内容。
另外，在废弃共同钱包的情况下，能够同样应用在第八实施例中说明的内容。
＜第十实施例＞
第十实施例是与上述的各种实施例中的两个帐户(第一帐户和第二帐户)的组合(变化)相关的实施例。
图10是示出用于说明第一帐户与第二帐户的组合的表的一例的图。
在该表中，作为非限定的例子，关联地规定了模式、第一帐户以及第二帐户。以下，对各个模式进行说明。
(1)模式A
模式A是将第一帐户设为“第一共同帐户(第一共同钱包)”的模式，并且确定了将第二帐户设为四个种类的模式A1～模式A4这四个模式。
第一共同帐户是包括自己的终端20的用户在内的多个终端20的用户能够使用的共同钱包的帐户(第一个帐户)。
模式A1是将第二帐户设为“自己的用户帐户(电子钱币账户)”的模式。
模式A2是将第二帐户设为“他人的用户帐户(电子钱币账户)”的模式。
模式A3是将第二帐户设为“运营商帐户(运营商贷款账户)”的模式。
作为非限定的例子，运营商是包括提供支付服务(支付应用)的运营商在内的受到从事货币的融资/借贷的认可的运营商。
运营商帐户是该运营商的支付应用的帐户。
运营商贷款账户是该运营商用于向利用者(终端20的用户)融资/借贷货币的账户。
模式A4是将第二帐户设为“第二共同帐户(第二共同钱包)”的模式。
第二共同帐户是包括自己的终端20的用户在内的多个终端20的用户能够使用的与第一共同帐户不同的共同帐户(第二个共同帐户)。
(2)模式B
模式B是将第一帐户设为“自己的第一用户帐户”的模式，并且确定了将第二帐户设为四个种类的模式B1～模式B4这四个模式。
自己的第一用户帐户是自己的支付应用的帐户(第一个用户帐户)。
模式B1是将第二帐户设为“共同帐户”的模式。
模式B2是将第二帐户设为“他人的用户帐户”的模式。
模式B3是将第二帐户设为“运营商帐户”的模式。
模式B4是将第二帐户设为“自己的第二用户帐户”的模式。
自己的第二用户帐户是与自己的第一用户帐户不同的自己的支付应用的帐户(自己的第二个用户帐户)。
(3)模式C
模式C是将第一帐户设为“第一用户帐户(他人A)”的模式，并且确定了将第二帐户设为四个种类的模式C1～模式C4这四个模式。
第一用户帐户(他人A)是他人A的支付应用的帐户。
模式C1是将第二帐户设为“共同帐户”的模式。
模式C2是将第二帐户设为“自己的用户帐户”的模式。
模式C3是将第二帐户设为“运营商帐户”的模式。
模式C4是将第二帐户设为“第二用户帐户(他人A或他人B)”的模式。
第二用户帐户(他人A或他人B)是与他人A的第一用户帐户不同的他人A的支付应用的帐户(他人A的第二个用户帐户)、或者他人B的支付应用的帐户(他人B的第一个用户帐户)。
(4)模式D
模式D是将第一帐户设为“第一运营商帐户”的模式，并且确定了将第二帐户设为四个种类的模式D1～模式D4这四个模式。
第一运营商帐户是第一运营商的支付应用的帐户(第一运营商的第一个帐户)。
模式D1是将第二帐户设为“自己的用户帐户”的模式。
模式D2是将第二帐户设为“他人的用户帐户”的模式。
模式D3是将第二帐户设为“共同帐户”的模式。
模式D4是将第二帐户设为“第二运营商帐户”的模式。
第二运营商帐户是与第一运营商帐户不同的第一运营商的支付应用的帐户(第一运营商的第二个帐户)或者第二运营商的支付应用的帐户(第二运营商的第一个帐户)。
在共同帐户结算中，能够应用上述的模式中的包括共同帐户的模式即模式A(模式A1～模式A4)、模式B1、模式C1、模式D3中的任意一个模式。在该情况下，能够同样地应用第二实施例～第八实施例的方法来进行共同帐户结算。
在帐户联合结算中，能够应用上述的模式中的不包括共同帐户的模式即模式B2～模式B4、模式C2～模式C4、模式D1、D2、D4中的任意一个模式。在该情况下，能够同样地应用第九实施例的方法来进行帐户联合结算。
另外，如果将帐户联合结算理解为多个用户一起进行结算的方法，则也能够将不使用共同帐户的模式应用于第二实施例～第八实施例的方法。即，也能够将上述的模式中的不包括共同帐户的模式即模式B2～模式B4、模式C2～模式C4、模式D1、D2、D4中的任意一个模式应用于第二实施例～第八实施例。
＜第十实施例的效果＞
根据第十实施例，能够将第一帐户和第二帐户设定为各种帐户来实现结算，因此，能够提高终端的用户的便利性。
作为非限定的例子，第二帐户为运营商帐户(不限定，运营商的帐户的一例)，通过从该运营商帐户借贷余额的不足部分来执行与结算相关的处理，由此，能够至少基于运营商的帐户来实现结算。另外，通过从运营商的帐户借贷余额的不足部分，即便在余额不足的情况下也能够适当地进行结算。
附图标记说明
1 通信系统
10 服务器
10A 支付管理服务器
10B 消息收发管理服务器
20 终端
30 网络
40 店铺POS系统
50 店铺读码器装置
Claims (28)
1.一种程序，是用于使终端执行的程序，该终端基于代码信息而执行与结算相关的处理，其中，
通过所述终端执行以下的处理：
将与所述终端的用户能够结算的第一帐户建立了关联的第一代码信息或者作为与代码信息的读取相关的显示的第一读码器信息、和与不同于所述第一帐户的第二帐户相关的第二帐户信息显示于所述终端的显示区域；以及
基于由所述终端的用户针对所述第二帐户信息进行的输入，由所述终端的控制部执行与基于所述第一帐户和所述第二帐户的第一结算相关的处理。
2.根据权利要求1所述的程序，其中，
所述第一帐户是至少所述终端的用户、和不同于所述终端的用户的第一用户能够结算的共同帐户。
3.根据权利要求2所述的程序，其中，
通过所述终端执行以下的处理：
将与所述共同帐户建立了关联的第一电子货币的金额的信息、和用于从所述第二帐户向所述共同帐户进行转账的第一显示显示于所述显示区域；以及
基于由所述终端的用户针对所述第一显示进行的输入，执行从所述第二帐户向所述共同帐户的转账，基于向所述共同帐户的转账，使与所述共同帐户建立了关联的第二电子货币的金额的信息显示于所述显示区域。
4.根据权利要求3所述的程序，其中，
基于从所述第二帐户转账的所述共同帐户来执行与所述第一结算相关的处理。
5.根据权利要求3或4所述的程序，其中，
针对所述第一显示的输入是从所述第二帐户向所述共同帐户转账的金额的输入。
6.根据权利要求2所述的程序，其中，
通过所述终端执行以下的处理：
基于针对所述第二帐户信息的输入，将所述第二帐户与所述共同帐户建立了关联的所述第一代码信息、或者所述第一读码器信息显示于所述显示区域；以及
基于所述第一代码信息被读取或者基于通过所述第一读码器信息显示于所述显示区域的所述终端来读取所述代码信息，由所述控制部执行与所述第一结算相关的处理。
7.根据权利要求6所述的程序，其中，
通过所述终端执行以下的处理：
将与所述共同帐户建立了关联的所述第一代码信息或者所述第一读码器信息、以及所述第二帐户信息显示于所述显示区域；以及
基于针对所述第二帐户信息的输入，将使所述第二帐户与所述共同帐户建立了关联的第二代码信息、或者第二读码器信息显示于所述显示区域。
8.根据权利要求7所述的程序，其中，
从执行与所述第一结算相关的处理的服务器向所述终端发送所述第一代码信息和所述第二代码信息。
9.根据权利要求7或8所述的程序，其中，
通过所述终端执行以下的处理：
在所述显示区域显示：将与所述共同帐户建立了关联的第一电子货币的金额的信息和与所述第二帐户建立了关联的第二电子货币的金额的信息相加而得到的金额的信息、和所述第二代码信息或者所述第二读码器信息。
10.根据权利要求2所述的程序，其中，
通过所述终端执行以下的处理：
将与所述共同帐户建立了关联的所述第一代码信息、或者所述第一读码器信息显示于所述显示区域；以及
基于针对所述第二帐户信息的输入，将与所述第二帐户建立了关联的第三代码信息、或者第三读码器信息显示于所述显示区域。
11.根据权利要求6至10中任一项所述的程序，其中，
在所述第一结算中，从所述共同帐户和所述第二帐户中的所述共同帐户的余额优先地进行支付。
12.根据权利要求2至11中任一项所述的程序，其中，
通过所述终端执行以下的处理：
将与不同于所述第二帐户的第三帐户相关的第三帐户信息、和所述第二帐户信息显示于所述显示区域。
13.根据权利要求2至12中任一项所述的程序，其中，
所述第二帐户为所述终端的用户的帐户。
14.根据权利要求13所述的程序，其中，
通过所述终端执行以下的处理：
基于所述第一结算的金额、所述共同帐户的余额以及所述第二帐户的余额，将与所述共同帐户和所述第二帐户的余额不足相关的第一信息显示于所述终端的显示区域；以及
基于由所述终端的用户针对所述第一信息进行的输入，由所述控制部执行对所述第二帐户进行转账的处理。
15.根据权利要求2至12中任一项所述的程序，其中，
所述第二帐户是所述第一用户的帐户。
16.根据权利要求15所述的程序，其中，
通过所述终端执行以下的处理：通过所述终端的通信部向所述第一用户的第一终端发送与委托许可基于所述第二帐户的结算相关的信息，
基于所述第一用户许可通过所述第二帐户进行结算，来执行与所述第一结算相关的处理。
17.根据权利要求13所述的程序，其中，
通过所述终端执行以下的处理：
通过所述终端的通信部来发送与金额的请求相关的请求信息，所述金额基于所述第二帐户的支付；以及
将基于所述请求信息的第二显示显示于所述终端的显示区域。
18.根据权利要求16所述的程序，其中，
通过所述终端执行以下的处理：
通过所述终端的通信部来接收与金额的请求相关的请求信息，所述金额基于所述第二帐户的支付；以及
将基于所述请求信息的第三显示显示于所述终端的显示区域。
19.根据权利要求2至12中任一项所述的程序，其中，
基于所述共同帐户和包括所述第二帐户在内的、通过所述共同帐户能够结算的用户的各个帐户，来执行与所述第一结算相关的处理。
20.根据权利要求19所述的程序，其中，
对所述各个帐户均等地分配所述共同帐户的所述余额的不足部分，来执行基于所述第一结算的支付。
21.根据权利要求2至12中任一项所述的程序，其中，
所述第二帐户是运营商的帐户，
通过从所述第二帐户借贷所述余额的不足部分来执行与所述第一结算相关的处理。
22.根据权利要求1所述的程序，其中，
所述第二帐户是与所述终端的用户不同的第一用户的帐户。
23.根据权利要求22所述的程序，其中，
基于由所述终端的用户针对所述终端进行的输入来选择所述第二帐户。
24.根据权利要求22所述的程序，其中，
基于由所述终端的用户进行的、针对包括所述终端的用户和所述第一用户在内的聊天室的选择，来选择所述第二帐户。
25.根据权利要求22至24中任一项所述的程序，其中，
通过所述终端执行以下的处理：通过所述通信部向所述第一用户的第一终端发送与委托许可基于所述第二帐户的结算相关的信息，
基于所述第一用户许可通过所述第二帐户进行结算，来执行与所述第一结算相关的处理。
26.一种终端的信息处理方法，该终端基于代码信息而执行与结算相关的处理，其中，
所述终端的信息处理方法包括：
将与所述终端的用户能够结算的第一帐户建立了关联的第一代码信息或者作为与代码信息的读取相关的显示的第一读码器信息、和与不同于所述第一帐户的第二帐户相关的第二帐户信息显示于所述终端的显示区域；以及
基于由所述终端的用户针对所述第二帐户信息进行的输入，由所述终端的控制部执行与基于所述第一帐户和所述第二帐户的第一结算相关的处理。
27.一种终端，是基于代码信息而执行与结算相关的处理的终端，其中，
所述终端具备：
显示部，其显示与所述终端的用户能够结算的第一帐户建立了关联的第一代码信息或者作为与代码信息的读取相关的显示的第一读码器信息、和与不同于所述第一帐户的第二帐户相关的第二帐户信息；以及
控制部，其基于由所述终端的用户针对所述第二帐户信息进行的输入，执行与基于所述第一帐户和所述第二帐户的第一结算相关的处理。
28.一种终端，是基于代码信息而执行与结算相关的处理的终端，其中，
所述终端具备处理器，该处理器读出存储于存储器的程序，执行基于所述程序的处理，
所述处理器执行以下的处理：
将与所述终端的用户能够结算的第一帐户建立了关联的第一代码信息或者作为与代码信息的读取相关的显示的第一读码器信息、和与不同于所述第一帐户的第二帐户相关的第二帐户信息显示于所述终端的显示区域；以及
基于由所述终端的用户针对所述第二帐户信息进行的输入，执行与基于所述第一帐户和所述第二帐户的第一结算相关的处理。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2019240074A JP6941666B2 (ja) | 2019-12-30 | 2019-12-30 | プログラム、情報処理方法、端末 |
| PCT/JP2019/051640 WO2021137268A1 (ja) | 2019-12-30 | 2019-12-30 | プログラム、情報処理方法、端末 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114424224A true CN114424224A (zh) | 2022-04-29 |
Family
ID=76687442
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201980100427.XA Pending CN114424224A (zh) | 2019-12-30 | 2019-12-30 | 程序、信息处理方法、终端 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US20220207502A1 (zh) |
| JP (2) | JP6941666B2 (zh) |
| KR (1) | KR20220098015A (zh) |
| CN (1) | CN114424224A (zh) |
| WO (1) | WO2021137268A1 (zh) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR102447248B1 (ko) * | 2021-12-03 | 2022-09-27 | 주식회사 프렉스코리아 | 다른 사용자와 연동하여 종목을 거래할 수 있는 시스템을 제공하는 거래소 운영 방법 및 시스템 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002176671A (ja) | 2000-09-28 | 2002-06-21 | Takashi Fujimoto | 移動体電話機 |
| JPWO2004010356A1 (ja) * | 2002-07-19 | 2005-11-17 | 富士通株式会社 | 決済システム、決済装置、決済プログラム、および決済プログラム記憶媒体 |
| JP2012048694A (ja) * | 2010-08-26 | 2012-03-08 | Zybox:Kk | ワンクリック決済機能付オーダリング端末機 |
| US20140052634A1 (en) * | 2012-08-16 | 2014-02-20 | Joshua Baron | Merging balances of payment cards |
| WO2014030875A1 (en) * | 2012-08-24 | 2014-02-27 | Samsung Electronics Co., Ltd. | Apparatus and method for providing interaction information by using image on device display |
| US20190236589A1 (en) * | 2018-01-31 | 2019-08-01 | Edge Mobile Payments Llc | Hand-held electronics device for aggregation of and management of personal electronic data |
-
2019
- 2019-12-30 CN CN201980100427.XA patent/CN114424224A/zh active Pending
- 2019-12-30 WO PCT/JP2019/051640 patent/WO2021137268A1/ja active Application Filing
- 2019-12-30 KR KR1020227020244A patent/KR20220098015A/ko unknown
- 2019-12-30 JP JP2019240074A patent/JP6941666B2/ja active Active
-
2021
- 2021-08-31 JP JP2021141861A patent/JP7456986B2/ja active Active
-
2022
- 2022-03-18 US US17/698,625 patent/US20220207502A1/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| JP2021110959A (ja) | 2021-08-02 |
| WO2021137268A1 (ja) | 2021-07-08 |
| KR20220098015A (ko) | 2022-07-08 |
| JP2021192259A (ja) | 2021-12-16 |
| JP7456986B2 (ja) | 2024-03-27 |
| JP6941666B2 (ja) | 2021-09-29 |
| US20220207502A1 (en) | 2022-06-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10740807B2 (en) | Systems and methods for transmission of representational image-based offers based on a tactile input | |
| JP7460686B2 (ja) | プログラム、情報処理方法、サーバ | |
| JP6977127B1 (ja) | プログラム、情報処理方法、端末、サーバ | |
| JP7175877B2 (ja) | プログラム、表示方法、端末 | |
| JP2021192260A (ja) | プログラム、情報処理方法、端末 | |
| JP7456986B2 (ja) | プログラム、情報処理方法、端末 | |
| JP7405930B2 (ja) | プログラム、情報処理方法、端末 | |
| JP7250186B2 (ja) | サーバ、プログラム、情報処理方法 | |
| JP2023068513A (ja) | アプリケーションプログラム、サービス提供システム、および端末装置 | |
| JP7306772B2 (ja) | プログラム、情報処理方法、サーバ | |
| WO2023277001A1 (ja) | プログラム、情報処理方法、サーバ、情報処理装置 | |
| JP7146866B2 (ja) | プログラム、情報処理方法、端末 | |
| US20230138065A1 (en) | Program, information processing method, and terminal | |
| JP2023006759A (ja) | プログラム、情報処理方法、情報処理装置 | |
| JP2023006760A (ja) | プログラム、情報処理方法、サーバ | |
| JP7417795B2 (ja) | プログラム、情報処理方法、サーバ、システム、端末 | |
| JP7183217B2 (ja) | プログラム、情報処理方法、端末 | |
| JP7034226B1 (ja) | プログラム、情報処理方法、端末 | |
| WO2022070453A1 (ja) | プログラム、情報処理方法、端末、サーバ | |
| CN115699051A (zh) | 程序、信息处理方法、终端、服务器 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |