Enhanced pairing to facilitate seamless Bluetooth / WiFi connectivity

Abstract

Example operations include one or more of the following: detecting that a plurality of wireless devices are located in a vehicle; pairing a wireless device of the plurality of wireless devices with a head unit of the vehicle when the wireless device receives or transmits audio; and transmitting the audio through a head unit of the vehicle.

Description

Background Art

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

[0002] An example embodiment provides a method that includes one or more of: detecting that a plurality of wireless devices are located in a vehicle; pairing a wireless device among the plurality of wireless devices with a head unit of the vehicle when the wireless device receives or transmits audio; and transmitting the audio through the head unit of the vehicle.

[0003] Another example embodiment provides a system including a processor and a memory, wherein the processor and the memory are communicatively coupled, wherein the processor detects that a plurality of wireless devices are located in a vehicle; pairs the wireless devices with a head unit of the vehicle when a wireless device among the plurality of wireless devices receives or transmits audio; and transmits the audio through the head unit of the vehicle.

[0004] A further example embodiment provides a computer-readable storage medium comprising instructions that, when read by a processor, cause the processor to perform one or more of: detecting that a plurality of wireless devices are located in a vehicle; pairing a wireless device among the plurality of wireless devices with a head unit of the vehicle when the wireless device receives or transmits audio; and transmitting audio through the head unit of the vehicle. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0006] Figure 1B Yet another example of a system diagram according to an example embodiment is illustrated.

[0007] Figure 1C A flow chart according to an example embodiment is illustrated.

[0008] Figure 1D Another flow chart according to an example embodiment is illustrated.

[0009] Figure 1E Yet another flow chart according to an example embodiment is illustrated.

[0010] Figure 1F Yet another flow chart according to an example embodiment is illustrated.

[0011] Figure 1G Yet another flow chart according to an example embodiment is illustrated.

[0012] Figure 2A A transportation network diagram is illustrated according to an example embodiment.

[0013] Figure 2B Another transportation network diagram is illustrated according to an example embodiment.

[0014] Figure 2C Yet another transportation network diagram is illustrated according to an example embodiment.

[0015] Figure 2D Another transportation network diagram is illustrated according to an example embodiment.

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

[0017] Figure 2F A diagram depicting electrification of one or more components is illustrated according to an example embodiment.

[0018] Figure 2G A diagram depicting the interconnections between different elements according to an example embodiment is illustrated.

[0019] Figure 2H Yet another diagram depicting the interconnections between different elements according to an example embodiment is illustrated.

[0020] Fig.2I Yet another diagram depicting interconnections between elements according to an example embodiment is illustrated.

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

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

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

[0024] Figure 2M Yet another diagram illustrating an example of a vehicle performing secure V2V communications using security credentials according to an example embodiment.

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

[0026] Figure 3A A flow chart according to an example embodiment is illustrated.

[0027] Figure 3B Another flow chart according to an example embodiment is illustrated.

[0028] Figure 3C Yet another flow chart according to an example embodiment is illustrated.

[0029] Figure 4 A machine learning transportation network diagram is illustrated according to an example embodiment.

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

[0031] Figure 5B Another example vehicle configuration for managing database transactions between various vehicles is illustrated in accordance with an example embodiment.

[0032] Fig. 6A A blockchain architecture configuration according to an example embodiment is illustrated.

[0033] Figure 6B Another blockchain configuration according to an example embodiment is illustrated.

[0034] Figure 6C Illustrated is a blockchain configuration for storing blockchain transaction data according to an example embodiment.

[0035] Fig.6D An example data block is illustrated according to an example embodiment.

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

[0037] It will be readily appreciated that the present components as generally described and illustrated in the various figures herein may be arranged and designed in a variety of different configurations. Therefore, the following detailed description of embodiments of at least one of the methods, apparatus, computer-readable storage media, and systems as shown in the accompanying drawings is not intended to limit the scope of the claimed application, 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 may be a non-transitory computer-readable medium or a non-transitory computer-readable storage medium.

[0038] Communications between the transport(s) and certain entities, such as remote servers, other transports, and local computing devices (e.g., smartphones, personal computers, transport embedded computers, etc.) may be sent and / or received and processed by one or more "components", which may be hardware, firmware, software, or a combination thereof. These components may be part of any of these entities or computing devices or certain other computing devices. In one example, consensus decisions related to blockchain transactions may be performed by one or more computing devices or components associated with the transport(s) (which may be any of the elements described and / or depicted herein) and one or more of the components external to the transport(s) or located at a remote location away from the transport(s).

[0039] The features, structures or characteristics described in this specification can be combined in any suitable manner in one or more embodiments. For example, the phrases "exemplary embodiments", "some embodiments" or other similar languages ​​used throughout this specification refer to the fact that the specific features, structures or characteristics described in conjunction with the embodiment can be included in at least one example. Therefore, the phrases "exemplary embodiments", "in some embodiments", "in other embodiments" or other similar languages ​​that appear throughout this specification do not necessarily refer to the same set of embodiments, and the described features, structures or characteristics can be combined in one or more embodiments in any suitable manner. In each figure, even if the connection drawn is a one-way or two-way arrow, any connection between elements can also allow one-way and / or two-way communication. In the current solution, a vehicle or transport can include a car, a truck, a pedestrian area battery electric vehicle (BEV), an electronic panel car (e-Palette), a fuel cell bus, a motorcycle, a scooter, a bicycle, a ship, a recreational vehicle, an airplane, and any object that can be used to transport people and / or goods from one location to another.

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

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

[0042] Within the communication infrastructure, a decentralized database is a distributed storage system that includes multiple nodes that communicate with each other. Blockchain is an example of a decentralized database that includes an append-only immutable data structure (i.e., a distributed ledger) that can maintain records between untrusted parties. Untrusted parties are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database record, and no single peer can modify the database record without reaching a consensus between the distributed peers. For example, peers can execute a consensus protocol to verify blockchain storage entries, group storage entries into blocks, and build hash chains via these blocks. For consistency, the process forms a ledger by sorting storage entries on demand. In a public or non-permissioned blockchain, any party can participate without a specific identity. Public blockchains can involve cryptocurrencies and use consensus based on various protocols such as proof of work (PoW). In contrast, a licensed blockchain database can protect interactions between a group of entities that share a common goal but do not fully trust or cannot fully trust each other (such as businesses that exchange funds, goods, information, etc.). The present solution can work in permissioned and / or permissionless blockchain settings.

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

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

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

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

[0047] The current state of the immutable ledger represents the latest values ​​of all keywords contained in the chain entry log. Because the current state represents the latest keyword value known to the channel, it is sometimes called the world state. Smart contract executable code calls execution entries against the current state data of the ledger. In order for these smart contract executable codes to interact efficiently, the latest values ​​of keywords can be stored in the state database. The state database can be just an indexed view of the chain's entry log and can therefore be regenerated from the chain at any time. The state database can be automatically restored (or generated as needed) when a peer node starts and before an entry is accepted.

[0048] Blockchain differs from traditional databases in that it is not a central storage, but a decentralized, immutable and secure storage where nodes must share changes to records in the storage. Some properties inherent in and contributing to the implementation of blockchain include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, etc.

[0049] Example embodiments provide services to specific vehicles and / or user profiles applied to vehicles. For example, a user may be the owner of a vehicle or the operator of a vehicle owned by another party. A vehicle may need to be serviced at certain intervals, and service requirements may need to be authorized before receiving service. Moreover, a service center may provide services to vehicles in a nearby area based on the current route plan of the vehicle and the relative service level requirements (e.g., immediate, severe, medium, minor, etc.). Vehicle demand may be monitored via one or more vehicle and / or road sensors or cameras, which report sensed data to a central controller computer device in and / or outside the vehicle. The data is forwarded to a management server for review and action. The sensor may be located on one or more of the following: the interior of a transport, the exterior of a transport, a fixed object away from the transport, and another transport near the transport. The sensor may also be associated with the speed of the transport, the braking of the transport, the acceleration of the transport, the fuel level, the service requirement, the shifting of the transport, the steering of the transport, etc. As described herein, a sensor may also be a device, such as a wireless device in and / or near the transport. Additionally, sensor information may be used to identify whether the vehicle is operating safely and whether occupants are exposed to any unexpected vehicle conditions, such as during vehicle entry and / or use. Vehicle information collected before, during, and / or after vehicle operation may be identified and stored in transactions on a shared / distributed ledger, which may be generated and submitted to an immutable ledger as determined by a permission-granting group, and thus in a "decentralized" manner, such as via a blockchain membership group.

[0050] Each interested party (i.e., owner, user, company, agency, etc.) may wish to limit disclosure of private information, so the blockchain and its immutability can be used to manage permissions for each specific user vehicle profile. Smart contracts can be used to provide compensation, quantify user profile scores / ratings / reviews, apply vehicle event permissions, determine when service is required, identify conflict and / or degradation events, identify safety issue events, identify parties to an event, and provide distribution to registered entities seeking access to such vehicle event data. Likewise, results can be identified and necessary information can be shared among registered companies and / or individuals based on a "consensus" method associated with the blockchain. Such an approach cannot be implemented on a traditional centralized database.

[0051] Various driving systems of the present solution can utilize software, sensor arrays, and machine learning capabilities, light detection and ranging (LIDAR) projectors, radars, ultrasonic sensors, etc. to create maps of terrain and roads that vehicles can use for navigation and other purposes. In some embodiments, GPS, maps, cameras, sensors, etc. can also be used in autonomous vehicles instead of LIDAR.

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

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

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

[0055] Figure 1A A system diagram 100 in one set of embodiments is illustrated. In some embodiments, the present solution is executed in whole or in part in the memory of a processor 108 of a computer associated with the vehicle 102, in the memory of a server 106, in the memory of a processor 128 associated with a head unit 114, and / or in the memory of one or more other processors associated with the devices and / or entities mentioned herein. In some embodiments, the head unit 114 is a multimedia system. One or more of the server 106, the processor 108, and / or the head unit 114 may be communicatively coupled to the network 104. In some embodiments, the present solution is executed in whole or in part on any processor or server located on any element in the system diagram 100.

[0056] In some embodiments, the processor 108, the processor 128, and / or the server 106 are configured to detect that a plurality of wireless devices, such as the first wireless device 110 and the second wireless device 112, are located in the vehicle 102. For example, mobile devices, such as the first wireless device 110 and the second wireless device 112, transmit radio signals, known as probe frames, to locate nearby wireless networks. A first set of probe frames transmitted by the first wireless device 110 may include a first media access control (MAC) address that uniquely identifies the first wireless device 110. Similarly, a second set of probe frames transmitted by the second wireless device 112 may include a second MAC address that uniquely identifies the second wireless device 112. The presence of the first wireless device 110 in the vehicle 102 may be determined by the WiFi transceiver 132 of the head unit 114 scanning one or more WiFi channels to detect at least one probe frame in the first set of probe frames transmitted by the first wireless device 110. Similarly, the presence of the second wireless device 112 in the vehicle 102 may be determined by the WiFi transceiver 132 scanning one or more WiFi channels to detect at least one probe frame in the second set of probe frames transmitted by the second wireless device 112. When the WiFi transceiver 132 receives two or more different (ie, unique) MAC addresses corresponding to two or more different mobile devices, the presence of multiple wireless devices can be determined. This technique can also work in scenarios where the first and second MAC addresses are randomized for privacy reasons.

[0057] Alternatively or additionally, the presence of the first wireless device 110 and / or the second wireless device 112 in the vehicle 102 may be detected via Bluetooth; however, not all wireless device users may continuously or constantly activate Bluetooth functionality. Thus, in some cases, WiFi may be more reliable than Bluetooth for detecting the presence of the first and / or second wireless devices 110, 112.

[0058] In another embodiment, the presence of the first and / or second wireless devices 110, 112 is detected by a sensor 118 operatively coupled to the processor 108 and / or the processor 128. For example, the sensor 118 may be configured to detect RF energy emitted by the first and / or second wireless devices 110, 112. In some embodiments, the sensor 118 may include a mechanism for sensing the frequency, occupied bandwidth, and / or communication channel of the detected RF energy, thereby providing a basis for distinguishing the first wireless device 110 from the second wireless device 112. In some embodiments, the sensor 118 may include a mechanism for receiving and demodulating packets received from the first and / or second wireless devices 110, 112. The demodulated packets may include first and second MAC addresses for uniquely identifying the first and second wireless devices 110, 112.

[0059] In some embodiments, the processor 108, the processor 128, and / or the server 106 are configured to pair a wireless device (such as the first wireless device 110) among the plurality of wireless devices with the head unit 114 when the first wireless device 110 receives or transmits audio. In some embodiments, such pairing is performed using the Bluetooth transceiver 120 of the first wireless device 110 and the Bluetooth transceiver 130 of the head unit 114. Bluetooth pairing is a form of information registration for communicatively linking the first wireless device 110 with the head unit 114. The first wireless device 110 and the head unit 114 perform Bluetooth pairing by exchanging device information. The device information for the head unit 114 is stored in the memory of the first wireless device 110. Likewise, the device information for the first wireless device 110 is stored in the memory of the processor 128 of the head unit 114. After the first wireless device 110 is paired with the head unit 114, each time Bluetooth communication between the wireless device 110 and the head unit 114 is desired, it may not be necessary to repeat the aforementioned pairing process because each device has saved the necessary information in its memory, and thus communication connectivity can be maintained. However, the processor 128 and / or the processor 108 of the head unit 114 may erase, delete, and / or overwrite the device information for the first wireless device 110 from the memory of the processor 128, thereby cancelling the pairing of the first wireless device 110 with the head unit 114. Similarly, the device information for the head unit 114 may be erased, deleted, or overwritten from the memory of the first wireless device 110, thereby cancelling the pairing of the first wireless device 110 with the head unit 114.

[0060] In some embodiments, pairing is performed using the WiFi transceiver 122 of the first wireless device 110 and the WiFi transceiver 132 of the head unit 114. For example, WiFi pairing can be performed using WiFi Direct. WiFi Direct is a connection that allows device-to-device communication, linking devices together without a centralized network. In some embodiments, a first device (such as the first wireless device 110) acts as an access point. A second device (such as the head unit 114) can connect to the first wireless device 110 using the WiFi Protected Setup (WPS) security protocol and the WiFi Protected Access (WPA / WPA2) security protocol. In other embodiments, the head unit 114 acts as an access point, and the first wireless device connects to the head unit 114 using the WPS and WPA / WPA2 security protocols. Although WiFi Direct and Bluetooth may appear similar at first glance, there are some differences between them. For example, WiFi Direct can handle more information at a higher speed than Bluetooth—about 10 times faster than Bluetooth under optimal conditions. Therefore, WiFi Direct can be used when a point-to-point connection needs to transmit data-rich content (such as high-resolution images or videos).

[0061] In some embodiments, the first wireless device 110 and the head unit 114 are paired when the first wireless device 110 is receiving or transmitting audio. For example, the first wireless device 110 may be receiving an incoming voice call, making a voice call, or receiving audio from a streaming application. Some illustrative examples of streaming applications may include an online radio station, an online music service, a podcast, an online movie, or an audio-visual presentation. In some embodiments, the received audio is transmitted from the Bluetooth transceiver 120 of the first wireless device 110 to the Bluetooth transceiver 130 of the head unit 114. In other embodiments, the received audio is transmitted from the WiFi transceiver 122 of the first wireless device 110 to the WiFi transceiver 132 of the head unit 114.

[0062] In some embodiments, the processor 108, the processor 128, and / or the server 106 are configured to prioritize a wireless device that transmits audio, such as the first wireless device 110, and another wireless device that receives an incoming call, such as the second wireless device 112. For example, the first wireless device 110 may be paired with the head unit 114 and transmit audio from an on-demand streaming application, such as an online radio station, an online music service, a podcast, an online movie, or an audio-visual presentation, to the head unit 114. The second wireless device 112 may be associated with a user. The second wireless device 112 may receive an incoming phone call from another wireless device. For example, the other wireless device may be associated with a spouse, family member, close friend, work colleague, or supervisor of the user associated with the second wireless device 112. In some embodiments, the second wireless device 112 is equipped with an application (i.e., an "app") that provides a notification to the processor 108 and / or the processor 128 via the network 104 in response to the second wireless device 112 receiving the incoming call.

[0063] The incoming call received by the second wireless device 112 may involve an emergency matter or unexpected development that is more important than listening to the on-demand audio stream transmitted by the first wireless device 110. However, even if the incoming call involves a routine or non-emergency matter, the on-demand audio stream transmitted by the first wireless device 110 is generally non-interactive and can be resumed, restarted, or replayed at a later point in time. In contrast, the incoming call received by the second wireless device 112 is interactive and occurs in real time.

[0064] In some embodiments, an incoming phone call from the second wireless device 112 is considered to take precedence over streaming audio transmitted by the first wireless device 110. By interrupting, terminating, and / or ending a previously performed pairing of the first wireless device 110 with the head unit 114, an incoming call on the second wireless device 112 may take precedence over an on-demand audio stream received by the first wireless device 110, thereby unpairing the wireless device 110 from the head unit 114. In some embodiments, unpairing is performed by the processor 128 and / or the processor 108 resetting, erasing, and / or overwriting a portion of a computer-readable memory of the processor 128 of the head unit 114 that is used to store device information of the first wireless device 110. Pairing of the second wireless device 112 with the head unit 114 may then be performed. In some embodiments, the Bluetooth transceiver 130 of the head unit 114 enables pairing with the Bluetooth transceiver 124 of the second wireless device 112. Audio from an incoming phone call received by the second wireless device 112 is transmitted by the head unit 114. In other embodiments, the WiFi transceiver 132 of the head unit 114 implements pairing with the WiFi transceiver 126 of the second wireless device 112 as described above in conjunction with WiFi Direct. Audio from an incoming phone call received by the second wireless device 112 may be transmitted by the head unit 114.

[0065] In some embodiments, a lookup table stored in a computer-readable memory is used to determine the priority of a wireless device sending audio, such as the first wireless device 110, and another wireless device receiving an incoming call, such as the second wireless device 112. For example, the lookup table may be stored in a memory of the processor 108, a memory of the processor 128, a memory of the server 106, a memory of the first wireless device 110, and / or a memory of the second wireless device 112. In yet another embodiment, when the recipient of the call is in the lookup table, the streaming audio transmitted by the first wireless device 110 is disconnected from the head unit 114 by unpairing the first wireless device 110 from the head unit 114 and then pairing the second wireless device 112 with the head unit 114 to connect to the incoming call.

[0066] In another embodiment, the present solution uses at least one microphone 153 in the cabin of the vehicle 102 to receive audio, including speech from a user of the second wireless device 112 when a call is incoming. The received audio may be analyzed by the head unit 114, the processor 128, and / or the processor 108 to determine an estimated urgency of the speech. When the analysis indicates that the estimated urgency of the speech is above a threshold, the streaming audio from the first wireless device 110 to the head unit 114 may be cut off by unpairing the wireless device 110 from the head unit 114. The head unit 114 may then be paired with the second wireless device 112, connecting the incoming call to the head unit 114. In yet another embodiment, the estimated urgency is based on any of: a match of a particular determined word in the speech with a set of words in an emergency word list stored in a memory of the processor 108, the processor 128, and / or the server 106; or a particular pitch and / or energy of the speech as determined by analyzing the received audio by the head unit 114, the processor 128, and / or the processor 108.

[0067] In some embodiments, the processor 108, the processor 128, and / or the server 106 are configured to determine when a wireless device, such as the first wireless device 110, is proximate to the vehicle 102 and the first wireless device 110 is not paired with the head unit 114. In response to determining that the first wireless device 110 is proximate to the vehicle 102 and is not paired with the head unit 114, the head unit 114 transmits a message to the first wireless device 110 indicating that pairing with the head unit 114 is available. For example, the first wireless device 110 transmits a first set of probe frames to locate a nearby wireless network. The first set of probe frames transmitted by the first wireless device 110 may include a first MAC address that uniquely identifies the first wireless device 110. The presence of the first wireless device 110 proximate to the vehicle 102 may be determined by scanning one or more WiFi channels by the WiFi transceiver 132 of the head unit 114 to detect at least one probe frame in the first set of probe frames transmitted by the first wireless device 110. Alternatively or additionally, detecting the presence of the first wireless device 110 proximate to the vehicle 102 may be performed via Bluetooth; however, not all wireless device users may continuously or constantly activate Bluetooth functionality. Thus, in some cases, WiFi may be more reliable than Bluetooth for detecting the presence of the first wireless device 110 proximate to the vehicle 102 .

[0068] In some embodiments, the processor 128 determines that the head unit 114 is not paired with the first wireless device 110 by searching the memory of the processor 128 for device information corresponding to the first wireless device 110. For example, the processor 128 may compare a first MAC address received from at least one of the first set of probe frames of the first wireless device 110 with one or more MAC addresses stored in the memory of the processor 128. If the processor 128 fails to locate the first MAC address in the memory of the processor 128, then the head unit 114 is not paired with the first wireless device 110. In contrast, if the processor 128 locates the first MAC address in the memory of the processor 128, then the first wireless device 110 is paired with the head unit 114.

[0069] In some embodiments, an incoming call is received by the first wireless device 110. The processor 108, the processor 128, and / or the server 106 are configured to determine that the incoming call is at least one of a multimedia call or a video call. When the first wireless device 110 is paired with the head unit 114, the incoming call is presented on a display 134 of the vehicle 102. In some embodiments, the display 134 is integrated into the head unit 114.

[0070] In some embodiments, multimedia and video calls are distinguished from audio calls by analyzing the data transfer rate of packets sent from the Bluetooth transceiver 120 of the first wireless device 110 to the Bluetooth transceiver 130 of the head unit 114. In other embodiments, multimedia and video calls are distinguished from audio calls by analyzing the data transfer rate of packets sent from the WiFi transceiver 122 of the first wireless device 110 to the WiFi transceiver 132 of the head unit 114. For example, a typical audio call may exhibit a relatively slow data transfer rate, ranging from 4 Kbps to 13 Kbps. In contrast, a typical video call may exhibit a relatively fast data transfer rate, ranging from 1 Mbps to 8 Mbps. In other embodiments, multimedia and video calls are distinguished from audio calls by loading an application (i.e., an "app") onto the first wireless device 110, wherein the application is configured to send a notification to the head unit 114 that enables multimedia and video calls to be distinguished from audio calls.

[0071] Multimedia Messaging Service (MMS) is a technology for sending messages including multimedia content to and from first wireless device 110 via a cellular network (such as network 104). Such messages may be referred to as PXT, picture messages, or multimedia messages by users and providers. Unlike plain text SMS, MMS can deliver any of a variety of media, including up to 40 seconds of video, a single image, a slideshow of multiple images, and / or audio. An illustrative use of MMS involves sending photos from a wireless device equipped with a camera. Some media companies have utilized MMS on a commercial basis as a method of delivering news and entertainment content. Some retailers have deployed MMS as a tool for delivering scannable coupon codes, product images, and videos.

[0072] The MMS message may be encoded and encapsulated by a sending device (such as the first wireless device 110) using Multipurpose Internet Mail Extensions (MIME). The encoded and encapsulated MMS message may be forwarded to a first MMS storage and forwarding server (referred to as a Multimedia Messaging Service Center (MMSC)) on the network 104. The MMSC may be associated with a wireless carrier that provides services to the sending device. If the MMS message recipient device (such as the second wireless device 112) uses a different wireless carrier than the sending device, the first MMSC may act as a relay and forward the MMS message to a second MMSC of the wireless carrier associated with the recipient device via the network 104. For example, the MMS message may be forwarded using the Internet. Once the second MMSC receives the MMS message, it determines whether the wireless device (such as the second wireless device 112) has MMS capabilities. If the second wireless device 112 supports MMS, the content of the MMS message is extracted to a temporary storage server that is communicatively coupled to the network 104 and accessible via a Hypertext Transfer Protocol (HTTP) front end. An SMS control message containing a uniform resource locator (URL) of the content stored on the temporary storage server is sent to the second wireless device 112.

[0073] In some embodiments, the application on the second wireless device 112 sends an SMS control message to the head unit 114. The head unit 114 may then access the URL in the SMS control message to retrieve and display the MMS message.

[0074] In some embodiments, the audio from the Bluetooth transceiver 120 of the first wireless device 110 is received by the Bluetooth transceiver 130 of the head unit 114. In other embodiments, the audio from the WiFi transceiver 122 of the first wireless device 110 is received by the WiFi transceiver 132 of the head unit 114. The processor 108 and / or the processor 128 can monitor the incoming speech in the received audio by converting the incoming speech into a digitized representation of phenomena and / or text and identifying one or more sensitive words using the digitized representation of phenomena and / or text. The processor 108 and / or the processor 128 can maintain a running count indicating the number or amount of sensitive words in the received audio. When the running count exceeds a threshold, the first wireless device 110 can be unpaired from the head unit 114. For example, a portion of the device information for the first wireless device 110 stored in the memory of the processor 128 can be erased, deleted and / or overwritten. In some embodiments, one or more sensitive words may include terms related to money, finances, health conditions, death, proprietary business strategies, national security, intellectual property rights and / or other sensitive or personal matters. In some embodiments, one or more sensitive words are stored in a searchable data table in a memory of processor 128 or processor 108 .

[0075] Figure 1B A diagram of a system 150 in one set of embodiments is illustrated. In some embodiments, the present solution is executed in whole or in part in the memory of a processor 108 of a computer associated with the vehicle 102, in the memory of a server 106, in the memory of a processor 128 associated with a head unit 114, and / or in a computer-readable memory of one or more other processors associated with the devices and / or entities mentioned herein. In some embodiments, the head unit 114 is a multimedia system. One or more of the server 106, the processor 108, and / or the head unit 114 may be communicatively coupled to the network 104. In some embodiments, the present solution is executed in whole or in part on any processor or server located on any element in the system diagram 150.

[0076] In some embodiments, the processor 108, the processor 128, and / or the server 106 pairs the head unit 114 with a wireless device associated with a non-owner of the vehicle 102, such as the non-owner's wireless device 162. For example, in some embodiments, the Bluetooth transceiver 166 of the non-owner's wireless device 162 is paired with the Bluetooth transceiver 130 of the head unit 114. In other embodiments, the WiFi transceiver 170 of the non-owner's wireless device 162 is paired with the WiFi transceiver 132 of the head unit 114. The processor 108, the processor 128, and / or the server 106 can then detect at least one of the receipt of a call or the initiation of a call at a wireless device associated with the owner of the vehicle 102, such as the vehicle owner's wireless device 160. In some embodiments, the vehicle owner's wireless device 160 is equipped with an application (i.e., an "app") that provides a notification to the processor 108, the processor 128, and / or the server 106 via the network 104 in response to the vehicle owner's wireless device 160 receiving an incoming call. In some embodiments, an incoming phone call received on a vehicle owner's wireless device 160 is considered to have priority over a non-owner's wireless device 162 .

[0077] In some embodiments, an incoming call on the vehicle owner's wireless device 160 is prioritized over the non-owner's wireless device 162 by interrupting, terminating, and / or ending (i.e., unpairing) a previously performed pairing of the non-owner's wireless device 162 with the head unit 114. In some embodiments, the unpairing is performed by resetting, erasing, or overwriting a portion of the computer-readable memory of the processor 128 of the head unit 114 that is used to store device information for the non-owner's wireless device 162. Pairing of the vehicle owner's wireless device 160 with the head unit 114 may then be performed by the processor 108, the processor 128, the server 106, and / or the vehicle owner's wireless device 160. In some embodiments, the Bluetooth transceiver 130 of the head unit 114 enables pairing with the Bluetooth transceiver 164 of the vehicle owner's wireless device 160. Audio from an incoming phone call received by the vehicle owner's wireless device 160 is transmitted by the head unit 114. In other embodiments, the WiFi transceiver 132 of the head unit 114 enables pairing with the WiFi transceiver 168 of the vehicle owner's wireless device 160 as described above in conjunction with WiFi Direct. Audio from an incoming phone call received by the vehicle owner's wireless device 160 is transmitted by the head unit 114.

[0078] In some embodiments, the vehicle owner's wireless device 160 and the non-owner's wireless device 162 are determined using MAC addresses. Mobile devices such as the vehicle owner's wireless device 160 and the non-owner's wireless device 162 transmit radio signals called probe frames to locate nearby wireless networks. A first set of probe frames transmitted by the vehicle owner's wireless device 160 may include a first media access control (MAC) address that uniquely identifies the vehicle owner's wireless device 160. Similarly, a second set of probe frames transmitted by the non-owner's wireless device 162 may include a second MAC address that uniquely identifies the non-owner's wireless device 162. For example, the presence of the vehicle owner's wireless device 160 approaching the vehicle 102 may be determined by the WiFi transceiver 132 of the head unit 114 scanning one or more WiFi channels to detect at least one probe frame in the first set of probe frames transmitted by the vehicle owner's wireless device 160. Similarly, the presence of the non-owner's wireless device 162 approaching the vehicle 102 may be determined by the WiFi transceiver 132 scanning one or more WiFi channels to detect at least one probe frame in the second set of probe frames transmitted by the non-owner's wireless device 162. In some embodiments, one or more of the first MAC address of the vehicle owner's wireless device 160 and / or the second MAC address of the non-owner's wireless device 162 are stored in a memory of the processor 108. In other embodiments, one or more of the first MAC address of the vehicle owner's wireless device 160 and / or the second MAC address of the non-owner's wireless device 162 are stored in a memory of the processor 128. In some embodiments, the processor 108 and / or the processor 128 compares the stored first MAC address and / or the stored second MAC address with the probe signal received by the WiFi transceiver 132 to distinguish the vehicle owner's wireless device 160 from the non-owner's wireless device 162.

[0079] In some embodiments, the processor 108, the processor 128, the server 106, and / or the non-owner wireless device 162 pairs the non-owner wireless device 162 with the head unit 114. A first call is received on the non-owner wireless device 162. In some embodiments, the first call is detected by the Bluetooth transceiver 130 and / or the WiFi transceiver of the head unit 114. In other embodiments, the first call is detected by an application (i.e., an "app") running on the non-owner wireless device 162. The app is configured to generate a notification to the processor 108, the processor 128, and / or the server 106 via the network 104 in response to the receipt of the first call. A second call is received on the vehicle owner's wireless device 160. In some embodiments, the second call is detected by an application (i.e., an "app") running on the vehicle owner's wireless device 160. The app is configured to generate a notification to the processor 108, the processor 128, and / or the server 106 via the network 104 in response to the receipt of the second call.

[0080] In some embodiments, the processor 108, the processor 128, and / or the server 106 determine the priority between the first call and the second call based on at least one of a first party participating in the first call, a second party participating in the second call, an upcoming meeting of the first party, an upcoming meeting of the second party, a previous meeting of the first party, a previous meeting of the second party, and / or a time of day. For example, the first party participating in the first call may be determined by an application running on the non-owner's wireless device 162, where the application accesses a list of contacts associated with the non-owner's wireless device 162. Similarly, the second party participating in the second call may be determined by an application running on the vehicle owner's wireless device 160, where the application accesses a list of contacts associated with the vehicle owner's wireless device 160. For example, an incoming call from a contact with a name such as "boss," "supervisor," "mom," or "dad" may be considered to have the highest priority level.

[0081] The first party's upcoming meeting and the first party's previous meeting may be determined by an application running on the non-owner's wireless device 162, where the application accesses the calendar functionality of the non-owner's wireless device 162. Similarly, the second party's upcoming meeting and the second party's previous meeting may be determined by an application running on the vehicle owner's wireless device 160, where the application accesses the calendar functionality of the vehicle owner's wireless device 160. For example, a first incoming call involving a meeting (such as a previous meeting or an upcoming meeting) may be considered to have a higher priority than a second incoming call that does not involve the meeting, while a third incoming call involving a previous meeting may be considered to have the same priority as a fourth incoming call involving an upcoming meeting.

[0082] The time of day may be determined by a clock running on any of the vehicle owner's wireless device 160, the non-owner's wireless device 162, the network 104, the server 106, the processor 108, and / or the processor 128. For example, a call from a work contact may be considered to have a higher priority if received during work hours, but may be considered to have a lower priority if received outside of work hours. According to another example, a call from a family contact or friend may be considered to have a higher priority when received outside of work hours, but may be considered to have a lower priority when received during work hours.

[0083] In some embodiments, when the determined priority is the second call, the non-owner wireless device 162 is unpaired from the head unit 114. The vehicle owner's wireless device 160 can then be paired with the head unit 114. In some embodiments, the unpairing of the wireless device 162 from the head unit 114 is performed by resetting, erasing, or overwriting a portion of a memory of the processor 128 of the head unit 114 that stores device information for the non-owner wireless device 162. The pairing of the vehicle owner's wireless device 160 with the head unit 114 can then be performed by the processor 108, the processor 128, the server 106, and / or the vehicle owner's wireless device 160. In some embodiments, the Bluetooth transceiver 130 of the head unit 114 performs pairing with the Bluetooth transceiver 164 of the vehicle owner's wireless device 160. Audio from the incoming phone call received by the vehicle owner's wireless device 160 can be transmitted by the head unit 114. In other embodiments, the WiFi transceiver 132 of the head unit 114 performs pairing with the WiFi transceiver 168 of the vehicle owner's wireless device 160 as previously described in connection with WiFi Direct. Audio from an incoming phone call received by the vehicle owner's wireless device 160 may be transmitted by the head unit 114 .

[0084] Figure 1C A flow chart 160C is depicted of a guest mode for wireless connection via a multimedia (MM) prompt according to an example embodiment. For the front end 162C, the process begins with the customer entering the vehicle 164C. An MM prompt 178C with available Bluetooth devices from the back end 176C appears 166C, asking the customer to connect to possible options (similar to the available Wi-Fi connection prompt for a phone). When the customer selects a device 168C from the list, the selection is received. To avoid disturbing the customer in the future, there is an option at the bottom to disable the GUI window to prevent future display. A pairing code is sent 170C to the device to make a connection between the device and the vehicle. The customer enters 172C the pairing code and then connects the device 174C.

[0085] Figure 1D A flow chart 160D is depicted of a wireless icon in a user menu according to an example embodiment. For the front end 162D, the process begins with the customer entering a vehicle 164D. The customer selects a wireless icon 166D, such as a Bluetooth icon. Available BT devices 178D appear 168D, asking the customer to connect to possible options (similar to a phone's available Wi-Fi connection prompt). When the customer selects a device from the list 170D, the selection is received. The device is paired 172D, and the device is connected 174D.

[0086] Figure 1E A flow chart 160E is depicted of a guest mode for wireless connection with a shared digital key according to an example embodiment. In the front end 162E of the system, the owner shares a digital key via communication with another device, such as via SMS messaging 164E. The digital key is accepted at the other device 166E. The digital key is used to perform an action, such as unlocking the vehicle 168E. In some embodiments, the MAC ID of the mobile device is transmitted to the digital key ECU. The digital key ECU sends the MAC ID to the multimedia / head unit 170E of the vehicle.

[0087] Figure 1F Flowchart 160F depicts guest mode for connecting with a QR code or app download with a digital key in place, according to an example embodiment. In a front end 162F, a QR code is scanned or accessed via an app executed on a mobile device, where the code is associated with a rentable object, such as a vehicle. The QR contains digital key access 164F. The digital key is accepted via the mobile device 166F. The vehicle is accessed via use of the accepted digital key 168F. The digital key ECU sends a MAC ID to the vehicle's multimedia / head unit 170F. The mobile device connects to the vehicle's multimedia / head unit 172F.

[0088] Figure 1G A flow chart depicting a guest mode of connecting with a QR code or App download without a digital key according to an example embodiment. In the front end 162G, a vehicle is booked online using an application executed on a mobile device 164G. The web interface provides instructions to scan the QR code for remote pairing 166G. The QR code is scanned 168G. The MAC ID and a link to the vehicle's identification number are transmitted to the CTP 170G. The vehicle's DCM receives a notification with the MAC ID and sends it to the vehicle's multimedia / head unit for storage 172G. When the mobile device approaches the vehicle, automatic pairing occurs 174G.

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

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

[0091] Figure 2A The transport network diagram 200 according to an example embodiment is illustrated.The network includes element, and element includes the transport 202 with processor 204 and the transport 202 ' with processor 204 '.The transport 202, 202 ' communicates with each other via processor 204, 204 ' and other elements (not shown), and other elements include transceiver, transmitter, receiver, storage device, sensor and other elements that can provide communication.The communication between the transport 202 and 202 ' can directly occur, via private and / or public network (not shown) or via other transports and include one or more elements in processor, memory and software.Although being depicted as single transport and processor, multiple transports and processor can be present.One or more of the application, feature, step, solution etc. described and / or depicted herein can be utilized and / or provided by this element.

[0092] Figure 2BAnother transport network diagram 210 according to an example embodiment is illustrated. The network includes elements, and elements include a transport 202 with a processor 204 and a transport 202' with a processor 204'. Transport 202, 202' communicate with each other via processors 204, 204' and other elements (not shown), and other elements include transceivers, transmitters, receivers, storage devices, sensors and other elements that can provide communication. Communication between transport 202 and 202' can occur directly, via private and / or public networks (not shown) or via other transports and elements including one or more of a processor, memory and software. Processors 204, 204' can also communicate with one or more elements 230 including a sensor 212, a wired device 214, a wireless device 216, a database 218, a mobile phone 220, a transport 222, a computer 224, an I / O device 226 and a voice application 228. Processors 204, 204' can also communicate with one or more elements including a processor, a memory and software.

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

[0094] Figure 2C Another transport network diagram 240 is illustrated according to an example embodiment. The network includes elements including a transport 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 ). Vehicle 202 may be a vehicle, a server, or any device having a processor and a memory.

[0095] The processor 204 performs one or more of: detecting that a plurality of wireless devices are located in the vehicle 244C; pairing a wireless device of the plurality of wireless devices with a head unit of the vehicle when the wireless device receives or transmits audio 246C; and transmitting the audio through the head unit of the vehicle 248C.

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

[0097] The processor 204 performs one or more of the following: determining a higher priority wireless device among the wireless device transmitting the audio and another wireless device receiving the call among the plurality of wireless devices; and pairing 244D between the higher priority wireless device and a head unit of the vehicle; determining when the wireless device is close to the vehicle and the wireless device is not paired with the head unit; and transmitting a message 245D to the wireless device that can be paired with the head unit; receiving an incoming call by the wireless device; determining that the incoming call is at least one of a multimedia call or a video call; and presenting the incoming call on a display of the vehicle after the wireless device is paired with the head unit 246D; pairing the head unit with a wireless device associated with a non-owner of the vehicle; detecting at least one of the receipt of a call or the initiation of a call at the wireless device associated with the owner of the vehicle; unpairing the wireless device associated with the non-owner of the vehicle; and pairing the head unit with the wireless device associated with the owner of the vehicle Pairing wireless devices 247D; monitoring received audio; and when a threshold of one or more sensitive words in the received audio is exceeded, unpairing the wireless device from the head unit 248D; pairing one of the multiple wireless devices with the head unit; receiving a first call on the one of the multiple wireless devices; receiving a second call on another of the multiple wireless devices; determining a priority between the first call and the second call based on at least one of a first party participating in the first call, a second party participating in the second call, an upcoming meeting of the first party, an upcoming meeting of the second party, a previous meeting of the first party, a previous meeting of the second party, and / or a time of day; and when the determined priority is the second call, unpairing the one of the multiple wireless devices from the head unit, and pairing the other of the multiple wireless devices with the head unit 249D.

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

[0099] Although this example only describes one transport 202 in detail, multiple such nodes can be connected to blockchain 206. It should be understood that the transport 202 may include additional components and may remove and / or modify some of the components described herein without departing from the scope of the present application. The transport 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 other hardware devices. Although a single processor 204 is depicted, it should be understood that the transport 202 may include multiple processors, multiple cores, etc. without departing from the scope of the present application. The transport 202 may be a transport, a server, or any device with a processor and a memory.

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

[0101] The processor and / or computer readable medium 242E may reside completely or partially inside or outside of the vehicle. The steps or features stored in the computer readable medium 242E may be executed completely or partially by any processor and / or element in any order. In addition, one or more steps or features may be added, omitted, combined, performed at a later time, etc.

[0102] Figure 2FA diagram 265 depicting the electrification of one or more elements is illustrated. In one example, a vehicle 266 can provide power stored in its battery to one or more elements, including other (one or more) 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, and the charging stations 270 can be coupled to one or more of the vehicles 268. This configuration allows for distribution of power / power received from the vehicle 266. The vehicle 266 can also interact with other (one or more) vehicles 268, such as via vehicle-to-vehicle (V2V) technology, cellular communications, WiFi, etc. The vehicle 266 can also interact with other vehicles 268, (one or more) charging stations 270, and / or with (one or more) power grids 272 wirelessly and / or in a wired manner. 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 other (one or more) 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 elements described herein in a variety of advantageous ways as described and / or depicted herein. In addition, the safety and efficiency of the vehicle can be improved, and the environment can be positively impacted as described and / or depicted herein.

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

[0104] In one example, the charging station 270 manages the amount of energy transferred from the transport 266 so that there is enough charge remaining in the transport 266 to reach the destination. In one example, the wireless connection is used to wirelessly guide a certain amount of energy transfer between the transports 268, where the transports may all be in motion. In one embodiment, wireless charging can occur via fixed chargers and batteries of the transports aligned with each other (such as charging pads in a garage or parking space). In one example, an idle vehicle, such as vehicle 266 (which may be autonomous) is guided to provide a certain amount of energy to the charging station 270 and return to the 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 remaining energy from at least one other transport 268 and transmit the stored remaining energy at the charging station 270. In one example, various factors determine the amount of energy transferred to the charging station 270, such as distance, time, and traffic conditions, road conditions, environmental / weather conditions, vehicle conditions (weight, etc.), (one or more) occupant schedules when using the vehicle, and expected (one or more) occupant schedules waiting for the vehicle. In one example, vehicle(s) 268 , charging station(s) 270 , and / or power grid(s) 272 may provide energy to vehicle 266 .

[0105] In one embodiment, a location (not depicted) such as a building, residence, etc. may be communicatively coupled to one or more of the power grid 272, the vehicle 266, and / or the charging station(s) 270. Depending on external conditions (such as weather), the rate of electrical current flowing to one or more of the location, the vehicle 266, the other vehicle(s) 268 may be modified. For example, when the outside temperature is extremely hot or cold, increasing the likelihood of a power outage, the flow of power to the connected vehicles 266 / 268 may be slowed to help minimize the likelihood of a power outage.

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

[0107] In one example, the solution can also be used to use a mobile energy storage unit that uses a determined path to travel to a vehicle with excess energy and deposit the stored energy into the grid. In one example, the solution can also be used to determine the priority of the vehicle's need to provide energy to the grid, as well as the priority of the vehicle's current needs, such as the priority of the occupants or upcoming occupants, or the 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 certain position to release excess energy to the energy grid and then return to the previous position. In one example, the solution can also be used to determine the amount of energy required by the vehicle based on one or more conditions (such as weather, traffic, road conditions, car conditions, occupants and / or cargo in another vehicle) to provide the required energy for another vehicle via energy transmission from vehicle to vehicle, and instruct the vehicle to follow the route to another vehicle and provide energy. In one example, the solution can also be used to transfer energy from one vehicle in motion to another vehicle in motion. In one example, the solution can also be used to retrieve energy by a transport based on the energy spent by the transport to reach a rendezvous point with another transport, provide service, and return to the original location. In one example, the solution can also be used to provide the remaining distance required by the charging station, and the charging station determines the amount of energy to be retrieved from the transport, where the remaining amount of charge is based on the remaining distance. In one example, the solution can also be used to manage transports that are charged simultaneously by more than one point, such as a charging station via a wired connection and another transport via a wireless connection. In one example, the solution can also be used to apply priority to the allocation of energy to transports, where priority is given to those transports that will provide a portion of their stored charge to another entity (such as a power grid, a residence, etc.).

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

[0109] Figure 2G275 . The present solution may be stored and / or executed in whole or in part on 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 transport 276 , one or more service providers 279 , one or more public buildings 281 , one or more transportation infrastructures 282 , one or more residences 283 , a power grid / charging station 284 , a microphone 285 and / or another transport 277 . Other entities and / or devices, such as one or more private users using a smart phone 278 , a laptop 280 , an augmented reality (AR) device, a virtual reality (VR) device, and / or any wearable device may also interoperate with the present solution. Smartphone 278, laptop 280, microphone 285 and other devices can be connected to one or more of connected computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287' and 277'. One or more public buildings 281 can include various institutions. One or more public buildings 281 can utilize computing device 281'. One or more service providers 279 can include dealers, towing services, collision centers or other repair shops. One or more service providers 279 can utilize computing device 279'. These various computer devices can be directly and / or communicatively coupled to each other, such as via a wired network, a wireless network, a blockchain network, etc. In one example, microphone 285 can be used as a virtual assistant. In one example, one or more traffic infrastructure 282 can include one or more traffic signals, one or more sensors, including one or more cameras, vehicle speed sensors or traffic sensors, and / or other traffic infrastructure. One or more traffic infrastructure 282 can utilize computing device 282'.

[0110] In one example, the transport 277 / 276 can transport people, objects, permanent or temporarily fixed devices, etc. In one example, the transport 277 can communicate with the transport 276 via V2V communication through a computer associated with each transport 276' and 277' and can be referred to as a transport, a car, a vehicle, a motor vehicle, etc. The transport 276 / 277 can be a self-propelled wheeled vehicle, such as a car, a sports utility vehicle, a truck, a bus, a van, or other motorized or battery-driven or fuel cell-driven transport. For example, the transport 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 with a fuel cell stack, a motor and / or a generator. Other examples of vehicles include bicycles, scooters, trains, airplanes, ships, and any other form of transport capable of transport. The transport 276 / 277 can be semi-autonomous or autonomous. For example, the transport 276 / 277 can be self-manipulated and navigated without manual input. An autonomous vehicle may have and use one or more sensors and / or navigation units to autonomously drive itself.

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

[0112] In one example, the solution can also be used to allow the transport to continue to operate outside the boundary when the transport reaches a consensus based on the characteristics of the transport's operation and the transport's occupant. In one example, the solution can also be used to analyze the available data upload / download speed of the transport, the size of the file and the speed / direction of the transport's travel to determine the distance required to complete the data upload / download and allocate the safe area boundary for the data upload / download to be performed. In one example, the solution can also be used to perform a usually dangerous maneuver in a safe manner, such as when the system determines that an exit is coming and when the transport does not seem to be ready to exit (e.g., in an incorrect lane or at a speed that is not conducive to the upcoming exit) and instruct the target transport and other adjacent transports to allow the target transport to exit in a safe manner. In one example, the solution can also be used to use one or more vehicles to verify the diagnosis of another transport when one or more vehicles and another transport are in motion.

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

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

[0115] In one example, the solution can also be used to warn the occupants when the transport is navigating to a dangerous area and / or event, thereby allowing the transport to notify the occupants or central controller that there is a potential dangerous area on or near the current transport route. In one example, the solution can also be used to detect when the transport is traveling at a high speed, using at least one other transport to help slow down the transport in a way that minimizes traffic impact. In one example, the solution can also be used to identify dangerous driving situations, where media is captured by vehicles involved in dangerous driving situations. A geo-fence is established based on the distance of the dangerous driving situation, and additional media is captured by at least one other vehicle within the established geo-fence. In one example, the solution can also be used to send a notification to one or more occupants of the transport that the transport is approaching a traffic control mark on the road, and then if the transport crosses the mark, then receive instructions for bad driving from other nearby transports. In one example, the solution can also be used to make the transport partially inoperable by (in some embodiments) limiting speed, limiting the ability to approach another vehicle, limiting speed to a maximum value, and only allowing a given mileage allowed per time period.

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

[0117] In one example, the solution can also be used to move a transport to another location based on the user's event. More specifically, the system tracks the user's device and modifies the transport to be moved near the user at the end of the original event or the modified event. In one example, the solution can also be used to allow the available locations in the area to be verified by existing transports in the area. The approximate time when the location can be vacated is also determined based on the verification of existing transports. In one example, the solution can also be used to move the transport to the closer parking space when a closer parking space becomes available and the elapsed time since the initial parking is less than the average event time. In addition, when the event is completed or according to the location of the device associated with at least one occupant of the transport, the transport is moved to the final parking space. In one example, the solution can also be used to plan parking before the upcoming crowd. The system interacts with the transport, provides some services at a price lower than the full price and / or guides the transport to an alternative parking location based on the priority of the transport, thereby improving the optimization of the parking situation before arrival.

[0118] In one example, the solution can also be used to sell fractional ownership in a transport or to determine pricing and availability in a ride-sharing application. In one example, the solution can also be used to provide accurate and timely reports of dealer sales activity that far exceeds what is currently available. In one example, the solution can also be used to allow dealers to request assets through blockchain. By using blockchain, consensus is reached before any assets are moved. In addition, the process is automated and payments can be initiated through 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 a transport operator, and the second user is the responsible party of the transport. 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 for the destination of the transport. One or more service locations are located where the required services can be provided, which are both located in the area on the route to the destination and have the availability to perform the service. The navigation of the transport is updated using the determined service locations. A smart contract containing a service compensation value is identified, and the blockchain transaction is stored in a distributed ledger of transactions.

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

[0120] Figure 2H 290 is another block diagram showing the interconnection between different elements in one example 290. A vehicle 276 is presented and includes ECUs 295, 296 and a head unit (also known as an infotainment system) 297. An electrical control unit (ECU) is an embedded system in automotive electronics that controls one or more electrical systems or subsystems in a vehicle. The ECU may include, but is not limited to, managing 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 a controller area network (CAN) bus 294 of the vehicle. The ECU may also communicate with a vehicle computer 298 via the CAN bus 294. The vehicle's processor / sensor (such as a vehicle computer) 298 may communicate with external elements such as a server 293 via a network 292 (such as the Internet). Each ECU 295, 296 and head unit 297 may contain its own security policy. The security policy defines the allowed processes that can be executed in the appropriate context. In one example, the security policy may be provided in part or in whole in the vehicle computer 298.

[0121] ECU 295, 296 and head unit 297 can each include a custom security function element 299 that defines authorized processes and the context in which these processes are allowed to run. Context-based authorization for determining the validity of whether a process can be executed allows the ECU to maintain secure operation and prevent unauthorized access from elements such as a vehicle controller area network (CAN bus). When an ECU encounters an unauthorized process, the ECU can block the process operation. The automotive ECU can use different contexts to determine whether a process is operating within its allowed boundaries, such as proximity contexts (such as nearby objects, distances to approaching objects, speeds, and trajectories relative to other moving objects), and operating contexts (such as whether the vehicle is moving or parked, the current speed of the vehicle, the state of the transmission), user-related contexts (such as devices connected to the vehicle via wireless protocols, the use of infotainment systems, cruise control, parking assistance, driving assistance), location-based contexts and / or other contexts.

[0122] In one example, the solution described and depicted herein can be used to make a transport partially inoperable by (in some embodiments) limiting speed, limiting the ability to approach another vehicle, limiting speed to a maximum, and only allowing a given number of mileages allowed per time period. In one example, the solution can also be used to facilitate the exchange of vehicle ownership using blockchain, where data is sent to a server by a device associated with a transport accident or a device close to the accident. Based on the severity of the accident or close to the accident, the server notifies the sender of the data. In one example, the solution can also be used to help the transport avoid accidents by querying servers of other transports close to the accident, such as when the transport is involved in an accident. The server attempts to obtain data from other transports, allowing the server to understand the nature of the accident from multiple vantage points. In one example, the solution can also be used to determine that the sound from the transport is atypical and transmit data related to the sound and possible source locations to the server, where the server can determine possible causes and avoid potential dangerous situations. In one example, the solution can also be used to establish a location boundary via the system when the transport is involved in an accident. The boundary is based on decibels associated with the accident. Multimedia content of devices within the boundary is obtained to help further understand the scene of the accident. In one example, the solution can also be used to associate a vehicle with an accident and then capture media obtained by a device close to the accident location. The captured media is saved as a media fragment. The media fragment is sent to another computing device, which builds a sound profile of the accident. The sound profile will help understand more details about the accident.

[0123] In one example, the solution can also be used to utilize sensors to record audio, video, motion, etc. to record areas where potential events have occurred, such as whether a vehicle is in contact or may come into contact with another vehicle (while moving or parked), the system captures data from sensors that may reside on one or more vehicles and / or fixed or moving objects. In one example, the solution can also be used to determine that a vehicle is damaged by using sensor data to identify a new condition of the vehicle during a vehicle event and comparing that condition to a vehicle condition profile, thereby enabling safe and secure capture of critical data from a vehicle that is about to be involved in a hazardous event.

[0124] In one example, the solution can also be used to warn the occupants of a transport when the transport determines via one or more sensors that it is approaching or traveling down a one-way road the wrong way. The transport has sensors / cameras / maps that interact with the system of the current solution. The system knows the geographic location of the one-way streets. The system can notify the occupants with an audible sound, such as "approaching a one-way street." In one example, the solution can also be used to allow the transport to be paid, thereby allowing autonomous vehicle owners to monetize the data collected and stored by their vehicle sensors, thereby providing incentives for owners to share their data and provide additional data to entities, through which the performance of future vehicles can be improved, services can be provided to the owner, etc.

[0125] In one example, the solution may also be used to increase or decrease features of a vehicle based on the vehicle's actions over a period of time. In one example, the solution may also be used to assign partial ownership to a vehicle. Sensor data associated with one or more vehicles and equipment proximate to the vehicle is used to determine the condition of the vehicle. Partial ownership of the vehicle is determined based on the condition and new vehicle responsibilities are provided. In one example, the solution may also be used to provide data to a replacement / assembly component, wherein the data attempts to destroy an authorized function of the replacement / assembly component, and in response to non-destruction of the authorized function, the component is allowed to use the authorized function of the replacement / assembly component.

[0126] In one example, the solution can also be used to provide individuals with the ability to ensure that the occupant should be in the transport and that the occupant reaches a specific destination. In addition, the system ensures that the driver (if it is a non-autonomous transport) and / or other occupants are authorized to interact with the occupant. Moreover, the boarding, disembarking and location are also noted. All of the above are stored on the blockchain in an immutable manner. In one example, the solution can also be used to determine the characteristics of the driver via analysis of driving style and other elements to take action when the driver does not drive in a normal manner (such as the way the driver previously drove in specific conditions such as daytime, night, rain, snow, etc.). In addition, the attributes of the transport are also considered. Attributes include weather, whether the headlights are on, whether navigation is being used, whether HUD is being used, the volume of media being played, etc. In one example, the solution can also be used to notify the occupants in the transport of dangerous situations when the items inside the transport indicate that the occupants may not know about the dangerous situation.

[0127] In one example, the solution can also be used to mount a calibration device on a rig fixed to a vehicle, where various sensors on the transport can automatically adjust themselves based on what the calibration device should detect compared to what is actually detected. In one example, the solution can also be used to require consensus from multiple service centers using blockchain when a transport that needs service sends fault information, thereby allowing remote diagnostic capabilities, where consensus is required from other service centers on the severity threshold of the data. 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 outside the transport and the sensor data of the transport itself. The transport requests software from the server to correct the problem. In one example, the solution can also be used to allow messaging of transports nearby or in the area when an event occurs (e.g., a collision).

[0128] refer to Fig.2I , illustrates an operating environment 290A for a connected vehicle according to some embodiments. As shown, a vehicle 276 includes a controller area network (CAN) bus 291A connecting the elements 292A-299A of the vehicle. Other elements may 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 an advanced driver assistance system (ADAS) 294A, and a navigation system 295A. In some embodiments, the vehicle 276 includes a processor 296A, a memory 297A, a communication unit 298A, and an electronic display 299A.

[0129] The processor 296A includes an arithmetic logic unit, a microprocessor, a general purpose controller, and / or a similar processor array to perform calculations and provide electronic display signals to 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.

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

[0131] 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 for the navigation application 295A to provide functionality.

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

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

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

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

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

[0137] In one example, the solution described and depicted herein can be used to manage emergency scenarios and vehicle features when it is determined that the vehicle enters an area without network access. In one example, the solution 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 solution can also be used to determine when the profile of a person approaching the vehicle matches the profile attributes of the profile of at least one occupant in the vehicle. A notification is sent from the vehicle to establish communication.

[0138] In one example, the solution may also be used to analyze the availability of occupants in a respective vehicle 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 solution may also be used to determine two levels of road blockage threat and receive a gesture that may indicate an alert that the blockage has not risen above a threshold and proceed along the road by the vehicle. In one example, the solution may also be used to delete sensitive data from a vehicle when the vehicle has been damaged and cannot be used.

[0139] In one example, the solution can also be used to verify whether the customer data to be removed has indeed been removed from all required locations within the enterprise to prove GDPR compliance. In one example, the solution can also be used to provide consideration for exchanging data related to safety, important notifications, etc. from one transport to another to enhance the autonomous capabilities of lower-level autonomous vehicles. In one example, the solution can also be used to provide the ability of the transport to receive data based on the first biometric associated with the occupant. Then, the transport decrypts the encrypted data based on the verification of the second biometric, where the second biometric is a continuum of the first biometric. The transport provides the occupant with unencrypted data only when the occupant can receive the unencrypted data and delete the sensitive part when providing the sensitive part of the unencrypted data and delete the non-sensitive part after a time period associated with the biometric. In one example, the solution can also be used to provide the transport with the ability to verify the individual based on the weight and the grip applied to the steering wheel of the transport. In one example, the solution can also be used to provide the car with features that already exist but are not currently enabled, so as to present features reflecting the characteristics of the occupant to the occupant of the car.

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

[0141] In one example, the solution can also be used to assign a state to each passenger in the transport and verify the gesture of the passenger based on the state of the passenger. In one example, the solution can also be used to collect the sound details related to the collision (at what position, in what direction, rise or fall, from what device, data associated with the device, such as type, manufacturer, owner, and the number of simultaneous sounds, the time of emitting sound, etc.) and provide to the system, wherein the analysis of data helps to determine the detailed information about the collision. In one example, the solution can also be used to determine whether the transport operation is unsafe. The transport includes a plurality of components that interoperate to control the transport, and each component is associated with a separate component key. The cryptographic key is sent to the transport to reduce the transport function. In response to receiving the cryptographic key, the transport disables one or more component keys. Disabling one or more component keys causes one or more of the following: limiting the distance that the transport moves not to exceed a given speed, limiting the distance that the transport does not approach another transport, and limiting the transport not to travel beyond a threshold distance.

[0142] In one example, the solution can also be used to provide instructions from one specific transport (about to vacate a position) to another specific transport (seeking to occupy a position), with blockchain used to perform authentication and coordination. In one example, the solution can also be used to determine partial responsibility for a transport. Such as a situation where multiple people own a single transport, and the system uses the use of the transport that may change over time to update partial ownership. Other embodiments will be included in this application, including minimum ownership of a transport that is not based on the use of the transport but based on the availability of the transport and the determination of the driver of the transport and other factors.

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

[0144] In one example, the solution can also be used to propagate software / firmware uploads to a first subset of transport vehicles. The first set of transport vehicles tests the update, and when the test is successful, the update will propagate to another set of transport vehicles. In one example, the solution can also be used to propagate software / firmware updates from the main transport vehicle to the vehicle, where the update propagates from the first subset through the vehicle's network, then a larger subset, and so on. A portion of the update may be sent first, and then the rest is sent from the same vehicle or another vehicle. In one example, the solution can also be used to provide updates to the transport computer to the devices of the transport vehicle and the transport operator / passenger. The update may be authorized by all drivers and / or all occupants. The software update is provided to the vehicle and (one or more) devices. The user does not need to do anything, as long as he is close to the vehicle, the function will automatically occur. A notification is sent to (one or more) devices indicating that the software update has been completed. In one example, the solution can also be used to verify whether the OTA software update is performed by a qualified technician, and one or more transport components generate a status related to the following: the initiator of the verification code, the wireless reception of the software update, the information contained in the software update, and the process of verifying the results.

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

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

[0147] Electronic Control Units (ECUs) are nodes within a vehicle that control tasks such as activating windshield wipers to tasks such as anti-lock brakes. ECUs are typically interconnected through a central network of the vehicle, which may be referred to as a Controller Area Network (CAN). Features of existing technologies such as autonomous driving rely heavily on implementing new and complex ECUs such as Advanced Driver Assistance Systems (ADAS), sensors, etc. While these new technologies help improve vehicle safety and driving experience, they also increase 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.

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

[0149] When the user presses the button 293B on the keychain 292B (or otherwise activates the keychain, etc.), the CPU 2922B wakes up in the keychain 292B and sends a data stream to the transmitter 2921B, which is output via an antenna. In other embodiments, the user's intention is confirmed on the keychain 292B via other means, such as via a microphone that receives audio, a camera that captures images and / or videos, or other sensors commonly used in the art for detecting the user's intention, including receiving gestures, movements, eye movements, etc. The data stream can be a 64-bit to 128-bit long signal, which includes one or more of a preamble, a command code, and a rolling code. The signal can be sent at a rate between 2KHz and 20KHz, but the embodiment is not limited thereto. In response, the receiver 2911B of the transport 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, unlock the door, etc.) to the command module 2912B.

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

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

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

[0153] In this example, the ECU 291C includes a transceiver 2911C and a microcontroller 2912C. The transceiver can be used to send and receive messages to and 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 also 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 the message and also uses the ECU software installed therein to decide what message to send.

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

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

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

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

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

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

[0160] 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, roadside infrastructure (e.g., traffic lights, signs, cameras, parking meters, etc.) and the like via wireless networks. Wireless networks may include one or more of Wi-Fi networks, cellular networks, dedicated short-range communications (DSRC) networks, and the like. Vehicles can use V2V communications to provide other vehicles with information about the speed, acceleration, braking, direction, and the like of the vehicles. Therefore, vehicles can understand the situation ahead before it becomes visible, thereby greatly reducing collisions. In addition, as discussed with respect to Figure 2L The present solution described and depicted may be used with this and other networks and / or systems, including those described and depicted herein.

[0161] Figure 2M An example 290E of vehicles 293E and 292E performing secure V2V communications using security credentials is illustrated in accordance with an example embodiment. Figure 2M , the vehicles 293E and 292E can communicate via V2V communication on a short-range network, a cellular network, etc. Before sending a message, the vehicles 293E and 292E can sign the message using the corresponding public key certificates. For example, the vehicle 293E can sign the V2V message using the public key certificate 294E. Similarly, the vehicle 292E can sign the V2V message using the public key certificate 295E. In one example, the public key certificates 294E and 295E are associated with the vehicles 293E and 292E, respectively.

[0162] After receiving communications from each other, the transports may verify the signatures with the certificate authority 291E or the like. For example, the transport 292E may verify with the certificate authority 291E that the public key certificate 294E used by the transport 293E to sign the V2V communication is authentic. If the transport 292E successfully verifies the public key certificate 294E, then the transport knows that the data is from a legitimate source. Similarly, the transport 293E may verify with the certificate authority 291E that the public key certificate 295E used by the transport 292E to sign the V2V communication is authentic. In addition, as described with respect to Figure 2M The present solution described and depicted may be used with this and other networks and / or systems, including those described and depicted herein.

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

[0164] exist Figure 2N In the example of , the security processor 292F may include an authorization module 293F, an authentication module 294F, and a cryptographic module 295F. The security processor 292F may be implemented within a computer of a vehicle 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 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 computer of the vehicle via a line are also secure.

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

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

[0167] The encryption module 295F can store asymmetric key pairs for the transport to use for communication with other external user devices and transports. For example, the encryption module 295F can provide a private key for the transport to use for encryption / decryption communications, and the corresponding public key can be provided to other user devices and transports to enable other devices to decrypt / encrypt communications. The encryption module 295F can communicate with a remote server to receive new keys, updates to keys, keys for new transports, users, etc. The encryption module 295F can also transmit any updates to the local private / public key pair to the remote server.

[0168] Figure 3A A flowchart 300 is illustrated according to an example embodiment. Figure 3A The process includes one or more of the following: detecting that multiple wireless devices are located in a vehicle 302; pairing the wireless device with a head unit of the vehicle when a wireless device in the multiple wireless devices receives or sends audio 304; and transmitting audio through the head unit of the vehicle 306.

[0169] Figure 3B Another flow chart 320 is illustrated according to an example embodiment. Figure 3B, the process includes one or more of the following: determining a higher priority wireless device among the wireless device sending audio and another wireless device receiving the call among the multiple wireless devices; and pairing 322 between the higher priority wireless device and a head unit of the vehicle; determining when the wireless device is close to the vehicle and the wireless device is not paired with the head unit; and transmitting a message to the wireless device that can be paired with the head unit 323; receiving an incoming call by the wireless device; determining that the incoming call is at least one of a multimedia call or a video call; and presenting the incoming call on a display of the vehicle after the wireless device is paired with the head unit 324; pairing the head unit with a wireless device associated with a non-owner of the vehicle; detecting at least one of reception of a call or initiation of a call at the wireless device associated with the owner of the vehicle; unpairing the wireless device associated with the non-owner of the vehicle; and pairing the head unit with a wireless device associated with the owner of the vehicle Device pairing 325; monitoring received audio; and when a threshold of one or more sensitive words in the received audio is exceeded, unpairing the wireless device from the head unit 326; and pairing one of the multiple wireless devices with the head unit; receiving a first call on the one of the multiple wireless devices; receiving a second call on another of the multiple wireless devices; determining a priority between the first call and the second call based on at least one of a first party participating in the first call, a second party participating in the second call, an upcoming meeting of the first party, an upcoming meeting of the second party, a previous meeting of the first party, a previous meeting of the second party, and / or a time of day; and when the determined priority is the second call, unpairing the one of the multiple wireless devices from the head unit, and pairing the other of the multiple wireless devices with the head unit 327.

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

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

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

[0173] 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 sensor 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.

[0174] In yet another embodiment, the vehicle 402 may send one or more sensor 404 data to the machine learning training system 410. In yet another example, the machine learning subsystem 406 may send the sensor 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.

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

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

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

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

[0179] Figure 6B FIG. 1 illustrates a shared ledger configuration according to an example embodiment. Figure 6B , blockchain logic example 640 includes a blockchain application interface 642 as an API or plug-in application linked to a computing device and execution platform for a specific transaction. Blockchain configuration 640 may include one or more applications that link to an application programming interface (API) to access and execute stored program / application code (e.g., smart contract executable code, smart contracts, etc.) that can be created according to the custom 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 an attachment to a distributed ledger.

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

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

[0182] Fig. 6A and Figure 6B The blockchain architecture configuration can process and execute program / application code via one or more interfaces exposed by the blockchain platform and the services provided. As a non-limiting example, a smart contract can be created to perform reminders, updates, and / or other notifications of changes, updates, etc. The smart contract itself can be used to identify rules associated with authorization and access requirements and the use of the ledger. For example, the information may include a new entry, which may be processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer. The results may 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 may be utilized to retrieve any data or information described herein.

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

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

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

[0186] Figure 6C FIG. 1 illustrates a blockchain configuration for storing blockchain transaction data according to an example embodiment. Figure 6C , an 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 may represent a service provider entity that queries a vehicle service provider to share user profile rating information in the event that a known and established user profile is attempting to rent a vehicle with an established rating profile. The server 666 may be receiving and processing data related to a vehicle service request. As service events occur, such as vehicle sensor data indicating a need for fuel / charging, maintenance service, etc., smart contracts may be used to invoke rules, thresholds, sensor information collection, etc., which may be used to invoke vehicle service events. Blockchain transaction data 670 is saved for each transaction, such as access events, subsequent updates to vehicle service status, event updates, etc. The transaction may include the parties, requirements (e.g., 18 years of age, eligible candidate for service, valid driver's license, etc.), compensation levels, distance traveled during the event, recipients of the registration allowed to access the event and host vehicle service, permissions / permissions, sensor data retrieved during vehicle event operations, operations to record details of a service event and identify the condition status of the vehicle, and thresholds used to determine whether the service event has been completed and whether the condition status of the vehicle has changed.

[0187] Fig.6D 680, and the contents of block structures 682A through 682n, that may be added to a distributed ledger according to an example embodiment. Fig.6D , a client (not shown) may submit entries to a blockchain node to enact an activity on the blockchain. As an example, a client may be an application that acts on behalf of a requester (such as a device, person, or entity) to propose an entry for a blockchain. Multiple blockchain peers (e.g., blockchain nodes) may maintain the state of a blockchain network and a copy of a distributed ledger. There may be different types of blockchain nodes / peers in a blockchain network, including an endorsing peer that simulates and endorses an entry proposed by a client and a committing peer that verifies the endorsement, validates the entry, and submits the entry to the distributed ledger. In this example, a blockchain node may perform the role of an endorser node, a committer node, or both.

[0188] 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. One distributed ledger can exist for each channel, and each peer maintains its own copy of the distributed ledger for each channel of which it is a member. The blockchain is a log of entries structured as hash-linked blocks, where each block contains a sequence of N entries. Blocks can include various components, such as Fig.6D The blocks are linked by adding a hash of the previous block's header to the block header of the current block. In this way, all entries on the blockchain are ordered and cryptographically linked together, preventing tampering of the blockchain data without breaking the hash links. In addition, because of the links, the latest block in the blockchain represents every entry that came before it. The present blockchain can be stored on a peer-to-peer file system (local or attached storage) that supports append-only blockchain workloads.

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

[0190] An endorsing peer receives an entry from a client and endorses the entry based on the simulation results. An endorsing peer holds a smart contract that simulates the entry proposal. When an endorsing peer endorses an entry, the endorsing peer creates an entry endorsement, which is a signed response from the endorsing peer 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 in the smart contract executable code. An example of an endorsement policy is "a majority of endorsing peers must endorse the entry". Different channels can have different endorsement policies. The client application forwards the endorsed entry to the ordering service.

[0191] The sorting service accepts endorsed entries, sorts them into blocks, and delivers those blocks to commit peers. For example, a sorting service may initiate a new block when a threshold of entries has been reached, a timer has timed out, or other conditions have occurred. In this example, the blockchain node is a committing peer that has received a data block 682A for storage on the blockchain. The sorting service may consist of a cluster of sorters. The sorting service does not process entries, smart contracts, or maintain a shared ledger. Instead, the sorting service may accept endorsed entries and specify the order in which those entries are submitted to the distributed ledger. The architecture of a blockchain network may be designed so that a specific implementation of "sorting" (e.g., Solo, Kafka, BFT, etc.) becomes a pluggable component.

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

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

[0194] Block data 690A may store entry information for each entry recorded in the block. For example, entry data may include 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's signature, endorser's identity, endorser signature, proposal hash, smart contract executable code event, response status, namespace, read set (list of keywords and versions read by the entry, etc.), write set (list of keywords and values, etc.), start key, end key, keyword list, Merkel tree query summary, etc. One or more of the above. Entry data may be stored for each of the N entries.

[0195] In some embodiments, the block data 690A may also store transaction-specific data 686A that adds additional information to the blockchain of the hash link of the block in the blockchain. Therefore, the data 686A may be stored in an immutable log of the block on the distributed ledger. Some benefits of storing such data 686A are reflected in the various embodiments disclosed and described 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 when the block was created, a reference to the last configuration block, an entry filter that identifies valid and invalid entries within the block, the last offset persisted by the sorting service that sorts the block, etc. The signature, the last configuration block, and the sorting metadata may be added by the sorting service. At the same time, the submitter of the block (such as a blockchain node) may add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. The entry filter may include a byte array of size equal to the number of entries in the block data 610A and a verification code that identifies whether the entry is valid / invalid.

[0196] 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 a hash value of the immediately preceding block. The hash value of the immediately preceding block may be just the hash of the header of the previous block, or may be the hash value of the entire previous block. By including the hash value of the previous block in each of the remaining blocks, tracking from the Nth block to the genesis block (and the associated original files) can be performed block by block, as indicated by arrow 692, to establish an auditable and unchangeable chain-of-custody.

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

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

[0199] Figure 7 It is not intended to imply any limitation on the scope of use or functionality of the embodiments of the present application described herein. Regardless, computing node 700 is capable of being implemented and / or performing any set of functionality described herein above.

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

[0201] 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. In general, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. Computer system / server 702 may be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communications network. In a distributed cloud computing environment, program modules may be located in local and remote computer system storage media including memory storage devices.

[0202] like Figure 7 As shown in FIG. 7 , a computer system / server 702 in a 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.

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

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

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

[0206] As will be appreciated by those skilled in the art, aspects of the present application may be implemented as systems, methods or computer program products. Thus, aspects of the present application may take the form of complete hardware embodiments, complete software embodiments (including firmware, resident software, microcode, etc.) or embodiments of combined software and hardware aspects, which embodiments may generally all be referred to as "circuits", "modules" or "systems". Here, aspects of the present application may take the form of computer program products implemented in one or more computer-readable media, which have computer-readable program codes implemented thereon.

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

[0208] Although exemplary embodiments of at least one of the systems, methods, and non-transient computer-readable media are shown in the accompanying drawings and described in the foregoing detailed description, it should be understood that the present application is not limited to the disclosed embodiments, but is capable of many rearrangements, modifications, and substitutions as set forth and defined in the following claims. For example, the capabilities of the systems of the various figures may be performed by one or more of the modules or components described herein or in a distributed architecture, and may include pairs of transmitters, receivers, or both. For example, all or part of the functions performed by the various modules may be performed by one or more of these modules. In addition, the functions described herein may be performed at different times and in relation to various events inside or outside the modules or components. Moreover, information sent between the various modules may be sent between the modules via at least one of the following: a data network, the Internet, a voice network, an Internet protocol network, a wireless device, a wired device, and / or via multiple protocols. Moreover, messages sent or received by any module may be sent or received directly and / or via one or more other modules.

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

[0210] It should be noted that some of the system features described in this specification have been presented as modules in order to more specifically emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising a custom very large scale integration (VLSI) circuit or gate array, such as an off-the-shelf semiconductor of a logic chip, transistors or other discrete components. A module may also be implemented in a programmable hardware device, such as a field programmable gate array, programmable array logic, a programmable logic device, a graphics processing unit, etc.

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

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

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

[0214] It will be readily understood by those skilled in the art that the above content may be practiced using steps in a different order and / or using hardware elements in a configuration different from that disclosed. Therefore, although the present application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative configurations will be apparent.

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

Claims

1. A method comprising: detecting that a plurality of wireless devices are located in a vehicle; pairing the wireless device with a head unit of the vehicle when a wireless device among the plurality of wireless devices receives or transmits audio; as well as The audio is transmitted through the head unit of the vehicle.

2. The method of claim 1, comprising: determining a higher priority wireless device among the wireless device transmitting the audio and another wireless device receiving the call among the plurality of wireless devices; as well as Pairing is performed between the higher priority wireless device and the head unit of the vehicle.

3. The method of claim 1, comprising: determining when the wireless device is in proximity to the vehicle and the wireless device is not paired with the head unit; as well as A message is transmitted to the wireless device to pair with the head unit.

4. The method of claim 1, comprising: receiving an incoming call by the wireless device; determining that the incoming call is at least one of a multimedia call or a video call; as well as After the wireless device is paired with the head unit, the incoming call is presented on a display of the vehicle.

5. The method of claim 1, comprising: pairing the head unit with a wireless device associated with a non-owner of the vehicle; detecting at least one of receipt of a call or initiation of a call at a wireless device associated with an owner of the vehicle; unpairing the wireless device associated with a non-owner of the vehicle; as well as The head unit is paired with the wireless device associated with the owner of the vehicle.

6. The method of claim 1, comprising: monitoring of received audio; as well as When a threshold of one or more sensitive words in the received audio is exceeded, the wireless device is unpaired from the head unit.

7. The method of claim 1, comprising: pairing a wireless device from the plurality of wireless devices with the head unit; receiving a first call on the one of the plurality of wireless devices; receiving a second call on another wireless device of the plurality of wireless devices; determining a priority between the first call and the second call based on at least one of a first party participating in the first call, a second party participating in the second call, an upcoming meeting of the first party, an upcoming meeting of the second party, a previous meeting of the first party, a previous meeting of the second party, and / or a time of day; as well as When the determined priority is the second call, pairing of the one of the plurality of wireless devices with the head unit is canceled, and the other of the plurality of wireless devices is paired with the head unit.

8. A system comprising: processor; as well as a memory, wherein the processor and the memory are communicatively coupled, wherein the processor: detecting that a plurality of wireless devices are located in a vehicle; pairing the wireless device with a head unit of the vehicle when a wireless device among the plurality of wireless devices receives or transmits audio; as well as The audio is transmitted through the head unit of the vehicle.

9. The system of claim 8, wherein the processor: determining a higher priority wireless device among the wireless device transmitting the audio and another wireless device receiving the call among the plurality of wireless devices; and Pairing is performed between the higher priority wireless device and the head unit of the vehicle.

10. The system of claim 8, wherein the processor: determining when the wireless device is proximate to the vehicle and the wireless device is not paired with the head unit; and A message is transmitted to the wireless device to pair with the head unit.

11. The system of claim 8, wherein the processor: receiving an indication of a call from the wireless device; determining that the call is at least one of a multimedia call or a video call; and After the wireless device is paired with the head unit, the call is presented on a display of the vehicle.

12. The system of claim 8, wherein the processor: pairing the head unit with a wireless device associated with a non-owner of the vehicle; detecting at least one of receipt of a call or initiation of a call at a wireless device associated with an owner of the vehicle; unpairing the wireless device associated with a non-owner of the vehicle; as well as The head unit is paired with the wireless device associated with the owner of the vehicle.

13. The system of claim 8, wherein the processor: monitoring received audio; and When a threshold of one or more sensitive words in the received audio is exceeded, the wireless device is unpaired from the head unit.

14. The system of claim 8, wherein the processor: pairing a wireless device from the plurality of wireless devices with the head unit; receiving a first indication of a first call from the one of the plurality of wireless devices; receiving a second indication of a second call from another wireless device of the plurality of wireless devices; determining a priority between the first call and the second call based on at least one of a first party participating in the first call, a second party participating in the second call, a scheduled future meeting of the first party, a scheduled future meeting of the second party, a previous meeting of the first party, a previous meeting of the second party, and / or a time of day; as well as When the determined priority is the second call, pairing of the one of the plurality of wireless devices with the head unit is canceled, and the other of the plurality of wireless devices is paired with the head unit.

15. A computer-readable storage medium comprising instructions which, when read by a processor, cause the processor to execute: detecting that a plurality of wireless devices are located in a vehicle; When a wireless device among the plurality of wireless devices receives or transmits audio, pairing the wireless device with a head unit of the vehicle; and The audio is transmitted through the head unit of the vehicle.

16. The computer-readable storage medium of claim 15, further comprising instructions for: determining a higher priority wireless device among the wireless device transmitting the audio and another wireless device receiving the call among the plurality of wireless devices; and Pairing is performed between the higher priority wireless device and the head unit of the vehicle.

17. The computer-readable storage medium of claim 15, further comprising instructions for: determining when the wireless device is proximate to the vehicle and the wireless device is not paired with the head unit; and A message is transmitted to the wireless device to pair with the head unit.

18. The computer-readable storage medium of claim 15, further comprising instructions for: receiving an incoming call by the wireless device; determining that the incoming call is at least one of a multimedia call or a video call; and After the wireless device is paired with the head unit, the incoming call is presented on a display of the vehicle.

19. The computer-readable storage medium of claim 15, further comprising instructions for: monitoring received audio; and When a threshold of one or more sensitive words in the received audio is exceeded, the wireless device is unpaired from the head unit.

20. The computer-readable storage medium of claim 15, further comprising instructions for: pairing a wireless device from the plurality of wireless devices with the head unit; receiving a first call on the one of the plurality of wireless devices; receiving a second call on another wireless device of the plurality of wireless devices; determining a priority between the first call and the second call based on at least one of a first party participating in the first call, a second party participating in the second call, an upcoming meeting of the first party, an upcoming meeting of the second party, a previous meeting of the first party, a previous meeting of the second party, and / or a time of day; as well as When the determined priority is the second call, pairing of the one of the plurality of wireless devices with the head unit is canceled, and the other of the plurality of wireless devices is paired with the head unit.

Images