CN113935726A - 实现公共账户的方法、设备以及计算机可读介质 - Google Patents

Abstract

本申请实施例提供了一种实现公共账户的方法、设备以及计算机可读介质，该方案在创建公共账户后，可以将所述公共账户与多个共享用户的信用账户关联，然后从所述共享用户的信用账户转移信用额度至所述公共账户。由于公共账户采用的是信用额度的形式，且可以在创建后自动关联多个参与账户共享的共享用户的信用账户，不需要用户在消费前将实际资金转入公共账户中，且由于未实际的信用额度不会对用户的实际资金产生影响，因此用户可以通过设定较高的信用额度来应对计划外的消费，无需对公共账户的资金做准确的预算规划，减轻了用户的使用负担，提高了用户体验。

Description

实现公共账户的方法、设备以及计算机可读介质

技术领域

本申请涉及信息技术领域，尤其涉及一种消息处理方法、设备以及计算机可读介质。

背景技术

随着移动终端、移动互联网、无线互联网的迅速普及，移动支付已成为人们日常生活中广泛使用的支付方式。在移动支付系统中，用户都有一个属于自己的支付账户，用于支付自己的各类消费所产生的费用。但是，在实际场景中，由于每个人都具有社会属性，没有绝对独立的个体，每个人都会或多或少与社会有所交集，在生活工作中，很多时候需要共同支出费用。

目前对于此种情况的解决方式是设立一个公共账户，由各个用户将资金转入到该公共账户内，当需要共同支出费用时，由所述公共账户来支付。此种方式虽然可以解决共同支出的问题，但是需要参与的用户预先将实际的资金转入到公共账户内，因此用户需要对公共账户内的资金有一定的预算规划。而对于一些计划外的消费需求，很有可能会因为资金余额不足而无法快速完成支付，而需要由参与用户再次向公共账户转入资金后才可以完成，因此会导致整体的使用过程较为繁琐、用户体验不佳。

发明内容

本申请的目的之一是提供一种实现公共账户的方法、设备以及计算机可读介质。

为实现上述目的，本申请实施例提供了一种实现公共账户的方法，其中，所述方法包括：

创建公共账户，并将所述公共账户与多个共享用户的信用账户关联；

从所述共享用户的信用账户转移信用额度至所述公共账户，从各个信用账户转出的信用额度的总和等于所述公共账户转入的信用额度；

在收到来自所述共享用户的、基于公共账户的支付请求时，使用所述公共账户的信用额度处理所述支付请求，并按照记账比例确定各个信用账户的记账金额；

在生成账单时，统计各个信用账户的记账金额，确定相应的账单金额。

本申请的一些实施例还提供了一种消息处理设备，其中，该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行所述实现公共账户的方法。

此外，本申请的一些实施例还提供了一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现所述实现公共账户的方法。

本申请实施例提供的实现公共账户的方案中，首先创建公共账户，并将所述公共账户与多个共享用户的信用账户关联，然后从所述共享用户的信用账户转移信用额度至所述公共账户，其中，从各个信用账户转出的信用额度的总和等于所述公共账户转入的信用额度。在收到来自所述共享用户的、基于公共账户的支付请求时，使用所述公共账户的信用额度处理所述支付请求，并按照记账比例确定各个信用账户的记账金额；在生成账单时，统计各个信用账户的记账金额，确定相应的账单金额；在所述公共账户结算时，从所述公共账户将所述信用额度的剩余额度转移至共享用户的信用账户，从所述公共账户将所述信用额度的剩余额度等于各个信用账户转入的信用额度的总和。由于公共账户采用的是信用额度的形式，且可以在创建后自动关联多个参与账户共享的共享用户的信用账户，不需要用户在消费前将实际资金转入公共账户中，且由于未实际的信用额度不会对用户的实际资金产生影响，因此用户可以通过设定较高的信用额度来应对计划外的消费，无需对公共账户的资金做准确的预算规划，减轻了用户的使用负担，提高了用户体验。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为本申请实施例提供的一种实现公共账户的方法的处理流程图；

图2为本申请实施例中一种创建公共账户并添加共享用户时的交互流程图；

图3为本申请实施例中另一种创建公共账户并添加共享用户时的交互流程图；

图4为本申请实施例中由其它用户主动申请成为共享用户时的交互流程图；

图5为用户使用本申请实施例的方案所实现的公共账户时的使用流程图；

图6为本申请实施例的方案所实现的公共账户在产生账单过程中的记账流程图；

图7为本申请实施例中一种用于实现公共账户的设备的结构示意图；

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本申请一个典型的配置中，终端、服务网络的设备均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

本申请实施例提供了一种实现公共账户的方法，该方法在创建公共账户后，可以将所述公共账户与多个共享用户的信用账户关联，然后从所述共享用户的信用账户转移信用额度至所述公共账户。由于公共账户采用的是信用额度的形式，且可以在创建后自动关联多个参与账户共享的共享用户的信用账户，不需要用户在消费前将实际资金转入公共账户中，且由于未实际的信用额度不会对用户的实际资金产生影响，因此用户可以通过设定较高的信用额度来应对计划外的消费，无需对公共账户的资金做准确的预算规划，减轻了用户的使用负担，提高了用户体验。

所述方法的执行主体可以是网络设备，所述网络设备包括但不限于如网络主机、单个网络服务器、多个网络服务器集或基于云计算的计算机集合等实现。在此，云由基于云计算(Cloud Computing)的大量主机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟计算机。在实际场景中，所述网络设备的具体实现形式可以是支付平台等与用户绑定、且能够提供支付功能的系统，用户可以使用各自的用户设备并通过个人帐号登录该系统，然后可以使用该系统提供的支付功能完成支付。

图1示出了本申请实施例提供的一种实现公共账户的方法的处理流程，至少包括以下步骤：

步骤S101，创建公共账户，并将所述公共账户与多个共享用户的信用账户关联。其中，所述公共账户即为由多个用户共同使用的账户，使用该公共账户的用户可以定义为该公共账户的共享用户，例如，当支付平台的，服务器执行该方法时，若服务器创建了一个公共账户Account0，并将该公共账户与用户User1～5的信用账户Account1～5进行了关联，使得用户User1～5可以共同使用Account0，此时用户User1～5即为该公共账户的共享用户。

在本申请的一些实施例中，服务器可以获取来自任意一个用户的创建请求，根据所述公共账户创建请求创建公共账户，同时可以将发送所述创建请求的用户确定为共享用户。例如，当用户User1发送了创建请求，服务器收到该创建请求后，可以根据该创建请求创建公共账户Account0，并先该用户User1确定为其中的一个共享用户，同时可以将公共账户Account0与User1的信用账户关联。

而其他的共享用户，则可以在创建公共账户后，根据实际的需求采用预设的方式进行添加。在本实施例中，公共账户的创建者，如前述的用户User1，采用直接添加或者邀请的方式，来增加该公共账户的共享用户，或者其它的用户也可以主动要求成为该公共账户的共享用户。无论采用何种方式，相关的用户均可以向服务器发送成员添加请求，使得服务器能够获取成员添加请求，将所述成员添加请求所要添加的用户确定为共享用户，然后将所述公共账户与这些共享用户的信用账户关联。

以图2为例，其示出了一种创建公共账户并添加共享用户时的交互方式，包括如下的交互步骤：

步骤S201，用户User1使用手机等用户设备在支付平台的应用程序中点击创建公共账户，此时用户设备会向支付平台的服务器发送包括创建请求的消息，且该消息中也可以同时携带成员添加请求，成员添加请求中包含了用户User1想要添加至该公共账户中的其它用户的信息，如用户User2～5等。

步骤S202，服务器在收到创建请求后，根据所述公共账户创建请求创建公共账户Account0。

步骤S203，服务器将发送所述创建请求的用户User1确定为共享用户，同时根据成员添加请求将用户User2～5也确定为共享用户。

步骤S204，将公共账户Account0与共享用户User1～5的信用账户关联。

在实际场景中，服务器在根据成员添加请求将所述成员添加请求所要添加的用户确定为共享用户时，可以先向这些待添加的用户发送邀请信息，当这些受邀用户同意后，再将其确定为共享用户。由此，前述的交互方法可以采用如图3所示的交互流程，包括如下的处理步骤：

步骤S301，用户User1使用手机等用户设备在支付平台的应用程序中点击创建公共账户，此时用户设备会向支付平台的服务器发送包括创建请求和成员添加请求的消息。

步骤S302，服务器在收到创建请求后，根据所述公共账户创建请求创建公共账户Account0。

步骤S303，服务器将发送所述创建请求的用户User1确定为共享用户，并将公共账户Account0与用户User1的信用账户关联。

步骤S304，服务器根据成员添加请求将向用户User2～5发送成为共享用户的邀请信息。

步骤S305，用户User2～5通过手机等用户设备收到该邀请信息后，选择是否同意。若同意成为共享用户，则通过各自的用户设备返回同意信息给服务器。

步骤S306，服务器在收到同意信息后，将同意的用户确定为共享用户，并将这些共享用户的信用账户与公共账户Account0关联。

此外，图4示出了由其它用户主动申请成为共享用户时的交互流程，可以采用如下的处理步骤：

步骤S401，用户User1使用手机等用户设备在支付平台的应用程序中点击创建公共账户，此时用户设备会向支付平台的服务器发送包括创建请求的消息。

步骤S402，服务器在收到创建请求后，根据所述公共账户创建请求创建公共账户Account0。

步骤S403，服务器将发送所述创建请求的用户User1确定为共享用户，并将公共账户Account0与用户User1的信用账户关联。

步骤S404，用户User2使用手机等用户设备向服务器发送成员添加请求，申请成为公共账户Account0的共享用户。

步骤S405，服务器在收到成员添加请求后，用户User2确定为共享用户，并将公共账户Account0与用户User2的信用账户关联。在实际场景中，为了确保安全性，服务器在为公共账户添加新的共享用户时，可以向公共账户的创建者或者管理员用户发送确认消息，由创建者或者管理员用户来确认是否同一该用户成为新的共享用户。或者，也可以安全认证的机制前置，使得其它的用户仅可以通过创建者或者管理员用户提供的特定信息，才可以向服务器发送成员添加请求，如用户User2是通过扫描创建者User1提供的二维码的方式向服务器发送成员添加请求。

在实际场景中，为了便于公共账户的统一管理，可以为公共账户设定管理员用户。所述管理员用户可以对公共账户实现特定的管理功能，例如添加、移除共享用户等、设置公共账户的信用额度、名称、查看二维码、注销、锁定公共账户等。在本申请的一些实施例中，可以将发送所述创建请求的用户设定为所述公共账户的管理员用户，即将创建者设置为默认的管理员用户。而在此基础上，创建者也可以进一步添加其它的共享用户成为管理员用户，不同管理员用户的权限可以根据实际场景的需求设定，例如创建者对应的管理员用户可以具有最高的权限，而创建者所添加的管理员用户的权限可以由创建者设定，以便于协助创建者对公共账户进行管理。

此外，所述公共账户下的共享用户之间，可以采用类似群组的组织形式，即共享用户之间组成一个用户群，类似于即时通信场景中的聊天群，公共账户的创建者即为该用户群的群主，可以添加其它普通的共享用户为用户群的群管理员。

步骤S102，从所述共享用户的信用账户转移信用额度至所述公共账户。其中，从各个信用账户转出的信用额度的总和等于所述公共账户转入的信用额度，例如对于前述的公共账户Account0以及与其关联的信用账户Account1～5而言，若每个信用账户均转出500元的信用额度，则公共账户转入的信用额度为2500元。

在转移信用额度时，服务器可以获取来自各个共享用户的额度转移信息，所述额度转移信息包括从各个信用账户转出的信用额度的数额，例如共享用户User2的额度转移信息中包括了从共享用户User2的信用账户Account2中转出500元的信用额度。服务器在收到所有共享用户的额度转移信息之后，即可根据所述额度转移信息，从所述共享用户的信用账户转移相应数额的信用额度至所述公共账户，从而完成公共账户的信用额度的设置。

在实际场景中，公共账户的信用额度可以由各个共享用户共同决定，即每个共享用户根据自身的实际情况主动给出的相应的额度转移信息，从而相加后确定公共账户的信用额度的具体数额。此外，公共账户的信用额度也可以由创建者决定，然后由创建者分配每个共享用户需要转入的信用额度，或者是由包括创建者在内的所有共享用户通过协商的方式分配每个共享用户需要转入的信用额度。无论采用何种方式确定需要转入的信用额度后，各个共享用户再通过发送额度转移信息，使得服务器可以以此完成共享用户的信用账户的设置。

步骤S103，在收到来自所述共享用户的、基于公共账户的支付请求时，使用所述公共账户的信用额度处理所述支付请求，并按照记账比例确定各个信用账户的记账金额。

当公共账户具有一定的信用额度之后，共享用户即可在消费时使用该公共账户完成支付。在共享用户使用公共账户进行消费时，服务器会收到来自所述共享用户的、基于公共账户的支付请求，此时使用所述公共账户的信用额度处理所述支付请求，并按照记账比例确定各个信用账户的记账金额。以公共账户Account10，当支付请求需要付款500元时，则所述公共账户需要使用其中的500元的信用额度来完成该支付请求的处理，若该公共账户Account10所关联的信用账户为Account11和Account12的记账比例为1：4，则两个信用账户的记账金额分别为100元和400元。

在本申请的一些实施例中，可以根据各个共享用户的额度转移信息之间的比例，确定处理支付请求时的记账比例。例如，以前述的公共账户Account10为例，其对应的共享用户分别为小明和小红，关联的信用账户为Account11和Account12，若小明和小红在通过各自的信用账户向公共账户转入信用额度时，分别转入了1000元和4000元，则可以根据额度转移信息的比例，确定处理支付请求时的记账比例为1：4。此外，也可以根据所述公共账户的管理员用户设定的比例，确定处理支付请求时的记账比例。在此种情况下，管理员用户设定的比例将优先于转移额度信息之间的比例，若公共账户Account10的管理员用户小明设定了记账比例为1：1，则可以以此确定处理支付请求时的记账比例为1：1。

由于本申请的方案是采用信用支付的方式处理支付请求，为了避免产生资金风险，可以对每个公共账户关联的各个信用账户的记账金额总和进行限制，以避免某一共享用户产生过多的消费。由此，服务器可以对公共账户所关联的各个信用账户的记账金额进行统计，若在一次支付请求的处理过程中，发现任一信用账户的记账金额总和超过所述信用账户转入所述公共账户的信用额度，终止对本次支付请求的处理。例如，小明的信用账户Account11转入公共账户Account10的信用额度为1000元，在之前的消费中，已经陆续产生了950元的记账金额，若处理本次支付请求会产生100元的记账金额，则会导致其记账金额总和1050元超过所述信用账户转入所述公共账户的信用额度1000元，此时服务器会对本次支付请求的处理，同时可以发送信用提示信息，使得用户所使用的用户设备可以显示该提示信息，如“账户信用额度不足，交易失败”。

在实际场景中，判断任一信用账户的记账金额总和超过所述信用账户转入所述公共账户的信用额度时，可以在每一次产生记账金额时，先计算各个信用账户在公共账户中的余额，例如小明的信用账户Account11转入公共账户Account10的信用额度为1000元，在处理完一次支付请求后，产生了200元的记账金额，则此时该信用账户Account11在公共账户Account10中的余额为800元。在手续收到新的处理请求时，将该余额和预计产生的记账金额进行比对即可，若记账金额未超过余额，则表示记账金额总和未超过所述信用账户转入所述公共账户的信用额度，反之，则表示记账金额总和超过所述信用账户转入所述公共账户的信用额度。

步骤S104，在生成账单时，统计各个信用账户的记账金额，确定相应的账单金额。由于本申请的方案中采用的是信用账户的形式，因此会在每个记账周期结束时生成当期的账单，由于在每次处理完支付请求时，会按照记账比例确定各个信用账户的记账金额，因此通过统计记账周期内各个信用账户的记账金额，即可确定相应的账单金额。

由此，各个共享用户基于各自的账单金额进行还款即可。在实际还款时，用户可以基于各自的账单金额直接通过公共账户进行还款，也可以将账单金额计入各自的信用账户后，通过信用账户进行还款。

在本申请的一些实施例中，共享用户也可以在需要时将转入公共账户的信用额度转出至各自的信用账户，服务器可以根据用户发送的转出请求，从所述公共账户将信用额度转移至共享用户的信用账户。在从公共账户转出信用额度时，需要确保从所述公共账户转出至目标信用账户的信用额度的数额不大于所述目标信用账户在公共账户中的转入余额，且从所述公共账户转出所述信用额度等于各个信用账户转入的信用额度的总和。

以前述的公共账户Account10为例，若当前两个关联的信用账户Account11和Account12在该公共账户中的转入余额分别为100元和200元，其中，所述转入余额为信用账户转入公共账户的信用额度与所述信用账户的当前记账金额之间的差值，例如，信用账户Account11转入公共账户的信用额度为500元，若此时该信用账户已经产生了400元的记账金额，则可以计算出其当前的转入余额为100元，同理可以确定Account12的转入余额。在从所述公共账户Account10将信用额度转移至共享用户小明的信用账户Account11时，由于信用账户Account11的转入余额为100元，因此公共账户Account10转出至信用账户Account11的信用额度最多为100元。

信用额度在公共账户与信用账户之间发生转移时，可以采用以下的方式实现。其中一种方案中，在从所述共享用户的信用账户转移信用额度至所述公共账户时，可以减少所述共享用户的信用账户的信用额度，并相应增加所述公共账户的信用额度。例如，在用户的请求下，服务器修改对各个账户授权的信用额度，其中，对信用账户Account11授权的信用额度-400，对信用账户Account12授权的信用额度-500，同时对公共账户Account10授权的信用额度+900。而在从所述公共账户将信用额度转移至共享用户的信用账户时，可以减少所述公共账户的信用额度，并相应增加共享用户的信用账户的信用额度，其处理过程转入的过程类似，确保转移的信用额度不超出各个信用账户的转入余额即可。

而在另一种方案中，在从所述共享用户的信用账户转移信用额度至所述公共账户时，可以冻结所述共享用户的信用账户的信用额度，并相应增加所述公共账户的信用额度。相较于前一种方案，此种方案的区别在于不对信用账户的信用额度进行直接的调整，而是对其进行冻结，例如可以采用了类似预授权的方式，例如在用户的请求下，服务器修改对各个账户授权的信用额度，其中，冻结信用账户Account11中数额为400的信用额度，以及信用账户Account12中数额为500的信用额度，同时对公共账户Account10授权的信用额度+900，而不实际调整信用账户的信用额度。

而在从所述公共账户将信用额度转移至共享用户的信用账户时，减少所述公共账户的信用额度，并相应恢复共享用户的信用账户中已冻结的信用额度，其处理过程转入的过程类似，确保转移的信用额度不超出各个信用账户的转入余额即可。

图5示出了用户使用本申请实施例的方案所实现的公共账户时的使用流程，可以包括以下的步骤：

步骤S501，用户小明启动具有公共账户功能的应用程序。

步骤S502，用户小明在应用程序中点击创建公共账户，并建立共享用户群，小明成为群主。

步骤S503，用户小明添加群成员成为该公共账户的共享用户。在本实施例中，小明添加用户小红成为群成员，最多可添加9位群成员。

步骤S504，群主和群成员可以将自己的信用账户中的部分信用额度转入公共账户。如本实施例中，小明转入公共账户的信用额度为500元，小红转入公共账户的信用额度为400元，公共账户当前拥有的信用额度则为900元。

步骤S505，群成员在消费时可以选择使用公共账户进行支付，且群成员可以随时向公共账户转入或从公共账户转出信用额度，在转出时不能超过该群成员的转入余额。

步骤S506，每月末根据公共账户支付情况，将各个群成员账单金额计入各自的信用账户，群成员通过各自的信用账户进行还款。

图6示出了本申请实施例的方案所实现的公共账户在产生账单过程中的记账流程，可以包括以下的步骤：

步骤S601，群主或群管理员设置产生消费时的记账比例，如群主小明可以将消费时的小明和小红之间的记账比例设定为2：1。

步骤S602，群成员使用公共账户支付一笔消费。

步骤S603，将该笔消费的金额照记账比例产生记账金额。例如，当一次消费需要支付30元时，由于记账比例为2：1，则小明产生20元的记账金额，小红产生10元的记账金额。

步骤S604，当一笔消费的金额按照记账比例分配后，大于某一位群成员的转入余额时，则显示XX余额不足，无法使用。例如一笔消费金额为400元，小明在公共账户中转入余额为210元，而小红在公共账户中的转入余额为90元，按照记账比例，小明的记账金额200元＜转入余额210元，但是小红的记账金额100元＞转入余额90元，则公共账户在支付该笔消费时，显示小红余额不足，无法使用。

步骤S605，群主或群管理员可以随时调整支付时的记账比例，新调整的记账比例仅对之后的消费生效。

基于同一发明构思，本申请实施例中还提供了一种实现公共账户的设备，以实现前述的实现公共账户的方法，并且其解决问题的原理与该方法相似。该实现公共账户的设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行前述的实现公共账户的方法。

图7示出了适用于实现本申请实施例中的方法和/或技术方案的一种设备的结构，该设备700包括中央处理单元(CPU，Central Processing Unit)701，其可以根据存储在只读存储器(ROM，Read Only Memory)702中的程序或者从存储部分708加载到随机访问存储器(RAM，Random Access Memory)703中的程序而执行各种适当的动作和处理。在RAM 703中，还存储有系统操作所需的各种程序和数据。CPU 701、ROM 702以及RAM703通过总线704彼此相连。输入/输出(I/O，Input/Output)接口705也连接至总线704。

以下部件连接至I/O接口705：包括键盘、鼠标、触摸屏、麦克风、红外传感器等的输入部分706；包括诸如阴极射线管(CRT，Cathode Ray Tube)、液晶显示器(LCD，LiquidCrystal Display)、LED显示器、OLED显示器等以及扬声器等的输出部分707；包括硬盘、光盘、磁盘、半导体存储器等一个或多个计算机可读介质的存储部分708；以及包括诸如LAN(局域网，Local Area Network)卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。

特别地，本申请实施例中的方法和/或实施例可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在该计算机程序被中央处理单元(CPU)701执行时，执行本申请的方法中限定的上述功能。

需要说明的是，本申请所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图或框图示出了按照本申请各种实施例的设备、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的针对硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个计算机可读指令，所述计算机可读指令可被处理器执行以实现前述本申请的多个实施例的方法和/或技术方案。

综上所述，本申请实施例提供的一种实现公共账户的方案中，在创建公共账户后，可以将所述公共账户与多个共享用户的信用账户关联，然后从所述共享用户的信用账户转移信用额度至所述公共账户。由于公共账户采用的是信用额度的形式，且可以在创建后自动关联多个参与账户共享的共享用户的信用账户，不需要用户在消费前将实际资金转入公共账户中，且由于未实际的信用额度不会对用户的实际资金产生影响，因此用户可以通过设定较高的信用额度来应对计划外的消费，无需对公共账户的资金做准确的预算规划，减轻了用户的使用负担，提高了用户体验。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一些实施例中，本申请的软件程序可以通过处理器执行以实现上文步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (10)

1.一种实现公共账户的方法，其中，所述方法包括：

创建公共账户，并将所述公共账户与多个共享用户的信用账户关联；

从所述共享用户的信用账户转移信用额度至所述公共账户，从各个信用账户转出的信用额度的总和等于所述公共账户转入的信用额度；

在收到来自所述共享用户的、基于公共账户的支付请求时，使用所述公共账户的信用额度处理所述支付请求，并按照记账比例确定各个信用账户的记账金额；

在生成账单时，统计各个信用账户的记账金额，确定相应的账单金额。

2.根据权利要求1所述的方法，其中，创建公共账户，并将所述公共账户与多个共享用户的信用账户关联，包括：

获取创建请求，根据所述公共账户创建请求创建公共账户，并将发送所述创建请求的用户确定为共享用户；

获取成员添加请求，将所述成员添加请求所要添加的用户确定为共享用户；

将所述公共账户与所述共享用户的信用账户关联。

3.根据权利要求1所述的方法，其中，从所述共享用户的信用账户转移信用额度至所述公共账户，从各个信用账户转出的信用额度的总和等于所述公共账户转入的信用额度，包括：

获取来自各个共享用户的额度转移信息，所述额度转移信息包括从各个信用账户转出的信用额度的数额；

根据所述额度转移信息，从所述共享用户的信用账户转移相应数额的信用额度至所述公共账户，从各个信用账户转出的信用额度的总和等于所述公共账户转入的信用额度。

4.根据权利要求3所述的方法，其中，所述方法还包括：

根据各个共享用户的额度转移信息之间的比例，确定处理支付请求时的记账比例；或根据所述公共账户的管理员用户设定的比例，确定处理支付请求时的记账比例。

5.根据权利要求1所述的方法，其中，在使用所述公共账户的信用额度处理所述支付请求时，还包括：

若任一信用账户的记账金额总和超过所述信用账户转入所述公共账户的信用额度，终止对本次支付请求的处理。

6.根据权利要求1所述的方法，其中，所述方法还包括：

从所述公共账户将信用额度转移至共享用户的信用账户，其中，从所述公共账户转出至目标信用账户的信用额度的数额不大于所述目标信用账户在公共账户中的转入余额，所述转入余额为信用账户转入公共账户的信用额度与所述信用账户的当前记账金额之间的差值，从所述公共账户转出所述信用额度等于各个信用账户转入的信用额度的总和。

7.根据权利要求6所述的方法，其中，从所述共享用户的信用账户转移信用额度至所述公共账户，包括：

减少所述共享用户的信用账户的信用额度，并相应增加所述公共账户的信用额度；

从所述公共账户将信用额度转移至共享用户的信用账户，包括：

减少所述公共账户的信用额度，并相应增加共享用户的信用账户的信用额度。

8.根据权利要求1所述的方法，其中，从所述共享用户的信用账户转移信用额度至所述公共账户，包括：

冻结所述共享用户的信用账户的信用额度，并相应增加所述公共账户的信用额度；

从所述公共账户将信用额度转移至共享用户的信用账户，包括：

减少所述公共账户的信用额度，并相应恢复共享用户的信用账户中已冻结的信用额度。

9.一种实现公共账户的设备，其中，该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行权利要求1至8中任一项所述的方法。

10.一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现如权利要求1至8中任一项所述的方法。

Images