Claims:

1. A method for preventing vehicle theft, the method comprising:
receiving (606), from a base station controller (102), a plurality of parameters corresponding to a stolen vehicle, wherein the plurality of parameters are received by a set of Road Side Units (RSUs) associated with the base station controller (102);
transmitting (608), by each of the set of RSUs, a stolen vehicle message comprising the plurality of parameters to a first set of associated nearby vehicles;
determining (610) based on the stolen vehicle message, by each of the first set of associated nearby vehicles, whether the stolen vehicle message is self-associated; and
performing (612), by a first nearby vehicle from the first set of associated nearby vehicles, at least one of a set of predefined actions, when the stolen vehicle message is self-associated with the first nearby vehicle and the first nearby vehicle is identified as the stolen vehicle.

2. The method of claim 1, further comprising:
receiving (602), by the base station controller (102), a stolen vehicle complaint comprising the plurality of parameters corresponding to the stolen vehicle; and transmitting (604), by the base station controller (102), the plurality of parameters to the set of RSUs, wherein the plurality of parameters and the stolen vehicle message is sent based on at least one of a Cellular Vehicle to Everything (C-V2X) protocol or a Dedicated Sort Range Communication (DSRC) protocol.

3. The method of claim 1, further comprising
transmitting (702), by each of the first set of associated nearby vehicles, the stolen message to a second set of associated nearby vehicles, when the stolen vehicle message is not self-associated with each of the first set of associated nearby vehicles;
determining (704) based on the stolen vehicle message, by each of the second set of associated nearby vehicles, whether the stolen vehicle message is self-associated;
transmitting (706), by each of the second set of associated nearby vehicles, the stolen message to a third set of associated nearby vehicles, when the stolen vehicle message is not self-associated with each of the second set of associated nearby vehicles; and
performing (708), by a second nearby vehicle from the second set of associated nearby vehicles, at least one of the set of predefined actions, when the stolen vehicle message is self-associated with the second nearby vehicle and the second nearby vehicle is identified as the stolen vehicle.

4. The method of claim 1, wherein the stolen vehicle message is iteratively transmitted after expiry of a predefined time interval for a predefined time period.

5. The method of claim 1, wherein:
the set of predefined actions comprises at least one of warning a driver of the stolen vehicle to stop and park the stolen vehicle, disengaging and stopping the stolen vehicle, initiate at least one of a set of external vehicular indications, or driving the stolen vehicle to a nearby law enforcement station;
the set of predefined actions further comprise at least one of transmitting a set of information associated with the stolen vehicle to at least one of an RSU from the set of RSUs and at least one nearby vehicle from a third set of nearby vehicles associated with the stolen vehicle; and
the set of information comprises a current location of the stolen vehicle, past and current trajectory of the stolen vehicle, and tampering actions performed on the stolen vehicle.

6. The method of claim 5, further comprises:
transmitting (614), by at least one of the RSU and the at least one nearby vehicle, the set of information associated with the stolen vehicle to the base station controller (102); and
broadcasting, by the stolen vehicle, the set of information iteratively after expiry of a predefined time interval for a predefine time period, wherein broadcasting of the set of information stops upon receiving a confirmation message from the base station controller (102).

7. A method for preventing vehicle theft, the method comprising:
receiving (1002), by a vehicle, a stolen vehicle message comprising a plurality of parameters corresponding to a stolen vehicle;
determining (1004) based on the stolen vehicle message, by the vehicle, whether the stolen vehicle message is self-associated;
performing (1006), by the vehicle at least one of a set of predefined actions, when the stolen vehicle message is self-associated with the vehicle and the vehicle is identified as the stolen vehicle; and
transmitting (1008), by the vehicles, the stolen message to a set of nearby vehicles associated with the vehicle, when the stolen vehicle message is not self-associated with the vehicle.

8. The method of claim 7, wherein:
the set of predefined actions comprises at least one of warning a driver of the stolen vehicle to stop and park the stolen vehicle, disengaging and stopping the stolen vehicle, initiate at least one of a set of external indication, or driving the stolen vehicle to a nearby law enforcement station;
the set of predefined actions further comprise at least one of transmitting a set of information associated with the stolen vehicle to at least one of a Radio Side Unit (RSU) and at least one nearby vehicles from a set of nearby vehicles associated with the stolen vehicle; and
the set of information comprises a current location of the stolen vehicle, past and current trajectory of the stolen vehicle, and tampering actions performed on the stolen vehicle.

9. A vehicle configured for theft protection, the vehicle comprising:
a processor;
a memory communicatively coupled to the processor, wherein the memory comprises processor instructions, which, on execution, causes the processor to:
receive (1002) a stolen vehicle message comprising a plurality of parameters corresponding to a stolen vehicle;
determine (1004) based on the stolen vehicle message, whether the stolen vehicle message is self-associated;
perform (1006) at least one of a set of predefined actions, when the stolen vehicle message is self-associated with the vehicle and the vehicle is identified as the stolen vehicle; and
transmit (1008) the stolen message to a set of nearby vehicles associated with the vehicle, when the stolen vehicle message is not self-associated with the vehicle.

10. The vehicle of claim 9, wherein:
the set of predefined actions comprises at least one of warning a driver of the stolen vehicle to stop and park the stolen vehicle, disengaging and stopping the stolen vehicle, initiate at least one of a set of external indication, or driving the stolen vehicle to a nearby law enforcement station;
the set of predefined actions further comprise at least one of transmitting a set of information associated with the stolen vehicle to at least one of a Radio Side Unit (RSU) and at least one nearby vehicles from a set of nearby vehicles associated with the stolen vehicle, and
the set of information comprises a current location of the stolen vehicle, past and current trajectory of the stolen vehicle, and tampering actions performed on the stolen vehicle.

Description:
Technical Field
[001] Generally, the invention relates to vehicle theft. More specifically, the invention relates to method and system for preventing vehicle theft.

Background
[002] Vehicle to Everything (V2X) communication is an emerging technology in the field of vehicular communication. Vehicular communication started with a Vehicle to Vehicle (V2V) communication that enabled a vehicle to communicate with another vehicle either directly or through a network. In V2V communication, a vehicle may capture and transmit information that may include speed, direction, location, emergency braking, and other basic safety messages with other vehicles. Further, vehicular communication expanded towards communication of the vehicle with surrounding infrastructure. This technology where the vehicle communicates with surrounding infrastructure is referred as Vehicle to Infrastructure (V2I) communication. The V2I communication technology helped the vehicle to communicate with its surrounding infrastructure like, Road Side Units (RSUs) and traffic signals.
[003] Apart from V2V and V2I communication technology, vehicular communication further evolved to a field where the vehicle communicates with other telecom and data structures. This is commonly referred as Vehicle to Network (V2N) communication. Vehicular communication was further enabled between vehicles and pedestrian or multiple pedestrians within close proximity. This is referred to as Vehicle to Pedestrian (V2P) communication.
[004] All existing technology for vehicular communication, i.e., the V2V communication, the V2I communication, the V2N communication, and the V2P communication are collectively referred to as the V2X communication. The V2X communication was initially designed for semi-autonomous vehicle. The V2X communication further evolved towards fully autonomous vehicle, i.e., driverless cars. This enabled fully autonomous vehicles to take all driving and maintenance decision without any human intervention using On Board Unit (OBU) installed in the vehicle. The V2X communication provides various benefits including improved driver awareness for upcoming potential dangers, traffic congestion, and increased safety. However, no effective solution is yet available that may easily identify and monitor a stolen vehicle in order to prevent vehicle theft.
[005] Therefore, there is a need of an efficient and reliable method and system for preventing vehicle theft.

SUMMARY OF INVENTION
[006] In one embodiment, a method of preventing vehicle theft is disclosed. The method may include receiving, from a base station controller, a plurality of parameters corresponding to a stolen vehicle. It should be noted that, the plurality of parameters are received by a set of Road Side Units (RSUs) associated with the base station controller. The method may include transmitting, by each of the set of RSUs, a stolen vehicle message comprising the plurality of parameters to a first set of associated nearby vehicles. The method may include determining based on the stolen vehicle message, by each of the first set of associated nearby vehicles, whether the stolen vehicle message is self-associated. The method may include performing, by a first nearby vehicle from the first set of associated nearby vehicles, at least one of a set of predefined actions, when the stolen vehicle message is self-associated with the first nearby vehicle and the first nearby vehicle is identified as the stolen vehicle.
[007] In another embodiment, a method for preventing vehicle theft is disclosed. The method includes receiving, by a vehicle, a stolen vehicle message comprising a plurality of parameters corresponding to a stolen vehicle. The method further includes determining based on the stolen vehicle message, by the vehicle, whether the stolen vehicle message is self-associated. The method includes performing, by the vehicle at least one of a set of predefined actions, when the stolen vehicle message is self-associated with the vehicle and the vehicle is identified as the stolen vehicle.
[008] In yet another embodiment, a vehicle configured for theft protection is disclosed. The vehicle includes a processor and a memory that is communicatively coupled to the processor. The memory includes processor instructions, which, on execution, causes the processor to receive a stolen vehicle message comprising a plurality of parameters corresponding to a stolen vehicle. The processor instructions further causes the processor to determine based on the stolen vehicle message, whether the stolen vehicle message is self-associated. The processor instructions causes the processor to perform at least one of a set of predefined actions, when the stolen vehicle message is self-associated with the vehicle and the vehicle is identified as the stolen vehicle.
[009] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS
[010] The present application can be best understood by reference to the following description taken in conjunction with the accompanying drawing figures, in which like parts may be referred to by like numerals
[011] FIG. 1 is an exemplary environment in which various embodiments may be employed.
[012] FIG. 2 is a function block diagram of a system for preventing vehicle theft, in accordance with an embodiment.
[013] FIG. 3 is a functional block diagram of various modules within a memory of a Base Station Controller (BSC) configured to prevent vehicle theft, in accordance with an embodiment.
[014] FIG. 4 is a functional block diagram of various modules within a memory of a Road Side Unit (RSU) configured to prevent vehicle theft, in accordance with an embodiment.
[015] FIG. 5 is a functional block diagram of various modules within a memory of a vehicle configured to prevent vehicle theft, in accordance with an embodiment.
[016] FIG. 6 is a flowchart of a method for preventing vehicle theft, in accordance with an embodiment.
[017] FIG. 7 is a flowchart of a method representing iterative transmission of a stolen vehicle message for identifying a stolen vehicle in order to prevent vehicle theft, in accordance with an embodiment.
[018] FIG. 8 is a flowchart of a detailed exemplary process for preventing vehicle theft, in accordance with an embodiment.
[019] FIG. 9 depicts a scenario of preventing vehicle theft, in accordance with an exemplary embodiment.
[020] FIG. 10 is a flowchart of a method performed by a vehicle for preventing vehicle theft, in accordance with an embodiment.

DETAILED DESCRIPTION OF THE DRAWINGS
[021] The following description is presented to enable a person of ordinary skill in the art to make and use the invention and is provided in the context of particular applications and their requirements. Various modifications to the embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Moreover, in the following description, numerous details are set forth for the purpose of explanation. However, one of ordinary skill in the art will realize that the invention might be practiced without the use of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order not to obscure the description of the invention with unnecessary detail. Thus, the invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
[022] While the invention is described in terms of particular examples and illustrative figures, those of ordinary skill in the art will recognize that the invention is not limited to the examples or figures described. Those skilled in the art will recognize that the operations of the various embodiments may be implemented using hardware, software, firmware, or combinations thereof, as appropriate. For example, some processes can be carried out using processors or other digital circuitry under the control of software, firmware, or hard-wired logic. (The term “logic” herein refers to fixed hardware, programmable logic and/or an appropriate combination thereof, as would be recognized by one skilled in the art to carry out the recited functions.) Software and firmware can be stored on computer-readable storage media. Some other processes can be implemented using analog circuitry, as is well known to one of ordinary skill in the art. Additionally, memory or other storage, as well as communication components, may be employed in embodiments of the invention.
[023] A system 100 for identifying and preventing vehicle theft, is illustrated in FIG. 1. The system 100 includes a Base Station Controller (BSC) 102, a set of Road Side Units (RSUs) 104, a plurality of nearby vehicles (NV) 106. The BSC 102 may be configured to receive a stolen vehicle complaint from a user of a stolen vehicle. The stolen vehicle complaint may include a plurality of parameters corresponding to the stolen vehicle. Examples of the plurality of parameters may include, but are not limited to the vehicle registration number of the stolen vehicle, the color of the stolen vehicle, manufacturer of the stolen vehicle, the vehicle type of the stolen vehicle, the engine number of the stolen vehicle, chassis number of the stolen vehicle, Vehicle Identification Number (VIN) of the stolen vehicle, and the last known location of the stolen vehicle.
[024] On receiving the stolen vehicle complaint, based on the plurality of parameters in the stolen vehicle complaint, the BSC 102 may perform necessary verification and authentication in order to verify the user. By way of an example, name of the user may be verified with owner name of the stolen vehicle and the vehicle registration number. The BSC 102 may then transmit the plurality of parameters corresponding to the stolen vehicle to the set of RSUs 104 that are associated with the BSC 102. Thereafter, each of the set of RSUs 104 may transmit a stolen vehicle message to a first set of associated nearby vehicles available in the vicinity of each of the set of RSUs 104. In other words, within an associated coverage area of each of the set of RSUs 104. By way of an example, referring to a coverage area 108, the RSU 104 within the coverage are 108 may be able to transmit the stolen vehicle message only to the nearby vehicles within the coverage area 108.
[025] The stolen vehicle message may include the plurality of parameters associated with the stolen vehicle received from the BSC 102. In an embodiment, at least one of a Cellular Vehicle to Everything (C-V2X) protocol or a Dedicated Sort Range Communication (DSRC) protocol may be used to transmit the plurality of parameters and the stolen vehicle message between the BSC 102 and the set of RSUs 104 and between the set of RSUs 104 and the associated set of nearby vehicles from the plurality of vehicles 106.
[026] Upon receiving the stolen vehicle message, each of the plurality of nearby vehicles 102 may determine whether the stolen vehicle message is self-associated. In other words, a nearby vehicle upon receiving the stolen vehicle message determines whether that nearby vehicle itself is the stolen vehicle or not. Each of the plurality of nearby vehicles 102 may either receive the stolen vehicle message from one of the set of RSUs 104 or from one of the plurality of nearby vehicles 102, as explained below on detail.
[027] On identifying by a first nearby vehicle from a first set of associated nearby vehicles that the stolen vehicle message is self-associated, the first nearby vehicle may perform at least one of a set of predefined actions. In other words, the first nearby vehicle may identify itself as the stolen vehicle. By way of an example, the RSU 104 within the coverage area 108 may transmit the stolen vehicle message to the two nearby vehicles 106 within the coverage area 108. One of the two nearby vehicles 106 may identify itself as the stolen vehicle and may thus perform the set of predefined actions. The set of predefined actions may include, but are not limited to at least one of warning a driver of the stolen vehicle to stop and park the stolen vehicle, disengaging and stopping the stolen vehicle, initiating at least one of a set of external vehicular indications, or driving the stolen vehicle to a nearby law enforcement station. The set of external vehicular indications, for example, may include flashing the tail lights in a specific pattern, or intermittent honking.
[028] However, when the stolen vehicle message is not self-associated with each of the first set of associated nearby vehicle, then the stolen vehicle message may be transmitted by each of the first set of associated nearby vehicles to a second set of associated nearby vehicles. It should be noted that, the second set of associated nearby vehicles may be in vicinity of each of the first set of associated nearby vehicles. In continuation of the example above, each of the two nearby vehicles 106 in the coverage area 108 may not identify themselves as the stolen vehicle, may thus transmit the stolen vehicle message to nearby vehicles in coverage areas 110 and 112. In an embodiment, the stolen vehicle message may be transmitted until some vehicle identifies itself the stolen vehicle. It will be apparent to a person skilled in the art that the above scenario is merely exemplary and various other scenarios may necessitate such prevention of vehicle theft by the BSC 102.
[029] Referring now to FIG. 2, a functional block diagram of an exemplary system 200 for preventing vehicle theft is illustrated, in accordance with an embodiment. The system 100 may include the BSC 102, an RSU 210, and a vehicle 220. The vehicle 220, for example, may be an autonomous or a semi-autonomous vehicle. The BSC 102 may receive a stolen vehicle complaint that includes a plurality of parameters corresponding to the stolen vehicle. By way of an example, a user of the stolen vehicle may file a complaint (also referred as the stolen vehicle complaint) at the BSC 102. Examples of the plurality of parameters may include, but are not limited to the vehicle registration number of the stolen vehicle, the color of the stolen vehicle, manufacturer of the stolen vehicle, the vehicle type of the stolen vehicle, the engine number of the stolen vehicle, chassis number of the stolen vehicle, and the last known location of the stolen vehicle. The BSC 102 may include a memory 202, a processor 204, and a display 206. The display 206 may further include a user interface 208. A controller or an administrator may interact with the BSC 102 and vice versa through the display 206.
[030] By way of an example, the display 206 may be used to display results of analysis performed by the BSC 102. By way of another example, the user interface 208 may be used by the administrator to provide inputs (e.g., the stolen vehicle complaint, and the set of predefined actions) to the BSC 102. Thus, for example, in some embodiments, the BSC 102 may ingest the stolen vehicle complaint by way of the plurality of parameters associated with the stolen vehicle via the user interface 208. Further, for example, in some embodiments, the BSC 102 may render intermediate results (e.g., information (for example, current location) associated with the stolen vehicle) or final results (e.g., at least of a set of predefined actions performed by the stolen vehicle) to the administrator via the user interface 208.
[031] The memory 202 may store instructions that, when executed by the processor 204, may cause the processor 204 to perform steps required to prevent vehicle theft, in accordance with some embodiments. As will be described in greater detail in conjunction with FIG. 3 to FIG. 10, in order to prevent vehicle theft, the processor 204 in conjunction with the memory 202 may perform various functions including verifying the stolen vehicle complaint, storing the plurality of parameters, and transmitting the stolen vehicle complaint that includes the plurality of parameters to a set of RSUs (including the RSU 210) associated with the BSC 102. By way of an example, the BSC 102 may transmit the plurality of parameters to the RSU 210. In an embodiment, the BSC 102 may directly transmit the plurality of parameters corresponding to the stolen vehicle directly to the vehicle 220.
[032] The memory 202 may also store various data (for example, the parameters corresponding to the stolen vehicle, a set of information associated with the stolen vehicle, and a set of predefined actions, location of each of the set of RSUs, number of vehicles and details of each vehicle registered with the BSC 102, etc.) that may be captured, processed, and/or required by the BSC 102. The memory 202 may be a non-volatile memory (e.g., flash memory, Read Only Memory (ROM), Programmable ROM (PROM), Erasable PROM (EPROM), Electrically EPROM (EEPROM) memory, etc.) or a volatile memory (e.g., Dynamic Random Access Memory (DRAM), Static Random-Access memory (SRAM), etc.)
[033] Once the plurality of parameters are received by the BSC 102, the BSC 102 may transmit the plurality of parameters to the RSU 210. The BSC 102 may use one or more of the C-V2X protocol or a DSRC protocol for transmitting the message. Alternatively, the BSC 102 may have a wired connection with the RSU 210. On receiving the plurality of parameters, the RSU 210 may transmit the stolen vehicle message to the vehicle 220. It will be apparent to a person skilled in the art that the RSU 210 may transmit the stolen vehicle message to multiple such vehicles within the coverage are of the RSU 210 and only the vehicle 220 is depicted for ease of explanation. The stolen vehicle message may include the plurality of parameters associated with the stolen vehicle.
[034] The RSU 210 may include a memory 212, a processor 214, an Input/Output (I/O) device 216, and a camera 218. The memory 212 may store instructions that, when executed by the processor 214, may cause the processor 214 to prevent vehicle theft, in accordance with some embodiments. As will be described in greater detail in conjunction with FIG. 3 to FIG. 10, in order to prevent vehicle theft, the processor 214 in conjunction with the memory 212 may perform various functions including identifying a first set of associated nearby vehicles and transmitting the stolen vehicle message to each of the first set of associated nearby vehicles in the vicinity of the RSU 210. By way of an example, the RSU 210 may transmit the stolen vehicle message to the vehicle 220.
[035] The memory 212 may also store various data (for example, the stolen vehicle message, the set of information associated with the stolen vehicle, number of vehicles registered with the RSU 210 and details of each such vehicle) that may be captured, processed, and/or required by the RSU 210. The memory 212 may be a non-volatile memory (e.g., flash memory, Read Only Memory (ROM), Programmable ROM (PROM), Erasable PROM (EPROM), Electrically EPROM (EEPROM) memory, etc.) or a volatile memory (e.g., Dynamic Random Access Memory (DRAM), Static Random-Access memory (SRAM), etc.)
[036] The I/O device 216 may be responsible for receiving inputs and providing outputs to the BSC 102 and the vehicle 220. By way of an example, the I/O device 216 may be a communication module and may receive the plurality of parameters associated with the stolen vehicle from the BSC 102. The communication module may be compliant with one or more of the C-V2X protocol or a DSRC protocol. In addition, the I/O device 216 may send the stolen vehicle message to the vehicle 220. Based on processing of the stolen vehicle message, the I/O device 216 may receive a set of information from the vehicle 220. The set of information may correspond to the stolen vehicle, which in some cases may be the vehicle 220. The I/O device 216 of the RSU 210 may further provide the set of information associated with the stolen vehicle as an output to the BSC 102. The RSU 210, in some embodiment, may also include the camera 218 that may be used to capture images of vehicles passing by in the near vicinity of the RSU 210. The captured images may also be used to extract a set of information, which may be associated with the stolen vehicle. On receiving the stolen vehicle message, the vehicle 220 may determine whether the stolen vehicle message is self-associated. In other words, the vehicle 220 may determine whether it is the stolen vehicle or not. To this end, the vehicle 220 may include a memory 222, a processor 224, a display 226, and an onboard camera 228. The memory 222 may store instructions that, when executed by the processor 224, may cause the processor 224 to perform various steps in order to prevent vehicle theft, in accordance with some embodiments.
[037] As will be described in greater detail in conjunction with FIG. 3 to FIG. 10, in order to prevent vehicle theft, the processor 224 in conjunction with the memory 222 may perform various functions including determining by the vehicle 220, based on the stolen vehicle message, whether it is the stolen vehicle, identifying the set of information associated with the vehicle 220 (once the vehicle 220 determines it is the stolen vehicle message), transmitting the stolen vehicle message to nearby vehicles, transmitting the set of information associated with the stolen vehicle to the BSC 102 and/or the RSU 210, and performing at least one a set of predefined actions. Once the vehicle 220 determines that the stolen vehicle message is self-associated, then the vehicle 220 may perform at least one the set of predefined action. The set of predefined actions may include, but are not limited to at least one of warning a driver of the stolen vehicle to stop and park the stolen vehicle, disengaging and stopping the stolen vehicle, initiating at least one of a set of external vehicular indications, or driving the stolen vehicle to a nearby law enforcement station. The set of external vehicular indications, for example, may include flashing the tail lights in a specific pattern, or intermittent honking. The memory 222 may also store various data (for example, a set of parameters associated with the vehicle 220, the stolen vehicle message, and a set of information associated with the stolen vehicle, etc.) that may be captured, processed, and/or required by the vehicle 220. The memory 222 may be a non-volatile memory (e.g., flash memory, Read Only Memory (ROM), Programmable ROM (PROM), Erasable PROM (EPROM), Electrically EPROM (EEPROM) memory, etc.) or a volatile memory (e.g., Dynamic Random Access Memory (DRAM), Static Random-Access memory (SRAM), etc.)
[038] The display 226 (dashboard) may act as user interface for receiving inputs and providing outputs to a driver of the vehicle 220. In particular, the driver of the vehicle 220 may interact with the vehicle 220 and vice versa using the display 226. By way of an example, when the vehicle 220 identifies itself as the stolen vehicle, the display 226 may warn the driver by displaying the message to stop and park the stolen vehicle immediately. The onboard camera 228 may be used by the vehicle 220 to capture details of surrounding or nearby location in order to accurately determine its current location. The vehicle 220 may transmit all such captured information to the BSC 102, the RSU 210, and/or any other nearby vehicle. In addition, the RSU 210, and/or any other nearby vehicle may further transmit all such captured information received from the vehicle 220 to the BSC 102.
[039] Referring now to FIG. 3, a functional block diagram of various modules within the memory 202 of the BSC 102 configured to prevent vehicle theft is illustrated, in accordance with an embodiment. Initially, an input data 302 may be received by the memory. The input data 302 may correspond to a stolen vehicle complaint filed by a user of the stolen vehicle. The stolen vehicle complaint may include a plurality of parameters corresponding to the stolen vehicle. The memory 202 may further include a storage module 304, a data verification module 306, an identification module 308, a command generation module 310, and a notifying module 312.
[040] The storage module 304 may store information related to all vehicles that are registered with the BSC 102. Such information may include, but is not limited to vehicle registration numbers of the registered vehicles, bibliographic details of owners of the registered vehicles, violations caused by one or more of the registered vehicles. The storage module 304 may also store the input data 302 received from the user, which may be the stolen vehicle complaint. Additionally, the storage module 304 may store a set of predefined actions that are needed to be performed by the stolen vehicle, once its identity is confirmed. The set of predefined actions may be periodically updated based on rules and regulations associated with a particular jurisdiction or based on functional capabilities of various vehicles. The set of predefined actions may include, but are not limited to at least one of warning a driver of the stolen vehicle to stop and park the stolen vehicle, disengaging and stopping the stolen vehicle, initiate at least one of a set of external vehicular indications, or driving the stolen vehicle to a nearby law enforcement station. Further, the storage module 304 may store a set of information associated with the stolen vehicle after receiving the same. The set of information associated with the stolen vehicle may be transmitted by the stolen vehicle to the BSC 102 directly or via the RSU 210 and/or the vehicle 220.
[041] The data verification module 306 may be configured to verify the plurality of parameters corresponding to the stolen vehicle. The plurality of parameters may be verified in order to verify whether the stolen vehicle complaint filed by the user of the stolen vehicle is authentic or not. By way of an example, the data verification module 306 may verify that the stolen vehicle belongs to the user filing the stolen vehicle complaint. To this end, the data verification module 306 may extract data for registered vehicles from the storage module 304 and may compare it with the plurality of parameters provided by the user and details associated with the user.
[042] The identification module 308 may be configured to identify a set of RSUs (for example, the RSU 210) associated with the BSC 102. It should be noted that, the set of RSUs associated with the BSC 102 may be identified in order to optimize communication of the plurality of parameters. Once the set of RSUs are identified, the BSC 102 may transmit the plurality of parameters corresponding to the stolen vehicle to each of the set of RSUs. In an embodiment, the identification module 308 may also identify a first set of associated nearby vehicles in order to directly transmit the plurality of parameters to each of the first set of associated nearby vehicles.
[043] The command generation module 310 may be configured to generate a command for each of the set of RSUs to identify the stolen vehicle. In an embodiment, the command generated may include the plurality of parameters corresponding to the stolen vehicle. The notifying module 312 may be configured to notify the driver of the vehicle, drivers of the vehicles nearby the stolen vehicle, and the set of RSUs, that the vehicle has been recognized as the stolen vehicle. Based on the notification, the driver of the stolen vehicle may be instructed to at least one the set of predefined actions or the stolen vehicle may itself perform at least one the set of predefined actions. By way of an example, if the driver of the stolen vehicle fails to perform any of the set of predefined action in response to the notification, the stolen vehicle may itself perform at least one of the set of predefined actions. It should be noted that the stolen vehicle may perform at least one of the set of predefined actions via an On Board Unit (OBU) installed in the stolen vehicle.
[044] Referring now to FIG. 4, a functional block diagram of various modules within the memory 212 of the RSU 210 configured to prevent vehicle theft is illustrated, in accordance with an embodiment. Initially, the plurality of parameters corresponding to the stolen vehicle may be received from the BSC 102 by the memory 212 of the RSU 210. The memory 212 may include a data processing module 402, a vehicle location tracking module 404, and an alerting module 406. It may be noted that, for ease of explanation, we are considering processing performed by various modules of one RSU (i.e., the RSU 210). As will be appreciated, the plurality of parameters corresponding to the stolen vehicle may be transmitted by the BSC 102 to each of a set of RSUs associated with the BSC 102.
[045] Upon receiving the plurality of parameters by the memory 212, the data processing module 402 may process the plurality of parameters in order to generate a stolen vehicle message. The data processing module 402 may also be configured to process ta set of information received from the stolen vehicle. The data processing module 402 on receiving the set of information may determine a suitable predefined action from a set of predefined actions that should be performed by the stolen vehicle.
[046] Once the stolen vehicle message is generated, the vehicle location tracking module 404 may determine a first set of associated nearby vehicles. The first set of associated nearby vehicles may be the vehicles within a coverage area of the RSU 210. Additionally, the vehicle location tracking module 404 may be configured to identify the current location of the stolen vehicle. By way of an example, the vehicle location tracking module 404 may communicate with various location tracking systems, for example, but not limited to Global Position System (GPS) or GLObal NAvigation Satellite System (GLONASS) for locating each of the first set of associated nearby vehicles and then tracking the stolen vehicle after being identified. It should be noted that, the vehicle location tracking module 404 may locate the first set of associated nearby vehicles and the stolen vehicle based on any other type of vehicle location technology.
[047] The alerting module 406 may be configured to transmit the stolen vehicle message to the first set of associated nearby vehicles identified by the vehicle location tracking module 404. In an embodiment, based on the stolen vehicle message received, each vehicle from the first set of associated nearby vehicle may determine whether the stolen vehicle message is self-associated. By way of an example, the first vehicle from the first set of associated nearby vehicles may identify that the first vehicle is the stolen vehicle on determining that the stolen vehicle message is self-associated. This is further explained in detail in conjunction to FIG. 5.When the first vehicle identifies itself as the stolen vehicle and the RSU 212 receives a confirmation for the same, the alerting module 406 may generate an alert message for the first vehicle and may send it to each of the first set of associated nearby vehicle.
[048] Referring now to FIG. 5, a functional block diagram of various modules within the memory 222 of the vehicle 220 configured to prevent vehicle theft is illustrated, in accordance with an embodiment. The memory 222 may be included in an OBU within the vehicle 220. In such case, the OBU may be configured to prevent vehicle theft. A stolen vehicle message transmitted by the RSU 210 or a nearby vehicle may be received by the memory 222 of the vehicle 220. The memory 222 may include a parameter repository 502, an assessment module 504, a trajectory tracking module 506, and an alarm module 508, which may further include a response generation module 510. It should be noted that, for ease of explanation we are considering processing performed by various modules of one vehicle only (i.e., the vehicle 220o). As will be appreciated, the processing may be performed by similar module of multiple such vehicles.
[049] The parameter repository 502 stores parameters associated with the vehicle 220. Examples of the parameters may include, but are not limited to the vehicle registration number of the vehicle 220, the color of the vehicle 220, manufacturer of the vehicle 220, the vehicle type of the vehicle 220, and the engine number of the vehicle 220. On receiving the stolen vehicle message, the assessment module 504 may perform a check to identify whether the stolen vehicle message is self-associated. In other words, the assessment module 504 determines whether the stolen vehicle message is associated with the vehicle 220 or not. To this end, the assessment module 504 compares a plurality of parameters associated with the stolen vehicle with the parameters stored in the parameter repository 502. Examples of the plurality of parameters may include, but are not limited to the vehicle registration number of the stolen vehicle, the color of the stolen vehicle, manufacturer of the stolen vehicle, the vehicle type of the stolen vehicle, the engine number of the stolen vehicle, chassis number of the stolen vehicle, and the last known location of the stolen vehicle.
[050] By way of an example, the assessment module 504 may compare each parameter associated with the vehicle 220 with corresponding parameter in the plurality of parameters in the stolen vehicle message. If none of the parameters of the vehicle 220 match with one or more of the plurality of parameters, the assessment module 504 identifies that the stolen vehicle message is not self-associated. In other words, the assessment module 504 may determine that the vehicle 220 is not the stolen vehicle. In such case, the assessment module 504 may transmit the stolen vehicle message to one or more vehicles that are vicinity and within communication range of the vehicle 220. In an embodiment, the vehicle 220 may iteratively transmit the stolen vehicle message after expiry of a predefined time interval for a predefined time period. This is further explained in detail in conjunction to FIG. 8
[051] However, if one or more of the parameters of the vehicle 220 match with one or more of the plurality of parameters, the assessment module 504 identifies that the stolen vehicle message is self-associated. In other words, the assessment module 504 identifies the vehicle 220 as the stolen vehicle. Further, when the stolen vehicle message is identified as self-associated, the assessment module 504 may prompt the tracking module 506 to start tracking sequential locations of the vehicle 220 and thereby a trajectory of the vehicle 220. The tracking module 506 may additionally determine or extract a set of information associated with the stolen vehicle. The set of information may include a current location of the vehicle 220, the past and current trajectory of the vehicle 220, and tampering actions performed on the vehicle 220.Thereafter, the tracking module 506 may then transmit the set of information associated with the vehicle 220 to the alarm module 508.
[052] In addition to receiving the above, the alarm module 508 may also receive information as to the vehicle 220 being the stolen vehicle, from the assessment module 504. In response, the alarm module 508 may transmit the set of information to at least one of the RSU 210 or one or more nearby vehicles that are within the range of the vehicle 220. In an embodiment, the alarm module 508 may directly transmit the set of information associated with the stolen vehicle to the BSC 102. Additionally, the alarm module 508 may broadcast the set of information the set of information iteratively after expiry of a pre-defined time interval for the predefined time interval or until a confirmation message is received from the BSC 102. The confirmation message may specify that the set of information has been received by the BSC 102. By way of an example, the confirmation message received from the BSC 102 may confirm that the vehicle 220 has been located and is now being tracked.
[053] Once the confirmation message is received, the response generation module 510 may trigger the stolen vehicle to perform at least one of a set of predefined actions. The set of predefined actions may include, but are not limited to at least one of warning a driver of the stolen vehicle to stop and park the stolen vehicle, disengaging and stopping the stolen vehicle, initiating at least one of a set of external vehicular indications, or driving the stolen vehicle to a nearby law enforcement station. Additionally, the response generation module 510 may send a message about successful completion of the at least one of the set of predefined action performed by vehicle 220 to at least one of the RSU 210 or the one or more nearby vehicles. In an embodiment, the response generation module 508 may send the message directly to the BSC 102.
[054] It should be noted that, when the OBU includes the memory 222, the OBU may be implemented in programmable hardware devices such as programmable gate arrays, programmable array logic, programmable logic devices, or the like. An identified engine/module of executable code may, for instance, include one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, module, procedure, function, or other construct. Nevertheless, the executables of an identified engine/module need not be physically located together but may include disparate instructions stored in different locations which, when joined logically together, comprise the identified engine/module and achieve the stated purpose of the identified engine/module. Indeed, an engine or a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different applications, and across several memory devices.
[055] As will be appreciated by one skilled in the art, a variety of processes may be employed for preventing vehicle theft using one of the C-V2X or the DSRC protocol. For example, the exemplary system 200 and the BSC 102, the RSU 210, and the vehicle 220 may manage prevention of theft of the vehicle 220, based on the process discussed herein. In particular, as will be appreciated by those of ordinary skill in the art, control logic and/or automated routines for performing the techniques and steps described herein may be implemented by the system 200, the BSC 102, and the RSU 210 either by hardware, software, or combinations of hardware and software. For example, suitable code may be accessed and executed by one or more processors in the system 200 to perform some or all of the techniques described herein. Similarly, application specific integrated circuits (ASICs) configured to perform some or all the processes described herein may be included in the one or more processors in the system 200.
[056] Referring now to FIG. 6, a flowchart of a method for preventing vehicle theft is illustrated, in accordance with an embodiment. In an embodiment, communication between various entities (for example, BSCs, RSUs, or vehicles) may be performed using at least one of the C-V2X protocol or the DSRC protocol. At step 602, a stolen vehicle complaint may be received by a BSC (for example, the BSC 102). The stolen vehicle complaint received may include a plurality of parameters corresponding to the stolen vehicle. Examples of the plurality of parameters may include, but are not limited to the vehicle registration number of the stolen vehicle, the color of the stolen vehicle, manufacturer of the stolen vehicle, the vehicle type of the stolen vehicle, the engine number of the stolen vehicle, chassis number of the stolen vehicle, and the last known location of the stolen vehicle. In an embodiment, the stolen vehicle complaint may be filed by the user of the stolen vehicle. At step 604, the plurality of parameters corresponding to the stolen vehicle may be transmitted to a set of RSUs associated with the BSC. For example, as depicted in FIG. 1, each of the set of RSUs 106 may be associated with the BSC 102. Further, at step 606, the set of RSUs may receive the plurality of parameters corresponding to the stolen vehicle. Once the plurality of parameters are received by the set of RSUs, then at step 608, each of the set of RSUs may transmit a stolen vehicle message to a first set of associated nearby vehicles. The stolen vehicle message may include the plurality of parameters associated with the stolen vehicle. It should be noted that, each of the first set of associated nearby vehicles may be in vicinity of at least one of the set of RSUs. In an embodiment, the plurality of parameters and the stolen vehicle message may be transmitted based on at least one of the C-V2X protocol or the DSRC protocol.
[057] Based on the stolen vehicle message received, at step 610, each of the first set of associated nearby vehicles may determine whether the stolen vehicle message is self-associated. In an embodiment, a first nearby vehicle from the first set of associated nearby vehicles may determine that the stolen vehicle message is self-associated. Once the stolen vehicle message is determined as self-associated by the first nearby vehicle, then the first nearby vehicle may be identified as the stolen vehicle.
[058] Thereafter, based on identification of the first nearby vehicle as the stolen vehicle, at step 612, the first nearby vehicle may perform at least one of a set of predefined actions. The set of predefined actions may include, but are not limited to at least one of warning a driver of the stolen vehicle to stop and park the stolen vehicle, disengaging and stopping the stolen vehicle, initiate at least one of a set of external vehicular indications, or driving the stolen vehicle to a nearby law enforcement station.
[059] In addition, the set of predefined actions may also include at least one of a transmission of the set of information associated with the stolen vehicle. The set of information may include, but is not limited to a current location of the stolen vehicle, past and current trajectory of the stolen vehicle, and tampering actions performed on the stolen vehicle. The set of information may be transmitted to at least one of RSU from the set of RSUs and/or at least one nearby vehicle from a second set of associated nearby vehicles that are associated with the stolen vehicle. The set of information may also be directly transmitted to the BSC.
[060] Further, at step 614, the set of information associated with the stolen vehicle may be transmitted from the at least one RSU and/or the at least one nearby vehicle to the BSC. In an embodiment, the set of information may be broadcasted by the stolen vehicle iteratively after expiry of a predefined time period for a predefined time interval. In an alternat embodiment, the set of information may be broadcasted until a confirmation message may be received by the stolen vehicle from the BSC. The confirmation message may include an acknowledgement as to the stolen vehicle being tracked.
[061] Referring now to FIG. 7, a flowchart of a method for iterative transmission of a stolen vehicle message for identifying the stolen vehicle in order to prevent vehicle theft is illustrated, in accordance with an embodiment. Referring back to FIG. 6, in an embodiment, each of a first set of associated nearby vehicles may determine that the stolen vehicle message is not self-associated. In other words, none of the first set of associated nearby vehicles is the stolen vehicle. Thereafter, at step 702, the stolen vehicle message may be transmitted by each of the first set of associated nearby vehicle to a second set of associated nearby vehicles. At step 704, each of the second set of associated nearby vehicle may determine whether the stolen vehicle message received is self-associated. To this end, a check may be performed by each of the second set of associated nearby vehicles. In one embodiment, based on the check performed, when it is determined that the stolen vehicle message is associated with any of the second set of associated nearby vehicles, at step 706, the stolen vehicle message may be transmitted by each of the second set of associated nearby vehicle to a third set of associated nearby vehicles.
[062] However, when a second vehicle from the second set of associated nearby vehicle determines that the stolen vehicle message is self-associated and thus identifies itself as the stolen vehicle, at step 708, the second vehicle may perform at least one of a set of predefined actions.
[063] Further, the stolen vehicle message may be iteratively transmitted after expiry of a predefined time interval for a predefined time period. In other words, the stolen vehicle message may be iteratively transmitted to a new set of associated nearby vehicle based on the predefined time internal until the predefined time period expires. By way of an example, the predefined time period may be set at 8 hrs. and the predefined time interval after which the stolen vehicle message may be transmitted is set at 15 minutes. Thus, the stolen vehicle message may be transmitted from each of the set of RSUs to the first set of associated nearby vehicle repeatedly after every 15 minutes. It will be apparent to a person skilled in the art that the first set of associated nearby vehicles may keep changing over a period of time. Moreover, if it is determined that the stolen vehicle message is not associated with any of the first set of associated nearby vehicles, each of the first set of associated nearby vehicles may transmit the stolen vehicle message to the second set of associated nearby vehicles iteratively after every 15 minutes. In a similar manner, the transmission of the stolen vehicle message may continue to the next set of associated nearby vehicle until the stolen vehicle is identified or the predefined time period has expired.
[064] Referring now to FIG. 8, a flow diagram of a detailed exemplary process for preventing vehicle theft is illustrated, in accordance with some embodiment. At step 802, a stolen vehicle complaint may be received at a BSC (for example, the BSC 102). In an embodiment, the stolen vehicle complaint may be received from the user of the stolen vehicle. Further, the stolen vehicle complaint may include a plurality of parameters associated with the stolen vehicle. At step 804, the BSC may transmit the plurality of parameters associated with the stolen vehicle to an associated RSU. On receiving the plurality of parameters by the associated RSU, at step 806, the associated RSU may transmit the stolen vehicle message to a first associated nearby vehicle. The stolen vehicle message may include the plurality of parameters corresponding to the stolen vehicle.
[065] Upon receiving the stolen vehicle message, at step 808, the first associated nearby vehicle may perform a check to determine whether the stolen vehicle message is self-associated. In an embodiment, based on the check performed, if the first associated nearby vehicle determines that the stolen vehicle message is self-associated, then at step 810, the first associated vehicle may establish itself as the stolen vehicle. Once the first associated nearby vehicle established itself as the stolen vehicle, at step 812, the first associated nearby vehicle may perform at least one of a set of predefined actions. The set of predefined action may include at least one of warning a driver of the stolen vehicle to stop and park the stolen vehicle, disengaging and stopping the stolen vehicle, initiate at least one of a set of external vehicular indications, or driving the stolen vehicle to a nearby law enforcement station.
[066] Referring back to step 808, if the first associated nearby vehicle determines that the stolen vehicle message is not self-associated, at step 814, a check may be performed to determine whether the predefined time period has expired. If the predefined time period has not expired, at step 816, the first associated nearby vehicle may transmit the stolen vehicle message to a second associated nearby vehicle. Thereafter, the control may move to the step 808, and thus one or more of the steps 808 to 816 may be performed iteratively to identify the stolen vehicle. It should be noted that, the transmission of the stolen vehicle message is performed at a predefined time interval and may continue until the expiry of the predefined time period. Referring back to step 814, if the predefined time interval has not expired, at step 818, transmission of the stolen vehicle message may be stopped.
[067] As will be appreciated, for ease of explanation, the process may consider transmission of data (i.e., the plurality of parameters and the stolen vehicle message) between single entities. The entities may correspond to the BSC 102, the associated RSU, the first associated nearby vehicle, and the second associated nearby vehicle.
[068] Referring now to FIG. 9, depicts a scenario 900 of preventing vehicle theft, in accordance with an exemplary embodiment. In the scenario 900, a BSC 902 may receive a stolen vehicle complaint from a user of a stolen vehicle 904. The stolen vehicle complaint may include a plurality of parameters corresponding to the stolen vehicle 904. Upon receiving the plurality of parameters, the BSC 902 may transmit the plurality of parameters to an RSU 906. The RSU 906 may transmit a stolen vehicle message 908 to a vehicle 910 (nearby vehicle). The stolen vehicle message 908 may include the plurality of parameters associated with the stolen vehicle 904. Thereafter, the vehicle 910 may perform a check to determine whether the stolen vehicle message is self-associated or not.
[069] Upon receiving the stolen vehicle message, the vehicle 910 may determine that the stolen vehicle message 908 is not self-associated, the vehicle 910 may transmit the stolen vehicle message 908 to the stolen vehicle 904. Thereafter, the stolen vehicle 904 (which is not yet aware of it being stolen) may perform the check to determine whether the stolen vehicle message is self-associated or not. Based on the check, the stolen vehicle 904 may determine that the stolen vehicle message is self-associated and it is stolen. Thereafter, the stolen vehicle 904 may perform at least one of a set of predefined actions. The set of predefined actions may include, but are not limited to at least one of warning a driver of the stolen vehicle to stop and park the stolen vehicle, disengaging and stopping the stolen vehicle, initiate at least one of a set of external vehicular indications, or driving the stolen vehicle to a nearby law enforcement station.
[070] The stolen vehicle 904 may additionally transmit a set of information 912 associated with the stolen vehicle 904 to at least one of the RSU 906 and the vehicle 910. The set of information 912 may include the current location of the stolen vehicle, past and current trajectory of the stolen vehicle, and tampering actions performed on the stolen vehicle. On receiving the set of information 912 ( or the stolen vehicle information), the RSU 906 and the vehicle 910 may transmit the set of information 912 to the BSC 902. Alternatively, the vehicle 910 may transmit the set of information 912 to the RSU 906. In an embodiment, the stolen vehicle 904 may directly transmit the set of information 912 to the BSC 102. The stolen vehicle 904 may broadcast the set of information 912 iteratively after expiry of a predefined time interval for a predefined time period. Further, the stolen vehicle 904 may stop transmitting the set of information 912 upon receiving a confirmation message 914 from the BSC 102.
[071] Referring now to FIG. 10, a flowchart of a method performed by a vehicle for preventing vehicle theft is illustrated, in accordance with an embodiment. At step 1002, a stolen vehicle message may be received by a vehicle. The stolen vehicle message received may include the plurality of parameters associated with the stolen vehicle. At step 1004, based on the stolen vehicle message received, the vehicle may determine whether the stolen vehicle message is self-associated. In an embodiment, in order to determine whether the stolen vehicle message is self-associated, the vehicle may perform a check based on the plurality of parameters received. Based on the check performed, when the stolen vehicle message is determined to be self-associated, the vehicle may establish itself as the stolen vehicle.
[072] On determining by the vehicle that the stolen vehicle message is self-associated and the vehicle itself is the stolen vehicle, then at step 1006, the vehicle may perform at least one of a set of predefined actions. Moreover, based on the check performed, when the vehicle determines that the stolen vehicle message is not self-associated, then at step 1008, the vehicle may transmit the stolen vehicle message to a set of nearby vehicles associated with the stolen vehicle.
[073] Various embodiments provide method and system for preventing vehicle theft. The disclosed method and system may help to prevent vehicle theft based on at least one of a Cellular Vehicle to Everything (C-V2X) protocol or a Dedicated Sort Range Communication (DSRC) protocol. The disclosed method and system may receive a plurality of parameters corresponding to a stolen vehicle. Further, the system and method may transmit a stolen vehicle message that includes the plurality of parameters to a set of nearby vehicles. Thereafter, each of the set of nearby vehicles may determine whether the stolen vehicle message is self-associated or not. One of the set of vehicles may be identified as the stolen vehicle and the stolen vehicle may then perform at least one of a set of predefined actions.
[074] The system and method provide some advantages like detection of the stolen vehicle. In addition, the system and method may allow the stolen vehicle to disengage, which in turn will not allow the driver of the stolen vehicle to further move the stolen vehicle. Moreover, the BSC may easily track the stolen vehicle based on the set of information (e.g., the current location) received from the stolen vehicle.
[075] It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processors or domains may be used without detracting from the invention. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.
[076] Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention.
[077] Furthermore, although individually listed, a plurality of means, elements or process steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather the feature may be equally applicable to other claim categories, as appropriate.