System and method for providing secure access to a vehicle system

Abstract

In some embodiments, apparatuses and methods are provided herein that may be used to allow connection to a vehicle. In some implementations, a method includes receiving, by an authorization server, a connection request for the vehicle from a remote device; verifying the connection request by the authorization server; generating, by the authorization server, an authorization certificate in response to verifying the connection request; the authorization server sends the authorization certificate; receiving, by the vehicle, the certificate of authorization; authenticating, by the vehicle, the certificate of authorization; and activating, by the vehicle, a vehicle communication system in response to authenticating the certificate of authorization.

Description

Technical Field

[0001] This invention relates generally to vehicles, and more specifically to providing secure access to vehicles through authenticated and authorized operations. Background Technology

[0002] Typically, vehicles (e.g., buses and commercial vehicles) include mechanisms for accessing vehicle-related information. For example, most vehicles include an On-Board Diagnostics (OBD) port. Traditionally, the information available for access is primarily vehicle-related diagnostic information. Vehicle-related diagnostic information can be accessed via the OBD port. For example, a person can physically connect a device (e.g., a diagnostic tool) to the OBD port to access diagnostic information. While this OBD port allows access to vehicle-related diagnostic information, it offers virtually no security guarantees. For example, OBD port security has traditionally been based on the fact that physical access to the OBD port is required to access diagnostic information. Because the OBD port is located inside the vehicle, unauthorized access is prevented solely by preventing entry into the vehicle (e.g., by locking the vehicle doors).

[0003] However, vehicles are becoming increasingly advanced. While information accessible via the OBD port was once primarily limited to diagnostic information, modern vehicles may have numerous systems accessible via the OBD port. Therefore, the potential dangers of unauthorized access to the OBD port extend far beyond simply receiving diagnostic information. For example, in modern vehicles, engine control parameters, autonomous driving controls, and information about connected devices can be accessed and / or modified via the OBD port. Further complicating matters, many modern vehicles support wireless (“over-the-air” or “OTA”) access. This wireless access can be performed via a device communicatively coupled to the OBD port (e.g., a “donkey” device) or a radio associated with the vehicle. When wirelessly connected to the vehicle, physical access is not required, and simply preventing entry into the vehicle's interior is insufficient to provide the necessary security. Therefore, improved systems and methods are needed for secure access to the vehicle's onboard systems. Summary of the Invention

[0004] In some implementations, a method for allowing connection to a vehicle includes: receiving a connection request to the vehicle from a remote device by an authorization server; verifying the connection request by the authorization server; generating an authorization certificate by the authorization server in response to verifying the connection request; sending the authorization certificate by the authorization server; receiving the authorization certificate by the vehicle; authenticating the authorization certificate by the vehicle; and activating a vehicle communication system by the vehicle in response to authenticating the authorization certificate.

[0005] In some embodiments, a system for allowing connection to a vehicle includes: an authorization server and the vehicle, wherein the authorization server is configured to: receive a connection request to the vehicle from a remote device; verify the connection request; generate an authorization certificate in response to verifying the connection request; and send the authorization certificate; wherein the vehicle is configured to: authenticate the authorization certificate; and activate a vehicle communication system in response to authenticating the authorization certificate. Attached Figure Description

[0006] This document discloses embodiments of systems, devices, and methods relating to allowing connection to vehicles. This specification includes accompanying drawings, in which:

[0007] Figure 1 It is a block diagram of a system according to some embodiments, including an example of a system for allowing connection to a vehicle.

[0008] Figure 2 This is a block diagram of a system for allowing connection to a vehicle, according to some implementation methods;

[0009] Figure 3 According to some implementation methods, including regarding Figure 2 A block diagram of an example implementation of a system for allowing connection to a vehicle, with additional details;

[0010] Figure 4 It is a flowchart depicting example operations for allowing connection to a vehicle according to some implementations;

[0011] Figure 5 It describes the actions according to some implementation methods. Figure 4 The flowchart of the supplementary example operation for the example operation, which sends the owner prompt to the owner of the vehicle;

[0012] Figure 6 It describes the actions according to some implementation methods. Figure 4 A flowchart of example operations for deactivating a vehicle's communication system, supplementing the example operations; and

[0013] Figure 7 It is based on some embodiments that can be used for implementation Figure 2 and / or Figure 3 A block diagram of any of the components, circuits, circuit systems, systems, functions, devices, processes, or equipment of a system and / or other systems or devices mentioned above or below, or a part of such circuits, circuit systems, functions, systems, devices, processes, or equipment.

[0014] The elements in the accompanying drawings are shown for simplicity and clarity and are not necessarily drawn to scale. For example, the size and / or relative positioning of some elements in the drawings may be enlarged relative to other elements to aid in understanding the various embodiments of this disclosure. Moreover, common but well-known elements that are useful or necessary in commercially viable embodiments are not typically depicted to facilitate a clearer view of these different embodiments of this disclosure. Detailed Implementation

[0015] Generally, according to various embodiments, this document provides systems, apparatuses, and methods that can be used to allow connection to a vehicle. In some embodiments, a method includes: receiving a connection request to the vehicle from a remote device by an authorization server; verifying the connection request by the authorization server; generating an authorization certificate by the authorization server in response to verifying the connection request; sending the authorization certificate by the authorization server; receiving the authorization certificate by the vehicle; authenticating the authorization certificate by the vehicle; and activating a vehicle communication system by the vehicle in response to authenticating the authorization certificate.

[0016] As discussed earlier, vehicles (e.g., buses and commercial vehicles) typically include mechanisms for accessing vehicle-related information. Traditionally, this mechanism is a physical port located inside the vehicle (e.g., an OBD port). Furthermore, the information accessible via the OBD port is usually vehicle-related diagnostic information. For example, inserting a diagnostic tool into a vehicle might display code P0401, indicating a problem with the vehicle's exhaust gas recirculation (EGR) system. Because the information accessible via the OBD port is limited to diagnostic information, malicious actors could hardly harm the vehicle even if they accessed diagnostic information in an unauthorized manner. Therefore, OBD port security is minimal due to the low risk. Typically, OBD port security is limited to preventing physical access to the vehicle interior, thereby preventing physical access to the OBD port itself.

[0017] In modern vehicles, as vehicles become increasingly complex and interconnected, the information accessible via the OBD port has expanded. For example, modern vehicles can store information and / or parameters associated with autonomous driving features, user personal information, engine control parameters, and so on. Therefore, in modern vehicles, if a malicious actor has access to one or more of the vehicle's electronic control units (ECUs), the malicious actor could potentially impair the vehicle's autonomous driving functions, access user personal information, and so on.

[0018] Despite the astonishing pace of vehicle development, the security of access to vehicle-related information has remained largely stagnant. Complicating matters further, many modern vehicles include wireless (e.g., “over-the-air” or “OTA”) connectivity. This wireless access can be performed via a device communicatively coupled to the OBD port (e.g., a “donkey” device) or a radio associated with the vehicle. In the case of wireless connectivity, traditional methods of preventing physical access to the OBD port (e.g., by locking the vehicle's doors) are ineffective.

[0019] Currently, most security mechanisms (if any) that prevent unauthorized access to a vehicle via communication channels operate at the application layer. That is, authentication of the connection is not performed until a connection has been established and data has been exchanged between the device connected to the vehicle (e.g., a “remote device”) and the vehicle. Because this security mechanism authenticates after a connection has been established, an unauthorized device may have already communicated with the vehicle, and the security mechanism may be compromised. Furthermore, even if the security mechanism successfully prevents unauthorized access to sensitive information or controls, attacks that disable and / or alter vehicle operation (e.g., via a denial-of-service “DoS” attack) can still occur because a connection has already been established.

[0020] This document describes systems, methods, and apparatuses that seek to minimize, if not eliminate, the shortcomings of current security mechanisms. In one implementation, authentication is performed remotely from outside the vehicle. For example, a remote device (i.e., the device issuing a connection request to connect to the vehicle) sends the connection request to an authorization server. The authorization server verifies the connection request and generates an authorization certificate. The vehicle authenticates the authorization certificate, and upon such authentication, the vehicle communication system is activated. Once the vehicle communication system is activated, the remote device (or another device) can communicate with the vehicle's internal systems. Because authentication occurs before connecting to the vehicle, this implementation reduces the risk of unauthorized access to the vehicle's internal systems. Figure 1 The discussion provides an overview of this system.

[0021] Figure 1 This is a block diagram of a system 100 for allowing connection to vehicle 108 according to some embodiments, including example operations for allowing connection to the vehicle. The system includes a remote device 102, an authorization server 104, a diagnostic device 106, and vehicle 108. A user (e.g., an automotive technician) can interact with the authorization server 104 and / or vehicle 108 via a communication network (not shown). Figure 1 Operations from stage A to stage K are described. These stages are examples and do not necessarily occur separately over time (e.g., operations in different stages may overlap). Furthermore, Figure 1 This is an overview of the example operations.

[0022] In phase A, remote device 102 sends connection request 110 to authorization server 104. For example, a user may generate connection request 110 via a user input device of remote device 102. Connection request 110 requests a connection to vehicle 108, for example, for diagnostic and / or maintenance work on vehicle 108. Connection request 110 may include any suitable information (i.e., information associated with connection request 110), as discussed herein. For example, information associated with connection request 110 may include vehicle identifier (e.g., vehicle identification number (VIN)), brand of vehicle 108, model of vehicle 108, trim of vehicle 108, diagnostic information of vehicle 108, type of connection requested (e.g., wired, wireless, etc.), type of service to be performed, indication of the vehicle system to be accessed by remote device 102, duration of the requested access, time of the requested access, identity of the individual receiving connection request 110 from it, type of facility receiving connection request 110 from it, information associated with remote device 102, information associated with the device to be communicatively coupled to vehicle 108, etc. In one implementation, the connection request 110 includes at least information identifying the vehicle 108 and the requester (e.g., the user and / or device making the request).

[0023] In phases B through C, the authorization server 104 receives and verifies the connection request 110. The authorization server 104 may verify the connection request 110 in any suitable manner. For example, in one embodiment, the authorization server 104 employs an account-based system. In such a system, automotive facilities (e.g., dealerships, independent repair shops, etc.) and possibly individual technicians may have accounts with account information (e.g., credentials) stored at and / or in a database associated with the authorization server 104. In addition to information identifying the vehicle 108 and the requesting party, the connection request 110 may also include the requesting party's credentials. The authorization server 104 verifies the requesting party's credentials and / or account information. Further, in some embodiments, the authorization server 104 verifies whether the requested operation is registered and / or permitted based on the credentials and / or account information, and may verify device information. If the authorization server 104 verifies the connection request, then in phase D, the authorization server 104 generates an authorization certificate 112, and in phase E, the authorization server 104 sends the authorization certificate 112 to the remote device 102 and / or diagnostic device 106. In some embodiments, the authorization certificate 112 includes access operation details.

[0024] Authorization server 104 can protect authorization certificate 112 in any suitable manner. For example, authorization server 104 can protect authorization certificate 112 via encryption. As a concrete example, authorization server 104 can digitally sign authorization certificate 112 using a private key and public key pair. That is, authorization server 104 can digitally sign and encrypt authorization certificate 112 using a private key. Once encrypted, only those who possess the public key can access the information contained in authorization certificate 112. Furthermore, because authorization certificate 112 is encrypted with a private key, if authorization certificate 112 can be successfully decrypted with the public key, a second system (e.g., a system associated with vehicle 108) can trust the authorization certificate.

[0025] In stages F and G, remote device 102 receives and sends authorization certificate 112. It should be noted that in some implementations, authorization certificate 112 may be received from authorization server 104 from a device other than or different from remote device 102. As an example, if diagnostic device 106 will eventually be connected to (i.e., communicatively coupled to) vehicle 108, authorization server 104 may send authorization certificate 112 to diagnostic device 106 (whether directly or via remote device 102). Alternatively, authorization server 104 may send authorization certificate 112 directly to vehicle 108. Wherever authorization server 104 sends authorization certificate 112, this sending will generally be referred to herein as directed to remote device 102. Remote device 102 (or another device that has already received authorization certificate 112) then forwards authorization certificate 112 to vehicle 108.

[0026] In phases H and I, vehicle 108 receives and authenticates authorization certificate 112. As previously described, in one embodiment, authorization server 104 digitally signs and encrypts authorization certificate 112 using a private key. In such an embodiment, vehicle 108 authenticates authorization certificate 112 via a public key. Once vehicle 108 has authenticated authorization certificate 112, vehicle 108 activates the vehicle communication system in phase J. Furthermore, in some embodiments, prior to activating the vehicle communication system, vehicle 108 may pre-configure one or more of its internal systems (e.g., ECU, gateway, etc.) for authentication and filtering operations, as per [reference to...]. Figure 2 More detailed description.

[0027] How vehicle 108 activates the communication system can depend on the type of vehicle communication system. For example, if the vehicle communication system is based on a wired connection, vehicle 108 activates the vehicle communication system by activating a wired port (e.g., an OBD port) of vehicle 108. As an example, vehicle 108 may include a vehicle access locker (VAL) that communicatively connects to devices to be connected to vehicle 108 (e.g., remote device 102 and / or diagnostic device 106) between the wired port and / or the wired port between the wired port and internal vehicle systems (e.g., [missing information]). Figure 3 (As illustrated in the example). By default, the VAL prevents communication from being transmitted to the wired port or from the wired port to the internal vehicle system. When vehicle 108 activates the vehicle communication system, vehicle 108 “opens” the VAL and allows communication to be transmitted between the device to be connected to vehicle 108 and the internal system of vehicle 108. As another example, if the vehicle communication system is based on a wireless connection, vehicle 108 can activate the vehicle communication system by enabling a wireless network. The wireless network can take any suitable form and operate via any suitable protocol (e.g., near-field communication, 802.11 standard, Zigbee, etc.). In one implementation, vehicle 108 enables the wireless network by generating a network for vehicle 108. For example, vehicle 108 can generate the vehicle's network by generating a Service Set Identifier (SSID) and password for the network. In such an implementation, network credentials (e.g., SSID and / or password) can be shared with the device to be connected to vehicle 108. It should also be noted that in some embodiments, the vehicle communication system may include both an activated wired channel and an activated wireless channel. Regardless of whether the vehicle communication system is based on a wired connection, a wireless connection, or a combination of both, because the vehicle communication system is not activated until the vehicle 108 is certified with authorization certificate 112, communication between external devices (e.g., remote device 102, diagnostic device 106, etc.) and the vehicle 108 is prevented or at least restricted before certification. In other words, the vehicle 108 has a zero-trust relationship with external devices (e.g., remote device 102 and / or diagnostic device 106) until the vehicle 108 has been certified with authorization certificate 112.

[0028] It should be noted that in some embodiments, the authorization process does not end once the remote device 102 (or another device) connects (i.e., communicatively couples) to the vehicle 108. In such embodiments, the vehicle 108 and / or the authorization server 104 can monitor communication between the vehicle 108 and the connected device. For example, once the vehicle communication system is activated, the vehicle 108 can verify that the device connected to the vehicle 108 is the device intended to be connected to the vehicle 108. This can be done in a variety of ways. As an example, the vehicle 108 can verify that the device's identifier (e.g., MAC address, IP address, etc.) matches the information in the authorization certificate 112. As another example, if the authorization certificate 112 includes time information associated with the connection, the vehicle 108 can verify that the timing of the connection is consistent with the time information in the authorization certificate 112. Further, in some embodiments, this monitoring can continue during the connection process. For example, communication can be monitored and recorded. If a connection or action outside the scope of the authorization certificate 112 is detected, communication can be filtered and / or blocked, and in some cases, the vehicle communication system can be deactivated. In such embodiments, the vehicle 108 can send communication records to the authorization server 104.

[0029] Figure 1 The discussion provides an overview of the systems and example operations that allow connection to vehicles, while Figure 2 and Figure 3 The discussion provides additional details about such systems.

[0030] Figure 2 This is a block diagram of a system 200 for allowing connection to vehicle 204 according to some embodiments. System 200 generally includes vehicle 204, authorization server 206, network 208, remote device 210, and diagnostic device 212. It should be noted that in some embodiments, remote device 210 and diagnostic device 212 may be a single device. Vehicle 204, authorization server 206, remote device 210, and diagnostic device 212 are communicatively coupled via network 208. Therefore, network 208 can take any suitable form (e.g., local area network (LAN), wide area network (WAN) (such as the Internet), wireless wide area network (WWAN), etc.) and includes wired and / or wireless links.

[0031] Remote device 210 is typically configured to generate a connection request. The connection request requests a connection between vehicle 204 and remote device 210 and / or diagnostic device 212. This connection can be used for diagnostic purposes, repair purposes, data collection purposes, data transfer purposes, software update purposes, etc. The connection request may include any suitable information, such as vehicle identifiers (e.g., Vehicle Identification Number (VIN)), the brand of vehicle 204, the model of vehicle 204, the trim level of vehicle 204, diagnostic information of vehicle 204, the type of connection requested (e.g., wired, wireless, etc.), the type of service to be performed, an indication of the vehicle system to be accessed by remote device 210, the duration of the requested access, the time of the requested access, the identity of the individual receiving the connection request, the type of facility receiving the connection request, information associated with remote device 210, information associated with devices to be communicatively coupled to vehicle 204, etc. Remote device 210 sends the connection request to authorization server 206 via network 208.

[0032] Authorization server 206 is typically configured to verify connection requests and generate authorization certificates. That is, authorization server 206 verifies that the communication request is a legitimate connection request and, in response, generates an authorization certificate. Authorization server 206 can verify connection requests in any suitable manner. For example, authorization server 206 can verify connection requests via a PKI system, encryption, account-based systems, etc. Regarding encryption, in one implementation, remote device 210 can digitally sign the connection request. Assuming remote device 210 is a trusted device, decryption performed by authorization server 206 can verify the identity of remote device 210. Regarding account-based systems, the connection request may include credentials associated with the user of remote device 210 and / or facilities associated with the user and / or remote device 210. Credentials may include, for example, a username and password. In such an implementation, authorization server 206 can verify the connection request by verifying the credentials included in the connection request. Further, such a system may include two-factor authentication between remote device 210 and authorization server 206. Additionally, in some implementations, the connection request may include operational details about the user account. For example, a connection request may include instructions for an operating role, such as wireless connection, infotainment system maintenance, battery maintenance, engine maintenance, etc. In such an implementation, the authorization server 206 can not only verify credentials but also verify that the specified user is correctly authorized based on operational details. If the authorization server 206 cannot verify the connection request (e.g., incorrect credentials, connection request not properly encrypted, etc.), the authorization server 206 may actively or passively reject the connection request.

[0033] Once the authorization server 206 has verified the connection request, it contains operation authorization information for each request and the registered user account. The authorization server verifies whether the requested operation is correctly authorized for the account. Upon verification, the authorization server 206 generates an authorization certificate. In some embodiments, when verifying a connection request, the authorization server 206 authorizes the connection request information and any user credentials (if applicable). Because the authorization certificate contains the authorized requested operation, it confirms to vehicle 204 that the connection request has been verified and the operation in the certificate has been authorized. In one embodiment, the authorization server 206 digitally signs and encrypts the authorization certificate. For example, the authorization server 206 may digitally sign and encrypt the authorization certificate using a private key.

[0034] Vehicle 204 can be any suitable type (e.g., commercial vehicle or bus, ship, aircraft, etc.) and includes many systems (e.g., electrical systems, drivetrain, infotainment systems, climate control systems, safety systems, communication systems, sensor systems, autonomous driving systems, engine control systems, etc.). However, for the sake of clarity, vehicle 204 is shown only as including control system 202 and vehicle communication system 214.

[0035] Control system 202 may include a fixed-purpose hardwired hardware platform (including, but not limited to, application-specific integrated circuits (ASICs) (which are integrated circuits designed specifically for a particular purpose rather than intended for general use), field-programmable gate arrays (FPGAs), etc.), or may include a partially or fully programmable hardware platform (including, but not limited to, microcontrollers, microprocessors, etc.). These architectural options for such a structure are well known and understood in the art and need not be further described herein. Control system 202 is configured to (e.g., through corresponding programming that will be well understood by those skilled in the art) perform one or more of the steps, actions, and / or functions described herein.

[0036] Alternatively, the control system 202 can be operatively coupled to the memory. The memory can be integrated with the control system 202 or physically ( wholly or partially) separated from the control system 202 as needed. The memory can also be local to the control system 202 (where, for example, both share a common circuit board, chassis, power supply, and / or housing), or it can be partially or completely remote from the control system 202 (where, for example, the memory is physically located in another facility, another metropolitan area, or even another country compared to the control system 202).

[0037] The memory can be used, for example, to non-transiently store computer instructions that, when executed by the control system 202, cause the control system 202 to behave as described herein. As used herein, “non-transient” will be understood to mean the non-transient state of the stored content (and therefore excludes the case where the stored content constitutes only a signal or wave), rather than the volatility of the storage medium itself, and therefore includes both non-volatile memory (such as read-only memory (ROM)) and volatile memory (such as erasable programmable read-only memory (EPROM)).

[0038] Control system 202 is typically configured to authenticate authorization certificates and activate the vehicle communication system, as well as perform other tasks associated with vehicle 204. Regarding the authentication of authorization certificates, control system 202 can employ any suitable mechanism based on the type of authorization certificate. Continuing with the example provided above of authorization server 206 digitally signing and encrypting authorization certificates, control system 202 can authenticate authorization certificates via the public key in a public / private key pair. If control system 202 can correctly decrypt the authorization certificate with the public key, it indicates that the authorization certificate was signed and encrypted with the correct private key, and therefore originated from authorization server 206, and has not been tampered with or otherwise altered. Furthermore, because the authorization certificate originated from authorization server 206 and the authorization server verified the connection request, control system 202 can assume that the connection request is legitimate.

[0039] Furthermore, in some embodiments, after the control system 202 authenticates the authorization certificate, but before the control system 202 activates the vehicle communication system 214, the control system 202 may configure the internal vehicle system for subsequent communication. For example, the control system 202 may transmit information associated with a connection request to one or more ECUs, gateways, etc. of the vehicle 204. This information may include, for example, an indication of the system to be accessed and an indication of the device that will access the system. The one or more ECUs, gateways, etc. of the vehicle 204 may then monitor the communication and allow only authorized operations to pass through (e.g., while rejecting unauthorized communication). This operation monitoring may be implemented as operation rules or filtering procedures (such as eBPF, etc.). Thus, the operation may be identified by a signature (such as a MAC address and / or IP address) and other message or protocol identifiers associated with the authorized operation. During configuration and during operation access, the control system 202 verifies each approved operation request. During this monitoring, if the control system 202 detects an incident, unauthorized operation, and / or unauthorized access, the control system 202 may revoke the authorization, disable communication and access, and report the incident to the authorization server 206.

[0040] When applicable, the functionality of control system 202 can be distributed among one or more internal vehicle ECUs and gateways. The functionality of control system 202 can be implemented in firmware such as an FPGA, or in a software stack such as a CAN and / or TCP / IP stack, where operational and signature details can be checked. Control system 202 is highly dynamically configurable and can update the operational rules used for monitoring during runtime to adapt to modern vehicle environments.

[0041] Once the control system 202 authenticates the authorization certificate, it activates the vehicle communication system 214. The vehicle communication system 214 can be based on a wired and / or wireless connection. For example, in the case of a wired system, the vehicle may include a physical port (e.g., an OBD port). The control system 202 may activate the physical port physically and / or electrically. As an example of physical activation, the physical port may be blocked in some way so that a device cannot connect to it. For example, the physical port may be blocked by a door or other structure that prevents connection to the physical port. In this implementation, when the control system 202 activates the physical port, it may move the door or other structure so that access to the physical port is no longer blocked. Alternatively or additionally, the control system 202 may activate the physical port electronically. In such an implementation, the vehicle 204 may include a VAL. The VAL may be communicatively located before or between the physical port and the vehicle's internal systems. By default, the VAL may block or otherwise prevent communication through and / or from the physical port to the vehicle's internal systems. Once the control system 202 activates the physical port, VAL allows communication to and / or from the physical port to the vehicle's internal systems. Regarding the wireless system, the control system 202 can activate the vehicle communication system by enabling a wireless network associated with and / or broadcast by the vehicle 204. For example, the control system 202 can enable the wireless network by generating a wireless network, allowing external connections to the wireless network, or making the wireless network visible to external devices. As an example, the control system 202 can enable the wireless network by generating the SSID and password for the wireless network.

[0042] In some embodiments, the control system 202 may also control and / or restrict access to the internal systems of the vehicle 204 based on a connection request. For example, assuming the connection request includes information from which a specific vehicle system can be identified, the control system 202 may identify one or more vehicle systems that require access. For example, the connection request may explicitly or implicitly include this information, or the control system 202 may infer this information based on information about the requested connection and / or the service to be performed. In such an implementation, the control system 202 may activate the vehicle communication system such that only those vehicle systems that require access are accessible. For example, if the connection request is to perform a software update on the infotainment system of the vehicle 204, the control system 202 may enable communication only with the vehicle systems associated with the infotainment system while blocking other communications (e.g., communications with the LiDAR system associated with the autonomous driving features of the vehicle 204).

[0043] As previously described, system 200 includes a diagnostic device 212, and in some embodiments, the diagnostic device 212 and the remote device 210 may be the same device. The diagnostic device 212 is typically a device connected to the vehicle communication system 214. The diagnostic device 212 can receive data from the vehicle's internal systems via the vehicle communication system 214 and may send data to the vehicle's internal systems. Therefore, the diagnostic device 212 can receive diagnostic information from vehicle 204 and / or send data to vehicle 204 to provide software updates, change operating parameters, clear codes, etc.

[0044] Figure 3 According to some implementation methods, including regarding Figure 2 A block diagram of an example implementation of a system 300 for allowing connection to a vehicle, with additional details provided. System 300 typically includes a remote / diagnostic device (hardwired) 302, a remote / diagnostic device (wireless) 304, a vehicle 310, an authorization server 306, and a database 308. Although the remote / diagnostic device (hardwired) 302 and the remote / diagnostic device (wireless) 304... Figure 3In the examples depicted, they are portrayed as separate components, but it should be noted that the remote / diagnostic device (hardwired) 302 and the remote / diagnostic device (wireless) 304 can be the same component. Furthermore, although the remote / diagnostic device (hardwired) 302 and the remote / diagnostic device (wireless) 304 are labeled as "remote / diagnostic" devices, it should be noted that these boxes can represent any number of devices with various purposes. That is, the remote / diagnostic device (hardwired) 302 and the remote / diagnostic device (wireless) 304 simply represent devices that seek communicatively coupled (i.e., "connected") to the vehicle 310 for any purpose requiring or preferably establishing communication with the vehicle 310. For ease of discussion, both the remote / diagnostic device (hardwired) 302 and the remote / diagnostic device (wireless) 304 are generally referred to as "remote devices" unless the specific function of one of the remote / diagnostic devices (hardwired) 302 and the remote / diagnostic device (wireless) 304 is being discussed.

[0045] Vehicle 310 includes a wide variety of components, and Figure 3 The components shown are merely examples of components included in vehicle 310. That is, vehicle 310 may include more than... Figure 3 The components depicted in the text include more, fewer, and / or different components. For example... Figure 3 The vehicle 310 depicted includes a port 312 (e.g., an on-board diagnostic port), one or more vehicle access lockers (“VAL”) 314, multiple gateways (e.g., CAN ECU gateway 316 and DOIP gateway 320), a control system 338, an internal network 322, and multiple electronic control units (ECUs), such as a CAN ECU 318, an IP ECU AD 326, an IP ECU CD 330, and an IP ECU area 334.

[0046] As previously discussed, the remote device generates a connection request and sends it to the authorization server 306. The authorization server 306 verifies the connection request. For example, the connection request may include credentials associated with the remote device and / or the user requesting to connect to vehicle 310. In such an implementation, the authorization server 306 may verify credentials in database 308. Once the authorization server 306 has verified the connection request, it generates an authorization certificate. The authorization server 306 digitally signs and encrypts the authorization certificate and sends it to vehicle 310 and / or the remote device. The authorization certificate is received by vehicle 310 via control system 338. Control system 338 typically authenticates the authorization certificate and may therefore be referred to as a "vehicle authorization server" and / or include the functionality of a "vehicle authorization server."

[0047] Furthermore, as described above, in some embodiments, after vehicle 310 receives the authorization certificate, vehicle 310 may pre-configure its internal systems for communication. For example, the authorization certificate may include operational details, such as instructions on which devices(s) to connect to vehicle 310, instructions on which internal systems will be accessed, etc. Vehicle 310 may configure its internal systems, for example, by initiating a monitoring protocol by its internal vehicle system. The internal vehicle system can then monitor communication and / or connectivity during operation to ensure that the communication and / or connectivity are consistent with the operational authorization outcome.

[0048] As previously discussed, in some implementations, there is no trust between the vehicle and the remote device until the vehicle (e.g., control system 338) authenticates the authorization certificate. That is, vehicle 310 will not accept (e.g., will block) communication from the remote device unless and until the authorization certificate is authenticated. Once vehicle 310 authenticates the authorization certificate (e.g., by decrypting the authorization certificate), vehicle 310 can activate the vehicle communication system. Generally, the vehicle communication system can be a wired communication system and / or a wireless communication system (e.g., port 312 and wireless network 336, respectively), or it can be associated with both wired and / or wireless communication systems.

[0049] Regarding the wired communication system, vehicle 310 may include one or more VALs 314. A VAL 314 may be a hardware and / or software component positioned between a remote device and an internal vehicle system (e.g., a gateway, ECU, internal network, etc.). A VAL 314 typically has inputs and outputs in both directions. From the outside of the vehicle to the inside, the inputs are configured to receive communication from the remote device, and the outputs are configured to transmit communication from the remote device to the internal system of vehicle 310. When disabled, a VAL 314 prevents communication from passing through it. As an example, in the disabled state, the inputs and outputs of a VAL 314 can be decoupled in both directions (e.g., via a switch), so that there is no communication channel between the inputs and outputs of the VAL 314. When enabled, a VAL 314 allows communication to pass between the inputs and outputs.

[0050] In embodiments including a single VAL 314, VAL 314 can control the transmission of communication from a remote device to some or all of the internal vehicle systems. That is, a single VAL 314 can allow communication to pass from its input to its output connected to various internal vehicle systems, or be disabled so that such a communication channel does not exist.

[0051] In implementations that include multiple VAL 314 (e.g.) Figure 3In the system 300 depicted, each VAL 314 can be specific to one or more of the internal vehicle systems. For example, as Figure 3 As depicted, the first VAL in VAL 314 is associated with CANECU gateway 316, the second VAL in VAL 314 is associated with DOIP gateway 320, and the third VAL in VAL 314 is associated with DOIP ECU 328. Therefore, communication exists between VAL 314 control port 312 and each internal vehicle system. In some embodiments, the connection request may include information (whether explicit or implicit) allowing control system 338 to determine which internal vehicle system a remote device needs to access. In such embodiments, control system 338 may enable only the required VAL 314, thereby preventing remote devices from accessing internal vehicle systems that are not needed. Additionally or alternatively, authorization server 306 may use the information in the connection request to identify the internal vehicle system that a remote device needs to access. In such embodiments, authorization server 306 may include an indication of the internal vehicle system that needs access. Similarly, the connection request may explicitly or implicitly specify whether a wired or wireless connection is requested. In such embodiments, control system 338 may activate the appropriate vehicle communication system.

[0052] Furthermore, in some implementations, as described, when the remote device communicates with the vehicle communication system (i.e., during "runtime"), the control system 338 can monitor the connection between the remote device and the vehicle communication system and / or the internal vehicle system. If the communication between the remote device and the vehicle communication system is outside the scope of explicit, implicit, or implicit communication based on information in the connection request (including, for example, operational details), the vehicle 310 can revoke the remote device's permissions. For example, the vehicle 310 can revoke permissions by disabling the vehicle communication system. This revocation can be based on any suitable criteria, such as the timing of the connection, the duration of the connection, the internal vehicle system accessed, the internal vehicle system attempted to be accessed, and the remote device's identifier being different from that listed in the connection request (e.g., MAC address, IP address, etc.).

[0053] The control system 338 can also monitor operational details between remote devices and the internal vehicle system based on operational authorizations in the authorization certificate (such as destination ECU identifier, IP address, operation and / or message type and identifier, etc.). The control system 338 can reject any unauthorized operation requests, revoke authorizations under specific circumstances, etc. In some embodiments, once configured and activated, the control system 338 monitors operations throughout the access period and deactivates access when authorization expires or should be revoked. Further, in some embodiments, the authorization certificate can be updated, and therefore the control system 338 can adjust monitoring at runtime based on requests from the authorization server 306.

[0054] Figure 2 and Figure 3 The discussion provides additional details about the systems used to allow connection to vehicles, while Figures 4 to 6 The discussion provides additional details about example operations of such a system.

[0055] Figures 4 to 6 This is a flowchart depicting example operations for allowing connection to a vehicle, according to some implementations. It should be noted that... Figure 4 The flowchart depicted includes additional example operations, represented by A and B, which are respectively in Figure 5 and Figure 6 The process will proceed in box 402.

[0056] At box 402, a connection request is received. For example, a connection request can be received from a remote device at an authorization server. The connection request typically requests a connection to the vehicle and may include any suitable information. At a higher level, the connection request includes information identifying the requesting party (e.g., the user requesting the connection, the device requesting the connection, etc.) and the vehicle. Optionally, in an implementation that generates a vehicle owner notification, the process... Figure 5 The process continues at box 502, as indicated in A. In the implementation where the owner prompt is not generated, the process continues at box 404.

[0057] At box 502, a vehicle owner alert is generated. For example, an authorization server can generate a vehicle owner alert. In some implementations, the authorization server generates a vehicle owner alert in response to receiving a connection request. Typically, a vehicle owner alert is an alert generated for a user of the vehicle (e.g., the vehicle owner, lessee, lessor, operator, etc.). The vehicle owner alert may include any suitable information. For example, the vehicle owner alert may include a vehicle identifier, the brand of the vehicle, the diagnostic information of the vehicle, the type of connection requested, the type of service to be performed, an indication of the vehicle system to be accessed by the remote device, the duration of the requested access, the time of the requested access, the identity of the individual from whom the connection request is received, the type of facility from which the connection request is received, information associated with the remote device, information associated with the device to be communicatively coupled to the vehicle, etc. The process continues at box 504.

[0058] At box 504, an owner notification is sent. For example, the authorization server may send the owner notification to the user device associated with the vehicle's user. The authorization server sends the owner notification over a network via any suitable protocol. For example, the owner notification may be sent as a Simple Messaging Service (SMS) message, a Multimedia Messaging Service (MMS) message, email, telephone call, etc. The vehicle's user can view the owner notification via a user device (e.g., cellular phone, smartphone, laptop, desktop computer, tablet, smartwatch, wearable device, etc.). The vehicle's user can then approve or decline the notification or may request more information about it. The process continues at box 506.

[0059] At box 506, assuming the vehicle user approves the owner prompt or in an implementation where approval is not required, the authorization server receives approval for the owner prompt from the user device associated with the vehicle user (or communication is lacking). The process is as follows: Figure 4 Continue at box 404.

[0060] At box 404, the connection request is verified. For example, an authorization server can verify the connection request. The authorization server can verify the connection request in any suitable manner. For example, the authorization server can verify the connection request via encryption, an account-based system, etc. Regarding encryption, in one implementation, the remote device can digitally sign the connection request. Assuming the remote device is a trusted device, decryption performed by the authorization server can verify the identity of the remote device. Regarding an account-based system, the connection request may include credentials associated with the user of the remote device and / or the facility associated with the user and / or the remote device. Credentials may include, for example, a username and password. In such an implementation, the authorization server can verify the connection request by verifying the credentials included in the connection request. Further, such a system may include two-factor authentication between the remote device and the authorization server. If the authorization server cannot verify the connection request (e.g., incorrect credentials, the connection request not being properly encrypted, etc.), the authorization server can actively or passively reject the connection request. Furthermore, in some embodiments, the authorization server can verify that the operation requested by the requester is permissible. This verification can be specific to the requester (e.g., different requesters may have authorized access rights to different internal vehicle systems due to their different user roles). The process continues at box 406.

[0061] At box 406, an authorization certificate is generated. For example, an authorization server can generate an authorization certificate. The authorization certificate confirms to the vehicle that the connection request has been verified and is therefore authorized. In one implementation, the authorization server digitally signs and encrypts the authorization certificate. For example, the authorization server can digitally sign and encrypt the authorization certificate using a private key. The authorization certificate may include any suitable information, such as some or all of the information included in the connection request, as well as information added by the authorization server (e.g., the internal vehicle systems authorized for access). The process continues at box 408.

[0062] At box 408, send the authorization certificate. For example, the authorization server can send the authorization certificate. The process continues at box 410.

[0063] At box 410, the authorization certificate is received. The authorization certificate can be received by any suitable device. For example, a remote device or diagnostic device can receive the authorization certificate from the authorization server. The process continues at box 412.

[0064] At box 412, the authorization certificate is sent. For example, a remote device and / or diagnostic device can send an authorization certificate. The authorization certificate is sent to the vehicle. The process continues at box 414.

[0065] At box 414, the authorization certificate is authenticated. For example, a vehicle can authenticate an authorization certificate. The vehicle can employ any suitable mechanism to authenticate the authorization certificate based on its type. Continuing with the example provided above of the authorization server digitally signing and encrypting the authorization certificate, the vehicle can authenticate the authorization certificate via the public key in the public / private key pair. If the vehicle can correctly decrypt the authorization certificate with the public key, it indicates that the authorization certificate was signed and encrypted with the correct private key, and therefore originated from the authorization server, and has not been tampered with or otherwise altered. Furthermore, because the authorization certificate originated from the authorization server and the authorization server verified the connection request, the vehicle can assume that the connection request is legitimate. The process continues at box 416.

[0066] At box 416, the vehicle communication system is activated. For example, the vehicle may activate the vehicle communication system. The vehicle activates the vehicle communication system in response to authentication of an authorization certificate. The vehicle communication system may be a wired communication system and / or a wireless communication system. In the case of a wired communication system, the vehicle may activate the vehicle communication system by enabling a physical port of the vehicle. In the case of a wireless communication system, the vehicle may activate the vehicle communication system by enabling a wireless network associated with or broadcast by the vehicle. Furthermore, as previously described, in some embodiments, the vehicle configures its internal vehicle systems to receive communication before the vehicle communication system is activated. Optionally, in embodiments where the vehicle communication system can be deactivated (e.g., during runtime monitoring), the process continues at box 602, as indicated by B.

[0067] At box 602, it is determined that the scope of the connection is inconsistent with the connection request. For example, the vehicle may determine that the scope of the connection is inconsistent with the connection request. As previously discussed, the connection request may include information associated with which internal vehicle systems to be accessed, the duration of the access, the necessary type of communication, etc. Similarly, this information may be passed to the vehicle (e.g., in an authorization certificate). In such an implementation, the vehicle may monitor the connectivity between the vehicle and remote devices and / or diagnostic devices. The scope of the connection is inconsistent with the connection request when an external device (e.g., a remote device, diagnostic device, etc.) attempts to connect to internal vehicle systems other than those specified in the connection request, sends data other than those specified in the connection request, or connects for a time period other than those specified in the connection request. As previously mentioned, this monitoring can be performed during runtime. The process continues at box 604.

[0068] At box 604, the vehicle communication system is disabled. For example, the vehicle may disable its vehicle communication system. The vehicle disables the vehicle communication system in response to a discrepancy between the determined connectivity range and the connectivity request.

[0069] Figures 4 to 6The discussion provides additional details regarding example operations of systems that allow connection to vehicles, while Figure 7 The discussion provides additional details about specific components of this system.

[0070] Figure 7 It is based on some embodiments that can be used for implementation Figure 2 and / or Figure 3 This is a block diagram of any component, circuit, circuit system, system, function, device, process, or apparatus of any system or device mentioned above or below, or a part of such circuit, circuit system, function, system, device, process, or apparatus. The circuits, circuit systems, systems, devices, processes, methods, techniques, functions, services, servers, sources, etc., described herein can be used, implemented, and / or operated on many different types of devices and / or systems. For example, System 700 can be used to implement some or all of a control system, authorization server, remote device, user equipment, diagnostic device, and / or other such component, circuit system, function, and / or apparatus. However, it is certainly not necessary to use System 700 or any part thereof.

[0071] For example, system 700 may include a processor (e.g., a control system) 712, memory 714, and one or more communication links, paths, buses, etc. 718. Some embodiments may include one or more user interfaces 716, and / or one or more internal and / or external power supplies or power outlets 740. Processor 712 may be implemented by one or more processors, microprocessors, central processing units, logic, local digital storage, firmware, software, and / or other control hardware and / or software, and may be used to perform or assist in performing the steps of the processes, methods, functions, and techniques described herein, and to control various communications, decisions, programs, content, lists, services, interfaces, logging, reporting, etc. Further, in some embodiments, processor 712 may be part of a control system and / or a control system 710, which may be implemented by one or more processors accessing one or more memories 714, which may store commands, instructions, codes, etc., implemented by the control system and / or processor to perform the intended functions. In some applications, the control system and / or memory may be distributed across a communication network (e.g., LAN, WAN, Internet) providing distributed and / or redundant processing and functionality. Similarly, system 700 can be used to implement one or more or some of the above or below: components, circuits, systems, processes, etc.

[0072] User interface 716 allows users to interact with system 700 and receive information through the system. In some instances, user interface 716 includes display device 722 and / or one or more user input devices 724, such as buttons, touchscreens, trackballs, keyboards, mice, etc., which may be part of or wired or wirelessly coupled to system 700. In some implementations, display device 722 may project a barcode onto the vehicle's windshield, and when scanned by a user's smart device, the barcode may redirect the user to enter user credentials and / or account information associated with the authorization server via user input device 724. In this way, users can remotely interact with the authorization server as described above to generate and send connection requests, receive and send authorization certificates, and obtain physical access to the vehicle (e.g., the ability to open doors and enter the vehicle) and activate access to the vehicle's internal systems. Typically, system 700 also includes one or more communication interfaces, ports, transceivers 720, etc., which allow system 700 to communicate via a communication bus, a distributed computer and / or communication network (e.g., a local area network (LAN), a wide area network (WAN) (such as the Internet), etc.), a communication link 718, other networks or communication channels with other devices and / or other such communications, or a combination of two or more such communication methods. Further, transceiver 720 can be configured for wired, wireless, fiber optic cable, satellite, or other such communication configurations, or a combination of two or more such communications. Some embodiments include an I / O interface comprising one or more input / output (I / O) ports 734 that allow one or more devices to couple to system 700. I / O ports 734 can be substantially any relevant port or combination of ports, such as, but not limited to, USB, Ethernet, or other such ports. The I / O interface can be configured to allow wired and / or wireless communication coupling to external components. For example, the I / O interface can provide wired and / or wireless communication (e.g., Wi-Fi, Bluetooth, cellular, RF, and / or other such wireless communication), and in some instances may include any known wired and / or wireless interface device, circuit and / or connection device, such as, but not limited to, one or more transmitters, receivers, transceivers 720, or combinations of two or more such devices.

[0073] In some embodiments, the system may include one or more sensors 726 to provide information to the system and / or transmit sensor information to another component (such as a central control system, vehicle, etc.). Sensor 726 may include virtually any relevant sensor, such as distance measurement sensors (e.g., optical units, sound / ultrasonic units, etc.), optical-based scanning sensors for sensing and reading optical patterns (e.g., barcodes), radio frequency identification (RFID) tag reader sensors capable of reading RFID tags near the sensor, imaging systems and / or cameras, other such sensors, or combinations of two or more such sensor systems. The foregoing examples are intended to be illustrative and not to provide an exhaustive list of all possible sensors. Rather, it should be understood that these teachings will be adapted to sensing any of the wide variety of situations in a given application environment.

[0074] System 700 includes an example of a control and / or processor-based system having a processor 712. Similarly, the processor 712 can be implemented by one or more processors, controllers, central processing units, logic, software, etc. Furthermore, in some embodiments, the processor 712 can provide multiprocessor functionality.

[0075] The memory 714, accessible by the processor 712, typically includes one or more processor-readable and / or computer-readable media accessible at least by the control system, and may include volatile and / or non-volatile media, such as RAM, ROM, EEPROM, flash memory, and / or other memory technologies. Further, the memory 714 is shown as being internal to the control system 710; however, the memory 714 may be internal memory, external memory, or a combination of internal and external memory. Similarly, some or all of the memory 714 may be internal memory, external memory, or a combination of internal and external memory of the processor 712. External memory can be substantially any relevant memory, such as, but not limited to, one or more of solid-state storage devices or drives, hard disk drives, Universal Serial Bus (USB) sticks or drives, Flash Secure Digital (SD) cards, other memory cards, and other such memories or combinations of two or more such memories, and some or all of the memory 714 may be distributed across multiple locations on a computer network. The memory 714 can store code, software, executable files, scripts, data, content, lists, programming, programs, logs or historical data, user information, customer information, product information, etc. Although Figure 7 The various components are shown to be coupled together via a bus, but it should be understood that the various components can actually be directly coupled to the control system and / or one or more other components.

[0076] Those skilled in the art will recognize that various other modifications, alterations, and combinations can be made with respect to the above embodiments without departing from the scope of this disclosure, and such modifications, alterations, and combinations should be considered within the scope of the inventive concept.

[0077] The various aspects of the above embodiments can be used individually, in combination, or in various arrangements not specifically discussed in the foregoing embodiments. Therefore, the application of this specification is not limited to the details and arrangements of the components set forth in the foregoing description or shown in the drawings. For example, an aspect described in one embodiment can be combined in any way with aspects described in other embodiments.

[0078] Having described several aspects of at least one embodiment, it should be understood that various changes, modifications, and improvements will readily occur to those skilled in the art. Such changes, modifications, and improvements are intended to be part of this disclosure and are intended to fall within the spirit and scope of the principles described herein. Therefore, the foregoing description and figures are merely illustrative.

Claims

1. A method for allowing connection to a vehicle, the method comprising: The authorization server receives a connection request for the vehicle from a remote device. The connection request is verified by the authorization server; In response to the connection verification request, the authorization server generates an authorization certificate; The authorization certificate is sent by the authorization server; The authorization certificate is received by the vehicle. The vehicle authenticates the authorization certificate; as well as In response to the authentication of the authorization certificate, the vehicle communication system is activated by the vehicle.

2. The method as described in claim 1, wherein, The connection request includes information associated with the connection request, wherein the information associated with the connection request includes a vehicle identifier, the brand of the vehicle, the model of the vehicle, the trim of the vehicle, the diagnostic information of the vehicle, the type of connection requested, the type of service and operation to be performed, an indication of the vehicle system to be accessed by the remote device, the duration of the requested access, the time of the requested access, the identity of the individual from which the connection request is received, the type of facility from which the connection request is received, information associated with the remote device, information associated with the device to be communicatively coupled to the vehicle, or any combination thereof.

3. The method of claim 2, further comprising: The determination of the range of connection to the vehicle based on the information associated with the connection request is inconsistent with the information associated with the connection request; as well as In response to a discrepancy between the information determining the extent of the connection to the vehicle and the information associated with the connection request, the vehicle communication system is deactivated by the vehicle.

4. The method of claim 1, further comprising: The authorization certificate is encrypted by the authorization server, wherein the authentication of the authorization certificate includes decrypting the authorization certificate.

5. The method of claim 1, wherein, The verification of the connection request includes verifying the operational details included in the connection request, and the method further includes: In response to the verification of the connection request, the authorization server includes an operation authorization result in the authorization certificate, wherein the operation authorization result indicates the permitted operation roles associated with the connection request.

6. The method of claim 5, further comprising: The connection to the vehicle is determined to be outside the scope of the operation authorization result; as well as The vehicle communication system is deactivated.

7. The method of claim 1, wherein, The vehicle communication system is an on-board diagnostic system, and activating the vehicle communication system includes activating the on-board diagnostic port of the vehicle.

8. The method of claim 1, further comprising: In response to receiving the connection request for the vehicle, the authorization server generates a vehicle owner notification; The authorization server sends the vehicle owner notification to the user device associated with the vehicle owner; Receive approval from the user equipment for the prompt to the vehicle owner; The activation of the vehicle communication system is also performed in response to the approval prompted by the vehicle owner.

9. The method of claim 8, wherein, The vehicle owner notification includes the vehicle identifier, the vehicle's brand, the vehicle's diagnostic information, the type of connection requested, the type of service and operation to be performed, an indication of the vehicle system the remote device wants to access, the duration of the requested access, the time of the requested access, the identity of the individual receiving the connection request, the type of facility receiving the connection request, information associated with the remote device, information associated with the device to be communicatively coupled to the vehicle, or any combination thereof.

10. The method of claim 1, further comprising: The vehicle identifies the first vehicle system that needs to be accessed based on the authorization certificate; as well as Access to the first vehicle system is provided via the vehicle communication system.

11. A system for allowing connection to a vehicle, the system comprising: Authorization server, wherein the authorization server is configured as follows: Receive a connection request for the vehicle from a remote device; Verify the connection request; In response to the connection verification request, an authorization certificate is generated; and Send the authorization certificate; and The vehicle, wherein the vehicle is configured as follows: Authenticate the authorization certificate; and In response to the authentication of the authorization certificate, the vehicle communication system is activated.

12. The system of claim 11, wherein, The connection request includes information associated with the connection request, wherein the information associated with the connection request includes a vehicle identifier, the brand of the vehicle, the model of the vehicle, the trim of the vehicle, the diagnostic information of the vehicle, the type of connection requested, the type of service and operation to be performed, an indication of the vehicle system to be accessed by the remote device, the duration of the requested access, the time of the requested access, the identity of the individual from which the connection request is received, the type of facility from which the connection request is received, information associated with the remote device, information associated with the device to be communicatively coupled to the vehicle, or any combination thereof.

13. The system of claim 12, wherein, Provide the vehicle with the duration of the requested access, and wherein the vehicle is further configured to: The determination of the range of connection to the vehicle based on information associated with the connection request is inconsistent with the information associated with the connection request; and In response to a discrepancy between the information determining the extent of the connection to the vehicle and the information associated with the connection request, the vehicle communication system is deactivated.

14. The system of claim 11, wherein, The authorization server is also configured as follows: The authorization certificate is encrypted, and the vehicle authenticates the authorization certificate by decrypting it.

15. The system of claim 11, wherein, The authorization server verifies the connection request by verifying the operational details included in the connection request, and the authorization server is further configured to: In response to verifying the connection request, the authorization certificate includes an operation authorization result, wherein the operation authorization result indicates the permitted operation roles associated with the connection request.

16. The system of claim 15, wherein, The authorization server is also configured as follows: Determining that the connection to the vehicle is outside the scope of the operational authorization result; and The vehicle communication system is deactivated.

17. The system of claim 11, wherein, The vehicle communication system is an on-board diagnostic system, and activating the vehicle communication system includes activating the on-board diagnostic port of the vehicle.

18. The system of claim 11, wherein, The authorization server is also configured as follows: In response to receiving the connection request for the vehicle, a vehicle owner notification is generated; Send the vehicle owner notification to the user device associated with the vehicle owner; as well as Receive approval from the user equipment for the prompt to the vehicle owner; The vehicle communication system is also activated in response to the owner's approval prompt.

19. The system of claim 18, wherein, The vehicle owner notification includes the vehicle identifier, the vehicle's brand, the vehicle's diagnostic information, the type of connection requested, the type of service and operation to be performed, an indication of the vehicle system the remote device wants to access, the duration of the requested access, the time of the requested access, the identity of the individual receiving the connection request, the type of facility receiving the connection request, information associated with the remote device, information associated with the device to be communicatively coupled to the vehicle, or any combination thereof.

20. The system of claim 11, wherein, The vehicle is also configured to: Based on the authorization certificate, the first vehicle system requiring access is identified; and Access to the first vehicle system is provided via the vehicle communication system.

Images