CN107464153A - 一种信息处理方法及服务器 - Google Patents

Abstract

本发明公开了一种信息处理方法及服务器，其特征在于，所述方法包括：获取第一请求，所述第一请求用于提交待交易置换的第一信息；获取第二请求，所述第二请求用于提交待交易置换的第二信息；响应所述第一请求，从所述第一请求中解析出所述第一信息；响应所述第二请求，从所述第二请求中解析出所述第二信息；提取信息匹配策略，所述信息匹配策略用于表征所述第一信息标识的现有房源与所述第二信息标识的期望房源之间的匹配程度；根据所述信息匹配策略得到匹配程度的排序结果；将所述排序结果分别发送给第一请求发起端和/或第二请求发起端。

Description

一种信息处理方法及服务器

技术领域

本发明涉及通讯技术，尤其涉及一种信息处理方法及服务器。

背景技术

随着互联网技术的发展，智能终端的大量普及，能为用户提供的服务类型越来越多，提供服务的方式也越来越多样化，很多服务类型都不仅可以在线下进行操作和办理，也可以在线上进行操作和办理。就线上操作和办理而言，比如，用户可以通过社交关系链、社交网站、社交应用或者在线平台实现“一买一卖”服务的交易。

这种线上操作和办理并不能支持“一买一卖”服务的所有服务类型，比如，对于房屋换购服务类型来说，目前只能实现线下的操作和办理，有线上的功能，也仅仅限于将房屋换购所需的现有房源和求购房源的信息录入数据库而已，实现房屋换购服务时，需要为买卖双方以人工查询的方式逐一查询及匹配某一方的单方面需求(如买方需求或卖方需求)，导致查询的处理效率低和匹配精确度低的问题。然而，相关技术中，对于该问题，尚无有效解决方案。

发明内容

有鉴于此，本发明实施例希望提供一种信息处理方法及服务器，至少解决了现有技术存在的问题。

本发明实施例的技术方案是这样实现的：

本发明实施例的一种信息处理方法，所述方法包括：

获取第一请求，所述第一请求用于提交待交易置换的第一信息；

获取第二请求，所述第二请求用于提交待交易置换的第二信息；

响应所述第一请求，从所述第一请求中解析出所述第一信息；

响应所述第二请求，从所述第二请求中解析出所述第二信息；

提取信息匹配策略，所述信息匹配策略用于表征所述第一信息标识的现有房源与所述第二信息标识的期望房源之间的匹配程度；

根据所述信息匹配策略得到匹配程度的排序结果；

将所述排序结果分别发送给第一请求发起端和/或第二请求发起端。

上述方案中，所述方法还包括：

将所述现有房源的属性按照不同的分类粒度进行划分，得到第一划分结果；

根据第一划分结果将相近似的现有房源进行归类和合并；

所述现有房源的属性包括行业通用属性和专有属性。

上述方案中，所述方法还包括：

将所述期望房源的属性按照不同的分类粒度进行划分，得到第二划分结果；

根据第二划分结果将相近似的期望房源进行归类和合并；

所述期望房源的属性包括行业通用属性和专有属性。

上述方案中，所述按照不同的分类粒度进行划分时，所依据的至少一个划分粒度包括：

按照区县进行划分、按照商圈进行划分、按照小区进行划分、按照楼层进行划分、按照当前楼盘参考价进行划分、按照装修状况进行划分、按照建筑面积进行划分、按照户型进行划分、按照朝向进行划分、按照建筑年代进行划分、按照税费状况进行划分、按照建筑类别进行划分、按照产权性质进行划分、按照房屋结构进行划分。

上述方案中，所述根据所述信息匹配策略得到匹配程度的排序结果，包括：

若所述第一请求发起端和第二请求发起端对应的置换需求为：买卖双方一对一的置换双向需求，则根据所述信息匹配策略计算出对应的两个计算结果；所述两个计算结果中包括买方和卖方的相关结果；

将所述两个计算结果相加后排序，以得到所述排序结果。

上述方案中，所述根据所述信息匹配策略计算出对应的两个计算结果，将所述两个计算结果相加后排序，包括：

当获取到所述现有房源和所述期望房源后，按照所述信息匹配策略中的第一处理策略，对现有房源和期望房源进行分类后添加入房源信息库；

按照所述信息匹配策略中的第二处理策略，从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第一计算结果；

将所述预设套数的房源分别按照各自请求发起端房主的求购房源要求对第一用户现有房源进行打分，去除掉分数低于第一阈值的项目后，得到第二计算结果；

将所述第一计算结果和所述第二计算结果相加后排序，以得到所述排序结果。

上述方案中，所述根据所述信息匹配策略得到匹配程度的排序结果，包括：

若所述第一请求发起端和第二请求发起端对应的置换需求为：买卖双方一对多的置换多向需求，则根据所述信息匹配策略计算出对应的三个计算结果，其中，所述三个计算结果中包括除了买方和卖方的相关结果，还包括中间方的相关结果；

将所述三个计算结果相加后排序，以得到所述排序结果。

上述方案中，所述根据所述信息匹配策略计算出对应的三个计算结果，将所述三个计算结果相加后排序，包括：

检测到使用所述信息匹配策略来针对买卖双方一对一的置换双向需求进行处理时得不到预期的所述排序结果时，则执行针对买卖双方一对多的置换双向需求进行处理的所述信息匹配策略；

按照所述信息匹配策略中的第二处理策略，根据第一用户提交的求购房源从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第一计算结果；

将所述预设套数的房源分别按照各自请求发起端房主的求购房源要求，分别从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第二计算结果；

所有套数的房源按照所述第一计算结果和所述第二计算结果相加排序后，选择排在前面的所述预设套数的房源并作为目标房源，将所述目标房源分别对应到各自请求发起端房主的求购房源。

本发明实施例的一种服务器，所述服务器包括：

第一获取单元，用于获取第一请求，所述第一请求用于提交待交易置换的第一信息；

第二获取单元，用于获取第二请求，所述第二请求用于提交待交易置换的第二信息；

第一响应单元，用于响应所述第一请求，从所述第一请求中解析出所述第一信息；

第二响应单元，用于响应所述第二请求，从所述第二请求中解析出所述第二信息；

提取单元，用于提取信息匹配策略，所述信息匹配策略用于表征所述第一信息标识的现有房源与所述第二信息标识的期望房源之间的匹配程度；

第一处理单元，用于根据所述信息匹配策略得到匹配程度的排序结果；

发送单元，用于将所述排序结果分别发送给第一请求发起端和/或第二请求发起端。

上述方案中，所述服务器还包括：

划分单元，用于将所述现有房源的属性按照不同的分类粒度进行划分，得到第一划分结果；

归类单元，用于根据第一划分结果将相近似的现有房源进行归类和合并；

所述现有房源的属性包括行业通用属性和专有属性。

上述方案中，所述服务器还包括：

划分单元，用于将所述期望房源的属性按照不同的分类粒度进行划分，得到第二划分结果；

归类单元，用于根据第二划分结果将相近似的期望房源进行归类和合并；

所述期望房源的属性包括行业通用属性和专有属性。

上述方案中，所述划分单元，进一步用于：

按照不同的分类粒度进行划分时，所依据的至少一个划分粒度包括：按照区县进行划分、按照商圈进行划分、按照小区进行划分、按照楼层进行划分、按照当前楼盘参考价进行划分、按照装修状况进行划分、按照建筑面积进行划分、按照户型进行划分、按照朝向进行划分、按照建筑年代进行划分、按照税费状况进行划分、按照建筑类别进行划分、按照产权性质进行划分、按照房屋结构进行划分。

上述方案中，所述第一处理单元，进一步用于：

若所述第一请求发起端和第二请求发起端对应的置换需求为：买卖双方一对一的置换双向需求，则根据所述信息匹配策略计算出对应的两个计算结果；所述两个计算结果中包括买方和卖方的相关结果；

将所述两个计算结果相加后排序，以得到所述排序结果。

上述方案中，所述第一处理单元，进一步用于：

当获取到所述现有房源和所述期望房源后，按照所述信息匹配策略中的第一处理策略，对现有房源和期望房源进行分类后添加入房源信息库；

按照所述信息匹配策略中的第二处理策略，从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第一计算结果；

将所述预设套数的房源分别按照各自请求发起端房主的求购房源要求对第一用户现有房源进行打分，去除掉分数低于第一阈值的项目后，得到第二计算结果；

将所述第一计算结果和所述第二计算结果相加后排序，以得到所述排序结果。

上述方案中，所述第一处理单元，进一步用于：

若所述第一请求发起端和第二请求发起端对应的置换需求为：买卖双方一对多的置换多向需求，则根据所述信息匹配策略计算出对应的三个计算结果，其中，所述三个计算结果中包括除了买方和卖方的相关结果，还包括中间方的相关结果；

将所述三个计算结果相加后排序，以得到所述排序结果。

上述方案中，所述第一处理单元，进一步用于：

检测到使用所述信息匹配策略来针对买卖双方一对一的置换双向需求进行处理时得不到预期的所述排序结果时，则执行针对买卖双方一对多的置换双向需求进行处理的所述信息匹配策略；

按照所述信息匹配策略中的第二处理策略，根据第一用户提交的求购房源从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第一计算结果；

将所述预设套数的房源分别按照各自请求发起端房主的求购房源要求，分别从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第二计算结果；

所有套数的房源按照所述第一计算结果和所述第二计算结果相加排序后，选择排在前面的所述预设套数的房源并作为目标房源，将所述目标房源分别对应到各自请求发起端房主的求购房源。

本发明实施例的信息处理方法包括：获取第一请求，所述第一请求用于提交待交易置换的第一信息；获取第二请求，所述第二请求用于提交待交易置换的第二信息；响应所述第一请求，从所述第一请求中解析出所述第一信息；响应所述第二请求，从所述第二请求中解析出所述第二信息；提取信息匹配策略，所述信息匹配策略用于表征所述第一信息标识的现有房源与所述第二信息标识的期望房源之间的匹配程度；根据所述信息匹配策略得到匹配程度的排序结果；将所述排序结果分别发送给第一请求发起端和/或第二请求发起端。

采用本发明实施例，服务器对获取的第一请求和第二请求进行响应后，提取信息匹配策略，所述信息匹配策略用于表征所述第一信息标识的现有房源与所述第二信息标识的期望房源之间的匹配程度；根据所述信息匹配策略得到匹配程度的排序结果；将所述排序结果分别发送给第一请求发起端和/或第二请求发起端，由于可以直接匹配到买方需求和卖方需求，并返回买卖双方的请求发起端，是一种双方面需求的查询和处理，一次匹配就可以知道买方需求和哪个卖方需求相匹配，而无需以人工查询的方式逐一查询及匹配某一方的单方面需求，从而提高了查询的处理效率和匹配精确度。

附图说明

图1为本发明实施例中进行信息交互的各方硬件实体的示意图；

图2为本发明实施例一的方法流程图；

图3为应用本发明实施例的一对一匹配算法进行匹配排序的流程图；

图4为应用本发明实施例的一对多匹配算法进行匹配排序的流程图；

图5为应用本发明实施例四的系统架构示意图；

图6为应用本发明实施例的现有房源(自有房源)的属性列表示意图；

图7为应用本发明实施例的期望房源(求购房源)的属性列表示意图；

图8为应用本发明实施例的匹配算法的一个实现示意图；

图9为应用本发明实施例的楼盘属性存储方式的示意图；

图10为应用本发明实施例的匹配算法的另一个实现示意图。

具体实施方式

下面结合附图对技术方案的实施作进一步的详细描述。

现在将参考附图描述实现本发明各个实施例的移动终端。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明实施例的说明，其本身并没有特定的意义。因此，"模块"与"部件"可以混合地使用。

在下面的详细说明中，陈述了众多的具体细节，以便彻底理解本发明。不过，对于本领域的普通技术人员来说，显然可在没有这些具体细节的情况下实践本发明。在其他情况下，没有详细说明公开的公知方法、过程、组件、电路和网络，以避免不必要地使实施例的各个方面模糊不清。

另外，本文中尽管多次采用术语“第一”、“第二”等来描述各种元件(或各种阈值或各种应用或各种指令或各种操作)等，不过这些元件(或阈值或应用或指令或操作)不应受这些术语的限制。这些术语只是用于区分一个元件(或阈值或应用或指令或操作)和另一个元件(或阈值或应用或指令或操作)。例如，第一操作可以被称为第二操作，第二操作也可以被称为第一操作，而不脱离本发明的范围，第一操作和第二操作都是操作，只是二者并不是相同的操作而已。

本发明实施例中的步骤并不一定是按照所描述的步骤顺序进行处理，可以按照需求有选择的将步骤打乱重排，或者删除实施例中的步骤，或者增加实施例中的步骤，本发明实施例中的步骤描述只是可选的顺序组合，并不代表本发明实施例的所有步骤顺序组合，实施例中的步骤顺序不能认为是对本发明的限制。

本发明实施例中的术语“和/或”指的是包括相关联的列举项目中的一个或多个的任何和全部的可能组合。还要说明的是：当用在本说明书中时，“包括/包含”指定所陈述的特征、整数、步骤、操作、元件和/或组件的存在，但是不排除一个或多个其他特征、整数、步骤、操作、元件和/或组件和/或它们的组群的存在或添加。

本发明实施例的智能终端(如移动终端)可以以各种形式来实施。例如，本发明实施例中描述的移动终端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、个人数字助理(PDA，Personal Digital Assistant)、平板电脑(PAD)、便携式多媒体播放器(PMP，Portable Media Player)、导航装置等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。下面，假设终端是移动终端。然而，本领域技术人员将理解的是，除了特别用于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。

图1为本发明实施例中进行信息交互的各方硬件实体的示意图，图1中包括：服务器11、终端设备21-24，终端设备21-24通过有线网络或者无线网络与服务器进行信息交互，终端设备包括手机、台式机、PC机、一体机等类型。其中，终端设备21-24中存在买房终端和卖方终端，分别发出各种的请求，采用本发明实施例，基于上述图1所示的系统，该信息处理方法包括：获取第一请求(如卖方房主有一套房想要出售，则向服务器发出第一请求，如通过房屋置换中心或房屋置换应用向后台发出该第一请求)，所述第一请求用于提交待交易置换的第一信息(第一信息用于标识现有房源)；获取第二请求(如买方房主想要购买一套房，则向服务器发出第二请求，如通过房屋置换中心或房屋置换应用向后台发出该第二请求)，所述第二请求用于提交待交易置换的第二信息(第二信息用于标识期望房源或称为求购房源)；服务器响应所述第一请求，从所述第一请求中解析出所述第一信息(如现有房源)；响应所述第二请求，从所述第二请求中解析出所述第二信息(如期望房源或称为求购房源)；提取信息匹配策略(该策略具体为现有房源与用户期望房源之间匹配度的经验公式，包括一对一场景和一对多场景下不同的匹配算法)，所述信息匹配策略用于表征所述第一信息标识的现有房源与所述第二信息标识的期望房源之间的匹配程度；根据所述信息匹配策略得到匹配程度的排序结果；将所述排序结果分别发送给第一请求发起端和/或第二请求发起端。

可见：本发明实施例有别于现有技术，现有技术是房屋换购所需的现有房源和求购房源的信息录入数据库而已，实现房屋换购服务时，需要为买卖双方以人工查询的方式逐一查询及匹配某一方的单方面需求(如买方需求或卖方需求)，而本发明实施例体现的是双方或多方需求的满足，而不是单方面的需求，对各个房主发起的至少两个请求进行响应，然后对该至少两个请求进行自动匹配，匹配得到排序结果，将排序结果作为推荐信息提供给各个房主进行选择。采用本发明实施例，能满足置换双向需求(同时满足买方需求和卖方需求)或置换多向需求(同时满足买方需求、中间方需求和卖方需求)。

上述图1的例子只是实现本发明实施例的一个系统架构实例，本发明实施例并不限于上述图1所述的系统结构，提出本发明方法各个实施例。

实施例一：

本发明实施例的一种信息处理方法，如图2所示，所述方法包括：

步骤101、获取第一请求，所述第一请求用于提交待交易置换的第一信息。

这里，本步骤的一个实例为：获取第一请求(如卖方房主有一套房想要出售，则向服务器发出第一请求，如通过房屋置换中心或房屋置换应用向后台发出该第一请求)，所述第一请求用于提交待交易置换的第一信息，第一信息用于标识现有房源。

这里，第一请求的请求发起者可以是服务器侧的操作人员，比如房产中介公司的房产经纪，这是房产中介手工录入信息后，对买卖双方的双方需求进行的查询和匹配场景。第一请求的请求发起者还可以是服务器收到终端用户通过终端上安装的社交应用，社交网络，在线网站发送的第一请求，此时，第一请求的请求发起者为请求房屋换购的用户自身(如第一终端用户自身)，请求房屋换购的用户自身(如第一终端用户自身)在线上自主发出请求后，服务器收到第一请求后，自主进行查询和匹配的场景，相应的，步骤102中发起第二请求的请求发起者为请求房屋换购的对端用户自身(如第二终端用户自身)，请求房屋换购的用户自身(如第二终端用户自身)在线上自主发出请求后，服务器收到第二请求后，自主进行查询和匹配的场景，如果第一终端和第二终端都发起请求，则同时为二者适配自主进行查询和匹配的场景。

本发明实施例还适用于如下场景；

一个实例为：用户可以为第一信息标识的第一用户(如用户A)和第二信息标识的第二用户，(如用户B)，用户A和用户B可以为不同用户，比如，用户A不着急出手，只是先挂一下现有房源信息，想向房产中介咨询下备选方案的场景，则第一用户和第二用户分别为符合待交易置换双向需求的买卖双方用户。另一个实例为：用户也可以为第一用户(如用户A)自己，第一用户(如用户A)同时有卖和买的需求，如用户A着急出手，需要第一时间得到置换信息，好进行交易的场景。

步骤102、获取第二请求，所述第二请求用于提交待交易置换的第二信息。

本步骤的一个实例为：获取第二请求(如买方房主想要购买一套房，则向服务器发出第二请求，如通过房屋置换中心或房屋置换应用向后台发出该第二请求)，所述第二请求用于提交待交易置换的第二信息，第二信息用于标识期望房源或称为求购房源。

步骤103、响应所述第一请求，从所述第一请求中解析出所述第一信息。

步骤104、响应所述第二请求，从所述第二请求中解析出所述第二信息。

步骤105、提取信息匹配策略，所述信息匹配策略用于表征所述第一信息标识的现有房源与所述第二信息标识的期望房源之间的匹配程度。

这里，所述信息匹配策略可以为现有房源与用户期望房源之间匹配度的匹配算法，包括买卖双方为一对一的场景，还可以包括买卖双方为一对多的场景。

步骤106、根据所述信息匹配策略得到匹配程度的排序结果。

步骤107、将所述排序结果分别发送给第一请求发起端和/或第二请求发起端。

这里，以用户登录社交应用进行房屋置换交易为例，房屋置换交易包括：买房买房、租房、长期租房或短期租房等各种场景。则服务器基于第一请求和第二请求的交互处理的一个实例为：一方在第一终端发起第一请求，另一方在另一终端(第二终端)发起第二请求，两个请求汇总到服务器时，服务器分别得到这两个请求，利用所述信息匹配策略(如预设的“一对一匹配”匹配算法或“一对多匹配”匹配算法)进行自动匹配，并将匹配结果(进一步是根据匹配结果得到的排序结果)分别发送给发起第一请求的第一终端和发起第二请求的第二终端，从而，实现完全自动，和同时满足双向需求的买卖置换交易。

采用本发明实施例，由于可以直接匹配到买方需求和卖方需求，并返回买卖双方的请求发起端，是一种双方面需求的查询和处理，一次匹配就可以知道买方需求和哪个卖方需求相匹配，而无需以人工查询的方式逐一查询及匹配某一方的单方面需求，从而提高了查询的处理效率和匹配精确度。

实施例二：

本发明实施例的一种信息处理方法，所述方法包括：

步骤201、获取第一请求，所述第一请求用于提交待交易置换的第一信息。

这里，本步骤的一个实例为：获取第一请求(如卖方房主有一套房想要出售，则向服务器发出第一请求，如通过房屋置换中心或房屋置换应用向后台发出该第一请求)，所述第一请求用于提交待交易置换的第一信息，第一信息用于标识现有房源。

这里，第一请求的请求发起者可以是服务器侧的操作人员，比如房产中介公司的房产经纪，这是房产中介手工录入信息后，对买卖双方的双方需求进行的查询和匹配场景。第一请求的请求发起者还可以是服务器收到终端用户通过终端上安装的社交应用，社交网络，在线网站发送的第一请求，此时，第一请求的请求发起者为请求房屋换购的用户自身(如第一终端用户自身)，请求房屋换购的用户自身(如第一终端用户自身)在线上自主发出请求后，服务器收到第一请求后，自主进行查询和匹配的场景，相应的，步骤202中发起第二请求的请求发起者为请求房屋换购的对端用户自身(如第二终端用户自身)，请求房屋换购的用户自身(如第二终端用户自身)在线上自主发出请求后，服务器收到第二请求后，自主进行查询和匹配的场景，如果第一终端和第二终端都发起请求，则同时为二者适配自主进行查询和匹配的场景。

本发明实施例还适用于如下场景；

一个实例为：用户可以为第一信息标识的第一用户(如用户A)和第二信息标识的第二用户，(如用户B)，用户A和用户B可以为不同用户，比如，用户A不着急出手，只是先挂一下现有房源信息，想向房产中介咨询下备选方案的场景，则第一用户和第二用户分别为符合待交易置换双向需求的买卖双方用户。另一个实例为：用户也可以为第一用户(如用户A)自己，第一用户(如用户A)同时有卖和买的需求，如用户A着急出手，需要第一时间得到置换信息，好进行交易的场景。

步骤202、获取第二请求，所述第二请求用于提交待交易置换的第二信息。

本步骤的一个实例为：获取第二请求(如买方房主想要购买一套房，则向服务器发出第二请求，如通过房屋置换中心或房屋置换应用向后台发出该第二请求)，所述第二请求用于提交待交易置换的第二信息，第二信息用于标识期望房源或称为求购房源。

步骤203、响应所述第一请求，从所述第一请求中解析出所述第一信息。

步骤204、响应所述第二请求，从所述第二请求中解析出所述第二信息。

步骤205、提取信息匹配策略，所述信息匹配策略用于表征所述第一信息标识的现有房源与所述第二信息标识的期望房源之间的匹配程度。

这里，所述信息匹配策略可以为现有房源与用户期望房源之间匹配度的匹配算法，包括买卖双方为一对一的场景，还可以包括买卖双方为一对多的场景。

步骤206、根据所述信息匹配策略得到匹配程度的排序结果。

步骤207、将所述排序结果分别发送给第一请求发起端和/或第二请求发起端。

这里，以用户登录社交应用进行房屋置换交易为例，房屋置换交易包括：买房买房、租房、长期租房或短期租房等各种场景。则服务器基于第一请求和第二请求的交互处理的一个实例为：一方在第一终端发起第一请求，另一方在另一终端(第二终端)发起第二请求，两个请求汇总到服务器时，服务器分别得到这两个请求，利用所述信息匹配策略(如预设的“一对一匹配”匹配算法或“一对多匹配”匹配算法)进行自动匹配，并将匹配结果(进一步是根据匹配结果得到的排序结果)分别发送给发起第一请求的第一终端和发起第二请求的第二终端，从而，实现完全自动，和同时满足双向需求的买卖置换交易。

在本发明实施例一实施方式中，所述方法还包括：对现有房源和期望房源分别进行划分，归类和合并处理。二者的原理是一样的，只是针对的房源数据不同。1)将所述现有房源的属性按照不同的分类粒度进行划分，得到第一划分结果；根据第一划分结果将相近似的现有房源进行归类和合并；所述现有房源的属性包括行业通用属性和专有属性。2)将所述期望房源的属性按照不同的分类粒度进行划分，得到第二划分结果；根据第二划分结果将相近似的期望房源进行归类和合并；所述期望房源的属性包括行业通用属性和专有属性。划分能达到的有益效果是：虽然房源的具体属性共有16个，是房产行业通用标准，但是在各个房源属性中如何将近似的房源进行归类合并是减少计算量，增加成交机会的关键；因此对于各个房源属性按照不同的粒度进行划分(或称区分)就变得十分重要，能提高查询和处理速度，大量节约时间成本。

由于针对现有房源和期望房源划分的原理是一样的，只是针对的房源数据不同，因此，二者，划分的机制在这里统一说明一下。所述按照不同的分类粒度进行划分时，所依据的至少一个划分粒度包括：按照区县进行划分、按照商圈进行划分、按照小区进行划分、按照楼层进行划分、按照当前楼盘参考价进行划分、按照装修状况进行划分、按照建筑面积进行划分、按照户型进行划分、按照朝向进行划分、按照建筑年代进行划分、按照税费状况进行划分、按照建筑类别进行划分、按照产权性质进行划分、按照房屋结构进行划分。

其中，现有房源和期望房源都共有16个属性，但是不是针对每个属性都进行划分，一个实际划分规则如下所示：

1)区县：按照所在城市的行政区域划分；

2)商圈：按照房产行业约定俗成的商圈划分规则区分；

3)小区：按照楼盘的全称、简称、通称、别名等名称进行合并，并进行编号区分；

4)楼栋号：不进行区分；

5)楼层：按照物理楼层区分；

6)当前楼盘参考价：按照当地市场房屋均价除以10为一档，进行区分；

7)装修状况：统一分为毛坯、简装、中装、精装、豪装共5档，并提供相应定义标准；

8)面积：按照10平方米一个档次进行区分；

9)户型：按照居室个数进行区分；

10)朝向：按照南北通透、东西向、朝东、朝南、朝西、朝北分档进行区分；

11)建筑年代：按照每2年一个档次进行区分；

12)税费状况：按照普宅满2年、普宅不满2年、非普宅分档进行区分；

13)建筑类别：按照板楼、塔楼、平房进行区分；

14)产权性质：按照公产、企业产、私产、商住分档进行区分；

15)房屋结构：按照平层、复式、跃层、错层、开间分档进行区分；

16)厌恶因素：不进行区分。

采用本发明实施例，由于可以直接匹配到买方需求和卖方需求，并返回买卖双方的请求发起端，是一种双方面需求的查询和处理，一次匹配就可以知道买方需求和哪个卖方需求相匹配，而无需以人工查询的方式逐一查询及匹配某一方的单方面需求，从而提高了查询的处理效率和匹配精确度，且通过本发明实施例的预先属性划分，归类和合并，将这些归类合并信息添加到房源信息库，以备后续查询和匹配使用，能进一步提高查询的处理效率和匹配精确度。

实施例三：

基于上述各个实施例，本发明实施例的一种信息处理方法，可以采取包括预设的“一对一匹配”匹配算法或“一对多匹配”匹配算法进行自动匹配，并将匹配结果(进一步是根据匹配结果得到的排序结果)分别发送给发起第一请求的第一终端和发起第二请求的第二终端，从而，实现完全自动，和同时满足双向需求的买卖置换交易。预设的“一对一匹配”匹配算法或“一对多匹配”匹配算法即为上述实施例提及的所述信息匹配策略。

所述信息匹配策略有两种具体实现方式，分别针对不同的应用场景，以下具体阐述：

一，买卖双方1对1的场景，采用预设的“一对一匹配”匹配算法。对于买卖双方，通过1对1的交易匹配算法，经二次计算结果相加排序，提供给换房用户。具体的，若所述第一请求发起端和第二请求发起端对应的置换需求为：买卖双方一对一的置换双向需求，则根据所述信息匹配策略计算出对应的两个计算结果；所述两个计算结果中包括买方和卖方的相关结果；将所述两个计算结果相加后排序，以得到所述排序结果。

如图3所示为采用预设的“一对一匹配”匹配算法进行匹配排序的过程，包括：

步骤301、当获取到所述现有房源(第一信息标识的现有房源)和所述期望房源(第二信息标识的期望房源)后，按照所述信息匹配策略中的第一处理策略(现有房源处理方式)，对现有房源和期望房源进行分类后添加入房源信息库；

步骤302、按照所述信息匹配策略中的第二处理策略(求购房源/期望房源处理)，从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第一计算结果；

步骤303、将所述预设套数的房源分别按照各自请求发起端房主的求购房源要求对第一用户现有房源进行打分，去除掉分数低于第一阈值的项目后，得到第二计算结果；

步骤304、将所述第一计算结果和所述第二计算结果相加后排序，以得到所述排序结果。

一个实际应用中，当用户A提交现有房源和求购房源后，按照现有房源处理方法对房源进行分类入库，按照求购房源处理方法从库中筛选出得分最高且大于40分的100套房源；再将这100套房源分别按照各自房主的求购房源要求对用户A现有房源进行打分，去除掉分数低于40分的项目后，按照两次计算的结果相加进行排序提供给用户选择。

一，买卖双方1对多的场景，采用预设的“一对多匹配”匹配算法。对于买卖双方，通过1对多的交易匹配算法，经三次计算结果相加排序，提供给换房用户。具体的，若所述第一请求发起端和第二请求发起端对应的置换需求为：买卖双方一对多的置换多向需求，则根据所述信息匹配策略计算出对应的三个计算结果，其中，所述三个计算结果中包括除了买方和卖方的相关结果，还包括中间方的相关结果；将所述三个计算结果相加后排序，以得到所述排序结果。

如图4所示为采用预设的“一对多匹配”匹配算法进行匹配排序的过程，先检测到使用所述信息匹配策略来针对买卖双方一对一的置换双向需求进行处理时得不到预期的所述排序结果时，则执行针对买卖双方一对多的置换双向需求进行处理的所述信息匹配策略，在执行针对买卖双方一对多的置换双向需求进行处理的所述信息匹配策略的过程中，包括：

步骤401、按照所述信息匹配策略中的第二处理策略(求购房源/期望房源处理)，根据第一用户提交的求购房源从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第一计算结果；

步骤402、将所述预设套数的房源分别按照各自请求发起端房主的求购房源要求，分别从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第二计算结果；

步骤403、所有套数的房源按照所述第一计算结果和所述第二计算结果相加得到第三计算结果并排序后，选择排在前面的所述预设套数的房源并作为目标房源，将所述目标房源分别对应到各自请求发起端房主的求购房源。

一个实际应用中，如果通过1对1匹配算法无法获得结果，则需要进入1对多匹配算法。1对多匹配算法包括：按照求购房源处理方法，根据用户A提交的求购房源从库中筛选出得分最高且大于40分的100套房源；再将这100套房源分别按照各自房主的求购房源要求，按照求购房源处理方法，分别从库中筛选出得分最高且大于40分的100套房源；将所有10000套房源按照两次计算得分相加排序取前100套房源，然后取出这100套房源分别按照各自房主的求购房源要求对用户A现有房源进行打分，去除掉分数低于40分的项目后，按照三次计算的结果相加进行排序提供给用户选择。

实施例四：

本发明实施例的一种信息处理系统，包括第一终端31、第二终端32和服务器33，第一终端31用于发起第一请求，第二终端32用于发起第二请求，如图5所示，所述服务器33包括：第一获取单元331，用于获取第一请求，所述第一请求用于提交待交易置换的第一信息；第二获取单元332，用于获取第二请求，所述第二请求用于提交待交易置换的第二信息；第一响应单元333，用于响应所述第一请求，从所述第一请求中解析出所述第一信息；第二响应单元334，用于响应所述第二请求，从所述第二请求中解析出所述第二信息；提取单元335，用于提取信息匹配策略，所述信息匹配策略用于表征所述第一信息标识的现有房源与所述第二信息标识的期望房源之间的匹配程度；第一处理单元336，用于根据所述信息匹配策略得到匹配程度的排序结果；发送单元337，用于将所述排序结果分别发送给第一请求发起端(如第一终端31)和/或第二请求发起端(如第二终端32)。

第一请求的请求发起者可以是服务器侧的操作人员，比如房产中介公司的房产经纪，这是房产中介手工录入信息后，对买卖双方的双方需求进行的查询和匹配场景。第一请求的请求发起者还可以是服务器收到终端用户通过终端上安装的社交应用，社交网络，在线网站发送的第一请求，此时，第一请求的请求发起者为请求房屋换购的用户自身(如第一终端用户自身)，请求房屋换购的用户自身(如第一终端用户自身)在线上自主发出请求后，服务器收到第一请求后，自主进行查询和匹配的场景，相应的，步骤102中发起第二请求的请求发起者为请求房屋换购的对端用户自身(如第二终端用户自身)，请求房屋换购的用户自身(如第二终端用户自身)在线上自主发出请求后，服务器收到第二请求后，自主进行查询和匹配的场景，如果第一终端和第二终端都发起请求，则同时为二者适配自主进行查询和匹配的场景。获取第二请求(如买方房主想要购买一套房，则向服务器发出第二请求，如通过房屋置换中心或房屋置换应用向后台发出该第二请求)，所述第二请求用于提交待交易置换的第二信息，第二信息用于标识期望房源或称为求购房源。

本发明实施例还适用于如下场景；

一个实例为：用户可以为第一信息标识的第一用户(如用户A)和第二信息标识的第二用户，(如用户B)，用户A和用户B可以为不同用户，比如，用户A不着急出手，只是先挂一下现有房源信息，想向房产中介咨询下备选方案的场景，则第一用户和第二用户分别为符合待交易置换双向需求的买卖双方用户。另一个实例为：用户也可以为第一用户(如用户A)自己，第一用户(如用户A)同时有卖和买的需求，如用户A着急出手，需要第一时间得到置换信息，好进行交易的场景。

这里，所述信息匹配策略可以为现有房源与用户期望房源之间匹配度的匹配算法，包括买卖双方为一对一的场景，还可以包括买卖双方为一对多的场景。

这里，以用户登录社交应用进行房屋置换交易为例，房屋置换交易包括：买房买房、租房、长期租房或短期租房等各种场景。则服务器基于第一请求和第二请求的交互处理的一个实例为：一方在第一终端发起第一请求，另一方在另一终端(第二终端)发起第二请求，两个请求汇总到服务器时，服务器分别得到这两个请求，利用所述信息匹配策略(如预设的“一对一匹配”匹配算法或“一对多匹配”匹配算法)进行自动匹配，并将匹配结果(进一步是根据匹配结果得到的排序结果)分别发送给发起第一请求的第一终端和发起第二请求的第二终端，从而，实现完全自动，和同时满足双向需求的买卖置换交易。

采用本发明实施例，由于可以直接匹配到买方需求和卖方需求，并返回买卖双方的请求发起端，是一种双方面需求的查询和处理，一次匹配就可以知道买方需求和哪个卖方需求相匹配，而无需以人工查询的方式逐一查询及匹配某一方的单方面需求，从而提高了查询的处理效率和匹配精确度。

在本发明实施例一实施方式中，所述服务器还包括：划分单元，用于将所述现有房源的属性按照不同的分类粒度进行划分，得到第一划分结果；归类单元，用于根据第一划分结果将相近似的现有房源进行归类和合并；所述现有房源的属性包括行业通用属性和专有属性。

在本发明实施例一实施方式中，所述服务器还包括：划分单元，用于将所述期望房源的属性按照不同的分类粒度进行划分，得到第二划分结果；归类单元，用于根据第二划分结果将相近似的期望房源进行归类和合并；所述期望房源的属性包括行业通用属性和专有属性。

在本发明实施例一实施方式中，所述划分单元，进一步用于：按照不同的分类粒度进行划分时，所依据的至少一个划分粒度包括：按照区县进行划分、按照商圈进行划分、按照小区进行划分、按照楼层进行划分、按照当前楼盘参考价进行划分、按照装修状况进行划分、按照建筑面积进行划分、按照户型进行划分、按照朝向进行划分、按照建筑年代进行划分、按照税费状况进行划分、按照建筑类别进行划分、按照产权性质进行划分、按照房屋结构进行划分。

在本发明实施例一实施方式中，所述第一处理单元，进一步用于：若所述第一请求发起端和第二请求发起端对应的置换需求为：买卖双方一对一的置换双向需求，则根据所述信息匹配策略计算出对应的两个计算结果；所述两个计算结果中包括买方和卖方的相关结果；将所述两个计算结果相加后排序，以得到所述排序结果。

在本发明实施例一实施方式中，所述第一处理单元，进一步用于：当获取到所述现有房源和所述期望房源后，按照所述信息匹配策略中的第一处理策略，对现有房源和期望房源进行分类后添加入房源信息库；按照所述信息匹配策略中的第二处理策略，从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第一计算结果；将所述预设套数的房源分别按照各自请求发起端房主的求购房源要求对第一用户现有房源进行打分，去除掉分数低于第一阈值的项目后，得到第二计算结果；将所述第一计算结果和所述第二计算结果相加后排序，以得到所述排序结果。

在本发明实施例一实施方式中，所述第一处理单元，进一步用于：若所述第一请求发起端和第二请求发起端对应的置换需求为：买卖双方一对多的置换多向需求，则根据所述信息匹配策略计算出对应的三个计算结果，其中，所述三个计算结果中包括除了买方和卖方的相关结果，还包括中间方的相关结果；将所述三个计算结果相加后排序，以得到所述排序结果。

在本发明实施例一实施方式中，所述第一处理单元，进一步用于：检测到使用所述信息匹配策略来针对买卖双方一对一的置换双向需求进行处理时得不到预期的所述排序结果时，则执行针对买卖双方一对多的置换双向需求进行处理的所述信息匹配策略；按照所述信息匹配策略中的第二处理策略，根据第一用户提交的求购房源从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第一计算结果；将所述预设套数的房源分别按照各自请求发起端房主的求购房源要求，分别从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第二计算结果；所有套数的房源按照所述第一计算结果和所述第二计算结果相加排序后，选择排在前面的所述预设套数的房源并作为目标房源，将所述目标房源分别对应到各自请求发起端房主的求购房源。

这里需要指出的是，上述终端可以为PC这种电子设备，还可以为如PAD，平板电脑，手提电脑这种便携电子设备、还可以为如手机这种智能移动终端，不限于这里的描述；所述服务器可以是通过集群系统构成的，为实现各单元功能而合并为一或各单元功能分体设置的电子设备，终端和服务器都至少包括用于存储数据的数据库和用于数据处理的处理器，或者包括设置于服务器内的存储介质或独立设置的存储介质。

其中，对于用于数据处理的处理器而言，在执行处理时，可以采用微处理器、中央处理器(CPU，Central Processing Unit)、数字信号处理器(DSP，Digital SingnalProcessor)或可编程逻辑阵列(FPGA，Field－Programmable Gate Array)实现；对于存储介质来说，包含操作指令，该操作指令可以为计算机可执行代码，通过所述操作指令来实现上述本发明实施例信息处理方法流程中的各个步骤。

这里需要指出的是：以上涉及终端和服务器项的描述，与上述方法描述是类似的，同方法的有益效果描述，不做赘述。对于本发明终端和服务器实施例中未披露的技术细节，请参照本发明方法流程描述的实施例所描述内容。

以一个现实应用场景为例对本发明实施例阐述如下：

本应用场景采用本发明实施例，在服务类型为房产置换交易的情况下，可以为基于多人房产置换交易的匹配及查询方案。先对本文涉及的用语进行解释说明：1)现有房源：指换房用户提交的自有房源，用户提交自有房源时需要明确指定自有房源的具体属性。2)求购房源：指换房用户提交的期望购买的房源，用户提交求购房源时需要对求购房源的期望属性进行指定范围，并对期望属性的重要度进行主动排序。3)现有房源处理方法：指应用本发明实施例所阐述的方法对换房用户提交的自有房源进行处理的方法。4)求购房源处理方法：指应用本发明实施例所阐述的方法对换房用户提交的求购房源进行处理的方法。5)房源基本属性评分规则：指利用本专利所阐述的评估房源库中现有房源与换房用户求购房源匹配度的评分规则。6)1对1的交易匹配算法：指应用本发明实施例所阐述的匹配算法将两名换房用户直接进行撮合匹配的算法。7)多人交易匹配算法：指应用本发明实施例所阐述的匹配算法将两名以上换房用户间接进行撮合匹配的算法。7)房源信息库：指换房用户提交的自有房源库，按照自有房源的具体属性分表存放，便于快速检索。8)换房用户：指目前拥有一套房源，并且有换房需求的用户，是应用本发明实施例的目标用户。9)自有房源具体属性：指换房用户自有房源的具体属性，包括下图6-7中的“1-16项”所示，其中，图6为现有房源(自有房源)的属性列表，图7为期望房源(求购房源)的属性列表(换房用户求购房源的期望属性)，下图6-7中的属性都为二手房行业通用属性，各属性的取值范围为行业通用标准。其中，图6-7中的“1-16项”，第4项“楼栋号”、第6项“当前楼盘参考价”、第7项“装修状况”不好量化，存在主观因素，为了准确匹配的考虑，根据用户需求可以有选择的采用，如买时不列入计算。

采用现有技术，只能满足单方面需求，如用户需要置换房产时，需要先卖掉自有住房，无法预知后续购买房屋时的情况，存在不确定性；用户需要置换房产时需要先卖后买，一买一卖的时间衔接存在不确定性，都不能精确匹配买卖双方的双向需求。比如，房屋中介网站目前只提供买房信息和卖房信息的发布和检索功能，线下门店只提供房屋的买卖居间服务，只能针对1套房源匹配出买方和卖方，无法直接满足用户房产置换的需求，在房屋置换交易中需要通过多次交易来实现，不仅处理效率低，匹配度也不高，为了解决买卖双向需求匹配不精确的问题，本应用场景采用本发明实施例，实现了一种基于多人房产交易的匹配方法，在进行交易前先帮助用户锁定自有房屋的买家和求购房屋的卖家，存在不确定性，匹配精确，查询和处理效率都很高。

在一个实际应用中，本应用场景采用本发明实施例，应用上述信息处理系统进行匹配的算法示意图如图8所示，A11所标识的运算部分为“一对一”匹配算法，适用于包括“买、卖双方”的场景。“一对一”匹配算法是“一对多”匹配算法的基础。A12所标识的运算部分为除了买、卖双方，还包括中间方(如第三人)的“买、卖，第三人”的场景中涉及第三人的算法，第三人的算法也是一对一”匹配算法，只是把每一个可能输出项与上述买、卖双方做“一对一”匹配，最终把评分加起来进行排序(如，将得到分值先排序，去掉太低的分，然后再相加，总分再排序)。

在一个实际应用中，本应用场景采用本发明实施例，房源具体属性的区分粒度：指自有房源和求购房源的各属性中，每个属性按照取值进行归档分类的标准，此标准是为了对房源属性进行标准化分类。具体来说，就房源具体属性的区分粒度而言，房源的具体属性共有16个，是房产行业通用标准；但是在各个房源属性中如何将近似的房源进行归类合并是减少计算量，增加成交机会的关键；因此对于各个房源属性按照不同的粒度进行区分就非常有必要。划分规则具体如下：

区县：按照所在城市的行政区域划分；

商圈：按照房产行业约定俗成的商圈划分规则区分；

小区：按照楼盘的全称、简称、通称、别名等名称进行合并，并进行编号区分；

楼栋号：不进行区分；

楼层：按照物理楼层区分；

当前楼盘参考价：按照当地市场房屋均价除以10为一档，进行区分；

装修状况：统一分为毛坯、简装、中装、精装、豪装共5档，并提供相应定义标准；

面积：按照10平方米一个档次进行区分；

户型：按照居室个数进行区分；

朝向：按照南北通透、东西向、朝东、朝南、朝西、朝北分档进行区分；

建筑年代：按照每2年一个档次进行区分；

税费状况：按照普宅满2年、普宅不满2年、非普宅分档进行区分；

建筑类别：按照板楼、塔楼、平房进行区分；

产权性质：按照公产、企业产、私产、商住分档进行区分；

房屋结构：按照平层、复式、跃层、错层、开间分档进行区分；

厌恶因素：不进行区分。

在一个实际应用中，本应用场景采用本发明实施例，所述现有房源的处理方法包括：按照现有房源的16个具体属性对应建立16张表，分别存放每个房源的不同属性；换房用户提交现有房源后，将现有房源的编号A分别按照16个具体属性的维度对应存入相应的图9中，图9为描述各个楼盘属性的存储方式，如a和b是楼盘id的举例，标识楼盘a和b分别对应的id值。

在一个实际应用中，本应用场景采用本发明实施例，就所述求购房源期望属性的打分规则而言，由于房源是一个特殊商品，每个房源具有一些通用属性的同时还具有唯一的特性，对于用户的期望很难100％满足，因此通过本规则尽可能多的满足用户需求，通过本规则，来制定一套现有房源与用户期望房源之间匹配度的经验公式。具体描述如下：

区县：命中指定区县1分、命中指定区县周边区县0.8分；

商圈：命中指定商圈1分、命中指定商圈周边商圈0.9分；

小区：命中指定小区1分，命中指定小区1KM范围小区0.7分，命中指定小区2KM范围小区0.5分；

楼层：命中指定范围楼层1分，命中指定楼层上下1层0.8分，上下两层0.5分；

面积：命中指定范围面积1分，命中指定面积上下10平米0.8分，上下20平米0.5分；

户型：命中指定户型1分，命中指定户型相邻户型0.8分；

朝向：命中指定朝向1分，其他朝向0.5分；

建筑年代：命中指定范围建筑年代1分，距离指定范围每10年减0.1分；

税费状况：命中指定税费状况1分，其他税费状况0.5分；

建筑类别：命中指定建筑类别1分，其他建筑类别0.5分；

产权性质：命中指定产权性质1分，其他产权性质0.5分；

房屋结构：命中房屋结构1分，其他房屋结构0.5分；

总价范围：指定房源楼盘参考价*面积命中范围1分，距离范围每1万元减0.1分；

楼栋号、装修状况、厌恶因素：不计入打分范围。

在一个实际应用中，本应用场景采用本发明实施例，所述求购房源的处理方法包括：由于房源是一个特殊商品，每个房源具有一些通用属性的同时还具有唯一的特性，因此能够按照全部属性找到100％匹配的房源是小概率事件，为了更好的找到相对匹配的房源，要求用户在填写求购房源需求时对关注的房源属性进行主动排序，根据用户的排序情况依次进行匹配并对匹配结果按照如下公式进行打分，根据打分结果进行排序。根据用户输入的各个选项按照《房源基本属性打分规则》对所有房源进行打分，然后按照用户排定的前3项*10，4-8项*3，9-16项*1对房源进行打分，根据房源得分进行排序。

在一个实际应用中，本应用场景采用本发明实施例，如图10所示，为揭示1对1和1对多的交易匹配算法实现示意图，E1、就1对1的交易匹配算法而言，当用户A提交现有房源和求购房源后，按照现有房源处理方法对房源进行分类入库，按照求购房源处理方法，第一步，从库中筛选出得分最高且大于40分的100套房源；第二步，再将这100套房源分别按照各自房主的求购房源要求对用户A现有房源进行打分，去除掉分数低于40分的项目后，按照两次计算的结果相加进行排序提供给用户选择。E2、就一对多的交易匹配算法而言，如果通过1对1匹配算法无法获得结果时，则需要进入多人匹配算法。一对多匹配算法包括：第一步，按照求购房源处理方法，根据用户A提交的求购房源从库中，筛选出得分最高且大于40分的100套房源；第二步，再将这100套房源分别按照各自房主的求购房源要求，按照求购房源处理方法，分别从库中筛选出得分最高且大于40分的100套房源；第三步，将所有10000套房源按照两次计算得分相加排序取前100套房源，然后取出这100套房源分别按照各自房主的求购房源要求对用户A现有房源进行打分，去除掉分数低于40分的项目后，按照三次计算的结果相加进行排序提供给用户选择。

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

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

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

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

或者，本发明上述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (16)

1.一种信息处理方法，其特征在于，所述方法包括：

获取第一请求，所述第一请求用于提交待交易置换的第一信息；

获取第二请求，所述第二请求用于提交待交易置换的第二信息；

响应所述第一请求，从所述第一请求中解析出所述第一信息；

响应所述第二请求，从所述第二请求中解析出所述第二信息；

提取信息匹配策略，所述信息匹配策略用于表征所述第一信息标识的现有房源与所述第二信息标识的期望房源之间的匹配程度；

根据所述信息匹配策略得到匹配程度的排序结果；

将所述排序结果分别发送给第一请求发起端和/或第二请求发起端。

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

将所述现有房源的属性按照不同的分类粒度进行划分，得到第一划分结果；

根据第一划分结果将相近似的现有房源进行归类和合并；

所述现有房源的属性包括行业通用属性和专有属性。

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

将所述期望房源的属性按照不同的分类粒度进行划分，得到第二划分结果；

根据第二划分结果将相近似的期望房源进行归类和合并；

所述期望房源的属性包括行业通用属性和专有属性。

4.根据权利要求2或3所述的方法，其特征在于，所述按照不同的分类粒度进行划分时，所依据的至少一个划分粒度包括：

按照区县进行划分、按照商圈进行划分、按照小区进行划分、按照楼层进行划分、按照当前楼盘参考价进行划分、按照装修状况进行划分、按照建筑面积进行划分、按照户型进行划分、按照朝向进行划分、按照建筑年代进行划分、按照税费状况进行划分、按照建筑类别进行划分、按照产权性质进行划分、按照房屋结构进行划分。

5.根据权利要求4所述的方法，其特征在于，所述根据所述信息匹配策略得到匹配程度的排序结果，包括：

若所述第一请求发起端和第二请求发起端对应的置换需求为：买卖双方一对一的置换双向需求，则根据所述信息匹配策略计算出对应的两个计算结果；所述两个计算结果中包括买方和卖方的相关结果；

将所述两个计算结果相加后排序，以得到所述排序结果。

6.根据权利要求5所述的方法，其特征在于，所述根据所述信息匹配策略计算出对应的两个计算结果，将所述两个计算结果相加后排序，包括：

当获取到所述现有房源和所述期望房源后，按照所述信息匹配策略中的第一处理策略，对现有房源和期望房源进行分类后添加入房源信息库；

按照所述信息匹配策略中的第二处理策略，从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第一计算结果；

将所述预设套数的房源分别按照各自请求发起端房主的求购房源要求对第一用户现有房源进行打分，去除掉分数低于第一阈值的项目后，得到第二计算结果；

将所述第一计算结果和所述第二计算结果相加后排序，以得到所述排序结果。

7.根据权利要求4所述的方法，其特征在于，所述根据所述信息匹配策略得到匹配程度的排序结果，包括：

若所述第一请求发起端和第二请求发起端对应的置换需求为：买卖双方一对多的置换多向需求，则根据所述信息匹配策略计算出对应的三个计算结果，其中，所述三个计算结果中包括除了买方和卖方的相关结果，还包括中间方的相关结果；

将所述三个计算结果相加后排序，以得到所述排序结果。

8.根据权利要求7所述的方法，其特征在于，所述根据所述信息匹配策略计算出对应的三个计算结果，将所述三个计算结果相加后排序，包括：

检测到使用所述信息匹配策略来针对买卖双方一对一的置换双向需求进行处理时得不到预期的所述排序结果时，则执行针对买卖双方一对多的置换双向需求进行处理的所述信息匹配策略；

按照所述信息匹配策略中的第二处理策略，根据第一用户提交的求购房源从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第一计算结果；

将所述预设套数的房源分别按照各自请求发起端房主的求购房源要求，分别从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第二计算结果；

所有套数的房源按照所述第一计算结果和所述第二计算结果相加排序后，选择排在前面的所述预设套数的房源并作为目标房源，将所述目标房源分别对应到各自请求发起端房主的求购房源。

9.一种服务器，其特征在于，所述服务器包括：

第一获取单元，用于获取第一请求，所述第一请求用于提交待交易置换的第一信息；

第二获取单元，用于获取第二请求，所述第二请求用于提交待交易置换的第二信息；

第一响应单元，用于响应所述第一请求，从所述第一请求中解析出所述第一信息；

第二响应单元，用于响应所述第二请求，从所述第二请求中解析出所述第二信息；

提取单元，用于提取信息匹配策略，所述信息匹配策略用于表征所述第一信息标识的现有房源与所述第二信息标识的期望房源之间的匹配程度；

第一处理单元，用于根据所述信息匹配策略得到匹配程度的排序结果；

发送单元，用于将所述排序结果分别发送给第一请求发起端和/或第二请求发起端。

10.根据权利要求9所述的服务器，其特征在于，所述服务器还包括：

划分单元，用于将所述现有房源的属性按照不同的分类粒度进行划分，得到第一划分结果；

归类单元，用于根据第一划分结果将相近似的现有房源进行归类和合并；

所述现有房源的属性包括行业通用属性和专有属性。

11.根据权利要求9所述的服务器，其特征在于，所述服务器还包括：

划分单元，用于将所述期望房源的属性按照不同的分类粒度进行划分，得到第二划分结果；

归类单元，用于根据第二划分结果将相近似的期望房源进行归类和合并；

所述期望房源的属性包括行业通用属性和专有属性。

12.根据权利要求10或11所述的服务器，其特征在于，所述划分单元，进一步用于：

按照不同的分类粒度进行划分时，所依据的至少一个划分粒度包括：按照区县进行划分、按照商圈进行划分、按照小区进行划分、按照楼层进行划分、按照当前楼盘参考价进行划分、按照装修状况进行划分、按照建筑面积进行划分、按照户型进行划分、按照朝向进行划分、按照建筑年代进行划分、按照税费状况进行划分、按照建筑类别进行划分、按照产权性质进行划分、按照房屋结构进行划分。

13.根据权利要求12所述的服务器，其特征在于，所述第一处理单元，进一步用于：

若所述第一请求发起端和第二请求发起端对应的置换需求为：买卖双方一对一的置换双向需求，则根据所述信息匹配策略计算出对应的两个计算结果；所述两个计算结果中包括买方和卖方的相关结果；

将所述两个计算结果相加后排序，以得到所述排序结果。

14.根据权利要求13所述的服务器，其特征在于，所述第一处理单元，进一步用于：

当获取到所述现有房源和所述期望房源后，按照所述信息匹配策略中的第一处理策略，对现有房源和期望房源进行分类后添加入房源信息库；

按照所述信息匹配策略中的第二处理策略，从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第一计算结果；

将所述预设套数的房源分别按照各自请求发起端房主的求购房源要求对第一用户现有房源进行打分，去除掉分数低于第一阈值的项目后，得到第二计算结果；

将所述第一计算结果和所述第二计算结果相加后排序，以得到所述排序结果。

15.根据权利要求12所述的服务器，其特征在于，所述第一处理单元，进一步用于：

若所述第一请求发起端和第二请求发起端对应的置换需求为：买卖双方一对多的置换多向需求，则根据所述信息匹配策略计算出对应的三个计算结果，其中，所述三个计算结果中包括除了买方和卖方的相关结果，还包括中间方的相关结果；

将所述三个计算结果相加后排序，以得到所述排序结果。

16.根据权利要求15所述的服务器，其特征在于，所述第一处理单元，进一步用于：

检测到使用所述信息匹配策略来针对买卖双方一对一的置换双向需求进行处理时得不到预期的所述排序结果时，则执行针对买卖双方一对多的置换双向需求进行处理的所述信息匹配策略；

按照所述信息匹配策略中的第二处理策略，根据第一用户提交的求购房源从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第一计算结果；

将所述预设套数的房源分别按照各自请求发起端房主的求购房源要求，分别从房源信息库中筛选出得分最高且大于第一阈值的预设套数的房源，得到第二计算结果；

所有套数的房源按照所述第一计算结果和所述第二计算结果相加排序后，选择排在前面的所述预设套数的房源并作为目标房源，将所述目标房源分别对应到各自请求发起端房主的求购房源。