乘客信息处理系统的制作方法

本实用新型涉及信息处理领域，具体而言，涉及一种乘客信息处理系统。

背景技术：

众所周知，乘客在乘坐公交车时，需要在上车时支付费用，这一过程几乎所有公交车都具备。支付费用的手段有多种，例如，现金、公交卡或者电子扫码支付。目前，刷码支付、公交卡等手段已经占据了大量市场。但是，传统刷码支付、刷卡支付，只支持付费。

公交车由于具有人员密集、乘客流动性大、空间封闭等特征，容易导致不少疾病的传播和安全隐患的出现。随着时代和科技的进步，人们自我健康意识越来越高，迫切需要能够识别乘客的健康状况，并对具备不宜乘坐公交车的特征的乘客进行有针对性的识别的方法。然而目前的技术不能让公交系统获取乘客的个人信息，也无法确定乘客的健康状况。

因此，在相关技术中，存在不能获取公交车上乘客的健康状况信息，从而导致乘车不安全的技术问题。

针对上述的问题，目前尚未提出有效的解决方案。

技术实现要素：

本实用新型实施例提供了一种乘客信息处理系统，以至少解决相关技术中，不能获取公交车上乘客的健康状况信息，从而导致乘车不安全的技术问题。

根据本实用新型实施例的一个方面，提供了一种乘客信息处理系统，包括：用户设备，用于获取乘客信息，并将所述乘客信息发送至服务器；所述服务器，用于根据接收的所述乘客信息确定乘客的健康状况信息，并将所述健康状况信息返回给所述用户设备；所述用户设备，还用于根据所述健康状况信息生成乘车二维码，其中，所述乘车二维码包括所述乘客的健康状况信息；二维码扫描装置，位于公交车上，用于扫描所述用户设备提供的所述乘车二维码，解析所述乘客的健康状况信息；信息提示装置，用于根据所述二维码扫描装置解析出的所述乘客的健康状况，发出包括所述乘客的健康状况的提示信息。

可选地，所述用户设备，还用于获取所述乘客的公交到站信息，根据所述公交到站信息和所述健康状况信息生成所述乘车二维码。

可选地，所述二维码扫描装置，还用于根据扫描所述乘车二维码解析出的公交到站信息，确定到站乘客人数，并将确定的到站乘客人数发送给所述信息提示装置；所述信息提示装置，还用于发出包括所述到站乘客人数的提示信息。

可选地，该系统还包括：公交卡刷卡器，位于所述公交车上，用于读取公交卡的信息，其中，所述公交卡中包括所述乘客的健康状况信息。

可选地，该系统还包括：所述公交卡刷卡器，还用于读取所述乘客的到站刷卡信息；所述二维码扫描装置，还用于将根据二维码扫码确定的到站乘客人数与根据所述到站刷卡信息得到的到站乘客人数进行统计，得到总到站乘客人数，并将所述总到站乘客人数发送给所述信息提示装置；所述信息提示装置，还用于发出包括所述总到站乘客人数的提示信息。

可选地，该系统还包括：云数据库，用于存储所述乘客的乘客信息，使用所述用户设备乘车的日志数据，公交车线路及站点索引数据。

可选地，所述信息提示装置包括以下至少之一：进行语音播报的语音提示器，显示画面提示信息的显示器，通过闪耀光的光发生器。

可选地，所述用户设备，还用于通过承载于预定服务软件的第三方插件，处理所述乘客信息以及生成所述乘车二维码；或者通过新开发的应用软件，处理所述乘客信息以及生成所述乘车二维码。可选地，所述用户设备，还用于通过所述乘车二维码完成支付功能。

可选地，所述公交车包括以下至少之一：电动公交车，无人驾驶公交车。

在本实用新型实施例中，采用用户设备获取乘客信息并将信息上传服务器的方式，通过返回乘客健康状况信息并生成二维码，达到了根据乘客上车时展示的二维码解析乘客的健康状况的目的，从而实现了在乘客上车前了解乘客的健康状况信息的技术效果，进而解决了相关技术中，不能获取公交车上乘客的健康状况信息，从而导致乘车不安全技术问题。

附图说明

此处所说明的附图用来提供对本实用新型的进一步理解，构成本申请的一部分，本实用新型的示意性实施例及其说明用于解释本实用新型，并不构成对本实用新型的不当限定。在附图中：

图1是根据本实用新型实施例的乘客信息处理系统的结构框图；

图2是根据本实用新型实施例的用户设备执行乘客信息处理的示意图；

图3是根据本实用新型优选实施方式的用户设备使用插件实现乘客信息处理的示意图；

图4是根据本实用新型实施例的维码扫描装置执行乘客信息处理的示意图；

图5是根据本实用新型优选实施方式的二维码扫描装置处理乘客信息的示意图；

图6是根据本实用新型实施例的用户设备的结构框图；

图7是根据本实用新型实施例的二维码扫描装置的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本实用新型方案，下面将结合本实用新型实施例中的附图，对本实用新型实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本实用新型一部分的实施例，而不是全部的实施例。基于本实用新型中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本实用新型保护的范围。

需要说明的是，本实用新型的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本实用新型的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

根据本实用新型实施例，提供了一种乘客信息处理系统的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1是根据本实用新型实施例的乘客信息处理系统的结构框图，如图1所示，该乘客信息处理系统10包括：服务器12，用户设备14，二维码扫描装置16和信息提示装置18，下面对乘客信息处理系统10进行说明。

服务器12，用于根据接收的乘客信息确定乘客的健康状况信息，并将健康状况信息返回给用户设备；

用户设备14，用于获取乘客信息，并将乘客信息发送至服务器；

该用户设备14，还用于根据健康状况信息生成乘车二维码，其中，乘车二维码包括乘客的健康状况信息；

二维码扫描装置16，位于公交车上，用于扫描用户设备提供的乘车二维码，解析乘客的健康状况信息；

信息提示装置18，用于根据二维码扫描装置解析出的乘客的健康状况，发出包括乘客的健康状况的提示信息。

通过上述乘客信息处理系统，采用用户设备获取乘客信息并将信息上传服务器的方式，通过返回乘客健康状况信息并生成二维码，达到了根据乘客上车时展示的二维码解析乘客的健康状况的目的，从而实现了在乘客上车前了解乘客的健康状况信息的技术效果，进而解决了相关技术中，不能获取公交车上乘客的健康状况信息，从而导致乘车不安全技术问题。

刷码支付已经是一种方便，快捷，安全的支付方式，应用于各种支付流程中。刷码支付是指可以用软件(例如，微信或支付宝)生成的二维码进行支付的交互过程，其中二维码中包括支付信息，在交互过程中，需要使用特定的设备识别并读取。在传统的乘客信息处理系统中，仅支持乘客上车刷码、刷卡后，司机师傅不知乘客到站下车地点，通过按钮提醒和言语交流会增加病毒传播几率，非常不安全，不智能。而且，传统刷码支付、刷卡支付，只为付费而无其他功能。无法收集乘客的详细信息，无法考虑乘客的安全。通过本实用新型实施例的乘客信息处理系统，也可以认为是一种公交车乘客安全智能识别系统，在满足乘客操作习惯的前提下，该系统能为乘客提供安全、卫生的乘车环境。确保对乘客的健康安全负责，能让乘客安心乘坐公交车。另外，该乘客信息处理系统适用性强，无论是司机驾驶还是无人驾驶，均适用，兼容性强。而且，适用人群也没有要求，例如，针对老人和小孩无法使用手机的人群，使用公交卡同样有效。

作为一种优选的实施方式，当用户设备生成乘车二维码时，可以采用多种方式，例如，本系统通过用户设备上一款独立的应用软件实现，也可以采用承载于第三方软件中的插件或者小程序来实现。插件：是一种遵循一定规范的应用程序接口编写出来的程序。能运行在程序规定的系统平台下(可支持多个平台)。例如，可以运行在微信和支付宝平台下。比如，支付宝中的城市服务，微信的第三方服务等等。在本实用新型实施例中，例如，可以承载于作为第三方软件的微信或者支付宝来实现，乘客使用个人信息(例如，手机号)注册并通过验证后，登录即可使用。从而满足大量乘客使用软件乘车扫码的习惯，操作简单快捷，操作简单快捷，不会使用户排斥或带来任何副作用。

作为一种可选的实施例，用户设备中的程序或者插件可以将乘客的健康状况信息与支付功能融合为一体，即融合在同一个乘车二维码中，使二维码升级，一码多用。采用这样的处理，不仅扩展了普通二维码的功能范围，一码多用，提高了二维码功能效益，而且也减轻了乘客乘车需要多次扫码的负担，既能合理收集乘客信息也能完成支付功能，方便乘客使用。

作为一种可选的实施例，上述用户设备，还可以用于获取乘客的公交到站信息，根据公交到站信息和健康状况信息生成乘车二维码。传统的公交车信息处理系统中，乘客上车刷码、刷卡后，司机仅能获知该乘客是否付费，而不知道乘客的到站下车地点。需要乘客主动按按钮提醒司机或者言语交流的方法会增加病毒传播几率，不够卫生，也可能传播其他通过上述方式可以传播的传染病。而根据本优选实施方式，乘客可以主动将下车地点输入用户设备，例如，输入手机的应用程序中，应用程序根据乘客的健康状况信息和/或到站信息生成乘车二维码。该方法从而进一步扩展二维码的使用范围，让乘车二维码发挥更大的作用。

作为一种可选的实施例，公交车上的二维码扫描装置可以扫描乘客的乘车二维码并解析出乘客的公交到站信息，确定到站乘客人数，并将确定的到站乘客人数发送给信息提示装置，信息提示装置还可以根据确定的到站乘客人数，发出提示信息。根据本实施方式，公交司机可以通过信息提示装置了解到下站是否有人到站下车和到站下车的具体人数，减少了信息沟通成本，提高了工作效率。即，乘客提交的站点信息用于司机提前知晓下客站点，减少乘客交流和接触机会，降低了流行疾病传染几率。因此，该二维码扫描装置和信息提示装置，通过乘客的健康状况信息，可以有效避免高风险乘客上车，保障车内乘客安全，防止交叉感染，让乘客安心乘车；通过到站乘客人数，减少乘客交流和接触机会，降低了流行疾病传染几率，实现了基于双层考虑乘客的乘车安全。需要说明的是，该二维码扫描装置和信息提示装置同时兼容无人驾驶模式。

作为一种可选的实施例，本乘客信息处理系统还可以包括位于公交车上的公交卡刷卡器，该刷卡器可以读取公交卡信息，例如，可以读取公交卡中包括的乘客的健康状况信息；此外，公交卡刷卡器还可以用于读取乘客的到站刷卡信息；二维码扫描装置还可以用于将根据二维码扫码确定的到站乘客人数与根据到站刷卡信息得到的到站乘客人数进行统计，得到总到站乘客人数，并将总到站乘客人数发送给信息提示装置；信息提示装置，还用于发出包括总到站乘客人数的提示信息。

因为有的人群没有手机，例如，老人或者儿童，所以在本优选实施方式中，在对公交卡进行升级后，也可以实现类似手机二维码的效果。具体的，公交卡用户到公交公司或指定地点办理公交卡的升级注册即可，方便快捷。因此，针对公交卡用户，只需在注册时提供相关信息，充值时更新信息即可。例如，注册时，可以在公交卡中录入乘客个人的健康状况信息，上车刷卡时，公交卡刷卡器可以读取到用户的健康状况信息，如果该乘客不适宜乘坐公交车，则发出拒绝乘车提示或提示付费失败。

对于公交卡用户，公交卡用户需要再次使用公交卡刷卡器扫描公交卡，提示司机自己将在下一站下车。因此，因公交卡不带输入功能，需要在下车到站前一站点区间再次刷一下卡作为下车提示(此次不扣费)，健康乘客上车后无需交流也减少了不必要的接触，大大降低了某些已知或未知的流行病感染几率。公交车的二维码扫描装置可以将通过二维码扫码确定的到站乘客人数与刷卡提示要到站下车的乘客人数进行统计并反馈给司机，便于司机及时了解情况。例如，当乘客上车后，司机可以通过显示面板知晓乘客到站信息人数(如上述所指的根据二维码扫码确定的到站乘客人数与根据到站刷卡信息得到的到站乘客人数进行统计，得到的总到站乘客人数)，无需乘客提醒，司机会根据当前车上乘客到站信息和公交站是否有乘客需要上车，行驶到相应站点停车。

作为一种可选的实施例，本乘客信息处理系统还可以使用大数据管理分析，将海量的数据进行有效的处理，分析，使乘客的信息更准确、更安全地保存。例如，服务器12可以是云服务器，采用云服务器用于实现公交车与远程通讯信息处理的计算服务，用于处理、保存用户数据。针对乘客信息的管理和健康状况的判断都在云端进行，可以有效的保护乘客隐私，保证乘客的健康状况信息不会在终端泄露。同时，将海量个人信息的存储与检索放到云端，可以有效的降低用户设备和二维码扫描装置的存储和计算负担，提高资源配置效率，降低系统整体成本。其中，云服务器的数据来源包括：app上传的用户注册数据和用户乘车时输入的到站站点信息数据。云服务器是查询、写入、读取云数据库所必备的一个系统单元。云服务器升级可按需求当有新增线路或站点更改时，可同步至云数据库。

作为一种可选的实施例，在云端，还可以使用云数据库。云数据库：是指数据库不在本地，可以远程查看数据信息，方便快捷，成本低，主要提供给云服务器使用。本实用新型所提供的乘客信息处理系统所包括的云数据库，可以用于存储所述乘客的乘客信息，使用所述用户设备乘车的日志数据，公交车线路及站点索引数据。例如，云数据库中包括用户注册信息数据、使用日志数据，可以根据实际需要从用户那里获得，让用户在注册小程序或者app的时候填入(例如用户姓名、联系方式、身份证信息、住址、性别等等)。同时还储存有该用户所在城市的所有公交车线路及站点索引，包括不同城市、不同路线、不同站点的序列。在使用app输入乘车站点信息后，程序会根据当前索引查询对应路线的过站车辆(类似百度地图的公交车查询功能)。再次，还可以在云端进行大数据分析。在采用大数据分析时，用户使用app的频率、查询站点、使用时间段、使用区域等信息都会以日志的方式存储在云数据库，如果要优化某一线路运行情况，可以按月按周或者按天来分析数据日志，达到根据用户上下车站点情况、时间段来合理调整运营车辆的目的。

因此，在本实用新型实施例中，采用云数据库用于存储用户数据，云服务器提供可靠性服务。通过公交车上放置的二维码扫描装置或刷卡器获取乘客到站和健康信息，扫描乘客提供的二维码或公交卡，经过云服务器处理后即可得知该乘客是否满足乘车条件，保证乘客上车前均为健康状态，以及到下车的整个乘车过程中均是健康的。

另外，在本实用新型实施例中所采用的云数据库存储，云服务器处理分析，可用于不同城市乃至国家，容量足够大，可移植性强，同时相关乘车数据可提供给公司调度使用，保证在工作日和节假日运行载客状态最佳。

作为一种可选的实施例，乘客信息处理系统中的信息提示装置可以包括以下至少之一：用于语音播报的语音提示器，用于画面显示提示信息的显示器，通过闪耀光进行提醒的光发生器。几种不同的信息提示装置都可以对该乘客的健康状况进行提示，具体选用哪种方法，可以根据具体情况或者司机的偏好进行设置，可以只选用一种信息提示装置或者同时选用两种或者两种以上的信息提示装置。

作为一种可选的实施例，乘客信息处理系统的用户设备，可以还用于通过承载于预定服务软件的第三方插件，处理所述乘客信息以及生成所述乘车二维码；或者通过新开发的应用软件，处理所述乘客信息以及生成所述乘车二维码。因此，用户设备可以通过多种方式生成乘车二维码，可以依据用户需要灵活选择。

作为一种可选的实施例，用户设备生成的乘车二维码还可以完成支付功能。通过将支付功能与健康信息确认功能融合在一个二维码上，可以大大提高系统的效率。每次乘车过程，用户只需要扫描一次二维码即可，方便快捷，不会造成用户的烦琐和抵触。

作为一种可选的实施例，可以应用本乘客信息处理系统的公交车可以包括电动公交车，无人驾驶公交车。因为包括乘客上车通过扫码或者刷卡完成付费与健康状况确认，下车时的到站确认，都可以通过该乘客信息处理系统完成，所以乘客与公交车的全程交互都可以在无工作人员在场的情况下完成，这就为无人驾驶公交车的工作模式提供了设备基础。该系统可以很好地将乘客的信息与意愿进行处理与反馈，后续只要将本系统收集到的乘客信息传输给无人驾驶系统，无人驾驶系统就能够根据乘客的需求进行进一步的操作。

实施例2

从乘客信息处理系统所包括的用户设备而言，图2是根据本实用新型实施例2的用户设备执行乘客信息处理的示意图，如图2所示，包括：

s202，获取乘客的乘客信息，并将乘客信息发送至服务器；

s204，接收服务器依据乘客信息返回的乘客的健康状况信息；

s206，根据健康状况信息生成乘车二维码，其中，乘车二维码包括乘客的健康状况信息；

s208，展示乘车二维码，其中，乘车二维码用于在公交车上提示乘客的健康状况。

通过用户设备的上述处理，采用获取乘客信息并将乘客信息上传服务器，通过接收服务器依据乘客信息返回的乘客的健康状况信息生成乘车二维码，达到了根据乘客上车时展示的二维码解析乘客的健康状况的目的，从而实现了在乘客上车前了解乘客的健康状况信息的技术效果，进而解决了相关技术中，不能获取公交车上乘客的健康状况信息，从而导致乘车不安全技术问题。

作为一种可选的实施例，用户设备根据所述健康状况信息生成乘车二维码可以包括：获取所述乘客的公交到站信息；根据乘客的公交到站信息和健康状况信息生成乘车二维码。

图3是根据本实用新型优选实施方式的用户设备使用插件实现乘客信息处理的示意图，如图3所示，包括：

步骤301，使用手机打开微信、支付宝或应用程序app，找到智能安全乘车小程序或提前去对应站点注册公交卡，注册目的是生成用户健康信息。具体的，乘客注册后每隔5天(可根据实际需求调整)，可以重新验证健康状态，操作步骤和新用户注册一致。重复验证健康状态是为了防止这期间，用户接触外来人员或其他情况导致感染疾病。

步骤302，新用户可以使用手机号码登录，验证码方式验证，完成注册即可。此时后台数据库会存储用户基本面信息以及手机号漫游记录、使用区域、以及往日行动轨迹等信息。乘客数据保存至云数据库后可根据当日客流量进行相应的调度处理，满足调度需求。

步骤303，用户进行登录操作，如果上次登陆过，则可以不用再次输入验证码，直接进入乘车界面。小程序运行后台需要定位用户当前位置，这样可以支持公交车辆站点查询，支持调用解析乘车二维码，(或提供乘客信息给平台，由平台生成包含乘客信息的二维码)，并在二维码中加入用户健康信息。乘车时提供二维码信息，用于扫码使用。

步骤304，找到对应提示窗口，输入乘车站点或到站站点、公交车辆、目的地等信息，进行行程查询。若乘客当前地理位置在乘车站点路线范围内时，选择乘车下车站点后，小程序提供乘车二维码。为安全考虑，二维码可以10秒钟失效，需要重新刷新，具体时间根据实际情况决定。公交卡用户无需此步骤，上车刷卡即可。

步骤305，如果输入的站点、地点等输入的目标地理位置经过查询后不能由公交车直达或者换乘，则提示无直达或换乘路线，请重新输入。

步骤306，查询或输入完成后，选择站点，点击我要安全乘车，即可获取乘车支付二维码。如果为换乘，则在换乘时刷新二维码或取消操作，上车按当前换乘站扣费。

步骤307，上车时使用注册好的公交卡刷卡支付。

步骤308，在下车前一站区间内刷卡，提示司机需要停靠下车。

从乘客信息处理系统所包括的二维码扫描装置而言，图4是根据本实用新型实施例2的维码扫描装置执行乘客信息处理的示意图，如图4所示，包括：

s402，扫描乘车二维码，其中，乘车二维码包括乘客的健康状况信息；

s404，解析乘车二维码，得到乘客的健康状况信息；

s406，将乘客的健康状况信息发送给信息提示装置，以发出包括乘客的健康状况的提示信息。

通过维码扫描装置的上述处理，采用扫描包括乘客的健康状况信息的乘车二维码，解析乘车二维码，得到乘客的健康状况信息并通过提示装置发出提示信息，达到了根据乘客上车时展示的二维码解析乘客的健康状况的目的，从而实现了在乘客上车前了解乘客的健康状况信息的技术效果，进而解决了相关技术中，不能获取公交车上乘客的健康状况信息，从而导致乘车不安全技术问题。

作为一种可选的实施例，在乘车二维码还包括乘客的公交到站信息的情况下，还可以解析乘车二维码，得到乘客的公交到站信息，并将乘客的公交到站信息发送给信息提示装置，以发出包括乘客的公交到站信息的提示信息。

图5是根据本实用新型优选实施方式的二维码扫描装置处理乘客信息的示意图，如图5所示，包括如下处理：

步骤501，公交车从行驶路段进入停靠车站。

步骤502，乘客上车后展示二维码，通过二维码进行信息交互和支付操作。

步骤503，二维码扫描装置通过扫描二维码，对其中的信息进行记录。公交车扫码及刷卡装置，可以直接使用原车上的二维码扫描装置，但是需要升级系统，以连接远程云服务器或本地服务器，可根据需求灵活选择。目的是存储用户数据为调度和对比健康信息使用。

步骤504，识别二维码相关信息，确保乘客信息满足健康状态。

步骤505，二维码扫描装置进行逻辑判断，若乘客满足健康条件，则进入步骤507，若不满足则进入步骤506。

步骤506，该乘客不满足健康条件，则判断其无法乘坐公交车，终止扣费流程，并进行语音提示，提示信息可以是：风险乘客无法乘车。

步骤507，若该乘客满足乘车条件，进入扣费流程，可以播放语音提示：安全，刷卡成功。

步骤508，扫码装置将记录的乘客到站信息保存到站点列表中，结合语音到站播报系统，每到一个站，则清空该站点下车人数，驾驶员根据到站和刷卡情况停靠。车辆行驶后，扫码装置根据所有用户提供的站点下车信息，重新计数到仪表或显示装置。此处的实现，可以单独使用一个小显示屏，也可以通过can总线集成到仪表上。简易显示情况下，可以只显示一个数字，表示前方到站下车人数，如果为0，则表示前方站点无人下车。无人驾驶模式下，可以显示两组数字，一组表示前方到站下车人数，一组表示前方到站上车人数。

步骤509，若前方站点有乘客下车，则进行停靠，若无乘客下车，再根据站台的上车人数选择是否停靠。

实施例3

图6是根据本实用新型实施例3的用户设备的结构框图，如图6所示，该用户设备60包括：获取模块62，接收模块64，生成模块66和展示模块68，下面对该用户设备60进行说明：

获取模块62，用于获取乘客的乘客信息，并将乘客信息发送至服务器；

接收模块64，连接至上述获取模块62，用于接收服务器依据乘客信息返回的乘客的健康状况信息；

生成模块66，连接至上述接收模块64，用于根据健康状况信息生成乘车二维码，其中，乘车二维码包括乘客的健康状况信息；

展示模块68，连接至上述生成模块66，用于展示乘车二维码，其中，乘车二维码用于在公交车上提示乘客的健康状况。

此处需要说明的是，上述获取模块62，接收模块64，生成模块66和展示模块68对应于实施例2中的图2操作，上述模块与对应的操作所实现的实例和应用场景相同，但不限于上述实施例2所公开的内容。

实施例4

图7是根据本实用新型实施例4的二维码扫描装置的结构框图，如图7所示，该二维码扫描装置70包括：扫描模块72，解析模块74，发送模块76，下面对该二维码扫描装置70进行说明：

扫描模块72，用于扫描乘车二维码，其中，乘车二维码包括乘客的健康状况信息；

解析模块74，连接至上述扫描模块72，用于解析乘车二维码，得到乘客的健康状况信息；

发送模块76，连接至上述解析模块74，用于将乘客的健康状况信息发送给信息提示装置，以发出包括乘客的健康状况的提示信息。

此处需要说明的是，上述扫描模块72，解析模块74和发送模块76对应于实施例2中的图4的操作，上述模块与对应的操作所实现的实例和应用场景相同，但不限于上述实施例2所公开的内容。

上述本实用新型实施例序号仅仅为了描述，不代表实施例的优劣。

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

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

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

另外，在本实用新型各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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

以上所述仅是本实用新型的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本实用新型原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本实用新型的保护范围。