一种基于物联网的智慧城市社会救助审核方法和系统

本说明书涉及物联网及社会救助领域，特别涉及一种基于物联网的智慧城市社会救助审核的方法和系统。

尽管当前社会已在高速的发展，但仍有许多贫困人员需要得到社会的救助，其中不乏一些非贫困人员通过某些手段利用虚假信息来申请社会救助，这使得社会救助资源面临未帮助到真正贫困的人员的风险。

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

因此，需要一种基于物联网的智慧城市社会救助审核的方法，能够准确识别真正需要社会救助的人员。

本说明书实施例之一提供一种基于物联网的智慧城市社会救助审核方法。所述社会救助审核方法包括：通过社会救助服务平台，基于用户平台获取救助申请人的社会救助申请；获取审核辅助信息；基于所述审核辅助信息对所述社会救助申请进行审核，确定通过审核的救助对象。

本说明书实施例之一提供一种基于物联网的智慧城市社会救助审核系统，所述社会救助审核系统包括用户平台、社会救助服务平台、社会救助管理平台，所述社会救助管理平台被配置为执行以下操作：通过社会救助服务平台，基于用户平台获取救助申请人的社会救助申请；获取审核辅助信息；基于所述审核辅助信息对所述社会救助申请进行审核，确定通过审核的救助对象。

本说明书实施例之一提供一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机执行基于物联网的智慧城市社会救助审核方法。

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

图1是根据本说明书一些实施例所示的基于物联网的智慧城市社会救助审核系统的应用场景示意图；

图2是根据本说明书一些实施例所示的基于物联网的智慧城市社会救助审核系统的示例性示意图；

图3是根据本说明书一些实施例所示的基于物联网的智慧城市社会救助审核方法的示例性流程图；

图4是根据本说明书一些实施例所示的获取审核辅助信息方法的示例性流程图；

图5是根据本说明书另一些实施例所示的获取审核辅助信息的示例性流程图；

图6是根据本说明书一些实施例所示的获得欺诈风险信息的示例性流程图。

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

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

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

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

图1是根据本说明书一些实施例所示的基于物联网的智慧城市社会救助审核系统的应用场景示意图。如图1所示，基于物联网的智慧城市社会救助审核系统的应用场景100可以包括处理设备110、网络120、存储设备130、金融管理系统140、医疗系统150、食品发放系统160、社会救助系统170以及公交系统180。

在一些实施例中，应用场景100的一个或多个组件可以经由网络120(例如无线连接、有线连接或其组合)，以实现彼此连接和/或通信。如图1所示，处理设备110可以通过网络120连接到存储设备130。又例如，处理设备110可以通过网络120连接到医疗系统150和食品发放系统160。

处理设备110可以用于处理与应用场景100有关的信息和/或数据，例如，社会救助申请、审核辅助信息等。处理设备110可以处理从其他设备或应用场景100组成部分中获得的数据、信息和/或处理结果，并基于这些数据、信息和/或处理结果执行程序指令，以执行本说明书中描述的一个或以上功能。在一些实施例中，处理设备110可以被配置为用于社会救助管理平台的平台维护及管理工作。

网络120可以连接应用场景100的各组成部分和/或连接应用场景100与外部资源部分。网络使得各组成部分之间，以及与应用场景100之外其他部分之间可以进行通讯，促进数据和/或信息的交换。网络可以是局域网、广域网、互联网等，可以是多种网络结构的组合。

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

金融管理系统140可以指为金融提供管理的系统。例如，银行的管理系统等。金融管理系统不仅可以对用户的资金进行管理，还可以保障资金和个人信息的安全。例如，金融管理系统可以对用户的资金进行保管，并通过加密算法、生物识别等方法保障资金和个人信息的安全。

金融管理系统可以包括用户的多种信息。例如，用户的基本信息，如，姓名、手机号码等。又例如，用户的存款信息，如，存款总额等。再例如，用户的消费信息，如，每次消费的金额、每个月消费的金额等。

医疗系统150可以指在医疗体系中使用的系统。例如，医院的药库系统、医院的收费系统、医院的病历系统等。医疗系统可以包括病人的多种信息。例如，病人的基本信息，如，姓名、亲属、朋友等。又例如，病人的病历信息，如，看病次数、病历、看病花费的金额等。再例如，病人的医保信息，如，医保报销的金额、医保报销的次数等。

食品发放系统160可以指对食品发放提供管理的系统。例如，在食品发放前进行审核的系统、进行食品发放的系统等。食品发放系统可以包括领取食品的人的多种信息。例如，领取的人的基本信息，如，姓名、亲属、朋友等。又例如，领取的人的领取信息，如，领取次数、领取食品的总价值、领取的地点和数量等。

社会救助系统170可以指为社会救助提供管理的系统。例如，审核系统、实施社会救助的系统等。社会救助系统可以包括需要救助的人以及各种机构的多种信息。例如，需要救助的人的住址、收入信息、银行流水、征信信息、欺诈风险等。又例如，金融机构，如银行、金融管理中心使用的金融管理系统所包括的用户的多种信息、医保机构，如医保中心使用的医疗系统所包括得病人的多种信息等。

公交系统180可以指为公交提供管理的系统。例如，公交调度系统、乘客坐车记录系统、客流量统计系统等。公交系统可以包括乘客的坐车记录信息。例如，坐车次数、上下车的站点等。

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

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

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

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

图2是根据本说明书一些实施例所示的基于物联网的智慧城市社会救助审核系统的示例性示意图。如图2所示，基于物联网的智慧城市社会救助审核系统200，以下简称为系统200，包括用户平台、社会救助服务平台、社会救助管理平台。在一些实施例中，系统200可以为处理设备110的一部分或由处理设备110实现。

在一些实施例中，系统200可以应用于社会救助的多种场景。在一些实施例中，系统200可以分别获取多种场景下的救助申请数据、救助反馈数据以及救赎施行数据，以得到社会救助运行的管理策略。在一些实施例中，系统200可以基于获取到各个场景下的社会救助相关数据，得到整个区域(如整个城市)的社会救助管理策略。

社会救助的多种场景可以包括如社会救助申请、社会救助审核、救助品发放与管理等场景。例如，可以包括救助申请人数预测、捐赠物资预测、救助品运输管理、救助品存储管理等。需要说明的是以上场景仅为示例，并不对系统200的具体应用场景起限制作用，本领域技术人员可以在本实施例公开的内容基础上，将系统200应用于其他合适的任何场景。

在一些实施例中，系统200可以应用于救助申请人数预测。在应用于救助申请人数预测时，用户平台可以用于采集相应的用户信息，如候选申请人的身份信息、家庭信息、工作信息、救助需求等。社会救助服务平台可以将各个用户的信息汇总至社会救助管理平台，由社会救助管理平台对收到的数据进行分析处理，如根据身份信息、家庭信息、工作信息、救助需求等提取候选申请人的人物特征，再结合历史提出救助申请人的特征，将二者进行比对，对该候选申请人会提出救助申请的概率进行预测，并将概率值大于预设值的认为是会提出救助申请的申请人，进而实现预先评估可能的申请人数，以及进一步获取申请人的分布等信息，以便更好的开展申请的审核工作。如对申请人数可能较多的区域可以增加审核人手等。

在一些实施例中，系统200可以应用于捐赠物资预测的管理。在应用于捐赠物资预测时，用户平台可以用于采集相应的用户信息，如历史捐赠人的近况信息以及候选捐赠人的用户信息，如可以包括身份信息、家庭信息、工作信息、捐赠意向等。社会救助服务平台可以将各个用户的信息汇总至社会救助管理平台，由社会救助管理平台对收到的数据进行分析处理，如根据身份信息、家庭信息、工作信息、捐赠意向等先确定有能力且捐赠意向较强的准捐赠用户，再基于历史信息推测准捐赠用户可能的捐赠品以及对应的金额。同时，社会救助管理平台还可以基于上述数据分析确定捐赠可能性较大的预捐用户，并结合特征比对等方式，确定预捐用户可能捐赠的物品或金额等。

基于上述分析可以实现提前获知可能收到的捐赠物品种类及数量，以便针对不同的捐赠物品设定对应的接受方案，如对于保质期较短的物品需要提前部署发放计划，对于需要冷藏的物品，则需提前准备对应的冷藏仓库等。

在一些实施例中，系统200可以应用于救助品运输管理。在应用于救助品运输管理时，用户平台可以用于采集捐赠人的捐赠物品信息，如物品种类、重量、捐赠地址等。社会救助服务平台可以将各个捐赠用户录入的信息汇总至社会救助管理平台，由社会救助管理平台对收到的数据进行分析处理，如根据捐赠地址对各区域即将收到的捐赠物品数量进行统计，对各类急需物资的分布进行统计等，进而基于就近原则等，采用最优的运输计划将相应的救助物品运输至发放地。

在一些实施例中，系统200可以应用于救助品存储管理。在应用于救助品存储管理时，用户平台可以用于采集捐赠人录入的捐赠物品信息，如物品种类、保质期限、重量、捐赠地址、保存要求等。社会救助服务平台可以将各个捐赠用户录入的信息汇总至社会救助管理平台，由社会救助管理平台对收到的数据进行分析处理，如根据救助物品的种类、保存需求、物资量等，确定对应的保存方案。

以下将以系统200应用于社会救助申请的审核场景为例对系统200进行具体说明。

用户平台210可以是指以用户为主导的平台，包括获取用户的输入以及将信息反馈给用户的平台。在一些实施例中，用户平台210可以用于接收用户需求，例如，接收用户提交的社会救助申请。

社会救助服务平台220可以是指将用户的输入与控制信息传达出去的平台。其连接了用户平台210和社会救助管理平台230。

在一些实施例中，社会救助服务平台220可以基于用户平台210获取救助申请人的社会救助申请，查询社会救助申请是否通过审核，并将所述审核的结果反馈给用户。

社会救助管理平台230可以指对社会救助进行管理的平台。在一些实施例中，社会救助管理平台230可以被配置为通过社会救助服务平台，基于用户平台获取救助申请人的社会救助申请；获取审核辅助信息；基于审核辅助信息对社会救助申请进行审核，确定通过审核的救助对象。

在一些实施例中，社会救助管理平台230可以被配置为将存款限额信息和消费限额信息发送至金融管理系统；通过金融管理系统，基于隐私保护安全计算方式，获取救助申请人的第一特征。

在一些实施例中，社会救助管理平台230可以被配置为基于医疗系统获取救助申请人的医疗知识图谱；基于医疗知识图谱获取救助申请人的第二特征。

在一些实施例中，社会救助管理平台230可以被配置为向医疗系统发送救助对象的医疗辅助信息。

在一些实施例中，社会救助管理平台230可以被配置为基于食品发放系统获取救助申请人的食品领取知识图谱；基于食品领取知识图谱获取救助申请人的第三特征。

在一些实施例中，社会救助管理平台230可以被配置为向食品发放系统发送救助对象的食品辅助信息。

在一些实施例中，社会救助管理平台230可以被配置为基于社会救助系统获取救助申请人的整合信息知识图谱；基于整合信息知识图谱获取救助申请人的信用信息、金融信息、个人医疗信息、关联人员医疗信息、免费食品领取信息、风险人员关联信息、个人历史社会救助申请信息、关联历史社会救助申请信息人员中的至少一种作为风险评估辅助信息；基于风险评估辅助信息对救助对象进行欺诈风险评估，获得救助对象的欺诈风险信息。

在一些实施例中，社会救助管理平台230可以被配置为基于欺诈风险信息确定再评估救助对象；基于公交系统获取再评估救助对象的公交乘坐信息；基于公交乘坐信息对再评估救助对象的欺诈风险信息进行调整。

在一些实施例中，社会救助管理平台230可以被配置为基于再评估救助对象的公交乘坐信息、再评估救助对象的定位信息，对再评估救助对象的欺诈风险信息进行调整。

在一些实施例中，社会救助管理平台可以分为多个分平台，例如，医疗管理分平台、金融管理分平台、食品发放管理分平台、社会救助管理分平台和交通管理分平台等。

医疗管理分平台可以从医保平台获取数据，例如，医疗管理分平台可以从医保平台获取救助申请人的医保数据。

金融管理分平台可以从金融管理系统获取数据，例如，金融管理分平台可以从金融管理系统获取救助申请人的存款和消费数据。

食品发放管理分平台可以从食品发放平台获取数据，例如，食品发放管理分平台可以从食品发放平台获取救助申请人领取免费食品的数据。

社会救助管理分平台可以从社会救助管理分平台数据库获取数据，例如，社会救助管理分平台可以从社会救助管理分平台数据库获取救助申请人的过往救助信息数据。

交通管理分平台可以从交通管理平台数据库获取数据，例如，交通管理分平台可以从交通管理平台数据库获取救助申请人乘坐交通工具的数据。

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

图3是根据本说明书一些实施例所示的基于物联网的智慧城市社会救助审核方法的示例性流程图。如图3所示，流程300包括下述步骤。在一些实施例中，流程300可以由社会救助管理平台230执行。

步骤310，通过社会救助服务平台，基于用户平台获取救助申请人的社会救助申请。

救助申请人可以指对社会救助提出申请的人。例如，低保户、无劳动能力的人由于无法保证基本生活需求，而申请社会救助，提出申请的这些人可以被称为救助申请人。

社会救助申请可以指申请国家和社会给予经济和物质上的帮助。例如，最低生活保障申请、医疗救助申请等。

在一些实施例中，社会救助管理平台可以与社会救助服务平台和用户平台进行通信，通过社会救助服务平台，基于用户平台获取救助申请人的社会救助申请。例如，救助申请人通过用户平台提交社会救助申请，社会救助服务平台可以基于社会救助管理平台的请求，从用户平台获取救助申请人的社会救助申请并发送给社会救助管理平台。

步骤320，获取审核辅助信息。

审核辅助信息可以指在审核社会救助申请时，起辅助作用的信息。例如，收入信息、病历信息等。

在一些实施例中，社会救助管理平台可以通过多个管理分平台获取多个数据，将这些数据作为审核辅助信息。例如，社会救助管理平台可以通过医疗管理分平台，从医疗系统获取数据，将获得的数据作为审核辅助信息。又例如，社会救助管理平台可以通过金融管理分平台，从金融管理系统获取数据，将获得的数据作为审核辅助信息。

在一些实施例中，社会救助管理平台可以通过以下方法获取审核辅助信息：将存款限额信息和消费限额信息发送至金融管理系统；通过金融管理系统，基于隐私保护安全计算方式，获取救助申请人的第一特征。

存款限额信息可以指对存款进行限定的额度信息。例如，存款限额信息可以包括总存款的总额限定信息、对每日存款和/或每笔存款的数额、次数的限定信息，如，存款限额信息为总存款额不高于5万、单笔存款限额为3000元，日累计存款限额为5000元，存款日累计笔数不能超过5笔等。

在一些实施例中，社会救助管理平台可以基于人工的输入，确定存款限额信息。例如，若人工输入的信息为存款限额信息为总存款额不高于5万，则社会救助管理平台可以将总存款额不高于5万确定为存款限额信息。

消费限额信息可以指对消费进行限定的信息。例如，对每日消费和/或每笔消费的数额、次数的限定信息，如，单笔消费限额为300元，日累计消费限额为1000元，消费日累计笔数不能超过6笔等。

在一些实施例中，社会救助管理平台可以基于人工的输入，确定消费限额信息。例如，若人工输入的信息为单笔消费限额为300元，则社会救助管理平台可以将单笔消费限额为300元确定为消费限额信息。

隐私保护安全计算方式可以指能够保护隐私的计算方式。例如，多方安全计算，如，密钥分享、随机预言机等。

在一些实施例中，多个金融管理系统对各自系统所包括的信息进行隐私保护安全计算并得到结果，社会救助管理平台可以将得到的多个结果进行汇总以得到最终结果，并将最终结果作为存款和/或消费信息。

通过多方安全计算，可以在无可信第三方的前提下保证参与计算的各方成员的信息不暴露，而且同时能够获得准确的运算结果，可以保护用户隐私。

救助申请人的第一特征可以指表征救助申请人的存款和/或消费是否超过限制的特征。救助申请人的第一特征可以有文字、数字等多种表示方式。例如，“存款超过限制”、“消费超过限制200％”等。

在一些实施例中，可以通过存款限额信息和/或消费限额信息判断存款和/或消费是否超过限制。在一些实施例中，金融管理系统可以将对应用户的存款和/或消费信息与存款限额信息和/或消费限额信息进行比较，以确定救助申请人的第一特征并返回给社会救助管理平台。例如，若存款大于存款限额信息规定的总存款额，则向社会救助管理平台返回“存款超过限制”作为救助申请人的第一特征。

关于获取审核辅助信息的更多描述参见图4、5及其说明。

步骤330，基于审核辅助信息对社会救助申请进行审核，确定通过审核的救助对象。

救助对象可以指进行社会救助的对象。例如，已经通过社会救助申请审核的人、正在接受社会救助的人等。

在一些实施例中，社会救助管理平台可以基于审核辅助信息对社会救助申请进行审核，确定通过审核的救助对象。在一些实施例中，社会救助管理平台可以基于符合预设标准的审核辅助信息确定救助对象，如将符合预设标准的审核辅助信息所对应的救助申请人，确定为通过审核的救助对象。

预设标准可以指基于经验对审核辅助信息预先设置的条件。预设标准可以与救助申请人的存款信息、消费信息、医疗信息等相关，例如，预设标准可以为第一特征为存款及消费信息均未超过限制，则若前述获取到的救助申请人的第一特征为存款及消费信息均未超过限制时，则该救助申请人可以被认定为救助对象。

本说明书的一些实施例使用审核辅助信息对社会救助申请进行审核，可以提高审核的准确率，同时使用多方安全计算可以保护用户隐私。

图4是根据本说明书一些实施例所示的获取审核辅助信息的示例性流程图。如图4所示，流程400包括下述步骤。在一些实施例中，流程400可以由社会救助管理平台230执行。

步骤410，基于医疗系统获取救助申请人的医疗知识图谱。

医疗知识图谱可以指与医疗相关的知识图谱。医疗知识图谱可以包括多个节点和多条边。在医疗知识图谱中，节点的类型可以包括对象节点和机构节点，其中，对象节点是指以救助申请人及其关系人生成的节点，对象节点也可以被称为人节点，机构节点可以指以医疗机构作为的节点，例如，救助申请人A对应的医疗知识图谱可以包括“对象1”、“对象2”、“第一医院”等多个节点；其中，“对象1”对应救助申请人A，“对象2”是“对象1”的父亲。

在一些实施例中，多个节点之间可以由边进行连接，边可以表示节点之间的关系，边的属性可以包括看病次数、大病次数、严重程度、金额、医保报销次数、医保报销总金额等。例如，“对象1”与“第一医院”之间基于一条边连接，基于该边的属性可以确定“对象1”在“第一医院”产生的看病次数、大病次数、严重程度、金额、医保报销次数、医保报销总金额等信息。在一些实施例中，医疗知识图谱的边可以具有权重(图中未示出)，以表示一个关系人对应的对象节点对于救助申请人对应的对象节点的重要程度。

医疗知识图谱中类型为人的节点(即对象节点)，而且没有箭头指向的节点，可以作为医疗知识图谱中的根节点。例如，如图4所示，“对象1”节点可以作为根节点，这个医疗知识图谱可以被称为对象1的医疗知识图谱，即对象1即为需要进行评估的救助申请人。

在一些实施例中，医疗知识图谱可以提前构建完成，并且可以动态更新。例如，人工提前构建好医疗知识图谱，后续可以根据不同的情况(如，患有新的疾病)，对医疗知识图谱进行更新(如，增加、删除等)。

在一些实施例中，社会救助管理平台可以基于救助申请人身份信息，基于医疗系统获取救助申请人的医疗知识图谱。例如，社会救助管理平台基于救助申请人的身份证号码，可以通过医疗系统查与身份证号码匹配的医疗知识图谱，将其作为救助申请人的医疗知识图谱。

在一些实施例中，社会救助管理平台还可以通过其他方式获取救助申请人的医疗知识图谱。例如，通过人工对医学数据进行标注等。

步骤420，基于医疗知识图谱获取救助申请人的第二特征。

救助申请人的第二特征可以指表征救助申请人的医疗相关信息的特征。例如，第二特征可以包括救助申请人的看病次数、大病次数、疾病的严重程度、花费的金额、医保报销次数、医保报销金额等。在一些实施例中，救助申请人的第二特征可以有文字、数字等多种表示方式。例如，救助申请人看病次数10次、花费123829元、疾病的严重程度为非常严重等。

在一些实施例中，社会救助管理平台可以基于医疗知识图谱中边的属性，获取救助申请人的医疗相关信息，进而确定救助申请人的第二特征。

在救助申请人的医疗知识图谱中，可能存在一个或多个对象节点，与救助申请人的节点进行连接，可以将这些节点称为关系节点，将这些对象节点对应的人称为关系人。例如，如图4所示，若“对象1”为救助申请人，则“对象2”可以被称为“对象1”的关系人。由于血缘关系或其他因素的影响，多个关系人与救助申请人的连接的边的权重可能不同。

在一些实施例中，救助申请人的医疗知识图谱中也可以包括其关系人的医疗相关信息，关系人的医疗相关信息可以作为救助申请人的医疗相关信息的构成部分或影响因素。

关系人的医疗相关信息可以指与关系人疾病相关的多种信息。例如，看病次数、大病次数、疾病的严重程度、花费的金额、医保报销次数、医保报销金额等。

在一些实施例中，社会救助管理平台可以基于医疗知识图谱中从救助申请人对应的节点出发，获取邻度大于或等于1的边连接的对象节点，查这些节点连接医疗机构节点的边的属性，获取关系人的医疗相关信息。邻度可以用于表示节点与节点或节点与边之间的相邻程度，邻度为1的边是指基于当前节点发出的边，关于邻度的更多描述参见图6及其说明。

在一些实施例中，社会救助管理平台可以将救助申请人的医疗相关信息与关系人的医疗相关信息进行汇总，以获取救助申请人的第二特征。例如，若第二特征包含看病次数这一特征，且基于“对象1”的邻度为1的边中连接医疗机构节点的边的属性确定，对象1的看病次数为1次，基于“对象2”的邻度为1的边中连接医疗机构节点的边的属性确定对象2的看病次数为20次，则社会救助管理平台可以将对象1的看病次数和对象2的看病次数进行相加，将相加的结果21作为救助申请人的第二特征中的看病次数信息，即对象1的第二特征中看病次数为21次。第二特征中其他信息如大病次数、医疗金额等获取方式同看病次数，此处不再赘述。

在一些实施例中，社会救助管理平台可以对一个或多个关系人的医疗相关信息进行加权，再将加权的结果与救助申请人的医疗相关信息进行相加，以获取救助申请人的第二特征。仍以上述示例为例，若救助申请人的医疗知识图谱中还包括“对象3”，“对象3”与“对象2”为父女关系，“对象3”与“对象1”通过邻度为2的边连接(即“对象3”与“对象1”之间间隔了“对象2”)，基于“对象3”的邻度为1的边中连接医疗机构节点的边(即图4中连接“对象3”与“第三医院”两个节点的边)的属性确定对象3的看病次数为30次。

在一些实施例中，各个关系人对应的医疗相关信息对应的权重与其边与根节点的邻度值相关，如邻度值越小，说明关系越紧密，则对应的权重越大，如“对象1”和“对象2”之间的权重为0.8，“对象1”和“对象3”之间的权重为0.1，社会救助管理平台可以将对象2的看病次数和对象3的看病次数进行加权，得到加权的结果为看病次数19次，再将加权的结果与对象1的看病次数进行相加，将相加的结果20作为救助申请人的第二特征中的看病次数，即对象1的第二特征中看病次数为20次。第二特征中其他信息如大病次数、医疗金额等获取方式同看病次数，此处不再赘述。

在流程300中，当基于审核辅助信息对社会救助申请进行审核时，前文步骤330所述的预设标准可以与第二特征相关，如预设标准包括看病次数大于N、大病次数大于M。可以理解的是，看病次数大于N、大病次数大于M，可以认为救助申请人的身体状况较差，需要得到救助。

在一些实施例中，流程400还可以包括：向医疗系统发送救助对象的医疗辅助信息。需要说明的是此步骤为非必要步骤，可以根据实际需求设置。

医疗辅助信息可以指与救助对象接受医疗救治相关的信息。例如，姓名、年龄、身份证号码、既往病史等。

在一些实施例中，社会救助管理平台可以向医疗系统发送救助对象的医疗辅助信息。如此设置，可以免去医疗系统再次对已经通过社会救助申请的人的医疗救助审核，使其可以及时享受到医疗救助。

本说明书的一些实施例从救助申请人及其关系人的身体健康状况来判断其需要救助的程度，如身体较健康的人通常不会申请社会救助，可以进一步提升对于救助申请人的审核的准确性。

应当注意的是，上述有关流程400的描述仅仅是为了示例和说明，而不限定本说明书的适用范围。对于本领域技术人员来说，在本说明书的指导下可以对流程400进行各种修正和改变。然而，这些修正和改变仍在本说明书的范围之内。

图5是根据本说明书另一些实施例所示的获取审核辅助信息的示例性流程图。如图5所示，流程500包括下述步骤。在一些实施例中，流程500可以由社会救助管理平台230执行。

步骤510，基于食品发放系统获取救助申请人的食品领取知识图谱。

食品领取知识图谱可以指与食品领取相关的知识图谱。食品领取知识图谱可以包括多个节点和多条边。与医疗知识图谱类似，在食品领取知识图谱中，节点的类型可以包括人节点(即，对象节点)和机构节点，机构节点可以指以食品发放机构作为的节点。例如，救助申请人A对应的食品领取知识图谱可以包括“对象1”、“对象2”等对象节点，以及“第一食品发放点”、“第二食品发放点”等机构节点。其中，“对象1”对应救助申请人A，“对象2”是“对象1”的父亲。

在一些实施例中，多个节点之间可以由边进行连接，边可以表示节点之间的关系，边的属性可以包括领取次数、领取食品的总价值、领取的地点、领取的数量等。例如，“对象1”与“第一食品发放点”之间基于一条边连接，基于该边的属性可以确定“对象1”在“第一食品发放点”产生的免费食品的领取次数、领取食品的总价值、领取的地点、领取的数量等信息。在一些实施例中，食品领取知识图谱的边可以具有权重(图中未示出)，以表示一个关系人对应的对象节点对于救助申请人对应的对象节点的重要程度。

食品领取知识图谱中类型为人的节点(即对象节点)，而且没有箭头指向的节点，可以作为食品领取知识图谱中的根节点。例如，如图5所示，“对象1”节点可以作为根节点，这个食品领取知识图谱可以被称为对象1的食品领取知识图谱，即对象1即为需要进行评估的救助申请人。

在一些实施例中，食品领取知识图谱可以提前构建完成，并且可以动态更新。例如，人工提前构建好食品领取知识图谱，后续可以根据不同的情况(如，领取新的食品)，对食品领取知识图谱进行更新(如，增加、删除等)。

在一些实施例中，社会救助管理平台可以基于领取人在领取食物时使用的与身份标识绑定的标识码、优惠信息等信息，获取领取人身份信息。与身份标识绑定的标识码、优惠信息等信息可以指与身份绑定的信息，通过这些信息可以确定出领取人唯一的一个身份信息。例如，通过标识码，可以确定身份证号码。

在一些实施例中，社会救助管理平台可以基于救助申请人身份信息，基于食品发放系统获取救助申请人的食品领取知识图谱。例如，社会救助管理平台基于救助申请人的身份证号码，可以通过食品发放系统查与身份证号码匹配的食品领取知识图谱，将其作为救助申请人的食品领取知识图谱。

在一些实施例中，社会救助管理平台还可以通过其他方式获取救助申请人的食品领取知识图谱。例如，通过人工对领取数据进行标注等。

步骤520，基于食品领取知识图谱获取救助申请人的第三特征。

救助申请人的第三特征可以指表征救助申请人的食品领取相关信息的特征。例如，第三特征可以包括救助申请人的领取次数、领取食品的总价值、领取的地点、领取的数量等。在一些实施例中，救助申请人的第三特征可以有文字、数字等多种表示方式。例如，救助申请人领取次数6次、领取食品总价值885元等。

在一些实施例中，社会救助管理平台可以基于食品领取知识图谱中边的属性，获取救助申请人的食品领取相关信息。

在救助申请人的食品领取知识图谱中，可能存在一个或多个对象节点，与救助申请人的节点进行连接，可以将这些节点称为关系节点，将这些对象节点对应的人称为关系人。例如，如图5所示，若“对象1”为救助申请人，则“对象2”可以被称为“对象1”的关系人。由于血缘关系或其他因素的影响，多个关系人与救助申请人的连接的边的权重可能不同。

在一些实施例中，救助申请人的食品领取知识图谱中也可以包括其关系人的食品领取相关信息，关系人的食品领取相关信息可以作为救助申请人的食品领取相关信息的构成部分或影响因素。

关系人的食品领取相关信息可以指与关系人领取食品相关的多种信息。例如，领取次数、领取食品的总价值、领取的地点、领取的数量等。

在一些实施例中，社会救助管理平台可以基于食品领取知识图谱中从救助申请人对应的节点出发，获取邻度大于或等于1的边连接的对象节点，查这些节点连接食品发放机构节点的边的属性，获取关系人的食品领取相关信息。

在一些实施例中，社会救助管理平台可以将救助申请人的食品领取相关信息与关系人的食品领取相关信息进行汇总，以获取救助申请人的第三特征。例如，若第三特征包含领取次数这一特征，且基于“对象1”的邻度为1的边中连接食品发放机构节点的边(如图5中连接“对象1”和“第一食品发放点”两个节点的边)的属性确定，对象1的领取次数为6次，基于“对象2”的邻度为1的边中连接食品发放机构节点的边的属性，确定对象2的领取次数为10次，则社会救助管理平台可以将对象1的领取次数和对象2的领取次数进行相加，将相加的结果16作为救助申请人的第三特征中的领取次数信息，即对象1的第三特征中领取次数为16次。第三特征中其他信息如领取食品的总价值、领取的地点、领取的数量等获取方式同领取次数，此处不再赘述。

在一些实施例中，社会救助管理平台可以对一个或多个关系人的食品领取相关信息进行加权，再将加权的结果与救助申请人的食品领取相关信息进行相加，以获取救助申请人的第三特征。仍以上述示例为例，若救助申请人的食品领取知识图谱中还包括“对象3”，“对象3”与“对象2”为父女关系，“对象3”与“对象1”通过邻度为2的边连接(即“对象3”与“对象1”之间间隔了“对象2”)，基于“对象3”的邻度为1的边中连接食品发放机构节点的边的属性确定对象3的领取次数为30次。

在一些实施例中，各个关系人对应的食品领取相关信息对应的权重与其边与根节点的邻度值相关，如邻度值越小，说明关系越紧密，则对应的权重越大，如“对象1”和“对象2”之间的权重为0.9，“对象1”和“对象3”之间的权重为0.2，社会救助管理平台可以将对象2的领取次数和对象3的领取次数进行加权，得到加权的结果为领取次数11次，再将加权的结果与对象1的领取次数进行相加，将相加的结果17作为救助申请人的第三特征中的领取次数，即对象1的第三特征中领取次数为17次。第三特征中其他信息如领取食品的总价值、领取的地点、领取的数量等获取方式同领取次数，此处不再赘述。

在流程300中，当基于审核辅助信息对社会救助申请进行审核时，前文步骤330所述的预设标准可以与第三特征相关，如预设标准包括领取次数小于K、领取数量小于P。可以理解的是，领取次数小于K、领取数量小于P，可以认为救助申请人的食物来源主要依靠领取的食物，需要得到救助。

在一些实施例中，流程500还可以包括：向食品发放系统发送救助对象的食品辅助信息。需要说明的是此步骤为非必要步骤，可以根据实际需求设置。

食品辅助信息可以指与救助对象接受食品救助相关的信息。例如，姓名、身份证号码、所需的食物等。

在一些实施例中，社会救助管理平台可以向食品发放系统发送救助对象的食品辅助信息。如此设置，可以免去食品发放系统再次对已经通过社会救助申请的人的食品救助审核，使其可以及时享受到食品救助。

本说明书的一些实施例从救助申请人及其关系人的食品领取情况来判断其需要救助的程度，如各个地方到处领取免费食品的人，通常具有更高的欺诈风险，可以进一步提升对于救助申请人的审核的准确性。

应当注意的是，上述有关流程500的描述仅仅是为了示例和说明，而不限定本说明书的适用范围。对于本领域技术人员来说，在本说明书的指导下可以对流程500进行各种修正和改变。然而，这些修正和改变仍在本说明书的范围之内。

可以理解的是，审核这个过程所需的时间较短，可能花费几分钟、几个小时或几天的时间即可完成。为了防止骗取救助的情况的发生，可以长时间地跟踪和收集救助申请人的各种信息，进行分析和处理，以将社会救助提供给真正需要的人。

图6是根据本说明书一些实施例所示的获得欺诈风险信息的示例性流程图。如图6所示，流程600包括下述步骤。在一些实施例中，流程600可以由社会救助管理平台230执行。

步骤610，基于社会救助系统获取救助申请人的整合信息知识图谱。

整合信息知识图谱可以指包括了金融管理系统、医疗知识图谱和食品领取知识图谱中的部分信息或全部信息的知识图谱。整合信息知识图谱与前文所述的医疗知识图谱和食品领取知识图谱类似，可以包括多个节点和多条边。在整合信息知识图谱中，节点的类型可以包括对象节点和机构节点，其中，对象节点是指以救助申请人及其关系人生成的节点，对象节点也可以被称为人节点，机构节点可以指以金融机构、医疗机构、食品发放机构作为的节点。例如，救助申请人A对应的整合信息知识图谱可以包括“对象1”、“对象2”等对象节点，以及“第一银行”、“第一医院”、“第一食品发放点”等机构节点。其中，“对象1”对应救助申请人A，“对象2”是“对象1”的父亲。

在一些实施例中，多个节点之间可以由边进行连接，边可以表示节点之间的关系，边的属性可以包括存款信息、消费信息、看病次数、大病次数、严重程度、金额、医保报销次数、医保报销总金额、领取次数、领取食品的总价值、领取的地点、领取的数量等。例如，“对象2”与“兴隆镇食品发放点”之间基于一条边连接，基于该边的属性可以确定“对象2”在“第二食品发放点”产生的领取次数、领取食品的总价值、领取的地点、领取的数量等信息。在一些实施例中，整合信息知识图谱的边可以具有权重，以表示一个关系人对应的对象节点对于救助申请人对应的对象节点的重要程度。

整合信息知识图谱中类型为人的节点(即对象节点)，而且没有箭头指向的节点，可以作为整合信息知识图谱中的根节点。例如，如图6所示，“对象1”节点可以作为根节点，相应的知识图谱可以被称为对象1的整合信息知识图谱，即对象1即为需要进行评估的救助申请人。在一些实施例中，整合信息知识图谱可以提前构建完成，并且可以动态更新。

在一些实施例中，节点还可以具有属性。节点的属性可以指表征节点的性质的统称。在一些实施例中，人节点的属性可以包括住址信息、银行流水、收入信息、征信数据、欺诈风险值等。欺诈风险值可以指进行救助申请欺诈的可能性。欺诈风险值可以用0至1之间的数字进行表示，数字越大，表示越有可能进行欺诈，关于欺诈风险值及其获取等进一步说明参见步骤630的说明。机构节点的属性可以包括机构地址、所属区域等信息。

在一些实施例中，人节点的属性和机构节点的属性可以通过读取存储在存储设备中的相关信息进行获取。例如，存储设备中存储了对象1的住址信息、银行流水、收入信息、征信数据、欺诈风险值等信息，“对象1”节点的属性可以通过读取存储设备中对象1的上述信息进行获取。

在一些实施例中，人节点的属性和机构节点的属性还可以通过其他的方式进行获取。例如，通过互联网、人工标注等。

在整合信息知识图谱中，边的类型可以至少分为以下六类：“直系亲属”类型、“住址相同”类型、“流水往来”类型、“医疗相关”类型、“免费食品领取”类型、“救助申请”类型。

边也可以具有属性。边的属性可以指表征节点之间的关系的统称。例如，两个节点的从属关系等。在一些实施例中，边的属性可以表示各自的特征数据。例如，如图6所示，连接节点“对象1”和节点“第一银行”的边的属性可以表示对象1在第一银行的存款信息、取款信息等。

“直系亲属”类型的边可以为连接人节点与人节点的边。“直系亲属”类型包括的边可以表示人与人之间的亲属关系。“直系亲属”类型包括的边的属性可以包括：父子、母子、夫妻等。如图6中连接“对象1”与“对象2”的边即属于“直系亲属”类型的边，且图6中该边的属性为父子。

“住址相同”类型的边可以为连接人节点与人节点的边。“住址相同”类型包括的边的属性可以表示人与人之间的住址是相同的。例如，通过查询两个人A和B的住址信息，若发现他们住在同一个房子中，则节点A和节点B存在一条类型为“住址相同”的边。如图6中连接“对象2”与“对象3”的边即属于“住址相同”类型的边，且图6中该边的属性为住址相同。

“流水往来”类型的边可以为连接人节点与金融机构节点的边。“流水往来”类型包括的边可以表示人和金融机构的流水往来。基于这种类型的边的属性可以确定出对象节点的存款、消费特征，例如存款额、月均消费等。计算方法可以采用图3所述的隐私保护安全计算方式。“流水往来”类型包括的边的属性可以包括发生时间、流水数额、流水去向(如，取钱、存钱、消费)等。如图6中连接“对象1”与“第一银行”的边即属于“流水往来”类型的边，且图6中该边的属性包括发生时间、流水数额、流水去向等。

“医疗相关”类型的边可以为连接人节点与医疗机构节点的边。“医疗相关”类型包括的边可以表示人的医疗相关信息。“医疗相关”类型包括的边的属性可以包括：看病次数、大病次数、疾病的严重程度、花费的金额、医保报销次数、医保报销金额等。如图6中连接“对象1”与“第一医院”的边即属于“医疗相关”类型的边，且图6中该边的属性包括看病次数、大病次数、疾病的严重程度、花费的金额、医保报销次数、医保报销金额等。

“免费食品领取”类型的边可以为连接人节点与免费食品发放机构节点的边。“免费食品领取”类型包括的边可以表示人领取免费食品的相关信息。例如，用户A去过免费食品发放机构B领取过免费食品，还去过免费食品发放机构C领取过免费食品，则节点A和节点B、节点A和节点C都存在一条类型为“免费食品领取”的边。“免费食品领取”类型包括的边的属性可以包括：领取次数(或频率)、领取食品的总价值、领取的地点、领取的数量等。如图6中连接“对象1”与“第一食品发放点”的边即属于“免费食品领取”类型的边，且图6中该边的属性包括领取次数(或频率)、领取食品的总价值、领取的地点、领取的数量等。

“救助申请”类型的边可以为连接人节点与社会救助机构节点的边。“救助申请”类型包括的边可以表示人的救助申请事件。例如，用户A向救助机构B和救助机构C均提出过救助申请，则节点A和节点B、节点A和节点C都存在一条类型为“救助申请”的边。“救助申请”类型包括的边的属性可以包括：救助申请频率(或次数)、救助申请总金额、救助申请通过率(或次数)等。如图6中连接“对象1”与“第一社会救助机构”的边即属于“救助申请”类型的边，且图6中该边的属性包括救助申请频率(或次数)、救助申请总金额、救助申请通过率(或次数)等。

需要说明的是，上述的医疗知识图谱、食品领取知识图谱和整合信息知识图谱，可以存储于任何位置。例如，全部存储在存储设备130。又例如，分别存储在金融管理系统140、医疗系统150、食品发放系统160、社会救助系统170以及公交系统180等其中的一个或多个系统中。同时，使用知识图谱时可以使用相同的知识图谱。例如，需要用到知识图谱的地方，都可以使用整合信息知识图谱，仅需通过筛选节点的类型或边的类型即可将需要的信息进行筛选。例如，将整合信息知识图谱用于获取与医疗相关信息对应的第二特征时，则需要筛选节点类型为人节点及医疗机构节点即可，或筛选属于“医疗相关”的边及其连接的节点。

在一些实施例中，社会救助管理平台可以基于救助申请人身份信息，基于社会救助系统获取救助申请人的整合信息知识图谱。例如，社会救助管理平台基于救助申请人的身份证号码，可以通过社会救助系统查与身份证号码匹配的整合信息知识图谱，将其作为救助申请人的整合信息知识图谱。

在一些实施例中，社会救助管理平台还可以通过其他方式获取救助申请人的整合信息知识图谱。例如，通过人工对多种数据进行标注等。

步骤620，基于整合信息知识图谱获取救助申请人的信用信息、金融信息、个人医疗信息、关联人员医疗信息、免费食品领取信息、风险人员关联信息、个人历史社会救助申请信息、关联人员历史社会救助申请信息中的至少一种作为风险评估辅助信息。

信用信息可以指能够反映人的信用的信息。例如，征信信息、行政处罚信息、法院强制执行信息等。

金融信息可以指与金融活动相关的多种信息。例如，消费信息、存款信息、金融证券交易信息等。

个人医疗信息可以指与本人的医疗相关的信息。例如，生病的次数、就诊的医院、医保报销次数等。

关联人员医疗信息可以指与救助申请人相关联的人(即关系人)的医疗相关的信息。例如，救助申请人的儿子的生病的次数、救助申请人的父亲的就诊的医院、救助申请人的父亲的医保报销次数等。

免费食品领取信息可以指救助申请人和/或关系人关于领取免费食品相关的信息。例如，领取的免费食品的次数、领取的免费食品的总价值、领取的免费食品的地点等。

风险人员关联信息可以指救助申请人与具有欺诈风险的人的关系。例如，若救助申请人的父亲被法院判定为老赖，则风险人员关联信息可以为救助申请人的父亲是个老赖。

在一些实施例中，社会救助管理平台可以通过欺诈风险值与预设阈值进行比较，确定具有欺诈风险的人。例如，若图6中节点“对象2”的属性中欺诈风险值为0.8，社会救助管理平台将其与预设阈值0.6进行比较，超过了预设阈值，可以确定对象2为具有欺诈风险的风险人员，则社会救助管理平台可以确定对象1与风险人员对象2具有关联，且关联关系为父子。

在一些实施例中，救助管理平台还可以通过其他的方式确定具有欺诈风险的人。例如，通过人工标注等。

个人历史社会救助申请信息可以指与救助申请人在过去的一段时间内提交的社会救助申请相关的信息。例如，社会救助申请的次数、社会救助申请的时间等。

关联人员历史社会救助申请信息可以指与救助申请人相关联的人(即关系人)在过去的一段时间内提交的申社会救助申请相关的信息。例如，救助申请人的父亲的社会救助申请的次数、救助申请人的儿子的社会救助申请的时间等。

风险评估辅助信息可以指用于辅助进行风险评估的信息。例如，可以将前述信用信息、金融信息、个人医疗信息、关联人员医疗信息、免费食品领取信息、风险人员关联信息、个人历史社会救助申请信息、关联人员历史社会救助申请信息等其中的一种或多种作为风险评估辅助信息。

在一些实施例中，社会救助管理平台可以从整合信息知识图谱中直接查询相应节点及边的属性，以获取救助申请人的风险评估辅助信息。

在一些实施例中，社会救助管理平台可以从整合信息知识图谱中直接查询救助申请人的节点的属性，以获取救助申请人的信用信息。例如，社会救助管理平台可以通过到救助申请人的节点(如图6中的“对象1”节点)，将节点的属性，如，银行流水、收入信息、征信数据等信息作为救助申请人的信用信息。

在一些实施例中，社会救助管理平台可以从整合信息知识图谱中查询与救助申请人对应的节点的邻度为1且类型为“流水往来”的边的属性，以获取救助申请人的金融信息。例如，社会救助管理平台可以通过到救助申请人对应的节点(如图6中的“对象1”节点)，基于邻度为1且类型为“流水往来”的边(如图6中，连接“对象1”节点和“第一银行”节点的边)的属性，如，发生时间、流水数额等信息，确定为救助申请人的金融信息。

邻度可以表示节点与边相邻的程度。邻度的单位可以为非零自然数。邻度为1的边可以指本节点发出的边。例如，如图6所示，“第一食品发放点”与“对象1”是通过邻度为1的边连接，“第二食品发放点”与“对象1”是通过邻度为2的边连接。邻度的数字越大，表示与本节点的关系越弱。

在一些实施例中，当整合信息知识图谱中存在多条与救助申请人的节点的邻度为1且类型为“流水往来”的边时，社会救助管理平台可以对多条边，使用求和、加权平均等方法，获得救助申请人的金融信息。

在一些实施例中，社会救助管理平台可以从整合信息知识图谱中查询与救助申请人对应的节点的邻度为1且类型为“医疗相关”的边的属性，以获取救助申请人的个人医疗信息。例如，社会救助管理平台可以通过到救助申请人对应的节点(如图6中的“对象1”节点)，基于邻度为1且类型为“医疗相关”的边(如图6中，连接“对象1”节点和“第一医院”节点的边)的属性，如，看病次数、大病次数等信息确定为救助申请人的个人医疗信息，如图6所示，基于“对象1”与“第一医院”之间的边的属性可以获得对象1的个人医疗信息包括看病10次、大病3次、严重程度为非常严重、金额5万元、医保报销次数9次、医保报销总金额3万元等信息。

在一些实施例中，当整合信息知识图谱中存在多条与救助申请人的节点的邻度为1且类型为“医疗相关”的边时，社会救助管理平台可以对多条边，使用求和、加权平均等方法，获得救助申请人的个人医疗信息。

在一些实施例中，社会救助管理平台可以基于整合信息知识图谱中从救助申请人对应的节点出发，获取邻度大于或等于1的边连接的对象节点，查与这些对象节点连接且类型为“医疗相关”的边的属性，以获取救助申请人的关联人员医疗信息。

例如，如图6所示，社会救助管理平台可以基于救助申请人的节点，如，节点“对象1”，获取邻度为1的边连接的对象节点，即，节点“对象2”，查与节点“对象2”直接连接且类型为“医疗相关”的边(即与节点“对象2”邻度为1且类型为“医疗相关”的边)的属性，并将边的属性，如，医保报销次数、医保报销金额等信息确定为救助申请人的关联人员医疗信息。如图6所示，基于“对象2”与“第二医院”之间的边的属性可以获得救助申请人的关联人员医疗信息包括看病3次、大病1次、严重程度为不严重、金额2万元、医保报销次数1次、医保报销总金额1万元等信息。

在一些实施例中，当整合信息知识图谱中存在多条与救助申请人的节点通过邻度为大于或等于1的边连接的对象节点，且各对象节点均有直接连接且类型为“医疗相关”的边时，社会救助管理平台可以对多条边包含的属性信息中与医疗信息相关的特征，使用求和、加权平均等方法，获得救助申请人的关联人员医疗信息。

在一些实施例中，社会救助管理平台可以从整合信息知识图谱中查询与救助申请人对应的节点的邻度为1且类型为“免费食品领取”的边的属性，以获取救助申请人的免费食品领取信息。例如，社会救助管理平台可以通过到救助申请人对应的节点(如图6中的“对象1”节点)，基于邻度为1且类型为“免费食品领取”的边(如图6中，连接“对象1”节点和“第一食品发放点”节点的边)的属性，如，免费食品领取次数、免费食品领取总价值等信息确定为救助申请人的免费食品领取信息。如图6所示，基于“对象1”与“第一食品发放点”之间的边的属性可以获得对象1的免费食品领取信息包括领取次数为16次、领取食品总价值为500元、领取的地点为祥和街道、领取的数量为22个等信息。

在一些实施例中，当整合信息知识图谱中存在多条与救助申请人的节点的邻度为1且类型为“免费食品领取”的边时，社会救助管理平台可以对多条边对应的属性信息中与免费食品领取信息相关的特征，使用求和、加权平均等方法，获得救助申请人的免费食品领取信息。

在一些实施例中，社会救助管理平台可以基于整合信息知识图谱中从救助申请人对应的节点出发，获取邻度大于或等于1的边连接的对象节点，查与这些对象节点连接且类型为“免费食品领取”的边的属性，以获取救助申请人的关联人员免费食品领取信息。

例如，如图6所示，社会救助管理平台可以基于救助申请人的节点，如，节点“对象1”，获取邻度为1的边连接的对象节点，即，节点“对象2”，查与节点“对象2”直接连接且类型为“免费食品领取”的边(即与节点“对象2”邻度为1且类型为“免费食品领取”的边)的属性，并将边的属性，如，免费食品领取次数、免费食品领取总价值等信息确定为救助申请人的关联人员免费食品领取信息。如图6所示，基于“对象2”与“第二食品发放点”之间的边的属性可以获得救助申请人的关联人员免费食品领取信息包括免费食品领取次数为5次、免费食品领取总价值为200元等信息。

在一些实施例中，当整合信息知识图谱中存在多条与救助申请人的节点通过邻度为大于或等于1的边连接的对象节点，且各对象节点均有直接连接且类型为“免费食品领取”的边时，社会救助管理平台可以对多条边包含的属性信息中与免费食品领取信息相关的特征，使用求和、加权平均等方法，获得救助申请人的关联人员免费食品领取信息。

在一些实施例中，社会救助管理平台可以基于整合信息知识图谱中从救助申请人对应的节点出发，获取邻度大于或等于1的边连接的对象节点，将这些对象节点的欺诈风险值加权求和，以获取救助申请人的风险人员关联信息。例如，如图6所示，社会救助管理平台可以基于救助申请人的节点，如，节点“对象1”，获取对象节点为“对象2”和“对象3”，将“对象2”和“对象3”的欺诈风险值加权求和，以获取救助申请人的风险人员关联信息。

在一些实施例中，在社会救助管理平台获取邻度大于1的边连接的对象节点时，可以预先设置最大邻度，以明确关联范围，最大邻度值可以基于经验值确定。例如，预先设置最大邻度为5，社会救助管理平台获取邻度小于等于5且类型为“直系亲属”或“住址相同”的边所连接的对象节点，对到的多个对象节点的欺诈风险值，进行加权计算，以获得救助申请人的风险人员关联信息。

可以理解的是，居住环境在一定程度上可以反映出来欺诈风险的高低。例如，居住在贫民区的人比居住在高档小区的人可能具有更高的欺诈风险。同样可以理解的是，亲属也可能对人是否欺诈产生影响。例如，父母都是诚实守信的人，那么他们的子女欺诈风险就很小。因此，基于救助申请人关联的人员的欺诈风险值综合对救助申请人进行评定，可以进一步提升评定的准确性。

在一些实施例中，基于“直系亲属”类型的边连接的节点获取的信息的权重，可以比基于“住址相同”类型的边连接的节点获取的信息的权重要大。例如，若“对象A”在整合信息知识图谱中邻度为1且类型为“直系亲属”的边连接到“对象B”，邻度为1且类型为“住址相同”的边连接到“对象C”，且对象B和对象C不是同一个人；则在运算时，基于“对象B”获取的信息的权重大于基于“对象C”获取的信息的权重，例如，基于“对象B”获取的信息的权重为0.7，基于“对象C”获取的信息的权重为0.3。

在一些实施例中，基于邻度越大的边连接的节点，获取的信息的权重越小。例如，若“对象A”在整合信息知识图谱中邻度为1的边连接到“对象B”，邻度为2的边连接到“对象C”。则在参与运算时，基于“对象B”获取的信息的权重大于基于“对象C”获取的信息的权重，例如，基于“对象B”获取的信息的权重为0.7，基于“对象C”获取的信息的权重为0.3。

在一些实施例中，社会救助管理平台可以从整合信息知识图谱中查询与救助申请人对应的节点的邻度为1且类型为“救助申请”的边的属性，以获取救助申请人的个人历史社会救助申请信息。例如，社会救助管理平台可以通过到救助申请人对应的节点，基于邻度为1且类型为“救助申请”的边的属性，如，申请次数、申请金额、总申请金额等信息确定为救助申请人的个人历史社会救助申请信息。如图6所示，基于“对象1”与“第一社会救助机构”之间的边的属性可以获得对象1的个人历史社会救助申请信息包括申请次数为6次、申请金额为5000元、总申请金额为30000元等信息。

在一些实施例中，当整合信息知识图谱中存在多条与救助申请人对应的节点的邻度为1且类型为“救助申请”的边时，社会救助管理平台可以对多条边对应的属性信息中与救助申请信息相关的特征，使用求和等方法，获得救助申请人的个人历史社会救助申请信息。

在一些实施例中，社会救助管理平台可以基于整合信息知识图谱中从救助申请人对应的节点出发，获取邻度大于或等于1的边连接的对象节点，查与这些对象节点直接连接且类型为“救助申请”的边的属性信息中，与救助申请信息相关的特征进行加权求和，以获取救助申请人的关联人员历史社会救助申请信息。

在一些实施例中，在社会救助管理平台获取邻度大于1的边连接的对象节点时，预先可以设置最大邻度。例如，预先设置最大邻度为3。

步骤630，基于风险评估辅助信息对救助对象进行欺诈风险评估，获得救助对象的欺诈风险信息。

欺诈风险信息可以指救助申请人进行救助申请欺诈的可能性。欺诈风险信息可以包括有欺诈风险、无欺诈风险、欺诈风险值等。欺诈风险信息可以有数字、文字等多种表示方式。例如，有欺诈风险、欺诈风险值为0.8等。欺诈风险值可以0至1之间的数字表示，数值越大，表示越有可能欺诈。

在一些实施例中，社会救助管理平台可以基于风险评估辅助信息，通过与预先设置的阈值进行比较，获得救助对象的欺诈风险信息。例如，步骤330中的预设标准可以包括预先设置的阈值，如，预设标准可以包括存款金额小于1万元、大病次数大于3次、免费食品领取次数小于10次等，若风险评估辅助信息中的一种或多种信息都不符合预设标准，则社会救助管理平台可以确定救助对象的欺诈风险信息为有欺诈风险。

在一些实施例中，社会救助管理平台可以基于风险预测模型处理风险评估辅助信息，确定救助对象的欺诈风险值。

关于风险评估辅助信息的说明可以参见上述步骤620中的相关描述。

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

在一些实施例中，训练该风险预测模型时，可以使用多个带有标签的训练样本，通过多种方法(例如，梯度下降法)进行训练，从而可以学习到模型的参数。当训练的模型满足预设条件时，训练结束，获取训练好的风险预测模型。

训练样本可以包括历史整合信息知识图谱中的人节点的相关信息。例如，历史风险评估辅助信息。历史风险评估辅助信息可以包括历史信用信息、历史个人医疗信息、历史关联人员信息、历史免费食品领取次数等。关于历史风险评估辅助信息的描述可以参见上述风险评估辅助信息的说明。训练样本的标签可以是历史欺诈风险值。训练样本的标签可以通过人工标注进行获取。例如，将存在骗救助行为(或多次骗救助，因为单次可能是模型误判)的人的标签置为1，将明显不存在骗救助行为(可通过人工评估)的人的标签置为0。在一些实施例中，风险预测模型可以在另外的设备或模块中被训练。

在一些实施例中，社会救助管理平台可以将救助对象的欺诈风险值赋值给该救助对象的节点属性中的欺诈风险值。如此设置，可以方便后续将该救助对象用于其他对象的欺诈风险的判断。

在一些实施例中，社会救助管理平台可以基于其他信息，对救助对象进行多次评估。例如，社会救助管理平台基于救助对象穿的衣服、使用的手机，对救助对象进行再次评估。

可以理解的是，大多数需要救助的人的出行工具基本是公共交通工具，例如，公交、地铁等。因此，其他信息可以包括公交乘坐信息。

在一些实施例中，流程600还可以包括：基于欺诈风险信息确定再评估救助对象；基于公交系统获取再评估救助对象的公交乘坐信息；基于公交乘坐信息对再评估救助对象的欺诈风险信息进行调整。

再评估救助对象可以指已经经过了评估的救助对象。例如，经过一次评估的救助对象。在一些实施例中，再评估救助对象可以包括经过了评估，但是欺诈风险值较高的救助对象。

在一些实施例中，社会救助管理平台可以将欺诈风险值超过阈值的救助对象确定为再评估救助对象。例如，社会救助管理平台将欺诈风险值超过60％的救助对象确定为再评估救助对象。

在一些实施例中，救助管理平台可以通过对象节点的属性，获取欺诈风险值。例如，救助管理平台基于节点“对象1”的属性中包括的欺诈风险值，获取节点“对象1”的欺诈风险值。

在一些实施例中，管理平台可以通过风险预测模型的输出，获取欺诈风险值。

公交乘坐信息可以指与乘坐公交相关的信息。例如，上车的站点、下车的站点、乘坐公交的次数等。

在一些实施例中，社会救助管理平台可以基于再评估救助对象的身份信息，通过查询公交系统，得到再评估救助对象的公交乘坐信息。

在一些实施例中，社会救助管理平台可以基于公交乘坐信息对再评估救助对象的欺诈风险信息进行调整。

在一些实施例中，社会救助管理平台可以基于再评估救助对象的乘坐公交的次数多，降低再评估救助对象的欺诈风险信息中的欺诈风险值。在一些实施例中，社会救助管理平台可以基于地域信息、公交起止点，将再评估救助对象的欺诈风险信息中的欺诈风险值降低不同的程度。例如，某个地区的私家车道很堵，而公交车道很宽敞，因此很多人选择公交出行，所以这种地区中经常坐公交的人不一定是需要救助的人，因此对于这种地区，降低程度可以减小。

在一些实施例中，社会救助管理平台可以将调整后的救助对象的欺诈风险信息中的欺诈风险值，赋值给整合信息知识图谱该救助对象对应的对象节点的属性中的欺诈风险值。如此设置，可以方便后续将该救助对象用于其他对象的欺诈风险的判断。

本说明书的一些实施例基于公交乘坐信息，对救助对象进行再次评估，考虑的特征更加全面，可以提高评估的准确率。

在一些实施例中，社会救助管理平台可以基于公交乘坐信息，结合其他的信息，对再评估救助对象的欺诈风险信息进行调整。例如，结合再评估救助对象的同行者的信息、再评估救助对象的经常乘坐的公交线路等。

在一些实施例中，社会救助管理平台可以基于再评估救助对象的公交乘坐信息、再评估救助对象的定位信息，对再评估救助对象的欺诈风险信息进行调整。例如，再评估救助对象的定位信息显示其正在快速移动，但查询不到他的公交乘坐信息，说明该人员很可能开私家车或打车出行，社会救助管理平台可以提高他的欺诈风险信息中的欺诈风险值。

定位信息可以指救助对象所处的地理位置。例如，救助对象在地图上的实时移动轨迹。在一些实施例中，社会救助管理平台可以基于再评估救助对象随身携带的手机等可以定位的装置，获取定位信息。

在一些实施例中，社会救助管理平台可以将调整后的救助对象的欺诈风险信息中的欺诈风险值，赋值给整合信息知识图谱该救助对象对应的节点的属性中的欺诈风险值。如此设置，可以方便后续将该救助对象用于其他对象的欺诈风险的判断。

本说明书的一些实施例不仅基于公交乘坐信息，还基于定位信息，对救助对象进行再次评估，考虑的特征更加全面，可以进一步提高评估的准确率。

本说明书的一些实施例使用整合信息知识图谱和风险预测模型，基于知识图谱提供的海量数据以及机器学习模型的高准确率的判别，可以有效地识别出目标人员的欺诈风险，从而有助于社会救助机构进行精准救助。

应当注意的是，上述有关流程600的描述仅仅是为了示例和说明，而不限定本说明书的适用范围。对于本领域技术人员来说，在本说明书的指导下可以对流程600进行各种修正和改变。然而，这些修正和改变仍在本说明书的范围之内。

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

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

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

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

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

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

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