A method and a device to enable autocharge technology

Abstract

Example embodiments provide a method for enabling Autocharge technology. A device (200) is configured to obtain a first list of vehicle identifiers, wherein each vehicle identifier is linked to user information; determine that a vehicle identifier is static if a same user information is linked to the vehicle identifier at least a first predetermined number of times on the first list; determine that the vehicle identifier is unique if, within a certain number of vehicle identifiers on the first list, the vehicle identifier is listed at least a second predetermined number of times, and wherein the vehicle identifier is each time linked to the same user information; and enable authorization to start charging at charging stations based on the vehicle identifiers determined to be both static and unique Devices, methods, and computer programs are disclosed.

Description

[0001] A METHOD AND A DEVICE TO ENABLE AUTOCHARGE

[0002] TECHNOLOGY

[0003] TECHNICAL FIELD

[0004] The present application generally relates to electric vehicle charging. Some example embodiments of the present application relate to an automatic process for enabling Autocharge-technology.

[0005] BACKGROUND

[0006] When drivers want to charge their electric vehicles on a charging station, they may need to be authorized so that an operator of a charging station management system knows who is using the charging station - this info is needed for example so that the operator can invoice the driver for charging. A common way to authorize drivers are RFID tags and mobile applications. In addition, one of the used authorization technologies is called Autocharge, With Autocharge technology, drivers of electric vehicles can be authorized simply by connection of a charging cable from a charging station to the electric vehicle, without a need to use RFID tags or mobile applications.

[0007] SUMMARY

[0008] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0009] Example embodiments may enable automating the process of activating the Autocharge function for users. A method is provided for automatic detection of an electric vehicle supporting the Autocharge function, and further, for enabling activation of the Autocharge function with reduced user interaction.

[0010] According to a first aspect, a device is provided. The device comprises at least one processor; and at least one memory comprising instructions which, when executed by the at least one processor, cause the device at least toobtain a first list of vehicle identifiers, wherein each vehicle identifier is linked to user information;; determine that a vehicle identifier is static if a same user information is linked to the vehicle identifier at least a first predetermined number of times on the first list; determine that the vehicle identifier is unique if, within a certain number of vehicle identifiers on the first list, the vehicle identifier is listed at least a second predetermined number of times, and wherein the vehicle identifier is each time linked to the same user information; and enable authorization to start charging at charging stations based on the vehicle identifiers determined to be both static and unique.

[0011] In an embodiment, the memory comprises instructions which, when executed by the at least one processor, cause the device to detect when a rejected authorization request and an accepted authorization request to start charging at a same charging station are received consecutively within a certain period, and wherein the rejected authorization request comprises a vehicle identifier and the accepted authorization request comprises a second type of identifier linked to user information; store the vehicle identifier of the rejected authorization request to the first list, wherein the vehicle identifier is linked to the user information based on the accepted authorization request.

[0012] In an embodiment, the vehicle identifier is a media access control, MAC, address of an electric vehicle.

[0013] In an embodiment, in addition or alternatively, the at least one memory comprises instructions which, when executed by the at least one processor, cause the device to receive an indication from a user that the user wants to enable authorization based on vehicle identifier; determine if the user is linked with at least one of the static and unique vehicle identifiers based on the user information; and store the at least one static and unique vehicle identifier as an identifier to be used for authorization for the user.

[0014] In an embodiment, in addition or alternatively, the at least one memory comprises instructions which, when executed by the at least one processor, cause the device to receive an indication from the user that the user wants to disable the authorization based on vehicle identifier; and deactive the at least one vehicle identifier stored as the identifier for authorization for the user.

[0015] In an embodiment, in addition or alternatively, the at least one memory comprises instructions which, when executed by the at least one processor, cause the device to receive an indication from the user to enable the authorization based on vehicle identifier; and activate the vehicle identifier stored as the identifier for authorization for the user if it was deactivated.

[0016] In an embodiment, in addition or alternatively, at least one of the first predetermined number of times or the second predetermined number of times is at least two times. In an embodiment, in addition or alternatively, the second predetermined number of times is increased when the used certain number of vehicle identifiers on the first list is increased.

[0017] In an embodiment, in addition or alternatively, the at least one memory comprises instructions which, when executed by the at least one processor, cause the device to check if the static and unique vehicle identifier associated with the user has not been previously added to the user as the identifier to be used for authorization; and if not, store the vehicle identifier as the identifier to be for authorization.

[0018] In an embodiment, in addition or alternatively, the at least one memory comprises instructions which, when executed by the at least one processor, cause the device to store a second list comprising the vehicle identifiers determined to be both static and unique and linked with the respective user information; update the second list at predetermined intervals based on the first list; and enable the authorization to start charging at charging stations based on the second list.

[0019] In an embodiment, in addition or alternatively, the indications are received via at least one of a mobile application or a web page.

[0020] In an embodiment, in addition or alternatively, the at least one memory comprises instructions which, when executed by the at least one processor, cause the device to detect simultaneous charging transactions at different charging stations, wherein the same vehicle identifier is used for authorization; and when detected, at least one of remove the vehicle identifier from the second list, disable authorization based on the vehicle identifier or alert an operator.

[0021] In an embodiment, in addition or alternatively, the at least one memory comprises instructions which, when executed by the at least one processor, cause the device to detect that a same vehicle identifier has been used for authorization at two different charging stations and wherein a distance between the charging stations divided by time between the authorizations is above a threshold; and when detected, at least one of remove the vehicle identifier from the second list, disable authorization based on the vehicle identifier or alert an operator.

[0022] In an embodiment, in addition or alternatively, the at least one memory comprises instructions which, when executed by the at least one processor, cause the device to perform the detections related to the use of the same vehicle identifier for authorizations at least one of when a new charging transaction is started with a vehicle identifier or periodically.

[0023] According to a second aspect, a computer-implemented method for enabling Autocharge technology is provided. The method comprisesobtaining a first list of vehicle identifiers, wherein each vehicle identifier is linked to user information;; determining that a vehicle identifier is static if a same user information is linked to the vehicle identifier at least a first predetermined number of times on the first list; determining that the vehicle identifier is unique if, within a certain number of vehicle identifiers on the first list, the vehicle identifier is listed at least a second predetermined number of times, and wherein the vehicle identifier is each time linked to the same user information; and enabling authorization to start charging at charging stations based on the vehicle identifiers determined to be both static and unique.

[0024] According to a third aspect, a computer program is provided, comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of the second aspect.

[0025] Many of the attendant features will be more readily appreciated as they become better understood by reference to the following detailed description considered in connection with the accompanying drawings.

[0026] BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The accompanying drawings, which are included to provide a further understanding of the example embodiments and constitute a part of this specification, illustrate example embodiments and together with the description help to explain the principles of the example embodiments. In the drawings:

[0028] FIG. 1 illustrates an operating principle of the Autocharge technology;

[0029] FIG. 2 illustrates an example of a device configured to perform one or more example embodiments;

[0030] FIG. 3 illustrates an example of a database of vehicle identifiers linked to user accounts according to an example embodiment;

[0031] FIG. 4 illustrates another example of a database of vehicle identifiers linked to user accounts according to an example embodiment;

[0032] FIG. 5 illustrates an example of a process flow for linking unique and static vehicle identifiers to user accounts according to an example embodiment; FIG. 6 illustrates an example of a data model linking vehicle identifiers to users according to an example embodiment;

[0033] FIG. 7 illustrates an example of a flow chart to link vehicle identifiers and users according to an example embodiment;

[0034] FIG. 8 illustrates an example of a flow chart to enable or disable Autocharge function by a user according to an example embodiment;

[0035] FIG. 9 illustrates an example of a flow chart for error detection according to an example embodiment; and

[0036] FIG. 10 illustrates an example of a method for enabling Autocharge for a user according to an example embodiment.

[0037] Like references are used to designate like parts in the accompanying drawings.

[0038] DETAILED DESCRIPTION

[0039] Reference will now be made in detail to example embodiments, examples of which are illustrated in the accompanying drawings. The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present examples may be constructed or utilized. The description sets forth the functions of the example and a possible sequence of operations for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

[0040] Autocharge function is a mechanism currently used for automatic charging start and authorization of electric vehicle based on a vehicle identifier. FIG. 1 illustrates an operating principle of the Autocharge technology. The vehicle identifier may be some unique identifier that can be read by a charging station 104 when a connector of the charging station is plugged in to the electric vehicle 106. The vehicle identifier may be, for example, a MAC (media access control) address assigned to the electric vehicle 106. In general, charging stations (CS) are used to charge electric vehicles (EV). Charging stations can be connected to a Charging Station Management System (CSMS) with OCPP protocol, or with other similar communication protocols.

[0041] After the vehicle identifier is read by the charging station 104, the charging station 104 may automatically send an authorization request with the vehicle identifier of the electric vehicle 106 to a device 100 configured to manage charging operations of the charging station. The device 100 may comprise the CSMS. The device 100 may then check if an identifier of the authorization request, which in this case is the MAC address, is linked to any user account in a database 102. For example, if the MAC address of the electric vehicle 106 is MAC = 11 :22:33:AA:BB, the charging station 104 may send the authorization request with a vehicle identifier based IdToken VID:112233AABB. An IdToken refers to an identifier for authorization or user authentication. The device 100 may then check that the IdToken VID: 112233AABB is linked with a user “Alice”. After the linked user account (or other user information identifying a person 108 who wants to start charging) is found, the device 100 can accept the authorization request and charging can start at the charging station 104.

[0042] In order for the Autocharge to work, an electric vehicle may need to have a unique and static vehicle identifier. However, not all electric vehicle manufacturers provide unique and static MAC addresses, or other used vehicle identifiers. Some electric vehicle models randomize the MAC addresses between charging sessions. An electric vehicle may thus provide a new MAC address each time it is connected to a charging station. If the MAC address does not stay the same between charging sessions, it may not be possible to use the Autocharge function with the electric vehicle. Further, some electric vehicle models have the same static MAC address for several different electric vehicles. If two different electric vehicles have the same MAC address, it may not be possible to use the MAC address to identify a unique electric vehicle. Also in this case, the Autocharge function may not be used by the electric vehicle.

[0043] Another requirement for Autocharge to work correctly is that the CSMS system may need information on which MAC address belongs to which user. However, MAC addresses are not public information: users may not know what is the MAC address of their electric vehicle. Therefore, the users may not just manually type the MAC address to a mobile application or some other similar place to notify the information for the CSMS.

[0044] One approach to enable the Autocharge function is to use a workflow in a mobile application. First, the user is asked to login to the mobile application to obtain an identity of the user. The mobile application then asks for a model of an electric vehicle of the user. Based on the model, the mobile application can check if that model supports the Autocharge function. Next, the user is asked to drive to a charging station and start charging using the mobile application. The mobile application (or CSMS behind the mobile application) can then read the MAC address for example from standard OCPP messages, read the identity of the user from the login information, and combine the identity of the user with the read MAC address.

[0045] In the mobile application-based approach, the CSMS may need to keep a manually updated database of electric vehicle models compatible with the Autocharge function. As new electric vehicle models can come to the market all the time, and as there are hundreds of different electric vehicle models available, keeping this model database up to date can be difficult. Users may also enter a wrong model by error, which may result in problems with the Autocharge.

[0046] In addition, requesting users to go through the workflow in the mobile application can be difficult for many users. Not all charging stations support the Autocharge function, so first the user needs to find a charging station that supports the technology. Next, the user needs to do actions in the right order (first connect charging cable, then start charging from the mobile application etc.). Even if the mobile application would direct the user through the process, a complex process often feels too difficult to many non-technical people. Further, if a user has more than one electric vehicle (for example, a family might have two electric vehicles), the users need to go through the Autocharge process with the mobile application every time for each electric vehicle.

[0047] An objective is to enable the Autocharge function for users in an easier way. An example embodiment provides a statistical method to determine which MAC addresses of electric vehicles are unique and static, and hence, can be used for the Autocharge function. The static and unique MAC addresses can be detected automatically such that a user of the respective electric vehicle can activate the Autocharge function for the electric vehicle with a single click. Further, error detection algorithms to provide a further verification that a MAC address is unique and static are provided.

[0048] With the statistical model, there is no need to maintain a database of electric vehicle models compatible with the Autocharge function. Instead, electric vehicles supporting the Autocharge function can be detected automatically. Further, users are not required to physically go to a charging station and enable the Autocharge function through a multi-step dialogue in a mobile application. Instead, the Autocharge mechanism can be also enabled for users who start charging using an RFID tag or the like. With the automated detection, the user is not required to, for example, tell what electric vehicle model they are using. Enabling the Autocharge function can be performed more automatically in the background with reduced user interaction. The user can simply indicate that they wish to enable Autocharge, and the method performs the rest, including detecting compatibility of the electric vehicle of the user for the Autocharge function and thereafter activating the Autocharge function for the user. The method may not require users to enable Autocharge separately for each electric vehicle they are using. Instead, the Autocharge function can be enabled automatically to all compatible electric vehicles a user has.

[0049] FIG. 2 illustrates an example of a device 200 configured to perform one or more example embodiments.

[0050] The device 200 may comprise at least one processor 202. The at least one processor 202 may comprise, for example, one or more of various processing devices, such as for example a co-processor, a microprocessor, a controller, a digital signal processor (DSP), a processing circuitry with or without an accompanying DSP, or various other processing devices including integrated circuits such as, for example, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a microcontroller unit (MCU), a hardware accelerator, a special-purpose computer chip, or the like.

[0051] The device 200 may further comprise at least one memory 204. The at least one memory 204 may be configured to store, for example, computer program code 206 or the like, for example operating system software and application software. The at least one memory 204 may comprise one or more volatile memory devices, one or more non-volatile memory devices, and / or a combination thereof. For example, the memory may be embodied as magnetic storage devices (such as hard disk drives, magnetic tapes, etc.), optical magnetic storage devices, or semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash ROM, RAM (random access memory), etc.).

[0052] The device 200 may further comprise a communication interface 208 configured to enable the device 200 to transmit information to other devices, such as to charging stations and / or mobile devices. The communication interface 208 may be further configured to enable the device 200 to receive information from other devices, such as the charging stations, mobile devices, and the like. The communication interface 208 may be configured to provide at least one wireless radio connection, such as for example a 3GPP mobile broadband connection (e.g. 3G, 4G, 5G, or beyond). However, the communication interface 208 may be configured to provide one or more other type of connections, for example a wireless local area network (WLAN) connection such as for example standardized by IEEE 802.11 series or Wi-Fi alliance; a short range wireless network connection such as for example a Bluetooth, NFC (near-field communication), or RFID connection; a wired connection such as for example a local area network (LAN) connection, a universal serial bus (USB) connection or an optical network connection, or the like; or a wired Internet connection. The communication interface 208 may comprise, or be configured to be coupled to, at least one antenna to transmit and / or receive radio frequency signals. One or more of the various types of connections may be also implemented as separate communication interfaces, which may be coupled or configured to be coupled to a plurality of antennas.

[0053] The device 200 may further comprise or be coupled to a user interface 210 comprising an input device and / or an output device. The input device may comprise, for example, one or more buttons, a keyboard, a microphone, a touch screen, or the like. The input device may be configured to provide user inputs to the device 200, for example, to change one or more settings or parameters for performing detection of static and unique vehicle identifiers and / or error detection algorithms. The output device may comprise, for example, a display, a speaker, or the like. The output device may be configured to provide data to an operator about at least one of detected static and unique vehicle identifiers, configurations performed based on the detected static and unique vehicle identifiers, detected errors, or charging transactions related data for invoicing purposes.

[0054] When the device 200 is configured to implement some functionality, some component and / or components of the device 200, such as for example the at least one processor 202 and / or the at least one memory 204, may be configured to implement this functionality. Furthermore, when the at least one processor 202 is configured to implement some functionality, this functionality may be implemented using program code 206 comprised, for example, in the at least one memory 204.

[0055] The device 200 may be configured to determine which received vehicle identifiers are both static and unique. The device 200 may be further configured to detect the static and unique vehicle identifiers based on rejected authorization requests with vehicle identifiers and accepted authorization requests with other types of identifiers, wherein the rejected authorization request and the accepted authorization request are received one after the other within a set period of time.

[0056] For example, when an electric vehicle of a user is plugged in to a charging station, the charging station receives a vehicle identifier from the EV and sends authorization request with the vehicle identifier to the device 200. When the vehicle identifier is not linked to any user, the device 200 rejects the authorization request. Thereafter, the user initiates charging e.g. by showing a RFID card / tag to a reader of the charging station or starts charging via a dedicated mobile application. The device 200 therefore receives a new authorization request related to the same charging station with an identifier linked to the user, and accepts the authorization request. The device 200 may determine that the two authorization requests are associated with the same user, when they are received within the set period of time. The device 200 can store the linked identifiers and related user information to a first list for further analysis.

[0057] Alternatively, the device 200 can be configured to receive the first list from another device, wherein the other device is configured to perform the analysis of the authorization requests. The device 200 may then determine if a vehicle identifier is static and unique based on the received first list of vehicle identifiers, wherein each vehicle identifier is linked to user information. The user information may comprise some identification information of a respective user, such as an identifier or name of the user.

[0058] If there are enough authorization requests with the same vehicle identifier linked to the same user, and if there are enough authorization requests with the same vehicle identifier all being linked to the same user, the device 200 may conclude that the vehicle identifier is both static and unique. Then, the device 200 may check if the user has enabled the Autocharge function. If the user has indicated that she / he wants the Autocharge function to be enabled and the user is linked to the static and unique vehicle identifier, the device 200 may set the vehicle identifier as an identifier for user authentication (i.e., an IdToken).

[0059] The device 200 may periodically search for static and unique vehicle identifiers from the first list, and store them to a second list of static and unique identifiers. Once the user indication is received, the device 200 can check from the second list if the user is linked to a static and unique vehicle identifier to activate the Autocharge function. Alternatively, the device 200 can be configured to check from the first list if the user who wants to enable the Autocharge function is linked with a vehicle identifier that can be considered to be both static and unique. Thereafter, authorization requests received with the vehicle identifier can be accepted by the device 200 because the vehicle identifier is now linked with the user and also determined to be both static and unique. Hence, the Autocharge function is enabled to work correctly (the used vehicle identifier is static and unique) and bills can go for the right user (the vehicle identifier is linked to user information). Importatly, enabling the Autocharge function is made easy for the user as most of the process is automatically performed by the device 200. To increase reliability, the device 200 may be further configured to detect if some vehicle identifier has been erroneously stored as a static and unique vehicle identifier. The device 200 may be configured to detect if there are multiple simultaneously ongoing charging transactions initiated with the same vehicle identifier. The device 200 may be further configured to detect if there have been consecutive charging transactions initiated with the same vehicle identifier at different charging stations, and wherein geographical locations and timestamps of the charging transactions are such that the same electric vehicle could not have been charging at the different charging stations. When detecting either of the indications for an error, the device 200 can be configured to disable use of the vehicle identifier for authocharge.

[0060] The functionality described herein may be performed, at least in part, by one or more computer program product components such as software components. According to an embodiment, the apparatus comprises a processor or processor circuitry, such as for example a microcontroller, configured by the program code when executed to execute the embodiments of the operations and functionality described. Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), application-specific Integrated Circuits (ASICs), application-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), Graphics Processing Units (GPUs).

[0061] The device 200 comprises means for performing at least one method described herein. In one example, the means comprises the at least one processor 202, the at least one memory 204 including program code 206 configured to, when executed by the at least one processor 202, cause the device 200 to perform the method. The program code 206 may comprise instruction which, when executed by the at least one processor 202, cause the device 200 to perform at least one method described herein.

[0062] The device 200 may comprise for example a computing device such as for example a server, a mobile phone, a tablet computer, a laptop, or the like. Although the device 200 is illustrated as a single device it is appreciated that, wherever applicable, functions of the device 200 may be distributed to a plurality of devices. In one example, the device 200 may comprise a CSMS server device. In an embodiment, the device 200 may operate in the cloud. FIG. 3 illustrates an example of a database of vehicle identifiers linked to user accounts according to an example embodiment. The database may be gathered and stored by a computing device, such as the device 200.

[0063] The device 200 may be configured to store authorization requests to a database. The authorization requests are obtained from one or more charging stations. The authorization requests may comprise different kinds of identifiers for authorization, such as vehicle identifiers, RFID tag numbers, identifiers submitted to a mobile application, and the like. Communication between the device 200 and the one or more charging stations may be performed based on an OCPP protocol, for example.

[0064] As described, when a user connects a charging cable between an electric vehicle and a charging station, the charging station may be configured to send a vehicle identifier obtained from the electric vehicle in an authorization request to the device 200. The vehicle identifier may be, for example, a MAC address of the electric vehicle. The device 200 maybe then configured to reject the authorization request when the MAC address is not linked to any user account.

[0065] Next, the device 200 may receive a new authorization request with a RFID tag number from the same charging station. The new authorization request may be received within a short period from reception of the authorization request with the MAC address, let’s say within 12 seconds in this example. The device 200 may know that the RFID tag number belongs to a certain user and accepts the new authorization request. When the successful authorization happened within a certain period from the reception of the authorization request with the MAC address, the device 200 may conclude that the MAC address belongs to the same user who owns the RFID tag. The certain period may be relatively short, such as 30 seconds. However, the period within which the rejected and accepted authorization requests are linked may depend on configuration of the device 200. Further, the period may be changed, for example, by an operator of the device 200. The period may be configured, for example, based on an average or estimated time that a user usually spends on a charging station to initiate charging.

[0066] As previously described, in addition to knowing which MAC address is associated with which user, the MAC address received from the EV may need to be also unique and static so that it can be used for Autocharge.

[0067] The device 200 may be configured to use statistical data to determine which MAC addresses received from EVs are static and unique. Hence, there is no need to store for example EV model databases for the information or obtain data of a model of the electric vehicle of a user. The device 200 may be configured to create based on the database with the authorization requests, a database 300 of vehicle identifiers that were sent to the device 200 before a related successful authentication using another type of an identifier as described (i.e., the vehicle identifier is being linked to a user account based on the subsequently received new authorization request), such as RFID or mobile application based identifier.

[0068] The database 300 may comprise a list of vehicle identifiers, such as MAC addresses. The list of vehicle identifiers may comprise one or more MAC addresses. The list of vehicle identifiers may comprise MAC addresses comprised in rejected authorization requests.

[0069] The database 300 may further comprise a list of other identifiers. The other identifiers may be unique identifiers associated to users. The list of other identifiers may comprise one or more unique identifiers. The unique identifiers may comprise, for example, identifiers received from a RFID tag or a mobile application. The list of other identifiers may be obtained from accepted authorization requests received within the certain period from reception of one of the rejected authorization requests with a MAC address. The device 200 may be further configured to check if the accepted authorization request was received from a same charging station as the rejected authorization request. In addition, or alternatively, the database 300 may comprise a list of users linked with identifiers of the accepted authorization requests.

[0070] In other words, the database 300 may be configured to comprise one or more MAC addresses paired with user information based on certain criteria. Data on the database 300 may be based on, for example, the different types of identifiers linked based on outcome of the related authorization requests within the certain period and / or that they are received from the same charging station. The database 300 may further comprise timestamps of reception of the MAC addresses.

[0071] In the example database 300 of FIG. 3, there are two charges made by Alice (rows 1 and 3). The database 300 can comprise at least one of an identifier linked to the user (and obtained from the accepted authorization request, e.g. A1B2C3D4 for Alice) or other user information retrieved based on the identifier, such as the name of the user. Both rows have the same MAC address (VID: 112233AABB). From this information, it can be known that Alice’s EV has a static MAC address that does not change between charges. In the example database 300, there are also two charges that belong to Bob (rows 2 and 4). On those rows one can see a different MAC address (VID:55AA66BB77 and VID:22EE11AAB1), which is an indicator that Bob’s EV does not have a static MAC address. The device 200 can be configured to determine, based on a content of the database 300, that a MAC address is static if the same user information is linked in more than N events with the same MAC address. In an embodiment, N may be at least two events. In order to increase reliability, the limit for the number of events before the MAC address is considered to be static can be increased. The limit N can be set to, for example, N=5, meaning that at least five charges with the same MAC address on the same user needs to be detected by the device 200, so that it is trusted that MAC address is static. However, N can be also given other values depending on, e.g., a size of the database or a desired level of accuracy.

[0072] FIG. 4 illustrates another example of a database 300 of vehicle identifiers linked to user accounts according to an example embodiment. The database 300 may be gathered similar to the database 300 in FIG. 3. By looking at content of the example database 300 in FIG. 4, there is a MAC address VID:112233AABB (rows 1,3) and it belongs to Alice in each of the rows 1 and 3. So, it may be determined that no other users than Alice use that MAC address, meaning the MAC address most likely is unique. At the same time, there is a second MAC address VID:55AA66BB77 (rows 2, 4). The second MAC address belongs to two different users, Bob and Cecilia based on the database 300. This means, that the second MAC address is most likely not unique.

[0073] The device 200 may be configured to determine that a MAC address is unique if the database 300 comprises at least N occurrences of the MAC address and they all are linked to the same user information, wherein a sample size of the database is at least X records. In an embodiment, reliability can be increased by requiring higher X and N. For example, the device 200 may be configured such that the database 300 should comprise a sample size of at least X= 10000 records of charges, and among the X records, there should be at least N=5 occurrences of the same MAC address, and all those occurrences should belong to the same user based on the linked user information. The records of charges may refer to the linked rejected and accepted authorization requests. Value of N may be selected to be the same as when determining if a vehicle identifier is static, or different values of N can be used for indication of a static and a unique vehicle identifier.

[0074] When a vehicle identifier is determined to be both static and unique, the vehicle identifier may be stored by the device 200 to a database of static and unique vehicle identifiers. The database of static and unique vehicle identifiers comprises a list of the stored vehicle identifiers linked to the user information based on which the vehicle identifier was determined to be static and unique. The database of static and unique vehicle identifiers may comprise at least a subset of records of the database 300, filtered based on the criteria for static and unique vehicle identifiers. The database of static and unique vehicle identifiers may comprise at least an indication of a user linked with the static and unique vehicle identifier.

[0075] FIG. 5 illustrates an example of a process flow for linking unique and static vehicle identifiers to user accounts according to an example embodiment. The described process may be implemented with a computing device, such as the device 200.

[0076] The device 200 may be configured to obtain an indication to enable Autocharge for a user. The indication may be received via a user interface. The indication may be received, for example, from a mobile application, at 500, or from a web page, at 502. For example, in the mobile application, a user can enable and / or disable the Autocharge simply by selecting one checkbox. The indication (i.e., ticking the checkbox) can be then received by the device 200 via the mobile application. The user may have first logged in to the mobile application, and hence, the device 200 knows for which user to enable (or disable) the Autocharge function. In case the user does not have the mobile application, or does not want to use it, the user can enable the Autocharge in a registration form on the web page. On the web page, the user may provide their user information and enable the Autocharge function for example simply by ticking a selection box, pressing a button, or the like. In both cases, there is no need to ask for a model of an electric vehicle of the user, or to request the user to go to an Autocharge-compatible charging station. All that may be needed from the user is the information that they want to use the Autocharge function / technology. The received indication is associated with some user information such that the device 200 knows for which user to initiate the process.

[0077] At 504, the device 200 may check if there is data about a static and unique vehicle identifier linked with the user. The device 200 may check this information, for example, based on the database 300. For example, a database of static and unique vehicle identifiers created based on the database 300 may comprise a static and unique MAC address 11 :22:33 :44:55 linked to a user “Alice”. If one or more static and unique vehicle identifiers linked with the user who wanted to enable the Autocharge is found, the device 200 can be configured to add the vehicle identifier as an IdToken for the user to an IdToken database, at 506.

[0078] For example, at 500 or 502, the user “Alice” may have indicated that she wants to enable Autocharge, The device 200 then checks that the user “Alice” is linked with the static and unique MAC address 11 :22:33:44:55. Thereafter, the device 200 can add the MAC address as an identifier for authorization to said user, e.g. VID (vehicle identifier): 1122334455 is linked with “Alice” in the IdToken database. The IdToken database may comprise one or more pairs of vehicle identifiers linked with user information according to the described process. The IdToken database may further comprise other types of identifiers linked to the user for authorization purposes, such as a RFID tag number of the user. The device 200 can be configured to check the database 300 and / or the database of static and unique vehicle identifiers periodically, such as once an hour, to see if there are any static and unique MAC addresses linked to the user. Further, the database 300 may be continuously or periodically updated based on new received authorization requests.

[0079] FIG. 6 illustrates an example of a data model linking vehicle identifiers to users according to an example embodiment.

[0080] At 600, a computing device, such as the device 200, is configured to store user information of one or more users. The user information may comprise identification data of registered EV drivers. The user information may comprise, for example, at least one of a name of a registered EV driver as a string or an identification number of the EV driver.

[0081] At 602, the device 200 may be configured to store information about enabled and / or disabled Autocharge functions by the users. The information may comprise, for example, in a Boolean form an indication if a specific user has enabled the Autocharge. The information may further comprise a timestamp when the Autocharged was enabled by the user. The timestamp may comprise date and time information. The information may further comprise a timestamp of a disabled Autocharge function if the user has indicated to disable the Autocharge. The indications may be received via a user interface, for example, based on a checked or unchecked checkbox by the user. Of course, instead of a checkbox, the indication may be provided by the user via any other user interface element configured for the purpose.

[0082] At 604, the device 200 may be configured to store a list of IdTokens. Each IdToken may be associated with one of the EV drivers. An EV driver may be associated with one or more IdTokens. The IdTokens may be in a string form. The list may comprise one or more types of IdTokens, such as RFID, mobile application or vehicle identifier based IdTokens. As mentioned, IdTokens, or identification tokens, refer to identifiers used for authentication. IdTokens may be used in tokenbased authentication to cache user information. The list of IdTokens may also comprise information about whether the IdToken is currently active or not, e.g. by a boolean value of true or false.

[0083] At 606, the device 200 may be configured to store a list of static and unique vehicle identifiers, such as MAC addresses. The MAC addresses may have a string value. Each MAC address may be linked to a specific EV driver, and the list may comprise at least part of the user information stored for the EV driver, such as an identifier number of the EV driver. The list may further comprise timestamps indicating when the MAC address was stored on the list.

[0084] At 608, the device 200 may be configured to store information about processed authorization requests. The device 200 may store information at least about authorization requests rejected based on a vehicle identifier included in the request and about authorization requests approved based on another type of an identifier included in the request. When an approved and rejected authorization requests are received within a certain timeframe, they are added to a database linking vehicle identifiers (MAC addresses) of rejected authorization requests to user information obtained based on the approved authorization requests.

[0085] The device 200 may be configured to use the data model to link MAC addresses to EV drivers. For example, the device 200 may be configured to determine information at 606 based on the information stored at 600, 604 and 608. The device 200 may be configured to determine the information at 608 based on information stored at 600 and 604. The device 200 may be configured to store the information at 604 based on the information stored at 600, 602, 606 and / or 608.

[0086] FIG. 7 illustrates an example of a flow chart to link vehicle identifiers and users according to an example embodiment. The process illustrated by the flow chart may be performed, for example, by the device 200. The process may be repeated periodically. The process may be performed automatically, for example, every Y minutes, where Y is a value configured for the repetition.

[0087] At 700, the device 200 may be configured to find new static and unique MAC addresses (or other used vehicle identifiers) added since a last run. The new static and unique MAC addresses may be searched from a stored database with the static and unique MAC addresses linked with user information. Alternatively, the new static and unique MAC addresses may be searched from the database 300 based on the set criteria. The databases may be compiled and updated by the device 200.

[0088] At 702, the device 200 may be configured to check for each of the new static and unique MAC addresses if it can be added as an active IdToken for a user. At 704, the device 200 may check if the user linked with the static and unique MAC address has enabled the Autocharge function.

[0089] At 706, the device 200 may check if the MAC address has not yet been added as an IdToken to the user.

[0090] At 708, if the result of the checking operation both at 704 and 706 is true, the device 200 may be configured to add the static and unique MAC address as the IdToken for the user. Hence, next time an authorization request with the MAC address stored as the IdToken is received, the device 200 can accept the authorization based on the user linked with the MAC address.

[0091] FIG. 8 illustrates an example of a flow chart to enable or disable Autocharge function by a user according to an example embodiment. After the Autocharge function has initially been enabled by the user, the Autocharge function can also be temporarily disabled and / or enabled by the user.

[0092] At 800, a computing device, such as the device 200, receives an indication from a user to disable the (previously enabled) Autocharge function. The indication may be received from a user interface in response to a user input. For example, the user may have clicked a dedicated button in a mobile application communicating with the device 200.

[0093] At 802, the device 200 may be configured to set all vehicle identifier based IdTokens which are linked with the user who wants to disable the Autocharge function as deactivated. For example, an active status each IdToken of the user with a type MAC address may be set to “false”.

[0094] At 806, the device 200 may receive an indication from the user to enable the Autocharge function. The indication may be received via the user interface in response to a user input. For example, the user may have again clicked the dedicated button in the mobile application.

[0095] At 808, the device 200 may be configured to set all vehicle identifier based IdTokens which are linked with the user who wants to enable the Autocharge function as activated. For example, an active status each IdToken of the user with a type MAC address may be set to “true”.

[0096] At 804, the device 200 may receive an authorization request from a charging station comprising a MAC address for authorization. The device 200 can then check, if the MAC address is set as activated or deactivated. If the MAC address contained in the authorization request is active, the device 200 may decide to accept the authorization. If the MAC address is set as deactivated, the device 200 may decide to reject the authorization. FIG. 9 illustrates an example of a flow chart for error detection according to an example embodiment. The error detection may be implemented by a computing device, such as the device 200.

[0097] The method for enabling use of the Autocharge technology may rely on statistical data with a large number of charges. Even though the method may be reliable with a large amount of data, there is a chance that some MAC address tagged as static and unique is not that in reality. For example, when a new EV model comes on the market, the EV model can be configured to use the same MAC address for all the different EVs. During a first month, only one user may have enabled the Autocharge function for the new EV model. Because of this, all charges performed with the MAC address are linked to a single user and analysis shows the MAC address as static and unique even though in reality it is not unique. Then, in the next month two other users with the same EV model enable Autocharge. Since the MAC address is not unique (same for all EVs of the EV model), all charges performed with EVs of the two users would be linked to the user who was first to enable the Autocharge. Hence, the first user would need to pay for the charges of the later users. However, these kinds of situations may be avoided by utilizing at least one of timestamps related to charges or information about locations of the charging station where the charges were performed.

[0098] At 900, the device 200 may be configured to repeat the error detection periodically. The error detection may be performed, for example, every Z minutes, wherein Z is a value configured for the repetition interval.

[0099] At 902, the device 200 detects that a new charging transaction is started. This can be detected, for example, based on an accepted authorization request or a message received from a charging station indicative of a start of a charging transaction (e.g., status notification). In general, a charging transaction, or a charge, may refer to a charging occurrence for a single EV during which energy is transmitted from a charging station to the EV, measured in duration according to the time when the EV was plugged-in to the charging station to the time the EV is unplugged.

[0100] At 904, the device 200 may check if the charging transaction was started with Autocharge, that is, if the authorization request was accepted based on a vehicle identifier. If not, the device 200 may determine at 906 that there is no need to perform the error detection for that charging transaction.

[0101] If the charging transaction was started with Autocharge, the device 200 may be configured to check, at 908, if there is another charging transaction ongoing which has been started based on the same vehicle identifier. For example, the device 200 may check if the are two (or more) charging transactions active at the same time, and which two (or more) charging transactions have been authorized with the same MAC address. If the same MAC address is used to start charging on two different charging stations at the same time, it cannot be unique. If yes, the device 200 may detect an error and disable the Autocharge function for the MAC address used by multiple users at the same time.

[0102] If there are no multiple ongoing charging transactions started with the same MAC address, the device 200 may proceed to check, at 912, where the last charge with the same MAC address was previously made. If the same MAC address is used to start charging within a short period of time on two different stations that are too far from each other for an EV to travel that distance quickly enough, the MAC address may not be unique. For example, the device 200 may store identities and geographic coordinates of charging stations. One charging station can have several charging transactions. Each charging transaction has a timestamp telling when it was started. Each charging transaction may be started with an IdToken. If Autocharge was used to start a charging transaction, the IdToken is the vehicle identifier of the EV, such as the MAC address. The device 200 stores, or obtains, information about the timestamps and used IdTokens of the charging transactions. The device 200 knows from which charging station an authorization request is received from. Based on the timestamps, used IdTokens, and geographical coordinates of the charging station, the device 200 can determine where a charging transaction with the same MAC address as with the new charging transaction was last used.

[0103] At 914, the device 200 may detect if a same electric vehicle could not have been charging at different charging stations although charging has not been performed at the same time. The device 200 may determine a distance between the charging stations where the two charging transactions with the same MAC address were started. The device 200 may be configured to calculate a time between timestamps of the two charging transactions (e.g., based on authorization times of the charging transactions) and divide the distance by the calculated time. If the resulting speed value, at which speed the EV should have been driving from the first charging station to the second charging station such that the EV could have been able to be present at both of the charging stations during the charging transactions, is above a threshold, the device 200 can determine that there is an error. The threshold may be based on, for example, an average driving speed of electric vehicles or some other configured value which may be specific to the area. If the threshold is not exceeded, the device 200 can determine at 916 that no errors are detected. If the threshold is exceeded, the device 200 can determine at 910 that there is an error, and disable Autocharge for the MAC address (e.g., by setting the MAC address as deactivated in an IdToken database). In addition, the device 200 can be configured to alert an operator to investigate the detected errors. In addition, or alternatively, the device 200 can be configured to remove the MAC address from the list of static and unique vehicle identifiers.

[0104] FIG. 10 illustrates an example of a method 1000 for enabling Autocharge for a user according to an example embodiment. The method may be performed by a computing device, such as the device 200.

[0105] At 1002, the method may comprise obtaining a first list of vehicle identifiers, wherein each vehicle identifier is linked with user information. In an embodiment, the method may comprise detecting when a rejected authorization request and an accepted authorization request to start charging at a same charging station are received consecutively within a certain period, and wherein the rejected authorization request comprises a vehicle identifier and the accepted authorization request comprises a second type of identifier linked to user information. The method may further comprise storing the vehicle identifier of the rejected authorization request to the first list, wherein the vehicle identifier is linked to the user information based on the accepted authorization request. Alternatively, the method may comprise receiving the first list from a device configured to manage the authorization requests, such as a CSMS server.

[0106] At 1004, the method may comprise determining that a vehicle identifier is static if a same user information is linked to the vehicle identifier at least a first predetermined number of times on the first list.

[0107] At 1006, the method may comprise determining that the vehicle identifier is unique if, within a certain number of vehicle identifiers on the first list, the vehicle identifier is listed at least a second predetermined number of times, and wherein the vehicle identifier is each time linked to the same user information.

[0108] At 1008, the method may comprise enabling authorization to start charging at charging stations based on the vehicle identifiers determined to be both static and unique. In other words, the method enables use of the Autocharge function based on the vehicle identifiers determined to be static and unique at 1004 and 1006. In an embodiment, the method may further comprise receiving an indication from a user to activate the Autocharge function. In response to the indication, the method may comprise enabling use of at least one of the static and unique vehicle identifiers for authorization and user authentication when user information associated with the user is linked to the vehicle identifier.

[0109] It is obvious to a person skilled in the art that with the advancement of technology, the basic idea of the invention may be implemented in various ways. The invention and its embodiments are thus not limited to the examples described above, instead they may vary within the scope of the claims.

[0110] Further features of the methods directly result from the functionalities and parameters of the apparatus as described in the appended claims and throughout the specification and are therefore not repeated here. It is noted that one or more operations of the method may be performed in different order.

[0111] An apparatus may be configured to perform or cause performance of any aspect of the method(s) described herein. Further, a computer program may comprise instructions for causing, when executed, an apparatus to perform any aspect of the method(s) described herein. Further, an apparatus may comprise means for performing any aspect of the method(s) described herein. According to an example embodiment, the means comprises at least one processor, and memory including program code, the at one memory and the program code configured to, when executed by the at least one processor, cause performance of any aspect of the method(s).

[0112] Any range or device value given herein may be extended or altered without losing the effect sought. Also, any embodiment may be combined with another embodiment unless explicitly disallowed.

[0113] Although the subject matter has been described in language specific to structural features and / or acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as examples of implementing the claims and other equivalent features and acts are intended to be within the scope of the claims.

[0114] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages. It will further be understood that reference to 'an' item may refer to one or more of those items.

[0115] The operations of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Additionally, individual blocks may be deleted from any of the methods without departing from the scope of the subject matter described herein. Aspects of any of the embodiments described above may be combined with aspects of any of the other embodiments described to form further embodiments without losing the effect sought.

[0116] The term 'comprising' is used herein to mean including the method, blocks, or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or apparatus may contain additional blocks or elements.

[0117] The terms ‘automated’, ‘automatically’, ‘automatic’ and variations thereof, as used herein, may refer to any process or operation done without human input when the process or operation is performed. However, a process or operation can be automatic, even though performance of the process or operation uses human input, if the input is received before performance of the process or operation.

[0118] As used in this application, the term ‘circuitry’ may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry) and (b) combinations of hardware circuits and software, such as (as applicable) :(i) a combination of analog and / or digital hardware circuit(s) with software / firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation. This definition of circuitry applies to all uses of this term in this application, including in any claims.

[0119] As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0120] It will be understood that the above description is given by way of example only and that various modifications may be made by those skilled in the art. The above specification, examples and data provide a complete description of the structure and use of exemplary embodiments. Although various embodiments have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from scope of this specification.

Claims

CLAIMS1. A device (200), comprising: at least one processor (202); and at least one memory (204) comprising instructions which, when executed by the at least one processor (202), cause the device (200) at least to: receive, from one or more charging stations, authorization requests with different kinds of identifiers for authorization to start charging at the respective charging station; detect, based on the received authorization requests, when a rejected authorization request and an accepted authorization request to start charging at a same charging station are received consecutively within a certain period from the same charging station, and wherein the rejected authorization request comprises a vehicle identifier and the accepted authorization request comprises a second type of identifier linked to user information; store the vehicle identifier of the rejected authorization request to a first list of vehicle identifiers, wherein the vehicle identifier is linked to the user information based on the accepted authorization request; determine that a vehicle identifier is static if a same user information is linked to the vehicle identifier at least a first predetermined number of times on the first list, the first predetermined number of times comprising at least two times; determine that the vehicle identifier is unique if, within a certain number of vehicle identifiers on the first list, the vehicle identifier is listed at least a second predetermined number of times, the second predetermined number of times comprising at least two times, and wherein the vehicle identifier is each time linked to the same user information; enable authorization to start charging at charging stations based on the vehicle identifiers determined to be both static and unique; and accept authorization requests, received from the one or more charging stations, with the vehicle identifier determined to be both static and unique and linked to the user information on the first list.

2. The device (200) of claim 1 , wherein the vehicle identifier is a media access control, MAC, address of an electric vehicle.

3. The device (200) of any preceding claim, wherein the at least one memory (204) comprises instructions which, when executed by the at least one processor (202), cause the device (200) to:receive an indication from a user that the user wants to enable authorization based on vehicle identifier; determine if the user is linked with at least one of the static and unique vehicle identifiers based on the user information; and store the at least one static and unique vehicle identifier as an identifier to be used for authorization for the user.

4. The device (200) of claim 3, wherein the at least one memory (204) comprises instructions which, when executed by the at least one processor (202), cause the device (200) to: receive an indication from the user that the user wants to disable the authorization based on vehicle identifier; and deactive the at least one vehicle identifier stored as the identifier for authorization for the user.

5. The device (200) of claim 4, wherein the at least one memory (204) comprises instructions which, when executed by the at least one processor (202), cause the device (200) to: receive an indication from the user to enable the authorization based on vehicle identifer; and activate the vehicle identifier stored as the identifier for authorization for the user if it was deactivated.

6. The device (200) of any of claims 3 to 5, wherein the indications are received via at least one of a mobile application or a web page.

7. The device (200) of any preceding claim, wherein the second predetermined number of times is increased when the used certain number of vehicle identifiers on the first list is increased.

8. The device (200) of any of claims 3 to 7, wherein the at least one memory (204) comprises instructions which, when executed by the at least one processor (202), cause the device (200) to: check if the static and unique vehicle identifier associated with the user has not been previously added to the user as the identifier to be used for authorization; andif not, store the vehicle identifier as the identifier to be for authorization.

9. The device (200) of any preceding claim, wherein the at least one memory (204) comprises instructions which, when executed by the at least one processor (202), cause the device (200) to: store a second list comprising the vehicle identifiers determined to be both static and unique and linked with the respective user information; update the second list at predetermined intervals based on the first list; and enable the authorization to start charging at charging stations based on the second list.

10. The device (200) of claim 9, wherein the at least one memory (204) comprises instructions which, when executed by the at least one processor (202), cause the device (200) to: detect simultaneous charging transactions at different charging stations based on authorization requests received from the different charging stations, wherein the same vehicle identifier is used for authorization; and when detected, at least one of remove the vehicle identifier from the second list, disable authorization based on the vehicle identifier or alert an operator.

11. The device (200) of claim 9 or 10, wherein the at least one memory (204) comprises instructions which, when executed by the at least one processor (202), cause the device (200) to: detect that a same vehicle identifier has been used for authorization at two different charging stations based on authorization requests received from the two different charging stations and wherein a distance between the charging stations divided by time between the authorizations is above a threshold; and when detected, at least one of remove the vehicle identifier from the second list, disable authorization based on the vehicle identifier or alert an operator.

12. The device (200) of claim 10 or 11, wherein the at least one memory (204) comprises instructions which, when executed by the at least one processor (202), cause the device (200) to:perform the detections related to the use of the same vehicle identifier for authorizations at least one of when a new charging transaction is started with a vehicle identifier or periodically.

13. A computer-implemented method (1000) for enabling automatic charging start and authorization of electric vehicle based on a vehicle identifier, the method comprising: receiving, from one or more charging stations, authorization requests with different kinds of identifiers for authorization to start charging at the respective charging station; detecting, based on the received authorization requests, when a rejected authorization request and an accepted authorization request to start charging at a same charging station are received consecutively within a certain period from the same charging station, and wherein the rejected authorization request comprises a vehicle identifier and the accepted authorization request comprises a second type of identifier linked to user information; storing the vehicle identifier of the rejected authorization request to a first list of vehicle identifiers, wherein the vehicle identifier is linked to the user information based on the accepted authorization request; determining (1004) that a vehicle identifier is static if a same user information is linked to the vehicle identifier at least a first predetermined number of times on the first list, the first predetermined number of times comprising at least two times; determining (1006) that the vehicle identifier is unique if, within a certain number of vehicle identifiers on the first list, the vehicle identifier is listed at least a second predetermined number of times, the second predetermined number of times comprising at least two times, and wherein the vehicle identifier is each time linked to the same user information; enabling (1008) authorization to start charging at charging stations based on the vehicle identifiers determined to be both static and unique; and accepting authorization requests, received from the one or more charging stations, with the vehicle identifier determined to be both static and unique and linked to the user information on the first list.

Images