Patent Description:
To ensure compliance with these safety regulations, the FMCSA also requires drivers to keep Hours of Services (HOS) records, i.e., detailed written records of the number of hours driving, on-duty but not driving, resting, and off-duty. Drivers must provide daily updates, detailing the number of hours spent in each of the four categories mentioned above. Instead of a traditional log book, modern carriers use Electronic Logging Device (ELD) systems to automatically record the amount of time spent driving the vehicle.

Federal officials periodically inspect driver logbooks or ELD system data at weigh stations and other locations to certify that they have been kept up-to-date by the driver, and that the driver is following the FMCSA mandated regulations. If a driver is found to be out of compliance with the FMCSA regulations, they will not be permitted to continue driving until the proper amount of off-duty or rest time has elapsed. This results in late deliveries to customers and general inefficiency for the driver's employer. The driver is also penalized because the mandated "rest" time affects the hours that he/she is able to work. If a number of violations occur over a given time period, substantial fines may be levied against the driver and/or employers.

<CIT> discloses a blockchain of transactions may be used for various purposes and may be later accessed by interested parties for ledger verification. One example method of operation may include one or more of monitoring one or more applications to identify application events, identifying one or more application events, determining a hash of a log message payload associated with the application events and logging the hash of the log message payload in a blockchain.

<CIT> discloses techniques for collection and processing of motor vehicle telematics data and establishing control over access to the telematics data are disclosed herein. In an example, a communication device (e.g., a computing device) operated by an owner or operator of a motor vehicle operates to receive telematics data from a telematics system, generate and transmit a derived indication of the telematics data (e.g., using a hash of the data), receive and process a request for information from the telematics data, and generate and transmit an answer and proof of the answer validity in response to the request for information. In an example, the proof of the answer validity may be provided as a zero knowledge proof. The proof may be verified using the derived indication of the telematics data, such as from an indication that is stored in a public distributed block-chain that is auditable and unalterable.

Thus, improvements in ELD systems are desired.

The invention is defined by the accompanying claims and the following presents a simplified summary of one or more aspects of the present disclosure in order to provide a basic understanding of such aspects. Its sole purpose is to present some concepts of one or more aspects of the present disclosure in a simplified form as a prelude to the more detailed description that is presented later.

The present disclosure relates to an improved ELD system, which ensures the hours-of-service records are distributed between vehicles, the centralized database warehousing the records, roadside inspectors (e.g., stationed at weigh stations), and the government regulators (e.g., FMCSA) in a way that is highly secure and tamperproof.

Thus, in accordance with aspects of the present disclosure, a method and system of recording driver log information in a distributed ledger is disclosed. In an example, a transport log system includes a processing system for: receiving driver log information associated with one or more drivers respectively corresponding to one or more vehicles, wherein the driver log information contains hours-of-service data associated with the driver; generating a blockchain transaction data structure containing the hours-of-service data; and publishing the blockchain transaction data structure to a blockchain network, wherein the transport driver log system is a node within the blockchain network.

To the accomplishment of the foregoing and related ends, the one or more aspects of the present disclosure comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects of the present disclosure. These features are indicative, however, of but a few of the various ways in which the principles of various aspects of the present disclosure may be employed, and this description is intended to include all such aspects and their equivalents.

The disclosed aspects of the present disclosure will hereinafter be described in conjunction with the appended drawings, provided to illustrate and not to limit the disclosed aspects, wherein like designations denote like elements, where a dashed line may indicate an optional element or action, and in which:.

As discussed above, data authenticity and security of driver log information is an issue in the trucking industry. To address such issues, present disclosure provides techniques for recording and publishing electronic information associated with driving activities (e.g., driver log information) obtained from the one or more electronic logging devices (ELD) associated with one or more vehicles to a distributed data ledger or blockchain.

One example of an ELD may be Intelligent Vehicle Gateway (IVG) by Omnitracs Inc. or any mobile computing platform capable of tracking hours of service data.

Particularly, in accordance with government regulations, drivers are required to maintain accurate record of their driving activities (e.g., how much and how often a truck driver may drive). To this end, electronic logging systems for tracking, managing and maintaining driver log information for a fleet of portable assets have been developed. These electronic logging systems may assist a fleet operator and/or truck driver to accurately maintain driver logs that may identify, for example, time periods when the driver is on-duty and driving, on-duty but not driving, off-duty, and resting/sleeping, referred to herein as driver log information. In some aspects, ELD devices located in a cab and/or trailer of a vehicle transporting a portable asset may aid the truck driver in managing the driver log information. In some examples, the ELD device may offer a user interface to the truck driver to allow the truck driver to enter and/or track the required driver log information to record the driver activity. Additionally or alternatively, the ELD device may automatically measure or determine at least a portion of the driver log information (e.g., on-duty and driving, on-duty but not driving, off-duty, and resting/sleeping), for example, based on an initial driver entered indication and maintaining a timer, and/or based on a number of sensors that collect and report vehicle performance data to the ELD.

Aspects of the present disclosure provide a new, secure manner to record and publish driver log information in contrast to traditional centralized databases and data warehouses. In particular, the present disclosure includes a blockchain network having a plurality of nodes, some of which may be the ELDs themselves, which use cryptographic techniques to manage a distributed ledger or blockchain of driver log information. The blockchain of driver log information may be more resistant to modification, corruption, or loss of the driver log information than a traditional, centralized database of driver log information. As a result, a blockchain of driver log information may be a more reliable source of information that is the subject to government regulation and scrutiny, such as during logbook audits at weigh stations. Moreover, the blockchain of driver log information provides a decentralized source for the driver log information with increased availability when compared to databases, which can be single points of failure.

Various aspects are now described in more detail with reference to the <FIG>. Additionally, the term "component" as used herein may be one of the parts that make up a system, may be hardware, firmware, and/or software stored on a computer-readable medium, and may be divided into other components.

Referring to <FIG>, in an aspect, a system <NUM> includes modules for collecting, analyzing and presenting fleet and/or driver management or performance data, including a blockchain node module <NUM> configured to publish driver log information <NUM> received from one or more driver log modules <NUM> associated with one or more vehicles <NUM> to a blockchain network <NUM>. As used herein, the terms "module(s)" may be one of the parts that make up a device, may be hardware or software or firmware, and may be divided into other modules and/or distributed across one or more processors.

In an aspect, system <NUM> can comprise a blockchain network <NUM> configured to communicate with one or more vehicles <NUM> via a ELD <NUM> located on each vehicle <NUM> or associated with each driver of each vehicle <NUM>. The system <NUM> may include one or more fleets of vehicles <NUM>, each fleet having at least one vehicle. Typically, a fleet could include many tens, hundreds or thousands of vehicles. An example fleet <NUM> is illustrated as having two vehicles <NUM>. Additional fleets (not shown) are contemplated, but not shown. In implementations, each ELD <NUM> is configured to collect and transmit data associated with the driver and/or the operation of the vehicle <NUM> to the blockchain network <NUM>. Also, in some implementations, ELD <NUM> can be configured to perform calculations associated with one or more fleet and/or driver management or performance module(s) <NUM> using any of the collected data. In an aspect, fleet and/or driver management or performance module(s) <NUM> may be implemented as a software application defined by code or instructions stored in a computer-readable medium and executed by a processor, and/or as hardware (e.g., a specially programmed processor module), and/or as firmware. According to the present aspects, one of the fleet and/or driver management or performance module(s) <NUM> may include driver log module <NUM>, also referred to as an "Hours of Service module," which is configured to collect driver log information <NUM>, and a blockchain node module <NUM> configured to transmit the driver log information <NUM> to the blockchain network <NUM>, as will be discussed in more detail below.

In some implementations, ELD <NUM> may include a processor configured to execute one or more fleet and/or driver management or performance modules <NUM>, one or more transceivers to perform associated communications with external devices such as the blockchain network <NUM> via a communication network, and a memory configured to store computer-readable code that may define all or part of the modules <NUM> and also to store data associated with the components <NUM> and/or ELD <NUM>. ELD <NUM> may also include a user interface or display, a mobile application server, and a communications module (e.g., including the one or more transceivers, and one or more of terrestrial and Wi-Fi modems, one or more antennae, a GPS module, and a satellite communications module). For example, in an aspect, ELD <NUM> may include, but is not limited to, the Intelligent Vehicle Gateway (IVG) platform sold by OMNITRACS LLC of Dallas, Texas, which may include fleet and/or driver management or performance modules <NUM> such as, but not limited to, a driver log module <NUM>, an Analytics Manager module, a Critical Event Reporting module, a Driver Workflow module, an Extended Productivity Suite module, a Fault Monitoring module, an In-Cab Navigation module, an In-Cab Scanning module, an In-Cab Video Training module, a Media Manager module, a Performance Monitoring module with a Fuel Manager module, a Predictive Performance Service module, a Trip Manager module, a Vehicle Maintenance and Inspection Reporting module, a Web Browsing module, and a Telematics module.

As an example only, each vehicle <NUM> may be in bi-directional communication with at least one node of the blockchain network <NUM> over at least one communication channel. In the example shown in <FIG>, each vehicle <NUM> is in bi-directional communication with the blockchain network <NUM> over at least one of a satellite-based communication system <NUM> and a terrestrial-based system <NUM> (e.g., a wireless communication system using a communication protocol/technology such as, but not limited to, <NUM> or New Radio (NR), GSM, CDMA, TDMA, WCDMA, EDGE, OFDM, GPRS, EV-DO, LTE, WiFi, Bluetooth, or, when the vehicle is stopped, via a wired connection <NUM> through the Internet). Depending on many factors, data may be exchanged with the vehicles <NUM> using one or both of the satellite communication system <NUM> and the terrestrial-based communication system <NUM>.

In an aspect, many different types of data are collected and transmitted from the vehicles <NUM> to the blockchain network <NUM> Examples of such data include, but are not limited to, driver performance data, driver duty status such as driver log information <NUM>, truck performance data, critical events, messaging and position data, location delivery data, telematics data, and other types of data. As noted, the data associated with the operation of the vehicle <NUM> may further include driver log information <NUM> collected by the driver log module <NUM>. In some examples, the driver log module <NUM> may employ the user interface or display of the ELD <NUM> to allow a truck driver, for example, to enter relevant driver log information <NUM> (e.g., on-duty and driving, on-duty but not driving, off-duty, resting/sleeping, etc.) for one or more sampled time points into the ELD <NUM>. For instance, the driver may provide an entry upon a change in driver log information <NUM> (e.g., a change in a driver state from one to another of on-duty and driving, on-duty but not driving, off-duty, resting/sleeping, etc.), and driver log module <NUM> may include a timer that maintains a history of how long the driver was in each driver state. For instance, in one example that should not be construed as limiting, each driver state recorded in the driver log information <NUM> may be represented by a log code (e.g., code having a value of: <NUM> = off duty, <NUM> = sleeping, <NUM> = driving, <NUM> = on duty but not driving, <NUM> = yards moved, <NUM> = personal conveyance), and driver log module <NUM> may track which log code applies to the driver for each sampled time point, such as, for example, for each minute of the day. As such, in one non-limiting example, driver log module <NUM> may track the driver log information <NUM> in a manner that represents the <NUM> hours in a driver's day as a sequence of <NUM> codes, where the sequence corresponds to some combination or sequence of different log code values (e.g., <NUM> = off duty, <NUM> = sleeping, <NUM> = driving, <NUM> = on duty but not driving, <NUM> = yards moved, <NUM> = personal conveyance).

According to an exemplary aspect, rather than use a single data repository that receives all data that is exchanged with the vehicles <NUM>, aspects of the present disclosure use a blockchain network <NUM> which is a distributed peer-to-peer network formed from a plurality of nodes <NUM> or computing devices, that collectively maintain a distributed ledger, also referred to as a blockchain <NUM>. The blockchain <NUM> is a continuously-growing list of data records hardened against tampering and revision using cryptography and is composed of data structure blocks that hold the data received from other nodes (e.g., ELDs <NUM>). The nodes <NUM> of the blockchain network <NUM> may include one or more back-end servers, such as those maintained in a data center <NUM>, and other computing devices. Although depicted in <FIG> as separate from the blockchain network <NUM>, the ELDs <NUM> within the vehicles <NUM> may themselves be nodes <NUM> of the blockchain network. The nodes <NUM> of the blockchain network <NUM> may also include terminals, computers, and servers located at weigh stations used to audit driver log information, as well as servers managed by regulatory organizations (FMCSA).

In one aspect, the blockchain node module <NUM> of the ELD may be configured to generate and transmit a transaction data structure <NUM> containing data values related to driver log information to the blockchain network <NUM>, and a node in the blockchain network <NUM> records and confirms when and in what sequence the data transactions enter and are logged in the existing blockchain. Every node <NUM> in the decentralized system can have a copy of the growing blockchain <NUM>, avoiding the need to have a centralized data store managed by a trusted third party. Moreover, each of the nodes <NUM> can validate the data, add hash values to their copy of the blockchain <NUM>, and then broadcast these additions to other nodes in accordance with blockchain-related methodologies. In some aspects, the blockchain network <NUM> may be comprised of a mixture of "full" nodes and "partial" nodes. Full nodes may process the full blockchain and are validating and enforcing data integrity of the blockchain on a regular basis. Partial nodes, in contrast, are configured to interact with the blockchain in a lightweight manner, for example, by downloading block headers, and verifying only a small portion of what needs to be verified, using a distributed hash table as a database for trie nodes in place of its local hard drive. In one aspect, the ELDs <NUM> may be configured as partial nodes of the blockchain network, while other designated servers in the system <NUM> may be configured as full nodes.

In one aspect, the blockchain node module <NUM> of the ELD may be configured to manage the driver log information by maintaining a set of private and public encryption key pairs tied to the driver, and create and sign blockchain transactions involving the driver log information using those encryption keys. The holder of the private encryption key (e.g., the ELD) is able to sign records of driver log information, which are then put into force by being permanently recorded in the blockchain <NUM>.

All of the information that is communicated to and from the vehicles <NUM> may be published to the blockchain network <NUM>. In some aspects, the collected information (e.g., driver log information <NUM>) may periodically (e.g., every x minutes, where x is a whole number, or once a day, or upon availability of a wired or wireless connection) be transmitted from the ELD <NUM> to the blockchain network <NUM> for record keeping.

In one aspect, one of the fleet and/or driver management or performance module(s) <NUM> may include a blockchain node module <NUM> configured to receive the driver log information <NUM> associated with one or more drivers respectively corresponding to one or more vehicles <NUM>, which contains hours-of-service data associated with the driver. As described in greater detail below, the blockchain node module <NUM> may generate a blockchain transaction data structure that contains the hours-of-service data, and publishes the blockchain transaction data structure to the blockchain network <NUM>.

The system <NUM> also includes a data center <NUM>, which may be part of or in communication with the blockchain network <NUM>. The data center <NUM> illustrates one possible implementation of one or more node(s) <NUM> for storing all of the data received from each of the vehicles <NUM>. As an example, as mentioned above many different types of data are transmitted from the vehicles <NUM> to the data center <NUM>. In the case where data center <NUM> is in communication with other nodes of the blockchain network <NUM>, the data may be transmitted via connection <NUM> to the data center <NUM>. The connection <NUM> may comprise any wired or wireless dedicated connection, a broadband connection, or any other communication channel configured to transport the data. In an aspect, the data center <NUM> may include a processor, memory including volatile and non-volatile memory, specially-programmed operational software, a communication bus, an input/output mechanism, and other operational systems.

In an aspect, the data center <NUM> may include its own blockchain node module <NUM> for interacting with the other nodes of the blockchain network to maintain the blockchain ledger, as well as receive and verify published driver log data. In an aspect, the data center <NUM> may include a driver log report module <NUM> configured to retrieve and analyze driver log data from the blockchain (e.g., using the blockchain node module <NUM>) and generate fleet and/or driver management or performance metrics. According to the present aspects, the driver log report module <NUM> may aid in determining compliance with transportation regulations that govern drivers' hours-of-service based on driver log information <NUM> collected from driver log module <NUM> and the blockchain. The driver log report module <NUM> may capture, manipulate, and provide this information in a usable format, for example, over connection <NUM> for output on a display or printer associated with a terminal device <NUM>. The terminal device <NUM> can be a user interface portal, a web-based interface, a personal computer (PC), a laptop, a personal data assistant (PDA), a dedicated terminal, a dumb terminal, or any other device over which a user <NUM> (e.g., a manager or operator responsible for monitoring a fleet <NUM> of vehicles <NUM>; or a vehicle inspector at a weigh station) can view the display or receive a printed report provided by driver log report module <NUM>.

It should be noted that the example implementation illustrated in <FIG> should not be construed as limiting, as one of skill in the art may modify this implementation and achieve similar results. For instance, rather than the illustrated modules and described functionality for publishing blockchain transactions containing driver log information <NUM> directly to the blockchain network from an ELD <NUM>, the functionality described herein may instead be implemented by an intermediary publishing node (e.g., executing in a data center <NUM>) which receives driver data from the ELDs <NUM> and handles the blockchain-related tasks of verifying blockchain records.

Referring to <FIG>, an example of one implementation of a method <NUM> for processing and storing driver log information <NUM> in accordance with the present disclosure includes an interaction between a data center <NUM> and at least one designated ELD <NUM> associated with at least one vehicle <NUM> and at least one driver. In some aspects, the ELD(s) <NUM> may include driver log module <NUM> for collecting driver log information <NUM>. Although the illustrated example shows the interaction between the blockchain node module <NUM> and the ELD <NUM>, it should be understood that the blockchain node module <NUM> is not limited to receiving the driver log information <NUM> from the ELD <NUM> exclusively and may receive driver log information <NUM> from other blockchain nodes <NUM> as part of the distributed ledge operations. As discussed above, and referring for example to <FIG>, one example of driver log information <NUM> includes a combination or sequence of log codes <NUM>, where the value of each log code <NUM> represents a driver state (e.g., log code <NUM> having a value of: <NUM> = off duty, <NUM> = sleeping, <NUM> = driving, <NUM> = on duty but not driving, <NUM> = yards moved, <NUM> = personal conveyance) for an amount of time associated with each log code <NUM> (e.g., <NUM> log code/minute). So, for example, driver log module <NUM> may track which log code <NUM> applies to the driver for, for example, each minute of the day. As such, in one non-limiting example, driver log module <NUM> may track the driver log information <NUM> in a manner that represents the <NUM> hours in a driver's day as a sequence of <NUM> log codes (<NUM> log codes/minute x <NUM> minute/hour x <NUM> hours/day), where the sequence corresponds to some combination or sequence of different log code values.

As mentioned above, the ELD <NUM> may include a blockchain node module <NUM>, which is configured to act as a blockchain client that packages and publishes driver log information <NUM> as blockchain transactions. It should be noted that this example implementation should not be construed as limiting, as one of skill in the art may modify this implementation and achieve similar results. For instance, rather than the illustrated actions of method <NUM> occurring at the ELD <NUM>, the functionality associated with blockchain node module <NUM> may instead be implemented in the data center <NUM>, which receives aggregates raw driver log information <NUM> from the ELD <NUM> and publishes the driver log information <NUM>, using its own instance of a blockchain node module <NUM>, as blockchain transactions on behalf of the ELD <NUM>. Additionally, method <NUM> of <FIG> is discussed with further reference to <FIG>, which includes a representation of the collected driver log information <NUM> and the generated driver log blockchain data structure described herein for publishing the information into the blockchain, and to <FIG>, which includes a more detailed architectural implementation of the ELD <NUM>.

In accordance with various aspects of the present disclosure, at <NUM>, the method <NUM> may include collecting driver log information corresponding to one or more drivers of one or more vehicles. For example, in an aspect referring back to <FIG>, driver log module <NUM> may periodically collect driver log information <NUM> associated with one or more drivers of one or more vehicles <NUM>. In some aspects, for example, the driver log module <NUM> may execute code to generate a graphical user interface or other user input interface on a user interface, e.g., a display, of ELD <NUM>, where the graphical user interface may be operable to receive an indication of driver log information <NUM> via manual inputs by the truck driver or via automatic collection based on the various sensors, or some combination of both. For instance, driver log module <NUM> may collect the driver log information <NUM> corresponding to a respective driver (e.g., a driver may log in or may provide an identifier to identify him/her self) once every minute based on a manual input by the truck driver of a current driver state (e.g., a log code, such as a code corresponding to "off duty," "sleeping/resting," "driving," and "on duty but not driving") at the user interface of the ELD <NUM>. Further, in some aspects, driver log module <NUM> may maintain a clock or timer that tracks a time period associated with a current driver state (e.g., previously received log code) until receiving another manual input from the truck driver to change the current driver state.

For example, in an aspect that refers to <FIG>, when a log code corresponding to "off duty" is received, then driver log module <NUM> can record a log code of "off duty" at that point in time and for every subsequent minute (or other periodic time of interest) until a different driver state is received. In particular, the driver log information <NUM> associated with the corresponding driver may include, for example, log code <NUM> having a variable value that indicates the driver state. As mentioned above, one example of the various values and driver states associated with log code <NUM> may include, but is not limited to, a value of <NUM> to represent "off duty," a value of <NUM> to represent "sleeping/resting," a value of <NUM> to represent "driving," a value of <NUM> to represent "on duty but not driving," a value of <NUM> may represent "yards moved," and a value of <NUM> may represent "personal conveyance.

At <NUM>, the method <NUM> may include generating a blockchain transaction data structure associated with the driver and containing the driver log information <NUM> for that driver. For example, in an aspect, the blockchain node module <NUM> (e.g., executing on the ELD <NUM>) may generate a driver log transaction <NUM> that is a blockchain transaction data structure having an input portion <NUM> and an output portion <NUM> that contains data fields that, among other features, associate the driver log transaction <NUM> with previous and next transactions according to blockchain methodology, as described in greater detail below. The terms "next" and "previous" are not used to necessarily mean strictly next/previous in a sequential or chained data structures as might be found in a linked list type of data structure. Rather, the terms "next" and "previous" are used to refer to next and previous entries in a conceptual chain of driver log entries associated with a given driver, which may include some or many intervening blockchain transactions within a blockchain record (block). An example blockchain transaction <NUM> is shown in object notation in Listing <NUM> below.

In one aspect, the output portion <NUM> stores driver log information <NUM> and an associated public key script <NUM> that specifies conditions for publishing additional driver log information for this driver (described in detail below). The driver log information <NUM> may be hours-of-service data including at least one log code value representing a driving status and a corresponding time duration. For example, in an aspect, the blockchain node module <NUM> may generate an output portion <NUM> having a plurality of time entries that specify a first time duration of <NUM> hours and an associated driving status code of "<NUM>" (i.e., representing "driving"), and a second time duration of <NUM> hours and an associated driving status code of "<NUM>" to represent a sleeping or resting period. In an aspect, for example referring to <FIG>, the driver log information <NUM> encapsulated in a driver log transaction <NUM> may include some sequence of driver log codes <NUM> for each driver corresponding to a respective vehicle <NUM>, wherein the "sequence" of driver log codes <NUM> may represent a driver state over some period of time (e.g., which may depend on the frequency of uploading of driver log transactions <NUM> by ELD <NUM> (<FIG>)). As such, the transmitted driver log information <NUM> may represent some portion of the set <NUM> (<FIG>) of driver log information <NUM> collected for a predetermined time period <NUM> (<FIG>), which may be aggregated into one or more subsets <NUM> (<FIG>). Alternatively, or in addition, in some examples, ELD <NUM> may perform at least some part of the aggregating of driver log information <NUM> into one or more subsets <NUM> (<FIG>). Accordingly, in such alternative or additional cases, the driver log transaction <NUM> may include a sequence of driver log codes <NUM> and additionally some aggregated subsets <NUM> of driver log information <NUM> as compiled by the driver log module <NUM> associated with the ELD <NUM>.

The blockchain node module <NUM> may use the set of public and private encryption keys associated with the driver to form the public key script <NUM>. The public key script <NUM> includes scripting code or executable instructions that are recorded with each driver log transaction and, when executed by a blockchain node, specifies one or more conditions that a party must satisfy to be permitted to correlate additional driver log information with the driver associated with the current driver log transaction <NUM>. In other words, the public key script <NUM> describes how the driver log information recorded across different driver log transactions can be correlated to the same driver. For example, in an aspect, the public key script <NUM> may include scripting code for accepting and comparing one or more input values that are cryptographically-derived values. In one implementation, the public key script <NUM> may be configured to accept a digital signature of an ELD <NUM> as input and evaluate whether this input signature matches a copy of the public encryption key stored in the public key script <NUM> itself.

Turning to the input portion <NUM>, the blockchain node module <NUM> may generate an input portion <NUM> that includes a cryptographic reference to a previous driver log transaction (e.g., previous transaction <NUM>) for which the current driver log records <NUM> are an update. The cryptographic reference can be implemented using a driver log address <NUM> and a signature script <NUM>. The driver log address <NUM> is a unique transaction identifier (e.g., "previous_txid") that refers to the previous transaction <NUM> having previous hours-of-service records <NUM> attributed to the same driver. In some cases, the driver log address <NUM> may have been prior generated and retained by the blockchain node module <NUM>, so that the driver log address <NUM> can be retrieved at time of generating the transaction data structure <NUM>. In other aspects, the driver log address <NUM> may be provided to the blockchain node module <NUM> as an input value so that a driver may continue to log their HOS records in the same chain of records. In some implementations, the driver log address <NUM> may be derived from values of the previous transaction <NUM>, such as a hash or fingerprint value of the previous transaction <NUM>.

The blockchain node module <NUM> may additionally use the set of public and private encryption keys associated with the driver to form a signature script <NUM> stored in the input portion <NUM>. In an aspect, the signature script <NUM> includes scripting code or executable instructions that are recorded in the input portion <NUM> of the driver log transaction <NUM> and, when executed by a blockchain node, provides one or more input values (such as the driver's digital signature) used to satisfy the conditions of a public key script <NUM> of the prior transaction <NUM>, which proves the current driver log transaction <NUM> is created by the actual driver and not another party. That is, the signature script <NUM> includes input values that satisfy the prior transaction's public key script <NUM> to correlate the driver log information <NUM> from the driver with the previous driver log transaction <NUM> (which is from the same driver).

In an aspect, the signature script <NUM> may include a copy of the driver's public encryption key <NUM> and a digital signature ("<SIGDRIVER>"). The blockchain node module <NUM> may generate the digital signature using a private encryption key owned by the driver or the driver's ELD <NUM>. This digital signature may encode certain transaction data, such as the driver log address <NUM>, the driver log records <NUM>, the current public key script <NUM>, and the previous public key script <NUM> and be inserted into one of the fields of the blockchain transaction data structure itself. In an aspect, the digital signature may be a cryptographic hash of these data values in the transaction data structure <NUM> generated using elliptic curve cryptography, such as the Elliptic Curve Digital Signature Algorithm (ECDSA), or other forms of cryptographic algorithms such as the Digital Signature Algorithm (DSA). In this way, the digital signature advantageously prevents tampering and unauthorized modification of the driver's hours of service records when the ELD broadcasts these records to the blockchain network.

It is understood that other blockchain techniques for cryptographically tying together driver log transaction may be used. For example, a formulation similar to a "Pay To Script Hash" (P2SH) methodology may be used in which a redeem script is incorporated into the signature script <NUM>. In this aspect, to verify the driver log transaction, the blockchain node module may extract the redeem script from the signature script field <NUM>, decode the script, and be provided with the valid digital signature in addition to the correct redeem script.

Referring back to <FIG>, at <NUM>, method <NUM> may include transmitting the generated driver log transaction to the blockchain for processing and verification. In an aspect, the blockchain node module <NUM> of the ELD may broadcast the transaction to one or more blockchain nodes in the blockchain network. As described below, each peer node will independently validate the driver log transaction <NUM> before broadcasting the transaction further or attempting to include the transaction in a new block of transactions. For example, in an aspect, the ELD <NUM> and/or driver log module <NUM> may transmit a driver log transaction containing the driver log information <NUM> to a peer blockchain node module <NUM> (e.g., executing in the data center <NUM>). In some examples, driver log module <NUM> and blockchain node module <NUM> may periodically (e.g., every x minutes, where x is a whole number, or once a day, or upon availability of a wired or wireless connection) transmit a blockchain transaction encapsulating the driver log information <NUM> created since the last period to the blockchain. For instance, the driver log transaction <NUM> may be transmitted from the ELD <NUM> to the peer blockchain node using the communications component <NUM> (see <FIG>), e.g., a transceiver or modem, associated with ELD <NUM> over at least one communication channel (e.g., via satellite-based communication system <NUM> and a terrestrial-based system <NUM>).

At <NUM>, the method <NUM> may include receiving the driver log transaction associated with one or more drivers respectively corresponding to one or more vehicles. In an aspect, for example, the blockchain node <NUM> and/or the blockchain node module <NUM> may receive the driver log transaction <NUM> associated with one or more drivers respectively corresponding to one or more vehicles <NUM>. For instance, referring to <FIG> and <FIG>, driver log information <NUM> may be received via at least one of a satellite-based communication system <NUM> (<FIG>) and a terrestrial-based system <NUM> (<FIG>), such as through communications component <NUM> (<FIG>), e.g., a transceiver. Moreover, for instance, the received driver log transaction <NUM> may be further communicated to other blockchain nodes via a bus or other communication link (e.g., <NUM>, <NUM>) within the data center <NUM> or externally. Further, for example referring to <FIG>, the received driver log transaction <NUM> may include some sequence of driver log codes <NUM> for each driver corresponding to a respective vehicle <NUM>, wherein the "sequence" of driver log codes <NUM> may represent a driver state over some period of time (e.g., which may depend on the frequency of uploading of driver log transactions by ELD <NUM> (<FIG>)).

At <NUM>, the method <NUM> may include verifying the received driver log transaction <NUM> prior to publishing the driver log transaction in the blockchain. In an aspect, the peer blockchain node module <NUM> may cryptographically verify the driver log transaction by evaluating a script contained in the blockchain transaction data structure. For example, the peer blockchain node module <NUM> may evaluate the signature script <NUM> and the public key script <NUM> of the prior driver log transaction referred to by the prior transaction identifier (in that order). In one implementation, the blockchain node module provides a stack-based scripting system in which values left on the stack by the signature script <NUM> are evaluated by the public key script <NUM>. The driver log transaction <NUM> is deemed verified and authorized by the correct driver of the vehicle if the output of the public key script <NUM> is "true" (i.e., the script evaluates to true).

At <NUM>, the method <NUM> may include publishing the driver log transaction into the blockchain ledger. For example, in an aspect, responsive to determining that the scripting code of the referenced transaction <NUM> evaluates to true, the blockchain node module <NUM> may incorporate the verified driver log transaction <NUM> into a new or existing block of transactions, according to blockchain methodologies. In some aspects, the blockchain node module <NUM> may further transmit, broadcast, and otherwise share the verified driver log transaction <NUM> with peer blockchain nodes <NUM> in the blockchain network <NUM>.

In some aspects, one or more of the blockchain node modules <NUM> may be configured to generate an audit blockchain transaction data structure having a smart contract or other scripting code configured to, when executed by a node in the blockchain network <NUM>, certify compliance of the driver log information with one or more driving regulations. For example, such an HOS audit blockchain transaction data structure may be created by a blockchain node associated with an inspector, weigh station, or government regulator.

In an aspect, the HOS compliance process may be implemented using one or more function calls executed within a "smart contract" that is embedded in a special transaction data structure or even the driver log transaction <NUM> itself. The script may contain executable code which is configured to, when deployed on and executed by a node in the blockchain network <NUM>, check that the driver log information <NUM> contained in a cryptographically referenced chain of driver log transactions complies with one or more time-based limits provided by predetermined regulations and rules. In one aspect, the smart contract for HOS compliance may allocate internal, dedicated storage of a blockchain node to be used by the smart contract to store state. This storage may be organized as a "map" data structure or associative array. The smart contract for HOS compliance may include a map data structure configured to store a running counter of driver log information mapped per driver. The smart contract may use this map data structure of driver logs to compare whether an aggregated amount of hours of service (e.g., having a driver status code representing "driving") exceeds or is less than a predetermined time limit. In some aspects, responsive to determining that the hours of service for a given driver complies with the rules, the smart contract may be configured to generate and publish a compliance-check transaction within the blockchain ledger. This compliance-check transaction certifies compliance of HOS regulations, and may be digitally signed by a private encryption key associated with the inspector or weigh station.

In an aspect, an organization that provides the ELDs <NUM> and fleet/driver management/performance modules <NUM> for use by vehicles and drivers (i.e., ELD service provider) may manage one or more encryption key sets for use by customers/users to directly inspect HOS logs without relying on direct web services (e.g., driver log report module <NUM>) provided by that organization. The data center <NUM> (i.e., managed by ELD service provider) may instead be configured to issue to a third-party the appropriate encryption keys associated with a given driver's HOS transactions, which can then be used by that third party to access and verify the HOS logs published in the blockchain ledger <NUM>. This improves the functioning of the computing system by providing a high availability characteristic to the HOS data, in contrast to known solutions, because the data integration points are decentralized while the security management remains centralized. In this way, third parties are able to utilize the HOS data for feature functionality that extends beyond the described services, while the ELD service provider retains the ability to "license" access to the data with the management of the security keys.

In another aspect, the blockchain network <NUM> may be configured as a permissioned blockchain network that applies an access control layer on top of the blockchain <NUM>. This is another way in which third parties are permitted to use the HOS data for various features (e.g., analysis, auditing), while the ELD service provider retains the ability to "license" access to the data with the management of the permissioned blockchain. With a permissioned blockchain network, only pre-approved entities are permitted to execute blockchain nodes <NUM> that validate transaction blocks. For example, while any client (e.g., ELD <NUM>) can submit transactions containing driver log information <NUM> to the blockchain for verification, the blockchain node <NUM> executing in the data center <NUM> and managed by the ELD service provider may be authorized to execute a blockchain node <NUM> that validates transaction blocks containing driver log information <NUM>. In some aspects, only certain pre-approved entities (e.g., government regulators) are permitted to execute blockchain nodes <NUM> that execute smart contracts on the blockchain <NUM>, such as smart contracts that verify compliance of the hours-of-service regulations. In some aspects, the permissioned blockchain network may define various roles such as a "reader" role, that can be used by an auditor or government regulator to read and analyze the driver log records found in the blockchain <NUM> (but not write to it) for compliance purposes; a "writer" role which has the ability to read and write to the blockchain <NUM>, that can be used by an ELD <NUM> or other reporting devices; and an "operator" role which can perform management-related operations such as adding, removing, and/or authorizing with a particular role new members to the blockchain network <NUM>. Such an operator role can be used by the ELD provider to more closely regulate and manage the operations of the blockchain network while still enabling distributed access (via different roles).

In aspects having a permissioned blockchain network, each blockchain node <NUM> may be configured to validate a block of transactions containing driver log information using a proof-of-stake algorithm to achieve a distributed consensus with other blockchain nodes in the network <NUM>. For example, the blockchain nodes may use proof-of-stake algorithm such as a chain-based proof-of-stake algorithm, a byzantine fault tolerant (BFT)-style proof-of-stake algorithm, or Casper-related proof-of-stake algorithms used in Ethereum.

Referring to <FIG>, in an example that should not be construed as limiting, ELD <NUM> may include additional components that operate in conjunction with driver management and/or performance module(s) <NUM> and driver log module <NUM>, which may be implemented in specially programmed computer readable instructions or code, firmware, hardware, or some combination thereof.

In an aspect, for example as represented by the dashed lines, features described herein with respect to the functions of driver log module <NUM> may be implemented in or executed using one or any combination of processor <NUM>, memory <NUM>, communications module <NUM>, and data store <NUM>. For example, driver management or performance module(s) <NUM>, driver log module <NUM>, and blockchain node module <NUM> may be defined or otherwise programmed as one or more processor modules of processor <NUM>. Further, for example, driver management or performance module(s) <NUM>, driver log module <NUM>, and blockchain node module <NUM> may be defined as a computer-readable medium (e.g., a non-transitory computer-readable medium) stored in memory <NUM> and/or data store <NUM> and executed by processor <NUM>. Moreover, for example, inputs and outputs relating to operations of driver management or performance module(s) <NUM>, driver log module <NUM>, , and blockchain node module <NUM> may be provided or supported by communications module <NUM>, which may provide a bus between the modules of computer device or an interface for communication with external devices or modules.

Processor <NUM> can include a single or multiple set of processors or multi-core processors. Moreover, processor <NUM> can be implemented as an integrated processing system and/or a distributed processing system.

Memory <NUM> may operate to allow storing and retrieval of data used herein and/or local versions of applications and/or software and/or instructions or code being executed by processor <NUM>, such as to perform the respective functions of driver log module <NUM> described herein. Memory <NUM> can include any type of memory usable by a computer, such as random access memory (RAM), read only memory (ROM), tapes, magnetic discs, optical discs, volatile memory, non-volatile memory, and any combination thereof.

Communications module <NUM> is operable to establish and maintain communications with one or more internal components/modules or external devices utilizing hardware, software, and services as described herein. Communications component <NUM> may carry communications between modules on ELD <NUM>, as well as between user and external devices, such as devices located across a communications network and/or devices serially or locally connected to ELD <NUM>. For example, communications component <NUM> may include one or more buses, and may further include transmit chain modules and receive chain modules associated with a transmitter and receiver, respectively, or a transceiver, operable for interfacing with external devices.

Additionally, data store <NUM>, which can be any suitable combination of hardware and/or software, which provides for mass storage of information, databases, and programs employed in connection with aspects described herein. For example, data store <NUM> may be a data repository for applications not currently being executed by processor <NUM>.

ELD <NUM> may additionally include a user interface module <NUM> operable to receive inputs from a user, and further operable to generate outputs for presentation to the user. User interface module <NUM> may include one or more input devices, including but not limited to a keyboard, a number pad, a mouse, a touch-sensitive display, a navigation key, a function key, a microphone, a voice recognition module, any other mechanism capable of receiving an input from a user, or any combination thereof. Further, user interface module <NUM> may include one or more output devices, including but not limited to a display, a speaker, a haptic feedback mechanism, a printer, any other mechanism capable of presenting an output to a user, or any combination thereof.

Referring to <FIG>, in an example that should not be construed as limiting, a blockchain node <NUM> (e.g., executing in a data center <NUM>) may include additional components for verifying and publishing driver log data in a blockchain and in particular for operating in conjunction with the blockchain node module <NUM>, which may be implemented in specially programmed computer readable instructions or code, firmware, hardware, or some combination thereof.

In an aspect, for example as represented by the dashed lines, the features of the blockchain node module <NUM> described herein may be implemented in or executed using one or any combination of processor <NUM>, memory <NUM>, communications component <NUM>, and data store <NUM>. For example, blockchain node module <NUM> may be defined or otherwise programmed as one or more processor modules of processor <NUM>. Further, for example, blockchain node module <NUM> may be defined as a computer-readable medium (e.g., a non-transitory computer-readable medium) stored in memory <NUM> and/or data store <NUM> and executed by processor <NUM>.

Memory <NUM> may be operable for storing and retrieving data used herein and/or local versions of applications and/or software and/or instructions or code being executed by processor <NUM>, such as to perform the respective functions of the respective entities described herein. Memory <NUM> can include any type of memory usable by a computer, such as random access memory (RAM), read only memory (ROM), tapes, magnetic discs, optical discs, volatile memory, non-volatile memory, and any combination thereof.

Communications component <NUM> may be operable to establish and maintain communications with one or more internal components/modules and/or external devices utilizing hardware, software, and services as described herein. Communications component <NUM> may carry communications between peer blockchain nodes <NUM> within a data center <NUM> or elsewhere in the blockchain network <NUM>, as well as between user and external devices, such as devices located across a communications network and/or devices serially or locally connected to the blockchain node <NUM>. For example, communications component <NUM> may include one or more buses, and may further include transmit chain modules and receive chain modules associated with a transmitter and receiver, respectively, or a transceiver, operable for interfacing with external devices.

In instances in which the blockchain node <NUM> is executing in a data center with a driver log report module <NUM>, the blockchain node <NUM> may additionally include a user interface module <NUM> operable to receive inputs from a user, and further operable to generate outputs for presentation to the user. User interface module <NUM> may include one or more input devices, including but not limited to a keyboard, a number pad, a mouse, a touch-sensitive display, a navigation key, a function key, a microphone, a voice recognition module, any other mechanism capable of receiving an input from a user, or any combination thereof. Further, user interface module <NUM> may include one or more output devices, including but not limited to a display, a speaker, a haptic feedback mechanism, a printer, any other mechanism capable of presenting an output to a user, or any combination thereof.

In view of the disclosure above, one of ordinary skill in programming is able to write computer code or identify appropriate hardware and/or circuits to implement the disclosed invention without difficulty based on the flow charts and associated description in this specification, for example. Therefore, disclosure of a particular set of program code instructions or detailed hardware devices is not considered necessary for an adequate understanding of how to make and use the invention. The inventive functionality of the claimed computer implemented processes is explained in more detail in the above description and in conjunction with the FIGS. which may illustrate various process flows.

In the above description, the term "software product" may include files having executable content, such as: object code, scripts, byte code, markup language files, and patches. In addition, a "software product" referred to herein, may also include files that are not executable in nature, such as documents that may need to be opened or other data files that need to be accessed.

The term "software update" may also include files having executable content, such as: object code, scripts, byte code, markup language files, and patches. In addition, "software update" referred to herein, may also include files that are not executable in nature, such as documents that may need to be opened or other data files that need to be accessed.

As used in this description, the terms "module," "database," "module," "system," and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a module may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computing device and the computing device may be a module. One or more modules may reside within a process and/or thread of execution, and a module may be localized on one computer and/or distributed between two or more computers. In addition, these modules may execute from various computer readable media having various data structures stored thereon. The modules may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one module interacting with another module in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal).

In one or more exemplary aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted as one or more instructions or code on a computer-readable medium. By way of example, and not limitation, such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to carry or store desired program code in the form of instructions or data structures and that may be accessed by a computer.

For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line ("DSL"), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium.

Disk and disc, as used herein, includes compact disc ("CD"), laser disc, optical disc, digital versatile disc ("DVD"), floppy disk and blue-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.

Claim 1:
A transport driver log system, comprising:
a processing system for:
receiving driver log information associated with one or more drivers respectively corresponding to one or more vehicles, wherein the driver log information contains hours-of-service data associated with the driver (<NUM>);
generating a blockchain transaction data structure having an input portion and an output portion (<NUM>), wherein the input portion of the blockchain transaction data structure comprises a cryptographic reference to a previous transaction data structure associated with the driver, and the output portion stores the hours-of-service data including at least one log code value representing a driving status and a corresponding time duration;
publishing the blockchain transaction data structure to a blockchain network (<NUM>), wherein the transport driver log system is a node within the blockchain network; and
generating an audit blockchain transaction data structure having a contract script configured to, when executed by a node in the blockchain network, certify compliance of the driver log information with one or more driving regulations,
wherein the audit blockchain transaction data structure includes a map data structure having a running counter of the driver log information mapped to the one or more drivers and the audit blockchain transaction data structure is cryptographically signed by a private encryption key associated with an inspector or weigh station.