CN106570706A - 业务纠纷的处理方法及装置 - Google Patents

Abstract

本申请提供一种业务纠纷的处理方法及装置，该方法可以包括：接收到针对任一业务的纠纷处理申请；获取与所述任一业务相关的证据信息；根据所述证据信息，对所述纠纷处理申请进行响应。通过本申请的技术方案，可以实现对业务纠纷的自动取证和处理，简化了操作过程，有助于提升纠纷处理效率。

Description

业务纠纷的处理方法及装置

技术领域

本申请涉及业务处理技术领域，尤其涉及业务纠纷的处理方法及装置。

背景技术

在相关技术中，业务交互平台提供了用户直接之间实现业务交互的功能和机会。但是，用户之间的业务交互过程，往往会不可避免地发生各种类型的纠纷；一部分简单的纠纷，可以通过用户之间的沟通而解决，而更多的纠纷往往需要业务交互平台的人工客服介入，并涉及到对时间、操作等各方面因素的取证等，往往操作繁复且耗时很长，导致极大地影响了用户的应用体验。

发明内容

有鉴于此，本申请提供一种业务纠纷的处理方法及装置，可以实现对业务纠纷的自动取证和处理，简化了操作过程，有助于提升纠纷处理效率。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种业务纠纷的处理方法，包括：

接收到针对任一业务的纠纷处理申请；

获取与所述任一业务相关的证据信息；

根据所述证据信息，对所述纠纷处理申请进行响应。

根据本申请的第二方面，提出了一种业务纠纷的处理装置，包括：

接收单元，接收到针对任一业务的纠纷处理申请；

获取单元，获取与所述任一业务相关的证据信息；

响应单元，根据所述证据信息，对所述纠纷处理申请进行响应。

由以上技术方案可见，本申请通过业务交互平台的主动介入和取证，既可以提升证据可靠性，又可以避免业务请求方用户或业务响应方用户进行取证，简化了纠纷处理过程，并有助于提升纠纷处理效率。

附图说明

图1A-1B是本申请一示例性实施例中的一种业务交互的示意图；

图2是本申请一示例性实施例中的一种业务纠纷的处理方法的流程图；

图3是本申请一示例性实施例中的一种卖家未按约定时间发货的处理方法的流程图；

图4是本申请一示例性实施例中的另一种卖家未按约定时间发货的处理方法的流程图；

图5A是本申请一示例性实施例中的一种与物流公司进行协同处理的示意图；

图5B是本申请一示例性实施例中的另一种与物流公司进行协同处理的示意图；

图6是本申请一示例性实施例中的一种卖家发货数量不足的处理方法的流程图；

图7是本申请一示例性实施例中的一种电子设备的结构示意图；

图8是本申请一示例性实施例中的一种业务纠纷的处理装置的框图。

具体实施方式

图1A是本申请一示例性实施例中的一种业务交互的示意图，如图1A所示，业务交互平台使用户A和用户B之间可以实现直接的业务交互。举例而言，由用户A在业务交互平台上提供可交互的业务对象，而用户B在业务交互平台上浏览到该业务对象后，与用户A达成关于该业务对象的交互业务，即：由用户A向用户B提供上述的业务对象，而用户B向用户A提供相应的交互对象。

其中，用户B向用户A提供的交互对象，往往可以实现在线交互，比如从用户B的账户向用户A的账户转入一定数额的虚拟业务数据(可以直接通过业务交互平台进行数据转移，也可以通过与该业务交互平台相关的其他平台实现，本申请并不对此进行限制)；但是，用户A向用户B提供的业务对象往往具有实体，并不能够在线转移，而是需要通过服务提供方用户的物流协助，从而将业务对象从用户A处转移至用户B处。

所以，当用户A与用户B之间发生了纠纷事件时，可以通过对该服务提供方用户的取证操作，提供客观的证据，以便于业务交互平台实现公平的判决。然而，相关技术中的问题在于，服务提供方用户往往为物流公司等，用户A或用户B作为个人向物流公司进行取证时，往往存在流程繁复(比如证明用户身份、证明取证目的等)、证据造假等各种问题，不利于对纠纷进行及时、公正的解决；当然，在另一种情况下，如图1B所示，服务提供方用户可以为用户A自身，即用户A既可以提供业务对象，还提供对该业务对象的物流运输等服务，则用户B向用户A进行取证时，同样存在取证困难等问题。

因此，本申请通过由业务交互平台对服务提供方用户的主动介入和取证操作，以解决相关技术中存在的上述技术问题。下面结合实施例做进一步说明：

图2是本申请一示例性实施例中的一种业务纠纷的处理方法的流程图，如图2所示，该方法应用于业务交互平台中，可以包括以下步骤：

步骤202，接收到针对任一业务的纠纷处理申请。

在本实施例中，任一业务可以为业务交互平台上的任意业务，涉及到对应的业务请求方用户与业务响应方用户之间的业务交互，具体由业务请求方用户向业务响应方用户提供交互对象，并据此发起对业务响应方用户的业务对象的请求，从而完成该任一业务的创建。

举例而言，假定业务交互平台为电子商务平台，则业务请求方用户为买家用户、业务响应方用户为卖家用户，业务对象为卖家用户出售的商品、交互对象为买家用户用于购买该商品的钱款、代金券、红包等。其中，当买家用户选择在线付款时，若该买家用户选择了所需商品并交付了相应的金额(即完成“购买”操作)，则认为创建了上述的任一业务，形成了对应的购物订单；或者，当买家用户选择了货到付款时，若该买家用户选择了所需商品并确认购买，则认为创建了上述的任一业务。当然，除了电子商务平台之外，业务交互平台还可以为其他任意类型，本申请并不对此进行限制。

在本实施例中，业务请求方用户和业务响应方用户均可以提出纠纷处理申请，比如业务请求方用户认为业务响应方用户未及时发出业务对象，或者业务响应方用户认为业务请求方用户的行为属于恶意欺骗等，均可以向业务交互平台发起相应类型的纠纷处理申请。其中，纠纷处理申请可以针对任意类型的纠纷而提出，比如除了上述纠纷类型之外，还可以包括诸如业务对象数量不足、质量缺陷等，本申请并不对此进行限制。

步骤204，获取与所述任一业务相关的证据信息。

在本实施例中，可以通过以下方式中至少之一获取与所述任一业务相关的证据信息：

(1)从所述任一业务的描述信息中，提取与业务请求方用户和业务响应方用户中至少之一相关的证据信息；

其中，与业务请求方用户和业务响应方用户中的任一用户相关的证据信息，可以包括以下至少之一：

a.所述任一用户的属性信息；举例而言，比如该任一用户的登录账号、交易账户、所处地区、联系方式等；

b.所述任一用户执行的与所述任一业务相关的历史行为信息；举例而言，比如该任一用户为业务请求方用户时，历史行为信息可以为业务对象选择行为、下单行为、付款行为、备注行为等以及这些行为的发生时间、内容等信息；或者，比如该任一用户为业务响应方用户时，历史行为信息可以为发货行为、价格更改行为等以及这些行为的发生时间、内容等信息。

(2)获取对应于与所述任一业务相关的服务提供方用户的证据信息。

诸如图1A-1B所示，当业务响应方用户向业务请求方用户提供业务对象时，由于业务对象并非虚拟物品，因而需要由服务提供方用户进行物流运输，使业务对象从业务响应方用户处转移至业务请求方用户处。由于存在多家物流公司，因而需要了解当前纠纷处理申请对应的任一业务采用的是哪家物流，即该服务提供方用户的ID信息；同时，由于每家物流公司会同时处理很多业务对象的物流运输，因而需要通过该任一业务的业务对象在该服务提供方用户处的ID信息，对该业务对象进行区分和识别，比如该业务对象的ID信息可以为该服务提供方用户分配的物流单号。

其中，如图1A所示，服务提供方用户可以为区别于业务请求方用户(即用户B)和业务提供方用户(即用户A)的第三方用户，比如在电商场景下，用户A可以为卖家用户、用户B为买家用户、服务提供方用户可以为第三方物流公司；或者，如图1B所示，服务提供方用户可以为业务提供方用户(即用户A)，比如在电商场景下，用户A可以为自营电商，同时提供商品出售和物流运输(当然，可能属于该电商的不同部门进行运营和管理；相应地，业务交互平台在步骤206中可以向负责物流运输的部门发起取证请求，以获得相应的取证结果)、用户B可以为买家用户。

因此，可以通过确定业务响应方用户提供的与所述任一业务相关的服务提供方用户的ID信息，以及所述任一业务的业务对象在所述服务提供方用户处的ID信息；然后，向所述服务提供方用户发起针对所述纠纷处理申请的取证请求，并接收所述服务提供方用户返回的取证结果，以作为对应于所述服务提供方用户的证据信息。

其中，在本实施例中，业务交互平台可以根据服务提供方用户的ID信息，直接向该服务提供方用户进行取证，比如向该服务提供方用户发送业务对象的ID信息，以便该服务提供方用户查询到该业务对象及其对应的取证结果。或者，业务交互平台也可以仅与服务提供方集成平台建立数据连接，而该服务提供方集成平台分别连接至各个服务提供方用户，则业务交互平台只需要将该任一业务采用的服务提供方用户的ID信息以及业务对象在该服务提供方用户处的ID信息，即可由服务提供方集成平台查询到该业务对象及其对应的取证结果。

需要说明的是：上述两种方式的证据信息，仅用于举例说明；实际上，基于应用场景、状况等的不同，只要能够用于自动判责并解决纠纷问题，可以采用任意类型的证据信息，本申请并不对此进行限制。

步骤206，根据所述证据信息，对所述纠纷处理申请进行响应。

由上述实施例可知，本申请通过业务交互平台的主动介入和取证，既可以提升证据可靠性，又可以避免业务请求方用户或业务响应方用户进行取证，简化了纠纷处理过程，并有助于提升纠纷处理效率。

正如上文所述，本申请的技术方案可以应用于任意类型的业务交互平台，且每一业务交互平台下进一步包含了多种应用场景；因此，为了便于理解，下面结合一较为具体的实施例，针对本申请的技术方案进行详细说明。其中，假定业务交互平台为电子商务平台，且买家用户针对卖家用户未按约定时间发货而发起相应的纠纷处理申请，则本申请分别通过图3和图4示出了两个实施例的处理过程，下面分别进行举例说明。

实施例一

图3是本申请一示例性实施例中的一种卖家未按约定时间发货的处理方法的流程图，如图3所示，该方法可以包括以下步骤：

步骤302，用户A上线商品信息。

在本实施例中，假定用户A为电子商务平台上的卖家用户，该用户A可以将自己出售的任意商品“上线”至该电子商务平台上，使买家用户可以进行浏览，以便实现购买。

步骤304，用户B购买用户A的商品。

在本实施例中，假定用户B为买家用户，该用户B在浏览到用户A上线的商品后，实现了购买操作。应当理解的是：当用户B选择在线付款时，若该用户B选定了商品并支付了相应的费用后，认为用户B完成了“购买”操作，并形成了相应的订单，该订单记录了与本次“购买”操作相关的所有信息，包括用户A、用户B、商品、价格、物流、交易账户等各种信息；或者，当用户B选择了货到付款时，若该用户B选择了所需商品并确认购买，认为用户B完成了“购买”操作，并形成了相应的订单。

步骤306，用户B发起纠纷处理申请。

在本实施例中，假定用户A为商品预先定义并配置了“24小时发货”的特征信息，表明其承诺在商品被购买后的24小时内必然会将商品交付第三方即物流公司。当然，用户A还可以根据需要配置其他时长，比如“8小时发货”、“40分钟发货”等，本申请并不对此进行限制。

相应地，如果用户B在24小时之后，仍然无法再订单信息中查看到物流信息，则可以认为用户A并未履行其“24小时发货”的承诺，因而可以向电子商务平台发起纠纷处理申请。

当然，用户B还可以针对其他多种情况，举例而言，当用户B接收到商品后，发现商品包装破损或数量不足时，均可以发起相应的纠纷处理申请。此处仅以“未及时发货”为例进行说明。

步骤308A，获取用户B的登录账号、交易账户、付款时间等，作为与用户B相关的证据信息。

步骤308B，获取用户A的登录账号、交易账户、发货时间等，作为与用户A相关的证据信息。

在本实施例中，通过从订单中记录的信息中，获取与用户A、用户B相关的证据信息，并据此自动判定用户A是否存在未按约发货的情况。其中，上述步骤中列举的信息，均为相应证据信息的可能情况，而并不排除还有其他类型的证据信息，以适用于其他纠纷处理的场景下。

步骤310，若判定用户A存在未按约发货的情况，则转入步骤312A和步骤312B中至少之一。

在本实施例中，根据已获取的用户A的登录账号、用户B的登录账号、用户B的付款时间、用户A的发货时间等，即可确定用户A是否按约发货；举例而言，可以直接计算用户B的付款时间与用户A的发货时间之间的时间差，并确定该时间差是否符合用户A与用户B事先约定好的发货时间(诸如“24小时内发货”等)。

步骤312A，处罚用户A。

在本实施例中，当确定用户A未按约发货时，对纠纷处理申请的处理结果将不利于该卖家用户A。举例而言，可以包括以下至少之一：

1)通过用户A的关联账户对用户B进行赔付。比如该关联账户可以为用户A的交易账户(由上述的证据信息确定)；或者，该关联账户也可以是与用户A的登录账号相关的其他账户，比如红包账户、银行账户、保证金账户等。其中，向用户B进行赔付时，赔付数额可以为预定义数额(比如无论交易金额为何，均赔付10元等)或交易金额的预设比例(比如交易金额的10％等)，也可以为其他形式的任意数额。

2)降低用户A的信用等级，使得用户A在店铺扩张、搜索推荐、贷款数额等方面均受到限制。

3)提高用户A的保证金数额，使得用户A需要支付和冻结更多数额的保证金，降低其资金流动性。

步骤312B，赔付用户B。

在本实施例中，当确定用户A未按约发货时，对纠纷处理申请的处理结果将利于该买家用户B。举例而言，可以包括以下至少之一：

1)退还用户B在上述任一业务中支出的交互对象的至少一部分；换言之，可以退还用户B支付金额的至少一部分。

2)通过用户A的关联账户对用户B进行赔付，此处同上文。

实施例二

图4是本申请一示例性实施例中的一种卖家未按约定时间发货的处理方法的流程图，如图4所示，该方法可以包括以下步骤：

步骤402，用户A上线商品信息。

在本实施例中，假定用户A为电子商务平台上的卖家用户，该用户A可以将自己出售的任意商品“上线”至该电子商务平台上，使买家用户可以进行浏览，以便实现购买。

步骤404，用户B购买用户A的商品。

在本实施例中，假定用户B为买家用户，该用户B在浏览到用户A上线的商品后，实现了购买操作。应当理解的是：当用户B选择在线付款时，若该用户B选定了商品并支付了相应的费用后，认为用户B完成了“购买”操作，并形成了相应的订单，该订单记录了与本次“购买”操作相关的所有信息，包括用户A、用户B、商品、价格、物流、交易账户等各种信息；或者，当用户B选择了货到付款时，若该用户B选择了所需商品并确认购买，认为用户B完成了“购买”操作，并形成了相应的订单。

步骤406，用户B发起纠纷处理申请。

在本实施例中，假定用户A为商品预先定义并配置了“24小时发货”的特征信息，表明其承诺在商品被购买后的24小时内必然会将商品交付第三方即物流公司。当然，用户A还可以根据需要配置其他时长，比如“8小时发货”、“40分钟发货”等，本申请并不对此进行限制。

相应地，如果用户B在24小时之后，仍然无法再订单信息中查看到物流信息，则可以认为用户A并未履行其“24小时发货”的承诺，因而可以向电子商务平台发起纠纷处理申请。

当然，用户B还可以针对其他多种情况，举例而言，当用户B接收到商品后，发现商品包装破损或数量不足时，均可以发起相应的纠纷处理申请。此处仅以“未及时发货”为例进行说明。

步骤408A，判断用户B是否为恶意买家，若是则转入步骤409，否则转入步骤410。

步骤408B，判断用户B是否为低等级用户，若是则转入步骤409，否则转入步骤410。

在本实施例中，步骤408A与步骤408B之间可以为图4所示的并列关系，则当用户B满足其中任一项时，均转入步骤409；或者，步骤408A与步骤408B之间可以为递进关系，比如首先判断用户B是否满足步骤408A，若满足则直接转入步骤409，否则进一步判断其是否满足步骤408B。其中，电子商务平台还可以对更多类似的条件进行判断，以充分识别出用户B的身份类型信息，避免对纠纷处理申请的错误响应。

在本实施例中，步骤408A与步骤408B用于判断出用户B是否为预设特征用户，比如风险用户，其可能通过恶意发起纠纷处理申请而对用户A等卖家用户造成损失，因而需要做出准确的识别和处理。当然，步骤408A与步骤408B均为可选步骤，可以直接由步骤406转入步骤410，而无需对用户B的身份类型进行判断。

其中，基于对用户B进行历史行为分析等方式，可以判断并标识出用户B是否为恶意买家，则步骤408A即可通过读取该用户B的身份标识，确定其是否为恶意买家；而针对用户B的等级情况，比如该等级情况可以包括账号(或会员)等级、信用等级等，当等级较低(低于预设等级)时，表明用户B的账号可能新注册或不经常使用，存在一定的欺骗风险，因而应当避免对该用户B提出的纠纷处理申请进行自动处理，避免误判断。

步骤409，转入人工处理平台。

在本实施例中，人工处理平台可以为业务交互平台的子平台，也可以为与业务交互平台相关联的其他平台，本申请并不对此进行限制。通过人工处理平台进行处理的过程中，可以采用即时通讯应用、电话沟通等方式来实现，相关技术中存在成熟的处理方案，此处不再赘述。

步骤410，当订单信息中存在用户A填写的物流公司ID、物流单号时，转入步骤412A，否则转入步骤412B。

在本实施例中，正如上文所述，对应于图1A和图1B所示的应用场景，服务提供方可以存在不同情形，本实施例中以图1A所示的场景(即服务提供方为区别于用户A、用户B的第三方用户)为例进行说明。

步骤412A，根据获取的物流公司ID和物流单号，向相应的物流公司或物流平台发起请求。

在本实施例中，业务交互平台可以通过多种方式向第三方即物流公司请求取证。

在一种情况下，业务交互平台直接与各个物流公司进行数据交互。如图5A所示，假定业务交互平台分别与物流公司A和物流公司B等存在协作关系，则当用户A通过物流公司A发出用户B购买的商品时，业务交互平台可以直接向该物流公司A发送相应的物流单号，并由该物流公司A查询对应的物流信息，以实现取证。

在另一种情况下，业务交互平台可以与物流平台进行数据交互，而该物流平台自行与各个物流公司进行数据交互。比如图5B所示，假定业务交互平台仅与物流平台存在协作关系，而物流平台分别与物流公司A、物流公司B等存在协作关系，则当用户A通过物流公司A发出用户B购买的商品时，业务交互平台可以直接向物流平台发送该物流公司A的ID信息和相应的物流单号，并由该物流平台联络物流公司A查询对应的物流信息后，以实现取证。

步骤414A，接收物流公司或物流平台返回的取证结果，该取证结果为用户A的实际发货时间。

在本实施例中，对于本实施例的应用场景下，取证结果为实际发货时间；当应用场景发生变化时，采用的取证结果也相应地发生变化。

步骤416，对比用户B的付款时间与实际发货时间。

在本实施例中，用户B的付款时间即订单的生成时间，也是开始计算用户A“发货时长”的起始时间。假定付款时间为某天的上午8点、实际发货时间为当天的下午18点，则用户A的“发货时长”为10小时，满足用户A承诺的“24小时发货”，表明其实现了按约发货；而假定付款时间为某天的上午8点、实际发货时间为第二天的上午10点，则用户A的“发货时长”为26小时，显然并不满足用户A承诺的“24小时发货”，表明其并未按约发货。

在本实施例中，作为第三方的物流公司查询到的实际发货时间，可以认为是客观记录下的接收到用户A发出货品的时间，因而可以作为证据来证明用户A是否遵守了其自行承诺的发货时限；而通过业务交互平台与物流公司或物流平台之间的数据交互，使得用户A和用户B均无需单独向物流公司或物流平台请求相应的时间证据，有助于更加迅速、客观、公正地判断出用户A是否存在失信的情况。

步骤412B，获取在预设时间段内接收到与用户A相关的纠纷处理申请、且用户A未提供相应的物流公司ID或物流单号的历史统计次数a，若a≥N(N为预设次数)，则转入步骤409，否则转入步骤414B。

在本实施例中，卖家用户A可能由于繁忙而偶尔忘记填写物流公司ID和物流单号，因而可以预先设置次数N，若当前的历史统计次数a未达到预设次数N，则表明用户A确实是属于偶尔忘记填写，而大部分情况下均及时填写，可以通过步骤409的人工客服来核实情况，且当用户A确实在承诺时长内发货时，应当免去对用户A的惩罚处理，但需要对历史统计次数a进行加一处理。然而，当历史统计次数a已经达到或超出预设次数N，表明用户A并非偶尔忘记，可以直接进行转入步骤414B进行判别。

其中，历史统计次数a对应的“预设时间段”可以为“1年内”、“3个月内”等，当该时间段的长度到达时，可以对已经统计的次数a进行清零，并重新开始计算；当然，通过将“预设时间段”设定为“迄今为止”，则历史统计次数a将实现不断增加，不会清零。

步骤414B，对比用户B的付款时间与纠纷处理申请的申请发起时间。

在本实施例中，假定付款时间为某天的上午8点、申请发起时间为当天的下午18点，则尚处于用户A承诺的“24小时发货”的时间段内，表明用户A尚未存在失信的情况；而假定付款时间为某天的上午8点、申请发起时间为第二天的上午10点，则用户A的“发货时长”至少已经达到了26小时，显然并不满足用户A承诺的“24小时发货”，表明其并未按约发货。

步骤418，当确定用户A未按约发货时，转入步骤420A和步骤420B中至少之一。

步骤420A，处罚用户A。

在本实施例中，当确定用户A未按约发货时，对纠纷处理申请的处理结果将不利于该卖家用户A。举例而言，可以包括以下至少之一：

1)通过用户A的关联账户对用户B进行赔付。比如该关联账户可以为用户A的交易账户、红包账户、银行账户、保证金账户等；其中，向用户B进行赔付时，赔付数额可以为预定义数额(比如无论交易金额为何，均赔付10元等)或交易金额的预设比例(比如交易金额的10％等)，也可以为其他形式的任意数额。

2)降低用户A的信用等级，使得用户A在店铺扩张、搜索推荐、贷款数额等方面均受到限制。

3)提高用户A的保证金数额，使得用户A需要支付和冻结更多数额的保证金，降低其资金流动性。

步骤420B，赔付用户B。

在本实施例中，当确定用户A未按约发货时，对纠纷处理申请的处理结果将利于该买家用户B。举例而言，可以包括以下至少之一：

1)退还用户B在上述任一业务中支出的交互对象的至少一部分；换言之，可以退还用户B支付金额的至少一部分。

2)通过用户A的关联账户对用户B进行赔付，此处同上文。

由以上实施例及其附图3、4可知，本申请通过业务交互平台的主动介入，主动获取与业务请求方用户、业务响应方用户相关的证据信息，或者对第三方的物流公司或物流平台进行对接，可以实现对纠纷处理申请的自动、快速、准确识别和处理，提升了对纠纷处理申请的处理效率。而除了上述实施例中的“卖家未按约发货”的应用场景外，正如上文所述，本申请的技术方案还可以应用在其他任意数据交互场景下的纠纷处理过程；举例而言，如图6所示，本申请的技术方案还可以应用于“卖家发货数量不足”的应用场景中。

如图6所示，业务交互平台接收到买家用户发出的纠纷处理申请，该纠纷处理申请表明卖家用户发出的商品数量不符，比如买家用户下单了15支铅笔，而实际仅收到了10支铅笔。

那么，业务交互平台可以通过读取相应的订单信息来获取物流公司ID和物流单号，比如由物流公司B完成物流运输，则业务交互平台可以向物流平台发送商品数量询问消息，该消息中包含物流公司B的ID信息和物流单号，由物流平台与该物流公司B进行数据交互，使物流公司B查询其从用户A处收货时的铅笔数量(即实际商品数量)，并由物流平台返回业务交互平台。

然后，业务交互平台可以通过将该实际商品数量与订单中记载的购买数量进行比较后，确定卖家用户是否发货不足；如果发货不足，则应当对卖家用户进行处罚、对买家用户进行赔付。

图7示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图7，在硬件层面，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成业务纠纷的处理装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图8，在软件实施方式中，该业务纠纷的处理装置可以包括接收单元、确定单元、请求单元和响应单元。其中：

接收单元，接收到针对任一业务的纠纷处理申请；

获取单元，获取与所述任一业务相关的证据信息；

响应单元，根据所述证据信息，对所述纠纷处理申请进行响应。

可选的，所述获取单元通过以下方式中至少之一获取与所述任一业务相关的证据信息：

从所述任一业务的描述信息中，提取与业务请求方用户和业务响应方用户中至少之一相关的证据信息；

获取对应于与所述任一业务相关的服务提供方用户的证据信息。

可选的，所述服务提供方用户为所述业务响应方用户，或者所述服务提供方用户为区别于所述业务响应方用户和业务请求方用户的第三方用户。

可选的，与业务请求方用户和业务响应方用户中的任一用户相关的证据信息，包括以下至少之一：

所述任一用户的属性信息；

所述任一用户执行的与所述任一业务相关的历史行为信息。

可选的，所述获取单元具体用于：

确定业务响应方用户提供的与所述任一业务相关的服务提供方用户的ID信息，以及所述任一业务的业务对象在所述服务提供方用户处的ID信息；

向所述服务提供方用户发起针对所述纠纷处理申请的取证请求；

获取所述服务提供方用户返回的取证结果，作为对应于所述服务提供方用户的证据信息。

可选的，所述请求单元具体用于：

根据所述服务提供方用户的ID信息，将所述业务对象的ID信息发送至所述服务提供方用户，以接收所述服务提供方用户查询后返回的所述取证结果；

或者，将所述服务提供方用户的ID信息和所述业务对象的ID信息发送至服务提供方集成平台，以接收所述服务提供方集成平台查询后返回的所述取证结果。

可选的，所述纠纷处理申请的内容对应于以下情况中至少之一：

在所述任一业务被创建后的预设时长内，所述业务响应方用户未将所述任一业务的业务对象交由所述服务提供方用户进行处理；

所述业务响应方用户交付给所述服务提供方用户的所述业务对象的数量不足；

所述业务响应方用户交付给所述服务提供方用户的所述业务对象存在质量缺陷。

可选的，所述预设时长由所述业务响应方用户预先定义并预配置为所述业务对象的特征信息。

可选的，当所述纠纷处理申请表明：在所述任一业务被创建后的预设时长内，业务响应方用户未将所述任一业务的业务对象交由所述服务提供方用户进行处理时，所述取证结果包括：所述服务提供方用户记录的所述业务响应方用户将所述业务对象交付给所述服务提供方用户的实际时间；以及，所述响应单元具体用于：

当所述实际时间超出所述任一业务被创建后的预设时长时，对业务请求方用户和所述业务响应方用户中的至少之一执行处理，以响应于所述纠纷处理申请；

其中，对所述业务请求方用户执行处理时，处理结果有利于所述业务请求方用户，对所述业务响应方用户执行处理时，处理结果不利于所述业务响应方用户。

可选的，

还包括：时间获取单元，当所述业务响应方用户未提供所述服务提供方用户的ID信息或所述业务对象在所述服务提供方用户处的ID信息时，获取所述纠纷处理申请的接收时间；

所述响应单元具体用于：当所述接收时间超出所述任一业务被创建后的预设时长时，对业务请求方用户和所述业务响应方用户中的至少之一执行处理，以响应于所述纠纷处理申请；

其中，对所述业务请求方用户执行处理时，处理结果有利于所述业务请求方用户，对所述业务响应方用户执行处理时，处理结果不利于所述业务响应方用户。

可选的，

还包括：次数获取单元，当所述业务响应方用户未提供所述服务提供方用户的ID信息或所述业务对象在所述服务提供方用户处的ID信息时，获取在预设时间段内接收到与所述业务响应方用户相关的纠纷处理申请、且所述业务响应方用户未提供相应的服务提供方用户的ID信息或相应业务对象的ID信息的历史统计次数；

所述响应单元具体用于：当所述历史统计次数不大于预设次数时，转入人工处理平台，并将所述历史统计次数加一；当所述历史统计次数大于所述预设次数时，若所述接收时间超出所述任一业务被创建后的预设时长，则对业务请求方用户和所述业务响应方用户中的至少之一执行处理，以响应于所述纠纷处理申请。

可选的，

所述响应单元通过下述方式中至少之一对所述业务请求方用户执行处理：退还所述业务请求方用户在所述任一业务中支出的交互对象的至少一部分、通过所述业务响应方用户的关联账户对所述业务请求方用户进行赔付；

所述响应单元通过下述方式中至少之一对所述业务响应方用户执行处理：通过所述业务响应方用户的关联账户对所述业务请求方用户进行赔付、降低所述业务响应方用户的信用等级、提高所述业务响应方用户的保证金数额。

可选的，还包括：

判断单元，当所述纠纷处理申请来自业务请求方用户时，判断所述业务请求方用户是否为预设特征用户；

调度单元，当所述业务请求方用户为所述预设特征用户时，将所述纠纷处理申请转入人工处理平台。

可选的，当所述业务请求方用户满足以下条件中至少之一时，判定所述业务请求方用户为所述预设特征用户：

账号等级低于预设等级、信用等级低于预设等级、被预配置为所述预设特征用户。

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

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

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

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

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (28)

1.一种业务纠纷的处理方法，其特征在于，包括：

接收到针对任一业务的纠纷处理申请；

获取与所述任一业务相关的证据信息；

根据所述证据信息，对所述纠纷处理申请进行响应。

2.根据权利要求1所述的方法，其特征在于，通过以下方式中至少之一获取与所述任一业务相关的证据信息：

从所述任一业务的描述信息中，提取与业务请求方用户和业务响应方用户中至少之一相关的证据信息；

获取对应于与所述任一业务相关的服务提供方用户的证据信息。

3.根据权利要求2所述的方法，其特征在于，所述服务提供方用户为所述业务响应方用户，或者所述服务提供方用户为区别于所述业务响应方用户和业务请求方用户的第三方用户。

4.根据权利要求2所述的方法，其特征在于，与业务请求方用户和业务响应方用户中的任一用户相关的证据信息，包括以下至少之一：

所述任一用户的属性信息；

所述任一用户执行的与所述任一业务相关的历史行为信息。

5.根据权利要求2所述的方法，其特征在于，所述获取对应于与所述任一业务相关的服务提供方用户的证据信息，包括：

确定业务响应方用户提供的与所述任一业务相关的服务提供方用户的ID信息，以及所述任一业务的业务对象在所述服务提供方用户处的ID信息；

向所述服务提供方用户发起针对所述纠纷处理申请的取证请求；

接收所述服务提供方用户返回的取证结果，作为对应于所述服务提供方用户的证据信息。

6.根据权利要求5所述的方法，其特征在于，所述向所述服务提供方用户发起针对所述纠纷处理申请的取证请求，包括：

根据所述服务提供方用户的ID信息，将所述业务对象的ID信息发送至所述服务提供方用户，以接收所述服务提供方用户查询后返回的所述取证结果；

或者，将所述服务提供方用户的ID信息和所述业务对象的ID信息发送至服务提供方集成平台，以接收所述服务提供方集成平台查询后返回的所述取证结果。

7.根据权利要求5所述的方法，其特征在于，所述纠纷处理申请的内容对应于以下情况中至少之一：

在所述任一业务被创建后的预设时长内，所述业务响应方用户未将所述任一业务的业务对象交由所述服务提供方用户进行处理；

所述业务响应方用户交付给所述服务提供方用户的所述业务对象的数量不足；

所述业务响应方用户交付给所述服务提供方用户的所述业务对象存在质量缺陷。

8.根据权利要求7所述的方法，其特征在于，所述预设时长由所述业务响应方用户预先定义并预配置为所述业务对象的特征信息。

9.根据权利要求7所述的方法，其特征在于，当所述纠纷处理申请表明：在所述任一业务被创建后的预设时长内，业务响应方用户未将所述任一业务的业务对象交由所述服务提供方用户进行处理时，所述取证结果包括：所述服务提供方用户记录的所述业务响应方用户将所述业务对象交付给所述服务提供方用户的实际时间；以及，所述根据所述服务提供方用户返回的取证结果，对所述纠纷处理申请进行响应，包括：

当所述实际时间超出所述任一业务被创建后的预设时长时，对业务请求方用户和所述业务响应方用户中的至少之一执行处理，以响应于所述纠纷处理申请；

其中，对所述业务请求方用户执行处理时，处理结果有利于所述业务请求方用户，对所述业务响应方用户执行处理时，处理结果不利于所述业务响应方用户。

10.根据权利要求9所述的方法，其特征在于，

还包括：当所述业务响应方用户未提供所述服务提供方用户的ID信息或所述业务对象在所述服务提供方用户处的ID信息时，获取所述纠纷处理申请的接收时间；

所述根据所述服务提供方用户返回的取证结果，对所述纠纷处理申请进行响应，包括：当所述接收时间超出所述任一业务被创建后的预设时长时，对业务请求方用户和所述业务响应方用户中的至少之一执行处理，以响应于所述纠纷处理申请；

其中，对所述业务请求方用户执行处理时，处理结果有利于所述业务请求方用户，对所述业务响应方用户执行处理时，处理结果不利于所述业务响应方用户。

11.根据权利要求10所述的方法，其特征在于，还包括：

当所述业务响应方用户未提供所述服务提供方用户的ID信息或所述业务对象在所述服务提供方用户处的ID信息时，获取在预设时间段内接收到与所述业务响应方用户相关的纠纷处理申请、且所述业务响应方用户未提供相应的服务提供方用户的ID信息或相应业务对象的ID信息的历史统计次数；

所述根据所述服务提供方用户返回的取证结果，对所述纠纷处理申请进行响应，包括：当所述历史统计次数不大于预设次数时，转入人工处理平台，并将所述历史统计次数加一；当所述历史统计次数大于所述预设次数时，若所述接收时间超出所述任一业务被创建后的预设时长，则对业务请求方用户和所述业务响应方用户中的至少之一执行处理，以响应于所述纠纷处理申请。

12.根据权利要求9-11中任一项所述的方法，其特征在于，

通过下述方式中至少之一对所述业务请求方用户执行处理：退还所述业务请求方用户在所述任一业务中支出的交互对象的至少一部分、通过所述业务响应方用户的关联账户对所述业务请求方用户进行赔付；

通过下述方式中至少之一对所述业务响应方用户执行处理：通过所述业务响应方用户的关联账户对所述业务请求方用户进行赔付、降低所述业务响应方用户的信用等级、提高所述业务响应方用户的保证金数额。

13.根据权利要求1所述的方法，其特征在于，还包括：

当所述纠纷处理申请来自业务请求方用户时，判断所述业务请求方用户是否为预设特征用户；

当所述业务请求方用户为所述预设特征用户时，将所述纠纷处理申请转入人工处理平台。

14.根据权利要求13所述的方法，其特征在于，当所述业务请求方用户满足以下条件中至少之一时，判定所述业务请求方用户为所述预设特征用户：

账号等级低于预设等级、信用等级低于预设等级、被预配置为所述预设特征用户。

15.一种业务纠纷的处理装置，其特征在于，包括：

接收单元，接收到针对任一业务的纠纷处理申请；

获取单元，获取与所述任一业务相关的证据信息；

响应单元，根据所述证据信息，对所述纠纷处理申请进行响应。

16.根据权利要求15所述的装置，其特征在于，所述获取单元通过以下方式中至少之一获取与所述任一业务相关的证据信息：

从所述任一业务的描述信息中，提取与业务请求方用户和业务响应方用户中至少之一相关的证据信息；

获取对应于与所述任一业务相关的服务提供方用户的证据信息。

17.根据权利要求16所述的装置，其特征在于，所述服务提供方用户为所述业务响应方用户，或者所述服务提供方用户为区别于所述业务响应方用户和业务请求方用户的第三方用户。

18.根据权利要求16所述的装置，其特征在于，与业务请求方用户和业务响应方用户中的任一用户相关的证据信息，包括以下至少之一：

所述任一用户的属性信息；

所述任一用户执行的与所述任一业务相关的历史行为信息。

19.根据权利要求16所述的装置，其特征在于，所述获取单元具体用于：

确定业务响应方用户提供的与所述任一业务相关的服务提供方用户的ID信息，以及所述任一业务的业务对象在所述服务提供方用户处的ID信息；

向所述服务提供方用户发起针对所述纠纷处理申请的取证请求；

获取所述服务提供方用户返回的取证结果，作为对应于所述服务提供方用户的证据信息。

20.根据权利要求19所述的装置，其特征在于，所述请求单元具体用于：

根据所述服务提供方用户的ID信息，将所述业务对象的ID信息发送至所述服务提供方用户，以接收所述服务提供方用户查询后返回的所述取证结果；

或者，将所述服务提供方用户的ID信息和所述业务对象的ID信息发送至服务提供方集成平台，以接收所述服务提供方集成平台查询后返回的所述取证结果。

21.根据权利要求19所述的装置，其特征在于，所述纠纷处理申请的内容对应于以下情况中至少之一：

在所述任一业务被创建后的预设时长内，所述业务响应方用户未将所述任一业务的业务对象交由所述服务提供方用户进行处理；

所述业务响应方用户交付给所述服务提供方用户的所述业务对象的数量不足；

所述业务响应方用户交付给所述服务提供方用户的所述业务对象存在质量缺陷。

22.根据权利要求21所述的装置，其特征在于，所述预设时长由所述业务响应方用户预先定义并预配置为所述业务对象的特征信息。

23.根据权利要求21所述的装置，其特征在于，当所述纠纷处理申请表明：在所述任一业务被创建后的预设时长内，业务响应方用户未将所述任一业务的业务对象交由所述服务提供方用户进行处理时，所述取证结果包括：所述服务提供方用户记录的所述业务响应方用户将所述业务对象交付给所述服务提供方用户的实际时间；以及，所述响应单元具体用于：

当所述实际时间超出所述任一业务被创建后的预设时长时，对业务请求方用户和所述业务响应方用户中的至少之一执行处理，以响应于所述纠纷处理申请；

其中，对所述业务请求方用户执行处理时，处理结果有利于所述业务请求方用户，对所述业务响应方用户执行处理时，处理结果不利于所述业务响应方用户。

24.根据权利要求23所述的装置，其特征在于，

还包括：时间获取单元，当所述业务响应方用户未提供所述服务提供方用户的ID信息或所述业务对象在所述服务提供方用户处的ID信息时，获取所述纠纷处理申请的接收时间；

所述响应单元具体用于：当所述接收时间超出所述任一业务被创建后的预设时长时，对业务请求方用户和所述业务响应方用户中的至少之一执行处理，以响应于所述纠纷处理申请；

其中，对所述业务请求方用户执行处理时，处理结果有利于所述业务请求方用户，对所述业务响应方用户执行处理时，处理结果不利于所述业务响应方用户。

25.根据权利要求24所述的装置，其特征在于，

还包括：次数获取单元，当所述业务响应方用户未提供所述服务提供方用户的ID信息或所述业务对象在所述服务提供方用户处的ID信息时，获取在预设时间段内接收到与所述业务响应方用户相关的纠纷处理申请、且所述业务响应方用户未提供相应的服务提供方用户的ID信息或相应业务对象的ID信息的历史统计次数；

所述响应单元具体用于：当所述历史统计次数不大于预设次数时，转入人工处理平台，并将所述历史统计次数加一；当所述历史统计次数大于所述预设次数时，若所述接收时间超出所述任一业务被创建后的预设时长，则对业务请求方用户和所述业务响应方用户中的至少之一执行处理，以响应于所述纠纷处理申请。

26.根据权利要求23-25中任一项所述的装置，其特征在于，

所述响应单元通过下述方式中至少之一对所述业务请求方用户执行处理：退还所述业务请求方用户在所述任一业务中支出的交互对象的至少一部分、通过所述业务响应方用户的关联账户对所述业务请求方用户进行赔付；

所述响应单元通过下述方式中至少之一对所述业务响应方用户执行处理：通过所述业务响应方用户的关联账户对所述业务请求方用户进行赔付、降低所述业务响应方用户的信用等级、提高所述业务响应方用户的保证金数额。

27.根据权利要求15所述的装置，其特征在于，还包括：

判断单元，当所述纠纷处理申请来自业务请求方用户时，判断所述业务请求方用户是否为预设特征用户；

调度单元，当所述业务请求方用户为所述预设特征用户时，将所述纠纷处理申请转入人工处理平台。

28.根据权利要求27所述的装置，其特征在于，当所述业务请求方用户满足以下条件中至少之一时，判定所述业务请求方用户为所述预设特征用户：

账号等级低于预设等级、信用等级低于预设等级、被预配置为所述预设特征用户。