Method and apparatus for enabling map updates using a blockchain platform

FIELD OF THE INVENTION

0001This present invention refers generally to techniques for performing electronic map updates in autonomous vehicles. More specifically, the present invention is directed to a solution for providing and validating map updates globally for autonomous vehicles using blockchain technology.

BACKGROUND

0002Autonomous vehicles may rely heavily on pre-stored map data for map-assisted navigation. As autonomous vehicles increase in prevalence, it is exceedingly important to provide the vehicles with reliable and current map updates in real-time to allow them to react to changing conditions caused by, for example, road closures, traffic conditions, etc. in a time-sensitive fashion. In particular, areas such as construction zones often change quickly—causing prior map data of the areas to be inaccurate or obsolete. Consequently, the autonomous vehicle needs to not only be able to detect the construction zones, but also needs to be able to decide how the vehicle should maneuver through these zones. Providing the most up-to-date available map information to autonomous vehicles in real-time is, therefore, vital for the operation of the vehicles.

0003Currently, all known vendors providing map data for autonomous vehicles use their own proprietary format when communicating both maps or map updates to autonomous vehicles. No consistent mapping platform or map update format has emerged as a standard within the vendor group. As a result, no standardized and scalable working solution for map update support exists in the industry today, and any solutions presented by the respective vendors differ and remain isolated from each other. Furthermore, the isolated solutions that emerge may be controlled by at least one organization and/or entity in a select geo-region. This type of control is blocking the autonomous driving industry from acquiring proper maps and map updates instantly in every geo-region.

0004In a typical scenario, map update information is sent to a vendor proprietary server that is not open to receiving map updates from outside the vendor's ecosystem. Accordingly, there is no common platform or format available that solves the map update problem globally and democratizes map updates or the validation of the map updates. Furthermore, there is no way to check the accuracy of map updates provided by a given vendor, which makes industry-wide adoption of any particular solution unfeasible. This is problematic as autonomous vehicles become more prevalent because, without a consistent format or platform for exchanging and validating map updates, vehicles will be prevented from seamlessly exchanging vital location and route-related information between each other.

SUMMARY OF THE INVENTION

0005This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the invention, nor is it intended to be used to limit the scope of the invention.

0006Aspects of the present invention are directed to techniques for using a blockchain mechanism to provide a uniform platform and format for processing, exchanging and validating map updates associated with an electronic map that may be used by autonomous vehicles. The blockchain provides a secure, transparent and decentralized distributed database and platform capable of being updated by various different vendors (e.g., Original Equipment Manufacturers or automotive manufacturers (OEMs), mapping companies, map update companies, companies that deliver ground truth data, semiconductor companies, software provider companies, companies that rely on data from GPS devices, and suppliers that supply parts, e.g., sensors, or systems to the OEMs (e.g., Tier 1, Tier 2 and Tier 3 suppliers), etc.) that utilize the uniform map platform and update format associated with the blockchain. According to one aspect of the present invention, one or more map servers can be configured as nodes on the blockchain—the nodes accept map update communications from various different vendors and sources (including sensors and cameras on autonomous and non-autonomous vehicles) to update and maintain a server-based electronic map.

0007According to one aspect of the invention, the map data in the blockchain is held in an interlinked network of computers, which is not necessarily owned or run by any central authority. While several members of a mapping ecosystem may be able to make updates to the map data, in one embodiment, a single vendor may be responsible for operating the cloud platform on which the blockchain is implemented. Each contributor to the ecosystem attempting to make an update to the blockchain will typically need to be able to communicate using the consistent format and protocol of the blockchain. Alternatively, in one embodiment, the operator of the cloud platform may provide the various contributors to the ecosystem with an application programming interface (API) that, among other things, converts data that is in a vendor-specific format to a unified format compatible with the blockchain.

0008According to yet another aspect of the invention, the blockchain platform for map updates would be a semi-public ledger accessible only by users that are authorized, e.g., autonomous vehicles, survey cars, etc. or vendors that are part of the ecosystem and have active subscriptions to the mapping platform.

0009According to one or more embodiments, map updates are treated as a type of crypto-asset and the blockchain platform is used to trade map updates between the car units. For example, a crypto-asset referred to as a Map Update Token (MUT) may be used for trading map update information between autonomous car units. The MUTs may be used, inter alia, to reward vendors and end-consumers (or drivers) for providing valid map updates to the blockchain. The MUTs may also be used to track the reputation score associated with drivers and vendors. Further, the MUTs may be used to control access to the mapping data on the blockchain.

0010According to an aspect of the present invention, a solution is proposed for attaining consensus for map updates between the various interlinked nodes on the blockchain. Embodiments of the present invention attain consensus for the map updates provided to the blockchain by dynamically selecting and performing at least one of a tuple of multiple proofs, namely: a) Proof of Location (where the location of a map update is verified via other vehicles); b) Proof of Iterations (where a particular update is validated as true only after a number of similar updates are received); c) Proof of Safety that may include at least one proof, such as (without limitation): Proof of Functional Safety, Proof of Safety of the Intended Function, Proof of System Safety, and alike (any combination of risk avoidance, risk mitigation, prevention, validation, authorization techniques may be used) and d) Proof of Physical Delivery (the data authenticates its origin and accuracy). In one embodiment, the selecting of one or more proofs may be dynamic and may be dependent at least, in part, on a number of factors, for example, available sensor configurations, external conditions and the complexity of the environment.

0011More specifically, in one embodiment, a server-based method for updating map data using a blockchain is presented. The blockchain comprises data for maintaining the global map of a predetermined geographic area. The method comprises storing the blockchain at a server, where the blockchain is a semi-public distributed database including a plurality of data records, each data record being associated with an update to the global map. The method further comprises receiving a message associated with a map update to the global map, where the message comprises information pertaining to a map update for a particular route. Consensus regarding the map update is determined by evaluating the map update. The evaluating comprises dynamically selecting and performing at least one of a plurality of “proofs.” The plurality of proofs may include one or more of a proof of location, a proof of iterations, a proof of physical delivery and a proof of safety. In response to validating the map update against the plurality of proofs, the method comprises generating a data record associated with the map update. Subsequently, the blockchain is updated to include the generated data record and, thereafter, the generated data record is electronically transmitted to a plurality of nodes in the blockchain.

0012In some embodiments, the message is formatted based on a data format standard compatible with the blockchain. In other embodiments, the message is formatted based on a proprietary data format standard of a vendor, where the message is converted from the propriety data format of the vendor to the data format standard compatible with the blockchain prior to generating consensus regarding the map update.

0013In some embodiments, performing the proof of location comprises validating a map update received by a first mobile unit after a location of the first mobile unit is verified by a map update of a second mobile unit.

0014In some embodiments, performing the proof of iterations comprises validating a map update received by a first mobile unit after the map update of the first mobile unit is verified by an analogous map update of a second mobile unit, and after a route associated with the map update of the first mobile unit has been verified a threshold number of times by one or more mobile units.

0015In some embodiments, performing a proof of physical delivery comprises automating a shipment of data associated with the global map and corresponding map updates to a data center wherein the server is maintained and adding a tracking number associated with the shipment to the blockchain.

0016In some embodiments, performing a proof of safety comprises performing multiple iterations for the proof of location and the proof of iterations.

BRIEF DESCRIPTION OF THE DRAWINGS

0017The accompanying drawings are incorporated in and form a part of this specification. The drawings illustrate embodiments. Together with the description, the drawings serve to explain the principles of the embodiments:

0018<figref idref="DRAWINGS">FIG. 1</figref> is a diagram that illustrates the challenges associated with the conventional techniques in which map updates are handled.

0019<figref idref="DRAWINGS">FIG. 2A</figref> is a diagram that illustrates the manner in which blockchain technology can be used to provide a standardized mechanism for providing map updates in a mapping ecosystem in accordance with an embodiment of the present invention.

0020<figref idref="DRAWINGS">FIG. 2B</figref> is a diagram that illustrates an alternative embodiment for storing electronic maps and updates in a mapping ecosystem in accordance with an embodiment of the present invention.

0021<figref idref="DRAWINGS">FIG. 3</figref> illustrates the manner in which vehicles may connect to the map cloud platform on which the blockchain is implemented to provide map updates in accordance with an embodiment of the present invention.

0022<figref idref="DRAWINGS">FIG. 4</figref> is a diagram that illustrates the manner in which a proof of location can be established in accordance with an embodiment of the present invention.

0023<figref idref="DRAWINGS">FIG. 5</figref> illustrates the manner in which a proof of iterations can be established in accordance with an embodiment of the present invention.

0024<figref idref="DRAWINGS">FIG. 6</figref> is a flow diagram that illustrates an exemplary computer implemented method in which a proof of physical delivery can be established in accordance with an embodiment of the present invention.

0025<figref idref="DRAWINGS">FIG. 7</figref> depicts a flowchart of an exemplary computer implemented process for validating map updates using a blockchain in accordance with an embodiment of the present invention.

0026<figref idref="DRAWINGS">FIG. 8</figref> depicts a flowchart of an exemplary computer implemented process for maintaining map data using a blockchain in accordance with an embodiment of the present invention.

0027<figref idref="DRAWINGS">FIG. 9</figref> is a data flow diagram that illustrates an exemplary computer implemented method for updating a token account associated with a client in accordance with an embodiment of the present invention.

0028<figref idref="DRAWINGS">FIG. 10</figref> illustrates an exemplary computer system for implementing embodiments of the present invention.

DETAILED DESCRIPTION

0029Reference will now be made in detail to the preferred embodiments of the invention, a method and system for using a blockchain mechanism to provide a uniform platform and format for processing, exchanging and validating map updates associated with an electronic map that can be used by autonomous vehicles, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it will be understood that they are not intended to be limit to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope as defined by the appended claims.

0030Furthermore, in the following detailed descriptions of embodiments of the invention, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be recognized by one of ordinary skill in the art that the invention may be practiced without these specific details. In other instances, well known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the invention.

0031Some portions of the detailed descriptions that follow are presented in terms of procedures, steps, logic blocks, processing, and other symbolic representations of operations on data bits that can be performed on computer memory. These descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. A procedure, computer generated step, logic block, process, etc., is here, and generally, conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

0032It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present invention, discussions utilizing terms such as “storing,” “receiving,” “authenticating,” “converting,” “evaluating,” “updating,”, “refining,” or the like, refer to the action and processes of a computer system or integrated circuit, or similar electronic computing device, including an embedded system, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

0033Embodiments of the invention are directed to novel solutions for providing a uniform platform and format for processing and validating map updates associated with an electronic map for autonomous vehicles using a blockchain mechanism.

Conventional Mapping Systems and Challenges Associated Therewith

0034Vendors for conventional mapping systems used in autonomous vehicles typically utilize their proprietary format when communicating both map information or map updates to autonomous vehicles. Accordingly, there does not presently exist a standardized mapping platform, format, or map update format in the mapping industry. Because no standardized, scalable solution for supporting map updates currently exists that also supports multiple geo-regions and complies to national policies, any solutions presented by the various vendors differ and remain isolated from one another. Further, because vendors are not able to exchange information freely, they are forced to rely on fragmented coverage and/or expensive means such as using survey cars to update their map information.

0035Vendors that may provide mapping solutions for autonomous vehicles may include mapping companies, map update companies, automotive manufacturers (OEMs), companies that deliver ground truth data, semiconductor companies, software provider companies, companies that rely on data from GPS devices, and suppliers that supply parts, e.g., sensors, or systems to the OEMs (e.g., Tier 1, Tier 2 and Tier 3 suppliers). It should be noted that producers of the autonomous car development platforms, e.g., NVIDIA DRIVE™, for instance, may also provide their own mapping solutions that are technically and regionally scalable. The autonomous car development platform can be a scalable artificial intelligence (AI) driven platform—built around deep learning—that, among other things, provides mapping technology for autonomous vehicles and enables automakers and mapping companies to rapidly create high-definition (HD) maps, light HD maps, light maps, standard navigation maps, and alike, and also to maintain them. Typically, the platform is capable of fusing data from at least one or multiple cameras, as well as lidar, radar and ultrasonic sensors configured in the autonomous vehicle to understand the full 360-degree environment around the car to produce a robust representation, including static and dynamic objects. Further, an autonomous vehicle configured with the platform is also capable of precisely localizing itself to an HD map (also known as ‘localization’) and plan a safe path forward. Deep neural networks are used for the detection and classification of objects to increase the accuracy of the fused sensor data.

0036<figref idref="DRAWINGS">FIG. 1</figref> is a diagram that illustrates the challenges associated with the conventional techniques in which map updates are handled. Drivers of non-autonomous vehicles typically receive their mapping data from the GPS systems pre-configured into their vehicles (provided by the OEM) or through independent mapping companies (e.g., mapping companies that provide data to GPS device manufacturers). For example, conventional Car A in <figref idref="DRAWINGS">FIG. 1</figref> receives mapping information from an OEM cloud <b>110</b> (maintained by the manufacturer of Car A), wherein the data is formatted using proprietary format A used by the respective OEM. Similarly, conventional Car B receives mapping data from the mapping company cloud <b>120</b> (maintained by a company that provides mapping data and services), wherein the data is formatted using proprietary format B used by the respective mapping company.

0037A developer of an autonomous car development platform <b>190</b> for autonomous vehicle C may also have their own proprietary format C that is used to store and exchange mapping data stored in cloud server <b>130</b>. Developers of the autonomous car development platform <b>190</b> may, nevertheless, be able to collaborate and create partnerships with OEMs, mapping companies to increase the accuracy of the mapping data—resulting in more precise localization and a more robust representation of the environment. As shown in <figref idref="DRAWINGS">FIG. 1</figref>, autonomous car development platform <b>190</b> may be capable of integrating mapping data from other proprietary formats, e.g., proprietary format A and B. While partnerships with other vendors to receive and integrate accurate mapping data is beneficial, there are significant challenges associated with it. Most importantly, there is no common platform or format available that solves the map update problem globally and democratizes map updates, authorization, and/or the validation of the map updates. Without a consistent format or platform for exchanging map updates, and for validating map updates in real-time, autonomous vehicles are prevented from seamlessly exchanging vital location and route-related information in real-time between each other.

0038Other less obvious challenges associated with creating a common mapping ecosystem between the vendors include the difficulty of reliably verifying the map updates reported by any particular vendor. The map updates provided by a given vendor need to be trustworthy. To ensure trustworthiness, the source of the mapping data including the updates needs to be traceable. Further, what is required is a mechanism for auditing the map data and holding vendors accountable for the credibility of the updates provided by their respective platforms.

0039Also, the ecosystem needs to be able to provide varying levels of access to the mapping data. For example, a driver of an autonomous vehicle with an integrated autonomous car development platform may only need visible access to the map updates, but may not care about the content of the contribution. A mapping partner, e.g., a mapping company, however, may need to access the content of the map updates provided to authenticate the content or to make decisions based on the content.

0040The mapping data in the ecosystem and their sources need to be transparent, while at the same time protecting the privacy of the vendors and the users of the ecosystem. Other requirements of the navigation ecosystem may include transparent pricing for access to the ecosystem, accurate billing, and a mechanism for rewarding drivers and vendors for providing accurate map updates.

0041Finally, as mentioned previously, most vendors will rely on expensive means such as survey cars to update their map information. While survey cars are equipped with several sensors and are capable of generating accurate mapping data, they are expensive and inefficient. Survey cars, for example, capture changes in routes in real-time, but they only drive a limited amount of time and on a limited number of roads. If a particular route changes as a result of construction work, a survey car may not be able to update the map information until it makes at least one or more passes through the route. At present, because of the inability to freely exchange map-related information, no vendor has been able to find a reliable way of crowd sourcing information to generate map updates at scale and across all regions. In other words, currently there is no reliable and efficient mechanism in place for both non-autonomous vehicles and autonomous vehicles to be able to contribute map updates to a mapping ecosystem across the globe in a manner that would benefit every stakeholder and also result in valid, safe, and authorized map updates.

Blockchain Mechanism for Exchanging and Validating Map Updates in Real Time

0042Embodiments of the present invention provide a uniform platform and format for processing and validating map updates for updating an electronic map that can be used by autonomous vehicles, among other uses. Furthermore, embodiments of the present invention solve the map update problem using an update format and map servers that utilize blockchain technology—specifically, a blockchain able to accept map update communications from various different vendors to update and maintain a server-based electronic map. In one embodiment, map updates are treated as a type of crypto-asset and a crypto-engine associated with a blockchain is used to trade map updates between the car units.

0043<figref idref="DRAWINGS">FIG. 2A</figref> is a diagram that illustrates the manner in which blockchain technology can be used to provide a standardized mechanism for providing map updates in a mapping ecosystem in accordance with an embodiment of the present invention. As shown in <figref idref="DRAWINGS">FIG. 2A</figref>, map updates from various cars (e.g., car A <b>201</b>, car B <b>202</b>, autonomous vehicle C <b>203</b>, etc.) can be stored and validated using a blockchain <b>280</b>, which may be implemented across an interlinked network of cloud computing resources and/or servers (comprising, for example, OEM server <b>210</b>, mapping company server <b>220</b>, autonomous car development platform server <b>230</b>, etc.). Alternatively, in a different embodiment (as will be illustrated in <figref idref="DRAWINGS">FIG. 2B</figref>), the blockchain may be implemented on nodes that are separate from the vendor-managed servers. Note that the interlinked network of servers maintained on the mapping platform <b>250</b> may also comprise servers from mapping companies, companies delivering ground truth data, software provider companies, semiconductor companies, Tier 1 companies, companies who rely on GPS data for their products and services, and other vendors who are part of the autonomous vehicle or mapping data supply chain.

0044In one embodiment, data from OEMs, mapping companies, companies delivering ground truth, semiconductor companies, software provider companies, Tier 1 suppliers, companies who utilize GPS data, etc. may be part of the map cloud platform <b>250</b> on a single and/or distributed server. In another embodiment, a server or data from at least one of the representative vendor companies may be part of the mapping cloud platform <b>250</b> on a single and/or distributed server.

0045In yet another embodiment, at least one of the representative companies from a pool of OEMs, mapping companies, companies delivering ground truth data, semiconductor companies, software provider companies, Tier 1 suppliers, companies who utilize GPS data, government organizations, dedicated software providers, etc. may be part of the map cloud platform <b>250</b> on a single and/or distributed server. This embodiment would be particularly useful in geographic areas where government bodies would be part of the mapping ecosystem supply chain.

0046The blockchain <b>280</b> uses a secure, transparent and decentralized distributed database capable of being updated by various different map vendors and/or other entities, where the map updates are added to the blockchain <b>280</b> using a consistent format and/or after being converted to a consistent format. It should be noted that because blockchains are not designed to act as a storage medium, transactions, e.g., map updates provided to the blockchain tend to be relatively small, and large amounts of data pertaining to the blockchain are stored “off chain” with pointers and references stored within the chain and/or in cache memory, and alike.

0047In one embodiment, each entity attempting to make a map update to the blockchain communicates using the format and protocol used by the blockchain, thereby, ensuring consistency between the various vendors. Alternatively, in a different embodiment, such as the one illustrated in <figref idref="DRAWINGS">FIG. 2A</figref>, map update data communicated from at least one of the vendors may need to be converted to a consistent format before being added to the blockchain <b>280</b>. As shown in <figref idref="DRAWINGS">FIG. 2A</figref>, map updates made by autonomous vehicle C <b>203</b> use the blockchain format C and, accordingly, for data being transmitted from autonomous vehicle C, data ingestion module <b>240</b> may simply provide data and time synchronization. In other words, the format of the data from autonomous vehicle C does not need to be converted prior to updating blockchain <b>280</b>, but the data may need to be synchronized by the data ingestion module <b>240</b>. By contrast, updates from non-autonomous vehicle A <b>201</b> using proprietary format A and non-autonomous vehicle B <b>202</b> using proprietary format B are converted using data ingestion module <b>240</b> in the map cloud platform <b>250</b> before being added to the blockchain. It should be noted that for non-autonomous vehicles (e.g., car A <b>201</b> and car B <b>202</b>) to be able to contribute map updates, they may need to be equipped with cameras and other types of sensors (e.g., lidar, radar and ultrasonic sensors) that are calibrated to capture localization and route-related information.

0048In one embodiment, servers <b>210</b>, <b>220</b> and <b>230</b> are computer system nodes on blockchain <b>280</b> that work together to manage map related data and transactions, e.g., map updates pertaining to the map data. It should be noted that while the discussion herein is limited to three exemplary nodes, a typical blockchain will comprise several nodes. Any transaction, e.g., a map update communicated to one of the nodes—from an autonomous or non-autonomous vehicle—may be broadcast to some or all of the other nodes. The nodes receiving the transaction need to confirm and verify the transaction to ensure that the transaction is authentic. When the recipient nodes have reached a consensus that the transaction is legitimate and can be accepted, a new block on the blockchain <b>280</b> can be created. The block may typically include other confirmed transactions as well. Subsequently, the block of confirmed transactions, e.g., confirmed map updates is recorded on the blockchain <b>280</b>. In other words, the block is time-stamped, linked to the immediately preceding block and added to the blockchain.

0049In one embodiment, the blockchain platform <b>280</b> for map updates would be a semi-public ledger and accessible only by users that are authorized, e.g., drivers of authorized autonomous vehicles or vendors that are subscribing members of the ecosystem, e.g., OEMs, Tier 1 suppliers, etc. Further, in an embodiment, private keys for accessing and making contributions to the blockchain platform may be assigned only to vendors or subscribers to the mapping platform that contribute accurate and reliable map updates. In such an embodiment, all subscribing members may have visibility of any data contribution made to the platform, but access control mechanisms such as (without limitation) encrypted keys and smart contracts may be used to limit access to the contents of the contributions to only the members holding the private keys. Further, the ability to make updates may be limited only to members holding private keys.

0050In one or more embodiments, the blockchain <b>280</b> may not necessarily be owned or run by any central authority, in one embodiment, one of the vendors, e.g., the developers of the autonomous car development platform <b>290</b> (or any other vendor or party that is part of the mapping ecosystem) may establish and manage a map cloud platform <b>250</b> on which the blockchain may be maintained. In such an embodiment, the vendor managing the cloud platform <b>250</b> may provide an application programming interface (API) to the other vendors in the ecosystem, where the API, among other things, may be programmed to enable the vendor-operated servers to interface with the blockchain <b>280</b>. For example, an API may be provided to the vendors associated with servers <b>210</b> and <b>220</b> to allow them to convert the data from their proprietary format into the unified format of the blockchain <b>280</b>.

0051In one embodiment, the electronic maps maintained by the blockchain can either be traditional HD maps <b>276</b> (provided by, for example, digital mapping companies) or crowd-sourced maps <b>275</b> (provided by, for example, geospatial start-up companies). These electronic maps are normalized to the unified format before they are incorporated into the blockchain. The blockchain will store the foundational HD maps (e.g., ground truth maps) and also any updates to these HD maps (that may, for example, be received through data ingestion module <b>240</b>).

0052<figref idref="DRAWINGS">FIG. 2B</figref> is a diagram that illustrates an alternative embodiment for storing electronic maps and updates in a mapping ecosystem in accordance with an embodiment of the present invention. As noted above, in some embodiments, the blockchain may be implemented on separate nodes from the vendor servers on the map cloud platform <b>250</b>. As shown in <figref idref="DRAWINGS">FIG. 2B</figref>, the blockchain platform <b>260</b>—comprising the nodes of the blockchain—are implemented on the map cloud platform <b>250</b> separately from the vendor servers, e.g., external vendor server <b>262</b>. In this embodiment, the blockchain platform <b>260</b> stores, fuses, and processes the data from the various vendors on an ecosystem blockchain. The blockchain platform also stores the foundational maps (e.g., ground truth data, HD maps, light HD maps, SD maps, 3D map content, weather conditions, day and night conditions, points of interest, and alike) and updates to these maps. The foundational maps may either be traditional HD maps <b>276</b> or crowd-sourced maps <b>275</b>, as mentioned previously.

0053The data ingestion module <b>240</b> is capable of receiving data and generating updates to the maps. As discussed in connection with <figref idref="DRAWINGS">FIG. 2A</figref>, the data ingestion module will, among other things, convert the data from a vendor proprietary format to the unified format of the blockchain. For example, in the case of non-autonomous vehicle <b>201</b>, the data ingestion module may be operable to receive the data in a vendor-specific format and convert the data into the blockchain format. In the case of autonomous vehicle <b>203</b>, however, the data may already be in the blockchain format. In this case, the data ingestion module <b>240</b> may provide data and time synchronization services prior to adding the data to the blockchain.

0054Each of the vendor servers, including server <b>262</b>, uses the API <b>261</b> provided by the manager of the map cloud platform <b>250</b> in order to communicate with the blockchain and convert their map updates to the unified format required by the blockchain. Further, the API also enables the vendors to receive map updates from the blockchain seamlessly using a format and protocol that can be processed the respective vendors.

0055Typically, blockchains are associated with crypto-assets, which are digital assets designed to work as a medium of exchange that use cryptography to secure and verify transactions made on the blockchain and control the creation of additional units. As mentioned above, embodiments of the present invention use map updates as a type of crypto-asset, and a crypto-engine associated with the blockchain is used to trade map updates between the car units. In one embodiment, the assets of the blockchain of the present invention would also include map related data and map tiles. For example, a crypto-asset referred to as a Map Update Token (MUT) may be used as an exchange medium for trading assets, e.g., trading map update information between autonomous car units. The MUTs are stored and exchanged in one unified format using map cloud platform <b>310</b>. The MUTs may be used, inter alia, to reward vendors and end-consumers (or drivers) for providing valid map updates to the blockchain. In other words, MUTs are used to assign value to drivers and vendors for providing reliable and accurate map updates to the mapping ecosystem. In one embodiment, the MUTs may be shared between the involved parties with weighted contributions.

0056According to one or more embodiments, the MUTs may be tied to a monetary incentive that a driver or vendor receives for providing a certain number of accurate map updates. Alternatively, the MUTs may be exchanged for credits that entitle a driver or vendor to receive a certain number of map updates from the mapping system free of charge.

0057According to another embodiment, MUTs can also be used to track the reputation and credibility of a particular driver, driving unit, and/or vendor. A driver may build a reputation score by contributing updates that are not contradicted by or inconsistent with more accurate data from other sources. For example, a driver with a high reputation score may be driving a survey car with more accurate and advanced sensors. Accordingly, map updates from the driver may rarely be superseded by more precise information from other vehicles. Drivers with high reputation scores may, as noted above, be rewarded with MUTs and assigned a private key for contributing their updates to the cloud platform <b>250</b>.

0058The MUTs can, in one or more embodiments, also be used to control access to the mapping data on the blockchain. For example, using (as an example and without limitation) encrypted keys and smart contracts, the map cloud platform <b>250</b> may make map updates available only to members of the ecosystem that have a requisite number of MUTs to acquire the updates. The MUTs, in other words, can be used as currency to purchase, exchange, and/or sell map updates. In one embodiment, the MUTs may only be made available to members that contribute their own map updates to the cloud platform <b>250</b>. In order to receive map updates, members may, for instance, be required to also be contributing members of the ecosystem.

0059According to one or more embodiments, there may be several scenarios in which MUTs can be used for trading map updates. An autonomous or non-autonomous vehicle may earn an MUT for contributing accurate data regarding a particular route or accurate location information pertaining to another vehicle on the road. Similarly, a vehicle may earn an MUT any time it passes through an established route and confirms it. In other words, MUTs may be earned for iterating over known routes. A vendor-operated vehicle, e.g., a survey car may earn tokens by creating new routes and iterating over the routes multiple times. Similarly, vendor-operated vehicles may also earn tokens for creating regular map updates. An autonomous vehicle, e.g., one running autonomous car development platform <b>230</b> may earn tokens by using deep learning or other AI procedures to improve map updates. MUTs may be consumed by all types of vehicles by either consuming map-related data from the blockchain or by consuming map updates.

0060<figref idref="DRAWINGS">FIG. 3</figref> illustrates the manner in which vehicles may remotely connect to the map cloud platform on which the blockchain is implemented to provide map updates in accordance with an embodiment of the present invention. Both autonomous and non-autonomous vehicles may be allowed to consume or provide updates to the blockchain implemented on map cloud platform <b>310</b>. As noted above, the non-autonomous vehicles will typically be equipped with a set of sensors or cameras that are able to capture route-based information.

0061As shown in <figref idref="DRAWINGS">FIG. 3</figref>, OEM X server <b>320</b> connects with non-autonomous vehicles <b>351</b>, <b>352</b> and <b>353</b> and OEM Y server <b>330</b> connects with non-autonomous vehicles <b>354</b>, <b>355</b> and <b>356</b>—the vehicles transmit their updates to respective databases on OEM X server <b>320</b> and OEM Y server <b>330</b>. The updates are, thereafter communicated to nodes on the blockchain implemented on map cloud platform <b>310</b> for verification. As mentioned previously, the map updates from servers <b>320</b> and <b>330</b> may already be in the unified format of the blockchain or, alternatively, may need to be converted prior to adding the updates to a block on the blockchain. Note, as mentioned previously, the vendor managing the blockchain on the map cloud platform <b>310</b> may provide each of the vendors in charge of servers <b>320</b> and <b>330</b> with an API to communicate their map updates to the map cloud platform.

0062Similar to the non-autonomous vehicles, autonomous vehicles <b>357</b> and <b>358</b> shown in <figref idref="DRAWINGS">FIG. 3</figref> communicate their updates to a server <b>340</b> maintained by, for example, a developer of an autonomous car platform (or any other vendor that is part of the ecosystem). Server <b>340</b> may, for example, already communicate in a format consistent with the blockchain maintained on platform <b>310</b>. Accordingly, server <b>340</b> may transmit the map update transactions directly to nodes on the blockchain without any need of conversion. It should be noted that both autonomous and non-autonomous vehicles may also request and consume map updates from the platform <b>310</b>. In one embodiment, servers <b>320</b>, <b>330</b> and <b>340</b> may be part of the map cloud platform <b>310</b> and may also be configured as nodes on the blockchain.

0063In one embodiment, the crypto-engine executing on platform <b>310</b> may enable blockchain-based verification and validate map updates whenever a vehicle is connected to the blockchain platform. Accordingly, instead of having a mapping company, an OEM, or any other vendor in the mapping ecosystem rely exclusively on survey cars or autonomous vehicles, the blockchain platform can be scaled up easily to expedite the progress of map updating in real-time with a proper validation mechanism and by every-day drivers, e.g., drivers of vehicles <b>351</b> to <b>356</b>. Further, using the blockchain platform allows the expense and benefit of updating maps to be shared between multiple stakeholders, e.g., end consumers, OEMs, Tier 1 to Tier 3 suppliers etc.

0064Further, by using a blockchain-based mapping ecosystem, embodiments of the present invention advantageously provide a standardized mapping platform with a consistent format that solves the map update problem globally and democratizes the validation of map updates. Other challenges associated with conventional mapping solutions are also addressed by the mapping ecosystem of the present invention. For example, because blockchains are transparent and decentralized distributed databases, and each block is accompanied with a timestamp (and may be accompanied by a preceding block and a successor block), using a blockchain mechanism will allow traceability of any irregularities, e.g., any rogue updates to the map can be easily detected, their origin determined, and malicious updates scrapped. As a result, users of and contributors to the MUT-based system can be held accountable for the quality of the map updates provided and likewise rewarded or compensated for useful updates. Moreover, the transparency of the blockchain allows for transparent pricing for access to the ecosystem, accurate billing, and a mechanism for rewarding drivers and vendors for providing accurate map updates, e.g., by using MUTs.

0065Further, by implementing a semi-public blockchain for the mapping ecosystem, embodiments of the present invention advantageously allow access to the ecosystem to be controlled and the privacy of its members to be protected.

0066In a conventional blockchain platform, a network of communicating nodes performs blockchain maintenance. Each node validates transactions and adds them to its own local copy of the blockchain, and, subsequently, broadcasts block additions to other nodes. All these operations are performed in such a way that a distributed consensus emerges among network nodes about the information stored in the blockchain. If a block is forged and added to the chain, other nodes will find the data to be untrue. For example, in the Bitcoin crypto-currency system, the blockchain is used to store financial transaction records. Bitcoin attains consensus by using a Proof-of-Work algorithm, which is used to confirm transactions and produce new blocks to the chain. With Proof-of-Work, the responsibility for confirming transactions and arranging blocks (e.g. managing block additions) bears on special nodes called miners who compete against each other to complete transactions on the network and are rewarded.

0067By comparison, and importantly, embodiments of the present invention attain consensus for the map updates provided to the blockchain by using a tuple of multiple proofs, namely: a) Proof of Location (where the location of a map update is verified via other vehicles); b) Proof of Iterations (where a particular update is validated as true only after a number of similar updates are received); c) Proof of Safety (a combination of different risk avoidance, risk mitigation, prevention, validation, authorization techniques are used) that comprises at least one proof from the pool of safety proofs, such as, for example, Proof of Functional Safety; Proof of Safety of the Intended Function; Proof of System Safety, and alike; and d) Proof of Physical Delivery (the data authenticates its origin and accuracy).

0068It should be noted that not all proofs are required for consensus to be attained between the nodes. Consensus between the nodes may be attained with less than all four proofs discussed herein. For example, some embodiments of the present invention may only require a proof of location and a proof of iterations depending on the implementation choice and dependencies in such an implementation. By way of further example, some embodiments may only require one proof on any given occasion, but, at other times, a tuple of at least two proofs may be used. Embodiments of the present invention may be configured to dynamically and interchangeably select one or more proofs from the tuple of proofs based on several factors including, but not limited to, available sensor configurations, external conditions and the complexity of the environment.

0069Proof of Location

0070According to embodiments of the present invention, the blockchain <b>280</b> performs proof of location in order to verify the veracity of a location associated with a map update communication from a vendor or vehicle. To attain consensus on the location of a vehicle providing an update, a second map update communication that is within a threshold duration of time and corroborates the location of the vehicle providing the first map update communication is required from at least one other vehicle in proximity to the vehicle providing the update in order to validate the location of the reporting vehicle—this provides some validation of the truthfulness and accuracy of the reported update. In other words, at least two autonomous vehicles with an active connection to the blockchain platform would be required to provide a valid update that is based on the location of an autonomous vehicle. Or, alternatively, at least one other vehicle would need to report the location of the reporting vehicle so that the map update of the reporting vehicle can be verified at least to its reported location.

0071<figref idref="DRAWINGS">FIG. 4</figref> is a diagram that illustrates the manner in which a proof of location can be established in accordance with an embodiment of the present invention. As mentioned previously, an autonomous vehicle configured with the autonomous car development platform <b>230</b> is typically capable of precisely localizing itself to an HD map (also known as ‘localization’). If car <b>452</b> reports an update to its respective server with localization information, the update will typically need to be verified to ensure that car <b>452</b> is not reporting incorrect information (either due to malfunction or malicious actors). Similarly, car <b>450</b> will also transmit localization information to its respective server, which will need to be authenticated. Importantly, because cars <b>450</b> and <b>452</b> are in close proximity to one another, their respective cameras and sensors can detect and corroborate the locations of the other. For example, car <b>450</b> can confirm the localization information provided by car <b>452</b> and vice versa. Each car can independently transmit its confirmation of the other's location also to its respective server. In fact, this localization information may be reported to the respective server on a periodic basis.

0072In blockchain networks any transaction reported to a server or node on the blockchain will typically be communicated to one or more other nodes to attain consensus before the transaction can be recorded on the blockchain. When cars <b>450</b> and <b>452</b> report the localization information and a confirmation of each other's locations to their respective servers, the information is distributed to other nodes in the blockchain. Thereafter, the nodes can reach a consensus that the localization information provided by each of the cars is indeed accurate. With the received information, the server can match the location of the update from car <b>452</b> with the reported location of car <b>450</b> that also reports the presence of car <b>452</b> in close proximity. Proof of location is satisfied if the locations match. The map update information may then be added to a block and recorded in the blockchain (assuming the other proofs comprising the tuple of proofs are valid as well).

0073If, for example, car <b>452</b> reports confirmation information pertaining to the location of car <b>450</b> to its server, however, the information reported by car <b>452</b> does not corroborate with the localization information provided by car <b>450</b> to its own respective server, then both sets of information may be tagged as malicious or incorrect and be dismissed—unless other confirmations are received that validate either the information reported by car <b>450</b> or car <b>452</b> as being more accurate.

0074It should be noted that autonomous vehicles are not the only ones limited to providing localization information. Non-autonomous vehicles may also be configured with the intelligence in their GPS systems to provide localization information and may, further, be equipped with sensors and cameras to provide location confirmations for other vehicles on the road.

0075Proof of Iterations

0076In accordance with an embodiment of the present invention, the blockchain uses proof of iterations to verify the veracity of a map update which can help to weed out incorrect map updates which can be caused either by malfunctioning equipment, faulty and/or erroneous software algorithms, faulty and/or erroneous AI-based perception algorithms, and/or malicious actors. Multiple iterations (e.g., multiple reporting) on a single route will be needed to validate a map update to a particular route. For example, if two cars use the same route, and are providing a similar update report with respect to the route, then their updates and their routes can be compared and, in response to a determination that both cars used the same route and provided the same update, the route may be flagged as a candidate for a map update. The route itself may be a new route or there may be some update to a pre-existing route that is new.

0077Subsequently, a predetermined number of consistent, corroborating iterations are required for that route in order to update the blockchain. For example, when the platform is considering whether to add a newly discovered route, if the number of iterations required was 10, then either one car would need to use the same route 10 times or 10 different vehicles would each use the route once (or any other combination of cars and times driven totaling at least 10 instances of the driven route). Once the required number of iterations has been attained, the data collected from the various vehicles is unified and added to the blockchain in order to recognize and add the new route to the map. Similarly, if the platform needs to add a new update to a pre-existing route, e.g., as a result of an accident or construction work, a predetermined number of iterations need to be performed for that update to be integrated into the blockchain as a valid update. These updates may be performed by the same car traveling the same route multiple times or by multiple cars also traveling the same route. In one embodiment, the blockchain may require at least two different cars to perform the iterations in case one of the cars was a malicious actor or was providing compromised data as a result of malfunctioning cameras, sensors, and/or software.

0078<figref idref="DRAWINGS">FIG. 5</figref> illustrates the manner in which a proof of iterations can be established in accordance with an embodiment of the present invention. Car <b>550</b> and Car <b>552</b> both travel a new route for the first time, where car <b>550</b> is traveling from west to east, while car <b>552</b> is traveling from east to west. Both cars can ascertain that they are traveling the same route by comparing the routes. For example, car <b>550</b> determines that it located building <b>510</b> ten yards to the east and 30 yards to the north, while car <b>552</b> determines that it located building <b>510</b> 30 yards to the west and 70 yards to the north. Similarly, other infrastructural points of interest in the periphery including apartment complex 520 may be used to generate several other data points in order to triangulate the positions of the cars. After data regarding all the points of interest is transmitted to the nodes and normalized, the nodes use the normalized data to attempt to reach a consensus that both cars are traveling the same route. In other words, the nodes cross-reference the data from both cars and compare to see if the two data sets reinforce and support each other.

0079It should be noted that cars need not necessarily travel toward each other or in opposing directions in order to generate a candidate for a map update. In some embodiments, two cars traveling in the same direction (e.g., a multi-level road network such as a flyover or overpass) may also be able to generate a candidate for a map update if the nodes are able to cross-reference the two sets of data and attain consensus.

0080In response to a determination that both cars traveled the same route and provided a consistent update, the route may be flagged as a candidate for a map update. Subsequently, multiple iterations—either by cars <b>550</b> or <b>552</b> or other cars—may need to be performed on the same route during a predetermined timeframe in order to create a new block on the blockchain comprising the new route. If the two sets of data do not corroborate each other, they are either discarded or temporarily saved to see if further updates may confirm one of the data sets over the other.

0081The procedure for determining map updates, in one embodiment, needs to take into account the timing of the various updates provided. Because the blockchain keeps track of the timestamps of the various transactions, the timing for each attempted update can easily be extracted from the blockchain. For instance, for a given map segment, the requisite number of iterations needs to take place within a predetermined timeframe in order to be considered for a valid map update. If one or more of the iterations do not corroborate the same information as the majority of the other iterations by other vehicles, they can be discarded as having been reported by vehicles with malfunctioning equipment or malicious actors. For example, if forty iterations are performed on a particular route and all but two are reported to confirm the same data, the two aberrant iterations can be discarded. Requiring several iterations during a predetermined time period also helps eliminate short-term problems on a particular route from being updated on the blockchain. For example, if a temporary obstruction is caused by a delivery truck, there may not be enough iterations performed for the temporary obstruction to be approved as a valid map update on the blockchain before the obstruction is removed.

0082Further, vehicles passing through the same route at later times will, in one embodiment, confirm the map update. The map update remains valid while other vehicles passing through the same route keep confirming the update. If changes to the route occur and the map update is not valid anymore, a new set of updates would be culled from vehicles using the same route. For example, a route may be updated in the morning by vehicles traveling the route and there may not be any significant changes to the route during the day. Thereafter, all the cars traveling the same route during the day confirm the updates that were provided in the morning and, accordingly, the same map update remains valid through the day. In the evening, however, if construction blocks off part of the route, then new updates may need to be culled from the vehicles. These new updates will need to go through the same validation procedure, e.g., requiring a pre-requisite number of iterations during a predetermined time window.

0083In some embodiments, certain types of updates may be flagged with a higher priority and fewer numbers of iterations may be required in order to push the high priority updates to the blockchain. For example, if any car provides an update regarding an ambulance or fire engine, instead of the requisite <b>10</b>, only 2 iterations may be required to flag it as a valid map update.

0084Proof of Physical Delivery

0085The proof of physical delivery is a consensus based on the physical delivery value chain. Physical consensus is achieved by automating the data shipment from a vehicle to a digital database at a data center for further AI processing. For example, a solid-state drive may be shipped by the owner of an autonomous vehicle containing map related data. In this case, a tracking number may be used as a proof of physical delivery. This verifies both the data authenticity and also its accuracy. By way of another example, a survey car operated by a vendor may need to regularly ship map related data to the digital database maintained by a vendor. In this instance, a proof of physical delivery that can be added to the blockchain in the form of a tracking number helps make the data traceable.

0086Embodiments of the present invention, however, also cover the uploading of all the mapping related information from the car directly to the vendor data center using high speed cellular or W-Fi connections if bandwidth is available.

0087<figref idref="DRAWINGS">FIG. 6</figref> is a data flow diagram that illustrates an exemplary computer implemented method in which a proof of physical delivery can be established in accordance with an embodiment of the present invention. At step <b>610</b>, data is acquired from the sensors placed on a vehicle. This data may be stored on a solid-state drive within the vehicle and may be shipped at step <b>620</b> to a data center—a tracking number is obtained as proof of physical delivery. At step <b>630</b>, the data is curated and annotated in the map cloud platform <b>310</b>. Subsequently, neural network training is performed using the data at step <b>640</b>. In other words, the data gathered from the vehicles is used to train deep learning processes. After the neural network is trained at step <b>650</b>, it is used in autonomous vehicle applications and for autonomous vehicle map application development at step <b>660</b>. Thereafter, at step <b>670</b>, the autonomous vehicles may be test-driven with real-time maps or simulations may be conducted with maps and map updates.

0088Proof of Safety

0089The map maintenance server may perform proof of safety in order to provide reliability with accurate map updates. For example, in one embodiment, proof of safety requires: a) redundancy of implementation and b) diversity of implementation. Requiring multiple different proofs (a diversity of proofs) attains diversity of implementation. Proof of location, proof of iterations and proof of physical delivery, as required by embodiments of the present invention, provide three different or diverse mechanisms of validating the data.

0090Redundancy of implementation is attained by requiring multiple sources for the same updates or multiple iterations of the same update. For example, multiple proofs of location may be required within a particular time range. If two autonomous vehicles are in close proximity, multiple proofs of location may be determined over a period of time with each proof of location tagged with a unique time-stamp. If the multiple proofs of location within a time range all agree with each other, then a proof of safety has also been attained.

0091As noted above, embodiments of the present invention may be configured to dynamically and interchangeably select one or more proofs from the tuple of proofs based on several factors including, but not limited to, available sensor configurations, external conditions and the complexity of the environment. Each node in the blockchain network may be configured with the intelligence to determine the number of proofs that will be required to validate the transaction. For example, if the environment to which the map update applies is complex or the external weather conditions make localizing vehicles challenging, a node may require both proofs of location and iterations to validate a map update transaction.

0092In another scenario, for example, where consistent information is received from multiple platforms regarding iterations made over a given route, a proof of location may not be necessary for a node to validate a map update transaction pertaining to the route. In such an instance, a node may dynamically elect to perform only the proof of iterations to validate the map update. In a different scenario, if an update is received from a highly sensitive, military grade LiDAR in an environment with no other prevailing complexities, a proof of location may be sufficient to validate the transaction. In other words, the proof of iterations may be dropped for a map update transaction that is received from reliable sensor configurations.

0093In one or more embodiments, the information pertaining to the tuple of proofs is maintained in a data structure within the data record associated with a map update. The data structure is dynamic and can comprise information regarding one or multiple proofs, depending on the number of proofs that were required to validate the transaction.

0094In some embodiments of the present invention, a map update is not added to a block in the blockchain with a valid timestamp until proof of safety has been attained.

0095<figref idref="DRAWINGS">FIG. 7</figref> depicts a flowchart of an exemplary computer implemented process for validating map updates using a blockchain in accordance with an embodiment of the present invention.

0096At step <b>702</b>, a blockchain is distributed across servers that are part of the map cloud platform <b>250</b> and comprises data for maintaining a global map of a predetermined geographic area. The blockchain can either be maintained on dedicated nodes within the map cloud platform (e.g., blockchain <b>260</b>) or could also include servers maintained by the various vendors (e.g., blockchain <b>280</b>). The vendors may include mapping companies, OEMs, software provider companies, map update companies, semiconductor companies, companies delivering ground truth data, Tier 1 suppliers, etc. The blocks of the blockchain comprises data records, where the data records pertain to updates to the global map.

0097At step <b>704</b>, a message associated with a map update to the global map is received. The message may be transmitted either by a vehicle or one of the vendors in the mapping ecosystem. The message may pertain to a map update for a particular route and may be timestamped.

0098At step <b>706</b>, the received map update is evaluated by one or more nodes on the blockchain to determine consensus on whether the update is an accurate one. In order to reach consensus, the evaluating comprises selecting and performing at least one of a plurality of proofs including a proof of location, a proof of iterations, a proof of physical delivery and a proof of safety. In one embodiment, the selecting of one or more proofs can be based, in part, on a number of factors, for example, available sensor configurations, external conditions and the complexity of the environment.

0099At step <b>708</b>, a determination is made as to whether consensus was attained and if the proofs validated the map update. If the map update is not validated, then at step <b>716</b>, the message is discarded or stored temporarily until further evaluation can take place. For example, the message may be stored to wait for future updates that may confirm or deny the map update associated with the message.

0100If the map update is validated, then at step <b>710</b>, a data record is generated, where the data record is associated with the map update received. The data record may be part of other data records that are added to a new block on the blockchain.

0101At step <b>712</b>, the blockchain is updated with the new data record and the global map is updated based on the map update in the new data record.

0102At step <b>714</b>, the updated blockchain may be transmitted to other nodes in the blockchain. The other nodes may, for example, update their local copies of the blockchain and perform further validation.

0103<figref idref="DRAWINGS">FIG. 8</figref> depicts a flowchart of an exemplary computer implemented process for maintaining map data using a blockchain in accordance with an embodiment of the present invention.

0104At step <b>802</b>, a blockchain is stored at a server (or node) that is part of a blockchain. The blockchain is distributed across servers that are part of the map cloud platform <b>250</b> and comprises data for maintaining a global map of a predetermined geographic area. The blockchain can either be maintained on dedicated nodes within the map cloud platform (e.g., blockchain <b>260</b>) or could also include servers maintained by the various vendors (e.g., blockchain <b>280</b>). The blocks of the blockchain comprises data records, where the data records pertain to updates to the global map.

0105At step <b>804</b>, a first message is received at the server from a first client, where the first message is associated with a first map update to the global map. The message may pertain to a map update for a particular route. The map update may already be in the unified format of the blockchain and may not need to be further formatted.

0106At step <b>806</b>, a second message is received at the server from a second client, where the second message is associated with a second map update to the global map. The message may pertain to a map update for a particular route, however, unlike the first message, the second message may be in a vendor-specific format and may need to be formatted to make it compatible with the blockchain format.

0107At step <b>808</b>, the first and second clients are authenticated by the server as having valid subscriptions or access privileges for accessing the blockchain.

0108At step <b>810</b>, the second message is converted from the vendor-specific format into a unified format supported by the blockchain.

0109At step <b>812</b>, the first and second map updates are evaluated. The evaluation comprises performing a proof to validate the updates as being accurate.

0110At step <b>814</b>, the blockchain is updated with a new data record based on the first and second map updates and the global map is updated based on the map updates in the new data record.

0111At step <b>816</b>, token accounts for the first and second client are updated, where the token accounts define access privileges to the blockchain. As mentioned previously, the MUTs can, in one or more embodiments, be used to control access to the mapping data on the blockchain. For example, using encrypted keys and/or smart contracts, the map cloud platform <b>250</b> may make map updates available only to members of the ecosystem that have a requisite number of MUTs to acquire the updates. The MUTs, in other words, can be used as currency to purchase or sell map updates. As mentioned previously, according to one or more embodiments, the MUTs may be tied to a monetary incentive that a driver or vendor receives for providing a certain number of accurate map updates. Alternatively, the MUTs may be exchanged for credits that entitle a driver or vendor to consume a certain number of map updates from the mapping system free of charge.

0112<figref idref="DRAWINGS">FIG. 9</figref> is a data flow diagram that illustrates an exemplary computer implemented method for updating a token account associated with a client in accordance with an embodiment of the present invention.

0113At step <b>902</b>, a message is received from a client, e.g., an autonomous vehicle, a survey car, etc. Note that messages may also be received from vendors, e.g., mapping companies, OEMs, software provider companies, semiconductor companies, companies delivering ground truth data, Tier 1 suppliers, etc. The message may either comprise a request to provide an update a global map or to download a map update from the blockchain maintained on the cloud platform.

0114If the message comprises a request to provide a map update, then at step <b>904</b>, a subscription account associated with the client is checked to determine if the client has a valid and active subscription to the mapping platform.

0115Subsequently, at step <b>906</b>, a reputation associated with a client may be checked to determine if the reputation is above a threshold level. If the reputation is above the requisite threshold level, the client may be allowed to make updates to the blockchain. In one embodiment, MUTs can also be used to track the reputation and credibility of a particular driver or vendor. A driver may build a reputation score by contributing updates that do not get corrected or replaced with more accurate data from other sources. Drivers with high reputation scores may be rewarded with MUTs and assigned a private key for contributing their updates to the cloud platform.

0116At step <b>908</b>, the received map update is evaluated by one or more nodes on the blockchain to determine consensus on whether the update is an accurate one. As mentioned previously, in order to reach consensus, the evaluating comprises selecting and performing at least one of a plurality of proofs including a proof of location, a proof of iterations, a proof of physical delivery and a proof of safety. In one embodiment, the selecting of one or more proofs can be based, in part, on a number of factors, for example, available sensor configurations, external conditions and the complexity of the environment.

0117At step <b>910</b>, if the map update is validated, a data record is generated, where the data record is associated with the map update received. The data record may be part of other data records that are added to a new block on the blockchain.

0118At step <b>912</b>, the MUT account associated with the client is adjusted. For example, if the update is validated and recognized to be accurate, the client may be rewarded more tokens and the balance of the MUT account may be increased accordingly.

0119If the received message at step <b>902</b> is associated with a request to consume a map update, then at step <b>914</b>, a subscription account associated with the client is checked to determine if the client has a valid and active subscription to the mapping platform. Further, at step <b>916</b>, an MUT account associated with the client is also checked to determine if the client has enough tokens for consuming map updates.

0120At step <b>918</b>, if the client has access privileges and enough MUTs in the MUT account, a map update is provided to the client in accordance with the request.

0121Finally, at step <b>920</b>, MUT account associated with the client is adjusted. For example, the balance on the MUT account may be deducted to reflect the consumption of new map updates by the client.

0122Exemplary Computing System

0123As presented in <figref idref="DRAWINGS">FIG. 10</figref>, an exemplary system for implementing embodiments includes a general purpose computing system environment, such as computing system <b>1000</b>. For example, computing system <b>1000</b> may be used to implement one of the servers (or nodes) on the blockchain within the map cloud platform at which the updates are received. In its most basic configuration, computing system <b>1000</b> typically includes at least one processing unit <b>1001</b> and memory, and an address/data bus <b>1009</b> (or other interface) for communicating information. Depending on the exact configuration and type of computing system environment, memory may be volatile (such as RAM <b>1002</b>), non-volatile (such as ROM <b>1003</b>, flash memory, etc.) or some combination of the two. Computer system <b>1000</b> may also comprise one or more graphics subsystems <b>1005</b> for presenting information to the computer user, e.g., by displaying information on attached display device <b>1010</b>.

0124Additionally, computing system <b>1000</b> may also have additional features/functionality. For example, computing system <b>1000</b> may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in <figref idref="DRAWINGS">FIG. 10</figref> by data storage device <b>1004</b>. Because the blockchain of the present invention is a distributed database, parts of the blockchain ledger may be implemented on data storage device <b>1004</b>. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. RAM <b>1002</b>, ROM <b>1003</b>, and data storage device <b>1004</b> are all examples of computer storage media.

0125Computer system <b>1000</b> also comprises an optional alphanumeric input device <b>1006</b>, an optional cursor control or directing device <b>1007</b>, and one or more signal communication interfaces (input/output devices, e.g., a network interface card) <b>1008</b>. Optional alphanumeric input device <b>1006</b> can communicate information and command selections to central processor <b>1001</b>. Optional cursor control or directing device <b>1007</b> is coupled to bus <b>1009</b> for communicating user input information and command selections to central processor <b>1001</b>. Signal communication interface (input/output device) <b>1008</b>, which is also coupled to bus <b>1009</b>, can be a serial port. Communication interface <b>1009</b> may also include wireless communication mechanisms. Using communication interface <b>1009</b>, computer system <b>1000</b> can be communicatively coupled to other computer systems over a communication network such as the Internet or an intranet (e.g., a local area network), or can receive data (e.g., a digital television signal).

0126In the foregoing specification, embodiments have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is the invention and what is intended by the applicant to be the invention is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. Hence, no limitation, element, property, feature, advantage, or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.