WO2018081321A1

WO2018081321A1 - Automated ev charging station identification process with mobile phones and other automation processes

Info

Publication number: WO2018081321A1
Application number: PCT/US2017/058374
Authority: WO
Inventors: Rajit Gadh; Tianyang ZHANG; Chi-Cheng Chu; Ching-Yen Chung
Original assignee: The Regents Of The University Of California
Priority date: 2016-10-26
Filing date: 2017-10-25
Publication date: 2018-05-03

Abstract

Automating the task of identifying an Electric Vehicle (EV) charging station chosen by an EV user from which to commence charging. A reader is activated which determines and validates a charging station and / or given plug to a charging station having multiple plugs. A reader on the charging station is activated to determine and validate identification of an EV to be charged, and send a charge command to a server controlling charge activation of the charging station and its plugs. A method of prioritization of charging is described based on accumulation of solar charge credits, and providing a medium of exchange of those solar charge credits.

Description

AUTOMATED EV CHARGING STATION IDENTIFICATION PROCESS WITH MOBILE PHONES AND OTHER AUTOMATION PROCESSES

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to, and the benefit of, U.S. provisional patent application serial number 62/413,379 filed on October 26, 2016, incorporated herein by reference in its entirety.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not Applicable

INCORPORATION-BY-REFERENCE OF

COMPUTER PROGRAM APPENDIX

Not Applicable

NOTICE OF MATERIAL SUBJECT TO COPYRIGHT PROTECTION

[0004] A portion of the material in this patent document may be subject to copyright protection under the copyright laws of the United States and of other countries. The owner of the copyright rights has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the United States Patent and Trademark Office publicly available file or records, but otherwise reserves all copyright rights whatsoever. The copyright owner does not hereby waive any of its rights to have this patent document maintained in secrecy, including without limitation its rights pursuant to 37 C.F.R. § 1 .14.

BACKGROUND

[0005] 1 . Technical Field

[0006] The technology of this disclosure pertains generally to electric

vehicle (EV) charging stations, and more particularly to identification of EV charging stations as selected by an EV user.

[0007] 2. Background Discussion

[0008] In conventional electric vehicle charging stations, a user typically is assigned a sign-in credential for a web-based (internet-based) log-in and they utilize a radio-frequency identification (RFID) pay-card for physical access. For example, with a charging station by ChargePoint©, users swipe their RFID card at the charging station, which in turn unlocks the charger plug so that the user can gain access. Similarly with the mobile application by ChargePoint, users with mobile phones can use the global positioning system (GPS) to roughly find the nearest charging stations and then choose from a set of lists or points. The application then sends the credential and charger ID of the user to the server to unlock the plug and record consumption information. No RFID technology on automatic vehicle detection and charging initiation is so far deployed on commercial EV charging stations.

[0009] Currently deployed in the WINSmartEVTM™ infrastructure, users need to use a web-based app to log in, select the desired charging box and charging station, select their EV model, input the SOC and then confirm to start charging. In certain processes, the user needs to input their bidding price for the electricity they need. The application then sends over all related information to the server, and the server subsequently evaluates the request and initiates actions on the charging station. This has proven to be a very time consuming and labor intensive process.

[0010] Accordingly, a need exists for speeding up the process of selecting and initiating a user charging session at a charging station. The present disclosure fulfills that need and provides additional benefits over previous technologies.

BRIEF SUMMARY

[0011] A method and apparatus are described for automating the task of identifying an Electric Vehicle (EV) charging station that the EV user chooses for charging and commencing charging. The process uses a mobile device (e.g., cellular telephone) to aid the user in finding their designated charging station, from a list of available charging stations, both quickly and without excessive manual operations.

[0012] Further aspects of the technology described herein will be brought out in the following portions of the specification, wherein the detailed description is for the purpose of fully disclosing preferred embodiments of the technology without placing limitations thereon.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

[0013] The technology described herein will be more fully understood by reference to the following drawings which are for illustrative purposes only:

[0014] FIG. 1 is a flow diagram of using a Quick Response (QR) code to automate identifying the Electric Vehicle (EV) charging station according to an embodiment of the presented technology.

[0015] FIG. 2 is a schematic diagram of utilizing a Bluetooth beacon with plug-in detection according to an embodiment of the presented technology.

[0016] FIG. 3 is a flow diagram of using a Bluetooth beacon and plug-in detection configuration according to an embodiment of the presented technology.

[0017] FIG. 4 is a flow diagram of utilizing a Bluetooth beacon and tap-on scanner to automate identifying the Electric Vehicle (EV) charging station according to an embodiment of the presented technology.

[0018] FIG. 5 is a flow diagram of utilizing an RFID tag to automate

identifying the Electric Vehicle (EV) charging station according to an embodiment of the presented technology.

[0019] FIG. 6 is a flow diagram of utilizing automatic location tracking to automate identifying the Electric Vehicle (EV) charging station according to an embodiment of the presented technology.

[0020] FIG. 7A and FIG. 7B are a flow diagram of starting a charging

command at a central server to automate identifying the Electric Vehicle (EV) charging station according to an embodiment of the presented technology.

[0021] FIG. 8 is an image rendering of an event monitor interface for a

server utilized to automate identifying the Electric Vehicle (EV) charging station according to an embodiment of the presented technology.

[0022] FIG. 9 is a block diagram of a cloud-based EVSmartPlug

infrastructure as utilized according to an embodiment of the presented technology.

[0023] FIG. 10A through FIG. 10C are image renderings of a main interface of the EVSmartPlug application, showing charging information, charging station location, and charging station map, as utilized according to an embodiment of the presented technology.

[0024] FIG. 1 1 A through FIG. 1 1 C are image renderings of a mobile iOS interface showing charging tab, solar generation monitor and station status, as utilized according to an embodiment of the presented technology.

[0025] FIG. 12A through FIG. 12D are image renderings of a mobile iOS interface, showing paused, system pause explanation, boost configuration, and results of boost session / first ranked non-paused scenario, as utilized according to an embodiment of the presented technology.

[0026] FIG. 13A through FIG. 13D are image renderings of a mobile iOS interface with trading, showing menu, purchase page, sell solar page, and trading history, as utilized according to an embodiment of the presented technology.

DETAILED DESCRIPTION

[0027] 1 . Introduction to Infrastructure

[0028] A conventional commercial EV charger usually has one stationary body with a plug connected through an electric cord for the user to plug into their car. In contrast, multiplex charging stations have multiple plugs. By way of example and not limitation, each WinSmartEV station is configured with a total of four charging plugs. It should be appreciated that

embodiments of the presented technology can be applied to WinSmartEV multiplex charging stations; however, it can also be applied to other commercial EV chargers.

[0029] 1 .1 . Quick Response (QR) Code in each Charging Station / Plug

[0030] FIG. 1 illustrates an example embodiment 10 of handling EV

charging in response to the use of an implicit identification of the station where an identifier of the station is captured and sent from the mobile application, instead of the user manually selecting or entering a station number. In this example the station is inferred in response to obtaining a quick response (QR) code from the charging station or one of the plugs of the station. In at least one embodiment each charging station / plug is assigned a unique QR code and an indicia for the QR code is affixed to the main box and on the charging plug. The figure shows actions at central server 12, at the mobile application 14 and user actions 16. The user starts 18 the mobile application (mobile app) program connecting to charging event database 20. The mobile app starts by checking 22 whether this user has an active charging session, or the requested location has an active session. It should be noted that checking 22 for the active session is described more in FIG. 7A. If there is an active session, the mobile app generates (displays) 24 the main interface (seen in FIG. 12A discussed later). If there is not an active session, the mobile app automatically initiates 26 a QR code reader to scan for QR code in sight. If the user cancels the action, the app returns to the main interface. Otherwise, instead of canceling the action the user points 28 the mobile device imager (camera, code reader) to capture the desired QR code, such as found on the charge plug, and/or a portion of the charging station identified with a specific charge plug. If the QR code reader finds a valid QR code in camera sight, it will examine the converted ID against its station ID database. A determination is made at step 30 if there is a corresponding station, so the ID is checked in the charging event database. If there is not a corresponding station ID in the database, the mobile app reports the error and returns to the main interface at block 24. Otherwise, if the station ID is correct, the mobile app proceeds to ask the user if they want to start a charging session (screen is seen in FIG. 13A as discussed in a later section). In response to scanning of the QR code the mobile app sends 32 a command to the central server to start charging 34 on that station. The start charging request data structure sent to the server includes user id, user class, and station id. It will be noted that the typical steps in a minimum action embodiment can start charging with only requiring the user to: (1 ) plug in the EV; (2) start application; (3) move phone camera to shoot QR code.

[0031] 1 .2. Bluetooth Beacon with Plug-in Detection

[0032] In one embodiment, the system utilizes the plug-in status detection feature of the WinSmartEV multiplex box. Each station charge box, equipped with multiple (e.g. , four) plugs is equipped with a Bluetooth beacon for each box, thus there are four charging stations in one box.

[0033] FIG. 2 illustrates an example embodiment 50 of charge stations

using a Bluetooth beacon with plug-in detection. A first charge station 52 is seen with multiple charge plugs 54a, 54b, 54c, and 54d, and emitting periodic beacon signals 56. As seen in the example, the charge station is configured with four charge plugs; however, the present disclosure can operate with any reasonable number of plugs, such as from 2-8 charge plugs. A second charge station 58 is seen with charge plugs 60a, 60b, 60c, and 60d, which generates beacon signals 58.

[0034] A user 62 is seen with mobile device 64. Within the mobile

application of the present technology the background program is active in searching for beacons that are registered in its station beacon ID database. If there are any beacons in its range (less than around 25 meters), the program will select the box that is physically closest to the user. The mobile app subsequently sends a welcome message to the user and notifies the user to plug in their car with their desired plug.

[0035] In main interface, the app recursively checks with the central server to see whether there is any plug of this box that is newly plugged in. On a hardware level for the station and plug, the station always knows if the plug is plugged in to the EV or not. However, the cloud server doesn't have this real-time update. So interaction occurs 66 between the central server and the station in real-time. In the given example, this interaction occurs every one minute, although it can be implemented with different periods, or triggered by status changes, or in other ways without departing from the teachings of the present disclosure. If there is a new plug-in detected, the app will notify the user and starts charging. The start charging request data structure as sent to the server includes user id, user class, station id, although other information may be incorporated as desired.

[0036] FIG. 3 illustrates an example embodiment 70 of a beacon and plug in detection process for charge initiation. Typical steps in performing a minimum user action commencement of charging involve steps of: (1 ) driving near the station; (2) activating (opening) the mobile app of the present disclosure, such as through a notification; (3) plugging in the EV; and (4) confirming the station detected by the app to start charging.

[0037] The figure depicts these steps at central server 72, mobile

application 74 and user actions 76 as follows. The mobile app background program 78 is operating and checking 80 for beacons (or tags) in range as the user approaches 82 the charging box. If the beacon is in range, then in block 84 the mobile app notifies the user to plug in their EV from the selected charging box. In at least one embodiment, the user clicks the notification to acknowledge they want to commence charging. Alternatively, instead of clicking on the notification, the user can choose to open the mobile application itself to the same effect. Execution reaches a main interface 88 in which a query goes out to a charging event database 90. A check is made 92 by the mobile app to determine if there is already an active charging session. It should be noted that this check can be similar to that seen in FIG. 7A, such as process 22, checking for an active session either by the user on another station or other user on this station. If there is an active charging session logged, then execution returns to main menu 88 with another command to the central server 90. If no charging sessions from the user are active, then at block 94 the charging box is queried for plug-in status and block 96 reached to check for new plug being plugged in as the user plugs in their EV. Thus, if the user has an active charging session, he/she cannot charge at this station before he/she ends his/her previous charging session. If the plug is not yet detected, another query goes out 94 and the check 96 repeated. Otherwise, as the plug has been plugged into the EV, block 100 is reached which notifies the user of the found station that they are plugged into, and the user confirms 102 the station, upon which a charging command is sent 104 to the central server to commence the charging operation, at which time the mobile app displays status information during charging, such as time of charging, remaining time, and a stop button should the user wish to stop the charging process before it reaches full charge.

[0038] It should be appreciated that although the above example describes the use of the Bluetooth protocol, other forms of local wireless

communication can be utilized without departing from the present teachings. For example any RFI D tag, or similar wireless beacon, can be utilized. Preferably, these wireless devices would have a sufficient range for convenient detection of the charging box, such as of approximately 10 meters.

[0039] In instances in which two or more users simultaneously plug into the same charging box, and in which the server checks for plug-in status update for both user, the system can utilize various approaches to remediate confusion between the plugged in EVs, as described below.

[0040] 1 . Confirm charging station with user. The user is asked to confirm which plug on the charging station is being utilized.

[0041] 2. Using statistics, machine learning or other observation to

determine the preferred plug to be used. Due to physical location and other factors, there may be some spots that are more likely to be occupied by users thus the plug corresponding to it. The server can use this order to assign the more preferred plug to the user who enters the beacon range earlier. The following user is assigned to the next preferred plug.

[0042] 3. As different plugs are located at different distances from the box, the box can make use of the signal strength of the user to infer the distance between the user and the box. According to the distance, the box will infer the plug closest matched to the distance estimate. In this case, the beacon should be placed in the side of box so that every plug's distance to the beacon is different, not in the center of box in which case the plugs are in symmetry with regards to the beacon. It will be appreciated that implementation of the above is readily realized utilizing RFID technology which provides signal strength information.

[0043] 4. The charging box hardware records the plug in time/order. The server can assign the first used plug to the user who enters the region first and similarly with the following users/plugs.

[0044] 1 .3. Bluetooth Beacon Tap-on

[0045] FIG. 4 illustrates another example embodiment 1 10, using a

Bluetooth beacon and tap-on scanner to automate identifying the Electric Vehicle (EV) charging station that the EV user chooses to charge with. It should be appreciated that the "scanner" here refers to a general Bluetooth reader. Thus, the system can be implemented with no additional hardware, as most of the Bluetooth readers can determine distance. In this case, the "software scanner" will only respond when a very small distance is reported by the Bluetooth reader. In this embodiment each plug is considered to be configured with its own beacon, for example installing a Bluetooth or other wireless beacon on each charging plug. The flow diagram again shows steps performed by the central server 1 12, mobile app 1 14 and user actions 1 16 on the mobile app. At the main interface 1 18 of the mobile app, the user initiates the tap-on scanner 120 and the mobile app recursively checks 122 if there is any Bluetooth beacon in the immediate distance (around a few centimeters). In this process, the user moves their phone very close to the beacon or "taps on" the beacon. If the beacon is not detected then the program continues checking 122 until the desired plug has been selected by the user.

[0046] If the program detects the beacon in the immediate vicinity (within this short distance), then a command is sent to the charging event database 124 to open an active charging session. It should be noted that in both FIG. 3 and FIG. 4, an "active charging session" means to check whether the user has preexisting charging sessions (assuming only one session per user is allowed) or other session on the location, for example as seen by block 22 in FIG. 1 . The status of the sent request will be updated in the main interface at a later time, such as in response to regular status checking, whereby no explicit ACK message from the server needs to be sent in response to receiving the charge command. In at least one embodiment, the start charging request data structure as sent to the central server includes at least user id, user class, and charging station

identification. The mobile app checks 126 if the user already has an active charging session. If the user already has an active charging session or there are no other requests from other users on the particular location (e.g., as seen in FIG. 7A), then the app returns to main interface 1 18. If the user does not already have an active charging session, then block 128 is reached and the charge command is sent 130 from the mobile app telling the central server to start charging at that station.

[0047] Thus it is seen above, that the typical steps for a minimum user action to start charging are: (1 ) plug in EV; (2) start app; (3) initiate

Bluetooth scanner; and (4) tap phone to the beacon and initiate the charging. It will be appreciated in the above example that any near-field wireless communication or RFID can be utilized to substitute for the described Bluetooth technology.

[0048] 1 .4. Automatic Charging Request without Mobile Device (Phone)

[0049] FIG. 5 illustrates an example embodiment 150 of starting a charging session for a user without a mobile phone, or for an autonomous vehicle. At least one embodiment of the present disclosure provides a method for a charging station to communicate with an EV without the help of a mobile app. The method requires some form of identifier on the EV, for example an RFID tag, WiFi, Bluetooth, other short field or regular far field

communication or active or non-active RFI D tags. The figure depicts the interaction between central server 152, charging station (box) 154 and

EV/User 156.

[0050] In block 158 the charging box continuously checks (or sufficiently short period between checks not to miss beacons/responses), until a beacon or RFID tag is in range. Considering the case of using WiFi or Bluetooth on the EV, the charging box recognizes the unique MAC address to identify each vehicle uniquely. It will be noted that the advertising mode is configured to let users see messages from the charge station (box). To obtain the MAC address of an EV's Bluetooth, a Bluetooth reader should be incorporated in the charge station (box).

[0051] In order to distinguish the designated vehicle from other surrounding vehicles which may be also broadcasting their MAC address, the MAC address of the EV may need to be pre-registered with the station or central server database or follow certain pattern that the system can recognize it. If the system distinguishes a potential, but not registered EV MAC address is possible, then in at least one embodiment advertisement or invitations are broadcast to the users to join the Charging Station user database. Similarly, with add-on RFID tags, it is preferred to use a series of RFID with certain range of ID that an algorithm can recognize. Otherwise, the RFIDs to be put on EVs can also be pre-registered on vehicles. The figure thus depicts the case in which an RFID reader, or similar device is integrated in the EV Charging Box for communicating with the EV.

[0052] When a vehicle approaches 160 to a sufficiently close proximity to the charging box, the RFI D reader checks for EV beacons (RFID tags) periodically, and having detected one reaches block 162 in which it retrieves the EV beacon ID. Thus, the charging box detects the existence of the EV. The programming tracks the general movements/distance of the vehicle when moving and when its stops. This rough positional information is used in relation to the activity of the plug being inserted into the EV to properly correlate the plug insertion with the specific vehicle ID being charged. This process can be utilized in any of the other embodiments described herein without limitation. Alternative methods can be utilized instead of location tracking, such as statistical learning/inferring, other numerical/mathematical methods or manual preference marking (some positions are more likely to be occupied by user/vehicle than others statistically or logistically), can also be used to associate newly inserted plug with newly arrived vehicles in case of simultaneous arriving and/or EV plug-in.

[0053] The EV is plugged in 164 by the user or automatically. The charging box is actively checking 166 if a new plug is plugged in. It will be noted that either the EV is plugged in manually, such as by a user, or this feature can be tied with an EV system which allows for the EV to "dock" with the charging station to make a connection, or for an automated charging station to automatically (e.g., robotic arm) establish an electrical plug connection. It should be appreciated that the present disclosure, can be utilized with any manner of manual or automated charge plug connection mechanism.

[0054] Upon finding at block 166 that a new plug has been plugged in, such as within a certain defined time (around 5 minutes), the charging box sends 168 a charging request to the central server, such as by sending

information, which preferably includes at least information about the vehicle identification (vehiclelD), station identification (stationID), time and method of submission. The server, after receiving the request, will verify 170 that the request is valid, including verifying the corresponding user (User ID) from the vehicle ID and security verifications, as well as checking if the user already has an active charge session, such as was seen in block 22 of FIG.

1 which is detailed in FIG. 7A. If the request is valid, then the central server will initiate 172 charging by sending the start charging command (which is described in more detail in section 1 .6.)

[0055] 1 .5. Automatic Location Tracking

[0056] Given the proprietary nature of the controller area network (CAN) bus on an electric vehicle (EV) it can be difficult to directly obtain critical vehicle on-board information, such as State of Charge (SOC) and geographical location. It will be noted that the CAN bus is a robust vehicle bus standard used in vehicles to allow microcontrollers and devices to communicate with each other in the vehicle without the need of a host controller.

[0057] It is important to obtain SOC and other data available from the EV CAN, or through a manufacturer provided interface with the CAN to provide this information for charging stations. It will be noted that such information is significantly important for service providers for demand and service scheduling and for allowing an electric vehicle to perform autonomous route planning and charging station planning and recommendations. The service provider may plan charging priority based on user's SOC demand.

Charging Service providers may also provide charging station

recommendations for users that need charging to locations where demand is low, electric cost is cheap or other reasons based on vehicle locations and other user preferences.

[0058] FIG. 6 illustrates an example embodiment 190 of automatic location tracking to determine the users' mileage in the EV for estimating EV SOC. This information can be used in setting up a charging session, and for identifying an EV station at which to charge. The figure depicts the interaction between central server 192, charging station (box) 194 and EV/User 196. In order to obtain such information, in at least one embodiment of the present disclosure geographical tracking is utilized to estimate a user's movement with the vehicle and estimate their energy consumption and subsequently the state of charge of their associated EV. Every time the EV of the user is fully charged, the system uses that event as a calibration and reset scenario. For the purpose of determining if the user is inside the EV, a communication feature (e.g., Bluetooth feature) on board of the EV it utilized, or one could be added in the very unlikely event the EV does not have such a communication facility. It is assumed that the user utilizes his/her phone app to request charging from an embodiment of the presently disclosed charging system (assuming the user never charges at other non-associated locations (e.g., that use a different database) so the system can determine how much the user has charged by examining system data records. So the "recalibration" performed is automatically and does not require connection between the EV and their phone.

[0059] The mobile application 198 either runs in the background and/or during an active session, depending on user preferences. When the user approaches 200 the EV, their phone is automatically connected to the EV Bluetooth, the mobile app checks 202 if any known EV tag ID is connected. This approach distinguishes the EV connection from other Bluetooth device connections, such as wireless headphones. In at least one embodiment, the data structure of the tag preferably includes at least user identification as well as vehicle Bluetooth identification. If the tag is known, then execution moves to block 210. Otherwise, if no known EV tag is connected, as determined in block 202, the app will ask the user to select 204 EV Bluetooth from a list of connected Bluetooth devices and the app will subsequently store 206 the tag information into its local database and push 208 this information to the remote central server database before reaching block 210.

[0060] After the vehicle is recognized, the app continues to detect 210 if the mobile phone is moving. This is to distinguish scenarios when the user is simply standing nearby the EV instead of actually driving it. This strategy significantly reduces data storage size, transmission load and read/write frequency and increase the operation efficiency.

[0061] While the EV is both moving and connected, the mobile app

continues to record 212 the location of the mobile phone and store 214 this in its local database. The data structure to be stored includes phone location, moving speed and time. After a certain amount of data has been accumulated, the package of aggregated data will be sent to the central server when an internet connection is available. The process continues so that while the mobile phone is moving with the EV, that the time of travel by the EV is tracked.

[0062] 1 .6. Sequence of Starting Charging Command at Central Server

[0063] FIG. 7A and FIG. 7B illustrate an example embodiment 230 of

starting a charging command at a central server to automate identifying the Electric Vehicle (EV) charging station that the EV user chooses to charge with. Following the "send charging command" as previously discussed, in at least one embodiment the central server processes the charging request as seen in this flow diagram, with verification being performed through a back-end program that requires frequent access to the database of charging events.

[0064] The process starts with a request 232 to charge an EV in response to receiving a given a set of information, such as user ID, user class and location ID of the requested charging station. The routine 230 first evaluates 234 if the user has another active charging request. In the case where each user is only associated with one vehicle, only one active charging request is allowed at one time, so an error is reported 236 (e.g., error code = 4 for this example) for attempting to initiate a second charging request, and the charge request is closed. This is also to prevent multiple unintended submissions due to network and other errors, for example preventing a user from holding multiple plugs "hostage", so to speak, such as to garner all allotted charge capability for their own EV.

[0065] A check is then made 238 for availability of the charging station. If there is another active charging request on this plug of the station, an error is reported 240 to the user (e.g., error code = 5 for this example). The process is also intended to prevent cases, such as multiple charging requests due to network and operational errors. The server then checks 242 for whether the user class is allowed to use this charging box. This is used to control multiple user group privileges from the server side. If they are not allowed, then an error is reported 244 to the user (e.g., error code =

6 for this example). Lastly, the server checks 246 if the charging station is open for use. If not, an error is reported 248 to the user (e.g., error code =

7 for this example).

[0066] After the above verification, the request submission is processed 250. The system checks 252 whether there is Demand Response signals in action at the moment. If so, a hold is performed 254 on the charging request until the Demand Response signal is cleared. The system then proceeds to determine 256 if the system has any specific individual management plan for the user in action. In reality, this management plan could include multiple kinds of user consumption plans in order to, for example, limit user's energy consumption mix (i.e. , renewable energy, off- peak electricity, and other charging plans) and / or other personal preferences. If these plans need to be addressed then a hold 254 is performed and these issues addressed on a per plan basis. Once all of the above checks are cleared, the system proceeds to send 258 a charging command to the charging station (box), for example through an HTTP

POST.

[0067] FIG. 8 illustrates an example embodiment 260 of the event monitor interface, showing tabs for Real Time 262, Historical 264 and Statistics 266, that is directed for use by charge system managers/administrators to view the operation of a plurality of stations by a group of users. In the example shown, the Real Time tab 262 is open showing columns for location, parking structure (PS), box number, station number, user, status, active power (kW), charging current (A), relay status, plug status, and duty cycle. It will be appreciated that more or less information can be provided in this event monitor without departing from the teachings of the present disclosure.

[0068] It will be appreciated that providing an event monitor interface can significantly provides rapid display of status across the charging system to aid the system manager/administrator. The present disclosure also contemplates deployment of autonomous electric vehicles, and provides for

EVs to charge themselves without human interventions. The location tracking method solves the current universal problem of not being able to obtain SOC information from electric vehicles. The charging management flow shows an efficient system to address practical implementation issues.

[0069] 2. Site Set-up

[0070] In the examples described below, a Level 2 charging station (box) is described that is located at a workplace Parking Structure (PS) 2 which is the target of the deployment. The Level 2 charging box has a total of four plug outlets (each of them being referred to as charging stations) and a total max power of 6.6kW. When multiple users are plugged in and charging, the sum of their charging power cannot exceed 6.6kW.

[0071] In order to understand user behavior and power consumption patterns, all data associated with user behavior was collected during charging with minute-by-minute power data being collected during both charging and idle times. The following data is collected from different data Application Program Interfaces (API): (1 ) Power data: collected from a gateway (e.g. , Billion energy gateway), containing: timestamp (s), entity id, active power (W), current (A), voltage (V), frequency, power factor, apparent power (VA), main energy (kWh). (2) Relay data: collected from the controller of the charging box and containing: relay status (on/off), plug (plugged in/not plugged in), and duty cycle (0%-50%). (3) User charging session: collected from the mobile app and cloud server, containing the following data: user id, entity id, status (e.g., submitted / charging / finished / error), request timestamp (s), start of charge timestamp (s), stop timestamp (s), start main energy (kWh), stop main energy (kWh), stopped due to being fully charged (true/false), and stopped due to being unplugged (true/false).

[0072] The full cycle of a charging session is as follows. (1 ) EV user

submits his / her charging request to the smart charging server, including desired charging station and their user id. (2) The system processes the requests to determine whether certain sessions are to be started or stopped. (3) The system sends out commands to charging stations. (4) When the user is satisfied with their level of EV energy storage, or wants to drive off with their EV, they can request to stop the charging session. In other cases, for example the system detecting that no more current is accepted by the EV, which will arise if the EV is fully charged, or can arise if the charging plug connection is not well established, the system

automatically stops the charging session. This is followed by commands from the system to turn off the actual corresponding station. Additionally, real-time power data of renewable energy collection is collected from a controller associated with one or more banks of solar panels.

[0073] 3. Software Implementation and Algorithms

[0074] FIG. 9 illustrates an example embodiment 330 of a cloud-based EVSmartPlug infrastructure according to the present disclosure. The software architecture consists of three main components, a user front-end interface 336, cloud backend EV Control Center (EVCC) 332 and EV database. EVCC 332 is shown connecting to charging station (box) unit 334 which in turn is configured for connecting through a plug to an EV 338. EVCC 332 also receives information on demand response 340 and pricing information 342.

[0075] FIG. 10A through FIG. 10C illustrate example screens 350 from the EVSmartPlug application interface. In FIG. 10A a main interface is shown, while FIG. 10B depicts charging stations, and FIG. 10C depicts a map view of the charging stations in relation to the user location.

[0076] 3.1 . Electric Vehicle Charge Controller (EVCC)

[0077] The software EVCC sends commands to control the hardware that performs the J1772 standard operations. The EVCC manages charging sessions of users and controls the charging commands of charging stations. All charging processes are controlled within the EVCC which utilizes the latest EV status and power information from the EV Database and evaluates this according to the corresponding programming. EVCC handles charging requests from users and subsequently provides real-time monitoring data to the user interface, so that users can monitor their charging status on their mobile interface. In addition to user request handling, EVCC also automatically checks fully charged EVs or unplugged EVs without periodic manual user requests. After a charging session is completed, the EVCC sends a session completion (finish) report to the user including information about the charged energy. If less than 0.1 kWh energy is charged, EVCC will warn user of low charged energy either caused by loose physical connection between vehicle and plug or vehicle being fully charged. At the end of the day, users can also receive a daily summary of their total charged energy and amount of associated solar energy utilized. Additionally, EVCC obtains external information which is utilized in managing charge control, including Demand Response (DR).

[0078] 3.2. Mobile User Interface

[0079] The mobile interface, called EVSmartPlug™, has the following major functions, (a) Submit user charging request: as the main function of the mobile application, the user interface facilitates the process of a user requesting charging service from the server. In at least one embodiment, the request information includes: user ID, charger ID, time of request, and estimates of user energy demand, (b) Receive charging status updates: the mobile interface also serves to update users with their charging status, including power, energy charged and in at least one embodiment their place in the queue, (c) Real-time solar energy indicator: the current level of solar generation is clearly indicated (e.g., in the front tab of the app), so that users can make informed decisions to charge according to the solar generation level. Ancillary services, information and configurations: the application provides ancillary information related to the charging service including locations of charging stations, station occupancy status and personal consumption information.

[0080] FIG. 1 1 A through FIG. 1 1 C illustrate example iOS interface

snapshots of the EVSmartPlug mobile application. In FIG. 1 1 A the demand level 390 is shown with estimated charging time, while the amount of solar use is also listed. In FIG. 1 1 B a graph 410 is shown as a solar generation monitor so the user can time their charging to coincide with available solar energy. In FIG. 1 1 C a station status list 430 is shown.

[0081] 3.3. Automatic Solar Program

[0082] Since not all users are fully responsive to system intentions, a

feature referred to as "automatic solar program" has been implemented. When users opt to enroll in this program, the system automatically pauses the charging of the user when solar generation is lower than a pre-defined threshold. This helps users so that they do not consume low solar ratio energy thus "contaminating" their overall solar score. This essentially is the same effect achieved by a very attentive user who monitors the solar generation all the time.

[0083] 3.4. Charging Cycles

[0084] In order to prevent large power consuming users that would require an extended time period for charging from holding up (unduly delaying) the remaining users whose EVs await charging, at least one embodiment of the present disclosure imposes a cycle parameter that once each user has reached their preset threshold, they will be pushed back to the end of the queue and must restart until all other users with smaller cycle numbers are either finished or pushed to the same cycle number.

[0085] 3.5. Ranking Algorithm (Priority Round Robin)

[0086] 3.5.1 . Solar Ratio

[0087] User charging records consist of their charging sessions, in which the solar ratio of each charging session is determined by comparing the consumption power and the solar generation data during the same time interval. The solar ratio u_{i n} for the n -th session of user i can be computed as the following:

where a_{s h} is the solar generation power at time h , with h_st , and h_end being the start and stop time for each charging session of user i ranging from 1 to n . The value a_h is the power consumption of the station for the session at time h ; while a_{v h} , is the power consumption at time h for station v (e.g., from 1 to 4) within the same box of the station during the session. It is assumed that solar power generation is non-negative, wherein the solar ratio is always less or equal to 1 .

[0088] For each user i , a solar score S_j is determined as the overall ratio of charged solar energy to their entire energy consumption. The score S_j can be determined as follows. N

∑ ^ui,nE_n

¾ ⁼ ^ (2) n=l

where E_n is the total energy consumption for charging session n .

[0089] As users become proficient with utilizing the smart charging system, they will realize the effect of the charging priority and how it is positively changed by their usage of solar energy. As awareness is raised through frequent use of the system, it is expected that consumption patterns will change accordingly as users adopt the more eco-friendly solar power.

[0090] 3.5.2. Solar Usage Ratio

[0091] The solar usage ratio is a measure of how much locally generated solar energy is used by nearby EV charging. Because of intermittency of solar generation and the low buy-back rate from utilities, it is always preferable to use more renewable energy locally instead of selling it back to the grid. The solar usage ratio can be calculated as

N

Solar Usage Ratio = (3)

[0092] 3.5.3. Priority Round Robin

[0093] In using a Priority Round Robin method, the system is configured to provide maximum power to one user at a time and put other active users on hold. Users with higher solar scores Sj and lower demand E_j will have higher charging priority and therefore start earlier. It should be noted that while charging a first user, if a charge request is received from a second user with higher priority, then the system in at least one embodiment will turn off the current active charging session (first user) and start the new user (second user) which has higher charging priority. Each user session is provided with a fixed energy allowance in a single cycle, over which their charging will be given to other users. Thus, for a set of active users Q , the system provides charging service to user i which has the highest priority index g_j : gi = (4)

The power requested by the user is E_j . The instantaneous power received by the user is a_t . It should be appreciated that the above relation is only one example for determining a priority charging index g_j . For example this determination can be generalized to many different relations involving Sj and E_j depending on the application and intents of the lot owner. So more generally speaking, this charge priority can be written as g_j = f (s_j, E_j ) .

[0094] 3.6. Boost

[0095] In at least one embodiment of the system, lower ranked users can make use of virtual currency, SMERCOIN™ to temporarily boost their ranking to first place until the end of their session. This feature

accommodates situations in which a user requires reaching a select level of charge in a short period of time before departing with their EV. In this example embodiment, only one boost is available in one box at a time. If a user consumes less than 0.5 kWh in a boosted charging session, his SMERCOIN will be refunded. More details on the virtual currency is discussed later.

[0096] 3.7. Two Allowed Stations

[0097] Although the maximum power of the exemplified Level 2 charging station is 6.6 kW, the actual charging power utilized depends on the EV model. So there are cases that only 2-3 kW is being charged while only one car is charging. In this case, when charging power is only between 1 -4 kW, the system changes the allowed stations from 1 to 2 so that 2 EVs can charge simultaneously.

[0098] 3.8. Essential Method Implementations

[0099] By way of example and not limitation, a number of general

procedures are outlined in tables at the end of the specification, Table 1 describes steps of a "Recurrent Checker" procedure, Table 2 depicts general steps of an "evaluateChargingQueue (box)" procedure, Table 3 depicts steps of a "requestStop(session)" procedure, and Table 4 depicts a "requestStart(station, user)" procedure. One of ordinary skill in the art will appreciate that the teachings according to the present disclosure can be fulfilled using a variety of different coding forms, structures, and flows without departing from the present teachings.

[00100] In addition to being called in other portions of these procedures, requestStartO and requestStop() are also called when users manually request to start and stop their charging sessions respectively. Functions turnOn() and turnOff() are direct commands to turn on and off the charging stations through HTTP commands, and return True if the commands succeed. The method within the station class getEnergy() is configured to obtain readings of accumulative energy (e.g., accumulated energy counter) of the station so that the system can determine the consumed energy during each charging session.

[00101] FIG. 12A through FIG. 12D illustrate an example mobile iOS

interface incorporating a ranking method as described above. In FIG. 12A the main menu 450 depicts a paused scenario with the user at a second rank (2/2), and in at least one embodiment displays solar use as "Solar

Use: 10% (Rank 30/30). The screen also shows a "boost button" to allow the user to increase their priority, while a "stop button" allows the user to pull out of the charging queue entirely. The user can also determine "why am I paused", whereby the system displays a screen 470, such as seen in FIG. 12B. In FIG. 12C a screen 490 is displayed in response to the user selecting the "boost" option, wherein in this screen a confirmation of "boosting" is requested as it informs the user of the relative cost of the boost. In FIG. 12D a screen 510 shows as a result of using the boost session, this user is back in a first ranked non-paused scenario with the EV being charged.

[00102] 4. Software Variation in Current Sharing Scenario

[00103] Another variation of the above charging process is implemented when a different number of charge plugs per charge station. In this example scenario there are mainly two differences (1 ) there are only two plugs in each station, and (2) lower ranked users are never turned off, rather only given a smaller level of EV charge current. The charging paradigm in this scenario is shown in Table 5.

[00104] Method 2 describing the EvaluateChargingQueue (box) procedure from Table 2, is thus modified to Method 5 as seen in Table 6.

[00105] Additionally, the routine getTheOtherStation(station) returns the station that belongs to the same box but is different than the input station. The routine changeDutyCycle(duty_cycle) changes the station duty cycle into the input value. If the duty cycle is 0, it is equivalent to turning off charging. If initially the station is turned off, the function also turns on the station before changing into the designated duty cycle. The function has no effect for a station that has no EV plugged in or an EV that is fully charged.

[00106] 5. Virtual Currency SMERCOIN™ and Trading System

[00107] As mentioned in a prior section, SMERCOIN can be used to boost charge ranking for the user. In at least one embodiment of the present disclosure, the users automatically accumulate SMERCOINs by charging their EVs with solar energy. The solar energy charged within the total charged energy is multiplied by a factor and then added to the user's current SMERCOIN.

[00108] Users can anonymously trade their solar credit with other users or with the system using arbitrarily sized, or selected, electronic tokens herein referred to as SMERCOINS. Their new Solar Score will be increased (if they buy solar credit from others or the system) or decreased (if they sell their solar credit to others or to the system). The user score after trading for buyers and sellers can be determined according to the following.

_ Esolar,buyer + E_tracj_e

^Ubuyer - ^~ p W

^tota^buyer ^trade

p p

_ ^solar.seller ^trade ,c_\ useller ^~ ~ ^{~ ~} V=>)

^ total, seller ^trade [00109] When selling solar credits, the user can either sell them directly to the system, which is instantaneous, or put these solar credits on the market to wait for other users to buy them. The system purchase price is fixed, but users can define their own price if they decide to sell these solar credits on the market for others to buy.

[00110] When purchasing solar credit, the system first looks for user listings and sorts them from low to high and automatically provides the cheapest purchasing price for the amount of solar credit the user wants to buy. If no user listings are available, the user can purchase solar credits directly from the system. The purchasing procedure is outlined in Method 6 as shown in

Table 7.

[00111] FIG. 13A through FIG. 13D illustrate an example embodiment of the mobile application performing trading of the solar credits. In FIG. 13A a credit marketplace menu 530 is shown allowing the user to select either to Buy credits, Sell credits, or view their trading history. In FIG. 13B a solar credit purchase screen 550 is shown allowing the user to choose the amount of solar credit to purchase, and to show what the results of the transaction will be. The user can elect to go forward with the purchase by pressing the purchase button to execute the transaction. In FIG. 13C a screen 570 is shown for a user contemplating selling solar credits. The user can choose the amount of solar credits to sell, and the number of coins to represent a kWh. An offer is shown for selling to the system, and a confirmation button is provided to allow the user to execute the transaction. In FIG. 13D a solar credit trading history 590 is shown for the user, preferably depicting sales and purchases in different colors (or fonts etc.) to highlight the differences along the history.

[00112] 6. Implementation Caveats

[00113] The enhancements described in the presented technology can be readily implemented within various electric vehicle charging infrastructures which are configured to interact with a mobile communications device of a user. It should also be appreciated that elements of the charging infrastructure, and of course mobile communications devices themselves, are implemented to include one or more computer processor devices (e.g., CPU, microprocessor, microcontroller, computer enabled ASIC, etc.) and associated memory storing instructions (e.g., RAM, DRAM, NVRAM, FLASH, computer readable media, etc.) whereby programming

(instructions) stored in the memory are executed on the processor to perform the steps of the various process methods described herein.

] The computer and memory devices were not depicted in the diagrams for the sake of simplicity of illustration, as one of ordinary skill in the art recognizes the use of computer devices for carrying out steps involved with charge control and mobile communications. The presented technology is non-limiting with regard to memory and computer-readable media, insofar as these are non-transitory, and thus not constituting a transitory electronic signal.

] Embodiments of the present technology may be described herein with reference to flowchart illustrations of methods and systems according to embodiments of the technology, and/or procedures, algorithms, steps, operations, formulae, or other computational depictions, which may also be implemented as computer program products. In this regard, each block or step of a flowchart, and combinations of blocks (and/or steps) in a flowchart, as well as any procedure, algorithm, step, operation, formula, or computational depiction can be implemented by various means, such as hardware, firmware, and/or software including one or more computer program instructions embodied in computer-readable program code. As will be appreciated, any such computer program instructions may be executed by one or more computer processors, including without limitation a general purpose computer or special purpose computer, or other programmable processing apparatus to produce a machine, such that the computer program instructions which execute on the computer processor(s) or other programmable processing apparatus create means for

implementing the function(s) specified.

] Accordingly, blocks of the flowcharts, and procedures, algorithms, steps, operations, formulae, or computational depictions described herein support combinations of means for performing the specified function(s), combinations of steps for performing the specified function(s), and computer program instructions, such as embodied in computer-readable program code logic means, for performing the specified function(s). It will also be understood that each block of the flowchart illustrations, as well as any procedures, algorithms, steps, operations, formulae, or computational depictions and combinations thereof described herein, can be implemented by special purpose hardware-based computer systems which perform the specified function(s) or step(s), or combinations of special purpose hardware and computer-readable program code.

] Furthermore, these computer program instructions, such as embodied in computer-readable program code, may also be stored in one or more computer-readable memory or memory devices that can direct a computer processor or other programmable processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory or memory devices produce an article of manufacture including instruction means which implement the function specified in the block(s) of the flowchart(s). The computer program instructions may also be executed by a computer processor or other programmable processing apparatus to cause a series of operational steps to be performed on the computer processor or other programmable processing apparatus to produce a computer-implemented process such that the instructions which execute on the computer processor or other programmable processing apparatus provide steps for implementing the functions specified in the block(s) of the flowchart(s), procedure (s) algorithm(s), step(s), operation(s), formula(e), or computational depiction(s).

] It will further be appreciated that the terms "programming" or "program executable" as used herein refer to one or more instructions that can be executed by one or more computer processors to perform one or more functions as described herein. The instructions can be embodied in software, in firmware, or in a combination of software and firmware. The instructions can be stored local to the device in non-transitory media, or can be stored remotely such as on a server, or all or a portion of the instructions can be stored locally and remotely. Instructions stored remotely can be downloaded (pushed) to the device by user initiation, or automatically based on one or more factors.

[00119] It will further be appreciated that as used herein, that the terms

processor, hardware processor, computer processor, central processing unit (CPU), and computer are used synonymously to denote a device capable of executing the instructions and communicating with input/output interfaces and/or peripheral devices, and that the terms processor, hardware processor, computer processor, CPU, and computer are intended to encompass single or multiple devices, single core and multicore devices, and variations thereof.

[00120] From the description herein, it will be appreciated that the present disclosure encompasses multiple embodiments which include, but are not limited to, the following:

[00121] 1 . An apparatus for performing charging station identification for electric vehicle (EV) charging, the apparatus comprising: (a) at least one charging station configured for charging an electric vehicle (EV); (b) at least one server configured for controlling said at least one charging station using network communications; (c) a processor within said at least one server, said processor configured for communication with said at least one charging station, and with a charging application on a mobile device of a user; (d) a non-transitory computer-readable memory storing instructions executable by the processor of said at least one server; (e) wherein said instructions, when executed by the processor, perform steps comprising: (e)(i) determining that the user is not already actively charging an electric vehicle, in response to receiving an identification of a charging station, or a plug on a charging station having multiple plugs, from the mobile device of the user, and checking the identification of the charging station or plug as being valid within a database of said server; (e)(ii) wherein said

identification of the charging station, or plug on a charging station having multiple plugs, is determined in response to receiving a station identifier captured and sent by the mobile device of the user; and (e)(iii) sending a command to the charging station to start a charging session on the electric vehicle associated with the user whose mobile device sent the identification of the charging station, or the plug on the charging station.

[00122] 2. An apparatus for performing charging station identification for electric vehicle (EV) charging, the apparatus comprising: (a) at least one charging station configured for charging an electric vehicle (EV); (b) at least one server configured for controlling said at least one charging station using network communications; (c) a processor within said at least one charging station, said processor configured for communication with said at least one server; (d) a non-transitory computer-readable memory storing instructions executable by the processor of said at least one charging station; (e) wherein said instructions, when executed by the processor of the charging station, performs steps comprising: (e)(i) determining that an electric vehicle is in range of the reader on the charging station; (e)(ii) retrieving identification information from the electric vehicle, and tracking its motion in relation the station; (e)(iii) determining that a charge plug has been newly plugged in and correlating this with an electric vehicle whose identification information has been retrieved; (e)(iv) transmitting station ID and vehicle ID of the electric vehicle for validation from the charging station to a server to check that the charge request is valid and that the user is not already actively charging an electric vehicle; and (e)(v) receiving a charge command from the server to commence charging the electric vehicle.

[00123] 3. A method for automated electric vehicle (EV) charging station identification, the method comprising: (a) obtaining a valid charging station identification, by a server controlling multiple charging stations over a network, as sent from a mobile device of a user within a charge request from the user in response to either: (A) reading a single or multiple axis bar code from the charging station or plug on the charging station, or (B) from a wireless communication between the mobile device and the charging station; (b) determining at the server, from checking a database of charge sessions, that the user is not already actively charging an electric vehicle; and (c) transmitting a request from the server to the charging station to start a charge session on the electric vehicle for the user.

[00124] 4. A computer program product, the computer program product comprising a non-transitory computer-readable storage medium having computer usable program code containing instructions executable by a processor of a mobile device, the computer usable program code when executed performing steps comprising: (a) activating a reader on the mobile device to determine identification of a charging station, or a plug on a charging station having multiple plugs, and (b) validating the identification of the charging station from a charge station database accessed by the mobile device; (c) communicating the identification within a charge request over a network to a server controlling multiple charging stations, to activate charging on the identified charge station.

[00125] 5. The apparatus, method, or computer program product of any preceding embodiment, wherein said instructions when executed by the processor of said server prevent sending of said request for charging unless said vehicle is plugged into said charging station.

[00126] 6. The apparatus, method, or computer program product of any preceding embodiment, wherein receiving said identification of the charging station from the mobile device of the user is obtained in response to either: (A) reading a single or multiple axis bar code from the charging station or plug on the charging station, or (B) from a wireless communication between the mobile device and the charging station.

[00127] 7. The apparatus, method, or computer program product of any preceding embodiment, wherein said wireless communication media is selected from the group of wireless communication media consisting of Bluetooth, radio-frequency identification tag (RFID), or other wireless communication protocols.

[00128] 8. The apparatus, method, or computer program product of any preceding embodiment, wherein said at least one charging station is configured having either a single charge plug per charging station or multiple charge plugs per charging station.

[00129] 9. The apparatus, method, or computer program product of any preceding embodiment, wherein said request for charging as received from the mobile device of the user comprises: user ID, user class, and station ID information.

[00130] 10. The apparatus, method, or computer program product of any preceding embodiment, wherein said instructions when executed by the processor of the server determines a charge priority ranking for the user based on amount of energy requested for the charge, and previous charging history.

[00131] 1 1. The apparatus, method, or computer program product of any preceding embodiment, wherein said instructions when executed by the processor of said server implement a solar credit system, in which solar credits can be purchased by users to increase charge priority rankings.

[00132] 12. The apparatus, method, or computer program product of any preceding embodiment, wherein said instructions when executed by the processor of said server implement said solar credit system which also comprises a boost function in which users can temporarily boost their charge rankings in response to electronic submission of a virtual system currency.

[00133] 13. The apparatus, method, or computer program product of any preceding embodiment, wherein said instructions when executed by the processor of said server implement said solar credit system which comprises a trading system that allows users to buy and sell solar credits.

[00134] 14. The apparatus, method, or computer program product of any preceding embodiment, further comprising the server determining that the electric vehicle is plugged into the selected charging station prior to sending a command from the server to that charge controller to start the charging session.

[00135] 15. The apparatus, method, or computer program product of any preceding embodiment, wherein each charging station of the multiple charging stations is configured having either a single charge plug per charging station or multiple charge plugs per charging station.

[00136] 16. The apparatus, method, or computer program product of any preceding embodiment, wherein the charge request from the mobile device of the user to the server comprises: user ID, user class, and station ID information.

[00137] 17. The apparatus, method, or computer program product of any preceding embodiment, further comprising determining a charge priority ranking for the user based on amount of energy requested for the charge, and previous charging history.

[00138] 18. The apparatus, method, or computer program product of any preceding embodiment, further comprising executing a solar credit system, in which solar credits can be purchased by users to increase charge priority rankings.

[00139] 19. The apparatus, method, or computer program product of any preceding embodiment, wherein said solar credit system comprises a boost function in which users can temporarily boost their charge rankings in response to electronic submission of a virtual system currency.

[00140] 20. The apparatus, method, or computer program product of any preceding embodiment, wherein said solar credit system comprises a trading system that allows users to buy and sell solar credits.

[00141] 21. The apparatus, method, or computer program product of any preceding embodiment, wherein said program code containing instructions executable by a processor of the mobile device further comprises determining a charge priority ranking for the user based on amount of energy requested for the charge, and previous charging history, within a solar credit system, in which solar credits can be purchased by users to increase charge priority rankings.

[00142] 22. The apparatus, method, or computer program product of any preceding embodiment, wherein said program code containing instructions executable by a processor of the mobile device further comprises executing a boost function in which users temporarily boost their charge rankings in response to electronic submission of a virtual system currency. [00143] 23. The apparatus, method, or computer program product of any preceding embodiment, wherein said program code containing instructions executable by a processor of the mobile device further comprises executing a trading system, within said solar credit system, in which users buy and/or sell solar credits.

[00144] As used herein, the singular terms "a," "an," and "the" may include plural referents unless the context clearly dictates otherwise. Reference to an object in the singular is not intended to mean "one and only one" unless explicitly so stated, but rather "one or more."

[00145] As used herein, the term "set" refers to a collection of one or more objects. Thus, for example, a set of objects can include a single object or multiple objects.

[00146] As used herein, the terms "substantially" and "about" are used to describe and account for small variations. When used in conjunction with an event or circumstance, the terms can refer to instances in which the event or circumstance occurs precisely as well as instances in which the event or circumstance occurs to a close approximation. When used in conjunction with a numerical value, the terms can refer to a range of variation of less than or equal to ± 10% of that numerical value, such as less than or equal to ±5%, less than or equal to ±4%, less than or equal to

±3%, less than or equal to ±2%, less than or equal to ±1 %, less than or equal to ±0.5%, less than or equal to ±0.1 %, or less than or equal to ±0.05%. For example, "substantially" aligned can refer to a range of angular variation of less than or equal to ±10°, such as less than or equal to ±5°, less than or equal to ±4°, less than or equal to ±3°, less than or equal to

±2°, less than or equal to ±1 °, less than or equal to ±0.5°, less than or equal to ±0.1 °, or less than or equal to ±0.05°.

[00147] Additionally, amounts, ratios, and other numerical values may

sometimes be presented herein in a range format. It is to be understood that such range format is used for convenience and brevity and should be understood flexibly to include numerical values explicitly specified as limits of a range, but also to include all individual numerical values or sub-ranges encompassed within that range as if each numerical value and sub-range is explicitly specified. For example, a ratio in the range of about 1 to about 200 should be understood to include the explicitly recited limits of about 1 and about 200, but also to include individual ratios such as about 2, about 3, and about 4, and sub-ranges such as about 10 to about 50, about 20 to about 100, and so forth.

[00148] Although the description herein contains many details, these should not be construed as limiting the scope of the disclosure but as merely providing illustrations of some of the presently preferred embodiments. Therefore, it will be appreciated that the scope of the disclosure fully encompasses other embodiments which may become obvious to those skilled in the art.

[00149] All structural and functional equivalents to the elements of the

disclosed embodiments that are known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the present claims. Furthermore, no element, component, or method step in the present disclosure is intended to be dedicated to the public regardless of whether the element, component, or method step is explicitly recited in the claims. No claim element herein is to be construed as a "means plus function" element unless the element is expressly recited using the phrase "means for". No claim element herein is to be construed as a "step plus function" element unless the element is expressly recited using the phrase "step for".

Table 1

Recurrent Checker Procedure

box. station <— all station associated with box

all box <— all boxes

ongoing_session — all ongoing sessions

paused_session <— all paused sessions

cycle_threshold <— energy threshold for large charging sessions

solar_threshold <— critical threshold for solar generation

solar_enrolled_users <— list of users who enrolled in the automatic solar program //check for charging without session

for each box in all box, do

for each station in box. station, do

if station is charging in the last 5 min, then

if station is not in ongoing_session. station

turnOff(station)

end

for each session in ongoing_sessions, do

//check for finished charging sessions

if session, station is not charging within last 10 minutes and started for more than 15 minutes, then

requestStop(session)

else

//check for user with very large demand

if session. chargedPower > cycle_threshold*(session.round+l), then %the initial value for session.round is always 0

session.round <— session.round + 1

evaluateChargingQueue(session.box)

end Table 1 (con't) if session, station is unplugged, then

requestStop(session)

end

//check for solar generation and if change exists for solar program enrolled users if solar_generation > solarjhreshold, then

if any paused session.paused due to solar = = True, then

evaluateChargingQueue(solar_paused_session.box)

end

else

if ongoing_session.user in solar_enrolled_users

evaluateChargingQueue(session_with_enrolled_user.box) end

end

Table 2

EvaluateChargingQueue (box) Procedure

Input: the box to evaluate the charging ranking

active_session <— all active sessions (including ongoing and paused) within the box, sorted first by session. boost from high to low, session.round from low to high and by session. user.solar_score from high to low

solar_threshold <— critical threshold for solar generation

allowed_station <— 1

index — 0

for each session in active_session, do

if index < allowed station, then

//high ranked user to start charging

if session, user is not enrolled in solar program, then

charge — 1

else

if solar_generation > solar_threshold, then

charge <— 1

else

charge <— 0

end

if charge == 1, then

if session, station is charging, then

status <— True

else

status <— turnOn(session. station)

end

if status = = True, then

if session. start_time is null, then

//first time the session is being started

session. on_going <— True

session. start_energy <— session. station.getEnergyO Table 2 (con't)

session. start_time <— current_time

else

session. on_going <— True

end

else

//the user is being paused due to low solar generation, move on to next user if session, station is not charging, then

status <— True

else

status <— turnOff(session. station)

end

if status = = True, then

session.paused <— True

session.paused_due_to_solar <— True allowed_station <— allowed_station + 1

end

else

//pause lower ranked users

if session, station is not charging, then

status <— True

else

status <— turnOff(session. station)

end

if status = = True, then

session.paused — True

session.paused_due_to_solar <— False

end

index — index + 1

end Table 3

RequestStop (session) Procedure

Input: the session to stop

if session. start_energy is null, then

session. on_going <— false

else

if session, station is not charging, then

status <— True

else

status <— turnOff(session. station)

end

if status == True, then

session. on_going <— false

session.finish_energy <— session. station. getEnergy() end

end

Table 4

RequestStart (station, user) Proced

Input: the station to start, the user who requests the session Create active_session with the requested station and user evaluateChargingQueue (session.box)

Table 5

Charging Paradigm Table

Table 6

Alternate EvaluateChargingQueue (box) Procedure

evaluateChargingQueue (box)

Input: the box to evaluate the charging ranking

// active session— all active sessions (including ongoing and paused) within the box, sorted first by session.boost from high to low, session.round from low to high and by session. user. solar score from high to low on station — all stations that are charging if activesession = = 1, then

on duty on station.number = = 1? 50:30

off duty on station.number == 1? 0:20

else

on_duty = 30

off _duty = 20

end

index — 0

for each session in active_session, do

if index < allowed station, then

//high ranked user

if session.boost 1, then

on duty

off duty

end

theOtherStation = getTheOtherStation(session.

theOtherStation.changeDutyCycle(off duty)

session. station. changeDutyCycle(on_duty)

end

index index + 1

end Table 7

Purchase Credit Procedure Example purchaseCredit (user, solar, price system)

Input: user, amount of solar credit to purchase, price to pay, if purchase from system

Price of buying solar from system

all listing <— All solar credit offerings from all users, sorted from low price to high price if system = = 1, then

//purchase from system

if solar*system_price == price, then

user.solar_credit += solar

user. coin -= solar*system_price

else

return Error

end

else

price_prime = 0

energy _prime = solar

index = 0

for each listing in all listing, do

if energy _prime > listing, energy, then

//buy all

energy _prime -= listing, energy

price_prime += listing, price * listing, energy

transaction[index]. listing = listing

transaction[index]. energy = listing, energy

else

//last session

price_prime += listing, price * energy _prime

transaction[index]. listing = listing

transaction[index]. energy = energy _prime

end

index++ Table 7 (con't.) end

if price_prime == price, then

for buy index = 0 : index- 1, do

user, coin -= trans action [buy index], listing, price

transaction [buy index] . energy

user.solar += trans action [buy index], energy

transaction[buy index]. listing.user.coin +=

transaction[buy index]. listing.price * transaction[buy index]. energy

transaction[buy index]. listing. user.solar =- transaction[buy index]. energy end

else

return Error

end

Claims

What is claimed is: 1 . An apparatus for performing charging station identification for electric vehicle (EV) charging, the apparatus comprising:

(a) at least one charging station configured for charging an electric vehicle (EV);

(b) at least one server configured for controlling said at least one charging station using network communications;

(c) a processor within said at least one server, said processor configured for communication with said at least one charging station, and with a charging application on a mobile device of a user;

(d) a non-transitory computer-readable memory storing instructions executable by the processor of said at least one server;

(e) wherein said instructions, when executed by the processor, perform steps comprising:

(i) determining that the user is not already actively charging an electric vehicle, in response to receiving an identification of a charging station, or a plug on a charging station having multiple plugs, from the mobile device of the user, and checking the identification of the charging station or plug as being valid within a database of said server;

(ii) wherein said identification of the charging station, or plug on a charging station having multiple plugs, is determined in response to receiving a station identifier captured and sent by the mobile device of the user; and

(iii) sending a command to the charging station to start a charging session on the electric vehicle associated with the user whose mobile device sent the identification of the charging station, or the plug on the charging station.

2. The apparatus of claim 1 , wherein said instructions when executed by the processor of said server prevent sending of said request for charging unless said vehicle is plugged into said charging station.

3. The apparatus of claim 1 , wherein receiving said identification of the charging station from the mobile device of the user is obtained in response to either: (A) reading a single or multiple axis bar code from the charging station or plug on the charging station, or (B) from a wireless communication between the mobile device and the charging station.

4. The apparatus of claim 3, wherein said wireless communication media is selected from the group of wireless communication media consisting of Bluetooth, radio-frequency identification tag (RFID), or other wireless

communication protocols.

5. The apparatus of claim 1 , wherein said at least one charging station is configured having either a single charge plug per charging station or multiple charge plugs per charging station.

6. The apparatus of claim 1 , wherein said request for charging as received from the mobile device of the user comprises: user ID, user class, and station ID information.

7. The apparatus of claim 1 , wherein said instructions when executed by the processor of the server determines a charge priority ranking for the user based on amount of energy requested for the charge, and previous charging history.

8. The apparatus of claim 7, wherein said instructions when executed by the processor of said server implement a solar credit system, in which solar credits can be purchased by users to increase charge priority rankings.

9. The apparatus of claim 8, wherein said instructions when executed by the processor of said server implement said solar credit system which also comprises a boost function in which users can temporarily boost their charge rankings in response to electronic submission of a virtual system currency.

10. The apparatus of claim 8, wherein said instructions when executed by the processor of said server implement said solar credit system which comprises a trading system that allows users to buy and sell solar credits.

1 1 . An apparatus for performing charging station identification for electric vehicle (EV) charging, the apparatus comprising:

(c) a processor within said at least one charging station, said processor configured for communication with said at least one server;

(d) a non-transitory computer-readable memory storing instructions executable by the processor of said at least one charging station;

(e) wherein said instructions, when executed by the processor of the charging station, performs steps comprising:

(i) determining that an electric vehicle is in range of the reader on the charging station;

(ii) retrieving identification information from the electric vehicle, and tracking its motion in relation the station;

(iii) determining that a charge plug has been newly plugged in and correlating this with an electric vehicle whose identification information has been retrieved;

(iv) transmitting station I D and vehicle ID of the electric vehicle for validation from the charging station to a server to check that the charge request is valid and that the user is not already actively charging an electric vehicle; and (v) receiving a charge command from the server to commence charging the electric vehicle.

12. A method for automated electric vehicle (EV) charging station identification, the method comprising:

(a) obtaining a valid charging station identification, by a server controlling multiple charging stations over a network, as sent from a mobile device of a user within a charge request from the user in response to either: (A) reading a single or multiple axis bar code from the charging station or plug on the charging station, or (B) from a wireless communication between the mobile device and the charging station;

(b) determining at the server, from checking a database of charge sessions, that the user is not already actively charging an electric vehicle; and

(c) transmitting a request from the server to the charging station to start a charge session on the electric vehicle for the user.

13. The method of claim 12, further comprising the server determining that the electric vehicle is plugged into the selected charging station prior to sending a command from the server to that charge controller to start the charging session.

14. The method of claim 12, wherein each charging station of the multiple charging stations is configured having either a single charge plug per charging station or multiple charge plugs per charging station.

15. The method of claim 12, wherein the charge request from the mobile device of the user to the server comprises: user ID, user class, and station ID information.

16. The method of claim 12, further comprising determining a charge priority ranking for the user based on amount of energy requested for the charge, and previous charging history.

17. The method of claim 16, further comprising executing a solar credit system, in which solar credits can be purchased by users to increase charge priority rankings.

18. The method of claim 16, wherein said solar credit system comprises a boost function in which users can temporarily boost their charge rankings in response to electronic submission of a virtual system currency.

19. The method of claim 18, wherein said solar credit system comprises a trading system that allows users to buy and sell solar credits.

20. A computer program product, the computer program product comprising a non-transitory computer-readable storage medium having computer usable program code containing instructions executable by a processor of a mobile device, the computer usable program code when executed performing steps comprising:

(a) activating a reader on the mobile device to determine identification of a charging station, or a plug on a charging station having multiple plugs, and

(b) validating the identification of the charging station from a charge station database accessed by the mobile device;

(c) communicating the identification within a charge request over a network to a server controlling multiple charging stations, to activate charging on the identified charge station.

21 . The computer program product of claim 20, wherein said program code containing instructions executable by a processor of the mobile device further comprises determining a charge priority ranking for the user based on amount of energy requested for the charge, and previous charging history, within a solar credit system, in which solar credits can be purchased by users to increase charge priority rankings.

22. The computer program product of claim 21 , wherein said program code containing instructions executable by a processor of the mobile device further comprises executing a boost function in which users temporarily boost their charge rankings in response to electronic submission of a virtual system currency.

23. The computer program product of claim 21 , wherein said program code containing instructions executable by a processor of the mobile device further comprises executing a trading system, within said solar credit system, in which users buy and/or sell solar credits.