Bluetooth RF features for active security countermeasures

Abstract

Example operations include starting, by a vehicle, a timer when a pairing request is initiated; receiving, by the vehicle, a first response to the pairing request from the first device and a second response to the pairing request from the second device; recording a timer when each of the first response and the second response is received; determining a first connection time for the first device from the recorded timer and a second connection time for the second device from the recorded timer; and connecting, by the vehicle, to a device having the fastest connection time among the first device and the second device.

Description

Background Art

[0001] Vehicles or transportation means (such as cars, motorcycles, trucks, airplanes, trains, etc.) usually provide transportation needs to passengers and / or goods in various ways. Functions related to the transportation means can be recognized and utilized by various computing devices, such as computers or smart phones located on and / or outside the transportation means. Summary of the Invention

[0002] An example embodiment provides a method including one or more of the following: when a pairing request is initiated, starting a timer by a vehicle; receiving, by the vehicle, a first response to the pairing request from a first device and a second response to the pairing request from a second device; when each of the first response and the second response is received, recording the timer; determining, from the recorded timer, a first connection time for the first device and a second connection time for the second device; and connecting, by the vehicle, to the device having the fastest connection time among the first device and the second device.

[0003] Another example embodiment provides a system including a processor and a memory, wherein the processor and the memory are communicatively coupled, and wherein the processor: when a pairing request is initiated, starts a timer by a vehicle; receives, by the vehicle, a first response to the pairing request from a first device and a second response to the pairing request from a second device; when each of the first response and the second response is received, records the timer; determines, from the recorded timer, a first connection time for the first device and a second connection time for the second device; and connects, by the vehicle, to the device having the fastest connection time among the first device and the second device.

[0004] Another example embodiment provides a computer-readable storage medium including instructions that, when read by a processor, cause the processor to perform one or more of the following: when a pairing request is initiated, starting a timer by a vehicle; receiving, by the vehicle, a first response to the pairing request from a first device and a second response to the pairing request from a second device; when each of the first response and the second response is received, recording the timer; determining, from the recorded timer, a first connection time for the first device and a second connection time for the second device; and connecting, by the vehicle, to the device having the fastest connection time among the first device and the second device. Brief Description of the Drawings

[0005] Figure 1A An example system diagram according to an example embodiment is shown.

[0006] Figure 1BShows another example of a system diagram according to an example embodiment.

[0007] Figure 2A Shows a vehicle network diagram according to an example embodiment.

[0008] Figure 2B Shows another vehicle network diagram according to an example embodiment.

[0009] Figure 2C Shows yet another vehicle network diagram according to an example embodiment.

[0010] Figure 2D Shows another vehicle network diagram according to an example embodiment.

[0011] Figure 2E Shows yet another vehicle network diagram according to an example embodiment.

[0012] Figure 2F Shows a diagram depicting the electrification of one or more components according to an example embodiment.

[0013] Figure 2G Shows a diagram depicting the interconnection between different components according to an example embodiment.

[0014] Figure 2H Shows another diagram depicting the interconnection between different components according to an example embodiment.

[0015] Figure 2I Shows yet another diagram depicting the interconnection between components according to an example embodiment.

[0016] Figure 2J Shows yet another diagram depicting a keyless entry system according to an example embodiment.

[0017] Figure 2K Shows yet another diagram depicting the CAN within a vehicle according to an example embodiment.

[0018] Figure 2L Shows yet another diagram depicting an end-to-end communication channel according to an example embodiment.

[0019] Figure 2M Shows yet another diagram depicting an example of a vehicle using a security certificate to perform secure V2V communication according to an example embodiment.

[0020] Figure 2N Shows yet another diagram depicting an example of a vehicle interacting with a security processor and a wireless device according to an example embodiment.

[0021] Figure 3A Shows a flowchart according to an example embodiment.

[0022] Figure 3B Shows another flowchart according to an exemplary embodiment.

[0023] Figure 3C Shows yet another flowchart according to an exemplary embodiment.

[0024] Figure 4 Shows a machine learning vehicle network diagram according to an exemplary embodiment.

[0025] Figure 5A Shows an example vehicle configuration for managing database transactions associated with a vehicle according to an exemplary embodiment.

[0026] Figure 5B Shows another example vehicle configuration for managing database transactions conducted between various vehicles according to an exemplary embodiment.

[0027] Figure 6A Shows a blockchain architecture configuration according to an exemplary embodiment.

[0028] Figure 6B Shows another blockchain configuration according to an exemplary embodiment.

[0029] Figure 6C Shows a blockchain configuration for storing blockchain transaction data according to an exemplary embodiment.

[0030] Figure 6D Shows an example data block according to an exemplary embodiment.

[0031] Figure 7 Shows an example system supporting one or more exemplary embodiments. Detailed Description

[0032] It will be readily understood that, as generally described and illustrated in the figures herein, the components of the present disclosure can be arranged and designed in a variety of different configurations. Accordingly, the following detailed description of embodiments of at least one of the method, apparatus, computer-readable storage medium, and system as represented in the figures is not intended to limit the scope of the application as claimed, but is merely representative of selected embodiments. The multiple embodiments depicted herein are not intended to limit the scope of the solution. The computer-readable storage medium can be a non-transitory computer-readable medium or a non-transitory computer-readable storage medium.

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

[0034] The features, structures, or characteristics described in this specification can be combined in any suitable manner in one or more embodiments. For example, throughout this specification, the use of the phrases "example embodiment", "some embodiments", or other similar language refers to the fact that a particular feature, structure, or characteristic described in connection with an embodiment can be included in at least one example. Thus, the appearances of the phrases "example embodiment", "in some embodiments", "in other embodiments", or other similar language throughout this specification do not necessarily all refer to the same set of embodiments, and the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the figures, any connection between elements can permit one-way and / or two-way communication, even if the depicted connection is a one-way or two-way arrow. In the current solution, a vehicle or transportation means can include one or more of an automobile, a truck, a walking area battery electric vehicle (BEV), an electric palette (e-Palette), 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.

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

[0036] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide at least one of a transportation vehicle (also referred to herein as a vehicle or car), 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 / transportation vehicle status conditions and provide feedback regarding the condition and / or changes of the transportation vehicle. In one example, a user profile can be applied to a particular transportation vehicle / vehicle to authorize current vehicle events, service stops at service stations, authorize subsequent vehicle rental services, and enable vehicle-to-vehicle communication.

[0037] Within a communication infrastructure, a decentralized database is a distributed storage system that includes multiple nodes that communicate with each other. A blockchain is an example of a decentralized database that includes an append-only immutable data structure (i.e., a distributed ledger) capable of maintaining records between untrusted parties. Untrusted parties are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify the database records without consensus being reached among the distributed peers. For example, peers can execute a consensus protocol to verify blockchain storage entries, group the storage entries into blocks, and build a hash chain via the blocks. For consistency, this process forms a ledger by sorting the storage entries as needed. In a public blockchain or permissionless blockchain, anyone can participate without a specific identity. Public blockchains can be involved with cryptocurrencies and use consensus based on various protocols such as proof of work (PoW). In contrast, a permissioned blockchain database can ensure interactions between a group of entities, such as enterprises that exchange funds, goods, information, etc., that share a common goal but do not trust or cannot fully trust each other. The present solution can operate in a permissioned blockchain setting and / or a permissionless blockchain setting.

[0038] A smart contract is a trusted distributed application that leverages the tamper-proof properties of a shared or distributed ledger, which can be in the form of a blockchain, and the underlying protocol between member nodes, which is referred to as endorsement or endorsement policy. Generally, 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 the entry to the peers specified in the endorsement policy, the entry is executed to verify the entry. After verification, the entry enters a sorting phase in which a consensus protocol produces an ordered sequence of the endorsed entries grouped into blocks.

[0039] A node is a communication entity in a blockchain system. A "node" can perform logical functions, meaning that 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 proposals to the ordering service (e.g., ordering nodes). Another type of node is a peer node, which can receive entries submitted by clients, submit entries, and maintain a copy of the ledger of blockchain entries and the state. Peers can also have the role of endorsers. Ordering service nodes or orderers are nodes that run communication services for all nodes and implement delivery guarantees, such as broadcasting to each peer node in the system when an entry is submitted and the world state of the blockchain is modified. The world state can constitute the initial blockchain entry, which typically includes control and setup information.

[0040] A ledger is an ordered and tamper-proof record of all state transitions of a blockchain. State transitions can be caused by calls to smart contract executable code (i.e., entries) submitted by parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Entries can result in a set of asset key-value pairs being submitted to the ledger as one or more operands, such as create, update, delete, etc. The ledger includes a blockchain (also known as a chain), which stores immutable ordered records in blocks. The ledger also includes a state database, which 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.

[0041] A chain is an entry log of blocks constructed as a hash link, and each block contains a sequence of N entries, where N is equal to or greater than one. The block header includes the hash of the entries in the block and the hash of the previous block header. In this way, all entries on the ledger can be sorted and cryptographically linked together. Therefore, it is impossible to tamper with ledger data without breaking the hash link. The hash of the most recently added blockchain block represents every entry that has appeared before it on the chain, such that it can be ensured 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.), thus efficiently supporting the append-only nature of the blockchain workload.

[0042] The current state representation of an immutable ledger includes the latest values of all keys in the chain item log. Since the current state representation consists of the latest key values known to the channel, it is sometimes referred to as the world state. Smart contract executable code calls the current state data of the ledger to perform entries. To make these smart contract executable code interactions efficient, the latest values of the keys can be stored in a state database. The state database can be just an index view of the chain item log and can thus be regenerated from the chain at any time. The state database can be automatically restored (or generated if needed) when the peer node starts up and before an entry is accepted.

[0043] A blockchain differs from a traditional database in that a blockchain is not a central storage but a decentralized, immutable, and secure storage where nodes must share the changes to the records in the storage. Some of the properties inherent in a blockchain and that help enable a blockchain include, but are not limited to, an immutable ledger, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, etc.

[0044] Example embodiments provide services to a particular vehicle and / or a user profile applied to the vehicle. For example, the user can be the owner of the vehicle or the operator of a vehicle owned by another party. The vehicle may need services at certain intervals, and the service requirements may need to be authorized before the service can be received. Also, a service center can provide services to vehicles in a nearby area based on the vehicle's current route plan and the relative service requirement levels (e.g., immediate, severe, medium, minor, etc.). Vehicle requirements can be monitored via one or more vehicle and / or road sensors or cameras that report the sensed data to a central controller computer device in and / or away from the vehicle. This data is forwarded to a management server for review and action. The sensors can be located on one or more of the interior of the vehicle, the exterior of the vehicle, fixed objects away from the vehicle, and another vehicle near the vehicle. The sensors can also be related to the speed of the vehicle, the braking of the vehicle, the acceleration of the vehicle, the fuel level, the service requirement, the gear shift of the vehicle, the steering of the vehicle, etc. As described herein, the sensors can also be devices such as wireless devices in and / or near the vehicle. Also, the sensor information can be used to identify whether the vehicle is operating safely and whether the occupants have been involved in any unexpected vehicle conditions, such as during the vehicle access and / or use period. The vehicle information collected before, during, and / or after vehicle operation can be identified and stored in a transaction on a shared / distributed ledger, which can be generated and submitted to an immutable ledger as determined by a permission-granting consortium and is thus in a "decentralized" manner, such as via a blockchain membership group.

[0045] Each stakeholder (i.e., owner, user, company, agent, etc.) may want to limit the exposure of private information, and thus the blockchain and its immutability can be used to manage permissions to 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 needed, identify collision and / or degradation events, identify safety concern events, identify the parties to an event, and provide distribution to registered entities seeking access to such vehicle event data. Moreover, results can be identified and the information needed can be shared among registered companies and / or individuals based on the consensus method associated with the blockchain. Such a method cannot be implemented on a traditional centralized database.

[0046] The various drive systems of the present solution can utilize software, sensor arrays, and machine learning capabilities, light detection and ranging (Lidar) projectors, radar, ultrasonic sensors, etc. to create maps of the terrain and roads that the vehicle can use for navigation and other purposes. In some embodiments, GPS, maps, cameras, sensors, etc. can also be used in autonomous vehicles in place of Lidar.

[0047] In certain embodiments, the present solution includes authorizing a vehicle for service via an automatic and fast authentication scheme. For example, driving to a charging station or fuel pump can be performed by the vehicle operator or an autonomous vehicle, and receiving authorization for charging or fuel can be performed without any delay provided that the authorization is received by the service station and / or charging station. The vehicle can provide a communication signal that provides the identification of the vehicle, which has a current active profile linked to an account authorized to receive service, and the current active profile can be amended later by compensation. Additional measures can be used to provide further authentication, such as another identifier can be wirelessly sent from the user's device to the service center to replace or supplement the first authorization effort between the vehicle and the service center with additional authorization efforts.

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

[0049] Any action described herein can be performed by one or more processors, such as a microprocessor, a sensor, an electronic control unit (ECU), a head unit, etc., with or without a memory, and the one or more processors can be located on and / or outside a vehicle (such as a server, a computer, a mobile / wireless device, etc.). The one or more processors can communicate with other memories and / or other processors on or outside other vehicles to utilize data sent by the vehicle and / or data sent to the vehicle. The one or more processors and other processors can send data, receive data, and utilize the data to perform one or more of the actions described or depicted herein.

[0050] Figure 1A FIG. 100 shows a system diagram in a set of embodiments. In some embodiments, the present solution is executed entirely or partially in the memory of a processor 108 associated with a vehicle 102, the memory of a data authentication server 103, and / or the memory of one or more other processors associated with the devices and / or entities mentioned herein. In some embodiments, the processor 108 can be or include a microcontroller that includes one or more central processing unit (CPU) cores, as well as program memory and programmable input / output peripherals. The program memory can be provided, for example, in the form of flash memory.

[0051] In some embodiments, when a pairing request is initiated by a vehicle transceiver 107, the processor 108 starts a timer 105. For example, the vehicle transceiver 107 can be a Bluetooth transceiver. Bluetooth pairing establishes a communication link between two Bluetooth-capable devices through the exchange of registration information between the two devices. For example, the two devices can include the vehicle transceiver 107 and a first device 121, or the vehicle transceiver 107 and a second device 122. In some embodiments, both the first device 121 and the second device 122 are key fobs.

[0052] In some embodiments, the vehicle transceiver 107 receives a first response to the pairing request from the first transceiver 123 at the first device 121. The vehicle transceiver 107 also receives a second response to the pairing request from the second transceiver 125 at the second device 122. When each of the first response and the second response is received, the processor 108 may record the timer 105. The processor 108 may determine a first connection time for the first device 121 from the recorded timer 105, and determine a second connection time for the second device 123 from the recorded timer 105. The processor 108 instructs the vehicle transceiver 107 to connect to the device having the fastest connection time among the first device 121 and the second device 123. For example, the vehicle transceiver 107 pairs with the one of the first device 121 or the second device 123 having the fastest connection time.

[0053] In some embodiments, a first temperature is sensed by a first temperature sensor 124 at the first device 121. A second temperature is sensed by a sensor 111 within the vehicle 102. A difference between the first temperature and the second temperature may be determined. In response to the determined difference not exceeding a threshold, a connection of the vehicle transceiver 107 to the first transceiver 123 of the first device 121 is performed. In some embodiments, the first temperature sensor 124 is configured to measure an ambient temperature at the first device 121. For example, a typical relay attack involves a first accomplice who is located outside along an outer wall of a residence where a key fob such as the first device 121 is located. A second accomplice is also located outside, very close to the vehicle 102. The two accomplices are typically located in an unshielded location where the ambient temperature will be very different from the ambient temperature observed inside the insulated interior of the vehicle 102 and / or inside the residence containing the first device 121. In some embodiments, the second device 122 includes a second temperature sensor 126.

[0054] In some embodiments, a first plurality of movements of a first person associated with the first device 121 are sensed by a camera 109 operatively coupled to the processor 108. The first plurality of movements are analyzed by the processor 108 to identify at least one pattern among the first plurality of movements. The first plurality of movements may include the way the first person walks and / or the way the first person moves their arms. A second plurality of movements of a subsequent person are sensed by the camera 109. The second plurality of movements may include the way the subsequent person walks and / or the way the subsequent person moves their arms. The subsequent person may be the first person having the first device 121, or a second person having the second device 123. The first person may be an authorized owner or lessee of the vehicle 102, while the second person may be a bad actor attempting to steal the vehicle 102.

[0055] In some embodiments, when the second plurality of movements match at least one of the identified patterns, the processor 108 determines that the subsequent person is the first person and performs the connection of the vehicle transceiver 107 to the first device 121. When the second plurality of movements do not match at least one of the identified patterns, the processor 108 determines that the subsequent person is not the first person and the processor 108 requests authentication before performing the connection.

[0056] Authentication is the process of determining whether someone or something is actually who or what it claims to be. Authentication can be used to provide access control for a system such as the vehicle 102. For example, the processor 108 can establish a communication link to the data authentication server 103 via the network 104. The data authentication server 103 can check the authorized user database 113 to see if the credentials of the intended user match any of the authorized user credentials in the authorized user database 113. When the data authentication server 103 locates such a match, the intended user is allowed access to the vehicle 102. When the authentication server 103 does not locate such a match, access to the vehicle 102 is denied to the intended user.

[0057] According to one example, if the first person walks with a limping gait and the subsequent person does not walk with a limp, the processor 108 can determine that the first person is not the subsequent person. In contrast, if the first person walks with a limping gait and the subsequent person also walks with a limping gait, the processor can determine that the first person is the subsequent person. When the subsequent person is not the first person, there is a possibility that the subsequent person is a bad actor attempting to steal the vehicle 102. The processor 108 can require an authentication step in order to prevent a bad actor from accessing the vehicle transceiver 107 and potentially stealing the vehicle 102.

[0058] In some embodiments, a first wireless signal is received at the vehicle transceiver 107, such as a Bluetooth signal having a first radio frequency emission signature. A second wireless signal is also received at the vehicle transceiver 107, such as a Bluetooth signal having a second radio frequency emission signature. The first radio frequency emission signature is based on a first carrier frequency offset and / or a first I / Q (in-phase component / quadrature component) offset relative to a reference Bluetooth transmission. The second radio frequency emission signature is based on a second carrier offset and / or a second I / Q offset relative to the reference Bluetooth transmission. Different Bluetooth devices may exhibit slightly different carrier frequency offsets and / or I / Q component offsets. These offsets can potentially be used to identify a particular device, such as a Bluetooth device, such as the first device 121 and / or the second device 122.

[0059] In some embodiments, the processor 108 compares a first radio frequency emission characteristic received by the vehicle transceiver 107 with a second radio frequency emission characteristic received by the vehicle transceiver 107. In response to the first radio frequency emission characteristic matching the second radio frequency emission characteristic, the processor 108 instructs the vehicle transceiver 107 to connect to the device from which the first radio frequency emission characteristic and the second radio frequency emission characteristic were received. For example, both the first and second radio frequency emission characteristics may be received at the vehicle transceiver 107 from a first device 121. Accordingly, the vehicle transceiver 107 may be paired with the first device 121. In response to the first radio frequency emission characteristic not matching the second radio frequency emission characteristic, the processor 108 requests authentication before instructing the vehicle transceiver to connect to the first device 121 or the second device 122. For example, the first radio frequency emission characteristic may be received from the first device 121 operated by an authorized user, while the second radio frequency emission characteristic may be received from the second device 122 operated by a bad actor. Accordingly, the processor 108 will not implement a connection to the first device 121, and the processor 108 will not implement a connection to the second device 122 until the first device 121 or the second device 122 has been authenticated by the processor 108 and / or the data authentication server 103.

[0060] Figure 1B FIG. shows the system 150 in a set of embodiments. In some embodiments, the solution is executed, in whole or in part, in the memory of the processor 108 associated with the vehicle 102, the memory of the data authentication server 103, and / or the memory of one or more other processors associated with the devices and / or entities mentioned herein. In some embodiments, the processor 108 may be or include a microcontroller that includes one or more central processing unit (CPU) cores, as well as program memory and programmable input / output peripherals. The program memory may be provided, for example, in the form of flash memory.

[0061] In some embodiments, a first radio frequency signal received by vehicle transceiver 107 from a first device 121 is used to determine a first position of the first device 121. A second radio frequency signal received by vehicle transceiver 107 from a second device 122 is used to determine a second position of the second device 122. For example, the strength of the first radio frequency signal can be used to determine the first position of the first device 121, and the strength of the second radio frequency signal can be used to determine the second position of the second device 122. Alternatively or additionally, the first device 121 can include a processor 131 that receives a position identification signal from a first Global Positioning System (GPS) receiver 127 and forwards the position identification signal to the vehicle transceiver 107 using a first transceiver 123. Similarly, the second device 122 can include a processor 135 that receives a position identification signal from a second GPS receiver 128 and forwards the position identification signal to the vehicle transceiver 107 using a second transceiver 125. In one embodiment, other methods are used to determine the first position and the second position without departing from the scope of the current solution.

[0062] In some embodiments, processor 108 applies a prioritization scheme to identify a highest priority position among the first position of the first device 121 and the second position of the second device 122. Processor 108 instructs vehicle transceiver 107 to connect to the device in the highest priority position among the first device 121 and the second device 122.

[0063] In some embodiments, vehicle GPS 129 is used to determine the position of vehicle 102. Processor 108 and / or processor 131 can receive a position identification signal from vehicle GPS 129. In some embodiments, the authentication level required by the first device 121 and / or the second device 122 is determined by processor 108 and / or processor 131 based on the determined position. For example, the memory of processor 108 and / or the memory of processor 131 can include a look-up table that associates each of a plurality of position identifiers with a corresponding authentication level among a plurality of authentication levels. Similarly, a position identifier associated with a hazardous and / or high-crime location can be associated with a higher authentication level, while a position identifier associated with a low-hazard and / or low-crime location can be associated with a lower authentication level.

[0064] In some embodiments, the processor 108 and / or the processor 131 (via the network 104) instruct the vehicle transceiver 107 to perform a connection in response to a required authentication level being provided. In some embodiments, the required authentication level may be selected by the processor 108 and / or the processor 131 from a plurality of authentication levels. The first authentication level may include single-level authentication. For example, the processor 131 receives a username and password entered by the user on an input device 133 such as a keyboard, where the password matches the username. The second authentication level may include two-factor authentication. For example, receiving a unique code provided to the user via a mobile device or a digital key fob from the input device 133, and / or receiving biometric characteristics such as a face scan, a retina scan, a thumbprint, or a fingerprint from the input device 133. The third authentication level may include receiving three or more authentication factors from the user, such as three or more of the following: a username, a password, biometric characteristics, and / or personal questions that the user must answer. In other embodiments, additional and / or different authentication levels may be part of the current solution.

[0065] In some embodiments, in response to the vehicle transceiver 107 receiving a plurality of pairing requests from the first device 121, a plurality of locations of the first device 121 are determined. For example, the vehicle GPS 129 may be used to determine a plurality of locations of the vehicle 102. The processor 108 and / or the processor 131 may receive a location identification signal from the vehicle GPS 129. The processor 108 and / or the processor 131 may identify a location pattern from the plurality of locations. A subsequent pairing request may be received by the vehicle transceiver 107. For example, the location information collected by the first GPS receiver 127 is used to determine the origin location of the subsequent pairing request. The processor 131 may forward the location information via the network 104 to the processor 108. The processor 108 and / or the processor 131 compare the origin location with the location pattern. When the origin location is within the location pattern, the processor 108 and / or the processor 131 instruct the vehicle transceiver 107 to perform a connection. When the origin location is not within the location pattern, the processor 108 and / or the processor 131 request authentication from the user before performing the connection.

[0066] The flowcharts described herein (such as Figure 1A , Figure 1B , 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 operation 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 the corresponding claims.

[0067] It is important to note that, from Figure 1A , Figure 1B , Figure 2C , Figure 2D , Figure 2E , Figure 3A , Figure 3B and Figure 3C all of the flowcharts and corresponding processes derived therefrom can be part of the same process or can share sub - processes with each other, such that the diagrams can be combined into a single preferred embodiment that does not require any one particular operation, but performs some operations from one example process and from one or more additional processes. All example processes relate to the same physical system and can be used individually or interchangeably.

[0068] Figure 2A FIG. 200 shows a transportation vehicle network diagram according to an example embodiment. The network includes elements, which include a transportation vehicle 202 containing a processor 204 and a transportation vehicle 202' containing a processor 204'. The transportation vehicles 202, 202' communicate with each other via the processors 204, 204' and other elements (not shown), and the other elements include transceivers, transmitters, receivers, storage devices, sensors, and other elements capable of providing communication. Communication between the transportation vehicles 202 and 202' can occur directly, via a private network and / or a public network (not shown), or via other transportation vehicles and elements including one or more of processors, memories, and software. Although depicted as a single transportation vehicle and processor, there can be multiple transportation vehicles and processors. One or more of the applications, features, steps, solutions, etc. described and / or depicted herein can be utilized and / or provided by this element.

[0069] Figure 2BAnother transportation vehicle network diagram 210 according to an example embodiment is shown. The network includes elements, which include a transportation vehicle 202 containing a processor 204 and a transportation vehicle 202' containing a processor 204'. The transportation vehicles 202, 202' communicate with each other via the processors 204, 204' and other elements (not shown), and the other elements include transceivers, transmitters, receivers, storage devices, sensors, and other elements capable of providing communication. The communication between the transportation vehicles 202 and 202' can be carried out directly, via a dedicated network and / or a public network (not shown), or via other transportation vehicles and elements including one or more of a processor, a memory, and software. The processors 204, 204' can also communicate with one or more elements 230, and the one or more elements include a sensor 212, a wired device 214, a wireless device 216, a database 218, a mobile phone 220, a transportation vehicle 222, a computer 224, an I / O device 226, and a voice application 228. The processors 204, 204' can also communicate with elements including one or more of a processor, a memory, and software.

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

[0071] Figure 2C Another transportation vehicle network diagram 240 according to an example embodiment is shown. The network includes elements, which include a transportation 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 (which is in Figure 2B(depicted in). The vehicle 202 can be a vehicle, a server, or any device having a processor and a memory. The processor 204 performs one or more of the following: when initiating a pairing request, start a timer 244C by the vehicle; receive a first response to the pairing request from a first device and a second response 246C to the pairing request from a second device by the vehicle; when each of the first response and the second response is received, record the timer 248C; determine a first connection time for the first device from the recorded timer and determine a second connection time for the second device from the recorded timer 250C; and connect the vehicle to the device having the fastest connection time among the first device and the second device 252C.

[0072] Figure 2D Another vehicle network diagram 250 according to an example embodiment is shown. The network includes elements that include 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 an element 230 (which is depicted in Figure 2B (depicted in). The vehicle 202 can be a vehicle, a server, or any device having a processor and a memory.

[0073] The processor 204 performs one or more of the following: determining a first location of a first device using a first radio frequency signal received from the first device; determining a second location of a second device using a second radio frequency signal received from the second device; applying a prioritization scheme to identify a highest priority location among the first location and the second location; and using the highest priority location to perform connection 244D; sensing a first temperature at the first device; sensing a second temperature within the vehicle; determining a difference between the first temperature and the second temperature; and performing connection 245D in response to the determined difference not exceeding a threshold; determining a location of the vehicle; determining an authentication level required for a connection based on the determined location; and performing connection 246D in response to the required authentication level being provided; sensing a first plurality of movements of a first person associated with the first device; analyzing the first plurality of movements to identify at least one pattern among the first plurality of movements; sensing a second plurality of movements of a subsequent person; determining that the subsequent person is the first person and performing a connection when the second plurality of movements match the identified at least one pattern; and requiring authentication 247D before performing a connection when the second plurality of movements do not match the identified at least one pattern; receiving a first Bluetooth signal having first radio frequency emission characteristics from the first device; receiving a second Bluetooth signal having second radio frequency emission characteristics from the second device; comparing the first radio frequency emission characteristics with the second emission characteristics; performing a connection in response to the first radio frequency emission characteristics matching the second radio frequency emission characteristics; and requiring authentication 248D before performing a connection in response to the first radio frequency emission characteristics not matching the second radio frequency emission characteristics; determining a plurality of locations of the first device in response to a plurality of pairing requests received by the vehicle from the first device; identifying a location pattern from the plurality of locations; receiving a subsequent pairing request of the vehicle; determining an origin location of the subsequent pairing request; comparing the origin location with the location pattern; performing a connection when the origin location is within the location pattern; and requiring authentication 249D before performing a connection when the origin location is not within the location pattern.

[0074] Figure 2E Another vehicle network diagram 260 according to an example embodiment is shown. Refer to Figure 2E , the network diagram 260 includes a vehicle 202 connected to other vehicles 202' and an update server node 203 via a blockchain network 206. The vehicles 202 and 202' may represent vehicles. The blockchain network 206 may have a ledger 208 for storing software update verification data and sources 207 for verification for future use (e.g., for auditing).

[0075] Although this example only describes in detail one transportation vehicle 202, multiple such nodes can be connected to the blockchain 206. It should be understood that the transportation vehicle 202 may include additional components, and some of the components described herein may be removed and / or modified without departing from the scope of the present application. The transportation 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 transportation vehicle 202 may include multiple processors, multiple cores, etc. without departing from the scope of the present application. The transportation vehicle 202 may be a transportation vehicle, a server, or any device having a processor and a memory.

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

[0077] The processor and / or the computer-readable medium 242E may reside entirely or partially inside or outside the transportation vehicle. The steps or features stored in the computer-readable medium 242E may be executed by any processor and / or element in any order, entirely or partially. Additionally, one or more steps or features may be added, omitted, combined, executed later, etc.

[0078] Figure 2FFIG. 265 depicts the electrification of one or more components. In one example, a vehicle 266 can supply power stored in its battery to one or more components, including one or more other vehicles 268, one or more charging stations 270, and one or more power grids 272. One or more power grids 272 are 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 for the distribution of power received from the vehicle 266. The vehicle 266 can also interact with one or more other vehicles 268, such as via vehicle-to-vehicle (V2V) technology, communication via cellular, WiFi, etc. The vehicle 266 can also interact wirelessly and / or wiredly with other vehicles 268, one or more charging stations 270, and / or one or more power grids 272. In one example, the vehicle 266 is routed (or routes itself) to one or more power grids 272, one or more charging stations 270, or one or more other vehicles 268 in a safe and efficient manner. Using one or more embodiments of the present solution, the vehicle 266 can provide energy to one or more of the components depicted herein in various advantageous ways as described and / or depicted herein. Additionally, the safety and efficiency of the vehicle can be increased, and the environment can be positively affected as described and / or depicted herein.

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

[0080] In one example, the charging station 270 manages the amount of energy transferred from the vehicle 266 such that sufficient charge remains in the vehicle 266 to reach a destination. In one example, a wireless connection is used to wirelessly direct the amount of energy transfer between vehicles 268, where the vehicles can all be in motion. In one embodiment, wireless charging can occur via a stationary charger and a battery of the vehicle that are aligned with each other, such as a charging pad in a garage or parking space. In one example, an idle vehicle such as vehicle 266 (which can be autonomous) is directed to provide a certain amount of energy to the charging station 270 and return to its original location (e.g., its original location or a different destination). In one example, a mobile energy storage unit (not shown) is used to collect excess energy from at least one other vehicle 268 and transfer the stored excess energy at the charging station 270. In one example, various factors determine the amount of energy to be transferred to the charging station 270, such as distance, time, and traffic conditions, road conditions, environmental / weather conditions, the condition of the vehicle (weight, etc.), the (one or more) occupant schedules when using the vehicle, the (one or more) expected occupant schedules of waiting vehicles, etc. In one example, the (one or more) vehicles 268, the (one or more) charging stations 270, and / or the (one or more) power grids 272 can provide energy to the vehicle 266.

[0081] In one embodiment, a location such as a building, a residence, etc. (not shown) is communicatively coupled to one or more of the power grid 272, the vehicle 266, and / or the charging station 270. The current rate to one or more of the location, the vehicle 266, other vehicles 268 is modified according to external conditions (such as weather). For example, when the external temperature is very hot or very cold, the chance of power outage increases, and the current to the connected vehicles 266 / 268 is slowed down to help minimize the chance of power outage.

[0082] In one example, the solutions 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 demands and / or priorities, and provide intelligence between a device including a module and a vehicle, allowing a processor of the device to communicate wirelessly regarding the amount of energy stored in a battery on the vehicle. In one example, the solution can also be used to provide charge from a vehicle to the 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 a vehicle after a portion of the charge has been transferred to a charging station. In one example, the solution can also be used to notify a vehicle to provide a certain amount of energy from a battery on the vehicle, where the amount of energy to be transferred is based on the distance of the vehicle to a module receiving the energy.

[0083] In one example, the solution can also be used to utilize a mobile energy storage unit that travels along the determined path to a transportation vehicle having excess energy and deposits the stored energy into the power grid. In one example, the solution can also be used to determine the priority of the transportation vehicle's need to supply energy to the power grid and the priority of the transportation vehicle's current needs, such as the priority of passengers or upcoming passengers, or current cargo, or upcoming cargo. In one example, the solution can also be used to determine that when the vehicle is idle, the vehicle decides to maneuver to a location to release excess energy into the energy grid and then return to its previous location. In one example, the solution can also be used to determine, based on one or more conditions such as weather, traffic, road conditions, vehicle condition, and the occupants and / or cargo in another transportation vehicle, the amount of energy required to be transported by a transportation vehicle to another transportation vehicle via the transportation vehicle for energy transfer, and to direct the transportation vehicle to route to the other transportation vehicle and supply the energy. In one example, the solution can also be used to transfer energy from one moving vehicle to another moving vehicle. In one example, the solution can also be used to obtain the energy of a transportation vehicle based on the transportation vehicle's arrival at a meeting location with another transportation vehicle, the energy consumed in providing the service, and the estimated energy consumed in returning to the original location. In one example, the solution can also be used to provide the remaining distance to a charging station, and the charging station determines the amount of energy to obtain from the transportation vehicle, where the remaining charge amount is based on the remaining distance. In one example, the solution can also be used to manage transportation vehicles being charged simultaneously by more than one point, such as both a charging station via a wired connection and another transportation vehicle via a wireless connection. In one example, the solution can also be used to apply a priority to the allocation of energy to transportation vehicles, where the priority is given to those transportation vehicles that will supply a portion of their stored charge to another entity such as the power grid, a residence, etc.

[0084] In one embodiment, vehicles 266 and 268 can be used as bidirectional vehicles. Bidirectional vehicles are those vehicles that can be used as mobile microgrids, which can help supply power to the power grid 272 and / or reduce power consumption when the grid is strained. Bidirectional vehicles incorporate bidirectional charging, which, in addition to receiving charge into the vehicle, the vehicle can also draw energy from the vehicle and "push" the energy back into the power grid 272, which is also referred to as "V2G". In bidirectional charging, power flows bidirectionally to and from the vehicle. When the vehicle is charging, alternating current (AC) power from the power grid 272 is converted to direct current (DC). This can be performed by one or more of the vehicle's own converters or the converter in charger 270. The energy stored in the vehicle's battery can be sent back to the power grid in the opposite direction. The energy is converted from DC to AC by a converter typically located in charger 270, which is also referred to as a bidirectional charger. Additionally, as described and depicted with respect to Figure 2F The present solution can be used in this and other networks and / or systems.

[0085] Figure 2GFIG. 275 shows the interconnections between different components. This solution may be stored and / or executed, in whole or in part, on and / or 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 to and communicate with a network 286. A database 287 is communicatively coupled to the network and allows 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 residential homes 283, a power grid / charging station 284, a microphone 285, and / or another vehicle 277. Other entities and / or devices (such as one or more private users using a smartphone 278, a laptop computer 280, an augmented reality (AR) device, a virtual reality (VR) device, and / or any wearable device) may also interact with this solution. The smartphone 278, the laptop computer 280, the microphone 285, and other devices may 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 a computing device 281'. One or more service providers 279 may include a dealership, a towing service, a collision center, or other repair shops. One or more service providers 279 may utilize a computing device 279'. These various computing devices may be directly and / or communicatively coupled to each other, such as via a wired network, a wireless network, a blockchain network, and so on. In one example, the microphone 285 may be used as a virtual assistant. In one example, one or more transportation 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 transportation infrastructures. One or more transportation infrastructures 282 may utilize a computing device 282'.

[0086] In one embodiment, at any time when charging is given to and / or received from a charging station and / or a power grid, the entity(ies) allowing this to occur is / are one or more of the following: a vehicle, a charging station, a server, and a network communicatively coupled to the vehicle, the charging station, and the power grid.

[0087] In one example, the conveyance 277 / 276 can transport people, objects, permanently or temporarily fixed devices, etc. In one example, the conveyance 277 can communicate with the conveyance 276 via V2V communication through a computer associated with each conveyance 276' and 277', and can be referred to as a conveyance, automobile, vehicle, motor vehicle, etc. The conveyance 276 / 277 can be a self-propelled wheeled vehicle, such as an automobile, sport utility vehicle, truck, bus, van, or other motor or battery-driven or fuel cell-driven conveyance. For example, the conveyance 276 / 277 can be an electric vehicle, a hybrid vehicle, a hydrogen fuel cell vehicle, a plug-in hybrid vehicle, or any other type of vehicle having a fuel cell stack, motor, and / or generator. Other examples of vehicles include bicycles, scooters, trains, airplanes, boats, and any other form of conveyance capable of transportation. The conveyance 276 / 277 can be semi-autonomous or autonomous. For example, the conveyance 276 / 277 can be self-propelled and navigate without human input. An autonomous vehicle can have and use one or more sensors and / or navigation units to drive autonomously.

[0088] In one example, the solutions described and depicted herein can be used to determine access to a conveyance via blockchain consensus. In one example, the solution can also be used to perform profile verification before allowing an occupant to use the conveyance. In one example, the solution can also be used to cause the conveyance to indicate (visually, but in another example also verbally, etc.) to the user the actions that the user needs to perform (which can be pre-recorded) on or from the conveyance, and verify that it is the correct action. In one example, the solution can also be used to provide the conveyance with the ability to determine how to bifurcate data based on a risk level associated with the data and the driving environment, and distribute the portion of the bifurcated data with a lower risk level to the occupants during a safe driving environment, and later distribute the remaining portion of the bifurcated data with a higher risk level to the occupants after the occupants have left the conveyance. In one example, the solution can also be used to handle the transfer of a vehicle across a boundary (such as a country / state, etc.) by using blockchain and / or smart contracts, and apply the rules of the new region to the vehicle.

[0089] In one example, when a consensus is reached by the vehicle based on the vehicle's operations and the characteristics of the vehicle's occupants, the solution can also be used to allow the vehicle to continue operating outside the boundary. In one example, the solution can also be used to analyze the available data upload / download speed, file size, and the speed / direction in which the vehicle is traveling to determine the distance required to complete the data upload / download and allocate a secure area boundary for the data upload / download to be performed. In one example, the solution can also be used to perform normally hazardous maneuvers in a secure manner, such as when the system determines that an exit is approaching and when the vehicle does not appear to be prepared for the exit (e.g., traveling in the incorrect lane or at a speed not conducive to making the upcoming exit), and instruct the host vehicle and other nearby vehicles to allow the host vehicle to leave the exit in a secure manner. In one example, the solution can also be used to use one or more vehicles to verify the diagnostics of another vehicle when both the one or more vehicles and the other vehicle are in motion.

[0090] In one example, the solution can also be used to detect lane usage at a location and time of day to inform the vehicle's occupants or to guide the vehicle to recommend or not recommend a lane change. In one example, the solution can 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 for payment. In one example, the solution can also be used to provide services to the vehicle's occupants, where the services provided are subscription-based and where permission is obtained from other vehicles connected to the occupant's profile. In one example, the solution can also be used to record changes in the condition of the rented object. In one example, the solution can also be used to seek blockchain consensus from other vehicles near a damaged vehicle. In one example, the solution can also be used to receive media that may be related to an accident from a server such as an insurance entity server and from the 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 can also be used to obtain consensus to determine the severity of an event from several devices at different times prior to the event related to the vehicle.

[0091] In one example, the solution can also be used to solve problems in the absence of video evidence of an accident involving a vehicle. The current solution details querying media related to the accident from other vehicles that may have been near the accident by the vehicles involved in the accident. In one example, the solution can also be used to use the vehicle and other devices (e.g., a pedestrian's cellular phone, a streetlight camera, etc.) to record a specific part of the damaged vehicle.

[0092] In one example, the solution can also be used to warn occupants while the vehicle is navigating towards a hazardous area and / or event, thereby allowing the vehicle to notify the occupants or a central controller of potential hazardous areas on or near the current vehicle route. In one example, the solution can also be used to detect when a vehicle is traveling at a high rate and use at least one other vehicle to assist in slowing down the vehicle in a manner that minimally impacts traffic. In one example, the solution can also be used to identify a hazardous driving situation in which media is captured by the vehicle involved in the hazardous driving situation. A geofence is established based on the distance of the hazardous driving situation, and additional media is captured by at least one other vehicle within the established geofence. In one example, the solution can also be used to send a notification to one or more occupants of a vehicle that the vehicle is approaching a traffic control sign on the road, and then, if the vehicle crosses the sign, receive an indication of improper driving from other nearby vehicles. In one example, the solution can also be used to render the vehicle partially inoperable by (in some embodiments) restricting speed, restricting the ability to approach another vehicle, limiting speed to a maximum value, and only allowing a given number of miles per time period.

[0093] In one example, the solution can also be used to overcome the need for software updates to correct problems with a vehicle when the vehicle is not being operated correctly. By observing other vehicles on the route, the server will receive data from potentially multiple other vehicles that observe an unsafe or incorrect operation of the vehicle. Through analysis, these observations can result in a notification being sent to the vehicle when the data indicates an unsafe or incorrect operation. In one example, the solution can also be used to notify between a vehicle and a potential hazardous situation involving a person outside of the vehicle. In one example, the solution can also be used to send data from a device associated with an accident of a vehicle or a device near the accident to the server. Based on the severity of the accident or near-accident, the server notifies the sender of the data. In one example, the solution can also be used to provide recommendations for operating a vehicle to the driver or occupants of the vehicle based on data analysis. In one example, the solution can also be used to establish a geofence associated with a physical structure and determine liability for payment for the vehicle. In one example, the solution can also be used to coordinate the ability to disembark from a vehicle at a location using both the current state at the location of use and the proposed future state of the navigation destination of other vehicles. In one example, the solution can also be used to coordinate the ability to automatically schedule disembarkation from a vehicle at a location such as a vehicle rental entity.

[0094] In one example, the solution can also be used to move a vehicle to another location based on a 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 or modified event. In one example, the solution can also be used to allow verification of available locations within a region by existing vehicles within the region. The approximate time when a location might be vacated is also determined based on verification from existing vehicles. In one example, the solution can also be used to move a 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. Additionally, the vehicle is moved to a final parking space when the event is completed or based on the location of a device associated with at least one occupant of the vehicle. In one example, the solution can also be used to plan to park before an upcoming crowd. The system interacts with the vehicle to provide some services at a price lower than the full price and / or direct the vehicle to an alternative parking location based on the vehicle's priority, thereby increasing the optimization of the parking scenario before arrival.

[0095] In one example, the solution can also be used to sell partial ownership in a vehicle or determine pricing and availability in a ride-sharing application. In one example, the solution can also be used to provide accurate and timely reports that go far beyond current available dealer sales activities. In one example, the solution can also be used to allow a dealer to request an asset through a blockchain. By using a blockchain, consensus is obtained before any asset is moved. Additionally, the process is automated and payments can be initiated through the blockchain. In one example, the solution can 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 can also be used to associate digital keys with multiple users. The first user can be the vehicle operator while the second user is the party responsible for the vehicle. These keys are authorized by a server, where the proximity of the keys is verified against the location of the service provider. In one example, the solution can also be used to determine the services required at a vehicle destination. Locate one or more service locations that can provide the required services, which are both within a region on the route to the destination and have the availability to perform the service. Update the vehicle's navigation with the determined service locations. Identify a smart contract that contains the compensation value for the service, and the blockchain transaction is stored in the distributed ledger of the transaction.

[0096] In one example, the solution can also be used to interface a service provider vehicle with a profile of an occupant of the vehicle to determine services and goods that may be of interest to the occupant in the vehicle. These services and goods are determined by the occupant's history and / or preferences. The vehicle then receives offers from the service provider vehicle and, in another example, meets with the vehicle to provide the service / goods. In one example, the solution can also be used to detect vehicles within range and send service offers (such as maintenance offers, product offers, etc.) to the vehicles. An agreement is reached between the system and the vehicle, and the system selects a service provider to provide the agreement. In one example, the solution can 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 assist traffic flow. In one example, the solution can also be used to warn the driver of a vehicle through a device, where the device can be a traffic light or near an intersection. An alert is sent when an event occurs, such as when the light turns green and the vehicle in front of the vehicle list does not move.

[0097] Figure 2H Another block diagram 290 shows the interconnections between different elements in one example. Vehicle 276 is presented and includes ECUs 295, 296, and a host unit (also referred to as an infotainment system) 297. An electronic control unit (ECU) is an embedded system in automotive electronics that controls one or more of the electronic systems or subsystems in a vehicle. The ECU can include, but is not limited to, the management of the vehicle's engine, braking system, transmission system, door locks, dashboard, airbag system, infotainment system, electronic differential, and active suspension. The ECU is connected to the vehicle's controller area network (CAN) bus 294. The ECU can also communicate with the vehicle computer 298 via the CAN bus 294. The vehicle's processor / sensor (such as the vehicle computer) 298 can communicate with external elements (such as server 293) via network 292 (such as the Internet). Each ECU 295, 296, and host unit 297 can contain its own security policy. The security policy defines the allowable processes that can be executed in an appropriate context. In one example, the security policy can be provided partially or entirely in the vehicle computer 298.

[0098] The ECUs 295, 296, and the host unit 297 may each include a customized security function element 299 that defines authorized processes and the contexts in which these processes are permitted to run. Context-based authorization to determine the validity of whether a process can be executed allows the ECU to maintain secure operation and prevent unauthorized access from components such as a vehicle's Controller Area Network (CAN bus). When an ECU encounters an unauthorized process, the ECU may block the process from operating. Motor vehicle ECUs may use different contexts to determine whether a process is operating within its permitted scope, such as a proximity context (such as nearby objects, distance to an approaching object, speed, and trajectory relative to other moving objects), an operating context (such as an indication of whether the vehicle is moving or stopped, the vehicle's current speed, transmission state), a user-related context (such as a device connected to the vehicle via a wireless protocol, use of infotainment, cruise control, parking assistance, driving assistance), a location-based context, and / or other contexts.

[0099] In one example, the solutions described and depicted herein can be used to render a vehicle partially inoperable by (in some embodiments) restricting speed, restricting the ability to approach another vehicle, limiting speed to a maximum value, and only allowing a given number of miles per time period. In one example, the solutions can also be used to facilitate the exchange of vehicle ownership using a blockchain, where data is sent from a device associated with or near an accident of a vehicle to a server. Based on the severity of the accident or near-accident, the server notifies the sender of the data. In one example, the solutions can also be used to help a vehicle avoid an accident, such as when the vehicle is involved in an accident via a server that queries other vehicles near the accident. The server seeks to obtain data from other vehicles, thus allowing the server to understand the nature of the accident from multiple advantageous points. In one example, the solutions can also be used to determine that a sound from a vehicle is atypical and send data related to the sound and a possible source location to a server, where the server can determine a possible cause and avoid a potential dangerous situation. In one example, when a vehicle is involved in an accident, the solutions can also be used to establish a location boundary via the system. The boundary is based on the decibels associated with the accident. Multimedia content of devices within the boundary is obtained to assist in further understanding the accident scenario. In one example, the solutions can also be used to associate a vehicle with an accident and then capture media obtained by a device near the location of the accident. The captured media is saved as a media clip. The media clip is sent to another computing device that constructs a sound profile of the accident. The sound profile map will assist in understanding more details around the accident.

[0100] In one example, the solution can also be used to record audio, video, movement, etc. using sensors to record areas where potential events have occurred. For example, if a vehicle contacts or may contact another vehicle (while moving or parked), the system captures data from sensors that can reside on one or more of the vehicles and / or on stationary or moving objects. In one example, the solution can also be used to determine that a vehicle has been damaged by identifying a new condition of the vehicle during a vehicle event using sensor data and comparing that condition to a vehicle condition profile, enabling critical data to be captured safely and reliably from a vehicle about to participate in a harmful event.

[0101] In one example, when a vehicle has determined via one or more sensors that it is approaching or driving on a one-way road in an incorrect manner, the solution can also be used to warn the vehicle's occupants. The vehicle has sensors / cameras / maps that interact with the system of the current solution. The system knows the geographical location of one-way streets. The system can audibly notify the occupants, e.g., "Approaching one-way street". In one example, the solution can also be used to allow a vehicle to obtain payment, enabling the owner of an autonomous vehicle to monetize the data collected and stored by its vehicle sensors, creating an incentive for vehicle owners to share their data and provide additional data to entities to improve the performance of future vehicles, provide services to vehicle owners, etc.

[0102] In one example, the solution can also be used to increase or decrease a vehicle's features based on the vehicle's actions over a period of time. In one example, the solution can also be used to assign partial ownership to a vehicle. Sensor data related to one or more vehicles and devices in the vicinity of the vehicle is used to determine the condition of the vehicle. Based on that condition, partial ownership of the vehicle is determined and new vehicle responsibilities are provided. In one example, the solution can also be used to provide data to a replacement / upgrade (upfit) component, where the data attempts to subvert the authorized functionality of the replacement / upgrade component, and in response to non-subversion of the authorized functionality, the component is allowed to use the authorized functionality of the replacement / upgrade component.

[0103] In one example, the solution can also be used to provide an individual with the ability to ensure that an occupant is in a vehicle and to get that occupant to a specific destination. Additionally, the system ensures that the driver (if it is a non-autonomous vehicle) and / or other occupants are authorized to interact with the occupant. Additionally, pick-up, drop-off, and location are recorded. All of the above is stored immutably on a blockchain. In one example, the solution can also be used to determine a driver's characteristics via an analysis of driving style and other factors in order to take action if the driver is not driving in a normal manner, such as the way the driver has driven in a particular situation before, e.g., during the day, at night, in the rain, in the snow, etc. Additionally, the attributes of the vehicle are also considered. Attributes include weather, whether the headlights are on, whether navigation is being used, whether HUD is being used, the volume of the media being played, etc. In one example, the solution can also be used to notify an occupant in a vehicle of a dangerous situation when the items in the vehicle indicate that the occupant may be unaware of the dangerous situation.

[0104] In one example, the solution can also be used to install calibration equipment on a rig fixed to a vehicle, where various sensors on the vehicle can automatically self-adjust based on what the calibration equipment is supposed to detect compared to what is actually detected. In one example, when a vehicle in need of service sends a fault message that allows remote diagnostic capabilities, the solution can also be used to use the blockchain to request consensus from multiple service centers, where consensus is requested on what the severity threshold for the data is from other service centers. Once the consensus is received, the service center can send the fail-safe level to the blockchain for storage. In one example, the solution can also be used to determine the difference between sensor data external to the vehicle and the vehicle's own sensor data. The vehicle requests software from the server to correct the problem. In one example, the solution can also be used to allow vehicles in the vicinity or area to send messages when an event (e.g., a collision) occurs.

[0105] Reference Figure 2I , shows an operating environment 290A for connected vehicles according to some embodiments. As depicted, vehicle 276 includes a Controller Area Network (CAN) bus 291A that connects elements 292A - 299A of the vehicle. Other elements can be connected to the CAN bus and are not depicted herein. The depicted elements 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, vehicle 276 includes a processor 296A, a memory 297A, a communication unit 298A, and an electronic display 299A.

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

[0107] The memory 297A is a non-transitory memory that stores instructions or data that can be accessed and executed by the processor 296A. The instructions and / or data may include code for performing the techniques described herein. The memory 297A may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, a flash memory, or other memory devices. In some embodiments, the memory 297A may also include non-volatile memory or a similar permanent storage device and medium, which may include a hard disk 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 mass storage device for storing information on a permanent basis. A portion of the memory 297A may be reserved for use as a buffer or virtual random access memory (virtual RAM). Without departing from the current solution, the vehicle 276 may include one or more memories 297A.

[0108] 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 that may be required to provide functionality by the navigation application 295A.

[0109] The navigation system 295A may describe at least one navigation route that includes a starting point and an ending point. In some embodiments, the navigation system 295A of the vehicle 276 receives a request for a navigation route from a user, where the request includes a starting point and an ending point. The navigation system 295A may query (via the network 292) a real-time data server 293 (such as a server that provides driving directions) for navigation route data corresponding to the navigation route, including the starting point and the ending 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.

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

[0111] The sensor set 292A can include any sensors in the vehicle 276 that generate sensor data. For example, the sensor set 292A can include short-range sensors and long-range sensors. In some embodiments, the sensor set 292A of the vehicle 276 can include one or more of the following vehicle sensors: cameras, Lidar sensors, ultrasonic sensors, motor vehicle 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 detectors, 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 type of motor vehicle sensor. The navigation system 295A can store the sensor data in the memory 297A.

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

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

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

[0115] In one example, the solutions can also be used to analyze the availability of the occupants in each vehicle available for voice communication based on the amount of time remaining in the vehicle and the context of the communication to be performed. In one example, the solutions can also be used to determine two threat levels of a road obstacle, receive a gesture that can indicate that the obstacle has not risen above a threshold, and continue to move forward by the vehicles along the road. In one example, when the vehicle has been damaged such that it becomes inoperable, the solutions can also be used to delete sensitive data from the vehicle.

[0116] In one example, the solutions can also be used to verify that the customer data to be removed has been truly removed from all required locations within the enterprise, thus demonstrating GDPR compliance. In one example, the solutions can also be used to provide considerations from one vehicle to another to exchange data related to safety, important notifications, etc., to enhance the autonomous capabilities of lower-level autonomous vehicles. In one example, the solutions can also be used to provide the 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, where the second biometric is a continuum of the first biometric. When only the occupant can receive the unencrypted data, the vehicle provides the unencrypted data to the occupant, deletes the sensitive part when providing the sensitive part of the unencrypted data, and deletes the non-sensitive part after the time period associated with the biometric has passed. In one example, the solutions can also be used to provide the vehicle with the ability to verify an individual based on the weight and grip pressure applied to the vehicle's steering wheel. In one example, the solutions can also be used to provide features that are present but currently not enabled to the vehicle, thus presenting features to the occupants of the motor vehicle that reflect the characteristics of the occupants.

[0117] In one example, the solution can also be used to allow modification of a vehicle, particularly in one example, modifying the interior and exterior of the vehicle to reflect and assist at least one occupant. In another example, reconstructing the work and / or home environment of an occupant is disclosed. If the system determines that the user is in a "work mode" or "home mode", the system can attempt to "reconstruct" the user's work / home environment when the user is in a vehicle. All data related to the interior and exterior of the vehicle and the various occupants using the vehicle is stored on a blockchain and executed via a smart contract. In one example, the solution can also be used to detect an occupant's posture to assist in communicating with nearby vehicles, where the vehicles can maneuver accordingly. In one example, the solution can also be used to provide the vehicle with the ability to detect an expected posture using a posture definition database. In one example, the solution can also be used to provide the vehicle with the ability to take various actions based on the gait and the posture of the user. In one example, the solution can also be used to ensure that the driver of a vehicle currently engaged in various operations (such as driving while on a call with navigation, etc.) does not exceed an unsafe number of operations before being allowed to make gestures.

[0118] In one example, the solution can also be used to assign a status to each occupant in a vehicle and verify the posture from the occupant based on the occupant's status. In one example, the solution can also be used to collect details of sounds related to a collision (at what location, in what direction, rising or falling, from what device, data associated with the device (such as type, manufacturer, owner), and the number of sounds occurring simultaneously, and the time when the sound is emitted, etc.) and provide them to the system, where the analysis of the data assists in determining details about the collision. In one example, the solution can also be used to determine whether a vehicle is unsafe to operate. The vehicle includes multiple components that interoperate 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's functionality. In response to receiving the confidential key, the vehicle disables one or more component keys. Disabling one or more component keys results in one or more of the following: restricting the vehicle's movement to not greater than a given speed, restricting the vehicle to not be closer to another vehicle than a certain distance, and restricting the vehicle to travel not greater than a threshold distance.

[0119] In one example, the solution can also be used to provide an indication from one specific vehicle (which is about to vacate a position) to another specific vehicle (which is seeking to occupy the position), using a blockchain to perform authentication and coordination. In one example, the solution can also be used to determine the partial liability of a vehicle. Such as in the case where multiple people own a single vehicle, and the system uses the usage of the vehicle, which may vary over a period of time, to update the partial ownership. Other embodiments will be included in this application, including the minimum ownership of a vehicle based on the availability of the vehicle rather than its usage, and determining the driver of the vehicle and others.

[0120] In one example, the solution can also be used to allow a user to use his / her subscription in a vehicle with a closed group of people, such as family members or friends. For example, a user may want to share a membership, and if so, the associated transaction is stored in a blockchain or a traditional database. When the subscribed material is requested by a user who is not the primary subscriber, the blockchain node (i.e., the vehicle) can verify that the person requesting the service is an authorized person with whom the subscriber has shared the profile. In one example, the solution can also be used to allow a person to utilize a supplementary vehicle to reach the intended destination. A functional relationship value (e.g., a value indicating various parameters and their importance in determining what type of alternative vehicle to utilize) is used in determining the supplementary vehicle. In one example, the solution can also be used to allow the occupants in an accident to enter other vehicles to continue on to their initial destination.

[0121] In one example, the solution can also be used to upload and propagate software / firmware to a first subgroup of vehicles. This first group of vehicles tests the update, and when the test is successful, propagates the update to another group of vehicles. In one example, the solution can also be used to propagate software / firmware updates from a master vehicle to vehicles, where the updates are propagated through the vehicle network from a first subgroup, then from a larger subgroup, etc. A part of the update can be sent first, and then the remaining part can be sent from the same vehicle or another vehicle. In one example, the solution can also be used to provide updates for the computers of vehicles to the vehicles and the devices of the vehicle operators / occupants. The update can be authorized by all drivers and / or all occupants. Provide the software update to the vehicle and the device. The user doesn't have to do anything but walk near the vehicle, and the function occurs automatically. Send a notification indicating that the software update is complete to the device. In one example, the solution can also be used to verify that an OTA software update is performed by a qualified technician, and one or more vehicle components generate a status related to the originator of the verification code, the process for wirelessly receiving the software update, the information included in the software update, and the result of the verification.

[0122] In one example, the solution can also be used to provide the second component with the ability to parse software updates located in the first component. Then, the first part of the critical update and the second part of the non-critical update are verified, the verified first part is assigned to a process in the vehicle, this one process is used to run the verified first part for a period of time, and in response to a positive result based on this period of time, other processes are used to run the verified first part after this period of time. In one example, the solution can also be used to provide the occupants with a choice of services, where the services are based on the profile of the vehicle occupants and a shared profile shared with the occupants' profiles. In one example, the solution can also be used to store user profile data in a blockchain and intelligently present offers and recommendations to the user based on the automatically collected history of the user's purchases and preferences obtained from the user profile on the blockchain.

[0123] For a vehicle to be fully secure, it must be protected from unauthorized physical access as well as unauthorized remote access (e.g., cyber threats). To prevent unauthorized physical access, in one example, 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 communication to and from the vehicle.

[0124] An electronic control unit (ECU) is a node within a vehicle that controls tasks ranging from something like activating windshield wipers to something like an anti-lock braking system. ECUs are typically connected to each other via the vehicle's central network, which can be referred to as a controller area network (CAN). State-of-the-art features such as autonomous driving strongly rely on implementing new, complex ECUs, such as advanced driver assistance systems (ADAS), sensors, etc. Although these new technologies have helped improve vehicle safety and the driving experience, they have also increased the number of external communication units within the vehicle, making them more vulnerable to attacks. The following are some examples of protecting vehicles from physical and remote intrusions.

[0125] Figure 2J A keyless entry system 290B for preventing unauthorized physical access to a vehicle 291B is shown in accordance with an example embodiment. Refer to Figure 2J, in one example, a key fob 292B uses a radio frequency signal to send commands to a vehicle 291B. In this example, the key fob 292B includes a transmitter 2921B having an antenna capable of sending short-range radio signals. The vehicle 291B includes a receiver 2911B having an antenna capable of receiving the short-range radio signals transmitted from the transmitter 2921B. The key fob 292B and the vehicle 291B also respectively include CPUs 2922B and 2913B for controlling the respective devices. Here, the memories of the CPUs 2922B and 2913B (or memories accessible by the CPUs). In one example, each of the key fob 292B and the vehicle 291B includes a power supply 2924B and 2915B for powering the respective devices.

[0126] When the user presses a button 293B on the key fob 292B (or otherwise activates the key fob, etc.), the CPU 2922B wakes up within the key fob 292B and sends a data stream to the transmitter 2921B, which is output via the antenna. In other embodiments, the user's intent is confirmed on the key fob 292B via other means, such as a microphone for receiving audio, a camera for capturing images and / or video, or other sensors commonly used in the art for detecting the intent from the user, including receiving gestures, motion, eye movement, etc. The data stream can be a signal that is 64 bits to 128 bits long and 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 embodiments are not limited thereto. In response, the receiver 2911B of the vehicle 291B captures the signal from the transmitter 2921B, demodulates the signal, and sends the data stream to the CPU 2913B, which decodes the signal and sends a command (e.g., lock the door, open the door, etc.) to the command module 2912B.

[0127] If the key fob 292B and the vehicle 291B use a fixed code between them, a replay attack can be performed. In this case, if an attacker can capture / sniff the fixed code during short-range communication, the attacker can replay the code to gain entry into 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 an initial seed 2923B (e.g., a random number, a pseudo-random number, etc.). This is called pairing. The key fob 292B and the vehicle 291B also include a shared algorithm for modifying the initial seed 2914B each time the button 293B is pressed. Subsequent button presses will take the result of the previous button press as input and transform it into the next number in the sequence. In some cases, the vehicle 291B can store multiple next codes (e.g., 255 next codes) in the event that the vehicle 291B does not detect button presses on the key fob 292B. Thus, multiple button presses on the key fob 292B that are not heard by the vehicle 291B will not prevent the vehicle from becoming desynchronized.

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

[0129] Figure 2K A controller area network (CAN) 290C within a vehicle according to an example embodiment is shown. Referring Figure 2K , the CAN 290C includes a CAN bus 297C having a high end and a low end, and a plurality of electronic control units (ECUs) 291C, 292C, 293C, etc., which are 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), which allows the ECUs 291C - 293C to send commands to each other at the root level. At the same time, the ECUs 291C - 293C represent controllers for controlling electrical systems or subsystems within the vehicle. Examples of electrical systems include power steering, anti-lock braking, air conditioning, tire pressure monitoring, cruise control, and many other features.

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

[0131] To protect the CAN 290C from network threats, various security protocols can be implemented. For example, sub-networks (such as sub-networks A and B, etc.) can be used to divide the CAN 290C into smaller sub-CANs and limit the ability of an attacker to access the vehicle remotely. In Figure 2K the example, the ECUs 291C and 292C can be part of the same sub-network, while the ECU 293C is part of a separate sub-network. In addition, a firewall 294C (or gateway, etc.) can be added to prevent messages from crossing the CAN bus 297C across sub-networks. If an attacker gains access to one sub-network, the attacker will not be able to access the entire network. To make the sub-networks even more secure, in one example, the most critical ECUs are not placed on the same sub-network.

[0132] Although Figure 2K not shown in, other examples of security control within the CAN include intrusion detection systems (IDSs), which can be added to each sub-network and read all the data passing through to detect malicious messages. If a malicious message is detected, the IDS can notify the vehicle user. Other possible security protocols include encryption / security keys that can be used to obscure messages. As another example, in one example, an authentication protocol is implemented that enables messages to authenticate themselves.

[0133] In addition to protecting the internal network of the vehicle, the vehicle can also be protected when communicating with an external network such as the Internet. One of the benefits of 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, on-board diagnostics, tire pressure, etc. These communication systems are generally referred to as telematics because they involve a combination of telecommunications and informatics. In addition, as described and depicted with respect to Figure 2K the present solution can be used in this and other networks and / or systems, including those described and depicted herein.

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

[0135] The secure management of data starts from the vehicle 291D. In some embodiments, the device 296D may collect information before, during, and after a trip. The data may include GPS data, travel data, passenger information, diagnostic data, fuel data, speed data, etc. However, the device 296D may transmit the collected information back to the host server 295D only in response to vehicle ignition and trip completion. Additionally, the communication may be initiated only by the device 296D, rather than by the host server 295D. Thus, in one example, the device 296D will not accept communication initiated by an external source.

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

[0137] 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 over wireless networks, communicate with roadside infrastructure (e.g., traffic lights, signs, cameras, parking meters, etc.), and so on. The wireless network can include one or more of a Wi-Fi network, a cellular network, a dedicated short-range communication (DSRC) network, and the like. Vehicles can use V2V communication to provide other vehicles with information about the vehicle's speed, acceleration, braking, and direction, to name just a few. Thus, a vehicle can receive insights into such conditions before they become visible ahead, thereby greatly reducing collisions. Additionally, as described and depicted with respect to Figure 2L the present solution can be used in this and other networks and / or systems, including those described and depicted herein.

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

[0139] When receiving communications from each other, vehicles can verify the signatures with a certificate authority such as 291E. For example, vehicle 292E can verify with certificate authority 291E that the public key certificate 294E used by vehicle 293E to sign the V2V communication is authentic. If vehicle 292E successfully verifies public key certificate 294E, the vehicle knows that the data is from a legitimate source. Similarly, vehicle 293E can verify with certificate authority 291E that the public key certificate 295E used by vehicle 292E to sign the V2V communication is authentic. Additionally, as described and depicted with respect to Figure 2M the present solution can be used in this and other networks and / or systems, including those described and depicted herein.

[0140] Figure 2N Another diagram 290F shows an example of a vehicle depicting the interaction of a security processor and a wireless device according to an example embodiment. In some embodiments, Figure 2BThe computer 224 shown in Figure 2N may include a security processor 292F, as shown in the example process 290F of

[0141] In Figure 2N the example, 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, such as an ECU / CAN network 296F, wired and wireless devices 298F such as a wireless network interface, input ports, etc. The security processor 292F may ensure that data frames (e.g., CAN frames, etc.) transmitted internally 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 attached or connected to the vehicle's computer via a wire are also secure.

[0142] For example, the authorization module 293F may store passwords, usernames, PIN codes, biometric scans, etc. of different vehicle users. The authorization module 293F may determine whether a user (or technician) has permission to access certain settings such as the vehicle's computer. In some embodiments, the authorization module may communicate with a network interface to download any required authorization information from an external server. When a user wishes to change the vehicle's settings or modify the technical details of the vehicle via a console or GUI within the vehicle or via an attached / connected device, the authorization module 293F may require the user to authenticate themselves in some way before changing such settings. For example, the authorization module 293F may request a username, password, PIN code, biometric scan, a predefined line drawing or gesture, etc. In response, the authorization module 293F may determine whether the user has the requested required permission (access, etc.).

[0143] The authentication module 294F can be used to authenticate internal communication between ECUs on the vehicle's CAN network. As an example, the authentication module 294F can provide information for authenticating communication between ECUs. As an example, the authentication module 294F can send a bit signature algorithm to the ECUs of the CAN network. The ECU can use the bit signature algorithm to insert authentication bits into the CAN field of the CAN frame. All ECUs on the CAN network typically receive each CAN frame. Whenever one of the ECUs generates a new CAN frame, the bit signature algorithm can dynamically change the position, quantity, etc. of the authentication bits. The authentication module 294F can also provide a list of exempt ECUs (security list), and these ECUs do not need to use authentication bits. The authentication module 294F can communicate with a remote server to retrieve updates to the bit signature algorithm, etc.

[0144] The encryption module 295F can store an asymmetric key pair to be used by the vehicle for communication with other external user devices and vehicles. For example, the encryption module 295F can provide a private key to be used by the vehicle for encrypting / decrypting communication, while the corresponding public key can be provided to other user devices and vehicles so that other devices can decrypt / encrypt the communication. The encryption module 295F can communicate with a remote server to receive new keys, updates to keys, 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.

[0145] Figure 3A A flowchart 300 according to an example embodiment is shown. Refer to Figure 3A , the process includes one or more of the following: when a pairing request is initiated, the vehicle starts a timer 302; the vehicle receives a first response to the pairing request from a first device and a second response 304 to the pairing request from a second device; when each of the first response and the second response is received, the timer is recorded 306; a first connection time for the first device is determined from the recorded timer, and a second connection time for the second device is determined from the recorded timer 308; and the vehicle connects to the device with the fastest connection time among the first device and the second device 310.

[0146] Figure 3B Another flowchart 320 according to an example embodiment is shown. Refer to Figure 3B, the process includes one or more of the following: determining a first location of a first device using a first radio frequency signal received from the first device; determining a second location of a second device using a second radio frequency signal received from the second device; applying a prioritization scheme to identify a highest priority location among the first location and the second location; and using the highest priority location to perform connection 322; sensing a first temperature at the first device; sensing a second temperature within the vehicle; determining a difference between the first temperature and the second temperature; and performing connection 323 in response to the determined difference not exceeding a threshold; determining a location of the vehicle; determining an authentication level required for the connection based on the determined location; and performing connection 324 in response to the required authentication level being provided; sensing a first plurality of movements of a first person associated with the first device; analyzing the first plurality of movements to identify at least one pattern among the first plurality of movements; sensing a second plurality of movements of a subsequent person; when the second plurality of movements match the identified at least one pattern, determining that the subsequent person is the first person and performing the connection; and when the second plurality of movements do not match the identified at least one pattern, requiring authentication before performing the connection 325; receiving a first Bluetooth signal having a first radio frequency emission characteristic from the first device; receiving a second Bluetooth signal having a second radio frequency emission characteristic from the second device; comparing the first radio frequency emission characteristic with the second emission characteristic; performing the connection in response to the first radio frequency emission characteristic matching the second radio frequency emission characteristic; and requiring authentication before performing the connection in response to the first radio frequency emission characteristic not matching the second radio frequency emission characteristic 326; in response to receiving a plurality of pairing requests from the first device by the vehicle, determining a plurality of locations of the first device; identifying a location pattern from the plurality of locations; receiving a subsequent pairing request of the vehicle; determining an origin location of the subsequent pairing request; comparing the origin location with the location pattern; performing the connection when the origin location is within the location pattern; and requiring authentication before performing the connection when the origin location is not within the location pattern 327.

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

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

[0149] 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 datasets. 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.

[0150] The vehicle 402 sends data from one or more sensors 404 to the machine learning subsystem 406. The machine learning subsystem 406 provides the one or more sensors 404 data to the 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.

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

[0152] Figure 5A An example vehicle configuration 500 for managing database transactions associated with a vehicle according to an example embodiment is shown. Referring Figure 5A When a particular vehicle 525 participates in a transaction (e.g., vehicle service, dealership transaction, delivery / pickup, transportation service, etc.), the vehicle may receive assets 510 and / or expel / transfer assets 512 according to 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, contingencies, etc. Those transactions in the transaction module 520 may be copied to the database 530. The database 530 may be one of an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, and may be on the vehicle, outside the vehicle, directly accessible and / or accessible via a network, or accessible by the vehicle.

[0153] Figure 5BFIG. 550 shows an example vehicle configuration for managing database transactions conducted between various vehicles. When a vehicle has reached a state where it needs to share services with another vehicle, vehicle 525 may engage with another vehicle 508 to perform various actions such as sharing, transferring, obtaining service calls, etc. For example, vehicle 508 may need battery charging and / or may have a tire problem, and may be in a route to pick up a package for delivery. A vehicle processor 528 resides in vehicle 508, and there is communication between the vehicle processor 528, database 554, and transaction module 552. Vehicle 508 may notify another vehicle 525 that is within its network and operates on its blockchain member service. A vehicle processor 526 resides in vehicle 525, and there is communication between the vehicle processor 526, database 530, vehicle processor 526, and transaction module 520. Vehicle 525 may then request to receive information from vehicle 508 and / or from a server (not shown) via wireless communication to perform a package pickup. Transactions are recorded in the transaction modules 552 and 520 of both vehicles. Credits are transferred from vehicle 508 to vehicle 525, and records of the transferred services are recorded in database 530 / 554 assuming the blockchains are different from each other, or are recorded in the same blockchain used by all members. Database 554 can be one of an SQL database, RDBMS, relational database, non-relational database, blockchain, distributed ledger, and can be on the vehicle, outside the vehicle, directly accessible and / or accessible via a network.

[0154] Figure 6A FIG. 600 shows a blockchain architecture configuration according to an example embodiment. Referring Figure 6A , the blockchain architecture 600 may include certain blockchain elements, e.g., a set of blockchain member nodes 602 - 606 as part of a blockchain group 610. In one example embodiment, a permissioned blockchain is not accessible to all parties, but only to those members who are permitted to access the blockchain data. Blockchain nodes participate in multiple activities such as blockchain entry addition and verification processes (consensus). One or more blockchain nodes may endorse entries based on an endorsement policy and may provide an ordering service for all blockchain nodes. Blockchain nodes may initiate blockchain actions (such as authentication) and seek to write to a blockchain immutable ledger stored in the blockchain, copies of which may also be stored on underlying physical infrastructure.

[0155] When a blockchain transaction 620 is received and approved by a consensus model specified by the nodes of the members, it is stored in the memory of a computer. The approved transaction 626 is stored in the current block of the blockchain and is committed to the blockchain via a commit process that includes performing a hash of the data content of the transactions in the current block and referencing the previous hash of the previous block. Within the blockchain, there can be one or more smart contracts 630 that define the terms of the transaction protocols and actions included in the smart contract executable application code 632, such as the registered recipients, vehicle characteristics, requirements, permissions, sensor thresholds, etc. The code can be configured to identify whether the requesting entity is registered to receive vehicle services, what service characteristics they are authorized / required to receive given their profile status, and whether to monitor their actions in subsequent events. For example, when a service event occurs and the user is riding in the vehicle, sensor data monitoring can be triggered, and a specific parameter such as the vehicle charge level can be identified as being above / below a specific threshold over a specific period of time, and then the result can be a change to the current state that requires an alert to be sent to the management party (i.e., the vehicle owner, vehicle operator, server, etc.), so that the service can be identified and stored for reference. The collected vehicle sensor data can be based on the type of sensor data used to collect information about the vehicle state. The sensor data can also be the basis for vehicle event data 634, such as the location to be traveled, average speed, maximum speed, acceleration rate, whether there has been any collision, whether the expected route has been taken, what the next destination is, whether safety measures are in place, whether the vehicle has sufficient charge / fuel, etc. All such information can be the basis for the smart contract terms 630, which are then stored in the blockchain. For example, the sensor thresholds stored in the smart contract can be used as the basis for whether the detected service is needed and when and where the service should be performed.

[0156] Figure 6B illustrates a shared ledger configuration according to an example embodiment. Refer to Figure 6B , the blockchain logic example 640 includes a blockchain application interface 642 as an API or plug-in application that links to the computing device and execution platform for a specific transaction. The blockchain configuration 640 can include one or more applications that link to an application programming interface (API) to access and execute the 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 via attachment to the distributed ledger.

[0157] The smart contract application code 644 provides a basis for blockchain transactions by establishing application code that, when executed, makes the terms and conditions of the transaction effective. The smart contract 630, when executed, causes 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 656 that manages the execution of transactions, and a storage portion 654 that serves as a memory for storing transactions and smart contracts in the blockchain.

[0158] The blockchain platform can include various layers of blockchain data, services (such as cryptographic trust services, virtual execution environments, etc.), and underlying physical computer infrastructure that can be used to receive and store new entries and provide access to auditors seeking to access data entries. The blockchain can expose interfaces that provide access to the handler code and the virtual execution environments required for the participating physical infrastructure. Cryptographic trust services can be used to verify entries such as asset exchange entries and maintain information privacy.

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

[0160] Within the smart contract executable code, the smart contract can be created via high-level applications and programming languages and then written to a block in the blockchain. The smart contract can include executable code that is registered, stored, and / or replicated using the blockchain (such as a distributed network of blockchain peers). An entry is the execution of the smart contract code, which can be executed in response to conditions associated with the smart contract being met. The execution of the smart contract can trigger a trusted modification of the state of the digital blockchain ledger. The modification to the blockchain ledger caused by the execution of the smart contract can be automatically replicated across the distributed network of blockchain peers through one or more consensus protocols.

[0161] Smart contracts can write data to the blockchain in the format of key-value pairs. In addition, smart contract code can read the values stored in the blockchain and use them in application operations. Smart contract code can write the outputs of various logical operations to the blockchain. The code can be used to create temporary data structures in a virtual machine or other computing platforms. The data written to the blockchain can be public and / or can be encrypted and maintained privately. The temporary data used / generated by the smart contract is held in memory by the provided execution environment and then deleted once the data required by the blockchain is identified.

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

[0163] Figure 6C A blockchain configuration for storing blockchain transaction data according to an example embodiment is shown. Refer to Figure 6C , example configuration 660 provides for a vehicle 662, a user device 664, and a server 666 to share information with a distributed ledger (i.e., blockchain) 668. The server can represent a service provider entity that, in the case of a known and established user profile attempting to lease a vehicle with an established rating profile, asks the vehicle service provider to share user profile rating information. The server 666 can receive and process data related to the service requirements of the vehicle. When a service event occurs, such as vehicle sensor data indicating a need for fuel / charging, maintenance service, etc., a smart contract can be used to invoke rules, thresholds, sensor information collection, etc., which can be used to invoke vehicle service events. Blockchain transaction data 670, such as access events, subsequent updates to the vehicle service status, event updates, etc., is saved for each transaction. A transaction can include parties, requirements (e.g., 18 years old, eligible candidate for service, valid driver's license, etc.), compensation levels, distance traveled during the event, registered recipients who are allowed access to the event and host the vehicle service, permissions / licenses, sensor data retrieved during vehicle event operations 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 complete and whether the condition status of the vehicle has changed.

[0164] Figure 6D Shows the content of the blockchain block 680 and block structures 682A to 682n that can be added to a distributed ledger according to an example embodiment. Referring Figure 6D , a client (not shown) can submit entries to a blockchain node to enact activities on the blockchain. As an example, the client can be an application that acts on behalf of a requester (such as a device, person, or entity) to propose entries for the blockchain. Multiple blockchain peers (e.g., blockchain nodes) can maintain the state of the blockchain network and a copy of the distributed ledger. Different types of blockchain nodes / peers can exist in the blockchain network, including: endorsing peers, which simulate and endorse the entries proposed by the client; and committing peers, which verify the endorsements, validate the entries, and commit the entries to the distributed ledger. In this example, a blockchain node can perform the role of an endorser node, a committer node, or both.

[0165] The system includes a blockchain that stores immutable ordered records in blocks, and a state database (current world state) that maintains the current state of the blockchain. There can be one distributed ledger per channel, and each peer maintains its own copy of the distributed ledger for each channel of which they are a member. This blockchain is an entry log that is constructed as hash-linked blocks, where each block contains a sequence of N entries. A block can include various components such as Figure 6D those components shown in. The link of a block can be generated by adding the hash of the previous block header inside the block header of the current block. In this way, all entries on the blockchain are sorted and cryptographically linked together, thus preventing the tampering of blockchain data without breaking the hash link. Additionally, due to the link, the latest block in the blockchain represents every entry that came before it. This blockchain can be stored on a peer file system (local or attached storage) that supports an append-only blockchain workload.

[0166] The current state of the blockchain and the distributed ledger can be stored in the state database. Here, the current state data represents the latest values of all keys that have ever been included in the chain entry log of the blockchain. Smart contract executable code calls to execute entries against the current state in the state database. To make the interaction of these smart contract executable codes extremely efficient, the latest values of all keys are stored in the state database. The state database can include an indexed view into the entry log of the blockchain, and thus can be regenerated from the chain at any time. Before an entry is accepted, the state database can be automatically restored (or automatically generated if needed) when the peer starts up.

[0167] Endorsing nodes receive an entry from a client and endorse the entry based on simulation results. The endorsing nodes maintain the smart contract that simulates the input proposal. When an endorsing node endorses an entry, the endorsing node creates an entry endorsement, which is a signed response from the endorsing node to the client application indicating the endorsement of the simulated entry. The method of endorsing an entry depends on the endorsement policy that can be specified within the smart contract executable code. An example of an endorsement policy is "a majority of the endorsing peers must endorse the entry". Different channels can have different endorsement policies. The endorsed entry is forwarded by the client application to the ordering service.

[0168] The ordering service accepts the endorsed entries, sorts them into blocks, and delivers the blocks to the committing peers. For example, the ordering service can initiate a new block when a threshold of entries is reached, a timer times out, or another condition occurs. In this example, the blockchain node is the committing peer that has received the data block 682A for storage on the blockchain. The ordering service can consist of a cluster of orderers. The ordering service does not process entries, smart contracts, or maintain a shared ledger. Instead, the ordering service can accept the endorsed entries and specify the order in which those entries are committed to the distributed ledger. The architecture of the blockchain network can be designed such that a particular implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

[0169] Entries are written to the distributed ledger in a consistent order. The order of the entries is established to ensure that they are valid when updates to the state database are committed to the network. Different from cryptocurrency blockchain systems (e.g., Bitcoin, etc.) that sort by solving cryptographic puzzles or mining, in this example, the parties of the distributed ledger can choose the sorting mechanism that best suits the network.

[0170] Reference Figure 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 to 684n, transaction-specific data 686A to 686n, and block metadata 688A to 688n. It should be understood that the various illustrated blocks 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 block header 684A and block metadata 688A may be smaller than the transaction-specific data 686A that stores entry data; however, this is not a requirement. Block 682A may store transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) within block data 690A to 690n. Block 682A may also include a link to a previous block (e.g., on the blockchain) within block header 684A. In particular, block header 684A may include the hash of the previous block header. Block header 684A may also include a unique block number, the hash of block data 690A of the current block 682A, etc. The block number of block 682A may be unique and is assigned in an incrementing / sequential order starting from zero. The first block in the blockchain may be referred to as the genesis block, which includes information about the blockchain, its members, the data stored therein, etc.

[0171] 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: 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, Merkel tree query digest, etc. Entry data may be stored for each of the N entries.

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

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

[0174] The above embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in any combination of the foregoing. The computer program may be embodied on a computer-readable medium, such as a storage medium. For example, the computer program may reside in a random access memory (“RAM”), flash memory, read-only memory (“ROM”), erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), registers, 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.

[0175] The exemplary storage medium may be coupled to the 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 into 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 7FIG. 700 shows an example computer system architecture, which may be represented or integrated in any of the above components and the like.

[0176] Figure 7 It is not intended to impose any limitation on the scope of use or functions of the embodiments of the applications described herein. In any case, the computing node 700 is capable of implementing and / or executing any of the functions set forth above.

[0177] In the computing node 700, there is a computer system / server 702, which can operate with many other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with the computer system / server 702 include, but are not limited to, personal computer systems, server computer systems, thin clients, fat 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.

[0178] The 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, data structures, etc. that perform specific tasks or implement specific abstract data types. The computer system / server 702 may be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication 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.

[0179] As Figure 7 shown, the computer system / server 702 in the cloud computing node 700 is shown in the form of a general-purpose computing device. The 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.

[0180] The bus represents one or more of any 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 various bus architectures. By way of example and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

[0181] The computer system / server 702 generally includes various computer system-readable media. Such media can be any available media accessible by the computer system / server 702, and it includes volatile and non-volatile media, removable and non-removable media. In one example, the system memory 706 implements the flowcharts of the other figures. The system memory 706 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 708 and / or cache memory 710. The computer system / server 702 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the memory 706 may be provided for reading from and writing to an immovable, non-volatile magnetic medium (not shown and typically referred to as a "hard disk drive"). Although not shown, a disk drive may be provided for reading from and writing to a removable, non-volatile disk (e.g., a "floppy disk"), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk (such as a CD-ROM, DVD-ROM, or other optical media, etc.). In such cases, each can be connected to the bus through one or more data media interfaces. As will be further depicted and described below, the memory 706 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the various embodiments of the present application.

[0182] By way of example and not limitation, a program / utility having a set (at least one) of program modules, as well as an operating system, one or more application programs, other program modules, and program data may be stored in the 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 networked environment. The program modules generally execute the functions and / or methods of the various embodiments of the applications described herein.

[0183] As will be understood by those skilled in the art, aspects of the present application may be implemented as a system, method, or computer program product. Accordingly, aspects of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software aspects and hardware aspects, which may all be collectively referred to herein as "circuitry", "module", or "system". Additionally, 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 code thereon.

[0184] The computer system / server 702 can also communicate with one or more external devices via the following: I / O devices 712 (such as I / O adapters), which can include keyboards, pointing devices, displays, speech recognition modules, etc.; one or more devices that enable users to interact with the computer system / server 702; and / or any device that enables the computer system / server 702 to communicate with one or more other computing devices (e.g., network cards, modems, etc.). Such communication can be carried out via the I / O interface of device 712. In addition, the computer system / server 702 can communicate with one or more networks via a network adapter, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet). As shown in the figure, 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 can 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 archival storage systems, etc.

[0185] Although exemplary embodiments of at least one of a system, a method, and a non-transitory computer-readable medium are shown in the drawings and described in the foregoing detailed description, it will be understood that the present application is not limited to the disclosed embodiments, but is capable of numerous rearrangements, modifications, and substitutions as set forth and defined by the following claims. For example, the capabilities of the systems of the various figures can be performed by one or more of the modules or components described herein or in a distributed architecture, and can include pairs of transmitters, receivers, or both. For example, all or part of the functions performed by the various modules can be performed by one or more of these modules. In addition, the functions described herein can be performed at various times and can be associated with various events internal or external to the modules or components. Moreover, the information sent between the various modules can be sent between the modules via at least one of the following: data networks, the Internet, voice networks, Internet protocol networks, wireless devices, wired devices, and / or via multiple protocols. Also, the messages sent or received by any module can be sent or received directly and / or via one or more other modules.

[0186] Those skilled in the art will understand that a "system" can be implemented as a personal computer, a server, a console, a personal digital assistant (PDA), a cellular phone, a tablet computing device, a smart phone, or any other suitable computing device, or a 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 an example of many embodiments. In fact, the methods, systems, and devices disclosed herein can be implemented in localized and distributed forms consistent with computing technologies.

[0187] It should be noted that some of the system features described in this specification have been presented as modules to more particularly emphasize their implementation independence. For example, a module can be implemented as a hardware circuit, including custom very large scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors (such as logic chips, transistors, or other discrete components). A module can also be implemented with programmable hardware devices, such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc.

[0188] A module can also be implemented at least in part with software executed by various types of processors. The identified units of executable code, for example, can include one or more physical or logical blocks of computer instructions, which can be organized, for example, as objects, procedures, or functions. However, the executable code of the identified module does not need to be physically located together, but can include different instructions stored in different locations, which, when logically combined, include the module and implement the stated purpose of the module. In addition, a module can be stored on a computer-readable medium, which can be, for example, a hard disk drive, a flash device, random access memory (RAM), a magnetic tape, or any other such medium for storing data.

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

[0190] It will be readily understood that, as generally described and shown in the figures herein, the components of the present application can be arranged and designed in a variety of different configurations. Thus, the detailed description of the embodiments is not intended to limit the scope of the claimed present application, but merely represents selected embodiments of the present application.

[0191] Those of ordinary skill in the art will readily understand that the above can be practiced using different orders of steps and / or using hardware elements in configurations different from the disclosed configurations. Thus, although the present application has been described based on these preferred embodiments, certain modifications, variations, and alternative constructions will be apparent to those skilled in the art.

[0192] Although the preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely illustrative, and when considering equivalents and modifications in their full scope (e.g., protocols, hardware devices, software platforms, etc.), the scope of the present application is defined only by the appended claims.

Claims

1. A method, comprising: when a pairing request is initiated, starting a timer by a vehicle; receiving, by the vehicle, a first response to the pairing request from a first device and a second response to the pairing request from a second device; when each of the first response and the second response is received, recording the timer; determining, from the recorded timer, a first connection time for the first device and determining, from the recorded timer, a second connection time for the second device; and connecting, by the vehicle, to the device among the first device and the second device having the fastest connection time.

2. The method according to claim 1, comprising: using a first radio frequency signal received from the first device to determine a first position of the first device; using a second radio frequency signal received from the second device to determine a second position of the second device; applying a prioritization scheme to identify a highest priority position among the first position and the second position; and using the highest priority position to perform the connection.

3. The method according to claim 1, comprising: sensing a first temperature at the first device; sensing a second temperature inside the vehicle; determining a difference between the first temperature and the second temperature; and performing the connection in response to the determined difference not exceeding a threshold.

4. The method according to claim 1, comprising: determining a position of the vehicle; determining an authentication level required for the connection based on the determined position; and performing the connection in response to the required authentication level being provided.

5. The method according to claim 1, comprising: sensing a first plurality of movements of a first person associated with the first device; analyzing the first plurality of movements to identify at least one pattern among the first plurality of movements; sensing a second plurality of movements of a subsequent person; when the second plurality of movements match the at least one identified pattern, determining that the subsequent person is the first person and performing the connection; and when the second plurality of movements do not match the at least one identified pattern, requiring authentication before performing the connection.

6. The method according to claim 1, comprising: receiving a first Bluetooth signal having a first radio frequency emission characteristic from the first device; receiving a second Bluetooth signal having a second radio frequency emission characteristic from the second device; comparing the first radio frequency emission characteristic with the second emission characteristic; performing the connection in response to the first radio frequency emission characteristic matching the second radio frequency emission characteristic; and requiring authentication before performing the connection in response to the first radio frequency emission characteristic not matching the second radio frequency emission characteristic.

7. The method according to claim 1, comprising: in response to receiving a plurality of pairing requests from the first device by the vehicle, determining a plurality of positions of the first device; identifying a position pattern from the plurality of positions; receiving a subsequent pairing request of the vehicle; determining an origin position of the subsequent pairing request; comparing the origin position with the position pattern; performing the connection when the origin position is within the position pattern; and requiring authentication before performing the connection when the origin position is not within the position pattern.

8. A system, comprising: a processor; and A memory, wherein the processor and the memory are communicatively coupled, wherein the processor: When initiating a pairing request, start a timer by the vehicle; Receive a first response to the pairing request from a first device by the vehicle, and receive a second response to the pairing request from a second device; When each of the first response and the second response is received, record the timer; Determine a first connection time for the first device from the recorded timer, and determine a second connection time for the second device from the recorded timer; and Connect by the vehicle to the device with the fastest connection time among the first device and the second device.

9. The system according to claim 8, wherein, the processor: Use a first radio frequency signal received from a first device to determine a first position of the first device; Use a second radio frequency signal received from a second device to determine a second position of the second device; Apply a prioritization scheme to identify the highest priority position among the first position and the second position; and Use the highest priority position to perform the connection.

10. The system according to claim 8, wherein, the processor: Sense a first temperature at a first device; Sense a second temperature inside the vehicle; Determine the difference between the first temperature and the second temperature; and Execute the connection in response to the determined difference not exceeding a threshold.

11. The system according to claim 8, wherein, the processor: Determine the position of the vehicle; Determine an authentication level required for the connection based on the determined position; and Execute the connection in response to the required authentication level being provided.

12. The system according to claim 8, wherein, the processor: Sense a first plurality of movements of a first person associated with a first device; Analyze the first plurality of movements to identify at least one pattern among the first plurality of movements; Sense a second plurality of movements of a subsequent person; When the second plurality of movements match the at least one identified pattern, determine that the subsequent person is the first person, and execute the connection; and When the second plurality of movements do not match the at least one identified pattern, require verification before executing the connection.

13. The system according to claim 8, wherein, the processor: Receive a first Bluetooth signal with a first radio frequency emission characteristic from a first device; Receive a second Bluetooth signal with a second radio frequency emission characteristic from a second device; Compare the first radio frequency emission characteristic with the second emission characteristic; In response to the first radio frequency emission characteristic matching the second radio frequency emission characteristic, execute the connection; and In response to the first radio frequency emission characteristic not matching the second radio frequency emission characteristic, require authentication before executing the connection.

14. The system according to claim 8, wherein, the processor: In response to receiving a plurality of pairing requests from a first device by the vehicle, determine a plurality of positions of the first device; Identify a position pattern from the plurality of positions; Receive a subsequent pairing request of the vehicle; Determine an origin position of the subsequent pairing request; Compare the origin position with the position pattern; Perform the connection when the origin location is within the location pattern; and Require authentication before performing the connection when the origin location is not within the location pattern.

15. A computer-readable storage medium comprising instructions that, when read by a processor, cause the processor to perform: When a pairing request is initiated, start a timer by the vehicle; Receive, by the vehicle, a first response to the pairing request from a first device and a second response to the pairing request from a second device; When each of the first response and the second response is received, record the timer; Determine a first connection time for the first device from the recorded timer, and determine a second connection time for the second device from the recorded timer; and Connect, by the vehicle, to the device having the fastest connection time among the first device and the second device.

16. The computer-readable storage medium according to claim 15, further comprising instructions for: Using a first radio frequency signal received from the first device to determine a first position of the first device; Using a second radio frequency signal received from the second device to determine a second position of the second device; Applying a prioritization scheme to identify the highest-priority position among the first position and the second position; and Performing the connection using the highest-priority position.

17. The computer-readable storage medium according to claim 15, further comprising instructions for: Sense a first temperature at the first device; Sense a second temperature inside the vehicle; Determine the difference between the first temperature and the second temperature; and Perform the connection in response to the determined difference not exceeding a threshold.

18. The computer-readable storage medium according to claim 15, further comprising instructions for: Determine the position of the vehicle; Determine an authentication level required for the connection based on the determined position; and Perform the connection in response to the required authentication level being provided.

19. The computer-readable storage medium according to claim 15, further comprising instructions for: Sense a first plurality of movements of a first person associated with the first device; Analyze the first plurality of movements to identify at least one pattern among the first plurality of movements; Sense a second plurality of movements of a subsequent person; When the second plurality of movements match the at least one identified pattern, determine that the subsequent person is the first person and perform the connection; and Require authentication before performing the connection when the second plurality of movements do not match the at least one identified pattern.

20. The computer-readable storage medium according to claim 15, further comprising instructions for: In response to receiving a plurality of pairing requests from the first device by the vehicle, determine a plurality of positions of the first device; Identify a location pattern from the plurality of positions; Receive a subsequent pairing request of the vehicle; Determine the origin location of the subsequent pairing request; Compare the origin location with the location pattern; Perform the connection when the origin location is within the location pattern; and Require authentication before performing the connection when the origin location is not within the location pattern.

Images