CN113159350A - 网约车管理系统、方法和计算设备 - Google Patents

Abstract

公开了一种网约车管理系统、方法和设备。该系统包括服务器和多个客户端，其中述服务器用于：收集不同地区的地区防疫信息要求；根据所述地区防疫信息要求，生成填报配置信息，所述客户端用于：上传定位信息；获取根据所述定位信息下发的对应填报配置信息；基于填报配置信息，提交所需的防疫信息，以及所述服务器用于：审核所述客户端提交的防疫信息；在所述防疫信息通过审核的情况下，允许所述客户端接入网约车服务。由此，能够根据不同地区，抑或是不同租户对网约车参与人员，尤其是针对司机的防疫要求，灵活下发信息收集页面，实现定制化的高效收集。

Description

网约车管理系统、方法和计算设备

技术领域

本公开涉及一种防疫管理，尤其一种网约车管理系统、方法和计算设备。

背景技术

在现今疫情防控常态化的背景下，防疫信息的及时高效收集变得尤为重要。在这其中，公共出行领域由于涉及大量陌生人的、通常是跨社区的交互，需要被重点关照。

相比于地铁、公交、出租车等有固定运营牌照和从事人员的出行领域，网约车由于其司机相对自由的加盟性而更加难以监管。目前，网约车的疫情防控信息收集都是各家公司基于监管诉求在不同城市收集不同的信息，并且大多是线下收集。这造成防疫信息收集混乱、低效且不够及时。

为此，需要一种更为高效、并且能够定制化的防疫信息管理方案。

发明内容

本公开要解决的一个技术问题是提供一种网约车管理方案，能够根据不同地区，抑或是不同租户对网约车参与人员，尤其是针对司机的防疫要求，灵活下发信息收集页面，实现定制化的高效收集。

根据本公开的第一个方面，提供了一种网约车管理系统，包括服务器和多个客户端，其中述服务器用于：收集不同地区的地区防疫信息要求；根据所述地区防疫信息要求，生成填报配置信息，所述客户端用于：上传定位信息；获取根据所述定位信息下发的对应填报配置信息；基于填报配置信息，提交所需的防疫信息，以及所述服务器用于：审核所述客户端提交的防疫信息；在所述防疫信息通过审核的情况下，允许所述客户端接入网约车服务，例如，允许司机端出车接单。

可选地，所述服务器用于：收集不同租户的租户防疫信息需求；根据所述租户防疫信息需求以及所述地区防疫信息要求，生成所述填报配置信息，并且所述客户端用于：上传所属租户信息；以及获取根据所述定位信息和所述所属租户信息下发的对应填报配置信息。

可选地，所述服务器用于：更新不同地区和不同租户的防疫信息要求；以及根据更新的防疫信息要求，生成所述填报配置信息。

可选地，所述服务器用于：追踪所述客户端在行车过程中的行车信息；以及在所述行车信息符合预定规则的情况下，下发额外的填报配置信息，以要求所述客户端进行额外的防疫信息填报。

可选地，所述服务器用于：基于所述客户端对应的身份信息，从防疫信息平台获取至少部分所述防疫信息。

可选地，该系统还可以收集乘客防疫信息。为此，所述多个客户端包括乘客客户端，并且所述服务器下发乘客填报配置信息，并在乘客客户端提交对应防疫信息后允许所述客户端接入网约车叫车服务。

根据本公开的第二个方面，提供了一种网约车管理方法，包括：根据用户操作开启网约车客户端；上传定位信息和表明所属租户的身份信息；获取根据所述定位信息和身份信息下发的对应填报配置信息；基于填报配置信息，提交所需的防疫信息；以及在防疫信息审核通过的情况下，获取网约车服务。

可选地，所需的防疫信息包括：体温信息；口罩佩戴信息；健康码信息；车辆消杀信息；核酸检测信息；和/或疫苗接种信息。

可选地，该方法还包括：根据对应填报配置信息生成防疫信息填报页面；以及按照所述防疫信息填报页面的要求填报防疫信息。

可选地，按照所述防疫信息填报页面的要求填报防疫信息包括：按照所述防疫信息填报页面的要求提交文本信息；按照所述防疫信息填报页面的要求提交或拍摄图片；读取连接防疫信息收集装置的收集信息；和/或跳转至对应防疫信息发布或收集页面。

可选地，该方法还包括：在行车过程中获取行车信息；以及在所述行车信息符合预定规则的情况下，生成额外的防疫信息填报页面，以要求用户进行额外的防疫信息填报。

可选地，获取的行车信息包括：车辆定位信息，并且在车辆即将跨地区行驶时，生成基于将行驶区域的额外的防疫信息填报页面。

可选地，获取的行车信息包括：接单时间/次数信息，并且在接单时间 /次数信息符合预定规则的情况下，生成要求车辆消毒页面。

可选地，在生成要求车辆消毒页面后，暂停所述网约车服务并基于实时定位信息判定车辆停止时间超过预定时间。

可选地，基于填报配置信息，提交所需的防疫信息包括：自动提交在前已提交且未过有效期的防疫信息；以及手动提交新的或者已过有效期的防疫信息。

可选地，所述网约车客户端包括：网约车司机客户端；和/或网约车乘客客户端。

根据本公开的第三个方面，提供了一种计算设备，包括：定位单元，用于获取所述设备的定位信息；传输单元，用于上传定位信息和表明所属租户的身份信息，并获取根据所述定位信息和身份信息下发的对应填报配置信息；显示单元，用于显示基于所述填报配置信息生成防疫信息填报页面；以及输入单元，用于按照所述防疫信息填报页面的要求填报防疫信息。

可选地，该设备还包括：存储单元，用于存储作为防疫信息的图片；拍摄单元，用于拍摄作为防疫信息的图片；和/或外接的传感单元，用于感测并收集所需的防疫信息。

根据本公开的第四个方面，提供了一种计算设备，包括：处理器；以及存储器，其上存储有可执行代码，当可执行代码被处理器执行时，使处理器执行如上述第二方面所述的方法。

根据本公开的第五个方面，提供了一种非暂时性机器可读存储介质，其上存储有可执行代码，当可执行代码被电子设备的处理器执行时，使处理器执行如上述第二方面所述的方法。

由此，本发明设计了一套可以针对不同租户和不同城市收集司机防疫信息的网约车防疫管控系统。该系统可以通过平台配置不同租户在不同城市收集的防疫要求，司机根据防疫要求使用司机端通过拍照、图片等方式将所需的防疫信息上传至平台，平台通过审核后，司机才能出车，避免了线下人工收集信息的繁杂和混乱，同时还可随时基于不同时期的疫情要求去限制司机出车，以到达按要求管理司机，保障网约车在疫情期间安全接单的目的。

附图说明

通过结合附图对本公开示例性实施方式进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例性实施方式中，相同的参考标号通常代表相同部件。

图1示出了根据本发明一个实施例的网约车管理系统的组成示意图。

图2示出了根据本发明另一个实施例的网约车管理系统的组成示意图。

图3示出了根据本发明一个实施例的网约车管理方法的示意性流程图。

图4示出了根据本发明一个实施例的司机客户端出车前所需进行操作的例子。

图5示出了根据本发明一个实施例可用于实现上述网约车管理方法的计算设备的结构示意图。

图6A-C示出了根据本发明的防疫信息采集页面的例子。

具体实施方式

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

网约车是网络预约出租汽车经营服务的简称，是指以互联网技术为依托构建服务平台，接入符合条件的车辆和驾驶员，通过整合供需信息，提供非巡游的预约出租汽车服务的经营活动。

提供网约车服务的平台(即，网约车平台)优选由SaaS平台实现。 SaaS平台是运行SaaS软件的云平台。软件即服务(SaaS， Software-as-a-Service)向消费者(例如，作为租户的第三方厂商)提供技术服务接口或是直接的图形化操作界面，以使得消费者能够使用云基础设施上运行的各类应用。在不同的实现中，该应用可以通过诸如网络浏览器的客户端接口或是经由安装的专用APP的客户端进行访问。除了有限的特定于用户的应用配置设置的可能例外，消费者并不管理或控制包括网络、服务器、操作系统、存储、乃至个体应用能力的下层云基础设施。

“云”或者“云计算”可以看作一种服务交付模型，用于实现对可配置计算资源的共享且按需的访问。可配置计算资源能够以最小的管理成本或与服务提供者的最少交互而被快速供应和释放。

在基本配置完成之后，云的消费者无需与服务提供者进行人为交互就能够单方面自动地按需获取诸如服务器时间和网络存储等之类的计算能力。提供者的计算资源被池化，以使用多租户模型服务于多个消费者，并且根据需求动态地分配和再分配不同的物理和虚拟资源。消费者通常不能控制或不知晓所提供的资源的确切位置。另外，云基础设施还要具有扩展和缩减的能力，以满足消费者的升级(例如，服务升级)需求。进一步地，云系统可以利用适于服务类型(例如存储、处理、带宽和用户账户)的某个抽象层面上的计量能力，自动地控制和优化资源使用。可以监测、控制和报告资源使用，从而为被利用的服务的提供者和消费者双方提供透明度。

云计算环境是面向服务的，聚焦于无状态性、低耦合性、模块性和语意互操作性。云计算的核心是包含互连节点的网络的基础设施。云计算网络中的节点是计算装置，包括但不限于个人计算机系统、服务器计算机系统、移动客户端等。由于网约车服务的实时性，实现网约车服务的SaaS 平台还需要具有高时效性，能够同时处理大量来自移动客户端的请求，例如，在下单派单场景中，将用户请求(用户订单)分配给恰当接单方(司机接单)的司乘匹配操作，即，为乘客发送的每个订单匹配一个合适的司机。

由于提供网约车服务的云平台通常为不同租户(每个租户可能同时在不同城市运营)同时提供服务，尤其是如上所示的司乘匹配服务，因此也能够为不同租户进行高效的防疫信息收集，由此避免各个租户在不同城市分别收集所带来的低效与混乱。

图1示出了根据本发明一个实施例的网约车管理系统的组成示意图。本发明的网约车管理系统能够用于防疫信息的高效收集，即，可以实现为专门的防疫信息收集和管理系统，也可以看作是现有网约车管理系统的一部分，即并入的新功能。

如图所示，系统100包括服务器110和多个客户端120。在图1所示的例子中，该平台100可以是仅对接司机的平台(例如，为分属不同租户的司机进行司乘匹配等网约车核心服务的平台)，为此客户端120示出为多个车辆。但应该理解的是，虽然被示出为车辆，但司机客户端通常被安装在手机上。在司机为乘客提供运营服务时，司机通常利用其手机获取服务器110提供的服务，并进行防疫信息上报。在某些实施例中，一些智能化车辆也可以安装网约车APP，并作为图1所示的客户端120本身。

在此，服务器110可以用于：收集不同地区的地区防疫信息要求。在，防疫信息要求指代针对网约车正常运行所需要提交的防疫信息的要求。这些要求包括防疫信息种类的要求，也包括每种防疫信息的具体要求。例如，不同种类的防疫信息可以包括但不限于：体温信息；口罩佩戴信息；健康码信息；车辆消杀信息；核酸检测信息；和/或(在疫苗上市后的)疫苗接种信息等。每种防疫信息的具体要求则可以包括针对每一项信息的细化要求。例如，要求佩戴的口罩可以是常规的护理口罩，也可以要求佩戴防护性能更高的N95或是外科口罩。例如，根据防疫级别不同，要求的核酸检测信息可以是3日内、7日内、14日内的核酸检测报告。

不同地区的防疫信息要求通常由本地行政部门结合本地当前疫情状况以及松紧级别制定。例如，城市I作为首都，其常规防疫等级要高于其他城市。在存在散发病例时，其防疫等级也要高出其他存在散发病例的城市。城市II虽然同样作为超大型城市，但是由于其城市治理水平较高，其面对常规市民的防疫等级则通常要比其他城市更松。城市III则根据其所属省份的要求，而有着中等的防疫等级要求。在此，更高的防疫等级通常意味着需要提交更多的防疫信息种类以及更为严格的具体要求，例如，更为频繁的消杀、更短的核酸报告时效。在此，“地区”的级别通常为某一防疫要求所涵盖的范围，例如，一个市的范围、一个省的范围等。

在获取并汇总了不同地区的防疫信息要求之后，服务器110可以根据所述地区防疫信息要求，生成填报配置信息。在此，填报配置信息用于规定不同地区需要填报的信息种类及其配置(例如，要求拍摄大小在XX范围内的核算报告的图片)。上述填报配置信息或其对应的页面生成信息随后可由客户端获取用于填报页面的生成。

相应定，客户端120可以用于向服务器110上传定位信息。服务器110 可以根据该定位信息查找出对应的填报配置信息，并下发。于是，客户端 120可以获取根据所述定位信息下发的对应填报配置信息，并基于填报配置信息，提交所需的防疫信息。具体地，客户端120可以根据对应填报配置信息生成防疫信息填报页面，并且按照所述防疫信息填报页面的要求填报防疫信息。

填报好的防疫信息随后可被上传至服务器110，并交由服务器110审核所述客户端提交的防疫信息。服务器110的上述审核可以采用系统自动或至少是半自动的方式进行。可以对提交的图片信息进行自动分析，来确认其是否符合要求。例如，可以自动识别核酸报告中的报告日期、对象名称等来进行身份和时效的确认；可以自动识别拍摄图像中的口罩佩戴情况等。在某些情况下，也可以在后台进行人工审核。在所述防疫信息通过审核的情况下，可以允许所述客户端接入网约车服务，例如将司机端接入接单服务，并在进行司乘匹配时加入该客户端进行匹配。而在未通过审核的情况下，则司机无法通过司机端出车。

由此，本发明的网约车管理系统能够根据不同地区的不同防疫要求，为司机客户端生成不同的信息填报页面，由此实现基于地区要求的防疫信息的系统化、定制化收集。

进一步地，由于系统通常会为多个租户同时提供服务，因此所述服务器用于：收集不同租户的租户防疫信息需求，并且根据所述租户防疫信息需求以及所述地区防疫信息要求，生成所述填报配置信息。例如，平台的租户包括AA出行、BB专车、CC约车，这些租户在不同的地区(例如，不同的运营城市)，会有着与这些地区的防疫要求相同、甚至更严格的防疫信息要求。例如，不同的租户在不同的地区，甚至不同的租户在同一个地区的面临的监管诉求可能不同。为此，填报配置信息的生成不仅需要考虑司机所在地区的防疫信息要求，还需要考虑不同租户各自的需求。

相应定，客户端120在上传定位信息之外，还需要上传所属租户信息，例如其用户id。通常情况下，用户id(例如，AA_000123)除了用户在租户A下的唯一编号之外，还包括租户本身的身份编号，为此上传用户id 就能够知晓其所属的租户身份。例如，从用户id AA_000123判定出该用户的AA出行的司机身份。随后，服务器可以结合客户端上传的定位信息和所属租户信息，查找对应的填报信息配置，并进行下发。客户端120于是可以获取根据所述定位信息和所述所属租户信息下发的对应填报配置信息，并进行相应的信息填报。由此，通过进一步并入租户的要求，能够进一步提示定制的灵活性。

在某些情况下，服务器110还可以根据获取的用户id，读取用户信息，例如住址信息，并给出基于用户信息的额外配置信息。例如，从用户id AA_000123查找出该用户居住在存在散发疫情小区所在的区(例如，A市 H区)，因此可以相比于居住在A市其他区的司机，地区或是租户可能会要求司机提供额外的防疫信息，例如，7天内的核酸报告。

另外，由于防疫要求会随着确诊病例的增减、节假日的来临等而频繁发生变化，为此服务器110可以用于：更新不同地区和不同租户的防疫信息要求；以及根据更新的防疫信息要求，生成所述填报配置信息。

在某些情况下，服务器110可以以固定的间隔更新防疫信息要求。例如，服务器110可以在每天晚上根据国家卫健委的通报来更新防疫请求。在其他情况下，服务器110可以实时监控防疫要求的更新。上述更新可以是后台人工获取的，也可以是机器自动获取的。在优选的实施例中，服务器110可以自动抓取目标网站发布的疫情情况通报或是防疫要求，并据此生成填报配置信息。具体地，在情况无变化时保持原有的填报配置信息不变，在存在防疫要求的变化时才生成新的填报配置信息。

除了生成针对不同地区、不同租户的填报配置信息之外，服务器110 还可以生成默认配置信息，以方便在没有为司机上传的信息找到匹配的配置信息时，直接下发默认配置信息。

对于更新的填报配置信息，服务器110可以在需要司机提供额外防疫信息时，直接发送给客户端120，也可以在客户端120下一次需要出车而接入派单服务时作为新的填报配置信息下发。例如，对已经接入派单服务并正在运送乘客的客户端发送“XX出现新病例，请上传7日内核酸报告”。由于有些防疫信息需要额外获取(例如，需要去医院做检测)，为此服务端110此时可以仅下发需要额外信息的提醒，并不会因为司机无法当场提供上述信息而阻止司机出车。由此，司机可以在本次出车之后，及时进行额外防疫信息的准备(例如，去医院或检测点做核酸检测)，并在下一次出车时进行提供(此时，核酸报告可能已经成为出车前必须提供的防疫信息)。

另外，在某些实施例中，服务器110不仅用于在司机发车前进行防疫信息收集和出车许可下发，还可以在司机出车过程中进行行车信息的追踪，并在需要时收集额外的防疫信息。为此，服务器110可以用于：追踪所述客户端在行车过程中的行车信息；以及在所述行车信息符合预定规则的情况下，下发额外的填报配置信息，以要求所述客户端进行额外的防疫信息填报。

行车信息可以包括行车位置信息。司机客户端120由于需要实时上报其定位信息，因此服务器110原本就可获知司机所驾驶车辆的位置信息。当位置信息指示车辆即将进入不同地区时(例如，即将从A市进入B省)，服务器110可以查找B省的防疫信息要求，尤其是对来自A市车辆的防疫信息要求，并在B省需要额外防疫信息的情况下，向客户端120发送提醒，例如，“您即将进入B省，B省对来自A市的车辆有核酸报告的需求”。用户在看到上述需求后，可以放弃进入B省。也可以点击上述提醒下提供的“上传核酸报告”的按钮，为此进入额外信息填报页面，进行核酸报告的上传。

除了位置信息之外，服务器110还可以获取其他的行车信息。例如，可以规定车辆在每个固定时间进行消杀(例如，要求每两次进行消杀)，或是在运送完每个(或多个，例如三个)乘客后都要进行车辆消杀。此时，服务器110可以暂停该客户端120的发车许可达预定时间(例如，五分钟)，并且可以利用客户端上传的定位信号判定车辆停车，通过车辆停车判定司机进行了车辆消杀。

在某些情况下，除了直接由用户进行防疫信息申报，服务器110还可以基于所述客户端对应的身份信息，从防疫信息平台获取至少部分所述防疫信息。例如，在某些建有统一核酸报告管理平台和/或疫苗接种平台的省份，可以与本省管理部门合作，直接基于司机唯一身份标识符(例如，司机注册系统id是填写的身份证信息)从本地核酸/疫苗接种平台获取结构化的核酸检测/疫苗接种结果，而非获取司机上传的图片。由此，不仅能降低客户端操作的繁琐性，降低司机造假的可能性，还能通过结构化信息的直接获取代替图片解析，提高信息获取效率。

服务器110可以集中存储获取的上述防疫信息，并且优选地对不同租户的信息进行隔离。如果某位司机不仅注册的AA出行，还注册了CC约车，在某些情况下，该司机对于两个租户的重复防疫信息仅需要提交一次。例如，该司机首先在AA出行的司机端点击出车，并按要求提交了体温信息、口罩照片、消杀信息等。随后，在CC约车的司机端点击出车时，由于该系统通常对AA出行和CC约车这两个租户提供服务，为此可以自动填充上述信息，以方便司机的出车操作。在其他情况下，例如，信息在租户间完全隔离的情况下，该司机则需要分别完整填写AA出行和CC约车各自的防疫信息填报页。

虽然图1的系统中示出了仅包括司机端的客户端。但在某些实施例中，本发明的防疫系统可以一并收集乘客的防疫信息。图2示出了根据本发明另一个实施例的网约车管理系统的组成示意图。如图所示，此时，多个客户端不仅可以包括司机客户端220，还可以包括乘客客户端230，并且所述服务器210可以下发乘客填报配置信息，并在乘客客户端提交对应防疫信息后允许所述客户端接入网约车叫车服务。

本发明的防疫信息管理方案还可以实现为一种网约车管理方法。该方法可以由客户端，尤其是司机客户端实现。

图3示出了根据本发明一个实施例的网约车管理方法的示意性流程图。如图3所示，在步骤S310，根据用户操作开启网约车客户端。司机可以在自己的手机、甚至是智能车辆上安装网约车的司机客户端。在需要出车时，首先需要打开对应客户端，例如，通过点击手机桌面上司机APP的图标。

随后，在步骤S320，上传定位信息和表明所属租户的身份信息。服务器随后可以根据上传的定位信息和租户信息查找对应的填报配置信息。在步骤S330，获取根据所述定位信息和身份信息下发的对应填报配置信息。在步骤S340，基于填报配置信息，提交所需的防疫信息。随后在步骤S350，在防疫信息审核通过的情况下，获取网约车服务，例如，由平台提供的派单服务。类似地，所需的防疫信息可以根据要求而包括特定的种类及配置。不同种类的防疫信息包括：体温信息；口罩佩戴信息；健康码信息；车辆消杀信息；核酸检测信息；和/或疫苗接种信息。

在此，由于平台支持多租户，因此分属不同租户的司机可以开启不同的租户客户端，例如AA出行司机端、BB专车司机端、CC约车司机端等。这些客户端可以具有不同的页面布局和显示，但其都可以从同一个云平台获取配置信息，并将防疫信息传递至该平台(虽然不同租户的司机上传的信息可以在平台上保持租户间的隔离)。

无论司机客户端是否相同，都可以根据对应填报配置信息生成防疫信息填报页面；以及按照所述防疫信息填报页面的要求填报防疫信息。

具体地，按照所述防疫信息填报页面的要求填报防疫信息首先可以包：按照所述防疫信息填报页面的要求提交文本信息，例如，可以直接文本填写体温信息。此外，还可以按照所述防疫信息填报页面的要求提交或拍摄图片，例如，上传核酸检测结果的截图或是拍摄核酸检测报告的图片。另外，在更为严格的场景下，作为客户端的手机或是车辆还可以(有线或无线)连接第三方的信息收集装置，例如，专门的测温红外摄像头(用来进行体温实时监控)，专门的摄像头(用来进行口罩合规佩戴监控)等。进一步地，司机端APP还可以直接跳转至对应防疫信息发布或收集页面。例如，相比于用户自行提供截图，由APP启动的跳转能够提升信息获取速率并防止提供经过更改的虚假信息。

进一步地，客户端APP还可以在行车过程中获取行车信息，并在所述行车信息符合预定规则的情况下，生成额外的防疫信息填报页面，以要求用户进行额外的防疫信息填报。

在一个实施例中，获取的行车信息包括：车辆定位信息，并且在车辆即将跨地区行驶时，生成基于将行驶区域的额外的防疫信息填报页面。

在另一个实施例中，获取的行车信息包括：接单时间/次数信息，并且在接单时间/次数信息符合预定规则的情况下，生成要求车辆消毒页面。其中，在生成要求车辆消毒页面后，可以暂停所述网约车服务并基于实时定位信息判定车辆停止时间超过预定时间。由此来敦促司机进行车辆消毒。

在填报防疫信息时，可以是司机每次(或每日或规定时间间隔)出车都进行一次完全的防疫信息填报。也可以仅仅更新需要更新的项目。为此，客户端可以自动提交在前已提交且未过有效期的防疫信息，并手动提交新的或者已过有效期的防疫信息。例如，如果要求7日内核酸报告，则在首次提交核酸报告之后，在有效期内都无需重复提交该报告，而是本机自动提交相关凭证或是服务器端自动关联。而诸如体温和车辆消毒的防疫信息则需要每次都进行提交。

如上结合图3描述的方法尤其适用于网约车司机客户端。在该防疫信息收集系统也收集乘客信息的情况下，也可以适用于网约车乘客客户端。

图4示出了根据本发明一个实施例的司机客户端出车前所需进行操作的例子。

在此，为司机客户端提供出车服务的平台能够提供本发明的防疫信息收集功能。为此，平台配置不同租户和不同城市需要收集的防疫信息，如核酸检测信息、口罩佩戴信息、以及车辆消杀信息等。

当司机打开司机端点击出车按钮时，如果没有填写防疫信息，则进行提示，引导司机前往防疫信息采集页面。

当司机打开防疫信息采集页面时，APP上传定位城市和租户id到服务，服务搜索对应城市和租户id的配置信息下发到司机端，如果未获取到匹配的配置信息，则不下发配置信息，司机端展示默认的配置。

司机在采集页面填写防疫信息，并通过司机端上传防疫信息，如核酸检测信息、口罩佩戴信息、以及车辆消杀信息等。

平台显示司机上传的防疫信息，同时进行审核。审核通过后，司机点击司机端出车按钮即可正常出车。审核未通过或者司机未提交防疫信息，司机都无法通过司机端出车。

由此，通过平台快速配置需要收集的防疫信息，对司机端上传的定位城市和所属租户进行匹配，以及页面展示需要司机申报的防疫信息，提高了防疫信息收集速度和准确率。

本发明还可以实现为一种计算设备。该计算设备尤其可以实现如上结合图3描述的方法，并且尤其可以是能够安装司机客户端APP并且能够上传定位信息的任意智能设备，例如，智能收集、智能车辆等。

该计算设备包括：定位单元，用于获取所述设备的定位信息；传输单元，用于上传定位信息和表明所属租户的身份信息，并获取根据所述定位信息和身份信息下发的对应填报配置信息；显示单元，用于显示基于所述填报配置信息生成防疫信息填报页面；以及输入单元，用于按照所述防疫信息填报页面的要求填报防疫信息。

进一步地，该计算设备还可以包括：存储单元，用于存储作为防疫信息的图片；拍摄单元，用于拍摄作为防疫信息的图片；和/或外接的传感单元，用于感测并收集所需的防疫信息。

图5示出了根据本发明一个实施例可用于实现上述网约车管理方法的计算设备的结构示意图。

参见图5，计算设备500包括存储器510和处理器520。

处理器520可以是一个多核的处理器，也可以包含多个处理器。在一些实施例中，处理器520可以包含一个通用的主处理器以及一个或多个特殊的协处理器，例如图形处理器(GPU)、数字信号处理器(DSP)等等。在一些实施例中，处理器520可以使用定制的电路实现，例如特定用途集成电路(ASIC，Application Specific Integrated Circuit)或者现场可编程逻辑门阵列(FPGA，Field Programmable Gate Arrays)。

存储器510可以包括各种类型的存储单元，例如系统内存、只读存储器(ROM)，和永久存储装置。其中，ROM可以存储处理器520或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器510可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(DRAM，SRAM，SDRAM，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器 510可以包括可读和/或写的可移除的存储设备，例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM，双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

存储器510上存储有可执行代码，当可执行代码被处理器520处理时，可以使处理器520执行上文述及的网约车管理方法。

应用例

为了方便理解，图6A-C示出了根据本发明的防疫信息采集页面的例子。图6A-C的例子都可以是各自的客户端根据上传的租户和定位信息获取的配置信息而生成的防疫信息采集页面。

图6A示出了在防疫措施相对较松的地区，要求司机填写的“健康打卡”页面。该页面包括健康状况、体温和车辆消毒等条目，条目旁的“*”表示该条目为必填条目。用户可以通过点击每个条目后的“>”按钮来进入相应的项目填写页，或是使得该项目被展开显示。图6A所示的条目都是可以通过文本输入而填写的条目。

图6B示出了需要司机填写“核酸检测”报告的“健康打卡”页面。并且该页面的常规申报项目可以与图6A的例子不同。相比于进行车辆消杀，图6B中更关注自行申报与可以人群的解除。

图6C示出了在防疫措施相对较严的地区，要求司机填写的“健康打卡”页面。应该理解的是，图6A和6B示出了完整的防疫信息采集页面。该页面可能无法在显示屏中被同时显示，而是需要用户通过上下滑动来进行显示，例如，持续上滑以显示页面底部。图6C考虑到附图显示长度有限，而仅上述页面在核酸信息和健康码上传项目被点开后的部分，略去了后续的体温和车辆消毒等条目。

例如，图6C所示页面可以是图6A同一司机在不同日期所显示的防疫信息采集页面。在该地区没有本土病例时，司机仅需如图6A所示自行申报健康状况、体温和车辆消毒等条目。而在该地区出现本土病例之后，由于防疫措施的升级，司机需要如图6C所示上传更多的证明凭证。例如，核酸检测凭证、疫苗接种凭证和健康码等。

上述不同的页面显示，可以通过获取服务端下发的不同配置信息来实现。在服务端中，可以具有相应的web操作页面，由于根据城市、省份和租户等灵活选择需要在客户端采集页面中显示的条目模块。用户在提交了符合规定的防疫信息之后，就可以点击“提交”按钮进行提交，并在后台审核通过之后出车。

上文中已经参考附图详细描述了根据本发明的可以针对不同租户和不同城市收集司机防疫信息的网约车防疫信息管理系统。该系统可以通过平台配置不同租户在不同城市收集的防疫要求，司机根据防疫要求使用司机端通过拍照、图片等方式将所需的防疫信息上传至平台，平台通过审核后，司机才能出车，避免了线下人工收集信息的繁杂和混乱，同时还可随时基于不同时期的疫情要求去限制司机出车，以到达管理未按要求防疫司机的目的，保障网约车在疫情期间安全接单。

此外，根据本发明的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。

或者，本发明还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机指令代码)，当所述可执行代码(或计算机程序、或计算机指令代码)被电子设备(或计算设备、服务器等)的处理器执行时，使所述处理器执行根据本发明的上述方法的各个步骤。

本领域技术人员还将明白的是，结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。

附图中的流程图和框图显示了根据本发明的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (20)

1.一种网约车管理系统，包括服务器和多个客户端，其中

所述服务器用于：

收集不同地区的地区防疫信息要求；

根据所述地区防疫信息要求，生成填报配置信息，

所述客户端用于：

上传定位信息；

获取根据所述定位信息下发的对应填报配置信息；

基于填报配置信息，提交所需的防疫信息，以及

所述服务器用于：

审核所述客户端提交的防疫信息；

在所述防疫信息通过审核的情况下，允许所述客户端接入网约车服务。

2.如权利要求1所述的系统，其中，所述服务器用于：

收集不同租户的租户防疫信息需求；

根据所述租户防疫信息需求以及所述地区防疫信息要求，生成所述填报配置信息，并且

所述客户端用于：

上传所属租户信息；以及

获取根据所述定位信息和所述所属租户信息下发的对应填报配置信息。

3.如权利要求2所述的系统，其中，所述服务器用于：

更新不同地区和不同租户的防疫信息要求；以及

根据更新的防疫信息要求，生成所述填报配置信息。

4.如权利要求1所述的系统，其中，所述服务器用于：

追踪所述客户端在行车过程中的行车信息；以及

在所述行车信息符合预定规则的情况下，下发额外的填报配置信息，以要求所述客户端进行额外的防疫信息填报。

5.如权利要求1所述的系统，其中，所述服务器用于：

基于所述客户端对应的身份信息，从防疫信息平台获取至少部分所述防疫信息。

6.如权利要求1所述的系统，其中，所述多个客户端包括乘客客户端，并且所述服务器下发乘客填报配置信息，并在乘客客户端提交对应防疫信息后允许所述客户端接入网约车叫车服务。

7.一种网约车管理方法，包括：

根据用户操作开启网约车客户端；

上传定位信息和表明所属租户的身份信息；

获取根据所述定位信息和身份信息下发的对应填报配置信息；

基于填报配置信息，提交所需的防疫信息；以及

在防疫信息审核通过的情况下，获取网约车服务。

8.如权利要求7所述的方法，其中，所需的防疫信息包括：

体温信息；

口罩佩戴信息；

健康码信息；

车辆消杀信息；

核酸检测信息；和/或

疫苗接种信息。

9.如权利要求7所述的方法，还包括：

根据对应填报配置信息生成防疫信息填报页面；以及

按照所述防疫信息填报页面的要求填报防疫信息。

10.如权利要求9所述的方法，其中，按照所述防疫信息填报页面的要求填报防疫信息包括：

按照所述防疫信息填报页面的要求提交文本信息；

按照所述防疫信息填报页面的要求提交或拍摄图片；

读取连接防疫信息收集装置的收集信息；和/或

跳转至对应防疫信息发布或收集页面。

11.如权利要求7所述的方法，还包括：

在行车过程中获取行车信息；以及

在所述行车信息符合预定规则的情况下，生成额外的防疫信息填报页面，以要求用户进行额外的防疫信息填报。

12.如权利要求11所述的方法，其中，获取的行车信息包括：

车辆定位信息，并且

在车辆即将跨地区行驶时，生成基于将行驶区域的额外的防疫信息填报页面。

13.如权利要求11所述的方法，其中，获取的行车信息包括：

接单时间/次数信息，并且

在接单时间/次数信息符合预定规则的情况下，生成要求车辆消毒页面。

14.如权利要求13所述的方法，其中，在生成要求车辆消毒页面后，暂停所述网约车服务并基于实时定位信息判定车辆停止时间超过预定时间。

15.如权利要求7所述的方法，其中，基于填报配置信息，提交所需的防疫信息包括：

自动提交在前已提交且未过有效期的防疫信息；以及

手动提交新的或者已过有效期的防疫信息。

16.如权利要求7所述的方法，其中，所述网约车客户端包括：

网约车司机客户端；和/或

网约车乘客客户端。

17.一种计算设备，包括：

定位单元，用于获取所述设备的定位信息；

传输单元，用于上传定位信息和表明所属租户的身份信息，并获取根据所述定位信息和身份信息下发的对应填报配置信息；

显示单元，用于显示基于所述填报配置信息生成防疫信息填报页面；以及

输入单元，用于按照所述防疫信息填报页面的要求填报防疫信息。

18.如权利要求17所述的设备，还包括：

存储单元，用于存储作为防疫信息的图片；

拍摄单元，用于拍摄作为防疫信息的图片；和/或

外接的传感单元，用于感测并收集所需的防疫信息。

19.一种计算设备，包括：

处理器；以及

存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求7-15中任一项所述的方法。

20.一种非暂时性机器可读存储介质，其上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求7-15中任一项所述的方法。

Images