NETWORK COMPUTER SYSTEM TO DETERMINE SUITABILITIES OF VEHICLES USING BLOCKCHAIN RECORDS

A network computer system can determine an identifier of a token that is uniquely associated with a vehicle. Additionally, the network computer system can utilize the identifier of the token to retrieve a record from a blockchain. Moreover, the network computer system can make a determination as to whether the vehicle is suitable for use with a network transport service based on the retrieved record.

BACKGROUND

A network computer system can receive, from user devices, service requests for one or more network services. The service request can include data related to a service location (e.g., a service initialization location) that the service provider is to travel to, to provide the requested service. The network computer system can provide to the service provider routing information to the location. Increasingly, autonomous vehicles are also being used to provide transportation services.

DETAILED DESCRIPTION

In some examples, a network computer system determines whether a vehicle is suitable or use with a network transportation service (e.g., an on-demand transport service). In some examples, the determination of whether the vehicle is suitable is based on transactions that are recorded on an immutable ledger. In such examples, the immutable ledger can be provided with public blockchain services. In variations, the network computer system can write to the blockchain service a variety of records relating to the use or operability of the vehicle.

According to some examples, a vehicle is autonomous and owned by an owner entity that is independent of a network computer system that provides an on-demand transport service. In such examples, the network computer system can rely on, for example, inspections, certifications and/or service records that are signed by trusted entities on the blockchain service.

Among other benefits, examples enable requesters of an on-demand network transportation service or passengers of the vehicle to view the inspection records, certifications, or service history of the vehicle, as recorded by on the ledger of the blockchain service.

As provided herein, the terms “user,” “requester” and “service requester” are used throughout this application interchangeably to describe a person or group of people who utilize a requester application on a computing device to request, over one or more networks, on-demand services from a network computing system. The term “service provider” is used to describe a person utilizing a provider application on a computing device to provide on-demand services to the service requesters.

Moreover, examples described herein can generally require the use of specialized computing devices, including processing and memory resources. For example, one or more examples described may be implemented, in whole or in part, on computing devices such as servers, desktop computers, cellular or smartphones, personal digital assistants (e.g., PDAs), laptop computers, printers, digital picture frames, network equipment (e.g., routers), wearable computing devices, and tablet devices. Memory, processing, and network resources may all be used in connection with the establishment, use, or performance of any example described herein (including with the performance of any method or with the implementation of any system). For instance, a computing device coupled to a data storage device storing the computer program and configured to execute the program corresponds to a special-purpose computing device. Furthermore, any computing systems referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.

Alternatively, one or more examples described herein may be implemented through the use of dedicated hardware logic circuits that are comprised of an interconnection of logic gates. Such circuits are typically designed using a hardware description language (HDL), such as Verilog and VHDL. These languages contain instructions that ultimately define the layout of the circuit. However, once the circuit is fabricated, there are no instructions. All the processing is performed by interconnected gates.

System Description

FIG. 1illustrates an example network computer system for determining a suitability of a vehicle for use with an on-demand network service. In particular, network computer system100can determine a suitability of a vehicle (e.g., vehicle50) for use with, for example, an on-demand network transportation service based on records contained in an immutable ledger of a blockchain service11. As described by various examples, a vehicle can be deemed suitable for operation or use for a network transportation service if the vehicle is deemed safe. Additionally, the determination of suitability can consider rules, conditions and/or terms for the use of the vehicle, as specified by an owner entity, as well as the need for the vehicle by the network transportation service. In examples in which the vehicle is autonomous, the suitability of the vehicle can include a determination of whether the autonomous vehicle is sufficiently capable to navigate independently in a given geographic region.

According to examples, the network computer system100can utilize a blockchain service11which provides an immutable ledger to record transactions. The blockchain service11can maintain, for example, an immutable ledger that is maintained on a decentralized architecture.

In some examples, a vehicle50can be owned, or under control of an owner entity32(e.g., person, corporation, group of owners). By way of example, the owner entity32can have a lease, time-based ownership, or outright title to the vehicle50. In some examples, the vehicle50is a fully autonomous vehicle, meaning the vehicle50can operate and travel routes to select destinations without a human driver.

According to some examples, the vehicle50can be assigned or otherwise associated to a blockchain token20. In examples, the blockchain token20can include an encrypted alphanumeric string (e.g., private key) that can be stored in a data storage media of the owner entity32. By way of example, the blockchain token20can be stored on a digital wallet of the user, which can reside on, for example, an owner device102of the owner entity32, with a network account of the owner entity32, or on a specialized storage device. In variations, the blockchain token20can be stored on a data storage media of the network computer system100, or of a third-party.

In some examples, the owner entity32can elect to make the vehicle50available for use with an on-demand network transportation service that is implemented by the network computer system100. In examples where the vehicle50is fully autonomous, the owner entity32can, for example, intermittingly make the vehicle50available to the on-demand network transportation service when the user is not utilizing the vehicle50. As described by examples, the owner entity32can use transaction records, recorded in the blockchain ledger to provide verifiable records relating to the safety and capability of the vehicle50.

The blockchain token20can be uniquely associated with addresses on the blockchain ledger of the blockchain service11which record transactions that identify the blockchain token20. The blockchain token20can include a public identifier, such as a memory address, and the identifier can be used to read and/or write transactions to the blockchain ledger. In examples, transactions which are associated with the memory address or identifier of the blockchain token20are collectively referred to as a “token ledger” (represented inFIG. 1by the “token ledger30”). As with other portions of the blockchain ledger, the token ledger30can also be immutable.

In some examples, the token ledger30can store signed transactions that relate to the vehicle50. In one implementation, the token ledger30can store a record that includes the vehicle identification number (VIN) or other unique identifier of the vehicle50. The record can be created by, for example, the owner entity32, using a signature that is generated from the blockchain token20. In examples, once the VIN of the vehicle50is associated with the blockchain token20on the blockchain service11, the VIN cannot be legitimately appropriated with another transaction unless there is a corresponding record that represents a corresponding transfer of the vehicle50.

In examples, the owner entity32can have trusted third-parties sign transactions which are relevant to the vehicle50(e.g., service or inspection). By way of example, the token ledger30can include signed transactions, or records, of vehicle inspections, service checks, maintenance, and/or repairs, as performed by one or more pre-approved or trusted third-parties. The trusted third-parties can use their own blockchain token to sign transactions on the blockchain ledger, thereby creating a corresponding immutable record that is time stamped and associated with the vehicle50. In implementations, the owner entity32can also sign the transactions using the blockchain token20, to enable creation of a corresponding record on the blockchain service11.

In examples, the network computer system100can include an owner interface112, a vehicle intake subsystem120, a blockchain interface130and a network transportation subsystem150. The owner entity32can use the owner interface112to make the vehicle50available to the network transportation service for use as a transportation resource. The owner interface112can be implemented as, for example, a programmatic process that communicates with the owner device102of the owner entity32. For example, the owner entity32can run a service application on the owner device102to register the vehicle50with the network transportation service provided through the network computer system100. Registration by the owner entity32can generate an account that is stored with the owner account store106. The account can include, or otherwise be associated with profile information which identifies information such as the vehicle50of the owner entity32. As described below, the owner account store106can include a history of the usage of the vehicle50with the network computer system100, including whether the vehicle50has previously been determined to be suitable for use by the system.

The owner device102can communicate an identifier of the owner entity32or the vehicle50to the network computer system100. For example, the owner device102can transmit an identifier (e.g., mobile number, account identifier) to the owner interface112, and the owner interface112can determine whether a vehicle or ledger address is associated with the account of owner entity32and/or owner device102. In variations, the owner device102can transmit an identifier of the token ledger30to the owner interface112.

Additionally, in some examples, the owner entity32can specify rules, conditions and/or terms for using the vehicle with the network transportation service. For example, the owner entity32of the vehicle50can make the vehicle available for a select number of hours during a time period when the owner is at work, or for a duration in which the vehicle50is on a trip and away from home. According to examples, the owner entity32can specify various rules and conditions relating to the use of the vehicle with the network transportation service of100. For example, the owner entity32can specify available hours of vehicle use, the geographic range where the vehicle50can be used, and/or a maximum number of occupants that are to be included in the vehicle50. The owner entity32can also specify one or more compensatory terms for the usage of vehicle50. For example, the owner entity32can specify a time and/or distance based cost for use of the vehicle50by the network computer system100. In some examples, the owner entity32can specify the rules, conditions, and/or compensatory terms through the service application of the owner device102. As an addition or variation, the owner entity32or the network computer system100can communicate some or all of the rules, conditions, and/or compensatory terms to logic provided with a corresponding blockchain ledger. For example, the compensatory terms can be self-executed by logic provided through the blockchain ledger.

In examples, the owner entity32makes the vehicle50available for use by making a vehicle intake request151that is received by the owner interface112. In response to receiving the owner interface112, vehicle intake subsystem120implements one or more processes to determine whether to use the vehicle50, in connection with the network transportation service, for a given time interval specified in the vehicle intake request151.

In examples, vehicle intake subsystem120can include one or more processes which make determinations as to whether the network computer system100should use the vehicle50to arrange transport for requesters (e.g., riders). Vehicle intake subsystem120can make one or multiple determinations before accepting the vehicle50for use through the on-demand network transportation service. In examples, the determinations can include (i) a determination as to whether the vehicle50is suitable for the one-demand network transportation service, (ii) a determination as to whether there is an expectation of sufficient demand for the vehicle50during a time period in which the vehicle50is to be made available, and/or (iii) a determination as to whether rules, conditions and/or terms specified by the owner entity32with respect to the use of the vehicle50are acceptable.

According to examples, the vehicle intake subsystem120can include a vehicle evaluation component122to make a determination of the suitability of the vehicle50based on transaction records that reference the blockchain token20on the blockchain ledger. For example, the blockchain ledger can store transaction records that reference the public identifier of the blockchain token20, and which reflect a purchase or age of the vehicle50, service repairs, and/or recent inspections of the vehicle50. The vehicle evaluation component122can access and read transaction records on the blockchain which reference the public identifier of the blockchain token20via blockchain interface130. The blockchain records that reference the public identifier of the blockchain token20can be retrieved, and information contained in the records can be used to make the suitability determinations. By way of example, the records can include, for example, maintenance records, ownership records, and/or insurance records. The suitability determination made by the vehicle evaluation component122can be in the form of, for example, one or more scores, ratings and/or checklists. The vehicle evaluation component122can determine the suitability of the vehicle50by making, for example, a determination of an overall safety level of the vehicle50. In examples in which the vehicle50is autonomous, the suitability determination can also relate to the capability of the vehicle50to operate autonomously. The determinations can further be specific as to whether the vehicle50is suitable for use in an on-demand network service.

In some variations, the determinations of the vehicle evaluation component122can also be written as a separate signed transaction with the blockchain service11. Thus, for example, blockchain interface130can use a signature of network computer system100to create a transaction record that reflects one or more of the suitability determinations of the vehicle evaluation component122(e.g., safety score, autonomous capability), and the time and/or conditions when such determination(s) was made. In some implementations, the owner entity32may also sign the respective records as validation. For example, the owner entity32may be required to sign and validate transactions that are initiated by the system100as a condition for having the vehicle50used as part of the network transportation service.

In some examples, the network computer system100may implement requirements for inspection of the vehicle50before the vehicle50is accepted for use with the on-demand network transportation service. The inspection can be by, for example, a trusted third-party, to evaluate the operation of the vehicle50and/or the autonomous capability of the vehicle50. The vehicle evaluation component122can use the public identifier of the blockchain token20to determine whether there is a signed record reflecting that a transaction in which the vehicle50was inspected by a trusted third-party.

Accordingly, the vehicle evaluation component122can access the blockchain ledger of the blockchain service11via the blockchain interface130to retrieve information about signed transactions relating to the operability, safety or capability (e.g., autonomous capability) of the vehicle50. The vehicle evaluation component122can make the determination of suitability based on, for example, the type of inspections (or certifications) that were made on the vehicle50, the source of the inspection or certification records, the recency of the inspections or certifications, and/or the result of the of the inspections or certifications. The vehicle evaluation component122can communicate the determination to the owner entity32via the owner interface112. For example, the owner device102can generate a message that communicates to the owner entity32whether the system100has deemed the vehicle suitable. In some examples, the vehicle evaluation component122can communicate, via the owner interface112, requirements of suitability to the owner interface112based on an outcome of the determination, or in advance of the making the determination. Thus, for example, if the vehicle50is deemed as not being suitable, the vehicle evaluation component122can communicate information as to what the owner entity32needs to do, such as identifying the type of inspection and/or a trusted source for providing the required inspection.

In other variations in which the vehicle50is autonomous, the vehicle50can be provided with software that can create records reflecting signed transactions of the vehicle50, on blockchain ledger of the blockchain service11. The autonomous capable vehicle50may, for example, create signed transaction records on the blockchain ledger to reflect the occurrence of events, such as the receipt of as map update or software version by the vehicle50. In such variations, the vehicle evaluation component122can further make determinations of suitability based on information provided by such transaction records as stored in the blockchain ledger of the blockchain service11.

Additionally, if the vehicle50is known (e.g., previously used by the network computer system100), the network computer system100may still implement periodic requirements (e.g., based on passage of time, or miles driver) which mandate inspection or servicing of the vehicle50by a trusted source. In turn, the trusted source (e.g., third-party) can perform a required inspection and sign a transaction (which the owner entity32may cosign) with the blockchain ledger of the blockchain service11, using a public identifier of the blockchain token20. The signed record can identify, for example, the third-party, a data of the inspection, and the type of inspection that was performed.

In examples, the vehicle intake subsystem120can also evaluate other conditions or criteria before the vehicle50is used by the network computer system100. The vehicle intake subsystem120can make a determination as to whether the network computer system100has need for the vehicle50. For example, the determination can be based on existing or projected supply of vehicles, as well as existing or projected demand for transport by users of the network computer system100. Thus, the vehicle intake subsystem120can make a determination as to whether to permit the vehicle50to become part of the available vehicles which the on-demand network transportation service can match to transport requests over a given time interval.

In examples, vehicle intake subsystem120can include owner rules logic124to evaluate the rules, conditions and/or terms that the owner entity32has specified in the blockchain with respect to the use of the vehicle50. Vehicle intake subsystem120can implement the owner rules logic124to determine whether the network computer system100can meet, for example, rules and conditions relating to the use of the vehicle50(e.g., geographic region, time interval for vehicle use, restrictions with respect to number of passengers, etc.). Vehicle intake subsystem120can also implement the owner rules logic124to evaluate the terms of the use of the vehicle50. Vehicle intake subsystem120can determine the rules, conditions and/or terms of the use of vehicle50from the blockchain ledger, using, for example, the public identifier of the blockchain token20. Alternatively, vehicle intake subsystem120can determine some or all of the rules, conditions and/or terms of the use of vehicle50from the owner entity32, via, for example, use of a service application running on the owner device102.

According to examples, vehicle intake subsystem120can determine that the terms specified by the owner entity32are too expensive, given the current projection of available vehicles and demand for the specified time interval. In some examples, the owner rules logic124can be implemented to evaluate and determine the rules, conditions and terms of the owner as satisfactory or not satisfactory. Vehicle intake subsystem120can communicate the outcome to the owner entity32via the owner interface112. In some variations, if the determination is not satisfactory, the owner entity32can make a change (e.g., reduce cost or relax condition) to have the evaluation of the rules, conditions and/or terms be satisfactory.

If, in response to the vehicle intake request (IR)151, vehicle intake subsystem120determines to use the vehicle50, vehicle intake subsystem120can make the vehicle50available to the network transportation subsystem150. The network transportation subsystem150can include a requester interface152, a vehicle interface154, a matching engine156, and a service data store158. In examples in which the vehicle50is an autonomous vehicle that is to be used to provide transport, the vehicle interface154can establish a communication link with the vehicle50(e.g., using information provided by the owner entity32). The vehicle interface154can identify, for example, a location of the vehicle50using location-aware resources of the vehicle50(e.g., satellite receiver). The vehicle interface154can further create and/or update a service record (SR)159for the vehicle50with the service data store158, where the service record identifies a current location of the vehicle50, as well as other information, such as a state of the vehicle50(e.g., open), and/or a type of the vehicle50(e.g., full autonomous). In some variations, the vehicle interface154can also instruct, or otherwise control the vehicle50to position itself at a particular sub-region, in order to better the vehicle's ability to meet projected demand, and/or to improve the performance of vehicle50(e.g., position vehicle in well-mapped region). As the vehicle50travels, the vehicle interface154can track the vehicle50and update the record of the vehicle50with the service data store158as to the current location of the vehicle50.

With further reference to the network transportation subsystem150, the requester interface152can communicate with requester devices104of a population of users (as represented by requester device104inFIG. 1). The requester device104can, for example, implement a corresponding service application (SA)105, which individual requesters can use to make transport requests101. The transport requests101can specify parameters such as a service start location (e.g., pickup location), destination location (e.g., drop-off location), and other parameters such as the type of vehicle which the requester prefers or requires. In examples in which autonomous vehicles are available for requesters, the requester can specify a preference for or against an autonomous vehicle. Additionally, the requester can specify a preference for or against autonomous vehicles of different sources (e.g., privately owned, provided by particular entity, etc.). The requester interface152can receive the transport request101from the requester device104, and the matching engine156can match the transport request101to an available vehicle (e.g., vehicle50) based on the service parameters (e.g., start location, destination location, type of vehicle) of the request.

When the matching engine156selects the vehicle50for a given transport request101, the matching engine156can communicate information about the matched service request to the vehicle interface154. For example, the information can identify the service start and destination locations. In turn, the vehicle interface154can instruct the vehicle50to travel to the service start location to meet the passengers or requesters. In some variations, the vehicle interface154can also communicate instructions for additional operations to facilitate the transport service provided by the vehicle50. For example, the vehicle interface154can communicate a stopping location, where the vehicle50can stop temporarily to meet the passenger. In some variations, the vehicle interface154can communicate with the requester interface152to determine, for example, when the passenger enters the vehicle50. For example, the requester interface152may have the rider signal in response to when the passenger is seated, at which time, the vehicle interface154instructs the vehicle50to travel to the destination of the given transport request101.

With respect to autonomous vehicles, examples recognize that passengers or requesters may want assurance of a safety or capability of vehicle50before accepting to ride in the vehicle50, particularly if the vehicle50is an autonomous vehicle being supplied by an individual or unknown third-party. In such examples, the network computer system100may arrange transport using autonomous vehicles from multiple sources, including vehicles that are its own, as well as vehicles that belong to third-parties such as the owner entity32. For example, in cases such as described, the requester interface152can provide safety-related information155, based directly or indirectly off the token ledger30of the vehicle50. The safety-related information155can be provided automatically, or in response to a request from the rider. To provide the safety-related information155, the requester interface152can retrieve a copy of the most recent inspection and/or certification records of vehicle50. In some implementations, the retrieved records may be retrieved through the blockchain interface130, using the public identifier of the blockchain token20. In some variations, the vehicle intake subsystem120can retrieve a recent copy of the records of vehicle50from the owner account store106, rather than from the blockchain ledger of the blockchain service11.

As an addition or variation, the requester interface152can retrieve, from the owner account store106, a link to one or more specific transactions on the blockchain ledger of the blockchain service11, corresponding to inspection, certification and/or service records of the vehicle50. The requester interface152can provide the requester device104with the link to directly access the relevant records of the vehicle50, as maintained by the blockchain ledger of the blockchain service11. In some variations, the link can be a direct or link to a specific record of the blockchain ledger of the blockchain service11. In some examples, the requester interface152can provide content to the requester device104, based on retrieved transaction records from the blockchain ledger of the blockchain service11, and/or the determinations of vehicle intake subsystem120(e.g., a determined safety score of the vehicle50).

In examples, the vehicle interface154can implement monitoring operations on the vehicle50, to track, for example, a location and/or route of the vehicle50, as well as to identify events of varying magnitude. For example, the vehicle interface154can monitor the vehicle50to detect events such as accidents, near-accidents, incidents of suspect driving (e.g., overly sharp turn or braking event), indicators of vehicle damage, or other events. The vehicle interface154can record one or more transactions with the blockchain ledger of the blockchain service11, via blockchain interface130, using the public identifier of the blockchain token20. In examples, the owner entity32of the vehicle50may also sign the signed transactions generated by the network computer system100(e.g., as a requirement to have the vehicle50used with the network transportation service). The recorded transactions of the vehicle interface154can include information that is based on information determined from monitoring the vehicle50. Depending on implementation, the vehicle interface154can generate blockchain data (BCD)149, for block chain records161, via blockchain interface130, to include information such as, for example, (i) the occurrence of safety-related events, such as an accident involving the vehicle50, (ii) the occurrence of potential safety issues or hazards, such as close-calls, encounters with road debris, etc., and/or (iii) usage information (e.g., the distance traveled in the vehicle50with other riders).

In some variations, the vehicle interface154can detect thresholds or events after which the vehicle50should be serviced, inspected and certified. The vehicle interface154can record such events with the owner account store106, such that on one or more following instances (e.g., when the owner entity32makes another vehicle intake request151), the owner interface112can use profile information stored with the owner account store106to request the owner entity32to service, inspect and/or certify the vehicle50. As an addition or variation, the vehicle interface154can record with the token ledger30, via blockchain interface130, the request for the owner entity32to service, inspect and/or certify the vehicle50.

In some variations, the vehicle interface154can determine usage information as the vehicle50is used with the network computer system100. Blockchain interface130can further generate records with the token ledger30that reflect the usage information. By way of example, the usage information can reflect periodic odometer readings, records of individual transport requests that were fulfilled using the vehicle50(e.g., service start location, destination location, number of riders, etc.) and/or the number of tolls which the vehicle50passed through or incurred payment of. In such examples, the owner entity32can use the log information to determine a usage level of the vehicle50.

In other examples, the requester interface152can provide a rating interface to the requester device104, via the service application105. A passenger of the vehicle50can record a rating feedback, which can be received by the requester interface152and recorded against the blockchain ledger of the blockchain service11.

Still further, in order examples, the vehicle interface154detects and records, via blockchain interface130, sensor information of the vehicle50, on a periodic basis. By way of example, such records can include periodic determination of location information of the vehicle50, and/or vehicle information of vehicle50(e.g., onboard diagnostic data or “OBD”).

Methodology

FIG. 2illustrates an example method to determine whether a vehicle is suitable for use for a network transport service. In the below discussions ofFIG. 2, reference may be made to reference characters representing features a shown and described with respect toFIG. 1for purpose of illustrating a suitable component for performing a set or sub-step being described.

With reference toFIG. 2, the network computer system100can determine an identifier of a token that is uniquely associated with a vehicle (e.g., vehicle50) (200). For example, the network computer system100can identify the blockchain token20in response to an owner entity32making a vehicle intake request (VR)151. For example, in the context of autonomous vehicles, an owner entity32can make the vehicle50available for use with a network transport service when the autonomous capable vehicle50is not in use. As described with an example ofFIG. 1, the vehicle intake subsystem120can determine a public identifier of blockchain token20. In examples, the owner entity32can associate the vehicle50with the blockchain token20, by, for example, creating a transaction record that specifies the vehicle identification number (VIN) of the vehicle50using the blockchain token20.

Network computer system100can retrieve a record from a blockchain using the token identifier (202). For example, vehicle intake subsystem120can access and read transaction records on the blockchain which reference the public identifier of blockchain token20via blockchain interface130. The blockchain records that reference the public identifier of the blockchain token20can be retrieved by, for example, the blockchain interface130, using the public identifier of the blockchain token20. By way of example, the retrieved records can include, for example, maintenance records, ownership records, and/or insurance records. The records can be self-verified when signed by trusted third-parties.

Network computer system100can make a determination as to whether the vehicle is suitable for use with a network transport service based on one or more retrieved records from the blockchain ledger of the blockchain service11(204). For example, the vehicle intake subsystem120can make a determination of the suitability of vehicle50, based on the retrieved records. The received records can reference the public identifier of the blockchain token20on the blockchain ledger of the blockchain service11. The vehicle intake subsystem120can determine the suitability of the vehicle50by making, for example, a determination of an overall safety level of the vehicle50. In examples in which the vehicle50is autonomous, the suitability determination can also relate to the capability of the vehicle50to operate autonomously. The determinations can further be specific as to whether the vehicle50is suitable for use in an on-demand network service. In examples, the suitability determination made by the vehicle intake subsystem120can be in the form of, for example, one or more scores, ratings and/or checklists.

User Interface

In scenarios provided for by examples, a user of requester device104makes a transport request of the network computer system100, and the network computer system100selects an autonomous vehicle (e.g., vehicle50that has autonomous capabilities) for the user. Examples recognize that the user may want assurance that the arriving autonomous vehicle is safe to ride and is capable of autonomous driving to a destination specified by the transport request.

FIG. 3Aillustrates an example user interface (UI) executing on a service application of a requester device to provide information related to a vehicle that is selected to provide transport for a user. For example,FIG. 3Aincludes user interface300that be provided by a service application (e.g., service application105) running on a requester device (e.g., requester device104). User interface300can include various information panels, such as a photograph panel302that depicts a picture of the assigned vehicle, as well as a name (e.g., first name) or other identifiers304of the owner entity32, and one or more visible vehicle identifiers312(e.g., license plate number, color, make, model) of the assigned vehicle.

User interface300can also include panels that can provide information relevant to the safety and/or capability of the assigned vehicle. For example, the user interface300can include safety rating panel306. Safety rating panel306can include safety related information (e.g., safety-related information155) that is based directly or indirectly a record that references the public identifier of the blockchain token20, on the blockchain ledger of the blockchain service11. By way of example, the record can directly or indirectly identify a most recent inspection, certification, or maintenance record of the vehicle. Additionally, the user interface300can include vehicle type panel308. Vehicle type panel308can include vehicle capability related information (e.g., autonomous driving capabilities of the vehicle assigned to the service request). Vehicle capability related information can also be based directly or indirectly from a record (e.g., autonomous capability certification) that references the public identifier of the blockchain token20, on the blockchain ledger of the blockchain service11.

FIG. 3Billustrates an example user interface (UI) executing on a service application of a requester device that displays content from a record that is maintained with a blockchain service (e.g., blockchain service11). In particular, some examples provide for the user interface300to include a selectable feature310that enables requester to directly view a safety-related record that is stored with the blockchain ledger of the blockchain. As illustrated inFIG. 3B, selection of selectable feature310can cause a service application of a requester device to present the record (or records) that the safety rating panel306is based on. As illustrated byFIG. 3B, user interface320can be displayed in response to a user selecting the selectable feature310, as shown in an example ofFIG. 3A.

In examples, the user interface320can display content corresponding to records322,324. Record322can display the contents of a record maintained with the blockchain service11, and referencing the public identifier of the blockchain token20, where the displayed record relates to a certification of the autonomous capability of the vehicle, by a trusted source. Similarly, the record324can display the contents of a record maintained with the blockchain service11, which references the public identifier of the blockchain token20, where the record reflects a safety-related inspection by a trusted third-party.

Hardware Diagram

FIG. 4is a block diagram that illustrates a computer system upon which examples described herein may be implemented. In one embodiment, computer system400may correspond to a mobile computing device, such as a cellular device that is capable of telephony, messaging, and data services. Computer system400can correspond to a device operated by a requester or, in some examples, a device operated by the service provider (e.g., a freight operator) that provides location-based services. Examples of such devices include smartphones, handsets, tablet devices, or in-vehicle computing devices that communicate with cellular carriers. Computer system400includes processor410, memory resources420, display component430(e.g., such as a touch-sensitive display device), one or more communication sub-systems440(including wireless communication systems), one or more input mechanisms450(e.g., accelerometer and/or gyroscope, microphone, barometer, etc.), and one or more location detection components (e.g., GPS component)460. In one example, at least one communication sub-system440sends and receives cellular data over network(s)470(e.g., data channels and voice channels). Communication sub-systems440can include a cellular transceiver and one or more short-range wireless transceivers. Processor410can exchange data with a service arrangement system (not illustrated inFIG. 4) via the one or more communications sub-systems440and over network(s)470.

Processor410can provide a variety of content to display component430by executing instructions stored in memory resources420. Memory resources420can store instructions for service application425. For example, processor410can execute the service application425to read data from one or more input mechanisms450of the computing device, and to transmit the data, along with location data of GPS component460as local device data to a network computer system (e.g. network computer system100).

Examples described herein to extend to individual elements and concepts described herein, independently of other concepts, ideas or system, as well as for examples to include combinations of elements recited anywhere in this application. Although examples are described in detail herein with reference to the accompanying drawings, it is to be understood that the concepts are not limited to those precise examples. Accordingly, it is intended that the scope of the concepts be defined by the following claims and their equivalents. Furthermore, it is contemplated that a particular feature described either individually or as part of an example can be combined with other individually described features, or parts of other examples, even if the other features and examples make no mentioned of the particular feature. Thus, the absence of describing combinations should not preclude having rights to such combinations.