基于物联网的智慧城市保障住房申请风险评估方法和系统

摘要

本说明书实施例提供基于物联网的智慧城市保障住房申请风险评估方法和系统。该方法由包括用户平台、服务平台和管理平台的基于物联网的智慧城市保障住房申请风险评估系统实现，管理平台执行该方法。该方法包括：管理平台从服务平台获取保障住房申请风险的查询请求，查询请求由用户平台基于申请对象通过用户平台输入的保障住房申请生成；响应于查询请求，通过管理平台对应的管理分平台，以及服务平台对应的服务分平台，获取申请对象及其关联人的相关信息，确定申请对象的保障住房申请风险；管理平台采用不同的管理分平台进行数据存储、数据处理和/或数据传输；其中，不同的管理分平台对应不同的信息来源；以及将保障住房申请风险发送至服务平台。

说明书

技术领域

本说明书涉及物联网领域，特别涉及基于物联网的智慧城市保障住房申请风险评估方法和系统。

背景技术

物联网是新一代信息技术的重要组成部分，是互联网基础上的延伸和扩展的网络，将各种信息与网络结合起来而形成的一个巨大网络，实现任何时间、任何地点，人、机、物的互联互通。这为人口较为密集、人口贫富程度不一的城市，提供了技术基础。通过物联网技术，设计出一种基于物联网技术的保障住房申请风险的评估系统具有重要意义。

因此，结合物联网技术，提供基于物联网的智慧城市保障住房申请风险评估方法和系统，以实现对申请对象的保障住房申请进行准确的风险评估。

发明内容

发明内容包括基于物联网的智慧城市保障住房申请风险评估方法。由基于物联网的智慧城市保障住房申请风险评估系统实现。所述基于物联网的智慧城市保障住房申请风险评估系统包括用户平台、服务平台和管理平台，所述方法由管理平台执行，所述方法包括：管理平台从服务平台获取保障住房申请风险的查询请求，所述查询请求由用户平台基于申请对象通过所述用户平台输入的保障住房申请生成；响应于所述查询请求，通过管理平台对应的管理分平台，以及服务平台对应的服务分平台，获取申请对象及其关联人的相关信息，确定申请对象的保障住房申请风险；管理平台采用不同的管理分平台进行数据存储、数据处理和/或数据传输；其中，不同的管理分平台对应不同的信息来源；以及将所述保障住房申请风险发送至所述服务平台。

发明内容包括提供基于物联网的智慧城市保障住房申请风险评估系统，包括用户平台、服务平台、管理平台；服务平台用于获取保障住房申请风险的查询请求，查询请求由所述用户平台，基于申请对象通过用户平台输入的保障住房申请生成；管理平台用于响应于查询请求，通过管理平台对应的管理分平台，以及服务平台对应的服务分平台，获取申请对象及其关联人的相关信息，确定申请对象的保障住房申请风险；管理平台采用不同的管理分平台进行数据存储、数据处理和/或数据传输；其中，不同的管理分平台对应不同的信息来源；以及管理平台用于将保障住房申请风险发送至服务平台。

附图说明

本说明书将以示例性实施例的方式进一步说明，这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的编号表示相同的结构，其中：

图1是根据本说明书一些实施例所示的基于物联网的智慧城市保障住房申请风险评估系统的应用场景示意图；

图2是根据本说明书一些实施例所示的基于物联网的智慧城市保障住房申请风险评估系统的示例性示意图；

图3是根据本说明书一些实施例所示的基于物联网的智慧城市保障住房申请风险评估方法的示例性流程图；

图4是根据本说明书一些实施例所示的确定申请对象的保障住房申请风险的示例性示意图；

图5是根据本说明书一些实施例所示的关联信息图谱的示例性示意图。

具体实施方式

为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本说明书的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本说明书应用于其它类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。

应当理解，本文使用的“系统”、“装置”、“单元”和/或“模块”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换所述词语。

非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。

本说明书中使用了流程图用来说明根据本说明书的实施例的系统所执行的操作。应当理解的是，前面或后面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各个步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

图1是根据本说明书一些实施例所示的基于物联网的智慧城市保障住房申请风险评估系统的应用场景示意图。

在一些实施例中，基于物联网的智慧城市保障住房申请风险评估系统的应用场景100可以包括服务器110、网络120、存储设备130、信息系统140以及终端设备150。服务器110可以包括处理设备112。

在一些实施例中，应用场景100中的组件可以经由网络120（例如无线连接、有线连接或其组合），以实现彼此连接和/或通信。例如，服务器110可以通过网络120连接到存储设备130。又例如，信息系统140可以通过网络120连接到服务器110、存储设备130。

在一些实施例中，应用场景100可以通过实施本说明书中披露的方法和/或过程来获取针对用户查询请求的查询结果。例如，处理设备可以基于用户平台接收用户发起的对保障住房申请风险的查询请求；基于服务平台根据查询请求生成查询指令，并下发至管理平台；基于管理平台根据查询指令，获取查询结果，并将查询结果上传至服务平台；基于服务平台上传查询结果上传至用户平台反馈给用户。

服务器110可以与终端设备150可以通过网络120相连，服务器110可以与存储设备130通过网络120相连。服务器110可以用于管理资源以及处理来自本系统至少一个组件或外部数据源（例如，云数据中心）的数据和/或信息。在一些实施例中，可以通过服务器110接收用户发起的对保障住房申请风险的查询请求。服务器110在处理时可以获取存储设备130上的数据或将数据保存到存储设备130。在一些实施例中，服务器110可以是单一服务器或服务器组。在一些实施例中，服务器110可以被配置为服务平台；在一些实施例中，服务器110可以被配置为管理平台；在一些实施例中，服务器110可以是区域的或者远程的。在一些实施例中，服务器110可以在云平台上实施，或者以虚拟方式提供。

在一些实施例中，服务器110可以包括处理设备112。处理设备112可以用于处理与应用场景100有关的信息和/或数据，例如，保障住房申请、保障住房申请对象的相关信息、评估保障住房申请风险等。在一些实施例中，处理设备112可以包括一个或以上处理引擎（例如，单芯片处理引擎或多芯片处理引擎）。仅作为示例，处理设备112可以包括中央处理单元（CPU）。处理设备112可以处理从其他设备或系统组成部分中获得的数据、信息和/或处理结果，并基于这些数据、信息和/或处理结果执行程序指令，以执行本说明书中描述的一个或以上功能。例如，处理设备112可以被配置为用于管理平台的平台维护及管理工作。

网络120可以连接应用场景100的各组成部分和/或连接系统与外部资源部分。网络120使得各组成部分之间，以及与系统之外其他部分之间可以进行通讯，促进数据和/或信息的交换。在一些实施例中，网络120可以是有线网络或无线网络中的任意一种或多种。例如，网络120可以包括电缆网络、光纤网络等或其任意组合。各部分之间的网络连接可以是采用上述一种方式，也可以是采取多种方式。在一些实施例中，网络可以是点对点的、共享的、中心式的等各种拓扑结构或者多种拓扑结构的组合。在一些实施例中，网络120可以包括一个或以上网络接入点。在一些实施例中，可以通过网络120传递存储设备130、信息系统140、终端设备150等的相关数据。

存储设备130可以用于存储数据和/或指令。在一些实施例中，存储设备130可以储存服务器110用来执行或使用以完成本说明书中描述的示例性方法的数据和/或指令。在一些实施例中，存储设备130可以连接到网络120以与应用场景100的一个或以上组件（例如，服务器110、终端设备150、信息系统140）通信。

信息系统140可以指提供用于保障住房申请风险评估的相关数据和/或信息的系统。在一些实施例中，信息系统140可以包括住房信息系统140-1、生活消费信息系统140-2、公共交通信息系统140-3、道路交通信息系统140-4、人口信息系统140-5、定位信息系统140-6等。信息系统140包括的各个系统可被配置为与服务器110进行通信，以实现数据的传输。

住房信息系统140-1可以包括与居住场所相关的信息。例如，居住的地址、居住的房屋的产权、居住的时间等。

生活消费信息系统140-2可以包括与日常生活中的消费行为相关的信息。例如，消费的金额、消费的次数、消费的场所等。生活消费信息系统140-2还可以包括贷款信息，例如，贷款的金额、次数等。

公共交通信息系统140-3可以包括与公共交通相关的信息。例如，乘坐公共交通工具的次数、乘坐的公共交通工具、乘坐公共交通工具的时间等。

道路交通信息系统140-4可以包括与道路的交通相关的信息。例如，道路的限速信息、道路的拥堵情况、道路的车流量等。

人口信息系统140-5可以包括与人口信息相关的信息。例如，人的婚姻情况、人的亲属关系等。

定位信息系统140-6可以包括与定位信息相关的信息。例如，人的实时位置、人的历史位置等。

在一些实施例中，信息系统140可以是来自本系统或外部的数据源。在一些实施例中，信息系统140可以将相关数据和/或信息通过网络120发送到服务器110。在一些实施例中，信息系统140可以作为服务平台和/或管理平台的分平台。例如，住房信息系统140-1、人口信息系统140-5和定位信息系统140-6可以分别作为服务平台中的住房服务分平台、人口信息服务分平台和定位分平台；又例如，生活消费信息系统140-2、公共交通信息系统140-3和道路交通信息系统140-4可以分别作为管理平台中的生活消费管理分平台、公共交通管理分平台和道路交通管理分平台。

终端设备150可以包括一个或多个终端设备或软件。在一些实施例中，终端设备150可以包括移动电话150-1、平板电脑150-2、膝上型计算机150-3等。在一些实施例中，终端设备150的用户可以是一个或多个用户。用户可以是保障住房的申请对象、保障住房申请风险评估的审核人员等。在一些实施例中，用户可以通过终端设备150查看信息和/或输入数据和/或指令。例如，用户可以通过终端设备150输入保障住房申请风险的查询指令等。又例如，用户可以通过终端设备150查看保障住房申请风险的评估结果。在一些实施例中，终端设备150可以作为用户平台，接收用户输入的保障住房申请风险查询请求。

应当注意应用场景100仅仅是为了说明的目的而提供，并不意图限制本说明书的范围。对于本领域的普通技术人员来说，可以根据本说明书的描述，做出多种修改或变化。例如，应用场景还可以包括数据库。又例如，应用场景可以在其他设备上实现以实现类似或不同的功能。然而，变化和修改不会背离本说明书的范围。

物联网系统是一种包括用户平台、服务平台、管理平台中部分或全部平台的信息处理系统，其中，用户平台是整个物联网运行体系的主导者，可以用于获取用户需求。用户需求是物联网运行体系形成的基础和前提，物联网系统的各平台之间的联系均是为了满足用户的需求。服务平台是位于用户平台和管理平台之间以实现用户平台和管理平台联系的桥梁，服务平台可以为用户提供输入和输出服务。管理平台可以实现统筹、协调各功能平台（如用户平台、服务平台）之间的联系和协作，管理平台汇聚着物联网运行体系的信息，可以为物联网运行体系提供感知管理和控制管理功能。

物联网系统中信息的处理可以分为感知信息的处理流程及控制信息的处理流程，控制信息可以是基于感知信息而生成的信息。其中，感知信息的处理是由管理平台传递至服务平台，并最终到达用户平台。控制信息则是由用户平台发出，依次通过服务平台到达管理平台。

在一些实施例中，将物联网系统应用于城市管理时，可以将其称之为智慧城市物联网系统。

图2是根据本说明书一些实施例所示的基于物联网的智慧城市保障住房申请风险评估系统的示例性示意图。如图2所示，基于物联网的智慧城市保障住房申请风险评估系统200，以下简称为系统200，包括用户平台210、服务平台220和管理平台230。在一些实施例中，系统200可以为服务器110的一部分或由服务器110实现。

在一些实施例中，系统200可以应用于保障住房申请风险评估的多种场景。在一些实施例中，系统200可以基于用户发起的保障住房申请风险的查询请求，得到查询指令，并根据查询指令，获取查询结果。在一些实施例中，系统200可以基于保障住房申请风险的查询请求和申请对象及其关联人的住房信息、生活消费信息、公共交通信息、贷款信息、基本信息等相关信息，确定申请对象的保障住房申请的风险评估结果。

保障住房申请风险评估的多种场景可以包括申请对象的公共交通乘坐情况的评估、生活消费情况的评估、保障住房申请的风险预测等，需要说明的是以上场景仅为示例，并不对系统200的具体应用场景起限制作用，本领域技术人员可以在本实施例公开的内容基础上，将系统200应用于其他合适的任何场景。

在一些实施例中，系统200在应用于申请对象公共交通乘坐情况的评估时，管理平台可以获取申请对象的公共交通乘坐信息，例如，基于申请对象的公共汽车、地铁的刷卡记录等，从而确定申请对象每个月的公共汽车、地铁等交通工具的乘坐次数、频率等，结合道路的拥堵情况确定申请对象的生活是否节俭。再例如，管理平台可以获取申请对象每月乘坐高铁、飞机等出行交通工具的乘坐信息，以确定申请对象是否存在经常采用高消费出行的方式，从而评估申请对象的保障住房申请的风险。

在一些实施例中，系统200在应用于申请对象生活消费情况的评估时，管理平台可以获取申请对象的生活轨迹信息，确定申请对象经常前往的场所信息。例如，可以统计申请对象每个月前往高消费场所的次数、停留的时长等，从而确定申请对象的高消费情况，进而评估申请对象的保障住房申请的风险。

在一些实施例中，系统200在应用于保障住房申请的风险预测时，管理平台可以获取申请对象及其关联人的相关信息，相关信息包括基本信息（如身份证号码、姓名、年龄、职业）、住房信息（如名下房产信息，租房信息等）、生活消费信息、公共交通乘坐信息（如公交车、地铁乘坐次数等）、贷款信息（如贷款已结清/待还的笔数和金额）等，基于相关信息构建关联信息图谱，管理平台可以对上述关联信息图谱进行处理，并获取申请对象的保障住房申请风险的评估结果。管理平台将评估结果上传至服务平台，并由服务平台将评估结果上传至用户平台反馈给用户。

以下将以系统200应用于申请风险预测场景为例对系统200进行具体说明。

用户平台210可以指以用户为主导的平台，包括获取用户的需求以及将信息反馈给用户的平台。在一些实施例中，用户平台210基于申请对象通过所述用户平台输入的保障住房申请生成查询请求。在一些实施例中，用户平台210被配置为输入终端，用于获取用户的查询指令。在一些实施例中，用户平台210被配置显示终端，可以将查询结果反馈给用户。在一些实施例中，用户平台210可以将查询指令发送至服务平台220。在一些实施例中，用户平台210可以接收服务平台220发送的风险查询结果。

服务平台220可以指将用户的输入与控制信息传达出去的平台。其连接了用户平台210和管理平台230。在一些实施例中，服务平台220可以接收用户平台210的查询请求，查询申请对象及其关联人的相关信息，如基本信息、住房信息等。在一些实施例中，服务平台220可以将查询请求以及相关信息发送至管理平台230，以基于管理平台230进行进一步的数据分析和处理。

在一些实施例中，服务平台220可以从管理平台230接收风险评估的查询结果，并将查询结果发送至用户平台210以反馈给用户。在一些实施例中，服务平台220可以采用独立式布置，独立式布置是指服务平台220对不同类型或不同数据来源的数据采用不同的分平台进行数据存储、数据处理和/或数据传输。

在一些实施例中，服务平台220可以设置人口信息服务分平台、住房服务分平台和定位分平台，上述分平台可以基于保障住房申请风险评估的需求对保障住房申请人及其关联人的相关信息进行数据存储、数据处理和/或数据传输。例如，人口信息服务分平台可以将人的婚姻情况、人的亲属关系等信息发送至管理平台。又例如，住房服务分平台可以将居住的地址、居住的房屋的产权、居住的时间等信息发送至管理平台。再例如，定位分平台可以将人的实时位置、人的历史位置等信息发送至管理平台。

管理平台230可以指统筹、协调各功能平台之间的联系和协作，提供感知管理和控制管理的物联网平台。在一些实施例中，管理平台230接收服务平台220下发的保障住房申请风险的查询请求，并将风险评估结果发送至服务平台220。

在一些实施例中，管理平台230可以采用前分式布置。前分式布置是指管理平台设置有总数据库和多个分平台，多个分平台根据不同的数据源对相应的数据进行存储和处理，各分平台进一步将处理的数据汇总到总数据库，管理平台基于汇总后的数据进行分析处理并存储，再通过总数据库将数据传输至服务平台。例如，管理平台230基于保障住房申请风险评估的需求，可以从服务平台220的人口信息服务分平台获取申请对象的年龄、婚姻、亲属关系等信息，也可以从服务平台220的住房服务分平台获取申请对象及其关联人的居住信息、房产信息等。在一些实施例中，管理平台230包括的多个分平台可以包括生活消费管理分平台、公共交通管理分平台和道路交通管理分平台。

在一些实施例中，管理平台230用于响应于查询请求，通过管理平台230对应的管理分平台，以及服务平台220对应的服务分平台，获取申请对象及其关联人的相关信息，确定申请对象的保障住房申请风险。例如，管理平台230可以基于用户对申请对象的保障住房风险查询请求，通过管理平台230对应的生活消费管理分平台、公共交通管理分平台，以及服务平台220对应的人口信息服务分平台，分别将申请对象及其关联人的生活消费信息、公共交通乘坐信息进行处理并汇总到管理平台230的总数据库，管理平台230可以基于汇总后的信息进行处理（如构建关联信息图谱），获取保障住房申请风险并存储，通过总数据库将保障住房申请风险上传至服务平台220。

为了简化描述，上述示例中管理平台230对应的生活消费管理分平台、公共交通管理分平台分别将用户及其关联人的生活消费信息、公共交通乘坐信息汇总到管理平台230的总数据库，管理平台230可以基于汇总后的信息进行处理，可以被描述为“管理平台与管理分平台进行通信”。本说明书中出现的“管理平台与管理分平台进行通信”可以指管理平台发送获取数据指令到各管理分平台，并将从各管理分平台获取的数据汇总到管理平台的总数据库。同理，本说明书中出现的“管理平台与服务平台进行通信”可以指管理平台向服务平台发送获取相关数据的指令，并将服务平台和/或服务分平台下发的数据经过处理后汇总到管理平台的总数据库。

在一些实施例中，相关信息包括住房信息、生活消费信息、公共交通信息、贷款信息、基本信息中的至少一种。

在一些实施例中，公共交通信息包括路段拥堵时公共交通乘坐情况。

在一些实施例中，生活消费信息包括生活轨迹信息，管理平台230进一步用于基于生活轨迹信息生成生活特征向量，生活特征向量包括每类场所去过的次数、每类场所的平均停留时间、高消费场所占比中的至少一种。

在一些实施例中，管理平台230进一步用于将申请对象及其关联人的相关信息输入风险预测模型以确定保障住房申请风险，风险预测模型为机器学习模型。

在一些实施例中，风险预测模型包括图神经网络模型，管理平台230进一步用于将关联信息图谱输入图神经网络模型，基于申请对象对应的节点的输出，确定申请对象的保障住房申请风险；关联信息图谱基于申请对象及其关联人的相关信息获取。

在一些实施例中，关联信息图谱的节点包括对象节点和特征节点，对象节点对应申请对象及其关联人，特征节点对应申请对象及其关联人的相关信息；关联信息图谱的边包括第一类边和第二类边，第一类边用于连接对象节点；第一类边的特征为被连接的对象节点的生活相似度；第二类边用于连接对象节点与对象节点对应的特征节点；第二类边的特征为被连接的特征节点的特征值。

在一些实施例中，特征节点包括年龄节点、职业节点、公共交通节点、贷款节点、生活消费节点中的至少一种；年龄节点包括预设的多个年龄段的节点，职业节点包括预设的多个职业的节点。

] 在一些实施例中，风险预测模型的输入还包括置信度，置信度相关于关联信息图谱包括的节点和边的数量。

关于管理平台230的具体说明，参见图3-图5及其相关说明。

需要注意的是，以上对于系统及其组成部分的描述，仅为描述方便，并不能把本说明书限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可能在不背离这一原理的情况下，对各个组成部分进行任意组合，或者构成子系统与其他组成部分连接。例如，城市疫苗管理平台和疫苗服务平台可以整合在一个组成部分中。又例如，各个组成部分可以共用一个存储设备，各个组成部分也可以分别具有各自的存储设备。诸如此类的变形，均在本说明书的保护范围之内。

图3是根据本说明书一些实施例所示的基于物联网的智慧城市保障住房申请风险评估方法的示例性流程图。如图3所示，流程300包括下述步骤。在一些实施例中，流程300可以由管理平台230执行。

步骤310，管理平台从服务平台获取保障住房申请风险的查询请求，查询请求由用户平台，基于申请对象通过用户平台输入的保障住房申请生成。

申请对象可以指提出保障住房申请的人。例如，低保户、年收入低于规定的收入标准的人由于无法保证基本的住房需求，向政府机构提出保障住房申请，这些人可以被称为申请对象。

保障住房申请可以指申请对象提出保障住房申请的需求或指令。在一些实施例中，申请对象可以通过用户平台210提出保障住房申请。例如，申请对象可以在用户平台210上进行输入，如，填写申请保障住房的资料、点击“申请保障住房”选项等，以提出保障住房申请。

保障住房申请风险可以指申请对象不满足保障住房申请要求的可能性。例如，申请对象名下已经拥有条件良好的住房，则其不满足保障住房申请要求。保障住房申请风险可以用文字、数字等多种方式进行表示。例如，保障住房申请风险可以是0-100的数值。其数值越高表示风险越大，申请对象保障住房申请被审核通过的概率越低。又例如，保障住房申请风险可以是预设的等级，如1级、2级、3级、4级等，等级越高表示风险越大，申请对象的保障住房申请被审核通过的概率越低。

保障住房申请风险的查询请求可以指对保障住房申请风险进行查询的指令。保障住房申请风险的查询请求可以基于申请对象通过用户平台210输入的保障住房申请生成。例如，当申请对象通过用户平台210输入完成保障住房申请之后，用户平台210可以生成保障住房申请风险的查询请求。

在一些实施例中，管理平台可以与服务平台进行通信，并从服务平台获取保障住房申请风险的查询请求。例如，当申请对象通过用户平台输入的保障住房申请风险的查询请求下发到服务平台后，管理平台可以从服务平台获取该查询请求。

步骤320，响应于查询请求，通过管理平台对应的管理分平台，以及服务平台对应的服务分平台，获取申请对象及其关联人的相关信息，确定申请对象的保障住房申请风险。

关联人可以指与申请对象有关联关系的人。例如，申请对象的家庭成员、同事、朋友等。在一些实施例中，关联人的相关信息可以由管理平台通过各个服务分平台和/或管理分平台获取。例如，管理平台可以从人口信息服务分平台获取关联人，然后基于关联人的标识（如，身份证号码、ID等）从生活消费管理分平台获取关联人的消费的金额、消费的次数等信息。关于人口信息服务分平台、生活消费管理分平台的更多细节参见图2及其相关描述。

在一些实施例中，关联人可以指与申请对象住在一起的人。例如，与申请对象住在预定范围内的父母、配偶、兄弟姐妹等。预定范围可以指预先设定的地理范围。例如，同一个房间、楼栋、小区等。预定范围可以根据实际需要进行调整。

相关信息可以指与人及其各种行为相关的信息。例如，身份证号码、上班和居住的地址、出行所选择的交通工具、购物信息（如，在商场购买的商品及花费的金额）等多种信息。申请对象及其关联人的相关信息可以指与申请对象及其关联人的各种行为相关的信息。在一些实施例中，申请对象及其关联人的相关信息包括申请对象及其关联人的住房信息、生活消费信息、公共交通信息、贷款信息、基本信息中的至少一种。

基本信息可以指与能够单独或者与其它信息结合，以识别特定自然人身份或反映特定自然人活动情况的信息。例如，身份证号码、姓名、年龄、职业等。

在一些实施例中，响应于申请对象的保障住房申请风险的查询请求，管理平台可以通过管理平台对应的管理分平台，以及服务平台对应的服务分平台，获取申请对象及其关联人的相关信息。例如，管理平台可以与各个服务分平台和/或管理分平台进行通信，以获取相关信息。如，管理平台与定位分平台进行通信，获取申请对象及其关联人的实时位置、历史位置等。又如，管理平台与生活消费管理分平台进行通信，获取申请对象及其关联人的贷款信息。

在一些实施例中，管理平台可以通过住房服务分平台获取申请对象的住房信息。例如，管理平台可以与住房服务分平台进行通信，以获取申请对象的住房信息。申请对象的住房信息可以指申请对象的居住场所相关的信息。申请对象的住房信息可以包括历史租房情况、名下房产情况、历史保障住房申请信息中的至少一种。

在一些实施例中，管理平台可以获取申请对象的关联人的住房信息。例如，管理平台可以基于从服务平台的人口信息服务分平台获取的申请对象的关联人，通过与住房服务分平台进行通信，以获取申请对象的关联人的住房信息。

在一些实施例中，管理平台可以基于申请对象的住房信息以及申请对象的关联人的住房信息确定申请对象是否存在房产转移情况。例如，管理平台可以根据房产的权利人变更记录，若房产的权利人由申请对象变更为了申请对象的父母，则管理平台可以认为其存在房产转移情况。

公共交通信息可以指与乘坐公共交通工具相关的信息。例如，每月乘坐公共交通工具的次数、时间等。在一些实施例中，公共交通信息包括路段拥堵时公共交通乘坐情况。

公共交通乘坐情况可以指申请对象乘坐公共交通工具的记录。例如，今天是否乘坐公交。又例如，每个月乘坐公交的次数。在一些实施例中，管理平台可以通过公共交通管理分平台获取申请对象的公共交通乘坐情况。例如，管理平台与公共交通管理分平台进行通信，以获取申请对象的公共交通的刷卡记录，如申请对象的上车、下车刷卡记录。管理平台还可以通过统计，获取申请对象乘坐公共交通的次数、频率等。

在一些实施例中，管理平台可以根据申请对象的公共交通乘坐情况确定申请对象在路段拥堵时的公共交通乘坐情况。管理平台可以通过多种方式获取道路拥堵情况，例如，管理平台可以与道路交通管理分平台进行通信，以获取各个时间段的道路拥堵情况。在一些实施例中，管理平台可以基于道路拥堵情况确定拥堵值。拥堵值可以通过文字、数字等多种方式进行表示。示例性的，拥堵值可以用数值0或1表示，其中，拥堵值为1，表示发生堵车；拥堵值为0，表示道路畅通无阻。

公共交通乘坐信息还可以包括申请对象在一段时间内（如，一周、一月等）的远程出行信息，例如申请对象乘坐火车、长途汽车出行等信息，以及高消费出行信息。高消费出行可以指出行所花费的金额超过第一预设阈值的出行。第一预设阈值可以依据经验进行设置。高消费出行信息可以包括高消费出行的次数、金额等。若出行花费的金额高于第一预设阈值，则管理平台可以认为该出行为高消费出行，并确认申请对象消费水平较高。

将申请对象的公共交通信息，用于确定保障住房申请风险，可以提高确定的结果的准确性。可以理解的是，如果申请对象是因为路段堵而选择坐公交而非开车或打车，则不能说明申请对象生活比较拮据。如果申请对象所坐公交或地铁对应的路段并不堵，而申请对象频繁乘坐公交地铁，则在一定程度上可以说明申请对象的生活情况至少比较节俭，管理平台可以降低保障住房申请风险。

在一些实施例中，生活消费信息包括生活轨迹信息。

生活轨迹可以指申请对象在日常生活中所做的事情和/或所去过的地方。例如，某段时间，由A小区到B写字楼。生活轨迹信息可以指与申请对象的生活轨迹相关的信息。例如，生活轨迹发生的时间、地点等。生活轨迹信息可以由管理平台通过定位分平台获取。生活轨迹可以由多个时间点的申请对象去过的场所信息构成的序列进行表示。例如，（08：00，A小区），（09：00，B写字楼），（12：00，C饭店），（21：00，D酒吧）。

可以理解的是，场所有不同的分类，例如，非消费场所（如公园、小区、写字楼等）、消费场所（如书店、文具店、饭店、酒吧、珠宝店等）。其中，消费场所中可以包括低消费场所和高消费场所。高消费场所可以指最低消费水平高于第二预设阈值的消费场所。低消费场所则可以指最低消费水平低于第三预设阈值的消费场所。第二预设阈值和第三预设阈值可以基于申请对象所在的城市或地区的平均收入水平、物价水平等确定。示例性的，高消费场所可以包括高级酒店、名贵珠宝店、汽车专卖店等。低消费场所可以包括书店、文具店。

在一些实施例中，管理平台可以根据申请对象的生活轨迹信息，判断申请对象的消费情况。例如，管理平台基于生活轨迹信息，统计申请对象经常前往的场所以及停留的时长。示例性的，管理平台可以统计某一段时间内申请对象的生活轨迹信息中出入所有场所的总次数，以及其中的出入高消费场所的次数，进而获取出入高消费场所的次数与出入所有场所的总次数的比值，当该比值大于第四预设阈值，则管理平台可以确定申请对象的高消费场所占比较高，同时确定申请对象的消费水平较高。其中，第四预设阈值可以依据经验进行设置。

在一些实施例中，管理平台可以基于生活轨迹信息生成生活特征向量。生活特征向量可以指生活轨迹信息的向量表示。生活特征向量可以包括每类场所去过的次数、每类场所的平均停留时间、高消费场所占比中的至少一种。可以理解的是，管理平台可以根据功能、消费金额等多方面将场所分为多种类型。例如，住宿场所、娱乐场所、餐饮场所等。又例如，高消费场所、低消费场所等。每类场所可以指多种类型的场所中的一种。

示例性的，生活特征向量可以表示为（a，b，c），其中a元素代表场所类型（如a的数值1表示公园；2表示小区；3表示写字楼；4表示饭店；5表示酒吧等），b元素代表去过的次数，c元素代表平均停留时长（如30表示平均停留30分钟），例如，生活特征向量为（5，5，20），表示申请对象去过酒吧5次，平均停留时长为20分钟；又一示例性的，生活特征可以表示去消费场所的情况，其向量表示为（b，c，d），其中b表示消费场所的次数，c表示消费场所的停留时长，d代表高消费场所占比（如数值0.5表示占比为50%），例如，生活特征向量为（8，30，0.5），表示申请对象去过消费场所8次，每次平均停留30分钟，其中高消费场所的占比为50%。

在一些实施例中，生活消费信息还可以包括高消费场所消费情况。

高消费场所消费情况可以指在高消费场所与消费相关的信息。例如，高消费场所消费情况可以包括申请对象在高消费场所的消费次数及其在所有场所的消费次数的占比。

在一些实施例中，管理平台可以通过生活消费管理分平台获取高消费场所消费情况。例如，管理平台可以与生活消费管理分平台进行通信，以获取申请对象在各高消费场所的消费记录。

将高消费场所消费情况用于确定保障住房申请风险，可以避免或减少通过欺骗的方式获取保障住房的情况的发生。可以理解的是，若申请对象的高消费场所消费情况包括多次在高消费场所的消费记录，则其保障住房申请风险将会变高。

在一些实施例中，管理平台可以通过定位分平台获取申请对象在高消费场所的停留时间。停留时间可以用于辅助判断申请对象是否在高消费场所进行了消费。可以理解的是，若申请对象在高消费场所的停留时间较短，如，1分钟、20分钟等，则其可能只是路过高消费场所，或在高消费场所去寻找朋友等。若申请对象在高消费场所的停留时间较长，如，1小时、3小时等，则其可能是在高消费场所进行了消费。

在一些实施例中，管理平台可以对申请对象及其关联人的相关信息进行处理，以确定申请对象的保障住房申请风险。

在一些实施例中，管理平台可以进行建模或采用各种数据分析算法，例如回归分析法、判别分析法等，对申请对象及其关联人的相关信息进行分析处理，以确定申请对象的保障住房申请风险。

在一些实施例中，管理平台可以基于风险预测模型确定申请对象的保障住房申请风险。关于风险预测模型的更多细节参见图4以及相关描述，此处不再赘述。

步骤330，管理平台将保障住房申请风险发送至服务平台。

在一些实施例中，管理平台可以与服务平台通信，将保障住房申请风险发送至服务平台。在管理平台将保障住房申请风险发送至服务平台之后，保障住房申请风险可以被服务平台发送至用户平台，以供用户查看。

本说明书一些实施例基于从多种平台获取的保障住房申请对象以及关联人的多种相关信息，评估申请对象的保障住房申请风险，进而可以提高确定的保障住房申请风险的准确性。

图4是根据本说明书一些实施例所示的确定申请对象的保障住房申请风险方法示例性示意图。

在一些实施例中，管理平台可以将申请对象及其关联人的相关信息输入风险预测模型以确定保障住房申请风险。

风险预测模型为训练后的机器学习模型。风险预测模型可以包括其他模型。例如，循环神经网络模型、卷积神经网络或其他自定义的模型结构等中的任意一种或组合。

风险预测模型可以基于输入为申请对象及其关联人的相关信息，输出保障住房申请风险。

在一些实施例中，管理平台可以基于多个训练样本及标签训练得到风险预测模型。

训练样本包括历史的申请对象及其关联人的相关信息。训练样本的标签可以是相应的各申请对象的保障住房申请风险，训练样本的标签可以通过人工进行标注。

训练过程中，管理平台可以基于训练样本的标签和风险预测模型的输出建立损失函数，对模型的参数进行更新。并基于损失函数迭代更新风险预测模型的参数，直到预设条件被满足训练完成，得到训练好的预测模型。其中，预设条件可以是损失函数小于阈值、收敛，或训练周期达到阈值。

在一些实施例中，风险预测模型可以包括图神经网络模型。在一些实施例中，管理平台可以将关联信息图谱输入图神经网络模型，基于申请对象对应的节点的输出，确定申请对象的保障住房申请风险。如图4所示，风险预测模型430可以包括图神经网络模型431，管理平台基于申请对象及其关联人的相关信息410生成关联信息图谱420，并将关联信息图谱420输入图神经网络模型431，通过图神经网络模型431对关联信息图谱420进行处理，确定申请对象的保障住房申请风险440。

在一些实施例中，图神经网络模型可以通过训练获取。训练样本为历史的关联信息图谱，训练样本的标签可以是相应的申请对象的保障住房申请风险。训练样本的标签可以通过人工进行标注。

管理平台在训练初始的图神经网络模型时，基于训练样本的标签和图神经网络模型的输出构建损失函数，基于损失函数迭代更新图神经网络模型的参数，直到预设条件被满足训练完成，得到训练好的图神经网络模型模型。其中，预设条件可以是损失函数小于阈值、收敛，或训练周期达到阈值。

关于关联信息图谱的相关细节参见图5及其描述。

在一些实施例中，风险预测模型的输入还包括置信度，所述置信度相关于所述关联信息图谱包括的节点和边的数量。关于关联信息图谱的节点和边的相关细节参见图5及其描述，此处不再赘述。

置信度可以指用于评价关联信息图谱的可信程度的量。其可以通过数字和/或文字等多种方式进行表示，示例性的，置信度可以用数字进行表示，数值越大，表示置信度越高。置信度可以通过关联信息图谱包含的信息来衡量，关联信息图谱包含的信息越多，则置信度越高。可以理解的是，关联信息图谱的节点和边的数量越多，代表相关信息越多，对申请对象的保障住房风险评估越充分，结果也越准确。

在一些实施例中，管理平台可以基于关联信息图谱包括的节点和边的数量，通过预设表，确定置信度。例如，关联信息图谱包括的节点和边的数量为70时，通过查预设表，可以确定置信度为50%。预设表可以基于经验预先设置。

在一些实施例中，置信度可以作为关联信息图谱中的申请对象节点的一个特征节点。关于特征节点的更多内容参见图5及其说明。关联信息图谱中的其他节点和边可以具有权重，权重可以在构件关联信息图谱时预设。

在一些实施例中，管理平台可以通过统计的方式，获取关联信息图谱包括的节点和边的数量。

在一些实施例中，统计可以通过加权求和进行，节点和边的数量可以基于其他节点和边与申请对象节点的跳跃关系确定。

加权求和可以指统计节点、边的数量时，基于节点、边的权重以及与目标对象的跳数进行加权统计。

跳跃关系可以指与某个节点直接和非直接连接的节点或边与该节点之间的距离关系。跳跃关系可以用跳数进行表示。跳数可以指从某个点到与该节点直接和非直接连接的节点或边时，需要经历的最小节点或边的数量。例如，在关联信息图谱A-B-C中，节点A通过边AB与节点B直接相连接，节点B并通过边BC与节点C连接。其中，节点B、边AB为节点A的一次跳跃关系，节点C、边BC为节点A的二次跳跃关系，节点A到节点C的跳数为2，节点A到边BC的跳数为2。

在一些实施例中，管理平台在统计关联信息图谱中包括的节点和边的数量时，可以基于节点、边的权重确定节点和边的数量。例如，管理平台可以将权重为50%的边，确定为0.5个边。

在一些实施例中，管理平台可以基于节点、边的权重以及与目标节点的跳数进行加权统计。

在一些实施例中，距离申请对象节点的越远的节点/边，跳数越大，参与计算时的权重越小。例如，权重为100%的节点A，其到申请对象节点的跳数为1，参与计算时，节点A的权重可以为100%。又例如，权重为100%的节点B，其到申请对象节点的跳数为2，参与计算时，节点B的权重可以为50%。管理平台可以基于预设的权重衰减策略（如逐次减半策略）预先设定不同跳跃关系的权重，例如，跳跃关系为1次跳数的节点/边其权重为100%，2次跳数的节点/边其权重为50%，3次跳数的节点/边其权重为25%。

在一些实施例中，管理平台可以基于节点、边的权重以及与目标节点的跳数进行加权统计，确定节点、边的数量，进而通过预设表确定置信度。仍以上述示例为例，管理平台对节点A和节点B进行加权统计，确定节点、边的数量为共有1.5个节点，通过查询预设表，确定置信度为1%。

将置信度输入风险预测模型，可以用于辅助判断风险预测模型输出的保障住房申请风险是否可信，进而可以避免一味地相信模型的输出结果，提高确定的保障住房申请风险的准确性。

本说明书一些实施例通过使用风险预测模型确定保障住房的申请对象的申请风险，可以提高确定保障住房申请风险的速度和准确度，还可以减少人力和财力的投入。

图5是根据本说明书一些实施例所示的关联信息图谱的示例性示意图。

关联信息图谱可以指基于申请对象及其关联人的相关信息构建的图。其可以表示关联人和/或各种信息与申请对象的存在的关系和/或相关程度。关联信息图谱包括多个节点和多个边。其中，关联信息图谱的节点之间通过边连接，代表节点之间的关系。在一些实施例中，管理平台可以基于管理平台对应的管理分平台，以及服务平台对应的服务分平台所获取的申请对象及其关联人的相关信息，通过各种可行的方式构建关联信息图谱。

在一些实施例中，关联信息图谱的节点包括对象节点和特征节点。

对象节点对应申请对象及其关联人。如图5所示，关联信息图谱500的对象节点分别为申请对象节点、关联人A节点和关联人B节点。其中，申请对象节点可以表示提交保障住房申请本人，关联人A节点和关联人B节点可以表示申请对象的关联人。若申请对象与关联人A和关联人B可以通过边连接，关于边的具体说明参见后文。

对象节点可以具有特征。对象节点的特征可以表示对象节点具有与其它对象节点不同的特点。例如，对象节点的特征可以包括置信度。

特征节点对应申请对象及其关联人的各类相关信息，如年龄、职业、公共交通乘坐信息、贷款信息、生活消费信息等。每个特征节点可以具有不同的特征。在一些实施例中，管理平台可以根据相关信息所属的种类，将该种类确定为特征节点和该特征节点的特征。例如，管理平台可以根据25岁所属的种类为年龄，将年龄确定为一个特征节点，并确定该特征节点的特征为年龄。相关信息所属的种类可以由管理平台进行标注。

在一些实施例中，特征节点包括年龄节点、职业节点、公共交通节点、贷款节点、生活消费节点中的至少一种。

在一些实施例中，年龄节点包括预设的多个年龄段的节点。如图5所示，关联信息图谱500的年龄节点包括20岁-30岁节点、30岁-40岁节点、50岁-60岁节点、60岁以上节点。

在一些实施例中，职业节点包括预设的多个职业的节点，如图5所示，关联信息图谱500的职业节点包括医生节点、学生节点、无业节点、律师节点。

在一些实施例中，公共交通节点对应路段拥堵时公共交通乘坐情况。如图5所示，关联信息图谱500的公共交通节点包括公交车乘坐次数节点、地铁乘坐次数节点。管理平台可以将图3中获取的公交车乘坐次数和地铁乘坐次数，分别确定为公交车乘坐次数节点和地铁乘坐次数节点。

在一些实施例中，生活消费节点对应高消费场所消费情况。如图5所示，关联信息图谱500的生活消费节点包括月消费额节点。

关联信息图谱的边用于连接对象节点和特征节点或对象节点和对象节点，基于边的特征可以表示节点与节点的关系。边包括第一类边和第二类边。

第一类边可以指用于连接两个对象节点的边。第一类边的特征为被连接的两个对象节点所代表的对象之间的生活相似度。

生活相似度可以指申请对象与其关联人生活习惯的相似程度。例如，消费习惯、出行习惯。在一些实施例中，管理平台可以基于申请对象的生活特征向量与关联人的生活特征向量，通过各种可行的方式计算上述两个向量之间的相似度，进而确定生活相似度。例如，管理平台可以通过图4中所述的方法确定申请对象的生活特征向量与关联人的生活特征向量，通过计算欧式距离，确定上述两个向量之间的相似度，并将上述两个向量之间的相似度确定为生活相似度。在一些实施例中，生活相似度作为第一类边的特征值。

第二类边可以指用于连接对象节点与特征节点的边。若对象节点具有特征节点的特征，则该对象节点与该特征节点可以连接构成第二类边，其中，第二类边可以具有特征值，第二类边的特征值可以基于申请对象及其关联人的相关信息进行确定。

如图5所示，在关联信息图谱500中，对于申请对象节点和20岁-30岁节点，申请对象的年龄为28岁，满足年龄预设的年龄范围20-30岁，则申请对象节点与20岁-30岁节点相连接构成第二类边，其中边的特征值为28岁；又例如，对于贷款节点，申请对象存在2笔贷款信息、关联人A存在1笔贷款信息，关联人B无贷款信息，则申请对象节点与贷款节点连接构成边，其中边的特征值为2笔；关联人A节点与贷款节点连接构成边，其中边的特征值为1笔；关联人B无贷款信息，无需与贷款节点连接，即无此类边。

为了进一步提高确定的保障住房申请风险的准确性，可以在构建关系信息图时，基于上述图3所述的方法获取更多的申请对象及其关联人的相关信息，如，申请对象及其关联人的收入信息、资金往来信息等，将其作为特征节点，并通过第二类边与对象节点进行连接，第二类边的特征值可以基于获取的申请对象及其关联人的相关信息进行确定。

在一些实施例中，置信度可以作为申请对象节点的特征。例如，通过上述方式获取得到的置信度为1%，可以作为申请对象节点的特征。

本说明书一些实施例通过构建关联信息图谱，可以较好地表示申请对象及其关联人，以及申请对象及其关联人的相关信息之间存在的多种关系，有助于更准确得对申请对象的保障住房申请风险进行评估。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本说明书的限定。虽然此处并没有明确说明，本领域技术人员可能会对本说明书进行各种修改、改进和修正。该类修改、改进和修正在本说明书中被建议，所以该类修改、改进、修正仍属于本说明书示范实施例的精神和范围。

同时，本说明书使用了特定词语来描述本说明书的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本说明书至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本说明书的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

此外，除非权利要求中明确说明，本说明书所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本说明书流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本说明书实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本说明书披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本说明书实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本说明书对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

一些实施例中使用了描述成分、属性数量的数字，应当理解的是，此类用于实施例描述的数字，在一些示例中使用了修饰词“大约”、“近似”或“大体上”来修饰。除非另外说明，“大约”、“近似”或“大体上”表明所述数字允许有±20%的变化。相应地，在一些实施例中，说明书和权利要求中使用的数值参数均为近似值，该近似值根据个别实施例所需特点可以发生改变。在一些实施例中，数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本说明书一些实施例中用于确认其范围广度的数值域和参数为近似值，在具体实施例中，此类数值的设定在可行范围内尽可能精确。

针对本说明书引用的每个专利、专利申请、专利申请公开物和其他材料，如文章、书籍、说明书、出版物、文档等，特此将其全部内容并入本说明书作为参考。与本说明书内容不一致或产生冲突的申请历史文件除外，对本说明书权利要求最广范围有限制的文件（当前或之后附加于本说明书中的）也除外。需要说明的是，如果本说明书附属材料中的描述、定义、和/或术语的使用与本说明书所述内容有不一致或冲突的地方，以本说明书的描述、定义和/或术语的使用为准。

最后，应当理解的是，本说明书中所述实施例仅用以说明本说明书实施例的原则。其他的变形也可能属于本说明书的范围。因此，作为示例而非限制，本说明书实施例的替代配置可视为与本说明书的教导一致。相应地，本说明书的实施例不仅限于本说明书明确介绍和描述的实施例。