资源调配方法和装置以及电子支付方法与流程

本申请涉及计算机技术领域，尤其涉及资源调配方法和装置，以及电子支付方法。

背景技术：

随着互联网技术的发展和智能终端设备的普及，人们的生活越来越便利，资源调配也越来越普遍。在现有的资源调配方式中，资源调配的双方往往需要获取对方的部分隐私信息才能实现资源的调配，从而对资源调配双方的隐私信息安全性构成潜在威胁。

以资源具体化为资金，资源的调配具体化为资金的转账为例，移动支付这种实现资金转账的方式已广泛应用。现有的移动支付方式可以采用收款方(转账过程中的资金转入方)扫描付款二维码或者付款方(转账过程中的资金转出方)扫描收款二维码的方式进行。相比于传统的银行转账方式而言，采用现有的移动支付方式进行转账时，无需将自己的银行账户信息告知对方，对收款方和付款方均能起到一定的信息屏蔽作用，在一定程度上保护了转账双方的个人隐私。

然而，现有的移动支付方式仍然会将收款方和付款方在支付平台上的注册信息告知对方，可能包括会员账号、真实姓名、头像照片、手机号码等，对转账双方而言，仍然存在隐私泄露的风险。在诸如陌生人之间、偶发性交易的场景下，隐私泄露的风险进一步增大。

技术实现要素：

本申请实施例提供了资源调配方法和装置，旨在保护资源调配双方的隐私信息，确保资源调配的信息安全。

本申请实施例提供了电子支付方法，旨在保护电子支付双方的隐私信息，确保资金转账的信息安全。

本申请实施例采用下述技术方案：

本申请实施例提供的一种资源调配方法，包括：

接收第一客户端发出的访问服务器端的第一请求；其中，所述第一请求中携带有令牌信息，所述令牌信息与第二客户端的资源信息具有对应关系；

依据所述第一请求中携带的所述令牌信息，确定与所述令牌信息相对应的所述第二客户端的所述资源信息；

接收所述第一客户端输入的资源调配信息，并依据所述第一客户端输入的所述资源调配信息以及第二客户端的所述资源信息完成资源的调配。

本申请实施例提供的第二种资源调配方法，包括：

第一客户端向服务器端发出访问所述服务器端的第一请求，以便所述服务器端依据所述第一请求中携带的所述令牌信息，确定与所述令牌信息相对应的所述第二客户端的所述资源信息；其中，所述第一请求中携带有令牌信息，所述令牌信息与第二客户端的资源信息具有对应关系；

输入资源调配信息，并将所述资源调配信息发送到所述服务器端，供所述服务器端依据所述第一客户端输入的所述资源调配信息以及第二客户端的所述资源信息完成资源的调配。

本申请实施例提供的一种资源调配装置，包括：

请求接收模块，接收第一客户端发出的访问服务器端的第一请求；其中，所述第一请求中携带有令牌信息，所述令牌信息与第二客户端的资源信息具有对应关系；

资源信息确定模块，依据所述第一请求中携带的所述令牌信息，确定与所述令牌信息相对应的所述第二客户端的所述资源信息；

信息接收模块，接收所述第一客户端输入的资源调配信息；

资源调配模块，依据所述第一客户端输入的所述资源调配信息以及第二客户端的所述资源信息完成资源的调配。

本申请提供的一种电子支付方法，包括：

接收付款端发出的访问服务器端的第一请求；其中，所述第一请求中携带有令牌信息，所述令牌信息与收款端的收款信息具有对应关系；

依据所述第一请求中携带的所述令牌信息，确定与所述令牌信息相对应的所述收款端的所述收款信息；

接收所述付款端输入的付款信息，并依据所述付款端输入的所述付款信息以及收款端的所述收款信息完成所述付款端向所述收款端的电子支付。

优选地，本申请提供的电子支付方法中，所述付款端发出的访问服务器端的所述第一请求，是由所述付款端扫描所述收款端的标识码信息后发出的。

优选地，本申请提供的电子支付方法中，所述第一请求具体为与所述标识码信息一一对应的、用于访问所述服务器端的统一资源定位符；所述统一资源定位符中携带有用于确定所述收款端的所述收款信息的令牌信息。

优选地，本申请提供的电子支付方法中，所述令牌信息与收款端的收款信息的对应关系的建立，具体包括：

生成与所述收款端相对应的携带有所述令牌信息的统一资源定位符，确定所述令牌信息与所述收款端的收款信息的对应关系。

优选地，本申请提供的电子支付方法中，生成与所述收款端相对应的携带有所述令牌信息的统一资源定位符，确定所述令牌信息与所述收款端的收款信息的对应关系，具体包括：

获取所述收款端的所述收款信息；

当对所述收款信息验证通过时，建立所述收款信息与所述令牌信息的第一对应关系，并生成携带有所述令牌信息的所述统一资源定位符和相对应的标识码信息；

保存所述收款信息与所述令牌信息的所述第一对应关系以及所述令牌信息与所述统一资源定位符的第二对应关系，并将所述标识码信息发送到所述收款端。

优选地，本申请提供的电子支付方法中，依据所述第一请求中携带的所述令牌信息，确定与所述令牌信息相对应的所述收款端的所述收款信息，具体包括：

提取所述第一请求对应的所述统一资源标识符中携带的所述令牌信息；

依据所述令牌信息，在所述服务器端确定与所述令牌信息建立有所述第一对应关系的收款端的收款信息。

优选地，本申请提供的电子支付方法中，所述标识码信息为条形码和/或二维码。

优选地，本申请提供的电子支付方法中，所述付款端输入的所述付款信息，具体包括所述付款端的付款账号信息和电子支付金额信息；所述收款端的所述收款信息，具体包括所述收款端的身份信息和收款账号信息。

优选地，本申请提供的电子支付方法中，所述付款账号信息包括所述付款端的银行账号信息和/或所述付款端在所述服务器端的用户注册账号信息；所述收款账号信息包括所述收款端的银行账号信息和/或所述收款端在所述服务器端的用户注册账号信息。

优选地，本申请提供的电子支付方法中，所述服务器端包括平台服务器端和至少一个金融服务器端，所述方法具体包括：

所述平台服务器端接收所述付款端发出的访问所述平台服务器端的第一请求；其中，所述第一请求中携带有令牌信息，所述令牌信息与收款端的收款信息具有对应关系；

所述平台服务器端依据所述第一请求中携带的所述令牌信息，确定与所述令牌信息相对应的收款端的所述收款信息；

所述平台服务器端接收所述付款端输入的所述付款信息；

所述金融服务器端依据所述付款端输入的所述付款信息以及收款端的所述收款信息完成所述付款端向所述收款端的电子支付。

优选地，本申请提供的电子支付方法中，在所述平台服务器端接收所述付款端输入的所述付款信息之后，在所述金融服务器端依据所述付款端输入的所述付款信息以及收款端的所述收款信息完成所述付款端向所述收款端的电子支付之前，还包括：

所述平台服务器端依据所述付款端的付款账号信息，确定与所述付款账号信息相匹配的金融服务器端；

所述平台服务器端向与所述付款账号信息相匹配的金融服务器端发送支付指令，供与所述付款账号信息相匹配的金融服务器端完成所述付款端向所述收款端的电子支付。

优选地，本申请提供的电子支付方法中，所述平台服务器端向与所述付款账号信息相匹配的金融服务器端发送的支付指令中，具体包括所述收款端的收款账号信息和所述付款端的所述付款账号信息。

本申请还提供第二种电子支付方法，包括：

接收收款端发出的访问服务器端的第一请求；其中，所述第一请求中携带有令牌信息，所述令牌信息与付款端的付款信息相对应；

依据所述第一请求中携带的所述令牌信息，确定与所述令牌信息相对应的付款端的付款信息；

接收所述收款端输入的收款信息，并依据所述收款端输入的所述收款信息以及所述付款端的所述付款信息完成所述付款端向所述收款端的电子支付。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

本申请实施例中，第一客户端向服务器端发出访问服务器端的第一请求。该第一请求中不携带第二客户端的资源信息，而是携带与第二客户端的资源信息具有对应关系的令牌信息。服务器端接收到携带有令牌信息的第一请求后，能够通过识别第一请求中的令牌信息，确定与令牌信息相对应的第二客户端的资源信息，从而服务器端能够知晓第一客户端希望与哪一个第二客户端进行资源的调配。采用本申请实施例，由于第一客户端不对第二客户端的资源信息进行识别，且无论是第一客户端的资源调配信息，还是第二客户端的资源信息，均在服务器端中进行处理，第一客户端和第二客户端在无需知道对方隐私信息的情况下即可完成资源调配，因此，更有效、更全面地保护了第一客户端和第二客户端的隐私信息，达到了本申请的技术目的。

在进行资源调配时的资源调配双方(即第一客户端和第二客户端)，可以具体化为进行电子支付的收款端和付款端，从而完成付款端向收款端的电子支付，从而本申请实施例适用于资金转账、电子支付等应用场景。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1-1为本申请实施例的一种资源调配方法的流程示意图；

图1-2为本申请实施例的第二种资源调配方法的流程示意图；

图1-3为本申请实施例的第三种资源调配方法的流程示意图；

图1-4为本申请实施例的第四种资源调配方法的流程示意图；

图1-5为本申请实施例的第五种资源调配方法的应用场景示意图；

图1-6为本申请实施例的第六种资源调配方法的流程示意图；

图1-7为本申请实施例的第七种资源调配方法的流程示意图；

图2为本申请实施例的第八种资源调配方法的流程示意图；

图3-1为本申请实施例的资源调配方法中的一种界面示意图；

图3-2为本申请实施例的资源调配方法中的第二种界面示意图；

图3-3为本申请实施例的资源调配方法中的第三种界面示意图；

图4为本申请实施例的一种资源调配装置的结构示意图；

图5为本申请实施例的电子支付方法的流程示意图。

具体实施方式

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

以下结合附图，详细说明本申请各实施例提供的技术方案。

实施例1

参见图1，该图示出了本申请实施例提供的资源调配方法。该方法可以适用于服务器端，包括：

s101：接收第一客户端发出的访问服务器端的第一请求；其中，第一请求中携带有令牌信息，令牌信息与第二客户端的资源信息具有对应关系；

s102：依据第一请求中携带的令牌信息，确定与令牌信息相对应的第二客户端的资源信息；

s103：接收第一客户端输入的资源调配信息；

s104：依据第一客户端输入的资源调配信息以及第二客户端的资源信息完成资源的调配。

优选地，上述第一客户端发出的访问服务器端的第一请求，可以由第一客户端扫描第二客户端的标识码信息(与第二客户端的统一资源定位符相对应)后发出。在本申请的实施例中，第一客户端在扫描第二客户端的标识码信息后，向服务器端发出访问服务器端的第一请求。该第一请求中携带有能够让服务器端确定第二客户端的资源信息的令牌信息，而不携带第二客户端的资源信息。服务器执行步骤s101接收到第一请求后，执行步骤s102，通过第一请求中携带的令牌信息确定与令牌信息相对应的第二客户端的资源信息，从而服务器端能够知晓第一客户端希望与哪一个第二客户端进行资源的调配。进一步地，服务器端通过执行步骤s103接收到第一客户端输入的资源调配信息后，就能够执行步骤s104完成资源的调配了。

采用上述实施例，第一客户端通过第二客户端的标识码信息不会识别出第二客户端的资源信息，且无论是第一客户端的资源调配信息，还是第二客户端的资源信息，均在服务器端中进行处理，第一客户端和第二客户端均无需知道对方的隐私信息即可完成资源的调配，因此，能够更有效、更全面地保护第一客户端和第二客户端的隐私信息，达到本申请的技术目的。

以下将从多个角度详细说明本申请实施例的具体实施。

在服务器端执行步骤s101接收到第一请求前，第一客户端可以扫描第二客户端的标识码信息，这一标识码信息可能是第二客户端公开发布的，也可能是向第一客户端定向展示的。这一标识码信息可以由服务器根据已有的第二客户端的资源信息映射得到，也可以应第二客户端的申请，由服务器端依据第二客户端提交的资源信息确定得到，参见图1-2所示。具体地，服务器端可执行步骤s100，生成与收款端相对应的携带有令牌信息的统一资源定位符，进而建立令牌信息与第二客户端的资源信息的对应关系。可以具体包括以下步骤，参见图1-3所示：

s1001：获取第二客户端的资源信息；

s1002：服务器端对第二客户端的资源信息进行验证，判断第二客户端的资源信息是否验证通过：若验证不通过，则执行步骤s1003，向第二客户端反馈验证不通过的结果；若验证通过，则执行步骤s1004～步骤s1006；

s1004：当对资源信息验证通过时，建立资源信息与令牌信息的第一对应关系，并生成携带有令牌信息的统一资源定位符和相对应的标识码信息；

s1005：保存资源信息与令牌信息的第一对应关系以及令牌信息与统一资源定位符的第二对应关系；

s1006：将标识码信息发送到第二客户端。

在执行步骤s1001时，可以采用多种方式获取第二客户端的资源信息：可以是服务器端从数据库中读取，也可以由第二客户端提交至服务器端。在执行步骤s1002对第二客户端的资源信息进行验证时，依据第二客户端提交到服务器端的资源信息的不同，对资源信息的验证内容和验证流程也可有所不同。例如，若第二客户端提交的资源信息包括第二客户端用户的姓名和银行账号，则服务器端可以验证姓名、银行账号、开户行信息等相关信息的一致性与对应性。具体地，若服务器端可以直接对这些信息进行验证验证(例如服务器端中包含银行系统服务器或已存储有银行系统的账号信息等)，则服务器端可以直接给出验证结果；若服务器端无法直接对这些信息进行验证验证，则需要将这些信息发送到有权机构(例如央行系统等)进行验证验证，根据反馈得到的验证结果确定验证是否通过。又例如，若第二客户端提交的资源信息包括第二客户端用户在平台服务器端的会员注册信息，如注册的会员账号、账号密码等，则服务器端可以验证第二客户端用户在该平台服务器端的会员资格，依据验证的结果确定验证是否通过。再例如，若第二客户端提交的资源信息包括申请开展的业务和相关的资质证明(例如工商营业执照，食品卫生许可证等)，则服务器端可以验证第二客户端的主体资格与资质证明的对应性。第二客户端提交的资源信息还可能会包含第二客户端用户申请的标识码信息所对应的业务类型，该业务类型信息可能表示第二客户端用户将在资源调配过程中充当资源转出方还是资源转入方，也可能表示第二客户端用户所从事的行业类型，例如餐饮行业，服装行业等。总之，本实施例对于第二客户端采用何种形式提交资源信息、提交哪些资源信息等方面不做具体限定，对服务器端采用何种流程和手段验证资源信息、验证哪些资源信息、以及依据验证的结果如何确定验证是否通过等方面的具体实现也不做限定，只要执行步骤s104时，服务器端保存的与第二客户端相对应的资源信息能够满足对资源进行调配的要求即可。

当对资源信息验证通过时，服务器端执行步骤s1004～s1006，建立资源信息与令牌信息的第一对应关系，并生成携带有令牌信息的统一资源定位符和相对应的标识码信息，进而将标识码信息发送到第二客户端，可供第二客户端向第一客户端展示。在本申请的各实施例中，标识码信息可以采用条形码或二维码，也可以采用二者的结合，优选采用信息量大、易识别、容错性强、成本低廉、持久耐用的二维码。当第一客户端需要与第二客户端进行资源调配的时候，通过扫描标识码信息的方式即可识别出与标识码信息相对应的统一资源定位符，从而发出访问服务器端的第一请求，即访问统一资源定位符所对应的地址的请求。

上述实施例中所称的统一资源定位符(uniformresourcelocator，简称url)，是对可以从互联网上得到的文件的位置和访问方法的一种简洁的表示，是互联网上标准文件的访问地址。互联网上的每个文件都有一个唯一的url，它包含的信息通常能够指出文件的位置以及应该怎么处理。在本实施例中，服务器端执行步骤s1004建立资源信息与令牌信息的第一对应关系，并建立令牌信息与统一资源定位符的第二对应关系，从而通过令牌信息的桥梁作用，将第二客户端的资源信息映射为url，在建立对应关系时，在url中加入与第二客户端的资源信息的令牌信息相对应的令牌信息。因此，服务器端在接收到第一客户端发送来的携带有令牌信息的第一请求(即与标识码信息一一对应的、用于访问服务器端的统一资源定位符url)后，执行步骤s102确定与令牌信息相对应的第二客户端的资源信息时，可以通过url中携带的令牌信息确定该url所对应的第二客户端及其资源信息，从而使得服务器知晓第一客户端希望与哪一个第二客户端进行资源的调配，并可以调取第二客户端的资源信息进行资源的调配。进一步地，在上述url中不携带第二客户端的资源信息，因此，第一客户端扫描与url相对应的标识码信息后，不会识别出第二客户端的姓名、银行账号、会员账号等资源信息，从而第二客户端的隐私信息在第一客户端扫描标识码信息时得以保护。

在建立令牌信息与第二客户端的资源信息的对应关系时，除以上方式外，还可以在服务器端先生成携带有令牌信息的统一资源定位符，然后在接收到第二客户端的资源信息后，确定令牌信息与第二客户端的资源信息的对应关系。同样能够建立令牌信息与资源信息的对应关系。

更具体地，服务器端执行步骤s102依据第一请求中携带的令牌信息，确定与令牌信息相对应的第二客户端的资源信息时，参见图1-4所示，可具体包括：

s1021：提取第一请求对应的统一资源标识符中携带的令牌信息；

s1022：依据令牌信息，在服务器端确定与令牌信息建立有第一对应关系的第二客户端的资源信息。

在本实施例中，可以将统一资源标识符中携带的令牌信息理解为统一资源标识符与第二客户端的资源信息之间的桥梁，一方面，统一资源标识符与第二客户端的资源信息并不直接关联，从而第一客户端无法通过统一资源标识符获取到第二客户端的资源信息；另一方面，由于服务器端保存有资源信息与令牌信息的第一对应关系以及令牌信息与统一资源定位符的第二对应关系，因此，服务器端能够通过统一资源定位符中携带的令牌信息，在服务器端查找到与这一令牌信息建立有对应关系的资源信息，从而能够确定与统一资源定位符相对应的资源信息，实现资源的调配。需要说明的是，在具体实现时，与第二客户端的资源信息具有对应关系的令牌信息与携带在上述url中的令牌信息，可以是相同的字符串，也可以是按照预设规则进行组合和/或计算得到预设结论的字符串。

以上详细说明了服务器端依据第二客户端的资源信息为第二客户端生成标识码信息的过程，以及服务器端依据第一客户端扫描标识码信息后发出的第一请求确定第二客户端的资源信息的过程。下面结合图1-5所示实施例，更具体的说明上述过程在具体应用场景下的实现：

收款方(相当于第二客户端)将姓名、收款银行账号、手机号、联系地址、会员账号等信息作为申请收款二维码(相当于标识码信息)的申请信息(相当于资源信息)提交到服务器端；服务器端对申请信息验证通过后，将输入的申请信息映射成收款二维码和对应的url，且收款二维码对应的url中包含token(相当于令牌信息)；服务器端保存收款二维码、url和收款银行账户信息，以及各项信息之间的对应关系。这一对应关系体现为：收款二维码与包含有token的二维码url相对应，二维码url中包含的token与收款方的姓名、收款银行账号、手机号、联系地址、会员账号等信息相对应。包含有token的二维码url在收款二维码与收款方的隐私信息之间起到了信息隔离的作用，从而能够保护收款方的隐私。

在服务器端执行步骤s101接收第一客户端扫描第二客户端的标识码信息后发出的访问服务器端的第一请求之后，在执行步骤s103接收第一客户端输入的资源调配信息之前，参见图1-6所示，还可以包括：

s105：向第一客户端发送用于提示第一客户端输入资源调配信息的第二请求。

服务器端接收到第一客户端发送来的第一请求后，一方面可以执行步骤s102确定相对应的第二客户端的资源信息，另一方面既可以等待接收第一客户端发送来的资源调配信息，又可以执行步骤s105主动向第一客户端发送第二请求，以提示第一客户端输入资源调配信息。本实施例对步骤s105与步骤s102的执行顺序不作具体限定，既可以一先一后串行执行，又可以同时并列执行。

进一步优选地，执行步骤s105服务器端向第一客户端发送的第二请求中不包括通过令牌信息解析出的第二客户端的资源信息，从而可以进一步避免第一客户端知晓第二客户端的隐私信息，保障资源调配过程中的隐私信息安全。

在执行步骤s104依据第一客户端输入的资源调配信息以及第二客户端的资源信息完成资源的调配之后，参见图1-7所示，还可以包括：

s106：将资源调配的结果推送给第一客户端和第二客户端。

具体地，将资源调配的结果推送给第一客户端和第二客户端时，资源调配的结果中可包括资源调配成功的结果或者资源调配失败的结果，而优选不包括第二客户端的资源信息或第一客户端输入的资源调配信息。从而，在完成资源调配之后仍然持续的保护第一客户端和第二客户端的隐私信息，保护资源调配的信息安全。

在本申请各实施例中，第一客户端输入的资源调配信息，可以具体包括第一客户端的第一资源管理账号信息和资源调配数据信息。其中，资源调配数据信息，可以具体为用具体的数据信息量化表示希望进行调配的资源，还可以包含资源调配的目的、用户等相关说明。以银行转账的应用场景为例，可以具体为需要转账的金额，还可以包括转账的用途等备注说明。第一客户端输入的第一资源管理账号信息，可以根据第一客户端用户的实际情况，由第一客户端用户确定输入哪些内容。以第一客户端需要进行转账付款为例，若第一客户端用户不是支付平台的注册用户，则输入的第一资源管理账号信息可以是该用户用于转账付款的银行账号、姓名、开户行、银行密码等相关信息；而若第一客户端用户是支付平台的注册用户，则输入的第一资源管理账号信息还可以是该用户在支付平台已注册的用户名和密码。

在本申请各实施例中，第二客户端的资源信息，可以具体包括第二客户端的身份信息和第二资源管理账号信息，具体的内容可以根据第二客户端的实际情况选择确定。例如，第二客户端的身份信息可以包括姓名、身份证号、手机号码、联系地址、工商登记信息、资质认证信息等一项或多项涉及第二客户端的身份认证的相关信息。第二资源管理账号信息也同样可以包含多项可选的内容，以第二客户端希望进行转账收款为例，若第二客户端用户不是支付平台的注册用户，则第二资源管理账号信息可以是该用户用于转账收款的银行账号、姓名、开户行等相关信息；而若第二客户端用户已是支付平台的注册用户，则第二资源管理账号信息还可以是该用户在支付平台已注册的用户名和密码。

由此可见，采用本申请的实施例，若第一客户端和第二客户端之间希望进行资源的调配，只要向服务器端提供调配资源所需的必要信息即可，即只需要提供需要调配的资源、以及资源转出方和资源转入方的与被调配的资源密切相关的部分信息即可，而对于第一客户端和第二客户端是否已在平台进行会员注册，是否是同一平台的注册会员等方面没有限制。更具体地，以资源具体化为资金，资源的调配具体化为资金的转账为例，第一客户端和第二客户端可以是支付平台的注册会员，也可以不是；可以是相同支付平台的注册会员，也可以不是。若第一客户端或第二客户端不是支付平台的注册会员，只要能够向服务器端提供可用于资金转账的银行账号即可。因此，优选地，第一资源管理账号信息中可不包含第一客户端在服务器端的用户注册信息，和/或第二资源管理账号信息中可不包含第二客户端在服务器端的用户注册信息，从而可以简化第一客户端和/或第二客户端在进行资源的调配前在服务器端进行会员注册的步骤，也对第一客户端和第二客户端用户是否是同一服务平台的注册会员不做限定，有利于提高本申请实施例的适用性。

在具体实现本实施例时，上述服务器端可以由独立的运营商运营，也可以由不同的运营商分工运营，例如，可以包括平台服务器端和至少一个资源管理端，则以图1-1所示实施例为例，平台服务器端执行步骤s101～s103，资源管理端执行步骤s104；图1-2和图1-3所示实施例中，步骤s100以及具体步骤s1001～s1006的执行主体为平台服务器端；图1-6所示实施例中，步骤s105的执行主体为平台服务器端；图1-7所示实施例中，步骤106的执行主体，既可以是平台服务器端，也可以是资源管理端，还可以是二者的结合。

进一步地，若存在多个可选的资源管理端，假设第一客户端为资源转出方、第二客户端为资源转入方，则可根据资源转出方(此处即第一客户端)确定相匹配的资源管理端。具体地，在平台服务器端接收第一客户端输入的资源调配信息之后，在资源管理端依据第一客户端输入的资源调配信息以及第二客户端的资源信息完成资源的调配之前，可还包括：

平台服务器端依据第一客户端输入的第一资源管理账号信息，确定与第一资源管理账号信息相匹配的资源管理端；

平台服务器端向与第一资源管理账号信息相匹配的资源管理端发送调配资源指令，供与第一资源管理账号信息相匹配的资源管理端完成资源的调配。

基于以上举例，由于第一客户端输入的资源调配信息保存在平台服务器端，而第二客户端的资源信息也保存在平台服务器端，因此，为实现资源管理端对资源的调配，可以在平台服务器端向与第一资源管理账号信息相匹配的资源管理端发送的调配资源指令中，加入第二客户端的第二资源管理账号信息和第一客户端输入的资源调配数据信息。

需要说明的是，本申请实施例中的第一客户端既可以是资源转出方，也可以是资源转入方，只要第一客户端与第二客户端是资源调配的相对方即可。以上述实施例应用于资金转账中为例，既可以是付款方(此时为第一客户端)扫描收款方(此时为第二客户端)对应的标识码信息(可具体化为二维码)进行付款，也可以是收款方(此时为第一客户端)扫描付款方(此时为第二客户端)对应的标识码信息(可具体化为二维码)进行收款。在实际应用中，若付款方作为第一客户端，收款方作为第二客户端，则付款方的资金安全能够得到更好的保障，收款方的高频次收款也能保证较高的效率，可作为商户向顾客收款使用，也可用于个人需要转账的情况。在实际应用中，若付款方作为第二客户端，收款方作为第一客户端，则付款方的资金安全可结合其他的技术手段或非技术手段加以保护，可作为税务部门(此时为第一客户端，作为收款方)向个人或企业(此时为第二客户端，作为付款方)征缴税款，或者作为社保部门(此时为第一客户端，作为收款方)向个人或企业(此时为第二客户端，作为付款方)扣款使用。

实施例2

参见图2所示，本申请还提供了一种资源调配方法，适用于第一客户端，包括：

s201：第一客户端向服务器端发出访问服务器端的第一请求，以便服务器端依据第一请求中携带的令牌信息，确定与令牌信息相对应的第二客户端的资源信息；其中，第一请求中携带有令牌信息，令牌信息与第二客户端的资源信息具有对应关系；

s202：输入资源调配信息，并将资源调配信息发送到服务器端，供服务器端依据第一客户端输入的资源调配信息以及第二客户端的资源信息完成资源的调配。

上述实施例中的第一客户端可以采用具备扫描功能的仪器设备对标识码信息进行扫描，也可以采用安装有应用程序(application，简称app)的智能移动终端进行扫描，以发出上述第一请求。

进一步地，在向服务器端发出访问服务器端的第一请求之后，在输入资源调配信息之前，还可包括：

接收服务器端发送来的、用于提示第一客户端输入资源调配信息的第二请求。

本实施例中的第一客户端与实施例1中的服务器端相配合实现本申请的技术目的，实施例1中的相关阐释均适用于本实施例，此处不再赘述。

实施例3

本申请还提供一种资源调配方法，适用于第二客户端。第二客户端接收到标识码信息后向第一客户端展示，以便服务器端进行以下步骤：

接收第一客户端发出的访问服务器端的第一请求；其中，第一请求中携带有令牌信息，令牌信息与第二客户端的资源信息具有对应关系；

依据第一请求中携带的令牌信息，确定与令牌信息相对应的第二客户端的资源信息；

接收第一客户端输入的资源调配信息，并依据第一客户端输入的资源调配信息以及第二客户端的资源信息完成资源的调配。

具体地，第二客户端在向服务器端申请标识码信息时，可以向服务器端提交用于申请标识码信息的资源信息，以便服务器端在对资源信息验证通过时，建立资源信息与令牌信息的第一对应关系，生成携带有令牌信息的统一资源定位符和相对应的标识码信息，并保存资源信息与令牌信息的第一对应关系以及令牌信息与统一资源定位符的第二对应关系。服务器端将标识码信息发送到第二客户端后，第二客户端即可向第一客户端展示该标识码信息。

具体实现时，向服务器端提交资源信息时，可以采用线下纸质材料提交的方式进行，可以在服务器端对应的网页上进行，也可以采用移动终端的app进行。

图3-1～图3-3给出了一种第二客户端向服务器端申请二维码的实施示例，以第二客户端为收款方为例，向服务器端申请发放收款二维码。图3-1给出了收款二维码的申请界面，包括：服务器端要求第二客户端(此处即收款方)填写的申请收款二维码所需的资源信息。其中，资源信息可包含至少一种用户唯一标识，例如手机号码、银行卡号等。如图3-1中所示，资源信息可以包含用户的三种用户唯一标识，具体可以包含用户输入的手机号“13333333333”、持卡人的姓名“xxx”、银行卡的卡号“666666666666666”，还可以包含根据手机号实时获取的验证码。

在图3-1的界面下进行“下一步”操作后，将上述信息提交到服务器端，供服务器端对这些资源信息进行验证。验证通过后将资源信息映射为收款二维码和对应的url(url中携带有用于确定资源信息的令牌信息)。进一步地，服务器端将收款二维码发放给第二客户端，发放的方式可以有多种形式，可以是将电子版的收款二维码发送给第二客户端，也可以如图3-2或图3-3所示，要求第二客户端提供收款二维码的寄送地址或者服务器端将获取到的寄送地址展示给第二客户端确认，从而服务器端可以将收款二维码印制完毕后寄送给第二客户端。

第二客户端接收到收款二维码后，可以将收款二维码向特定或不特定的第一客户端展示，以便第一客户端扫描收款二维码后进行转账付款。

本实施例中的第二客户端与实施例1中的服务器端相配合实现本申请的技术目的，实施例1中的相关阐释均适用于本实施例，此处不再赘述。

实施例4

参见图4所示，与实施例1中提供的资源调配方法相对应地，本申请还提供了一种资源调配装置，包括：

请求接收模块101，接收第一客户端发出的访问服务器端的第一请求；其中，第一请求中携带有令牌信息，令牌信息与第二客户端的资源信息具有对应关系；

资源信息确定模块102，依据第一请求中携带的令牌信息，确定与令牌信息相对应的第二客户端的资源信息；

信息接收模块103，用于接收第一客户端输入的资源调配信息；

资源调配模块104，用于依据第一客户端输入的资源调配信息以及第二客户端的资源信息完成资源的调配。

本实施例也可以理解为服务器端的一种实现方案。当服务器端分为平台服务器端和资源管理端时，请求接收模块101、资源信息确定模块102、信息接收模块103可以认为是平台服务器端的一部分，资源调配模块104可以认为是资源管理端的一部分。

由于本实施例是与实施例1中的资源管理方法相对应的，因此，实施例1中的相关阐述均适用于本实施例，此处不再赘述。

实施例5

将实施例1给出的方法应用于金融领域时，即资源具体化为资金，调配方式具体化为电子支付，第一客户端和第二客户端具体化为电子支付的相对方时，本申请还提供了电子支付方法。以第一客户端具体化为付款端、第二客户端具体化为收款端，资源信息具体化为收款信息，资源调配信息具体化为付款信息为例，上述电子支付方法可具体包括：

接收付款端发出的访问服务器端的第一请求；其中，第一请求中携带有令牌信息，令牌信息与收款端的收款信息具有对应关系；

依据第一请求中携带的令牌信息，确定与令牌信息相对应的收款端的收款信息；

接收付款端输入的付款信息，并依据付款端输入的付款信息以及收款端的收款信息完成付款端向收款端的电子支付。

在上述实施例中，付款端发出的访问服务器端的第一请求，可以是由付款端扫描收款端的标识码信息后发出的，也可以是付款方通过输入指定网址或者指定字符串后发出的。进一步地，标识码信息可以采用条形码或二维码，从而可以简化电子支付的操作，提高效率。

上述第一请求可包括用于访问服务器端的统一资源定位符，统一资源定位符中携带有用于确定收款端的收款信息的令牌信息。

优选地，令牌信息与收款端的收款信息的对应关系的建立，可以包括：

生成与收款端相对应的携带有令牌信息的统一资源定位符，确定令牌信息与收款端的收款信息的对应关系。

优选地，令牌信息与收款端的收款信息的对应关系，具体可采用以下方式生成：

获取收款端的收款信息；

当对收款信息验证通过时，建立收款信息与令牌信息的第一对应关系，并生成携带有令牌信息的统一资源定位符和相对应的标识码信息；

保存收款信息与令牌信息的第一对应关系以及令牌信息与统一资源定位符的第二对应关系，并将标识码信息发送到收款端。

采用这种方式在获取到收款端的收款信息后生成统一资源定位符，确定令牌信息与收款信息的对应关系，令牌信息的具体内容与收款信息的具体内容可能存在关联。

还可以采用以下方式建立令牌信息与收款信息的对应关系：

生成携带有令牌信息的统一资源定位符和相对应的标识码信息；

接收收款端的收款信息后，建立令牌信息与收款端的收款信息的对应关系。

采用这种方式建立对应关系，可以先在服务器端预先生成携带有令牌信息的统一资源定位符。当服务器端接收到收款端的收款信息后，可以进一步对收款信息进行验证，验证通过后可将收款信息与预先生成的携带有令牌信息的统一资源定位符建立对应关系，从而建立令牌信息与收款端的收款信息的对应关系。采用本方式，令牌信息与统一资源定位符的具体内容与收款端的收款信息并无关系，只是在服务器端建立有令牌信息与收款信息的对应关系。

优选地，服务器端依据第一请求中携带的令牌信息，确定与令牌信息相对应的收款端的收款信息，可具体包括：

提取第一请求对应的统一资源标识符中携带的令牌信息；

依据令牌信息，在服务器端确定与令牌信息建立有第一对应关系的收款端的收款信息。

付款端输入的付款信息，可具体包括付款端的付款账号信息和电子支付金额信息；收款端的收款信息，可具体包括收款端的身份信息和收款账号信息。更近一步地，付款账号信息可包括付款端的银行账号信息和/或付款端在服务器端的用户注册账号信息；收款账号信息包括收款端的银行账号信息和/或收款端在服务器端的用户注册账号信息。需要说明的是，若服务器端在进行电子支付之前，已经获取到付款端的付款账号信息，则付款端在进行电子支付时输入的付款信息，可以只包括本次电子支付所对应的电子支付金额信息。

进一步地，服务器端可包括平台服务器端和至少一个金融服务器端，在实现电子支付时具体可包括：

平台服务器端接收付款端发出的访问平台服务器端的第一请求；其中，第一请求中携带有令牌信息，令牌信息与收款端的收款信息具有对应关系；

平台服务器端依据第一请求中携带的令牌信息，确定与令牌信息相对应的收款端的收款信息；

平台服务器端接收付款端输入的付款信息；

金融服务器端依据付款端输入的付款信息以及收款端的收款信息完成付款端向收款端的电子支付。

进一步地，在平台服务器端接收付款端输入的付款信息之后，在金融服务器端依据付款端输入的付款信息以及收款端的收款信息完成付款端向收款端的电子支付之前，还优选包括：

平台服务器端依据付款端的付款账号信息，确定与付款账号信息相匹配的金融服务器端；

平台服务器端向与付款账号信息相匹配的金融服务器端发送支付指令，供与付款账号信息相匹配的金融服务器端完成付款端向收款端的电子支付。其中，平台服务器端向与付款账号信息相匹配的金融服务器端发送的支付指令中，可具体包括收款端的收款账号信息和付款端的付款账号信息。

与以上实施例相对地，以第一客户端为收款端、第二客户端为付款端、资源信息具体化为付款信息，资源调配信息具体化为收款信息为例，本申请实施例的电子支付方法可具体包括：

接收收款端在扫描付款端的标识码信息后发出的访问服务器端的第一请求；其中，第一请求中携带有令牌信息，令牌信息与付款端的付款信息具有对应关系；

依据第一请求中携带的令牌信息，确定与标识码信息相对应的付款端的付款信息；

接收收款端输入的收款信息，并依据收款端输入的收款信息以及付款端的付款信息完成付款端向收款端的电子支付。

本实施例的电子支付方法是实施例1在资金转账、电子支付这一应用场景下的实现，实施例1中阐述的相关内容均适用于本实施例，此处不再赘述。

需要说明的是，本申请实施例所提供的资源调配方法及其装置，除适用于本实施例的场景之外，还适用于其他需要在第一客户端和第二客户端两方之间进行资源调配的情况，本实施例不应理解为对实施例1的应用场景的限定。

实施例6

现结合实施例1～实施例5中的优选实施方式，以第一客户端为付款端、第二客户端为收款端为例，说明在电子支付的应用场景下，付款端、收款端、平台服务区器端以及金融服务端相互配合，实现电子支付的过程。

参见图5所示：

s01：收款端向平台服务器端提交收款信息；

s02：平台服务器端对收款端提交的收款信息进行验证；

s03：验证通过后，平台服务器端向收款端下发标识码信息；标识码信息可以是条形码，也可以是二维码；下发标识码信息的方式，可以是电子版标识码发送，供收款端下载、打印、展示，也可以是由服务器端印制标识码信息，将纸质版标识码寄送至收款端；

s04：收款端接收到标识码信息后，向付款端展示；

s05：付款端扫描标识码信息；

s06：付款端向平台服务器端发送第一请求，第一请求中携带有令牌信息，优选地，第一请求中不携带收款端的收款信息；

s07：平台服务器端依据第一请求中携带的令牌信息确定相对应的收款端的收款信息；

s08：平台服务器端向付款端发送第二请求，用于提示付款端输入付款信息；

s09：付款端输入付款信息，并发送至平台服务器端；

s10：平台服务器端向金融服务端发送调配资源指令，该指令中包含付款端输入的付款信息和收款端的收款信息；

s11：金融服务端依据付款信息和收款信息，进行电子支付；

s12：金融服务端向平台服务器端反馈电子支付结果；

s13：平台服务器端向付款端和收款端推送电子支付结果。

本实施例中未尽事宜，参见实施例1～实施例5中相关阐述，此处不再赘述。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

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

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。