Vehicle data service configurable deployment

Abstract

Example operations include one or more of linking a mobile device and a vehicle; configuring a data service request on the mobile device; receiving, at a controller area network of the vehicle, a data service request from the mobile device; and displaying, within the vehicle, the data set responsive to the configuration.

Description

Background Art

[0001] Vehicles or conveyances, such as cars, motorcycles, trucks, airplanes, trains, etc., generally provide transportation needs for passengers and / or cargo in various ways. Functions associated with the conveyance can be recognized and utilized by various computing devices such as smart mobile phones or computers located on and / or outside the conveyance. Summary of the invention

[0002] An example embodiment provides a method comprising one or more of the following operations: linking a mobile device and a vehicle; configuring a data service request on the mobile device; receiving the data service request from the mobile device at a controller area network of the vehicle; and displaying a data set in the vehicle in response to the configuration.

[0003] Another example embodiment provides a system comprising a memory communicatively coupled to a processor, wherein the processor performs one or more of the following operations: linking a mobile device and a vehicle; configuring a data service request on the mobile device; receiving a data service request from the mobile device at a controller area network of the vehicle; and displaying a data set in response to the mobile device configuring the data service request within the vehicle.

[0004] Yet another example embodiment provides a computer-readable storage medium comprising instructions that, when read by a processor, cause the processor to perform one or more of the following operations: linking a mobile device and a vehicle; configuring a data service request on the mobile device; receiving a data service request from the mobile device at a controller area network of the vehicle; and displaying a data set within the vehicle in response to the configuration. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 An example diagram illustrating a configurable deployment of a vehicle data service according to an example embodiment.

[0006] Figure 2A A vehicle network diagram is shown according to an example embodiment.

[0007] Figure 2B Another vehicle network diagram is shown according to an example embodiment.

[0008] Figure 2C Another vehicle network diagram is shown according to an example embodiment.

[0009] Figure 2D Yet another transportation network diagram is shown according to an example embodiment.

[0010] Figure 2E Yet another transportation network diagram is shown according to an example embodiment.

[0011] Figure 2F A diagram depicting electrification of one or more elements is shown according to an example embodiment.

[0012] Figure 2G A diagram depicting the interconnection between different elements is shown according to an example embodiment.

[0013] Figure 2H Yet another diagram depicting the interconnection between different elements according to an example embodiment is shown.

[0014] Fig.2I Still another diagram depicting interconnections between elements according to an example embodiment is shown.

[0015] Figure 2J Yet another diagram depicting a keyless entry system is shown according to an example embodiment.

[0016] Figure 2K Yet another diagram depicting a CAN within a vehicle is shown according to an example embodiment.

[0017] Figure 2L Yet another diagram depicting an end-to-end communication channel is shown according to an example embodiment.

[0018] Figure 2M Still another diagram depicting an example of a vehicle performing secure V2V communications using security credentials is shown in accordance with an example embodiment.

[0019] Figure 2N Still another diagram depicting an example of a vehicle interacting with a secure processor and a wireless device is shown according to an example embodiment.

[0020] Figure 3A A flow chart according to an example embodiment is shown.

[0021] Figure 3B Another flow chart according to an example embodiment is shown.

[0022] Figure 3C Another flow chart according to an example embodiment is shown.

[0023] Figure 4 A machine learning vehicle network diagram is shown according to an example embodiment.

[0024] Figure 5A An example vehicle configuration for managing database transactions associated with a vehicle is shown according to an example embodiment.

[0025] Figure 5B Another example vehicle configuration for managing database transactions between various vehicles is shown according to an example embodiment.

[0026] Fig. 6A A blockchain architecture configuration according to an example embodiment is shown.

[0027] Figure 6B Another blockchain configuration according to an example embodiment is shown.

[0028] Figure 6C A blockchain configuration for storing blockchain transaction data according to an example embodiment is shown.

[0029] Fig.6D Example data blocks are shown according to example embodiments.

[0030] Figure 7 An example system is shown that supports one or more of the example embodiments. DETAILED DESCRIPTION

[0031] It is readily understood that, as generally described herein and illustrated in the accompanying drawings, the instant components can be arranged and designed in a variety of different configurations. Therefore, as shown in the accompanying drawings, the following detailed description of an embodiment of at least one of the method, apparatus, computer-readable storage medium, and system is not intended to limit the scope of the claimed application, but only represents selected embodiments. The multiple embodiments described herein are not intended to limit the scope of the solution. The computer-readable storage medium can be a non-transient computer-readable medium or a non-transient computer-readable storage medium.

[0032] Communications between a vehicle and certain entities such as remote servers, other vehicles, and local computing devices (e.g., smart mobile phones, personal computers, computers embedded in vehicles, etc.) may be sent and / or received and processed by one or more "components", which may be hardware, firmware, software, or a combination thereof. A component may be part of any of these entities or computing devices or some other computing device. In one example, consensus decisions related to blockchain transactions may be performed by one or more computing devices or components associated with the vehicle (which may be any of the elements described and / or depicted herein) and components external to the vehicle or at a location remote from the vehicle.

[0033] The instant features, structures or characteristics described in this specification may be combined in any suitable manner in one or more embodiments. For example, throughout this specification, the use of the phrase "exemplary embodiment", "some embodiments" or other similar language refers to the specific features, structures or characteristics described in association with the embodiment that may be included in at least one example. Therefore, throughout this specification, the appearance of the phrase "exemplary embodiment", "in some embodiments", "in other embodiments" or other similar language does not necessarily refer to the same set of embodiments, and the described features, structures or characteristics may be combined in any suitable manner in one or more embodiments. In the diagram, even if the depicted connection is a unidirectional or bidirectional arrow, any connection between the elements may allow unidirectional and / or bidirectional communication. In the current solution, the vehicle or vehicle may include one or more of a car, a truck, a pedestrian zone battery electric vehicle (BEV), an electronic flatbed, a fuel cell bus, a motorcycle, a scooter, a bicycle, a boat, a recreational vehicle, an airplane, and any object that can be used to transport people and / or goods from one location to another.

[0034] Furthermore, although the term "message" is used in the description of the embodiments, other types of network data may also be used, such as packets, frames, datagrams, etc. Furthermore, although certain types of messages and signaling may be depicted in exemplary embodiments, they are not limited to a certain type of message or signaling.

[0035] Example embodiments provide methods, systems, components, non-transient computer-readable media, devices, and / or networks that provide at least one of a vehicle (also referred to herein as a vehicle or automobile), a data collection system, a data monitoring system, a verification system, an authorization system, and a vehicle data distribution system. Vehicle status condition data received in the form of communication messages (such as wireless data network communications and / or wired communication messages) can be processed to identify vehicle / vehicle status conditions and provide feedback on the condition and / or changes of the vehicle. In one example, a user profile can be applied to a specific vehicle / vehicle to authorize a current vehicle event, a service stop at a service station, authorize subsequent vehicle rental services, and enable communication between vehicles.

[0036] In the communication infrastructure, a decentralized database is a distributed storage system including multiple nodes that communicate with each other. Blockchain is an example of a decentralized database that includes an append-only immutable data structure (i.e., a distributed ledger) that can keep records between untrusted parties. Untrusted parties are referred to as peers, nodes, or peer nodes in this article. Each peer keeps a copy of the database record, and if there is no consensus between the distributed peers, no peer can modify the database record. For example, peers can execute a consensus protocol to verify blockchain storage entries, group storage entries into blocks, and build a hash chain via blocks. For consistency, the process forms an account book by ordering storage entries as needed. In a public or permissionless blockchain, anyone can participate without a specific identity. Public blockchains can involve cryptocurrency and use consensus based on various protocols such as proof of work (PoW). In contrast, a permissioned blockchain database can protect interactions between a group of entities that share a common goal but do not fully trust or cannot fully trust each other, such as businesses that exchange funds, goods, and information. The instant solution can operate in permissioned and / or permissionless blockchain settings.

[0037] Smart contracts are trusted distributed applications that exploit the tamper-proof properties of a shared or distributed ledger (possibly in the form of a blockchain) and the underlying protocols between member nodes (known as endorsements or endorsement policies). Typically, blockchain entries are "endorsed" before being submitted to the blockchain, and unendorsed entries are ignored. A typical endorsement policy allows the smart contract executable code to specify endorsers for an entry in the form of a set of peer nodes required for endorsement. When a client sends an entry to the peers specified in the endorsement policy, the entry is executed to validate the entry. After validation, the entry enters the ordering phase, where the consensus protocol generates an ordered sequence of endorsed entries grouped into blocks.

[0038] A node is a communication entity of a blockchain system. A "node" can perform a logical function, i.e., multiple nodes of different types can run on the same physical server. Nodes are grouped in trust domains and are associated with logical entities that control them in various ways. Nodes can include different types, such as client or submitting client nodes, which submit entry calls to endorsers (e.g., peers) and broadcast entry suggestions to subscription services (e.g., subscription nodes). Another type of node is a peer node, which can receive entries submitted by clients, submit entries and maintain a copy of the state of blockchain entries and the ledger. Peers can also play the role of endorsers. Subscription service nodes or subscribers are nodes that run communication services for all nodes and implement delivery guarantees, such as broadcasting to each peer node in the system when submitting entries and modifying the world state of the blockchain. The world state can constitute an initial blockchain entry, which typically includes control and setup information.

[0039] The ledger is an ordered, tamper-proof record of all state transitions of the blockchain. State transitions may originate from smart contract executable code calls (i.e., entries) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). An entry may result in a set of asset key-value pairs being submitted to the ledger as one or more operands (such as create, update, and delete, etc.). The ledger includes a blockchain (also called a chain), which stores immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain. Typically, there is one ledger per channel. Each peer node maintains a copy of the ledger for each channel of which they are a member.

[0040] A chain is a log of entries structured as hash-linked blocks, and each block contains a sequence of N entries, where N is equal to or greater than 1. The block header includes the hash of the block entry and the hash of the previous block header. In this way, all entries on the ledger can be ordered and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash links. The hash of the most recently added blockchain block represents every entry on the chain that came before it, making it possible to ensure that all peer nodes are in a consistent and trusted state. The chain can be stored on the peer node file system (i.e. local, attached storage, cloud, etc.), efficiently supporting the append-only nature of blockchain workloads.

[0041] The current state of the immutable ledger represents the latest values ​​of all keys contained in the chain entry log. Because the current state represents the latest key values ​​known to the channel, it is sometimes called the world state. Smart contract executable code calls execute entries against the current state data of the ledger. In order to make these smart contract executable code interactions efficient, the latest values ​​of the keys can be stored in the state database. The state database may be just an indexed view into the chain entry log and can therefore be regenerated from the chain at any time. The state database can be automatically restored (or generated if needed) when a peer node starts and before an entry is accepted.

[0042] The difference between blockchain and conventional databases is that blockchain is not a central storage, but a decentralized, immutable and secure storage, where nodes must share changes to records in the storage. Blockchain is inherent to and helps achieve some of the properties of blockchain, including but not limited to immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement and accessibility.

[0043] Example embodiments provide services to specific vehicles and / or user profiles applied to vehicles. For example, a user may be the owner of a vehicle or the operator of a vehicle owned by another party. A vehicle may require service at certain time intervals, and service requirements may require authorization before being allowed to receive service. In addition, a service center may provide services to vehicles in nearby areas based on the current route plan of the vehicle and the relative level of service requirements (e.g., immediate, severe, moderate, slight, etc.). Vehicle requirements may be monitored via one or more vehicle and / or road sensors or cameras, which report sensed data to a central controller computer device inside and / or outside the vehicle. The data is forwarded to a management server for review and operation. The sensor may be in one or more of the following locations: inside a vehicle, outside a vehicle, on a fixed object separated from the vehicle, and on other vehicles near the vehicle. The sensor may also be associated with the speed of the vehicle, the braking of the vehicle, the acceleration of the vehicle, the fuel level, the service requirement, the vehicle shifting, and the steering of the vehicle. As described herein, the sensor may also be a device, such as a wireless device in and / or near the vehicle. Additionally, sensor information may be used to identify whether the vehicle is operating safely and whether an occupant is in any unexpected vehicle condition, such as during vehicle entry and / or use. Vehicle information collected before, during, and / or after vehicle operation may be identified and stored in transactions on a shared / distributed ledger, which may be generated by a permission granting consortium and submitted to an immutable ledger and thus executed in a "decentralized" manner, such as via a blockchain member group.

[0044] Various stakeholders (i.e., owners, users, companies, agencies, etc.) may wish to limit exposure of private information, so blockchain and its immutability can be used to manage permissions for each specific user's vehicle profile. Smart contracts can be used to provide compensation, quantify user profile scores / ratings / reviews, apply vehicle event permissions, determine when service is required, identify collision and / or degradation events, identify safety issue events, identify parties to events, and provide distribution to registered entities seeking access to such vehicle event data. In addition, results can be identified and necessary information shared between registered companies and / or individuals based on a consensus method associated with the blockchain. This approach cannot be implemented on a conventional centralized database.

[0045] Various drive systems of instant solutions can use software, sensor arrays and machine learning functions, light detection and ranging (lidar) projectors, radars, ultrasonic sensors, etc. to create maps, which are maps of terrain and roads that vehicles can use for navigation and other purposes. In some embodiments, GPS, maps, cameras, sensors, etc. can also be used in autonomous vehicles instead of lidar.

[0046] In certain embodiments, the instant solution includes authorizing the vehicle for service via an automatic and rapid verification scheme. For example, a vehicle operator or an autonomous vehicle may be driven to a charging station or fuel pump, and authorization to receive charge or fuel may be performed without delay, provided that the service and / or charging station receives the authorization. The vehicle may provide a communication signal that provides an identification of the vehicle with a currently active profile that is linked to an account that is authorized to receive service, which may be corrected later by compensation. Additional measures may be used to provide further authentication, such as another identifier that may be wirelessly sent from the user's device to the service center to replace or supplement the first authorization work between the vehicle and the service center with additional authorization work.

[0047] The shared and received data may be stored in a database that maintains the data in a single database (e.g., a database server) and is typically stored in a specific location. The location is typically a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored on a centralized database is typically accessible from multiple different points. A centralized database is easy to manage, maintain, and control due to its single location, especially for security purposes. In a centralized database, data redundancy is minimized because a single storage location for all data also means that a given data set has only one master record. Blockchain can be used to store data and transactions related to vehicles.

[0048] Any of the actions described herein may be performed, with or without memory, by one or more processors (such as microprocessors, sensors, electronic control units (ECUs), and host units, etc.) that may be located on and / or off a vehicle (such as a server, computer, mobile / wireless device, etc.). The one or more processors may communicate with other memory and / or other processors on or off other vehicles to utilize data sent by and / or to the vehicle. The one or more processors and other processors may send data, receive data, and utilize the data to perform one or more of the actions described or depicted herein.

[0049] Figure 1 An example diagram of a configurable deployment 100 of a vehicle data service according to an example embodiment is shown. The system 100 may include a vehicle that may transport passengers and / or cargo. In one embodiment, the vehicle may be at least partially powered by electrical energy (i.e., an electric vehicle). The vehicle includes one or more processors and associated storage devices, including but not limited to a main processor or vehicle processor 120, a navigation processor, a communication processor, an ECU, a sensor processor, etc.

[0050] A person associated with the vehicle (e.g., the vehicle owner or a family member of the vehicle owner) may own a communication device or other device. The communication device may include a smart mobile phone, a tablet, a smart watch, a wearable computer, etc. The device may include a mobile device processor 110 and a storage device accessible to the mobile device processor 110 for storing applications and data. The mobile device may communicate with the vehicle processor 120 via a wired connection such as a universal serial bus (USB) cable, or wirelessly via a wireless connection such as WI-FI or BLUETOOTH.

[0051] The system 100 may also include a server 130. The server 130 may include one or more computers communicatively coupled to the vehicle processor 120 and the mobile device processor 110. The server 130 may include one or more processors and a memory device for storing applications and data. In one embodiment, the server 130 may be associated with a manufacturer of the vehicle (including a repair facility), a sales facility, an entertainment venue, etc. In one embodiment, the server 130 may be located in a network or cloud and / or located in or connected to a vehicle charging station.

[0052] In one embodiment, the server 130 may link the mobile device with the vehicle. The vehicle may be associated with the server 130, for example, through the purchase of the vehicle. In one embodiment, the server 130 may be associated with the vehicle manufacturer. As part of the purchase transaction, the server 130 may deliver a notification to the vehicle processor 120. The notification may include a link to a website where the vehicle owner may enter information to register the vehicle with the server 130. The vehicle information may include the VIN number, the manufacturer's name or ID, the time / date of manufacture, the location of manufacture, the vehicle options, the vehicle owner's name, address, telephone number, and email address, etc. In one embodiment, the server 130 may verify the ownership information with the vehicle information. For example, the authentication may involve a digital key that is stored in a memory device accessible to the server 130 or obtained from the vehicle processor 120 as part of the vehicle information. The authentication process may link ownership to a specific vehicle.

[0053] The server 130 may receive the vehicle information and deliver a notification to an email address or phone address specified in the information. The user of the mobile device may receive a notification including an SMS text message or an email with a link. The notification may include a link to a website where the vehicle owner may enter information to associate the mobile device and vehicle with the server 130, such as confirming joint ownership of the mobile device and vehicle. The server 130 may send a vehicle linked notification 114 to the vehicle processor 120 and a mobile device linked notification 116 to the mobile device processor 110.

[0054] In one embodiment, the mobile device processor 110 may configure a message such as a data service request 118 and send the data service request 122 to the vehicle processor 120. In one embodiment, the data service request 118 may be a CAN data service request. Currently, CAN data services may be developed in the cloud and may not be configured in the vehicle's head unit (HU) or customer-level mobile device application. Customers may not be able to choose what they see or not see or how they see it. The CAN data service or data service request 118 may include driving characteristics, driving history, telematics, map data, fleet-related video data, seat settings, etc. of the vehicle. For example, the data service request 122 may include a request for telematics or sensor data for a time period, a range of values, or relative to a specified threshold. As another example, the data service request 122 may request the driving characteristics of a specific individual for a specific purpose (e.g., braking), a time period, an area, or within a distance to a location and / or multiple vehicles.

[0055] In one embodiment, the vehicle processor 120 may receive the data service request 122 via a CAN bus of the vehicle 124. For example, the HU processor or the host vehicle processor may receive the data service request 122 and pass the data service request 122 to the vehicle processor 120 via the CAN bus. In one embodiment, the vehicle processor 120 may interpret the data service request 126. For example, the data service request 122 may include a request type (e.g., a request for driving characteristics, driving history, telematics, map data, fleet-related video data, seat settings, etc.), a time period, a value range, or an indication relative to a specified threshold, where a response to the data service request is to be provided (e.g., visually displayed within the vehicle to a HU, one or more mobile devices, etc., in text-to-speech audio form, or both).

[0056] In one embodiment, the vehicle processor 120 can configure a data set for the data service request 128. The data set can include various data items from the interpreted data service request 126. The vehicle can obtain data for the data set from one or more accessible memory devices of the vehicle (e.g., a memory device accessible to the vehicle processor 120), a server 130, and / or a mobile device processor 110 or other mobile device. For example, the vehicle processor 120 can obtain a data set template from the server 130 and fill the template with data items from the accessible memory device of the vehicle. After the data template is partially or completely filled with data items, the vehicle processor 120 can display the data set 132 on the HU or another display associated with the vehicle. Alternatively, the vehicle processor 120 can present the data set audibly through the speaker of the vehicle. In another embodiment, the vehicle processor 120 can send the data set to the mobile device processor 110, and the mobile device processor 110 can present the data set visually and / or audibly on the mobile device.

[0057] In one embodiment, the vehicle processor 120 may determine that the mobile device and one or more other mobile devices are within the vehicle, modify the data service request 122 based on a combination of the mobile devices, and display the modified data based on the combination.

[0058] In one embodiment, several passengers or vehicle occupants may be in the vehicle. Each passenger may have an associated mobile device that the passenger uses for communication and data transfer with other devices and computers. The vehicle processor 120 may determine that multiple mobile devices are in the vehicle at the current time. For example, a first mobile device may be connected to a USB port of the vehicle, a second mobile device may be connected to the vehicle processor 120 via a Bluetooth wireless connection, and so on.

[0059] In one embodiment, the data service request 122 may include various preferences associated with the first vehicle occupant. For example, the preferences may include a playlist of music, podcasts, or other content preferred by the first vehicle occupant. In response to receiving the data service request 122 from the mobile device processor 110 corresponding to the first vehicle occupant and detecting the mobile device of the second vehicle occupant, the vehicle processor 120 may transmit a notification requesting the content preferences of the second vehicle occupant to the mobile device of the second vehicle occupant. The processor of the mobile device of the second vehicle occupant may receive the notification and, in response, provide the vehicle processor 120 with a playlist including the content preferences of the second vehicle occupant. The vehicle processor 120 may modify the data service request based on the combination of mobile devices by identifying common items in the two playlists and presenting the common items visually and / or audibly to the vehicle occupant.

[0060] In one embodiment, the vehicle processor 120 may determine that the mobile device is not within the vehicle, determine that the mobile device is proximate to one or more other vehicles associated with the vehicle, and communicate the data service request from the mobile device to the one or more other vehicles.

[0061] In one embodiment, the vehicle processor 120 can determine that the mobile device is not in the vehicle by a wired or wireless method. For example, the vehicle processor 120 can detect a mobile device connected through a USB port of the vehicle. If no mobile device is connected through the USB port, the vehicle processor 120 can determine that no wired mobile device is in the vehicle. For example, the vehicle processor 120 can detect a mobile device connected through a Bluetooth connection of the vehicle. If no mobile device is connected through a Bluetooth connection, the vehicle processor 120 can determine that no wireless mobile device is in the vehicle.

[0062] In one embodiment, after determining that the mobile device is not in the vehicle, the vehicle processor 120 may determine that the mobile device is close to one or more other vehicles related to the vehicle. Related may mean owned by an entity such as a family member, a business, or a group of individuals related to one or more categories. In one embodiment, the related vehicles may communicate one or more vehicle identifiers between the related vehicles. In one embodiment, the related vehicles may be paired via a wireless interface such as Bluetooth. For example, a user associated with the mobile device may access an application in a memory device associated with the mobile device processor 110 and enter an identifier for each of the related vehicles. The identifier may include parameters such as a VIN number, a license plate number, a MAC address, an IP address, an email address, a phone number, and / or an alphanumeric value. In one embodiment, the vehicle processor 120 may send an identifier corresponding to the related vehicle, and may determine which of the related vehicles is close based on which of the related vehicles responds. Each of the responding vehicles may send a unique identifier back to the mobile device processor 110.

[0063] In one embodiment, the vehicle processor 120 receives the data service request 122 from the mobile device processor 110 and sends the data service request 122 to one or more of the associated vehicles. In one embodiment, each of the one or more associated vehicles provides a data set back to the vehicle processor 120. The provided data set may include the request information in the data service request 122 that is specific to the receiving vehicle. In one embodiment, the vehicle processor 120 may receive the data set from the responding neighboring associated vehicles, combine the data in the received data set, and present the combined data set on the vehicle or mobile device or visually and / or audibly.

[0064] In one embodiment, the vehicle processor 120 can determine that the mobile device is in another vehicle, receive a data service request from the mobile device at the CAN of the other vehicle, configure the data service request in the other vehicle on the mobile device, and display data in response to the configuration in the other vehicle. In one embodiment, the mobile device can be connected to the processor of the other vehicle through a wired connection or a wireless connection. The mobile device processor 110 and the other vehicle processor can exchange various information, such as the GPS coordinates of the mobile device and the other vehicle and / or the user profile of the user of the mobile device. The mobile device processor 110 can execute an application that provides GPS coordinates and user profiles to the vehicle processor 120 of the vehicle. For example, the vehicle processor 120 can track the location and identity of the user associated with the mobile device. The vehicle processor 120 can compare the received GPS coordinates, and if the GPS coordinates match, it is determined that the mobile device is in the other vehicle.

[0065] In another embodiment, the user of the mobile device can configure the data service request 118 on the mobile device, and the mobile device processor 110 can send the data service request 122 to the other vehicle processor. In one embodiment, the other vehicle processor can receive the data service request via the CAN bus of the other vehicle. For example, the HU processor or the main vehicle processor can receive the data service request and pass the data service request to the other vehicle processor via the CAN bus. In one embodiment, the other vehicle processor can interpret the data service request. For example, the data service request can include an indication of the request type (e.g., a request to provide a user profile of a user associated with the mobile device, a request for services associated with other vehicles, etc.).

[0066] In one embodiment, the other vehicle processor can configure the data set of the data service request. The data set may include various data items from the interpreted data service request. The vehicle may obtain data of the data set from one or more accessible memory devices of the other vehicle (e.g., memory devices accessible to the other vehicle processor), the server 130 and / or the mobile device processor 110 or other mobile device. For example, the other vehicle processor can obtain a data set template from the server 130 and fill the template with data items from the accessible memory device of the other vehicle. After the data template is partially or completely filled with data items, the other vehicle processor can display the data set on the HU or another display associated with the other vehicle. Alternatively, the other vehicle processor can audibly present the data set through the speaker of the other vehicle. In another embodiment, the other vehicle processor can send the data set to the mobile device processor 110, and the mobile device processor 110 can visually and / or audibly present the data set on the mobile device.

[0067] In another embodiment, the vehicle processor 120 can determine that the mobile device is within a rental vehicle, obtain a user profile corresponding to the user of the mobile device, and display rental vehicle parameters within the rental vehicle corresponding to the user profile. In one embodiment, the other vehicle can be a rental vehicle, a rideshare, or a friend's or family member's car, etc. In one embodiment, the mobile device can be connected to the vehicle processor of the rental vehicle via a wired connection such as a USB connection, or a wireless connection such as a Bluetooth connection.

[0068] The mobile device processor 110 and the rental vehicle processor can exchange various information, including GPS coordinates of the mobile device and the rental vehicle and / or a user profile of the user of the mobile device. The mobile device processor 110 can execute an application that provides GPS coordinates and user profiles to the vehicle processor 120 of the vehicle. For example, the vehicle processor 120 can track the location and identity of the user associated with the mobile device. The vehicle processor 120 can compare the received GPS coordinates, and, if the GPS coordinates match, determine that the mobile device is in the other vehicle. The rental vehicle processor can display a portion of the user profile received from the mobile device. For example, a portion of the user profile can include a destination address, a current time, and a route to the destination, etc. The rental vehicle processor can configure a data set corresponding to a portion of the user profile and display rental vehicle parameters in the rental vehicle. The rental vehicle parameters can include a rental vehicle description, a rental time, a destination, and a route to the destination, etc. In one embodiment, the rental vehicle processor can display the rental vehicle parameters on a display associated with the HU of the rental vehicle. In another embodiment, the rental vehicle processor can send the rental vehicle parameters to the mobile device processor 110, and the mobile device processor 110 can display the rental vehicle parameters on the display of the mobile device.

[0069] In one embodiment, the data service request 122 may include the purchased service. The vehicle processor 120 may determine that one or more other vehicles associated with the vehicle are eligible to receive the purchased service, notify the one or more other vehicles of the data service request 122 including the purchased service, and display data responsive to the purchased service in the other vehicles.

[0070] The purchased service may be a subscription to a music or movie streaming service, or a traffic data upgrade for a vehicle navigation function. The subscription may include a group of vehicles, for example, vehicles owned by an entity such as a family member. Prior to the data service request 122, the user of the vehicle may have entered information into the HU of the vehicle to provide identification communication information of other related vehicles. For example, the identification information may include an email address, an IP address, a MAC address, a VIN number, and a license plate number, etc. The data service request 122 may include an indication of the qualifications of other related vehicles. When the vehicle processor 120 receives the data service request 122, the vehicle processor 120 identifies the other related vehicles as eligible to receive the subscription. The vehicle processor 120 sends a notification to each of the related vehicles informing them that they are eligible to receive the subscription. The vehicle processor in each of the related vehicles receives the notification and may display data in response to the notification. For example, each related vehicle may display information about the subscription, service time, purchaser, subscription terms and / or subscription cost on the HU display.

[0071] In one embodiment, the vehicle processor 120 may receive a user profile from a mobile device, determine a common area of ​​interest between a threshold in the user profile and the vehicle's data, and display the common area of ​​interest and the data value associated with the threshold within the vehicle when the threshold is exceeded. In one embodiment, the threshold may indicate a criticality of a data value associated with vehicle safety, vehicle efficiency, vehicle performance, and valuable driver behavior. For example, the threshold may indicate a level at which the vehicle may be more difficult to safely control under certain road or weather conditions, or a maximum parameter level previously reached by the driver using the vehicle.

[0072] In one embodiment, an application on a mobile device can be used to configure the display of vehicle telematics on the HU display of the vehicle. A user associated with the mobile device can utilize the application to send a portion of the user profile from the mobile device to the vehicle processor 120. The vehicle processor 120 can determine the driver's name and a request for brake telematics on the vehicle from a portion of the user profile. Braking telematics may represent an area of ​​interest, which may be a set of vehicle parameters that a user may be concerned about. The vehicle processor 120 can obtain a history of braking data and a threshold value for the identified driver from an accessible memory device. For example, the threshold value may represent a common area of ​​interest with the user profile and may reflect, among other things, the maximum measured braking force value, the amount of braking energy, and the maximum length of time that braking is applied.

[0073] In one embodiment, when a threshold is exceeded, the vehicle processor 120 can display the common area of ​​interest (e.g., braking history), the threshold, and the current braking data on the vehicle HU. In one embodiment, when a threshold is exceeded, the vehicle processor 120 can store the current braking data as a new threshold in an accessible memory device.

[0074] In one embodiment, the vehicle processor 120 can link the other mobile device and the vehicle, configure the other data service request on the other mobile device, receive the other digital service request from the mobile device at the CAN of the other vehicle, and determine which of the data service request and the other data service request to display.

[0075] In one embodiment, the vehicle processor 120 can link other mobile devices with the vehicle. For example, a user with a mobile device can use an application to add another new user to the vehicle. The application can send a notification to the vehicle processor 120 through the mobile device processor 110, where the notification can include the name of the new user and the communication information of the mobile device to contact the new user. The vehicle processor 120 can store the name and communication information of the new user in an accessible memory device and send a request to the new mobile device to confirm the new user. The new user can view the request to confirm the new user on the display of the new mobile device and select to confirm. The new mobile device can send a confirmation to the vehicle processor 120, and the vehicle processor 120 links the new mobile device and the vehicle based on the confirmation.

[0076] In one embodiment, other mobile device processors may configure other data service requests and send other data service requests to the vehicle processor 120. In one embodiment, other data service requests may be CAN data service requests. Currently, CAN data services may be developed in the cloud and may not be configured in the vehicle's head unit (HU) or customer-level mobile device application. Customers may not be able to choose what they see or not see or how they see it. CAN data services or other data service requests may include driving characteristics, driving history, telematics, map data, fleet-related video data, and / or seat settings of the vehicle. For example, other data service requests may include requests for time periods, value ranges, or telematics or sensor data relative to specified thresholds. As another example, other data service requests may request driving characteristics of a specific individual for a specific purpose (e.g., braking), time period, area, or within a distance to a location and / or multiple vehicles.

[0077] In one embodiment, the vehicle processor 120 may receive the other data service request via a CAN bus of the vehicle. For example, the HU processor or the main vehicle processor may receive the other data service request and pass the other data service request to the vehicle processor 120 via the CAN bus. In one embodiment, the vehicle processor 120 may interpret the other data service request. For example, the other data service request may include a request type (e.g., a request for driving characteristics, driving history, telematics, map data, fleet-related video data, and seat settings, etc.), a time period, a value range, or an indication relative to a specified threshold, where a response to the data service request is to be provided (e.g., a visual display to a HU, one or more mobile devices, etc., as text-to-speech audio within the vehicle, or both).

[0078] In one embodiment, the vehicle processor 120 can configure a data set for other data service requests. The data set can include various data items from the interpreted data service request. The vehicle can obtain data for the data set from one or more accessible memory devices of the vehicle (e.g., a memory device accessible to the vehicle processor 120), the server 130, and / or the mobile device processor 110 or other mobile device processors. For example, the vehicle processor 120 can obtain a data set template from the server 130 and fill the template with data items from the accessible memory device of the vehicle.

[0079] In one embodiment, the vehicle processor 120 may determine which of the data service request 122 and other data service requests to display. In one embodiment, the vehicle processor 120 may determine that the most recently received data service request should be displayed. In another embodiment, the vehicle processor 120 may determine that the most urgent data service request should be displayed. The most urgent data service request may be determined by the vehicle processor 120, which checks the emergency data value accompanying each data set. For example, a braking-related data service request may have a higher emergency value than a navigation data service request, and a navigation data service request may have a higher emergency value than an entertainment-related data service request. In another embodiment, the vehicle processor 120 may determine that a data service request from a higher priority user should be displayed. For example, the vehicle processor 120 may determine that a data service request from a user who is the owner of the vehicle has a higher priority than a data service request from a user who is a family member of the owner of the vehicle, and a data service request from a user who is a family member of a non-owner has a higher priority than a data service request from a user who is a non-family member.

[0080] After the data template is partially or completely populated with data items corresponding to the higher priority data service request, the vehicle processor 120 can display the data set on the HU or another display associated with the vehicle. Alternatively, the vehicle processor 120 can audibly present the data set through a speaker of the vehicle. In another embodiment, the vehicle processor 120 can send the data set to the mobile device processor 110, and the mobile device processor 110 can visually and / or audibly present the data set on the mobile device.

[0081] In another embodiment, the vehicle processor 120 may determine that a different driver than the typical driver is driving the vehicle, identify a common destination for the vehicle with previous destinations of the typical driver, and display an optimal route to the common destination from previous destination route data.

[0082] In one embodiment, an internal camera in the vehicle may capture an image of the driver and provide the image to the vehicle processor 120. The vehicle processor 120 may use a facial recognition application to compare the captured image with stored images of typical vehicle drivers (e.g., vehicle owners) in an accessible memory device. The application may determine that a driver different from the typical driver is currently driving the vehicle.

[0083] The vehicle processor 120 may request a trip destination from the new vehicle driver, and the new vehicle driver may provide the trip destination audibly, by typing in a HU display input field, or by selecting from a stored destination drop-down list. For example, the vehicle processor 120 may compare the trip destination to stored destinations and identify a common destination for the vehicles. In one embodiment, the vehicle may include a navigation processor that may access a memory device including route information. The route information may include an optimal route from previous destination route data to the common destination. The vehicle processor 120 may obtain the optimal route information from the navigation processor and display the optimal route on a display of a HU in the vehicle.

[0084] The flowchart shown in this article, such as Figure 1 , Figure 2C , Figure 2D , Figure 2E , Figure 3A , Figure 3B and Figure 3C , are separate examples, but may be the same or different embodiments. Any of the operations in one flowchart may be adopted and shared with another flowchart. The example operations are not intended to limit the subject matter of any embodiment or corresponding claim.

[0085] It is important to note that Figure 1 , Figure 2C , Figure 2D , Figure 2E , Figure 3A , Figure 3B and Figure 3C All of the derived flow charts and corresponding processes may be part of the same process, or may share sub-processes with each other, so that the diagrams may be combined into a single preferred embodiment that does not require any one specific operation, but performs certain operations from one example process and one or more additional processes. All example processes are related to the same physical system and may be used individually or interchangeably.

[0086] Figure 2AA vehicle network diagram 200 according to an example embodiment is shown. The network includes multiple elements, multiple elements including a vehicle 202 and a vehicle 202', the vehicle 202 including a processor 204, and the vehicle 202' including a processor 204'. The vehicles 202, 202' communicate with each other via processors 204, 204' and other elements (not shown), and the other elements include transceivers, transmitters, receivers, memories, sensors and other elements that can provide communication. The communication between the vehicles 202 and 202' can occur directly, via a dedicated and / or public network (not shown), or via other vehicles and elements, and the elements include one or more of processors, memories and software. Although depicted as a single vehicle and processor, multiple vehicles and processors may exist. One or more of the applications, features, steps, solutions, etc. described and / or depicted herein may be utilized and / or provided by the instant element.

[0087] Figure 2B Another vehicle network diagram 210 according to an example embodiment is shown. The network includes multiple elements, multiple elements including vehicle 202 and including vehicle 202', vehicle 202 including processor 204, and vehicle 202' including processor 204'. Vehicles 202, 202' communicate with each other via processors 204, 204' and other elements (not shown), and other elements include transceivers, transmitters, receivers, memories, sensors and other elements that can provide communication. Communication between vehicles 202 and 202' can occur directly, via a dedicated and / or public network (not shown), or via vehicles and elements, and elements include one or more of processors, memories and software. Processors 204, 204' can also communicate with one or more elements 230, and one or more elements 230 include sensors 212, wired devices 214, wireless devices 216, databases 218, mobile phones 220, vehicles 222, computers 224, I / O devices 226 and voice applications 228. The processors 204, 204' may also be in communication with elements including one or more of a processor, memory, and software.

[0088] Although described as a single vehicle, processor, and element, there may be multiple vehicles, processors, and elements. Information or communication may occur to and / or from any of the processors 204, 204', and elements 230. For example, the mobile phone 220 may provide information to the processor 204, which may initiate the vehicle 202 to take action, and may also provide information or additional information to the processor 204', which may initiate the vehicle 202' to take action, and may further provide information or additional information to the mobile phone 220, the vehicle 222, and / or the computer 224. One or more of the applications, features, steps, solutions, etc. described and / or depicted herein may be utilized and / or provided by the instant element.

[0089] Figure 2C Another vehicle network diagram 240 is shown according to an example embodiment. The network includes multiple elements, including a vehicle 202, a processor 204, and a non-transitory computer readable medium 242C. The processor 204 is communicatively coupled to the computer readable medium 242C and the element 230 (such as Figure 2B Vehicle 202 may be a vehicle, a server, or any device having a processor and a memory.

[0090] The processor 204 performs one or more of the following operations: linking the mobile device and the vehicle 244C; configuring a data service request on the mobile device 246C; receiving the data service request from the mobile device at the controller area network of the vehicle 248C; and displaying a data set responsive to the configuration 250C within the vehicle.

[0091] Figure 2D Another vehicle network diagram 250 is shown according to an example embodiment. The network includes multiple elements, including a vehicle 202, a processor 204, and a non-transitory computer readable medium 242D. The processor 204 is communicatively coupled to the computer readable medium 242D and the element 230 (such as Figure 2B Vehicle 202 may be a vehicle, a server, or any device having a processor and a memory.

[0092] The processor 204 performs one or more of the following operations: determining that the mobile device and one or more other mobile devices are in the vehicle, modifying the data service request based on the combination of the mobile devices, and displaying modified data based on the combination 244D; determining that the mobile device is not in the vehicle, determining that the mobile device is in proximity to one or more other vehicles associated with the vehicle, and transmitting the data service request from the mobile device to the one or more other vehicles 245D; determining that the mobile device is in the other vehicles, receiving the data service request from the mobile device at the controller area network of the other vehicles, configuring the data service request in the other vehicles on the mobile device, and displaying data responsive to the configuration in the other vehicles 246D; wherein the data service request includes a purchased service; Determining that one or more other vehicles associated with the vehicle are eligible to receive the purchased service, notifying one or more other vehicles of a data service request including the purchased service, and displaying data responsive to the purchased service in the other vehicles 247D; receiving a user profile from a mobile device, determining a common area of ​​interest between a threshold in the user profile and the vehicle's data, and displaying the common area of ​​interest and data values ​​associated with the threshold in the vehicle when the threshold is exceeded 248D; and linking the other mobile device and the vehicle, configuring other data service requests on the other mobile device, receiving other data service requests from the mobile device at a controller area network of the other vehicle, and determining one of the data service request and the other data service request to be displayed 249D.

[0093] Figure 2E Still another transportation network diagram 260 is shown according to an example embodiment. Figure 2E , network diagram 260 includes vehicle 202 connected to other vehicles 202′ and update server node 203 via blockchain network 206. Vehicles 202 and 202′ may represent vehicles / vehicles. Blockchain network 206 may have a ledger 208 for storing software update verification data and a verification source 207 for future use (e.g., for auditing).

[0094] Although only one vehicle 202 is described in detail in this example, multiple such nodes may be connected to the blockchain 206. It should be understood that the vehicle 202 may include additional components without departing from the scope of the instant application, and some of the components described herein may be removed and / or modified. The vehicle 202 may have a computing device or a server computer, etc., and may include a processor 204, which may be a semiconductor-based microprocessor, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), and / or another hardware device. Although a single processor 204 is depicted, it should be understood that the vehicle 202 may include multiple processors or multiple cores, etc. without departing from the scope of the instant application. The vehicle 202 may be a vehicle, a server, or any device having a processor and a memory.

[0095] The processor 204 performs one or more of the following operations: receiving a confirmation of the event from one or more elements described or depicted herein, wherein the confirmation includes a blockchain consensus 244E between peers represented by any of the elements; and executing a smart contract to record the confirmation 246E on a blockchain based on the blockchain consensus. Consensus is formed between any element 230 and / or one or more of any elements described or depicted herein (including vehicles, servers, wireless devices, etc.). In another example, the vehicle 202 can be one or more of any element 230 and / or any element described or depicted herein (including servers, wireless devices, etc.).

[0096] The processor and / or computer readable medium 242E may be located completely or partially inside or outside the vehicle. The steps or features stored in the computer readable medium 242E may be performed completely or partially by any of the processors and / or elements in any order. In addition, one or more steps or features may be added, omitted, combined, performed later, etc.

[0097] Figure 2FA diagram 265 depicting the electrification of one or more elements is shown. In one example, a vehicle 266 can provide power stored in its battery to one or more elements including other vehicles 268, a charging station 270, and a power grid 272. The power grid 272 is coupled to one or more of the charging stations 270, which can be coupled to one or more of the vehicles 268. This configuration allows the distribution of power received from the vehicle 266. The vehicle 266 can also interact with other vehicles 268, such as via vehicle-to-vehicle (V2V) technology, cellular communications, and WiFi. The vehicle 266 can also interact wirelessly and / or wired with other vehicles 268, charging stations 270, and / or power grids 272. In one example, the vehicle 266 is routed (or routed itself) to the power grid 272, charging stations 270, or other vehicles 268 in a safe and efficient manner. Using one or more embodiments of the instant solution, the vehicle 266 can power one or more of the elements described herein in various advantageous ways described and / or depicted herein. Additionally, transportation safety and efficiency may be improved, and the environment may be positively impacted as described and / or depicted herein.

[0098] The term "energy" may be used to refer to any form of energy received, stored, used, shared, and / or lost by a vehicle. Energy may be used in conjunction with a voltage source and / or charge current supply provided to a vehicle from an entity during a charge / use operation. Energy may also be in the form of fossil fuels (e.g., for hybrid vehicles) or via alternative energy sources, including but not limited to lithium-based, nickel-based, hydrogen fuel cells, atomic / nuclear energy, fusion energy, and energy dynamically generated during energy sharing and / or use operations in order to increase or decrease one or more vehicle energy levels at a given time.

[0099] In one example, the charging station 270 manages the amount of energy transferred from the vehicle 266 so that there is a remaining charge in the vehicle 266 sufficient to reach the destination. In one example, a wireless connection is used to wirelessly guide the amount of energy transfer between vehicles 268, wherein the vehicles can all be in motion. In one embodiment, wireless charging can occur via a fixed charger and a battery of a vehicle aligned with each other (such as a charging pile in a garage or parking space). In one example, an idle vehicle such as vehicle 266 (which can be autonomous) is instructed to provide a certain amount of energy to the charging station 270 and return to the original position (e.g., its original position or a different destination). In one example, a mobile energy storage unit (not shown) is used to collect remaining energy from at least one other vehicle 268 and transfer the stored remaining energy at the charging station 270. In one example, factors such as distance, time, and traffic conditions, road conditions, environmental / weather conditions, vehicle conditions (weight, etc.), occupant schedules when using the vehicle, potential occupant schedules waiting for the vehicle, etc. determine the amount of energy to be transferred to the charging station 270. In one example, vehicle 268 , charging station 270 , and / or grid 272 may provide energy to vehicle 266 .

[0100] In one embodiment, a location (not shown), such as a building or residence, is communicatively coupled to one or more of the power grid 272, the vehicle 266, and / or the charging station 270. The rate of current flow to one or more of the location, the vehicle 266, and the other vehicles 268 is modified based on external conditions such as weather. For example, when the outside temperature is extremely high or low, thereby increasing the chance of a power outage, the current flow to the connected vehicles 266 / 268 is slowed to help minimize the chance of a power outage.

[0101] In one example, the solution described and depicted herein can be used to determine the load impact on a vehicle and / or system, provide energy to the vehicle and / or system based on future needs and / or priorities, and provide intelligence between the device containing the module and the vehicle that allows the processor of the device to wirelessly communicate with the vehicle about the amount of energy stored in the vehicle battery. In one example, the solution can also be used to provide charging from a vehicle to a location based on factors such as the temperature at the location, the cost of energy, and the power level at the location. In one example, the solution can also be used to manage the amount of energy remaining in the vehicle after transferring a portion of the charge to a charging station. In one example, the solution can also be used to notify the vehicle to provide a certain amount of energy from a battery on the vehicle, wherein the amount of energy to be transferred is based on the distance of the vehicle to the module receiving the energy.

[0102] In one example, the solution may also be used to use a mobile energy storage unit that uses a determined path to travel to a vehicle with excess energy and deposits the stored energy into the grid. In one example, the solution may also be used to determine the priority of the vehicle's need to provide energy to the grid and the priority of the vehicle's current needs, such as the priority of passengers or upcoming passengers, current cargo or upcoming cargo. In one example, the solution may also be used to determine that when the vehicle is idling, the vehicle decides to maneuver to a location to discharge excess energy to the grid and then return to the previous location. In one example, the solution may also be used to determine the amount of energy required for a vehicle to provide the required energy to another vehicle via vehicle-to-vehicle energy transfer based on one or more conditions such as weather, traffic, road conditions, car conditions, and passengers and / or cargo in another vehicle, and instruct the vehicle to route to another vehicle and provide energy. In one example, the solution may also be used to transfer energy from one vehicle in motion to other vehicles in motion. In one example, the solution may also be used to recover energy by the vehicle based on the estimated energy consumed by the vehicle to reach a meeting point with another vehicle, provide services, and return to the original location. In one example, the solution may also be used to provide a remaining distance required to a charging station and the charging station to determine an amount of energy to be recovered from the vehicle, wherein the amount of charge remaining is based on the remaining distance. In one example, the solution may also be used to manage vehicles that are charged simultaneously by more than one point, such as both a charging station via a wired connection and another vehicle via a wireless connection. In one example, the solution may also be used to assign energy application priorities to vehicles, wherein priority is given to those vehicles that provide a portion of their stored charge to another entity, such as a power grid and a residence, etc.

[0103] In one embodiment, vehicles 266 and 268 can be used as bidirectional vehicles. Bidirectional vehicles are vehicles that can be used as mobile microgrids that can help supply power to the grid 272 and / or reduce power consumption when the grid is strained. Bidirectional vehicles include bidirectional charging, in addition to receiving a charge to the vehicle, the vehicle can also take energy from the vehicle and "push" energy back into the grid 272 (also known as "V2G"). In bidirectional charging, the current flows in both directions; to the vehicle and from the vehicle. When the vehicle is charged, alternating current (AC) from the grid 272 is converted to direct current (DC). This can be performed by the vehicle's own converter or one or more of the converters on the charger 270. Energy stored in the vehicle's battery can be sent back to the grid in the opposite direction. The energy is converted from DC to AC by a converter (also known as a bidirectional charger) that is typically located in the charger 270. In addition, refer to Figure 2F The instant solution described and depicted may be used in this and other networks and / or systems.

[0104] Figure 2G275 is a diagram showing the interconnection between different elements 275. The instant solution may be stored in whole or in part on and / or executed by one or more computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287' and 277' associated with various entities, all of which are communicatively coupled and in communication with the network 286. The database 287 is communicatively coupled to the network and allows for the storage and retrieval of data. In one example, the database is an immutable ledger. One or more of the various entities may be a vehicle 276, one or more service providers 279, one or more public buildings 281, one or more transportation infrastructures 282, one or more residences 283, a power grid / charging station 284, a microphone 285 and / or other vehicles 277. Other entities and / or devices, such as one or more private users using a smart mobile phone 278, a laptop computer 280, an augmented reality (AR) device, a virtual reality (VR) device and / or any wearable device, may also interact with the instant solution. Smart mobile phones 278, laptop computers 280, microphones 285, and other devices can be connected to one or more of the connected computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287', and 277'. One or more public buildings 281 may include various institutions. One or more public buildings 281 may utilize computing devices 281'. One or more service providers 279 may include dealers, towing services, collision centers, or other repair shops. One or more service providers 279 may utilize computing devices 279'. These various computer devices may be directly and / or communicatively coupled to each other, such as via a wired network, a wireless network, and a blockchain network. In one example, microphone 285 may be used as a virtual assistant. In one example, one or more traffic infrastructures 282 may include one or more traffic signals, one or more sensors including one or more cameras, vehicle speed sensors, or traffic sensors, and / or other traffic infrastructure. One or more traffic infrastructures 282 may utilize computing devices 282'.

[0105] In one example, vehicles 277 / 276 can transport people, objects, and permanent or temporarily fixed devices, etc. In one example, vehicles 277 can communicate with vehicles 276 via V2V communication through computers associated with each vehicle 276' and 277', and can be referred to as vehicles, cars, vehicles, and motor vehicles, etc. Vehicles 276 / 277 can be self-propelled wheeled transporters, such as cars, sports utility vehicles, trucks, buses, vans, or other motors or battery-driven or fuel cell-driven vehicles. For example, vehicles 276 / 277 can be electric vehicles, hybrid vehicles, hydrogen fuel cell vehicles, plug-in hybrid vehicles, or any other type of vehicles with fuel cell stacks, motors, and / or generators. Other examples of vehicles include bicycles, scooters, trains, airplanes, ships, and any other forms of vehicles that can be transported. Vehicles 276 / 277 can be semi-autonomous or autonomous. For example, vehicles 276 / 277 can be automatically operated and navigate without manual input. An autonomous vehicle may have and use one or more sensors and / or navigation units to drive autonomously.

[0106] In one example, the solution described and depicted herein can be used to determine access to a vehicle through a blockchain consensus. In one example, the solution can also be used to perform profile verification before allowing an occupant to use the vehicle. In one example, the solution can also be used to enable the vehicle to indicate (visually, but also verbally in another example, etc.) the action (which can be pre-recorded) that the user needs to perform on the vehicle or from the vehicle, and verify that it is the correct action. In one example, the solution can also be used to provide such a capability for the vehicle, that is, to enable it to determine how to fork the data based on the risk level associated with the data and the driving environment, and distribute a portion of the risk level lower in the forked data during the safe driving environment to the occupant, and then distribute the remaining portion of the risk level higher of the forked data to the occupant after the occupant leaves the vehicle. In one example, the solution can also be used to process the transfer of vehicles across borders (such as countries / states, etc.) by using blockchains and / or smart contracts, and the rules of the new area are applied to the vehicle.

[0107] In one example, the solution may also be used to allow the vehicle to continue to operate outside the boundary when the vehicle reaches a consensus based on the characteristics of the vehicle's operation and the vehicle's occupants. In one example, the solution may also be used to analyze the available data upload / download speed of the vehicle, the file size, and the speed / direction in which the vehicle is traveling to determine the distance required to complete the data upload / unload, and assign a safe area boundary for the data upload / load to be performed. In one example, the solution may also be used to perform normally dangerous maneuvers in a safe manner, such as when the system determines that an exit is coming and when the vehicle does not seem to be ready to go out (e.g., in an incorrect lane or at a speed that is not conducive to the upcoming exit) and instruct the subject vehicle and other nearby vehicles to allow the subject vehicle to go out in a safe manner. In one example, the solution may also be used to use one or more vehicles to verify the diagnosis of other vehicles when one or more vehicles and other transport tools are in motion.

[0108] In one example, the solution may also be used to detect lane usage at a location at a time of day to notify the occupants of a vehicle or indicate that the vehicle recommends or does not recommend a lane change. In one example, the solution may also be used to eliminate the need to send information by mail and the need for the driver / occupant to respond by mail or in person. In one example, the solution may also be used to provide services to the occupants of a vehicle, wherein the services provided are subscription-based and licenses are obtained from other vehicles connected to the occupant's profile. In one example, the solution may also be used to record changes in the condition of a rental object. In one example, the solution may also be used to seek blockchain consensus from other vehicles approaching a damaged vehicle. In one example, the solution may also be used to receive media that may be related to an accident from a server such as an insurance entity server, from a vehicle computer. The server accesses one or more media files to access the damage to the vehicle and stores the damage assessment on the blockchain. In one example, the solution may also be used to obtain consensus to determine the severity of an event from several devices at different times before an event related to a vehicle occurs.

[0109] In one example, the solution can also be used to solve the problem of no video evidence of vehicle-related accidents. The current solution details querying the vehicle involved in the accident for media related to the accident from other vehicles that may be close to the accident. In one example, the solution can also be used to utilize vehicles and other devices (e.g., pedestrians' mobile phones, street light cameras, etc.) to record specific parts of damaged vehicles.

[0110] In one example, the solution may also be used to warn occupants when the vehicle is navigating toward a dangerous area and / or event, thereby allowing the vehicle to notify the occupants or a central controller of a potential dangerous area on or near the current vehicle route. In one example, the solution may also be used to detect when the vehicle is traveling at high speed, and at least one other vehicle is used to help slow down the vehicle in a way that minimizes traffic impact. In one example, the solution may also be used to identify dangerous driving situations, where media is captured by vehicles involved in dangerous driving situations. A geo-fence is established based on the distance of the dangerous driving situation, and additional media is captured by at least one other vehicle within the established geo-fence. In one example, the solution may also be used to send a notification to one or more occupants of the vehicle that the vehicle is approaching a traffic control sign on the road, and then, if the vehicle crosses the sign, receive instructions for poor driving from other nearby vehicles. In one example, the solution may also be used to disable a portion of the vehicle from operating by (in some embodiments) limiting speed, limiting the ability to approach other vehicles, limiting the speed to a maximum, and allowing only a given number of miles per time period.

[0111] In one example, the solution may also be used to overcome the need to rely on software updates to correct vehicle problems when the vehicle is not operating correctly. By observing other vehicles on the route, the server will receive data from potentially multiple other vehicles that observe unsafe or incorrect operation of the vehicle. Through analysis, these observations may lead to notifications to the vehicle when the data indicates that the operation is unsafe or incorrect. In one example, the solution may also be used to notify between the vehicle and the potential dangerous situation involving people outside the vehicle. In one example, the solution may also be used to send data to the server through a device related to a vehicle accident or a device near the accident. Based on the severity of the accident or near-accident, the server notifies the sender of the data. In one example, the solution may also be used to provide suggestions for operating the vehicle to the driver or occupant of the vehicle based on data analysis. In one example, the solution may also be used to establish a geographical fence associated with a physical structure and determine the payment responsibility for the vehicle. In one example, the solution may also be used to coordinate the ability to get off at a location using the current state of a location and the proposed future state of the navigation destination of other vehicles. In one example, the solution may also be used to coordinate the ability to automatically arrange for vehicles to get off at locations such as transportation rental entities.

[0112] In one example, the solution may also be used to move a vehicle to another location based on the user's event. More specifically, the system tracks the user's device and modifies the vehicle to be moved near the user at the end of the original event or the modified event. In one example, the solution may also be used to verify the available locations in the area through the existing vehicles in the area. The approximate time when the location may be vacated is also determined based on the verification from the existing vehicles. In one example, the solution may also be used to move the vehicle to a closer parking space when a parking space becomes available and the time elapsed since the initial parking is less than the average event time. In addition, the vehicle is moved to the final parking space at the end of the event or according to the location of the device associated with at least one occupant of the vehicle. In one example, the solution may also be used to plan parking before the upcoming crowd. The system interacts with the vehicle to provide some services at a price lower than the full price and / or guide the vehicle to an alternative parking location based on the priority of the vehicle, thereby optimizing the parking situation before arrival.

[0113] In one example, the solution may also be used to sell fractional ownership of a vehicle, or determine pricing and availability for ride-sharing applications. In one example, the solution may also be used to provide accurate and timely reports of dealer sales activity that go far beyond what is currently available. In one example, the solution may also be used to allow dealers to request assets through blockchain. By using blockchain, consensus is obtained before any asset is moved. In addition, the process is automated and payments may be initiated through blockchain. In one example, the solution may also be used to arrange agreements with multiple entities (such as service centers), where consensus is obtained and actions (such as diagnostics) are performed. In one example, the solution may also be used to associate digital keys with multiple users. The first user may be a vehicle operator and the second user is the responsible party for the vehicle. These keys are authorized by a server, where the proximity of the keys is verified for the location of the service provider. In one example, the solution may also be used to determine the services required at the destination of the vehicle. One or more service locations that can provide the required services are located, which are both in the area on the route to the destination and can be used to perform the services. The navigation of the vehicle is updated by the determined service locations. A smart contract containing the compensation value of the service is identified, and the blockchain transaction is stored in the distributed ledger of the transaction.

[0114] In one example, the solution may also be used to dock the service provider's vehicle with the profile of the occupant of the vehicle to determine the services and goods that the occupant in the vehicle may be interested in. These services and goods are determined by the occupant's history and / or preferences. The vehicle then receives a quote from the service provider vehicle, and in another example, meets with the vehicle to provide services / goods. In one example, the solution may also be used to detect vehicles within the range, and send service quotes (such as maintenance quotes, product quotes, etc.) to the vehicle. An agreement is reached between the system and the vehicle, and the service provider is selected by the system to provide the agreement. In one example, the solution may also be used to assign one or more vehicles as road managers, where the road manager assists in controlling traffic. The road manager can generate road indicators (such as lights, displays, and sounds) to help traffic flow. In one example, the solution may also be used to warn the driver of the vehicle through a device, wherein the device may be a traffic light or near an intersection. When a vehicle in front of the vehicle list does not move, a warning is sent when an event occurs, such as when a green light is on and the vehicle does not move.

[0115] Figure 2H 290. A vehicle 276 is shown that includes ECUs 295, 296 and a head unit (also called an infotainment system) 297. An electrical control unit (ECU) is an embedded system in automotive electronics that controls one or more of the electrical systems or subsystems in a vehicle. The ECU may include, but is not limited to, management of the vehicle's engine, braking system, transmission system, door locks, instrument panel, airbag system, infotainment system, electronic differential, and active suspension. The ECU is connected to the vehicle's CAN bus 294. The ECU may also communicate with a vehicle computer 298 via the CAN bus 294. The vehicle's processor / sensor (such as a vehicle computer) 298 may communicate with external elements such as a server 293 via a network 292 (such as the Internet). Each ECU 295, 296 and head unit 297 may contain its own security policy. The security policy defines the allowed processes that can be executed in the appropriate context. In one example, the security policy may be provided in part or in whole in the vehicle computer 298.

[0116] The ECUs 295, 296 and the head unit 297 may each include a custom security function element 299 that defines the authorization processes and the contexts in which these processes are allowed to run. Context-based authorization determines the validity of whether a process can be executed, which allows the ECU to maintain secure operation and prevent unauthorized access from elements such as the vehicle's controller area network (CAN bus). When an ECU encounters an unauthorized process, the ECU can prevent the process from running. The automotive ECU can use different contexts (such as proximity contexts (such as nearby objects, distance to approaching objects, speed, and trajectory relative to other moving objects), as well as operational contexts (such as an indication of whether the vehicle is moving or parked, the current speed of the vehicle, the transmission status), user-related contexts (such as devices connected to the vehicle via wireless protocols, the use of infotainment, cruise control, parking assistance, driving assistance, location-based contexts, and / or other contexts) to determine whether a process is running within its allowed scope.

[0117] In one example, the solution described and depicted herein can be used to partially disable a vehicle by (in some embodiments) limiting speed, limiting the ability to approach other vehicles, limiting the speed to a maximum, and allowing only a given number of miles per time period. In one example, the solution can also be used to use blockchain to facilitate the exchange of vehicle ownership, wherein data is sent to a server by a device related to a vehicle accident or a device near the accident. Depending on the severity of the accident or attempted accident, the server notifies the sender of the data. In one example, the solution can also be used to help vehicles avoid accidents (for example, when a vehicle is involved in an accident by querying a server of other vehicles near the accident). The server attempts to obtain data from other vehicles, allowing the server to understand the nature of the accident from multiple vantage points. In one example, the solution can also be used to determine that the sound from the vehicle is atypical, and send data related to the sound and possible source location to the server, wherein the server can determine possible causes and avoid potentially dangerous situations. In one example, the solution can also be used to establish a location boundary via the system when a vehicle is involved in an accident. The boundary is based on decibels associated with the accident. Multimedia content of devices within the boundary is obtained to help further understand the situation of the accident. In one example, the solution can also be used to associate a vehicle with an accident and then capture media obtained by a device near the accident location. The captured media is saved as a media clip. The media clip is sent to another computing device that builds a sound profile of the accident. The sound profile helps understand more details around the accident.

[0118] In one example, the solution may also be used to utilize sensors to record audio, video, motion, etc. to record areas where potential events are occurring, such as if a vehicle is in contact or may come into contact with other vehicles (while moving or parked), the system capturing data from sensors that may be located on one or more of the vehicles and / or fixed or moving objects. In one example, the solution may also be used to determine if a vehicle is damaged by using sensor data to identify a new condition of the vehicle during a vehicle event and comparing that condition to a vehicle condition profile, thereby enabling safe and reliable capture of critical data from a vehicle about to undergo a harmful event.

[0119] In one example, the solution may also be used to warn the occupants of a vehicle when the vehicle determines via one or more sensors that it is approaching or traveling along a one-way street the wrong way. The vehicle has sensors / cameras / maps that interact with the system of the current solution. The system knows the geographic location of the one-way street. For example, the system may notify the occupants by sound that "you are approaching a one-way street." In one example, the solution may also be used to allow the vehicle to be paid, thereby allowing autonomous vehicle owners to monetize the data collected and stored by their vehicle sensors, incentivizing vehicle owners to share their data and provide additional data to entities (through which the performance of future vehicles is improved), providing services to vehicle owners, etc.

[0120] In one example, the solution may also be used to increase or decrease features of a vehicle based on the operation of the vehicle over a period of time. In one example, the solution may also be used to assign partial ownership to a vehicle. Sensor data associated with one or more vehicles and devices in proximity to the vehicle is used to determine a condition of the vehicle. Partial ownership of the vehicle is determined based on the condition, and new vehicle responsibility is provided. In one example, the solution may also be used to provide data to a replacement / upgrade component, wherein the data attempts to subvert an authorized function of the replacement / upgrade component, and in response to non-subversion of the authorized function, use of the authorized function of the replacement / upgrade component is allowed by the component.

[0121] In one example, the solution may also be used to provide individuals with the ability to ensure that an occupant should be in a vehicle and that the occupant arrives at a specific destination. In addition, the system ensures that the driver (if it is a non-autonomous vehicle) and / or other occupants are authorized to interact with the occupant. In addition, pickups and locations are also recorded. All of the above is stored on the blockchain in an immutable manner. In one example, the solution may also be used to determine the characteristics of the driver by analyzing driving style and other factors to take action when the driver does not drive in a normal manner (such as the way the driver previously drove under specific conditions (such as daytime, night, rain, snow, etc.)). In addition, the attributes of the vehicle are also considered. Attributes include weather, whether the headlights are on, whether navigation is used, whether HUD is used, the volume of media played, etc. In one example, the solution may also be used to notify the occupants in the vehicle of a dangerous situation when items in the vehicle indicate that the occupants may not be aware of the dangerous situation.

[0122] In one example, the solution may also be used to mount a calibration device on a rig fixed to a vehicle, wherein various sensors on the vehicle may automatically adjust themselves based on what the calibration device should detect compared to what is actually detected. In one example, the solution may also be used to use blockchain to require consensus from multiple service centers when a vehicle in need of service sends fault information that allows remote diagnostic functionality, wherein consensus on the severity threshold of the data is required from other service centers. Once consensus is received, the service center may send the fail-safe level to the blockchain for storage. In one example, the solution may also be used to determine the difference between sensor data external to the vehicle and sensor data of the vehicle itself. The vehicle requests software from a server to correct the problem. In one example, the solution may also be used to allow messaging to vehicles in the vicinity or area when an event occurs (e.g., a collision).

[0123] Reference Fig.2I , showing an operating environment 290A for a connected vehicle according to some embodiments. As shown, the vehicle 276 includes a CAN bus 291A that connects elements 292A to 299A of the vehicle. Other elements may be connected to the CAN bus and are not shown here. The elements shown connected to the CAN bus include a sensor group 292A, an electronic control unit 293A, an autonomous feature or advanced driver assistance system (ADAS) 294A, and a navigation system 295A. In some embodiments, the vehicle 276 includes a processor 296A, a memory 297A, a communication unit 298A, and an electronic display 299A.

[0124] Processor 296A includes an arithmetic logic unit, a microprocessor, a general purpose controller, and / or a similar processor array to perform calculations and provide electronic display signals to display unit 299A. Processor 296A processes data signals and may include various computing architectures, including a complex instruction set computer (CISC) architecture, a reduced instruction set computing (RISC) architecture, or an architecture that implements a combination of instruction sets. Vehicle 276 may include one or more processors 296A. Other processors, operating systems, sensors, displays, and physical configurations (not shown) that are communicatively coupled to each other may be used with the instant solution.

[0125] Memory 297A is a non-transient memory that stores instructions or data that can be accessed and executed by processor 296A. Instructions and / or data may include the code for executing the technology described herein. Memory 297A may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, a flash memory or another memory device. In certain embodiments, memory 297A may also include a non-volatile memory or similar permanent storage device and medium, which may include a hard drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device or some other large-capacity storage devices for permanent storage information. A part of memory 297A may be reserved for use as a buffer or a virtual random access memory (virtual RAM). Without departing from current solutions, vehicles 276 may include one or more memory 297A.

[0126] The memory 297A of the vehicle 276 may store one or more of the following types of data: navigation route data 295A and autonomous feature data 294A. In some embodiments, the memory 297A stores data required for the navigation application 295A to provide functionality.

[0127] The navigation system 295A can describe at least one navigation route including a starting point and an end point. In some embodiments, the navigation system 295A of the vehicle 276 receives a request for a navigation route from a user, wherein the request includes a starting point and an end point. The navigation system 295A can query (via the network 292) a real-time data server 293 (such as a server providing driving directions) for navigation route data corresponding to the navigation route including a starting point and an end point. The real-time data server 293 sends the navigation route data to the vehicle 276 via the wireless network 292, and the communication system 298A stores the navigation data 295A in the memory 297A of the vehicle 276.

[0128] ECU 293A controls the operation of many systems of vehicle 276 including ADAS system 294A. ECU 293A can, in response to instructions received from navigation system 295A, deactivate any unsafe and / or unselected autonomous functions during a trip controlled by ADAS system 294A. In this way, navigation system 295A can control whether ADAS systems 294A are activated or enabled so that they can be activated for a given navigation route.

[0129] The sensor group 292A may include any sensor in the vehicle 276 that generates sensor data. For example, the sensor group 292A may include short-range sensors and long-range sensors. In some embodiments, the sensor group 292A of the vehicle 276 may include one or more of the following vehicle sensors: cameras, lidar sensors, ultrasonic sensors, automotive engine sensors, radar sensors, laser altimeters, manifold absolute pressure sensors, infrared detectors, motion detectors, thermostats, sound detectors, carbon monoxide sensors, carbon dioxide sensors, oxygen sensors, mass air flow sensors, engine coolant temperature sensors, throttle position sensors, crankshaft position sensors, valve timers, air-fuel ratio meters, blind spot meters, curb feeler gauges, defect detectors, Hall effect sensors, parking sensors, radar guns, speedometers, speed sensors, tire pressure monitoring sensors, torque sensors, transmission fluid temperature sensors, turbine speed sensors (TSS), variable reluctance sensors, vehicle speed sensors (VSS), water sensors, wheel speed sensors, GPS sensors, mapping functions, and any other types of automotive sensors. The navigation system 295A may store sensor data in the memory 297A.

[0130] The communication unit 298A transmits and receives data with the network 292 or another communication channel. In some embodiments, the communication unit 298A may include a DSRC transceiver, a DSRC receiver, and other hardware or software required to make the vehicle 276 a DSRC-equipped device.

[0131] The vehicle 276 may interact with other vehicles 277 via V2V technology. In one example, V2V communication includes sensing radar information corresponding to a relative distance to an external object, receiving GPS information of a vehicle, setting an area to an area where other vehicles 277 are located based on the sensed radar information, calculating a probability that the GPS information of the target vehicle is located at the set area, and identifying a vehicle and / or object corresponding to the radar information and the GPS information of the target vehicle based on the calculated probability.

[0132] In one example, the solution described and depicted herein can be used to manage emergency situations and vehicle features when a vehicle is determined to be entering an area without network access. In one example, the solution can also be used to manage and provide functions (such as audio, video, navigation, etc.) in a vehicle without a network connection. In one example, the solution can also be used to determine when the profile of a person near the vehicle matches the profile attributes of at least one occupant in the vehicle. A notification is sent from the vehicle to establish communication.

[0133] In one example, the solution may also be used to analyze the availability of occupants in various vehicles for voice communications based on the amount of time remaining in the vehicle and the context of the communication to be performed. In one example, the solution may also be used to determine two levels of threat for road obstructions and receive a gesture that may indicate that the obstruction has not risen above a threshold alert and proceed along the road by the vehicle. In one example, the solution may also be used to delete sensitive data from a vehicle when damage to the vehicle renders it unusable.

[0134] In one example, the solution may also be used to verify whether the customer data to be removed has indeed been removed from all required locations within the enterprise to demonstrate GDPR compliance. In one example, the solution may also be used to provide consideration from one vehicle to another in the exchange of data related to safety, important notifications, etc., to enhance the autonomous capabilities of low-level autonomous vehicles. In one example, the solution may also be used to provide a vehicle with the ability to receive data based on a first biometric associated with an occupant. The vehicle then decrypts the encrypted data based on the verification of a second biometric, wherein the second biometric is a continuum of the first biometric. When only the occupant can receive unencrypted data, the vehicle provides the occupant with unencrypted data, and deletes the sensitive portion of the unencrypted data when providing the sensitive portion and deletes the non-sensitive portion after a period of time associated with the biometric. In one example, the solution may also be used to provide a vehicle with the ability to verify an individual based on the weight and grip pressure applied to the steering wheel of the vehicle. In one example, the solution may also be used to provide a car with features that exist but are not currently enabled, thereby presenting features that reflect the characteristics of the occupant to the occupant of the car.

[0135] In one example, the solution may also be used to allow modification of a vehicle, in particular the interior of the vehicle and the exterior of the vehicle, to reflect and assist at least one occupant. In another example, the work and / or home environment of the occupant is publicly reconstructed. If the system determines that the user is in "work mode" or "home mode", the system may try to "reconstruct" the user's work / home environment when the user is in the vehicle. All data related to the interior and exterior of the vehicle and the various occupants utilizing the vehicle are stored on the blockchain and executed via smart contracts. In one example, the solution may also be used to detect occupant gestures to assist in communicating with nearby vehicles, where the vehicle can be manipulated accordingly. In one example, the solution may also be used to provide the vehicle with the ability to detect expected gestures using a gesture definition database. In one example, the solution may also be used to provide the vehicle with the ability to take various actions based on gait and user gestures. In one example, the solution may also be used to ensure that the driver of a vehicle currently performing various operations (e.g., driving while talking while turning on navigation, etc.) does not exceed the number of unsafe operations before being allowed to make gestures.

[0136] In one example, the solution may also be used to assign a state to each occupant in a vehicle, and to verify gestures from the occupant based on the occupant's state. In one example, the solution may also be used to collect sound details related to a collision (at what position, in what direction, rising or falling, from what device, data related to the device, such as type, manufacturer, owner, and the number of sounds in the same period and the time of sound emission, etc.), and the analysis provided to the data helps determine the system of the details of the collision. In one example, the solution may also be used to determine whether the operation of the vehicle is unsafe. The vehicle includes a plurality of components that operate mutually to control the vehicle, and each component is associated with a separate component key. An encryption key is sent to the vehicle to reduce the vehicle function. In response to receiving a cryptographic key, the vehicle disables one or more of the component keys. Disabling one or more component keys results in one or more of the following situations: limiting the moving speed of the vehicle to not exceed a given speed, limiting the distance between the vehicle and other vehicles to not exceed a distance, and limiting the travel distance of the vehicle to not exceed a threshold distance.

[0137] In one example, the solution may also be used to provide an indication that blockchain is used to perform verification and coordination from one specific vehicle (about to vacate a location) to another specific vehicle (seeking to occupy a location). In one example, the solution may also be used to determine partial responsibility for a vehicle. In situations such as the following: multiple people own a single vehicle, and the use of the vehicle may change over a period of time, the system uses the use of the vehicle to update partial ownership. Other embodiments are also included in the application, including minimum ownership of a vehicle based on the availability of the vehicle and the determination of the driver and others of the vehicle rather than the use of the vehicle.

[0138] In one example, the solution may also be used to allow a user to reach their subscription with a closed group of people such as family members or friends in a vehicle. For example, a user may wish to share a membership, and if so, the relevant transaction is stored in a blockchain or conventional database. When a user who is not a primary subscriber requests a subscription material, the blockchain node (i.e., the vehicle) can verify that the person requesting the service is an authorized person who shares the profile with the subscriber. In one example, the solution may also be used to allow someone to utilize a supplementary vehicle to reach an intended destination. Functional relationship values ​​(e.g., values ​​indicating various parameters and their importance in determining which type of alternative vehicle to use) are used when determining a supplementary vehicle. In one example, the solution may also be used to allow occupants in an accident to take other vehicles to continue to their initial destination.

[0139] In one example, the solution may also be used to propagate software / firmware uploads to a first subset of vehicles. This first subset of vehicles tests the update, and, when the test is successful, the update is propagated to another group of vehicles. In one example, the solution may also be used to propagate software / firmware updates to vehicles from a master vehicle that propagates updates from a first subset through a vehicle network, followed by a larger subset, and so on. A portion of the update may be sent first, followed by the remainder sent from the same vehicle or another vehicle. In one example, the solution may also be used to provide updates to the vehicle's computer to the devices of the vehicle and the vehicle operator / passenger. The update may be authorized by all drivers and / or all occupants. The software update is provided to the vehicle and the device. The user does not have to do anything, just approach the vehicle, and the function occurs automatically. A notification is sent to the device indicating that the software update has been completed. In one example, the solution may also be used to verify that the OTA software update is performed by a qualified technician, and that one or more vehicle components generate a status related to the initiator of the verification code, a process for wirelessly receiving the software update, information contained in the software update, and the results of the verification.

[0140] In one example, the solution may also be used to provide the ability for a software update located in a first component to be parsed by a second component. A first portion of a critical update and a second portion of a non-critical update are then verified, the first portion of the verification is assigned to a process in a vehicle, the first portion of the verification is run with one process during a time period, and in response to a positive result based on the time period, the first portion of the verification is run with another process after the time period. In one example, the solution may also be used to provide a selection of services to an occupant, where the service is based on a profile of an occupant of the vehicle and a shared profile shared with the occupant's profile. In one example, the solution may also be used to store user profile data in a blockchain and intelligently present offers and recommendations to a user based on the user's automatically collected purchase history and preferences obtained from the user profile on the blockchain.

[0141] In order to adequately protect a vehicle, the vehicle must be protected from unauthorized physical access as well as unauthorized remote access (e.g., cyber threats). In one example, to prevent unauthorized physical access, the vehicle is equipped with a secure access system such as keyless entry. At the same time, in one example, security protocols are added to the vehicle's computers and computer networks to facilitate secure remote communications with the vehicle.

[0142] Electronic Control Units (ECUs) are nodes within a vehicle that control tasks such as activating windshield wipers or even tasks such as anti-lock brakes. ECUs are usually connected to each other through a central network of the vehicle, which may be referred to as a CAN bus. State-of-the-art features such as autonomous driving strongly rely on implementing new complex ECUs, such as advanced driver assistance systems (ADAS) and sensors. While these new technologies help improve vehicle safety and driving experience, they also increase the number of external communication units inside the vehicle, making it more vulnerable to attacks. The following are some examples of protecting vehicles from physical and remote intrusions.

[0143] Figure 2J A keyless entry system 290B for preventing unauthorized physical access to a vehicle 291B is shown according to an example embodiment. Figure 2JIn one example, the key fob 292B sends a command to the vehicle 291B by using a radio frequency signal. In this example, the key fob 292B includes a transmitter 2921B having an antenna capable of sending short-range wireless radio signals. The vehicle 291B includes a receiver 2911B having an antenna capable of receiving short-range wireless signals sent from the transmitter 2921B. The key fob 292B and the vehicle 291B also include CPUs 2922B and 2913B, respectively, that control the various devices. Here, the memory (or CPU-accessible memory) of the CPUs 2922B and 2913B. In one example, each of the key fob 292B and the vehicle 291B includes power supplies 2924B and 2915B for powering the various devices.

[0144] When the user presses the button 293B on the keychain 292B (or otherwise activates the keychain, etc.), the CPU 2922B wakes up in the keychain 292B and sends a data stream to the transmitter 2921B, which is output via the antenna. In other embodiments, the user's intention is confirmed on the keychain 292B via other components (such as via a microphone that receives audio, a camera that captures images and / or video, or other sensors commonly used in the art) to detect the intention from the user (including receiving gestures, movements, and eye movements, etc.). The data stream can be a 64-bit to 128-bit long signal that includes one or more of a preamble, a command code, and a rolling code. The signal can be sent at a rate between 2KHz and 20KHz, but the embodiment is not limited thereto. In response, receiver 2911B of vehicle 291B captures the signal from transmitter 2921B, demodulates the signal, and sends a data stream to CPU 2913B, which decodes the signal and sends a command (e.g., lock doors, unlock doors, etc.) to command module 2912B.

[0145] If the key fob 292B and the vehicle 291B use fixed codes between them, a replay attack can be performed. In this case, if the attacker can capture / sniff the fixed code during short-range communication, the attacker can replay the code to enter the vehicle 291B. To improve security, the key fob and the vehicle 291B can use a rolling code that changes after each use. Here, the key fob 292B and the vehicle 291B are synchronized with the initial seed 2923B (e.g., a random number, a pseudo-random number, etc.). This is called pairing. The key fob 292B and the vehicle 291 also include a shared algorithm for modifying the initial seed 2914B each time the button 293B is pressed. The following key presses will take the result of the previous key press as input and convert it into the next number in the sequence. In some cases, when the vehicle 291B does not detect the key on the key fob 292B, the vehicle 291B can store multiple next codes (e.g., 255 next codes). Thus, a few key presses on the key fob 292B that the vehicle 291B cannot hear do not prevent the vehicle from becoming out of sync.

[0146] In addition to rolling codes, key fob 292B and vehicle 291B may also employ other methods to make attacks more difficult. For example, different frequencies may be used to transmit rolling codes. As another example, two-way communication between transmitter 2921B and receiver 2911B may be used to establish a secure session. As another example, the code may have a limited expiration time or timeout. In addition, referring to Figure 2J The instant solution described and depicted may be used in this and other networks and / or systems, including those described and depicted herein.

[0147] Figure 2K FIG. 2 shows a CAN bus 290C in a vehicle according to an example embodiment. Figure 2K , CAN 290C includes a CAN bus 297C having a high terminal and a low terminal and a plurality of electronic control units (ECUs) 291C, 292C, 293C, etc. connected to the CAN bus 297C via a wired connection. The CAN bus 297C is designed to allow microcontrollers and devices to communicate with each other in applications without a host computer. The CAN bus 297C implements a message-based protocol (i.e., the ISO 11898 standard) that allows ECUs 291C-293C to send commands to each other at the root level. At the same time, ECUs 291C-293C represent controllers for controlling electrical systems or subsystems within a vehicle. Examples of electrical systems include power steering, anti-lock brakes, air conditioning, tire pressure monitoring, cruise control, and many other functions.

[0148] In this example, the ECU 291C includes a transceiver 2911C and a microcontroller 2912C. The transceiver can be used to send and receive messages with the CAN bus 297C. For example, the transceiver 2911C can convert data from the microcontroller 2912C to the format of the CAN bus 297C, and can also convert data from the CAN bus 297C to a format for the microcontroller 2912C. At the same time, in one example, the microcontroller 2912C interprets the message and also decides what message to send by using the ECU software installed therein.

[0149] To protect the CAN 290C from cyber threats, various security protocols may be implemented. For example, subnetworks (e.g., subnetworks A and B, etc.) may be used to divide the CAN 290C into smaller sub-CANs and limit the ability of an attacker to remotely access the vehicle. Figure 2K In the example of , ECU 291C and 292C can be part of the same subnet, while ECU 293C is part of a separate subnet. In addition, a firewall 294C (or gateway, etc.) can be added to prevent messages from traversing the CAN bus 297C across the subnets. If an attacker accesses one subnet, the attacker cannot access the entire network. In one example, to make the subnets more secure, the most critical ECUs are not placed on the same subnet.

[0150] although Figure 2K Not shown, but other examples of security control within the CAN include an intrusion detection system (IDS) that can be added to each sub-network and reads all transmitted data to detect malicious messages. If a malicious message is detected, the IDS can notify the car user. Other possible security protocols include encryption / security keys that can be used to hide messages. As another example, in one example, an authentication protocol is implemented that enables messages to self-authenticate.

[0151] In addition to protecting the vehicle's internal network, the vehicle can also be protected when communicating with external networks such as the Internet. One of the benefits of having a vehicle connection to a data source such as the Internet is that information from the vehicle can be sent over the network to a remote location for analysis. Examples of vehicle information include GPS, onboard diagnostics, and tire pressure, among others. These communication systems are often referred to as telematics because they involve a combination of telecommunications and informatics. In addition, referring to Figure 2K The instant solution described and depicted may be used in this and other networks and / or systems, including those described and depicted herein.

[0152] Figure 2L A secure end-to-end vehicle communication channel is shown according to an example embodiment. Figure 2L, the telematics network 290D includes a vehicle 291D and a host server 295D that is set at a remote location (e.g., a network server, a cloud platform, a database, etc.) and connected to the vehicle 291D via a network such as the Internet. In this example, a device 296D associated with the host server 295D can be installed within a network within the vehicle 291D. In addition, although not shown, the device 296D can be connected to other elements of the vehicle 291D, such as a CAN bus, an on-board diagnostic (ODBII) port, a GPS system, a SIM card, and a modem. The device 296D can collect data from any of these systems and transmit the data to the server 295D via the network.

[0153] The secure management of data begins with the vehicle 291D. In some embodiments, the device 296D can collect information before, during, and after a trip. The data may include GPS data, driving data, occupant information, diagnostic data, fuel data, speed data, etc. However, the device 296D may only transmit the collected information back to the host server 295D in response to the vehicle ignition and the trip completion. In addition, the communication may be initiated only by the device 296D, not by the host server 295D. Therefore, in one example, the device 296D will not accept communications initiated by an external source.

[0154] In order to perform communication, device 296D can establish a secure private network between device 296D and host server 295D. Here, device 296D may include a tamper-proof SIM card that provides secure access to carrier network 294D via radio tower 292D. When preparing to transmit data to host server 295D, device 296D can establish a one-way secure connection with host server 295D. Carrier network 294D can communicate with host server 295D by using one or more security protocols. As a non-limiting example, carrier network 294D can communicate with host server 295D via a VPN tunnel that allows access through firewall 293D of host server 295D. As another example, carrier network 294D can use data encryption (e.g., AES encryption, etc.) when transmitting data to host server 295D. In some cases, multiple security measures such as VPN and encryption that can be used by the system to further protect data.

[0155] In addition to communicating with external servers, vehicles can also communicate with each other. In particular, vehicle-to-vehicle (V2V) communication systems enable vehicles to communicate with each other and with roadside infrastructure (such as traffic lights, signs, cameras, parking meters, etc.) via wireless networks. Wireless networks may include one or more of Wi-Fi networks, cellular networks, and dedicated short-range communication (DSRC) networks, etc. Vehicles can use V2V communications to provide other vehicles with information about the speed, acceleration, braking, and direction of the vehicle. Therefore, vehicles can understand the conditions ahead before they become visible, thereby greatly reducing collisions. In addition, with reference to Figure 2L The instant solution described and depicted may be used in this and other networks and / or systems, including those described and depicted herein.

[0156] Figure 2M An example 290E is shown of vehicles 293E and 292E performing secure V2V communications using security certificates according to an example embodiment. Figure 2M , vehicles 293E and 292E can communicate via V2V communication through a short-range network or a cellular network, etc. Before sending a message, vehicles 293E and 292E can sign the message using their respective public key certificates. For example, vehicle 293E can sign the V2V message using public key certificate 294E. Similarly, vehicle 292E can sign the V2V message using public key certificate 295E. In one example, public key certificates 294E and 295E are associated with vehicles 293E and 292E, respectively.

[0157] When receiving communications from each other, the vehicles can verify the signature with the certificate authority 291E or the like. For example, the vehicle 292E can verify with the certificate authority 291E that the public key certificate 294E used by the vehicle 293E to sign the V2V communication is authentic. If the vehicle 292E successfully verifies the public key certificate 294E, then the vehicle knows that the data is from a legitimate source. Similarly, the vehicle 293E can verify with the certificate authority 291E that the public key certificate 295E used by the vehicle 292E to sign the V2V communication is authentic. In addition, referring to Figure 2M The instant solution described and depicted may be used in this and other networks and / or systems, including those described and depicted herein.

[0158] Figure 2N Still another diagram 290F depicting an example of a vehicle interacting with a secure processor and a wireless device according to an example embodiment is shown. In some embodiments, Figure 2B The computer 224 shown may include: Figure 2NThe security processor 292F shown in the example process 290F of FIG. In particular, the security processor 292F can perform authorization, authentication, cryptography (e.g., encryption), etc. on data transmissions sent between the ECU and other devices on the vehicle's CAN bus and data messages transmitted between different vehicles.

[0159] exist Figure 2N In the example of , the security processor 292F may include an authorization module 293F, an authentication module 294F, and an encryption module 295F. The security processor 292F may be implemented within a vehicle's computer and may communicate with other vehicle elements (e.g., an ECU / CAN network 296F, wired and wireless devices 298F such as wireless network interfaces, and input ports, etc.). The security processor 292F may ensure that data frames (e.g., CAN frames, etc.) transmitted within the vehicle (e.g., via the ECU / CAN network 296F) are secure. Similarly, the security processor 292F may ensure that messages transmitted between different vehicles and devices fixed or connected to the vehicle's computer via wires are also protected.

[0160] For example, the authorization module 293F can store passwords, user names, PIN codes, and biometric scans of different vehicle users. The authorization module 293F can determine whether a user (or technician) has access to certain settings, such as a computer of a vehicle. In some embodiments, the authorization module can communicate with a network interface to download any necessary authorization information from an external server. When a user wishes to change vehicle settings or modify technical details of a vehicle via a console or GUI in the vehicle or via a fixed / connected device, the authorization module 293F can require the user to verify himself in some way before changing these settings. For example, the authorization module 293F may require a user name, password, PIN code, biometric scan, and predefined line drawing or gestures, etc. In response, the authorization module 293F can determine whether the user has the necessary permissions (access, etc.) requested.

[0161] The authentication module 294F can be used to authenticate internal communications between ECUs on the CAN network of the vehicle. As an example, the authentication module 294F can provide information for authenticating communications between ECUs. As an example, the authentication module 294F can send a bit signature algorithm to the ECU of the CAN network. The ECU can use the bit signature algorithm to insert the authentication bit into the CAN field of the CAN frame. All ECUs on the CAN network usually receive each CAN frame. Whenever a new CAN frame is generated by one of the ECUs, the bit signature algorithm can dynamically change the position, amount, etc. of the authentication bit. The authentication module 294F can also provide a list of ECUs that are exempted and do not need to use the authentication bit (security list). The authentication module 294F can communicate with a remote server to retrieve updates to the bit signature algorithm, etc.

[0162] The encryption module 295F can store asymmetric key pairs used by the vehicle to communicate with other external user devices and vehicles. For example, the encryption module 295F can provide a private key used by the vehicle to encrypt / decrypt communications, and the corresponding public key can be provided to other user devices and vehicles to enable other devices to decrypt / encrypt communications. The encryption module 295F can communicate with a remote server to receive new keys, key updates, keys for new vehicles, users, etc. The encryption module 295F can also send any updates to the local private / public key pair to the remote server.

[0163] Figure 3A A flowchart 300 is shown according to an example embodiment. Figure 3A , the flowchart includes one or more of the following operations: linking a mobile device and a vehicle 302, configuring a data service request on the mobile device 304, receiving a data service request from the mobile device at a controller area network of the vehicle 306, and displaying a data set responsive to the configuration within the vehicle 308.

[0164] Figure 3B Another flow chart 320 is shown according to an example embodiment. Figure 3B, the flowchart includes one or more of the following operations: determining that the mobile device and one or more other mobile devices are in the vehicle, modifying the data service request based on the combination of the mobile devices, and displaying the modified data based on the combination 322; determining that the mobile device is not in the vehicle, determining that the mobile device is close to one or more other vehicles related to the vehicle, and transmitting the data service request from the mobile device to the one or more other vehicles 323; determining that the mobile device is in another vehicle, receiving the data service request from the mobile device at a controller area network of the other vehicle, configuring the data service request in the other vehicle on the mobile device, and displaying the data responsive to the configuration in the other vehicle 324, wherein the data service request includes the purchased service; determining that the mobile device is not in the vehicle, determining that the mobile device is close to one or more other vehicles related to the vehicle, and transmitting the data service request from the mobile device to the one or more other vehicles 323; determining that the mobile device is in another vehicle, receiving the data service request from the mobile device at a controller area network of the other vehicle, configuring the data service request in the other vehicle on the mobile device, and displaying the data responsive to the configuration in the other vehicle 324. Determine that one or more other vehicles associated with the vehicle are eligible to receive the purchased service, notify the one or more other vehicles of a data service request including the purchased service, and display data responsive to the purchased service in the other vehicles 325; receive a user profile from a mobile device, determine a common interest area between a threshold in the user profile and the vehicle's data, and display the common interest area and data values ​​associated with the threshold in the vehicle when the threshold is exceeded 326; and link another mobile device and the vehicle, configure another data service request on the other mobile device, receive another data service request from the mobile device at a controller area network of another vehicle, and determine which of the data service request and the other data service request to display 327.

[0165] Figure 3C Another flow chart 340 is shown according to an example embodiment. Figure 3C , the flowchart includes one or more of the following operations: receiving confirmation of an event from one or more elements described or depicted herein, wherein the confirmation includes a blockchain consensus 342 between peers represented by any of the elements; and executing a smart contract to record the confirmation 344 on a blockchain based on the blockchain consensus.

[0166] Figure 4 A machine learning vehicle network diagram 400 is shown according to an example embodiment. The network 400 includes a vehicle 402 that interfaces with a machine learning subsystem 406. The vehicle includes one or more sensors 404.

[0167] The machine learning subsystem 406 includes a learning model 408, which is a mathematical artifact created by a machine learning training system 410 that generates predictions by finding patterns in one or more training data sets. In some embodiments, the machine learning subsystem 406 resides in the vehicle 402. In other embodiments, the machine learning subsystem 406 resides outside the vehicle 402.

[0168] The vehicle 402 sends data from one or more sensors 404 to a machine learning subsystem 406. The machine learning subsystem 406 provides the one or more sensor 404 data to a learning model 408, which returns one or more predictions. The machine learning subsystem 406 sends one or more instructions to the vehicle 402 based on the predictions from the learning model 408.

[0169] In another embodiment, vehicle 402 may send one or more sensor 404 data to machine learning training system 410. In another example, machine learning subsystem 406 may send sensor 404 data to machine learning subsystem 410. One or more of the applications, features, steps, solutions, etc. described and / or depicted herein may utilize machine learning network 400 described herein.

[0170] Figure 5A An example vehicle configuration 500 is shown for managing database transactions associated with a vehicle according to an example embodiment. Figure 5A , when a particular vehicle / vehicle 525 participates in a transaction (e.g., vehicle service, dealer transaction, delivery / pickup, vehicle service, etc.), the vehicle may receive assets 510 and / or evict / transfer assets 512 in accordance with the transaction. A vehicle processor 526 resides in the vehicle 525, and there is communication between the vehicle processor 526, the database 530, the vehicle processor 526, and the transaction module 520. The transaction module 520 may record information such as assets, parties, credits, service descriptions, dates, times, locations, results, notifications, incidents, etc. Those transactions in the transaction module 520 may be replicated in the database 530. The database 530 may be one of a SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, and may be on the vehicle, may be off the vehicle, may be accessed directly and / or through a network, or may be accessed by the vehicle.

[0171] Figure 5BAn example vehicle configuration 550 for managing database transactions between various vehicles is shown according to an example embodiment. When a vehicle has reached a state where it is necessary to share services with other vehicles, the vehicle 525 can interact with other vehicles 508 to perform various actions, such as sharing, delivery, obtaining service calls, etc. For example, the vehicle 508 may need battery charging and / or may have tire problems, and may be on the way to pick up a delivery. The vehicle processor 528 resides in the vehicle 508, and there is communication between the vehicle processor 528, the database 554, and the transaction module 552. The vehicle 508 can notify other vehicles 525 that are in its network and running on its blockchain member service. The vehicle processor 526 resides in the vehicle 525, and there is communication between the vehicle processor 526, the database 530, the vehicle processor 526, and the transaction module 520. The vehicle 525 can then request to receive information via wireless communication to perform a package pickup from the vehicle 508 and / or from a server (not shown). The transaction is recorded in the transaction modules 552 and 520 of the two vehicles. Credit is transferred from vehicle 508 to vehicle 525, and the record of the service transferred is recorded in database 530 / 554, assuming that the blockchains are different from each other, or in the same blockchain used by all members. Database 554 can be one of a SQL database, RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, and can be on the vehicle, can be outside the vehicle, can be accessed directly and / or through a network.

[0172] Fig. 6A A blockchain architecture configuration 600 is shown according to an example embodiment. Fig. 6A , the blockchain architecture 600 may include certain blockchain elements, such as a set of blockchain member nodes 602-606 as part of a blockchain group 610. In an example embodiment, a permissioned blockchain is not accessible to all parties, but only to those members who have access to blockchain data. Blockchain nodes participate in several activities, such as blockchain entry addition and verification processes (consensus). One or more of the blockchain nodes may endorse entries based on an endorsement policy, and may provide subscription services for all blockchain nodes. Blockchain nodes may initiate blockchain actions (such as verification) and seek to write to a blockchain immutable ledger stored in the blockchain, a copy of which may also be stored on the underlying physical architecture.

[0173] When the transaction is received and approved by the consensus model specified by the member nodes, the blockchain transaction 620 is stored in the memory of the computer. The approved transaction 626 is stored in the current block of the blockchain and is submitted to the blockchain via a submission process, which includes performing a hash on the data content of the transaction in the current block and referencing the previous hash of the previous block. Within the blockchain, there may be one or more smart contracts 630 that define the terms of the transaction agreement and the actions contained in the smart contract executable application code 632, such as registered recipients, vehicle features, requirements, permissions, sensor thresholds, etc. The code can be configured to identify whether the requesting entity is registered to receive vehicle services, which service features they are entitled / need to receive considering their profile status, and whether to monitor their actions in subsequent events. For example, when a service event occurs and the user is traveling in the vehicle, sensor data monitoring can be triggered, and specific parameters such as vehicle charge level can be identified as being above / below a specific threshold within a specific time period, and the result may then be a change in the current state, which requires an alert to be sent to the management party (i.e., the vehicle owner, vehicle operator, server, etc.), so the service can be identified and stored for reference. The vehicle sensor data collected can be based on the type of sensor data used to collect information about the state of the vehicle. The sensor data can also be the basis for vehicle event data 634, such as the location to be traveled, the average speed, the maximum speed, the acceleration rate, whether there are any collisions, whether the expected route is taken, where the next destination is, whether safety measures are taken, whether the vehicle has enough power / fuel, etc. All of this information can serve as the basis for smart contract terms 630, which are then stored in the blockchain. For example, sensor thresholds stored in a smart contract can be used as the basis for detecting whether a service is necessary and when and where the service should be performed.

[0174] Figure 6B A shared ledger configuration according to an example embodiment is shown. Figure 6B , blockchain logic example 640 includes a blockchain application interface 642 as an API or plug-in application linked to a computing device and execution platform for a specific transaction. Blockchain configuration 640 may include one or more applications that link to an application programming interface (API) to access and execute stored program / application code (e.g., smart contract executable code, smart contracts, etc.), which can be created according to the customized configuration sought by the participants and can maintain its own state, control its own assets, and receive external information. This can be deployed as an entry and installed on all blockchain nodes by attaching to the distributed ledger.

[0175] Smart contract application code 644 provides the basis for blockchain transactions by establishing application code that, when executed, validates the terms and conditions of the transaction. Smart contracts 630, when executed, cause certain approved transactions 626 to be generated, which are then forwarded to the blockchain platform 652. The platform includes security / authorization 658, a computing device that performs transaction management 656, and a storage portion 654 that acts as a memory for storing transactions and smart contracts in the blockchain.

[0176] The blockchain platform may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and underlying physical computer infrastructure that may be used to receive and store new entries and provide access to auditors seeking access to data entries. The blockchain may expose an interface that provides access to the virtual execution environment required to process program code and participate in the physical infrastructure. Cryptographic trust services may be used to verify entries such as asset exchange entries and keep the information private.

[0177] Fig. 6A and 6B The blockchain architecture configuration can process and execute program / application code through the blockchain platform via one or more exposed interfaces and provided services. As a non-limiting example, smart contracts can be created to perform reminders, updates, and / or other notifications affected by changes, updates, etc. The smart contract itself can be used to identify rules associated with authorization and access requirements and ledger usage. For example, information can include new entries, which can be processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer. The results can include decisions to reject or approve new entries based on criteria defined in the smart contract and / or consensus of peers. The physical infrastructure can be used to retrieve any data or information described herein.

[0178] In smart contract executable code, smart contracts can be created via high-level applications and programming languages ​​and then written to blocks in the blockchain. Smart contracts can include executable code that is registered, stored, and / or replicated using a blockchain (e.g., a distributed network of blockchain peers). An entry is an execution of the smart contract code that can be executed in response to the satisfaction of a condition associated with the smart contract. The execution of a smart contract may trigger a trusted modification of the state of a digital blockchain ledger. Modifications to the blockchain ledger caused by the execution of a smart contract can be automatically replicated throughout the distributed network of blockchain peers through one or more consensus protocols.

[0179] Smart contracts can write data to the blockchain in the format of key-value pairs. In addition, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to the blockchain. The code can be used to create temporary data structures in virtual machines or other computing platforms. The data written to the blockchain can be public and / or can be encrypted and kept as private data. Temporary data used / generated by the smart contract is kept in memory by the supplied execution environment and then deleted after the data required by the blockchain is identified.

[0180] The smart contract executable code may include a code interpretation of the smart contract with additional features. As described herein, the smart contract executable code may be a program code deployed on a computing network, where it is executed and verified together by a chain validator during a consensus process. The smart contract executable code receives a hash and retrieves a hash associated with a data template created by using a previously stored feature extractor from the blockchain. If the hash of the hash identifier and the hash created from the stored identifier template data match, the smart contract executable code sends an authorization key to the requested service. The smart contract executable code may be written to blockchain data associated with encryption details.

[0181] Figure 6C A blockchain configuration for storing blockchain transaction data according to an example embodiment is shown. Figure 6C , an example configuration 660 provides a vehicle 662, a user device 664, and a server 666 that share information with a distributed ledger (i.e., blockchain) 668. The server can represent a service provider entity that queries a vehicle service provider to share user profile rating information when a known and established user profile attempts to rent a vehicle using an established rating profile. The server 666 can receive and process data related to service requirements for the vehicle. When a service event occurs, such as vehicle sensor data indicating that fuel / power is required, maintenance service, etc., smart contracts can be used to invoke rules, thresholds, sensor information collection, etc., which can be used to invoke vehicle service events. Blockchain transaction data 670 is saved for each transaction, such as access events, subsequent updates to vehicle service status, event updates, etc. The transaction may include the parties, requirements (e.g., 18 years of age, eligible candidate for service, valid driver's license, etc.), compensation level, distance traveled during the event, registered recipients allowed to access the event and host vehicle service, rights / authorities, sensor data retrieved during the vehicle event operation to record details of the next service event and identify the condition status of the vehicle, and thresholds used to determine whether the service event is completed and whether the vehicle condition status has changed.

[0182] Fig.6D680 and the contents of block structures 682A-682n that may be added to a distributed ledger according to an example embodiment. Fig.6D , a client (not shown) can submit entries to a blockchain node to perform activities on the blockchain. As an example, a client can be an application that proposes a blockchain entry on behalf of a requester (such as a device, person, or entity). Multiple blockchain peers (e.g., blockchain nodes) can maintain the state of the blockchain network and a copy of the distributed ledger. There may be different types of blockchain nodes / peers in a blockchain network that includes endorsement peers that simulate and endorse entries proposed by clients and commit peers that verify endorsements, verify entries, and submit entries to the distributed ledger. In this example, a blockchain node can perform the role of an endorser node, a committer node, or both.

[0183] The live system consists of a blockchain that stores immutable, ordered records in the form of blocks, and a state database (the current world state) that maintains the current state of the blockchain. There may be one distributed ledger per channel, and each peer maintains its own copy of the distributed ledger for each channel of which it is a member. The live blockchain is a log of entries structured as hash-linked blocks, where each block contains a sequence of N entries. Blocks may include entries such as Fig.6D The various components shown in . A chain of blocks can be generated by adding the hash of the previous block's block header in the current block's block header. In this way, all entries on the blockchain are ordered and cryptographically linked together, preventing tampering of the blockchain data without breaking the hash chaining. In addition, due to the chaining, the latest block in the blockchain represents every entry that came before it. The live blockchain can be stored on a peer-to-peer file system (local or attached storage), which supports append-only blockchain workloads.

[0184] The current state of the blockchain and distributed ledger can be stored in a state database. Here, the current state data represents the latest values ​​of all keys ever included in the chain entry log of the blockchain. Smart contract executable code calls execute entries against the current state in the state database. In order to make these smart contract executable code interactions very efficient, the latest values ​​of all keys are stored in the state database. The state database can include an indexed view into the blockchain's entry log, so it can be regenerated from the chain at any time. The state database can be automatically restored at peer startup (or generated when needed) before accepting an entry.

[0185] An endorsing node receives an entry from a client and endorses the entry based on the simulation results. An endorsing node maintains a smart contract that simulates the entry proposal. When an endorsing node endorses an entry, the endorsing node creates an entry endorsement, which is a signed response of the endorsing node to the client application's indication of the endorsement of the simulated entry. The method of endorsing an entry depends on an endorsement policy that can be specified in the smart contract executable code. An example of an endorsement policy is "a majority of endorsing peers must endorse the entry". Different channels may have different endorsement policies. The endorsed entry is forwarded by the client application to the ordering service.

[0186] The ordering service accepts endorsed entries, orders them into blocks, and delivers blocks to submitting peers. For example, an ordering service can start a new block when an entry threshold is reached, a timer times out, or other conditions occur. In this example, a blockchain node is a submitting peer that has received data block 682A to store on the blockchain. The ordering service may consist of a group of subscribers. The ordering service does not handle entries, smart contracts, or maintain a shared ledger. Instead, the ordering service can accept endorsed entries and specify the order in which these entries are submitted to the distributed ledger. The architecture of the blockchain network can be designed so that the specific implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) becomes a pluggable component.

[0187] Entries are written to the distributed ledger in a consistent order. The order of entries is established to ensure that updates to the state database are valid when submitted to the network. Unlike cryptocurrency blockchain systems (such as Bitcoin, etc.) where ordering occurs through the solution of cryptographic puzzles or mining, in this example, the parties to the distributed ledger can choose the ordering mechanism that best suits the network.

[0188] refer to Fig.6D, a block 682A (also referred to as a data block) stored on a blockchain and / or distributed ledger may include multiple data segments, such as block headers 684A-684n, transaction-specific data 686A-686n, and block metadata 688A-688n. It should be understood that the various blocks shown and their contents, such as block 682A and its contents, are for illustrative purposes only and are not meant to limit the scope of the example embodiments. In some cases, both the block header 684A and the block metadata 688A may be smaller than the transaction-specific data 686A storing the entry data; however, this is not required. Block 682A may store transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) within block data 690A-690n. Block 682A may also include a link to a previous block (e.g., on a blockchain) within the block header 684A. In particular, the block header 684A may include a hash of the previous block header. The block header 684A may also include a unique block number and a hash of the block data 690A of the current block 682A, etc. The block number of the block 682A may be unique and assigned in increments / sequentially starting from zero. The first block in the blockchain may be referred to as a genesis block, which includes information about the blockchain, its members, data stored therein, etc.

[0189] Block data 690A may store entry information for each entry recorded in the block. For example, the entry data may include one or more of the following items: entry type, version, timestamp, channel ID of the distributed ledger, entry ID, epoch, payload visibility, smart contract executable code path (deployment tx), smart contract executable code name, smart contract executable code version, input (smart contract executable code and function), client (creator) identification (such as public key and certificate), client signature, endorser identity, endorser signature, proposal hash, smart contract executable code event, response status, namespace, read set (list of keys and versions read by the entry, etc.), write set (list of keys and values, etc.), start key, end key, list of keys and Merkle tree query summary, etc. Entry data may be stored for each of the N entries.

[0190] In some embodiments, the block data 690A may also store transaction-specific data 686A, which adds additional information to the hash-linked blockchain in the blockchain. Thus, the data 686A may be stored in an immutable block log on a distributed ledger. Some of the benefits of storing such data 686A are reflected in the various embodiments disclosed and described herein. The block metadata 688A may store multiple metadata fields (e.g., as a byte array, etc.). The metadata fields may include a signature when the block was created, a reference to the last configured block, an entry filter that identifies valid and invalid entries within the block, a persistent last offset of an ordering service that orders the block, etc. The signature, last configured block, and subscriber metadata may be added by the ordering service. At the same time, the submitter of the block (such as a blockchain node) may add validity / invalidity information based on endorsement policies, read / write set verification, etc. The entry filter may include a byte array of size equal to the number of entries in the block data 610A and a verification code that identifies whether the entry is valid / invalid.

[0191] The other blocks 682B-682n in the blockchain also have block headers, files, and values. However, unlike the first block 682A, each of the block headers 684A-684n in the other blocks includes a hash value of the immediately preceding block. The hash value of the immediately preceding block may be just the hash of the block header of the previous block, or may be the hash value of the entire previous block. By including the hash value of the preceding block in each of the remaining blocks, tracking from the Nth block back to the genesis block (and the associated original files) can be performed on a block-by-block basis (such as shown by arrow 692) to establish an auditable and immutable chain of custody.

[0192] The above embodiments may be implemented in hardware, a computer program executed by a processor, firmware, or a combination thereof. The computer program may be embodied in a computer-readable medium such as a storage medium. For example, the computer program may reside in a random access memory ("RAM"), a flash memory, a read-only memory ("ROM"), an erasable programmable read-only memory ("EPROM"), an electrically erasable programmable read-only memory ("EEPROM"), a register, a hard disk, a removable disk, a compact disk read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

[0193] An exemplary storage medium may be coupled to a processor such that the processor can read information from and write information to the storage medium. In an alternative, the storage medium may be integrated with the processor. The processor and the storage medium may reside in an application specific integrated circuit ("ASIC"). In an alternative, the processor and the storage medium may reside as discrete components. For example, Figure 7An example computer system architecture 700 is shown that may represent or integrate any of the above components, among others.

[0194] Figure 7 It is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the applications described herein.In any event, computing node 700 is capable of implementing and / or performing any of the functionality set forth above.

[0195] In computing node 700, there is a computer system / server 702 that operates with numerous other general or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with computer system / server 702 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems or devices, etc.

[0196] Computer system / server 702 may be described in the general context of computer system-executable instructions, such as program modules, executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic and data structures, etc. that perform particular tasks or implement particular abstract data types. Computer system / server 702 may be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.

[0197] like Figure 7 As shown, a computer system / server 702 in a cloud computing node 700 is represented in the form of a general-purpose computing device. Components of the computer system / server 702 may include, but are not limited to, one or more processors or processing units 704, a system memory 706, and a bus that couples various system components including the system memory 706 to the processor 704.

[0198] Bus refers to one or more of several types of bus structures including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0199] Computer system / server 702 generally includes various computer system readable media. Such media can be any available media accessible to computer system / server 702, and it includes volatile and non-volatile media, removable and non-removable media. In one example, system memory 706 implements the flow charts of other diagrams. System memory 706 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 708 and / or cache memory 710. Computer system / server 702 can also include other removable / non-removable, volatile / non-volatile computer system storage media. As an example only, a memory 706 for reading and writing about non-removable, non-volatile magnetic media (not shown, commonly referred to as "hard drive") can be provided. Although not shown, a disk drive for reading and writing about a removable, non-volatile disk (e.g., "floppy disk") and an optical disk drive for reading or writing about a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media can be provided. In this case, one or more data media interfaces can be connected to the bus, respectively. As will be further depicted and described below, memory 706 may include at least one program product having a set (eg, at least one) of program modules that are configured to implement the functions of various embodiments of the present application.

[0200] As an example and not limitation, a program / utility having a set (at least one) of program modules and an operating system, one or more application programs, other program modules, and program data may be stored in memory 706. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment. The program modules typically implement the functions and / or methods of various embodiments of the present application as described herein.

[0201] Those skilled in the art will appreciate that aspects of the present application may be embodied as systems, methods or computer program products. Therefore, aspects of the present application may take the form of a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.) or a combination of software and hardware embodiments, which may all be generally referred to herein as "circuit", "module" or "system". In addition, aspects of the present application may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program codes embodied thereon.

[0202] The computer system / server 702 may also communicate with one or more external devices, one or more devices that enable a user to interact with the computer system / server 702, and / or any device (e.g., a network card, a modem, etc.) that enables the computer system / server 702 to communicate with one or more other computing devices via an I / O device 712 (such as an I / O adapter), which may include a keyboard, a pointing device, a display, a voice recognition module, etc. Such communication may occur via an I / O interface of the device 712. The computer system / server 702 may also communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) via a network adapter. As shown, the device 712 communicates with other components of the computer system / server 702 via a bus. It should be understood that, although not shown, other hardware and / or software components may be used in conjunction with the computer system / server 702. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archiving storage systems.

[0203] Although illustrated in the drawings and described in the foregoing detailed description, exemplary embodiments of at least one of the systems, methods, and non-transient computer-readable media, it should be understood that the present application is not limited to the disclosed embodiments, but is capable of many rearrangements, modifications, and substitutions set forth and defined by the following claims. For example, the capabilities of the systems of the various diagrams can be performed by one or more of the modules or components described here or in a distributed architecture, and can include a transmitter, a receiver, or a pair of both. For example, all or part of the functions performed by each module can be performed by one or more of these modules. In addition, the functions described herein can be performed at various times and with respect to various events inside or outside the module or component. In addition, the information sent between the various modules can be sent between the modules via at least one of a data network, the Internet, a voice network, an Internet protocol network, a wireless device, a wired device, and / or via a variety of protocols. In addition, messages sent or received by any one of the modules can be sent or received directly and / or via one or more of the other modules.

[0204] Those skilled in the art will appreciate that a "system" may be embodied as a personal computer, server, console, personal digital assistant (PDA), cellular phone, tablet computing device, smart phone, or any other suitable computing device or combination of devices. Presenting the above functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but is intended to provide one example among many embodiments. In fact, the methods, systems, and apparatus disclosed herein may be implemented in localized and distributed forms consistent with computing technology.

[0205] It should be noted that some of the system features described in this specification are presented as modules to more particularly emphasize their implementation independence. For example, a module can be implemented as a hardware circuit including a custom very large scale integrated circuit (VLSI) circuit or gate array, an off-the-shelf semiconductor (such as a logic chip), a transistor, or other discrete components. A module can also be implemented in a programmable hardware device such as a field programmable gate array, a programmable array logic, a programmable logic device, or a graphics processing unit.

[0206] Also can be at least partially for being used for being implemented by the software of various types of processors.The identification unit of executable code can for example comprise one or more physical or logical blocks of computer instructions, and these instructions can for example be organized as object, process or function.But the executable file of the module of identification does not need to be physically located together, but can comprise the completely different instructions stored in different locations, and these instructions comprise module and realize the predetermined purpose of this module when being logically connected together.In addition, module can be stored on computer readable medium, and this computer readable medium can be for example hard disk drive, flash erase memory, random access memory (RAM), magnetic tape or any other such medium for storing data.

[0207] In fact, a module of executable code may be a single instruction or many instructions, and may even be distributed over several different code segments, between different programs, and between multiple storage devices. Similarly, operational data may be identified and shown here within a module, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations (including on different storage devices), and may exist, at least in part, only as electronic signals on a system or network.

[0208] It is easy to understand that the components of the present application generally described and shown in the drawings herein can be arranged and designed in a variety of different configurations. Therefore, the detailed description of the embodiments is not intended to limit the scope of the claimed application, but only represents the selected embodiments of the present application.

[0209] Those skilled in the art will readily appreciate that the above may be practiced with steps in different orders and / or with hardware elements in configurations different from the disclosed configurations. Therefore, although the present application has been described based on these preferred embodiments, certain modifications, variations, and alternative configurations will be clear to those skilled in the art.

[0210] Although preferred embodiments of the present application have been described, it will be understood that the described embodiments are merely illustrative and that the scope of the present application will be limited solely by the appended claims when considering the full range of equivalents and modifications thereof (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A method comprising: Linking mobile devices and vehicles; configuring a data service request on the mobile device; receiving, at a controller area network of the vehicle, a data service request from the mobile device; as well as A data set responsive to the configuration is displayed within the vehicle.

2. The method according to claim 1, comprising: determining that the mobile device and one or more other mobile devices are within the vehicle; Modifying data service requests based on a combination of mobile devices; as well as Modified data based on the combination is displayed.

3. The method according to claim 1, comprising: determining that the mobile device is not in the vehicle; determining that the mobile device is in proximity to one or more other vehicles associated with the vehicle; as well as A data service request is communicated from the mobile device to the one or more other vehicles.

4. The method according to claim 1, comprising: determining that the mobile device is in another vehicle; receiving, at a controller area network of the other vehicle, a data service request from the mobile device; configuring, on the mobile device, a data service request in the other vehicle; and Data responsive to the configuration is displayed in the other vehicle.

5. The method of claim 1, wherein the data service request comprises a purchased service, wherein the method comprises: determining that one or more other vehicles related to the vehicle are eligible to receive the purchased service; notifying the one or more other vehicles of the data service request including the purchased service; and Data responsive to the purchased service is displayed within the other vehicle.

6. The method according to claim 1, comprising: receiving a user profile from the mobile device; determining a common area of ​​interest between a user profile and a threshold in data of the vehicle; as well as When a threshold is exceeded, a common area of ​​interest and a data value associated with the threshold are displayed within the vehicle.

7. The method according to claim 1, comprising: linking other mobile devices with the vehicle; configuring other data service requests on the other mobile devices; receiving other data service requests from mobile devices at controller area networks of other vehicles; as well as One of the data service request and the other data service request to be displayed is determined.

8. A system comprising: processor; as well as a memory coupled to the processor, the memory comprising instructions that, when executed by the processor, are configured to: Linking mobile devices and vehicles; configuring a data service request on the mobile device; receiving, at a controller area network of the vehicle, a data service request from the mobile device; as well as A data set responsive to the mobile device configuration data service request is displayed within the vehicle.

9. The system of claim 8, wherein the instructions are configured to: determining that the mobile device and one or more other mobile devices are within the vehicle; modifying the data service request based on the combination of mobile devices; and Modified data based on the combination is displayed.

10. The system of claim 8, wherein the instructions are configured to: determining that the mobile device is not in the vehicle; determining that the mobile device is in proximity to one or more other vehicles related to the vehicle; and A data service request is communicated from the mobile device to the one or more other vehicles.

11. The system of claim 8, wherein the instructions are configured to: determining that the mobile device is in another vehicle; receiving, at a controller area network of the other vehicle, a data service request from the mobile device; configuring, on the mobile device, a data service request in the other vehicle; and Data responsive to the mobile device configuration data service request is displayed in the other vehicle.

12. The system of claim 8, wherein the data service request comprises a purchased service, wherein the instructions are configured to: determining that one or more other vehicles related to the vehicle are eligible to receive the purchased service; notifying the one or more other vehicles of the data service request including the purchased service; and Data responsive to the purchased service is displayed within the other vehicle.

13. The system of claim 8, wherein the instructions are configured to: receiving a user profile from the mobile device; determining a common area of ​​interest between a user profile and a threshold in the data of the vehicle; and When a threshold is exceeded, a common area of ​​interest and a data value associated with the threshold are displayed within the vehicle.

14. The system of claim 8, wherein the instructions are configured to: linking other mobile devices with the vehicle; configuring other data service requests on the other mobile devices; receiving other data service requests from mobile devices at controller area networks of other vehicles; and One of the data service request and the other data service request to be displayed is determined.

15. A computer-readable storage medium comprising instructions which, when read by a processor, cause the processor to execute: Linking mobile devices and vehicles; configuring a data service request on the mobile device; receiving, at a controller area network of the vehicle, a data service request from the mobile device; and A data set responsive to the configuration is displayed within the vehicle.

16. The computer-readable storage medium of claim 15, wherein the instructions cause the processor to execute: determining that the mobile device and one or more other mobile devices are within the vehicle; modifying the data service request based on the combination of mobile devices; and Modified data based on the combination is displayed.

17. The computer-readable storage medium of claim 15, wherein the instructions cause the processor to execute: determining that the mobile device is not in the vehicle; determining that the mobile device is in proximity to one or more other vehicles related to the vehicle; and A data service request is communicated from the mobile device to the one or more other vehicles.

18. The computer-readable storage medium of claim 15, wherein the instructions cause the processor to execute: determining that the mobile device is in another vehicle; receiving, at a controller area network of the other vehicle, a data service request from the mobile device; configuring, on the mobile device, a data service request in the other vehicle; and Data responsive to the configuration is displayed in the other vehicle.

19. The computer-readable storage medium of claim 15, wherein the data service request comprises a purchased service, wherein the instructions cause the processor to: determining that one or more other vehicles related to the vehicle are eligible to receive the purchased service; notifying the one or more other vehicles of the data service request including the purchased service; and Data responsive to the purchased service is displayed within the other vehicle.

20. The computer-readable storage medium of claim 15, wherein the instructions cause the processor to perform: receiving a user profile from the mobile device; determining a common area of ​​interest between a user profile and a threshold in the data of the vehicle; and When a threshold is exceeded, a common area of ​​interest and a data value associated with the threshold are displayed within the vehicle.

Images