Distributed vehicle access

A usage rule specifies a number of tokens to access a vehicle. Authorization of a request to access the vehicle is based on receiving the number of tokens specified by the usage rule. The request is stored to an electronic ledger. Actuation of the vehicle is based on the request being authorized. An allocation rule specifies the number of tokens allocated to each of an entity and the vehicle based on the request. Allocation of tokens to the entity and the vehicle is based on the allocation rule.

BACKGROUND

Digital data collected and/or stored in vehicles can be lost or corrupted and can also be vulnerable to alteration. Such data can be important for monitoring and authorizing users to access vehicles. It is a problem that data for user access to a vehicle can be lost or corrupted.

DETAILED DESCRIPTION

A method includes determining a usage rule for a vehicle based on a request to access the vehicle. The usage rule specifying a number of tokens to access the vehicle. The method further includes authorizing the request based on receiving the number of tokens specified by the usage rule and storing the request to an electronic ledger, actuating the vehicle based on the request being authorized, and determining an allocation rule specifying the number of tokens allocated to each of an entity and the vehicle based on the request and allocating tokens to the entity and the vehicle based on the allocation rule.

Actuating the vehicle includes operating the vehicle along a route.

The method can further include determining the allocation rule based further on a time of day the vehicle is operating. The allocation rule is different at different times of day.

The method can further include determining the allocation rule based further on an identifier for the vehicle. The allocation rule is different for different vehicles.

The method can further include determining the allocation rule based further on a route for the vehicle to travel. The allocation rule is different for different routes.

The method can further include determining the allocation rule based further on an occupancy rate of the vehicle. The allocation rule is different for different occupancy rates.

The method can further include determining the usage rule based on the allocation rule. The usage rule is different for different allocation rules.

The method can further include receiving the request from a user device. The request specifying an identifier of the user device.

The method can further include authorizing the request based further on querying the electronic ledger to determine the identifier of the user device is an authorized identifier.

The method can further include initiating the request based on a location of the vehicle.

A system includes a computer including a processor and a memory, the memory storing instructions executable by the processor to determine a usage rule for a vehicle based on a request to access the vehicle. The usage rule specifying a number of tokens to access the vehicle. The instructions further include instructions to authorize the request based on receiving the number of tokens specified by the usage rule and store the request to an electronic ledger, actuate the vehicle based on the request being authorized, and determine an allocation rule specifying the number of tokens allocated to each of an entity and the vehicle based on the request and allocate tokens to the entity and the vehicle based on the allocation rule.

Actuating the vehicle includes operating the vehicle along a route.

The instructions can further include instructions to determine the allocation rule based further on a time of day the vehicle is operating. The allocation rule is different at different times of day.

The instructions can further include instructions to determine the allocation rule based further on an identifier for the vehicle. The allocation rule is different for different vehicles.

The instructions can further include instructions to determine the allocation rule based further on a route for the vehicle to travel. The allocation rule is different for different routes.

The instructions can further include instructions to determine the allocation rule based further on an occupancy rate of the vehicle. The allocation rule is different for different occupancy rates.

The instructions can further include instructions to determine the usage rule based on the allocation rule. The usage rule is different for different allocation rules.

The instructions can further include instructions to receive the request from a user device. The request specifying an identifier of the user device.

The instructions can further include instructions to authorize the request based further on querying the electronic ledger to determine the identifier of the user device is an authorized identifier.

The instructions can further include instructions to initiate the request based on a location of the vehicle.

Further disclosed herein is a computing device programmed to execute any of the above method steps. Yet further disclosed herein is a computer program product, including a computer readable medium storing instructions executable by a computer processor, to execute an of the above method steps.

A plurality of computers110,140generate and maintain a blockchain ledger150for managing authorized requests to access a vehicle105. Each of the plurality of computers110,140is communicatively coupled in a blockchain network111. For example, the computers110,140may be included in computing devices140external to the vehicle105and a vehicle computer110. The blockchain network111includes distributed computers110,140as a peer-to-peer network or a peer-to-peer network with a supervisory computer. The computers110,140authorized to participate in the blockchain network111are listed in the blockchain ledger150.

In this disclosure, the term “network” in the context of a blockchain means a network formed by computers110,140, i.e., a blockchain network means the computers110,140that form the blockchain, including links to each other stored by the computers110,140. On the other hand, a “network” in the context of devices communicating with each other, e.g., ECUs and/or devices communicating via a vehicle network and/or wide area network135, means a physical wired and/or wireless network comprising conventional networking hardware, media, protocols, etc.

Authorized requests to access the vehicle105can be stored as data blocks in the blockchain ledger. The blockchain ledger150is one example of an electronic ledger. An electronic ledger is a distributed database. “Distributed” in this context means that copies of the database are maintained by multiple entities with access to the electronic ledger, e.g., to verify data on the ledger, to store data to the ledger, etc. The data blocks stored within the blockchain ledger150are linked in chains by hashes.

A blockchain150is an electronic ledger maintained in each of a plurality of the computers110,140that form the blockchain network111, each storing data based on generation of hashes for blocks of data. A hash in the present context is a one-way encryption of data, i.e., a result of executing a hash function, having a fixed number of bits. An example of hash encryption is SHA-256. The hashes, i.e., results of hash functions, provide links to blocks of data by identifying locations of the block of data in storage (digital memory), for example by use of an association table mapping hashes to respective storage locations. An association table provides a mechanism for associating the hash (which may also be referred to as a hash key) with an address specifying a physical storage device either in a vehicle or a stationary location. The hash for the block of data further provides a code to verify the data to which the hash links. Upon retrieving the block of data, a computer can recompute the hash of the block of data and compare the resulting hash with the hash providing the link. In the case that the recomputed hash matches the linking hash, the computer can determine that the block of data is unchanged. Conversely, a recomputed hash that does not match the linking hash indicates that the block of data or the hash has been changed, for example through corruption or tampering. The hash providing the link to a block of data may also be referred to as a key or a hash key. An example structure of a blockchain ledger150is discussed below in reference toFIG.2.

FIG.1Ais a block diagram of an example system100that includes an instance of a blockchain ledger150hosted on at least one entity computer140and a vehicle computer110. The vehicle computer110is programmed to determine a usage rule for a vehicle105based on a request to access the vehicle105. The usage rule specifies a number of tokens to access the vehicle105. The vehicle computer110is further programmed to authorize the request based on receiving the number of tokens specified by the usage rule. The computers110,140are programmed to store the request to an electronic ledger, e.g., the blockchain ledger150. The vehicle computer110is programmed to actuate the vehicle105based on the request being authorized. The computers110,140are further programmed to determine an allocation rule specifying the number of tokens allocated to each of an entity and the vehicle105based on the request and to allocate tokens to the entity and the vehicle105based on the allocation rule.

The entity may request tokens from the vehicle computer110based on transportation services rendered by the vehicle105. For example, a vehicle computer110may receive tokens from a user to provide the user access to the vehicle105, and then the vehicle computer110may allocate a portion of the tokens to the entity, e.g., at predetermined time intervals such as once per day, week, month, etc. Herein, an “entity” is a user or users that specifies vehicle computers110that can host an instance of the blockchain ledger150. Advantageously, the computers110,140can allocate tokens for each request based on determining the applicable allocation rule stored in the electronic ledger, which allows the entity to receive the specified number of tokens without relying on the vehicle computer110to transfer the tokens at a later time.

The vehicle105includes a vehicle computer110, sensors115, actuators120, vehicle components125, and a vehicle communications bus130. Via a network135, the communications bus130allows the vehicle computer110to communicate with other computing devices.

The vehicle computer110includes a processor and a memory such as are known. The memory includes one or more forms of computer-readable media, and stores instructions executable by the vehicle computer110for performing various operations, including as disclosed herein.

The vehicle computer110may operate the vehicle105in an autonomous, a semi-autonomous mode, or a non-autonomous (or manual) mode. For purposes of this disclosure, an autonomous mode is defined as one in which each of vehicle105propulsion, braking, and steering are controlled by the vehicle computer110; in a semi-autonomous mode the vehicle computer110controls one or two of vehicles105propulsion, braking, and steering; in a non-autonomous mode a human operator controls each of vehicle105propulsion, braking, and steering.

The vehicle computer110may include programming to operate one or more of vehicle105brakes, propulsion (e.g., control of acceleration in the vehicle105by controlling one or more of an internal combustion engine, electric motor, hybrid engine, etc.), steering, transmission, climate control, interior and/or exterior lights, etc., as well as to determine whether and when the vehicle computer110, as opposed to a human operator, is to control such operations. Additionally, the vehicle computer110may be programmed to determine whether and when a human operator is to control such operations.

The vehicle computer110may include or be communicatively coupled to, e.g., via a vehicle communications network130such as a communications bus as described further below, more than one processor, e.g., included in electronic controller units (ECUs) or the like included in the vehicle105for monitoring and/or controlling various vehicle components125, e.g., a transmission controller, a brake controller, a steering controller, etc. The vehicle computer110is generally arranged for communications on a vehicle communication network that can include a bus in the vehicle105such as a controller area network (CAN) or the like, and/or other wired and/or wireless mechanisms.

Via the vehicle communications network130, the vehicle computer110may transmit messages to various devices in the vehicle105and/or receive messages (e.g., CAN messages) from the various devices, e.g., sensors115, an actuator120, ECUs, etc. Alternatively, or additionally, in cases where the vehicle computer110actually comprises a plurality of devices, the vehicle communication network130may be used for communications between devices represented as the vehicle computer110in this disclosure. Further, as mentioned below, various controllers and/or sensors115may provide data to the vehicle computer110via the vehicle communication network130.

Vehicle105sensors115may include a variety of devices such as are known to provide data to the vehicle computer110. For example, the sensors115may include Light Detection And Ranging (LIDAR) sensor(s)115, etc., disposed on a top of the vehicle105, behind a vehicle105front windshield, around the vehicle105, etc., that provide relative locations, sizes, and shapes of objects surrounding the vehicle105. As another example, one or more radar sensors115fixed to vehicle105bumpers may provide data to provide locations of the objects, second vehicles105, etc., relative to the location of the vehicle105. The sensors115may further alternatively or additionally, for example, include camera sensor(s)115, e.g. front view, side view, etc., providing images from an area surrounding the vehicle105. In the context of this disclosure, an object is a physical, i.e., material, item that can be represented by physical phenomena (e.g., light or other electromagnetic waves, or sound, etc.) detectable by sensors115. Thus, vehicles105, as well as other items including as discussed below, fall within the definition of “object” herein.

The vehicle105actuators120are implemented via circuits, chips, or other electronic and or mechanical components that can actuate various vehicle subsystems in accordance with appropriate control signals as is known. The actuators120may be used to control components125, including braking, acceleration, and steering of a vehicle105.

In the context of the present disclosure, a vehicle component125is one or more hardware components adapted to perform a mechanical or electro-mechanical function or operation—such as moving the vehicle105, slowing or stopping the vehicle105, steering the vehicle105, etc. Non-limiting examples of components125include a propulsion component (that includes, e.g., an internal combustion engine and/or an electric motor, etc.), a transmission component, a steering component (e.g., that may include one or more of a steering wheel, a steering rack, etc.), a brake component (as described below), a park assist component, an adaptive cruise control component, an adaptive steering component, a movable seat, etc.

In addition, the vehicle computer110may be configured for communicating via a vehicle-to-vehicle communication bus130or interface with devices outside of the vehicle105, e.g., through a vehicle-to-vehicle (V2V) or vehicle-to-infrastructure (V2X) wireless communications to another vehicle, and/or to other computers (typically via direct radio frequency communications). The communications bus130could include one or more mechanisms by which the computers110of vehicles105may communicate, including any desired combination of wireless (e.g., cellular, wireless, satellite, microwave and radio frequency) communication mechanisms and any desired network topology (or topologies when a plurality of communication mechanisms are utilized). Exemplary communications provided via the communications bus130include cellular, Bluetooth, IEEE 802.11, dedicated short range communications (DSRC), and/or wide area networks (WAN), including the Internet, providing data communication services.

The network135represents one or more mechanisms by which a vehicle computer110may communicate with remote computing devices. Accordingly, the network135can be one or more of various wired or wireless communication mechanisms, including any desired combination of wired (e.g., cable and fiber) and/or wireless (e.g., cellular, wireless, satellite, microwave, and radio frequency) communication mechanisms and any desired network topology (or topologies when multiple communication mechanisms are utilized). Exemplary communication networks include wireless communication networks (e.g., using Bluetooth®, Bluetooth® Low Energy (BLE), IEEE 802.11, vehicle-to-vehicle (V2V) such as Dedicated Short Range Communications (DSRC), etc.), local area networks (LAN) and/or wide area networks (WAN), including the Internet, providing data communication services.

A user device155may be programmed to transmit tokens to and/or receive tokens from one or more other computers110,140. The user device155may, for example, store tokens in a memory of the user device155.

The user device155may be programmed to transmit a request to access the vehicle105to the vehicle computer110, e.g., via the network135. For example, the user device155can receive input, e.g., via an interface, from a user specifying the request. A user device155be can be any one of a variety of computers that can be used while carried by a person, e.g., a smartphone, a tablet, a personal digital assistant, a smart watch, etc.

Typically, a request to access the vehicle105includes a request to transport a user in the vehicle105along a route. That is, the request specifies a route to transport the user in the vehicle105. Further, the route includes a specification of a time or times of day, e.g., to begin and end transportation along the route. Additionally, the request specifies an identifier for the user device155. Herein, an “identifier” is a set of data, e.g., an alphanumeric string of data, that substantially uniquely identifies a thing, e.g., a vehicle105, a user device155, an entity computer140, etc. Further, the request may, for example, specify an identifier for the vehicle105. That is, the user device155may request a specific vehicle105to transport the user along the route. Additionally, or alternatively, the user device155may initiate a request based on a location of the vehicle105relative to the user device155. For example, the user device155may initiate a request to access the vehicle105when the vehicle105is within a predetermined radius of the user device155. The user device155may detect the vehicle105within the predetermined radius by, e.g., GPS-based geo-fencing, BLE, wireless local area networks (WLAN), radio-frequency identification (RFID), etc.

The blockchain network111(as shown inFIG.1B) communicatively couples the plurality of computers110,140. In an example, the plurality of computers110,140is a peer-to-peer network, with each computer in the peer-to-peer network connected to at least one other computer. Initial computers in the plurality of computers110,140may be specified by, e.g., the vehicle105manufacturer, a government agency, etc., and may be recorded in the blockchain ledger150.

The blockchain ledger150is a distributed blockchain ledger. That is, each computer110,140stores, e.g., in a memory, one copy of the blockchain ledger150. The computers110,140may, for example, receive data blocks from other computers110,140and may upload the data blocks to their respective copies of the blockchain ledger150, i.e., store the respective data blocks in respective storage locations in their respective blockchain ledgers150such that each data block is linked to one respective previous data block. The data blocks may be generated based on requests, which may be submitted, for example, from a user device155. Each computer110,140can compare its stored blockchain data, i.e., linked data blocks, to blockchains stored by other computers110,140to verify the data blocks. For example, each computer110,140can generate a hash based on the data stored in a respective data block of a blockchain stored by another computer110,140. In the case the hash generated by one computer110,140matches the hash stored by the other computers110,140for the respective data block, the one computer110,140determines the data block is verified.

The plurality of computers110,140maintains the blockchain ledger150. That is, the plurality of computers110,140may receive requests from time to time to add a computer to the plurality of computers110,140. The computer may be, for example, from another vehicle105, a computer external to the vehicle105, etc. The computers110,140in the plurality of computers110,140evaluate the request. In case that the request is approved, the plurality of computers110,140adds the computer to the plurality of computers110,140and adds a data block to the blockchain ledger150recording the addition.

Additionally, or alternatively, the plurality of computers110,140may receive requests to access the vehicle105from a user device155. The computers110,140in the plurality of computers110,140evaluate the request, as described below. In the case that the request is approved, each of the plurality of computers110,140adds a data block to the blockchain ledger150recording the authorization.

Each computer110,140stores one copy of the blockchain ledger150. The computers110,140can be accessed via the communications network135. The computers110,140may be associated with an entity that participates in maintaining the blockchain ledger150, e.g., to verify data in the blockchain ledger150, to store data on the blockchain ledger150, etc. For example, the computers110,140may be computing devices external to the vehicle105, e.g., an entity computer140, and computing devices internal to the vehicle105, e.g., the vehicle computer110.

The vehicle computer110may be programmed to transmit tokens to and/or receive tokens from one or more other computers110,140. The vehicle computer110may, for example, store tokens in a memory of the vehicle computer110.

The vehicle computer110is programmed to receive, e.g., via the network135, a request from a user device155. Upon the computers110,140authorizing the request (as described below), the vehicle computer110is programmed to actuate the vehicle105. For example, the vehicle computer110may be programmed to actuate one or more vehicle components125, e.g., locks, doors, etc., to allow the user to access the vehicle105. Additionally, the vehicle computer110may actuate vehicle components125, e.g., at least one of a brake, a steering, and a propulsion, to operate the vehicle105along the route specified by the request.

The vehicle computer110can store, e.g., in a memory, a usage rule. Herein, a “usage rule” is a specification of a number of tokens (the number can be one or more) required to access the vehicle105to transport the user along the route. In the present context, a “token” is data that represents a number of units of an object and is transferrable on the blockchain. The unit can be, for example, a unit of currency money, e.g., 0.01 cents, 0.1 cents, 1 cent, a unit of virtual currency (or faction thereof), etc., an amount of an object, e.g., size or weight, of a raw material object, e.g., 1 gram of gold or silver, 1 foot of lumber, etc. Upon receiving the request to access the vehicle105from the user device155, the vehicle computer110may be programmed to transmit the usage rule to the user device155.

The usage rule is typically determined by the vehicle105according to an algorithm or formula that determines the number of tokens according to one or more measurements, e.g., a distance traveled, an elapsed time to travel a route, etc. The usage rule, as stated above, specifies a predetermined number of one or more tokens required to access the vehicle105to transport the user along the route. A usage rule is typically specified for each vehicle105, and therefore typically includes an identifier of the vehicle105. The usage rule may, for example, be determined based on the route. For example, the usage rule may specify one or more tokens based on a distance travelled along the route, e.g., a number of tokens for every mile travelled, as shown in Equation 1 below.
Ta=TrdEquation 1
Wherein “Ta” is the number of tokens to access the vehicle105, “Tr” is the rate of tokens per unit of distance, and “d” is the distance, e.g., in miles, along the route the vehicle105transports the user.

As another example, the usage rule may specify an expenditure of one or more tokens based on the duration the vehicle105is travelling along the route, i.e., a rate of token expenditure per unit of time, e.g., five tokens expended for every ten minutes (or fraction thereof), as shown in Equation 2 below.
Ta=ErtEquation 2
Wherein “Ta” is the number of tokens to access the vehicle105and “t” is the duration of time, e.g., in minutes, the vehicle105is transporting the user along the route, and “Er” is the rate of token expenditure per unit of time.

As yet another example, the usage rule may be determined based on the allocation rule. That is, the usage rule may be different for different allocation rules, e.g., may specify that the number of tokens in some percentage or ratio, e.g., expressed as a weight w, of a number of tokens to be allocated to an entity, as shown in Equation 3 below.
Ta=wTeEquation 3
Wherein “Ta” is the number of tokens to access the vehicle105and “Te” is the number of tokens allocated to the entity based on the applicable allocation rule, and w is the weight, or ratio, e.g., 0.8, 1.2, 1.5, etc. For example, in the case the allocation rule specifies, e.g., ten tokens, be allocated to the entity, the usage rule may specify, e.g., twelve tokens, to access the vehicle105, as compared to the case where the allocation rule specifies, e.g., five tokens, be allocated to the entity, the usage rule may specify, e.g., six tokens, to access the vehicle105.

The entity computer140is a computing device including a processor and a memory as are known. The entity computer140may be maintained by an entity, e.g., a government agency. The entity computer140may transmit tokens to and/or receive tokens from one or more other computers110,140. The entity computer140may, for example, store tokens in a memory of the entity computer140.

The computers110,140can store an allocation rule to the blockchain ledger150. Herein, an “allocation rule” is a specification of numbers of tokens (the number can be a fraction of one, or one or more) to be distributed to the entity and the vehicle105for the vehicle105transporting the user along the route. The computers110,140can store one or more allocation rules in the blockchain ledger150. The computers110,140may determine the applicable allocation rule for a request by querying the blockchain ledger150. The allocation rule identifies each computer110,140that receives tokens from the user device155upon authorization of the request, and further specifies a number, percentage, or fraction of the token(s) allocated to the entity and the vehicle105. For example, the allocation rule may specify that four of five tokens received for transporting the user are allocated to the vehicle105and the other of the five tokens is allocated to the entity.

The allocation rule is typically determined by an entity and the vehicle105owner. For example, a user representing the entity and the vehicle105owner can input the allocation rule into the respective computer110,140. In such an example, the entity computer140and the vehicle computer110can transmit the allocation rule to each other and/or one or more other computers140. The computers110,140can compare the allocation rules transmitted by each of the entity computer140and the vehicle computer110. In the case that the allocation rules match, i.e., specify the same allocation of tokens to the vehicle computer110and the entity computer140, respectively, the computers110,140can authorize the allocation rule and store the allocation rule to the blockchain ledger150. In the case that the allocation rules do not match, the computers110,140can reject the allocation rule.

The allocation rule typically includes an identifier for the vehicle105, i.e., specifies a vehicle105to which the allocation rule applies. The allocation rule may, for example, be based on the identifier of the vehicle105. That is, the allocation rule may be different for different vehicles105. For example, the allocation rule for a user being transported by a bus may be different than the allocation rule for a user being transported by a personal vehicle105. For example, the allocation rule for a user being transported by bus could specify that four of five usage tokens are allocated to the bus, and the allocation rule for a user being transported by a personal vehicle105could specify that three of five usage tokens are allocated to the personal vehicle105.

Additionally, or alternatively, the allocation rule may be based on a time of day at which the vehicle105is operating. That is, the allocation rule may be different at different times of day. For example, the allocation rule may specify two of five tokens are allocated to the vehicle105during heavy traffic periods, e.g., from 7 a.m. to 9 a.m. and 3 p.m. to 6 p.m., and four of five tokens are allocated to the vehicle105during the other times of the day (with the remaining token(s) in each instance being allocated to the entity).

Additionally, or alternatively, the allocation rule may be based on the route along which the vehicle105travels. That is, the allocation rule may be different for different routes. For example, the allocation rule may specify three of five tokens are allocated to the vehicle105transporting the user in a city, and four of five tokens are allocated to the vehicle105transporting the user outside of the city (with the remaining token(s) in each instance being allocated to the entity). As another example, the allocation rule may specify three of five tokens are allocated to the vehicle105travelling on residential roads, and four of five tokens are allocated to the vehicle105travelling on freeways (with the remaining token(s) in each instance being allocated to the entity). As another example, the allocation rule may specify three of five tokens are allocated to the vehicle105for transporting the user less than, e.g., two miles, and four of five tokens are allocated to the vehicle105transporting the user more than, e.g., two miles (with the remaining token(s) in each instance being allocated to the entity).

Additionally, or alternatively, the allocation rule may be based on data received from a device, e.g., a vehicle sensor115, a server, a computer external to the vehicle105, etc., on a vehicle communications bus130. That is, the allocation rule may be different based on the data received on the vehicle communications bus130. As an example, the allocation rule may be based on the occupancy rate of the vehicle105. That is, the allocation rule may be different for different occupancy rates of the vehicle105. The occupancy rate is the number of vacant seats in the vehicle105divided by the total number of seats in the vehicle105. For example, the allocation rule may specify that four of five tokens are allocated to the vehicle105with an occupancy rate above eighty percent, and three of five tokens are allocated to the vehicle105with an occupancy rate below eighty percent (with the remaining token(s) in each instance being allocated to the entity). The total number of seats in the vehicle105may be stored in a memory of the vehicle computer110. The number of vacant seats may be determined based on sensor115data, e.g., an image of the cabin of the vehicle105when the vehicle computer110receives the request from the user device155. As another example, the vehicle computer110may receive, e.g., traffic data, weather data, road construction data, etc., via the vehicle communications bus130. The allocation rule may, for example, specify a two of five tokens are allocated to the vehicle105during heavy precipitation, and may specify one of five tokens are allocated to the vehicle105operating in a road construction zone (with the remaining token(s) in each instance being allocated to the entity).

As one example, the allocation rule can specify a number of tokens Teallocated to the entity based on Equation 4 below.
Te=Trd+Ttdh+TorEquation 4
Wherein “d” is the distance, e.g., in miles, the vehicle105transports the user along the route, “Tr” is the rate of tokens per unit of distance, “h” is the time of day of operation, “Tv” is a second rate of tokens per unit of distance, “To” is a number of tokens, and “r” is the occupancy rate of the vehicle105. In such an example, “h” is a binary value, e.g., 0 or 1. For example, in the case that the time of day of operation is during heavy traffic periods, “h” is 1. Otherwise, “h” is 0. Additionally, “r” may be a binary value, e.g., 0 or 1. For example, in the case that the occupancy rate is above a threshold value, e.g., eighty percent, “r” is 0. Otherwise, “r” is 1. As another example, “r” may be the numerical value of the occupancy rate of the vehicle105, e.g., 0.5.

Additionally, the allocation rule can specify the number of tokens Tvallocated to the vehicle105based on Equation 5 below.
Tv=Ta−TeEquation 5
Wherein “Ta” is the number of tokens to access the vehicle105based on the applicable usage rule and “Te” is the number of tokens allocated to the entity based on the applicable allocation rule.

The computers110,140are programmed to allocate tokens to the entity and the vehicle105based on the applicable allocation rule. Upon the vehicle computer110authorizing the request, the user device155allocates, i.e., assigns, the number of tokens specified by the allocation rule to the vehicle computer110and the entity computer140identified by the allocation rule.

The computers110,140are programmed to vote to accept or reject the request to access the vehicle105. The result of the vote may be based on a majority of the computers110,140in the plurality of computers110,140. Further, the result of the vote may be based on a weighted majority wherein each of the computers110,140are assigned weights. Each computer110,140may be allotted a vote with a predetermined weight (for example, stored in memory by the device manufacturer, or for aftermarket devices, stored in memory when the aftermarket device is added to the blockchain ledger150). The weight may be predetermined, for example, based on the entity associated with the computers110,140. As an example, the entity computer140may have a higher predetermined weight than the vehicle computer110.

The computers110,140may evaluate the request and determine whether to accept or reject the request, i.e., how to vote on the request. The computers110,140perform the evaluation based on one or more criteria. A first criterion may be whether the vehicle105is an authorized vehicle. For example, the blockchain ledger150may store identifiers of authorized vehicles. Upon receiving the response from the vehicle105accepting the request, the computers110,140may query the electronic ledger to determine whether the identifier of the vehicle105matches an identifier of an authorized vehicle. In the case the identifier of the vehicle105matches an identifier of an authorized vehicle, the computers110,140determine the vehicle105is an authorized vehicle.

Additionally, or alternatively, other criteria may include whether the user has enough tokens. For example, the user device155then can transmit data identifying the number of tokens allocated to the user, i.e., stored in a memory of the user device155, and the computers110,140can compare the data to the token(s) specified in the applicable usage rule. The computers110,140can accept the request when the user's available tokens meet or exceed the token(s) specified in the usage rule. Conversely, the computers110,140serve to reject the request when the user tokens are below the token(s) specified in the usage rule.

Additionally, or alternatively, other criteria may include the presence or absence of available occupancy in the vehicle105. For example, the computers110,140can accept the request when the vehicle105has available occupancy to transport the user. Conversely, the computers110,140can reject the request when the vehicle105lacks available occupancy to transport the user.

Additionally, or alternatively, other criteria may be used to evaluate the request to determine whether to vote positively or negatively with respect to granting requested authorization. For example, the computers110,140may maintain a list of identifiers of user devices155that can be authorized. The computers110,140may require that an identifier be supplied by a user device155requesting access that appears on the list of identifiers that can be authorized and only accept requests from user devices155that supply such an identifier. That is, the computers110,140may querying the blockchain ledger150to determine the identifier of the user device155is an authorized identifier. In a case that one or more of the criteria for acceptance by the computers110,140are not met, the computers110,140will vote to reject the request.

FIG.2is an example of a blockchain200such as may be used for the blockchain ledger150. The blockchain200includes a zero data block202, a first data block206, a second data block210and a nth data block214. The blocks are organized in a chain. The zero data block202is at a first, beginning end of the chain. The first data block206is linked to the zero data block202. The second data block210is linked to the first data block206. Each successive data block is linked to the previous data block. The nth data block214, at a second end of the chain, is linked to the (n−1)th data block (not shown).

Each block includes a data portion and a linking portion as shown in Table 1.

The data portion203,207,211,215includes data to be stored in the data block. The linking portion204,208,212,216includes a link to the data portion, and, except for the zero data block, includes a link to the previous data block in the chain. For example, in the first data block206, the data portion207stores data. The linking portion208includes a link “block 1 data link” that provides a link to the data portion207. The linking portion208further includes a link “backward link to block 0” that provides a link to the linking portion of data block 0.

FIG.3is a diagram of an example process300for authorizing access to a vehicle105. The process begins in a block305.

In the block305, the vehicle computer110receives a request from a user device155for a user to access the vehicle105. For example, the user can input a request to the user device155, e.g., via an interface, and the user device155can transmit the request to the vehicle computer110, e.g., via the network135. As another example, the user device155can initiate the request based on, e.g., a location of a vehicle105relative to the user device155. The request includes an identifier of the user device155and a route, as described above. Alternatively, the entity computer140can receive a request from the user device155and then can transmit the request to the vehicle computer110. The process300continues in a block310.

In the block310, the vehicle computer110determines whether the user device155is authorized. The blockchain ledger150may store authorized identifiers that specifies user devices authorized to access the vehicle105. The vehicle computer110may query the blockchain ledger150to determine whether the identifier of the user device155matches an authorized identifier. In the case the identifier of the user device155matches the authorized identifier, the vehicle computer110determines user device155is authorized to access the vehicle105. Conversely, in the case the identifier of the user device155does not match the authorized identifier, the vehicle computer110determines the user device155is not authorized to access the vehicle105. Alternatively, the entity computer140can determine whether the user device155is authorized and then transmit a message to the vehicle computer110indicating whether the user device155is authorized. In the case the user device155is authorized, the process300continues in a block315. Otherwise, the vehicle computer110rejects the request and the process300returns to the block305.

In the block315, the vehicle computer110determines the allocation rule. For example, one or more allocation rules, as described above, may be stored in the blockchain ledger150, and the vehicle computer110may be programmed to query the blockchain ledger150for the applicable allocation rule based on the request. The vehicle computer110may query the blockchain ledger150based on one or more criteria, e.g., a time of day, an identifier for the vehicle, a route for the vehicle, a number of passengers, etc., as described above. The vehicle computer110provides the allocation rule that matches the one or more criteria to the user device155. Alternatively, the entity computer140can determine the allocation rule and provide the allocation rule to the user device155. The process300continues in a block320.

In the block320, the vehicle computer110determines the usage rule. For example, the vehicle computer110can store one or more usage rules, e.g., in a memory. As one example, the vehicle computer110can determine the applicable usage rule based on the allocation rule. As another example, the vehicle computer110can determine the applicable usage rule based on, e.g., a distance travelled along the route, a duration of time expended along the route, etc. The vehicle computer110can then transmit the usage rule to the user device155. Alternatively, one or more usage rules may be stored in the blockchain ledger150. In these circumstances, the vehicle computer110may be programmed to query the blockchain ledger150to determine the applicable usage rule based on, e.g., the allocation rule, the identifier of the vehicle105, the route, etc. The process300continues in a block325.

In the block325, the user device155transmits a message to at least one of the vehicle computer110and the entity computer140. The message indicates a number of tokens stored in a memory of the user device155. The respective computer110,140, determines the number of tokens stored in the user device155based on the message. The process300continues in a block330.

In the block330, the computers110,140vote to authorize or reject the request to access the vehicle105. For example, in the case that the number of tokens stored by the user device155meets or exceeds the number of tokens specified by the usage rule, the computers110,140vote to authorize the request for the user device155to access the vehicle105. In the case that the number of tokens stored by the user device155is below than the number of tokens specified by the usage, the computers110,140vote to reject the request for the user device155to access the vehicle105. The vehicle computer110receives the votes from the other computers140and then determines whether the request is authorized based on the number of votes authorizing the request to access the vehicle105. The result of the vote may be based on e.g., a majority of the computers110,140, i.e., a consensus protocol, a weighted majority vote with each computer110,140assigned a weight, etc., as described above. In the case that the request is authorized, the process300continues in a block335. Otherwise, the process300ends.

In the block335, the vehicle computer110is programmed to provide the user device155access to the vehicle105. For example, the vehicle computer110may be programmed to actuate one or more vehicle components125, e.g., doors, locks, etc., to allow the user to physically access the vehicle105. The vehicle computer110may be programmed to actuate one or more vehicle components125to operate the vehicle105along the route, e.g., specified by the request. The process300continues in a block340.

In the block340, the user device155allocates the tokens based on the applicable allocation rule. That is, the user device155transmits the specified number of tokens to the entity computer140and the vehicle computer110, respectively. In this situation, the number of tokens stored in the memory of the user device155is decrease according to the usage rule. Additionally, the number of tokens stored in the respective memories of the entity computer140and the vehicle computer110are increased according to the allocation rule. The process300continues in a block345.

In the block345, the blockchain ledger150is modified. Typically, each computer110,140modifies the respective copy of the blockchain ledger150stored in the memory of the computer110,140. For example, each computer110,140may add a data block to the respective copy of the blockchain ledger150. The added data block can include a data portion including an identifier for the user device155, an identifier for the vehicle105, an identifier for the entity, the request is authorized, the number of tokens allocated to each of the entity and the vehicle105, and a route along which the vehicle105transports the user. The data block can further include a linking portion including a link to the data portion, and a link to the most recent previous block added to the blockchain ledger150. Following addition of the data block to the blockchain ledger150, the process300ends.

With regard to the media, processes, systems, methods, heuristics, etc. described herein, it should be understood that, although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes may be practiced with the described steps performed in an order other than the order described herein. It further should be understood that certain steps may be performed simultaneously, that other steps may be added, or that certain steps described herein may be omitted. In other words, the descriptions of processes herein are provided for the purpose of illustrating certain embodiments and should in no way be construed so as to limit the claims.