订单信息处理以及订单类型转换处理方法及装置与流程

本申请涉及订单信息处理技术领域，特别是涉及订单信息处理以及订单类型转换处理方法及装置。

背景技术：

随着电子商务交易平台以及在线支付业务不断扩大，线下到线下(o2o)市场的重要性逐渐凸显出来，而“衣食住行”中“住”作为其中非常重要的组成部分，人们对于旅游服务品质的追求也上升到了全新的高度。在此背景下，未来的酒店业将需要在技术设备、营销模式、经营效率及服务理念等方面升级到新的高度，才能满足消费者预期，提升行业竞争力。

现有技术中，一些电商平台能够提供“在线订房线下入住”的服务，在线预订酒店时，如果指定了入住日期，并且要求酒店为其保留房间，则用户通常需要支付一定的保证金，如果用户不按时入住，则保证金不予退还，以免造成酒店的经济损失。而如果用户按时入住，则在用户离店时，将保证金退还给用户。

以上这种传统的担保方式具有一些弊端，首先，需要用户提前支付保证金，会对用户的资金造成占用；其次，通常需要将用户的支付账户信息提供给酒店，其中，对于一些国内酒店，能够支持的支付途径比较多，可以包括银行卡、支付宝等、其他第三方支付工具等，而一些国际的酒店，通常只能支持银行卡支付，但无论采用何种支付方式，都存在将用户的账户信息提供给酒店的情况，因此，在支付的过程中存在安全隐患；再者，操作流程相对复杂，效率比较低，在用户按时入住的情况下，还需要执行逆向流程，将保证金退还到用户的账户，对于网络资源等也会造成一定程度的浪费，并且逆向流程一般无法实时到账，用户资金占用时间更长，另外，通常还需要通过支付工具交易明细查询资金到账情况，体验非常差。

技术实现要素：

本申请提供了订单信息处理以及订单类型转换处理方法及装置，能够提高用户信息安全性，提高效率，节省网络资源。

本申请提供了如下方案：

一种订单信息处理方法，包括：

服务器接收客户端针对指定第一用户的目标数据对象创建担保订单的请求；

判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件；

如果满足，则创建订单，并添加信用标识符，并将所述信用担保订单提供给所述第一用户数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。

一种订单信息处理方法，包括：

第一用户数据处理系统接收服务器提供的信用担保订单，所述信用担保订单通过以下方式生成：所述服务器在接收到客户端针对目标数据对象创建担保订单的请求时，判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则创建订单，并添加信用标识符；

如果第二用户未能按时履约，则向所述服务器提交订单状态信息，所述状态信息为第二用户未按时履约，以便服务器从所述第二用户关联的支付账户划拨预置金额到所述第一用户的收款账户。

一种订单类型转换处理方法，包括：

服务器记录业务订单的相关信息，所述相关信息包括所述业务订单关联的第一用户以及第二用户信息，所述业务订单为非担保订单；

接收将指定非担保订单转换为担保订单的请求；

判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件；

如果满足，则将所述指定非担保订单转换为信用担保订单，并将转换结果提供给第一用户数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。

一种订单类型转换处理方法，包括：

第一用户数据处理系统向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；

接收服务器返回的转换结果，以便按照信用担保的方式为所述第二用户提供线下资源预留服务。

一种订单类型转换处理方法，包括：

第二用户客户端向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；

接收服务器返回的转换结果。

一种订单信息处理装置，应用于服务器，包括：

请求接收单元，用于接收客户端针对指定第一用户的目标数据对象创建担保订单的请求；

判断单元，用于判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件；

订单创建单元，用于如果所述判断单元的判断结果为满足，则创建订单，并添加信用标识符，并将所述信用担保订单提供给所述第一用户数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。

一种订单信息处理装置，应用于第一用户数据处理系统，包括：

订单接收单元，用于接收服务器提供的信用担保订单，所述信用担保订单通过以下方式生成：所述服务器在接收到客户端针对目标数据对象创建担保订单的请求时，判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则创建订单，标记为并添加信用担保订单标识符；

状态提交单元，用于如果第二用户未能按时履约，则向所述服务器提交订单状态信息，所述状态信息为第二用户未按时履约，以便服务器从所述第二用户关联的支付账户划拨预置金额到所述第一用户的收款账户。

一种订单类型转换处理装置，应用于服务器，包括：

订单信息记录单元，用于记录业务订单的相关信息，所述相关信息包括所述业务订单关联的第一用户以及第二用户信息，所述业务订单为非担保订单；

转换请求接收单元，用于接收将指定非担保订单转换为担保订单的请求；

信用判断单元，用于判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件；

转换单元，用于如果所述信用判断单元的判断结果为满足，则将所述指定非担保订单转换为信用担保订单，并将转换结果提供给第一用户的数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。

一种订单类型转换处理装置，应用于第一用户数据处理系统，包括：

第一转换请求提交单元，用于向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；

第一转换结果接收单元，用于接收服务器返回的转换结果，以便按照信用担保的方式为所述第二用户提供线下资源预留服务。

一种订单类型转换处理装置，应用于第二用户客户端，包括：

第二转换请求提交单元，用于向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；

第二转换结果接收单元，用于接收服务器返回的转换结果。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，对于信用度比较高的第二用户，采用的是信任的态度，在其需要第一用户为其提供预留线下资源的服务时，可以在不必支付保证金的情况下，即可享受相应的服务。这样，在用户未发生违约的情况下，就不会造成对用户资金的额外占用，并且，由于不必将第二用户的支付账户等信息提供给第一用户，因此，也保证了第二用户隐私信息的安全性。另外，由于不必执行第二用户预先支付保证金、第一用户再退还保证金等一系列的流程，因此，也大大节省了系统在网络、存储等方面的资源。对于第二用户而言，会感觉到自己在消费过程中被信任而获得尊重，因此，也可以提升第二用户的体验。

对于第一用户而言，在第二用户未按时履约的情况下，还可以由服务器将相应的款项，从第二用户的支付账户划拨到第一用户的收款账户，因此，也不会使得第一用户受到损失。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的系统的示意图；

图2是本申请实施例提供的第一方法的流程图；

图3是本申请实施例提供的第二方法的流程图；

图4是本申请实施例提供的第三方法的流程图；

图5是本申请实施例提供的第四方法的流程图；

图6是本申请实施例提供的第五方法的流程图；

图7是本申请实施例提供的第一装置的示意图；

图8是本申请实施例提供的第二装置的示意图；

图9是本申请实施例提供的第三装置的示意图；

图10是本申请实施例提供的第四装置的示意图；

图11是本申请实施例提供的第五装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，第一用户可以是商家用户或者卖家用户等，并且这种第一用户通常是以提供线下资源的方式，为第二用户提供服务，相应的，第二用户就是通过使用第一用户提供的线下资源获得相应服务的买家用户、消费者用户等。具体的，对于不同类别的第一用户，线下资源的具体种类也有所不同，例如，对于酒店类的第一用户，具体的线下资源可以包括客房、房内的设施等等，对于汽车租赁类的第一用户，具体的线下资源主要是指汽车等。

针对上述应用场景，在本申请人提交的其他专利申请中，提供了以下技术方案：基于现有的电子商务交易平台(例如，阿里旅行、支付宝等，为便于描述，这里以阿里旅行为例进行介绍)，可以为用户提供“信用消费服务”，例如，可以称为“信用住”等。具体实现时，参见图1，涉及到的交互实体通常包括：平台服务器，平台提供的第二用户客户端，以及第一用户数据处理系统(例如，酒店的pms(propertymanagementsystem，经营管理系统))或者平台提供的第一用户客户端等(为便于描述，这里以pms为例进行介绍，此时，平台与第一用户pms之间可以是合作关系，可以预先开放自己的一些接口给对方)。当第二用户具体需要使用信用消费服务(例如，信用住)时，可以首先利用平台的第二用户客户端，在线预订具有“信用住”属性的酒店，平台服务器依据支付宝信用体系校验用户信用等级，符合信用等级的用户可以享受信用住模式预定，并将用户预定信息实时传递到第一用户pms系统，第一用户前台也可以直接看到订单信息。第二用户到第一用户办理入住时，可以直接进行免押金入住，在第二用户离店时，免查房、免排队，平台服务器可以直接将实际消费的资金从第二用户的关联账户(例如，支付宝账户等)划拨到第一用户的账户。或者，在其中的“信用住”模式下，第二用户也可以不必预先在线预订，而是直接到酒店办理入住，此时，第一用户pms系统也可以采集第二用户的身份信息、支付宝账户信息等，将其传递给平台服务器，平台服务器对第二用户进行信用权限验证，如果满足条件，则可以通知酒店为该第二用户办理信用住，同样，该第二用户也可以免押金入住，离店时免查房、免排队，由平台服务器办理结账事宜。

总之，在提供信用消费服务的过程中，阿里旅行等电子商务交易平台可以与第一用户的pms系统相互配合，为第一用户以及第二用户都提供了便利。相应的，本申请实施例就可以在以上技术方案的基础上，利用服务器能够与第一用户pms系统相互配合这一特点，进一步提供订单担保的处理方法，以便在开具订单担保环节上也能够为第一用户以及第二用户提供便利，提高效率，节省用户时间。当然，在实际应用中，能够提供“信用消费服务”功能的应用平台也不限于阿里旅行，例如，还可以为该功能提供专用的服务器，开发专用的第一用户客户端、第二用户客户端，等等。另外，在实现本申请实施例中的处理担保订单的功能时，也可以不必以实现“信用消费服务”功能为前提，也就是说，可以单独提供处理担保订单的功能。

需要说明的是，前文所述中提及的“酒店”、“阿里旅行”、“信用住”等是为了对本申请实施例的具体实现方式进行举例说明，不应看作是对本申请实施例保护范围的限定。

下面对具体的实现方式进行详细介绍。

实施例一

该实施例一首先从服务器的角度提供了一种订单信息处理方法，参见图2，该方法可以包括以下步骤：

s201：服务器接收客户端针对指定第一用户的目标数据对象创建担保订单的请求；

具体实现时，酒店等第一用户可以将其酒店产品发布到服务器，服务器就可以以数据对象的形式提供给客户端，其中，如果第一用户想要提供担保形式的服务，则在发布数据对象时可以提供相应的属性信息，包括所需的保证金金额等等。服务器在向客户端提供数据对象信息时，就可以根据第一用户发布数据对象时提供的属性信息，提供相应的信息。这样，如果某用户在预订某第一用户的数据对象时，发现存在可生成担保订单的选项，则可以通过该选项，向服务器发起创建担保订单的请求。

s202：判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件；

服务器在收到客户端的请求后，可以首先对第二用户的信用信息进行判断，具体的判断方式可以有多种，例如，具体的验证方式可以有多种，并且，具体的业务条件可以根据实际的业务需求来确定。例如，可以是对用户的信用等级、信用额度的大小、未结账交易订单的数量等进行限制。这样，服务器具体在进行判断时，针对业务条件中涉及到的各项参数，可以确定出当前用户对应的参数值，并与条件中设定的阈值等进行比对，进而确定用户是否符合业务条件。例如，在阿里旅行平台下，可以获取到用户的支付宝账户关联的“芝麻信用”信息，还可以获取“蚂蚁花呗”为该第二用户提供的额度信息，另外，还可以确定出该支付宝账户关联的未结账订单数量，等等，以上因素都可以用于确定当前用户是否满足业务条件。

其中，如果数据对象信息中记录有如果发生未按时履约的情况下，需要支付的金额信息，则在进行业务条件判断时，还可以判断用户的根据所述第二用户的信用信息，确定所述第二用户的授信额度，如果所述授信额度大于所述预置金额，则确定所述第二用户的信用信息满足所述预置的业务条件。

s203：如果满足，则创建订单，并添加信用标识符；

如果满足条件，即可生成订单，并将订单的类型标记为信用担保订单。例如，在一种方式下，可以在保存订单信息的数据表中提供“是否为担保订单”的字段，在生成担保订单的情况下，可以将该字段的值置为“是”，等等。

需要说明的是，在本申请实施例中，在生成担保订单后，只需要添加相应的标识符即可，第二用户不需要执行支付保证金操作，也就不存在将其支付账户信息提供给第一用户的情况，因此，可以降低安全隐患。当然，关于在用户未按时入住等情况下需要支付的金额，可以记录在相应的订单中，以便后续当发生这种违约情况时，按照订单中记录的金额，向第一用户进行款项的划拨。

s204：将所述信用担保订单提供给所述第一用户的数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。

在生成订单后，就可以将订单信息提供给第一用户的数据处理系统(例如，pms等)，这样，在第一用户收到订单后，就可以按照订单中记录的入住日期、房型等，为第二用户预留相应的线下资源。之后，如果第二用户未能按照订单中约定的时间进店入住，则第一用户的数据处理系统可以将订单状态提供给服务器，该订单状态可以为：第二用户未按时履约，此时，服务器再从第二用户关联的支付账户中，将相应的用作保证金的金额划拨到第一用户的收款账户中。

需要说明的是，在实际应用中，服务器与第一用户的数据处理系统之间可以通过直连的方式进行互通，也即，服务器可以与第一用户的数据处理系统之间建立合作关系，相互开放自己的标准化接口给对方，这样，相互之间就可以通过接口调用的方式，实现信息的直连式互通，而不需要由双方的工作人员通过手动工单的形式来进行信息传递。

总之，通过本申请实施例提供的实现方案，对于信用度比较高的第二用户，采用的是信任的态度，在其需要第一用户为其提供预留线下资源的服务时，可以在不必支付保证金的情况下，即可享受相应的服务。这样，在用户未发生违约的情况下，就不会造成对用户资金的额外占用，并且，由于不必将第二用户的支付账户等信息提供给第一用户，因此，也保证了第二用户隐私信息的安全性。另外，由于不必执行第二用户预先支付保证金、第一用户再退还保证金等一系列的流程，因此，也大大节省了系统在网络、存储等方面的资源。对于第二用户而言，会感觉到自己在消费过程中获得尊重，因此，也可以提升第二用户的体验。当然，对于第一用户而言，由于在第二用户未按时履约的情况下，还可以由服务器将相应的款项，从第二用户的支付账户划拨到第一用户的收款账户，因此，也不会使得第一用户受到损失。

实施例二

该实施例二是与实施例一相对应的，从第一用户数据处理系统的角度，提供了一种订单信息处理方法，参见图3，该方法可以包括以下步骤：

s301：第一用户的数据处理系统接收服务器提供的信用担保订单，所述信用担保订单通过以下方式生成：所述服务器在接收到客户端针对目标数据对象创建担保订单的请求时，判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则创建订单，并添加信用标识符；

s302：如果第二用户未能按时履约，则向所述服务器提交订单状态信息，所述状态信息为第二用户未按时履约，以便服务器从所述第二用户关联的支付账户划拨预置金额到所述第一用户的收款账户。

以上实施例二是与实施例一相对应的，因此，相关的具体实现参见实施例一中的介绍即可，这里不再赘述。

实施例三

在实际应用中，还可能存在以下应用场景：第二用户在线预订时，采用了非担保订单的方式，但是，在后来又希望第一用户为其进行线下资源的预留，此时，如果是在现有技术中，则第二用户通常只能将原来的非担保订单取消，然后再重新进行预订，并生成担保订单，或者要求用户提供信用卡等信息用来担保。这样显然会使得操作流程比较繁琐，效率不高，对于平台服务器而言，也会造成资源的浪费。为此，在本申请实施例中，在采用前述实施例中提到的担保方式的基础下，还可以提供进行订单类型转换的功能。其中，订单类型转换的发起方可以是第二用户客户端，还可以是第一用户的数据处理系统，下面分别进行详细介绍。

在该实施例三中，首先从服务器的角度提供了一种订单类型转换处理方法，参见图4，该方法可以包括以下步骤：

s401：服务器记录业务订单的相关信息，所述相关信息包括所述业务订单关联的第一用户以及第二用户信息，所述业务订单为非担保订单；

具体实现时，如果是第二用户预先通过客户端预订了“信用消费服务”，则相应的业务订单通常是由服务器生成的，该业务订单中可以记录第一用户以及第二用户的标识信息。其中，由于是采用在线预订的方式，因此，也即意味着第一用户以及第二用户都是当前平台(例如阿里旅行)的注册用户，因此，在保存第一用户以及第二用户的标识信息时，可以通过用户id、用户名、账户信息等进行保存。

如果第二用户并没有提前在线预订“信用消费服务”，而是在第二用户进店消费时，由第一用户客户端向服务器发起对第二用户的信用校验，并在校验通过，服务器确定该第二用户为可信用户的情况下，第一用户客户端为其生成业务订单，则第一用户客户端在生成业务订单后，可以将业务订单信息保存到服务器(例如，阿里旅行的服务器等)，包括订单的状态、关联的第一用户第二用户标识信息等，服务器可以对业务订单的这些相关信息进行保存。

需要说明的是，在上述第二种情况下，关于第二用户，该用户通常是在阿里旅行等平台注册的用户，因此，可以利用该用户在平台中注册的用户id、用户名或者账户名等信息，作为第二用户的标识。而关于第一用户，如果第一用户使用的是阿里旅行平台提供的客户端，则也可以通过第一用户在阿里旅行平台中注册的用户id、用户名或者账户名等信息进行标识。而如果是使用的第三方pms系统，则可以通过其他信息对第一用户进行标识，例如，可以是第一用户使用的设备id，或者，在pms系统中注册的用户id、账户名等等。

s402：接收将指定非担保订单转换为担保订单的请求；

具体实现时，转换订单类型的请求可以是由第二用户发起的，例如，此时，可以由第二用户客户端向服务器提交转换请求。当然，在实际应用中，上述转换请求可以是由第二用户主动发起，或者，也可以由第一用户的数据处理系统根据非担保订单中记录的计划入住时间等信息，提前发出提醒消息，以提醒第二用户进行订单类型的转换。其中，对于后者，第一用户的数据处理系统，可以首先将提醒信息提交到服务器，然后，再由服务器将提醒消息发送到第二用户客户端，或者，还可以根据服务器中记录的第二用户的联系方式，通过短消息等方式，将提醒消息发送给第二用户，等等。

或者，转换订单类型的请求也可以是由第一用户的数据处理系统发起的，在这种情况下，可以是在第二用户通过某种途径联系到第一用户的情况下，两者进行协商之后，由第一用户数据处理系统发起订单类型转换的请求。当然，对于这种情况，为了确保第二用户对该转换操作的知情权，服务器在接收到第一用户的数据处理系统发送的请求后，还可以首先向第二用户客户端发送通知消息，通知其订单被第一用户的数据处理系统申请进行订单类型转换，在第二用户客户端返回确认可以转换的情况下，再执行后续的转换操作。

s403：判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件；

该步骤中具体对第二用户信用信息的验证过程可以与实施例一中类似，参见实施例一中的记载即可。需要说明的是，如果之前的非担保订单已经是“信用消费订单”，则意味着在生成非担保订单时，已经对第二用户进行了信用验证，因此，也可以直接根据非担保订单是否为信用消费订单进行验证。当然，由于在转换成担保订单后，如果第二用户不能按时履约，则存在按照预置的标准对第一用户进行赔付的情况，因此，即使在之前的非担保订单生成过程中已经对第二用户进行了信用校验，该步骤中，也可以进行进一步的校验，例如，判断第二用户的授信额度，是否高于失约时的赔付标准，等等。

s404：如果满足，则将所述指定非担保订单转换为信用担保订单，并将转换结果提供给第一用户的数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。

在确定第二用户的信用符合预置业务条件的情况下，即可将非担保订单转换为信用担保订单，在本申请实施例中，该转换的过程，只需要对订单进行标记即可，不需要执行其他操作，包括第二用户预先支付保证金等。在类型转换完成后，即可将转换结果提供给第一用户的数据处理系统，这样，第一用户就可以按照信用担保的方式为第二用户提供服务，也即，在无需第二用户预先支付保证金的情况下，即可按照订单中的预约信息，保留相应的线下资源，包括房间，等等。另外，在订单类型转换完成后，还可以将转换结果提供给第二用户客户端。

在将订单转换为信用担保订单之后，后续的处理便可以与前述实施例一中相同，也即，如果第二用户按时履约，则第二用户无需支付与保证金相关的额外费用，而当第二用户存在未按时履约的情况时，第一用户的数据处理系统可以将订单状态信息提供给服务器，以通知服务器，第二用户未能按时履约，此时，就可以由服务器从所述第二用户关联的支付账户划拨预置金额到所述第一用户的收款账户。

可见，在该实施例三中，可以灵活的进行订单类型的转换，将非担保订单转换为担保订单，并且，在转换过程中，同样无需第二用户提前支付保证金，即可享受到第一用户为其预留相应线下资源的服务，提高效率，节省系统资源，同时，也可以提升用户体验。

实施例四

该实施例四是与实施例三相对应的，从第一用户的数据处理系统角度进行介绍，具体的，参见图5，该实施例四提供了一种订单类型转换处理方法，该方法可以包括以下步骤：

s501：第一用户数据处理系统向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；

s502：接收服务器返回的转换结果，以便按照信用担保的方式为所述第二用户提供线下资源预留服务。

如果第二用户未能按时履约，则还可以向所述服务器提交订单状态信息，所述状态信息为第二用户未按时履约，以便服务器从所述第二用户关联的支付账户划拨预置金额到所述第一用户的收款账户。

实施例五

在上述实施例四中，订单类型转换请求是由第一用户数据处理系统提交到服务器的，而在另一种实现方式下，该订单类型转换请求也可以是由第二用户客户端提交到服务器，具体的，参见图6，该实施例五提供了一种订单类型转换处理方法，该方法可以包括以下步骤：

s601：客户端向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；

s602：接收服务器返回的转换结果。

以上实施例四、五均是与实施例三相对应的，因此，相关的具体实现参见实施例三中的介绍即可，这里不再赘述。

与实施例一相对应，本申请实施例还提供了一种订单信息处理装置，该装置应用于服务器，参见图7，该装置具体可以包括：

请求接收单元701，用于接收客户端针对指定第一用户的目标数据对象创建担保订单的请求；

判断单元702，用于判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件；

订单创建单元703，用于如果所述判断单元的判断结果为满足，则创建订单，并添加信用标识符，并将所述信用担保订单提供给所述第一用户数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。

具体实现时，所述订单创建单元703具体可以通过预先获知的所述第一用户数据处理系统的接口，将所述信用担保订单提供给所述第一用户数据处理系统。

在一种具体的实现方式下，该装置还可以包括：

订单状态接收单元，用于接收所述第一用户的数据处理系统提供的所述订单的状态信息；

资源划拨单元，用于如果所述订单状态为第二用户未按时履约，则从所述第二用户关联的支付账户划拨预置资源信息到所述第一用户的收款账户。

其中，所述预置资源信息可以由所述第一用户在发布所述目标数据对象时提供。

此时，判断单元702具体可以用于：根据所述第二用户的信用信息，确定所述第二用户的授信额度；如果所述授信额度大于所述预置金额，则确定所述第二用户的信用信息满足所述预置的业务条件。

与实施例二相对应，本申请实施例还提供了一种订单信息处理装置，该装置应用于第一用户数据处理系统，参见图8，该装置具体可以包括：

订单接收单元801，用于接收服务器提供的信用担保订单，所述信用担保订单通过以下方式生成：所述服务器在接收到客户端针对目标数据对象创建担保订单的请求时，判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则创建订单，标记为并添加信用担保订单标识符；

状态提交单元802，用于如果第二用户未能按时履约，则向所述服务器提交订单状态信息，所述状态信息为第二用户未按时履约，以便服务器从所述第二用户关联的支付账户划拨预置金额到所述第一用户的收款账户。

与实施例三相对应，本申请实施例还提供了一种订单信息处理装置，该装置应用于服务器，参见图9，该装置具体可以包括：

订单信息记录单元901，用于记录业务订单的相关信息，所述相关信息包括所述业务订单关联的第一用户以及第二用户信息，所述业务订单为非担保订单；

转换请求接收单元902，用于接收将指定非担保订单转换为担保订单的请求；

信用判断单元903，用于判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件；

转换单元904，用于如果所述信用判断单元的判断结果为满足，则将所述指定非担保订单转换为信用担保订单，并将转换结果提供给第一用户的数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。

具体实现时，转换请求接收单元902具体可以用于接收第一用户的数据处理系统提交的将指定非担保订单转换为担保订单的请求；

此时，该装置还可以包括：

通知单元，用于在判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件之前，向所述指定非担保订单关联的第二用户客户端发送通知消息；

触发单元，用于在接收到第二用户客户端返回的确认转换的响应后，触发执行所述判断操作。

在另一种实现方式下，所述转换请求接收单元902具体可以用于：接收第二用户客户端提交的将指定非担保订单转换为担保订单的请求。

此时，该装置还可以包括：

转换结果提供单元，用于将订单转换结果提供给第二用户客户端。

另外，该装置还可以包括：

订单状态信息接收单元，用于接收所述第一用户的数据处理系统提供的订单状态信息；

资源划拨单元，用于如果所述订单状态为第二用户未按时履约，则从所述第二用户关联的支付账户划拨预置资源信息到所述第一用户的收款账户。

与实施例四相对应，本申请实施例还提供了一种订单信息处理装置，该装置应用于第一用户数据处理系统，参见图10，该装置具体可以包括：

第一转换请求提交单元1001，用于向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；

第一转换结果接收单元1002，用于接收服务器返回的转换结果，以便按照信用担保的方式为所述第二用户提供线下资源预留服务。

与实施例五相对应，本申请实施例还提供了一种订单信息处理装置，该装置应用于第二用户客户端，参见图11，该装置具体可以包括：

第二转换请求提交单元1101，用于向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；

第二转换结果接收单元1102，用于接收服务器返回的转换结果。

通过本申请实施例，对于信用度比较高的第二用户，采用的是信任的态度，在其需要第一用户为其提供预留线下资源的服务时，可以在不必支付保证金的情况下，即可享受相应的服务。这样，在用户未发生违约的情况下，就不会造成对用户资金的额外占用，并且，由于不必将第二用户的支付账户等信息提供给第一用户，因此，也保证了第二用户隐私信息的安全性。另外，由于不必执行第二用户预先支付保证金、第一用户再退还保证金等一系列的流程，因此，也大大节省了系统在网络、存储等方面的资源。对于第二用户而言，会感觉到自己在消费过程中被信任而获得尊重，因此，也可以提升第二用户的体验。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的订单信息处理以及订单类型转换处理方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。