CN108734451A - 服务器及其控制方法 - Google Patents

Abstract

提供了一种服务器的控制方法。所述方法包括如下步骤：响应于从第一用户的终端设备接收到包括与代理支付相关联的预期付款额、所述第一用户的账户信息以及与一个或更多个第二用户相关联的信息的代理支付认可请求，向所述第二用户的终端设备发送询问是否认可所述代理支付认可请求的消息；响应于从所述第二用户的终端设备接收到包括所述第二用户的账户信息的认可，发送针对所述代理支付认可请求的认可消息；以及响应于接收到针对所述代理支付的所述第一用户的支付信息，向与所述第二用户的账户相关联的金融交易服务器发送用于请求从所述第二用户的账户向所述第一用户的账户汇款的账户转账信息。

Description

服务器及其控制方法

相关申请的交叉引用

本申请要求于2017年2月24日在韩国知识产权局提交并被分配了序号10-2017-0025072的韩国专利申请的优先权，其全部公开内容通过引用并入在本文中。

技术领域

本公开涉及与代理支付系统、服务器及其控制方法有关的系统、服务器和方法。更具体地，本公开涉及用于处理代理支付的服务器及其控制方法。

背景技术

最近，利用先进电子与信息技术(IT)科技，已经提供了用于购买商品或服务的各种支付方式。在线下商店购买商品或服务的消费者可能需要使用各种卡(诸如信用卡、借记卡或现金卡)以及现金来进行支付。消费者也可以通过各种电子商务交易手段在线上商店购买商品或服务或者进行支付。各种移动支付服务的最近引入及商业化已使得能实现使用诸如智能电话等的移动设备来进行支付的方式。

由于各种先进电子金融系统或电子商务交易系统如上所述的发展，消费者能够更方便地进行支付。然而，在由代表委托人购买商品或服务的受托人执行代理支付并针对该代理支付进行后续还款时仍然存在相当大的不便。

例如，当委托人A在稍后偿还付款的请求下请求他的朋友B购买产品X时，作为受托人的朋友B购买产品X并代表委托人A支付价款。此后，受托人B将产品X转交给委托人A，并且委托人A偿还受托人B先前已进行的针对产品X的付款。

在示例中，受托人B可以直接与委托人A会面并且以现金接收针对产品X的付款。然而，因为委托人和受托人(代理付款人)彼此必须直接会面所以这造成不便。或者，受托人B可以通过账户转账在不用与委托人A会面的情况下被付款。然而，这可能是有问题的，因为通过账户转账的付款需要不方便的处理，诸如向委托人A指示受托人B的账户、由委托人A通过银行提供的账户转账服务将付款汇款到受托人B的账户、在汇款之后确认由受托人B接收等。此外，在这种还款过程期间，受托人B的个人信息(例如，账号等)可能被暴露给委托人A。进一步地，取决于情况，当委托人A不向受托人B进行支付时，受托人B可能处于费用未被付款的麻烦中。同时，在当多个购买希望者对实行“AA制支付”或“各自付账”的条件取得一致意见时的情形下也可能发生以上问题，其中，在所述“AA制支付”或“各自付账”中，一个购买希望者针对全部费用进行垫付款并且稍后接收其余购买希望者的根据相应协议部分的付款。

因此，需要一种能够解决上面所提及的问题(诸如在代理支付的偿还过程中经历的还款的不准确和不便以及个人信息暴露的风险)的新技术。

以上信息仅作为背景信息被呈现以帮助理解本公开。至于上述中的任一项对于本公开而言是否可能适用为现有技术，尚未作出确定，并且也未作出断言。

发明内容

本公开的各方面是为了至少解决上面提及的问题和/或缺点并至少提供在下面所描述的优点。因此，本发明的一个方面是为了提供一种用于处理代理支付的服务器及其控制方法。

本公开的另一方面是为了提供一种能够立即偿还代理付款的代理支付系统、一种服务器以及一种服务器的控制方法。

依照本公开的另一方面，提供了一种服务器的控制方法。所述方法包括如下步骤：响应于从第一用户的终端设备接收到包括与代理支付相关联的预期付款额、所述第一用户的账户信息以及与一个或更多个第二用户相关联的信息的代理支付认可请求，向所述第二用户的终端设备发送询问是否认可所述代理支付认可请求的消息；响应于从所述第二用户的终端设备接收到包括所述第二用户的账户信息的认可，发送针对所述代理支付认可请求的认可消息；以及响应于接收到针对所述代理支付的所述第一用户的支付信息，向与所述第二用户的账户相关联的金融交易服务器发送用于请求从所述第二用户的账户向所述第一用户的账户汇款的账户转账信息。

进一步地，所述的代理支付认可请求可以附加地包括指示第一模式和第二模式中的一种的模式信息，其中，在所述第一模式下，所述第二用户支付全部预期付款额，在所述第二模式下，所述第一用户和所述第二用户分担所述预期付款额。

在本公开的实施例中，所述的向第二用户的终端设备发送的步骤可以包括：当所述模式信息是所述第一模式时，向所述第二用户的终端设备发送询问如下事项的消息：是否认可通过将所述预期付款额除以所述第二用户的总数而计算出的付款额；以及当所述模式信息是所述第二模式时，向所述第二用户的终端设备发送询问如下事项的消息：是否认可通过将所述预期付款额除以所述第一用户和所述第二用户的总数而计算出的付款额。

进一步地，所述的向金融交易服务器发送的步骤可以包括：响应于接收到所述支付信息，向与所述第二用户的账户相关联的金融交易服务器发送用于请求通过将所述预期付款额除以所述总数而计算出的付款额的汇款的账户转账信息。

进一步地，所述代理支付认可请求进一步可以包括与分担所述预期付款额的用户的数量相关联的信息，其中，所述的向第二用户的终端设备发送的步骤可以包括：向所述第二用户的终端设备发送询问如下事项的消息：是否认可通过将所述预期付款额除以分担所述预期付款额的用户的数量而计算出的付款额；并且，所述的向金融交易服务器发送可以包括：响应于接收到所述支付信息，向与所述第二用户的账户相关联的金融交易服务器发送用于请求通过将所述预期付款额除以所分担的用户的总数而计算出的付款额的汇款的账户转账信息。

进一步地，分担所述预期付款额的用户除了包括所述第一用户和所述第二用户之外还可以进一步包括不使用经由所述服务器的代理支付服务的用户。

进一步地，所述的向第二用户的终端设备发送的步骤可以包括：响应于从所述第一用户的终端设备接收到包括有关在所述第一用户与所述第二用户之间分担所述预期付款额的比例或关于所述预期付款额中的支付份额的份额信息的代理支付请求，向所述第二用户的终端设备发送询问如下事项的消息：是否认可通过根据所述份额信息来划分所述预期付款额而计算出的付款额；并且所述的向金融交易服务器发送的步骤可以包括：响应于接收到所述支付信息，向与所述第二用户的账户相关联的金融交易服务器发送用于请求通过根据所述份额信息来划分所述预期付款额而计算出的付款额的汇款的账户转账信息。

进一步地，所述的向第一用户的终端设备发送的步骤可以包括：响应于从多个第二用户当中的一些第二用户的终端设备接收到对所述代理支付认可请求的不认可并且从所述多个第二用户当中的其他用户的终端设备接收到认可，向所述第一用户的终端设备发送询问是否继续代理支付的消息；并且，所述的向金融交易服务器发送的步骤可以包括：响应于接收到所述支付信息，向与所述多个第二用户当中的所述其他用户的账户中的每一个相关联的金融交易服务器，发送用于请求从所述其他用户的账户向所述第一用户的所述账户汇款的账户转账信息。

进一步地，所述的询问是否认可的消息可以包括与需要所述第二用户认可的支付金额相关联的信息；并且，所述的向金融交易服务器发送的步骤可以包括：当所述预期付款额不同于所述支付信息中包括的已付金额时，向与所述第二用户的账户相关联的金融交易服务器发送用于请求所述需要所述第二用户认可的支付金额和所述已付金额中的较小者的汇款的账户转账信息。

进一步地，所述的向金融交易服务器发送的步骤可以包括：当所述第一用户的终端设备通过与支付终端设备通信而进行支付时，从与所述第一用户的支付相关联的金融交易服务器接收所述支付信息。

依照本公开的另一方面，提供了一种服务器。所述服务器包括：通信器，所述通信器被配置为与用户的终端设备和所述用户的金融交易服务器进行通信；以及处理器，所述处理器被配置为：响应于从第一用户的终端设备接收到包括与代理支付相关联的预期付款额、所述第一用户的账户信息以及与一个或更多个第二用户相关联的信息的代理支付认可请求，控制所述通信器向所述第二用户的终端设备发送询问是否认可所述代理支付认可请求的消息；响应于从所述第二用户的终端设备接收到包括所述第二用户的账户信息的认可，控制所述通信器发送针对所述代理支付认可请求的认可消息；以及响应于接收到针对所述代理支付的所述第一用户的支付信息，控制所述通信器向与所述第二用户的账户相关联的金融交易服务器发送用于请求从所述第二用户的账户向所述第一用户的账户汇款的账户转账信息。

进一步地，所述代理支付认可请求可以进一步包括指示第一模式和第二模式中的一种的模式信息，其中，在所述第一模式下，所述第二用户支付全部预期付款额，在所述第二模式下，所述第一用户和所述第二用户分担所述预期付款额。

进一步地，所述处理器可以被配置为：当所述模式信息是所述第一模式时，控制所述通信器向所述第二用户的终端设备发送询问如下事项的消息：是否认可通过将所述预期付款额除以所述第二用户的总数而计算出的付款额；以及当所述模式信息是所述第二模式时，控制所述通信器向所述第二用户的终端设备发送询问如下事项的消息：是否认可通过将所述预期付款额除以所述第一用户和所述第二用户的总数而计算出的付款额。

进一步地，所述处理器可以被配置为：响应于接收到所述支付信息，控制所述通信器向与所述第二用户的账户相关联的金融交易服务器发送用于请求通过将所述预期付款额除以所述总数而计算出的付款额的汇款的账户转账信息。

进一步地，所述代理支付认可请求可以进一步包括与分担所述预期付款额的用户的数量相关联的信息；其中，所述处理器可以被配置为：控制所述通信器向所述第二用户的终端设备发送询问如下事项的消息：是否认可通过将所述预期付款额除以分担所述预期付款额的用户的数量而计算出的付款额；并且响应于接收到所述支付信息，控制所述通信器向与所述第二用户的账户相关联的金融交易服务器发送用于请求通过将所述预期付款额除以分担所述预期付款额的用户的数量而计算出的付款额的汇款的账户转账信息。

进一步地，分担所述预期付款额的用户除了包括所述第一用户和所述第二用户之外可以进一步包括不使用经由所述服务器的代理支付服务的用户。

进一步地，所述处理器可以被配置为：响应于从所述第一用户的终端设备接收到包括关于在所述第一用户与所述第二用户之间分担所述预期付款额的比例或所述预期付款额中的支付份额的份额信息的代理支付请求，控制所述通信器向所述第二用户的终端设备发送询问如下事项的消息：是否认可通过根据所述份额信息来划分所述预期付款额而计算出的付款额；并且，响应于接收到所述支付信息，控制所述通信器向与所述第二用户的账户相关联的金融交易服务器发送用于请求通过根据所述份额信息来划分所述预期付款额而计算出的付款额的汇款的账户转账信息。

进一步地，所述处理器可以被配置为：响应于从多个第二用户当中的一些的终端设备接收到对所述代理支付认可请求的不认可并且从所述多个第二用户当中的其他用户的终端设备接收到认可，控制所述通信器向所述第一用户的终端设备发送询问是否继续代理支付的消息；并且响应于接收到所述支付信息，控制所述通信器向与所述多个第二用户当中的其他用户的账户的每一个相关联的金融交易服务器发送用于请求从所述其他用户的账户向所述第一用户的账户汇款的账户转账信息。

进一步地，所述的询问是否认可的消息可以包括与需要所述第二用户认可的支付金额相关联的信息；其中，所述处理器可以被配置为：当所述预期付款额不同于所述支付信息中包括的已付金额时，控制所述通信器向与所述第二用户的账户相关联的金融交易服务器发送用于请求所述需要所述第二用户认可的支付金额和所述已付金额中的较小者的汇款的账户转账信息。

进一步地，所述处理器可以被配置为：当所述第一用户的终端设备通过与支付终端设备通信来进行支付时，从与所述第一用户的支付相关联的金融交易服务器接收所述支付信息。

根据上述的各种实施例，代理付款人可以在进行支付的同时接收还款而不必暴露个人信息，并且对于实际付款人而言，他或她也能够方便地偿还付款，而不必经历繁琐的过程。换句话说，能够解决在代理购买过程期间可能发生的还款的不便和暴露个人信息的风险。

从结合附图公开了本公开的各种实施例的以下具体描述中，本公开的其他方面、优点和显著特征对于本领域技术人员而言将变得显而易见。

附图说明

从结合附图的以下描述中，本公开的某些实施例的以上及其他方面、特征和优点将更显而易见，在附图中：

图1是根据本公开的实施例的代理支付系统的例示；

图2是根据本公开的实施例的服务器的框图；

图3是根据本公开的实施例的代理支付系统的操作的例示；

图4是根据本公开的实施例的代理支付系统的操作的例示；

图5是根据本公开的实施例的用户终端设备的构造的框图；

图6、图7、图8A、图8B、图8C、图9、图10、图11A、图11B和图12是根据本公开的各种实施例执行的代理支付应用的屏幕的例示；以及

图13是例示了根据本公开的实施例的服务器的控制方法的流程图。

在整个附图中，应当注意的是，相似的附图标记用于描绘相同或相似的元件、特征和结构。

具体实施方式

参考附图的以下描述被提供来协助全面理解如由权利要求及其等同形式限定的本公开的各种实施例。以下描述包括各种具体细节以协助该理解，但是这些具体细节将被认为是仅仅示例性的。因此，本领域的普通技术人员将认识到，在不脱离本公开的范围和精神的情况下，能够对本文所描述的各种实施例作出各种改变和修改。此外，为了清楚和简洁，可以省略对众所周知的已知功能和构造的描述。

在以下描述和权利要求中使用的术语和单词不限于书面含义，而是，仅仅由发明人使用以使得能够清楚且一致地理解本公开。因此，对于本领域技术人员而言应当显而易见的是，本公开的各种实施例的以下描述是仅为了例示目的而提供的，而不是为了限制如由所附权利要求及其等同形式限定的本公开的目的而提供的。

应当理解的是，除非上下文另外清楚地规定，否则未指明数量的术语“一”、“一个”和“所述”既可以包括单数的情况也可以包括复数的情况。因此，例如，对“一组件表面”的引用包括对此类表面中的一个或多个的引用。

术语“基本上”意味着不必确切地实现所记载的特征、参数或值，而是可能在量上发生不阻碍该特征旨在提供的效果的偏差或变化，包括例如公差、测量误差、测量准确度限制以及本领域技术人员所知的其他因素。

本文所使用的表述仅用于描述本公开的某些实施例，而不旨在限制本公开的范围。除非另外指定，否则未指明数量的术语既可以包括单数的情况也可以包括复数的情况。

在描述各种元件时可以使用表述“第一”、“第二”等，但是这些元件不应当被限于这些表述。这些表述仅被用于将一个元件和另一元件相区分的目的。

本文所使用的表述“包括”或“具有”旨在标明操作、元件、组件或这些的组合的存在，并且因此，这不应当被理解为排除其他特征、数字、操作、元件、组件或这些的组合中的一个或更多个的存在或者添加其他特征、数字、操作、元件、组件或这些的组合中的一个或更多个的可能性。

进一步地，在本公开的实施例中，诸如“模块”、“单元”、“部件”等的术语用于指代用于执行至少一个功能和操作的元件，并且它们可以作为硬件、软件或硬件和软件的组合被实现。进一步地，除了每个都需要作为单独的具体硬件被实现的示例之外，多个“模块”、“单元”、“部件”等可以被集成到至少一个模块或芯片中以作为至少一个处理器(未例示)被实现。

下文将通过参考所附的附图具体地描述本公开的各种实施例。

图1是根据本公开的实施例的代理支付系统的例示。

参考图1，代理支付系统包括服务器100、第一用户2的终端设备200、第二用户3的终端设备300、与第一用户2的支付相关联的金融交易服务器400以及与第二用户3的账户相关联的金融交易服务器500。

第一用户2是受第二用户3委托来对于在线上或线下商店处销售的商品或服务(在下文中，被统称为“商品”)进行垫付款的用户，并且第一用户2对于所购买的商品进行垫付款并且从第二用户3接收针对该垫付款的付款。第二用户3是委托第一用户2为商品进行垫付款的用户，并且第二用户3偿还第一用户2代表第二用户3进行的付款。因此，第一用户2可以被称为“代理付款人”、“代理购买者”、“购买受托人”等，而第二用户3可以被称为“实际付款人”、“实际购买者”、“购买委托人”等。同时，可以有多个第二用户。

第一用户2的终端设备200和第二用户3的终端设备300是分别由第一用户2和第二用户3拥有并使用的终端设备，并且可以是智能电话、膝上计算机、平板、平板手机、个人数字助理(PDA)、智能手表、运动图像专家组阶段1或阶段2(MPEG-1或MPEG-2)音频层3(MP3)播放器等，但是不限于此。

服务器100提供根据要在下面描述的、本公开的各种实施例的代理支付服务。为此，服务器100可以提供在用户2、3的终端设备200、300上安装并运行的代理支付应用。因此，第一用户2和第二用户3可以访问服务器100或应用提供服务器(例如，游戏商店、应用商店等)并且将代理支付应用安装在他们的终端设备200、300上，执行并操纵已安装的代理支付应用，从而可以使用由服务器100提供的代理支付服务。

进一步地，服务器100可以注册订阅了代理支付服务的用户2、3。例如，第一用户2和第二用户3可以通过安装在他们的终端设备200、300上的代理支付应用来访问由服务器100提供的web页面以订阅由服务器100提供的代理支付服务，并且服务器100可以注册订阅了该服务的用户。在示例中，可以在注册期间将关于用户2、3的各种信息项目存储在服务器100中。

除非在本文中具体地提到了第一用户2或第二用户3对代理支付服务的订阅与否或者安装在终端设备200、300上的代理支付应用的存在与否，否则将在下面通过假定第一用户2和第二用户3是由服务器100提供的代理支付服务的成员并且第一用户2的终端设备200和第二用户3的终端设备300安装有由服务器100提供的代理支付应用来描述各种实施例。

第一用户2可以在根据第二用户3同意的协议进行支付之前首先请求第二用户3认可代理支付并且在这种请求被认可时才进行支付，使得第一用户2在进行支付的同时接收到来自第二用户3的支付。

具体地，第一用户2可以通过安装在终端设备200上的代理支付应用来向服务器100发送代理支付认可请求。在示例中，代理支付认可请求可以包括与代理支付相关联的各种信息，诸如垫付款的还款将被转账到的第一用户2的账户信息、被请求认可的第二用户3的信息、预期付款金额等。

响应于从第一用户2的终端设备200接收到代理支付认可请求，服务器100通过使用包括在代理支付认可请求中的各种信息项目来生成询问是否认可代理支付认可请求的消息，并且将所生成的消息发送到第二用户3的终端设备300。

响应于从服务器100接收到询问是否认可的消息，第二用户3的终端设备300可以执行代理支付应用以显示所接收到的消息，并且当第二用户3认可第一用户2的认可请求时，将包括第二用户3的账户信息的认可发送到服务器100。

响应于从第二用户3的终端设备300接收到认可，服务器100可以生成指示第一用户2的认可请求被认可的认可消息，并且将所生成的消息发送到第一用户2的终端设备200。因此，当认可消息被显示在第一用户2的终端设备200上时，第一用户2可以确认对代理支付认可请求的认可，并且通过使用各种支付手段来根据与第二用户3的协议进行支付。

当第一用户2根据与第二用户3的协议进行支付时，服务器100可以通过与第一用户2的支付相关联的金融交易服务器400来接收第一用户2的支付信息，生成用于请求从第二用户3的账户向第一用户2的账户汇款的账户转账信息，并且将所生成的信息发送到与第二用户3的账户相关联的金融交易服务器500。

因此，与第二用户3的账户相关联的金融交易服务器500根据从服务器100接收到的账户转账信息进行账户转账，使得第一用户2在根据与第二用户3的代理支付协议进行支付的同时从第二用户3得到偿还。

下面将通过参考图2、图3和图4具体地描述服务器100提供代理支付服务的各种实施例。图2是根据本公开的实施例的服务器100的框图。

图2是根据本公开的实施例的服务器的框图。

参考图2，服务器100包括通信器110和处理器120。

通信器110可以通过各种有线和无线网络来执行与外部终端设备或另一服务器的通信。为此，通信器110可以根据各种通信方法包括有线和无线通信模块。具体地，通信器110可以包括根据各种通信标准的有线通信模块(未例示)中的至少一种，所述通信标准诸如高清多媒体接口(HDMI)、通用串行总线(USB)、电气与电子工程师协会(IEEE)1394、推荐标准(RS-232)、RS-422、RS-485和以太网。进一步地，通信器110可以包括无线通信模块(未例示)，诸如无线本地接入网络(LAN)通信模块(未例示)或移动通信模块(未例示)。在示例中，无线LAN通信模块(未例示)是根据诸如Wi-Fi、IEEE、WiBro等的无线通信协议与外部网络连接以执行通信的模块，而无线通信模块是根据诸如第三代(3G)、第三代合作伙伴计划(3GPP)、长期演进(LTE)等的各种移动通信标准与移动通信网络连接以执行通信的模块。

具体地，在处理器120的控制下与第一用户2和第二用户3的终端设备200、300以及第一用户2和第二用户3的金融交易服务器400、500通信的通信器110可以发送和接收各种信息项目。在示例中，与第一用户和第二用户相关联的金融交易服务器400、500可以包括与第一用户2的支付相关联的金融交易服务器400以及与第二用户3的账户相关联的金融交易服务器500，但是不限于此。与第一用户2的支付相关联的金融交易服务器400可以是第一用户2的增值网络(VAN)服务器、支付网关(PG)服务器、信用卡公司服务器、交易银行服务器、交易证券公司服务器等，而与第二用户3的账户相关联的金融交易服务器500可以是第二用户3的交易银行服务器、交易证券公司服务器等。

同时，如上面在图1中所描述的，服务器100可以提供被安装在注册到服务器100的用户2、3的终端设备200、300上以使用代理支付服务的代理支付应用，并且根据各种实施例将代理支付服务提供给用户2、3。为此，通信器110可以执行与诸如应用商店、游戏商店等的外部应用提供服务器(未例示)的通信，并且将代理支付应用上传到应用提供服务器(未例示)或者更新该代理支付应用。进一步地，通信器110可以将代理支付应用发送到通过能够提供该代理支付应用的web页面来访问服务器100的用户的终端设备200、300。

存储部(未例示)可以存储用于要在下面描述的服务器100的操作的各种信息项目、数据和程序。为此，存储部(未例示)可以作为随机存取存储器(RAM)、只读存储器(ROM)、闪速存储器、硬盘驱动器(HDD)、固态驱动器(SSD)等被实现，但是实施例可以不限于此。

处理器120可以控制服务器100的总体操作。为此，处理器120可以包括中央处理单元(CPU)、控制器、应用处理器(AP)、通信处理器(CP)和ARM处理器中的一种或更多种。

具体地，处理器120可以提供根据本公开的各种实施例的代理支付服务。在示例中，由服务器100提供的“代理支付服务”是指当代理付款人在根据代理付款人与实际付款人之间的代理支付协议来对于商品进行垫付款之前向实际付款人请求代理支付认可并且接收到认可时使得能够在代理付款人进行支付的同时从实际付款人的账户转账全部或部分付款的服务。

为此，处理器120可以将订阅了代理支付服务的用户注册到服务器100并且将代理支付服务提供给已注册用户。在示例中，处理器120可以将订阅了服务的用户的信息与相应用户匹配并且将结果存储在存储部(未例示)中。例如，处理器120可以基于用户识别信息(诸如用户2、3的识别符(ID)、姓名、电话号码)、用户2、3的终端设备200、300识别信息(诸如媒体访问控制(MAC)地址、序列号等)、安装在用户2、3的终端设备200、300上的代理支付应用的设备信息等来存储用户信息，但是不限于此。

将在下面通过参考图3来描述根据各种实施例的处理器120的操作。

图3是根据本公开的实施例的代理支付系统的操作的例示。

参考图3，当通过通信器110从代理付款人(即，第一用户2)的终端设备200接收到代理支付认可请求时，处理器120可以控制通信器110以向实际付款人(即，第二用户3)的终端设备300发送询问是否认可代理支付认可请求的消息。在示例中，代理支付认可请求可以包括：将要被请求代理支付认可的第二用户3的信息、代理支付的预期付款额信息(即，要由第一用户2根据第一用户2与第二用户3之间的代理支付协议来支付以购买商品的垫付款的金额)以及用于当第一用户2进行支付时接收来自第二用户3的还款的第一用户2的账户信息。

具体地，响应于从第一用户2的终端设备200接收到代理支付认可请求，处理器120可以确定第一用户2和第二用户3是否被注册到服务器100。

例如，处理器120可以通过使用根据服务器100与终端设备200之间的通信方法在通信过程期间交换的设备识别信息来识别终端设备200。换句话说，可以根据终端设备200与服务器100之间的通信方法来给由终端设备200发送到服务器100的代理支付认可请求添加或提供终端设备200的识别信息，并且处理器120可以通过使用该识别信息来识别发送了代理支付认可请求的终端设备200。处理器120可以将所识别的终端设备200的信息与存储在存储部(未例示)中的用户信息相比较以确定第一用户2是否被注册到服务器100。

然而，处理器120用于确定第一用户2是否被注册的方法不限于上述。例如，第一用户2的终端设备200可以发送包括第一用户2的信息(例如，第一用户2识别信息、终端设备200识别信息、安装在终端设备200上的代理支付应用的识别信息等)的代理支付认可请求或者发送包括第一用户2信息的代理支付认可请求。进一步地，处理器120可以将所接收到的第一用户2信息与存储在存储部(未例示)中的用户信息相比较以确定请求代理支付认可的第一用户2是否被注册到服务器100。

同时，处理器120可以将包括在代理支付认可请求中的第二用户3的信息(具体地为用户识别信息，但是不限于此)与存储在存储部(未例示)中的用户信息相比较以确定第二用户3是否被注册到服务器100。

因此，当第一用户2和第二用户3被确定为已注册用户时，处理器120可以通过使用包括在代理支付认可请求中的各种信息项目以及存储在存储部(未例示)中的第一用户2和第二用户3的信息来生成询问是否认可代理支付认可请求的消息。在示例中，询问是否认可的消息可以包括关于第一用户2请求对代理支付的认可的信息(例如，用户识别信息，但是不限于此)、预期付款额信息、关于需要第二用户3的认可的支付金额的信息等。

同时，根据本公开的实施例，代理支付认可请求可以进一步包括第一用户2打算进行支付的商品的信息、销售对应商品的线上或线下商店的信息、预期付款时间的信息等，并且处理器120可以生成询问是否认可的消息，所述消息可以进一步包括包含在代理支付认可请求中的这些信息。

下文将具体地说明根据各种实施例的用于计算包括在询问是否认可的消息中的需要第二用户3认可的支付金额的方法。

第一用户2与第二用户3之间的代理支付协议可以包括第一用户2对他或她进行的垫付款没有责任并且因此第一用户2从第二用户3接收全部付款的协议(“第一类型协议”)，以及第一用户2对他或她进行的垫付款有部分责任并且因此第一用户2仅接收第二用户3负责的部分付款的另一协议(“第二类型协议”)。

例如，第一类型协议的一个示例可以包括如下情形：第二用户3在稍后偿还付款的条件下请求第一用户2购买书籍，并且第一用户2同意这样做。根据此协议，第一用户2可以从第二用户3接收他或她购买书籍所进行的全部垫付款。同时，第二类型协议的示例可以包括如下情形：第一用户2和第二用户3每人都同意在第一用户2对于吃饭的全部价格进行垫付款的条件下分担吃饭的一半费用，使得第二用户3付款的份额由第一用户2代表第二用户3通过代理支付来支付，并且第一用户2接收除了他自己分担的责任之外的第二用户3分担的责任的还款。

因此，取决于上述的代理支付协议的类型，即使当预期付款金额相同时需要第二用户3认可的支付金额也可能变化。因此，为了提供基于代理支付协议的类型的代理支付服务，处理器120可以利用要在下面描述的各种方法通过使用包括在代理支付认可请求中的信息来计算需要第二用户3认可的支付金额。

具体地，根据本公开的实施例，从第一用户2的终端设备200接收到的代理支付认可请求可以进一步包括模式信息以及第二用户3的信息和预期付款额的信息。模式信息可以包括指示第一模式(对应于上述的第一类型协议)和第二模式(对应于第二类型协议)中的一种的信息，其中，在第一模式中，第二用户3承担全部预期付款额，在第二模式中，第一用户2和第二用户3分担预期付款额的责任。

在这种情况下，当包括在代理支付认可请求中的模式信息是第一模式时，处理器120可以通过将预期付款额除以第二用户3的总数来计算需要第二用户3认可的支付金额，而当模式信息是第二模式时，处理器120可以通过将预期付款额除以第一用户2和第二用户3的总数来计算需要第二用户认可的支付金额。

例如，当预期付款额是30,000韩元并且模式信息是第一模式时，处理器120可以通过将预期付款额(30,000韩元)除以第二用户的总数(1)(即，通过将30,000韩元除以1，这得到30,000韩元)来计算需要第二用户3认可的支付金额。同时，当预期付款额是30,000韩元并且模式信息是第二模式时，处理器120可以通过将预期付款额(即，30,000韩元)除以第一用户2和第二用户的总数(即，2)(即，通过将30,000韩元除以2，这得到15,000韩元)来计算需要第二用户3的认可的支付金额。

同时，根据本公开的另一实施例，即使当代理支付认可请求不包括单独的模式信息时，处理器120也可以根据第一用户2的信息是否作为将承担预期付款额的用户的信息被包括来确定第一模式或第二模式的一种。

换句话说，当代理支付认可请求不包括作为将承担预期付款额的用户的信息的第一用户2信息时，第一用户2对预期付款额没有责任，并且因此，处理器120可以将当前模式确定为第一模式。相反地，当代理支付认可请求包括作为将承担预期付款额的用户的信息的第一用户2信息时，第一用户2对预期付款额有责任，并且因此，处理器120可以将当前模式确定为第二模式。已经在上面描述了处理器120在确定模式之后的操作。

同时，根据本公开的另一实施例，从第一用户2的终端设备200接收到的代理支付认可请求可以包括关于分担预期付款额责任的用户的数量的信息。在这种情况下，处理器120可以通过将预期付款额除以分担付款责任的用户的数量来计算需要第二用户3认可的支付金额。

例如，当预期付款额是30,000韩元并且分担责任的用户的数量是1时(如在第一用户2和第二用户3对第一类型协议取得一致意见的示例中)，处理器120可以通过将预期付款额(30,000韩元)除以1(这得到30,000韩元)来计算需要第二用户3认可的支付金额。同时，当预期付款额是30,000韩元并且分担责任的用户的数量是2时(如在第一用户2和第二用户3对第二类型协议取得一致意见的示例中)，处理器120可以通过将预期付款额(30,000韩元)除以2(这得到15,000韩元)来计算需要第二用户3认可的支付金额。

同时，根据本公开的另一实施例，从第一用户2的终端设备200接收到的代理支付认可请求可以包括份额信息。份额信息可以包括关于相对于预期付款额第一用户2和第二用户3的付款比例的信息或关于第一用户2和第二用户3的预期付款额的支付份额的信息。在这种情况下，处理器120可以通过根据份额信息划分预期付款额来计算需要第二用户3认可的支付金额。

具体地，当份额信息是分担预期付款额的比例时，处理器120可以基于该比例来计算第一用户2对预期付款额的分担责任以及第二用户3对预期付款额的分担责任，并且基于第二用户3的分担责任来计算需要第二用户3认可的支付金额。

例如，当预期付款额是30,000韩元并且比例是0:1时(如在第一用户2和第二用户3对第一类型协议取得一致意见的示例中)，处理器120可以计算第一用户2的分担责任为0韩元，并且计算第二用户3的分担责任为30,000韩元，并且计算需要第二用户3认可的支付金额为30,000韩元。

同时，当预期付款额是30,000韩元并且比例是1:1时(如在第一用户2和第二用户3对第二类型协议取得一致意见的示例中)，处理器120可以计算第一用户2的分担责任和第二用户3的分担责任分别为15,000韩元，并且基于第二用户3的分担责任计算需要第二用户3认可的支付金额为15,000韩元。1:1的比例是为了说明的方便而举例说明的，但各种实施例不限于此。因此，可以使用任何比例。

同时，当份额信息是每个用户在预期付款额中的分担付款时，处理器120可以将与第二用户3相对应的分担金额计算为需要第二用户3认可的支付金额。例如，当预期付款额是30,000韩元并且分担责任对于第一用户2来说是0韩元而对于第二用户3来说为30,000韩元时，处理器120可以将30,000韩元计算为需要第二用户3认可的支付金额。同时，当预期付款额是30,000韩元并且分担责任对于第一用户2来说是15,000韩元而对于第二用户3来说为15,000韩元时，处理器120可以将15,000韩元计算为需要第二用户3认可的支付金额。在这种情况下，分担责任也可以与上面所提供的示例不同。

如上所述，当根据本公开的各种实施例计算需要第二用户3认可的支付金额时，处理器120可以生成询问是否认可的消息，所述消息包括所计算出的需要第二用户3认可的支付金额。

当生成了询问是否认可代理支付认可请求的消息时，处理器120可以控制通信器110以将所生成的消息发送到第二用户3的终端设备300。如上所述，因为代理支付认可请求包括第二用户3的信息(例如，第二用户3的ID或姓名，但是不限于此)，所以处理器120可以通过使用存储在存储部(未例示)中的第二用户3的信息(例如，终端设备300的电话号码或识别信息，但是不限于此)来将所生成的消息发送到第二用户3的终端设备300。

根据本公开的实施例，当终端设备300的电话号码或识别信息被包括在代理支付认可请求的第二用户3信息中时，处理器120可以通过使用包括在代理支付认可请求中的信息而不是使用存储在存储部(未例示)中的信息来将所生成的消息发送到第二用户3的终端设备300。

同时，当从第一用户2的终端设备200接收到代理支付认可请求时，处理器120可以将包括在代理支付认可请求中的第一用户2的账户信息临时存储在存储部(未例示)中。第一用户2的账户信息可以是通过安装在终端设备200上的代理支付应用加密的信息，并且处理器120可以对经加密的第一用户2的账户信息进行解密并且根据需要使用该账户信息。在示例中，加密和解密方法可以不受限制。同时，可以在具体付款被从第二用户3的账户转账到第一用户2的账户之后从存储部(未例示)中删除第一用户2的账户信息，将在下面对此进行进一步描述。

可以在第二用户3的终端设备300上显示询问是否认可发送到第二用户3的终端设备300的代理支付认可请求的消息，并且因此，第二用户3可以认可或者可以不认可该代理支付认可请求。

当代理支付认可请求被第二用户3认可时，通信器110可以从第二用户3的终端设备300接收包括第二用户3的账户信息的、针对代理支付认可请求的认可。

响应于接收到针对代理支付认可请求的认可，处理器120可以将第二用户3的账户信息临时存储在存储部(未例示)中。第二用户3的账户信息可以是经加密的信息，并且处理器120可以对经加密的第二用户3的账户信息进行解密并且根据需要使用该账户信息。在示例中，加密和解密方法可以不受限制。同时，在具体支付金额被从第二用户3的账户转账到第一用户2的账户之后，可以从存储部(未例示)中删除第二用户3的账户信息。

进一步地，响应于从第二用户3的终端设备300接收到针对代理支付认可请求的认可，处理器120可以生成针对代理支付请求的认可消息并且将所生成的消息发送到第一用户2的终端设备200。

在示例中，认可消息可以包括指示由第一用户2作出的代理支付认可请求被认可的信息。例如，认可消息可以包括指示需要第二用户3认可的预期付款额或支付金额被第二用户3认可的信息，但是不限于此。

响应于接收到认可消息，第一用户2的终端设备200可以显示该认可消息，并且因此，第一用户2可以确认第一用户2的代理支付认可请求被第二用户3认可。

同时，确认了代理支付请求被认可的第一用户2可以通过各种支付手段来进行支付，并且可以通过与第一用户2的支付相关联的金融交易服务器400在通信器110处接收关于由第一用户2进行的支付的支付信息。

例如，当第一用户2在线下商店处根据代理购买协议购买商品并通过使用卡来付款时，支付信息可以被发送到VAN服务器和卡公司服务器，并且通信器110可以从VAN服务器或卡公司服务器接收第一用户2的支付信息。

在示例中，如图3中所例示的，用于使用卡来进行支付的方法不仅包括第一用户2通过支付终端设备600-1直接刷他的或她的信用卡20的示例，而且包括第一用户2使用终端设备200来用信用卡支付的示例。换句话说，即使当第一用户2的终端设备200在与支付终端设备600-2的通信中进行支付时，支付信息也可以被发送到VAN服务器和卡公司服务器，并且通信器110可以从VAN服务器或信用卡公司服务器接收第一用户2的账户信息。

例如，当终端设备200是智能电话时，第一用户2可以在第一用户2的终端设备200上安装应用卡应用或移动卡应用，将信用卡注册到已安装的应用，并且因此，通过终端设备200来使用信用卡。对于应用卡方法，当用户执行应用时可以显示与信用卡相对应的条形码或快速响应(QR)码，并且支付终端设备600-2可以在处理信用卡支付的同时读取该条形码或QR码。对于移动卡方法，信用卡信息被存储在智能电话的全球用户身份模块(USIM)中或者信用卡被注册到已安装的应用，并且该应用被执行来将终端设备200标记到支付终端设备600-2。

同时，当第一用户2在线上商店根据代理购买协议购买商品并付款时，支付信息可以被发送到PG服务器、银行服务器或信用卡公司服务器，并且通信器110可以从PG服务器、银行服务器或信用卡公司服务器接收第一用户2的支付信息。

即使在没有来自服务器100的单独请求的情况下，接收到第一用户2的支付信息的金融交易服务器400也可以自动地将第一用户2的支付信息发送到服务器100或者应服务器100的请求发送支付信息。上述可以根据金融交易服务器400的运营商与服务器100的运营商之间的协议而变化。

如上所述，当通过通信器110接收到针对代理支付的第一用户的支付信息时，处理器120可以生成用于请求从第二用户3的账户向第一用户2的账户汇款的账户转账信息，并且将所生成的账户转账信息发送到与第二用户的账户相关联的金融交易服务器500。

具体地，响应于接收到支付信息，处理器120可以将从与第一用户2的支付相关联的金融交易服务器400接收到的支付信息与包括在第一用户2的代理支付认可请求中的各种信息相比较以确定与支付信息相对应的代理支付认可请求存在与否。

处理器120可以将从第一用户2的终端设备200接收到的代理支付认可请求临时存储在存储部(未例示)中。因此，存储部(未例示)可以存储使用代理支付服务的用户的每个代理支付认可请求。

同时，代理支付认可请求可以包括与要由第一用户2支付的商品相关联的信息、与销售对应商品的线上或线下商店相关联的信息、与预期付款时间相关联的信息等，以及第一用户2的账户信息、与第二用户3相关联的信息和预期付款额信息。支付信息可以包括与支付手段相关联的信息(例如，信用卡信息等)、与支付价格相关联的信息、与被支付商店相关联的信息、与要支付的商品相关联的信息、与支付时间相关联的信息等。

相应地，处理器120可以将包括在支付信息中的各种信息与包括在代理支付认可请求中的各种信息相比较，以确定与支付信息相对应的代理支付认可请求是否存在于存储在存储部(未例示)中的多个代理支付认可请求中。

当确定的结果揭示与支付信息相对应的代理支付认可请求存在时，处理器120可以生成用于请求从第二用户3的账户向第一用户2的账户汇款的账户转账信息。

具体地，当包括在代理支付认可请求中的预期付款额与包括在支付信息中的付款额相同时，处理器120可以生成需要第二用户3认可的支付金额被从第二用户3的账户转账到第一用户2的账户的账户转账信息。

需要第二用户3认可的支付金额可以与包括在上述询问是否认可的消息中的需要第二用户3认可的支付金额相同，并且因此，将在下面对它进行进一步描述。为了提供例示以便更好地理解，在模式信息被包括在代理支付请求中的实施例中，如上所述，需要第二用户3认可的支付金额可以在模式信息是第一模式时通过将预期付款额除以第二用户3的总数来获得，或者在模式信息是第二模式时通过将预期付款额除以第一用户2和第二用户3的总数来获得。因此，当第一用户2支付与预期付款额相同的付款额时，处理器120可以生成这种支付金额被从第二用户3的账户转账到第一用户2的账户的账户转账信息。

同时，当包括在代理支付认可请求中的预期付款额与包括在支付信息中的支付金额不同时，处理器120可以生成需要第二用户3认可的支付金额和支付金额中的较小者被从第二用户3的账户转账到第一用户2的账户的账户转账信息。

这是因为需要第二用户3认可的支付金额是通过基于预期付款额的上述各种方法计算出的，并且另外第二用户3通过询问是否认可的消息来确认需要认可的支付金额并且针对该金额认可代理支付认可请求。这也是因为如果第一用户2的付款额小于包括在询问是否认可的消息中的付款额(即，需要第二用户3认可的支付金额)将是不公平的，因为在这种情况下，第一用户2将接收到比他或她实际上支付的更多的付款。

同时，当第一用户2向第二用户3请求代理支付认可并接收到认可，但是预期稍后实际上要支付的付款额与被认可的预期付款金额不同时(更特别地，当预期付款额增加时)，第一用户2可以在进行支付之前针对具有修改后的预期付款额的新代理支付来请求第二用户3的认可。

处理器120可以控制通信器110以将上述所生成的账户转账信息发送到与第二用户3的账户相关联的金融交易服务器500，例如，发送到管理第二用户3的账户的银行服务器。因此，响应于接收到账户转账信息，与第二用户3的账户相关联的金融交易服务器500可以基于所接收到的账户转账信息来执行账户转账，并且因此，第一用户2可以在根据代理支付协议进行支付的同时从第二用户3接收付款。

最后，当服务器100相对于第一用户2的代理支付认可请求的代理支付服务完成时，处理器120可以相对于已完成的代理支付服务删除临时存储在存储部(未例示)中的信息。

具体地，当基于账户转账信息完成账户转账时，与第二用户3的账户相关联的金融交易服务器500可以向服务器100发送指示账户转账完成的消息。因此，当通过通信器110接收到指示账户转账完成的消息时，处理器120可以删除被临时存储在存储部(未例示)中的第一用户2的代理支付认可请求、第一用户2的账户信息、第二用户3的账户信息、第一用户2的支付信息等。

同时，上文举例说明并描述了实际付款人即第二用户3是一个人。然而，关于上述的第一类型协议和第二类型协议，第二用户可以包括多个第二用户。换句话说，例如，当第二用户I和第二用户II在稍后将偿还所对应的付款并且第一用户2同意上述做法的条件下委托第一用户2购买书籍时，这可以对应于存在多个第二用户的第一类型协议的示例，并且第一用户2可以从第二用户I和第二用户II接收购买书籍的全部付款，因为他没有分担责任。同时，当第一用户2、第二用户I和第二用户II同意各自承担吃饭费用的三分之一并且第一用户2首先代表其他人支付吃饭的全部付款时，代表其他人支付了吃饭费用的全部付款的第一用户2可以仅从第二用户I和第二用户II接收根据他们的分担责任的付款，并且因为第一用户2具有分担责任，所以上述情况可以适用作为存在多个第二用户的第二类型协议的示例。

下文将通过参考图4来描述当存在两个或更多个第二用户时根据各种实施例的处理器120的操作。

图4是根据本公开的实施例的代理支付系统的操作的例示。

参考图4，为了描述方便存在两个第二用户3-1、3-2。然而，本领域技术人员显然可以理解的是，以下实施例类似地适用于存在两个或更多个第二用户的情况。

同时，图4除了存在两个第二用户之外与图3相同。在图4的实施例中，除了根据从一个第二用户到多个第二用户的变化可能发生的修改之外，可以一律地应用图3中的处理器120的操作。因此，当在下面说明图4时，将不冗余地提供与图3重叠的操作或元件，而将主要描述仅由于包括多个第二用户而与图3的不同之处。

参考图4，在与第二用户3-1和第二用户3-2的代理支付协议下的第一用户2可以通过使用第一用户2的终端设备200来请求代理支付认可。因此，当通过通信器110从第一用户2的终端设备200接收到代理支付认可请求时，处理器120可以控制通信器110以向第二用户3-1的终端设备300-1和第二用户3-2的终端设备300-2发送询问是否认可代理支付认可请求的消息。在示例中，代理支付认可请求可以包括与第二用户3-1和第二用户3-2相关联的信息、预期付款额信息以及第一用户2的账户信息。

具体地，当从第一用户2的终端设备200接收到代理支付认可请求时，处理器120可以确定第一用户2、第二用户3-1和第二用户3-2是否被注册到服务器100。已经在上面描述了处理器120用于确定每个用户是否被注册到服务器100的方法。

因此，当第一用户2和第二用户3被确定为已注册用户时，处理器120可以通过使用包括在代理支付认可请求中的各种信息项目以及存储在存储部(未例示)中的第一用户2和第二用户3的信息来生成询问是否认可代理支付认可请求的消息。

例如，处理器120可以分别生成要发送到第二用户3-1的询问是否认可的消息以及要发送到第二用户3-2的询问是否认可的消息。分别被发送到第二用户3-1、3-2的询问是否认可的消息可以包括与分别需要第二用户3-1、3-2认可的支付金额相关联的信息。根据本公开的实施例，询问是否认可的消息可以进一步包括与第一用户2相关联的信息(例如，用户识别信息，但不限于此)、预期付款额信息、与要由第一用户2支付的商品相关联的信息、与销售对应商品的线上或线下商店相关联的信息、与预期付款时间相关联的信息等。

然而，实施例可以不限于上述内容，并且因此，处理器120可以生成向第二用户3-1和第二用户3-2发送的询问是否认可的一个消息。询问是否认可的一个消息应当包括与需要第二用户3-1认可的支付金额相关联的信息以及与需要第二用户3-2认可的支付金额相关联的信息。

下文将具体描述当存在多个第二用户时计算需要第二用户中的每一个认可的支付金额的各种实施例。

如上所述，取决于代理支付协议的类型，即使当预期付款额相同时，需要认可的支付金额也可以在第二用户3-1、3-2之间变化。因此，为了提供基于代理支付协议的类型的代理支付服务，处理器120可以利用要在下面描述的各种方法通过使用包括在代理支付认可请求中的信息来计算需要多个第二用户3-1、3-2认可的支付金额。

具体地，如上所述，当从第一用户2的终端设备200接收到的代理支付认可请求进一步包括模式信息时，处理器120可以通过使用预期付款额、与第二用户3-1、3-2相关联的信息以及模式信息来计算需要第二用户3-1、3-2认可的支付金额。

因此，当包括在代理支付认可请求中的模式信息是第一模式时，处理器120可以通过将预期付款额除以第二用户3的总数来计算需要第二用户3认可的支付金额，而当模式信息是第二模式时，处理器120可以通过将预期付款额除以第一用户2和第二用户3的总数来计算需要第二用户认可的支付金额。

例如，当预期付款额是30,000韩元并且模式信息是第一模式时，处理器120可以通过将预期付款额(30,000韩元)除以第二用户的总数(2)(即，通过将30,000韩元除以2，这得到15,000韩元)来计算需要第二用户3-1认可的支付金额以及需要第二用户3-2认可的支付金额。

同时，当预期付款额是30,000韩元并且模式信息是第二模式时，处理器120可以通过将预期付款额(即，30,000韩元)除以第一用户2和第二用户3-1、3-2的总数(即3)(即，通过将30,000韩元除以3，这得到10,000韩元)来计算需要第二用户3-1认可的支付金额以及需要第二用户3-2认可的支付金额。

同时，如上所述，在本公开的另一实施例中，即使当代理支付认可请求不包括单独的模式信息时，处理器120也可以根据第一用户2的信息是否作为将承担预期付款额的用户的信息被包括来确定第一模式或第二模式中的一种。

换句话说，处理器120可以在代理支付认可请求不包括作为将承担预期付款额的用户的信息的第一用户2信息时将当前模式确定为第一模式，或者否则，处理器120确定第二模式。已经在上面描述了处理器120在确定模式之后的操作。

进一步地，如上所述，根据本公开的另一实施例，从第一用户2的终端设备200接收到的代理支付认可请求可以包括关于分担预期付款额的责任的用户的数量的信息。在这种情况下，处理器120可以通过将预期付款额除以分担付款的责任的用户的数量来计算需要第二用户3认可的支付金额。

例如，当预期付款额是30,000韩元并且分担责任的用户的数量是2(如在第一用户2和两个第二用户3-1、3-2对第一类型协议取得一致意见的示例中)时，处理器120可以通过将预期付款额(30,000韩元)除以2(这得到15,000韩元)来计算需要第二用户3-1认可的支付金额和需要第二用户3-2认可的支付金额。

同时，当预期付款额是30,000韩元并且分担责任的用户的数量是3(如在第一用户2和第二用户3-1、3-2对第二类型协议取得一致意见的示例中)时，处理器120可以通过将预期付款额(30,000韩元)除以3(这得到10,000韩元)来计算需要第二用户3-1认可的支付金额和需要第二用户3-2认可的支付金额。

同时，如上所述，根据本公开的另一实施例，从第一用户2的终端设备200接收到的代理支付认可请求可以包括份额信息。份额信息可以包括关于相对于预期付款额第一用户2以及第二用户3-1和第二用户3-2的付款比例的信息或者关于第一用户2以及第二用户3-1和第二用户3-2的预期付款额的支付份额的信息。在这种情况下，处理器120可以通过根据份额信息划分预期付款额来计算需要第二用户3-1认可的支付金额和需要第二用户3-2认可的支付金额。

具体地，当份额信息是分担预期付款额的比例时，处理器120可以基于该比例针对预期付款额来计算第一用户2的分担责任、第二用户3-1的分担责任和第二用户3-2的分担责任，并且基于第二用户3-1、3-2的分担职责来计算需要第二用户3-1认可的支付金额和需要第二用户3-2认可的支付金额。

例如，当预期付款额是30,000韩元并且比例是0:1:1(如在第一用户2和两个第二用户3-1、3-2对第一类型协议取得一致意见的示例中)时，处理器120可以计算需要第二用户3-1认可的支付金额和需要第二用户3-2认可的支付金额分别为15,000韩元。同时，当预期付款额是30,000韩元并且比例是1:1:1(如在第一用户2和两个第二用户3-1、3-2对第二类型协议取得一致意见的示例中)时，处理器120可以计算需要第二用户3-1认可的支付金额和需要第二用户3-2认可的支付金额分别为10,000韩元。

同时，当份额信息是每个用户在预期付款额中的分担付款时，处理器120可以将与第二用户3-1和第二用户3-2相对应的分担金额计算为需要第二用户3认可的支付金额。

例如，当预期付款额是30,000韩元并且分担责任对于第一用户2来说为0韩元而对于第二用户3-1来说为15,000韩元且对于第二用户3-2来说为15,000韩元时，处理器120可以将15,000韩元计算为需要第二用户3-1和第二用户3-2认可的支付金额。同时，当预期付款额是30,000韩元并且分担责任对于第一用户2来说为10,000韩元而对于第二用户3-1来说为10,000韩元且对于第二用户3-2来说为15,000韩元时，处理器120可以将10,000韩元计算为需要第二用户3-1和第二用户3-2认可的支付金额。

同时，尽管上文描述了计算需要第二用户3-1和第二用户3-2认可的相同支付金额的份额信息的示例，然而实施例可以不限于此。因此，与支付的比例相关联的信息或与支付的分担责任相关联的信息能够与以上实施例不同。

如上所述，当根据本公开的各种实施例计算需要第二用户3-1和第二用户3-2认可的支付金额时，处理器120可以生成询问是否认可的消息，所述消息包括根据计算出的需要第二用户3-1认可的支付金额和需要第二用户3-2认可的支付金额。

当生成了询问是否认可代理支付认可请求的消息时，处理器120可以控制通信器110以将所生成的消息分别发送到第二用户3-1的终端设备300-1和第二用户3-2的终端设备300-2，已经在上面通过参考图3对此进行了描述。

同时，可以分别在第二用户3-1、3-2的终端设备300-1、300-2上显示发送到终端设备300-1、300-2的询问是否认可代理支付认可请求的消息，并且因此，第二用户3-1和第二用户3-2可以认可或者可以不认可该代理支付认可请求。

当代理支付认可请求分别被第二用户3-1和第二用户3-2认可时，通信器110可以分别从第二用户3-1的终端设备300-1和第二用户3-2的终端设备300-2接收包括第二用户3-1的账户信息的针对代理支付认可请求的认可以及包括第二用户3-2的账户信息的针对代理支付认可请求的认可。

因此，处理器120可以分别将第二用户3-1的账户信息和第二用户3-2的账户信息临时存储到存储部(未例示)，并且生成针对代理支付请求的认可消息并将所生成的消息发送到第一用户2的终端设备200。

例如，响应于从第二用户3-1、3-2的终端设备300-1、300-2接收到认可，服务器100可以生成指示第一用户2的认可请求被认可的单个认可消息，并且将所生成的消息发送到第一用户2的终端设备200。或者，根据本公开的实施例，服务器100可以按照从第二用户3-1、3-2的终端设备300-1、300-2接收到认可的顺序生成指示请求认可的消息并且将所生成的消息发送到第一用户2的终端设备200。

在示例中，认可消息可以包括指示需要第二用户3认可的预期付款额或支付金额被第二用户3认可的信息，但是不限于此。

第一用户2的终端设备200可以显示从服务器100接收到的认可消息，并且因此，第一用户2可以确认第一用户2的代理支付认可请求被第二用户3-1和/或第二用户3-2认可。

同时，确认代理支付请求被认可的第一用户2可以通过各种支付手段进行支付，并且可以通过与第一用户2的支付相关联的金融交易服务器400在通信器110处接收关于由第一用户2进行的支付的支付信息。因为已经在上面通过参考图3对此进行了描述，所以将不在下面对此进行进一步描述。

如上所述，当通过通信器110接收到针对代理支付的第一用户2的支付信息时，处理器120可以生成用于请求从第二用户3-1的账户和第二用户3-2的账户向第一用户2的账户汇款的账户转账信息，并且将所生成的账户转账信息分别发送到与第二用户3-1和第二用户3-2的账户相关联的金融交易服务器500。尽管图4例示了与第二用户3-1和第二用户3-2的账户相关联的金融交易服务器500是同一服务器，然而这些金融交易服务器也可以是彼此不同的。

具体地，当接收到支付信息时，处理器120可以将该支付信息与包括在第一用户2的代理支付认可请求中的各种信息相比较以确定是否存在与该支付信息相对应的代理支付认可请求。当确定的结果揭示存在与支付信息相对应的代理支付认可请求时，处理器120可以生成用于请求从第二用户3-1的账户向第一用户2的账户汇款的账户转账信息以及用于请求从第二用户3-2的账户向第一用户2的账户汇款的账户转账信息。

在示例中，当包括在代理支付认可请求中的预期付款额与包括在支付信息中的付款额相同时，处理器120可以生成用于将需要第二用户3-1认可的支付金额从第二用户3-1的账户转账到第一用户2的账户的账户转账信息以及用于将需要第二用户3-2认可的支付金额从第二用户3-2的账户转账到第一用户2的账户的账户转账信息。

同时，当包括在代理支付认可请求中的预期付款额与包括在支付信息中的支付金额不同时，处理器120可以生成用于将需要第二用户3-1、3-2认可的支付金额(即，需要第二用户3-1认可的支付金额和需要第二用户3-2认可的支付金额之和)和所述付款额中的较小者从第二用户3-1、3-2的账户转账到第一用户2的账户的账户转账信息。

具体地，当付款额超过需要第二用户3-1、3-2认可的支付金额时，处理器120可以生成用于将需要第二用户3-1认可的支付金额从第二用户3-1的账户转账到第一用户2的账户的账户转账信息以及用于将需要第二用户3-2认可的支付金额从第二用户3-2的账户转账到第一用户2的账户的账户转账信息。

例如，当需要第二用户3-1认可的支付金额和需要第二用户3-2认可的支付金额分别是10,000韩元并且预期付款额是30,000韩元以及由第一用户2进行的付款超过20,000韩元时，因为由第一用户2进行的付款与预期付款额不同并且付款额超过了作为需要第二用户3-1、3-2认可的支付金额的20,000韩元，所以处理器120可以生成用于从第二用户3-1的账户向第一用户2的账户转账10,000韩元的账户转账信息以及用于从第二用户3-2的账户向第一用户2的账户转账10,000韩元的账户转账信息。

同时，当付款小于需要第二用户3-1、3-2认可的支付金额时，处理器120可以通过根据分别需要第二用户3-1认可的支付金额和需要第二用户3-2认可的支付金额的比例来划分付款额而分别生成转账信息。

例如，当需要第二用户3-1认可的支付金额和需要第二用户3-2认可的支付金额分别是10,000韩元并且预期付款额是30,000韩元以及由第一用户2进行的付款少于20,000韩元时，因为由第一用户2进行的付款额与预期付款额不同并且付款额少于作为需要第二用户3-1、3-2认可的支付金额的20,000韩元，所以处理器120可以基于需要第二用户3-1认可的支付金额与需要第二用户3-2认可的支付金额之间的比例(1:1)来划分付款额(10,000韩元)，这得到5,000韩元，并且因此，生成从第二用户3-1的账户向第一用户2的账户转账5,000韩元的账户转账信息以及从第二账户3-2的账户向第一用户2的账户转账5,000韩元的账户转账信息。

同时，为了说明方便，上文举例说明了第一用户2和第二用户3-1、3-2对第二类型协议取得一致意见，并且需要第二用户3-1、3-2认可的支付金额通过1:1的比例彼此相同。然而，以上技术构思可以被应用于包括当用户的协议是第一类型时或当需要认可的支付金额的比例不是1:1时的任何示例。

处理器120可以将所生成的账户转账信息发送到与第二用户3的账户相关联的金融交易服务器500，并且因此，响应于接收到该账户转账信息，与第二用户3的账户相关联的金融交易服务器500可以分别基于所接收到的账户转账信息来执行账户转账，并且因此，第一用户2可以在根据代理支付协议进行支付的同时接收来自第一用户3-1和第二用户3-2的付款。同时，在账户转账完成之后，处理器120还可以相对于已完成的代理支付服务删除临时存储在存储部(未例示)中的各种信息。

同时，在分担预期付款额的用户的数量的信息被包括在代理支付认可请求中的以上实施例中，分担预期付款额的用户的数量可以包括不通过服务器100来使用代理支付服务的用户。

例如，第一用户2、第二用户3和第三用户可以对他们在一起吃饭并且各自分担吃饭费用的三分之一的协议取得一致意见，其中第一用户2代表其他人对于全部费用进行垫付款，然后第二用户3和第三用户偿还他们的分担责任。在这种情况下，第一用户2和第二用户3被注册到由服务器100提供的代理支付服务，而第三用户是非注册用户。

当假定吃饭费用总共为30,000韩元时，第一用户2可以在支付费用之前通过使用终端设备200向服务器100发送代理支付认可请求。代理支付认可请求可以包括与预期付款额(30,000韩元)相关联的信息、与分担预期付款额的用户的数量(即，3人)相关联的信息以及与第二用户3相关联的信息。

在这种情况下，处理器120可以通过将预期付款额(30,000韩元)除以分担责任的用户的数量(3)来将需要第二用户3认可的支付金额计算为10,000韩元，生成询问是否认可10,000韩元的消息，并且将该消息发送到第二用户3的终端设备300。

因此，当第一用户2在具有第二用户3的认可时进行30,000韩元的支付时，处理器120可以生成用于请求从第二用户3的账户向第一用户2的账户汇款10,000韩元(即，通过将预期付款额除以用户的数量而计算出的支付金额)的账户转账信息，并且将所生成的消息发送到与第二用户3的账户相关联的金融交易服务器500。结果，第一用户2可以从第二用户3接收到第二用户3的分担责任(即，10,000韩元)。

同时，因为第三用户未被注册到由服务器100提供的代理支付服务，所以第一用户2可能无法通过由服务器100提供的代理支付服务来接收第三用户的分担责任(即，10,000韩元)，在此情况下第一用户2可以通过单独的手段(诸如通过直接与第三用户会面、使用根据相关技术的账户转账方法等)来接收10,000韩元的还款。

上文举例说明了第二用户3是如图3所例示的一个人，但是各种实施例不限于此。因此，当如在图4中一样存在多个第二用户3时，分担代理支付的用户的数量包括未注册到服务器100的第三用户的上述示例是同样适用的。

同时，在本公开的实施例中，除了第二用户3的数量或协议的类型之外，接收到询问是否认可代理支付认可请求的消息的第二用户中的一些或全部可以不认可代理支付认可请求。参考作为示例的图4，服务器100分别向第二用户3-1的终端设备300-1和第二用户3-2的终端设备300-2发送询问是否认可代理支付认可请求的消息，并且第二用户3-1认可代理支付认可请求但是第二用户3-2不认可它。

因此，当通过通信器110从第二用户3-1的终端设备300-1接收到认可并且从第二用户3-2的终端设备300-2接收到不认可时，处理器120可以控制通信器110以生成询问是否继续代理支付的消息，并且将所生成的消息发送到第一用户2的终端设备200。询问是否继续代理支付的消息可以包括关于在多个第二用户当中谁认可且谁不认可代理支付认可请求的信息，但是不限于此。

因此，可以在第一用户2的终端设备200上显示询问是否继续代理支付的消息，并且第一用户2可以确认该消息并确定是否继续代理支付。

当尽管第二用户3-2对代理支付认可请求不认可但第一用户2依然进行了支付使得通过通信器110接收到了支付信息时，处理器120可以控制通信器110以生成用于请求从在所述多个第二用户3-1、3-2当中认可了代理支付请求的第二用户3-1的账户向第一用户2的账户汇款的账户转账信息，并且将所生成的消息发送到与第二用户3-1的账户相关联的金融交易服务器。应当通过另一单独的手段将第二用户3-2的分担责任偿还给第一用户2。

同时，虽然上文举例说明了从第二用户3-2的终端设备300-2接收到不认可的示例，但是实施例可以不限于此。例如，对于询问是否认可的消息，第二用户3-2的终端设备300-2可以在预定时间内不响应，在此情况下处理器120可以确定第二用户3-2不认可认可请求并且执行上述的后续操作。

进一步地，当第二用户3-1、3-2都不认可代理支付认可请求时，即使第一用户2进行支付也可以不通过由服务器100提供的代理支付服务来偿还支付。

同时，根据本公开的实施例，第二用户3可以修改包括在询问是否认可的消息中的、需要认可的支付金额并发出认可。

例如，尽管在图3中第二用户3接收到询问是否认可10,000韩元的的消息，然而第二用户3可以将该金额修改为5,000韩元并且基于经修改的金额认可代理支付。

在这种情况下，服务器100可以通过通信器110从第二用户3的终端设备300接收针对经修改的支付的认可，并且处理器120可以生成询问是否继续代理支付的消息并且将所生成的消息发送到第一用户2的终端设备。在示例中，询问是否继续代理支付的消息可以包括指示代理支付认可请求已被第二用户3修改的信息以及与经修改的金额相关联的信息，但是实施例可以不限于此。

因此，可以在第一用户2的终端设备200上显示询问是否继续代理支付的消息，并且第一用户2可以确认该消息并确定是否继续代理支付。

当第一用户2不管第二用户3-2对需要认可的经修改的支付金额的认可都进行支付使得通过通信器110接收到支付信息时，处理器120可以控制通信器110以生成用于请求从第二用户3的账户向第一用户2的账户汇款经修改的金额的账户转账信息并且将所生成的消息发送给与第二用户3的账户相关联的金融交易服务器。

同时，根据本公开的实施例，服务器100可以向终端设备提供与注册到服务器100的用户2、3、3-1、3-2的终端设备200、300、300-1、300-2中的每一个中存储的联系人列表相对应的代理支付服务用户列表。例如，当通过通信器110从第一用户2的终端设备200接收到联系人列表时，处理器120可以控制通信器110以确定在联系人列表中包括的用户当中订阅了代理支付服务的用户，生成与该联系人列表相对应的代理支付服务用户列表，并且将所生成的消息发送到第一用户2的终端设备200。

具体地，从第一用户2的终端设备200接收到的联系人列表可以包括各种信息项目，例如由第一用户2存储的各用户的屏幕名称(例如，名称、ID等)、地址、电子邮件地址和电话。因此，处理器120可以将包括在联系人列表中的各种信息与存储在存储部(未例示)中的、与订购了代理支付服务的用户相关联的信息相比较，并且确定联系人列表中包括的用户当中订阅了代理支付服务的用户。因此，处理器120可以生成与第一用户2的联系人列表相对应的代理支付服务用户列表，并且将所生成的消息发送到第一用户2的终端设备200。

因此，如下所述，第一用户2可以在代理支付服务用户列表上选择第二用户3并且将与第二用户3相关联的信息包括在代理支付认可请求中。

同时，根据本公开的实施例，当信用卡被注册在安装在终端设备200、300、300-1、300-2中的移动卡应用中时，服务器100能够提供用于通过终端设备来处理信用卡支付的各种移动卡服务。换句话说，根据相关技术的用于提供移动卡服务的服务器也可以提供上述的代理支付服务。然而，各种实施例不限于上面给出的示例。

同时，尽管上文描述了可以在服务器100与终端设备200、300、300-1、300-2之间发送和接收代理支付认可请求、询问是否认可的消息、针对代理支付认可请求的认可与否、认可消息，然而不一定应当同时发送和接收每个信息。相反，也可以相继地并按顺序发送和接收上面提到的信息。

图5是根据本公开的实施例的用户终端设备的构造的框图。

参考图5，终端设备1000可以是上述的第一用户2的终端设备200，或第二用户3、3-1、3的终端设备300、300-1、300-2。

同时，图5中所例示的终端设备1000的元件是仅为了说明方便而例示的，并且因此，可以根据终端设备1000的类型省略或修改一些元件，或者可以重新添加其他元件。

终端设备1000可以作为移动电话(诸如智能电话)被实现，但是实施例可以不限于此。因此，终端设备1000可以作为能够存储和实现应用并且执行与服务器100的通信的各种类型的设备被实现，所述各种类型的设备诸如PDA、便携式多媒体播放器(PMP)、平板、平板手机、智能手表、MP3播放器等。

尽管为了说明方便在本文中参考图5中所例示终端设备1000的构造作为第一用户2和第二用户3、3-1、3-2的终端设备200、300、300-1、300-2的代表性示例对实施例进行描述，然而应当注意的是，用户2、3、3-1、3-2的终端设备200、300、300-1、300-2的类型或构造也可以是彼此不同的。

参考图5，终端设备1000可以包括通信器1010、处理器1020、显示器1030、用户输入器1040和存储部1050。

通信器1010可以通过各种有线和无线网络来执行与外部设备的通信。具体地，通信器1010可以在处理器1020的控制下通过与提供代理支付服务的服务器100、支付终端设备600-2、应用提供服务器等的通信来发送和接收各种信息。

为此，通信器1010可以包括近场通信(NFC)模块和无线通信模块。NFC模块被配置为与定位在终端设备1000附近的外部设备无线地执行NFC。具体地，NFC模块可以包括蓝牙模块、磁安全传输(MST)模块、红外(IrDA)模块、NFC模块、Wi-Fi模块和Zigbee模块中的至少一种。无线通信模块被配置为根据诸如Wi-Fi、IEEE等的无线通信协议连接到外部网络，以执行与各种服务器的通信。此外，无线通信模块可以进一步包括移动通信模块，以连接到移动通信网络并且根据各种移动通信标准(诸如3G、3GPP、LTE等)执行通信。进一步地，通信器1010可以包括根据通信标准(诸如HDMI、USB、IEEE 1394、RS-232、RS-422、RS-485和以太网)的有线通信模块(未例示)中的至少一种。

显示器1030可以显示屏幕。在示例中，屏幕可以包括播放诸如图像、视频、文本、音乐的各种内容的屏幕、执行包括各种内容的应用的屏幕、图形用户界面(GUI)屏幕等。具体地，显示器1030可以显示在将在下面描述的处理器1020的控制下执行各种代理支付应用的屏幕。

为此，显示器1030可以作为各种显示器被实现，所述各种显示器诸如液晶显示器、薄膜晶体管-液晶显示器、有机发光二极管、柔性显示器、三维(3D)显示器等。此外，显示器1030可以与包括在用户输入器1040中的触摸板相结合以夹层结构形成触摸屏。

用户输入器1040被配置为接收用户命令以控制终端设备1000。为此，用户输入器1040可以包括各种按钮、触摸板、麦克风、相机等。因此，用户可以通过推动操纵、触摸操纵、语音发言、运动等将用户命令输入到终端设备1000。具体地，用户可以通过操纵用户输入器1040来实现代理支付应用或者输入各种信息或用户命令，以便从服务器100接收代理支付服务。

存储部1050被配置为存储终端设备1000的操作所必需的各种程序和数据，所述存储部1050可以作为RAM、ROM、闪速存储器、HDD、SSD等被实现。具体地，存储部1050可以存储各种应用和数据，以便通过终端设备200从服务器100接收代理支付服务。

处理器1020控制终端设备1000的总体操作。为此，处理器1020可以包括CPU、控制器、AP、CP和ARM处理器中的一种或更多种。具体地，处理器1020可以根据订阅了由服务器100提供的代理支付服务的用户的操纵来控制终端设备1000的操作并提供代理支付服务。

首先，处理器1020可以控制通信器1010以根据通过用户输入器1040接收到的用户操纵来连接服务器100或应用提供服务器，并且接收由服务器100提供的代理支付应用。所接收到的代理支付应用可以被存储在存储器150中。

当通过用户输入器1040输入用于实现代理支付应用的用户命令时，处理器1020可以控制显示器1030以实现存储在存储部1050中的代理支付应用并且显示根据随后的用户命令而执行各种代理支付应用的屏幕，从而向用户提供代理支付服务。

下文将通过参考图6、图7、图8A、图8B、图8C、图9、图10、图11A、图11B和图12中所例示的执行各种代理应用的屏幕来说明处理器120的具体操作。图6、图7、图8A、图8B、图8C、图9、图10、图11A、图11B和图12中所例示的屏幕可以仅仅是本公开的实施例中的一个，并且因此，可以以不同形式实现菜单的类型、名称、形式、位置、布置等。

图6例示了根据本公开的实施例的执行代理支付服务应用的屏幕。

参考图6，当用户通过选择显示在显示器1030上的代理支付应用图标1100来执行代理支付应用时，处理器1020可以控制显示器1030以显示执行代理支付应用的屏幕，所述屏幕包括账户管理菜单1120、用户列表接收菜单1130和认可请求菜单1140。

在示例中，账户管理菜单1120被提供来注册和管理订阅了代理支付服务的用户的账户，并且用户列表接收菜单1130被提供来获得终端设备1000中存储的用户的联系人列表中的用户当中被注册到由服务器100提供的代理支付服务的订阅用户的列表。进一步地，当用户是第一用户2时，认可请求菜单1140被提供来将上述的代理支付认可请求发送到服务器100。

用户可以选择显示在执行代理支付应用的屏幕上的各种菜单并且使用由服务器100提供的代理支付服务。

下文将通过参考当菜单1120、1130、1140中的每一个被显示时随后显示的、执行代理支付应用的屏幕的示例来具体地说明处理器1020的操作。

如上所述，第一用户2请求用于使用代理支付服务的代理支付认可，并且该对代理支付认可的请求可以在代理支付认可请求中包括将接收还款的第一用户2的账户信息。进一步地，当第二用户3认可代理支付认可请求时，第二用户3的终端设备300可以向服务器100发送包括作为将偿还特定付款的账户信息的第二用户的账户信息的认可。

因此，代理支付认可请求或所述认可包括用户的账户信息，并且第一用户2或第二用户3可以将包括在代理支付认可请求中或所述认可中的账户信息注册到(例如，利用账户管理菜单1120)代理支付应用。

具体地，当在图6中输入了选择账户管理菜单1120的用户命令时，处理器1020可以控制显示器1030以显示如图7中所例示的执行代理支付应用的屏幕。

图7例示了根据本公开的实施例的执行为订阅了由服务器提供的代理支付服务的用户提供的代理支付应用以注册他的账户信息的屏幕。

参考图7，用于注册账户信息的屏幕可以包括接收方注册菜单1121和发送方账户注册菜单1122。接收方注册菜单1121被提供来注册在用户是第一用户(即，代理付款人)时接收还款的账户，而发送方账户注册菜单1122被提供来注册在用户是第二用户3(即，实际付款人)时提取由用户认可的还款付款的账户。

因此，用户可以通过选择接收方注册菜单1121在代理支付应用中预先注册在使用代理支付服务时接收付款的账户，即，要被包括在代理支付认可请求中的账户；或者通过选择发送方账户注册菜单1122在代理支付应用中预先注册在使用代理支付服务时提取付款的账户，即，要被包括在所述认可中的账户。在示例中，注册到代理支付应用的用户账户信息可以用各种方法进行加密并存储。

同时，第一用户2的代理支付认可请求可以包括与将承担全部或部分预期付款额的用户相关联的信息，即，与接收代理支付认可请求的第二用户3相关联的信息。因为服务器100可以仅向订阅并注册到代理支付服务的用户提供代理支付服务，所以第一用户2在请求代理支付认可时应当知道谁是他的联系人列表中包括的用户当中的代理支付服务的成员。

因此，终端设备200可以被提供有来自服务器100的联系人列表当中订阅了由服务器100提供的代理支付服务的用户的列表。具体地，响应于接收到用户对于图6中所例示的用户列表接收菜单1130的选择命令，处理器1020可以将存储在存储部1050中的联系人列表发送到服务器100，并且从服务器100接收与该联系人列表相对应的代理支付服务用户列表。

因此，所接收到的代理支付服务用户列表可以用于构建用户选择项目以从执行代理支付应用的屏幕中选择第二用户3，将在下面对此进行描述。

同时，当用户是第一用户2时，用户可以通过服务器100向第二用户3请求代理支付的认可以便使用代理支付服务。具体地，第一用户2可以通过安装在终端设备200上的代理支付应用向服务器100发送代理支付认可请求，并且服务器100可以通过使用包括在代理支付认可请求中的各种信息来生成询问是否认可的消息并且将所生成的消息发送到第二用户3的终端设备300，并且第一用户2可以向第二用户3请求代理支付的认可。这同样适用于两个或更多个第二用户被选择的示例。

例如，当第一用户2从图6中所例示的执行代理支付应用的屏幕中选择认可请求菜单1140时，处理器1020可以控制显示器1030以如图8A、图8B、图8C、图9、图10、图11A和图11B一样显示用于请求代理支付认可的各种屏幕。第一用户2可以通过用户输入器1040在代理支付认可请求屏幕上输入各种信息，并且处理器1020可以控制通信器1010以将包括各种信息的代理支付认可请求发送到服务器100。

图8A、图8B和图8C是根据本公开的实施例的代理支付认可请求屏幕的例示。代理支付认可请求屏幕可以包括用于输入要被包括在代理支付认可请求中的各种信息的项目。

参考图8A，例示了根据代理支付协议的类型输入模式信息的模式选择项目的示例。图8A中所例示的第一模式涉及与上述的第一类型协议相对应的模式，并且第二模式涉及与上述的第二类型协议相对应的模式。因此，第一用户2可以从模式选择项目中选择一种模式并且将模式信息包括在代理支付认可请求中。

同时，模式信息的名称可以不限于图8A中所例示的第一模式和第二模式，并且可以根据实施例而变化。例如，可以使用诸如“代理支付模式”或“1:1支付模式”的其他名称代替第一模式，并且可以使用诸如“AA制支付模式”等的名称代替第二模式。

参考图8B，例示了预期付款额输入项目的示例，通过该预期付款额输入项目，第一用户2输入预期付款额。第一用户2可以通过如图8B中所例示的预期付款额输入项目来输入预期付款额。

参考图8C，例示了用于选择分担预期付款额的用户的用户选择项目的示例。包括在用户选择项目中的用户列表具有被注册到代理支付服务的所有用户。因此，第一用户2可以从显示在用户选择项目上的用户中选择一个或更多个第二用户3并且将与第二用户3相关联的信息包括在代理支付认可请求中。

根据图8A、图8B和图8C的实施例，第一用户2选择第一模式，输入30,000韩元作为预期付款额，并且选择BBB作为第二用户3。在此示例中，向服务器100发送的代理支付认可请求可以包括作为模式信息的第一模式、作为预期付款额信息的30,000韩元以及作为与第二用户3相关联的信息的BBB，并且服务器100可以通过使用包括在代理支付认可请求中的信息来生成询问是否认可代理支付认可请求的消息，并且将所生成的消息发送到第二用户3的终端设备300。询问是否认可的消息可以包括作为需要第二用户3认可的支付金额的、通过将预期付款额(30,000韩元)除以第二用户3的总数(1)而获得的30,000韩元。

当图8A的模式信息被选择为第二模式时，服务器100可以通过将预期付款额(30,000韩元)除以第一用户2和第二用户3的总数(2)来计算需要第二用户3认可的支付金额(15,000韩元)，并且向第二用户3的终端设备300发送包括以上计算结果的询问是否认可的消息。

同时，可以根据用户的选择和所输入的信息在显示器1030上顺序地显示图8A、图8B和图8C的项目中的每一个，但是实施例可以不限于此。因此，在一些实施例中可以在一个屏幕上显示项目中的每一个。

图9是根据本公开的实施例的代理支付认可请求屏幕的例示。

参考图9，如上面参考服务器100的实施例所描述的，服务器100的处理器120可以根据与第一用户2相关联的信息的存在与否来将模式确定为与分担预期付款额的用户相关联的信息。图9例示了与服务器100的以上操作相对应的代理支付认可请求屏幕的一个示例。

具体地，参考图9，代替模式选择项目，项目“我”作为分担预期付款额的用户之一被添加到用户选择项目，这与图8不同。因此，第一用户2可以通过选择项目“我”以将他自己包括在分担预期付款额的用户中来呈现第二模式。

如图9中所例示的，接收到包括“我”、“BBB”和“CCC”作为与分担预期付款额的用户相关联的信息的代理支付认可请求的服务器100可以将模式确定为第二模式，通过将预期付款额(30,000韩元)除以第一用户2(“我”)和第二用户(“BBB”，“CCC”)的总数(3)来计算需要第二用户认可的支付金额(即，10,000韩元)，并且分别向“BBB”和“CCC”的终端设备发送询问是否认可10,000韩元的消息。

当在用户选择项目处未选择项目“我”时，服务器100可以将模式信息确定为第一模式，并且分别向“BBB”和“CCC”的终端设备发送询问是否认可15,000韩元的消息。

图10是根据本公开的另一实施例的代理支付认可请求屏幕的例示。如上面参考服务器100的实施例所描述的，代理支付认可请求可以包括与分担预期付款额的用户的数量相关联的信息。图10例示了执行代理支付应用的相应屏幕的示例。

参考图10，包括了“所分担的用户的数量”项目。因此，第一用户2可以通过“所分担的用户的数量”项目来输入与分担预期付款额的用户的数量相关联的信息。

例如，当作为终端设备1000的用户的第一用户2、被注册到由服务器100提供的代理支付服务的“BBB”以及不使用代理支付服务的“XXX”每人分担付款的1/3时，并且当第一用户2对于全部付款(30,000韩元)进行垫付款时，第一用户2可以在垫付全部价款之后通过由服务器100提供的代理支付服务被偿还“BBB”的分担责任，并且单独地被偿还“XXX”的分担责任。

在这种情况下，第一用户2在如图10中所例示的代理支付认可请求屏幕中将预期付款额输入为30,000韩元，并且将分担责任的用户的数量输入为3，并且从用户选择项目中选择“BBB”。

因此，接收到包括3作为与分担责任的用户的数量相关联的信息的代理支付认可请求的服务器100可以通过将预期付款额(30,000韩元)除以分担责任的用户的数量(3)来计算需要第二用户认可的支付金额(即，10,000韩元)，并且向第二用户(即“BBB”)的终端设备发送询问是否认可10,000韩元的消息。

尽管图10举例说明了包括不使用代理支付服务的用户，但是实施例可以不限于此。

图11A和图11B是描绘了根据本公开的实施例的代理支付认可请求屏幕的例示。

参考图11A和图11B，如上面参考服务器100的实施例所描述的，代理支付认可请求可以包括与份额信息相关联的信息，并且图10例示了执行代理支付应用以输入关于相应支付份额的信息的相应屏幕的示例。

例如，当如图11A所例示的从用户选择项目中选择“我”、“BBB”和“CCC”时，处理器1020可以显示如图11B中所示出的支付份额信息输入项目。第一用户2可以直接在支付份额信息输入项目中输入付款，并且因此，将与每个用户的支付份额相关联的信息包括在代理支付认可请求中。

同时，尽管未例示，然而根据本公开的实施例，处理器1020可以显示包括用于输入与分担预期付款额的比例相关联的信息的项目的代理支付认可请求屏幕，并且可以显示可以进一步包括与要由第一用户2支付的商品相关联的信息、与商店相关联的信息、与预期付款时间相关联的信息等的代理支付认可请求屏幕。

当通过上述的代理支付认可请求屏幕输入各种信息时，并且当输入了用于发送代理支付认可请求的用户命令时，处理器1020可以控制通信器1010以向服务器100发送包括通过代理支付认可请求屏幕所输入的各种信息以及注册到代理支付应用的接收方信息的代理支付认可请求。

因此，从第一用户2的终端设备200接收到代理支付认可请求的服务器100可以通过使用包括在代理支付认可请求中的各种信息来生成询问是否认可代理支付认可请求的消息，并且将所生成的消息发送到第二用户3的终端设备300。

从服务器100接收到询问是否认可的消息的第二用户3的终端设备300可以显示所接收到的消息。具体地，当终端设备1000是第二用户2的终端设备300时，如果通过通信器1010接收到询问是否认可的消息，则处理器1020可以控制显示器1030以显示所接收到的消息。在示例中，询问是否认可的消息可以包括关于请求对代理支付的认可的第一用户2的信息以及关于需要第二用户3认可的支付金额的信息。

图12例示了根据本公开的实施例的在第二用户的终端设备的显示器上以弹出形式显示的询问是否认可的消息。

参考图12，第一用户2(例如，“ZZZ”)正在请求对10,000韩元的付款额进行认可。

因此，第二用户3可以通过经由用户输入器1040选择包括在认可消息中的认可图标1201来认可第一用户2的认可请求，或者通过选择拒绝图标1202来不认可第一用户2的认可请求。

显示询问是否认可的消息1200的实施例可以不限于图12。例如，关于用于显示消息的方法，代替图12的弹出形式，可以在提供了用于确认消息1200的用户命令时显示消息描述。进一步地，除了图12中所示出的信息之外，所显示的消息1200的描述可以进一步包括与要由第一用户2支付的商品相关联的信息、与商店相关联的信息、与付款时间相关联的信息等。

因此，当第二用户3认可或不认可认可请求时，处理器1020可以控制通信器1010以将相应的认可结果发送到服务器100。

具体地，当第二用户3认可认可请求时，第二用户3的终端设备200的处理器1020可以控制通信器1010以向服务器100发送包括被注册到代理支付应用的发送方账户信息的针对代理支付认可请求的认可。当第二用户3不认可认可请求时，处理器1020可以控制通信器1010以向服务器100发送对代理支付认可请求的不认可。

从第二用户3的终端设备300接收到认可或不认可的服务器100可以生成认可消息、不认可消息，或者根据情况，生成询问是否继续代理支付的消息，并且将所生成的消息发送到第一用户2的终端设备200。

当终端设备1000是第一用户2的终端设备200，并且当如上所述从服务器100接收到认可消息、不认可消息或询问是否继续代理支付的消息时，处理器1020可以控制显示器1030以显示所接收到的消息。因此，第一用户2可以确认他的或她的代理支付认可请求被认可或不认可。

确认了上述消息的第一用户2可以通过使用各种支付手段来根据代理支付协议进行支付或者可以不进行支付，并且在进行支付时，可以在进行支付的同时被转账根据协议的还款，如上面参考服务器100所描述的。

同时，根据本公开的实施例，当终端设备1000是第一用户2的终端设备200时，第一用户2可以通过使用终端设备1000来进行支付。例如，当第一用户2订阅了应用卡服务或移动卡服务并且将应用卡应用或移动卡应用安装在终端设备1000上时，可以通过将卡(信用卡、支票卡、借记卡、现金卡等)注册到已安装的应用上经由终端设备1000来使用该卡。

具体地，关于应用卡方法，当第一用户2实现应用卡应用时，处理器1020可以控制显示器1030以显示与注册到应用的卡对应的条形码或QR码。因此，可以通过使用在线下商店处提供的支付终端设备600-2读取显示在终端设备1000上的条形码或QR码来执行卡支付。

同时，关于移动卡方法，当第一用户2执行移动卡应用时，处理器1020可以控制通信器1010以无线地向支付终端设备600-2发送终端设备1000内的集成电路(IC)芯片中存储的卡信息或注册到应用的卡信息。支付终端设备600-2与通信器1010之间的无线通信方法可以是近距离通信方法，诸如NFC方法或MST方法，但是实施例可以不限于此。因此，第一用户2可以执行移动卡应用，然后通过在支付终端设备600-2上标记终端设备1000来执行卡支付。

同时，当第一用户2根据代理支付协议在网络上购买在线上商店处销售的各种商品或服务并进行网上支付时，处理器1020可以控制显示器1030以连接提供了与相应线上商店相关联的支付服务的各种服务器并且显示支付页面。因此，第一用户2可以通过支付页面来进行网上支付。

同时，尽管上文举例说明了终端设备1000是移动设备，然而实施例可以不限于此。即使当终端设备1000不是诸如台式个人计算机(PC)、智能电视(TV)等的移动设备时，也可以应用本公开的技术构思。例如，当第一用户2在家里通过使用PC向第二用户3请求对代理支付的认可时并且当认可请求被认可时，第一用户2可以通过在线上商店或线下商店处根据代理支付协议执行支付来在进行支付的同时接收针对支付付款的还款。

图13是例示了根据本公开的实施例的服务器的控制方法的流程图。

参考图13，将不再重复地提供上面已经描述的详细说明。响应于从第一用户2的终端设备200接收到包括与代理支付相关联的预期付款额、第一用户2的账户信息以及与一个或更多个第二用户3相关联的信息的代理支付认可请求，服务器100可以在操作S1310中向第二用户3的终端设备300发送询问是否认可代理支付认可请求的消息。

根据本公开的实施例，代理支付认可请求可以进一步包括指示预期付款额全部由第二用户3支付的第一模式以及预期付款额由第一用户2和第二用户3分担的第二模式中的一种的模式信息。

在这种情况下，当模式信息是第一模式时，服务器100可以向第二用户3的终端设备300发送询问如下事项的消息：是否认可通过将预期付款额除以第二用户3的总数而计算出的付款额。当模式信息是第二模式时，服务器100可以向第二用户3的终端设备300发送询问如下事项的消息：是否认可通过将预期付款额除以第一用户2和第二用户3的总数而计算出的付款额。

因此，当从第二用户3的终端设备300接收到包括第二用户3的账户信息的认可时，服务器100可以在操作S1320中向第一用户2的终端设备200发送针对代理支付认可请求的认可消息。

接收到认可消息的第一用户2可以根据代理支付协议进行支付。因此，当接收到第一用户2针对代理支付的支付信息时，服务器100可以在操作S1330中向与第二用户3的账户相关联的金融交易服务器发送用于请求从第二用户3的账户向第一用户2的账户汇款的账户转账信息。

具体地，当模式信息是第一模式时并且当接收到支付信息时，服务器100可以向与第二用户3的账户相关联的金融交易服务器500发送用于请求通过将预期付款额除以第二用户3的总数而计算出的付款额的汇款的账户转账信息。当模式信息是第二模式时并且当接收到支付信息时，服务器100可以向与第二用户3的账户相关联的金融交易服务器500发送用于请求通过将预期付款额除以第一用户2和第二用户3的总数而计算出的付款额的汇款的账户转账信息。

同时，根据本公开的另一实施例，代理支付认可请求可以进一步包括与分担预期付款额的用户的数量相关联的信息。在这种情况下，服务器100可以向第二用户3的终端设备300发送询问如下事项的消息：是否认可通过将预期付款额除以分担责任的用户的总数而计算出的付款额。根据本公开的实施例，分担责任的用户除了包括第一用户2和第二用户3之外可以进一步包括不使用经由服务器100的代理支付服务的用户。

在这种情况下，当接收到支付信息时，服务器100可以向与第二用户3的账户相关联的金融交易服务器500发送用于请求通过将预期付款额除以分担责任的用户的数量而计算出的付款额的汇款的账户转账信息。

同时，根据本公开的另一实施例，代理支付认可请求可以包括与第一用户2与第二用户3之间的分担预期付款额的比例或预期付款额的支付份额相关联的份额信息。在这种情况下，服务器100可以向第二用户3的终端设备300发送询问如下事项的消息：是否认可通过将预期付款额除以份额信息而计算出的付款额。

当接收到支付信息时，服务器100可以向与第二用户3的账户相关联的金融交易服务器500发送用于请求通过根据份额信息来划分预期付款额而计算出的付款额的汇款的账户转账信息。

同时，根据本公开的实施例，当存在多个第二用户3时，可以从所述多个第二用户3当中的某些用户的终端设备接收针对代理支付认可请求的不认可，并且可以从其他用户的终端设备接收到认可。在这种情况下，服务器100可以向第一用户2的终端设备300发送询问是否继续代理支付的消息。

此后，当接收到支付信息时，服务器100可以向与多个第二用户当中的认可代理支付认可请求的用户的账户的每一个相关联的金融交易服务器发送用于请求从认可代理支付认可请求的用户的账户向第一用户2的账户汇款的账户转账信息。

同时，根据本公开的实施例，询问是否认可的消息可以包括与需要第二用户认可的支付金额相关联的信息。当预期付款额不同于包括在支付信息中的付款额时，服务器100可以向与第二用户3的账户相关联的金融交易服务器500发送用于请求需要第二用户3认可的支付金额和已付金额中的较小者的汇款的账户转账信息。

同时，根据本公开的实施例，第一用户2可以通过使用他的终端设备200来进行支付。在这种情况下，当第一用户2的终端设备200通过与支付终端设备600-2通信来执行支付时，服务器100可以从与第一用户2的支付相关联的金融交易服务器400接收支付信息。

根据上述的各种实施例，代理付款人可以在进行支付的同时接收还款而不必暴露个人信息，并且对于实际付款人而言，他或她也能够方便地偿还付款，而不必经历繁琐的过程。换句话说，能够解决在代理购买过程期间可能发生的还款的不便和暴露个人信息的风险。

具体地，根据上述的各种实施例，代理付款人的支付和实际付款人的支付汇款能够作为一系列操作被一次处理，并且能够解决不得不执行另一应用(诸如用于对代理付款人进行支付的移动银行应用)的实际付款人的不便。进一步地，因为用户账户信息被注册并存储在用户终端设备上安装的代理支付应用中而不是被注册并存储在服务器100中，并且在代理支付服务过程中在内部处理之后被从服务器100中移除，所以能够防止个人信息的暴露。

同时，根据以上各种实施例的服务器100的处理器120的操作或服务器100的控制方法可以作为软件被生成并被安装在服务器100上。

例如，服务器100可以安装存储有用于执行服务器100的控制方法的程序的非暂时性计算机可读介质，所述控制方法包括：响应于从第一用户2的终端设备200接收到包括针对代理支付的预期付款额、第一用户2的账户信息以及与一个或更多个第二用户3相关联的信息的代理支付认可请求，向第二用户3的终端设备300发送询问是否认可代理支付认可请求的消息；响应于从第二用户3的终端设备300接收到包括第二用户3的账户信息的认可，发送针对代理支付认可请求的认可消息；以及响应于接收到针对代理支付的第一用户2的支付信息，向与第二用户3的账户相关联的金融交易服务器500发送用于请求从第二用户3的账户向第一用户2的账户汇款的账户转账信息。

本公开的某些方面也能够作为计算机可读代码被具体实现在非暂时性计算机可读记录介质上。非暂时性计算机可读记录介质是能够存储之后能够由计算机系统读取的数据的任何数据存储设备。非暂时性计算机可读记录介质的示例包括只读存储器(ROM)、随机存取存储器(RAM)、紧凑型光盘-ROM(CD-ROM)、磁带、软盘和光学数据存储设备。非暂时性计算机可读记录介质也能够分布在网络耦合的计算机系统上，使得计算机可读代码以分布式方式被存储和执行。此外，用于实现本公开的功能程序、代码和代码段能够容易地由本公开所属领域的程序设计员来构造。

在这一点上应当注意的是，如上所述的本公开的各种实施例在一定程度上通常涉及输入数据的处理和输出数据的生成。该输入数据处理和输出数据生成可以以硬件或与硬件结合的软件加以实现。例如，可以在移动设备或者类似或相关的电路中采用特定电子组件以便实现与如上所述的本公开的各种实施例相关联的功能。或者，依照所存储的指令而操作的一个或更多个处理器可以实现与如上所述的本公开的各种实施例相关联的功能。如果情况是这样的，则可以将此类指令存储在一个或更多个非暂时性处理器可读介质上是落在本公开的范围内的。处理器可读介质的示例包括ROM、RAM、CD-ROM、磁带、软盘和光学数据存储设备。处理器可读介质也能够分布在网络耦合的计算机系统上，使得指令以分布式方式被存储和执行。此外，用于实现本公开的功能计算机程序、指令和指令段能够容易地由本公开所属领域的程序设计员来构造。

虽然已经参考本公开的各种实施例示出并描述了本公开，但是本领域的技术人员应理解的是，在不脱离如由所附权利要求及其等同形式所限定的本公开的精神和范围的情况下，可以对本公开作出形式和细节上的各种改变。

Claims (15)

1.一种服务器的控制方法，所述方法包括如下步骤：

响应于从第一用户的终端设备接收到包括与代理支付相关联的预期付款额、所述第一用户的账户信息以及与一个或更多个第二用户相关联的信息的代理支付认可请求，向所述第二用户的终端设备发送询问是否认可所述代理支付认可请求的消息；

响应于从所述第二用户的终端设备接收到包括所述第二用户的账户信息的认可，发送针对所述代理支付认可请求的认可消息；以及

响应于接收到针对所述代理支付的所述第一用户的支付信息，向与所述第二用户的账户相关联的金融交易服务器发送用于请求从所述第二用户的账户向所述第一用户的账户汇款的账户转账信息。

2.根据权利要求1所述的方法，其中，所述代理支付认可请求进一步包括指示第一模式和第二模式中的一种的模式信息，其中，在所述第一模式下，所述第二用户支付所述预期付款额的总额，并且在所述第二模式下，所述第一用户和所述第二用户分担所述预期付款额。

3.根据权利要求2所述的方法，其中，所述的向所述第二用户的终端设备发送的步骤包括：

当所述模式信息是所述第一模式时，向所述第二用户的终端设备发送询问如下事项的消息：是否认可通过将所述预期付款额除以所述第二用户的总数而计算出的付款额；以及

当所述模式信息是所述第二模式时，向所述第二用户的终端设备发送询问如下事项的消息：是否认可通过将所述预期付款额除以所述第一用户和所述第二用户的总数而计算出的付款额。

4.根据权利要求3所述的方法，其中，所述的向金融交易服务器发送的步骤包括：响应于接收到所述支付信息，向与所述第二用户的账户相关联的金融交易服务器发送用于请求通过将所述预期付款额除以所述总数而计算出的付款额的汇款的账户转账信息。

5.根据权利要求1所述的方法，

其中，所述代理支付认可请求进一步包括与分担所述预期付款额的用户的数量相关联的信息，

其中，所述的向所述第二用户的终端设备发送的步骤包括：向所述第二用户的终端设备发送询问如下事项的消息：是否认可通过将所述预期付款额除以分担所述预期付款额的用户的数量而计算出的付款额，并且

其中，所述的向金融交易服务器发送的步骤包括：响应于接收到所述支付信息，向与所述第二用户的账户相关联的金融交易服务器发送用于请求通过将所述预期付款额除以分担所述预期付款额的用户的数量而计算出的付款额的汇款的账户转账信息。

6.根据权利要求5所述的方法，其中，分担所述预期付款额的用户除了包括所述第一用户和所述第二用户之外还包括不使用经由所述服务器的代理支付服务的用户。

7.根据权利要求1所述的方法，

其中，所述的向所述第二用户的终端设备发送的步骤包括：响应于从所述第一用户的终端设备接收到包括关于在所述第一用户与所述第二用户之间分担所述预期付款额的比例或关于所述预期付款额中的支付份额的份额信息的代理支付请求，向所述第二用户的终端设备发送询问如下事项的消息：是否认可通过根据所述份额信息来划分所述预期付款额而计算出的付款额，并且

其中，所述的向金融交易服务器发送的步骤包括：响应于接收到所述支付信息，向与所述第二用户的账户相关联的金融交易服务器发送用于请求通过根据所述份额信息来划分所述预期付款额而计算出的付款额的汇款的账户转账信息。

8.根据权利要求1所述的方法，

其中，所述的向所述第一用户的终端设备发送的步骤包括：响应于从多个第二用户当中的一些第二用户的终端设备接收到对所述代理支付认可请求的不认可并且从所述多个第二用户当中的其他用户的终端设备接收到认可，向所述第一用户的终端设备发送询问是否继续代理支付的消息，并且

其中，所述的向金融交易服务器发送的步骤包括：响应于接收到所述支付信息，向与所述多个第二用户当中的所述其他用户的账户中的每一个相关联的金融交易服务器，发送用于请求从所述其他用户的账户向所述第一用户的账户汇款的账户转账信息。

9.根据权利要求1所述的方法，

其中，所述的询问是否认可的消息包括与需要所述第二用户认可的支付金额相关联的信息，并且

其中，所述的向金融交易服务器发送的步骤包括：当所述预期付款额不同于所述支付信息中包括的已付金额时，向与所述第二用户的账户相关联的金融交易服务器发送用于请求所述需要所述第二用户认可的支付金额和所述已付金额中的较小者的汇款的账户转账信息。

10.根据权利要求1所述的方法，其中，所述的向金融交易服务器发送的步骤包括：当所述第一用户的终端设备通过与支付终端设备通信而进行支付时，从与所述第一用户的支付相关联的金融交易服务器接收所述支付信息。

11.一种服务器，包括：

通信器，所述通信器被配置为与用户的终端设备和所述用户的金融交易服务器进行通信；以及

至少一个处理器，所述至少一个处理器被配置为：

响应于从第一用户的终端设备接收到包括与代理支付相关联的预期付款额、所述第一用户的账户信息以及与一个或更多个第二用户相关联的信息的代理支付认可请求，控制所述通信器向所述第二用户的终端设备发送询问是否认可所述代理支付认可请求的消息；

响应于从所述第二用户的终端设备接收到包括所述第二用户的账户信息的认可，控制所述通信器发送针对所述代理支付认可请求的认可消息；以及

响应于接收到针对所述代理支付的所述第一用户的支付信息，控制所述通信器向与所述第二用户的账户相关联的金融交易服务器发送用于请求从所述第二用户的账户向所述第一用户的账户汇款的账户转账信息。

12.根据权利要求11所述的服务器，其中，所述代理支付认可请求进一步包括指示第一模式和第二模式中的一种的模式信息，其中，在所述第一模式下，所述第二用户支付所述预期付款额的总额，在所述第二模式下，所述第一用户和所述第二用户分担所述预期付款额。

13.根据权利要求12所述的服务器，其中，所述至少一个处理器被进一步配置为：

当所述模式信息是所述第一模式时，控制所述通信器向所述第二用户的终端设备发送询问如下事项的消息：是否认可通过将所述预期付款额除以所述第二用户的总数而计算出的付款额；以及

当所述模式信息是所述第二模式时，控制所述通信器向所述第二用户的终端设备发送询问如下事项的消息：是否认可通过将所述预期付款额除以所述第一用户和所述第二用户的总数而计算出的付款额。

14.根据权利要求13所述的服务器，其中，所述至少一个处理器被进一步配置为：响应于接收到所述支付信息，控制所述通信器向与所述第二用户的账户相关联的金融交易服务器发送用于请求通过将所述预期付款额除以所述总数而计算出的付款额的汇款的账户转账信息。

15.根据权利要求11所述的服务器，

其中，所述代理支付认可请求进一步包括与分担所述预期付款额的用户的数量相关联的信息，以及

其中，所述至少一个处理器被进一步配置为：

控制所述通信器向所述第二用户的终端设备发送询问如下事项的消息：是否认可通过将所述预期付款额除以分担所述预期付款额的用户的数量而计算出的付款额；并且

响应于接收到所述支付信息，控制所述通信器向与所述第二用户的账户相关联的金融交易服务器发送用于请求通过将所述预期付款额除以分担所述预期付款额的用户的数量而计算出的付款额的汇款的账户转账信息。