一种资源处理方法及装置

本申请是中国专利申请CN106845957A的分案申请，原申请的申请日为：2015年12月4日；申请号为：201510886211.4；发明创造名称为：一种资源处理方法及装置。

技术领域

本申请涉及计算机技术领域，尤其涉及一种资源处理方法及装置。

背景技术

随着信息技术的发展，用户除了可以在服务提供方提供的网络化平台上获得相应的业务服务以外，还可以直接从其他用户处获得相应的业务服务。

现有技术中，用户与用户之间进行业务操作的过程通常可在近场通信(NearField Communication，NFC)或二维码技术的支持下完成。具体而言，需求方用户(也称为第一用户)可以使用终端通过NFC或扫描二维码的方式，使得第一用户自身账户内的业务资源经服务器发送给提供方用户(也称为第二用户)的账户中，从而，第一用户便可以获得其所需的、且由第二用户所提供的业务服务。

但是，对于上述现有的过程而言，均是以终端作为媒介，也就是说，第一用户每次获得其他第二用户所提供的业务服务时，都需要使用终端进行通信或扫码的操作，以便完成业务资源的发送，一旦用户脱离终端，则不能完成业务资源的发送。

发明内容

本申请实施例提供一种资源处理方法及装置，用以解决现有的业务资源的处理的过程较为繁琐的问题。

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

接收终端发送的认证信息以及业务资源量信息，其中，所述认证信息与第一账户具有关联关系，所述终端与第二账户相绑定；

根据预先建立的认证信息与第一账户的关联关系，确定该认证信息对应的第一账户；

根据所述业务资源量信息，从第一账户的业务资源中获取与所述业务资源量信息相对应的业务资源，并转发给第二账户。

本申请实施例还提供的一种资源处理方法，包括：

终端向服务器发送认证信息以及业务资源量信息，使所述服务器根据预先建立的认证信息与第一账户的关联关系，确定该认证信息对应的第一账户；

所述终端通过绑定的第二账户接收所述服务器发送的与所述业务资源量信息相对应的业务资源，其中，所述业务资源为所述服务器根据所述业务资源量信息从所述第一账户的业务资源中获取到的。

本申请实施例还提供的一种资源处理方法，包括：

终端接收认证信息生成请求；

将该认证信息生成请求发送给服务器，以使得所述服务器根据该认证信息生成请求，生成唯一的认证信息，并建立所述认证信息与第一账户的关联关系，其中，所述认证信息与所述第一账户的关联关系用于使所述服务器根据与第二账户相绑定的终端所发送的认证信息，确定出与该认证信息所对应的第一账户，并从确定出的所述第一账户的业务资源中获取指定数量的业务资源。

本申请实施例还提供的一种资源处理方法，包括：

接收终端发送的款项认证信息以及额度信息，其中，所述款项认证信息与第一账户具有关联关系，所述终端与第二账户相绑定；

根据预先建立的款项认证信息与第一账户的关联关系，确定该款项认证信息对应的第一账户；

根据所述额度信息，从第一账户的款项中获取与所述额度信息相对应的款项，并转发给第二账户。

本申请实施例还提供的一种资源处理方法，包括：

接收终端发送的款项认证信息以及额度信息，其中，所述款项认证信息与第一账户具有关联关系，所述终端与第二账户相绑定；

根据预先建立的款项认证信息与第一账户的关联关系，确定该款项认证信息对应的第一账户；

判断所述额度信息所对应的款项额度是否超过所述第一账户的款项额度；

若是，则确定所述第一账户对应的信用款项，从所述信用款项中，获取与所述额度信息相对应的款项，并转发给第二账户，或者，从所述第一账户的款项以及确定出的所述第一账户的信用款项中，获取与所述额度信息相对应的款项，并转发给第二账户；

否则，则从所述第一账户的款项中获取与所述额度信息相对应的款项，并转发给第二账户。

本申请实施例还提供的一种资源处理方法，包括：

终端向服务器发送款项认证信息以及额度信息，使所述服务器根据预先建立的款项认证信息与第一账户的关联关系，确定该款项认证信息对应的第一账户；

所述终端通过绑定的第二账户接收所述服务器发送的与所述额度信息相对应的款项，其中，所述款项为所述服务器根据所述额度信息从所述第一账户的款项中获取到的。

本申请实施例还提供的一种资源处理方法，包括：

终端接收款项认证信息生成请求；

将该款项认证信息生成请求发送给服务器，以使得所述服务器根据该款项认证信息生成请求，生成唯一的款项认证信息，并建立所述款项认证信息与所述第一账户的关联关系，其中，所述款项认证信息与所述第一账户的关联关系用于使所述服务器根据与第二账户相绑定的终端所发送的款项认证信息，确定出与该款项认证信息所对应的第一账户，并从该第一账户的款项中获取指定额度的款项。

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

接收模块，用于接收终端发送的认证信息以及业务资源量信息，其中，所述认证信息与第一账户具有关联关系，所述终端与第二账户相绑定；

确定模块，用于根据预先建立的认证信息与第一账户的关联关系，确定该认证信息对应的第一账户；

处理模块，用于根据所述业务资源量信息，从第一账户的业务资源中获取与所述业务资源量信息相对应的业务资源，并转发给第二账户。

本申请实施例还提供的一种资源处理装置，包括：

发送模块，用于向服务器发送认证信息以及业务资源量信息，使所述服务器根据预先建立的认证信息与第一账户的关联关系，确定该认证信息对应的第一账户；

接收模块，用于通过与终端绑定的第二账户接收所述服务器发送的与所述业务资源量信息相对应的业务资源，其中，所述业务资源为所述服务器根据所述业务资源量信息从所述第一账户的业务资源中获取到的。

本申请实施例还提供的一种资源处理装置，包括：

接收模块，用于接收认证信息生成请求；

发送模块，用于将该认证信息生成请求发送给服务器，以使得所述服务器根据该认证信息生成请求，生成唯一的认证信息，并建立所述认证信息与第一账户的关联关系，其中，所述认证信息与所述第一账户的关联关系用于使所述服务器根据与第二账户相绑定的终端所发送的认证信息，确定出与该认证信息所对应的第一账户，并从确定出的所述第一账户的业务资源中获取指定数量的业务资源。

本申请实施例还提供的一种资源处理装置，包括：

接收模块，用于接收终端发送的款项认证信息以及额度信息，其中，所述款项认证信息与第一账户具有关联关系，所述终端与第二账户相绑定；

确定模块，用于根据预先建立的款项认证信息与第一账户的关联关系，确定该款项认证信息对应的第一账户；

处理模块，用于根据所述额度信息，从第一账户的款项中获取与所述额度信息相对应的款项，并转发给第二账户。

本申请实施例还提供的一种资源处理装置，包括：

接收模块，用于接收终端发送的款项认证信息以及额度信息，其中，所述款项认证信息与第一账户具有关联关系，所述终端与第二账户相绑定；

确定模块，用于根据预先建立的款项认证信息与第一账户的关联关系，确定该款项认证信息对应的第一账户；

处理模块，用于判断所述额度信息所对应的款项额度是否超过所述第一账户的款项额度，若是，则确定所述第一账户对应的信用款项，从所述信用款项中，获取与所述额度信息相对应的款项，并转发给第二账户，或者，从所述第一账户的款项以及确定出的所述第一账户的信用款项中，获取与所述额度信息相对应的款项，并转发给第二账户；否则，则从所述第一账户的款项中获取与所述额度信息相对应的款项，并转发给第二账户。

本申请实施例还提供的一种资源处理装置，包括：

发送模块，用于向服务器发送款项认证信息以及额度信息，使所述服务器根据预先建立的款项认证信息与第一账户的关联关系，确定该款项认证信息对应的第一账户；

接收模块，用于通过与终端绑定的第二账户接收所述服务器发送的与所述额度信息相对应的款项，其中，所述款项为所述服务器根据所述额度信息从所述第一账户的款项中获取到的。

本申请实施例还提供的一种资源处理装置，包括：

接收模块，用于接收款项认证信息生成请求；

发送模块，用于将该款项认证信息生成请求发送给服务器，以使得所述服务器根据该款项认证信息生成请求，生成唯一的款项认证信息，并建立所述款项认证信息与所述第一账户的关联关系，其中，所述款项认证信息与所述第一账户的关联关系用于使所述服务器根据与第二账户相绑定的终端所发送的款项认证信息，确定出与该款项认证信息所对应的第一账户，并从该第一账户的款项中获取指定额度的款项。

本申请实施例提供一种资源处理方法及装置，通过本方法，在应用场景下，当第一用户在获得第二用户所提供的业务服务的过程中，第一用户可以无需携带终端设备，只需使用第二用户使用的、且与该第二用户自身的第二账户相绑定的终端，输入与第一用户自身的第一账户具有关联关系的认证信息以及相应的业务资源量信息，就可以向第二用户的第二账户转移相应数量的业务资源。这样的方式有效地提升了不同用户之间转移业务资源的便捷性。

附图说明

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

图1～3为本申请实施例提供的资源处理过程；

图4～7为本申请实施例提供的在实际应用场景下的资源处理过程；

图8～10为本申请实施例提供的资源处理装置结构示意图；

图11～14为本申请实施例提供的在实际应用场景下的资源处理装置结构示意图。

具体实施方式

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

如图1所示，本申请实施例提供一种资源处理过程，具体包括以下步骤：

S101：接收终端发送的认证信息以及业务资源量信息。

其中，所述认证信息与第一账户具有关联关系，所述终端与第二账户相绑定。

在本申请实例中，终端可以是移动终端或计算机终端。第一账户可以是第一用户(也即，前述的需求方用户)的账户，相应地，第二账户可以是第二用户(也即，前述的提供方用户)的账户。认证信息可以看作是一种账户内的业务资源的认证信息，具体可以为包含字母、数字或符号的字符串。而业务资源量信息反映了第一账户需要向第二账户转移的业务资源的数量。当第一账户向第二账户转移了相应数量的业务资源后，第一用户便可以获得第二用户提供的业务服务。

当然，本申请实施例中的业务资源具体可以是能够在不同账户之间进行转移、交换的各类资源，如：属于某账户且在网盘中存储的数据文件、属于某人员管理账户的人员分组信息、款项等等。

在本申请实施例中的一种应用场景下，针对上述步骤S101，可以认为，第一用户在绑定了第二账户的终端中，输入认证信息和业务资源量信息。

S102：根据预先建立的认证信息与第一账户的关联关系，确定该认证信息对应的第一账户。

由于认证信息是一种账户内的业务资源的认证信息，也就是说，认证信息与相应的账户(第一账户)内的业务资源有关联，那么，通过认证信息，就可以确定出与该认证信息具有关联关系的账户。正如在本发明实施例中，通过认证信息就可以确定出与该认证信息具有关联关系的第一账户。

需要说明的是，对于任意账户，都可以通过相应的认证信息确定出相应的账户，那么，一个认证信息也就唯一对应着一个账户，即，认证信息具有唯一性。

S103：根据所述业务资源量信息，从第一账户的业务资源中获取与所述业务资源量信息相对应的业务资源，并转发给第二账户。

正如前述，业务资源量信息反映了获得业务服务所需的业务资源的数量，而账户中通常包含相应的业务资源，那么，当根据认证信息确定出了相应的账户后，也就可以获取该账户中相应数量的业务资源。换言之，在本申请实施例的应用场景中，可以根据业务资源量信息，确定出第一用户所使用的业务资源的数量，并从第一账户的业务资源中获取对应数量的业务资源，从而将获取得到的业务资源转发给第二账户。

需要说明的是，本申请实施例中的上述过程，可由服务提供商(包括但不限于：网站、银行、电信运营商等)后台的服务系统内的服务器执行，也即，第一用户和第二用户均在该服务系统中注册各自的账户(即，第一账户和第二账户)，当然，这里并不构成对本申请的限定。

通过上述步骤，显然，与现有技术不同的是，在应用场景下，当第一用户在获得第二用户所提供的业务服务的过程中，第一用户可以无需携带终端设备，只需使用第二用户使用的、且与该第二用户自身的第二账户相绑定的终端，输入与第一用户自身的第一账户具有关联关系的认证信息以及相应的业务资源量信息，就可以向第二用户的第二账户转移相应数量的业务资源。这样的方式有效地提升了不同用户之间转移业务资源的便捷性。

正如前述内容，当第一用户在获得第二用户提供的业务服务的过程中，第一用户只需在与第二账户绑定的终端中输入认证信息，从而，服务器便可以根据认证信息唯一地确定出第一账户，并从第一账户的业务资源中获取相应的业务资源。也就是说，认证信息与第一账户之间预先建立了一一对应的关联关系，一一对应的关联关系保证了服务器根据认证信息只会确定出第一账户，而不会确定出其他账户。

那么，在本申请实施例中，预先建立所述认证信息与第一账户的关联关系，具体包括：接收由第一账户发出的认证信息生成请求，根据接收到的所述认证信息生成请求，生成唯一的认证信息，并建立生成的所述认证信息与所述第一账户的关联关系。

具体而言，在实际应用场景下，第一用户可预先通过其第一账户发出请求，以请求服务器生成全局唯一的认证信息，并在服务器生成了该认证信息后，建立与第一账户之间的关联关系。从而，第一用户便可以直接使用该认证信息。

除了上述由服务器生成认证信息的方式之外，作为本申请实施例中的一种方式，认证信息也可以由用户自行设置，不同用户自行设置的认证信息可能出现重复，为了避免重复现象的出现，那么，服务器可以根据用户自行设置的认证信息的唯一性进行检验。例如：用户A自行设置了认证信息为“aaa”的字符串，那么，服务器将针对该字符串“aaa”进行唯一性的校验，在未发现与“aaa”相同的字符串后，服务器可将该字符串“aaa”确定为与用户A的账户相关联的认证信息。当然，这里并不构成对本申请的限定。

另外，考虑到在实际应用中，如果用户在获取其他用户所提供的业务服务的过程中使用了认证信息，那么，认证信息就可能存在泄露的风险，所以，为了避免或降低用户使用了认证信息后可能存在泄露的风险，所以在本申请实施例中，所述方法还包括：在生成所述认证信息时进行计时，当计时时长达到设定时长时，解除所述认证信息与所述第一账户的关联关系。

换言之，认证信息具有时效性，即，认证信息将在设定时长之后失效。在本申请实施例中，设定时长可以为12小时、24小时等等，具体可以根据实际使用时的需要进行设置，这里不构成对本申请的限定。

此外，在实际应用中，当用户获得其他用户所提供的业务服务的过程中，业务资源量信息所对应的业务资源的数量可能超过该用户自身的账户的业务资源的数量，在这样的情况下，将导致获取业务服务过程失败，而服务提供商可能会为不同的账户提供一种额外的业务资源，在本申请实施例中，额外的业务资源可称为超额资源，这样一来，即使用户的账户中的业务资源的数量少于业务资源量信息对应的业务资源的数量，服务器也可以从账户的超额资源中获取业务资源，以便用户完成获取业务服务的过程。

基于此，根据所述业务资源量信息，从第一账户的业务资源中获取与所述业务资源量信息相对应的业务资源，具体包括：判断所述业务资源量信息所对应的业务资源量是否超过所述第一账户的业务资源量，若是，则确定所述第一账户对应的超额资源，从所述超额资源中，获取与所述业务资源量信息相对应的业务资源，或者，从所述第一账户的业务资源以及确定出的所述超额资源中，获取与所述业务资源量信息相对应的业务资源；否则，则从所述第一账户的业务资源中获取与所述业务资源量信息相对应的业务资源。

具体而言，在业务资源量信息所对应的业务资源量超过第一账户的业务资源量的情况下，服务器获取业务资源可分为两种方式：第一种方式为，服务器之间从第一账户对应的超额资源中获取与业务资源量信息所对应的业务资源；第二种方式为，服务器首先获取第一账户的全部业务资源，再从第一账户对应的超额资源中获取剩余的业务资源，从而使得获取到的业务资源的数量与业务资源量信息对应的业务资源的数量相同。

当然，如果业务资源量信息所对应的业务资源量并未超过第一账户的业务资源量，那么，便可以直接从第一账户的业务资源中获取相应数量的业务资源。

例如：假设用户A的第一账户A’中的业务资源的数量为2，服务器为第一账户A’分配了10个单位的超额资源。同时假设用户A在获取其他用户的业务服务的过程中，业务资源量信息对应的业务资源的数量为5。那么，当用户A在其他用户的终端上输入了认证信息和业务资源量信息后，服务器就会首先获取第一账户A’中2个单位的业务资源，并再从第一账户A’的超额资源中获取3个单位的业务资源，使得获取到的业务资源的数量为5。又或者，服务器直接从第一账户A’的超额资源中获取5个单位的业务资源。

而对于第一账户A’的业务资源的数量不小于业务资源量信息所对应的业务资源的数量的情况，服务器便可以直接从第一账户A’的业务资源中获取，这里不再具体举例说明。

在实际应用中，第一账户所对应的超额资源，通常与账户的等级相关，也就是说，服务提供商通常会为不同等级的账户分配不同数量的超额资源，所以，确定所述第一账户对应的超额资源，具体包括：确定所述第一账户的账户等级，根据预先设定的账户等级与超额资源的对应关系，确定所述第一账户对应的超额资源。

需要说明的是，本申请实施例中的超额资源，由服务提供商所提供，并非是用户自身账户中的业务资源，可以认为超额资源属于一种信用资源，因此，当用户使用了超额资源后，将在设定时间后归还所使用的超额资源，作为本申请实施例中的一种方式，服务提供商在设定时间后，可以从用户的账户中扣除相应数量的业务资源。当然，这里并不构成对本申请的限定。

另外，需要说明的是，在实际应用场景下，当服务器执行了上述过程后，并非将获取到的业务资源直接转发给第二账户，通常，服务器会将获取到的业务资源临时存储在第三方账户中，并针对每一次获取第一账户中的业务资源的过程都生成相应的明细信息，并通过第一账户展示给第一用户，以便于第一用户进行确认，也即，在本申请实施例中，转发给第二账户之前，所述方法还包括：接收由第一账户发出的确认指示。

之所以需要第一用户进行确认，是为了避免出现其他用户在获知第一用户的第一账户的认证信息后，在第一用户不知情的情况下，恶意进行业务资源的获取行为。从而，通过确认指示的方式，使得第一用户可以有效的分辨出每一次自己输入的认证信息。对于并非由第一用户自身输入认证信息的过程，第一用户可以通过第一账户发出否认指示，服务器在接收到否认指示后，则会将从第一账户中获取的业务资源返回第一账户。

当然，作为本申请实施例中的一种方式，若服务器并未在设定的时间内接收到由第一账户发出的确认指示，那么，服务器可以临时存储于第三方账户的业务资源转发给第二账户。这里的设定时间可以根据实际应用的需要进行设置，如：设置为7天、10天等等，并不构成对本申请的限定。

此外，作为本申请实施例中另的一种方式，为了避免出现第一用户通过第一账户恶意发出否认指示，第二用户可以通过第二账户向服务提供商提交相应的证明信息，以证明第一用户输入了认证信息和业务资源量信息，并由服务提供商后台的服务系统进行判定，当然，这里并不构成对本申请的限定。

上述内容是基于服务器侧的执行过程，在实际应用中，对于发出认证信息和业务资源量信息的终端侧而言，本申请实施例中还提供一种资源处理方法，如图2所示，具体包括以下步骤：

S201:终端向服务器发送认证信息以及业务资源量信息，使所述服务器根据预先建立的认证信息与第一账户的关联关系，确定该认证信息对应的第一账户。

与上述实施例中相类似，这里的终端是与第二账户相绑定的终端，认证信息与第一账户具有关联关系，故在此不再过多赘述。

S202:所述终端通过绑定的第二账户接收所述服务器发送的与所述业务资源量信息相对应的业务资源，其中，所述业务资源为所述服务器根据所述业务资源量信息从所述第一账户的业务资源中获取到的。

经由与第二账户相绑定的终端向服务器发送认证信息和业务资源量信息后，服务器便可以根据认证信息确定出相应的第一账户，并从第一账户中获取业务资源，并转发给第二账户。

可见，在本申请实施例对应的实际应用场景下，在业务资源进行转移的过程中，第一用户不再需要使用自身的终端设备，而是可以直接通过绑定了第二账户的终端，输入相应的认证信息和业务资源量信息后，便可以完成业务资源的转移过程。这极大提升了由用户所发起的业务资源转移过程的便捷性。

另外，对于本申请实施例中的认证信息而言，其与第一账户相关联，认证信息的生成通常基于第一用户在第一账户下所发出的相应操作，故在本申请实施例中还提供一种资源处理方法，如图3所示，具体包括如下步骤：

S301：终端接收认证信息生成请求。

这里的终端是与第一账户相绑定的终端，认证信息生成请求可以由第一用户在终端上执行相应的操作而发出。

S302:将该认证信息生成请求发送给服务器，以使得所述服务器根据该认证信息生成请求，生成唯一的认证信息，并建立所述认证信息与第一账户的关联关系，其中，所述认证信息与所述第一账户的关联关系用于使所述服务器根据与第二账户相绑定的终端所发送的认证信息，确定出与该认证信息所对应的第一账户，并从确定出的所述第一账户的业务资源中获取指定数量的业务资源。

服务器在接收到了认证信息生成请求后，就会生成相应的认证信息，并建立与第一账户的关联关系，也即，认证信息可以唯一地确定出第一账户，故服务器可以进一步地从第一账户的业务资源中获取指定数量的业务资源，这里指定数量的业务资源，就是上述内容中业务资源量信息所对应的业务资源的数量，当然，具体过程正如前述内容，这里不再过多赘述。

另外，当第一用户发起了向第二用户自身的第二账户中转移业务资源的操作后，服务器还会像第一用户自身的第一账户发出确认，以使得第一用户进行确认，所以，在本申请实施例中，所述方法还包括：所述终端接收服务器发送的确认请求，根据用户针对所述确认请求的操作，生成确认指示，返回给服务器，以使得所述服务器根据所述确认指示将获取的所述业务资源转发给第二账户。

综上所述，在本申请实施例中提供了一种不同与现有技术的资源处理方式，使得在用户发起的业务资源转移的过程中，第一用户可以无需使用或携带终端设备，只需借助第二用户所使用的、与第二账户相绑定的终端，输入认证信息和业务资源量信息，即可将相应数量的业务资源转移给第二账户，从而有效提升了由用户发起的业务资源转移的过程的便捷性。

本申请中的上述内容，也适用于实际应用中的个人与个人之间的电子商务(Customer to Customer)的服务架构。为了清楚的说明上述的资源处理过程，现以业务资源为款项、业务资源量信息为额度信息的场景进行描述。

在该场景下，第一用户可以获得第二用户所提供的业务服务，此时，第一用户需要向第二用户支付相应的款项，在第一用户不携带终端的情况下，第一用户可以使用第二用户的终端完成款项的支付过程。

基于此，本申请实施例中提供一种资源处理方法，如图4所示，具体包括如下步骤：

S401:接收终端发送的款项认证信息以及额度信息，其中，所述款项认证信息与第一账户具有关联关系，所述终端与第二账户相绑定。

S402:根据预先建立的款项认证信息与第一账户的关联关系，确定该款项认证信息对应的第一账户。

S403:根据所述额度信息，从第一账户的款项中获取与所述额度信息相对应的款项，并转发给第二账户。

可见，第一用户可以在第二用户的终端(该终端与第二用户自身的第二账户相绑定)上直接输入所要支付的额度以及该款项认证信息，从而，服务器便可以根据款项认证信息，从第一用户自身的第一账户内扣除相应额度的款项并支付给第二账户。显然，这样的方式可以在第一用户不携带任何终端设备的情况下完成支付操作，有效提升了支付的便捷性。

相应地，在本申请实施例中还提供一种资源处理方法，如图5所示，具体包括如下步骤：

S501：接收终端发送的款项认证信息以及额度信息，其中，所述款项认证信息与第一账户具有关联关系，所述终端与第二账户相绑定。

S502:根据预先建立的款项认证信息与第一账户的关联关系，确定该款项认证信息对应的第一账户。

S503:判断所述额度信息所对应的款项额度是否超过所述第一账户的款项额度，若是，则执行步骤S504，否则，则执行步骤S505。

S504：确定所述第一账户对应的信用款项，从所述信用款项中，获取与所述额度信息相对应的款项，并转发给第二账户，或者，从所述第一账户的款项以及确定出的所述第一账户的信用款项中，获取与所述额度信息相对应的款项，并转发给第二账户；

S505：从所述第一账户的款项中获取与所述额度信息相对应的款项，并转发给第二账户。

可见，在本申请实施例中，服务提供商可以提供一种赊账服务，使得用户可以借助其账户的信用款项完成支付操作。当然，账户所对应的信用款项与账户的等级相关，即，账户等级越高，其信用款项的额度也就越高，具体内容与前述内容相类似，故在此不再过多赘述。

对于第二用户所使用的终端而言，如图6所示，在本申请实施例中还提供一种资源处理方法，具体包括以下步骤：

S601:终端向服务器发送款项认证信息以及额度信息，使所述服务器根据预先建立的款项认证信息与第一账户的关联关系，确定该款项认证信息对应的第一账户。

S602：所述终端通过绑定的第二账户接收所述服务器发送的与所述额度信息相对应的款项，其中，所述款项为所述服务器根据所述额度信息从所述第一账户的款项中获取到的。

相应地，对于第一用户所使用的终端而言，如图7所示，在本申请实施例中还提供一种资源处理方法，具体包括以下步骤：

S701:终端接收款项认证信息生成请求。

S702:将该款项认证信息生成请求发送给服务器，以使得所述服务器根据该款项认证信息生成请求，生成唯一的款项认证信息，并建立所述款项认证信息与所述第一账户的关联关系，其中，所述款项认证信息与所述第一账户的关联关系用于使所述服务器根据与第二账户相绑定的终端所发送的款项认证信息，确定出与该款项认证信息所对应的第一账户，并从该第一账户的款项中获取指定额度的款项。

综上所述，在C2C的服务架构下，采用本申请实施例中的资源处理方法，第一用户可以无需再使用或携带终端设备，而是可以直接使用第二用户的终端(该终端与第二用户自身的第二账户相绑定)，通过输入款项认证信息的方式完成支付操作，从而有效提升了支付操作的便捷性。

以上为本申请实施例提供的资源处理方法，基于同样的思路，本申请实施例还提供一种资源处理装置，如图8所示。所述装置包括：

接收模块801，用于接收终端发送的认证信息以及业务资源量信息，其中，所述认证信息与第一账户具有关联关系，所述终端与第二账户相绑定。

确定模块802，用于根据预先建立的认证信息与第一账户的关联关系，确定该认证信息对应的第一账户。

处理模块803，用于根据所述业务资源量信息，从第一账户的业务资源中获取与所述业务资源量信息相对应的业务资源，并转发给第二账户。

具体地，确定模块802，具体用于接收由第一账户发出的认证信息生成请求，根据接收到的所述认证信息生成请求，生成唯一的认证信息，并建立生成的所述认证信息与所述第一账户的关联关系。

基于此，上述装置还包括：时效模块804，用于在生成认证信息时进行计时，当计时时长达到设定时长时，解除所述认证信息与所述第一账户的关联关系。

在本申请实施例中，处理模块803，具体用于判断所述业务资源量信息所对应的业务资源量是否超过所述第一账户的业务资源量，若是，则确定所述第一账户对应的超额资源，从所述超额资源中，获取与所述业务资源量信息相对应的业务资源，或者，从所述第一账户的业务资源以及确定出的所述超额资源中，获取与所述业务资源量信息相对应的业务资源；否则，则从所述第一账户的业务资源中获取与所述业务资源量信息相对应的业务资源。

更为具体地，处理模块803，具体用于确定所述第一账户的账户等级，根据预先设定的账户等级与超额资源的对应关系，确定所述第一账户对应的超额资源。

另外，转发给第二账户之前，接收模块801，还用于接收由第一账户发出的确认指示。

本申请实施例还提供一种资源处理装置，如图9所示。所述装置包括：

发送模块901，用于向服务器发送认证信息以及业务资源量信息，使所述服务器根据预先建立的认证信息与第一账户的关联关系，确定该认证信息对应的第一账户；

接收模块902，用于通过与终端绑定的第二账户接收所述服务器发送的与所述业务资源量信息相对应的业务资源，其中，所述业务资源为所述服务器根据所述业务资源量信息从所述第一账户的业务资源中获取到的。

本申请实施例还提供一种资源处理装置，如图10所示。所述装置包括：

接收模块1001，用于接收认证信息生成请求。

发送模块1002，用于将该认证信息生成请求发送给服务器，以使得所述服务器根据该认证信息生成请求，生成唯一的认证信息，并建立所述认证信息与第一账户的关联关系，其中，所述认证信息与所述第一账户的关联关系用于使所述服务器根据与第二账户相绑定的终端所发送的认证信息，确定出与该认证信息所对应的第一账户，并从确定出的所述第一账户的业务资源中获取指定数量的业务资源。

基于此，上述装置还包括：确认指示模块1003，用于接收服务器发送的确认请求，根据用户针对所述确认请求的操作，生成确认指示，返回给服务器，以使得所述服务器根据所述确认指示将获取的所述业务资源转发给第二账户。

在基于C2C服务架构的场景下，本申请实施例中还提供一种资源处理装置，如图11所示，包括：

接收模块1101，用于接收终端发送的款项认证信息以及额度信息，其中，所述款项认证信息与第一账户具有关联关系，所述终端与第二账户相绑定。

确定模块1102，用于根据预先建立的款项认证信息与第一账户的关联关系，确定该款项认证信息对应的第一账户。

处理模块1103，用于根据所述额度信息，从第一账户的款项中获取与所述额度信息相对应的款项，并转发给第二账户。

如图12所示，本申请实施例中还提供一种资源处理装置，包括：

接收模块1201，用于接收终端发送的款项认证信息以及额度信息，其中，所述款项认证信息与第一账户具有关联关系，所述终端与第二账户相绑定。

确定模块1202，用于根据预先建立的款项认证信息与第一账户的关联关系，确定该款项认证信息对应的第一账户。

处理模块1203，用于判断所述额度信息所对应的款项额度是否超过所述第一账户的款项额度，若是，则确定所述第一账户对应的信用款项，从所述信用款项中，获取与所述额度信息相对应的款项，并转发给第二账户，或者，从所述第一账户的款项以及确定出的所述第一账户的信用款项中，获取与所述额度信息相对应的款项，并转发给第二账户；否则，则从所述第一账户的款项中获取与所述额度信息相对应的款项，并转发给第二账户。

如图13所示，本申请实施例中还提供一种资源处理装置，包括：

发送模块1301，用于向服务器发送款项认证信息以及额度信息，使所述服务器根据预先建立的款项认证信息与第一账户的关联关系，确定该款项认证信息对应的第一账户。

接收模块1302，用于通过与终端绑定的第二账户接收所述服务器发送的与所述额度信息相对应的款项，其中，所述款项为所述服务器根据所述额度信息从所述第一账户的款项中获取到的。

如图14所示，本申请实施例中还提供一种资源处理装置，包括：

接收模块1401，用于接收款项认证信息生成请求。

发送模块1402，用于将该款项认证信息生成请求发送给服务器，以使得所述服务器根据该款项认证信息生成请求，生成唯一的款项认证信息，并建立所述款项认证信息与所述第一账户的关联关系，其中，所述款项认证信息与所述第一账户的关联关系用于使所述服务器根据与第二账户相绑定的终端所发送的款项认证信息，确定出与该款项认证信息所对应的第一账户，并从该第一账户的款项中获取指定额度的款项。

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

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

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

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

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

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