System, method, and computer program product for dynamic vehicle communication

Abstract

The present disclosure provides systems, methods, and computer program products for dynamic vehicle communication. The present disclosure provides a system, method, and apparatus for automatically managing communications between vehicles. According to an embodiment, a system may include: a storage store storing computer executable instructions; and at least one processor communicatively connected to the storage, the at least one processor may be configured to execute instructions to: receive identification information of a target vehicle from a server; acquiring identification information of the nearby vehicle from the nearby vehicle; determining whether the identification information of the target vehicle is consistent with the identification information of nearby vehicles; and in response to a determination that the identification information of the target vehicle coincides with the identification information of the nearby vehicles, transmitting the current time and location to the server.

Description

Technical Field

[0001] Systems, methods, and computer programs consistent with exemplary embodiments of the present disclosure relate to vehicles, and more particularly, to communication between vehicles. Background Art

[0002] Modern vehicles can perform a wide range of complex functions such as the generation of telemetry data, the transmission and reception of data via the Internet, and similar functions. In order for the vehicle to perform the above functions, the vehicle is essentially connected to an upstream server.

[0003] Vehicle tracking is a crucial process for determining a vehicle's geographic location within this function. Vehicle tracking serves various purposes, including the collective management of service vehicles, emergency vehicles, and public transportation vehicles, as well as the tracking of suspicious or stolen vehicles. In related art, a vehicle's location is determined by having the vehicle periodically or irregularly report its location to a server during check-in.

[0004] Moreover, in this function, vehicle software management is an important process for receiving software updates and applying them to the vehicle. In the related art, the software updates of the vehicle can be received by having the server send the software updates directly to the vehicle.

[0005] Nevertheless, in the related art, the above-mentioned method for determining the location of a vehicle and receiving software updates may have at least the following disadvantages.

[0006] When a vehicle is older than a certain number of years, it may be unable to communicate with a server due to components of the vehicle no longer being supported by the cellular network. Relatedly, since the vehicle's location is determined when the vehicle reports its location to the server, and software updates are received from the server, when the vehicle is older than a certain number of years and no longer able to communicate with the server, the server may be unable to determine the location and provide software updates to the vehicle. For example, in the case of a vehicle equipped with a 3G (3rd Generation) modem, the cellular network may no longer support or listen to the signal from the 3G modem, and the vehicle may be unable to communicate with the server.

[0007] Therefore, a need exists for a system that can locate and identify a vehicle with aged hardware that is unable to communicate with a server and that can assist the vehicle in receiving software updates. Summary of the Invention

[0008] Exemplary embodiments of the present disclosure automatically manage communications between vehicles. Thus, exemplary embodiments of the present disclosure can locate a vehicle with aged hardware that is unable to communicate with a server and assist the vehicle in receiving software updates.

[0009] According to an embodiment, a system is provided. The system may include: a storage device storing computer-executable instructions; and at least one processor communicatively connected to the storage device, wherein the at least one processor may be configured to execute the instructions to: receive identification information of a target vehicle from a server; obtain identification information of nearby vehicles from nearby vehicles; determine whether the identification information of the target vehicle is consistent with the identification information of the nearby vehicles; and, in response to a determination that the identification information of the target vehicle is consistent with the identification information of the nearby vehicles, transmit a current time and location to the server.

[0010] According to an embodiment, at least one processor may further be configured to execute instructions to: receive a list from nearby vehicles; in response to a determination that the identification information of the target vehicle is inconsistent with the identification information of nearby vehicles, determine whether the received list contains the identification information of the target vehicle; and in response to a determination that the received list contains the identification information of the target vehicle, send the current time and location to the server.

[0011] According to an embodiment, the received list may include a hashed list containing one or more International Mobile Equipment Identity (IMEI) codes identified by nearby vehicles.

[0012] According to an embodiment, the at least one processor may be further configured to execute instructions to record the acquired identification information of nearby vehicles in a list.

[0013] According to an embodiment, the nearby vehicle may be a first nearby vehicle, and the at least one processor may be configured to execute instructions to transmit the list to a second nearby vehicle.

[0014] According to an embodiment, the identification information of the target vehicle and the identification information of the nearby vehicles may include International Mobile Equipment Identity (IMEI).

[0015] According to an embodiment, identification information of a nearby vehicle may be received via shortwave broadcasting, direct communication between digital communication modules (DCMs), or Bluetooth (registered trademark).

[0016] According to an embodiment, a method is provided. The method may include: receiving identification information of a target vehicle from a server; obtaining identification information of nearby vehicles from nearby vehicles; determining whether the identification information of the target vehicle is consistent with the identification information of the nearby vehicles; and, in response to determining that the identification information of the target vehicle is consistent with the identification information of the nearby vehicles, transmitting a current time and location to the server.

[0017] According to an embodiment, the method may also include: receiving a list from nearby vehicles; in response to a determination that the identification information of the target vehicle is inconsistent with the identification information of the nearby vehicles, determining whether the received list includes the identification information of the target vehicle; and in response to the determination that the received list includes the identification information of the target vehicle, sending the current time and location to the server.

[0018] According to an embodiment, the received list may include a hashed list containing one or more International Mobile Equipment Identity (IMEI) numbers identified by nearby vehicles.

[0019] According to an embodiment, the method may further include recording the acquired identification information of the nearby vehicles in a list.

[0020] According to an embodiment, the nearby vehicle may be a first nearby vehicle, and the method may further include: sending the list to a second nearby vehicle.

[0021] According to an embodiment, the identification information of the target vehicle and the identification information of the nearby vehicles may include International Mobile Equipment Identity (IMEI).

[0022] According to an embodiment, identification information of nearby vehicles is received via shortwave broadcasting, direct communication between digital communication modules (DCMs) or Bluetooth (registered trademark).

[0023] According to an embodiment, a non-transitory computer-readable recording medium (or computer program product) is provided. Regarding the non-transitory computer-readable recording medium, sometimes the non-transitory computer-readable recording medium stores instructions, the instructions being executable by at least one processor and configured to cause the at least one processor to perform a method, the method comprising: receiving identification information of a target vehicle from a server; obtaining identification information of nearby vehicles from nearby vehicles; determining whether the identification information of the target vehicle is consistent with the identification information of the nearby vehicles; and, in response to determining that the identification information of the target vehicle is consistent with the identification information of the nearby vehicles, transmitting a current time and location to the server.

[0024] According to an embodiment, the method may also include: receiving a list from nearby vehicles; in response to a determination that the identification information of the target vehicle is inconsistent with the identification information of the nearby vehicles, determining whether the received list includes the identification information of the target vehicle; and in response to the determination that the received list includes the identification information of the target vehicle, sending the current time and location to the server.

[0025] According to an embodiment, the received list may include a hashed list containing one or more International Mobile Equipment Identity (IMEI) numbers identified by nearby vehicles.

[0026] According to an embodiment, the method may further include recording the acquired identification information of the nearby vehicles in a list.

[0027] According to an embodiment, the nearby vehicle may be a first nearby vehicle, and the method may further include: sending the list to a second nearby vehicle.

[0028] According to an embodiment, the identification information of the target vehicle and the identification information of the nearby vehicles may include International Mobile Equipment Identity (IMEI).

[0029] Additional aspects will be described in part in the description which follows and, in part, may be obvious from the description, or may be achieved by practice of the presented embodiments of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Hereinafter, features, advantages, and significance of preferred embodiments of the present disclosure will be described with reference to the accompanying drawings, in which like reference numerals denote like elements.

[0031] Figure 1 A block diagram illustrating an exemplary system configuration related to vehicle communications according to one or more embodiments.

[0032] Figure 2 A block diagram illustrating exemplary components of a VC system according to one or more embodiments.

[0033] Figure 3 A flowchart illustrating an exemplary method for determining a position of a vehicle according to one or more embodiments is shown.

[0034] Figure 4 A flowchart illustrating an exemplary method for determining a position of a vehicle according to one or more embodiments is provided.

[0035] Figure 5 A flowchart illustrating an exemplary method for assisting with vehicle software updates according to one or more embodiments is provided.

[0036] Figure 6A flowchart illustrating an exemplary method for assisting with vehicle software updates according to one or more embodiments is provided.

[0037] Figure 7 A flowchart illustrating an exemplary method for assisting with vehicle software updates according to one or more embodiments is provided. DETAILED DESCRIPTION

[0038] The following detailed description of exemplary embodiments will refer to the accompanying drawings, in which the same reference numerals in different drawings may identify the same or identical elements.

[0039] The above disclosure provides examples and illustrations, but is not intended to be exhaustive or to limit the implementation scheme to the precise form disclosed. Modifications and variations can be obtained in view of the above disclosure, or can also be obtained according to the implementation scheme. Moreover, one or more features or constituent elements of one embodiment can be embedded in another embodiment (or one or more features of another embodiment), or can be combined therewith. Moreover, it is understood that in the flowcharts and descriptions of the actions provided below, one or more actions can be omitted, one or more actions can be added, one or more actions can be performed (at least partially) simultaneously, and the order of one or more actions can be switched.

[0040] It is apparent that the systems and / or methods described in this specification can be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement the system and / or method is not limited to the implementation scheme. Therefore, the actions and behaviors of the system and / or method are described in this specification without reference to specific software code. It is understood that software and hardware can be designed to implement the system and / or method based on the description of this specification.

[0041] Even if a particular combination of features is recited in the claims and / or disclosed in this specification, that combination is not intended to limit the disclosure of possible implementations. Indeed, many of the features may be combined in ways not specifically recited in the claims and / or disclosed in this specification. Each dependent claim listed below may be directly dependent on only one claim, but the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set.

[0042] As long as it is not particularly clearly stated, the elements, behaviors or instructions used in this specification should not be interpreted as important (critical) or necessary (essential). In addition, the articles "a" and "an" used in this specification are intended to include more than one project and can be used interchangeably with "more than one". In the case of only meaning one project, the term "one" or the same term is used. In addition, the terms "has", "have", "having", "include", "including" or similar terms used in this specification are meant to be open-ended terms. Moreover, as long as it is not particularly clearly stated, phrases such as "based on..." mean "at least partially based on...". Moreover, expressions such as "at least one of [A] and [B]", "[A] and / or [B]" or "at least one of [A] or [B]" should be understood to include only A, only B or both A and B.

[0043] It is assumed that the features, advantages, and significance of the exemplary embodiments described above in this specification are only part of the present disclosure and are not intended to be exhaustive or to limit the scope of the present disclosure.

[0044] The following provides further descriptions of the features, components, configuration, operation, and implementation of the vehicle communication system of the present disclosure in accordance with one or more embodiments.

[0045] Exemplary system architecture

[0046] Figure 1 A block diagram illustrating an exemplary system configuration 100 related to vehicle communications according to one or more embodiments is shown. Figure 1 As shown, the system configuration 100 may include a server 110 , a vehicle communication (VC) system 120 , and other vehicles 130 .

[0047] The server 110 may include a cloud server, a hybrid cloud server, a server cluster, or similar servers configured to track and manage vehicles on a network. The server 110 may be remote from the VC system 120 and may be communicatively connected to the VC system 120 via a cellular network.

[0048] The VC system 120 may include a device, system, platform, module, or similar component configured to perform one or more actions or behaviors for managing vehicle communications, determining the vehicle's location, and facilitating vehicle software updates. Depending on the embodiment, the VC system 120 may be included in a vehicle (hereinafter, "this vehicle"). Depending on the embodiment, the VC system 120 may be included in multiple vehicles and may be configured to communicate with each other.

[0049] The VC system 120 may also include one or more components that enable the VC system 120 to communicate with the server 110 and / or other vehicles 130. For example, the VC system 120 may include a digital communication module (DCM). The DCM may be an electronic control unit (ECU) that includes a cellular network modem and may be configured to communicate with the server 110 via a cellular network and a base station. The DCM may also be configured to communicate with other vehicles 130 via shortwave broadcasting, direct communication between DCMs, Bluetooth (registered trademark), and similar communications. Thus, the VC system may function as a vehicle cellular sniffer.

[0050] For example, a vehicle-mounted DCM can have a listener for responses from a base station. Furthermore, if other vehicles haven't initiated callbacks to the cellular base station, the DCM can instead listen for outbound communications from other vehicles. Furthermore, the DCM can make callbacks periodically (e.g., every ten minutes) while the vehicle is in motion, and periodically (e.g., every two seconds) while the vehicle is off and the battery level exceeds an acceptable level. Because the cellular modem needs to search the cloud for a remote start command, the callbacks when the vehicle is off are shorter. On the other hand, because the callbacks when the vehicle is in motion are longer, the cellular modem can listen for an extended period to enumerate callbacks from other nearby vehicles. These callbacks can be recorded and stored locally in the vehicle, with the vehicle storing a list of links associated with the last X IMEIs observed by the vehicle. Furthermore, a modern vehicle may be able to detect that an older DCM is functioning in another vehicle (meaning it can recognize that a 3G signal is being sent but cannot respond via the cellular network).

[0051] Below, refer to Figures 3 to 7Exemplary actions that may be performed by the VC system 120 to manage vehicle communications (ie, determine the location of the vehicle and assist in vehicle software updates) are described below. Figure 2 Several exemplary components that may be included in the VC system 120 are described in more than one embodiment.

[0052] The other vehicles 130 may include any type of vehicle traveling near the VC system 120. For example, the other vehicles 130 may include vehicles traveling in the same direction as the VC system 120 within the communication range. Depending on the embodiment, the other vehicles 130 may also include the VC system 120. Depending on the embodiment, the other vehicles 130 may not include a VC system, but the other vehicles 130 may still communicate with the VC system 120 in the host vehicle.

[0053] Figure 2 A block diagram showing exemplary components of a VC system 200 according to one or more embodiments. Figure 1 Therefore, unless otherwise specified, features associated with the VC system 120 and the VC system 200 are applicable to each other in the same manner.

[0054] like Figure 2 As shown, the VC system 200 may include at least one communication interface 210, at least one processor 220, at least one input / output unit 230, and at least one storage 240. However, it is understood that the VC system 200 may include more than one communication interface 210 without departing from the scope of the present disclosure. Figure 2 More components than the components shown Figure 2 The components shown are few and / or can be arranged in accordance with Figure 2 The methods shown are different ways to configure.

[0055] The communication interface 210 may include a component (e.g., a transceiver, a separate receiver and transmitter, a bus, etc.) that enables the components of the VC system 200 to communicate with each other and / or with one or more components located outside the VC system 200 via a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection. For example, the communication interface 210 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi (Wireless Fidelity) interface, a cellular network interface, or the like.

[0056] For example, the communication interface 210 can connect the processor 220 to the storage 240, thereby enabling the processor 220 and the storage 240 to communicate with each other and perform operations together when performing one or more operations. As another example, the communication interface 210 can connect the VC system 200 (or one or more components included therein) to the server 110 and another vehicle 130, thereby enabling the VC system 200 (or one or more components included therein), the server 110, and the other vehicle 130 to communicate with each other and perform operations together.

[0057] According to one or more embodiments, the communication interface 210 may include one or more application programming interfaces (APIs) that enable the VC system 200 (or one or more components included therein) to communicate with one or more software applications (e.g., software applications deployed in the server 110).

[0058] The input / output unit 230 may include at least one component that enables the VC system 200 to receive information and / or provide output information. In some embodiments, the input / output unit 230 may include at least one input component (e.g., a touch screen display, a keyboard, a keypad, a mouse, buttons, switches, a microphone, etc.) and at least one output component (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.). It will be appreciated that the at least one input component and the at least one output component may be separate from each other. Furthermore, or alternatively, the at least one input component may include a sensor for sensing information (e.g., a Global Positioning System (GPS) component, an accelerometer, a gyroscope, and / or an actuator).

[0059] The storage 240 may include one or more storage media suitable for internally storing data, information and / or computer executable instructions. According to an embodiment, the storage 240 may include at least one storage storage such as a random access memory (RAM), a read-only memory (ROM) and / or another type of dynamic storage device or a static storage device (e.g., flash memory, magnetic memory and / or optical memory) for storing information and / or instructions for use by the processor 220. Further or alternatively, the storage 240 may include a corresponding drive and include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk and / or a solid-state drive), a compact disc (CD: Compact Disc), a digital versatile disc (DVD: Digital Versatile Disc), a floppy disk, a cartridge, a magnetic tape and / or another type of non-transitory computer-readable medium. In this specification, a computer-readable medium is defined as a non-transitory storage device. A storage device includes storage space within a single physical storage device or storage space involving multiple physical storage devices.

[0060] According to an embodiment, the storage 240 may be configured to store information such as raw data, metadata, or similar data. Further or alternatively, the storage 240 may be configured to store one or more information associated with one or more actions performed by the processor 220. For example, the storage 240 may store information that determines historical actions performed by the processor 220 to manage vehicle communications, one or more results of actions performed by the processor 220, or similar content. Moreover, the storage 240 may store data or information required for managing vehicle communications. For example, the storage 240 may store (hereinafter referred to as Figures 3 to 7 Recorded) list and software update information.

[0061] In some implementations, storage 240 may include multiple storage media. Storage 240 may be configured to store copies or replicas of at least a portion of the information on multiple storage media for redundancy and to back up the information or associated data. Furthermore, storage 240 may also store computer-readable or computer-executable instructions that, when executed by one or more processors (e.g., processor 220), cause the one or more processors to perform one or more actions described in this specification.

[0062] The processor 220 may include at least one processor that can be programmed or configured to perform the functions or actions described in this specification. For example, the processor 220 may be configured to execute computer-executable instructions stored in at least one storage medium or storage device (e.g., storage 240), thereby performing one or more behaviors or actions described in this specification.

[0063] According to an embodiment, the processor 220 may be configured to receive (e.g., via the communication interface 210, the input / output unit 230, etc.) one or more signals and / or one or more user inputs that determine one or more instructions for performing one or more actions. Moreover, the processor 220 may be implemented by hardware, firmware, or a combination of hardware and software. For example, the processor 220 may include a central processing unit (CPU), an image processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and / or at least one of another type of processing component or computing component.

[0064] According to an embodiment, the processor 220 may be configured to collect, extract and / or receive one or more information from the server 110 and other vehicles 130 (in the form of signals or data, etc.), process the one or more received information, and thereby manage vehicle communications.

[0065] Figure 2 The number and arrangement of the components shown are provided as an example. Figure 2 The VC system 200 may include additional components, fewer components, different components, or components configured differently than shown. Additionally or alternatively, a set of components (e.g., one or more components) of the VC system 200 may perform one or more functions described as being performed by another set of components of the VC system 200.

[0066] Below, refer to Figures 3 to 7 A description is provided of several exemplary actions that may be performed by processor 220 .

[0067] Exemplary actions for determining the position of a vehicle in the present disclosure

[0068] Below, refer to Figures 3 and 4 Several exemplary actions that can be performed by the VC system of the present disclosure are described below.

[0069] Figure 3 A flow chart illustrating an exemplary method 300 for determining a vehicle's location according to one or more embodiments. One or more actions in the method 300 may be performed by at least one processor of the VC system (eg, processor 220).

[0070] like Figure 3 As shown, in action S310 , at least one processor may be configured to receive identification information of a target vehicle from a server.

[0071] In particular, the target vehicle may be a vehicle whose location the server wishes to determine, but whose components, due to age, are unable to communicate or transmit the target vehicle's location to the server. Therefore, the server may transmit the target vehicle's identification information to a VC system installed in a vehicle different from the target vehicle (i.e., the host vehicle). Depending on the embodiment, it is understood that the server may transmit the target vehicle's identification information to VC systems installed in multiple vehicles.

[0072] According to an embodiment, the identification information of the target vehicle may be received via a DCM installed in the host vehicle. According to an embodiment, the identification information of the target vehicle may include an International Mobile Equipment Identity (IMEI).

[0073] According to an embodiment, the at least one processor may be further configured to receive a timestamp associated with the target vehicle's identification information from the server. The timestamp may specify a period during which the server desires to know the target vehicle's location. Therefore, as further described below, the VC system may notify the server of the target vehicle only during the period indicated by the timestamp, or may not notify the server of the target vehicle upon expiration of the timestamp. The method then proceeds to act S320.

[0074] In action S320 , at least one processor may be configured to obtain identification information of the nearby vehicles from the nearby vehicles.

[0075] Specifically, when the VC system receives the identification information of the target vehicle, the host vehicle may travel until the host vehicle encounters another vehicle. When the encountered vehicle is in the vicinity of the host vehicle (e.g., when the encountered vehicle is within the communication range of the VC system), the VC system may obtain the identification information of the encountered vehicle (i.e., the nearby vehicle).

[0076] According to an embodiment, at least one processor can communicate and obtain identification information of nearby vehicles from nearby vehicles via shortwave broadcasting, direct communication between DCMs, Bluetooth (registered trademark), and similar communications. The following describes exemplary actions that can be performed by the VC system to communicate with another vehicle.

[0077] According to an embodiment, the identification information of the nearby vehicles may include International Mobile Equipment Identity (IMEI).The method then proceeds to step S330.

[0078] In action S330, the at least one processor may be configured to determine whether the identification information of the target vehicle is consistent with the identification information of nearby vehicles. Depending on the embodiment, the at least one processor may be configured to determine whether the identification information of the target vehicle is consistent with the identification information of nearby vehicles by comparing the IMEI of the target vehicle with the IMEI of nearby vehicles. The method then proceeds to action S340.

[0079] In action S340 , the at least one processor may be configured to send the current time and location to the server in response to a determination that the identification information of the target vehicle is consistent with the identification information of the nearby vehicles.

[0080] Depending on the implementation, the current time may include the time when the VC system encountered a nearby vehicle, the time when the VC system determined that the identification information of the target vehicle matched that of the nearby vehicle, and the same time. Similarly, the current location may include the location where the VC system encountered a nearby vehicle, the location where the VC system determined that the identification information of the target vehicle matched that of the nearby vehicle, and the same location.

[0081] According to an embodiment, the at least one processor may be further configured to send a notification to the server indicating that the host vehicle has encountered the target vehicle.

[0082] According to an embodiment, the at least one processor may be configured to determine whether the received timestamp has expired. Thus, the at least one processor may be configured to send the current time and location to the server only in response to a determination that the received timestamp has not expired.

[0083] When action S340 is performed, method 300 may end or terminate. Alternatively, method 300 may return to action S310, with the result that at least one processor may be configured to repeatedly perform the following actions for at least a specified amount of time: (in action S310) receiving identification information of the target vehicle; (in action S320) obtaining identification information of nearby vehicles; (in action S330) determining whether the identification information of the target vehicle is consistent with the identification information of the nearby vehicles; and (in action S340) transmitting the current time and location.

[0084] For example, at least one processor may continuously (or periodically) receive further identification information of a target vehicle whose location the server wants to determine, and then restart the following actions: (in action S310) receive identification information of the target vehicle; (in action S320) obtain identification information of nearby vehicles; (in action S330) determine whether the identification information of the target vehicle is consistent with the identification information of nearby vehicles; and (in action S340) send the current time and location.

[0085] Thus, the process enables the server to determine the location of a target vehicle that is unable to communicate and transmit the target vehicle's location to the server due to the passage of time. The process also enables the server to determine the approximate number of vehicles traveling on a particular road.

[0086] For example, a law enforcement entity may want to locate a target vehicle, but due to the age of the target vehicle's components, this location may be impossible to determine. In this regard, the law enforcement entity may notify a server (e.g., Toyota) and provide the target vehicle's Vehicle Identification Number (VIN). The server can then use the VIN to identify the DCM installed in the target vehicle and its associated International Mobile Equipment Identity (IMEI) via an Enterprise Resource Planning (ERP) database. The server can then send this IMEI to multiple vehicles traveling in the area where the target vehicle was last seen, allowing them to identify the target vehicle and determine its location. The IMEI can also be accompanied by a timestamp indicating when the alert expired (i.e., when the server no longer needs to be notified of the target vehicle). The server can also compile a list of IMEIs and send it to the vehicle to determine the locations of multiple target vehicles.

[0087] Figure 4A flowchart illustrating an exemplary method 400 for determining a vehicle's position according to one or more embodiments. One or more actions of method 400 may be part of actions S310, S320, S330, and S340 of method 300 and may be performed by at least one processor of the VC system (e.g., processor 220).

[0088] like Figure 4 As shown, in action S410, at least one processor may be configured to receive identification information of the target vehicle from the server in the same manner as action S310 in method 300. Then, the method proceeds to action S420.

[0089] In action S420, at least one processor may be configured to obtain identification information of the nearby vehicles from the nearby vehicles in the same manner as action S320 in method 300. Then, the method proceeds to action S430.

[0090] In action S430, at least one processor may be configured to receive a list from nearby vehicles. Depending on the embodiment, the list may include one or more identification information of vehicles previously identified by the nearby vehicles. For example, the list may include one or more IMEIs previously identified by the nearby vehicles. Depending on the embodiment, the list may include an encrypted hashed list.

[0091] In particular, for example, when a vehicle encounters another vehicle and obtains an IMEI, the obtained IMEI may be recorded in a list, with the result that the list contains records of IMEIs previously encountered by the vehicle (further, associated vehicles).

[0092] Therefore, according to an embodiment, at least one processor may be configured to record the acquired identification information of nearby vehicles in a list. As a result, the VC system may store a list containing one or more identification information of vehicles previously identified by the VC system. Similarly, nearby vehicles may also have a list containing one or more identification information of vehicles previously identified by the nearby vehicle. The recorded list is not sent to the server but is stored locally, thereby protecting the user's privacy (as long as the server does not request the user's vehicle location).

[0093] According to an embodiment, the VC system may also send a list to nearby vehicles, with the result that the list of the host vehicle and the list of nearby vehicles are exchanged. For example, when the host vehicle determines that the identification information of the target vehicle is consistent with the identification information of a nearby vehicle (i.e., a first nearby vehicle), and then the host vehicle encounters another vehicle (i.e., a second nearby vehicle that is different from the first nearby vehicle), the at least one processor may be configured to send the list to the second nearby vehicle. According to an embodiment, the at least one processor may also be configured to send the received timestamp associated with the identification information of the target vehicle together with the list. The method then proceeds to action S440.

[0094] In action S440 , the at least one processor may be configured to determine whether the identification information of the target vehicle is consistent with the identification information of the nearby vehicles in the same manner as action S330 in method 300 .

[0095] Therefore, based on the determination that the identification information of the target vehicle matches the identification information of the nearby vehicle, the at least one processor may determine that the nearby vehicle is the target vehicle, and the method proceeds to action S445. On the other hand, based on the determination that the identification information of the target vehicle does not match the identification information of the nearby vehicle, the at least one processor may determine that the nearby vehicle is not the target vehicle, and the method proceeds to action S450.

[0096] In action S445 , at least one processor may be configured to send the current time and location to the server in the same manner as action S340 in method 300 .

[0097] In action S450, the at least one processor may be configured to determine whether the received list includes identification information of the target vehicle. According to an embodiment, the at least one processor may be configured to determine whether the identification information of the target vehicle is consistent with any one of the identification information of one or more vehicles in the received list (i.e., one or more identification information of vehicles previously identified by the nearby vehicle), thereby determining whether the received list includes the identification information of the target vehicle.

[0098] Therefore, based on the determination that the received list contains the identification information of the target vehicle, the at least one processor may determine that the nearby vehicle has previously encountered the target vehicle, and the method proceeds to step S455. On the other hand, based on the determination that the received list does not contain the identification information of the target vehicle, the at least one processor may determine that the nearby vehicle has not previously encountered the target vehicle, and the method proceeds to step S456.

[0099] In action S455 , at least one processor may be configured to send the current time and location to the server in the same manner as action S445 .

[0100] Depending on the embodiment, the current time may include the time when the VC system encountered a nearby vehicle, the time when the VC system determined that the received list contained the identification information of the target vehicle, and similar times. Similarly, the current location may include the location where the VC system encountered a nearby vehicle, the location where the VC system determined that the received list contained the identification information of the target vehicle, and similar locations.

[0101] According to an embodiment, the at least one processor may be further configured to send a notification to the server indicating that the host vehicle has encountered a vehicle that has previously encountered the target vehicle.

[0102] According to an embodiment, the at least one processor may be configured to determine whether the received timestamp has expired. Thus, the at least one processor may be configured to send the current time and location to the server only in response to a determination that the received timestamp has not expired.

[0103] When actions S445, S450, and / or S455 are performed, method 400 may end or terminate. Alternatively, method 400 may return to action S410, with the result that at least one processor may be configured to repeatedly perform the following actions for at least a specified amount of time: (in action S410) receiving identification information of the target vehicle; (in action S420) obtaining identification information of nearby vehicles; (in action S430) receiving a list; (in action S440) determining whether the identification information of the target vehicle matches the identification information of nearby vehicles; (in action S445) sending the current time and location; (in action S450) determining whether the received list contains the identification information of the target vehicle; and (in action S455) sending the current time and location.

[0104] For example, at least one processor may continuously (or periodically) receive further identification information of a target vehicle whose location the server wants to determine, and then restart the following actions: (in action S410) receive identification information of the target vehicle; (in action S420) obtain identification information of nearby vehicles; (in action S430) receive a list; (in action S440) determine whether the identification information of the target vehicle is consistent with the identification information of nearby vehicles; (in action S445) send the current time and location; (in action S450) determine whether the received list contains the identification information of the target vehicle; and (in action S455) send the current time and location.

[0105] As another example, the VC system and the vehicle may continuously (or periodically) encounter more vehicles and then restart the following actions: (in action S420) obtain identification information of nearby vehicles; (in action S430) receive a list; (in action S440) determine whether the identification information of the target vehicle is consistent with the identification information of nearby vehicles; (in action S445) send the current time and location; (in action S450) determine whether the received list contains the identification information of the target vehicle; and (in action S455) send the current time and location.

[0106] Thus, the above process enables the server to determine the location of a target vehicle that is unable to communicate and transmit the target vehicle's location to the server due to the passage of time. Furthermore, the server can obtain the direction, speed, and path taken by the target vehicle as it travels and encounters more vehicles over time, and obtain updates regarding the target vehicle's location. The above process also enables the server to determine the approximate number of vehicles currently traveling on a particular road.

[0107] Exemplary actions for assisting vehicle software updates in this disclosure

[0108] Below, refer to Figure 5 and Figure 7 Several exemplary actions that can be performed by the VC system of the present disclosure are described below.

[0109] Figure 5 A flow chart illustrating an exemplary method 500 for assisting with vehicle software updates according to one or more embodiments. One or more actions in method 500 may be performed by at least one processor of a VC system (eg, processor 220).

[0110] First, when a software update becomes available, a first vehicle may be able to communicate and receive the software update. For example, the first vehicle may be included in the first wave of vehicles that receive the software update after it is released (in the first week after release). However, a second vehicle may not be able to communicate and receive the software update due to the age of its components.

[0111] Therefore, one or more actions in method 500 may be performed by at least one processor (eg, processor 220 ) installed in the VC system of the second vehicle.

[0112] In this regard, first, the first vehicle can be configured to receive software updates and software update information. The software updates and software update information can be received from a server. Moreover, the software update can have a timestamp and a version number. According to an embodiment, the software update information can include information related to the software update (i.e., the received software update), but may not include the software update itself. For example, the software update information can include information associated with the software update such as the version of the software update, the size of the software update, the nature of the software update (e.g., safety critical / non-safety critical), when the software update becomes available, how to obtain the software update, and similar information. According to an embodiment, as further described below, the software update information can be sent by the first vehicle to other vehicles (e.g., the second vehicle).

[0113] According to an embodiment, the first vehicle may also be configured to receive a first digital certificate. The first digital certificate may be received by the first vehicle from a server, resulting in the first vehicle functioning as a notification vehicle. Furthermore, the first digital certificate may be associated with the software update information and the software update and may have an expiration date. The expiration date may be any period of time corresponding to the importance of the software update. For example, a first digital certificate associated with a non-safety-critical update may have an expiration date of 30 days, 60 days, or similar, while a first digital certificate associated with a safety-critical update may have an expiration date of 90 days or similar. According to an embodiment, the first digital certificate may be configured to authenticate the first vehicle to send the software update information to another vehicle (e.g., a second vehicle). When the first digital certificate expires, the first vehicle may remove the software update information from storage and may no longer have permission to send any software update information to other vehicles. Similarly, the second vehicle may be configured to receive software update information only if the software update information is accompanied by a digital certificate. Therefore, the validity period of the first digital certificate (and the validity period of the second digital certificate described below) can also function as an authentication means and enable the server to determine the period during which the server wants to notify the vehicle of the software update.

[0114] Thus, the above process provides improved security against unauthorized and / or malicious broadcasts associated with software updates.

[0115] like Figure 5 As shown, in action S510 , at least one processor may be configured to receive software update information from a first vehicle.

[0116] Depending on the implementation, the first vehicle may also be configured to transmit the first digital certificate to the second vehicle for authentication. Once the second vehicle authenticates the first digital certificate, the second vehicle may accept the software update information sent from the first vehicle. The following describes exemplary actions that may be performed via the VC system to communicate with another vehicle. The method then proceeds to step S520.

[0117] In action S520 , the at least one processor may be configured to determine whether the version of the software update indicated in the software update information is newer than the version of the software currently installed in the second vehicle.

[0118] Therefore, based on the determination that the version of the software update indicated in the software update information is new compared to the version of the software currently installed in the second vehicle, the at least one processor may determine that the software update should be received, and the method proceeds to action S530. On the other hand, based on the determination that the version of the software update indicated in the software update information is not new compared to the version of the software currently installed in the second vehicle (i.e., the second vehicle already has the version of the software update or has a newer version), the at least one processor may determine that it is not necessary to receive the software update, and the method proceeds to the end.

[0119] In action S530, the at least one processor may be configured to notify a user of the software update. The user may include a driver of the second vehicle.

[0120] When action S530 is performed, method 500 may end or terminate. Alternatively, method 500 may return to action S510, with the result that at least one processor may be configured to repeatedly perform the following actions for at least a specified amount of time: (in action S510) receiving software update information; (in action S520) determining whether the version of the software update shown in the software update information is newer than the version of the software currently installed in the second vehicle; and (in action S530) notifying the user.

[0121] For example, at least one processor may continuously (or periodically) receive further software update information from the first vehicle or a different vehicle, and then restart the following actions: (in action S510) receive the software update information; (in action S520) determine whether the version of the software update shown in the software update information is new compared to the version of the software currently installed in the second vehicle; and (in action S530) notify the user.

[0122] Thus, the above process enables the second vehicle, which is unable to communicate and receive software updates from the server due to components that have aged, to be notified of available software updates. Thus, the driver of the second vehicle can be notified to proceed with receiving the software update.

[0123] Figure 6 A flowchart illustrating an exemplary method 600 for assisting with vehicle software updates according to one or more embodiments. One or more actions of method 600 may be part of actions S510, S520, and S530 in method 500 and may be performed by at least one processor (e.g., processor 220) installed in the VC system of the second vehicle.

[0124] like Figure 6 As shown, in action S610, at least one processor may be configured to receive software update information from the first vehicle in the same manner as action S510 in method 500. Then, the method proceeds to action S620.

[0125] In action S620 , the at least one processor may be configured to determine whether the version of the software update indicated in the software update information is newer than the version of the software currently installed in the second vehicle in the same manner as action S520 in method 500 .

[0126] Therefore, based on the determination that the version of the software update indicated in the software update information is new compared to the version of the software currently installed in the second vehicle, the at least one processor may determine that the software update should be received, and the method proceeds to action S630. On the other hand, based on the determination that the version of the software update indicated in the software update information is not new compared to the version of the software currently installed in the second vehicle (i.e., the second vehicle already has the version of the software update or has a newer version), the at least one processor may determine that it is not necessary to receive the software update, and the method proceeds to action S660.

[0127] In action S630, the at least one processor may be configured to determine whether the software update is safety-critical.According to an embodiment, the at least one processor may be configured to determine whether the software update is safety-critical based on the received software update information.

[0128] Therefore, based on the determination that the software update is safety-critical, at least one processor may determine that the user should be urgently notified, and the method proceeds to action S650. On the other hand, based on the determination that the software update is not safety-critical, at least one processor may determine that the user does not need to be urgently notified, and the method proceeds to action S640.

[0129] In act S640, at least one processor may be configured to display a notification to a user. The notification may, for example, include a message indicating that a software update is available. The notification may also include instructions for obtaining the software update. Depending on the embodiment, the notification may be displayed via the in-vehicle infotainment (IVI) system of the second vehicle. Depending on the embodiment, the message may be displayed the next time the user starts the second vehicle. The user may include the driver of the second vehicle. The method then proceeds to act S660.

[0130] In action S650 , at least one processor may be configured to turn on an engine warning light. Next, the method proceeds to action S660 .

[0131] In action S660, the at least one processor may be configured to send the software update information to the third vehicle. The third vehicle may be different from the first vehicle and the second vehicle, and may not be able to communicate with the server due to age-related components.

[0132] According to an embodiment, when the second vehicle receives the first digital certificate from the first vehicle and authenticates it, at least one processor may be configured to generate a second digital certificate based on the first digital certificate. The second digital certificate may be associated with software update information and software updates and may have a validity period. The validity period of the second digital certificate may be the remaining time of the validity period of the first digital certificate. For example, if the first digital certificate has an initial validity period of 60 days, but when the second vehicle receives the first digital certificate from the first vehicle and authenticates it, the first digital certificate has a remaining validity period of 22 days, the validity period of the second digital certificate may be 22 days. According to an embodiment, the second digital certificate may be configured to authenticate the second vehicle to send software update information to other vehicles (e.g., a third vehicle). When the second digital certificate expires, the second vehicle may remove the software update information from the storage and may no longer have the authority to send any software update information to other vehicles.

[0133] Therefore, according to an embodiment, the at least one processor may be further configured to determine whether the second digital certificate has expired. Therefore, the at least one processor may be configured to send the software update information to the third vehicle only in response to the determination that the second digital certificate has not expired.

[0134] Depending on the implementation, the first digital certificate may have a limit on how many second digital certificates can be generated from the first digital certificate. For example, the first digital certificate may have a limit of six, so that only six second digital certificates can be generated from the first digital certificate. The limit of six is intended to facilitate communication between large networks of vehicles.

[0135] When action S660 is performed, method 600 may end or terminate. Alternatively, method 600 may return to action S610, with the result that at least one processor may be configured to repeatedly perform the following actions for at least a specified amount of time: (in action S610) receive software update information; (in action S620) determine whether the version of the software update shown in the software update information is newer than the version of the software currently installed in the second vehicle; (in action S630) determine whether the software update is safety-critical; (in action S640) display a notification; (in action S650) turn on the engine warning light; and (in action S660) send the software update information.

[0136] For example, at least one processor may continuously (or periodically) receive further software update information from the first vehicle or a different vehicle, and then restart the following actions: (in action S610) receive software update information; (in action S620) determine whether the version of the software update shown in the software update information is new compared to the version of the software currently installed in the second vehicle; (in action S630) determine whether the software update is safety-critical; (in action S640) display a notification; (in action S650) turn on the engine warning light; and (in action S660) send the software update information.

[0137] Thus, the above process enables a second vehicle and a third vehicle, which, due to components that have aged, are unable to communicate and receive software updates from a server, to be notified of available software updates. Consequently, the drivers of the second vehicle and the third vehicle can be notified to proceed with receiving the software update and can be informed of how to receive the software update (e.g., by visiting a dealer, a designated location, or the like). The above process also enables drivers to be notified of safety-critical updates in a timely manner, thereby reducing the risk associated with the safety-critical updates.

[0138] Figure 7 A flow chart illustrating an exemplary method 700 for assisting with vehicle software updates according to one or more embodiments. One or more actions in method 700 may be performed by at least one processor (eg, processor 220) of a VC system installed in a first vehicle.

[0139] like Figure 7 As shown, in action S710, at least one processor may be configured to receive software updates and software update information from a server in the same manner as the above method. Then, the method proceeds to action S720.

[0140] In action S720, the at least one processor may be configured to send the software update information to the second vehicle. Depending on the embodiment, the at least one processor may be configured to determine whether the first digital certificate has expired. Therefore, the at least one processor may be configured to send the software update information to the second vehicle only in response to a determination that the first digital certificate has not expired.

[0141] When action S720 is performed, method 700 may end or terminate. Alternatively, method 700 may return to action S710, with the result that at least one processor may be configured to repeatedly perform the following actions for at least a specified amount of time: (in action S710) receiving the software update and the software update information; and (in action S720) sending the software update information.

[0142] For example, at least one processor may continuously (or periodically) receive further software updates from the server and then restart the following actions: (in action S710) receiving software updates and software update information; and (in action S720) sending software update information.

[0143] Exemplary communication between vehicles

[0144] The following describes an exemplary flow of operations that can be performed by the VC system to communicate with another vehicle. In particular, the VC system can be installed in a vehicle that travels in the same direction as another vehicle during a certain period of time.

[0145] In a first example, the VC system can be configured to monitor the callbacks of DCMs installed in other vehicles via the DCM. Thus, the vehicle equipped with the VC system can function as the initiator vehicle, while the other vehicle can function as the receiving vehicle.

[0146] According to an embodiment, the initiating vehicle can be configured to initiate vehicle-to-vehicle communication with the receiving vehicle, whereby the two vehicles can exchange hashed lists of IMEIs previously encountered by the two vehicles. Vehicle-to-vehicle communication can be carried out via shortwave broadcast, direct communication between digital communication modules (DCMs) (DCMs), Bluetooth (registered trademark), and similar communications as needed based on the situation. For example, Bluetooth (registered trademark) can be utilized if the distance between the vehicles is sufficient, on the other hand, shortwave broadcast can be utilized if the receiving vehicle is using an older cellular network standard. Moreover, the hashed list can be encrypted by the private key of the corresponding vehicle (for example, the hashed list of the initiating vehicle can be encrypted by the private key of the initiating vehicle), on the other hand, the corresponding public key can be exchanged together with the list.

[0147] When the hash list and public key are exchanged, the hash list and public key can be stored. For example, when the initiating vehicle receives the hash list and public key of the receiving vehicle, the initiating vehicle can store the received hash list and public key of the receiving vehicle. The received hash list can be included as part of the transmission package in further transmissions with other vehicles as leaf nodes. Moreover, the hash list can have an expiration date, which determines the period between when the hash list is received and when the hash list should be removed. The expiration date can be an arbitrary date, for example, it can be 30 days from the time the hash list is received. The stored data can also not leave the vehicle, and can be that only the expiration date is stored in an unencrypted format.

[0148] Depending on the implementation, the initiating vehicle and the receiving vehicle may have a size limit on the hashed list that can be stored. For example, the initiating vehicle and the receiving vehicle may store a hashed list of less than ten megabytes of data in this format. Since the list is just text, this is a considerable amount of data.

[0149] According to an embodiment, the vehicle can update the above data throughout its lifespan. In addition, the data can be stored in the memory and written to the disk only when the vehicle is started or stopped.

[0150] It will be appreciated that when the hashed list is received, the vehicle can deploy the received data structure, proceed along the tree using the IMEI, hashing it to investigate whether a match is found.

[0151] In a second example, the VC system may be configured to observe other vehicles, but other vehicles may not always be using DCM.

[0152] According to an embodiment, the VC system may be configured to observe and record the IMEI numbers of other vehicles. The VC system may also be configured to record geographic locations and timestamps associated with when and where other vehicles were observed.

[0153] According to an embodiment, the VC system can be configured to record all IMEIs encountered by the VC system within a week in a daily format. The VC system can then take an average of the number of IMEIs observed and store this number of IMEIs. This measurement can be repeated quarterly if the vehicle's commuting or driving patterns change.

[0154] Various options for implementation

[0155] The above disclosure provides examples and illustrations, but is not intended to be exhaustive, nor is it intended to limit the implementation scheme to the exact form disclosed. Modifications and variations may be obtained in light of the above disclosure, or may also be obtained through practice of the implementation scheme.

[0156] In some embodiments, it may involve a system, method and / or computer-readable medium at any possible level of technical detail of the integration. Moreover, one or more of the above-mentioned constituent elements may be implemented as instructions stored in a computer-readable medium and executable by at least one processor (and / or include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or medium(s)), in which the computer-readable non-transitory storage medium (or medium(s)) has computer-readable program instructions for causing the processor to perform actions.

[0157] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof, but is not limited thereto. A non-exhaustive list of more specific examples of computer-readable storage media includes the following, i.e., a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM (Erasable Programmable Read Only Memory) or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM: Compact Disc Read Only Memory), a digital versatile disc (DVD), a memory stick, a floppy disk, a punch card, or a raised structure in a slot, etc., in which a device having instructions recorded therein, and any suitable combination thereof. The computer-readable storage medium used in this specification should not be interpreted as temporary signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (for example, light pulses passing through fiber optic cables), or electrical signals sent through wires.

[0158] The computer-readable program instructions described in this specification can be downloaded from a computer-readable storage medium to each computing / processing device, or can be downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and transmits the computer-readable program instructions to the computer-readable storage medium within the computing / processing device for storage.

[0159] The computer readable program code / instructions for performing the actions may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, or similar languages, and procedural programming languages such as the "C" programming language or similar programming languages. The computer readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, in order to perform a scheme or action, an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), can use state information of computer-readable program instructions to individualize the electronic circuit, thereby executing the computer-readable program instructions.

[0160] The computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device in order to generate a machine, and as a result, the instructions executed by the processor of the computer or other programmable data processing device generate a component for implementing the functions / behaviors specified in the functional block or functional blocks (multiple) of the flowchart and / or block diagram. The computer-readable program instructions can also be stored in a computer-readable storage medium, which can instruct the computer, programmable data processing device, and / or other devices to function in a specific method, and as a result, the computer-readable storage medium having the instructions stored therein has an article of manufacture, which includes instructions for implementing the scheme of the functions / behaviors specified in the functional block or functional blocks (multiple) of the flowchart and / or block diagram.

[0161] Computer-readable program instructions can also be loaded onto a computer, other programmable data processing apparatus or other device to perform a series of action steps on the computer, other programmable apparatus or other device to generate a computer-implemented process, as a result, the instructions executed on the computer, other programmable apparatus or other device implement the functions / behaviors specified in the functional box or functional box(es) in the flowchart and / or block diagram.

[0162] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and actions of possible implementations of the systems, methods, and computer-readable media of various embodiments. In this regard, each functional block in the flowchart or block diagram may represent a microservice module, segment, or portion of an instruction having one or more executable instructions for implementing a specified logical function. The method, computer system, and computer-readable medium may include additional functional blocks, fewer functional blocks, different functional blocks, or functional blocks in a different configuration than those depicted in the figures. In some alternative implementations, the functions described in the functional blocks may occur independently of the order described in the figures. For example, two functional blocks shown in succession may be executed virtually or substantially simultaneously, or the functional blocks may be executed in reverse order depending on the associated functions. It should also be noted that each functional block in the block diagram and / or flowchart, as well as combinations of functional blocks in the block diagram and / or flowchart, may be implemented by a dedicated hardware-based system that performs the specified functions or behaviors, or executes a combination of dedicated hardware and computer instructions.

[0163] It is apparent that the systems and / or methods described in this specification can be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement the system and / or method is not limited by the implementation scheme. Therefore, it is understood that the actions and behaviors of the system and / or method are described in this specification without reference to specific software code, and software and hardware can be designed to implement the system and / or method based on the description of this specification.

[0164] It will be appreciated that many modifications and variations of the present disclosure are possible in light of the above teachings. It will be apparent that the present disclosure can be implemented within the scope of the appended parts in ways other than those specifically described in this specification.

Claims

1. A system for dynamic vehicle communication, comprising: a storage memory storing computer-executable instructions; and at least one processor communicatively connected to the storage device; The at least one processor is configured to execute the instructions to: receiving identification information of the target vehicle from the server; acquiring identification information of the nearby vehicles from the nearby vehicles; determining whether the identification information of the target vehicle is consistent with the identification information of the nearby vehicles; as well as In response to a determination that the identification information of the target vehicle matches the identification information of the nearby vehicle, a current time and position are transmitted to the server.

2. The system according to claim 1, wherein: The at least one processor is further configured to execute the instructions to: receiving a list from said nearby vehicles; In response to a determination that the identification information of the target vehicle does not match the identification information of the nearby vehicles, determining whether the received list includes the identification information of the target vehicle; as well as In response to a determination that the received list contains the identification information of the target vehicle, a current time and location is sent to the server.

3. The system according to claim 2, wherein: The received list comprises a hashed list including one or more International Mobile Equipment Identity (IMEI) codes identified by the nearby vehicles.

4. The system according to any one of claims 1 to 3, wherein: The at least one processor is further configured to execute the instructions to record the acquired identification information of the nearby vehicles in a list.

5. The system according to claim 4, wherein: The nearby vehicle is a first nearby vehicle, The at least one processor is configured to execute the instructions to transmit the list to a second nearby vehicle.

6. The system according to any one of claims 1 to 5, wherein: The identification information of the target vehicle and the identification information of the nearby vehicles include International Mobile Equipment Identity (IMEI).

7. The system according to any one of claims 1 to 6, wherein: The identification information of the nearby vehicle is received via shortwave broadcasting, direct communication between digital communication modules DCM, or Bluetooth, which is a registered trademark.

8. A method for dynamic vehicle communication, comprising: receiving identification information of the target vehicle from the server; acquiring identification information of the nearby vehicles from the nearby vehicles; determining whether the identification information of the target vehicle is consistent with the identification information of the nearby vehicles; as well as In response to a determination that the identification information of the target vehicle matches the identification information of the nearby vehicle, a current time and position are transmitted to the server.

9. The method according to claim 8, wherein The method further comprises: receiving a list from said nearby vehicles; In response to a determination that the identification information of the target vehicle does not match the identification information of the nearby vehicles, determining whether the received list includes the identification information of the target vehicle; and In response to a determination that the received list contains the identification information of the target vehicle, a current time and location is sent to the server.

10. The method according to claim 9, wherein: The received list comprises a hashed list including one or more International Mobile Equipment Identity (IMEI) codes identified by the nearby vehicles.

11. The method according to any one of claims 8 to 10, wherein The method further includes recording the acquired identification information of the nearby vehicles in a list.

12. The method according to claim 11, wherein The nearby vehicle is a first nearby vehicle, The method also includes sending the list to a second nearby vehicle.

13. The method according to any one of claims 8 to 12, wherein: The identification information of the target vehicle and the identification information of the nearby vehicles include International Mobile Equipment Identity (IMEI).

14. The method according to any one of claims 8 to 13, wherein The identification information of the nearby vehicle is received via shortwave broadcasting, direct communication between digital communication modules DCM, or Bluetooth, which is a registered trademark.

15. A computer program product having instructions recorded thereon, wherein the instructions are executable by at least one processor and are configured to cause the at least one processor to perform a method, the method comprising: receiving identification information of the target vehicle from the server; acquiring identification information of the nearby vehicles from the nearby vehicles; determining whether the identification information of the target vehicle is consistent with the identification information of the nearby vehicles; as well as In response to a determination that the identification information of the target vehicle matches the identification information of the nearby vehicle, a current time and position are transmitted to the server.

16. The computer program product of claim 15, wherein: The method further comprises: receiving a list from said nearby vehicles; In response to a determination that the identification information of the target vehicle does not match the identification information of the nearby vehicles, determining whether the received list includes the identification information of the target vehicle; and In response to a determination that the received list contains the identification information of the target vehicle, a current time and location is sent to the server.

17. The computer program product of claim 16, wherein: The received list comprises a hashed list including one or more International Mobile Equipment Identity (IMEI) codes identified by the nearby vehicles.

18. The computer program product according to any one of claims 15 to 17, wherein: The method further includes recording the acquired identification information of the nearby vehicles in a list.

19. The computer program product of claim 18, wherein: The nearby vehicle is a first nearby vehicle, The method also includes sending the list to a second nearby vehicle.

20. The computer program product according to any one of claims 15 to 19, wherein: The identification information of the target vehicle and the identification information of the nearby vehicles include International Mobile Equipment Identity (IMEI).

Images