EP4680480A1

EP4680480A1 - A method and a system for performing battery authentication of a vehicle

Info

Publication number: EP4680480A1
Application number: EP24721245.9A
Authority: EP
Inventors: Avneet Singh BASSI; Tarun Ojha
Original assignee: Hero Motocorp Ltd
Current assignee: Hero Motocorp Ltd
Priority date: 2023-03-17
Filing date: 2024-03-16
Publication date: 2026-01-21
Also published as: CN121001895A; WO2024194888A1

Abstract

Disclosed herein is a method and system for performing battery authentication of a vehicle In particular, the method comprises receiving, by a battery authentication server, a battery identification number (Battery_ID) associated with a battery and a vehicle identification number (V_ID) associated with the vehicle, from a Vehicle Control Unit (VCU) of the vehicle. The method further comprises determining, by the battery authentication server, if the Battery_ID is mapped to the V_ID. Further, the method comprises performing, by the authentication server, authentication of the battery for use in the vehicle based on the determining. Finally, the method discloses transmitting, by the battery authentication server, a server response to the VCU based on the authentication.

Description

TECHNICAL FIELD

[001] The present invention generally relates to an electric vehicle battery swapping and battery authentication system.

BACKGROUND OF INVENTION

[002] The following description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.

[003] An existing battery installation way of an electric vehicle generally comprises a static way or a swappable way. For the static way, a battery is fixed on the vehicle, and thus, the vehicle is directly used as charged object when the battery is charged. For the swappable way, a battery generally adopts a movable installation way, and thus, the battery may be taken down at any time to swap with a new battery.

[004] Further, battery replacement/battery swapping is a complex process and may involve one or more stakeholder’s involvement to implement the swapping/replacement process depending upon different conditions in which swapping/replacement is being done. In an exemplary scenario, owner of a vehicle can swap a discharged battery with a charged battery from an authorized swappable station, or from another vehicle owned by him, or from another vehicle owned by third person like a friend, relative, or a stranger helping the owner in emergency condition.

[005] In another exemplary scenario, owner of the vehicle may lend his vehicle to a third person (i.e. friend, relative or a stranger whom the owner is helping in emergency condition), and the third person could do swapping of the old battery or discharged battery with new battery from an authorized swappable station, or from the another vehicle belonging to the vehicle lender, or from another vehicle owned by the same third person, or from another vehicle owned by forth person like a friend, relative, or a stranger helping the third person in emergency condition.

[006] In both the exemplary scenarios explained above, there are some instances where the vehicle and new battery are owned by the same person and swapping is performed by same person, whereas in some instances the vehicle and new battery may be owned by same person but swapping may be performed by a third person, and in yet some other instances the vehicle owner and battery owner may be different and swapping may be performed by the vehicle owner or the battery owner or by third person. Currently, there is no mechanism in place in the existing battery authentication system to check if the battery is being swapped/replaced with the agreement of both the vehicle owner and the battery owner. Thus, conventional systems fail to prevent stealing/theft by replacing a good working battery with an old battery left having less or no battery life remaining.

[007] Thus, the conventional authentication system in swappable way or battery installation way gives rise to potential increase in theft such as stealing battery from the vehicles. There exists a need to provide an improved method and system to perform battery authentication to overcome the above-mentioned drawbacks or disadvantages.

SUMMARY OF INVENTION

[008] The present disclosure overcomes one or more shortcomings of the prior art and provides additional advantages discussed throughout the present disclosure. Additional features and advantages are realized through the techniques of the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure.

[009] In one non-limiting embodiment of the present disclosure, a method of performing battery authentication of a vehicle is disclosed. The method comprises receiving, by a battery authentication server, a battery identification number (Battery_ID) associated with a battery and a vehicle identification number (V_ID) associated with the vehicle, from a vehicle control unit (VCU) of the vehicle. The method comprises determining by the battery authentication server, if the Battery _ID is mapped to the V_ID, and performing authentication of the battery for use in the vehicle based on the determining and transmitting a server response to the VCU based on the authentication.

[0010] In one non-limiting embodiment of the present disclosure, the server response is transmitted as one of ‘successful’ or ‘unsuccessful’. [0011] In one non-limiting embodiment of the present disclosure, wherein the Battery_ID and the V_ID are received at the battery authentication server when the Battery_ID does not match with a list of pre-stored Battery_IDs stored in the VCU.

[0012] In one non-limiting embodiment of the present disclosure, upon determining that the Battery_ID is mapped to the V_ID, the method further comprises transmitting, by the battery authentication server, a first authentication request to a first device associated with a user mapped to the V_ID. The method further comprises receiving, by the battery authentication server, a first user response fromthe first device in response to the first authentication request; and transmitting, by the battery authentication server, the server response as ‘successful’ upon receiving a ‘positive’ user response from the first device.

[0013] In one non-limiting embodiment of the present disclosure, upon determining that the Battery _ID is not mapped to the V_ID, the method further comprising: transmitting, by the battery authentication server, a first authentication request to a first device associated with a user mapped to the V_ID. The method further comprises receiving, by the battery authentication server, a first user response from the first device in response to the first authentication request. Further, the method discloses transmitting, by the battery authentication server, a second authentication request to a second device associated with a user mapped to the Battery_ID, receiving, by the battery authentication server, a second user response from the second device in response to the second authentication request; and transmitting, by the battery authentication server, the server response as ‘successful’ upon receiving a ‘positive’ user response from the first device and a ‘positive’ user response from the second device, and mapping by the battery authentication server, the Battery_ID to the V_ID upon receiving a ‘positive’ user response from the first device and a ‘positive’ user response from the second device.

[0014] In one non-limiting embodiment of the present disclosure, transmitting, the server response as ‘unsuccessful’ upon receiving one or more of the below responses: a ‘negative’ user response received form the first device; a ‘negative’ user response received form the second device; and a ‘negative’ user response from the first device and a ‘negative’ user response from the second device.

[0015] In one non-limiting embodiment of the present disclosure, the method further comprises further comprises adding, by the VCU, the Battery_ID in the list of prestored Battery IDs when the server response is received as ‘successful’.

[0016] In one non-limiting embodiment of the present disclosure, the method further comprises enabling, by the VCU, a power train of the vehicle, upon receiving a ‘successful’ server response from the battery authentication server; or preventing, by the VCU, from enabling the power train upon receiving an ‘unsuccessful’ server response from the battery authentication server.

[0017] In one non-limiting embodiment of the present disclosure, a method of performing battery authentication in a vehicle is disclosed. The method comprises receiving, by a battery authentication server, a battery identification number (Battery_ID) associated with a battery and a vehicle identification number (V_ID) associated with the vehicle, from a Vehicle Control Unit (VCU) of the vehicle. The method further comprises transmitting, by the battery authentication server, a first authentication request to a first device associated with a user mapped to a Vehicle Identification number (V_ID) of the vehicle; transmitting, by the battery authentication server, a second authentication request to a second device associated with a user mapped to a Battery Identification number (Battery_ID) of a battery. Thereafter, the method comprises performing authentication of the battery for use in the vehicle and transmitting a server response as one of ‘successful’ and ‘unsuccessful’ to the VCU based on the authentication.

[0018] In one non-limiting embodiment of the present disclosure, wherein performing authentication of the battery for use in the vehicle, the method further comprising receiving, by the battery authentication server, a first user response from the first device in response to the first authentication request; receiving, by the battery authentication server, a second user response from the second device in response to the second authentication request; transmitting the server response as ‘successful’ upon receiving a ‘positive’ user response from the first device and a ‘positive’ user response from the second device; and mapping the Battery lD to the V ID upon receiving a ‘positive’ user response from the first device and a ‘positive’ user response from the second device.

[0019] In one non-limiting embodiment of the present disclosure, wherein the method further comprises: adding, by the VCU, the Battery_ID in the list of pre-stored Battery lDs when the server response is received as ‘successful’.

[0020] In one non-limiting embodiment of the present disclosure, wherein the method further comprises: enabling, by the VCU, a power train of the vehicle upon receiving a ‘successful’ server response from the battery authentication server; or disabling, by the VCU, the power train of the vehicle upon receiving an ‘unsuccessful server response from the battery authentication server’.

[0021] In one non-limiting embodiment of the present disclosure, a system for performing battery authentication of a vehicle is disclosed. The system comprises a vehicle control unit (VCU) and a battery authentication server. The battery authentication server configured to receive a battery identification number (Battery_ID) associated with a battery and a vehicle identification number (V_ID) associated with the vehicle, from the VCU of the vehicle. Further, the battery authentication server determines if the Battery_ID is mapped to the V_ID. Thereafter, the battery authentication server performs an authentication of the battery for use in the vehicle based on the determination and transmits a server response as one of ‘successful’ and ‘unsuccessful’ to the VCU, based on the authentication. Furthermore, the VCU is configured to enable a power train of the vehicle upon receiving a ‘successful’ server response from the battery authentication server or disable the power train of the vehicle upon receiving an ‘unsuccessful’ server response from the battery authentication server.

[0022] In one non-limiting embodiment of the present disclosure, a system for performing battery authentication of a vehicle is disclosed. The system comprises a vehicle control unit (VCU) and a battery authentication server. The battery authentication server configured to receive a battery identification number (Battery_ID) associated with a battery and a vehicle identification number (V_ID) associated with the vehicle, from theVCU of the vehicle. Further, the battery authentication server transmits a first authentication request to a first device associated with a user mapped to the V_ID of the vehicle and transmits a second authentication request to a second device associated with a user mapped to the Battery_ID of the battery. Furthermore, the battery authentication server performs an authentication of the battery for use in the vehicle. The battery authentication server transmits a server response as one of ‘successful’ and ‘unsuccessful’ to the VCU based on the authentication and authenticates the battery for use in the vehicle based on the server response. Thereafter, the VCU is configured to: enable a power train of the vehicle upon receiving the ‘successful’ server response from the battery authentication server, or disable the power train of the vehicle upon receiving the ‘unsuccessful’ server response from the battery authentication server.

[0023] The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.

BRIEF DESCRIPTION OF DRAWINGS

[0024] The embodiments of the disclosure itself, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings. One or more embodiments are now described, by way of example only, with reference to the accompanying drawings in which:

[0025] Figure 1 depicts a block diagram of a system 100 for performing battery authentication of a vehicle, in accordance with an embodiment of the present disclosure;

[0026] Figures 2a-2b depict sequence diagrams for performing battery authentication of a vehicle, in accordance with an embodiment of the present disclosure;

[0027] Figures 3a-3b illustrate method/steps for performing battery authentication of a vehicle, in accordance with an embodiment of the present disclosure; and [0028] The figures depict embodiments of the disclosure for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the disclosure described herein.

DETAILED DESCRIPTION

[0029] The foregoing has broadly outlined the features and technical advantages of the present disclosure in order that the detailed description of the disclosure that follows may be better understood. It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure.

[0030] The novel features which are believed to be characteristic of the disclosure, both as to its organization and method of operation, together with further objects and advantages will be better understood from the following description when considered in connection with the accompanying Figures. It is to be expressly understood, however, that each of the Figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the present disclosure.

[0031] Disclosed herein is a method and system for performing battery authentication of a vehicle. When the battery of the vehicle gets discharged, the vehicle approaches a swapping station to swap the discharged battery with a new battery. The battery may be swapped with the swapping station or with another vehicle. Another vehicle may be referred to as a vehicle corresponding to a known person or friend, or relative. In both the scenarios, in order to swap the discharged battery with the new battery, battery authentication needs to be provided to avoid any type of unauthorized usage of the battery or theft. Thus, the present disclosure provides techniques for authenticating the battery for use in the vehicle. To do so, the battery authentication server first determines whether the new battery mapped with the vehicle or not. If it is found that the new battery is mapped with the vehicle, the battery authentication server transmits an authentication request to a user of the vehicle. Upon receiving a positive user response from the user, the battery authentication server transmits a server response as ‘successful’ which means that battery has been successfully authenticated for use in the vehicle. Whereas if the new battery does not map with the vehicle, as discussed earlier, there exist two scenarios. Firstly, where the battery is to be swapped at the swapping station, then approval for usage of the battery in the vehicle is required from the vehicle owner. Secondly, when the battery is to be swapped with another vehicle, then approval for usage of the battery in the vehicle is required from both the battery owner and the vehicle owner. Thus, if the approval from the battery owner or from both the vehicle owner and the batter owner is received then only the battery is inserted in the vehicle for usage other wise it cannot be consumed. Hence, the present disclosure provides an efficient way of exchanging batteries for use in vehicle by authenticating them and helps in theft prevention.

[0032] It may further be noted that the present disclosure may be implemented for two- wheelers, three-wheeler, four-wheeler vehicles but limited to electric vehicles and the term “vehicle” used hereafter for above mentioned types of vehicles.

[0033] Fig. 1 shows a block diagram illustrating a system for performing battery authentication of a vehicle, in accordance with an embodiment of the present disclosure. The explanation of Fig. 1 is described in conjunction with the Fig. 2a-2b to understand the invention with ease. Fig. 2a-2b illustrates sequence diagrams for performing battery authentication of the vehicle.

[0034] In one implementation, the system 100 comprises a battery authentication server 101 configured to authenticate a battery (not shown) for use in a vehicle 103. It may be well noted that the battery that need to be authenticated may be present at the swapping station or may relate to a battery (new battery) of another vehicle (not shown). In some embodiments, the swapping station may be referred to as swappable charging station. The battery authentication server 101 may be in communication with the vehicle 103 via a communication network 105. In some embodiments, the battery authentication server 101 may reside outside the system 100. The battery authentication server 101 may be in communication with a vehicle control unit (VCU) 107 residing inside the vehicle 103. Further, the battery authentication server 101 may comprise a processor 109 and a memory 111 coupled to each other. In some embodiments, the processor 109 may be configured to perform the functionality of the battery authentication server 101. In some embodiments, the battery authentication server 101 may be configured to store mapping between a vehicle identification number (V_ID) associated with the vehicle 103 and a battery identification number (Battery_ID) associated with the battery. In some embodiments, the VCU 107 may comprise a memory 113 configured to store the Battery _IDs and the V_IDs. The VCU 107 may be coupled to a battery 115 already stored/placed in the vehicle 103 and may be configured to store the Battery_ID associated with the battery. In some embodiments, the battery 115 which is already placed in the vehicle 103 may be referred to as old battery.

[0035] In some embodiments, the VCU 107 may be implemented as a processor, one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the VCU 107 may be configured to fetch and execute computer-readable instructions stored in the memory.

[0036] In an embodiment, the memory may be a computer-readable medium known in the art including, for example, volatile memory, such as static random-access memory (SRAM) and dynamic random-access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment, the information may be stored within the memory in the form of various data structures. Additionally, the information stored in memory may be organized using data models, such as relational or hierarchical data models or lookup tables. The memory may also store other data such as temporary data and temporary files, generated by the various units for performing the various functions of the VCU 107.

[0037] In accordance with the present disclosure, the battery authentication server 101 may be configured to receive a battery identification number (Battery_ID) associated with a battery and a vehicle identification number (V_ID) associated with the vehicle. It may be well noted to a person skilled in the art that the Battery_ID of new battery is received. In other words, the battery authentication server 101 receives the Battery_ID and the V_ID from the VCU 107 of the vehicle. In non-limiting embodiment, whenever a new vehicle is issued to a user, the battery _ID associated with already placed battery may be stored in the VCU 107. Accordingly, the VCU 107 may be configured to store a list of pre-stored Battery _IDs. Hence, the Battery_ID and V_ID are received at the battery authentication server 101 when the Battery_ID does not match with a list of pre-stored Battery_IDs stored in the VCU 107. Further, the battery authentication server 101 may determine if the Battery_ID is mapped to the V_ID. Upon determining that the Battery_ID is mapped to the V_ID, the battery authentication server 101 transmits a first authentication request to a first device associated with a user mapped to the V_ID. In other words, the first authentication request is transmitted to the first device of the user of the vehicle. The battery authentication server 101 may be configured to receive a first user response from the first device in response to the first authentication request. The first authentication request may be referred to as requesting approval for usage of battery in the vehicle. Thus, the battery authentication server 101 may be configured to transmit a server response as ‘successful’ upon receiving a ‘positive’ user response from the first device. The ‘positive’ user response from the first device is an approval for using the battery in the vehicle. In this manner, battery authentication is performed for using the battery in the vehicle.

[0038] In some embodiments, when the battery authentication server 101 determines that the Battery_ID is not mapped to the V_ID, the battery authentication server 101 may be configured to transmit a first authentication request and a second authentication request to a first device and a second device, respectively. The first device may be associated to a user mapped to the V_ID and the second device may be associated to a user mapped to the Battery _ID. However, this should be taken into limiting sense in a manner that the first device may be associated to a user mapped to the Battery_ID and the second device may be associated to a user mapped to the V_ID. In response to the first authentication request and the second authentication request, the battery authentication server 101 receives a first user response from the first device and a second user response from the second device, respectively. The battery authentication server 101 may be configured to transmit a server response to the VCU 107 and authenticate the battery for use in the vehicle 103 based on the server response. [0039] In some embodiments, the battery authentication server 101 may be configured to transmit the server response as ‘successful’ upon receiving a ‘positive’ user response from the first device and a ‘positive’ user response from the second device. In other words, the ‘successful’ server response is transmitted to the VCU 107 for using the battery in the vehicle 103 based on the positive response from the first device and the second device. The VCU 107 may be configured to enable a power train of the vehicle 103 upon receiving a ‘successful’ server response from the battery authentication server. Once the ‘positive’ user response is received from the first device and the second device, the battery authentication server 101 may be configured to map the Battery_ID to the V_ID. In some embodiments, the VCU 107 may be configured to add the Battery_ID in the list of pre-stored Battery_IDs when the server is received as ‘successful’. The Battery _ID may be stored in the list of pre-stored Battery_IDs so that for the next time the battery may be used for usage in the vehicle 103 since the battery is already authenticated.

[0040] In some embodiments, the VCU 107 may be configured to prevent from enabling the power train upon receiving an ‘unsuccessful’ server response from the battery authentication server. The ‘unsuccessful’ server response may be received from the battery authentication server 101 upon receiving a ‘negative’ user response from any one of the first device or second device or from both the first and second device. In other words, the user corresponding to the first device, or the second device may not allow to use the battery in the vehicle.

[0041] In another implementation, the battery authentication server 101 may be configured to receive a battery identification number (Battery _ID) associated with a battery and a vehicle identification number (V_ID) associated with the vehicle 103. The battery authentication server 101 receives the Battery_ID and the V_ID from the VCU 107 of the vehicle 103. The battery authentication server 101 may be configured to transmit a first authentication request and a second authentication request to a first device and a second device respectively. As discussed earlier, the first device may be associated with a user mapped to the V_ID of the vehicle 103 and the second device may be associated with a user mapped to the Battery_ID of the battery. In response to the first authentication request and the second authentication request, the battery authentication server 101 may be configured to receive a first user response and a second user response from the first device and the second device respectively. Further, the battery authentication server 101 may be configured to transmit a server response to the VCU 107 and authenticate the battery for use in the vehicle 103 based on the server response. In some embodiments, the battery authentication server 101 may be configured to transmit the server response as ‘successful’ upon receiving a ‘positive’ user response from the first device and the second device. Based on the ‘positive’ user response, the battery authentication server 101 may be configured to map the Battery_ID to the V_ID. However, the description should not be taken into limiting sense. In some embodiments, the VCU 107 may be configured to add the Battery_ID in the list of pre-stored Battery_IDs when the server response is received as ‘successful’. Based on the ‘successful’ server response, the VCU 107 may be configured to enable the power train of the vehicle 103. In another embodiment, the VCU 107 may be configured to disable the power train of the vehicle 103 based on receiving an ‘unsuccessful’ server response from the battery authentication server.

[0042] In an exemplary scenario, when the battery is swapped with the swapping station, the battery authentication server 101 may be configured not to proactively inform the new Battery_ID to the vehicle 103, until the battery is inserted in the vehicle and authentication is performed. Post authentication the battery is swapped with the swapping station. In order to swap the new battery with the old battery, following step may be performed. Firstly, the user of the vehicle removes the old battery from the vehicle 103 and inserts the old battery into the swapping station. The swapping station reads Battery_ID from the old battery and queries the battery authentication server 101 about the V_ID on which the old Battery_ID is mapped. Further, the swapping station swaps the old battery with a new battery and provides the new Battery_ID corresponding to the V_ID, to the battery authentication server. The battery authentication server 101 may be configured to map the new Battery _ID to the V_ID. In non-limiting embodiment, if the new Battery_ID is already mapped to the V_ID at the battery authentication server, this indicates that battery owner and the vehicle owner are same, Hence, the battery authentication server 101 may be configured to transmi t/send the notification/authentication request only to the vehicle owner. Furthermore, the swapping station provides the new battery to the user and inserts the new battery into the vehicle 103. In an embodiment, the VCU 107 compared new Battery_ID with pre-stored Battery_IDs in the memory of the VCU 107. The VCU 107 sends the new Battery_ID to the battery authentication server 101 for authentication. The battery authentication server 101 checks or determines whether the new Battery_ID is mapped to the V_ID and sends notification/request to the vehicle owner (also referred to as first device in the disclosure). If the vehicle owner sends positive response to the battery authentication server, the battery authentication server 101 transmits a server response as ‘successful’ to the VCU 107 based on the positive response. The VCU 107 enables power train of the vehicle 103 and stores new Battery_ID in the memory of the VCU 107 Whereas if the vehicle owner sends negative response to the battery authentication server, the battery authentication server 101 transmits the server response as ‘unsuccessful’ to the VCU 107 based on the negative response. The VCU 107 disables or prevents enabling power train of the vehicle 103.

[0043] In another exemplary scenario, in case battery is swapped with the swapping station, the battery authentication server 101 may be configured not to proactively inform the new Battery _ID to the vehicle 103, until battery is inserted in the vehicle 103 and authentication is performed. In this scenario, the battery is swapped with some other user or another vehicle. In such case, user removes old battery from the vehicle 103 and inserts a new battery swapped with another vehicle. The VCU 107 compared a Battery_ID of the new battery with the Battery_IDs stored in the memory of the VCU 107. The VCU 107 transmits the new Battery_ID and the V_ID of the vehicle 103 to the battery authentication server 101 for authentication. The battery authentication server 101 checks if the new Battery_ID is mapped to the V_ID and transmits a notification/authentication request to both the battery owner and the vehicle owner. If ‘positive’ user response is received from the battery owner and the vehicle owner, the battery authentication server 101 transmits a server response as ‘successful’ to the VCU 107. The battery authentication server 101 links or maps the new Battery _ID with the V_ID for future purposes. Upon receiving the ‘successful’ server response, the VCU 107 enables the power train of the vehicle 103. If ‘negative’ user response is received from any one of the battery owner or the vehicle owner, the battery authentication server 101 transmits the server response as ‘unsuccessful’ to the VCU 107. Upon receiving the ‘unsuccessful’ server response, the VCU 107 disables or prevents enabling the power train of the vehicle 103. It may be well notes that since new battery is not provided by the swapping station, therefore, the new Battery_ID is not mapped with the V_ID. This indicates that the battery owner and the vehicle owner are not same. Hence, the battery authentication server 101 transmits notification/authentication request to both the vehicle owner and the battery owner.

[0044] In another exemplary scenario, in case battery is swapped with the swapping station, the battery authentication server 101 is configured to proactively inform the new Battery_ID to the vehicle 103, even before the battery is inserted in the vehicle 103 and authentication is performed. In this case, the battery is swapped with the swapping station. The user removes old battery from the vehicle 103 and inserts the old battery into swapping station. The swapping station reads old Battery_ID from the old battery and queries the server about the V_ID on which the old Battery_ID is mapped. The swapping station swaps the old battery with a new battery and provides the new Battery_ID corresponding to the V_ID to the battery authentication server. The battery authentication server 101 maps the new Battery _ID to the V_ID and transmits the new Battery_ID to the VCU 107. The VCU 107 stores the new Battery_ID in the memory of the VCU 107. The user inserts the new battery into the vehicle 103. The VCU 107 compares the new Battery_ID with the pre-stored Battery_IDs in the memory. Once the battery is inserted in the vehicle 103, the VCU 107 enables the power train of the vehicle 103. This scenario is applicable where the new Battery_ID matches to the prestored Battery _IDs. Therefore, the VCU 107 enables power train of the vehicle 103 and there is no requirement of authenticating the battery.

[0045] In another exemplary scenario, in case battery is swapped with swapping station, the battery authentication server 101 may be configured to proactively inform the new Battery _ID to the vehicle 103, even before battery is inserted in the vehicle 103 and authentication is performed. In this case, the battery is swapped with another vehicle. The user removes the old battery from the vehicle 103 and inserts a new battery swapped with another vehicle. The VCU 107 of the vehicle 103 compares new Battery_ID with the pre-stored Battery _IDs in the memory. The VCU 107 transmits the new Battery _ID and the V_ID of the vehicle 103 in which battery is being placed to the battery authentication server 101 for authentication. The battery authentication server 101 transmits notification/authentication request to both the battery owner and the vehicle owner. Upon receiving ‘positive’ response from the battery owner and the vehicle owner, the battery authentication server 101 transmits a server response as ‘successful’ to the VCU 107. The battery authentication server 101 links/maps the new Battery_ID to the V_ID. The VCU 107 enables the power train of the vehicle 103 based on the ‘successful’ server response from the battery authentication server. The VCU 107 stores the new Battery_ID in the memory. Upon receiving ‘negative’ response from any one of the battery owner and the vehicle owner, the battery authentication server 101 transmits the server response as ‘unsuccessful’ to the VCU 107. The VCU 107 disables/prevent enabling the power train of the vehicle 103 based on the ‘unsuccessful’ server response. In this scenario, since the server is configured to proactively inform the vehicle 103 about the new battery (i.e., before new battery is inserted in the vehicle), the step of checking if new Battery_ID is mapped to the V_ID at the battery authentication server 101 is not required. Since, the new battery is not provided by the swapping station, therefore, the battery authentication server 101 has no information about the new Battery_ID. Hence, in this scenario, the battery authentication server 101 cannot proactively inform the vehicle 103 about the new battery (i.e., before new battery is inserted in the vehicle). Therefore, when VCU 107 compares new Battery_ID with the pre-stored Battery_IDs in the memory, there will be no match. Hence, the VCU 107 transmits new Battery_ID to the battery authentication server 101 for authentication. Since the battery owner and the vehicle owner are not same, the battery authentication server 101 transmits notification/authentication request to both the battery owner and the vehicle owner.

[0046] It may be worth noted that paragraphs [0036]-[0039] discloses exemplary scenarios and should not be taken into limiting sense within the scope of the disclosure.

[0047] Figure 3 depicts a method 300 for performing battery authentication of a vehicle 103, in accordance with an embodiment of the present disclosure. The method 300 may be described in the general context of computer executable instructions. Generally, computer executable instructions may include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform specific functions or implement specific abstract data types. [0048] The order in which the method 300 is described is not intended to be construed as a limitation, and any number of the described method blocks may be combined in any order to implement the method. Additionally, individual blocks may be deleted from the methods without departing from the spirit and scope of the subject matter described.

[0049] Further, the method 300a is implemented in a scenario where user of the vehicle 103 swaps battery with another vehicle. In this scenario, approval is requested from vehicle owner (first device) and owner of another vehicle (because owner of another vehicle is owner of a new battery).

[0050] At block 301a, the method 300a may comprise receiving a battery identification number (Battery _ID) associated with a battery and a vehicle identification number (V_ID) associated with the vehicle 103 from a vehicle control unit (VCU 107) of the vehicle 103. The method 302 is performed by a battery authentication server. In some embodiments, the Battery _ID and the V_ID are received at the battery authentication server 101 when the Battery_ID does not match with a list of pre-stored Battery_IDs stored in the VCU 107.

[0051] The method at block 303a may comprise determining if the Battery_ID is mapped to the V_ID. The method at block 305a may performing authentication of the battery for use in the vehicle. Thereafter, the method at block 307a may transmit a server response to the VCU. The method discloses transmitting the server response as one of ‘successful’ and ‘unsuccessful’.

[0052] In some embodiments, upon determining that the Battery _ID does not map to the V_ID, the method further comprises transmitting a first authentication request to a first device associated with a user mapped to the V_ID. In response to the first authentication request, a first user response from the first device is received. The method further comprises transmitting a second authentication request to a second device associated with a user mapped to the Battery _ID. In response to the second authentication request, a second user response from the second device is received. The method further includes transmitting the server response as ‘successful’ upon receiving a ‘positive’ user response from the first device and a ‘positive’ user response from the second device. Based on receiving the ‘positive’ user response from the first device and the ‘positive’ user response from the second device, the method further comprises mapping the Battery _ID to the V_ID.

[0053] In some embodiments, the method further comprises adding by the VCU 107 the Battery _ID in the list of pre-stored Battery_IDs when the server response is received as ‘successful’. The method comprises enabling by the VCU 107 a power train of the vehicle 103 upon receiving a ‘successful’ server response from the battery authentication server. In some embodiments, the method further comprises preventing by the VCU 107 enabling the power train upon receiving the ‘unsuccessful’ server response from the battery authentication server. In some embodiments, the server response may be ‘unsuccessful’ upon receiving one or more of the following responses: a ‘negative’ user response received form the first device, a ‘negative’ user response received form the second device; and a ‘negative’ user response from the first device and a ‘negative’ user response from the second device.

[0054] Further, the method 300b is implemented in a scenario where user of the vehicle 103 swaps battery with swapping station. In this scenario, approval is requested from vehicle owner (first device) because owner of the vehicle 103 is owner of the new battery. The method 300 is performed by a battery authentication server.

[0055] At block 301b, the method 300b may comprise receiving a battery identification number (Battery_ID) associated with a battery and a vehicle identification number (V_ID) associated with the vehicle 103 from a vehicle control unit (VCU 107) 107 of the vehicle 103.

[0056] At block 303b, the method may comprise transmitting a first authentication request to a first device associated with a user mapped to the V_ID of the vehicle 103. In response to the first authentication request, a first user response from the first device is received.

[0057] The method at block 305b may comprise transmitting a second authentication request to a second device associated with a user mapped to the Battery_ID. In response to the second authentication request, a second user response from the second device is received.

[0058] At block 307b, the method may further comprise performing authentication of the battery for use in the vehicle. Thereafter, the method at block 309b comprises transmitting a server response as one of ‘successful’ and ‘unsuccessful’ to the VCU.

[0059] In some embodiments, the method may further comprise mapping the Battery lD to the V ID upon receiving the ‘positive’ user response from the first device and the ‘positive’ user response from the second device. In some embodiments, the method may further comprise adding the Battery_ID in the list of pre-stored Battery_IDs when the server response is received as ‘successful’. The method is performed by the VCU 107. The method may further comprise enabling by the VCU 107 a power train of the vehicle 103 upon receiving a ‘successful’ server response from the battery authentication server. In some embodiments, the method may further comprise disabling by the VCU 107 the power train of the vehicle 103 upon receiving the ‘unsuccessful’ server response from the battery authentication server. In some embodiments, the server response may be ‘unsuccessful’ upon receiving one or more of the following responses: a ‘negative’ user response received form the first device, a ‘negative’ user response received form the second device; and a ‘negative’ user response from the first device and a ‘negative’ user response from the second device.

[0060] Without limiting the scope of the present disclosure, the foregoing paragraph explains one of the real-life situations in which one of the embodiments of the present disclosure may be implemented. For example, User-A lends his vehicle-A to User-B. User-B replaces the battery of the vehicle-A with a new battery removed from another Vehicle-B which belongs to User-C. When the User-B inserts the new battery in the vehicle-A, firstly Battery-ID of the new battery is detected and compared internally to see if a mapping lies in its internal database. On finding that there is no match found internally, the Battery_ID of the new battery and V_ID of Vehicle-A is transmitted to an authentication server. The authentication server firstly checks internally, if the received Battery _ID is mapped to the received V_ID. If it is not matched, then a notification is sent to the User-A (who is the owner of the received V_ID in this particular case), and another notification is sent to User-C (who is the owner of the received Battery_ID in this particular case). If a positive response received from the User-A and User-C in response to send notifications, then the authentication server will send a positive server response to the VCU of the Vehicle-A, and simultaneously it maps the Battery_ID with V_ID in its internal database. After receiving the positive response from the server, the VCU of Vehicle-A enables its power train and also maps the Battery_ID with the V_ID in its internal database. Mapping of V_ID and Battery_ID in the server, and in the Vehicle-A after successful authentication ensures that the above authentication process is not repeated again if the same battery is removed and inserted again in the Vehicle-A in the future. However, above mapping in the server and/or vehicle is optional can be removed if it is desired to repeat the above authentication process every time if a new battery is inserted in the vehicle. In case, a negative response is received from User-A or User-C or both in response to send notifications, then the authentication server will send a negative sever response to the VCU of the Vehicle-A. In case, no response is received from User-A or User-C or both until a predetermined time period from the time when notifications are sent to User-A and User-C, then the authentication server will send a negative server response to the VCU of the Vehicle-A. On receiving the negative response from the authentication server, the VCU of the Vehicle-A will disable its power-train. Alternatively, on receiving the negative response, the VCU enables its power train with limited functionality, for example vehicle will not be allowed to run more than 20 km/hr speed and not allowed to cover more than 40 Km distance. Alternatively, in the case of negative response, the authentication server can disable the old battery from being used in any of the vehicles, such measure ensures that if battery swapping is done with the intention of theft of old battery then the old battery will be of no use for the stealer.

[0061] Without limiting the scope of the present disclosure, the foregoing paragraph explains another real life situation in which one of the embodiments of the present disclosure can be used. For example, User-A owns two vehicles (Vehicle-A and Vehicle-B), and User-A replaces the battery of the Vehicle-A with the battery of the Vehicle-B. Firstly, the VCU of the Vehicle-A will check whether the Battery_ID of the newly inserted battery lies in its internal database. If a match is found, Vehicle-A is allowed to run. If a match is not found, then the Battery_ID of the newly inserted battery and V_ID of the Vehicle- A is sent to the authentication server. The authentication server checks its internal database, if a match is not found, it sends two notifications to the User-A, one for the authorizing the V_ID and other notification for authorizing the Battery_ID. On receiving positive response for both of the sent notifications, a positive server response sends to Vehicle- A else a negative server response sends to the Vehicle- A.

[0062] Without limiting the scope of the present disclosure, the foregoing paragraph explains yet another real life situation in which one of the embodiments of the present disclosure can be used. For example, User-A owns Vehicle-A, and goes to a swapping station for replacing its battery. The User-A put the old battery in the swapping station. The swapping station reads Battery_ID from the old battery and queries the battery authentication server about the V_ID on which the old Battery_ID is mapped. Further, the swapping station swaps the old battery with a new battery and provides the new Battery_ID corresponding to the V_ID, to the battery authentication server. The battery authentication server in this particular case is of non-proactive in nature which means upon receiving the new Battery_ID from the swapping station, the server does not proactively provide the new Battery _ID to the Vehicle-A. When the user inserts the newly picked battery in the Vehicle-A, it is checked internally in the vehicle database to see if a mapping exists. As the authentication server is of non-proactive nature, it did not provide the new Battery_ID to the Vehicle-A so Battery _ID certainly not going to match in the internal database of the Vehicle-A. Following this, the VCU of the Vehicle-A sends the Battery_ID of the new battery and the V_ID of the Vehicle-A to authentication server. The authentication server internally checks if the received Battery_ID mapped to the received V_ID. As server already received the mapping from the swapping station, thus batter-ID found to be mapped with V_ID. Following this, a notification is sent to the User-A to authorize the swapping. Notification is sent to ensure that the swapping is not performed by a third person without the agreement of the User-A. On receiving a positive response from the User-A, the authentication server sends a positive server response to the VCU of the vehicle-A else a negative server response is sent. [0063] A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the invention.

[0064] When a single device or article is described herein, it will be clear that more than one device/article (whether they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether they cooperate), it will be clear that a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the invention need not include the device itself.

[0065] Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present invention are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

[0066] While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

Reference Numerals

Claims

We Claim:

1. A method of performing battery authentication of a vehicle, the method comprising: receiving, by a battery authentication server, a battery identification number (Battery_ID) associated with a battery and a vehicle identification number (V_ID) associated with the vehicle, from a Vehicle Control Unit (VCU) of the vehicle; determining, by the battery authentication server, if the Battery_ID is mapped to the V_ID; and based on the determining, performing, by the battery authentication server, authentication of the battery for use in the vehicle; and based on the authentication, transmitting, by the battery authentication server, a server response to the VCU.

2. The method as claimed in claim 1 , wherein the server response is transmitted as one of ‘successful’ or ‘unsuccessful’.

3. The method as claimed in claim 1, wherein the Battery_ID and the V_ID are received at the battery authentication server when the Battery _ID does not match with a list of pre-stored Battery_IDs stored in the VCU.

4. The method as claimed in claim 2, upon determining that the Battery_ID is mapped to the V_ID, the method further comprising: transmitting, by the battery authentication server, a first authentication request to a first device associated with a user mapped to the V_ID; receiving, by the battery authentication server, a first user response from the first device in response to the first authentication request; and transmitting, by the battery authentication server, the server response as ‘successful’ upon receiving a ‘positive’ user response from the first device.

5. The method as claimed in claim 2, upon determining that the Battery_ID is not mapped to the V_ID, the method further comprising: transmitting, by the battery authentication server, a first authentication request to a first device associated with a user mapped to the V_ID; receiving, by the battery authentication server, a first user response from the first device in response to the first authentication request; transmitting, by the battery authentication server, a second authentication request to a second device associated with a user mapped to the Battery_ID; receiving, by the battery authentication server, a second user response from the second device in response to the second authentication request; and transmitting, by the battery authentication server, the server response as ‘successful’ upon receiving a ‘positive’ user response from the first device and a ‘positive’ user response from the second device; and mapping, by the battery authentication server, the Battery _ID to the V_ID upon receiving a ‘positive’ user response from the first device and a ‘positive’ user response from the second device.

6. The method as claimed in claim 4 or 5, the method further comprising: transmitting, the server response as ‘unsuccessful’ upon receiving one or more of the below responses: a ‘negative’ user response received form the first device; a ‘negative’ user response received form the second device; and a ‘negative’ user response from the first device and a ‘negative’ user response from the second device.

7. The method as claimed in claim 2, further comprises adding, by the VCU, the Battery_ID in the list of pre-stored Battery_IDs when the server response is received as ‘successful’.

8. The method as claimed in claim 2, further comprising: enabling, by the VCU, a power train of the vehicle, upon receiving a ‘successful’ server response from the battery authentication server; or preventing, by the VCU, from enabling the power train upon receiving an ‘unsuccessful’ server response from the battery authentication server.

9. A method of performing battery authentication in a vehicle, the method comprising: receiving, by a battery authentication server, a battery identification number (Battery_ID) associated with a battery and a vehicle identification number (V_ID) associated with the vehicle, from a Vehicle Control Unit (VCU) of the vehicle; transmitting, by the battery authentication server, a first authentication request to a first device associated with a user mapped to a Vehicle Identification number (V_ID) of the vehicle; transmitting, by the battery authentication server, a second authentication request to a second device associated with a user mapped to a Battery Identification number (Battery_ID) of a battery; performing authentication of the battery for use in the vehicle, by the battery authentication server; and based on the authentication, transmitting, by the battery authentication server, a server response as one of ‘successful’ and ‘unsuccessful’ to the VCU.

10. The method as claimed in claim 9, wherein performing authentication of the battery for use in the vehicle further comprising: receiving, by the battery authentication server, a first user response from the first device in response to the first authentication request; receiving, by the battery authentication server, a second user response from the second device in response to the second authentication request; transmitting the server response as ‘successful’ upon receiving a ‘positive’ user response from the first device and a ‘positive’ user response from the second device; and mapping the Battery lD to the V ID upon receiving a ‘positive’ user response from the first device and a ‘positive’ user response from the second device.

11. The method as claimed in claim 9, wherein the method further comprises: adding, by the VCU, the Battery_ID in the list of pre-stored Battery_IDs when the server response is received as ‘successful’.

12. The method as claimed in claim 9, wherein the method further comprising: enabling, by the VCU, a power train of the vehicle upon receiving the ‘successful’ server response from the battery authentication server; or disabling, by the VCU, the power train of the vehicle upon receiving the ‘unsuccessful server response from the battery authentication server’.

13. A system for performing battery authentication of a vehicle, the system comprising: a vehicle control unit (VCU); and a battery authentication server configured to: receive a battery identification number (Battery _ID) associated with a battery and a vehicle identification number (V_ID) associated with the vehicle, from the VCU of the vehicle; determine if the Battery_ID is mapped to the V_ID; perform an authentication of the battery for use in the vehicle, based on the determination; and transmit a server response as one of ‘successful’ and ‘unsuccessful’ to the VCU, based on the authentication; wherein the VCU is configured to: enable a power train of the vehicle upon receiving a ‘successful’ server response from the battery authentication server; or disable the power train of the vehicle upon receiving an ‘unsuccessful’ server response from the battery authentication server.

14. The system as claimed in claim 13, wherein the Battery_ID and the V_ID are received at the battery authentication server when the Battery _ID does not match with a list of pre-stored Battery_IDs stored in the VCU.

15. The system as claimed in claim 13, wherein upon determining that the Battery_ID is mapped to the V_ID, the battery authentication server is further configured to: transmit a first authentication request to a first device associated with a user mapped to the V_ID; receive a first user response from the first device in response to the first authentication request; and transmit the server response as ‘successful’ upon receiving a ‘positive’ user response from the first device.

16. The system as claimed in claim 13, wherein upon determining that the Battery_ID is not mapped to the V_ID, the battery authentication server is further configured to: transmit a first authentication request to a first device associated with a user mapped to the V_ID; receive a first user response from the first device in response to the first authentication request; transmit a second authentication request to a second device associated with a user mapped to the Battery_ID; receive a second user response from the second device in response to the second authentication request; transmit the server response as ‘successful’ upon receiving a ‘positive’ user response from the first device and a ‘positive’ user response from the second device; and map the Battery lD to the V ID upon receiving a ‘positive’ user response from the first device and a ‘positive’ user response from the second device.

17. The system as claimed in claim 13, wherein the VCU is configured to add the Battery_ID in the list of pre-stored Battery_IDs when the server response is received as ‘successful’.

18. A system for performing battery authentication of a vehicle, the system comprising: a vehicle control unit (VCU); and a battery authentication server configured to: receive a battery identification number (Battery _ID) associated with a battery and a vehicle identification number (V_ID) associated with the vehicle, from the VCU of the vehicle; transmit a first authentication request to a first device associated with a user mapped to the V_ID of the vehicle; transmit a second authentication request to a second device associated with a user mapped to the Battery_ID of the battery; perform an authentication of the battery for use in the vehicle; and transmit a server response as one of ‘successful’ and ‘unsuccessful’ to the VCU, based on the authentication; wherein the VCU is configured to: enable a power train of the vehicle upon receiving the

‘successful’ server response from the battery authentication server; or disable the power train of the vehicle upon receiving the

‘unsuccessful’ server response from the battery authentication server.

19. The system as claimed in claim 18, wherein to perform the authentication, the battery authentication server is further configured to: receive a first user response from the first device in response to the first authentication request; receive a second user response from the second device in response to the second authentication request; transmit the server response as ‘successful’ upon receiving a ‘positive’ user response from the first device and a ‘positive’ user response from the second device; and map the Battery lD to the V ID upon receiving a ‘positive’ user response from the first device and a ‘positive’ user response from the second device.

20. The system as claimed in claim 18, wherein the VCU is configured to: add the Battery _ID in the list of pre-stored Battery_IDs when the server response is received as ‘successful’.