消息过滤的方法、装置、中间服务器及车联网系统与流程

本发明涉及通信技术领域，尤其涉及一种消息过滤的方法、装置、中间服务器及车联网系统。

背景技术：

在通信技术领域中，对象之间往往利用消息进行信息交互，例如短信息服务(shortmessageservice，简称sms)、即时消息(instantmessaging，简称im)、电子邮件等都是目前应用普遍的通信方式。这些通信方式虽然给用户提供了低成本高效率的便捷通信，但也会不可避免地带来负面影响，例如垃圾邮件、骚扰短信、攻击消息都会给用户带来困扰。

现有技术给出了过滤上述恶意消息的方式，作为消息转发的中间服务器而言，在接收到作为消息发送端的业务方发送的消息后，对消息内容进行识别，如果消息内容中包括违禁词、敏感词等特定关键词，则将该消息判定为恶意消息并予以过滤，而对于不包含上述特定关键词的安全消息而言，中间服务器按照正常流程将其转发给作为消息接收端的用户侧设备。

在上述过滤恶意消息的过程中发明人发现，对消息内容的识别需要针对每条消息进行字符串匹配、关键词词库比对等操作，在一些更加高级的算法中，可能还会涉及到语义识别甚至情感倾向性分析。日常生活中，中间服务器转发消息的数量非常庞大，内容识别过程涉及的计算量不容小视，这种过滤方式一方面会增加中间服务器的资源开销，另一方面也会降低消息的转发速度，可见，现有过滤恶意消息的方式效率比较低下。

技术实现要素：

本发明实施例提供了一种消息过滤的方法、装置、中间服务器及车联网系统，能够解决消息过滤效率不高的问题。

为解决上述问题，第一方面，本发明实施例提供了一种消息过滤的方法，该方法包括：

接收业务方发送的目标消息；

判断业务方发送消息的频率是否超过预设的频率阈值；

若判断结果为是，则拒绝转发目标消息；

若判断结果为否，则将目标消息转发给消息接收方。

第二方面，本发明实施例还提供了一种消息过滤的装置，该装置包括：

接收单元，用于接收业务方发送的目标消息；

频率判断单元，用于判断业务方发送消息的频率是否超过预设的频率阈值；

发送单元，用于当判断结果为是时，拒绝转发目标消息；

发送单元还用于当判断结果为否时，将目标消息转发给消息接收方。

第三方面，本发明实施例还提供了一种中间服务器，该中间服务器包含上述第二方面所指的装置。

第四方面，本发明实施例还提供了一种车联网系统，该车联网系统，包括：如上述第三方面所指的中间服务器及安装在车辆中的车机系统；

车机系统，用于输出中间服务器转发的目标消息。

本发明实施例提供的消息过滤的方法、装置、中间服务器及车联网系统，能够根据业务方发送消息的频率判断目标消息是否为恶意消息，并基于此判断结果对目标消息进行相应处理。与现有技术中识别消息内容中是否包含关键词的方式相比，本发明实施例无需对消息内容进行解析、匹配、对比等一系列文本处理操作，仅需要根据消息发送的频率参数即可实现恶意消息的识别，能够大大减少中间服务器的计算量，提高消息转发的速度。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例提供的一种实现消息过滤的网络架构示意图；

图2示出了本发明实施例提供的第一种消息过滤的方法流程图；

图3示出了本发明实施例提供的第二种消息过滤的方法流程图；

图4示出了本发明实施例提供的第三种消息过滤的方法流程图；

图5示出了本发明实施例提供的消息过滤及分发的业务流程图；

图6示出了本发明实施例提供的第一种消息过滤的装置的结构示意图；

图7示出了本发明实施例提供的第二种消息过滤的装置的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

为便于本发明实施例的说明和理解，首先对本发明实施例基于的网络架构进行简单介绍。如图1所示，该网络架构涉及业务方、中间服务器及消息接收方三侧。其中，业务方为消息发送端，通过中间服务器向消息接收方发送消息，中间服务器用于存储及转发业务方发送给消息接收方的消息。本发明实施例基于中间服务器对消息进行过滤。实际应用中，业务方可以是一切具有消息单发或群发功能的系统，例如汽车销售系统(向用户发送某些销售信息)、账号服务系统(向用户发送账号登录验证短信)、app服务器(向用户app推送更新通知)、商家服务器(向用户发送广告邮件)、或者是用户终端。中间服务器可以是一个独立的服务器，也可以是由多个服务器组成的分布式的服务器集群，或者还可以是集成有通信、存储、转发、数据处理功能的终端。消息接收方一般为用户侧的客户端，例如邮箱、app、短信箱等。此外，实际应用中，消息的种类包括但不限于是：邮件、短信、即时消息、广播消息、推送通知等。

基于上述网络架构，本发明实施例提供了一种消息过滤的方法，该方法基于中间服务器侧实现，如图2所示，该方法包括：

201、接收业务方发送的目标消息。

中间服务器可以负责一个或多个业务方的消息转发任务，通过预先分配的业务方标识对业务方进行区分和管理。实际应用中，可以使用业务方的ip地址、mac地址、服务器序列号、业务名称、邮件地址、短信群发器号码等信息作为业务方标识使用，也可以由中间服务器为业务方分配专用的、并能够起到唯一标记作用的标识，例如对业务方属性信息进行md5运算获得的md5值、或者为业务方生成的二维码、或者仅仅通过随机数生成程序为业务方分配的随机标识。

业务方向中间服务器发送的消息中至少需要携带业务方标识和业务接收方标识(例如用户终端的ip地址、邮箱地址、手机号等)，中间服务器将两种标识建立映射关系并进行管理，由此区分将哪些业务方的消息发送给哪些消息接收方。

202、判断业务方发送消息的频率是否超过预设的频率阈值。

在接收到目标消息后，中间服务器对目标消息进行检测，判断其是否为恶意消息。如果目标消息为恶意消息则执行步骤203，如果目标消息为安全消息，则执行步骤204。

本实施例中定义的恶意消息是指对用户正常使用客户端造成干扰或者非法的消息，例如诈骗消息、广告推送消息、涉黄涉恐消息、包含钓鱼网站的消息等。除根据消息内容进行划分外，还可以根据消息发送方式对恶意消息进行定义，例如在ddos攻击环境中，攻击者会向企业服务器发送大量内容无实际意义的请求，以期占用服务器的并发数，这种消息因为会致使用户服务器瘫痪也可被定义为恶意消息。实际应用中，一切具有非正常发送特点的消息(例如重复性发送、短时间内大量发送或者发送对象过多等)均可以定义为恶意消息。与此相反，除恶意消息之外的其他正常消息，在本实施例中被称为安全消息。

与现有技术不同的是，本实施例无需基于消息内容识别恶意消息，而是通过业务方发送消息的行为特点识别恶意消息。例如诈骗消息具有受众面广泛的特点、ddos攻击具有短时间大量推送的特点。这些特点决定了恶意消息具有消息发送数量巨大这一显著共性，而消息数量反映在一段时间内的则是消息发送的频率，因此本实施例以消息发送频率作为衡量消息合法性的验证维度，对恶意消息进行识别。当业务方需要发送某个目标消息，如果中间服务器检测到该业务方在此之前的一段时间内发送消息的频率过高，将其希望发送的目标消息认定为恶意消息。

本实施例中，判断消息发送频率的角度有两种：其一是着眼于业务方，获取该业务方在一段时间内的消息发送频率，这种角度不限定该业务方发送消息的种类和内容，实际应用中，某个业务方可能发送某个消息的频率过高，也可能发送多种消息的总体频率过高；其二是着眼于消息本身，获取某条消息在一段时间内被发送的频率，这种角度不限定发送该消息的业务方的数量，该消息可能由一个业务方全部发出，也可能由多个不同的业务方分别发出。

当着眼于业务方统计消息发送频率时，中间服务器将预设时段内所有携带某个业务方标识的消息归类到该业务方名下，由此统计该业务方在预设时段内发送的消息数量；当着眼于消息本身统计消息发送频率时，中间服务器根据消息标识统计预设时段内不同消息的发送数量。在获得上述任意一种数量后，将其除以预设时段的时长，即可得到相应的消息发送频率。

在计算消息发送频率时，中间服务器可以以发送目标消息的时刻作为时间节点界定预设时段。例如业务方在14点整发送一条目标消息，预设时段的时长为3个小时，那么中间服务器统计从上午11点到下午14点这一时段内业务方或消息的发送频率。

当然，预设时段的选择并不一定基于目标消息的发送时刻确定，中间服务器也可以将发送目标消息时刻之前的任意一个时段作为预设时段使用。例如在上述示例中，当业务方在14点整发送一条目标消息时，中间服务器也可以将上午7点至10点的时段作为统计消息发送频率的预设时段。本实施例不对预设时段的时长进行具体限制。

在本实施例的一种实现方式中，中间服务器可以按照预设的时间粒度对业务方的消息发送频率进行周期性统计，并将最近一次的统计结果作为参考信息进行保存。当业务方需要发送目标消息时，中间服务器读取当前存储的、最近一次的统计结果进行使用。或者，中间服务器也可以对历次获得的统计结果进行整合(例如加总求平均等)并予以保存，在每次获得新的统计结果后根据该统计结果对前次的整合结果进行更新整合，获得新的整合结果，从而通过数据对业务方消息发送频率的变化趋势进行描述。

203、若判断结果为是，则拒绝转发目标消息。

中间服务器将该消息予以丢弃，并向业务方返回消息处理结果。或者中间服务器也可以将目标消息进行保存，以待后续通过其他验证手段对消息的合法性进行进一步验证。作为可选步骤，中间服务器虽然不再将目标消息发送给消息接收方，但是可以向消息接收方发送消息被拦截的通知，以便消息接收方统计之用。

204、若判断结果为否，则将目标消息转发给消息接收方。

若判断结果为否，则中间服务器对目标消息进行消息处理，包括但不限于消息解析、合法校验、分发等。所谓消息解析是指将不同类型消息的报文/数据包格式进行归一化处理，使得不同类型消息能够基于相同报文/数据包协议进行传输；所谓合法校验主要是指对消息的来源、时效性等信息进行验证，例如当消息的来源不明时不对其进行转发，或者当消息中的时间戳信息过期时不再对其进行转发等。在进行消息分发时，中间服务器可以直接将目标消息发送给消息接收方，也可以按照消息或业务方的种类将目标消息加入到相应的发送队列中，由对应该发送队列的第三方系统进行消息发送，例如邮件通过e-mail系统发送、短消息通过sms系统发送、app通知消息通过第三方应用的ios/android平台发送等。此外，本步骤中中间服务器还可能涉及到消息重发或者错误处理等操作过程。其中，当第三方系统返回消息发送失败的响应消息时，中间服务器根据消息属性选择是否进行重发。如果消息的重发属性设置为需要重发则中间服务器对消息的时效性再次进行验证，并且在消息时效性有效前提下进行重发。如果消息的重发属性设置为不需重发，或者作为消息接收方的用户终端卸载了接收消息的app，或者消息接收方明确反馈拒绝接受消息时，中间服务器不再重发消息。对于错误处理，示例性的，当因短信代理商平台宕机或用户终端欠费导致短信发送通道不可用时，中间服务器启动错误处理机制，切换到另一个短信发送通道进行发送，再例如，当用户终端卸载了接收消息的app时，中间服务器启动错误处理机制，将用户终端从消息发送对象列表中移除，此后不再向该对象发送消息。

进一步的，本发明实施例还提供了一种消息过滤的方法，如图3所示，该方法包括：

301、接收业务方发送的目标消息。

302、根据预设的黑白名单对业务方的合法性进行验证。

中间服务器可以预置业务方的黑白名单，其中黑名单用于记录发送恶意消息的业务方或者具有其他不法行为的业务方的标识，相反的除黑名单中记录的业务方以外，其他业务方的标识记录于白名单中。在进行步骤303之前，中间服务器首先从目标消息中获取业务方标识，然后在黑白名单中遍历该标识。若业务方记录于黑名单中，则中间服务器取消步骤303的执行，即取消消息发送频率的判断并直接跳转到步骤306拒绝转发目标消息。若业务方记录于白名单中，则中间服务器继续执行步骤303，判断业务方发送消息的频率是否超过预设的频率阈值。

本实施例中，黑白名单可以由运营人员根据业务方的投诉情况进行手动配置，也可以由中间服务器根据步骤303的判断结果自动配置，例如将消息发送频率超过频率阈值的业务方添加到黑名单中。对于后者方式，实际应用中可以考虑给予业务方从黑名单中移除的机会，例如当某个业务方在一段时间内没有出现消息发送频率过高的情况时，将其标识从黑名单转移到白名单中。

实际应用中，仅使用黑白名单中的一种即可，例如当使用白名单时，如果业务方标识记录于白名单中则执行步骤303，否则执行步骤306；或者当使用黑名单时，如果业务方标识记录于黑名单中则执行步骤306，否则执行步骤303。

此外，实际应用中也可以考虑对灰名单的适当使用，该灰名单用于记录下述业务方的标识：没有足够证据证明该业务方应当记录于黑名单中，同时也没有足够证据证明该业务方应当记录于白名单中，即无法确定合法性的业务方。当消息转发业务的用户服务质量要求侧重于严格过滤恶意消息时，可以按照黑名单业务方的处理方式对灰名单中的业务方进行处理；当用户服务质量要求侧重于消息转发的成功率时，则可以按照白名单业务方的处理方式对灰名单中的业务方进行处理。

与前述图2所示方法相比，本发明实施例通过对业务方黑白名单的过滤能够减少消息发送频率的判断次数，更加快速高效的实现恶意消息的识别。

303、判断业务方发送消息的频率是否超过预设的频率阈值。

本实施例给出以下两种频率判断方式：

1、针对业务方进行发送频率计算

本方式中，中间服务器判断发送目标消息的业务方的消息发送频率是否超过预设的频率阈值。示例性的，假设业务方1在预设时段[12:00，14:00]内发送了2000条消息a、3000条消息b以及5000条消息c，那么在业务方在2个小时内的业务方1的消息发送频率为(2000+3000+5000)/2＝5000条/小时。

或者假设业务方2在预设时段[13:00，14:00]内发送了8000条消息a，那么在业务方在1个小时内的消息发送频率为8000条/小时。

2、针对消息进行发送频率计算

本方式中，中间服务器判断目标消息被发送的频率是否超过预设的频率阈值。示例性的，假设在预设时段[12:00，14:00]内，业务方1、业务方2、业务方3发送消息a的数量分别是1000条、3000条和5000条，那么在2个小时内的消息a的发送频率为(1000+3000+5000)/2＝4500条/小时。

实际应用中，中间服务器可以使用上述任意一种方式进行发送频率的判定，也可以分别通过上述两种方式进行发送频率的判定，并且在任意一种判定方式判定发送频率过高时，确定拒绝发送目标消息；或者在上述两种判定方式均判定发送频率过高时，确定拒绝发送目标消息。

若中间服务器判断业务方发送消息的频率未超过预设的频率阈值时，执行步骤304，否则跳转到步骤306。

304、判断目标消息发送失败的次数是否超过预设的次数阈值。

实际应用中，用户可以选择拒绝接收对自己无用的消息，而对用户无用的消息往往大部分都是恶意消息，基于用户对消息的拒接行为可以从侧面判断出目标消息是否为恶意消息。在发送目标消息前，中间服务器首先检查该目标消息之前是否发送给消息接收方，若之前向消息接收方发送过目标消息，并且消息接收方对该目标消息进行了多次拒收，则断定该目标消息为恶意消息。

具体的，中间服务器在每重发一次消息时，对对应该消息的发送次数的计数器进行一次加1处理。在发送目标消息前，中间服务器根据消息标识查找对应该目标消息的计数器，如果之前没有重发过目标消息，则计数器为1，如果之前重发过1次目标消息，则计数器为2以此类推。中间服务器读取计数器中的数值，判断该数值是否超过预设的次数阈值，如果超过则执行步骤306，拒绝转发该目标消息；如果未超过，则中间服务器根据目标消息的时间戳校验其消息的时效性，并在时效性有效的情况下执行步骤305，将目标消息发送给消息接收方。

305、将目标消息发送给消息接收方。

306、拒绝将目标消息发送给消息接收方。

进一步的，如图4所示，本发明实施例还提供了一种消息过滤的方法，如图4所示，该方法包括：

401、接收业务方发送的目标消息。

402、根据预设的黑白名单对业务方的合法性进行验证。

403、判断业务方发送消息的频率是否超过预设的频率阈值。

本实施例中步骤401至步骤403的实现方式依次与图3中步骤301至步骤303的实现方式相同，此处不再赘述。

404、对目标消息进行关键词识别。

与图3方案不同的是，当中间服务器判断业务方发送消息的频率未超过预设的频率阈值时，替换执行步骤404，对目标消息进行关键词识别。若目标消息包含预设的敏感关键词，例如反动关键词、涉黄涉恐关键词、广告关键词、诈骗关键词等，则中间服务器执行步骤406，拒绝转发目标消息，否则执行步骤405，将目标消息转发给消息接收方。

实际应用中，可以采用现有技术中的文本识别技术及识别恶意消息使用的字典库进行关键词识别，本实施例对此不作限制。

405、将目标消息发送给消息接收方。

406、拒绝将目标消息发送给消息接收方。

本实施例在频率检测手段的基础上进一步增加了内容识别的检测手段，能够提高检测结果的准确性。同时，由于中间服务器已经通过频率检测手段对一部分消息进行了过滤，步骤404中只需要对少数消息进行内容识别，与现有技术中对所有消息均进行内容识别相比，仍能够节省大量的处理资源。

实际应用中，可以将上述图3及图4方案进行结合使用，例如在业务方发送消息的频率未超过预设的频率阈值后，首先进行消息发送失败次数的判断，在发送次数未超过次数阈值的情况下进一步对消息进行内容识别。或者，首先对消息进行内容识别，在未识别到关键词的情况下进一步进行消息发送失败次数的判断。本发明实施例不对上述两种手段执行的先后顺序进行限制。

进一步的，作为对上述各图所示方法的结合，中间服务器还可以对发送消息产生的日志信息进行统计，日志信息用于记录下述至少一项信息：业务方发送消息的数量、消息接收次数、消息发送失败次数。中间服务器基于日志信息获得上述各方法流程中的判断依据。例如根据业务方发送消息的数量以及预设时段的时长计算消息发送频率、根据消息发送数量与消息接收次数之差计算消息被拒接的次数等。实际应用中，中间服务器可以按照预设时间间隔周期性的进行日志统计，也可以在接收到统计指令时进行日志统计，或者在收到来自消息接收方或用户转发消息的第三方系统的更新信息后进行日志统计。

下面给出本发明实施例的一个应用场景：

如图5所示，各个业务方将消息发送给中间服务器，在消息受理层，中间服务器依次对消息进行黑白名单过滤、发送频率过滤、及规则过滤。其中黑白名单过滤如图3步骤302或图4步骤402所示方式实现，发送频率过滤如图1流程、图3步骤303或图4步骤403所示方式实现，规则过滤如图3步骤304或图4步骤404所示方式或两者之结合实现。对于通过上述过滤手段的消息，根据消息类型进行分类并添加到对应不同类型的消息队列中，例如将短信类型消息添加到短信消息队列中、将邮件类型消息添加到邮件类型队列中等。进入消息队列后，各消息按照“先进先出”的队列规则等待分发。

在消息处理层，中间服务器不断从消息队列中取出消息，并顺次对其进行解析、合法校验及分发处理。其中，解析的目的在于将不同类型消息转换成相同的协议类型以便底层协议统一进行转发；合法校验过程包括但不限于对消息的时效性进行验证；分发处理过程将不同类型消息发送给对应负责发送该类型的第三方系统，由第三方系统将消息发送给消息接收方。例如短信消息通过sms系统发送、安卓app通知消息由安卓系统发送、iosapp通知消息由ios系统发送、邮件类型消息由e-mail系统进行发送、internet、wap、集团企业专用网络等不同类型网络发送的推送消息由apn系统根据网络类型进行区分并实现消息发送。

此外，消息处理层还设置有消息重发及错误处理机制，对于消息重发机制，当消息发送失败时，中间服务器对消息的时效性进行验证，并在消息未失效的情况下重新通过第三方系统发送消息至消息接收方，直至时效性到期；对于错误处理机制，当第三方系统返回发生错误(例如推送不到)的响应消息时，中间服务器进行错误处理。例如，当错误是短信发送通道不可用时(如：短信代理商平台宕机，短信余额不足)，第三方系统自动切换到另一个发送通道；当错误是消息接收方为不可用设备时(例如终端卸载了app、或设置为不接收消息)，第三方系统将该终端进行移除，以后不再对其发送消息。

最后，中间服务器还会对消息转发过程产生的日志信息及消费信息进行统计，为过滤规则提供标准依据。例如统计预设时段内业务方发送的消息数量、消息发送失败次数等。

进一步的，作为本发明实施例的一种实现方式，还可以将上述图2至图5中所示方案应用到车联网领域中，以对发送给车辆的消息进行过滤。在车联网领域中，车辆的车机系统hmi作为上述方法中的消息接收方，接收来自中间服务器转发的消息，并通过语音、屏幕、蜂鸣器、振动等形式输出给驾驶者。这些消息可能是业务方希望推送给车辆的营销信息、或者应用推送给车辆的通知消息，或者来自于邮件服务器的邮件消息或来自短信服务器的短消息。实际应用中，一切经由网络侧推送给车机系统的消息均适用于本实现方式。中间服务器在接收到业务方发送的消息后，按照上述图2至图5所示方法对消息进行频率过滤，拒绝转发恶意或可疑的消息，从而过滤掉推送给车机系统的无用消息，减少车机系统的消息输出频率，降低消息推送对行车安全的不良影响。

进一步的，作为对上述方法的实现，本发明实施例还提供了一种消息过滤的装置，该装置位于中间服务器侧，如图6所示的，该装置包括：

接收单元61，用于接收业务方发送的目标消息；

频率判断单元62，用于判断业务方发送消息的频率是否超过预设的频率阈值；

发送单元63，用于当判断结果为是时，拒绝转发目标消息；

发送单元63还用于当判断结果为否时，将目标消息转发给消息接收方。

进一步的，如图7所示，频率判断单元62，包括：

第一频率判断模块621，用于判断发送目标消息的业务方的消息发送频率是否超过预设的频率阈值；

第二频率判断模块622，用于判断目标消息被发送的频率是否超过预设的频率阈值。

进一步的，如图7所示，该装置还包括：

验证单元64，用于在判断业务方发送消息的频率是否超过预设的频率阈值之前，根据预设的黑白名单对业务方的合法性进行验证；

发送单元63，用于当业务方记录于黑名单中时，取消消息发送频率的判断并直接拒绝转发目标消息；

频率判断单元62，用于当业务方记录于白名单中时，判断业务方发送消息的频率是否超过预设的频率阈值。

进一步的，如图7所示，该装置还包括：

次数判断单元65，用于当判断结果为否时，判断目标消息发送失败的次数是否超过预设的次数阈值；

发送单元63，用于当目标消息发送失败的次数超过次数阈值时，拒绝转发目标消息，否则将目标消息转发给消息接收方。

进一步的，如图7所示，该装置还包括：

识别单元66，用于当判断结果为否时，对目标消息进行关键词识别；

发送单元63，用于当目标消息包含预设的敏感关键词时，拒绝转发目标消息，否则将目标消息转发给消息接收方。

进一步的，如图7所示，该装置还包括：

统计单元67，用于对发送消息产生的日志信息进行统计，日志信息用于记录下述至少一项信息：

业务方发送消息的数量、消息接收次数、消息发送失败次数。

进一步的，消息接收方为车辆的车机系统。

进一步的，本发明实施例还提供了一种中间服务器，该中间服务器位于网络侧，包含如上述图6或图7所示的装置，在业务方与消息接收方之间起到消息传递和消息过滤的作用。

进一步的，本发明实施例还提供一种车联网系统，该车联网系统包括：如上所述的中间服务器及安装在车辆中的车机系统。车机系统，用于输出中间服务器转发的目标消息。

本实施例中车机系统包括但不限于通过语音、屏幕、蜂鸣器、振动等形式将消息输出给驾驶者。

本发明实施例提供的消息过滤的装置、中间服务器及车联网系统，能够根据业务方发送消息的频率判断目标消息是否为恶意消息，并基于此判断结果对目标消息进行相应处理。与现有技术中识别消息内容中是否包含关键词的方式相比，本发明实施例无需对消息内容进行解析、匹配、对比等一系列文本处理操作，仅需要根据消息发送的频率参数即可实现恶意消息的识别，能够大大减少中间服务器的计算量，提高消息转发的速度。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

可以理解的是，上述方法及装置中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(dsp)来实现根据本发明实施例的发明名称(如确定网站内链接等级的装置)中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。