Software Technology For “Systems and Methods for Collaborative Road User Safety”

Invented by Victoria J Miller, Kevin L Miller, Labyrinth Research LLC

The invention works by Victoria J Miller, Kevin L Miller, Labyrinth Research LLC

“Systems and techniques describe a collaborative road-user safety service that interacts to a coordinating set collaborative safety devices owned by road users to exchange reliable information about road safety. The service uses a distributed ledger/blockchain to coordinate data exchange among collaborative safety device users. Data subscribers receive reliable safety data that can then be used to automate technical processes. The use of collaborative safety devices to alert users to road safety issues can be used to verify information by collecting telemetry and sensor data. Subscribers can get aggregated, anonymized or de-anonymized road user data. They can also define incentives for road users who?self-review?. Smart contract interfaces can be used to determine if a road user is using a vehicle as a target vehicle. To encourage data sharing, accuracy and safe road behavior, cryptographic tokens can be transferred.

Background for “Systems and Methods for Collaborative Road User Safety”

“Despite the increased presence of automated vehicles and advanced safety features, road safety has been steadily declining.” An estimated 40,000 people died in car accidents in the United States in 2018, an increase of 14% in the last four years. In addition, approximately 4.5 million people were injured in crashes in 2018. In 2018, 6,227 pedestrians were killed in crashes on U.S. roads. This is a 35% increase over 2008 and an increase of 4% over 2017.

“Nearly 1.3 Million people die each year in road accidents, which is an average of 3,287 deaths every day. Another 20-50 million people are also injured or disabled each and every year. According to the World Health Organization, there will be nearly 2 million deaths per year by 2030. Economic losses account for around 3% of many countries? annual GDP. For those between 15 and 29, road crashes are the most common cause of death. Road traffic injuries will be the fifth leading cause for death by 2030, according to experts.

“In frustration over the increasing dangerousness of roadway travel, some drivers have turned to ad-hoc methods such as posting videos of hazardous drivers on their social media accounts and web pages, telephoning the police department, or telephoning fleet watch services such as ?1800-HOW’S-MY-DRIVING? Report problem drivers

“The above ad-hoc activities have many drawbacks. Not the least is the fact that entry methods (e.g., telephone calling) can be dangerous for drivers reporting hazardous behavior. These methods are unreliable and often unverifiable. They also do not allow for trend analysis, real-time data sharing, or automated decision-making via associated systems. The existing ad-hoc techniques lack the technical infrastructure to allow a wide range of stakeholders to work together on road safety.

These deficiencies are recognized and systems and techniques are described in this document to facilitate collaborative road user safety through a?collaborative route user safety service? It interacts with a coordinated set of devices belonging road users (collaborative safety device). To exchange reliable information about road safety, In connection with the collaborative road user Safety Service, a distributed ledger (e.g. a blockchain) is used to coordinate data exchange among safety device users.

“Thus, in one embodiment, a system for collaborative safety device (or CSD) is described. It allows road users to collect relevant and reliable information about a concern safety behavior?such erratic or aggressive driving?and then exchange that information with other road users in a safety service. The CSD can also be used to collect sensor and telemetry data which verify a safety behavior or vehicle identification data. The CSD can also be used in conjunction with the collaborative road safety service to verify the safety behavior or vehicle identification data of vehicles submitted by another user. A CSD can provide real-time information to road users about vehicles that are exhibiting safety behavior or concerns. Some CSD features have technical advantages, such as improved usability and techniques to gather safety data and target vehicle identification, high reliability of data (e.g. GPS data and sensor data are automatically gathered), and verification via technical methods for interchange with other CSDs.

“A ‘collaborative road safety service/system is another aspect. The CRSS (collaborative road user safety service/system) is used to facilitate data exchange between CSDs in order to reliably collect vehicle identification and safety data. The CRSS coordinates activities of other CSDs within the vicinity of a ‘target vehicle, in various embodiments. Reports from another CSD are used as ‘confirming devices’ Used to verify, validate, and/or suggest vehicle identification data as well as safety data for the target vehicle. The CRSS coordinates safety information exchange about target vehicles with CSDs nearby and other interested parties in some embodiments. The CRSS can calculate metrics that evaluate driver safety and severity, which can then be used in automated interchange with ancillary technical procedures.

“Some embodiments incorporate distributed ledger-facilitated technical elements to encourage participation among members of the CRSS and data sharing. These features allow for the easy transfer of cryptographic tokens into and out from cryptographic token repositories that belong or are associated with members of the CRSS. These technical features have the advantage of encouraging data sharing between devices participating in the CRSS, in addition to having the advantageous technical effect of improving and ensuring the quality of data that is used to make road user safety assessments at all levels of collaboration, from individual safety decisions, to regulatory/enforcement performance, to road safety operations, planning, and systems design.”

“Some embodiments provide permissioned data subscribers the ability to receive aggregated anonymized, de-anonymized or specific road user data pertaining one or more roadusers via smart contract interfaces to the distributed application network. Permissioned data subscribers may be able to use smart contracts to set the terms for road users who?self-revise’. If a road user’s vehicle exhibits a safety-related behaviour. The collaborative nature of these systems and techniques has a key technical advantage: the ability to exchange highly reliable safety data among disparate subscribers who require reliable data for complex decision making, especially when it is automated.

“Systems, techniques can provide many other advantageous technical effects that are described in relation to particular embodiments and examples. The Examples section at the end of this Detailed Description describes a variety of additional embodiments, and their combinations.

“This Brief Summary presents a few concepts in simplified form. They are described in detail below in the Detailed description. This Brief Summary does not intend to identify key features and essential features of claimed subject matter. It also is not meant to limit the claims.

“?Road users? “?Road users?” is a term that refers to all people on or near the roadway. This includes private and commercial vehicles as well as motorbikes and cyclists. A collaborative safety device can be used by any road user as a member. To initiate a?tagging activity?, you can use the collaborative road user safety system. against another road user vehicle that exhibits a safety-related behaviour (?target vehicle

“FIG. FIG. 1 illustrates an example system/component environment where some systems and techniques can be implemented to improve road safety. FIG. FIG. 1 shows an example representation of a collaborative road safety service/system (CRSS), and the associated devices and participants that interact with it. FIG. FIG. 1 illustrates aspects that are optional in certain embodiments.

The example component environment contains a collaborative safety system 100. This example may be implemented on a mobile device 99 in the possession of a roaduser 99. A collaborative safety device 100 communicates with a collaborative road users safety service (CRSS120) by sending a tag request 110 and other data over a network to the CRSS 120. CRSS 120 could contain additional components or sub-components, e.g. 121-124. The CRSS 120 components perform various processing tasks that facilitate the systems and techniques described in this document. FIGS. 2B, 3A, 3C and FIGS. 2B, 3A and 3C are also shown. 4-7. The simplest embodiment of CRSS 120 is to submit, via its own distributed app node 125 to distributed network 130 (e.g. a blockchain network), a tagging transactions 127 to record the tagging requests and associated data on a distributed leger 165 jointly instantiated by distributed application network 130 member nosdes. Other member nodes 131 may process and verify the tagging transaction 127. One or more transactions, such as the weighting transaction(s), 133, or incentive transaction(s), 132, can be submitted in a similar fashion to certain embodiments.

“Reviewing certain aspects of FIG. 1. A collaborative safety device 100 (or as it is sometimes called, CSD) is located in the possession of road users 99 who are members of the CRSS120. A collaborative safety system 100 could be any device or system described in FIG. 10. Mobile devices include smartphones, tablets and laptops as well as smart watches and smart glasses. There are also vehicle dashboard interfaces/panels and commercial vehicle dispatch interface devices. One such form factor is mobile device 98.

A CSD 100 can perform various processing tasks to exchange data for the CRSS 120 depending on its operational requirements. Components within the CSD 100 may perform one or more of these processing tasks, such as a tagging element 101, confirmation component 102, an alert component 103 and a GPS component 104. A telemetry component 95 is another example. These components can be implemented in software, firmware, hardware or any combination thereof.

For example, “Tagging component 101” may be responsible to implement the processing tasks related to providing interfaces to an initiating members for gathering tagging data and transmitting a tagging requests 110 to the CRSS 120. Tagging component 101 can provide an interface to the initiating member (e.g. 99) for initiating a tag request 110 and entering one or more elements of the vehicle identification data 112 and/or the target road users safety data 112. Sometimes, the tagging component 101 can coordinate with other components of CSD 100 such as the GPS component104 or the telemetry component105 to get sensor data and telemetry (e.g. 106) from the collaborative safety device 100. FIG. FIG. 2A illustrates an example flow for tagging events operations that could be performed by a 101 tagging component.

“Confirmation component 102 may, for example, be responsible for implementing processing tasks related to receiving, acting upon, and responding on a confirmation request 113 of the CRSS 120. As described in detail in FIGS. 3A-3C may be sent by CRSS 120 via a confirming device (which could be a CSD 100), to confirm data related to a specific tagging request that was originated with a different initiating apparatus. The confirmation component 102 may receive confirmation request 113 and verify the requested information via interaction with a confirming member.

“Alert component 103 may, for instance, be responsible for implementing processing tasks associated with receiving alert 115 from CRSS 120. It may also present user interface elements to notify road-users who are subscribing to the alert receiver device (which could be, but not necessarily, a CSD100) of the existence or likely proximity of a target vehicle to the alert receiver device. FIG. FIG. 4 explains in greater detail the process flow and other aspects of determining an alert from the CRSS 120. Alert component 103 can coordinate with other components in a CSD 100 such as the GPS component 104.

For example, GPS component 104 may be responsible to implement the processing tasks related to interfacing with GPS sensors CSD 100 in an effort to provide geolocation information (e.g. in GPS coordinates, other coordinate systems, and speed and direction) about the CSD 100 and the CRSS 120. GPS component 104 can provide geolocation information upon demand, such as when an initiating member uses the CSD 100 user interface for a?tagging’ request. Operation of a target road vehicle (as described, for example in FIG. 2A). 2A. GPS component 104 may sometimes provide geolocation information to the CRSS 120 on a repeated periodic basis (e.g., every few minutes, seconds or milliseconds). This is to assist the CRSS 120 in processing activities that include the identification of subscribing members or confirming devices with alert receivers who are geolocated proximate the target road user vehicle for a specific tagging request. GPS component 104 may provide additional information beyond geolocation coordinates. A vector can be calculated from multiple geolocation coordinates and their timestamps over time to determine the speed and direction of travel for a CSD 100. GPS data may also include a canonical timestamp.

For example, the telemetry component 105 may be responsible to implement the processing tasks related to interfacing with sensors components on the CSD 100 or interacting with a Telemetry Device 106 connected via a communications interface to the CSD 100. Any processing activity of the CSD 100 may be supported by the telemetry component. This includes any component (e.g. components 101-104). In FIG. 2, we describe in detail the types of sensor components and the telemetry devices (106), their connection to the CSD and the processing by the Telemetry Component 105. 2A.”

“The CSD 100 described components (including their components) can be instantiated in software (such an application,?app?). Distributed application or?DApp/dApp distributed application or?DApp/dApp? These instructions can be installed on the CSD 100 using an installer program, or any other installation process (e.g. downloading an app from GOOGLE PLAYSTORE), or integrated into existing control software (e.g. an operating system). Programming instructions can be in any form, including object code, programming language code, dynamically or statically linked libraries or any other form that is familiar to the average practitioner of the art.

“The processing tasks that were performed with respect to a specific tagging event could, in turn describe the role that a road user member plays in any given usage instance. The CSD 100 may be used by an initiating member (CRSS 120) as an ‘initiating device. To initiate a specific tagging request regarding a target road use vehicle, a different CSD in the possession of another road user member (?confirming Member) is used. The?confirming device? To confirm data related to a particular tagging event. Other CSDs could also act as?alert receivers? Other CSDs may also act as?alert receiver devices?, which send alerts via their user interfaces to notify subscribers about the particular tag event. The roles of road users may include initiating, confirming, or subscribing members. This is dependent on how their CSD is being used with respect to that particular tagging event. Not every CSD 100 implements all types of components (e.g. 101-105) or fulfills all processing tasks (e.g. tagging and confirming and alerting). A given device 100 can fulfill any of these roles in any combination. For example, a CSD 100 created on a smartwatch form factor might implement the program instructions for a tagging and alert component 101, but not the confirmation component 102.

FIGS. show the various processing tasks associated with a CSD 100, as well as its sub-components. 2A, 3B and 4″.

“CSD 100 (including its parts 101-105) communicates to a CRSS120 to send the tag request 110 over a network, using a communication interface described in FIG. 10. CSD 100 allows interaction with CRSS 120 by using an application programming interface (API), of the CRSS 120 that is accessible over the network. An “API” is a set of programming instructions and standards that enable two or more applications to communicate over the network. An?API? is a collection of instructions and standards that enable two or more applications communicate with one another. An API is an interface that can be implemented by either a hardware component or a program code component. It allows you to call another program code component or hardware part (hereinafter ‘API-calling components?). Access and use of one or more functions, methods and procedures. An API may define parameters that can be passed between the API calling component and the API implementing component. One or more computer-readable storage media may contain the API and any related components. Commonly, an API is implemented as a collection of Hypertext Transfer Protocol request messages and a specific format or structure to receive response messages according a REST architecture or SOAP architecture. An API might send response messages in XML (Extensible Markup Language), or JSON (JavaScript Object Notation) in some cases.

The network could include, but not be limited to: a cellular network (e.g. wireless phone), a point?to-point dial-up connection, a satellite internet network, the Internet and a local area network. These networks can be used to connect many types of network elements such as servers, gateways, routers and switches, hubs, bridges or routers. One or more networks may be connected to the network (e.g., multi-network environment), which can include public networks like the Internet and/or private networks like a secure enterprise private networking. As will be explained by those skilled in art, access to the network can be made via either wired or wireless access networks.

“Generally speaking, but not exclusively, a CRSS120 receives the tag request 110 (and any other data from the collaborative safety system 100, such as vehicle ID data 111 or target road user safety information 112) and performs various processing activities, including weighting, confirmation, and incentive transfers. The text relating to FIGS. discusses the processing activities of a CRSS 120. 2B, 3A and 3C. It is important to note that this architecture of a CRSS 120 with its distributed application network 130 architecture can be viewed architecturally. FIG. FIG. 10 shows a system that can be used in certain environments to implement a CRSS 120 with various types of virtual and physical computing systems and their associated components.

“CRSS 120 is a set of units or modules that perform various processing activities. It may include tagging unit 121 and confirmation unit 122. Weighting unit 123 and alerting unit 124. Distributed application node 125. Data feed smart contract unit 155. Incentive smart contract 160. These units can be separated into distinct codebases that run on different systems or may reside on the same platform and have a conceptual/logical separation. FIG. 1. Line 120 shows a virtual boundary around components that are logically under the control of CRSS.

“Tagging unit (121) may, for example, process tasks related to receiving tagging requests(s), 110, concurrently, or subsequently receiving vehicle ID data 111, target road user safety information 112, and generating, submitting and updating tagging transactions (127 on the distributed ledger, 165 via distributed app node 125. The process flow shown in FIG. 2B demonstrates these processing tasks in greater detail. 2B. For example, confirmation unit 122 may process tasks related to sending confirmation request(s), 113, concurrently processing confirmation replies 114, and generating confirmation transactions 134 on distributed ledger 165 via distributed app node 125. These processing tasks can be described in detail with regard to the examples of FIGS. 3A and 3C. 3A and 3C. For example, weighting unit 123 may be responsible for processing tasks such as determining event weighting scores, generating and submitting weighting transaction 133 to the distributed ledger via distributed application node 65, and so on. The process flow for FIG. 2 shows the details of these processing tasks. 5. For example, the alerting unit 124 may process tasks related to geolocation-based alerts and watch alerts regarding tagging events and then send those alerts to CSDs 100 acting in alert receiver devices and other alert receivers 140. In the following example, we will describe these processing tasks in greater detail. 4 and the various types and variations of alert receivers 140.”

“The CRSS 120 could also include one or more associated data repositories such as member database store 126. The data structures and content that describe the members of the service, as well as their metadata, make up a member data store 126. A member data store 126 structure can be structured in many ways. It can include highly-organized information collections?where every data element is assigned a place within a defined structure?to loose collections unstructured data. Relational database management systems (RDBMS) are able to manage highly-ordered information collections. They have the advantage of fast indexing and transactional integrity for data changes. Flexible collections of unstructured data may be beneficial in certain cases. They lack a central indexing hierarchy, which can cause a bottleneck in RDBMS processing. These unstructured methods of managing repository data are often called non-relational or?NoSQL? databases. One of the most basic forms of a non-relational databank is?documents? Files in the file system can be used as data stores. The ‘database’ is a collection of such files. The?database? simply consists of a collection such store files. Many of these may be binary objects. Although a document or file loosely corresponds with a record in an RDBMS database table, it contains data that is much less structured in many instances.

“Some embodiments, though not shown in FIG. 1. All or part of the member database store 126 is stored on the distributed ledger (165) on the distributed app network 130. In some embodiments, member database store 126 is located on or uses state or data storage services, such as a decentralized data system, decentralized data base, key/value storage, key/value storage, or any other state storage mechanism that can be accessed through, integrated with, residing or accessible through the distributed application network 130. These services can be accessed via a smart contract (also called a?DApp?) The distributed application network 130. Namecoin and Filecoin are just a few examples of these services, which can be integrated into existing distributed applications networks like Ethereum. Some embodiments may include all or part member data stored with an identity solution. This allows for the associating of a common identity with multiple DApps. (CIVIC is just one example of a company offering this solution).

“In certain embodiments, member database store 126 (or another data source 141) can be provided through an?oracle? Service accessible via, but not necessarily residing in, the distributed app network 130. A service called an oracle provides additional feeds or streams data that have been “trusted”. The distributed application network provides reliable data to support certain activities.

“Furthermore it is possible that all data stores (e.g. member data store 126) can reside on one type of storage or they may be arranged across multiple storage types (e.g. some data structures or segments of member data storage 126 may reside in computer-readable media provided to the CRSS, while others may reside on a distributed ledger, decentralized database, oracle or decentralized database).

“CRSS 120 can record a tagging transaction (or incentive transaction (132), weighting transaction (133), or confirmation transaction (134) in a persistent, trusted manner that allows responsive and automated data exchange with permissioned subscribers. The records may be stored on a distributed distributed ledger (165), which is unchangeable and undeletable and housed on the distributed network 130. To access the distributed ledger 165 and network, the CRSS 120 can use a distributed app node 125.

A distributed application network 130 usually includes many other nodes 131, which could be, e.g. one or more machines, computers or databases, data stores or the like, that are operably connected to one another. Node software can be used to make computing systems nodes in a distributed network 130. This includes node software specific to a particular type of distributed network 130. For example, node software to participate in a blockchain network (e.g. Bitcoin, Ethereum, or a private blockchain implementation). Sometimes, multiple nodes or nodes can be maintained by different entities. Node software connects to other nodes/peers (e.g. 131) in the distributed app network via a network (e.g. the Internet) and maintains either a complete copy/replica or a partial copy of the distributed ledger data base (e.g. 165). CRSS 120 contains a distributed node 125 that participates in a distributed network 130 by at most running node software.

“In certain embodiments, the distributed leadger 165 can be implemented as a Blockchain. Blockchain is a trusted distributed database system that is maintained in trust by all participants. It is unchangeable. Blockchains are typically independent of any central repository or administrator. A blockchain’s most well-known function is the public ledger for transactions in cryptocurrencies like Bitcoin.

A blockchain has many advantages over traditional databases. The validity of transactions stored on a blockchain ledger may be confirmed by a large number of nodes. Multiple versions of a transaction can exist on the ledger and multiple nodes may agree to the most current version. In the case of virtual currency transactions, for example, a blockchain node that creates a transaction can determine with a high degree of certainty whether it can be completed and confirm that there are no conflicts by verifying that other currency transactions have not been verified by the blockchain.

Data records in the blockchain are encrypted with cryptographic hashes. They are stored on nodes of the Blockchain in a chained order in which each block retains a pointer back to the previous block in that chain. Two types of records are common in a blockchain. The transaction type contains the actual data that is stored on the blockchain. The block type, records that verify when and how certain transactions were recorded in the blockchain, is the second type. Participating nodes create transactions, including the distributed application node (125) of CRSS 120. This allows participants to specify information that should be permanently stored on the blockchain. Participants of the blockchain (i.e. 131 of the distributed app network 130, of which CRSS120 is one) create transactions. These transactions are then passed around through a peer to peer (P2P), sharing network to other nodes. Nodes called?miners create block-type transactions. Or?validators? Depending on the type and level of distributed application network, they use special software or equipment to create blocks that contain one or more sequenced transaction that have been proved to be valid. Valid? A transaction that is valid can be validated using a set rules defined by the specific blockchain system. In the case of cryptocurrency blockchains (e.g. Bitcoin), a valid transaction can be one that has been digitally signed and spent from a valid digital account. Sometimes, it may also meet other criteria. Some blockchain systems reward miners and validators with a per-block reward, as well as fees that are included in transactions that have been validated. As a reward, a miner who successfully validates a transaction on the Blockchain may be able to receive fees and/or rewards as an incentive for creating more blocks. A miner can run both blockchain mining software and blockchain node software.

“Depending on the type and implementation of the distributed application network used, a distributed ledger or blockchain may be?sharded?” In order to increase storage efficiency and storage, The?state? is split in sharding. The’state? of the blockchain is divided into several parts called?shards. A sharding scheme for Ethereum, a well-known distributed app network, might place all addresses beginning with 0x00 in one shard and all addresses beginning with 0x01 in another shard. The simplest form is that each shard has its own transaction history. Transactions on Ethereum (a well-known distributed application network) might result in all addresses starting with 0x00 being placed into one shard, all addresses beginning with 0x01 being moved to another shard, and so forth. Cross-shard communication is possible with more advanced forms. Transactions on one shard may trigger events on others. Sharding allows several types of nodes to participate in the distributed network. For example, a super-full, which processes all transactions in all collations, and maintains the full status for all shards, or a top level node which processes all top levels of blocks but doesn’t try to download any transactions (instead it accepts it on the faith that a collation will be valid if at least two-thirds of the collators agree); a single-shardnode which can downloads the Merkle, and then it the Merkle-proof of the state, and the Merkle-based,

“Anyone node can have a partial or complete copy of the entire ledger, set of transactions or blocks on the blockchain. Devices with less processing and storage capabilities may run partial nodes, or?light clients?. The distributed application node described herein (e.g. 125) could be any node that has either a complete copy or a partial copy, and may also include miners depending on the implementation.

“In different embodiments, distributed ledgers (e.g. 165) or blockchain may be permission-less, permissioned/private, or a combination thereof. Permission-less blockchains include, for instance, Bitcoin blockchains in which any device can download the code and join the network as a node. Permissioned blockchain is a blockchain where only certain entities can join as nodes. A combination permission-less/permissioned blockchain allows the consensus process to be controlled by a pre-selected (permissioned), node. In different embodiments, some data stores can reside on a permissioned distributed leadger while others may reside on an permission-less ledger. A permissioned distributed ledger or a permission-less distributed one may be used to store transactions only related to disclosed CRSS 120. “Collaborative road user safety Blockchain?

“Nodes (e.g. 125, 131) are able to read transaction records without restriction. Transaction data may be stored in encrypted or obfuscated forms that are only accessible to those who have the cryptographic key necessary to decrypt it. Miners may verify obfuscated data using zero-knowledge proofs like zkSNARKS in some instances.

Smart contracts might be supported in some implementations that use distributed application networks. Smart contracts are a set or instructions that automate certain processes by a distributed network. A Turing-complete language is used to write a smart contract. A smart contract is written in a Turing-complete language and sent to a distributed network 130 as a transaction. The contract generation transaction is processed and committed to the distributed ledger.165. This makes the smart contract a set function that can be invoked to call processes that do different types of work on the distributed app network 130. Invoking the smart contract, e.g. calling one or more of its functions, causes the program instructions embedded within the smart contract to execute on one or more of the nodes 131. On some distributed application networks, such as Ethereum, one or more smart contract may be called a distributed app or DApp. A DApp on Ethereum, or any other distributed application network, may implement smart contracts that are part of a CRSS (e.g. 155, 160). Smart contracts can be committed to the distributed ledger, 165 and run exactly as they are programmed.

“In certain embodiments, the CRSS 120 might invoke one or more smart contract published to the distributed ledger 165. The CRSS 120 may implement, publish, and deploy various process flows as smart contracts or functions. Smart contracts from the CRSS can interact with the distributed leadger 165 to access data relating the CRSS. They also have the ability to generate and submit tagging transaction 127, incentive transactions 132, weighting transactions 135 and confirmation transactions 130 to the distributed leger 165 in different embodiments.

“In certain embodiments, the CRSS 120 might implement and deploy smart contract for data feeds 155 (as shown in FIG. 6 and incentives 160, which can include both incentives transactions and smart contracts to self-revise incentives. 7). Permissioned subscribers 150 may have access to data feed smart contract 155 and/or incentive Smart contracts 160 through their interaction with the distributed app network 130, as described in FIGS. 6-7.”

“CRSS 120 can interact with other data source 141 to obtain data relevant to CRSS processing tasks. These data sources 141 may allow data requests to be sent/received via the API. They can be public or private. These include weather services, real time traffic conditions services, insurance databases, or county licensing databases. Below are several processes that describe the various types of data sources 141 as well as how to use their information. Other data source 141 can be a ‘oracle’ in any implementation. service that is accessible to the distributed network 130.”

“FIGS. The process flow diagrams 2A and 2B illustrate an example of how a CSD gathers and exchanges data related to tagging events between the CSD and the collaborative roads user safety service. FIG. FIG. 2A shows the process flow for CSD data gathering and sending aspects, and FIG.

“FIG. 2A illustrates a process flow that can be used to initiate a tagging activity and other collection aspects using CSD processes. FIG. 200 shows the process flow. 2A could be used, for instance, in a 101 tagging component.”

FIG. 1. With the appropriate program instructions, a variety can be used to implement a CSD.

The CSD provides a user interface to initiate a tag request. The CSD provides a user interface that allows you to use any of its input modalities.

“The system/device type factor of the CSD will affect the user interface design and the associated input modes. For example, a CSD that is a mobile device may render program instructions from the CSS in a Web browser. It may also render the user-interface from instructions downloaded from an online software library. FIG. illustrates an example user interface for initiating a tag request. 9. Wearables could use similar methods to provide simpler interfaces that can be rendered to a smaller screen size. Vehicle dashboard panels may render interfaces from dash?app? code that can be integrated into the dashboard interface software library or downloaded.

The user interface elements can be visually oriented, such as command buttons that can easily be pressed using a touch screen mouse pointer or finger, and input fields for text entry. You can choose to include elements that allow data entry that aren’t just visual (e.g. voice, tactile) in any user interface design. Naturally, the best or most useful input modalities for the user interface will depend on the type of CSD device. Voice recognition capabilities can be used by the CSD or App to voice-initiate a tagging event. TAG plate ABC-1234, California. The voice command initiates a tagging order in the App and collects vehicle identification data. You should also note that voice input can be used to input additional vehicle information and safety data, in addition to initiating a tagging request.

“Upon receiving an indication from the initiating member at any of its input modalities a tagging order is generated consisting of GPS data and the initiating devices identifier and sent to the CRSS via communications interface (202).

GPS data also includes geolocation information regarding the current position of the initiating device CSD. Sometimes, the GPS component provides additional information such as speed and/or direction, coordinates, and geolocation (e.g. GPS) data. Operating system functions can be used to determine the speed and direction of a mobile device in some mobile operating systems. Other cases might allow the CSD to determine the speed or direction of an initiating device CSD by computing a vector using two or more geolocation coordinates and their timestamps, which were gathered over time via program instructions in the CSD App software. In order to capture the best possible geolocation information for the incident, it is important that the CSD gathers instant geolocation data as close to the tagging request indication.

“An ?initiating device identifier? It can include, but is not limited to data that is sufficient for the initiating device to be identified and associated with a specific member of the CRSS. The initiating devices identifier may include, for example, a universally unique identifier (UUID), which could have been assigned to the initiating user at the time that software applications were being used (e.g.,?apps?) or?DApps? were installed on the initiating devices to allow the member to join CRSS.

“A tagging inquiry can also contain other pertinent information such as the universally unique identifier (UUID), of the tagging request. To assist the CRSS and the CSD in linking the related tagging events data, any subsequent transmissions of data (e.g. vehicle identification data, safety information, data requests and replies) could also include the tagging UUID.

“The sending the tagging request along with its data to the CRSS can be done by transmitting data structures over the communications interface via an API as described in FIG. 1. Preferably, the tagging requests are sent within the time frame of the tagging order indication. This allows the CRSS to begin its own processes for sending confirmation requests and determining alarms (described in relation to FIGS. 2B, 3A-3C and Alerting sections below.

“Vehicle ID data about the target road use vehicle is collected and sent back to the CRSS (203). ?Vehicle identification data? It can come in a variety forms including a plate number (or partial plate number), the state/locality from which the plate was issued, and identifying characteristics of the vehicle (e.g. black LEXUS). These can all be combined with the geolocation to help identify the target vehicle. (See FIGS. 3A-3B below, or by the operator of the target vehicle or passenger (FIG. 3C) if he/she belongs to the CRSS. Any of the input modalities above can be used to collect all or part the vehicle identification data in any instance.

“In certain embodiments, data from a sensor device or telemetry device can be included in vehicle identification data. Below is a detailed description of these processes as well as related devices. This type of vehicle identification data can include, for instance, a photo or video taken with a camera (e.g. a cell phone camera serving as a CSD or a camera that is linked to the CSD via pairing the initiating member?s vehicle systems). Another example is a unique identifier being broadcast on the target vehicle’s connected vehicle systems and/or a broadcast of a transponder identifier from an onboard device within the target vehicle such as an automated tollbooth transponder, RFID sticker, or?EZ-Pass

“The vehicle identification data may be sent to the CRSS by sending data structures over the communications interface via an API as described in FIG. 1. Multiple parts of vehicle identification data can be sent at different times and at different times. For example, data entered by an initiating member might be sent at a different moment than data sent from a sensor or telemetry device. The vehicle identification data can be linked to the tag request via the UUID.

“Safety data associated to the tagging request are collected and sent the the CRSS (204). ?Safety data? Safety data can be in many forms. Any of these forms may be combined to create?safety?. collectively. It can also include safety behavior type. A classification of possible target vehicle behavior categories (e.g., aggressive?, speeding? or erratic?), etc. Each of these may be assigned severity ratings/weights. It may also contain a narrative description from the initiating member. Any of the input modalities above can be used to collect all or part the safety data, which includes the safety behavior type, narrative description, and other pertinent information.

“In certain embodiments, all or some of the safety data may be collected from a sensor device or telemetry device connected to the communications interface. Below is a detailed description of these procedures and the related devices. This type of safety data might include, for instance, data from an initiating member?s CSD such as speed and direction from a GPS device, accelerometer data (from the accelerometer), proximity of the initiating members vehicle to other vehicles, etc.

“Sending safety data to CRSS can be done by sending data structures over the communications interface via an API as described in FIG. 1. Safety data can be sent in different parts and at different times. For example, safety data entered by an initiating member might be sent at a different moment than that sent from a sensor or telemetry device. The tagging UUID may link the safety data to the tagging request. It is important to note that depending on the implementation, the sending the tagging request, vehicle ID data, and safety data could occur simultaneously or separately.

“Some input modalities allow for the initiation and collection of some or all of tagging event data (e.g. vehicle identification data, safety information). The App can capture a photo or a video and initiate the tagging process. It also collects a source image that can be used for optical character recognition and image recognition to identify the vehicle (e.g., target vehicle’s plate number and locality/state of origin, make/model/color). To determine or suggest safety data, such as the type of safety behavior (e.g., following too closely or moving too closely in front), a video may be analysed. The CSD might perform image analysis in some cases or transmit the raw photo/video to the CRSS for analysis.

“In some cases, input modalities like a?TAG skill may be used. A capability or skill may be added to the skill/capability ecosystem by a voice-activated agent/assistant, (e.g. AMAZON ALEXA SIRI, GOOGLE ASSISTANT), to provide an entry point for a tagging query and/or associated vehicle identification/safety data. This capability or skill can be “enabled”? An initiating member can integrate with their CRSS accounts. An example is that an initiating member might ask her phone to open the ALEXA app. ALEXA might reply?OK. What is the vehicle’s plate number? The initiating member responds with the plate number?ABC-1234 California. ALEXA responds?OK. From California, tag ABC-1234 What was the vehicle doing? The initiating member responds with “It cut me off, and slammed the brakes.” ALEXA replies?OK. Do you want to be aggressive? Safety information with the description “cut me off and slammed the brakes.” The?TAG skill is hidden behind the scenes. Program instructions are embedded into the skill/capability ecosystem and use an API to the CRSS for submission of the tagging request, vehicle ID data, safety data.

“In certain embodiments, vehicle identification data and safety data can be enhanced using data from a sensor device on the CSD or a telemetry unit connected to the CSD via a communications interface (205). A telemetry component (e.g. 105) may be used to perform these techniques. It is included in certain examples to allow for interaction with sensors on CSD or connected devices (e.g. 106)

“In terms of capabilities of the device, what are the?sensor components?” The onboard sensors that the CSD is implemented on, such as a mobile device, can be included. The above-mentioned GPS, accelerometers and magnetometers are all examples. Other components of sensor components may include mobile device front-facing or rear-facing cameras and other capabilities such as Bluetooth, cellular radio (e.g. 2G-5G, LTE) or Wi-Fi radio that detects signals from passing mobile phones, RFID components, or transponders.

“Regarding the?telemetry device? These devices can be connected through the communications system. They include devices that are placed in vehicles by the operator or passengers. These telemetry devices can often be connected to a driver’s mobile device via a communications interface.

“Telemetry devices can in some cases be part the vehicle systems of a vehicle where the initiating member of the system is a driver/passenger, such as the vehicle detection systems or driver assistance sensor array. ), and/or an autonomous or semi-autonomous driver sensor array (e.g. cameras placed in different viewpoints on the vehicle’s exterior, LIDAR/RADAR sensors positioned in one/more places on the vehicle such as the roof, front bumper/grill, or rear bumper/grill).

“Some vehicle systems allow users or manufacturers to upload customized programs onto their systems. For example,?apps can be uploaded to vehicle systems. In some vehicles, you can install?apps? via the vehicle’s user interface panel. This panel may run an operating system variation such as ANDROID. This allows for the installation of specialized program instructions on the vehicle’s computer-readable storage media. These specialized operations can be performed by a processor system to access and instruct vehicle system telemetry devices according to the processes described herein.

“Telemetry devices can be connected to the CSD through the communications interface in many ways that are appropriate to the type of telemetry device being used. ), wired network (e.g. Ethernet), or any other communication interface type that connects components or devices together (e.g. USB, FireWire or Thunderbolt), as well as other interface types such as HDMI, VGA or SVGA, DVI or DisplayPort as well as custom communications interfacings such as those used to integrate sensors into vehicle detection systems.

“Indicating by the initiating member that he/she would like to initiate a tagging request can almost instantly cause the CSD (via communications interface) activate the collection, monitoring and/or historical preservation status of any sensor components or telemetry devices. The camera or another sensor could be activated to record information about target vehicles. The collection may be stopped after a set period (e.g. 5-10 seconds) or when the sensors/telemetry device detect that the target vehicle has moved out of range. Some embodiments can obtain historical telemetry from sensor/telemetry units from a very short time before the tagging request was initiated. This depends on whether this capability is available in the sensor or the telemetry device at any given operational instance.

“Raw telemetry data may be interpreted by the CSD and/or transmitted to the CRSS in its raw form for processing depending on the embodiment. As we will see, the telemetry data that is provided by sensors/telemetry device in conjunction with a tagging request can have an impact on the tagging events weighting score or tagger reputation score (see FIG. 5).”

“After describing the types of telemetry devices and sensor components, we now turn to examples of how these devices and sensors can enhance or supplement vehicle information and/or safety data. You can combine any or all of these examples. “For example,

“T1. “T1.

“T2. “T2. This information can be used to identify vehicles, or to associate them with existing data, or to gather safety data (e.g. using triangulation RSSI to determine speed/direction of possible target vehicles).

“T3. “T3. The video may be used to analyze safety data, such as whether the target vehicle’s plate number, locality/state of issue, and make/model/color of the vehicle.

“T4. “T4.

“T5. “T5. A sensor or telemetry device (e.g. proximity sensor, RADAR LIDAR camera, infrared sensing device) is activated to give data about the distance between potential target vehicles and the initiating member’s car; the proximity data may also be part of the safety data.

“T6. “T6. This information can be used to supplement existing vehicle identification data or to identify and uniquely identify target vehicles.

Program instructions of the CSD may be used to process or partially process vehicle identification data and safety data collected from connected telemetry devices or sensor components. Processing might identify aspects of vehicle identification data and safety data that could be enhanced or narrowed through interaction with the initiating members. The CSD might request verification of these aspects via the user interface. An example of this is the analysis of wireless network data (example T2) that might show that the MAC address was associated with a target vehicle in a previous tagging request whose plate number was?ABC-1234. The CSD might ask the initiating member (e.g. via voice prompt) to confirm that the plate number is the target vehicle being tag. The CSD may also suggest to the initiating member that the safety behaviour type be designated as “proximity” if proximity information (e.g. in Example T5 above) indicates that the target vehicle was tailgating. The CSD asks the initiating members to confirm.

“FIG. 2B shows an example flow that can be used to increase road user safety collaboration according to specific examples. Several operations are described in FIG. 250’s example process flow. 2B can be implemented by a collaborative road safety service (CRSS 120) in certain embodiments, or components thereof such as the tagging unit 12 and the weighting unit 123. FIG. 2A discusses the CSD activities related to entering tagging request, as well as the form and substance for collecting and sending vehicle ID data and safety data. FIG. 2B describes CRSS activities related to receiving and processing tagging request, vehicle identification data and safety data.

“Initially, a tagging order (e.g. 110) is received from an initiating device that is associated with an initiating member in the CRSS (251). Remember that FIG. 2A describes how an initiating member can enter a tag request via an initiating device that uses various input/user interface motifs.

“The tagging request contains GPS data about the initiating device as well as an initiating device ID. GPS data gathered by the initiating devices GPS component can include timestamps, geolocation (in GPS coordinates, another coordinate system), speed and direction (which may be included or be computed using the CRSS in relation with previous passive geolocation data sent from the initiating Device CSD).

The CRSS uses the initiating device identifier in certain embodiments to identify an initiating member. This is useful for assigning tagging events weighting scores and tagger reputation ratings (see, e.g. FIG. 5), refining the selections of confirming devices, alert receiver devices (see, for example, FIGS. 3A-3B, and FIG. 4), and determining road user safety incentives.

“A tagging order can include additional information such as the universally unique identifier (UUID), of the tagging request. The CRSS may use a tagging UUID to associate tagging request data and subsequent data received or calculated in relation to the tag event.

“Once a request for tagging has been received by an initiating device the initiating devices has provided GPS data which identifies the geolocation and other pertinent data about the tagging event. Although this data is only one aspect of a tag transaction, it can be used to initiate ancillary processing (256), of certain process flows and techniques. This ancillary processing may be initiated simultaneously with vehicle identification data and/or security data received from the initiating device. This technical feature increases data gathering accuracy through better selection and communication between vehicles that may be moving at high speeds. Aancillary processes may be initiated at any stage of the processing, either immediately after the tagging request or multiple times after each such stage.

“As an example, in some embodiments, confirming device can be quickly chosen and confirmation requests can promptly be sent in relation to the location of the initiating devices (see, for instance, FIGS. 3A-3B). This increases the probability that confirming devices can gather precise and useful information about the target car, which allows for a more targeted set of devices. Sometimes, confirming devices can even confirm vehicle identification data which can be used to verify the initiating device.

“Another example of ancillary computing is that in certain embodiments, alert receivers can be selected accurately and quickly notified when a target vehicle is detected (see FIG. 4). 4). A first, provisional alert could indicate that a target vehicle was?tagged? The alerted member should keep an eye out for vehicles nearby. If the vehicle identification and safety data from the initiating device are improved, an updated or second alert may be issued. Cancellation of the first alert could occur if the enhanced safety information does not match the alert parameters.

“Vehicle ID data about a target vehicle road user vehicle is received in response to the tagging request (252). FIG. 2A shows detailed information about vehicle identification data. 2A, and as noted, partial or complete vehicle identification data can include telemetry data. The vehicle identification data can be sent to the CRSS by the CSD via a communications interface over an API. 1. The vehicle identification data could be linked to a prior-arriving tag request via the UUID.

“Safety data associated to the tagging request has been received (253). FIG. 2A provides extensive information on safety data. 2A, and as noted, complete or partial safety information may also include telemetry data. The CRSS may receive the safety data in data structures that are sent by CSD to the CSD over the API communications interface, as shown in FIG. 1. The safety data could be related to a prior-arriving tag request via the UUID.

“The safety data, vehicle identification data, GPS data are all analyzed and refined (254). Depending on the operating instance and the embodiment, the analysis and refinement can include adding or subtracting data to GPS, vehicle identification, and/or safety data. Sometimes, additional requests may be sent to the initiating device in order to request interaction through its user interface with an initiating member.

If an initiating member can only provide partial vehicle ID data (e.g., a partial plate number or vehicle color), the partial vehicle data could be analyzed and refined. The partial plate number, vehicle color, and CRSS member records might be matched to determine if the target vehicle is a CRSS Member. If a match is made, the CSD of the target member may be?pinged’. For its current geolocation, and, if the CSD of the target member is located in close proximity to the vehicle, the vehicle ID data can be added with additional data from the account record. Similar methods could be used to match partial vehicle ID data with target vehicle identifyrs from prior tagging transactions, and further supplement the vehicle information data.

“GPS data” might include raw GPS component telemetry. Once it has been used to determine the initiating devices’ geolocation (and/or speed, and direction), it is not necessary to store in the tag transaction and can be discarded.

“In embodiments that contain telemetry data about vehicle identification data or safety data that have been gathered from the CSD sensor components or connected telemetry device sensors, all or part may be analyzed at CRSS; the data may be supplemented with analysis or partially discarded (e.g. Certain raw telemetry, such as data about vehicles that are not the target of the tag request, is discarded.

“For example, vehicle identification data can be extracted from telemetry data by analysing raw wireless network traffic as described above in Example T2. The gathered network user IDs can be compared against existing vehicle data or member data to provide additional information. The extraneous network telemetry can be discarded after the vehicle identification data has been determined. Referring to Example T3, images and video footage that are 1) not related to vehicles near the target vehicle, 2) indeterminate or lacking any useful supplemental information, or 3) beyond what is necessary to validate the tag request may be discarded.

“Similarly, any telemetry data that could enhance safety data from an array of sensors or telemetry devices associated to the CSD can also be analyzed and then discarded. Example T4 can analyze the accelerometer data to determine if there was sudden braking or any other rapid jerky movements. The data that is useful can then be refined and discarded.

Interconnections with other data sources can enhance vehicle identification and/or safety data in certain embodiments (e.g. 141). Another type of data source is a weather system that provides weather data, such as visibility, precipitation, wind speed and temperature, localized via geolocation. A service that provides real time or near-real-time traffic conditions such as average traffic speeds, accident conditions and travel times is another type of data source. You can send requests that include the GPS location of the initiating device and receive responses using the API of these services. These services may be public or private.

Click here to view the patent on Google Patents.