使用区块链进行车内健康状况跟踪的系统和方法

技术领域

本公开描述了使用区块链进行车内健康状况跟踪的系统和方法。

背景技术

空气传播的微颗粒(诸如病毒和细菌病原体)的暴露可能会在我们的社会中引起流行病，从而导致各种感染、呼吸系统疾病和传染性疾病(诸如COVID-19)。随着越来越多地使用车辆作为共享资源(例如，共乘、汽车租赁、共享车队车辆等)，此类微颗粒的可能传播令人担忧。存在不同的潜在解决方案来识别空气传播的微颗粒并对其进行消毒或清洁。如今，没有标准方式将这些解决方案的输出(即，车辆内部空气质量状态)散播给不同的利益相关者。

发明内容

一种示例性方法可以包括从用户的移动装置接收对车辆的请求。所述示例性方法还可以包括从第一车辆内的病原体检测器装置接收对所述第一车辆内的病原体的数量小于阈值量的指示。所述示例性方法还可以包括基于对所述第一车辆内的病原体的所述数量小于阈值量的所述指示而将所述第一车辆分配给所述用户。

附图说明

参考附图阐述具体实施方式。相同附图标记的使用指示类似或相同的部件或元件；然而，也可以使用不同的附图标记来指示可能类似或相同的部件或元件。本公开的各种实施例可以利用除了附图中示出的那些之外的元件和/或部件，并且一些元件和/或部件可能不存在于各种实施例中。取决于上下文，使用单数术语来描述元件或部件可以涵盖复数数量的此类元件或部件，并且反之亦然。

图1示出了根据本公开的一个或多个实施例的示例性流程图。

图2示出了根据本公开的一个或多个实施例的示例性系统。

图3A至图3C示出了根据本公开的一个或多个实施例的示例性区块链架构。

图4示出了根据本公开的一个或多个实施例的示例性流程图。

图5示出了根据本公开的一个或多个实施例的示例性流程图。

图6示出了根据本公开的一个或多个实施例的示例性流程图。

图7示出了根据本公开的一个或多个实施例的示例性流程图。

图8示出了根据本公开的一个或多个实施例的示例性系统。

图9示出了根据本公开的一个或多个实施例的示例性方法。

图10示出了根据本公开的一个或多个实施例的计算系统的示例。

具体实施方式

本公开尤其涉及使用区块链进行车内健康状况跟踪的系统和方法。具体地，本文描述的系统和方法可以在约车服务的背景下使用以确保车辆对于连续乘客来说是干净的。所述系统和方法还可以允许约车乘车者请求车辆清洁度状态检查，并且如果当前分配的车辆不满足清洁度要求，则请求不同的车辆。虽然本文可以参考约车服务，但是所述系统和方法也可以适用于其他背景。例如，仅举几个非限制性示例，所述系统和方法也可以适用于车辆车队管理和车辆租赁。

为了实现车内健康状况跟踪器，病原体检测器可以集成在车辆内。病原体检测器可以是可作为独立装置的装置或集成到车辆中的装置。病原体检测器可能够检测给定环境(诸如车辆的内部)内的细菌和病毒病原体。病原体检测器还可能够将收集的数据传输到单独的本地或远程系统以进行处理。病原体检测器可以包括用于收集空气传播样本的直接空气处理系统。病原体检测器可以包括用于检测病原体的存在的生物芯片和/或生物传感器。病原体检测器还可以包括具有嵌入式软件的集成控制模块。病原体检测器可以容纳在集成壳体总成内以用于安装到诸如中央控制台的车辆内部车厢中。空气处理系统可以从车辆环境内捕集空气传播的病原体，并允许结合到生物芯片的表面上的纳米探针。然后，病原体检测器可以读取生物芯片的光学特性并将信号输出到控制模块或外部装置App。控制模块或外部装置App中的软件可以解译信号并输出指示在车辆内发现的病原体水平的无线数据。

病原体检测器可以连续地(或定期地)分析车辆的空气质量。当检测到病原体微颗粒时，可以从区块链请求车辆健康状况通过凭证。例如，车辆健康状况通过凭证可以是使用W3C可验证凭证标准颁发给车辆的数字凭证。为此，车辆可以使用W3C分散式标识符(DID)标准具有其自己的基于区块链的自主身份(SSI)。在DID生态系统中，任何人都可以颁发关于任何事情的可验证凭证，并且可以将其呈现给每个人并由每个人验证。在车辆健康状况通过凭证用例的情况下，可以将可验证凭证颁发给车辆，所述车辆可以是存储所述凭证以供后续使用的持有者。凭证可以由OEM或受信任的第三方(其可以是颁发者)颁发。可验证凭证可以由颁发者进行数字签名，这可以使可验证凭证具有防篡改和瞬时可验证性，从而允许持有者通过将其凭证呈现给验证者(例如，乘车者)来证明关于其自身的一些信息(例如，车内空气质量状态)。

如果检测到任何病原体或者如果病原体的数量超过阈值量(如果适用)，则车辆也可以被送到清洁设施进行清洁。替代地，车辆可以包括内部清洁机构，所述内部清洁机构可以允许车辆当场清洁自身。例如，车辆可以具有集成的紫外(UV)光消毒系统。在适当地消毒之后，可以再次运行病原体检测器以确认不再检测到病原体(或不再检测到阈值量的病原体)。然后可以请求新的车辆健康状况通过凭证。在任何时间，乘客、车队所有者和驾驶员以及车辆本身可能够通过针对区块链请求和验证车辆的健康状况通过凭证来验证车辆的状态。在一些情况下，如果车辆不能当场清洁自身，而是需要导航到清洁设施，则可以替代地将被确定为满足必要清洁度要求的第二车辆分配给乘客，然后可以将初始车辆送到清洁设施进行清洁以供其他乘客后续使用。该信息中的一些或全部可以被存储到区块链以创建约车车队中的车辆状态的易于访问的历史记录，以及任何其他信息，诸如乘客偏好等等。

在一些情况下，状态指示器还可以用于向乘车者、驾驶员或车辆的任何其他用户提供对车辆状态的指示。例如，如果确定病原体检测器识别车辆中的病原体，则可以改变状态指示器的颜色以反映病原体的存在。作为一个示例，颜色可以变为红色。红色的状态颜色可以提供对车辆需要消毒并且使用可能不理想的指示。当确定车辆已经被清洁时(例如，如果病原体检测器确定一旦车辆被清洁就不再检测到病原体)，则状态灯可以改变为不同的颜色。例如，状态灯可以变为绿色，这可以指示车辆是干净的。在一些情况下，状态灯可以直接呈现在车辆的一个或多个部分上或内部。如图8中描绘，车辆的车门可以包括可改变为不同颜色的相关联的状态灯。作为第二示例，可以从车辆投射门控地面照明灯。作为第三示例，状态可以呈现在车辆的人机界面(HMI)上。在一些情况下，可以通过呈现在用户的移动装置上的约车应用程序来呈现状态灯。可以关于图8描绘和描述关于状态指示器的附加细节。

本文描述的系统和方法可以提供许多优点。作为第一示例，可以自主地和自动地执行病原体检测，从而提高检测病原体的速度并减少人为错误的机会。另外，在区块链上跟踪病原体检测和车辆清洁，从而产生车辆不断变化的健康状态的不可变记录，从而增加对车辆状态的信任和信心。乘客和驾驶员可以使用该车辆信息来做出关于是否在包括日常驾驶、乘车共享、汽车租赁等场景中驾驶或进入车辆的明智决策。附加系统(如汽车租赁或车队管理软件)可以与车辆状态对接以基于车辆状态来将车辆分配自动化。可以批准使用干净的车辆，并且可以重新引导需要进一步清洁的车辆进行清洁。

转向附图，图1示出了根据本公开的一个或多个实施例的示例性流程图100。流程图100可以描绘与本文描述的系统和方法相结合地执行的操作的高级概述。流程图100可以从操作104开始，并且104在一些情况下可以是与车辆(例如，诸如约车车辆)相结合地执行的操作。操作102可以涉及收集空气质量数据。空气质量数据可以由病原体检测装置收集。一旦收集到空气质量数据，流程图就可以前进到条件104。条件104可以涉及确定在车辆中是否检测到任何病原体(例如，病原体检测器装置是否检测到任何病原体)。如果在车辆中检测到病原体，则流程图100可以前进到操作108。如果在车辆中未检测到病原体，则流程图100可以前进到操作110。在一些情况下，条件104可能不一定涉及确定车辆中是否存在任何病原体，而是可能涉及确定车辆中是否存在阈值量的病原体。该阈值量可以是适用于所有约车用户的默认量，或者可以是基于特定用户的指示偏好的阈值量。操作108和110可以涉及获得车辆健康状况通过凭证。流程图100可以从操作108前进到操作112。操作112可以涉及清洁车辆。可以通过任何合适的方法执行清洁。在一些情况下，车辆可以被配备为当场执行清洁而不必穿越到清洁设施。例如，车辆可以具有集成的紫外(UV)光消毒系统、热清洁系统和/或任何其他类型的清洁系统。然而，在一些情况下，车辆可能不具有此类能力，并且可能需要穿越到所设计的清洁设施。如果车辆是自主车辆，则可以自动地更改车辆的导航系统，以便自动地将车辆引导到清洁设施。关于清洁过程本身的附加细节可以在图6中提供。流程图100可以从操作110前进到操作114。操作114可以涉及提供对车辆干净的指示。例如，所述指示可以包括可(例如，通过约车应用程序)呈现在车辆上和/或内部和/或用户的移动装置上的状态指示器。也可以通过任何其他合适的方式提供状态。在操作112和/或操作114之后，流程图100可以前进到操作116，其可以涉及重复在流程图100中描绘的循环。即，流程图100可以返回到操作102。通过这种方式，系统可以迭代执行操作102至114，使得可以不断地或定期地检查车辆中的病原体和/或清洁车辆以供客户使用。在一些情况下，可以以某些预定义时间间隔(诸如每次约车乘客离开车辆时，或者每次将约车车辆分配给乘客时)检查车辆的病原体。作为另一个示例，用户可能够手动设定应检查车辆的病原体的时间间隔。还可以建立软件定义的触发(例如，访问医院或进入地理围栏区域)以触发病原体检测系统。这些仅是此类间隔的示例，并且无意是限制性的。

图2示出了根据本公开的一个或多个实施例的示例性系统200。在一些实施例中，系统200可以至少包括移动装置202、车辆204、区块链210和/或审计和数据分析系统230。另外，应当注意，系统200的这些部分中的任一者可以包括关于图10描述的机器1000的元件中的任一者。

移动装置202可以包括任何类型的用户装置，例如智能电话、膝上型计算机、台式计算机、平板计算机和/或任何其他类型的移动装置。移动装置可能够运行应用程序。例如，移动装置可以包括可由约车服务的驾驶员或乘客使用的约车应用程序。所述应用程序可以允许乘客请求约车车辆、请求车辆清洁度状态、查看车辆的状态和/或执行关于本文描述的系统和方法的任何其他操作。移动装置还可以执行诸如读取和验证车辆健康状况凭证和/或通过应用程序向用户呈现经验证的车辆健康状况凭证的功能。在一些情况下，移动装置可以验证存储在区块链210上的车辆健康状态。

车辆204包括无人驾驶自主车辆和/或驾驶员操作的车辆。车辆还可以包括内燃发动机(ICE)，可以是混合动力车辆，或者可以是全电动车辆。车辆204可以是可由一个或多个租赁客户(图中未描绘)通过约车服务租赁的车辆车队中所包括的车辆。车辆还可以包括数字钱包206和/或病原体检测器208。数字钱包206可以指代可用于将与区块链210相关联的任何数据存储在系统200的各个部分处的存储机制。例如，移动装置202也可以具有其自己的相关联的数字钱包206。通过这种方式，系统200的部分中的任一者都可以访问区块链210和包括在区块链210内的数据。然而，应当注意，移动装置202可能不一定需要数字钱包来验证车辆健康状况凭证或执行如本文所述的其他操作。病原体检测器208可以是集成到车辆中的装置，所述装置可以用于确定车辆中是否存在任何病原体。

病原体检测器208还可以用于确定车辆204中是否存在阈值数量的病原体。病原体检测器可以是可作为独立装置的装置或集成到车辆中的装置。病原体检测器可能够检测给定环境(诸如车辆的内部)内的细菌和病毒病原体。病原体检测器还可能够将收集的数据传输到单独的本地或远程系统以进行处理。病原体检测器可以是用于收集空气传播样本的直接空气处理系统。病原体检测器可以包括用于检测病原体的存在的生物芯片和/或生物传感器。病原体检测器还可以包括具有嵌入式软件的集成控制模块。病原体检测器可以容纳在集成壳体总成内以用于安装到诸如中央控制台的车辆内部车厢中。空气处理系统可以在车辆内捕集空气传播的病原体，并允许结合到生物芯片的表面上的纳米探针。然后，生物芯片可以读取生物芯片的光学特性并将信号输出到控制模块。控制模块中的软件可以解译信号并输出指示在车辆内发现的病原体水平的无线数据。

病原体检测器208可以通过多种不同的方式与车辆204集成。作为第一示例，病原体检测器208可以与车辆204的电子控制单元(ECU)集成，所述电子控制单元可以将信号置于CAN总线上以由车辆204内的容纳有车载钱包206、钥匙和区块链客户端的网关拾取。作为第二示例，病原体检测器208可以具有集成的蓝牙芯片(或其他网络传输能力)，所述集成的蓝牙芯片可以将数据传输到车辆204并且可以将数据置于车载钱包206中。车辆204还可以向移动装置202提供车辆健康状况凭证呈现，向区块链210提供对已经发生空气质量评估事件的指示以供存储，向区块链210提供对车辆清洁事件的指示以供存储，和/或向区块链210提供任何其他信息以供存储。

审计和数据分析系统230可以是将评估车队的车内空气质量的第三方机构(例如，政府或非盈利机构)。审计和数据分析系统230还可以从车辆204中读取和验证车辆健康状况凭证呈现，并从区块链210中读取和分析空气质量评估数据。

区块链210可以是例如分布式账本技术的形式，其可以是地理上分散的计算机网络上的具有价值的特定项目上的交易或其状态变化的不可变的顺序记录，而无需使用中央机构。例如，可以通过分布式账本管理与约车车队中的各种车辆204的清洁度状态有关的数据，从而在车辆的一个或多个租赁的使用期之前、期间和之后提供车辆的整个交易历史、状态变化和生命周期。通过这种方式，区块链210就像车辆204的传记一样。分布式账本系统的使用可以提供用于数据分析和存储的安全方法。这可能是因为可以通过分布式账本系统中的节点的共识来做出向账本添加交易的决定(例如，共识可以指大多数节点确定要添加的交易是有效交易)。账本系统的使用可以允许默认情况下保护该信息，但是如果满足某些触发条件，则还可以允许所有者进行干预并访问数据或执行与车辆相关联的远程功能。

区块链210可以包括验证者服务212、颁发者服务214、注册表216、智能合约218和/或账本220。验证器服务212可以包括用于验证与如本文所述的约车服务相结合地颁发的凭证的真实性的系统。颁发者服务214可以颁发凭证，其颁发记录存储在区块链210上。颁发者服务214可能够消耗颁发凭证所需的各种值。注册表216可以是分散式账本，其可以存储所有凭证的颁发者的身份和凭证模式，并且所述注册表可以允许验证者确认呈现给他们的凭证的真实性。颁发者服务214可以创建持有者可以获得并保存的凭证并对其进行数字签名。使用颁发者与受试者之间的隐私保护双向连接(例如，API)直接向受试者(例如，车辆)颁发凭证。凭证可以包括私人数据属性。该方法可以确保没有私人数据存储在账本上，而是作为可验证凭证存储在车辆本身上。验证器服务212可能不需要与颁发者服务214进行任何连接。验证器服务212可以从受试者获得可验证呈现并将其对照账本220进行验证。智能合约218可以指代与区块链相关联的在满足预定条件时运行的系统。智能合约218可以用于使协议的执行自动化，使得所有参与者都可以立即确定结果，而没有任何中间人的参与或时间损失。最后，账本220可以是分散的和分布式的信息源，其可以在系统200的其他部分处被持续更新、分发和/或存储。一个或多个节点中的一些或所有节点也可以访问和/或已经存储相同或类似的账本220。这可以允许节点在任何给定时间获知相同的账本信息(与约车车队中的各种车辆的清洁度状态有关的数据)。因此，更新账本220可以包括例如添加对应于账本记录的数据区块。为了减少保存在账本220处的信息量并因此减少节点中的每一者的存储要求，信息也可以从账本220远程存储。即，账本220可以简单地包括指向此类“链外”信息的指针。

在一些实施例中，例如，车辆健康状况通过凭证可以是使用W3C可验证凭证标准颁发给车辆的数字凭证。为此，车辆可以使用W3C分散式标识符(DID)标准具有其自己的基于区块链的自主身份(SSI)。在DID生态系统中，任何人都可以颁发关于任何事情的可验证凭证，并且可以将其呈现给每个人并由每个人验证。在车辆健康状况通过凭证用例的情况下，可以将可验证凭证颁发给车辆，所述车辆可以是存储所述凭证以供后续使用的持有者。凭证可以由OEM或受信任的第三方(其可以是颁发者)颁发。可验证凭证可以由颁发者进行数字签名，这可以使可验证凭证具有防篡改和瞬时可验证性，从而允许持有者通过将其凭证呈现给验证者(例如，乘车者)来证明关于其自身的一些信息(例如，车内空气质量状态)。车辆健康状况通过凭证可以与不同类型的信息相关联。例如，车辆健康状况通过凭证可以包括诸如ID、日期、车辆ID、空气质量系统ID、生物芯片ID、位置、病原体检测指示、病原体类型、清洁指示、清洁类型、安全指示的信息和/或任何其他类型的信息。ID可以指代持有者系统(例如，在这种情况下为车辆204)的公钥或分散式标识符(DID)。日期可以是指代由病原体检测器206在车辆204中执行的病原体检测扫描的日期。车辆ID可以包括车辆204的唯一ID(例如，车辆的VIN号或任何其他标识符)。空气质量系统ID可以包括与空气质量监测系统相关联的标识符(例如，病原体检测器206的标识符)。生物芯片ID可以是与在扫描中使用的生物芯片(例如，病原体检测器206所包括的生物芯片)相关联的ID。位置可以指代在扫描时车辆的位置。病原体检测指示可以提供关于是否检测到病原体和/或检测到阈值数量的病原体的指示。病原体检测指示的可能值可以包括布尔值，诸如真和/或假。然而，值也可以包括任何其他类型的指示。病原体的类型可以包括检测到的病原体的名称。清洁指示可以是关于车辆是否已经被清洁的指示器。病原体检测指示的可能值可以包括布尔值，诸如真和/或假。然而，值也可以包括任何其他类型的指示。清洁类型可以指代用于清洁车辆的消毒类型(例如，UV光、化学清洁、热清洁等)。病原体检测指示的可能值可以包括布尔值，诸如真和/或假。然而，值也可以包括任何其他类型的指示。

在一些实施例中，智能合约218也可以与某些类型的信息相关联。例如，智能合约218可以包括空气质量评估数据、车辆数据、清洁记录数据、所有空气质量评估数据、所有清洁数据、车辆数据、评估数据、清洁数据、检测到的病原体数据、未检测到病原体数据、空气质量评估的非理想数据、车辆清洁数据和/或任何其他类型的数据。

空气质量评估数据可以包括每次执行空气质量评估时收集的数据。空气质量评估数据可以包括日期、时间、车辆ID和/或病原体检测数据，以及任何其他类型的数据。日期可以指代空气质量评估的日期。时间可以指代空气质量评估的时间。车辆ID可以指代发生评估的车辆的ID。病原体检测指示可以提供关于是否检测到病原体和/或检测到阈值数量的病原体的指示。病原体检测指示的可能值可以包括布尔值，诸如真和/或假。然而，值也可以包括任何其他类型的指示。

车辆数据可以包括单独车辆的空气质量评估数据。车辆数据可以包括检测到的病原体、评估、清除病原体、清洁和/或任何其他类型的数据。检测到的病原体可以指代检测到病原体时的总评估。没有检测到病原体可以指代未检测到病原体时的总评估。评估可以指代空气质量评估的总次数。清除病原体可以指代当前是否没有检测到病原体的指示器。清洁可以指代车辆当前是否干净的指示器。

清洁记录可以包括每次清洁车辆时收集的记录。清洁记录可以包括清洁类型、日期、时间和/或任何其他类型的数据。清洁类型可以指代所使用的清洁类型。日期可以指代空气质量评估的清洁日期。时间可以指代清洁时间。在一些情况下，清洁记录可以包括基于评估编号的特定空气质量评估、曾经执行过的所有空气质量评估、特定车辆的所有空气质量评估、所有干净车辆(例如，清除病原体并且已经被清洁的所有车辆)和/或任何其他类型的信息。

智能合约218还可以包括其他类型的数据。例如，智能合约218可以包括所有空气质量评估数据、所有清洁数据、车辆数据、评估数据、清洁数据、检测到的病原体数据、未检测到病原体数据、空气质量评估的非理想数据、车辆清洁数据和/或任何其他类型的数据。所有空气质量评估可以包括所有空气质量评估的映射。所有清洁都可以包括所有清洁记录的映射。车辆可以包括所有车辆的映射。评估可以包括所执行的空气质量评估的总次数。清洁可以包括清洁的总次数。检测到的病原体可以包括检测到病原体时的评估的总次数。没有检测到的病原体可以包括未检测到病原体时的评估的总次数。空气质量评估清洁可以包括表示未检测到病原体的评估的事件。被评估不理想的空气质量可以包括表示检测到病原体的评估的事件。车辆清洁可以包括表示车辆被清洁的事件。

图3A至图3C示出了根据本公开的一个或多个实施例的示例性区块链架构。图3A至图3C示出了可以将针对区块链架构的各种方法应用于本文描述的系统和方法。图3A示出了第一架构300。第一架构300可以使用身份账本308(例如，Hyperledger Indy)来处理凭证请求，并且使用通用账本309(例如，Hyperledger Fabric)来处理解决方案逻辑。图3B示出了第二架构310。第二架构310可以使用能够对数据进行分区的单个通用账本316，例如，诸如Hyperledger Fabric的平台上的多个链码和信道，以处理凭证请求和解决方案逻辑两者。图3C示出了第三架构320。第三架构320可以使用身份账本328来处理凭证请求，并且使用集中式解决方案330(例如，具有关系或非结构化数据库的中间件)来处理解决方案逻辑。从操作角度来看，使用单个通用账本通常可能更具成本效益，而将架构划分为多个账本可能会更稳健且更易于操作。

图4示出了根据本公开的一个或多个实施例的示例性流程图400。流程图400可以是在图1中描绘的流程图100的更详细版本。流程图400可以在操作402处开始，其中车辆是干净的并在使用中(例如，由约车乘客使用)。在操作402之后，流程图400可以前进到操作404。操作404可以涉及从车辆收集空气质量数据。空气质量数据可以由病原体检测装置收集。在操作404之后，操作405可以涉及确定在车辆中是否检测到任何病原体。替代地，操作405可以涉及确定在车辆中是否检测到阈值数量的病原体。病原体检测器装置可以通过多种不同的方式与车辆集成。作为第一示例，病原体检测器装置可以与车辆的电子控制单元(ECU)集成，所述电子控制单元可以将信号置于CAN总线上以由车辆内的容纳有车载钱包、钥匙和区块链客户端的网关拾取。作为第二示例，病原体检测器装置可以具有集成的蓝牙芯片(或其他网络传输能力)，所述集成的蓝牙芯片可以将数据传输到车辆并且可以将数据置于车载钱包中。在操作405之后，操作406可以涉及获得车辆健康状况通过凭证。在一些情况下，来自病原体检测器的数据可以从车辆发送到区块链的智能合约，所述智能合约可以处理数据，确定车辆的状态，存储数据和状态，并将信息转发到区块链的颁发者服务。然后，颁发者服务可以将车辆健康状况凭证返回给车辆。然后可以将该凭证存储在车载钱包中。另外，从本文所述的操作中的任一者产生的任何信息都可以存储在区块链上，以便提供与包括在约车车队中的各种车辆的状态相关的综合历史。

在操作406之后，流程图400可以前进到条件408。条件408可以涉及确定车辆对于约车乘客来说是否足够干净。该确定可以涉及使用病原体检测器来确定是否在车辆中检测到任何病原体(和/或是否在车辆中检测到阈值量的病原体)。如果确定车辆不够干净，则流程图400可以前进到操作414。如果确定车辆足够干净，则流程图400可以前进到操作412。操作414可以涉及清洁车辆。可以使用任何数量的合适方法来清洁车辆。例如，可以使用化学溶液清洁车辆。作为第二示例，可以使用紫外(UV)消毒来清洁车辆。也可以使用任何其他方法来清洁车辆。在一些情况下，车辆可以被配备为当场执行清洁而不必穿越到清洁设施。例如，车辆可以具有集成的紫外(UV)光消毒系统。然而，在一些情况下，车辆可能不具有此类能力，并且可能需要穿越到所设计的清洁设施。如果车辆是自主车辆，则可以自动地更改车辆的导航系统，以便自动地将车辆引导到清洁设施。操作412可以涉及验证车辆健康状况通过凭证。在访问车辆之前，任何乘客和/或驾驶员都可以验证凭证并确认车辆的状态。从车辆钱包请求凭证。然后，可以通过用户移动装置的应用程序或以任何其他方式在车辆的HMI上呈现凭证。如关于图8所述，还可以在车辆上或车辆中或通过用户移动装置的应用程序呈现呈彩色灯形式的状态指示器。在操作412和/或414之后，流程图400可以返回到操作404。在需要清洁车辆的情况下，系统然后可以收集附加的空气质量数据以确定在操作414中执行的清洁是否足够。即，车辆的病原体检测器可以再次检查车辆以确定车辆内是否存在任何病原体(和/或车辆中是否存在阈值数量的病原体)。所述系统还可以继续不断地或定期地检查车辆的病原体。例如，车辆可以对来自用户的每次约车服务请求、以某些预定义时间间隔、每次约车乘车者退出车辆时、在用户请求时或以另一间隔执行检查。

图5示出了根据本公开的一个或多个实施例的示例性流程图500。流程图500可以示出涉及(例如，通过用户的移动装置的约车应用程序)确定车辆是否干净并准备好供约车乘客使用的逻辑流程。在一些情况下，这可以允许约车用户(或用户的组织)设定他们自己的关于构成供用户使用的足够干净的车辆的内容的偏好。流程图500还可以考虑向用户账户收费以对第一分配的车辆执行清洁度测试或取消初始分配的车辆并重新请求另一车辆。流程图500可以开始于操作502，其可以涉及从用户的约车应用请求乘车。在操作502之后，操作504可以涉及由约车服务基于所述请求向用户分配车辆。在操作504之后，操作506可以涉及约车应用程序查询区块链以确定车辆的状态。如本文所述，车辆的状态可以指代车辆的清洁度状态。例如，包括在约车车队中的车辆可以被配备有病原体检测器，所述病原体检测器可以用于确定给定的约车车辆中是否存在任何病原体。在操作506之后，操作508可以涉及从约车应用程序接收对车辆中的附加空气测试的请求。例如，用户可以通过他们的约车应用程序指示他们希望对分配给他们的车辆进行病原体测试。在操作508之后，操作514可以涉及约车服务在车辆中发起测试。例如，集成在车辆内的病原体检测器可以测试车辆以确定车辆中是否存在任何病原体。在一些情况下，病原体检测器还可以测试以确定车辆中是否存在阈值数量的病原体。在一些情况下，阈值数量可以基于用户偏好。例如，用户可以通过约车应用程序预先建立关于所分配的约车车辆可接受的病原体的阈值水平的设置。在操作514之后，流程图可以前进到条件516。条件516可以涉及确定车辆是否干净。例如，所述条件可以基于在车辆中是否检测到任何病原体和/或是否在车辆中检测到给定的阈值量的病原体。如果确定车辆是干净的，则流程图500可以前进到操作518。操作518可以涉及应用程序向客户显示对“干净”凭证和车辆信息的指示。然而，如果确定车辆不干净，则流程图500可以前进到操作512。操作512可以涉及取消先前分配的车辆。在此类情况下，约车应用程序可以自动请求新车辆和/或约车服务可以自动将新车辆分配给用户。另外，约车服务可以任选地识别满足用户的清洁度要求的车辆，使得用户可能不需要为新分配的车辆请求第二次测试。另外，在一些情况下，甚至可以在用户需要之前自动执行清洁度测试。可以基于用户的偏好或基于可以应用于所有约车用户的默认病原体阈值来自动执行测试。

图6示出了根据本公开的一个或多个实施例的示例性流程图600。流程图600可以呈现可用于增加当用户做出清洁请求时车辆被实际清洁的保证的逻辑流程。即，流程图600可以呈现一旦用户实际已发起车辆清洁请求(和/或在没有来自用户的请求的情况下自动安排车辆清洁时)就可以执行的操作。流程图600可以开始于操作602。操作602可以涉及车辆到达清洁位置。操作602还可以涉及车辆显示代码并请求特定类型的清洁服务。在一些情况下，代码可以是对时间敏感的代码。代码可以无线地(例如，经由WiFi、蓝牙或任何其他无线方法)呈现，或者可以在视觉上(例如，通过车辆的HMI或通过车辆的任何其他部分)呈现。在一些情况下，代码可以是QR码，然而，代码也可以是任何其他形式。操作604可以涉及将车辆识别码提供给区块链。操作606可以涉及智能合约确认车辆处于清洁位置处。该确认可以通过任何数量的合适方式执行。例如，位置确认可以包括使用车辆内的GPS来确定车辆在所述位置处。另一个示例可以包括确定清洁位置处的装置已经扫描了车辆代码。操作608之后可以是条件610。条件610可以包括确定在清洁位置处是否已经发生清洁。在一些情况下，该确定可以由集成到车辆中的病原体检测器来执行。在一些情况下，还可以使用任何其他车辆传感器(例如，相机等)来确定所述确定。如果是，则流程图600可以前进到操作612。操作612可以涉及智能合约接受对车辆被清洁的更新。

图7示出了根据本公开的一个或多个实施例的示例性流程图700。流程图700可以呈现何时可向用户呈现不同的状态指示器的逻辑流程。除了App内通知之外或作为其替代，内置在车辆中的状态灯可以为用户确认车辆的就绪状态。与应用程序和区块链结合使用，这可以提供车辆准备就绪的更快的最终确认(例如，如果用户在接载点没有互联网连接，或者存在短暂的时间段-可能在先前乘客退出之后运行测试-不应进入车辆)。为了提高对系统的置信度，状态指示器可以使用其自己的逻辑进行操作并且具有其自己的与区块链的连接。为了维持用户偏好，状态指示器可以具有针对灵敏度或所需测试频率(例如，每次乘车、每第五次乘车等)的多种操作模式，并且可以在接受乘车时在接载之前记录这些偏好。在一些情况下，状态指示器可以是可改变颜色以表示车辆的不同状态的彩色灯的形式。然而，状态指示器可以以任何其他形式呈现，诸如例如听觉指示器或另一种类型的视觉指示。

流程图700可以开始于操作702，其可以涉及确定车辆已经到达接载点。接载点可以指代由请求约车乘车的用户请求的接载位置。操作702之后可以是条件704，其可以涉及确定是否存在仍然坐在车辆内的先前乘客。如果满足条件704，则流程图可以前进到操作712。如果不满足条件704，则流程图700可以前进到操作706。操作706可以涉及将车辆上的状态指示器的颜色改变为黄色。操作706之后可以是操作708，其可以涉及等待驾驶员指示他们准备好让乘客进入车辆。操作708之后可以是操作710，其可以涉及车辆的状态指示器改变为绿色。

操作712可以涉及车辆的状态灯显示为红色。操作712之后可以是操作714，其可以涉及等待当前乘客离开车辆。操作714之后可以是条件716，其可以涉及确定是否需要测试。如果确定不需要测试，则流程图700可以前进到操作706。如果确定需要测试，则流程图700可以前进到操作718。操作718可以涉及运行测试并将结果发布到区块链。操作718之后可以是条件720。条件720可以涉及确定测试是否通过。如果满足条件，则流程图700可以前进到操作706。如果不满足条件720，则流程图700可以前进到操作722。操作722可以涉及车辆的状态灯闪烁红色。操作722之后可以是操作724，其可以涉及约车服务请求新车辆。这可以基于识别对区块链的失败测试。

图8示出了根据本公开的一个或多个实施例的示例性系统800。在一些情况下，图8所示的系统800可以提供可用于向用户呈现车辆802的状态的不同方法的示例。例如，如图7的流程图700所示，可以基于车辆的清洁度状态(或基于与车辆相关联的任何其他相关信息)向用户呈现不同的颜色状态指示器。在一些情况下，状态灯可以直接呈现在车辆802的一个或多个部分上或其内部。如图中描绘，车辆的车门804可以包括可改变为不同颜色的相关联的状态灯806。作为第二示例，可以从车辆802投射门控地面照明灯808。作为第三示例，状态可以呈现在车辆802的HMI 810上。该状态可以直接来自区块链，或者替代地，可以经由在车辆HMI上显示的QR码呈现车辆的健康状况通过凭证，用户可以扫描所述QR码并对照区块链进行验证。在一些情况下，可以通过呈现在用户的移动装置812上的约车应用程序来呈现状态灯。

图9示出了根据本公开的一个或多个实施例的示例性方法900。在框902处，方法900可以包括从用户的移动装置接收对约车车辆的请求。在框904处，方法900还可以包括从第一车辆内的病原体检测器装置接收对第一车辆内的病原体的数量小于阈值量的指示。方法900的框906可以包括基于对第一车辆内的病原体的数量小于阈值量的指示而将第一车辆分配给用户。

图10描绘了根据本公开的一个或多个示例性实施例的可以在其上执行一个或多个技术(例如，方法)中的任一者的示例性机器1000的框图。在其他实施例中，机器1000可以充当独立的装置，或者可以与其他机器连接(例如，联网)。在联网部署中，机器1000可以作为服务器机器、客户端机器或以上两者在服务器-客户端网络环境中操作。在示例中，机器1000可以充当对等(P2P)(或其他分布式)网络环境中的对等机器。机器1000可以是个人计算机(PC)、平板PC、机顶盒(STB)、个人数字助理(PDA)、移动电话、可穿戴计算机装置、网络设备、网络路由器、交换机或桥接器，或能够执行指令(连续或以其他方式)的任何机器，所述指令指定将要由所述机器(例如，基站)采取的动作。此外，虽然仅说明单个机器，但术语“机器”还应被视为包括单独地或联合地执行用于执行本文论述的方法中的任何一者或多者的一组(或多组)指令的任何机器集合，本文论述的方法例如为云计算、软件即服务(SaaS)或其他计算机集群配置。

本文描述的示例可以包括逻辑或许多部件、模块或机构，或者可以在逻辑或许多部件、模块或机构上操作。模块是能够在操作时执行指定操作的有形实体(例如，硬件)。模块包括硬件。在示例中，硬件可以特定被配置成执行特定操作(例如，硬连线)。在另一示例中，硬件可以包括可配置的执行单元(例如，晶体管、电路等)和含有指令的计算机可读介质，其中所述指令配置所述执行单元以当在操作中时执行特定操作。可以在执行单元或加载机构的引导下进行所述配置。因此，当装置在操作时，执行单元通信地耦合至计算机可读介质。在此示例中，执行单元可以是多于一个模块的成员。例如，在操作下，可以在一个时间点通过第一组指令配置执行单元以实施第一模块，并且在第二时间点通过第二组指令重新配置执行单元以实施第二模块。

机器(例如，计算机系统)1000可以包括硬件处理器1002(例如，中央处理单元(CPU)、图形处理单元(GPU)、硬件处理器核心，或其任何组合)、主存储器1004和静态存储器1006，它们中的一些或全部可以经由互连(例如，总线)1008彼此通信。机器1000还可以包括图形显示装置1010、字母数字输入装置1012(例如，键盘)和用户接口(UI)导航装置1014(例如，鼠标)。在示例中，图形显示装置1010、字母数字输入装置1012和UI导航装置1014可以是触摸屏显示器。机器1000可以另外包括存储装置(即，驱动单元)1016、耦合到天线1030的网络接口装置/收发器1020，以及一个或多个传感器1028，例如全球定位系统(GPS)传感器、罗盘、加速度计或其他传感器。机器1000可以包括输出控制器1034，例如串行(例如，通用串行总线(USB))、并行或其他有线或无线(例如，红外(IR)、近场通信(NFC)等)连接，以与一个或多个外围装置(例如，打印机、读卡器等)通信或控制所述一个或多个外围装置。

存储装置1016可以包括机器可读介质1022，其上存储由本文描述的技术或功能中的任何一者或多者体现或利用的一个或多个数据结构或指令集1024(例如，软件)。指令1024还可以在机器1000执行所述指令期间完全或至少部分地驻留在主存储器1004内、静态存储器1006内或硬件处理器1002内。在示例中，硬件处理器1002、主存储器1004、静态存储器1006或存储装置1016中的一者或任何组合可以构成机器可读介质。

虽然将机器可读介质1022说明为单个介质，但术语“机器可读介质”可以包括被配置为存储一个或多个指令1024的单个介质或多个介质(例如，集中或分布式数据库，和/或相关联的缓存和服务器)。

各种实施例可以完全或部分地以软件和/或固件实施。此软件和/或固件可以采用包含在非暂时性计算机可读存储介质中或其上的指令的形式。然后，可以由一个或多个处理器读取和执行那些指令，以实现本文所述的操作的执行。指令可以是任何合适的形式，例如但不限于源代码、编译代码、解释代码、可执行代码、静态代码、动态代码等。这种计算机可读介质可以包括用于以可由一个或多个计算机读取的形式存储信息的任何有形非暂时性介质，例如但不限于只读存储器(ROM)；随机存取存储器(RAM)；磁盘存储介质；光学存储介质；快闪存储器等。

术语“机器可读介质”可以包括具有以下性质的任何介质：能够存储、编码或载送供机器1000执行的指令；以及使机器1000执行本公开的技术中的任何一者或多者；或者能够存储、编码或载送由此类指令使用或与此类指令相关联的数据结构。非限制性机器可读介质示例可以包括固态存储器以及光学和磁性介质。在示例中，大规模机器可读介质包括拥有多个具有静止质量的颗粒的机器可读介质。大规模机器可读介质的特定示例可以包括非易失性存储器，例如半导体存储器装置(例如，电可编程只读存储器(EPROM)，或电可擦除可编程只读存储器(EEPROM))和快闪存储器装置；磁盘，例如内部硬盘和可移除盘；磁光盘；以及CD-ROM和DVD-ROM盘。

指令1024可以进一步利用多个传输协议(例如，帧中继、互联网协议(IP)、传输控制协议(TCP)、用户数据报协议(UDP)、超文本传输协议(HTTP)等)中的任何一者经由网络接口装置/收发器1020使用传输介质在通信网络1026上传输或接收。示例性通信网络可以包括局域网(LAN)、广域网(WAN)、分组数据网络(例如，互联网)、移动电话网络(例如，蜂窝网络)、普通老式电话(POTS)网络、无线数据网络(例如，称为

一些实施例可结合各种装置和系统使用，例如个人计算机(PC)、台式计算机、移动计算机、膝上型计算机、笔记本计算机、平板计算机、服务器计算机、手持计算机、手持式装置、个人数字助理(PDA)装置、手持式PDA装置、车载装置、车外装置、混合装置、车辆装置、非车辆装置、移动或便携式装置、消费者装置、非移动或非便携式装置、无线通信站、无线通信装置、无线接入点(AP)、有线或无线路由器、有线或无线调制解调器、视频装置、音频装置、音频-视频(A/V)装置、有线或无线网络、无线区域网络、无线视频区域网络(WVAN)、局域网(LAN)、无线LAN(WLAN)、个人局域网(PAN)、无线PAN(WPAN)等。

一些实施例可结合以下使用：单向和/或双向无线电通信系统、蜂窝无线电-电话通信系统、移动电话、蜂窝电话、无线电话、个人通信系统(PCS)装置、包含无线通信装置的PDA装置、移动或便携式全球定位系统(GPS)装置、包含GPS接收器或收发器或芯片的装置、包含RFID元件或芯片的装置、多输入多输出(MIMO)收发器或装置、单输入多输出(SIMO)收发器或装置、多输入单输出(MISO)收发器或装置、具有一根或多根内部天线和/或外部天线的装置、数字视频广播(DVB)装置或系统、多标准无线电装置或系统、有线或无线手持装置(例如，智能电话)、无线应用协议(WAP)装置等。

一些实施例可结合遵循一个或多个无线通信协议的一种或多种类型的无线通信信号和/或系统使用，所述无线通信协议例如是射频(RF)、红外(IR)、频分复用(FDM)、正交FDM(OFDM)、时分复用(TDM)、时分多址(TDMA)、扩展的TDMA(E-TDMA)、通用分组无线电服务(GPRS)、扩展的GPRS、码分多址(CDMA)、宽带CDMA(WCDMA)、CDMA 2000、单载波CDMA、多载波CDMA、多载波调制(MDM)、离散多音(DMT)、

另外，在本说明书和附图中，例如“存储区”、“存储装置”、“数据存储区”、“数据存储装置”、“存储器”、“存储库”以及与本公开的部件的操作和功能性相关的基本上任何其他信息存储部件的术语都指代存储器部件、体现在一个或若干个存储器装置中的实体或形成存储器装置的部件。应当注意，本文所描述的存储器部件或存储器装置体现或包括可能够由计算装置读取或以其他方式访问的非暂时性计算机存储介质。此类介质可在用于存储信息的任何方法或技术中实现，所述信息诸如机器可访问指令(例如，计算机可读指令)、信息结构、程序模块或其他信息对象。

除非另外明确说明，或者在所使用的上下文中以其他方式理解，否则诸如“能够”、“可以”、“可能”或者“可”等条件语言通常意图传达某些实现方式可以包括而其他实现方式不包括某些特征、元件和/或操作。因此，这种条件语言一般不意在暗示特征、元素和/或操作无论如何都是一个或多个实现方式所必需的，或者一个或多个实现方式必定包括用于在有或没有用户输入或提示的情况下判定这些特征、元素和/或操作是否被包括在任何特定实现方式中或者将在任何特定实现方式中执行的逻辑。

本文在本说明书和附图中已描述的内容包括系统、装置、技术和计算机程序产品单独地或组合地结合某些系统和方法的示例。当然，不可能为了描述本公开的各种元件的目的而描述可设想的部件和/或方法的每个组合，但是可认识到，所公开的元件的许多其他组合和排列是可能的。因此，可能明显的是，可在不脱离本公开的范围或精神的情况下对本公开做出各种修改。另外或作为替代方案，根据考虑本说明书和附图，以及如本文所呈现的对本公开的实践，本公开的其他实施例可能是明显的。本说明书和附图中提出的示例意图在所有方面都被视为是说明性的而不是限制性的。尽管本文采用了具体的术语，但是它们仅用于一般且描述性意义，而不是出于限制的目的。

根据本发明，提供了一种具有存储计算机可执行指令的非暂时性计算机可读介质，所述计算机可执行指令在由处理器执行时使所述处理器：从用户的移动装置接收对车辆的请求；使用第一车辆内的病原体检测器装置确定所述第一车辆内的病原体的数量小于阈值量；以及基于对所述第一车辆内的病原体的所述数量小于所述阈值量的指示将所述第一车辆分配给所述用户。

根据一个实施例，计算机可执行指令还使所述处理器：从所述病原体检测器装置接收对所述第一车辆内的病原体的所述数量大于所述阈值量的指示；以及基于确定所述第一车辆内的病原体的所述数量超过所述阈值量来确定将第二车辆分配给所述用户。

根据一个实施例，所述计算机可执行指令还使所述处理器：使用与区块链相关联的智能合约，在所述区块链上存储对所述第一车辆内的病原体的所述数量小于所述阈值量的指示。

根据一个实施例，所述计算机可执行指令还使所述处理器：发送使所述第一车辆行驶到清洁位置的指令；基于以下至少一项来确定所述第一车辆处于所述清洁位置处：来自所述第一车辆的全球定位系统(GPS)信号和/或对在所述清洁位置处扫描到与所述第一车辆相关联的代码的指示；以及从所述第一车辆内的所述病原体检测器装置接收对所述第一车辆已被清洁的指示。

根据一个实施例，所述计算机可执行指令还使所述处理器：为对所述第一车辆内的病原体的所述数量超过所述阈值量的确定呈现状态指示器。