信息处理方法及信贷平台

本发明涉及通信领域的信息处理技术，尤其涉及一种信息处理方法及信贷 平台。

随着互联网金融的发展，包括点到点P2P在内的各种无抵押贷款因其较高 的收益率得到了快速的发展。现有的网络金融中的授信方式包括两种：

第一种：由贷款申请人提供的收入证明等线下资料；

第二种：对用户行为产生的与偿还能力相关的数据进行大数据分析，以确 定用户偿还能力。采用这种方式，首先包括信息收集、信息真假帅选以及对帅 选后的信息进行综合分析，确定用户的偿还能力。与用户偿还能力相关的数据 包括互联网消费数据以及信贷记录等信息。

显然采用第一种方式，用户可能需要公司工具工资证明或银行开具存款证 明，再由用户上传到信贷平台，显然操作繁琐，效率低，与互联网信贷便捷的 宗旨是相违背的。

采用第二种方式，相对于第一种方式效率及用户使用满意度都提高了很多， 但是还是存在以下问题：

但是，依据大数据分析来确定用户的偿还能力，进而进行网上货贷的技术 方案，需要对每一个信贷用户与偿还能力的数据进行分析；会存在以下问题：

1：由于不同的平台之间出于信息安全等问题，会形成信息壁垒；导致获取 更加全面用户偿还能力的分析数据较难；具体如，银行系统基于安全问题，很 难在没有用户亲笔签名等授权情况下，向信贷平台披露用户的存款信息；且对 于用户依然不够方便。

2：需要对每一个信贷用户的消费数据、信贷数据或工资数据等进行大数据 分析，数据信息量大；为了确保正确同时还得在大量数据中进行信息真伪的辨 别，响应效率依然较低的问题。

3：对于一些新信贷用户，可能长期在国外，在很长一段时间内，在国内互 连网上都没有对应的消费记录、工资记录或信贷数据，这样无法确定这些用户 的偿还能力，进而导致这一部分用户无法获得信贷，进而导致信贷平台的用户 数量被减少或活跃度不高。

4：基于大数据分析来确定用户的偿还能力，均是对用户行为产生的历史数 据进行分析。而实际信贷时，用户可能因为升职、降职、继承、结婚或离婚等 不会立刻在互连网上形成相应记录的事件的发生，导致用户的偿还能力在短期 内发生很大的变化。然后信贷平台依旧以这些事情发生之前用户行为形成的历 史数据为依据来确定用户的偿还能力，会导致确定的用户偿还能力的准确定大 打折扣，进而导致出现呆账或死账的问题，或导致流失部分偿还能力很强的优 质客户，进而导致资金和信贷平台使用率无法达到资源最优化的问题。

有鉴于此，本发明实施例期望提供一种信息处理方法及信贷平台，以提高 信贷平台的智能性和资源优化使用率。

为达到上述目的，本发明的技术方案是这样实现的：本发明实施例第一方 面提供一种信息处理方法，所述方法包括：

信贷平台接收第一账户的客户端发送的信贷请求；所述信贷请求包括信贷 申请金额；

响应所述信贷请求，依据至少一个第二账户为所述第一账户信贷提供的担 保信息，确定所述第一账户的可用信用额度；其中，所述第二账户为所述第一 账户的担保账户；所述第二账户和所述第一账户为不同用户注册在所述信贷平 台的操作账户；

依据所述信贷申请金额和所述可用信用额度，向所述第一账户进行信贷支 付，形成信贷结果；

向所述第一账户的客户端发送所述信贷结果。

优选地，所述方法还包括：获取所述第二账户为所述第一账户信贷提供的 担保信息。

优选地，所述获取所述第二账户为所述第一账户信贷提供的担保信息，包 括：接收所述第二账户的客户端发送的表示同意为所述第一账户提供担保的认 证信息；依据所述认证信息，形成所述担保信息。

优选地，所述依据所述认证信息，形成所述担保信息，包括：获取所述第 一账户和所述第二账户的关联关系数据；依据所述关联关系数据及认证信息， 形成所述担保信息。

优选地，所述依据所述认证信息，形成所述担保信息，还包括：

审核所述认证信息，确定所述第二账户的可担保额度；

依据所述第二账户的可担保额度，确定实际担保额度；

形成包括实际担保额度及所述第二账户的账户信息的所述担保信息；

所述依据至少一个第二账户为所述第一账户信贷提供的担保信息，确定所 述第一账户的可用信用额度，包括：

依据所述实际担保额度，确定所述第一账户的信用额度。

优选地，所述审核所述认证信息，确定所述第二账户的可担保额度，包括：

获取所述第二账户的经济状况的依据信息、历史担保记录、第二账户的信 贷额度及第二账户与第一账户的关联关系的至少其中之一；

依据所述依据信息、所述历史担保记录、所述第二账户的信贷额度及所述 第二账户与第一账户的关联关系的至少其中之一，确定所述第二账户的可担保 金额。

优选地，所述审核所述认证信息，确定所述第二账户提供的担保额度，包 括：

查询所述第二账户的信用等级信息；

依据所述担保信用等级信息，确定所述可担保额度。

8、根据权利要求3至7任一项所述的方法，其特征在于，

所述认证信息还包括担保金额；

所述依据所述第二账户的可担保额度，确定实际担保额度，包括：

依据所述担保金额及所述可担保额度，确定所述实际担保额度；

其中，所述实际担保额度不高于所述可担保额度，且不高于所述担保金额。

优选地，所述方法还包括：

依据所述担保信息，形成担保生效信息；

分别向所述第一账户和所述第二账户的客户端发送所述担保生效信息。

优选地，所述获取所述第二账户为所述第一账户信贷提供的担保信息，还 包括：

接收所述第二账户的客户端发送的第一账户申请信贷的查询请求；

响应所述查询请求向所述第二账户的客户端发送第一账户的信贷申请状况 信息。

优选地，所述方法还包括：

当所述信贷结果表明所述信贷平台已向所述第一账户提供信贷时，形成并 向所述第二账户的客户端发送信贷担保反馈信息。

本发明实施例第二方面提供一种信贷平台，所述信贷平台包括：

接收单元，用于接收第一账户的客户端发送的信贷请求；所述信贷请求包 括信贷请求以及信贷申请金额；

响应单元，用于响应所述信贷请求，依据至少一个第二账户为所述第一账 户信贷提供的担保信息，确定所述第一账户的可用信用额度；其中，所述第二 账户为所述第一账户的担保账户；所述第二账户和所述第一账户为不同用户注 册在所述信贷平台的操作账户；

支付单元，用于依据所述信贷申请金额和所述可用信用额度，向所述第一 账户进行信贷支付，形成信贷结果；

发送单元，用于向所述第一账户的客户端发送所述信贷结果。

优选地，所述信贷平台还包括：

获取单元，用于获取所述第二账户为所述第一账户信贷提供的担保信息。

优选地，所述获取单元，包括：

接收模块，用于接收所述第二账户的客户端发送的表示同意为所述第一账 户提供担保的认证信息；

形成模块，用于依据所述认证信息，形成所述担保信息。

优选地，所述获取单元还包括：

获取模块，用于获取所述第一账户和所述第二账户的关联关系数据；

所述形成模块，具体用于依据所述认证信息及所述关联关系数据，形成所 述担保信息。

优选地，所述获取单元包括：

审核模块，用于审核所述认证信息，确定所述第二账户的可担保额度；

确定模块，用于依据所述第二账户的可担保额度，确定实际担保额度；

所述形成模块，具体用于形成包括实际担保额度及所述第二账户的账户信 息的所述担保信息；

所述响应单元，具体用于依据所述实际担保额度，确定所述第一账户的信 用额度。

优选地，所述审核模块，具体用于获取所述第二账户的经济状况的依据信 息、历史担保记录、第二账户的信贷额度及第二账户与第一账户的关联关系的 至少其中之一；并依据所述依据信息、所述历史担保记录、所述第二账户的信 贷额度及所述第二账户与第一账户的关联关系的至少其中之一，确定所述第二 账户的可担保金额。

优选地，所述信贷平台还包括：

形成单元，用于依据所述担保信息，形成担保生效信息；

所述发送单元，还用于分别向所述第一账户和所述第二账户的客户端发送 所述担保生效信息。

优选地，所述接收单元还用于接收所述第二账户的客户端发送的第一账户 申请信贷的查询请求；

所述发送单元，还用于响应所述查询请求向所述第二账户的客户端发送第 一账户的信贷申请状况信息。

优选地，所述发送单元，还用于当所述信贷结果表明所述信贷平台已向所 述第一账户提供信贷时，形成并向所述第二账户的客户端发送信贷担保反馈信 息。

本发明实施例信息处理方法及信贷平台，在进行信贷时可依据第二账户为 第一账户的信贷担保来发放信贷，相对于现有技术中依据大数据的处理结果来 决定是否发放信贷，减少了信贷平台的数据处理量，提高了信贷平台的响应速 率。于此同时，本发明实施例所述的方法和信贷平台在进行信贷处理时，也避 免因信息壁垒和信息滞后导致信息不全面和不准确导致的部分信贷的没有正常 发放的现象。且对于用户而言可以在其他账户的担保下获取信贷贷款，操作更 加简便，用户的使用满意度更高。此外，本发明实施例所述的方法提高了智能 平台的智能性，更好的优化了智能平台，实现了信贷资金和信贷平台的资源优 化。

图1为本发明实施例提供的信息处理方法的流程示意图之一；

图2为本发明实施例提供的信贷平台的结构示意图之一；

图3为本发明实施例提供的信贷平台的结构示意图之二；

图4为本发明实施例提供的信息处理方法的流程示意图之二；

图5本发明实施例提供的信息处理方法的流程示意图之三；

图6为本发明实施例提供的信息处理方法的流程示意图之四；

图7为本发明实施例提供的信息处理方法的流程示意图之五；

图8为本发明实施例提供的信息处理方法的流程示意图之六；

图9为本发明实施例提供的信息处理方法的流程示意图之七；

图10为本发明实施例所述的信贷平台的结构示意图之三；

图11为本发明实施例所述的信贷平台的结构示意图之四。

以下结合说明书附图及具体实施例对本发明的技术方案做进一步的详细阐 述。

方法实施例一：

如图1所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：信贷平台接收第一账户的客户端发送的信贷请求；所述信贷请 求包括信贷申请金额；

步骤S120：响应所述信贷请求，依据至少一个第二账户为所述第一账户信 贷提供的担保信息，确定所述第一账户的可用信用额度；其中，所述第二账户 为所述第一账户的担保账户；所述第二账户和所述第一账户为不同用户注册在 所述信贷平台的操作账户；

步骤S130：依据所述信贷申请金额和所述可用信用额度，向所述第一账 户进行信贷支付，形成信贷结果；

步骤S140：向所述第一账户的客户端发送所述信贷结果。

所述信贷平台为连接在互连网用于进行信用信贷相关信息处理的信息处理 平台、具体如，云平台或至少一台服务器构成的信息处理平台。

图2所示的为所述信贷平台的一种结构，图2所示的信贷平台100包括信 贷服务器101、数据库102以及信贷网关103。

所述信贷服务器101可用于执行上述步骤S110至步骤S150中的信息处理 操作。

所述数据库102包括存储第一账户和第二账户的所有信息，如信贷金额、 信贷时间、信贷用户身份信息、担保账户以及担保账户的用户身份信息等。

所述信贷网关103用于所述信贷平台100与外设进行信息交互的接口；用 于对接入所述信贷平台的客户端进行安全认证等处理，对进入所述信贷平台的 数据包做安全过滤处理，以免所述信贷平台的数据遭到损坏和盗窃。

在图2所示的个人PC 201和手机202均是通过互连网可以所述信贷平台建 立连接的客户端。在具体实现时，所述客户端不局限于手机和个人PC，还可以 平板电脑等具有互连网连接功能的电子设备。

在图2中与信贷相关的数据都存储在于所述信贷服务器分离的数据库中， 在具体实现时，所述数据也可以存储在所述信贷服务器的存储介质。将数据存 储在与所述信贷服务器分离的数据库中的好处是，可以提高信息安全。如当信 贷服务器出现系统故障时，因为信贷数据存储在数据库中，不会导致数据暂时 不能使用或永久丢失。

在具体实现时，所述信贷服务器和所述数据库都不止一个，如图3所示， 所述信贷平台100包括信贷服务器和数据库。所述信贷服务器中包括多 台信贷服务器；所述数据库中不仅包括多个数据库，如信贷收支数据库、担 保信息数据库以及账户信息数据库。

所述信贷收支数据库，可用于存储每一个信贷账户的信贷信息、支付信息 等与资金往来相关的数据。

所述担保信息数据库可以为用于存储所述担保信息的数据库。

所述账户信息数据库为存储有第一账户和第二账户的账户信息的数据库， 如第一账户的用户身份信息及第一账户可操作功能信息。所述第一账户可操作 功能信息可包括譬如开通免费还贷时限提醒功能、账户余额提示功能等信息。

不同的数据库根据其存储的数据的密级不用，可以采用不同安全等级的加 密方式和信息防盗方式，这种采用不同数据库存储同一账户的不同信息的方式， 相对于一个账户所有信息存储在一个数据库内，该数据库若出现泄密事件，则 该账户的所有信息都将泄密的问题，从而提高了信息安全问题。

所述第一账户和第二账户均为注册在所述信贷平台上的账户。每一个所述 账户通常都对应有账户标识和账户密码。

用户可以通过账户标识和账户密码登陆到所述信贷平台。所述信贷平台上 存储有各个账号进行的信用信贷等操作形成的各类信息，如借款金额、借款时 间以及担保信息等。

所述信贷请求为所述第一账户的客户端向所述信贷平台发送的请求发放信 用贷款的请求信息。所述信贷申请金额为第一账户的用户，期望获取的信贷金 额。

其中，所述第二账户可为第一账户具有关联关系的账户；这种关联关系可 以用关联关系数据来体现。具体如，所述第一账户的用户a为公司A的员工， 所述第二账户为所述公司A注册在所述信贷平台上的账户；则所述第一账户 为员工账户，所述第二账户为公司账户。由于第一账户的用户a为公司A的员 工，公司A很清楚用户a的经济能力，基于这种职业关系，公司A会愿意同意 为用户a提供信贷担保的可能性很大。

在具体实现时，在所述信贷平台的数据库中，可以将所述第二账户作为所 述第一账户的属性信息，从而建立所述第一账户与第二账户之间的关联关系。

所述第一账户和所述第二账户可以为不同用户注册在所述信贷平台上的操 作账户，所述第一账户的用户和所述第二账户的用户之间也可以没有关联关系。 具体如，所述第一账户和所述第二账户还可以是具有朋友或亲属等关联关系的 关联账户，表征所述第一账户和所述第二账户的关联关系的数据为关联关系数 据。具体如，第一账户和第二账户的用户是QQ好友或好友。此时，所述 关联关系数据可包括第一账户和所述第二账户通过QQ或进行交流的频繁 度看，参见同一社交活动的次数等数据。

所述关联关系不仅可以是职业关联关系，还可以是其他社交关联关系，具 体如信贷平台为移动客户端提供互连网信息处理平台。所述移动客户端可能手 机或平板电脑等电子设备。用户在所述信贷平台上进行注册时，可能是以手机 QQ或账号等运行在移动客户端上的社交账号注册的。此时，依据QQ 或，信贷平台在响应所述第一账号的信贷请求时，通过获得这些社交关 系数据，建立所述第一账户和第二账户之间的关联关系。所述社交关系数据即 为所述关联关系数据的一种。所述第一账户和第二账户之间的关联关系数据， 也可以是基于用户通过客户端向信贷平台提交的。

步骤S120中的可用信贷金额可以理解为剩余信贷金额，具体如当第一账户 的担保信息总共可提供20万信贷金额，但是第一账户已经支取的3万的信贷贷 款，则当前的可用信贷金额为17万。

在本实施例中，所述担保信息为确定可用信贷金额的参数之一。在具体实 现时，信贷平台可以基于第一账户的用户的资产证明为第一账户提供信贷金额。 在第一账户的信贷金额可包括第一账户的资产证明以及担保账户为其信贷提供 的担保信息信贷金额的总和。

在步骤S120中为第一账户提供信贷担保的第二账户可以为1个或多个，具 体如第一账户为账户A、其对应的第二账户可能包括3个，具体如，账户B、 账户C以及账户D。当所述第一账户有多个第二账户作为第一账户的担保账户， 为提供信贷担保，从一定程度上表明了第一账户的信用较高且有较多的担保人， 则向其提供信贷借款归还的几率高，可以向担保账户更多的第一账户提供更高 的信用额度。

在具体的实现过程中，若账户A有10个担保账户，若账户B仅有3个担 保账户。若风控规则为根据担保账户数达到指定数值时可提供信用贷款，且所 述指定数值为8。若信贷平台采用上述风控规则，进行信贷发放的控制，则各 个担保账户在提供信贷担保时无需提供担保金额，信贷平台也可以在不审核各 个担保账户可提供的担保金额，直接确定向所述第一账户提供等于所述信贷申 请金额的可用信贷额度，向所述第一账户进行信贷支付。按照上述风控规则进 行信贷支付，则信贷平台会向所述账户A提供信贷借款，而不会向所述账户B 提供信贷借款。

作为本实施例的进一步改进，如图4所示，所述方法还将包括：

步骤S150：依据所述信贷结果，形成并向所述第二账户的客户端发送信贷 担保反馈信息。

在步骤S150具体可包括：当信贷结果表明第一账户的此次信贷申请成功， 且信贷利用了第二账户为第一账户信贷提供的担保信息，则将形成信贷担保反 馈信息，以告知第二账户的用户为第一账户的信贷提供的担保已经生效了。

在具体实现时，若第二账户为第一账户提供信贷担保，当所述信贷结果表 明信贷申请失败，也可以发送所述信贷反馈信息以通过所述第二账户的客户端 告知第二账户的用户，此次信贷担保没有成功，以提高用户的使用满意度。

具体如，当第一账户的可用信贷担保有15万，其中10万是由第二账户为 第一账户信贷担保提供的，另外5万是由第一账户的用户的资产证明提供的， 若第一账户此次借贷13万，此时可以优先采用第一账户的用户资产证明提供的 信贷金额，借贷成功利用了第二账户为第一账户提供8万的信贷金额。信贷平 台将通过所述信贷担保反馈信息告知第二账户的客户端其已经为第一账户提供 了8万的信贷担保。

综合上述，本实施例提供了一种信息处理方法，将依据担保信息来进行信 贷支付，相对于现有技术中基于大数据操作的信贷支付，首先，减少了信贷平 台进行数据处理的数据量、避免了信息屏障导致的无法确定信用额度的问题， 同时避免了信息滞后导致无法确定信用额度的问题，提高了所述信贷平台的智 能性，更好的利用了信贷平台。

值得注意的是，在具体实现时，当所述信贷平台接收到第一账户的客户端 发送的信贷请求后，将为此次信贷申请生成信贷申请标识，并将所述信贷申请 标识返给第一账户的客户端。所述信贷申请标识可包括信贷申请序列号，以方 便后续根据该信贷申请标识查询对应的信贷请求。所述信贷平台还依据所述信 贷请求，形成信贷申请状态信息，并存储所述信贷申请标及所述信贷请求。所 述信贷申请状态信息可包括信贷申请金额、信贷申请金额的用途、信贷期限、 信贷还款人以及信贷类型。所述信贷类型的不同，可能信贷需要支付的利息不 同，信贷的未能及时还款的风险不同。

方法实施例二：

如图5所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：信贷平台接收第一账户的客户端发送的信贷请求；所述信贷请 求包括信贷申请金额；

步骤S120：响应所述信贷请求，依据至少一个第二账户为所述第一账户信 贷提供的担保信息，确定所述第一账户的可用信用额度；其中，所述第二账户 为所述第一账户的担保账户；所述第二账户和所述第一账户为不同用户注册在 所述信贷平台的操作账户；

步骤S130：依据所述信贷申请金额和所述可用信用额度，向所述第一账 户进行信贷支付，形成信贷结果；

步骤S140：向所述第一账户的客户端发送所述信贷结果。

所述方法还包括：

步骤S100：获取所述第二账户为所述第一账户信贷提供的担保信息。

若第一账户为新增设的账户，在此之前并没有形成有担保信息，但是第一 账户提出了信贷申请，则此时，可以通过向第一账户的客户端返回提示信息， 以提示用于需要提供担保信息。第一账户的用户可以通过自己社交圈内的好友 发起信贷担保的请求，当第二账户的第二用户同意为第一账户的信贷提供担保 时，可以向所述信贷平台发送所述担保信息，则所述信贷平台则可以通过接收 第二电子设备发送的信贷信息来获取所述担保信息。

此外，所述担保信息还可能已经形成了，但是存储在所述信贷平台以外的 外部设备中，需要从所述外部设备接收所述担保信息。

所述步骤S100可包括：

接收所述第二账户的客户端发送的表示同意为所述第一账户提供担保的认 证信息；

依据所述认证信息，形成所述担保信息。

在具体实现时，当第二账户的客户端接收到所述第一账户的客户端直接发 送或由所述信贷平台转发的请求提供担保的请求消息，直接向所述信贷平台发 送所述认证信息。

所述认证信息可为基于所述第二账户的用户在所述第二账户的客户端的一 键操作形成的。所述一键操作可为：在形成所述认证消息时，所述第二账户的 客户端通过对话框或担保提供页面等形式呈现所述请求消息，用户可通过点击 所述第二账户的客户端上的“同意”等控件或通过语音输入表示“同意”担保 的语音后，所述第二账户的客户端将自行向所述信贷平台发送所述认证信息， 这样就用户操作简单的优点。

在具体的实现过程中，所述第二站户的客户端还可以向所述第一账户的客 户端发送所述认证信息，以使所述第一账户的用户及时的获知当前第二账户的 用户是否提供担保，以再次提供用户使用满意度。

可选方式一：

所述依据所述认证信息，形成所述担保信息，包括：

获取所述第一账户和所述第二账户的关联关系数据；

依据所述关联关系数据和认证信息，形成所述担保信息。

所述依据所述关联关系和认证信息形成担保信息，可包括：

如第二账户本身的信贷额度为a；所述第二账户可为第一账户提供的担保 金额可为a*b；其中，所述b为加权系数；所述加权系数可以依据所述关联关 系数据来确定。通常所述，第一账户和第二账户之间的关联关系越紧密、具体 如通过社交软件交互的越频繁，则所述第二账户替所述第一账户偿还借贷的可 能性越大，此时，所述b的取值可更大。在具体的实现过程中，所述b为不小 于0的正数。

此外，在具体实现时，所述b的取值还可以依据所述第二账户的担保记录 或信用等级等其他因素来综合确定。通常第二账户为其他账户提供担保，也很 好的履行了担保责任，则在这种情况下，所述加权系数b的取值可以更大。

所述依据所述关联关系和认证信息形成担保信息，还可包括：

依据所述关联关系数据确定所述第一账户和所述第二账户是否满足预设关 联条件；当所述第一账户和所述第二账户满足预设关联条件时，依据所述认证 信息形成所述担保信息。

在这种情况下可以减少一些低关联账户的不负责的提供为其他账户提供担 保。

所述第一账户和所述第二账户均为注册在所述信贷平台上的账户，具体的 所述信贷平台可为财富通平台或手机QQ的平台。

为了减少与第一账户没有关联的第二账户为第一账户提供信贷担保或高额 担保，导致信贷担保的风险防控能力的下降的问题；在本实施例中，在形成担 保信息时，需要获取第一账户和第二账户之间的关联关系数据。具体如，获取 第一账户和第二账户基于QQ或等社交软件进行社交活动的频繁度或亲密 度等数据。这些数据可以反映出第一账户和第二账户之间的社交关系是否紧密， 所述第二账户的用户是否会为第一账户在预期不偿还信贷时，进行支付。最后， 根据所述关联关系数据决定是否允许第二账户为第一账户提供担保以及可担保 额额度。

所述确定所述第一账户和所述第二账户是否满足预设关联关系，具体可如： 指定时间内所述第一账户和第二账户的社交频次达到指定频次等。如第一账户 和第二账户最近一年内都有很频繁的通过社交应用进行社交活动，且频繁度超 过指定频次，这是可以将所述第二账户确定为所述第一账户的担保账户，以形 成所述担保信息。

在具体实现时，所述请求提供担保的请求信息，可以与社交软件结合，通 过社交软件的分享功能发送到第二账户的客户端的，以便于所述第二账户的客 户端基于所述请求提供担保的请求信息，形成认证消息。

具体如，所述信平台与社交平台相结合，在为各个账户的客户端提供信贷 服务的同时，还提供社交服务；进一步的所述信贷服务可以是基于所述社交服 务的。如第一账户的用户端基于用户指示，形成所述请求提供担保的请求信息， 并分享到好友圈，这样就若干个第二账户的客户端会接收到所述请求提供 担保的请求信息，第二账户的客户端基于用户指示对分享的所述请求信息进行 操作，将形成认证信息发送到所述信贷平台。由于所述信贷平台同时还提供社 交服务，从而可以简便的从其对应的数据库中查询到所述第一账户和第二账户 之间的关联关系数据。在具体的实现过程中，所述关联关系数据还可以是有第 一账户的客户端或所述第二账户的客户端向所述信贷平台提交的数据。

在具体的实现过程中，还可以根据所述第一账户和所述第二账户的社交关 系的稳定性、亲密度和/或频繁度等关联关系数据，确定所述第二账户为第一账 户提供的可担保额度。

依据认证信息形成担保信息的方式有多种，以下提供几种具体如何形成所 述担保信息的可选方式：

可选方式二：

所述依据所述认证信息，形成所述担保信息，还包括：

审核所述认证信息，确定所述第二账户的可担保额度；

依据所述第二账户的可担保额度，确定实际担保额度；接收所述第二账户 的客户端发送的表示同意为所述第一账户提供担保的认证信息；

审核所述认证信息，确定所述第二账户的可担保额度；

依据所述第二账户的可担保额度，确定实际担保额度；

形成包括实际担保额度及所述第二账户的账户信息的所述担保信息；

所述步骤S120可包括：依据所述实际担保额度，确定所述第一账户的信用 额度。

所述认证信息可仅为表示第二账户同意为第一账户提供信贷担保的担保同 一信息，根据信贷担保的风控规则，在无需确定第二账户可为第一账户提供担 保金额等情况下，也可以直接根据所述认证信息形成担保信息。

同样的，所述认证信息中可包括被担保的账户的标识信息，如所述第一账 户；提供担保的账户如第二账户的标识信息。所述认证信息还可包括第二账户 愿意提供的担保金额等信息。

此外，所述审核所述认证信息，确定所述第二账户的可担保额度，还可包 括：

获取所述第二账户的经济状况的依据信息、历史担保记录、第二账户的信 贷额度及第二账户与第一账户的关联关系的至少其中之一；

在依据上述获取的信息，确定所述第二账户的可担保额度。

具体如何获取可以由所述信贷平台通过查询第二账户在信贷平台上，形成 的信贷记录以及注册在所述信贷平台上的信息来获得，也可以是所述信贷平台 从其他平台获取，还可以是所述由第二账户的客户端提交，获取上述信息的方 法很多，在此就不再一一赘述了。

信贷平台接收到第二账户的客户端发送的所述认证信息之后，可对第二账 户进行审核，具体如审核第二账户的偿还能力信息、审核第二账户的信用状况 信息等信息，以确定所述第二账户的可担保额度。

具体如，第二账户的偿还能力信息可包括第二账户的每月可偿还金额。假 设第二账户每月可偿还金额为3万，第二账户当前自己需要自己申请信贷1万 元，则第二账户此时剩余的可偿还金额为2万。若当前第二账户在向信贷平台 提交的认证信息确认愿意为第一账户信贷提供3万的信贷担保；信贷平台依据 所述认证信息以及第二账户的偿还能力信息、第二账户与第一账户的关联关系 数据表征的第一账户和第二账户的亲密度、第二账户的担保记录等参数，综合 确定出加权系数为0.5，再将所述加权系数与剩余的可偿还金额2万做乘积计 算，确定第二账户的可担保额度仅为1万；则第二账户可提供的实际担保额度 为1万，而非3万。

若当前第二账户向信贷平台提交的认证信息表明：愿意为第一账户信贷提 供0.5万的信贷担保，显然第二账户的愿意提供担保的金额小于第二账户的可 偿还金额，尊重第二账户的用户意愿，在确定实际担保额度时，则确定所述实 际担保额度为0.5万。

此处的所述愿意提供担保的金额可称为：担保金额；所述依据所述第二账 户的可担保额度，确定实际担保额度，包括：依据所述担保金额及所述可担保 额度，确定所述实际担保额度；其中，所述实际担保额度不高于所述可担保额 度，且不高于所述担保金额。

在具体实现时，所述信贷平台在确定所述可担保额度以后，还可形成可担 保额度信息，分别向第一账户的客户端和第二账户的客户端发送所述可担保额 度信息，以使用户执行当前信贷平台确定的可担保额度。

在所述可选方式二中，确定所述可担保额度的方法有多种，不局限于上述 方法。

图6所示的信息处理方法是基于本实施例所述的信息处理方法的一个具体 应用示例；所述信息处理方法可包括：

步骤S101：第一账户的第一客户端向信贷平台发送包括信贷申请金额的信 贷请求。

步骤S102：信贷平台依据所述信贷请求确定是否有担保信息或当前担保信 息对应的可用信贷额度是否不小于信贷申请金额，当所述信贷平台的确定结果 表明，第一账户还未有担保信息或当前担保信息对应的可用信贷额度小于信贷 申请金额则进入步骤S103。所述可用信贷额度可理解为剩余信贷额度，具体如 担保信息可以提供10万的担保额度，但是第一账户已经借贷了3万，则当前的 可用信贷额度为7万。

步骤S103：信贷平台可向第一客户端发送提供担保提示。

步骤S104：第一客户端可以向第二账户的第二客户端发送请求第二账户提 供担保的请求信息。

步骤S105：第二客户端基于所述请求信息和第二账户的用户指示，向信贷 平台发送认证信息。

步骤S106：信贷平台审核认证信息，确定实际担保额度，以形成所述担保 信息。

显然本发明实施例提供了一种具体如何获取所述担保信息的方法，具有实 现简便的优点。当一个新开设的第一账户需要快速申请贷款时，可以通过有第 二账户的用户提供担保，快速的享用到信用贷款，显然信道效率更高，信贷平 台的智能性也更高了。

值得注意的是，在具体实现时，所述信贷平台可以在未接收到第一客户端 发送的信贷请求的情况下，也可以向发送所述提供担保提示，具体如信贷平台 发现第一账户没有形成有担保信息时。所述信贷平台也可能在没有接收到信贷 请求时，也会接收到第二账户为第一账户提供担保的认证信息。上述步骤S101 至步骤S106的执行顺序不限于上述顺序。

在具体实现时，所述认证信息包括确认第二账户的经济状况的依据信息；

所述审核所述认证信息，确定所述第二账户提供的担保额度还可包括：

依据所述依据信息，确定所述第二账户的可担保金额。

所述依据信息可包括第二账户的用户的存款信息、第二账户的用户的工资 信息、第二账户的消费记录信息或第二账户的固定资产证明或其他能够表明所 述第二账户的还款能力的信息。通常情况下，显然所述经济状况信息越好，则 可能提供的可担保额度就越高。

形成担保信息时，在确定所述第二账户的偿还能力信息，还需要考虑第二 账户的信用状况信息。若第二账户的信用状况信息表明第二账户的信用状况不 好，经常拖欠信贷款项；显然这样会不利于信贷平台从第二账户获取到担保还 款。有鉴于此，本实施例所述审核所述认证信息，确定所述第二账户提供的担 保额度，可包括：

查询所述第二账户的信用等级信息；

依据所述担保信用等级信息，确定所述可担保额度。

通常所述信用等级信息表明所述第二账户的信用等级越高，就表明第二账 户的及时偿还的状况更好，则可以适当给与较高的信贷额度。

具体如可以将信用等级信息分为M个等级。M个等级对应不同的信贷发放 权重，若一个账户的偿还能力信息表明可以每一个偿还周期内偿还N元款。所 述M可为不小于2的整数；所述N为大于1的数。

若第二账户的信贷等级信息表明第二账户的信用非常好，其为信用良好特 级用户，则可以溢额发放信贷金额，此时，可担保额度可等于a*N元，所述a 可为大于1的数。

当第二账户的信用等级信息表明第二账户的信用好，很少出现拖欠，若出 现拖欠也能及时还款，此时可以为良好用户，此时，所述a可以为1。

当第二账户的信用等级信息表明第二账户的信用状况差，则此时，所述a 可以取小于1的数。

综合上述方案，以下提供一个具体示例。假设第一账户申请的信贷申请金 额30000元，提交信贷申信息后，信贷平台通过信息查询等方式确定第一账户 的信贷额度为10000元，信贷平台向第一账户的客户端发送贷款申请的审批结 果到第一账户，以通过第一账户的客户端告知第一账户的用户当前其信贷额度 不足。第一账户的用户通过客户端上安装的社交软件或基于通信软件邀请第二 账户为其提供信贷担保。第二账户的客户端收到第一账户请求提供信贷担保的 信息邀请后，通过点击第二账户的客户端上的确定按钮“同意”等操作指示客 户端，向信贷平台发送同一为本笔贷款提供担保的认证信息。信贷平台在接收 到所述认证信息后，根据第二账户的账号查询第二账户得到信用额度为50000 员，再根据第二账户与第一账户的社交关系、历史担保记录、信用记录等信息 得到第二账户为第一账户担保的加权系数为ɑ，则当前第一账户的可用的贷款 额度为10000+50000*ɑ，若10000+50000*ɑ>30000，则第一账户的此时的信贷 申请将被信贷平台审核通过。如果存在多个担保人，ɑ的取值可能还与其他担 保人的个数及信用级别等因素相关。

以下为依据第二账户为第一账户提供担保的认证信息，确定担保信息中的 信贷额度的一种可选方式：

假设第i个担保账户的可担保额度为Mi，加权系数为ai，若满足 $10000+\underset{i=1}{\overset{I}{\Sigma }}(\mathrm{Mi}*\mathrm{ai})>30000,$ 其中I为担保账户的总个数。

在具体实现时，可以将方法一和方法二结合使用，不局限于单独使用。

所述步骤S100还包括：

接收所述第二账户的客户端发送的第一账户申请信贷的查询请求；

响应所述查询请求向所述第二账户的客户端发送第一账户的信贷申请状况 信息；

其中，所述信贷申请状况信息为形成所述认证信息提供依据。

如方法实施例一所述的，当信贷平台接收到第一账户的客户端发送的信贷 请求之后，可能会形成相应的信贷申请标记。第一账户的客户端在请求第二账 户为其提供信贷担保时，可以将所述信贷申请标记发送给所述第二账户的客户 端，这样可以方便后续依据所述信贷申请标记到信贷平台查询第一账户需要提 供担保的这次信贷的信贷申请状况信息。

所述第二账户的客户端接收的所述信贷申请状况，可能包括此次信贷若逾 期不还可能造成的结果以及第二账户的担保风险信息等状况信息。

第二账户的用户在接收到所述信贷申请状况信息之后，将依据自己的偿还 能力对第一账户的用户偿还能力以及信用状况等信息进行综合评价，确定是否 为其提供担保，若为第一账户的信贷申请提供担保，则通过所述第一账户的客 户端形成所述认证信息发送给所述信贷平台。

在具体实现时，上述查询请求可以不局限于用于形成所述认证信息，也可 以是在第一账户提供信贷担保之后，方便第一账户的客户端来查看。

方法实施例三：

如图1所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：信贷平台接收第一账户的客户端发送的信贷请求；所述信贷请 求包括信贷申请金额；

步骤S120：响应所述信贷请求，依据至少一个第二账户为所述第一账户信 贷提供的担保信息，确定所述第一账户的可用信用额度；其中，所述第二账户 为所述第一账户的担保账户；所述第二账户和所述第一账户为不同用户注册在 所述信贷平台的操作账户；

步骤S130：依据所述信贷申请金额和所述可用信用额度，向所述第一账 户进行信贷支付，形成信贷结果；

步骤S140：向所述第一账户的客户端发送所述信贷结果；

步骤S150：依据所述信贷结果，形成并向所述第二账户的客户端发送信贷 担保反馈信息；

步骤S100：获取所述第二账户为所述第一账户信贷提供的担保信息。其中， 所述步骤S100通常位于所述步骤S120之前。

所述步骤S100可包括：

接收所述第二账户的客户端发送的表示同意为所述第一账户提供担保的认 证信息；

审核所述认证信息，确定所述第二账户的可担保额度；

依据所述第二账户的可担保额度，确定实际担保额度；

形成包括实际担保额度及所述第二账户的账户信息的所述担保信息；

所述步骤S130可包括：依据所述实际担保额度，确定所述第一账户的信用 额度。

所述方法还包括：

依据所述担保信息，形成担保生效信息；

分别向所述第一账户和所述第二账户的客户端发送所述担保生效信息。

通常所述担保生效信息可包括实际担保额度信息，通过向第一账户和第二 账户的客户端发送所述担保生效信息，以告知第一账户和第二账户的用户目前 担保的状况。在具体的实现过程中，所述担保生效信息为所述第二账户为第一 账户提供信贷担保成功的时候发送，在所述第二账户为所述第一账户提供担保 失败时，所述信贷平台还可以向第一账户和第二账户的客户端发送担保失败信 息。

发送给第一账户和第二账户的客户端的所述担保生效信息可以完全相同， 也可以有部分不同。具体如发送给第二账户的担保生效信息，除了实际担保金 额，还可以包括担保风险信息，还可包括第二账户目前还可提供的担保的额度 等信息。

如图7所示，所述信息处理方法可包括：

步骤S201：账户B的客户端向信贷平台发送认证信息，所述认证信息为表 示账户B愿意为账户A提供信贷担保。所述账户A即为上述第一账户；所述 账户B即为所述第二账户。

步骤S202：信贷平台审核担保信息，具体的审核过程可以参见方法实施例 二任意技术方案，确定担保成功，则形成担保信息和担保生效信息。在具体实 现时，所述信贷平台还将存储所述担保信息。

步骤S203：信贷平台将所述担保生效信息发送给客户端A和客户端B。

在图7中客户端A和客户端B内显示的内容为分别发送给客户端的担保生 效信息。

如图8所示，所述信息处理方法可包括：

步骤S301：账户B的客户端向信贷平台发送认证信息，所述认证信息为表 示账户B愿意为账户A提供信贷担保。所述账户A即为上述第一账户；所述 账户B即为所述第二账户。

步骤S302：信贷平台通过审核认证确定担保失败，则形成担保失败信息。

步骤S303：向客户端A和客户端B分别发送所述担保失败信息。

所述担保失败信息可仅为担保失败结果，还可以包括担保失败的原因。具 体如图8的客户端A和客户端B显示的担保失败信息中还包括担保失败原因。

方法实施例四：

如图4所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：信贷平台接收第一账户的客户端发送的信贷请求；所述信贷请 求包括信贷申请金额；

步骤S120：响应所述信贷请求，依据至少一个第二账户为所述第一账户信 贷提供的担保信息，确定所述第一账户的可用信用额度；其中，所述第二账户 为所述第一账户的担保账户；所述第二账户和所述第一账户为不同用户注册在 所述信贷平台的操作账户；

步骤S130：依据所述信贷申请金额和所述可用信用额度，向所述第一账 户进行信贷支付，形成信贷结果；

步骤S140：向所述第一账户的客户端发送所述信贷结果。

具体实现时，所述方法还可包括步骤S150；所述步骤S150步骤S150：依 据所述信贷结果，形成并向所述第二账户的客户端发送信贷担保反馈信息。

在具体实现时，用户基于所述客户端向信贷平台申请的信贷申请金额，可 能高于当前第一账户的可用信用额度，也可能低于第一账户的可用信贷额度； 有鉴于此，所述步骤S140可包括以下两种实现方式的至少其中之一。

方式一：所述步骤S140可包：

比较所述信贷申请金额与所述可用信用额度；

当所述信贷申请金额不高于所述可用信用额度时，向所述第一账户支付等 于所述信贷申请金额的实际信贷金额；

依据所述实际信贷金额，形成信贷结果。

方式二：所述步骤S140可包括：

当所述信贷申请金额高于所述可用信用额度时，向所述第一账户的客户端 发送部分信贷提示信息；所述部分信贷提示信息包括可信贷金额；

接收所述第一账户的客户端基于所述部分信贷提示信息返回的部分信贷反 馈信息；

当所述部分信贷反馈信息表明同意部分信贷时，向所述第一账户进行信贷 支付，形成信贷结果。

当信贷申请金额不高于所述可用信用额度时，直接向所述第一账户支付等 于所述信贷申请金额的贷款，但是在信贷申请金额高于所述可用信用额度时， 通过向第一账户的客户端发送部分信贷提示信息，可以起到告知用户当期的可 用信贷额度不够，是否接收部分信贷。具体如用于申请信贷10万，但是累积当 前第一账户的担保信息及资产证明等信息，仅能提供8万的可用信贷金额，则 此时可通过所述部分信贷提示信息，告知用户的信贷申请状况并请求是否同意 先申请8万信贷的贷款，当用户同意部分信贷时，这样更好的利用信贷这个平 台，发放更多的信贷，促进资金的流动。

在具体实现时，所述信贷平台也可以在信贷申请金额高于所述可用信用额 度时，直接形成此次信贷申请失败的信息，将所述信贷申请失败的信息返回给 第一账户的客户端即可。同时还可以将可用信贷金额发送给第一账户的客户端， 方便用户查阅后，形成下一次信贷申请。

方法实施例四：

如图1所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：信贷平台接收第一账户的客户端发送的信贷请求；所述信贷请 求包括信贷申请金额；

步骤S120：响应所述信贷请求，依据至少一个第二账户为所述第一账户信 贷提供的担保信息，确定所述第一账户的可用信用额度；其中，所述第二账户 为所述第一账户的担保账户；所述第二账户和所述第一账户为不同用户注册在 所述信贷平台的操作账户；

步骤S130：依据所述信贷申请金额和所述可用信用额度，向所述第一账 户进行信贷支付，形成信贷结果；

步骤S140：向所述第一账户的客户端发送所述信贷结果。

所述方法还包括：

当所述第一账户在信贷还款日未偿还信贷时，形成偿还提示信息；

向所述第一账户和所述第二账户的客户端发送所述偿还提示信息。

本实施例中进一步在第一账户为如约偿还信贷时，形成偿还提示信息，这 个偿还提示信息不仅发送到第一账户的客户端，还同时发送到第二账户的客户 端；一方面提示第一账户的用户注意应该及时还款，以免支付多余的利息和罚 金和形成不良的信用记录；另一方面发送给第二账户的客户端，可以提醒第二 账户可能需要履行担保支付，并促使第二账户的用户注意提醒第一账户的用户 注意还款，这样能够保证信贷平台的资金尽可能按照正常流动，尽可能少的出 现呆账和坏账，从而信贷平台具有智能性高的优点。

此外，所述方法还包括：

当满足担保偿还条件时，向所述第二账户发送偿还请求或自动控制所述第 二账户进行偿还。

所述担保偿还条件，具体如第一账户的信贷金额逾期不还已经超过指定时 限，此时需要由第二账户进行信贷偿还，此时可以向第二账户发送偿还请求。 当所述第二账户内有可用资金时，还可基于所述第二账户与信贷平台之间签订 的自动支付协定，控制所述第二账户进行自动偿还。

在具体实现过程中，若所述第二账户基于所述偿还请求，替第一账户进行 信贷支付，则所述信贷平台还将生成信贷担保支付信息，发送到第一账户和第 二账户的客户端，方便后续第二账户的用户向所述第一账户的用户索要信贷担 保支付金额。

以下结合上述任意实施例提供一个具体应用示例：

如图9所示，所述示例包括：

步骤1：第一账户A的用户A登录客户端A并进入申请贷款界面。通常客 户端上都会安装可于所述信贷平台进行信息交互的应用，具体如信贷APP。

步骤2：客户端A向信贷平台发送信贷请求。所述信贷请求可包括信贷申 请金额M、第一账户的用户登录态标识skey、接收贷款的银行卡号C等信息发 送给信贷平台。

步骤3：信贷平台根据skey等信息及风控规则确定可用信用额度M'。其中， 所述风控规则为预先存储在所述信贷平台中用于信贷额度的参数之一，所述可 用信贷额度可为依据账户的总信贷额度与已用信贷额度的差来确定。

步骤4：如果M'>M，则直接向用户的银行卡号为C的银行卡放款；否则 向所述客户端A发送信贷申请标识信息token_id以及贷款申请失败原因等信 息。

步骤5：客户端A收到信贷申请标识信息token_id以及贷款申请失败原因 后，显示展示贷款结果。

步骤6：如果贷款申请失败原因为额度不足，用户A可以将邀请好友提供 信贷担保。邀请的过程可是将token_id及其他必要信息发送给自己的某个或多 个社交关系中的好友。

步骤:7：用户A的用户F在客户端B收到客户端的提供信贷担保的请求后， 携带token_id及用户F的第二账户的登录态skey'向信贷平台发送查询请求。

步骤8：客户端B接收信贷平台返回的包括用户A的贷款申请状况信息等 信贷申请详情。

步骤9：用户F若同意提供担保，则通过客户端A向信贷平台发送认证信 息，所述认证信息携带有所述token_id及用户F的第二账户的登录态skey'、担 保使用的银行卡号C'(可选)等信息向后台发同意担保的请求。

步骤10：信贷平台根据skey'查询该用户F的信用额度等信息，计算出用户 F提供担保后对token_id标识的贷款请求的授信额度M″。

步骤11：如果M″>M,后台则向贷款申请人A及所有为token_id这笔请求 提供担保的账户广播借贷成功的结果；否则可只向F发送担保生效的信息。

如果出现用户逾期未还款的情况，向用户F及所有为token_id这笔请求提 供担保的用户广播当前这笔贷款的状态。如果涉及需要担保人承担担保责任， 比如扣除信用额度，从担保时使用的银行卡扣款，则后台直接向用户A或者用 户F推送具体的提醒信息。

设备实施例一：

如图10所示，本实施例提供一种信贷平台，所述信贷平台包括：

接收单元110，用于接收第一账户的客户端发送的信贷请求；所述信贷请 求包括信贷请求以及信贷申请金额；

响应单元120，用于响应所述信贷请求，依据至少一个第二账户为所述第 一账户信贷提供的担保信息，确定所述第一账户的可用信用额度；其中，所述 第二账户为所述第一账户的担保账户；所述第二账户和所述第一账户为不同用 户注册在所述信贷平台的操作账户；

支付单元130，用于依据所述信贷申请金额和所述可用信用额度，向所述 第一账户进行信贷支付，形成信贷结果；

发送单元140，用于向所述第一账户的客户端发送所述信贷结果。

所述接收单元110和发送单元140的具体结构可包括通信接口，所述通信 接口可包括有线接口或无线接口；所述有线接口可包括电缆接口或光缆接口； 所述无线接口可包括收发天线等。所述接收单元110和所述发送单元140可对 应不同的通信接口，也可以集成对应于同一接口。

所述响应单元120支付单元130可包括具有信息处理功能的处理器及存储 介质，所述存储介质内可存储有计算机可执行指令，所述处理器通过设备内部 的总线等结构与所述存储介质相连。所述处理器读取并运行所述可执行指令， 则可以实现所述响应单元和所述支付单元的功能。所述响应单元120和支付单 元130可以对应于同一个处理器，也可以对应不同的处理器。当所述响应单元 120和所述支付单元130集成对应于同一处理器时，所述处理器可以采用时分 处理或并发线程等方式来实现所述信贷申请的响应和信贷支付。

所述处理器可为应用处理器AP、中央处理器CPU、数字信号处理器DSP、 微处理器MCU或可编程阵列PLC等具有信息处理功能的电子元器件或电子元 器件的组合。

本实施例所述的信贷平台，还可以如图2或图3所示的结构，是有多个网 络设备连接而成的设备平台，具体如包括信贷服务器、数据库以及信贷网关等 结构。

在具体实现时，所述信贷平台也可以仅包括信贷服务器。各种因信贷产生 的数据均可以直接存储在信贷服务器内部的存储介质上。所述信贷服务器也通 过其自身携带的通信接口，绕过所述信贷网关直接与客户端相连。

所述客户端可为手机或各种类型的电脑等用户终端设备。

作为本实施例的进一步改进，所述发送单元140，还用于当所述信贷结果 表明所述信贷平台已向所述第一账户提供信贷时，形成并向所述第二账户的客 户端发送信贷担保反馈信息。

总之本实施例提供一种信贷平台用于方法实施例中的信息处理方法，以提 高信贷平台的智能性，能够满足更多用户的信贷需求，减少信贷平台在进行信 贷时的数据处理量，提高信贷平台信贷时的处理效率。

设备实施例一：

如图10所示，本实施例提供一种信贷平台，所述信贷平台包括：

接收单元110，用于接收第一账户的客户端发送的信贷请求；所述信贷请 求包括信贷请求以及信贷申请金额；

响应单元120，用于响应所述信贷请求，依据至少一个第二账户为所述第 一账户信贷提供的担保信息，确定所述第一账户的可用信用额度；其中，所述 第二账户为所述第一账户的担保账户；所述第二账户和所述第一账户为不同用 户注册在所述信贷平台的操作账户；

支付单元130，用于依据所述信贷申请金额和所述可用信用额度，向所述 第一账户进行信贷支付，形成信贷结果；

发送单元140，用于向所述第一账户的客户端发送所述信贷结果。

所述信贷平台还包括：

获取单元，用于获取所述第二账户为所述第一账户信贷提供的担保信息。

所述获取单元具体同样可包括通信接口，可以通过从外设上接收所述担保 信息，具体如从客户端接收所述的担保信息。

所述获取单元的具体结构可包括多种，以下提供几种可选方式：

方式一：

所述获取单元可包括：

接收模块，用于接收所述第二账户的客户端发送的表示同意为所述第一账 户提供担保的认证信息；

形成模块，用于依据所述认证信息，形成所述担保信息。

所述接收模块可为通信接口，所述形成模块可包括具有信息处理功能的处 理器。

方式二：

基于方式一，所述获取单元还包括：

获取模块，用于获取所述第一账户和所述第二账户的关联关系数据；

所述形成模块，具体用于依据所述认证信息及所述关联关系数据形成所述 担保信息。

所述获取模块同样可为通信接口，通过接收客户端或外设发送的关联关系 数据，也可以是处理器，通过查询第一账户和第二账户的社交关系数据库来获 取所述关联关系数据。

方式三，基于方式一，如图11所示，所述获取单元，包括：

接收模块101，用于接收所述第二账户的客户端发送的表示同意为所述第 一账户提供担保的认证信息；

审核模块102，用于审核所述认证信息，确定所述第二账户的可担保额度；

确定模块103，用于依据所述第二账户的可担保额度，确定实际担保额度；

所述形成模块104，用于形成包括实际担保额度及所述第二账户的账户信 息的所述担保信息；

所述响应单元120，具体用于依据所述实际担保额度，确定所述第一账户 的信用额度。

所述接收模块可包括通信接口，可以与所述接收单元集成对应于物理设备 的同一通信接口。

所述审核模块102、确定模块103和形成模块104均可独立或集成对应处 理器。

本实施例所述的担保信息是基于客户端发送的认证信息由所述信贷平台自 行生成的。

在具体实现过程中，所述信贷平台内可预先存储有生成所述担保信息的生 成策略等，在接收到所述认证信息之后，可以根据所述认证信息转换成对应的 担保信息并保存。

进一步地，

所述审核模块102，还可用于获取所述第二账户的经济状况的依据信息、 历史担保记录、第二账户的信贷额度及第二账户与第一账户的关联关系的至少 其中之一；并依据所述依据信息、所述历史担保记录、所述第二账户的信贷额 度及所述第二账户与第一账户的关联关系的至少其中之一，确定所述第二账户 的可担保金额。

所述审核模块102，还用于查询所述第二账户的信用等级信息；及依据所 述担保信用等级信息，确定所述可担保额度。

在本实施例中的所述信贷平台将根据所述第二账户的经济状况的依据信 息、信用等级信息以及认证信息三者来确定所述担保信息，这样能够全面的评 估第二账户的偿还能力。在具体实现时，对所述第二账户的偿还能力的评估可 以在第二账户自行申请信贷时就有形成对应的审核结果，或者所述第二账户为 所述第一账户以外的其他账户提供信贷担保时，就有形成对应的审核结果。为 了方便加速处理，本实施例所述的信贷平台可以依据在次之前对第二账户的经 济状况以及信用等级信息的审核处理形成的审核结果，加速审核的过程，以快 速形成所述担保信息。

此外，所述认证信息还包括担保金额；

所述确定模块103，具体用于依据所述担保金额及所述可担保额度，确定 所述实际担保额度；

其中，所述实际担保额度不高于所述可担保额度，且不高于所述担保金额。

综合上述，本实施例所述的信贷平台可用于为方法实施例二所述的信息处 理方法提供实现硬件，同样的具有信贷平台对信贷申请的处理效率高，响应时 间延迟小，能够为更多的有偿还能力的用户方法信贷的优点。

设备实施例三：

如图10所示，本实施例提供一种信贷平台，所述信贷平台包括：

接收单元110，用于接收第一账户的客户端发送的信贷请求；所述信贷请 求包括信贷请求以及信贷申请金额；

响应单元120，用于响应所述信贷请求，依据至少一个第二账户为所述第 一账户信贷提供的担保信息，确定所述第一账户的可用信用额度；其中，所述 第二账户为所述第一账户的担保账户；所述第二账户和所述第一账户为不同用 户注册在所述信贷平台的操作账户；

支付单元130，用于依据所述信贷申请金额和所述可用信用额度，向所述 第一账户进行信贷支付，形成信贷结果；

发送单元140，用于向所述第一账户的客户端发送所述信贷结果；

所述发送单元140，还用于当所述信贷结果表明所述信贷平台已向所述第 一账户提供信贷时，形成并向所述第二账户的客户端发送信贷担保反馈信息。

所述信贷平台还包括：

形成单元，用于依据所述担保信息，形成担保生效信息；

所述发送单元140，还用于分别向所述第一账户和所述第二账户的客户端 发送所述担保生效信息。

当第二账户同意为第一账户提供单元，且信贷平台通过审核评估确定所述 第二账户可提供担保时，这是为了方便第一账户和第二账户的用户知悉担保是 否成功等信息，还将在形成担保信息之后，形成担保生效信息，并发送到对应 的客户端。

在具体的实现过程中，所述信贷平台还用于基于第二账户的认证信息确定 第二账户不可以提供担保时，不形成所述担保信息，直接向第一账户和第二账 户发送担保失败的信息。具体的如第二账户自身就有很多逾期待还信贷款，也 没有更多的资产用于形成资产担保，此时，所述第二账户就难以成为所述第一 账户的担保账户，形成有效的担保，故所述信贷平台还可以用于拒绝所述第二 账户的担保，形成所述担保失败的信息，以告知第一账户和第二账户的用户担 保失败。

进一步地，所述接收单元110还用于接收所述第二账户的客户端发送的第 一账户申请信贷的查询请求；

所述发送单元140，还用于响应所述查询请求向所述第二账户的客户端发 送第一账户的信贷申请状况信息。

第二账户的用户在接收的第一账户的客户端的请求提供信贷担保的信息 后，对是否提供担保需要了解第一账户的信贷申请的详细信息，故在本实施例 中所述接收单元110还将接收所述查询请求，所述发送单元还将响应所述查询 请求向所述第二账户的客户端发送所述信贷申请状况信息。这能就能方便第二 账户的用户根据所述信贷申请状况信息，形成对应的认证信息。

设备实施例四：

如图10所示，本实施例提供一种信贷平台，所述信贷平台包括：

接收单元110，用于接收第一账户的客户端发送的信贷请求；所述信贷请 求包括信贷请求以及信贷申请金额；

响应单元120，用于响应所述信贷请求，依据至少一个第二账户为所述第 一账户信贷提供的担保信息，确定所述第一账户的可用信用额度；其中，所述 第二账户为所述第一账户的担保账户；所述第二账户和所述第一账户为不同用 户注册在所述信贷平台的操作账户；

支付单元130，用于依据所述信贷申请金额和所述可用信用额度，向所述 第一账户进行信贷支付，形成信贷结果；

发送单元140，用于向所述第一账户的客户端发送所述信贷结果；

所述发送单元140，还用于当所述信贷结果表明所述信贷平台已向所述第 一账户提供信贷时，形成并向所述第二账户的客户端发送信贷担保反馈信息。

所述可信贷额度可能比所述信贷申请金额高，也可能比所述信贷申请金额 低，有鉴于此，所述支付单元120对应有两种处理方式。

第一种：

所述支付单元120，具体用于比较所述信贷申请金额与所述可用信用额度； 当所述信贷申请金额不高于所述可用信用额度时，向所述第一账户支付等于所 述信贷申请金额的实际信贷金额；及依据所述实际信贷金额，形成信贷结果。

第二种：

所述支付单元120，还用于当所述信贷申请金额高于所述可用信用额度时， 向所述第一账户的客户端发送部分信贷提示信息；所述部分信贷提示信息包括 可信贷金额；接收所述第一账户的客户端基于所述部分信贷提示信息返回的部 分信贷反馈信息；及当所述部分信贷反馈信息表明同意部分信贷时，向所述第 一账户进行信贷支付，形成信贷结果。

所述支付单元120在进行支付时，具体可用于控制一个银行卡向另一银行 卡进行支付，也可以控制一个支付账户向另一个支付账户进行支付。所述支付 账户可包括财富通账户、百度钱包或支付宝等网络支付账户。显然在支付时， 所述支付单元120也可以控制银行卡向支付账户进行支付，还可以时控制支付 账户向银行卡进行支付。

本实施例提供了的信贷平台，所述信贷平台将根据可用信贷金额和信贷申 请金额做出不同的支付响应，具有智能性高及用户使用满意度高的优点。

设备实施例五：

如图10所示，本实施例提供一种信贷平台，所述信贷平台包括：

接收单元110，用于接收第一账户的客户端发送的信贷请求；所述信贷请 求包括信贷请求以及信贷申请金额；

响应单元120，用于响应所述信贷请求，依据至少一个第二账户为所述第 一账户信贷提供的担保信息，确定所述第一账户的可用信用额度；其中，所述 第二账户为所述第一账户的担保账户；所述第二账户和所述第一账户为不同用 户注册在所述信贷平台的操作账户；

支付单元130，用于依据所述信贷申请金额和所述可用信用额度，向所述 第一账户进行信贷支付，形成信贷结果；

发送单元140，用于向所述第一账户的客户端发送所述信贷结果；

所述发送单元140，还用于当所述信贷结果表明所述信贷平台已向所述第 一账户提供信贷时，形成并向所述第二账户的客户端发送信贷担保反馈信息。

所述信贷平台还包括形成单元；

所述形成单元，用于当所述第一账户在信贷还款日未偿还信贷时，形成偿 还提示信息；

所述发送单元140，还用于向所述第一账户和所述第二账户的客户端发送 所述偿还提示信息。

所述形成单元可包括具有任意一种具有信息处理功能电子元器件，具体如 上述设备实施例中所述的处理器。

作为本实施例的进一步改进，所述发送单元240，还用于当满足担保偿还 条件时，向所述第二账户发送偿还请求。

本实施例通过所述偿还提示信息的生成，可以督促第一账户和第二账户的 用户及时还贷，以保证信贷平台的信贷资金正常回流，促进资金的良好循环。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法， 可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如， 所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分 方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特 征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、 或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通 信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作 为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方， 也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部 单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理模块 中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集 成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用 硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤 可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读 取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述 的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、 随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种 可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限 于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易 想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护 范围应以所述权利要求的保护范围为准。